Від vibe coding до контролю: як інженер приборкує AI-агентів

Кілька років Вадим Мирошник, Lead Software Development Engineer у SPD Technology, використовує pet-проєкти як полігон для роботи з AI-агентами. Спершу його підхід був простим: описати задачу, дати агенту написати код і сподіватися на найкраще. Згодом довелося змінювати стратегію — і ось чому.

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

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

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

Наступний крок — Spec-Driven Development. Перед написанням коду Вадим разом із агентом описує, як має працювати фіча. Наприклад, для системи оплати довелося продумати сценарії: що буде, якщо користувач закрив браузер під час оплати, коли починається період доступу, як працюють повернення коштів. Такі питання з’являються до реалізації, а не під час review.

Окремо Вадим контролює доступ агента: мінімальні дозволи, без доступу до .env і секретів, ручне підтвердження для небезпечних команд. Підсумок простий: важливі правила — у коді, автоматичні перевірки — на максимум, review — окремо, а планування — до написання коду.