Глосарій 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 — на основі вашої реальної автономії та звичок верифікації, приблизно за три хвилини.
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, де один синхронний агент поступається місцем кільком паралельним агентам.