Автор: Кваме Боатенг

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

Именно поэтому наиболее важным изменением в проектировании команд разработчиков, использующих агентов, может стать переход от личных запросов к видимым рабочим пространствам. Например, Slack Code, согласно описанию, объединяет проектные каналы с агентами для программирования, аудит различий кода, предварительный просмотр HTML в реальном времени, процессы обратной связи и одобрения, автоматическое архивирование и журналы аудита. В приложении Copilot от GitHub также появилась панель «Моя работа» для организации задач и запросов на слияние в разных проектах. Эти функции указывают на практический принцип: работа агента должна выглядеть не как непрозрачный ответ, а как набор изменений, проходящий через контролируемый производственный процесс.

Чат — это не рабочая запись

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

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

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

Пять уровней видимой работы

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

  1. Замысел: задача, критерии приёмки, ограничения и запрошенный объём работ.
  2. План: предложенный агентом подход до внесения изменений в файлы. Для нетривиальной задачи это контрольная точка одобрения, а не формальность.
  3. Различия: точные добавления, удаления, изменения зависимостей и конфигурации, а также сгенерированные ресурсы.
  4. Подтверждения: результаты тестов, вывод линтера, проверки безопасности, снимки экрана и, где это уместно, предварительный просмотр в реальном времени или готовая к развёртыванию версия.
  5. Запись решения: комментарии проверяющих, запрошенные изменения, одобрение, отклонение, откат или последующая работа.

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

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

Фраза «человек в контуре» слишком расплывчата, чтобы быть полезным средством контроля. Человек может одобрить план, не увидев итоговый набор различий, или одобрить изменение кода, не заметив, что агент также изменил файл развёртывания. Более качественные процессы чётко определяют, что именно разрешает одобрение.

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

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

Предварительные просмотры превращают проверку в осмотр

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

Предварительные просмотры не являются доказательством корректности. Они должны дополнять, а не заменять тесты и проверку исходного кода. Но они создают общий объект для обсуждения: проверяющий может указать на конкретный экран, состояние или взаимодействие и оставить отзыв, прикреплённый к предлагаемому изменению.

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

Для различий нужен контекст, а не только цвет

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

Полезные вопросы для ревью включают:

  • Как изменилось поведение, видимое пользователю?
  • Какие файлы были изменены только для поддержки реализации?
  • Какие предположения агент сделал о существующем поведении?
  • Какие тесты были добавлены, изменены или не запущены?
  • Может ли это изменение повлиять на разрешения, хранение данных, биллинг или внешние API?

Эти вопросы превращают ревью из расплывчатой просьбы «посмотрите это» в повторяемую проверку. Они также помогают выявить распространённую проблему: правдоподобная функция сопровождается неполным обновлением тестов или случайным изменением конфигурации.

Архивируйте важные рассуждения

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

Как минимум сохраняйте запрос, утверждённый план, итоговый diff, результаты работы инструментов и тестов, ссылку на предпросмотр или развёртывание, решения ревьюеров и любые предоставленные исключения. Если агент использовал внешние источники или извлекал внутренние документы, фиксируйте соответствующие ссылки на источники и момент, когда они повлияли на изменение. Для работы с высоким уровнем риска может быть оправдано сохранение полной переписки и журнала выполнения.

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

Как это меняет карьеру в сфере разработки ПО

Возникающий новый навык — не просто умение писать более качественные промпты. Это умение организовать работу так, чтобы другой человек мог её проверить и принять с доверием. Разработчикам нужно будет уверенно формулировать критерии приёмки, разбивать задачи, проверять diff в больших объёмах, создавать содержательные тесты и решать, в какой момент агент должен остановиться и задать вопрос.

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

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

Простое рабочее правило

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

В разработке с помощью агентов лучший помощник — не система, которая изолированно создаёт больше всего кода. Это система, чью работу можно понять, оспорить, утвердить, отменить и использовать для обучения.