Манифест программиста, использующего AI-кодинг-агента
До передачи задачи AI разработчик должен сам прочитать тикет, уточнить неоднозначности, воспроизвести баг и найти его настоящую причину. Агенту нужно заранее задать границы изменений, запретив попутный рефакторинг, обновление библиотек и переписывание соседних модулей: одна задача — один Pull Request.
Сгенерированные изменения должны быть покрыты тестами, которые проверяют именно требуемое поведение. Зелёных тестов и успешной компиляции недостаточно: программисту нужно запустить продукт, пройти пользовательский сценарий, проверить ошибки, пограничные случаи, старые данные и обратную совместимость. Если тикет переоткрыли, следует воспроизвести окружение тестировщика, а не добавлять очередную случайную правку.
Перед отправкой на ревью разработчик должен прочитать весь diff, удалить лишнее форматирование, дублирование и изменения вне задачи, а в описании указать причину проблемы, способ исправления, проведённые проверки и риски. После замечаний ревьюера тесты и основной сценарий запускаются повторно, поскольку за итоговый код отвечает программист, независимо от того, кто его сгенерировал.
Коротко
- Перед передачей задачи агенту программист должен сам прочитать тикет, снять двусмысленности и зафиксировать ожидаемое поведение.
- Баг нужно воспроизвести до изменений, а исправление должно устранять причину проблемы, а не маскировать симптом проверкой или повтором запроса.
- AI-агенту задают жёсткие границы: соседний рефакторинг, обновление библиотек и архитектурные изменения выносят в отдельные тикеты и Pull Request.
- Зелёных тестов недостаточно: разработчик обязан запустить продукт, проверить реальный пользовательский сценарий и очевидные пограничные случаи.
- Перед ревью программист читает весь diff, удаляет лишние изменения, описывает причину и проверку, а ответственность за итоговый код оставляет за собой.
FAQ
Зачем команде нужен отдельный манифест работы с AI-кодинг-агентами, если разработчики уже используют их как обычный инструмент?
Он фиксирует границу между генерацией кода и инженерной работой. Агент может ускорить изменения, но не должен самостоятельно трактовать продуктовую логику, определять причину бага и принимать результат.
Почему успешная компиляция и зелёные автоматические тесты не считаются достаточной проверкой результата AI-кодинг-агента?
Тест может проверять не то поведение или не охватывать реальный пользовательский сценарий. Поэтому разработчик должен лично запустить интерфейс, запрос, интеграцию или фоновую задачу, которую менял.
Как действовать, если тестировщик переоткрыл тикет после локальной проверки и предыдущего исправления, подготовленного с помощью AI?
Нужно воспроизвести его версию приложения, окружение, данные и точную последовательность действий. Добавлять случайные проверки и повторные запросы без воспроизведения ошибки не следует.
Читайте также
Персонализация без Big Data: как ранжировать новости в Telegram с помощью pgvector и пяти сигналов- Как перенести расчёт абсолютных валютных курсов на Kaggle и автоматизировать обзоры через Gemini API
- Серверные стойки на 5 и 10 дюймов для homelab: переработка Lab Rax
Meta обвинили в использовании предвзятого AI-таргетинга при массовых увольнениях
Reddit выясняет, не вредят ли сделки по продаже данных для ИИ его рекламному бизнесу
- Подготовка тикета перед передачей AI-кодинг-агенту: Перед запуском AI-агента разработчик должен самостоятельно сверить текст тикета с текущей логикой продукта и состоянием кода. Неоднозначные требования, предполагаемое поведение и затрагиваемые части системы нужно зафиксировать до генерации изменений, иначе агент может реализовать неверную трактовку задачи.
[Регламент AI-разработки]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Манифест формулирует практические правила работы с AI-кодинг-агентами внутри команды. Главный тезис: агент ускоряет написание кода, но понимание задачи, проверка результата и ответственность за Pull Request остаются за программистом.