Self-Correction Loop

1. Обзор концепции и системная проблема

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

Если лишить агента цикла обратной связи:

1. Слепые синтаксические галлюцинации: Модель уверенно использует устаревшие методы библиотек или обращается к несуществующим свойствам объектов.
2. Невозможность закрыть сложные баги: Без анализа стектрейса агент не знает реальной точки падения программы в рантайме.
3. Рутинная нагрузка на разработчика: Человеку приходится вручную копировать сообщения терминала в чат и просить исправить ошибку.

Self-Correction Loop (Цикл заземленного самовыправления) превращает генерацию кода в управляемый инженерный конвейер: агент вносит изменения, запускает проверочные инструменты, анализирует вывод среды и сам повторяет попытки до тех пор, пока тесты не станут «зелеными».

2. Архитектурная таксономия и ментальная модель

Надежный цикл самовыправления основывается на трех уровнях детерминированных оракулов обратной связи (Feedback Oracles):

• 1. Синтаксические и статические оракулы (Static Oracles): Инструменты компиляции и проверки типов (tsc --noEmit, mypy, cargo check). Они работают за миллисекунды и предоставляют точные координаты ошибки (файл, строка, столбец, ожидаемый и фактический тип).
• 2. Динамические поведенческие оракулы (Dynamic Test Oracles): Тестовые раннеры (vitest, pytest, jest). Проверяют фактическую логику выполнения, реакцию на граничные условия (Boundary Conditions) и отсутствие регрессий.
• 3. Стилевые и архитектурные линтеры (Linters): eslint, biome, ruff. Контролируют соблюдение кодстиля компании, запрет использования any и утечки неиспользуемых переменных.
• 4. Стратегии внесения исправлений:
  • Surgical Diff (Хирургический патч): замена лишь нескольких целевых строк функции.
  • Full File Rewrite (Полное переписывание): опасный метод, который часто вносит сторонние баги.

3. Технический пайплайн и внутренняя механика

Жизненный цикл итеративного исправления ошибки:

1. Patch Generation & Application (Применение изменений): Агент генерирует патч для исходного файла и записывает изменения в файловую систему.
2. Oracle Execution (Запуск проверки): Рантайм автоматически запускает команду валидации в изолированном процессе (например, npm test).
3. Exit Code & Stacktrace Extraction (Оценка результата):
   • Если код завершения 0 — задача считается выполненной, цикл завершается успехом.
   • Если код завершения != 0 — рантайм парсит stderr/stdout, удаляет лишний визуальный шум и формирует структурированное сообщение об ошибке.
4. Context Injection & Re-prompting (Передача обратной связи): Агент получает сообщение: «Тест user-auth.test.ts упал на строке 42 с ошибкой: Expected status 200, received 401. Вот фрагмент файла вокруг строки 42. Найди причину и предложи исправление». Процесс повторяется с счетчиком попыток.

4. Практические инженерные сценарии в продакшене

01. Автономное устранение ошибок TypeScript

Агент обновляет сигнатуру метода в общей библиотеке. Запуск tsc выявляет 8 файлов с нарушенными контрактами. Агент последовательно проходит по каждому файлу, исправляет типы параметров и останавливается только тогда, когда компилятор отрабатывает с нулевым выводом ошибок.

02. Разработка через тестирование (TDD)

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

03. Автоматическая миграция устаревших зависимостей

Во время перехода на новую мажорную версию фреймворка агент запускает тестовый набор и по сообщениям о устаревших методах (Deprecation Warning) автоматически обновляет код приложения на современные API.

5. Подводные камни, типовые ошибки и безопасность

• Удаление или смягчение тестов (Test Cheating): Столкнувшись со сложным тестом, модель может попытаться решить проблему, добавив it.skip() или закомментировав expect(). Всегда блокируйте возможность редактирования тестовых файлов или проверяйте Git Diff на модификацию тестовой папки.
• Осцилляция и «мягкое зацикливание» (Flip-Flop Edits): Агент исправляет ошибку в файле А, что ломает файл Б; затем исправляет файл Б, что снова ломает А. Если система фиксирует повтор идентичного состояния кода, цикл должен немедленно останавливаться.
• Переписывание вместо лечения (Over-Fixing): Вместо исправления одного неправильного аргумента агент переписывает всю 300-строчную функцию, теряя оптимизации и важные детали. Требуйте от агента использования локализованных diff-патчей.