D³ Framework: трёхфазная методология работы с legacy кодом через LLM

ФАЗА 1: DISCOVER
├─ Builder: Исследуй систему → документ "Что есть сейчас"
├─ Reviewer: Критикуй документ → список вопросов и дыр
└─ 🚦 HUMAN GATE: Человек проверяет, дополняет, утверждает контекст

ФАЗА 2: DEFINE  
├─ Builder: Предложи варианты решения → план с trade-offs
├─ Reviewer: Найди риски и скрытые зависимости → критика плана
└─ 🚦 HUMAN GATE: Человек выбирает подход и утверждает план

ФАЗА 3: DELIVER
├─ Builder: Генерируй код/контент → черновик реализации
├─ Reviewer: Проверь на дефекты и стиль → список замечаний
└─ 🚦 HUMAN GATE: Человек финально ревьюит и мержит

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

Задача: Ты работаешь с legacy админкой на Django, которую писали 5 лет назад три разных команды. Нужно добавить экспорт данных в Excel, но непонятно где логика фильтрации живёт, как права доступа проверяются, и какие модели затронуты.

ФАЗА 1: DISCOVER

Промпт Builder:

Я работаю с Django админкой для управления заказами. Код писался 5 лет, документации почти нет. 

Нужно добавить кнопку "Экспорт в Excel" для списка заказов с текущими фильтрами.

Помоги собрать контекст:
1. Какие модели связаны с Order (заказы)?
2. Где живёт логика фильтрации списка заказов?
3. Как проверяются права доступа на просмотр заказов?
4. Есть ли уже экспорты в других частях админки?

Вот структура проекта: [вставить tree output]
Вот модель Order: [вставить код models.py]
Вот view для списка заказов: [вставить код views.py]

Промпт Reviewer:

Вот документ с контекстом, который собрал мой коллега по legacy Django админке.

[вставить ответ Builder]

Твоя задача — найти дыры в исследовании:
- Какие важные вопросы не заданы?
- Где нужны уточнения?
- Какие риски или зависимости могли пропустить?

Представь, что ты senior engineer, который видел как подобные изменения ломали продакшн.

🚦 HUMAN GATE: Ты читаешь оба ответа, проверяешь что контекст полный, дополняешь если нужно, утверждаешь переход к планированию.

ФАЗА 2: DEFINE

Промпт Builder:

Контекст системы утверждён:
[вставить итоговый документ из Discover]

Предложи 2-3 варианта реализации экспорта в Excel:
- Где размещать кнопку?
- Как передавать фильтры в логику экспорта?
- Как обрабатывать большие датасеты (10к+ записей)?
- Какие библиотеки использовать?

Для каждого варианта укажи trade-offs: что быстрее написать, что проще поддерживать, какие риски.

Промпт Reviewer:

Вот три варианта реализации экспорта:
[вставить ответ Builder]

Твоя задача — найти проблемы:
- Какие edge cases не учтены?
- Где могут быть race conditions или проблемы с производительностью?
- Какие зависимости между компонентами пропущены?
- Что может сломаться в существующей функциональности?

Ты архитектор, который отвечает за стабильность прода.

🚦 HUMAN GATE: Ты выбираешь вариант, дополняешь план деталями, утверждаешь реализацию.

ФАЗА 3: DELIVER

Промпт Builder:

План утверждён:
[вставить финальный план]

Напиши код:
1. View для обработки экспорта
2. Функция генерации Excel файла  
3. Добавление кнопки в template
4. Unit-тесты

Используй библиотеку openpyxl, обрабатывай датасеты батчами по 1000 записей.

Промпт Reviewer:

Вот diff с новым кодом:
[вставить код от Builder]

Проверь на:
- Дефекты и баги (SQL injection, memory leaks, race conditions)
- Стиль и соответствие Django conventions
- Отсутствующие error handling
- Проблемы с тестами

Ты делаешь pre-review перед отправкой коллеге на финальный ревью.

🚦 HUMAN GATE: Ты читаешь критику Reviewer, правишь код, тестируешь локально, делаешь финальный коммит.

Результат:

Вы последовательно прошли три фазы, на каждой получили и критику, и генерацию. В итоге — план учитывает реальные риски системы, код проверен на типичные дефекты до human review, а вы держали контроль на каждом шаге вместо того чтобы потом распутывать AI-код с багами.

LLM плохо справляются с накоплением контекста в длинных задачах. Если попросить "реши задачу от начала до конца", модель может пропустить критические детали на ранних этапах, которые выстрелят багами в конце. К моменту когда ты обнаружишь проблему, придётся переписывать всё, потому что фундамент был неверным. Исследование показывает: на сложных задачах AI без структуры даёт −19% к скорости из-за cognitive load на исправление ошибок.

LLM отлично генерируют варианты, но плохо критикуют сами себя. Builder в режиме "предложи решение" оптимизирован на креативность и скорость, но не на скептицизм. Reviewer с явной установкой "найди дыры" работает в другом режиме — ищет риски, edge cases, скрытые зависимости. Разделение ролей усиливает обе стороны.

Human Gates гарантируют, что человек остаётся decision maker. Вместо "AI написал код → я исправляю баги" получается "AI предлагает → я проверяю и утверждаю → AI реализует мой выбор → я финально ревьюлю". Это дороже по числу запросов, но дешевле по времени, потому что исправлять плохой AI-код дороже, чем проверять хороший план.

Фазирование снижает когнитивную нагрузку. Вместо "держи в голове весь проект сразу" вы фокусируетесь: сначала только на понимании системы, потом только на проектировании, потом только на реализации. Это соответствует тому, как работают опытные инженеры, но AI помогает быстрее проходить каждую фазу.

Рычаги управления:

• Число агентов: два (Builder + Reviewer) — оптимум. Можно добавить третьего (Security Reviewer, Performance Reviewer), но это дороже по токенам.
• Детализация Human Gates: для простых задач можно объединить Discover+Define в одну фазу. Для критичных систем — добавить промежуточные gates внутри фаз.
• Глубина критики Reviewer: добавь "представь что это код, который сломает продакшн в 3 часа ночи" для острее критики. Убери для более мягкой обратной связи.
• Формат документов между фазами: для себя — bullet points достаточно. Для команды — попроси Builder оформить как Design Doc с секциями.

Промпт Builder:

Я работаю с {описание системы}. Контекст: {что известно, что нет}.

Задача: {что нужно сделать}.

Помоги собрать полный контекст:
1. {вопрос про архитектуру}
2. {вопрос про зависимости}
3. {вопрос про риски}
4. {вопрос про похожие решения в системе}

Вот материалы:
{код, структура, документы}

Результат: структурированный документ с ответами.

Промпт Reviewer:

Вот документ с контекстом по задаче:
[вставить ответ Builder]

Твоя задача — критика исследования:
- Какие важные вопросы не заданы?
- Где нужны уточнения?
- Какие риски или зависимости пропущены?

Ты senior engineer с опытом работы в {домен системы}.

🚦 HUMAN GATE: Проверь, дополни, утверди контекст.

Промпт Builder:

Контекст утверждён:
[итоговый документ из Discover]

Предложи 2-3 варианта реализации {задача}:
- {аспект 1: где размещать, как интегрировать}
- {аспект 2: технологии, библиотеки}
- {аспект 3: edge cases, производительность}

Для каждого варианта: trade-offs, сложность, риски.

Промпт Reviewer:

Вот варианты решения:
[вставить ответ Builder]

Найди проблемы:
- Какие edge cases не учтены?
- Где проблемы с производительностью/безопасностью?
- Какие зависимости пропущены?
- Что может сломаться?

Ты архитектор, отвечающий за стабильность системы.

🚦 HUMAN GATE: Выбери вариант, дополни план, утверди.

Промпт Builder:

План утверждён:
[финальный план]

Реализуй:
1. {компонент 1}
2. {компонент 2}
3. {тесты}

Требования:
- {технические детали}
- {стиль, conventions}

Промпт Reviewer:

Вот код:
[вставить код от Builder]

Pre-review:
- Дефекты и баги
- Стиль и conventions
- Error handling
- Проблемы с тестами

Ты делаешь проверку перед отправкой коллеге на финальный ревью.

🚦 HUMAN GATE: Проверь критику, доработай код, закоммить.

Плейсхолдеры: - {описание системы} — кратко: "Django админка 5 лет, 3 команды, техдолг" - {задача} — конкретная цель: "добавить экспорт в Excel" - {вопрос про X} — детализируй под свою ситуацию - {домен системы} — e-commerce, fintech, legacy enterprise

🚀 Быстрый старт — вставь в чат:

Вот методология D³ для работы со сложными системами через AI. 
Адаптируй под мою задачу: [твоя задача]. 

Задавай вопросы чтобы заполнить все три фазы: Discover, Define, Deliver.

[вставить шаблон выше]

LLM спросит про систему, задачу, материалы — чтобы заполнить Discover фазу. Она возьмёт структуру фаз и ролей (Builder/Reviewer) и адаптирует под вашу ситуацию.

⚠️ Подходит для сложных задач: Методология избыточна для простых задач ("напиши функцию сортировки массива"). Оверхед трёх фаз не окупится. D³ — для legacy систем, многокомпонентных изменений, задач с высокими рисками.

⚠️ Требует дисциплины: Human Gates работают только если вы реально останавливаетесь и проверяете каждую фазу. Если пропускать gates и доверять AI — получите те же проблемы что и при работе "в лоб".

⚠️ Дороже по токенам: Два агента на каждой фазе = больше запросов. Для задач где скорость генерации важнее качества плана — может быть невыгодно.

⚠️ Self-reported данные: Исследование основано на самооценке участников, не на контролируемых экспериментах. 26.9% productivity gain — это ощущения инженеров, не измерение task completion time. Воспринимайте как сигнал о practitioner sentiment, не как доказанный causal effect.

Автор (бывший Head of Engineering - AI в Amazon) провёл двухфазное исследование с 52 опытными инженерами (60% с 6+ годами опыта, 63% из компаний с 3000+ разработчиков). 84% работали в brownfield или смешанных средах — как раз те, кому legacy системы знакомы не понаслышке.

Phase I (Baseline): измерили как инженеры используют AI "в лоб" без методологии. Результат: 68% не находили AI полезным для сложных задач. Это подтверждает Brownfield Paradox — без структуры AI в legacy системах скорее мешает чем помогает.

Intervention: всех познакомили с D³ Framework, объяснили принципы разделения на фазы и использования Builder/Reviewer агентов.

Phase II (спустя 4 недели): повторный опрос тех, кто реально применил методологию на рабочих задачах (N=52).

Результаты самооценки: - 26.9% productivity improvement — участники ощущали что делают задачи быстрее - 77% снизили cognitive load — меньше ментального напряжения от отслеживания всех деталей - 83% тратили меньше времени на исправление AI-кода — потому что Human Gates отлавливали проблемы раньше

Почему результаты важны несмотря на self-reported природу: исследование показывает что структура workflow меняет восприятие инженеров от "AI бесполезен" (68%) к "AI реально помогает" (77% снижение cognitive load). Это не controlled experiment с точными метриками времени, но это сильный сигнал что дисциплина применения критичнее чем сырые возможности модели.

Инструменты: Участники использовали разные LLM (62% Claude, 19% ChatGPT, 19% Gemini), но методология работала независимо от модели — это подтверждает что D³ про принципы промптинга, не про специфику конкретной LLM.

Что удивило: самый большой выигрыш был не в скорости написания кода, а в снижении времени на исправления (83%). Это перекликается с данными Becker et al. про −19% slowdown на сложных задачах: AI быстро пишет, но медленно исправляется. D³ переворачивает это — медленнее генерирует (три фазы), но быстрее доходит до правильного результата.

🔧 Техника: свернуть Discover+Define → одна фаза для средних задач

Если задача не критична (добавить новый endpoint в знакомый сервис, написать утилиту), полноценный Discover может быть избыточен. Объедини:

Промпт Builder:

Я работаю с {система}. Задача: {задача}.

Шаг 1: Собери контекст и риски
Шаг 2: Предложи вариант реализации с trade-offs

Вот материалы: {код, структура}

Промпт Reviewer:

Вот контекст + план:
[ответ Builder]

Критикуй:
- Пропущенные риски в контексте
- Проблемы в плане

Ты senior engineer.

→ Экономия одного запроса, но сохранение двухагентной структуры.

🔧 Техника: добавить третьего агента (Security/Performance Reviewer) для критичных систем

Если задача касается платежей, персональных данных, высоконагруженных API — добавь специализированного ревьюера:

Промпт Security Reviewer (после основного Reviewer в Define):

Вот план реализации:
[план от Builder + критика от Reviewer]

Проверь только security:
- Какие векторы атак?
- Где утечки данных?
- Какие best practices нарушены?

Ты security engineer с OWASP и опытом incident response.

→ Более острые проверки по узкой области, не растворённые в общей критике.

🔧 Техника: асинхронный D³ для распределённых команд

Если вы работаете в команде через async communication (документы, Notion, Linear):

1. Discover: один инженер делает фазу, записывает в документ
2. Human Gate: коллеги async комментируют в документе
3. Define: Builder генерирует план в том же документе, Reviewer критикует
4. Human Gate: async обсуждение в комментариях, выбор варианта
5. Deliver: реализация + Reviewer pre-review перед PR

→ D³ становится структурой async collaboration document, а не набором промптов в чате одного человека.

"Beyond Greenfield: The D³ Framework for AI-Driven Productivity in Brownfield Engineering"

Krishna Kumaar Sharma (Formerly Head of Engineering - AI, Amazon)

Упомянутые исследования: - Harvey et al. — 2025 DORA report (90% AI adoption at work) - Deniz et al. — McKinsey research (2x task completion speed with AI) - Ziegler et al. — GitHub Copilot study (+55% speedup on simple tasks) - Becker et al. (METR) — Experienced developers study (−19% slowdown on complex tasks) - Sun et al. — Automated code review with LLMs (60-75% issue detection) - Forsgren et al. — Documentation ROI longitudinal study (6-12 months payback) - Harding (GitClear) — AI-generated code review analysis (1.3x more review rounds)