ai-native?

Глосарій AI-Native розробки: Agentic Coding, Vibe Coding та ще 16 термінів

Agentic coding — це підхід до розробки, де автономні AI-агенти планують, пишуть, запускають, тестують і змінюють код у кілька кроків з мінімальним втручанням людини, використовуючи такі інструменти, як оболонка, редагування файлів і тести всередині зворотного циклу. Цей глосарій визначає agentic coding та ще 17 AI-native термінів, кожен з яких прив'язаний до відповідного рівня 7-рівневої моделі AI-Native Developer.

Словник AI-native розробки розвивається швидше за словники. Нові терміни — agentic coding, vibe coding, MCP, context engineering, subagents — з'являються в X, потрапляють у CLI, а потім стають частиною робочого процесу команд — і все це за один квартал. Ця сторінка є канонічним довідником: кожен термін отримує чітке, цитабельне визначення, факти про походження, які більшість глосаріїв пропускає, і прив'язку до місця на 7-рівневій моделі AI-Native Developer — від L1 Chat-Assisted Developer до L7 Universal AI Creator.

Кожен запис завершується одним і тим самим чесним питанням: на якому рівні це вас ставить? Коли закінчите читати, пройдіть 3-хвилинний тест і дізнайтеся.

Перейти до терміну

Термін Рівень Термін Рівень
AI-native developer L1–L7 evals L6
Agentic coding L3 worktrees L5+
Agentic engineering L4–L5 Context engineering L4–L6
Vibe coding Поза сходинками Spec-driven development L4–L6
AI-assisted development L1–L7 Autonomous coding agent L3→L5
MCP L5–L6 Prompt engineering L1–L2
Agent orchestration L5 AI coding maturity model сама модель
Subagents L5+ Model routing L5–L6
Plan-before-code L3–L4 Verification harness L4–L5

AI-native developer

AI-native developer — це розробник, чий типовий робочий процес полягає у керуванні AI-системами для планування, написання, тестування та випуску коду, а не у ручному наборі більшості рядків. Це вимірюється рівнем автономії та звичками верифікації — а не кількістю встановлених AI-інструментів.

Сьогодні майже кожен розробник «використовує AI». Але це зовсім інше. Бути AI-native — це позиція, а не набір інструментів: AI є вашим основним виробничим механізмом, а ваша роль зміщується до керування, рев'ю та верифікації. Ключове питання не в тому, чи є у вас AI-асистент, а в тому — наскільки ви делегуєте і як перевіряєте результат?

Саме цю рису оцінює 7-рівнева модель AI-Native Developer — від L1 Chat-Assisted Developer («Старошкільний майстер», що копіпастить із чату) до L7 Universal AI Creator (одна людина, що запускає повний продуктовий цикл з агентами). Де ви опиняєтеся — залежить від автономії та верифікації, а не від вайбів.

На якому рівні це вас ставить? Пройти тест →

Agentic coding

Agentic coding — це підхід до розробки, де автономні AI-агенти планують, пишуть, запускають, тестують і змінюють код у кілька кроків з мінімальним втручанням людини, використовуючи інструменти — оболонку, редагування файлів, тест-ранери — всередині зворотного циклу до виконання задачі.

Ключове слово — цикл. Однокрокове чат-автодоповнення видає вам фрагмент і зупиняється; agentic coding агент володіє всією задачею. Він читає репозиторій, складає план, редагує файли, запускає тести, читає помилки і пробує знову — ітеруючи по довгій траєкторії, а не відповідаючи на один промпт. Google Cloud визначає це як підхід до розробки програмного забезпечення, де автономні AI-агенти планують, пишуть, тестують і змінюють код з мінімальним втручанням людини; IBM позиціонує coding agents як AI-системи, що поєднують LLM-міркування з доступом до інструментів кодування для дії в кілька кроків.

На сходинках agentic coding є відзнакою L3, Agentic Developer («The Agentic Native») — де агент пише рутину, ви плануєте перед кодом і не приймаєте його слова на віру. Детальніше — у розділі про agentic coding або на самому рівні L3 →.

На якому рівні це вас ставить? Пройти тест →

Agentic engineering

Agentic engineering — це фахова дисципліна оркестрування AI-агентів кодування як мультиплікаторів зусиль, де людина зберігає відповідальність за архітектуру, якість і верифікацію. Агенти роблять більшість набору; інженер — керує, обмежує й валідує.

Якщо agentic coding — це техніка, то agentic engineering — це суворість навколо неї. За визначенням MindStudio, це практика оркестрування AI-агентів кодування для виконання більшості коду, тоді як людина зберігає відповідальність за архітектуру, якість коду та інженерне судження — позиціонується як дисциплінований наступник vibe coding у 2026 році. Акцент — на специфікаціях, evals, рев'ю та відтворюваності, а не на «приймаю і сподіваюся».

Це відповідає діапазону L4–L5 — Director та Orchestrator — де ви перестаєте набирати рутину і починаєте будувати систему, яка її виробляє. Дивіться, як vibe coding і agentic engineering розходяться у vibe coding vs agentic coding, або перегляньте всі рівні.

На якому рівні це вас ставить? Пройти тест →

Vibe coding

Vibe coding — це створення програмного забезпечення шляхом промптингу AI та прийняття його виводу без перегляду коду. Андрей Карпаті ввів цей термін 2 лютого 2025 року, описуючи повне занурення у вайби та забуття про існування коду — прийняття змін AI без читання diff'ів.

Саймон Вілліссон загострив це до практичного критерію: vibe coding — це «розробка програмного забезпечення з LLM без перегляду коду, який він пише». Його висновок — це те, що турбує досвідчених розробників: якщо ви переглядаєте, тестуєте й можете пояснити код, «це розробка програмного забезпечення», а не vibe coding. Ця межа — і є вся гра. Vibe coding чудово підходить для одноразових прототипів та вихідних експериментів; це зобов'язання, коли річ має запускатися у продакшні без нагляду.

Принципово, vibe coding знаходиться поза інженерними сходинками L1–L7. Воно породжує архетип Vibe Builder: no-code/AI-творець, який запускає реальні продукти за допомогою AI app-builder-інструментів без написання традиційного коду — AI-native з першого дня, але інший вид, ніж інженер на сходинках зрілості. Це не пониження; це інша гра зі своєю суперсилою (швидкістю) та своєю стелею. Детальніше у vibe coding і в порівнянні vibe coding vs agentic coding.

На якому рівні це вас ставить? Пройти тест →

AI-assisted development

AI-assisted development — це будь-який робочий процес, де AI-інструменти — автодоповнення, чат або агенти — допомагають писати чи змінювати код, тоді як людина залишається в циклі, переглядаючи та приймаючи рішення. Це широка парасолька, що охоплює все від L1 до L7.

Думайте про це як про надмножину. І vibe coding, і agentic coding знаходяться всередині AI-assisted development; що їх розділяє — це скільки автономії ви надаєте і як перевіряєте вивід. Надавайте мало й перевіряйте все вручну — і ви делегуєте на початку сходинок. Надавайте багато, але підключіть verification harness — і ви займаєтеся дисциплінованим agentic engineering. Сам термін навмисно широкий — і саме тому рівнева модель корисна для визначення вашого місця всередині неї.

7-рівнева модель — це карта, яка перетворює цю парасольку на спектр, де ви можете знайти своє місце.

На якому рівні це вас ставить? Пройти тест →

MCP (Model Context Protocol)

MCP (Model Context Protocol) — це відкритий стандарт, що дозволяє AI-моделям підключатися до зовнішніх інструментів і джерел даних через один універсальний інтерфейс замість окремих інтеграцій для кожного інструменту. Anthropic представила та відкрила вихідний код 25 листопада 2024 року (версія специфікації 2024-11-05), разом з Python і TypeScript SDK.

Ментальна модель, до якої вдаються, — «USB-C для AI-інструментів»: один протокол, і будь-який сумісний клієнт може взаємодіяти з будь-яким сумісним сервером — ваші документи, база даних, трекер задач, оболонка. До MCP кожна інтеграція була окремою; після нього охоплення агента стає plug-in-екосистемою. Прийняття широко поширилося по галузі протягом 2025–2026 років, і ви можете прочитати першоджерело в анонсі Anthropic.

Підключення готового MCP-сервера — це те, що більшість AI-assisted розробників може зробити на ранніх етапах. Але управління MCP в межах команди — вирішення, що агентам дозволено досягати, і написання повторно використовуваних серверів — є сигналом L5–L6 Methodologist. Дивіться L6 → і пов'язаний запис про agent orchestration.

На якому рівні це вас ставить? Пройти тест →

Agent orchestration

Agent orchestration — це координація кількох AI-агентів — призначення задач, послідовність кроків, управління спільним станом і злиття результатів — так, щоб команда агентів виконала роботу, яку один агент не може надійно зробити самостійно.

Домінуюча форма — це orchestrator-worker (менеджер-виконавець): один агент планує й делегує, тоді як обмежені агенти-виконавці виконують і звітують. Згідно з документацією Claude Code, у цій схемі оркестратор відповідає за план, а кожен виконавець обробляє обмежену задачу — структура, яка робить багатоагентну роботу керованою, а не хаотичною.

Це визначальна риса L5, AI Engineering Architect («The Orchestrator») — рівня, де ви проєктуєте стек агентів, а не просто керуєте одним агентом. Дивіться L5 →, потім будівельні блоки: subagents і worktrees.

На якому рівні це вас ставить? Пройти тест →

Subagents

Subagents — це ізольовані агенти-виконавці, яким основний агент делегує задачі; кожен запускається з власним свіжим контекстом, доступом до інструментів і правами та повертає єдиний підсумок — зберігаючи контекст основного агента чистим, а роботу — паралелізованою.

Subagents — це те, що робить оркестрування керованим. Замість одного роздутого контекстного вікна, що жонглює всім, основний агент відправляє обмежених виконавців, кожен з чистим аркушем, і отримує акуратний результат. Згідно з документацією Claude Code, кожен subagent запускається з власним контекстом, інструментами та правами — і не може породжувати подальших subagents, тому вкладеність обмежена за задумом. Це обмеження є перевагою: воно запобігає неконтрольованому розростанню дерев агентів.

Регулярне використання subagents є поведінковим сигналом L5+ — ви перейшли від керування одним агентом до управління невеликою командою. Дивіться L5 → і ширший патерн у agent orchestration.

На якому рівні це вас ставить? Пройти тест →

Plan-before-code

Plan-before-code — це дисципліна agentic coding, де агент (або людина) складає явний план і отримує його схвалення перед написанням будь-якого коду — щоб намір перевірявся заздалегідь, а етап реалізації залишався обмеженим і перевіреним.

Це дешевий страховий поліс. Кілька хвилин на підтвердження «ось що я збираюся зробити і чому» запобігають дорогому сценарію, коли агент впевнено редагує двадцять файлів у неправильному напрямку. Це також витрачає менше токенів і створює diff'и, про які можна реально міркувати. Plan-before-code — це вхідна звичка, яка природно веде до spec-driven development.

Це звичка зрілості L3–L4 — момент, коли ви перестаєте дозволяти агентам вільно бігати і починаєте їх гейтувати на схваленому плані.

На якому рівні це вас ставить? Пройти тест →

Verification harness

Verification harness — це набір автоматизованих перевірок — тести, лінтери, перевірки типів, скрипти збірки та запуску — підключених так, щоб AI-агент міг перевіряти власну роботу в циклі та самокоректуватися без того, щоб людина читала кожен diff.

Це єдина річ, яка робить agentic coding з високою автономією («YOLO»-режим) безпечним, а не безрозсудним. Агент із сильним harness'ом може працювати гаряче — спробувати зміну, запустити перевірки, прочитати помилки, виправити, повторити — тому що перевірки перехоплюють його помилки до вас. Агент без harness'у — це просто неперевірений ризик, що рухається швидко. Harness — це те, що перетворює довіру на систему, а не на надію.

Побудова повторно використовуваних harness'ів — це розподільна лінія L4–L5: вона відокремлює «я перевіряю кожну зміну» від «я довіряю циклу і перевіряю результат». Дивіться рівні →, потім поєднайте це з evals.

На якому рівні це вас ставить? Пройти тест →

Evals

Evals — це систематичні тести, що вимірюють, чи AI-модель або агент продукує коректні, надійні виводи. Для coding agents evals перевіряють, чи агент правильно планує, викликає інструменти та виконує багатокрокові задачі по всій траєкторії — а не лише чи виглядає правильною кінцева відповідь.

Є дві основні форми, згідно з Confident AI: code-based evals (автоматизовані, CI-стиль твердження) та LLM-as-a-judge. Для роботи з кодом важлива траєкторія, тому що запуск охоплює багато кроків — агент може створити правильний файл з неправильних причин або пройти небезпечний шлях до успішного тесту. Evals це виловлюють. Це різниця між «один раз спрацювало» і «працює надійно».

Написання та підтримка evals є сигналом L6 Methodologist — ви не просто використовуєте агентів, ви вимірюєте й сертифікуєте їхню поведінку. Дивіться L6 → і суміжний запис — verification harness.

На якому рівні це вас ставить? Пройти тест →

Worktrees

Git worktrees — це окремі робочі директорії, що спільно використовують історію одного репозиторію, що дозволяє кільком AI-агентам працювати паралельно в ізольованих гілках або чекаутах — не перезаписуючи файли один одного.

Це стандартний механізм для запуску кількох сесій Claude Code на одній кодовій базі одночасно. Згідно з документацією Claude Code, worktree — це окрема робоча директорія з власною гілкою, яка ділить одну і ту ж історію репозиторію, що дозволяє кільком агентам працювати паралельно в ізольованих чекаутах. На практиці ви поєднуєте worktrees з ізоляцією портів і баз даних, щоб паралельні агенти не стикалися і поза файловою системою.

Паралельні робочі процеси агентів у worktrees — це риса L5+: Director на L4 вже запускає кілька агентів таким чином, а L5 Orchestrator систематизує це. Дивіться agent orchestration і L5 →.

На якому рівні це вас ставить? Пройти тест →

Context engineering

Context engineering — це, за формулюванням Андрея Карпаті у червні 2025 року, «делікатне мистецтво і наука заповнення контекстного вікна саме правильною інформацією для наступного кроку». Це дисципліна проєктування всього, що бачить LLM: інструкції, отримані документи, виводи інструментів, пам'ять і стан.

Карпаті підтримав цей термін замість «prompt engineering» у червні 2025 року, а Anthropic формалізувала концепцію у вересні 2025 року. Переосмислення важливе: у продакшн-агентних системах формулювання будь-якого окремого промпту — це невеликий зріз того, що визначає якість виводу. Як зазначає Glean, prompt engineering є підмножиною context engineering — повний контекст також включає історію розмови, отримані документи, виводи інструментів і стан агента. Розрив у якості між AI-користувачами сьогодні — це контекст, а не магічні слова.

Цілеспрямований context engineering є сигналом L4–L6 — це те, що роблять люди, коли підбирають файли CLAUDE.md, проєктують retrieval і навмисно управляють контекстним вікном. Порівняйте з його підмножиною, prompt engineering, і дивіться рівні →.

На якому рівні це вас ставить? Пройти тест →

Spec-driven development

Spec-driven development — це методологія, яка робить письмову специфікацію джерелом істини, яке AI-агенти використовують для генерації, тестування та валідації коду. Ви пишете специфікацію спочатку, потім план, потім невеликі тестовані задачі, потім реалізацію.

Згідно з GitHub, специфікація стає контрактом про те, як має поводитися код — джерело істини, що інструменти й AI-агенти використовують для генерації, тестування та валідації коду. GitHub анонсував і відкрив вихідний код Spec Kit (ліцензія MIT) 2 вересня 2025 року з основним потоком Spec → Plan → Tasks → Implement, явно позиціонованим як відтворювана, дисциплінована альтернатива ad-hoc vibe coding. Це plan-before-code, доведений до логічного завершення.

Spec-driven робочі процеси є маркером зрілості L4–L6. Вони будуються на plan-before-code і знаходяться в серці того, як Director'и та Methodologist'и здають роботу. Дивіться рівні →.

На якому рівні це вас ставить? Пройти тест →

Autonomous coding agent

Autonomous coding agent — це AI-система, яка отримує ціль і самостійно планує, редагує файли, запускає команди й тести та ітерує до завершення — працюючи по довгій багатокроковій траєкторії, а не відповідаючи на один промпт.

CLI-агенти на кшталт Claude Code — це канонічний приклад. Важливий нюанс: автономія — це спектр, а не перемикач: наскільки далеко ви дозволяєте агенту працювати без нагляду («YOLO-режим») визначається двома речами — вашим verification harness і правами, які ви йому надаєте. Сильний harness плюс жорсткі права = безпечна автономія. Слабкий harness плюс широкі права = поганий вечір.

Навчитися довіряти автономним агентам без руйнування продакшну — це і є прогресія L3 → L5 сама по собі: від «агент пише рутину» до «агент виконує багатотікетні цикли від початку до кінця». Дивіться рівні →.

На якому рівні це вас ставить? Пройти тест →

Prompt engineering

Prompt engineering — це практика складання текстових інструкцій для LLM — формулювання, приклади, роль і формат виводу — для спрямування його до бажаного однокрокового результату.

Це все ще важливо; чіткі інструкції досі перевищують неохайні. Але галузь переосмислила це як один компонент більшої дисципліни. У продакшн-агентних системах промпт — це невелика частка загального контексту, який також включає історію, отримані документи, виводи інструментів і стан — саме тому context engineering став більш корисним фреймом.

Prompt engineering — це основа L1–L2, яка переростає в context engineering близько L4. Саме звідси більшість починає; але це не вершина.

На якому рівні це вас ставить? Пройти тест →

AI coding maturity model

AI coding maturity model — це рівнева система, що оцінює, наскільки AI-native є розробник або команда — за автономією та поведінкою верифікації, а не за кількістю інструментів. 7-рівнева модель AI-Native Developer від ProCoders (L1 Chat-Assisted → L7 Universal AI Creator) — одна з них; 8 стадій agentic workflow від Стіва Єгге — інша.

Моделі зрілості дають мові, що швидко розвивається, спільний словник для градієнту довіри — від «AI автодоповнює рядок» до «я побудував власний оркестратор». 8 рівнів Єгге описують той самий градієнт — від майже нульового використання AI до побудови власного оркестратора, з критичним переходом на стадії 5–6, де один синхронний агент поступається місцем кільком паралельним агентам (за зведенням Augment Code). Рівнева система — це те, що дозволяє командам говорити про напрямок, а не лише про інструменти.

Канонічний приклад на цьому сайті і є модель — названа 7-рівнева модель AI-Native Developer, з персонажами і конкретними поведінковими сигналами для кожної сходинки. Найшвидший спосіб скористатися нею — тест.

На якому рівні це вас ставить? Пройти тест →

Model routing

Model routing — це автоматичний вибір AI-моделі або провайдера для кожного запиту на основі вартості, затримки, можливостей і доступності — прості задачі надсилаються до дешевих моделей, складні — до frontier-моделей, з fallback-варіантами.

Це важіль вартості й надійності, і різниця достатньо велика, щоб мати значення: за даними OpenRouter, вартість за токен між frontier і дешевшими моделями може відрізнятися приблизно в 10–50 разів, а такі платформи як OpenRouter надають елементи управління маршрутизацією і ліміти ціни. Правильно маршрутизуйте флот агентів — і ви залишите дорогі frontier-моделі для роботи, яка справді їх потребує, тоді як дешевші моделі поглинають просту кількість.

Маршрутизація моделей в флоті агентів — і встановлення для цього політики — є сигналом архітектора L5–L6; L5 Orchestrator відповідає за політику маршрутизації моделей в агентах команди. Дивіться L5 →.

На якому рівні це вас ставить? Пройти тест →


Як ці терміни відображаються на сходинках

Визначення — лише половина картини. Причина, чому цей глосарій прив'язує кожен термін до рівня, полягає в тому, що те саме слово означає різні речі на різних рівнях зрілості. «Використовувати MCP» — це ранній сигнал; «управляти MCP» — старший. «Запустити агента» — це L3; «оркеструвати флот у worktrees» — L5. Ось стислий огляд:

Рівень Персонаж Терміни глосарію, що його сигналізують
L1 Chat-Assisted Old-School Artisan prompt engineering
L2 AI-Assisted Junior Delegator prompt engineering, AI-assisted development
L3 Agentic Developer Agentic Native agentic coding, plan-before-code, autonomous coding agent
L4 System Builder Director verification harness, spec-driven development, context engineering
L5 Engineering Architect Orchestrator agent orchestration, subagents, worktrees, model routing
L6 Methodologist Methodologist evals, управління MCP, портативні методи
L7 Universal AI Creator Creator повний цикл соло по всьому вищезазначеному
Поза сходинками Vibe Builder vibe coding

Останній рядок — це розрізнення, яке загальні глосарії пропускають. Vibe coding — це не низька сходинка — це зовсім інші сходи. Vibe Builder запускає продукти без традиційного коду; інженер L1–L7 підіймається до управління системами, що це роблять. Обидва легітимні; вони просто не на одному шляху.

Знайдіть свій рівень

Читання визначень розповідає вам, що означають слова. Тест розповідає, де ви знаходитеся на 7-рівневій моделі AI-Native Developer — на основі вашої реальної автономії та звичок верифікації, приблизно за три хвилини.

Пройти тест → /quiz

FAQ

Що таке agentic coding?
Agentic coding — це підхід до розробки, де автономні AI-агенти планують, пишуть, запускають, тестують і змінюють код у кілька кроків з мінімальним втручанням людини, використовуючи такі інструменти як оболонка, редагування файлів і тест-ранери всередині зворотного циклу. На відміну від однокрокового автодоповнення, агент відповідає за всю задачу й ітерує до завершення. У 7-рівневій моделі AI-Native Developer він відповідає L3, Agentic Developer.
У чому різниця між vibe coding і agentic coding?
Vibe coding означає промптити AI і приймати його вивід без перегляду коду (Саймон Вілліссон: «розробка програмного забезпечення з LLM без перегляду коду, який він пише») — підходить для прототипів, ризиковано для продакшну. Agentic coding — дисципліноване: агент виконує цикл план-тест-виправлення проти verification harness, а ви керуєте і валідуєте результат. Vibe coding породжує off-ladder архетип Vibe Builder; agentic coding — це навичка інженера L3+.
Що таке MCP (Model Context Protocol)?
MCP — це відкритий стандарт, що дозволяє AI-моделям підключатися до зовнішніх інструментів і джерел даних через один універсальний інтерфейс замість окремих інтеграцій для кожного інструменту — часто його називають «USB-C для AI-інструментів». Anthropic представила й відкрила вихідний код 25 листопада 2024 року (версія специфікації 2024-11-05), разом з Python і TypeScript SDK, і він широко прийнятий по галузі протягом 2025–2026 років.
Хто ввів термін 'vibe coding'?
Андрей Карпаті ввів 'vibe coding' у пості в X 2 лютого 2025 року, описуючи повне занурення у вайби та забуття про існування коду — прийняття змін AI без читання diff'ів. Саймон Вілліссон пізніше загострив це до практичного критерію: vibe coding — це розробка програмного забезпечення з LLM без перегляду коду, який він пише.
У чому різниця між prompt engineering і context engineering?
Prompt engineering — це складання текстових інструкцій для LLM для досягнення однокрокового результату. Context engineering — підтримане Андреєм Карпаті у червні 2025 року як «делікатне мистецтво і наука заповнення контекстного вікна саме правильною інформацією для наступного кроку» та формалізоване Anthropic у вересні 2025 року — це ширша дисципліна проєктування всього, що бачить модель: інструкції, історія, отримані документи, виводи інструментів і стан. Prompt engineering є підмножиною context engineering.
Що таке AI coding maturity model?
AI coding maturity model — це рівнева система, що оцінює, наскільки AI-native є розробник або команда, за автономією та поведінкою верифікації, а не за кількістю інструментів. 7-рівнева модель AI-Native Developer від ProCoders охоплює від L1 Chat-Assisted Developer до L7 Universal AI Creator; 8 стадій agentic workflow Стіва Єгге — інша, з критичним переходом на стадії 5–6, де один синхронний агент поступається місцем кільком паралельним агентам.

А де ти?