TL;DR
MEP — трёхфазная методология подготовки контекста перед запуском AI на сложную задачу. Суть: вместо того чтобы сразу бросать ИИ в работу и потом бесконечно править, сначала создаёшь три артефакта — брифинг-документ с экспертизой, детальную спецификацию с обоснованием, декомпозицию задач с зависимостями — и только потом даёшь старт.
Когда просишь Claude написать большой сложный документ "в лоб", получаешь обобщённый результат. Модель генерирует по паттернам — но у неё нет твоей тактической экспертизы: что работает в твоём контексте, что нельзя, почему именно такой формат, а не другой. Это неявное знание ("вроде и так понятно, но попробуй объясни") — именно оно теряется. Результат: раунды правок, которые съедают больше времени, чем сама генерация.
MEP решает задачу переносом согласования с "после" на "до": в Фазе 1 ты записываешь всё что знаешь (включая неочевидное), в Фазе 2 уточняешь детали через диалог с AI и кодируешь "почему", в Фазе 3 разбиваешь работу на чёткие блоки с критериями готовности. Три шага — три артефакта — минимум итераций при выполнении.
Схема метода
ФАЗ 1 — Брифинг (выполняешь сам, отдельный документ)
→ Записываешь: экспертизу, ценности, ограничения, что НЕ делать
→ Артефакт: брифинг-документ (любой формат)
ФАЗ 2 — Спецификация (диалог с AI)
→ AI задаёт вопросы, ты отвечаешь, вместе фиксируете ЧТО и ПОЧЕМУ
→ Артефакт: дизайн-документ с обоснованием каждого решения
ФАЗ 3 — Декомпозиция (диалог с AI)
→ Спецификация → список задач с зависимостями и критериями готовности
→ Артефакт: упорядоченный список блоков
ВЫПОЛНЕНИЕ — AI работает по задачам последовательно (или параллельно)
→ Каждый блок — независимая чёткая единица, не требует уточнений
Фазы 1–3 — подготовка, выполнение — последнее. Ни строчки работы до завершения всех трёх фаз.
Пример применения
Задача: Владелец небольшой IT-студии хочет попросить Claude написать полноценную стратегию вывода нового SaaS-продукта на рынок. Запускает в лоб — получает шаблонный текст из серии "определите целевую аудиторию". Тратит час на правки. Применяет MEP.
Промпт (Фаза 1 — пишешь сам, вставляешь в начало сессии):
# Брифинг: стратегия вывода продукта на рынок
## Что я знаю о своём продукте и рынке:
Мы делаем CRM для небольших стоматологических клиник (1–5 кресел).
Ключевая боль: администраторы тратят 3–4 часа в день на обзвон пациентов
для напоминаний и перезаписи. Наш продукт автоматизирует это через WhatsApp.
Рынок: Россия + СНГ. Конкуренты есть, но заточены под крупные сети.
Маленькие клиники — их слепое пятно.
## Мои ценности и приоритеты:
Главное — скорость до первых 50 платящих клиентов.
Не хочу гнаться за узнаваемостью бренда на этом этапе.
Метрика успеха: MRR 500к рублей за 6 месяцев.
## Что НЕ нужно делать:
- Не нужен контент-маркетинг и SEO (долго)
- Не нужны маркетплейсы и агрегаторы
- Без инвестиций — только bootstrapped-каналы
## Ограничения:
Команда 3 человека. Бюджет на маркетинг — 100к рублей суммарно.
Основной канал продаж пока — я сам (founder-led sales).
Промпт (Фаза 2 — отдельное сообщение после брифинга):
Используй этот брифинг и помоги мне создать детальную спецификацию
стратегии вывода на рынок.
Задавай уточняющие вопросы — по одному, жди ответа.
По каждому решению фиксируй не только ЧТО, но и ПОЧЕМУ именно так.
Явно запиши что исключаем и обоснование.
Когда получим полную картину — сформируй финальный документ спецификации.
Промпт (Фаза 3 — после спецификации):
Используя спецификацию выше, разбей стратегию на отдельные блоки работ.
Для каждого блока укажи:
- Что конкретно делать (не абстрактно)
- Что должно быть готово до него (зависимости)
- Как понять что блок выполнен (критерий готовности)
Сортируй по порядку выполнения. Блоки должны быть независимыми —
каждый можно выполнять не возвращаясь к уточнениям.
Результат:
После Фазы 1 у тебя есть документ, который можно вставлять в любой новый чат как системный контекст. После Фазы 2 — детальная спецификация с зафиксированными "почему": почему cold outreach, а не реклама; почему стоматология; почему WhatsApp. После Фазы 3 — упорядоченный список блоков (например: "сформировать базу стоматологий в 5 городах → написать скрипт звонка → запустить пилот с 10 клиниками → ..."). Каждый блок можно отдать AI как отдельную задачу без повторных объяснений.
Почему это работает
Слабость LLM — модель генерирует текст по паттернам, выученным из общих данных. У неё нет твоей тактической экспертизы: что работает именно в твоём контексте, какие ограничения реальны, почему ты принял конкретные решения. Без этого она заполняет пробелы усреднёнными предположениями. Результат — шаблонный вывод.
Сильная сторона LLM — модель хорошо следует явным ограничениям и структурированным инструкциям. Чем богаче контекст и чётче границы, тем точнее вывод. Если ты зафиксировал "почему НЕТ SEO", модель не будет предлагать SEO.
Как MEP использует это — вместо того чтобы надеяться что модель сама угадает твой контекст, ты принудительно экстернализируешь неявное знание. Брифинг-документ заставляет тебя самого артикулировать то, что "и так понятно". Спецификация с "почему" даёт модели логику для самостоятельных микрорешений без эскалации. Декомпозиция убирает двусмысленность в каждом блоке.
Рычаги управления: - Глубина брифинга → чем больше неявного знания записал, тем меньше правок при выполнении - "Что НЕ делать" → явные исключения работают сильнее чем инструкции что включать - Размер блоков в Фазе 3 → мелкие блоки (15–30 мин работы) = меньше отклонений; крупные = риск потерять нить - Критерии готовности → без них AI сам решает когда остановиться, часто раньше нужного
Шаблон промпта
# MEP: Подготовка для {название_задачи}
---
## ФАЗА 1: БРИФИНГ (заполняешь сам)
### Что я знаю о домене (неочевидное, тактическая экспертиза):
{запиши всё что "и так понятно" — именно это теряется без брифинга}
### Мои ценности и приоритеты:
{что критично, в каком порядке приоритеты, главная метрика успеха}
### Что явно НЕ входит в скоуп:
{перечисли исключения — это важнее списка того что нужно}
### Контекст и ограничения:
{аудитория, бюджет, сроки, ресурсы, формат}
---
## ФАЗА 2: СПЕЦИФИКАЦИЯ (вставь после брифинга и отправь)
Используй брифинг выше. Помоги создать детальную спецификацию для {название_задачи}.
Задавай уточняющие вопросы по одному, жди ответа.
По каждому решению фиксируй ЧТО и ПОЧЕМУ.
Явно запиши что исключаем и обоснование исключений.
Когда картина полная — оформи финальный документ спецификации.
---
## ФАЗА 3: ДЕКОМПОЗИЦИЯ (вставь спецификацию + эту инструкцию)
Используя спецификацию, разбей {название_задачи} на блоки работ.
Целевой размер блока: {размер_блока} (например: "30 минут работы" или "один раздел документа").
Для каждого блока:
- Конкретное действие (без абстракций)
- Зависимости (что должно быть готово до)
- Критерий готовности (как понять что выполнено)
Сортируй по порядку выполнения.
Каждый блок должен быть самодостаточным — без возврата к уточнениям.
Что подставлять:
- {название_задачи} — конкретная задача: "маркетинговая стратегия", "политика онбординга", "питч для инвесторов"
- {размер_блока} — желаемая гранулярность: "15–30 минут", "один раздел", "один экран/страница"
- В блоке ФАЗА 1 — пиши свободно, не бойся "очевидного". Именно неочевидное-для-AI очевидное-для-тебя и нужно записать.
🚀 Быстрый старт — вставь в чат:
Вот шаблон MEP-методологии. Адаптируй под мою задачу: {твоя задача}.
Начни с вопросов для заполнения Фазы 1 — задавай по одному, жди ответа.
[вставить шаблон выше]
LLM спросит о твоей экспертизе, ограничениях и исключениях — потому что без этого она не может построить брифинг, который действительно отражает твой контекст. Она возьмёт структуру шаблона и адаптирует под специфику задачи.
Ограничения
⚠️ Размер задачи: MEP оправдывает себя только на сложных, многосоставных задачах. Для простых запросов (написать письмо, ответить на вопрос) overhead подготовки не окупается.
⚠️ Один кейс: Эмпирическая база — один хакатон, один участник, без контрольной группы. Соотношение 5.7:1 (подготовка vs. выполнение) и "почти нулевой" рефакторинг — наблюдения, не доказанный эффект.
⚠️ Экспертиза оператора: Качество брифинга напрямую зависит от твоей предметной экспертизы. Если ты сам не знаешь "почему" — модель не восполнит этот пробел.
⚠️ Параллельные агенты: Самая мощная часть MEP (параллельный запуск нескольких AI одновременно) требует технической настройки. В обычном чате — только последовательное выполнение.
⚠️ Фаза 2 требует терпения: Спецификация через диалог — это реальный разговор с несколькими раундами. Если торопиться и пропускать вопросы, теряется качество документа и смысл подготовки.
Как исследовали
Исследование — это скорее описание кейса, чем контролируемый эксперимент. Автор, Эндрю Зиглер из LinearB, применил методологию MEP во время реального соревновательного хакатона в январе 2026 года: 12 команд, 5 часов, задача — построить рабочий прототип на базе архива The Atlantic, приз $5,000.
Пока большинство команд начали писать код в первые 15 минут, автор потратил 2 часа на подготовку: создал 10 документов суммарно на 9 386 слов (включая конкурентный анализ и — важная деталь — расшифровку собственных педагогических взглядов, которые иначе остались бы в голове), создал детальную спецификацию и разбил работу на 64 блока-задачи.
Результат: платформа из 43 файлов и 8 496 строк кода, развёрнутая в продакшен за 184 минуты с 4 параллельными агентами. Медианное время закрытия одного блока — 5.9 минут. Что важно: баги при деплое были интеграционные и стилистические (обрезка контента API, иконка в браузере) — не архитектурные. Это и есть ключевой аргумент: богатый контекст на входе = правильная архитектура сразу.
Единственная честная оговорка от самого автора: он — специалист и в разработке, и в педагогике. Непонятно, сколько успеха дала методология, а сколько — его личная экспертиза. Из 12 команд только его команда запускала параллельных агентов — остальные работали линейно.
Адаптации и экстраполяции
🔧 Фаза 1 как постоянный "контекстный документ" для регулярных задач
Если ты регулярно работаешь с AI над похожими задачами (например, всегда пишешь контент для одного бренда или постоянно делаешь анализы для одного клиента) — создай один раз брифинг-документ и вставляй его в начало каждой сессии.
# Контекст [название проекта/клиента] — вставляй в начало каждого чата
## О проекте:
{постоянная информация — продукт, аудитория, позиционирование}
## Мой голос и стиль:
{тональность, что нельзя писать, любимые формулировки}
## Что всегда исключать:
{постоянные табу для этого контекста}
## Текущий приоритет:
{можно менять при каждой вставке}
Это не создаёт новый метод — это применяет принцип Фазы 1 как постоянный артефакт вместо разового.
🔧 "Критерий готовности" как инструмент против незавершённого вывода
Принцип декомпозиции из Фазы 3 можно использовать изолированно — даже без полного MEP. Добавь к любому промпту явный критерий готовности:
[твоё задание]
Критерий готовности: {опиши конкретный признак завершённого результата}.
Не останавливайся пока критерий не выполнен.
Примеры критериев: - "Все 5 разделов заполнены конкретными примерами, не абстрактными рекомендациями" - "Каждый пункт содержит действие, не только наблюдение" - "Итого: ровно 7 блоков, каждый с заголовком и 3–5 предложениями"
Ресурсы
Работа: "Mise en Place for Agentic Coding: Deliberate Preparation as Context Engineering Methodology" — Andrew Zigler, LinearB, Los Angeles
Артефакты (CC-BY 4.0 / MIT): https://doi.org/10.5281/zenodo.19868258 — промпты, конфиги агентов, шаблоны планирования (CLAUDE.md, схема beads, шаблоны)
Ключевые отсылки из исследования: - Термин "vibe coding" — Andrej Karpathy (2025), Twitter/X - Backward design — Wiggins & McTighe (концепция: начинай с желаемого результата) - Tacit knowledge — Michael Polanyi ("мы знаем больше, чем можем сказать") - Beads (система задач) — Geoffrey Yegge + Jeffrey Emanuel (github.com/Dicklesworthstone/beads_rust) - GitHub Spec Kit — github.com/github/spec-kit - Context engineering — Anthropic docs: docs.anthropic.com/en/docs/build-with-claude/context-engineering
Опубликовано: VibeX 2026, 9–12 June 2026, Glasgow, Scotland