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-патчів.