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

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

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

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

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

Саме такий підхід до Agentic Engineering пояснює Олександр Бутрим, ментор курсу [Backend Development with Agentic AI](https://eu1.hubs.ly/H0zgn-K0). На курсі ти зможеш відпрацювати це на практиці.

Раніше ми вже [розповідали про AI slop](https://t.me/SoftServeEducation/3345) і ризики швидкої генерації коду. А в наступному дописі розберемо, чому планування, реалізацію та перевірку роботи ШІ-агентів варто розділяти.