Л3. Архитектура внимания — от промпта к системе

📺 Слайды к лекции

На прошлой лекции мы разобрали, как устроена модель изнутри: токенизация, контекстное окно как RAM, галлюцинации как свойство архитектуры, разница между chat- и reasoning-моделями. Мы закончили пятью правилами работы с LLM — в том числе «контекст — дефицитный ресурс». На семинаре 3 вы увидели, как наивный подход «один гигантский промпт» ломается на реальной задаче. Сегодня мы разберём, как управлять контекстом системно — от антипаттернов, которые вы встретили на практике, до полноценной инженерии контекста и спецификаций.

К концу лекции вы будете смотреть на промпт иначе: не как на текст, который надо «правильно сформулировать», а как на последний слой многослойной системы. Мы разберём типичные грабли, четыре стратегии управления контекстом, файлы правил и spec-driven development.

---

Мостик — что мы уже знаем

Три идеи из прошлых лекций, на которые мы будем опираться. Объяснять заново не буду — просто напомню.

1. Контекст = RAM (Л2). Контекстное окно — ограниченный ресурс. U-образная кривая внимания: модель надёжно обрабатывает начало и конец контекста, но «теряет» середину. Отравление контекста: если туда попала неверная информация, модель «заражается».

2. Progressive Disclosure (Л1). AGENTS.md как оглавление, а не энциклопедия. Кейс OpenAI: вместо тысячестраничного мануала — карта, по которой агент находит нужный раздел.

3. Sycophancy (Л2). Модель соглашается с вами, даже когда вы неправы. Это следствие RLHF — модели обучались быть «полезными», и научились угождать. Скептицизм обязателен.

Мы знаем ограничения. Мы видели провалы на семинаре 3. Теперь учимся эти ограничения обходить.

---

Блок 1. Антипаттерны промптинга — почему «в лоб» не работает

На семинаре 3 многие из вас столкнулись с тем, что MVP разваливается после 3--4 итераций. Промпт, который казался «достаточно подробным», переставал работать. Давайте разберём, почему это происходит, и дадим названия тем граблям, на которые вы наступили.

1. Монолитный промпт (Kitchen Sink)

Самый распространённый антипаттерн — попытка запихать все требования, контекст, примеры и ограничения в один гигантский текст. Логика кажется безупречной: «чем больше информации, тем лучше результат». На практике — ровно наоборот.

Разработчики OpenAI описывают этот провал прямо. Они пробовали подход «один большой AGENTS.md» — и он предсказуемо сломался:

"We tried the 'one big AGENTS.md' approach. It failed in predictable ways: Context is a scarce resource. A giant instruction file crowds out the task, the code, and the relevant docs — so the agent either misses key constraints or starts optimizing for the wrong ones." — OpenAI, Harness engineering: leveraging Codex in an agent-first world

Проблема не в объёме как таковом, а в том, что когда всё помечено как «важное», ничего не является важным. Агент начинает pattern-match локально, вместо того чтобы навигировать по инструкциям осмысленно. OpenAI формулирует это так: «Too much guidance becomes non-guidance. When everything is "important," nothing is.»

И есть ещё один коварный эффект — гниение. Монолитный мануал мгновенно превращается в кладбище устаревших правил. Агент не может отличить актуальное от устаревшего, люди перестают поддерживать файл, и он тихо становится «attractive nuisance» — привлекательной помехой.

Именно это вы видели на С3

Когда ваш MVP начинал разваливаться после нескольких итераций — это классический kitchen sink в действии. Каждая новая инструкция, добавленная в промпт «для подстраховки», разбавляла те инструкции, которые реально важны.

2. Retrieve-everything (наивный RAG)

Противоположная крайность: вместо одного большого промпта — попытка подгрузить в контекст «всё, что может пригодиться». Это аналог антипаттерна из классического RAG: агент тонет в шуме и не может выделить сигнал.

Статья OpenDev описывает механику проблемы:

"A naive approach loads a single monolithic prompt containing every possible instruction... irrelevant instructions dilute the sections that do matter, making the agent's behavior noisier." — OpenDev, Building Effective AI Coding Agents for the Terminal

Нерелевантные секции съедают бюджет контекстного окна, не принося поведенческой ценности. А из-за U-образной кривой внимания (Л2) модель буквально «теряет» полезную информацию, утонувшую в шуме.

3. Implicit Requirements (неявные требования)

Разработчик держит требования «в голове» и ожидает, что модель их угадает. «Сделай мне API для заказов» — а в голове вы держите, что нужна пагинация, фильтрация по дате, soft delete и оптимистичная блокировка. Модель не спросит «а что вы имели в виду?» — она сгенерирует что-нибудь уверенно. Это прямое следствие sycophancy (Л2): модель обучена быть helpful, а не быть критичной.

Результат: модель галлюцинирует бизнес-логику, потому что у неё нет спецификации — только ваш промпт. И чем увереннее вы формулируете задачу, тем менее вероятно, что модель попросит уточнения.

4. Prompt Rot (гниение промпта)

Промпт, который работал с GPT-4, может ломаться с Claude Opus 4.6 или следующей версией той же модели. Промпты привязаны к конкретным весам модели — это хрупкая зависимость. В отличие от кода, промпты не имеют тестов, версионирования и CI/CD.

Коварность в том, что деградация происходит незаметно. Обновили модель, всё вроде работает, но в 10% случаев результат стал хуже. Без автоматических evaluation вы этого не заметите.

5. Оверинжиниринг по умолчанию

Современные модели (Claude, GPT-5) склонны усложнять — оборачивать в ненужные абстракции, создавать лишние файлы, городить иерархии классов. Без жёстких рамок модель генерирует технический долг, который вы ещё даже не успели запросить.

Денис в разборе agentic workflow формулирует это прямо:

«Современное поколение моделей склонны усложнять, они склонны оборачивать в ненужную абстракцию... и против этого надо бороться как в промпте планирования, так потом на этапе ревью.» — Денис, «Agentic Engineering AI Workflow»

Чем сильнее вы упростите код, тем больше шансов, что он будет долго жить и хорошо работать. На упрощение надо отдельно указывать на всех этапах — и в брифе, и в планировании, и при ревью.

Сводная таблица антипаттернов

Антипаттерн	Симптом	Откуда знаем
Kitchen Sink	Агент «забывает» важные инструкции	OpenAI: Harness engineering; С3
Retrieve-everything	Тонет в шуме, отвечает не по делу	OpenDev: Building AI Agents
Implicit Requirements	Галлюцинирует бизнес-логику	Sycophancy (Л2); С3
Prompt Rot	Промпт ломается при обновлении модели	Практика; отсутствие evals
Оверинжиниринг	Лишние абстракции и файлы	Денис: Agentic Workflow; С3

Узнаёте?

Если таблица напоминает ваш опыт с семинара — хорошо. Значит, у граблей теперь есть названия, и можно перестать на них наступать.

Окей, мы знаем, чего не делать. Но что делать вместо этого? Нам нужна системная рамка для управления контекстом. И такая рамка есть — четыре стратегии context engineering.

---

Блок 2. Четыре стратегии Context Engineering

Контекст — архитектурная дисциплина, а не магия промптов

Карпаты дал определение, которое стоит запомнить:

"Context engineering is the delicate art and science of filling the context window with just the right information for the next step." — Andrej Karpathy (цитируется в LangChain Blog)

Обратите внимание: «just the right information for the next step». Не «всю информацию». Не «максимум информации». Именно то, что нужно для конкретного следующего шага. Прямая противоположность kitchen sink.

Anthropic формулирует жёстче: цель — найти наименьший набор высокосигнальных токенов, который максимизирует вероятность желаемого результата. Минимум шума, максимум сигнала.

LangChain систематизировал четыре стратегии. Каждая отвечает на свой вопрос.

Стратегия 1: Write (Запись)

Вопрос: «Что сохранить за пределами контекста?»

"Writing context means saving it outside the context window to help an agent perform a task." — LangChain, Context Engineering

Суть: агент может записывать промежуточные результаты в файл, чтобы не забивать контекстное окно. Scratchpad, Memory Bank, заметки агента — всё это формы Write.

Пример: Claude Code сохраняет результаты длинных команд в temp-файлы и потом читает только нужные фрагменты. Из лекции 1 мы знаем, что это называется Dynamic Context Discovery — и оно экономит порядка 47% токенов.

Anthropic описывает эту стратегию как «structured note-taking»:

"A technique where the agent regularly writes notes persisted to memory outside of the context window. These notes get pulled back into the context window at later times." — Anthropic, Effective context engineering for AI agents

Проще говоря: контекстное окно — рабочая память. Всё, что не нужно прямо сейчас, пусть лежит на «диске» — в файлах, в git, в базе. Понадобится — подгрузим.

Стратегия 2: Select (Выборка)

Вопрос: «Что подгрузить в контекст?»

"Selecting context means pulling it into the context window to help an agent perform a task." — LangChain, Context Engineering

Файлы правил (CLAUDE.md, .cursor/rules), документы, примеры кода — всё это формы Select. Подгружать только то, что нужно для текущего шага. Не «всё на всякий случай» — это retrieve-everything из блока 1.

Anthropic рекомендует подход «just-in-time retrieval»:

"Rather than pre-processing all relevant data up front, agents built with the 'just in time' approach maintain lightweight identifiers (file paths, stored queries, web links, etc.) and use these references to dynamically load data into context at runtime using tools." — Anthropic, Effective context engineering for AI agents

Тут работает Progressive Disclosure из Л1: агент сначала читает оглавление (AGENTS.md, структуру проекта), потом — только нужный раздел. Claude Code использует CLAUDE.md, Cursor — файлы правил в .cursor/rules/, GitHub Copilot — .github/copilot-instructions.md. Мы подробно разберём эти файлы в блоке 3.

Стратегия 3: Compress (Сжатие)

Вопрос: «Как уместить больше в те же токены?»

"Compressing context involves retaining only the tokens required to perform a task." — LangChain, Context Engineering

Adaptive Context Compaction: автоматическая суммаризация истории диалога. Claude Code запускает auto-compact при 95% заполнения контекстного окна. Cursor Agent использует сжатие для длинных файлов — показывает модели только релевантные фрагменты, а не весь файл целиком.

Anthropic описывает механику:

"Compaction is the practice of taking a conversation nearing the context window limit, summarizing its contents, and reinitiating a new context window with the summary." — Anthropic, Effective context engineering for AI agents

Весь вопрос в том, что сохранить, а что выбросить. Нерешённые баги — сохраняем. Выводы уже отработавших инструментов — выбрасываем. Самый безопасный вид сжатия — просто очистить результаты инструментов, которые уже не нужны.

Обратная сторона медали — context rot: деградация качества при накоплении устаревших промежуточных результатов. Контекст копит «мусор» из прошлых итераций, модель путается. Периодическое сжатие и очистка помогают.

Стратегия 4: Isolate (Изоляция)

Вопрос: «Как разделить контекст между подзадачами?»

"Isolating context involves splitting it up to help an agent perform a task." — LangChain, Context Engineering

Идея простая: если задача сложная (дебаг, рефакторинг большого модуля), основной агент делегирует подзадачу субагенту с чистым контекстом. Субагент получает только то, что ему нужно, решает задачу, возвращает результат. Основной контекст не загрязняется промежуточным мусором.

Anthropic рекомендует:

"Rather than one agent attempting to maintain state across an entire project, specialized sub-agents can handle focused tasks with clean context windows." — Anthropic, Effective context engineering for AI agents

Аналогия с менеджментом: вы не пересказываете подчинённому всю историю компании. Вы даёте конкретную задачу с конкретным контекстом и ждёте результат.

Prompt Composer — как это работает внутри

Системы вроде Claude Code, Cursor и OpenDev не используют один статичный промпт. Они динамически собирают контекст из нескольких слоёв.

OpenDev описывает свой PromptComposer как четырёхшаговый pipeline:

"OpenDev assembles each agent's system prompt at runtime... Behavioral instructions are factored into independent sections, each stored as a separate markdown file and registered with two metadata fields: a condition predicate over a runtime context dictionary... and a priority integer that controls reading order." — OpenDev, Building Effective AI Coding Agents for the Terminal

Четыре шага: Filter (отфильтровать нерелевантные секции по предикату), Sort (упорядочить по приоритету), Load (загрузить и подставить переменные), Join (склеить в финальный промпт).

Claude Code использует каскадную систему CLAUDE.md:

1. ~/.claude/CLAUDE.md — глобальные персональные инструкции
2. ./CLAUDE.md — инструкции проекта (шарятся через git)
3. Поддиректории CLAUDE.md — локальные инструкции для конкретных частей кодовой базы

Cursor аналогично использует .cursor/rules/ с разными scope: Always On, Auto Attached (при открытии определённых файлов), Model Decision (AI сам решает), Manual (только по запросу).

Зачем это знать? Потому что вы не пишете «один промпт». Вы проектируете архитектуру контекста — раскладываете информацию по слоям, и каждый слой подгружается в нужный момент.

Кейс: GSD (Get Shit Done) — все четыре стратегии в одной системе

GSD (gsd-2) — open-source система для Claude Code, которая реализует все четыре стратегии в виде конкретной архитектуры файлов и процессов. Давайте разберём, как именно.

Write — файловая архитектура .gsd/:

GSD экстернализирует всё состояние на диск. Вместо того чтобы полагаться на память модели, система поддерживает набор Markdown-файлов:

• PROJECT.md — живое видение проекта, всегда загружается в контекст
• DECISIONS.md — append-only регистр архитектурных решений
• KNOWLEDGE.md — кросс-сессионные правила и паттерны
• STATE.md — дашборд текущего состояния (агент читает первым, чтобы «вспомнить» контекст)
• M001-ROADMAP.md — план milestone с чекбоксами
• T01-PLAN.md — атомарный план задачи с критериями верификации
• T01-SUMMARY.md — результат выполнения (что изменилось, что произошло)

Select — pre-loaded dispatch prompts:

Каждый субагент получает dispatch prompt, заранее собранный оркестратором — только релевантные файлы, резюме, решения. Агент не тратит контекст на exploration tools, чтобы сориентироваться.

Compress — железное правило:

Задача должна помещаться в одно контекстное окно (~200K токенов). Не помещается — это две задачи. Жёсткое ограничение, которое предотвращает context rot.

Isolate — wave-based параллельное исполнение:

GSD группирует задачи в «волны» (waves) на основе зависимостей. Независимые задачи выполняются параллельно в чистых контекстах субагентов. Зависимые — последовательно. Если у двух задач конфликт по файлам — они выполняются последовательно или мержатся в один план. Основной контекст остаётся на 30--40% заполнения.

Каждая задача = отдельный атомарный git commit. Это значит, что git bisect найдёт точную поломку, а каждая задача откатывается независимо.

Три встроенных субагента GSD

GSD использует три специализированных субагента для делегированной работы:

• Scout — быстрая разведка кодовой базы, возвращает сжатый контекст
• Researcher — веб-исследование, поиск и синтез актуальной информации
• Worker — выполнение задач в изолированном контекстном окне

Кейс: Ralph Loop — итеративный контекст через git

Ralph — фреймворк, реализующий паттерн «свежий контекст на каждую итерацию». Название отсылает к персонажу из «Симпсонов» — агент, как Ральф Виггам, упорно продолжает работу, пока задача не решена.

Идея проста:

• Каждый цикл запускает агента с чистым контекстом (Isolate)
• Память между итерациями — через progress.md (Write) и git history
• Верификация (typecheck, тесты) после каждой итерации предотвращает накопление ошибок
• Если агент пытается завершить работу — middleware перехватывает его и заставляет пройти чеклист верификации

Write и Isolate работают тут в связке: агент «забывает» всё между итерациями, но «помнит» через файлы. Git worktrees дают изоляцию — если что-то сломалось, ветку можно просто удалить.

Кейс: Superpowers — skills-фреймворк для Claude Code

Superpowers (110K+ stars) — самый популярный фреймворк расширения Claude Code. Он реализует все четыре стратегии через систему «навыков» (skills):

• Brainstorming перед кодом (Select — подгрузка контекста задачи через Socratic-диалог). Агент не прыгает сразу в код, а сначала спрашивает, что вы на самом деле хотите. Борьба с implicit requirements из блока 1.
• Git worktree для изоляции (Isolate — каждая фича в отдельной ветке)
• Plan → Execute через субагентов (Isolate — параллельные агенты с чистым контекстом)
• Verification before completion (Write — фиксация результатов проверки)

Почему все приходят к одному и тому же

GSD, Ralph, Superpowers — три разные команды, три разных проекта, одни и те же четыре стратегии. Ограничения контекстного окна объективны, и решения получаются похожими. Если завтра появится новый фреймворк, вы уже знаете, из чего он будет состоять.

Стратегия Select говорит: подгрузи правильный контекст. Но откуда его взять? Ответ — из файлов правил, которые вы пишете для вашего проекта. Давайте разберём, как это делать на практике.

---

Блок 3. Файлы правил — контекст как код

Зоопарк форматов

Каждый инструмент использует свой файл правил, но принципы одинаковы. Вот основные:

Инструмент	Файл правил	Формат
Claude Code	CLAUDE.md	Markdown, корень проекта + поддиректории
Cursor	.cursor/rules/	Markdown-файлы с scope (.mdc)
GitHub Copilot	.github/copilot-instructions.md	Markdown
OpenAI Codex	AGENTS.md	Markdown
Windsurf	.windsurfrules	Markdown

Файл называется по-разному, но суть одна — это персистентный контекст, который агент видит при каждом разговоре.

"Rules provide persistent instructions that shape how the agent works with your code... Think of them as always-on context that the agent sees at the start of every conversation." — Cursor, Best practices for coding with agents

Принципы эффективных правил

Как писать правила, чтобы они реально работали? Вот что мы знаем из практики Cursor, OpenAI и Meta.

Первое — атомарность. Одно правило — одна тема. Не смешивайте стилистику кода с архитектурными решениями в одном файле. Cursor рекомендует хранить правила в отдельных файлах в .cursor/rules/, каждый со своим scope. Claude Code поддерживает CLAUDE.md в поддиректориях — разные правила для frontend/, backend/, tests/.

Второе — ссылки вместо копирования. Правило указывает на файл (see docs/architecture.md), а не дублирует его содержимое. Иначе рассинхронизация неизбежна.

"Reference files instead of copying their contents; this keeps rules short and prevents them from becoming stale as code changes." — Cursor, Best practices for coding with agents

Третье — размер. OpenAI рекомендует ~100 строк для AGENTS.md. John Kim из Meta (Staff Engineer, 12 часов в день в Claude Code) целится в ~300 строк для CLAUDE.md:

"I think around 300 lines is about a decent place that you want to aim for... the more bloat you have in your context the less likely the AI will do exactly what you're trying to do." — John Kim (Meta Staff Engineer), How I use Claude Code

Больше — шум, меньше — недостаточно контекста.

Четвёртое — версионирование. Файлы правил лежат в репозитории. Они проходят code review наравне с кодом. Cursor рекомендует: «Check your rules into git so your whole team benefits.»

И пятое — обновление через агента. Не правьте CLAUDE.md руками после каждого бага. Попросите агента: «обнови правила, чтобы эта ошибка больше не повторялась». Kim из Meta формулирует это как аналогию с линтером:

"Whenever you run into something like that you want to fix it manually and then you just update your CLAUDE.md rules so that it never does that mistake again — think of it as like lint files." — John Kim (Meta Staff Engineer)

И ещё один момент: Claude Code читает CLAUDE.md сверху вниз, приоритет убывает. Самое важное — наверх. Архитектура проекта, паттерны, validation flow, правила «never do X» и «always do Y» с примерами.

Чего не надо делать в файлах правил

Cursor прямо указывает, что стоит избегать:

• Копировать целые стайл-гайды (используйте линтер)
• Документировать каждую возможную команду (агент и так знает стандартные инструменты)
• Добавлять инструкции для edge-кейсов, которые встречаются редко

Начинайте с простого. Добавляйте правила, только когда видите, что агент повторяет одну и ту же ошибку. Не оптимизируйте преждевременно.

Lazy Tool Discovery

В контексте MCP (Model Context Protocol) — не загружайте описания всех доступных инструментов сразу. Вместо этого: дайте агенту каталог инструментов (названия + 1 строка описания), и пусть он запрашивает полное описание только когда конкретный инструмент нужен.

Anthropic рекомендует это же:

"Tools should be self-contained, robust to error, and extremely clear with respect to their intended use... If a human engineer can't definitively say which tool should be used in a given situation, an AI agent can't be expected to do better." — Anthropic, Effective context engineering for AI agents

Экономия — сотни токенов в каждом запросе. И агент реже выбирает не тот инструмент.

Kim из Meta вообще старается минимизировать количество MCP-серверов: «I try very very hard to not use MCPs because I think they blow up your context window.» Свежий контекст бьёт раздутый.

Иерархия файлов правил

Claude Code поддерживает CLAUDE.md в поддиректориях. Это позволяет задавать разные правила для разных частей проекта:

project/
├── CLAUDE.md              # Общие правила проекта
├── frontend/
│   └── CLAUDE.md          # React-специфичные правила
├── backend/
│   └── CLAUDE.md          # FastAPI-специфичные правила
└── tests/
    └── CLAUDE.md          # Правила для тестов

Агент читает правила текущей директории плюс все родительские. Cursor поддерживает аналогичную структуру через .cursor/rules/ с файлами, привязанными к конкретным glob-паттернам.

Экосистема: где брать готовые правила

Не обязательно писать правила с нуля. Есть готовые коллекции:

• PatrickJS/awesome-cursorrules — коллекция .cursorrules для десятков стеков (React, FastAPI, Go, Flutter и т.д.). Отличная стартовая точка.
• affaan-m/everything-claude-code — 125+ skills, 60+ команд, 28 субагентов для Claude Code. Пример того, как далеко можно зайти с кастомизацией.
• skills.sh — маркетплейс навыков для Claude Code и других агентов. Установка одной командой: npx skillsadd owner/repo.
• obra/superpowers — skills-фреймворк (110K+ stars), добавляющий TDD, brainstorming, code review и другие workflow.

Начните с малого

Файлы правил — самый быстрый способ улучшить работу агента. CLAUDE.md на 30--50 строк создаётся за 15 минут. Архитектура, паттерны, типичные ошибки — и вы сразу увидите разницу.

Файлы правил говорят агенту, как работать. Но не говорят что строить. Для этого нужен следующий уровень — спецификации. И тут мы подходим к сдвигу, который меняет всё: код — побочный продукт, спецификация — первичный артефакт.

---

Блок 4. Spec-driven development — спецификация важнее кода

Проблема, которую решает SDD

Без спецификации агент принимает архитектурные решения за вас. И принимает их плохо. Вспомните оверинжиниринг из блока 1: модель городит абстракции, потому что ей не сказали этого не делать. Вспомните implicit requirements: модель галлюцинирует бизнес-логику, потому что у неё нет спецификации.

Спецификация — контракт между вами и агентом. Вот что делать, вот критерии приёмки, вот ограничения. Нет контракта — модель заполняет пробелы галлюцинациями (Л2: она не скажет «я не знаю»).

Данила Симонов в обзоре итогов года формулирует этот сдвиг так:

«Работа над проектами превращается не в работу с кодовой базой, а именно в проектирование того, как ваш проект будет выглядеть. Один из самых крупных звонких моментов — появление SpecKit от GitHub.» — Данила Симонов, «Итоги года»

Спецификация превращается в «декомпозированный pipeline задач, который потом на вход можно подавать кодинговым агентам». Вы проектируете, агент реализует. Не наоборот.

Итеративный бриф

SDD начинается не с написания кода, а с разговора. Денис описывает этот процесс:

«Я её итеративно с агентом дорабатываю — когда агент ответил, те части ответа, которые мне откликаются и кажутся движением в нужном направлении, я добавляю в изначальный промпт, и вот такими итерациями мой изначальный промпт растёт.» — Денис, «Agentic Engineering AI Workflow»

На практике это выглядит так:

1. Описываете идею в 2--3 предложениях
2. Просите модель задать уточняющие вопросы (это борьба с sycophancy: заставляете модель быть критичной, а не соглашательской)
3. Отвечаете на вопросы, модель генерирует черновик спецификации
4. Ревью спецификации (вы + модель): закрываете gaps, уточняете edge cases
5. Фиксация спецификации как артефакта проекта — файл в репозитории, а не сообщение в чате

John Kim из Meta использует план-режим для того же: «I actually use plan mode quite heavily... it's rare that I start in edit mode.» Он никогда не принимает первый ответ, а всегда челленджит модель.

Вертикальные слайсы

Спецификация разбивается не по слоям (frontend → backend → database), а по пользовательским сценариям. Каждый слайс — это минимальный end-to-end путь, который можно реализовать и протестировать изолированно.

Для AI-кодинга это особенно важно. Модель справляется с маленькой чётко очерченной задачей куда лучше, чем с «сделай весь backend». Вертикальные слайсы параллелизуются лучше горизонтальных слоёв (вспомните wave-based execution из GSD). И каждый слайс можно протестировать независимо.

Пример. Задача: «система управления проектами». Вместо горизонтальной декомпозиции (модели данных → API → UI), делим на вертикальные слайсы:

• Слайс 1: Пользователь создаёт проект (форма → API → БД → отображение)
• Слайс 2: Пользователь добавляет задачу в проект
• Слайс 3: Пользователь назначает задачу коллеге
• Слайс 4: Пользователь видит прогресс на дашборде

Каждый слайс — полноценная фича от UI до базы данных.

Acceptance Scenarios (BDD-формат)

Каждый слайс описывается через GIVEN/WHEN/THEN:

GIVEN: пользователь авторизован и находится на дашборде
WHEN: нажимает кнопку «Создать проект»
THEN: открывается форма с полями (название, описание, дедлайн)
AND: кнопка «Сохранить» неактивна, пока не заполнено название

Одна запись — три функции. Спецификация для агента (конкретный контракт). Критерии приёмки для вас (можно проверить руками). И основа для автотестов (BDD-формат транслируется в тестовые сценарии напрямую).

Фреймворки SDD

Разберём три подхода — от простого к тяжёлому.

ai-dev-tasks: самый простой вход

ai-dev-tasks — три Markdown-шаблона: create-prd.md → generate-tasks.md → build. Работает с любым AI-ассистентом без установки. Идеальный вариант для студентов, которые хотят попробовать SDD прямо сейчас.

SpecKit: шестифазный workflow от GitHub

SpecKit — open-source тулкит от GitHub для spec-driven development. Работает с 20+ AI-ассистентами через slash-команды.

"The workflow follows four explicit phases: /specify generates a detailed spec from a prompt, /plan creates technical architecture, /tasks breaks the plan into implementation tasks, and finally implementation generates code task by task." — OpenDev, Building Effective AI Coding Agents for the Terminal

Полный цикл SpecKit:

1. Constitution (/speckit.constitution) — создание «конституции» проекта: базовые принципы и ограничения, которые агент будет соблюдать на всех фазах
2. Specify (/speckit.specify) — описание бизнес-логики и пользовательских историй. На этом этапе строго отделяется что от как: «Be as explicit as possible about what you are trying to build and why. Do not focus on the tech stack at this point.»
3. Clarify (/speckit.clarify) — опциональная фаза: последовательные вопросы для закрытия gaps
4. Plan (/speckit.plan) — техническая архитектура: стек, constraints, design system
5. Tasks (/speckit.tasks) — декомпозиция на атомарные задачи с зависимостями и маркерами параллельного выполнения
6. Implement (/speckit.implement) — агент выполняет задачи одну за одной (или параллельно, где это безопасно)

Главное: вы не переходите к следующей фазе, пока не валидировали текущую. «At each phase, humans review and refine before proceeding.»

GSD: полноценная система

GSD объединяет SDD, context engineering и автономное исполнение. Мы уже разбирали его в блоке 2 — здесь подчеркнём SDD-аспект.

Иерархическая декомпозиция:

• Milestone — шиппабельная версия (например, MVP)
• Slice — демонстрируемая фича (вертикальный слайс)
• Task — помещается в одно контекстное окно

XML-спецификации задач — структурированный формат с полями <files>, <action>, <verify>, <done>. Это машиночитаемый контракт, а не проза — агент точно знает, что делать, какие файлы трогать и как верифицировать результат.

Встроенная верификация: после каждой задачи — lint, тесты, build. При провале — автоматический retry с диагностикой. При успехе — атомарный git commit.

Денис подчёркивает:

«Важно всё-таки замкнуть этот цикл, чтобы он крутился под нашим управлением, а не с нашим участием — наше участие должно сводиться к постановке задач и контролю результатов.» — Денис, «Agentic Engineering AI Workflow»

OpenSpec: для brownfield-проектов

OpenSpec — подход для существующих кодовых баз, когда нельзя начать «с нуля». Генерирует дельты спецификации: ADDED / MODIFIED / REMOVED — в формате GIVEN/WHEN/THEN. Спецификация живёт рядом с кодом и обновляется при каждом изменении.

Memory Bank — «библия» проекта

Паттерн, который возник в экосистеме Cline и распространился как универсальный подход к организации знаний проекта.

"Memory Bank is a documentation methodology that transforms Cline from a stateless assistant into a persistent development partner. Through structured markdown files, Cline can 'remember' your project details across sessions." — Cline Documentation

Денис использует Memory Bank в своём workflow и формулирует базовые принципы:

«Базовые принципы Memory Bank: single source of truth, атомарность, построен на progressive disclosure, дубли исключены.» — Денис, «Agentic Engineering AI Workflow»

Структура по C4-модели:

Денис использует подход C4 (Context → Container → Component → Code) для организации документации:

«Мы используем подход C4 в документации, чтобы по этим уровням разбивать изложение логики работы системы.» — Денис, «Agentic Engineering AI Workflow»

Те же уровни абстракции, что и в software architecture, но применённые к документации для AI-агента.

Разделение specs vs plans:

«В спеке должно быть актуальное состояние системы — как внутри что-то устроена конструкция. А папка планы — это как строительные чертежи, как это будет сделано.» — Денис, «Agentic Engineering AI Workflow»

• specs/ — что есть (актуальное состояние системы)
• plans/ — что будет (строительные чертежи)

Ключевые файлы Memory Bank:

• projectbrief.md — краткое описание проекта
• productContext.md — бизнес-контекст и пользовательские истории
• activeContext.md — текущая задача и фокус
• systemPatterns.md — архитектурные паттерны и решения
• techContext.md — технический стек и зависимости
• progress.md — текущий статус и известные проблемы

Агент читает эти файлы в начале каждой сессии и обновляет после значимых изменений. По сути, это долговременная память проекта, которая переживает сброс контекста.

Memory Bank = ваша ответственность

Помните предупреждение из Cline: «After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.» Memory Bank — это не магия, это инженерная дисциплина. Если вы не поддерживаете его в актуальном состоянии, он станет ещё одним источником context poisoning.

Попробуйте сегодня

Не обязательно сразу внедрять GSD или SpecKit. Перед следующей задачей напишите 5--10 предложений: что делать, чего не делать. Попросите модель задать уточняющие вопросы. Зафиксируйте результат в spec.md. Даже этот минимальный шаг заметно улучшит результат по сравнению с «сделай мне API для заказов».

От антипаттернов — через стратегии контекста и файлы правил — к спецификациям. Давайте соберём это в чеклист, который можно применить уже сегодня.

---

Блок 5. Итоги и чеклист

Чеклист: 5 шагов перед запуском агента

Шпаргалка

1. Написать спецификацию — хотя бы 5--10 предложений о том, что нужно сделать и чего делать не нужно
2. Разбить на вертикальные слайсы — каждый слайс = один end-to-end сценарий
3. Описать acceptance criteria — GIVEN/WHEN/THEN для каждого слайса
4. Настроить файлы правил — CLAUDE.md / .cursor/rules с ключевыми ограничениями проекта
5. Проверить Memory Bank — актуальна ли документация проекта, нет ли противоречий

Главный takeaway

Промпт — последний шаг, а не первый. 90% работы с AI — подготовка контекста и спецификаций. Чем меньше вы полагаетесь на магию формулировки, тем предсказуемее результат.

Что мы прошли сегодня:

1. Антипаттерны — почему наивный подход ломается (Kitchen Sink, Retrieve-everything, Implicit Requirements, Prompt Rot, Оверинжиниринг)
2. Четыре стратегии — Write, Select, Compress, Isolate
3. Файлы правил — CLAUDE.md, .cursor/rules — персистентный контекст для агента
4. Spec-driven development — спецификация как первичный артефакт

Арка курса

Лекция	Вопрос	Ответ
Л1	Зачем?	AI умножает экспертизу, но требует harness engineering
Л2	Почему?	Физика модели: токены, контекст, галлюцинации, reasoning
Л3	Как?	Context engineering, файлы правил, spec-driven development
Л4	Чем?	Фреймворк для оценки инструментов (Cursor, Claude Code, Copilot)

Мини-задание

Переделайте сломанный проект из С3, применив минимум 3 техники из сегодняшней лекции. Формат отчёта: было → стало → почему.

Например:

• Было: один монолитный промпт на 500 строк → Стало: CLAUDE.md (50 строк) + spec.md + 3 вертикальных слайса → Почему: антипаттерн Kitchen Sink, стратегия Select, SDD

Что дальше

На семинаре 4 будем разбирать AI в повседневных задачах — code review, рефакторинг, дебаг — уже с использованием правильного контекста.

На лекции 4 — фреймворк для оценки инструментов. Мы разобрались, как управлять контекстом и писать спецификации. Но в каком инструменте это делать? Cursor, Claude Code, Copilot, Windsurf — у каждого свои сильные и слабые стороны.

---

Дальнейшее чтение

Ключевые статьи и гайды

• LangChain (2025). Context Engineering — формализация четырёх стратегий управления контекстом.
• Anthropic (2025). Effective context engineering for AI agents — практические рекомендации от создателей Claude.
• OpenAI (2025). Harness engineering: leveraging Codex in an agent-first world — опыт OpenAI с AGENTS.md и контекстом.
• OpenDev (2025). Building Effective AI Coding Agents for the Terminal — PromptComposer, Memory Bank, SDD.
• Cursor (2025). Best practices for coding with agents — гайд по файлам правил и эффективной работе.

Видео

• John Kim (Meta Staff Engineer). How I use Claude Code — 12 часов в день в Claude Code, parallel development, CLAUDE.md best practices.
• Денис. «Agentic Engineering AI Workflow» — Memory Bank, C4, борьба с оверинжинирингом.
• Данила Симонов. «Итоги года» — spec-driven approach, SpecKit, сдвиг от кода к проектированию.

Open-source фреймворки

• github/spec-kit — шестифазный SDD workflow от GitHub.
• gsd-build/get-shit-done / gsd-build/gsd-2 — context engineering + SDD + автономное исполнение для Claude Code.
• snarktank/ralph — итеративный контекст через git, Ralph Loop.
• snarktank/ai-dev-tasks — три шаблона для простого входа в SDD.
• obra/superpowers — 110K+ stars, skills-фреймворк для Claude Code.
• PatrickJS/awesome-cursorrules — коллекция .cursorrules для десятков стеков.
• affaan-m/everything-claude-code — 125+ skills для Claude Code.
• skills.sh — маркетплейс навыков для AI-агентов.