Когда программист впервые исправляет за вас ошибку, реакция почти всегда одинакова: смесь энтузиазма и подозрений. Приятно, конечно. Но потом ты смотришь на диф и спрашиваешь себя: «Хорошо, а что именно он трогал? Могу ли я ему доверять? Сделает ли он это снова таким же образом завтра?».

Вот здесь, я думаю, начинается самое интересное. Не тогда, когда агент пишет функцию, а когда он становится достаточно дееспособным, чтобы брать на себя целые куски работы: читать репозиторий, создавать патч, запускать тесты, открывать PR, возвращаться после обзора комментария. Кодекс движется именно в этом направлении: фоновая работа, отдельные рабочие деревья, интегрированный браузер, автоматизация, плагины, память и более явный контроль разрешений.

Дело не в том, чтобы представить себе будущее, в котором никто больше не читает код. Это было бы ужасное будущее, а также довольно наивное. Суть в том, чтобы научиться работать с агентами, которые могут многое, не позволяя им делать все.

Изменение привычки

Благодаря традиционному автозаполнению вы всегда будете за рулем. ИИ предложил линию, вы решили. Однако с агентом отношения меняются: вы даете ему цель, и он самостоятельно проходит несколько этапов.

Это мощно, но это меняет проблему. Вопрос уже не в том, «может ли модель запрограммироваться?». Вопрос становится:

• Дал ли я ему достаточно небольшой простор?
• ты знаешь как проверить результат?
• Работаю ли я в изолированной среде?
• Является ли окончательный обзор гуманным и осторожным?

Здоровый рабочий процесс больше похож на волшебную палочку:

Звучит менее романтично, чем «все строит агент», но работает гораздо лучше. И именно так работают команды, которые хорошо ладят с людьми: четкие задачи, быстрая обратная связь, четкая подотчетность.

Хорошая подсказка — почти хороший билет

Самая опасная подсказка — расплывчатая, но уверенная: «исправить страницу счетов», «улучшить архитектуру», «почистить модуль авторизации». Это запросы, которые кажутся продуктивными и создают огромные различия. Но потом вы обнаруживаете, что занимаетесь археологией.

Полезная подсказка скучнее. Например: реализовать экспорт CSV для страницы счетов, зная, что таблица находится в app/(dashboard)/invoices/page.tsx, запросы находятся в src/server/invoices.ts и аналогичный шаблон уже существует в app/(dashboard)/reports.

Затем добавьте четкие ограничения: не меняйте схему базы данных, не добавляйте зависимости, если достаточно небольшой утилиты, сохраняйте существующий стиль пользовательского интерфейса. И завершите проверкой: npm test -- invoices и npm run build.

Этот тип задания не предназначен для того, чтобы «лучше объяснить ИИ». Прежде всего, это помогает вам понять, что вы делегируете. Если вы не можете расписать конкретно, возможно, задание еще не готово для агента.

Три работы, которые я охотно делегирую

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

Вторая — исследовательская работа: «найди, где подсчитывается эта сумма», «объясни мне, почему этот тест ненадежен», «воспроизведи ошибку и скажи мне, какие файлы кажутся затронутыми». Даже если он не создает патч сразу, он может провести полезную разведку.

Третий — периодические работы по техническому обслуживанию: небольшие обновления зависимостей, очистка старых флагов функций, сводка заблокированных PR, проверка забытых TODO. Это не гламурно, но это именно та работа, которая имеет тенденцию накапливаться.

Три работы, которые я считаю человечными

Решения о продукте остаются человеческими. Если изменение меняет способ оплаты пользователя, удаляет данные, видит цены или понимает разрешение, мне нужен ответственный человек.

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

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

Обзор не является обязательным

Соблазн, когда агент хороший, состоит в том, чтобы довериться зеленому CI. Это понятно. Тогда же начинаются проблемы.

Я всегда смотрю как минимум на пять вещей:

1. Патч решает только запрошенную задачу?
2. Трогал ли он файлы, которые не имели к этому никакого отношения?
3. Охватывают ли тесты новое поведение или просто счастливый случай?
4. Соответствует ли код местным шаблонам?
5. Обрабатываются ли ошибки так же, как и в остальной части проекта?

Когда что-то не так, обратная связь должна быть конкретной. «Исправить» — это лень. Лучше: эта утилита дублирует parseMoney в src/lib/money.ts; используйте эту функцию повторно, добавьте тест для случая EUR и не меняйте общедоступный API модуля выставления счетов.

Агенты гораздо лучше реагируют на небольшие, проверяемые комментарии. Любопытно, что и люди тоже.

Ограждения стоят усилий

Если агент может читать файлы, писать код и выполнять команды, его следует рассматривать как мощный процесс. Не надо паранойи, нужна гигиена.

Используйте отдельные рабочие деревья или ветви. Так вы сможете сравнить разницу, отбросить неудачные эксперименты и не смешивать работу агента с тем, что делали вы.

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

Ограничьте доступ к сети, когда он вам не нужен. Для многих задач достаточно официальной документации, реестра пакетов и конкретных внутренних сервисов. Меньше площадь поверхности, меньше сюрпризов.

Отслеживайте действия. Когда патч поступает на проверку, вы сможете восстановить подсказки, выполненные команды, пройденные тесты и измененные файлы. Не для создания бюрократии, а для того, чтобы иметь возможность понять, что произошло, если что-то пойдет не так.

Простой способ начать работу в команде

Если бы я вводил агентов в небольшую команду, я бы начал без крупных революций.

Я бы создал ярлык agent-ready для проблем с четким объемом. Я бы добавил шаблон с контекстом, ограничениями и командами проверки. Я бы попросил небольшой пиар, в идеале до нескольких сотен строк. Мне бы потребовалось тестирование или скриншоты для видимых изменений. И, прежде всего, я бы хотел, чтобы за слияние был ответственный человек.

Через две недели я смотрел данные: какие задачи действительно были ускорены, какие обзоры были тяжелыми, какие подсказки сбивали с толку, какие части кодовой базы слишком хрупкие, чтобы их делегировать.

Это менее эффектный подход, чем «с сегодняшнего дня мы все сделаем с агентами», но именно он позволяет без сожалений дойти до третьей недели.

Самая человечная часть

Забавно то, что чем более автономными становятся агенты, тем важнее снова становятся классические навыки: написание хорошего билета, внесение небольших сокращений, создание тестов, чтение различий, обсуждение компромиссов. Агент ускоряет тех, кто уже умеет хорошо работать. Это также усиливает хаос среди тех, кто плохо делегирует полномочия.

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

Агенты могут стать отличными асинхронными коллегами. Но чтобы быть полезным асинхронному коллеге, нужны контекст, границы и обзор. Точно так же, как и все остальные.

Полезные источники

• Кодекс (почти) всего — OpenAI
• Безопасное использование Кодекса в OpenAI
• Представляем Кодекс — OpenAI
• Что нового в агенте кодирования GitHub Copilot