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

«Агент Смит» сейчас — это уже целая платформа, на которой живут не только исправление багов, но и воспроизведение ошибок в браузере, автоматизация ручных тест-кейсов, ревью кода по требованиям и подготовка тестовой документации. Отлажены эти процессы неравномерно, лучше всего — именно исправление багов. Ключевая особенность процесса: это не цепочка промптов, а граф с ветвлениями и ранними остановками. Каждый шаг возвращает машинно читаемый артефакт (JSON по схеме), а решение о следующем шаге принимает код, читая эти артефакты. Модель не решает, куда идти дальше.

Прогон агента начинается с шага PREPARE: агент готовит рабочую зону, определяет, от какой ветки отталкиваться и куда пойдёт мерж-реквест — в основную ветку, релизную или фича-ветку. Выполняется чекаут, создаётся ветка под фикс, запускается переиндексация графа кода. Если граф не собрался, следующий шаг не получит контекст вовсе — устаревший граф хуже, чем никакого. Действует список защищённых путей (helm/, k8s/, Dockerfile, конфиги CI): багфикс не имеет права их трогать.

Процесс правки — не цепочка промптов, а граф с ветвлениями: модель не решает, куда идти дальше, это делает код.

На шаге ACCEPTANCE агент читает баг-репорт и формирует критерии приёмки — что значит «пофикшено». Читать код ему при этом запрещено: агент должен быть оракулом, который решает, какое поведение правильное. Если оракул увидит реализацию, он начнёт описывать то, что код делает, а не то, что он должен делать, и проверка превратится в тавтологию. Критерии должны описывать наблюдаемое поведение: «должно быть 200 вместо 401» — годится, «метод должен вернуть false» — нет. Каждый критерий опирается на дословную цитату из баг-репорта. Агент также выписывает смежное поведение, которое фикс не должен сломать, — страховка от «починил одно, сломал соседнее».

Если в задаче не хватает данных (текстов, локализации, конкретных значений), агент не сочиняет правдоподобное, а помечает задачу заблокированной и перечисляет, чего не хватает. На этой стадии — первая точка, где нужен человек: если агенту не удаётся вывести критерии, он просит у тестировщиков внятное описание или явный ожидаемый результат.

Шаг DIAGNOSE: агент читает код, ничего не меняя, и ищет корневую причину — не место падения. На выходе — гипотеза, файл и строки, отвергнутые версии и слой, в котором будет правка. Два вопроса здесь дороже остальных: один баг или целый класс (бьют ли соседние входы в тот же дефектный путь) и меняет ли фикс инвариант, на который опирается чужой код. Отдельно кодифицировано самое дорогое заблуждение — «в бэкенде это уже работает, тут только допилить UI». Такое допущение агент обязан подтвердить чтением кода. Глубину фикса агент выбирает сам, но рефакторинг ему пока запрещён — масштабные правки увеличивают технический долг.

Затем идёт шаг JUDGE: отдельный вызов с чистым контекстом сверяет диагноз с критериями приёмки и проверяет ровно одно — объясняет ли названная причина заявленный симптом. Судья не в курсе, что именно нашёл диагност, и это снижает риск самоуверенности модели.

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

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