Codex і багатоагентний робочий процес: працюйте з агентами, не втрачаючи контролю

spinny:~/writing $ vim codex-multi-agent-workflows.md

1~
2Коли вперше агент кодування справді виправляє помилку за вас, реакція майже завжди однакова: суміш ентузіазму та підозри. Гарно, звичайно. Але потім ви дивитеся на різницю і запитуєте себе: "Добре, але чого саме він торкнувся? Чи можу я йому довіряти? Чи зробить він це знову так само завтра?".
3~
4Тут, я думаю, починається найцікавіше. Не тоді, коли агент пише функцію, а коли він стає достатньо спроможним виконувати цілі частини роботи: читати репозиторій, створювати патч, запускати тести, відкривати PR, повертатися після перегляду коментаря. Codex рухається саме в цьому напрямку: фонова робота, окремі робочі дерева, інтегрований браузер, автоматизація, плагіни, пам’ять і більш чіткі засоби керування дозволами.
5~
6Справа не в тому, щоб уявити майбутнє, де ніхто більше не читатиме код. Це було б жахливе майбутнє, до того ж досить наївне. Суть у тому, щоб зрозуміти, як працювати з агентами, які можуть зробити багато, не дозволяючи їм робити все.
7~
8## Зміна звички
9~
10З традиційним автозаповненням ви завжди були за кермом. ШІ запропонував лінію, ви вирішили. З агентом, однак, стосунки змінюються: ви ставите йому ціль, і він самостійно проходить кілька кроків.
11~
12Це потужно, але зсуває проблему. Питання більше не просто «чи може модель програмувати?». Питання стає таким:
13~
14- Я дав йому досить малий приціл?
15- ти знаєш як перевірити результат?
16- Чи працюю я в ізольованому середовищі?
17- Остаточний огляд все ще гуманний і обережний?
18~
19Здоровий робочий процес більше схожий на це, ніж чарівна паличка:
20~
21```mermaid
22flowchart LR
23    Idea[Людське завдання] --> Scope[Маленька мета, яку можна перевірити]
24    Scope --> Agent[Агент у робочому дереві ізольований]
25    Agent --> Checks[Тест, lint, збірка, браузер]
26    Checks --> Review[Огляд людиною]
27    Review --> Merge[Об’єднання або нова ітерація]
28    Review --> Iterate[Точні коментарі до диф]
29    Iterate --> Agent
30```
31~
32Це звучить менш романтично, ніж «агент будує все», але працює набагато краще. І це також те, як працюють команди, які добре спілкуються з людьми: чіткі завдання, швидкий зворотний зв’язок, чітка підзвітність.
33~
34## Хороша підказка – майже хороший квиток
35~
36Найнебезпечніша підказка – це розпливчаста, але впевнена: «виправити сторінку рахунків», «покращити архітектуру», «очистити модуль авторизації». Ці запити звучать продуктивно та породжують величезні відмінності. Але потім ти починаєш займатися археологією.
37~
38Корисна підказка більш нудна. Наприклад: реалізуйте експорт CSV для сторінки рахунків-фактур, знаючи, що таблиця знаходиться в `app/(dashboard)/invoices/page.tsx`, запити знаходяться в `src/server/invoices.ts`, а подібний шаблон уже існує в `app/(dashboard)/reports`.
39~
40Потім додайте чіткі обмеження: не змінюйте схему бази даних, не додавайте залежності, якщо достатньо невеликої утиліти, збережіть існуючий стиль інтерфейсу користувача. І закрийте перевіркою: `npm test -- invoices` і `npm run build`.
41~
42Цей тип брифа не призначений для того, щоб «пояснити краще ШІ». Це насамперед для того, щоб вам було зрозуміліше, що ви делегуєте. Якщо ви не можете записати це конкретно, можливо, завдання ще не готове для агента.
43~
44## Три роботи, які я охоче делегую
45~
46Перший — це повторювана, але перевірена робота: додавання тестів, перенесення викликів до нового внутрішнього API, оновлення імпорту, заміна застарілих компонентів, виправлення помилок TypeScript. Тут агент може заощадити години, а ризик можна контролювати.
47~
48Друга — дослідницька робота: «знайдіть, де обчислюється ця сума», «поясніть мені, чому цей тест крихкий», «відтворіть помилку та скажіть мені, які файли, здається, зачеплені». Навіть якщо він не створює латку відразу, він може зробити корисну розвідку.
49~
50По-третє, це регулярна робота з обслуговування: невеликі оновлення залежностей, очищення старих позначок функцій, підсумок заблокованих PR, перевірка забутих TODO. Це не гламурно, але це саме та робота, яка має тенденцію накопичуватися.
51~
52## Три роботи, які я зберігаю людьми
53~
54Рішення щодо продукту залишаються людиною. Якщо зміни змінюють спосіб оплати користувача, видаляють дані, переглядають ціни чи розуміють дозвіл, мені потрібна відповідальна особа.
55~
56Межі безпеки також заслуговують на увагу з боку людини: автентифікація, ролі, маркери, реєстрація конфіденційних даних, міграція бази даних. Агент може допомогти в реалізації, але не обов’язково бути єдиним, хто приймає рішення.
57~
58Нарешті, все, що вимагає архітектурного смаку, я залишаю людським. Агент може запропонувати рефакторинг, але зрозуміти, чи справді потрібна абстракція чи ми просто відшліфовуємо неіснуючу проблему, залишається завданням.
59~
60## Огляд необов’язковий
61~
62Спокуса, коли агент хороший, полягає в тому, щоб довіряти зеленим CI. Це зрозуміло. Це також час, коли починаються проблеми.
63~
64Я завжди дивлюся щонайменше на п'ять речей:
65~
661. Чи вирішує патч лише поставлене завдання?
672. Він торкався файлів, які не мали до цього жодного відношення?
683. Тести охоплюють нову поведінку чи просто щасливий випадок?
694. Чи відповідає код місцевим шаблонам?
705. Чи обробляються помилки так само, як і в решті проекту?
71~
72Коли щось не так, відгук має бути конкретним. «Виправити» – це лінь. Краще: ця утиліта дублює `parseMoney` у `src/lib/money.ts`; повторно використовуйте цю функцію, додайте перевірку для випадку EUR і не змінюйте загальнодоступний API платіжного модуля.
73~
74Агенти набагато краще реагують на невеликі коментарі, які можна перевірити. Цікаво, що люди теж.
75~
76## Огородження варті зусиль
77~
78Якщо агент може читати файли, писати код і виконувати команди, його слід розглядати як потужний процес. Немає потреби в параної, потрібна гігієна.
79~
80Використовуйте окремі робочі дерева або гілки. Тож ви можете порівняти різницю, викинути невдалі експерименти та не змішувати роботу агента з тим, що ви робите.
81~
82Обмежити дозволи. Такі команди, як `rg`, `git diff`, `npm test` і `npm run build`, можуть бути досить безкоштовними. Розгортання, міграція баз даних, доступ до секретів і деструктивні команди повинні залишатися явними.
83~
84Зменште доступ до мережі, коли він вам не потрібен. Для багатьох завдань достатньо офіційної документації, реєстру пакетів і спеціальних внутрішніх служб. Менша площа, менше сюрпризів.
85~
86Відстежуйте дії. Коли патч надходить на перевірку, ви зможете реконструювати підказки, виконані команди, пройдені тести та змінені файли. Не для того, щоб створювати бюрократію, а щоб мати можливість зрозуміти, що сталося, якщо щось піде не так.
87~
88## Простий спосіб розпочати роботу як команда
89~
90Якби я ввів агентів у невелику команду, я б почав без серйозних революцій.
91~
92Я б створив мітку `agent-ready` для проблем із чітким масштабом. Я б додав шаблон із контекстом, обмеженнями та командами перевірки. Я б попросив невеликий піар, в ідеалі під кілька сотень рядків. Я б вимагав тестування або скріншотів для видимих змін. І перш за все я б залишив людину, відповідальну за злиття.
93~
94Через два тижні я переглядав дані: які завдання справді пришвидшилися, які перевірки були важкими, які підказки були заплутаними, які частини кодової бази занадто крихкі, щоб делегувати їх.
95~
96Це менш ефектний підхід, ніж «з сьогоднішнього дня ми все зробимо з агентами», але це той, який дозволяє без жалю дійти до третього тижня.
97~
98## Найбільш людська частина
99~
100Найсмішніше те, що чим більш автономними стають агенти, тим важливішими знову стають класичні навички: написання гарного квитка, створення невеликих скорочень, створення тестів, читання відмінностей, спілкування компромісів. Агент прискорює тих, хто вже вміє добре працювати. Це також посилює хаос тих, хто погано делегує повноваження.
101~
102Тож ні, я не вважаю багатоагентні робочі процеси ярликом, щоб припинити займатися розробкою. Я сприймаю їх як спосіб спрямувати більше енергії на важливі частини: вирішити, що будувати, переконатися, що це працює, підтримувати зрозумілість системи.
103~
104Агенти можуть бути чудовими асинхронними колегами. Але щоб асинхронний колега був корисним, потрібен контекст, межі та огляд. Як і всі інші.
105~
106## Корисні джерела
107~
108- [Codex для (майже) всього - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Безпечний запуск Codex на OpenAI](https://openai.com/index/running-codex-safely/)
110- [Представляємо Codex - OpenAI](https://openai.com/index/introducing-codex/)
111- [Що нового в агенті кодування GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112~

NORMAL · codex-multi-agent-workflows.md [readonly]112 lines · :q to close

2Коли вперше агент кодування справді виправляє помилку за вас, реакція майже завжди однакова: суміш ентузіазму та підозри. Гарно, звичайно. Але потім ви дивитеся на різницю і запитуєте себе: "Добре, але чого саме він торкнувся? Чи можу я йому довіряти? Чи зробить він це знову так само завтра?".

4Тут, я думаю, починається найцікавіше. Не тоді, коли агент пише функцію, а коли він стає достатньо спроможним виконувати цілі частини роботи: читати репозиторій, створювати патч, запускати тести, відкривати PR, повертатися після перегляду коментаря. Codex рухається саме в цьому напрямку: фонова робота, окремі робочі дерева, інтегрований браузер, автоматизація, плагіни, пам’ять і більш чіткі засоби керування дозволами.

6Справа не в тому, щоб уявити майбутнє, де ніхто більше не читатиме код. Це було б жахливе майбутнє, до того ж досить наївне. Суть у тому, щоб зрозуміти, як працювати з агентами, які можуть зробити багато, не дозволяючи їм робити все.

8## Зміна звички

10З традиційним автозаповненням ви завжди були за кермом. ШІ запропонував лінію, ви вирішили. З агентом, однак, стосунки змінюються: ви ставите йому ціль, і він самостійно проходить кілька кроків.

11~

12Це потужно, але зсуває проблему. Питання більше не просто «чи може модель програмувати?». Питання стає таким:

13~

14- Я дав йому досить малий приціл?

15- ти знаєш як перевірити результат?

16- Чи працюю я в ізольованому середовищі?

17- Остаточний огляд все ще гуманний і обережний?

18~

19Здоровий робочий процес більше схожий на це, ніж чарівна паличка:

20~

21```mermaid

22flowchart LR

23 Idea[Людське завдання] --> Scope[Маленька мета, яку можна перевірити]

24 Scope --> Agent[Агент у робочому дереві ізольований]

25 Agent --> Checks[Тест, lint, збірка, браузер]

26 Checks --> Review[Огляд людиною]

27 Review --> Merge[Об’єднання або нова ітерація]

28 Review --> Iterate[Точні коментарі до диф]

29 Iterate --> Agent

30```

31~

32Це звучить менш романтично, ніж «агент будує все», але працює набагато краще. І це також те, як працюють команди, які добре спілкуються з людьми: чіткі завдання, швидкий зворотний зв’язок, чітка підзвітність.

33~

34## Хороша підказка – майже хороший квиток

35~

36Найнебезпечніша підказка – це розпливчаста, але впевнена: «виправити сторінку рахунків», «покращити архітектуру», «очистити модуль авторизації». Ці запити звучать продуктивно та породжують величезні відмінності. Але потім ти починаєш займатися археологією.

37~

38Корисна підказка більш нудна. Наприклад: реалізуйте експорт CSV для сторінки рахунків-фактур, знаючи, що таблиця знаходиться в `app/(dashboard)/invoices/page.tsx`, запити знаходяться в `src/server/invoices.ts`, а подібний шаблон уже існує в `app/(dashboard)/reports`.

39~

40Потім додайте чіткі обмеження: не змінюйте схему бази даних, не додавайте залежності, якщо достатньо невеликої утиліти, збережіть існуючий стиль інтерфейсу користувача. І закрийте перевіркою: `npm test -- invoices` і `npm run build`.

41~

42Цей тип брифа не призначений для того, щоб «пояснити краще ШІ». Це насамперед для того, щоб вам було зрозуміліше, що ви делегуєте. Якщо ви не можете записати це конкретно, можливо, завдання ще не готове для агента.

43~

44## Три роботи, які я охоче делегую

45~

46Перший — це повторювана, але перевірена робота: додавання тестів, перенесення викликів до нового внутрішнього API, оновлення імпорту, заміна застарілих компонентів, виправлення помилок TypeScript. Тут агент може заощадити години, а ризик можна контролювати.

47~

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

49~

50По-третє, це регулярна робота з обслуговування: невеликі оновлення залежностей, очищення старих позначок функцій, підсумок заблокованих PR, перевірка забутих TODO. Це не гламурно, але це саме та робота, яка має тенденцію накопичуватися.

51~

52## Три роботи, які я зберігаю людьми

53~

54Рішення щодо продукту залишаються людиною. Якщо зміни змінюють спосіб оплати користувача, видаляють дані, переглядають ціни чи розуміють дозвіл, мені потрібна відповідальна особа.

55~

56Межі безпеки також заслуговують на увагу з боку людини: автентифікація, ролі, маркери, реєстрація конфіденційних даних, міграція бази даних. Агент може допомогти в реалізації, але не обов’язково бути єдиним, хто приймає рішення.

57~

58Нарешті, все, що вимагає архітектурного смаку, я залишаю людським. Агент може запропонувати рефакторинг, але зрозуміти, чи справді потрібна абстракція чи ми просто відшліфовуємо неіснуючу проблему, залишається завданням.

59~

60## Огляд необов’язковий

61~

62Спокуса, коли агент хороший, полягає в тому, щоб довіряти зеленим CI. Це зрозуміло. Це також час, коли починаються проблеми.

63~

64Я завжди дивлюся щонайменше на п'ять речей:

65~

661. Чи вирішує патч лише поставлене завдання?

672. Він торкався файлів, які не мали до цього жодного відношення?

683. Тести охоплюють нову поведінку чи просто щасливий випадок?

694. Чи відповідає код місцевим шаблонам?

705. Чи обробляються помилки так само, як і в решті проекту?

71~

72Коли щось не так, відгук має бути конкретним. «Виправити» – це лінь. Краще: ця утиліта дублює `parseMoney` у `src/lib/money.ts`; повторно використовуйте цю функцію, додайте перевірку для випадку EUR і не змінюйте загальнодоступний API платіжного модуля.

73~

74Агенти набагато краще реагують на невеликі коментарі, які можна перевірити. Цікаво, що люди теж.

75~

76## Огородження варті зусиль

77~

78Якщо агент може читати файли, писати код і виконувати команди, його слід розглядати як потужний процес. Немає потреби в параної, потрібна гігієна.

79~

80Використовуйте окремі робочі дерева або гілки. Тож ви можете порівняти різницю, викинути невдалі експерименти та не змішувати роботу агента з тим, що ви робите.

81~

82Обмежити дозволи. Такі команди, як `rg`, `git diff`, `npm test` і `npm run build`, можуть бути досить безкоштовними. Розгортання, міграція баз даних, доступ до секретів і деструктивні команди повинні залишатися явними.

83~

84Зменште доступ до мережі, коли він вам не потрібен. Для багатьох завдань достатньо офіційної документації, реєстру пакетів і спеціальних внутрішніх служб. Менша площа, менше сюрпризів.

85~

86Відстежуйте дії. Коли патч надходить на перевірку, ви зможете реконструювати підказки, виконані команди, пройдені тести та змінені файли. Не для того, щоб створювати бюрократію, а щоб мати можливість зрозуміти, що сталося, якщо щось піде не так.

87~

88## Простий спосіб розпочати роботу як команда

89~

90Якби я ввів агентів у невелику команду, я б почав без серйозних революцій.

91~

92Я б створив мітку `agent-ready` для проблем із чітким масштабом. Я б додав шаблон із контекстом, обмеженнями та командами перевірки. Я б попросив невеликий піар, в ідеалі під кілька сотень рядків. Я б вимагав тестування або скріншотів для видимих змін. І перш за все я б залишив людину, відповідальну за злиття.

93~

94Через два тижні я переглядав дані: які завдання справді пришвидшилися, які перевірки були важкими, які підказки були заплутаними, які частини кодової бази занадто крихкі, щоб делегувати їх.

95~

96Це менш ефектний підхід, ніж «з сьогоднішнього дня ми все зробимо з агентами», але це той, який дозволяє без жалю дійти до третього тижня.

97~

98## Найбільш людська частина

99~

100Найсмішніше те, що чим більш автономними стають агенти, тим важливішими знову стають класичні навички: написання гарного квитка, створення невеликих скорочень, створення тестів, читання відмінностей, спілкування компромісів. Агент прискорює тих, хто вже вміє добре працювати. Це також посилює хаос тих, хто погано делегує повноваження.

101~

102Тож ні, я не вважаю багатоагентні робочі процеси ярликом, щоб припинити займатися розробкою. Я сприймаю їх як спосіб спрямувати більше енергії на важливі частини: вирішити, що будувати, переконатися, що це працює, підтримувати зрозумілість системи.

103~

104Агенти можуть бути чудовими асинхронними колегами. Але щоб асинхронний колега був корисним, потрібен контекст, межі та огляд. Як і всі інші.

105~

106## Корисні джерела

107~

108- [Codex для (майже) всього - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Безпечний запуск Codex на OpenAI](https://openai.com/index/running-codex-safely/)

110- [Представляємо Codex - OpenAI](https://openai.com/index/introducing-codex/)

111- [Що нового в агенті кодування GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112~