Мій агент відправив 3 PR за один вечір. 40% моїх повідомлень були виправленнями.

Мій кодинг-агент на базі ШІ відправив три пул-реквести за один вечір, але 40% із 30 повідомлень, які я надіслав, були виправленнями.

Результатом сесії стали MCP-клієнт, Azure AI Agent та M365 Copilot Agent. Автоматичні перевірки підтвердили всі три PR, і я жодного разу не редагував жодного рядка коду. Проте транскрипт свідчить про інше: із 710 загальних повідомлень я написав 30, і 12 із них спрямували агента назад у правильне русло. «Коефіцієнт спрямування» (steering rate) — частка моїх повідомлень, що були виправленнями, — становить 40%.

Як була побудована архітектура конвеєра

  • Claude розробив план реалізації високого рівня.
  • DeepSeek V4-Flash виступав оркестратором, переглядаючи план.
  • Codex згенерував безпосередньо код.
  • Оркестратор перевірив код і відкрив пул-реквести.

За задумом роль оркестратора була суто сполучною — він мав вирішувати конфлікти між компонентами, а не писати код самостійно. На практиці агент згенерував 3500 рядків коду в межах трьох PR приблизно за 40 хвилин, але також припустився помилок у двох повторюваних класах.

Дві родини помилок

  1. Порушення робочого процесу — оркестратор час від часу перехоплював етап написання коду, ігноруючи свою роль «сполучної ланки» та самостійно прописуючи деталі реалізації.
  2. Збої у вибірці контексту — попри чіткі інструкції, агент обирав неправильний SDK або версію. Правильна інформація була в контексті промпту, але модель не змогла витягнути її в потрібний момент.

Це не прогалини в здатності до міркування; це інженерні баги в тому, як обмежений робочий процес. Навіть більш потужній мовній моделі все одно знадобилося б жорстке, незаворотне правило, яке прив'язує оркестратора до його не-кодингових обов'язків і змушує обирати правильний SDK.

Що я змінив, щоб приборкати агента

Я перестав сподіватися, що система сама зрозуміє свою роль із переліку кроків. Я додав пряму вказівку: «Ви — оркестратор. Ви не займаєтеся реалізацією». Знадобилося п'ять коригувальних повідомлень, щоб інструкція закріпилася, після чого агент почав дотримуватися меж.

Я також посилив логіку вибірки контексту. Коли з'являвся неправильний інструмент, я розглядав це як баг у конвеєрі вибірки, а не як галюцинацію, і переписав промпт, який передає деталі SDK, щоб правильну версію було неможливо пропустити.

Практичні висновки для розробки з використанням ШІ

  • Рахуйте власні повідомлення. Велика кількість прийнятих PR може маскувати зламаний процес. Кількість ваших виправлень — це опереджений індикатор того, де саме «протікає» система.
  • Чітко визначайте роль. Агенти не виводять свою ідентичність із чек-листа; їм потрібна чітка, закріплена інструкція про те, ким вони є і що їм дозволено робити.
  • Розглядайте помилки вибору інструментів як інженерні баги. Якщо агент ігнорує вказаний SDK, провина лежить на механізмі доставки контексту, а не на «знаннях» моделі.
  • Перетворюйте помилки на багаторазові навички. Я дозволив агенту згенерувати процедуру валідації на основі його власних помилок, перетворивши невдачу на майбутній запобіжник.

Більші ставки