Исследование, План, Реализация (RPI)

Вы бывали здесь. Просите AI “рефакторить этот модуль аутентификации”, и он генерирует 500 строк кода с библиотеками, которых у вас нет, создаёт методы, которые не существуют, и решает проблему, которой у вас нет. Три часа спустя вы распутываете галлюцинации и думаете, не проще ли было сделать самому.

AI не сломан. Вы просите его читать ваши мысли, не давая структуры.

RPI (Исследование → План → Реализация) исправляет это. Вместо прыжка напрямую к генерации кода, вы разбиваете работу на три сфокусированные фазы со встроенной валидацией. AI исследует что существует, планирует изменение систематически, затем выполняет механически. Это медленнее, чем “просто сделай” — и в этом смысл.

Проблема прямого промптинга

Когда вы просите AI-агента реализовать что-то без структуры, вы играете в азартную игру на нескольких вещах сразу:

• AI правильно понимает ваше намерение
• Он находит весь релевантный код и паттерны
• Он принимает архитектурные решения, с которыми вы бы согласились
• Он не галлюцинирует API или библиотеки
• Он остаётся в рамках scope

Что происходит на самом деле:

• Overflow контекста: При слишком большом количестве информации AI теряет фокус.
• Галлюцинации: AI выдумывает код, который не существует.
• Решена неправильная проблема: AI неправильно понимает требования.
• Scope creep: Работа расширяется за пределы предполагаемых границ.
• Нетестируемый код: У вас нет чётких критериев успеха.

Инсайт: без структуры даже блестящие AI-ассистенты становятся дорогими генераторами случайного кода.

Что RPI из себя представляет

RPI — это трёхфазный фреймворк с валидационными шлюзами между каждой фазой. Думайте о нём как о превращении вашего AI из стажера в опытного разработчика с GPS.

Фазы:

1. Исследование: Постройте контекст. Документируйте что существует сегодня — без мнений, без предложений.
2. План: Спроектируйте изменение. Используйте поэтапный подход с атомарными задачами и критериями успеха.
3. Реализация. Выполняйте механически. Следуйте плану и верифицируйте после каждой фазы.

Основные принципы:

• Одна цель за сессию: Держите LLM лазерно сфокусированным.
• Валидация перед продвижением: Используйте оценочные шкалы для верификации готовности.
• Человеческое суждение сохранено: AI не принимает крупных решений без валидации.
• Управление контекстом: Начинайте свежую сессию для каждой фазы.

Фреймворк торгует скорость на ясность, предсказуемость и корректность. Вы потратите больше времени впереди, но гораздо меньше времени на отладку галлюцинаций и исправление архитектурных ошибок.

Фаза 1: Исследование

Фаза исследования строит контекст и понимание. Вы документируете что существует сегодня — ничего больше.

Строгие правила:

• Документируйте что существует
• НЕ предлагайте изменения
• НЕ критикуйте
• НЕ планируйте
• Базируйте всё на фактах, не на предположениях

В goose:

/research "look through the codebase and research how
the LLM Tool Discovery is implemented"

Это запускает три параллельных под-агента:

Под-агент	Назначение
find_files	Использует локатор кодовой базы для поиска релевантных файлов
analyze_code	Полностью читает файлы и документирует как они работают
find_patterns	Ищет похожие фичи или конвенции в репо

Выход: Структурированный исследовательский документ в thoughts/research/YYYY-MM-DD-HHmm-topic.md

Документ включает git-метаданные, ссылки на файлы и строки, описания потоков, ключевые компоненты, открытые вопросы и техническую карту фичи как она существует сегодня.

Обратный промптинг

Вот где становится интересно. Вместо того чтобы вы объясняли всё заранее, AI задаёт вам уточняющие вопросы по одному:

• “Это должно работать из файлового менеджера или dashboard?”
• “Какие ограничения на типы файлов?”
• “Что происходит с общими файлами?”

Это раскрывает понимание, которое вы не учитывали, и предотвращает распространение неверных предположений через весь рабочий процесс.

Валидация исследования: шкала FAR

Перед переходом к планированию, валидируйте своё исследование по критериям FAR:

Критерий	Описание	Что это предотвращает
Factual	Базируется на реальном коде, не на предположениях	Галлюцинации
Actionable	Вы точно знаете что строить	Нечёткие требования
Relevant	Решает реальную потребность пользователя	Решена неправильная проблема

Критично: Человек должен просмотреть исследовательский документ перед продвижением. Это информирует всё последующее.

Фаза 2: План

Фаза планирования переводит исследование в поэтапный план реализации. Вы проектируете изменение с чёткими критериями успеха.

В goose:

/plan a removal of the Tool Selection Strategy feature

Процесс AI:

1. Читает исследовательский документ из предыдущей фазы
2. Askит уточняющие вопросы (полное удаление vs декомпозиция? поведение очистки конфига?)
3. Представляет варианты дизайна там, где существуют несколько подходов
4. Производит поэтапный план реализации

Выход: Детализированный план в thoughts/plans/YYYY-MM-DD-HHmm-description.md

План включает:

• Явные фазы (например, 10 фаз)
• Точные пути к файлам
• Сниппеты кода показывающие что менять
• Автоматизированные критерии успеха
• Ручные шаги верификации
• Чекбоксы для отслеживания прогресса
• Атомарные задачи на фазу

Почему атомарные задачи важны

Каждая задача должна быть единицей работы одной сфокусированной единицы — один вызов команды или редактирование файла. Это держит AI на треке с простыми инструкциями, делает прогресс легко верифицируемым, предотвращает переполнение контекста и позволяет восстановление если контекстное окно заполняется.

План должен быть достаточно явным, чтобы кто-то другой (или свежая AI-сессия) мог выполнить его без дополнительного контекста.

Валидация планов: шкала FACTS

Валидируйте каждую задачу по критериям FACTS:

Критерий	Описание	Что это предотвращает
Feasible	Может быть реально сделано с доступными инструментами/APIs	Невозможные задачи
Atomic	Единица, сфокусированная единица работы	Переполнение контекста, scope creep
Clear	Недвусмысленные инструкции	Неправильное толкование
Testable	Имеет чёткие критерии успеха	Нетестируемый код
Scoped	Правильно ограничено	Неконтролируемое выполнение

Фаза 3: Реализация

Фаза реализации выполняет план шаг за шагом с верификацией. Это должно ощущаться намеренно скучным и механическим. Если ощущается творчески — чего-то не хватает на предыдущем этапе.

В goose:

/implement thoughts/plans/2025-12-23-remove-tool-selection-strategy.md

Процесс AI:

1. Полностью читает план
2. Выполняет фазы по порядку
3. Запускает верификацию после каждой фазы
4. Обновляет чекбоксы напрямую в файле плана по ходу

Опции цикла обратной связи

Выбирайте уровень контроля на основе уверенности в плане:

Тип цикла	Когда использовать	Уровень контроля
Повальная валидация задач	Макогда нужен максимальный контроль	Высокий — валидируйте после каждой атомарной задачи
Повальная валидация фаз	Баланс скорости и контроля	Средний — валидируйте после завершения фазы
Полная валидация плана	Высокая уверенность в плане	Низкий — выполняйте всё, валидируйте в конце

Верификационные шлюзы

Каждая фаза должна пройти качественные шлюзы:

• Тесты должны пройти
• Сборки должны успешно завершиться
• Линтеры должны пройти
• Регрессий не введено

Если любой шлюз падает, реализация приостанавливается. Исправьте проблему перед продвижением.

Механизм восстановления

Если контекстное окно заполняется посреди реализации, чекбоксы в плане позволяют AI сжать и продолжить точно с того места, где остановился. Вот почему атомарные задачи и отслеживание прогресса важны — они позволяют элегантное восстановление.

Опционально: Итерация

Иногда планы нуждаются в корректировке после ревью или во время реализации.

В goose:

/iterate "plan path" + feedback

Процесс AI:

1. Читает существующий план
2. Исследует только то, что нужно переосмыслить
3. Предлагает точечные обновления
4. Хирургически редактирует план (не начинает заново)

Это позволяет уточнение без отбрасывания хорошей работы. Изменённые секции должны снова пройти FACTS-валидацию.

Структура файлов

Все выходные данные RPI живут в предсказуемых местах:

thoughts/
├── research/
│   └── YYYY-MM-DD-HHmm-topic.md
└── plans/
    └── YYYY-MM-DD-HHmm-description.md

Реальный пример

Давайте пройдём через реальное выполнение RPI: удаление фичи “Tool Selection Strategy” из крупной кодовой базы.

Сложность:

• Затрагивает 32 файла
• Касается Rust core-кода
• Влияет на TypeScript
• Изменяет конфигурацию
• Модифицирует тесты
• Обновляет документацию

Фаза исследования (9 минут)

Начали с /research "LLM Tool Discovery". Поняли что scope слишком широкий — скорректировали курс и перезапустили: /research "Tool Selection Strategy feature specifically".

Результат: детализированная техническая карта фичи.

Человеческое ревью: валидировали точность исследования перед продвижением.

Фаза планирования (4 минуты)

Запустили /plan a removal of the Tool Selection Strategy feature.

AI задал уточняющие вопросы:

• Полное удаление или декомпозиция?
• Как должно вести себя очистка конфига?
• Должны ли артефакты регенерироваться?
• Где живут связанные тесты?

Представил варианты дизайна. Сгенерировал 10-фазный план с атомарными задачами.

Человеческое ревью: валидировали осуществимость плана.

Фаза реализации (39 минут)

Запустили /implement thoughts/plans/2025-12-23-remove-tool-selection-strategy.md.

AI выполнил механически фазу за фазой. Контекстное окно заполнилось на полпути — AI сжал и возобновил с чекбоксов.

Человеческая активность во время этой фазы: “Я уснул.” Намеренно скучно и надёжно.

Результаты

• Общее время: 52 минуты (включая AI-работу, тестирование, человеческие Q&A)
• PR подан: Сборка прошла с первой попытки
• Агент код-ревью: Ноль комментариев
• Качество: Отличное

Сравнение:

Подход	Результат
Без AI	Несколько часов ручной работы
AI без RPI	Дрифт, баги, циклы доработки
RPI	Медленнее прямой реализации, но предсказуемо и корректно

Когда использовать RPI

Идеальные сценарии

Сложные задачи, затрагивающие несколько файлов:

• Рефакторинги
• Миграции
• Добавления фичей
• Крупные обновления
• Очистка после инцидентов
• Переработки документации

Характеристики, сигнализирующие что RPI стоит того:

• Сложная интеграция
• Множественные точки соприкосновения
• Высокие последствия ошибок
• Нужда в систематическом подходе
• Требуется чёткая валидация

Когда пропустить

Простые, базовые задачи:

• Изменения в одном файле
• Очевидные исправления багов
• Простые добавления фичей
• Быстрые прототипы

RPI намеренно медленнее. Накладные расходы валидации не стоят того для тривиальной работы.

Почему RPI работает

Предотвращает распространённые AI-неудачи

Режим неудачи	Как RPI предотвращает это
Переполнение контекста	Атомарные задачи держат работу сфокусированной и ограниченной
Галлюцинации	FAR-валидация требует фактических доказательств
Решена неправильная проблема	Исследование валидирует релевантность перед планированием
Нетестируемый код	FACTS-валидация обеспечивает чёткие критерии успеха
Scope creep	Атомарные задачи и валидационные шлюзы держат границы

Использует сильные стороны AI

• Паттерн-матчинг: AI превосходен в поиске похожего кода
• Генерация кода: AI эффективно пишет boilerplate
• Систематическое выполнение: AI идеально следует чеклистам

Сохраняет человеческое суждение

• Люди занимаются стратегией и валидацией
• Люди принимают архитектурные решения
• Люди верифицируют релевантность и корректность
• AI не принимает крупных решений без валидации

Встроенные качественные шлюзы

Каждая фаза имеет контрольные точки:

• Исследование: FAR-валидация
• План: FACTS-валидация
• Реализация: Тесты, сборки, линты должны пройти

Управление контекстом

• Свежие сессии на фазу — LLM остаётся сфокусированным
• Явные передачи — план имеет весь контекст для реализации
• Система контрольных точек — можно продолжить после прерываний

Интеграция с AI-инструментами

Не зависит от инструментов

RPI работает с любым AI-кодинг ассистентом:

• Claude
• GitHub Copilot
• Cursor
• OpenAI
• Gemini
• Любым агентом, который может следовать структурированным промптам

Фреймворк о структуре, а не о конкретном инструменте.

Реализация в goose

Инструмент goose от Block обеспечивает встроенную поддержку RPI со слэш-командами:

Команда	Назначение
/research "topic"	Фаза исследования
/plan "feature/task"	Фаза планирования
/implement "plan path"	Фаза реализации
/iterate "plan path" + feedback	Уточнение плана

Используемые рецепты:

• rpi-codebase-locator — Найти релевантные файлы
• rpi-codebase-analyzer — Анализировать код
• rpi-pattern-finder — Найти паттерны
• rpi-create-plan — Сгенерировать план
• rpi-implement-plan — Выполнить реализацию
• rpi-iterate-plan — Уточнить план

Без goose

Вы можете реализовать RPI вручную:

1. Создайте директории thoughts/research/ и thoughts/plans/
2. Используйте структурированные промпты для каждой фазы
3. Валидируйте вручную по шкалам FAR и FACTS
4. Отслеживайте прогресс с чекбоксами в markdown

Инструментарий помогает, но фреймворк работает без него.

Распространённые паттерны

Добавление фичи

1. /research "current authentication system"
2. /plan "add OAuth2 support"
3. /implement [plan path]

Исправление бага

1. /research "payment processing error handling"
2. /plan "fix race condition in transaction commits"
3. /implement [plan path]

Рефакторинг

1. /research "current data access layer"
2. /plan "migrate from ORM to raw SQL"
3. /implement [plan path]
4. /iterate [plan path] "need to handle edge case in migrations"

Миграция

1. /research "React class components in codebase"
2. /plan "convert to functional components with hooks"
3. /implement [plan path]

Сдвиг в навыках

Традиционный AI-кодинг спрашивает: “Как мне написать идеальный промпт?”

RPI спрашивает: “Как мне структурировать работу чтобы AI мог надёжно выполнять?”

Вы перестаёте направлять AI пошагово и начинаете проектировать рабочие процессы, которые сходятся к корректным решениям. Работа AI — систематическое выполнение. Ваша работа — определить, как выглядит “готово” и валидировать на контрольных точках.

Сдвиг в мышлении:

• От: “AI, построй эту фичу”
• К: “AI, помоги мне понять что существует, спланируй изменение систематически, затем выполни с валидацией”

Ресурсы

Официальные

• ЧИТАТЬ: Research → Plan → Implement Паттерн | goose — Официальный туториал с демонстрациями
• ЧИТАТЬ: Introducing the RPI Strategy — Пост блога создателя, объясняющий подход

Сообщество

• СЛУШАТЬ: The RPI workflow - Build Wiz AI Show (Podcast) — Аудио-обсуждение продвинутого AI-кодинга

Истоки

Изначально вдохновлено видео на YouTube, которое породило идею систематической AI-разработки. Разработано и популяризировано HumanLayer (создатели фреймворка), командой goose в Block (реализация и инструментарий) и Patrick Robinson (документация и евангелизм).

---

Используете RPI в продакшене? Поделитесь своим опытом—что сработало, что нет и что вы узнали.