Self-Debug

Коротко

Self-Debug особенно полезен для:

• text-to-code;
• text-to-SQL;
• функций с unit tests;
• исправления локальных багов;
• задач, где первый ответ "почти правильный".

Напиши функцию на Python. Затем сам проверь её на краевые случаи, найди баг и исправь код.

Задача: функция должна возвращать медиану списка чисел.

Техника хорошо работает, когда ошибка локальна и её можно выявить через объяснение или тест.

Почему Self-Debug работает

Первый кодовый ответ модели часто ломается не на архитектуре, а на локальных деталях:

• off-by-one;
• забытый edge case;
• неправильное имя поля;
• неверный SQL join;
• потерянная обработка пустого ввода.

Self-Debug добавляет ещё один проход, где модель перестаёт быть только "автором" и становится "отладчиком". Это резко полезнее, чем просто попросить "напиши лучше", потому что внимание направляется на failure modes.

Что именно проверяет техника

На практике Self-Debug может опираться на три типа сигнала:

1. объяснение собственного кода;
2. результат выполнения;
3. unit tests или их аналог.

Даже если нет test suite, одно лишь требование "пошагово объясни, что делает код на этом входе" часто помогает модели увидеть баг, который она не заметила на генерации.

Когда техника особенно полезна

Self-Debug окупается в сценариях, где:

• есть короткий feedback loop;
• баги локальны и воспроизводимы;
• запуск или симуляция дешёвые;
• важнее надёжность, чем минимальная latency.

Хорошие примеры:

• генерация SQL;
• Python-утилиты;
• небольшие backend-функции;
• data transforms;
• code interview tasks;
• правка тестов и миграций.

Где техника слабее

Self-Debug не заменяет полноценный code review.

• Если решение архитектурно неверно, локальная отладка мало поможет.
• Если тесты сами плохие, модель может "подогнать" код под слабую проверку.
• Если проблема в требованиях, а не в коде, self-debug только косметически улучшит реализацию.

То есть техника сильна на execution-level и logic-level ошибках, но слабее на system design.

Как применять в 2026

Сегодня Self-Debug особенно полезен в agentic coding runtimes, где есть доступ к:

• unit tests;
• линтерам;
• типизации;
• sandbox execution;
• diff-based edits.

Фактически это уже стандартный building block для coding agents: generate -> run -> inspect -> patch. Даже один такой цикл часто даёт огромный прирост к качеству по сравнению с single-pass generation.

Практическая ценность

Главный выигрыш Self-Debug не только в pass rate, но и в sample efficiency. Вместо десяти независимых кандидатных решений вы даёте модели шанс улучшить один почти рабочий вариант. Это часто дешевле и лучше контролируется.

Именно поэтому техника так хорошо ложится на современные coding workflows. Она делает модель ближе к реальному инженеру, который не просто пишет код, а читает свои ошибки и исправляет их.

Техническая реализация

const draft = await model(codeTask)
const feedback = await runTestsOrExplain(draft)

const patched = await model(`
Вот код и feedback.
1. Найди причину ошибки.
2. Исправь её минимальным патчем.

Code:
${draft}

Feedback:
${feedback}
`)

Практический совет: в self-debug loop полезно ограничивать объём правки. Просите minimal patch или изменение только затронутой функции, иначе модель может начать лишний рефакторинг.