Роками штучний інтелект сидів поруч із вами в редакторі та вгадував, що буде далі. Ви писали рядок — він пропонував наступний. Ви все ще володіли архітектурою, налагодженням та синтаксисом. Цей устрій залишився в минулому.
Ми переходимо до розробки, керованої намірами (Intent-Driven Development). Ви перестаєте друкувати цикли та умови. Замість цього ви описуєте потрібний результат. Агент сприймає цю мету, планує кроки, пише код, запускає тести та виправляє власні помилки ще до того, як ви побачите результат. Клавіатура більше не є основним інструментом. Основним стає чітке мислення.
Кінець порядкового програмування
Старий робочий процес змушував вас перекладати кожне наміри на конкретну мову, яку розумів компілятор. Ви тримали бізнес-вимогу в голові, а потім вручну розбивали її на функції, імпорти, обробку помилок і тестові випадки. Intent-Driven Development усуває цей шар перекладу.
Припустимо, вам потрібно інтегрувати платіжний webhook. Раніше ви б написали обробник маршруту (route handler), розпарсили корисне навантаження (payload), перевірили підпис, оновили базу даних у межах транзакції та поставили в чергу лист із квитанцією. Тепер ви описуєте вимогу: «Перевір вхідний Stripe webhook, ідемпотентно запиши подію та запусти процес надсилання квитанції. Скасуй операцію, якщо запис у базу даних не вдасться». Агент пише обробник, обирає стратегію парсингу, структурує логіку повторних спроб і генерує тести. Ваша роль змінюється з автора на режисера.
Це працює лише тому, що агент не зупиняється на генерації. Він входить у цикл.
Всередині циклу агента
Основна робота — це більше не друкування людиною чи ручне налагодження. Це щільний цикл між генерацією та валідацією. Агент створює код, виконує його за допомогою вашого набору тестів, читає результат і самостійно виправляє помилки. Відсутній імпорт, невідповідність типів, помилка твердження (assertion) — агент бачить стек викликів (stack trace), редагує файл і перезапускає набір тестів. Ви не берете участі в цьому циклі. Цикл працює у темпі машини.
Ви втручаєтеся, коли ламається сам цикл. Можливо, агент не може вирішити конфлікт між двома залежностями або продовжує генерувати код, який проходить юніт-тести, але порушує бізнес-правило вищого рівня. Саме на цих межах людське судження все ще має значення.
Ваша справжня робота: дизайнер обмежень та мисливець за граничними випадками
Якщо машина пише функції, що залишається вам? Дві речі, і вони складніші за написання синтаксису.
По-перше, ви пишете обмеження, які тримають агента в межах задачі. Агент має широкі знання, але не розуміє вашого специфічного середовища. Ви повинні сказати йому: «Використовуй лише внутрішній billing API, ніколи не логуй сирі токени карток і тримай затримку відповіді (latency) менше ніж двісті мілісекунд». Ці межі — це не просто тимчасові підказки (prompts). Це специфікації, які визначають успіх або невдачу.
По-друге, ви відловлюєте ті десять відсотків випадків, коли агент помиляється. Агенти добре справляються зі звичайними сценаріями. Вони спотикаються на тонких станах гонитви (race conditions), неоднозначних граничних випадках бізнес-логіки та припущеннях безпеки, закладених у їхні навчальні дані. Ваша перевага полягає у вмінні помітити стан гонитви між обробником webhook та cron-завданням повернення коштів або розпізнати, що згенерована логіка повторних спроб може призвести до дублювання платежів. Машина вирішує стандартну проблему. Ви ловите небезпечний виняток.
Замініть перегляд коду (Code Review) на механізм верифікації
Коли агент може створити п'ятдесят файлів за одну ніч, ви не можете переглянути їх, просто пробігаючи очима по diff-ах, щоб перевірити, чи вони «виглядають правильно». Через такий обсяг візуальна перевірка людиною стає неможливою. Вам потрібен механізм (harness), який виявлятиме помилки до того, як код потрапить до вас.
Цей механізм тримається на трьох стовпах.
Надійне виконання (Durable execution). Завдання агента часто тривають довше, ніж таймаут одного запиту. Якщо крок завершується помилкою через тимчасовий збій мережі, механізм робить паузу, повторює спробу та відновлює роботу, не пошкоджуючи стан. Робота зберігається навіть після переривання.
Структуровані виводи (Structured outputs). Замість того, щоб сподіватися, що агент поверне правильно сформований конфігураційний файл, ви заздалегідь встановлюєте контракт. Такі інструменти, як JSON Schema, миттєво валідують результат. Якщо агент пропустить обов'язкове поле або використає неправильний тип даних, механізм відхилить його ще до того, як код торкнеться вашого репозиторію.
Динамічні обмеження (Dynamic guardrails). Агент не повинен мати безмежний доступ до читання секретів або запису в робочі (production) бази даних. Механізм динамічно керує правами доступу, ізолюючи (sandboxing) агента так, щоб він міг взаємодіяти лише з призначеними тестовими базами даних та внутрішніми ендпоінтами. Ви не перевіряєте кожен рядок. Ви проводите аудит «паркану» навколо агента.
Коли код працює, а продукт зазнає невдачі
Ось у чому парадокс. Тестова оснастка виявляє поганий код. Вона не може виявити поганий намір.
Якщо ваша специфікація каже: «Надсилайте вітальний електронний лист кожному новому користувачеві», агент напише чистий, протестований код, який надсилатиме цей лист. Він не знатиме, що ви мали на увазі: «Надсилайте вітальний лист лише в тому випадку, якщо користувач підтвердив свою адресу, погодився на маркетинг і зареєструвався в робочі години за своїм місцевим часовим поясом». Код технічно бездоганний, але комерційно небезпечний.
Справжній ризик у Intent-Driven Development — це неоднозначна специфікація. Нечіткий намір створює програмне забезпечення, яке з підручною елегантністю вирішує не ту проблему. Ось чому ви повинні ставитися до своїх специфікацій як до реальних активів. Створюйте їхні версії. Обговорюйте їх зі стейкхолдерами. Перевіряйте їх на відповідність реальним робочим процесам, перш ніж агент почне розробку. Промпт, накиданий у чат-боті, — це не специфікація. Це джерело ризиків.
Інженерне судження зміщується на ранніші етапи
Інженерне судження не зникає. Воно переміщується на вищу висоту.
Ви більше не витрачаєте ментальну енергію на те, як ітерувати мапу або структурувати ієрархію класів. Ви витрачаєте її на те, що система має робити під час збоїв, які дані вона ніколи не повинна розкривати та які інваріанти мають зберігатися в розподілених сервісах. Мистецтво програмування стає мистецтвом формування вимог.
Це означає, що ваші специфікації потребують такої ж суворості, яку ви колись застосовували до свого коду. Чітко називайте свої обмеження. Явно визначайте режими відмови. Формулюйте бізнес-правила так само чітко, як ви колись оголошували свої типи. Агент візьме на себе реалізацію. Ви ж повинні гарантувати, що ця реалізація варта того, щоб її створювати.
Перенесіть планку якості з pull request на промпт. Спочатку побудуйте тестову оснастку. Потім напишіть специфікацію. А після цього дозвольте машині займатися синтаксисом, поки ви зосереджуєтеся на тому, чи правильно визначена проблема і чи безпечно встановлені межі.
Якщо ви хочете глибше дослідити ідеї, що стоять за цим переходом, оригінальна дискусія про Intent-Driven Development доступна тут. Щоб долучитися до поточних обговорень AI-native інженерії, ви також можете приєднатися до спільноти GyaanSetu.