🤔 Той самий запит до ШІ-агента може давати різні результати. А незначні зміни у формулюванні чи контексті можуть вплинути на план, реалізацію та навіть архітектурні рішення.

Для розробників це означає кілька викликів:
🔸 втрата контролю. Агент може змінювати десятки файлів, а відстежити логіку кожного рішення стає складніше.
🔸 вартість перевірки. Якщо рев'ю займає більше часу, ніж самостійне написання коду, очікуване прискорення зникає.
🔸 відповідальність. За безпеку, архітектуру та коректність системи все одно відповідає команда.

Зберігати контроль допомагають чіткі правила роботи агента:
✔️ визначити, які файли та компоненти дозволено змінювати
✔️ зафіксувати архітектурні правила й критерії приймання
✔️ налаштувати автоматичні перевірки та тести
✔️ передбачити етапи, на яких рішення погоджує людина

Наприклад, агент може запропонувати різні способи реалізації API. Але в кожному випадку результат має відповідати OpenAPI-контракту, проходити тести та не порушувати погоджені обмеження.

💡

Ми не усуваємо варіативність ШІ, а визначаємо межі, у яких він може працювати.

Саме такий підхід до Agentic Engineering пояснює Олександр Бутрим, ментор курсу Backend Development with Agentic AI. На курсі ти зможеш відпрацювати це на практиці.

Раніше ми вже розповідали про AI slop і ризики швидкої генерації коду. А в наступному дописі розберемо, чому планування, реалізацію та перевірку роботи ШІ-агентів варто розділяти.