Від «вайб-кодингу» до розробки, керованої специфікаціями: нова ера інженерії з агентами ШІ

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

Завершення ери «вайб-кодингу»

Андрій Карпатий, який запровадив термін «вайб-кодинг» у лютому 2025 року, вже за рік визнав, що ця ера добігає кінця. Ми вступаємо в епоху агентної інженерії, де основна увага приділяється оркеструванню агентів ШІ відповідно до детальних специфікацій під наглядом людини. Сьогодні програмування за допомогою агентів великих мовних моделей (LLM) стає стандартним робочим процесом для професіоналів, але з посиленим наглядом та контролем. Мета полягає в тому, щоб використовувати можливості агентів без компромісів щодо якості програмного забезпечення.

Термін «агентна інженерія» підкреслює дві ключові ідеї:

• «Агентна»: Оскільки в 99% випадків розробник не пише код безпосередньо, а оркеструє агентів, які це роблять, виконуючи функцію нагляду.
• «Інженерія»: Наголошує на тому, що це мистецтво та наука, яка вимагає експертизи, її можна вивчати та вдосконалювати, і вона має власну глибину.

«Вайб-кодинг» проти розробки, керованої специфікаціями

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

Основні недоліки «вайб-кодингу» включають:

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

Розробка, керована специфікаціями (SDD), набагато ближча до традиційних інженерних практик. Замість того, щоб одразу переходити до реалізації, розробники спочатку ретельно продумують архітектурні рішення, визначають вимоги та документують їх у структурованій специфікації Markdown, яка зберігається в репозиторії та оновлюється разом із проєктом. Це створює важливий зсув: специфікація (що і чому ми будуємо) відокремлюється від реалізації (власне коду).

SDD вирішує багато проблем «вайб-кодингу», зберігаючи контекст між сесіями (і навіть між різними агентами ШІ) та узгоджуючи дії людей та агентів щодо основних незмінних аспектів проєкту.

Робочий процес SDD

Типовий робочий процес розробки, керованої специфікаціями, складається з кількох етапів:

1. Визначення «конституції»: Це угода щодо ключових рішень для проєкту. Вона зазвичай включає кілька основних документів:

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

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

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

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

Практичне застосування SDD: проєкт Trainlytics

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

Створення «конституції»

Першим кроком було написання «конституції». Замість ручного створення, були використані LLM для її складання на основі початкового бачення продукту та додаткового контексту, зібраного через уточнюючі питання. Агент створив три файли: mission.md, tech-stack.md та roadmap.md у каталозі specs.

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

Перша фаза розробки функції

Наступним кроком була реалізація першої функції — MVP: Core Activity Logging. Користувач мав би мати можливість входити в систему, записувати пробіжки та тренування в спортзалі, а також переглядати їх в історії з повними деталями. Кожна фаза функції слідує циклу: планування → реалізація → валідація.

Для цієї фази було створено новий каталог у specs/ з файлами plan.md (структурований список груп завдань), requirements.md (обсяг, ключові рішення, контекст) та validation.md (як визначається успіх). Роль розробника зміщується до керування, перегляду та прийняття архітектурних рішень, а не безпосереднього написання специфікацій чи коду.

Реалізація виконувалася групами завдань. Після написання коду проводився ретельний огляд, зосереджений на бізнес-логіці та відповідності очікуванням. Також використовувалася рефлексія, коли новий агент перевіряв відповідність реалізації плану та пунктам у validation.md.

Якщо виникали проблеми, їх можна було вирішити шляхом додавання ітерацій до plan.md для невеликих змін або розглядати як частину наступної фази для більш суттєвих проблем. Важливо уникати спокуси просто пояснити проблему агенту LLM і попросити виправлення, замість того, щоб оновлювати специфікації. Збереження специфікації як єдиного джерела істини робить підхід надійним. Після всіх перевірок запит на злиття (pull request) створюється та об'єднується. Весь процес зайняв трохи більше двох годин.

Перепланування

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

Перепланування також є гарним моментом для перегляду самого процесу. Наприклад, було помічено, що roadmap.md не оновлювався послідовно, і специфікації почали розходитися. Було вирішено запровадити CHANGELOG.md для відстеження історії розвитку продукту.

Автоматизація та інструменти

Робочі процеси SDD можна автоматизувати як «навички» в таких інструментах, як Claude Code. Існують також готові реалізації SDD, наприклад, Spec Kit від GitHub. Spec Kit дозволяє ініціалізувати навички та використовувати команди для визначення «конституції» та ітерації через фази функцій. Хоча Spec Kit більше зосереджений на високорівневих аспектах, таких як якість коду та тестування, він надає готовий робочий процес SDD.

Висновки

Загалом, створення функціонального продукту зайняло близько 4,5 годин. Хоча для невеликих покращень або одноразового аналізу повні специфікації можуть бути надмірними, для великих проєктів, особливо з кількома розробниками, розробка, керована специфікаціями, є рекомендованим підходом.

Роль інженера змінюється: від безпосереднього написання коду до зосередження на архітектурних рішеннях, огляді та системному дизайні. Існує тенденція до того, що англійська мова стає основним інтерфейсом «мови програмування», з ранніми спробами, такими як CodeSpeak, що досліджують парадигми програмування, керовані природною мовою.

Цей матеріал натхненний коротким курсом DeepLearning.AI «Spec-Driven Development with Coding Agents».