Codex і багатоагентний робочий процес: працюйте з агентами, не втрачаючи контролю
· 6 min read · Filippo Spinella · AI, Developer Tools, Productivity, Software Engineering
Коли вперше агент кодування справді виправляє помилку за вас, реакція майже завжди однакова: суміш ентузіазму та підозри. Гарно, звичайно. Але потім ви дивитеся на різницю і запитуєте себе: "Добре, але чого саме він торкнувся? Чи можу я йому довіряти? Чи зробить він це знову так само завтра?".
Тут, я думаю, починається найцікавіше. Не тоді, коли агент пише функцію, а коли він стає достатньо спроможним виконувати цілі частини роботи: читати репозиторій, створювати патч, запускати тести, відкривати PR, повертатися після перегляду коментаря. Codex рухається саме в цьому напрямку: фонова робота, окремі робочі дерева, інтегрований браузер, автоматизація, плагіни, пам’ять і більш чіткі засоби керування дозволами.
Справа не в тому, щоб уявити майбутнє, де ніхто більше не читатиме код. Це було б жахливе майбутнє, до того ж досить наївне. Суть у тому, щоб зрозуміти, як працювати з агентами, які можуть зробити багато, не дозволяючи їм робити все.
Зміна звички
З традиційним автозаповненням ви завжди були за кермом. ШІ запропонував лінію, ви вирішили. З агентом, однак, стосунки змінюються: ви ставите йому ціль, і він самостійно проходить кілька кроків.
Це потужно, але зсуває проблему. Питання більше не просто «чи може модель програмувати?». Питання стає таким:
- Я дав йому досить малий приціл?
- ти знаєш як перевірити результат?
- Чи працюю я в ізольованому середовищі?
- Остаточний огляд все ще гуманний і обережний?
Здоровий робочий процес більше схожий на це, ніж чарівна паличка:
Це звучить менш романтично, ніж «агент будує все», але працює набагато краще. І це також те, як працюють команди, які добре спілкуються з людьми: чіткі завдання, швидкий зворотний зв’язок, чітка підзвітність.
Хороша підказка – майже хороший квиток
Найнебезпечніша підказка – це розпливчаста, але впевнена: «виправити сторінку рахунків», «покращити архітектуру», «очистити модуль авторизації». Ці запити звучать продуктивно та породжують величезні відмінності. Але потім ти починаєш займатися археологією.
Корисна підказка більш нудна. Наприклад: реалізуйте експорт CSV для сторінки рахунків-фактур, знаючи, що таблиця знаходиться в app/(dashboard)/invoices/page.tsx, запити знаходяться в src/server/invoices.ts, а подібний шаблон уже існує в app/(dashboard)/reports.
Потім додайте чіткі обмеження: не змінюйте схему бази даних, не додавайте залежності, якщо достатньо невеликої утиліти, збережіть існуючий стиль інтерфейсу користувача. І закрийте перевіркою: npm test -- invoices і npm run build.
Цей тип брифа не призначений для того, щоб «пояснити краще ШІ». Це насамперед для того, щоб вам було зрозуміліше, що ви делегуєте. Якщо ви не можете записати це конкретно, можливо, завдання ще не готове для агента.
Три роботи, які я охоче делегую
Перший — це повторювана, але перевірена робота: додавання тестів, перенесення викликів до нового внутрішнього API, оновлення імпорту, заміна застарілих компонентів, виправлення помилок TypeScript. Тут агент може заощадити години, а ризик можна контролювати.
Друга — дослідницька робота: «знайдіть, де обчислюється ця сума», «поясніть мені, чому цей тест крихкий», «відтворіть помилку та скажіть мені, які файли, здається, зачеплені». Навіть якщо він не створює латку відразу, він може зробити корисну розвідку.
По-третє, це регулярна робота з обслуговування: невеликі оновлення залежностей, очищення старих позначок функцій, підсумок заблокованих PR, перевірка забутих TODO. Це не гламурно, але це саме та робота, яка має тенденцію накопичуватися.
Три роботи, які я зберігаю людьми
Рішення щодо продукту залишаються людиною. Якщо зміни змінюють спосіб оплати користувача, видаляють дані, переглядають ціни чи розуміють дозвіл, мені потрібна відповідальна особа.
Межі безпеки також заслуговують на увагу з боку людини: автентифікація, ролі, маркери, реєстрація конфіденційних даних, міграція бази даних. Агент може допомогти в реалізації, але не обов’язково бути єдиним, хто приймає рішення.
Нарешті, все, що вимагає архітектурного смаку, я залишаю людським. Агент може запропонувати рефакторинг, але зрозуміти, чи справді потрібна абстракція чи ми просто відшліфовуємо неіснуючу проблему, залишається завданням.
Огляд необов’язковий
Спокуса, коли агент хороший, полягає в тому, щоб довіряти зеленим CI. Це зрозуміло. Це також час, коли починаються проблеми.
Я завжди дивлюся щонайменше на п'ять речей:
- Чи вирішує патч лише поставлене завдання?
- Він торкався файлів, які не мали до цього жодного відношення?
- Тести охоплюють нову поведінку чи просто щасливий випадок?
- Чи відповідає код місцевим шаблонам?
- Чи обробляються помилки так само, як і в решті проекту?
Коли щось не так, відгук має бути конкретним. «Виправити» – це лінь. Краще: ця утиліта дублює parseMoney у src/lib/money.ts; повторно використовуйте цю функцію, додайте перевірку для випадку EUR і не змінюйте загальнодоступний API платіжного модуля.
Агенти набагато краще реагують на невеликі коментарі, які можна перевірити. Цікаво, що люди теж.
Огородження варті зусиль
Якщо агент може читати файли, писати код і виконувати команди, його слід розглядати як потужний процес. Немає потреби в параної, потрібна гігієна.
Використовуйте окремі робочі дерева або гілки. Тож ви можете порівняти різницю, викинути невдалі експерименти та не змішувати роботу агента з тим, що ви робите.
Обмежити дозволи. Такі команди, як rg, git diff, npm test і npm run build, можуть бути досить безкоштовними. Розгортання, міграція баз даних, доступ до секретів і деструктивні команди повинні залишатися явними.
Зменште доступ до мережі, коли він вам не потрібен. Для багатьох завдань достатньо офіційної документації, реєстру пакетів і спеціальних внутрішніх служб. Менша площа, менше сюрпризів.
Відстежуйте дії. Коли патч надходить на перевірку, ви зможете реконструювати підказки, виконані команди, пройдені тести та змінені файли. Не для того, щоб створювати бюрократію, а щоб мати можливість зрозуміти, що сталося, якщо щось піде не так.
Простий спосіб розпочати роботу як команда
Якби я ввів агентів у невелику команду, я б почав без серйозних революцій.
Я б створив мітку agent-ready для проблем із чітким масштабом. Я б додав шаблон із контекстом, обмеженнями та командами перевірки. Я б попросив невеликий піар, в ідеалі під кілька сотень рядків. Я б вимагав тестування або скріншотів для видимих змін. І перш за все я б залишив людину, відповідальну за злиття.
Через два тижні я переглядав дані: які завдання справді пришвидшилися, які перевірки були важкими, які підказки були заплутаними, які частини кодової бази занадто крихкі, щоб делегувати їх.
Це менш ефектний підхід, ніж «з сьогоднішнього дня ми все зробимо з агентами», але це той, який дозволяє без жалю дійти до третього тижня.
Найбільш людська частина
Найсмішніше те, що чим більш автономними стають агенти, тим важливішими знову стають класичні навички: написання гарного квитка, створення невеликих скорочень, створення тестів, читання відмінностей, спілкування компромісів. Агент прискорює тих, хто вже вміє добре працювати. Це також посилює хаос тих, хто погано делегує повноваження.
Тож ні, я не вважаю багатоагентні робочі процеси ярликом, щоб припинити займатися розробкою. Я сприймаю їх як спосіб спрямувати більше енергії на важливі частини: вирішити, що будувати, переконатися, що це працює, підтримувати зрозумілість системи.
Агенти можуть бути чудовими асинхронними колегами. Але щоб асинхронний колега був корисним, потрібен контекст, межі та огляд. Як і всі інші.