Кодекс и мультиагентный рабочий процесс: работайте с агентами, не теряя контроля

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

1~
2Когда программист впервые исправляет за вас ошибку, реакция почти всегда одинакова: смесь энтузиазма и подозрений. Приятно, конечно. Но потом ты смотришь на диф и спрашиваешь себя: «Хорошо, а что именно он трогал? Могу ли я ему доверять? Сделает ли он это снова таким же образом завтра?».
3~
4Вот здесь, я думаю, начинается самое интересное. Не тогда, когда агент пишет функцию, а когда он становится достаточно дееспособным, чтобы брать на себя целые куски работы: читать репозиторий, создавать патч, запускать тесты, открывать PR, возвращаться после обзора комментария. Кодекс движется именно в этом направлении: фоновая работа, отдельные рабочие деревья, интегрированный браузер, автоматизация, плагины, память и более явный контроль разрешений.
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[Тестирование, проверка, сборка, браузер]
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- [Кодекс (почти) всего — OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Безопасное использование Кодекса в OpenAI](https://openai.com/index/running-codex-safely/)
110- [Представляем Кодекс — 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, возвращаться после обзора комментария. Кодекс движется именно в этом направлении: фоновая работа, отдельные рабочие деревья, интегрированный браузер, автоматизация, плагины, память и более явный контроль разрешений.

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[Тестирование, проверка, сборка, браузер]

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- [Кодекс (почти) всего — OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Безопасное использование Кодекса в OpenAI](https://openai.com/index/running-codex-safely/)

110- [Представляем Кодекс — 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~