Для парного программирования с ИИ нужны правила работы

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

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

Парная работа начинается с письменной договоренности

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

Я использую описание сессии, которое помещается на одном экране:

Outcome: Reject a renewal when the stored payment token is expired.
Allowed: billing/renewal, tests/billing
Do not change: public API, database schema, retry policy
Evidence: failing test first, focused suite passes, diff reviewed
Stop when: a schema change or policy decision appears necessary

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

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

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

Короткие сессии лучше героически длинного контекста

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

Для многих задач разумный рабочий диапазон составляет от 45 до 90 минут, но это не закон. Более строгое правило - один результат на сессию. Если исправление ошибки обнаруживает отсутствие нужной абстракции, закройте сессию по ошибке с зафиксированными выводами. Для проектирования абстракции начните отдельную сессию. Такая граница делает историю понятной и не дает локальному исправлению превратиться в экскурсию по всему репозиторию.

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

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

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

Давайте контекст с учетом уместности и риска

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

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

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

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

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

Результат агента остается предложением до проверки человеком

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

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

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

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

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

Git дает дешевую первичную проверку, которую команды слишком часто пропускают:

git status -s
git diff
git diff HEAD

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

Для участков с высоким риском требуйте второго ревьюера-человека или отдельную сессию проверки, которая начинается без объяснения исходного агента. Аутентификация, авторизация, движение денег, необратимые переносы данных и конкурентное выполнение заслуживают независимого анализа. Дело не в недоверии к ИИ как категории. Эти области требовали усиленной проверки и тогда, когда все строки писали люди; высокая скорость генерации увеличивает объем кода, который доходит до контрольной точки.

Проверяйте пространство вокруг изменений

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

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

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

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

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

Здесь небольшие запросы на слияние оправдывают себя. Google Engineering Practices утверждает, что ревьюеры быстрее отвечают на небольшие изменения и могут изучить их тщательнее. Я согласен с одной оговоркой: у маленькой разницы все равно может быть широкий радиус поведения. Ограничьте объем ради понимания, а затем отдельно исследуйте радиус влияния.

Человек отвечает за каждую принятую строку

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

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

Не просите агента изображать согласие. Вопрос Ты уверен? вызывает еще один уверенный ответ. Поручайте проверяемую работу: найти места вызова, показать падающий тест до исправления, сравнить два подхода по указанному ограничению или выдать точный результат команды. Доказательства могут оставаться неполными, но ревьюер получает конкретный материал для проверки.

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

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

Прерывайте агента на границах решений

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

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

В комментариях называйте нарушенное ограничение и наблюдаемое исправление. Фраза Это неправильно не задает агенту устойчивого направления. Указание Оставь два повтора, потому что провайдер может списать деньги при каждом принятом запросе; добавь тест, который считает вызовы содержит и причину, и способ проверки. Такой комментарий помогает партнеру-человеку и подходит для записи в запросе на слияние.

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

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

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

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

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

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

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

Завершайте сессию записью для другого инженера

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

Используйте короткий итоговый блок в описании запроса на слияние или рабочей задачи:

Outcome: Expired renewal tokens are rejected before provider calls.
Changed: renewal validator, both provider paths, boundary tests
Verified: billing unit suite; provider contract suite; manual expired fixture
Decisions: retained public error code for existing clients
Unresolved: alert threshold still uses the old failure category
Human owner: initials or team role

Заполняйте блок наблюдаемыми доказательствами. Формулировка Тесты прошли слишком расплывчата; назовите наборы или команды. Фраза Биллинг переработан скрывает поведение; назовите путь и неизменяемое условие. Строка с нерешенным вопросом не означает провал. Она не дает следующему человеку принять ограниченное изменение за полное исправление системы.

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

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

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

Проверяйте, сохранились ли знания после сессии

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

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

Несколько недель отслеживайте несколько рабочих показателей:

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

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

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

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

Расширяйте практику после укрепления системы ревью

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

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

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

Экономика требует полного расчета. Учтите подписки и вычисления, время ревьюеров, повторную работу, риск инцидентов и сэкономленное на реализации время. Сравнивайте завершенные и работающие результаты, а не созданный объем. Команда может выпускать втрое больше патчей и не ускорить поставку, если ревью и продуктовые решения остаются ограничением. Она также может стать намного меньше и быстрее, когда старшие инженеры владеют узкими результатами, а агенты выполняют точно описанную работу.

Основателям, которые не видят, куда переместилось ограничение, Team & AI Audit от oleg.is поможет оценить работу, нагрузку ревью, настройку агентов и возможную экономию до крупной перестройки. Полезный результат здесь - решение о составе команды и средствах контроля, а не стопка общих запросов.

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

Хороший этикет парного программирования с ИИ виден в репозитории после закрытия чата. Вы можете найти договоренность, проследить доказательства, назвать владельца и передать следующее изменение другому человеку. Если чего-то из этого нет, создавайте меньше кода, пока команда не докажет, что понимает уже принятое.