Меня зовут Игорь Симаков, я тимлид, руковожу двумя командами. Это две классические продуктовые команды, в которых есть все, кто нужен для полного цикла разработки, от discovery до delivery. Сам я бэкенд-разработчик с десятилетним опытом и не пишу код руками с марта 2026 года, про это у меня есть отдельная статья. Потом я внедрил в командах практики и перевел всех ребят на агентскую разработку: и QA, и бэкенд, и фронтенд. Так что мои команды уже полгода не пишут код руками

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

Стек у нас Java и Spring, Kafka, PostgreSQL, Kubernetes. Агент Claude Code с моделью Opus, правила для него лежат прямо в репозиториях. Тестировщиков трое: в одной команде один тестировщик, наполовину ручной, наполовину автоматизатор, в другой один ручной и один автоматизатор

Что ловится до прода, а что нет

Когда мне выделили вторую команду, я начал управлять через метрики. Про это я писал на Хабре, там по сути был рассказ про мой SaaS-проект, который я вскоре закрыл: Claude решает ту же проблему, и разрабатывать что-то дополнительно нет необходимости, он легко собирает из этого дашборд. Так что я один раз собрал себе похожий дашборд для своих команд. Через метрики управлять удобно: видно, кто, где, как и сколько

На таком дашборде я увидел, что пропуск дефектов на прод у нас действительно вырос, причем значительно, и рост сопоставим с объемом кода, который мы начали поставлять. Это хорошо видно, когда ставишь графики рядом. Плюс на performance review была обратная связь от хэда QA, и мы начали смотреть

Я решил покопать, что происходит, и разобрал все баги двух команд за год, 268 штук. Баги, как выяснилось, не новые, они были и до агентов. Но сейчас это стало заметнее: кода мы стали приносить втрое больше, и дефектов стало проскакивать ощутимо больше. В основном это подкапотные, инженерные, то есть технические дефекты:

• контракты

• ошибки от соседей, например из-за троттлинга в соседнем сервисе или неправильной обработки этих ошибок у нас

• нагрузка, когда клиенты через открытое API запрашивают кучу заказов или дергают ручку, где идет большая нагрузка

• данные между сервисами и их переливка

• выкатки без обратной совместимости, когда миграция поменяла структуру базы или сами данные, например заапдейтили колонку, и откатить релиз уже нельзя. Или криво создали индекс, и он заблокировал таблицу под нагрузкой

• гонки и конкурентные апдейты, которые перетирают данные

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

Что происходит, когда кода втрое больше

За год мерж-реквестов стало почти вдвое больше, с 199 до 351 за квартал, и сам средний мерж-реквест вырос почти вдвое, со 160 до 280 строк. Вместе это втрое больше кода, с 32 до 97 тысяч строк за квартал

Тестировщиков при этом столько же. Технических багов на проде с конца 2025 года стало вчетверо больше. Функциональные дефекты ребята успевают отлавливать, у нас есть e2e-тесты на Playwright и ручное тестирование. А инженерных дефектов раньше были единицы, теперь за квартал набирается три десятка, отсюда и хотфиксы

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

Кто находит баги на проде

Находят это на проде либо алерты, либо люди. Алерты и мониторинг находят 30%, пользователи и соседние команды 25%, сама команда 38%: у нас есть алерты, есть логи, и из них мы заводим долг или дефект. Для сравнения на графике разбор 152 серьезных инцидентов Microsoft Teams (Ghosh et al., SoCC 2022), там 55% нашли мониторы и только 6% сама команда

Почему «больше тестировать» не поможет

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

У Егора Бугаенко есть книга Angry Tests о том, что тесты должны быть злыми и ломающими. Но так делают единицы. Обычно тестировщик проверяет, что функционал работает так, как описано, плюс краевые сценарии, чтобы убедиться, что мы ничего не сломали

Как мы теперь проверяем код агента

Сейчас у нас это выглядит так:

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

• сгенерированный тест прогоняется мутацией локально в Claude: агент ломает код, и мы убеждаемся, что тест тестирует именно то, что должен, что он честный

• есть статические анализаторы, линтеры, правила ArchUnit, платформенные правила, тесты на базу данных и на индексы. Все это автоматизировано

• дальше селф-ревью и код-ревью, ревьюим друг друга, несколько циклов, мержим. На dev-стенде агент сам прогоняет сценарий end-to-end: у него есть REST-запросы и доступ на чтение к базе. Он смотрит, что нигде не поломал обратную совместимость, и проходит базовые корнер-кейсы

• на stage, где обезличенная копия прода без чувствительных данных, гоняем нагрузку и смотрим планы новых запросов через EXPLAIN ANALYZE. Скрипт нагрузки Claude делает очень хорошо: профиль под нефункциональные требования, дает нужную нагрузку, сразу снимает метрики и показывает, где мы упираемся, в базу, в треды или в гонки, где падаем и что проседает первым

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

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

Вопросы, на которые у меня нет ответа

Первый про роль тестировщика: кто он теперь и где он. Наши тестировщики все больше становятся инженерами: в первом квартале они отправили 6 мерж-реквестов, в третьем 34, почти все в репозиторий автотестов. То есть тестировщик должен решать, какие ситуации нужны на стенде и куда смотреть, а прогонять их, наверное, будет агент. А может, и разработчик, тут уже непонятно, границы начинают перекрываться. Недавно читал статью про Авито: команды у них становятся меньше, потому что нет необходимости в таком количестве ролей, а самих команд станет больше. Как я понимаю, каждый разработчик становится инженером полного цикла, команды и роли схлопываются. Они уже пробуют работать небольшими командами, которые ведут задачу от начала до конца, по сути от discovery до delivery, чтобы было меньше передач и коммуникаций. Может, и мы к этому придем и будем делиться по сервисам или поддоменам

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

И последний вопрос, пошире. Кода теперь появляется больше, чем мы успеваем прочитать и описать, и местами это код, который мы сами до конца не понимаем. Мы доверяем агенту и тому, чем он себя проверяет: интеграционным тестам и всем самопроверкам, которые мы для него написали. Раньше за качество отвечал человек, который понимал свой код. Теперь он отвечает, по сути, за пайплайн вокруг кода: где-то его подпирает, где-то вставляет проверки, говорит агенту, что и как делать, добавляет анализаторы. Можем ли мы этому доверять? Каждая команда решает сама. Я для себя решил, что можем: агент точно делает лучше, чем среднестатистический человек, и спорить с этим нет смысла. Чем быстрее мы это примем, тем быстрее пойдем вперед, тягаться с этим уже бессмысленно

Продолжение следует…