TL;DR
Failure-Aware Framework — система выбора метода улучшения кода, когда базовый progressive prompting (пошаговая генерация: требования → дизайн → тесты → код) не справился. Суть: разные типы ошибок требуют разных стратегий исправления — Self-Critique (самопроверка), Multi-Model Collaboration (разные модели для дизайна и кода) или RAG-Assisted (документация в контекст).
Progressive prompting выдаёт 96.9% выполнения задач против 80.5% у прямого промпта, но 32% проектов всё равно остаются недоделанными. Ошибки делятся на 4 типа: логические (пропущенная валидация), интеграционные (API не подключён), доменные (медицинские правила неизвестны), инфраструктурные (Docker-конфиг не настроен). Self-Critique отлично работает на логических ошибках (видны в коде при ревью), но даёт 0% улучшения на интеграционных — модель не знает как настроить RabbitMQ, сколько ни проверяй код. RAG-Assisted решает это, подсовывая туториалы по RabbitMQ прямо в контекст.
Decision framework — карта "тип ошибки → метод": для логических ошибок берём Self-Critique (быстро, 138 минут), для интеграций/домена/инфраструктуры — RAG-Assisted (193 минуты, 31.5 мин на процентный пункт улучшения), для критичных задач — Multi-Model (279 минут, но 100% в 5 из 6 проектов). Эмпирически доказано: не все методы работают везде, выбор зависит от характера недоделки.
Схема методов
Базовый: Progressive Prompting
ШАГ 1: Анализ требований → список задач
ШАГ 2: Архитектурный дизайн → структура проекта
ШАГ 3: Спецификация тестов → сценарии проверки
ШАГ 4: Генерация кода → реализация
Все шаги — отдельные промпты в одной сессии.
Enhancement 1: Self-Critique (самопроверка)
ШАГ 1-4: Progressive Prompting
ШАГ 5: "Проверь код. Все требования выполнены? Что пропущено?"
ШАГ 6: LLM находит пропуски → генерирует исправления
ШАГ 7: Повтор 5-6 пока LLM не скажет "всё готово"
Итеративный цикл в той же сессии.
Enhancement 2: Multi-Model Collaboration
В ChatGPT (GPT-5):
ШАГ 1: Анализ требований
ШАГ 2: Архитектурный дизайн → детальная спецификация
В Claude (Sonnet 4.5):
ШАГ 3: Копируешь спецификацию из GPT
ШАГ 4: Генерация кода по дизайну
Переключение между чатами — ручной перенос спецификации.
Enhancement 3: RAG-Assisted (документация в контекст)
ПОДГОТОВКА: Найди документацию/примеры (официальные доки, GitHub проекты)
ШАГ 1-4: Progressive Prompting + в промпт добавь:
"Используя эти примеры и документацию [вставить], реализуй требования"
Копипаст документации в каждый релевантный промпт.
Пример применения
Задача: Делаешь Telegram-бота для приёма заказов кофейни. Progressive prompting сгенерировал базовый код (меню, корзина, команды), но не смог интегрировать оплату через ЮKassa — в коде просто заглушка # TODO: payment integration.
Диагностируем тип ошибки
Смотришь код: логика корзины есть, валидация есть, но внешний API (ЮKassa) не подключён. Это External Integration Failure.
По decision framework: - 1-й выбор для integration failures: RAG-Assisted - 2-й выбор: Multi-Model - 3-й выбор: Self-Critique (не работает на таких ошибках)
Применяем RAG-Assisted
Промпт:
Используя официальную документацию ЮKassa для Python и примеры ниже,
доработай функцию create_payment() для оплаты заказа в Telegram-боте.
[вставляешь страницу Quick Start с сайта yookassa.ru/developers/api]
[вставляешь пример Payment.create() из GitHub примеров ЮKassa]
Требования:
- Создать платёж на сумму корзины
- Вернуть пользователю ссылку на оплату
- Обработать callback подтверждения платежа
Текущий код функции:
[вставляешь заглушку из сгенерированного кода]
Результат:
Модель заполнит заглушку рабочим кодом: импорты yookassa, инициализация с shop_id и secret_key, вызов Payment.create() с правильными параметрами (amount, currency="RUB", confirmation={"type": "redirect"}), обработка payment.confirmation.confirmation_url. Если progressive prompting не знал как работать с конкретным API — RAG даёт точный шаблон.
Почему это работает
Слабость LLM: Модель обучена на общих паттернах, но не знает специфики конкретных API, фреймворков, доменных правил. Когда встречает "интегрируй ЮKassa", генерирует правдоподобный, но нерабочий код — потому что не видела актуальную документацию 2024 года в тренировочных данных.
Сильная сторона LLM: Отлично адаптирует шаблоны под новый контекст. Если дать пример Payment.create() с параметрами — сразу поймёт логику и подставит правильные значения из задачи. Это не слепое копирование: модель понимает структуру и переносит паттерн.
Механика методов: - Self-Critique использует способность LLM анализировать код как текст. Работает когда ошибка видна: пропущенная функция, забытая валидация. Не работает когда нужно внешнее знание (как настроить RabbitMQ). - Multi-Model использует специализацию моделей: GPT-5 сильнее в системном дизайне, Claude — в кодогенерации. Разделение снижает двусмысленность требований. - RAG-Assisted подсовывает конкретные примеры и официальные паттерны, превращая "придумай как работает API" в "адаптируй этот рабочий пример".
Рычаги управления: - Количество циклов Self-Critique — можно остановить после 2-3 итераций вместо "пока не скажет готово", экономит время когда понятно что метод не помогает - Модели в Multi-Model — можно заменить GPT-5 на GPT-4o (дешевле) для дизайна, если проект простой - Глубина RAG-материалов — для простых задач достаточно Quick Start, для сложных нужны GitHub-примеры и best practices - Тип документации в RAG — официальные доки (точность) vs Stack Overflow (практичность) vs GitHub (реальный код)
Шаблон промпта
1. Progressive Prompting (базовый)
Шаг 1: Проанализируй требования и составь список задач для проекта: {описание_проекта}
---
Шаг 2: На основе списка задач спроектируй архитектуру: структуру кода, компоненты, API, модели данных.
---
Шаг 3: Создай спецификацию тестов для каждого компонента: какие сценарии проверить, граничные случаи.
---
Шаг 4: Реализуй код проекта по архитектуре и тестам из предыдущих шагов.
Плейсхолдеры: {описание_проекта} — то что обычно пишешь в чат: "Telegram-бот для кофейни с меню, корзиной, оплатой".
2. Self-Critique (самопроверка)
[После генерации кода progressive prompting]
Проверь сгенерированный код внимательно:
- Все задачи из шага 1 реализованы?
- Какие требования пропущены или сделаны частично?
- Где в коде заглушки или TODO?
Перечисли пропуски, затем исправь их.
[Повторяй пока LLM не ответит "всё выполнено" или не увидишь что дальше не улучшается]
3. Multi-Model Collaboration
В ChatGPT (GPT-5):
Шаг 1: Проанализируй требования для проекта: {описание_проекта}
---
Шаг 2: Спроектируй детальную архитектуру:
- Структура компонентов
- API endpoints / интерфейсы
- Модели данных
- Паттерны интеграции с внешними сервисами
Выдай полную спецификацию для передачи другому разработчику.
В Claude (Sonnet 4.5):
Реализуй код по следующей архитектурной спецификации:
[вставить спецификацию из GPT]
Следуй дизайну точно, используй указанные паттерны и структуру.
4. RAG-Assisted (документация в контекст)
Используя документацию и примеры ниже как reference, реализуй {задача}:
[вставить официальную документацию API/фреймворка]
[вставить примеры кода из GitHub / туториалов]
Требования:
{список_конкретных_требований}
Текущий код (если есть):
{код_с_заглушками}
Плейсхолдеры:
- {задача} — "интеграцию оплаты ЮKassa в Telegram-бота"
- Документация — копируешь со страниц Quick Start, API Reference
- Примеры — ищешь на GitHub по запросу "{библиотека} example", берёшь релевантные куски
- {список_конкретных_требований} — конкретика: "создать платёж на сумму корзины, вернуть ссылку, обработать callback"
- {код_с_заглушками} — то что progressive prompting уже сгенерировал с TODO
Где искать материалы для RAG: - Официальные доки: yookassa.ru/developers, python-telegram-bot.readthedocs.io - GitHub: поиск "{название библиотеки} example" → смотришь Issues и Wiki - Туториалы: habr.com, dev.to — фильтруй по свежести (2023-2024)
Decision Framework: что применять когда
1. Диагностируй тип ошибки в сгенерированном коде:
Логическая (Local Logic):
- Пропущенная функция
- Забытая валидация
- Неполная бизнес-логика
→ 1-й выбор: Self-Critique
→ 2-й выбор: RAG-Assisted
Интеграция (External Integration):
- API не подключён
- Сервис не сконфигурирован
- Внешний SDK неправильно использован
→ 1-й выбор: RAG-Assisted
→ 2-й выбор: Multi-Model
Доменная (Domain Knowledge):
- Специфичные правила отрасли
- Бизнес-процессы
- Регуляторные требования
→ 1-й выбор: RAG-Assisted
→ 2-й выбор: Multi-Model
Инфраструктурная (Infrastructure):
- Docker-конфиги
- CI/CD pipeline
- Развёртывание
→ 1-й выбор: RAG-Assisted
→ 2-й выбор: Multi-Model
2. Применяй 1-й выбор. Если не помогло → 2-й выбор.
3. Для критичных задач (продакшн-код) сразу Multi-Model —
slower но надёжнее (100% в 83% случаев).
Как диагностировать: - Открой сгенерированный код - Найди TODO, заглушки, пропущенные части - Задай вопрос: "Это видно в коде или нужно внешнее знание?" - Видно (пропущена функция, нет проверки) → Logic → Self-Critique - Нужно знание (как работает API) → Integration/Domain → RAG-Assisted
Ограничения
⚠️ Требует диагностики: Нужно правильно определить тип ошибки. Если применишь Self-Critique к интеграционной проблеме — потратишь 138 минут впустую (0% улучшения в исследовании).
⚠️ Multi-Model = две подписки: Нужен доступ к GPT-5 (или GPT-4) и Claude Sonnet 4.5. Если только один чат — используй RAG-Assisted как универсальный метод.
⚠️ RAG требует найти материалы: Эффективность зависит от качества документации. Если API малоизвестный, примеров мало — метод даёт меньше. В исследовании RAG не справился с проектом P10 (сложная логика инвентаря) — нет готовых примеров, только общие CRUD-паттерны.
⚠️ Специфично для кода: Framework создан для генерации кода, но принципы универсальны: Self-Critique для устранимых через ревью ошибок, RAG для задач требующих внешнего знания, Multi-Model для критичных случаев.
⚠️ Время vs точность: Self-Critique быстрее всех (138 мин среднее), но работает не везде. Multi-Model медленнее всех (279 мин), но надёжнее. RAG-Assisted — золотая середина (193 мин, лучшая эффективность 31.5 мин/процентный пункт).
Почему метод работает: логика исследования
Исследователи взяли 25 реальных проектов с GitHub (e-commerce, бронирование, микросервисы, инфраструктура) и сравнили direct prompting (один промпт "напиши код") с progressive prompting. Результат: progressive дал 96.9% выполнения против 80.5% у прямого (большой эффект, Cohen's d=1.63, p<0.001), но 8 из 25 проектов (32%) остались недоделаны — 19 задач не реализованы.
Команда классифицировала эти 19 недоделок на 4 типа по характеру пропущенной функциональности (не синтаксис, а что именно забыли): логические ошибки (пропущенная валидация инвентаря), интеграционные (RabbitMQ не настроен), доменные (медправила неизвестны), инфраструктурные (Docker-конфиги отсутствуют). Затем выбрали 6 представительных проектов (покрывают все 4 типа) и прогнали на каждом 3 метода улучшения = 18 экспериментов.
Что удивило: Self-Critique дал ровно 0% улучшения на 3 из 6 проектов (P8, P18, P25) — задачи с внешними интеграциями и доменным знанием. Сколько ни проверяй код итеративно, модель не может вывести как настроить RabbitMQ из пустоты. Зато на проектах P2 и P10 (логические пропуски: забыли API endpoint, пропустили валидацию) Self-Critique дал 100% за 115-155 минут. Это показало чёткую границу метода: работает только на code-reviewable failures — том что видно при ревью кода.
Multi-Model достиг 100% в 5 из 6 проектов (83%), но ни разу не был быстрейшим — среднее 279 минут против 193 у RAG и 138 у Self-Critique. RAG-Assisted показал лучшую универсальность: 100% на всех интеграционных/доменных/инфраструктурных проектах, плюс топовая эффективность — 31.5 минут на процентный пункт улучшения против 47.4 у Multi-Model. Парадокс: RAG и Multi-Model одинаково дали 99.2% среднее, но RAG выиграл 4 из 6 проектов по скорости.
Инсайт для практики: Не существует универсального "лучшего метода". Self-Critique — быстрый нишевый инструмент (работает только на 1 из 4 типов ошибок). RAG-Assisted — универсальный рабочий конь (работает везде с топ-эффективностью). Multi-Model — страховка для критичных задач (самый надёжный, но дорогой по времени). Decision framework — это эмпирическая карта: для каждого типа неудачи указан метод с доказанной эффективностью, не trial-and-error.
Ресурсы
Failure-Aware Enhancements for Large Language Model (LLM) Code Generation: An Empirical Study on Decision Framework
Jianru Shen, Zedong Peng, Lucy Owen, University of Montana
Данные эксперимента: https://doi.org/10.5281/zenodo.17637008