AI-агент у розробці: як перейти від vibe coding до контрольованого процесу

Кілька років Вадим Мирошник використовує власні pet-проєкти як полігон для експериментів з AI-агентами. Спочатку його підхід був простим: описати задачу й дати агенту писати код. Проте з часом з'ясувалося, що такий підхід призводить до накопичення прихованих проблем.

Перший серйозний факап стався, коли він вирішив додати темну тему в проєкт. Кольори були розкидані по компонентах у різних форматах – hex, RGB, різні відтінки. Агенти додавали їх безсистемно, тому довелося вручну мігрувати всі значення в спільну тему. Навіть після кількох проходів AI залишав старі кольори, а візуальна перевірка вже не допомагала. Рішенням став кастомний аналізатор, який автоматично знаходить hard-coded кольори й повертає задачу агенту на доопрацювання.

Друга помилка – надія на правила в промпті. Вадим намагався описати стиль, структуру файлів, підходи, але агенти часто порушували ці домовленості, особливо в складних задачах або нових сесіях. Він зрозумів: правила, які можна перевірити автоматично, не повинні жити лише в промпті. Для форматування – Prettier, для помилок – ESLint, для типізації – TypeScript, а для специфічних проєктних правил – власні валідатори. Тепер агент бачить помилку й виправляє код без додаткових вказівок.

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

Наступний крок – Spec-Driven Development. Для великих фіч, як-от система оплати зі Stripe, Вадим почав спочатку описувати вимоги, критерії приймання та сценарії, а вже потім давати агенту писати код. Це допомогло знайти питання, які він сам не передбачив: що буде, якщо користувач закриє браузер під час оплати, коли починається період доступу, як система реагує на повторні підтвердження платежу. Агент не лише реалізує, а й допомагає виявити прогалини в описі.

Окремий аспект – контроль доступу агента. Вадим працює за принципом мінімальних дозволів: агент не має прямого доступу до секретів, а небезпечні команди (видалення файлів, зміна Git-історії, deployment) вимагають ручного підтвердження.

Підсумок: важливі правила мають бути формалізовані в коді, а не лише в промпті; автоматичні перевірки не замінюють review; контроль потрібно починати ще до написання коду – на етапі вимог і планування. Для Вадима робота з AI-агентами перетворилася з написання ідеальних промптів на побудову процесу, де помилки виявляються якомога раніше.