Vibe Coding проти Agentic Engineering: що стверджує нова біла книга Google про SDLC

Від слогану до технічної документації

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

Приблизно через шістнадцять місяців Google оприлюднив 50-сторінковий документ під назвою «The New SDLC With Vibe Coding», написаний Адді Османі, Шубхамом Сабуу та Сократісом Картакісом. Він є деталізованим та чітко структурованим, а його послання є різким: vibe coding підходив для прототипів, проте поступово пошкоджує системи для продакшну, і багато команд не усвідомлюють цього, оскільки шкода накопичується поступово. Нижченаведені розділи розглядають аргументи документа, його чіткі межі та наслідки для тих, хто створює продукти за допомогою AI-агентів у 2026 році.

Чому vibe coding спрацював та де він закінчується

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

Коли агенти стали кращими, команди почали застосовувати цю саму просту практику запиту та прийняття рішень у роботі в продакшені, включаючи API для оплат, логіку автентифікації, канали передачі даних та інструменти охорони здоров’я. Результат виглядає акуратно та зазвичай проходить базові тести, тож його впроваджують у експлуатацію. Через кілька тижнів чи місяців щось зламується у спосіб, який є дорогим та складним для виявлення причин.

Причина криється у структурі. Метод Vibe coding був створений для швидкого запуску чогось, а не для дотримання вимог якості продакшен-рівня, і це різні цілі. Змішування цих підходів є причиною сучасних проблем. У білій книзі намагаються надати командам необхідну лексику та фреймворк, щоб запобігти їх змішуванню.

Спектр із одним фактором розмежування

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

Цей спектр охоплює три виміри: спосіб визначення наміру, рівень ретельності перевірки та профіль ризиків. Один фактор розділяє ці кінці, і це не те, яку модель ви використовуєте, наскільки розумними є ваші запити чи який інструмент ви обираєте. Це спосіб перевірки результатів.

Потрібні два види перевірок. Детерміністичні тести перевіряють, чи функція повертає правильний результат для заданого вхідних даних. Оцінка траєкторії перевіряє, чи агент дотримувався правильної послідовності кроків міркувань для досягнення цілі. Без обох цих видів перевірок ви все одно займаєтесь «вайб-кодингом», як би складною не виглядала конфігурація. Відполірований, плавний результат, у якого пропущена верифікація, — це не успіх. Це ще небезпечніша невдача, ніж та, що демонструє помилку, адже вона залишається прихованою аж до етапу впровадження. Ось це жорстка норма, і саме вона пояснює, чому багато команд із складними агентними робочими процесами все ще технічно займаються «вайб-кодингом».

Модель — не головна змінна

Це, ймовірно, найважливіша технічна зміна в цій статті, і багато розробників роблять помилки в її розумінні. Коли агент поводиться неправильно, зазвичай починають звинувачувати модель у тому, що вона занадто слабка, занадто повільна або схильна до галюцинацій, і вважають, що краща модель — це рішення проблеми. Однак такий підхід майже завжди є хибним.

Модель — це лише одна з складових. Решта, а саме запити, інструменти, правила контексту, средова среда виконання, підагенти та можливості спостереження, становлять інфраструктуру підтримки, і поведінка агента значною мірою залежить від неї, а не від самої моделі. Два дані зі статті підтверджують це. У проекті Terminal Bench 2.0 одна команда підняла агента для програмування з місця нижче 30-го у списку до першої п’ятірки, змінивши лише інфраструктуру підтримки. У окремому дослідженні LangChain зміни до системного запиту, інструментів та проміжного програмного забезпечення при незмінній моделі додали 13,7 балів до результатів агента у тестах.

Файли правил, інструменти, сандбокси, логіка оркестрації, механізми контролю та засоби візуалізації — усе це є частиною комплексу, і створення його повністю лежить на команді. Постачальник надсилає двигун, а команда будує навколо нього всю інфраструктуру. Якщо говорити чесно, більшість збоїв агентів пов’язані з проблемами конфігурації: відсутній інструмент, нечітке правило, відсутній механізм контролю чи вікно контексту, заповнене шумом. Вина покладається на модель, оскільки вона є видимим шаром, тоді як справжня проблема знаходиться у самому комплексі. Постійні оновлення моделей та ігнорування комплексу схожі на встановлення більш потужного двигуна у автомобіль без гальм.

Інженерія контексту замінює інженерію запитів

Інженерія запитів як окрема дисципліна переважно зникла, і її місце зайняла інженерія контексту. Це означає надання агентам насиченої, організованої інформації про кодову базу, архітектуру, конвенції та цілі, над якими вони працюють. У статті перелічено шість типів контексту, необхідних кожному агенту: інструкції, знання, пам’ять, приклади, інструменти та правила. Кожен з них може бути статичним, присутнім у кожній взаємодії, або динамічним, який запроваджується за потребою.

Статичний контекст коштує дорого, оскільки кожен токен передається з кожним викликом моделі, незалежно від того, чи є він важливим чи ні. Надмірна кількість токенів марнує ресурси, послаблює сигнал та може погіршити продуктивність через приховування ключових правил у шумі. Динамічний контекст є дешевшим — він походить зі скриптів типу RAG, механізмів підбору завдань чи результатів інструментів у момент їх необхідності. Вибір того, що потрапляє куди, є основним інженерним компромісом, а не просто додатковою налаштуванням, тому він потребує версіонування, перевірки та такої ж уваги, як і інші рішення щодо проектування.

Найкращим підходом тут є Agent Skills: структуровані, портативні набори процедурних знань, які завантажуються лише тоді, коли це необхідно для виконання завдання. Замість того, щоб заповнювати системний промпт спеціалізованими знаннями, ці навички дозволяють агенту залишатися легким універсалом, який стає спеціалістом у момент виклику. AGENTS.md, який належним чином регулює ці межі, може виглядати так:

# Project: PaymentService API

## Architecture
- REST API, Node.js, PostgreSQL
- Never modify /src/core/billing without explicit approval

## Agent Skills (load on demand)
- skill:stripe-integration → load when task involves payments
- skill:database-migrations → load when task involves schema changes

## Hard Constraints
- No hardcoded credentials
- All new endpoints require integration tests before merge

Точна синтаксис має менше значення, ніж ідея наміру, закодована як обмеження. Агент вчиться, що це таке, до чого може доторкнутися, що запускає спеціалізовану поведінку та що заборонено без дозволу, і все це не обов’язково має знаходитися в кожному вікні контексту. Ось у чому різниця між агентом, який залишається надійним під час сотень завдань, та тим, який починає працювати некоректно вже після перших десяти.

Пастка 80%

Агенти можуть швидко написати близько 80% коду функції. Ця частина зазвичай виглядає бездоганною, переживає поверхневу перевірку та випускається без проблем, і саме так закривається пастка. Останні 20% — це те, де системи ламаються: крайні випадки, бізнес-правила, які зберігаються в пам’яті людей, а не в документах, точки інтеграції між сервісами, створеними роками раніше різними командами, та вимоги до точності, які проявляються лише під справжнім навантаженням або при реальній поведінці користувачів.

Характер помилок ШІ також змінився. Ранні інструменти програмування виявляли очевидні синтаксичні помилки, які легко помічалися під час перевірки. Сучасні агенти створюють концептуальні помилки: неправильні припущення щодо бізнес-правил, правдоподібні, але непроявлені крайні випадки, а також архітектурні рішення, які призводять до прихованих довгострокових проблем з технічним обслуговуванням. Код виглядає правильним та може пройти набір тестів, проте проблема є структурною, виникає з запізненням, і її усунення зазвичай коштує значно дорожче, ніж її запобігання.

Ось чому оцінка траєкторії, тобто перевірка шляху міркувань агента разом із його результатом, не може бути пропущена в продакшн-системах з агентами. Оцінка результату полягає у перевірці того, чи повернула функція правильний результат. Оцінка траєкторії полягає у перевірці того, чи зрозумів агент задачу ще до того, як щось написати. Кожне з цих питань має значення, адже якщо дивитися лише на результат, то останні 20% випадків проходять без перевірки. Розробники, які справляються найкраще, не прискорюють роботу, приймаючи все без критики. Вони досягають швидкості, використовуючи власний судження там, де судження ШІ є структурно найслабкими: у незрозумілих вимогах, архітектурних компромісах та правильності функціонування системи на її межах.

Режими керівника та оркеструвальника

У статті описано два режими роботи, і перехід між ними може стати найбільш значущою з точки зору практики зміною професійного напрямку в інженерії програмного забезпечення сьогодні. У режимі керівника розробник працює безпосередньо в IDE, спостерігаючи за створенням коду, вносячи корективи та забезпечуючи детальний контроль над кожною зміною. Це зберігає інтуїцію та розуміння, до яких привчають інженерів під час навчання. Недоліком є низька продуктивність, оскільки особисте керування кожною взаємодією обмежує переваги використання ШІ.

Режим оркестратора знаходиться на вищому рівні. Розробники встановлюють цілі, передають їх агентам та переглядають отримані результати, не спостерігаючи за створенням коду рядок за рядком. Агенти працюють паралельно у фонових сандбоксах іноді протягом годин та надсилають запити на зміни. Розробник періодично перевіряє результати та, за потреби, коригує напрямок роботи.

Режим керівника є реальним часом, безпосереднім та передбачає роботу з одним агентом. Режим оркеструвальника є асинхронним, з паралельними агентами та результатом у вигляді запиту на обробку. Більшість розробників є навченими керівниками, тож перехід до ролі оркеструвальника означає значну зміну функцій.

Необхідні навички також відрізняються. Керівники проєктів покладаються на глибокі знання мови та синтаксису, швидке виправлення помилок, розуміння структури коду та здатність оперативно інтерпретувати помилки під час роботи. Оркеструвальники потребують точних специфікацій, розбиття завдань на частини, швидкої оцінки результатів та проектування системи, що означає формування обмежень, тестів та механізмів зворотного зв’язку, які забезпечують надійність агентів без постійного нагляду. Багато старших розробників є досвідченими керівниками проєктів, і оркестрування здається їм некомфортним, адже це нагадує втрату контролю. Іноді це справді так, тому перед розширенням процесу оркестрування необхідно використовувати інфраструктуру, оцінювати рівень покриття та забезпечувати інженерію контексту. Делегування без налаштування механізмів перевірки — це не інженерія. Це кодування у масштабі без належних правил.

Економічне питання

У статті дискусію щодо кодування атмосфери проти інженерії агентів розглядається як питання витрат, а не методу. Кодування атмосфери майже не коштує на початковому етапі: немає необхідності у суворих специфікаціях, інфраструктурі оцінки, проектуванні інструментів чи підтримці файлів AGENTS.md. Проте воно швидко накопичує приховані витрати через марнування токенів у неструктурованому контексті, зростання кількості помилок через неконтрольовані результати та втрату часу розробників на усунення проблем, які мали б бути виявлені автоматизованими засобами оцінки.

Інженерія агентів вимагає значних початкових інвестицій у суворість специфікацій, інфраструктуру оцінки, проектування інструментів та архітектуру контексту. Після цього граничні витрати на кожну нову функцію різко знижуються, оскільки кожна нова здатність агента використовує ті самі інструменти, набір засобів оцінки та архітектуру контексту.

Для одного розробника, для прототипу чи побічного проекту, метод vibe coding безумовно є вигіднішим з точки зору витрат. Не потрібно захищати жодну продуктивну систему, і борг ніколи не досягає небезпечних розмірів. Команди досягають цього переломного моменту раніше, ніж очікувалося. П’ятеро інженерів, які працюють за методом vibe coding протягом трьох місяців, можуть легко опинитися в ситуації, коли третина їхніх ресурсів йде на виправлення помилок та повторну роботу, чого можна було б уникнути завдяки систематичній перевірці. Інфраструктура типу агентів окупає свою вартість, за умови її впровадження до того, як борг досягне критичної межі.

Що розглядає стаття, а що — ні

Цей документ — це не презентація продукту. Це документ-контекст, причому більш зручний за більшість, оскільки його основні твердження можна перевірити. Ефект «підпряжки» є реальним та вимірюваним, як показують наведені тестові дослідження. Проблема 80% є реальною та посилюється, коли агенти беруться за складнішу роботу. А перехід від керівника до оркеструвальника вже відбувається в кожній серйозній інженерній організації великого масштабу.

Навмисно залишено нерозглянутим питання про те, де саме має знаходитися певна команда в цьому спектрі. Це залежить від ризиків, розміру команди, тиску часу та технічної зрілості, і жоден контекст не може це визначити. Документ надає лексику та ментальну модель, а рішення залишається за людьми, що, ймовірно, є найчеснішою позицією.

Структура масштабується, а атмосфера — ні. Розробники, які усвідомлюють це зараз, будують на зовсім інших основах, ніж ті, хто дізнається про це у складних умовах під час роботи в продакшені.