Последнее время я все чаще вижу одну и ту же картину.
Появился тикет. Программист копирует ссылку, передает ее AI-кодинг-агенту и через какое-то время получает готовый Pull Request.
Вроде бы красота.
Агент прочитал задачу, нашел нужный код, что-то поменял, запустил тесты и бодро написал, что все готово.
Только потом начинается самое интересное.
В Pull Request приезжает куча лишнего кода. Тесты зеленые, но сама функция не работает. Тикет уходит тестировщику и возвращается обратно. После исправления снова возвращается. А иногда оказывается, что агент вообще понял задачу не так, но программист этого даже не заметил, потому что сам тикет толком не прочитал.
Я не против AI-кодинг-агентов. Наоборот, я ими постоянно пользуюсь и считаю, что это уже обычный рабочий инструмент программиста.
Но инструмент, который быстро пишет код, не отменяет необходимость думать.
Сейчас возникла опасная иллюзия, что путь от тикета до Pull Request можно полностью отдать AI. Тестировщик написал задачу, агент написал код, программист просто нажал кнопку создания Pull Request.
Но между тикетом и готовым кодом остается огромное количество работы, которую должен делать именно программист.
Нужно понять задачу. Уточнить спорные моменты. Найти настоящую причину проблемы. Ограничить AI, чтобы он не переписал половину проекта. Проверить diff. Запустить продукт. Воспроизвести пользовательский сценарий. Подумать о старых данных, ошибках, пограничных ситуациях и побочных эффектах.
AI может помочь пройти этот путь быстрее, но пройти его вместо программиста он пока не может.
Поэтому я решил собрать простой манифест работы с AI-кодинг-агентами внутри команды.
Это не попытка запретить AI и не набор бюрократических правил. Скорее напоминание, что AI ускоряет работу программиста, но не переносит ответственность за результат на себя.
Ниже сам текст манифеста.
Манифест работы с AI-кодинг-агентом
От тикета до Pull Request еще очень далекий путь.
AI-кодинг-агент не снимает с программиста ответственность. Он только быстрее пишет код. Думать, проверять и отвечать за результат все равно должен программист.
Нельзя просто скормить агенту ссылку на тикет
Тикет обычно пишет тестировщик, маркетолог или другой человек, который видит проблему со своей стороны, но не знает всей системы и устройства кода.
Поэтому перед передачей задачи AI программист обязан сам прочитать тикет и понять, что именно требуется сделать.
Нужно проверить, не затрагивает ли задача другие части системы, не нужно ли такое же изменение в других местах и не предлагает ли автор тикета решение, которое на самом деле не устраняет проблему.
Программист должен устранить разрыв между текстом тикета и реальным состоянием кода.
Если что-то непонятно или допускает разные трактовки, сначала нужно написать комментарий автору тикета и зафиксировать, как именно задача была понята и какое поведение будет реализовано.
Нельзя отдавать AI непонятный тикет и надеяться, что он сам правильно додумает продуктовую логику.
Сначала нужно воспроизвести баг
Нельзя исправлять проблему, которую никто не видел своими глазами.
Перед изменением кода программист должен воспроизвести баг, понять условия его появления и увидеть фактический результат.
Без этого невозможно нормально проверить исправление.
Если баг не воспроизводится, нужно изучать логи, данные, версию приложения, окружение и последовательность действий. Просить AI поменять что-нибудь похожее и надеяться на результат нельзя.
Нужно исправлять причину, а не симптом
AI любит быстрые решения.
Добавить проверку на null. Поймать исключение. Скрыть ошибку. Добавить задержку. Повторить запрос. Подставить значение по умолчанию.
Иногда это действительно правильное решение. Но часто это просто маскировка проблемы.
Программист обязан понять, почему ошибка возникла, и убедиться, что исправлена именно причина.
Если мы сегодня спрятали симптом, завтра эта же проблема появится в другом месте.
AI нужно явно ограничивать
AI не должен заодно рефакторить соседние модули, форматировать весь файл, переименовывать сущности, обновлять библиотеки и менять архитектуру.
Перед началом работы нужно сказать, что именно требуется изменить и какие части системы трогать не нужно.
Если в процессе выяснилось, что нужен большой рефакторинг, для него создается отдельный тикет и отдельный Pull Request.
В исправлении одной кнопки не должно быть переписано половины проекта.
Нужно смотреть, как такие задачи уже решаются в проекте
Перед написанием нового кода нужно найти похожую реализацию, существующие тесты, общие утилиты и принятые в проекте подходы.
AI часто создает новый helper, новый сервис или новую библиотеку, хотя нужное решение уже существует рядом.
Нельзя допускать, чтобы одна и та же задача в разных частях системы решалась пятью разными способами.
Изменения всегда должны быть покрыты тестами
После выполнения задачи нужно отдельно попросить AI добавить тесты на новую функциональность или исправленный баг.
Для программиста это одна фраза. Для AI это несколько минут. Для проекта это защита от повторного появления проблемы.
Но наличие нового теста само по себе ничего не гарантирует.
Тест должен проверять именно то поведение, ради которого создан тикет. Если исправлялся баг, желательно убедиться, что тест падает на старом коде и проходит после исправления.
Зеленые тесты не означают, что задача сделана
Очень часто AI пишет код, проект компилируется, тесты проходят, и программист сразу создает Pull Request.
Потом задача доходит до тестировщика и оказывается, что ничего не исправилось или стало еще хуже.
После завершения работы программист обязан сам запустить продукт и лично проверить пользовательский сценарий из тикета.
Если исправлялся интерфейс, нужно открыть интерфейс.
Если исправлялся backend, нужно отправить реальный запрос.
Если исправлялась интеграция, нужно проверить интеграцию.
Если исправлялась фоновая задача, нужно дождаться ее выполнения.
Компиляция не является проверкой продукта.
Нужно проверять не только идеальный сценарий
Реальный пользователь может потерять интернет, дважды нажать кнопку, закрыть экран, иметь старую сессию, старые данные или старую версию приложения.
Сервер может вернуть ошибку. Приложение может быть выгружено из памяти. Ответ может прийти поздно или два раза.
Не нужно превращать каждый тикет в месячное тестирование, но очевидные пограничные сценарии программист обязан проверить сам.
Особенно это касается платежей, подписок, авторизации, уведомлений, фоновых задач и пользовательских данных.
Если тикет переоткрыли, нельзя снова исправлять его наугад
Если после локальной проверки тестировщик переоткрыл задачу, нужно воспроизвести его окружение.
При необходимости нужно поднять виртуальную машину, установить нужную версию системы, использовать похожие данные и повторить точную последовательность действий.
Нельзя неделями перебрасывать тикет между разработчиком и тестировщиком, каждый раз добавляя очередную случайную правку.
После переоткрытия нужно не угадывать, а воспроизводить.
Нужно учитывать существующих пользователей
AI обычно пишет код так, будто база пустая, все пользователи новые, а frontend и backend обновляются одновременно.
В реальном продукте есть старые записи, старые настройки, активные сессии и старые версии мобильных приложений.
Перед отправкой изменений нужно проверить, что произойдет с существующими пользователями.
Если нужна миграция, обратная совместимость или поддержка старого формата, это нельзя игнорировать.
Пользователь не должен видеть технический мусор
Пользователю нельзя показывать stack trace, внутренние названия сервисов, ответы провайдера и непонятные технические ошибки.
Пользователь должен получить нормальное сообщение.
Разработчик при этом должен получить достаточно информации в логах, чтобы потом найти причину.
В логах не должно быть токенов, паролей, ключей и чувствительных пользовательских данных.
Перед Pull Request нужно прочитать весь diff
Не пролистать. Не посмотреть количество файлов. Не поверить отчету AI.
Нужно прочитать каждое изменение.
Если программист не может объяснить, зачем изменена конкретная строка, эту строку нельзя отправлять на код-ревью.
Из Pull Request нужно убрать случайное форматирование, лишний рефакторинг, заглушки, закомментированный код, дублирование и изменения, которые не относятся к тикету.
Код-ревьюер не должен очищать за программистом результат работы AI.
Один Pull Request должен решать одну задачу
Не нужно смешивать исправление бага, обновление зависимостей, рефакторинг соседнего модуля и случайно найденные проблемы.
Чем меньше Pull Request, тем проще его понять, проверить, протестировать и откатить.
Большой Pull Request часто означает не большой объем полезной работы, а отсутствие контроля над AI.
Pull Request должен объяснять решение
Описание fixed или done не подходит.
Нужно написать, в чем была причина проблемы, что изменено, как проверялось и какие тесты добавлены.
Если есть риски или ограничения, их тоже нужно указать.
Тестировщик должен понимать, что проверять. Ревьюер должен понимать логику решения.
После замечаний код-ревьюера продукт нужно проверить еще раз
Изменения после код-ревью могут сломать уже рабочий сценарий.
После исправления замечаний нужно снова запустить тесты и еще раз проверить основной сценарий вручную.
Особенно если менялась логика, асинхронность, работа с данными или обработка ошибок.
За код отвечает программист
Фраза это написал AI не является оправданием.
Для пользователя, тестировщика, ревьюера и компании неважно, кто сгенерировал код.
Ответственность несет программист, который принял решение и создал Pull Request.
Если программист не понимает код, его нельзя отправлять на ревью.
Если программист не запустил продукт и не проверил результат, задача не закончена.
Если программист просто передал тикет AI, а потом передал его код ревьюеру и тестировщику, он не выполнил свою работу. Он просто переложил ее на следующих людей.
Это пока первая версия манифеста.
Я собрал в нем то, с чем сам сталкиваюсь при работе с AI-кодинг-агентами, при просмотре Pull Request и при возврате задач от тестировщиков.
Наверняка там чего-то не хватает. Возможно, с какими-то пунктами вы вообще не согласны.
Полный текст манифеста лежит на GitHub:
https://github.com/evgenyigumnov/ai-coding-manifesto
Присылайте Pull Request, создавайте Issues, предлагайте новые разделы и спорьте с существующими формулировками.
Будем вместе дорабатывать манифест по мере того, как меняются AI-агенты и сама работа программиста.
Потому что AI-кодинг только начинается, а правила нормальной работы с ним нам еще предстоит выработать.
ссылка на оригинал статьи https://habr.com/ru/articles/1059152/