Если AI-кодинг снижает качество кода, вы неправильно управляете качеством

Распространённый тезис про кодинг-агенты звучит так: «Конечно, AI помогает выдавать больше кода, но не пострадает ли качество?» Пострадает — если слепо мержить PR и отправлять их в прод. Но при вдумчивом, многоуровневом подходе к управлению качеством можно не просто удержать число багов на прежнем уровне, а даже снизить его — и при этом увеличить объём поставок в 2–3 раза.

Многие из этих защитных слоёв существовали и до эпохи Claude, Copilot и Codex (правда, теперь AI делает их заметно проще), а некоторые появились совсем недавно. Ниже — конфигурация, которую автор видел в успешной работе как в своей команде, так и у других.

Слой 1: Правильные требования

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

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

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

Слой 2: Unit-тесты с покрытием выше 95%

Кодинг-агенты делают test-driven development настолько простым, что повода его не делать не осталось. Но подходить нужно правильно: нельзя позволять агенту слепо писать проходящие тесты под баги, которые он сам только что добавил в код. Лучшие практики планирования и реализации обычно следуют такому шаблону:

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

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

Слой 3: Ручное тестирование

Замены человеку — вам, QA или продакту, который реально прогоняет фичу по всем краевым случаям, — по-прежнему нет. Именно этот шаг пока дал лишь скромный прирост продуктивности, и именно поэтому реальный рост выработки автора — 2–3x, а не 10x. Впрочем, есть шанс, что отдельные возможности для автоматизации здесь просто ещё не замечены.

Слой 4: Развитые автоматические E2E-тесты

End-to-end тесты — возможно, самые важные тесты в кодовой базе: они проверяют, что новые изменения не сломали существующую функциональность с точки зрения конечного пользователя. В идеале они гоняются на каждом PR, в тестовых и стейджинг-окружениях и в продакшене после каждого деплоя. В идеале их поддерживают те же разработчики, что пишут обычный код, — хотя понятно, что не каждая организация к такому готова.

AI упрощает написание E2E-тестов, но для эффективности ему нужны инструменты или MCP-серверы, позволяющие дебажить падения — например, браузерный инструмент или MCP-доступ к логам. При этом важно помнить: E2E-тесты не заменяют ручное тестирование, это лишь грубая, неполная проверка, что ничего важного не сломалось.

Слой 5: Проходы AI по качеству кода

Кодинг-агенты не очень хороши в следовании сложным инструкциям из AGENTS.md или CLAUDE.md. Зато они отлично справляются, если добавить отдельный проход на поиск и исправление конкретных проблем:

• проблемы безопасности;
• поиск переусложнённого или дублирующегося кода;
• соблюдение правил именования, организации файлов и форматирования;
• общий проход код-ревью на ошибки в логике;
• слишком длинные комментарии, написанные на «AI-языке» вместо нормального английского;
• любые другие специфические вещи, которые хочется находить и править.

Добавленные в скиллы планирования или реализации, такие проходы обходятся практически бесплатно: +5–15 минут к времени реализации без дополнительного внимания с вашей стороны. Их можно встроить и в ревью PR — если удобнее сначала посмотреть комментарии, а потом применять исправления.

Слой 6: Ревью PR людьми и AI

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

Но для сложных изменений ревью AI-кода по-прежнему необходимо. Регулярно всплывают ошибки уровня общей архитектуры, пропущенные нежелательные взаимодействия с другими фичами, переусложнённые или неоптимальные реализации — не говоря уже о странных подборах слов вроде «mint» вместо «generate» или «stamp» вместо «set».

AI-ревью тоже оказались отличным дополнением. В текущей команде на каждый PR гоняются и ревью от Claude, и от Cursor — и, что удивительно, каждый находит свои, разные проблемы. Можно добавить и кастомные ревью под разными углами: безопасность, эффективность, взаимодействия с другими репозиториями. Но имейте в виду: AI бывает чрезмерно придирчив, поэтому нужен ещё один проход, где другой агент вычищает предложенные AI-комментарии, лишённые реального смысла.

Слой 7: Мониторинг и алертинг

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

Лучше — подключить сервис трекинга ошибок вроде Sentry или GCP Error Reporting, который сам обнаруживает и дедуплицирует ошибки.

Лучший же подход — заставить Claude, Cursor или любого другого агента автоматически диагностировать эти ошибки, находить корневую причину и создавать PR с предложенным фиксом.

Выводы

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

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