Як підходити до розробки з AI-агентами
Контроль над результатом, людина як архітектор і тестувальник, і скіл, який змушує агента спершу пояснити рішення, а вже потім писати код.
Думаю, існує чимало поглядів на те, як правильно використовувати агентів у розробці. У цій статті я поділюся своїм підходом. Імовірно, він відрізнятиметься від думок інших, але головні ідеї напевно будуть дуже схожі.
1. Як зберегти контроль над тим, що створює агент
Я вважаю, що основою правильного використання агентів у розробці є контроль над результатом. Ми не мусимо знати кожен рядок коду. Але ми маємо знати кожне архітектурне рішення і розуміти його.
Між цими двома речами є суттєва різниця. Рядок коду можна переписати за хвилину, і здебільшого від нього нічого не залежить. Архітектурне рішення повернеться до вас за пів року, коли вже ніхто не пам’ятає, чому воно таке — і переписати його можна не за хвилину, а за тижні.
2. Яку роль відіграє людина в розробці з AI-агентами
На мою думку, людина в розробці з агентами має бути насамперед архітектором, UX-дизайнером і тестувальником. Звісно, ШІ може допомагати й у цих ролях — але людина має виконувати значну частину зусиль під час перевірки.
Це та частина, яку не можна делегувати. Агент напише вам код, який працює. Чи це правильний код у правильному місці і чи те, що ви замовили, взагалі було доброю ідеєю — це лишається на вас.
3. Як написати скіл для Claude Code, який вимагає рішення
З власного досвіду раджу створити собі скіл, у якому ви кажете агентові, що перед будь-якою реалізацією він має спершу пояснити вам обрані архітектурні кроки — у вигляді наперед визначеної структури всередині файлу Markdown.
Скажіть агентові, щоб він щедро використовував діаграми mermaid, приклади та графіки. Діаграма викриває нісенітницю, яка в суцільному тексті добре ховається: коли агент малює потік даних і два компоненти говорять один з одним в обидва боки, це видно з першого погляду.
Такий скіл може виглядати, наприклад, так:
.claude/skills/it-analysis/SKILL.md
---
name: it-analysis
description: Опрацюй ІТ-аналіз
---
# ІТ-аналітик
Ти — старший ІТ-аналітик. Ти спеціалізуєшся на ІТ-аналізах ІТ-систем + їхньої архітектури.
## Workflow
1. **Зрозумій, що маєш розв’язати** — Зрозумій завдання та обміркуй його. Як це розв’язати? які є варіанти розв’язання? Edge cases?
2. **Опрацюй аналіз за шаблоном template.md**
3. **Якщо є відповіді на наявні запитання** - Переопрацюй аналіз на основі відповідей на відкриті запитання. Відкриті запитання та відповіді не видаляй, залиш початкові. Можеш додати ще запитання. У кінець аналізу додай огляд змін (changelog).
## Rules
- Результат має відповідати шаблону `template.md`.claude/skills/it-analysis/template.md
# Шаблон для створення аналізів
## Зміст
1. [Архітектура](#1-arkhitektura)
2. [База даних](#2-baza-danykh)
3. [Backend](#3-backend)
4. [Frontend](#4-frontend)
5. [Ризики реалізації](#5-ryzyky-realizatsii)
6. [Відкриті запитання до рішення](#6-vidkryti-zapytannia)
## 1) Архітектура
У цій частині буде розглянута запропонована архітектура реалізованої функції. Водночас буде розглянуто, яким чином зміниться наявна архітектура + під’єднання до наявної архітектури. Бажані відповідні UML-діаграми в mermaid.
## 2) База даних
У цій частині буде розглянута запропонована модель бази даних через ER-діаграму. Водночас будуть розглянуті зміни наявної моделі бази даних + під’єднання до наявної моделі БД. Бажані ER-діаграми.
## 3) Backend
Тут у вигляді списку будуть розглянуті наслідки для бекенду — тобто що треба буде на бекенді додати / видалити / змінити.
## 4) Frontend
Тут у вигляді списку будуть розглянуті наслідки для фронтенду — тобто що треба буде на фронтенді додати / видалити / змінити.
## 6) Відкриті запитання до рішення
Нумерований список із запитаннями до рішення. Кожен пункт списку виглядатиме так:
- **Описова назва запитання**: Детальний текст запитання, з якого я маю бути здатний зрозуміти, про що ти запитуєш.
`Відповідь`: Текст відповіді, або `-`, якщо відповіді ще немає.4. Чому варто дати агентові спершу спроєктувати рішення
На основі цього скіла ви завжди спершу просите запропонувати рішення, яке завжди спочатку схвалюєте. Звісно, результат цього скіла треба як слід перевірити, але він однозначно того вартий.
До того ж, на мою думку, важливо розуміти ці засадничі питання, навіть попри те, що сам код пише агент. Це єдина частина, у якій вирішується, чи буде проєкт за рік іще на щось придатний.
Розділ із відкритими запитаннями в шаблоні є саме для цього. Агент схильний розв’язувати неоднозначності сам і мовчки — а ви дізнаєтеся про це аж тоді, коли код готовий. Коли змусите його виписати запитання, отримаєте їх раніше, ніж на них щось стоятиме.
5. Як обговорити з агентом рішення, якого ви не розумієте
Якщо щодо деяких частин документа ви не впевнені, не бійтеся обговорювати їх з агентом ітеративно. Завдяки розмові з ним ви краще зрозумієте запропоноване рішення, і це допоможе вам випустити якісний продукт.
Варто помітити, що ця розмова має й другий ефект. Коли ви про щось запитуєте, а відповідь не має сенсу, здебільшого це не тому, що ви чогось не зрозуміли — а тому, що рішення хибне. Власна невпевненість — пристойний детектор проблем.
6. Чому до AI-агента варто ставитися як до джуніора
На мою думку, до ШІ-агента ми завжди маємо ставитися як до джуніора на певній позиції — тій позиції, яку ми зараз даємо йому виконувати.
Джуніорові ви даєте завдання, просите пояснити, як він хоче його зробити, і перевіряєте результат. Ви не даєте йому рішень, які важко відкотити, і не лишаєте його працювати тиждень без огляду. Водночас ви не стоїте в нього над плечем біля кожного рядка, бо тоді простіше було б зробити це самому.
Саме так себе виправдала і робота з агентом.
7. Підсумок: три правила розробки з агентами
Цей спосіб особисто мені поки що виправдав себе найкраще. Я б підсумував його трьома реченнями: знайте кожне архітектурне рішення, попросіть пояснити його ще до того, як з’явиться код, і запитуйте про все, чого не розумієте.
Маєте іншу думку? Напишіть на support@coden-app.com.