Ревью и тесты

Agents умеют генерировать много кода — и так же умеют генерировать tech debt. Скорость хороша только рядом с высокой планкой качества. Стандарты merge одинаковы: написал код руками или agent’ом — не важно.

AI-код может выглядеть правильным и при этом быть тонко сломанным: следует паттернам, компилируется, зелёные тесты — но мимо edge cases, с security дырой или дублем логики из другого угла репы.

Поэтому code review критичен. Инвестируй в процессы, которые ловят проблемы до прода.

Self-review

Сначала ревьюй сам — до того, как звать людей.

Смотри, как agent работает: diff растёт в реальном времени. Уехал не туда — Stop / прерви и перенаправь. Не обязан ждать финала. Для большой смены курса — откат + уточнение плана (как в уроке про фичи).

Попроси agent ревьюить весь набор изменений разом. Затегай @Branch, чтобы отдать полный diff ветки: «review the changes on this branch» или «what am I working on right now?».

Подготовка к peer review

Agents легко выдают один гигантский коммит на сотни строк. Такое никто не любит ревьюить.

Делай маленькие semantic commits с ясными описаниями: один коммит = одно логическое изменение. Reviewer проходит историю, а не стену диффа.

Руками это нудно — agents справляются хорошо:

1. Пили фичу свободно, не паранойя про commit hygiene
2. Когда всё работает — попроси agent пересобрать историю в reviewable куски
3. Он откатывается к main, читает изменения, планирует последовательность чистых коммитов
4. Сверяет финальный diff с оригиналом, чтобы ничего не потерять

Имеет смысл оформить это как skill /rework-commits для всей команды.

Agent Review

После задачи: Review → Find Issues — отдельный code review проход. Agent разбирает правки line by line.

Для всех локальных изменений открой Source Control и гоняй Agent Review против main — ловит проблемы на полном наборе изменений. По сути это хорошо собранный review-prompt из коробки.

Bugbot для pull requests

Bugbot ревьюит PR при пуше. Смотрит не только дифф, но и как изменённый код стыкуется с остальной кодовой базой. В отличие от linter’ов (форматирование/стиль), Bugbot целится в logic bugs: null deref, race conditions, дырявый error handling, security.

Нашёл issue — может предложить фикс. С autofix можно закоммитить прямо из комментария в PR. Bugbot тоже кастомизируется rules — об этом в следующем уроке.

Verifiable goals

Дай agent’у ясные сигналы корректности:

• Tests — поведенческие регрессии
• Type checking — структурные ошибки
• Linting — стиль и паттерны

Чем больше таких checks, тем смелее делегирование. Typed-языки + покрытие + lint рядом с agent’ом — отличная база.

Пусть agents пишут тесты

Раньше нормальное покрытие стоило дорого. Часто тесты писали «после инцидента» или из-под палки coverage-политики.

С agents писать тесты проще: попросил → проверил → поправил. Agent может и «ручное» тестирование через browser: проверить UI-состояния, которые ты обычно кликаешь сам.

Хорошие prompts:

• «Спланируй e2e coverage для checkout. Какие сценарии?»
• «Подними integration tests для payments API по паттернам из src/__tests__/»
• «Какие edge cases не покрыты в discount feature?»
• «Напиши regression tests на баг, который чинили в PaymentService.ts»

Agent поможет и с нуля поднять инфраструктуру — например, настроить Playwright и первый тест.

Cloud agents

Локальный agent живёт в редакторе. Cloud agents крутятся в remote sandbox: закрыл ноут — потом забрал результат.

Как это обычно выглядит:

1. Описываешь задачу и даёшь context
2. Agent клонит репу, создаёт ветку
3. Работает сам, открывает PR
4. Тебя нотифицируют (Slack / email / web)
5. Ревьюишь и мержишь

Хорошо заходят задачи «с to-do списка»: побочный баг, покрытие тестами, docs, рефакторинг.

Тестирование масштабом

Мощный паттерн: много cloud agents параллельно бьют разные edge cases, error conditions, комбинации inputs.

Добавил discount codes — запусти агентов на каждый тип скидки, invalid inputs, stacking, boundary values. Каждый вернёт ветку с кейсами и результатами. Собери failures в локальные reproducible тесты и почини до merge.

Ускоряй feedback loops

Когда agents становится много, bottleneck смещается на самое медленное: test suite, typecheck по монорепе, CI.

Каждый разговор платит эти costs. Тесты 10 минут × 10 параллельных agents ≈ почти два часа ожидания. Ускорил тесты на 50% — почти час экономии на таком прогоне.

High-leverage улучшения:

• ускорить test suite
• почистить dependency tree
• оптимизировать CI
• ускорить typecheck / build

Команды часто откладывают такое «на потом», но когда agents гоняют эти команды десятки раз в день — экономия компаундится. Час на ускорение тестов может вернуть сотни часов.

И да: эти задачи как раз хорошо отдавать agents — узкий scope, понятный verifiable output.

Частый fail

Зелёные тесты ≠ код правильный. Тесты могли проверять не то поведение. Agent мог закрыть happy path и забыть edge cases.

Ты должен понимать изменения. Слишком большой дифф — режь на куски, удобные и тебе, и agents для ревью.

Что дальше

Фичи, дебаг, ревью — закрыты. Осталось ускорить workflow кастомизацией agents под твой codebase.