LLM анализ статьи

• https://www.youtube.com/watch?v=-QFHIoCo-Ko

Развёрнутая аннотация

Видео — длинный практический воркшоп Мэтта Покока о том, как строить инженерный workflow для AI coding не как «vibe coding», а как управляемый процесс от размытой идеи до production-кода. Центральный тезис: ИИ действительно меняет разработку, но фундаментальные практики software engineering — маленькие задачи, понятная архитектура, тесты, code review, вертикальные срезы и качественная обратная связь — становятся ещё важнее. Покок показывает это на сквозном примере: в учебной платформе Cadence нужно добавить геймификацию, потому что студенты записываются на уроки и бросают обучение. Вместо прямого «сделай фичу» он сначала добивается shared design concept через навык Grill Me, затем превращает разговор в PRD, разбивает PRD в Kanban/DAG из вертикальных задач, передаёт реализацию AFK-агенту Ralph, заставляет агента работать через TDD / red-green-refactor, после чего возвращает человека на code review и QA. Отдельный вклад видео — объяснение, почему большие context windows не решают coding-задачи сами по себе: у LLM есть «smart zone» и «dumb zone», поэтому задачи надо держать малыми, контекст — чистым, а кодовую базу — тестируемой и организованной вокруг глубоких модулей.

Подробный разбор

Введение и контекст

• Название: Full Walkthrough: Workflow for AI Coding — Matt Pocock.
• Канал/автор: канал AI Engineer, спикер Matt Pocock. Внешние индексы также дают расширенное название: Full Walkthrough: Workflow for AI Coding from Planning to Production — Matt Pocock (@mattpocockuk). (Podwise)
• Дата публикации: 2026-04-24. (Podwise)
• Хронометраж: 01:36:30 по внешнему каталогу; TalksIntel указывает «96 min», что согласуется с приложенным VTT, заканчивающимся примерно на 01:36:25. (DEV Community)
• Контекст: это воркшоп из AI Engineer Europe 2026 / AI Engineer conference track, описанный внешними источниками как hands-on session про полный lifecycle AI-assisted development: от неопределённых требований до agent-ready планов и автономных coding agents. (DEV Community)
• Целевая аудитория: разработчики и инженерные лиды, которые уже используют AI coding tools или раздражались их поведением. В начале Мэтт просит поднять руки тех, кто программировал с ИИ, кто делает это ежедневно, и кто был раздражён ИИ.
• Заявленная цель: показать, что «основы разработки ПО» по-прежнему работают с ИИ, и провести аудиторию через полный workflow: идея → уточнение → PRD → Kanban-задачи → AFK-реализация → TDD → review/QA → улучшение архитектуры.
• Источник содержания: использован приложенный русскоязычный VTT-транскрипт. Описание YouTube и закреплённый комментарий через доступные инструменты полностью не извлечены. OCR экранного текста не выполнен, потому что приложен транскрипт, но не сам видеофайл/кадры; экранные названия и команды ниже включены только там, где они отражены в речи или транскрипте.

Рекомендации и ключевые заметки

• Держать LLM в “smart zone”. Покок говорит, что у LLM есть «зона ума» и «зона глупости»: чем больше контекст, тем сильнее напряжены attention-связи. Рабочий ориентир — около 100k токенов, даже если доступно окно 200k или 1M.
• Не складывать огромные инструкции в system prompt. Он приводит антипример: если положить в системный контекст 250k токенов, модель попадёт в «dumb zone» ещё до начала работы.
• Очищать контекст предпочтительнее, чем постоянно compact-ить. Compacting создаёт «осадок» и непредсказуемое состояние; clear/reset возвращает модель к одинаковому базовому состоянию.
• Не относиться к AI как к compiler from specs to code. Покок критикует подход, где разработчик правит только спецификацию и не смотрит в код: «код — это ваше поле битвы».
• Начинать работу с AI через Grill Me. Суть навыка: «неустанно опрашивайте меня по каждому аспекту этого плана, пока мы не достигнем взаимопонимания».
• Цель Grill Me — shared design concept, а не просто план. Он ссылается на Фредерика П. Брукса и идею design concept: всем участникам разработки нужна общая модель того, что строится.
• Использовать sub-agents для исследования. Субагент имеет изолированное context window, исследует задачу и возвращает сжатый отчёт агенту-оркестратору.
• Различать human-in-the-loop и AFK-задачи. Планирование и alignment должны оставаться с человеком; реализацию можно отдавать агенту «ночной смены».
• PRD — destination document, не объект для бесконечной полировки. После Grill Me Мэтт пишет PRD, но говорит, что обычно не читает его целиком, потому что проверять надо не способность LLM резюмировать, а конечный код и QA.
• Разбивать PRD не в линейный phase plan, а в Kanban/DAG. Последовательные фазы выполняет один агент; Kanban с блокирующими связями позволяет параллелить независимые задачи.
• Предпочитать vertical slices / tracer bullets. ИИ склонен писать горизонтально: сначала БД, потом API, потом UI. Покок требует узкий вертикальный срез через все слои, чтобы в конце было что увидеть и проверить.
• В первом вертикальном срезе нужен end-to-end feedback. В примере правильный срез: начислить баллы за прохождение урока и показать их на dashboard.
• AFK-агент должен выбирать только задачи, помеченные как AFK. Если таких задач больше нет, он должен вывести «Больше задач нет».
• Приоритеты AFK-агента: критические ошибки → инфраструктура → tracer-bullet issues → quick wins/refactoring.
• TDD обязателен, где возможно. Агент сначала пишет failing test, подтверждает red, затем реализует green и рефакторит.
• Не давать агенту ревьюить свой код в том же переполненном контексте. Review должен запускаться в свежем контексте, иначе reviewer окажется в «dumb zone» и будет слабее implementer.
• Manual QA нельзя полностью автоматизировать. Покок считает QA местом, где человек навязывает кодовой базе taste и judgement; без этого получается «slop».
• Качество feedback loops — потолок качества AI coding. Если нет тестов, type check и понятных границ проверки, ИИ «кодит вслепую».
• Стандарты кодирования: pull для implementer, push для reviewer. Исполнитель должен иметь возможность подтянуть стандарты как навык; reviewer должен получить стандарты явно, чтобы сравнивать с кодом.
• Документацию и PRD не стоит бесконтрольно хранить в репозитории. Старые PRD могут сгнить: код, требования и названия меняются, а агент находит устаревший документ и принимает его за истину.
• Строить кодовую базу вокруг deep modules. Маленький интерфейс, много скрытой функциональности, понятная тестовая граница; shallow modules порождают плохие зависимости и плохие тесты.
• Проектировать интерфейсы модулей самому, реализацию делегировать. Это позволяет сохранять ментальную карту кодовой базы, не читая каждую строку AI-generated implementation.
• Для параллельных агентов Покок показывает Sandcastle. Это TypeScript-библиотека, которая создаёт git worktree, помещает его в Docker sandbox, запускает агента и потом позволяет мержить ветки.

Ключевые выводы и результаты

• Порог smart zone: около 100k токенов; в одном месте он формулирует это как «примерно на 40% или около 100 тысяч».
• Большие окна: 200k и 1M context windows не отменяют деградацию качества coding-задач; по его формулировке, они дают «гораздо больше dumb zone», полезной скорее для retrieval, чем для программирования.
• System prompt: пример плохой практики — 250k токенов в постоянном контексте.
• Grill Me research: исследовательский sub-agent потратил 93.7k токенов на Opus, но основной orchestrator-context почти не вырос.
• Grill Me длительность: обычные сессии могут включать 40, 80 или 100 вопросов; иногда это буквально час общения с ИИ.
• Демонстрационная сессия: в одном ускоренном фрагменте агент ответил на 22 собственных вопроса.
• Alignment context: после grilling у него оказалось примерно 25k токенов «золотого» контекста, который он хотел сохранить в destination documents.
• PRD: сгенерированный PRD включал problem statements, solution, implementation decisions и 18 user stories.
• Рабочий репозиторий Покока: он упоминает, что в своём course video manager записал около 1000 видео, а в GitHub-workflow у него 744 закрытых issue.
• Kanban decomposition: для геймификации агент предложил 5 задач, включая schema/service, streak tracking, использование points/streaks для quiz/lesson completion, retroactive backfill и финальный заблокированный всеми задачами блок.
• Tracer bullet analogy: в военной метафоре он говорит, что, например, каждая шестая пуля может быть трассирующей, чтобы дать feedback о направлении.
• AFK script: once.sh считывает локальные Markdown-issues, кладёт их в переменную issues, берёт последние 5 коммитов и запускает Claude Code с permission mode, позволяющим edits.
• Parallelization trade-off: он обсуждает случай, где одновременно решаются 4 задачи, и признаёт проблему: это увеличивает объём code review и конфликтует с маленькими self-contained PRs.
• Ralph run: после цикла появилась summary-выдача, коммит и проверяемый результат; затем были запущены feedback loops.
• Тесты: запускались npm run test и npm run type check; возникла 1 type error, которую агент исправил.
• Итог тестов: в репозитории после демонстрационной реализации стало 284 теста.
• Manual QA: при проверке dashboard Мэтт вошёл как студент Emma Wilson, прошёл Intro to TypeScript lesson и увидел ошибку SQLite из-за отсутствующей таблицы Point events; это стало примером того, почему manual QA необходим.
• Sandcastle: Мэтт потратил примерно 1 неделю на создание Sandcastle.
• Sandcastle roles: planner выбирает задачи для параллельной работы; implementer работает в sandbox; merger объединяет ветки; для implementation он использует Sonnet, для review — Opus.
• Финальный workflow: идею «жарят» до alignment, превращают в PRD, PRD — в параллелизуемые задачи, реализацию отдают агентам, затем делают QA/code review и возвращают найденные вопросы в Kanban.

Методы и фреймворки

• Smart zone / dumb zone. Модель качества LLM-сессии: сначала модель наиболее «умная», затем по мере накопления контекста деградирует. Причина объясняется через квадратичный рост attention relationships между токенами.
• Clear vs compact. Compacting сжимает историю в summary, но создаёт накопительный «осадок». Clearing сбрасывает состояние к базовому system prompt; Покок предпочитает предсказуемость reset-а.
• Ralph Wiggum loop. Подход: задать destination, затем просить ИИ делать небольшие изменения, приближающие к цели. Мэтт признаёт, что это работает, но хочет больше структуры.
• Grill Me Skill. Интервьюирующий навык: AI задаёт вопросы по одному, проходит дерево решений, разрешает зависимости и предлагает recommended answer на каждый вопрос.
• Design Concept. Через Брукса Покок объясняет, что нужно не просто иметь документ, а достичь общего понимания между человеком и агентом.
• PRD as destination document. PRD фиксирует problem statement, user problem, solution, user stories, implementation decisions и test-critical decisions.
• Kanban Board as DAG. Задачи имеют blocking relationships; независимые задачи можно брать параллельно. Это превращает план не в линейную последовательность, а в граф.
• Tracer bullets / vertical slices. Срез должен проходить через необходимые слои системы — schema/service/UI — и давать видимый результат, который можно проверить.
• AFK Agent / night shift. Человек делает дневную смену: планирование, alignment, структура. Агент делает ночную смену: implementation по подготовленному backlog.
• TDD / red-green-refactor. Агент сначала пишет failing test, убеждается в red, затем пишет implementation, добивается green и рефакторит.
• Fresh-context code review. Review запускается отдельно, в чистом контексте, чтобы reviewer был в smart zone.
• Manual QA as taste injection. QA — это не только проверка «работает/не работает», но и место, где человек вносит judgement, вкус и понимание продукта.
• Deep modules vs shallow modules. По John Ousterhout: deep module имеет маленький интерфейс и много скрытой функциональности; shallow modules — множество мелких файлов/exports с запутанными зависимостями.
• Improve Codebase Architecture Skill. Навык сканирует кодовую базу и ищет связанные группы модулей, которые можно углубить и тестировать как единое целое.
• Push / Pull для стандартов кодирования. Push — всегда отправлять инструкцию агенту, например через Claude.md; pull — дать агенту доступ к навыку/документу, который он может сам запросить.
• Sandcastle. TypeScript-библиотека для параллельных agent loops: создаёт git worktree, помещает его в Docker container, запускает CLI, даёт отдельные branches и затем мержит результаты.

Ключевые идеи и концепции

• AI coding — не отказ от software engineering, а усиление требований к нему. Чем больше кода делегируется агентам, тем важнее архитектура, feedback loops, тестируемость и качество задач.
• Большой context window — не silver bullet. Для поиска по большим корпусам 1M context полезен, но для coding-решений модель всё равно деградирует после условной smart zone.
• Документ не заменяет понимание. PRD полезен как destination artifact, но главная ценность создаётся раньше — в разговоре, где человек и модель приходят к общей design concept.
• Код остаётся главным источником истины. Подход «правим specs, не смотрим код» приводит к потере контроля. Покок называет код battleground именно потому, что качество в итоге живёт в кодовой базе.
• ИИ по умолчанию стремится к горизонтальному плану. Это удобно для текста, но плохо для инженерного feedback: пока не готов UI, API и БД вместе, нельзя проверить настоящую работу фичи.
• Вертикальные срезы создают раннюю проверяемость. Пример с баллами на dashboard хорош именно потому, что после первого среза человек видит outcome, а не только слой БД.
• Sub-agents помогают не засорять главный контекст. Исследователь может сжечь десятки тысяч токенов, но вернуть orchestrator только релевантные выводы.
• Implementation можно делегировать, planning — нет. Покок проводит границу: alignment, продуктовые решения и архитектурные границы требуют человека; кодирование подготовленных задач может идти AFK.
• Review и QA становятся узким местом. Если агенты создают больше кода, человек неизбежно больше ревьюит. Готового ответа, как сохранить маленькие PRs при агрессивном parallelization, в видео не заявлено.
• Frontend остаётся сложным для AI. Мэтт скептически относится к способности текущих browser/MCP/multimodal tools стабильно делать хороший UI в зрелой кодовой базе; он предпочитает генерировать несколько прототипов и выбирать глазами человека.
• Documentation rot опасен именно для агентов. Старый PRD может быть найден моделью как «истина», хотя код и требования давно ушли вперёд.
• Deep modules помогают сохранить ментальную карту. Разработчик знает форму и контракт модуля, но может делегировать его внутреннюю реализацию.
• Качество агентного workflow упирается в тесты. Без тестов и type checks агент не получает сигналов и начинает «работать вслепую».

Практические выводы и шаги

• Начинайте AI-задачу с минимального контекста: нужный skill, краткое описание задачи, релевантные файлы — без огромного system prompt.
• Для размытой продуктовой идеи запускайте Grill Me и отвечайте на вопросы до shared understanding.
• На вопросах Grill Me уточняйте не только требования, но и границы: что начисляет points, нужна ли retroactive backfill, где будет UI, как устроены levels, streaks и completion.
• После Grill Me превращайте accumulated conversation в PRD как destination document.
• Не тратьте много времени на идеальную полировку PRD; используйте его как опору для дальнейшего разбиения.
• Просите AI предложить affected modules и проверяйте, соответствует ли это реальной архитектуре.
• Конвертируйте PRD в Kanban-issues с blocking relationships, а не в линейный phase plan.
• Перепроверяйте задачи на vertical slicing: первый срез должен включать хотя бы минимальную схему/сервис/UI-проявление.
• Помечайте задачи, которые можно выполнять AFK, и отдавайте их агенту только после human-validated planning.
• В AFK-loop передавайте агенту локальные issue files, последние коммиты, приоритеты и clear instruction выбирать следующую доступную задачу.
• Требуйте TDD: сначала failing test, затем implementation, затем feedback loops.
• Запускайте npm run test, npm run type check и другие проверки, соответствующие проекту.
• Делайте code review в свежем контексте; не ревьюйте код тем же агентом, который только что дошёл до переполненного состояния.
• На review сначала смотрите тесты, затем implementation, затем руками проверяйте пользовательский сценарий.
• Результаты QA возвращайте обратно в Kanban как новые issues или blockers.
• Не храните устаревающие PRD/планы как живую документацию без статуса; если используете GitHub issues, закрытый статус даёт визуальный сигнал завершения.
• Улучшайте кодовую базу под AI: ищите shallow modules, объединяйте связанные куски в deep modules с ясным интерфейсом и тестовой границей.
• Для standards: implementer пусть подтягивает стандарты через pull/skills, reviewer получает standards явно через push.
• Для параллельной работы агентов используйте sandbox/worktree/branch isolation; в видео для этого показан Sandcastle.

Ссылки/таймкоды

• 00:00:51 — главный тезис: AI — новая парадигма, но software engineering fundamentals всё ещё работают.
• 00:03:00 — начало блока про ограничения LLM.
• 00:03:22 — smart zone / dumb zone.
• 00:04:05 — ориентир: около 40% / 100k токенов; 1M и 200k windows не отменяют деградацию.
• 00:04:43 — связь с классическими советами: не брать слишком большую задачу.
• 00:06:48 — Ralph Wiggum loop: destination + small incremental changes.
• 00:07:30 — LLM как персонаж из Memento: постоянное забывание и reset.
• 00:10:29 — compacting vs clearing; Покок предпочитает clear.
• 00:12:35 — критика specs-to-code / vibe coding под другим именем.
• 00:13:40 — «код — ваше поле битвы».
• 00:14:10 — демонстрационный client brief от Sarah Chen про Cadence и gamification.
• 00:15:44 — запуск Grill Me skill.
• 00:16:19 — ключевая формулировка Grill Me: relentlessly interview every aspect.
• 00:16:59 — Frederick P. Brooks и design concept.
• 00:17:42 — sub-agent потратил 93.7k токенов на Opus.
• 00:18:08 — определение sub-agent как отдельного LLM с isolated context window.
• 00:18:42 — первый вопрос Grill Me: points economy.
• 00:19:41 — вопрос про retroactive points/backfill.
• 00:20:56 — Grill Me может занимать 40/80/100 вопросов и около часа.
• 00:23:27 — Spec Kit / Open Spec / Taskmaster и позиция Покока: лучше контролировать стек самому.
• 00:25:00 — кто должен участвовать в Grill Me в больших командах.
• 00:26:44 — два типа задач: human-in-the-loop и AFK.
• 00:30:12 — после grilling накопилось около 25k токенов полезного alignment context.
• 00:30:37 — PRD как destination document.
• 00:31:31 — навык write-a-PRD и структура PRD.
• 00:32:49 — AI предлагает modules to modify.
• 00:34:54 — PRD содержит solution, user stories и 18 user stories.
• 00:35:15 — почему Мэтт не читает PRD целиком.
• 00:37:26 — Q&A про 1M context windows.
• 00:38:20 — 1M context полезнее для retrieval, чем для coding.
• 00:40:10 — переход от PRD к Kanban board.
• 00:40:36 — decomposition в 5 задач.
• 00:42:00 — tracer bullets / vertical slices.
• 00:42:56 — ИИ склонен писать горизонтально.
• 00:43:48 — вертикальные срезы как способ получить feedback через все слои.
• 00:45:14 — правила vertical slice и создание issue files.
• 00:46:41 — хороший vertical slice: points for lesson completion visible on dashboard.
• 00:49:43 — независимые issues и parallelizable blocking graph.
• 00:50:34 — Kanban как DAG для параллельной работы агентов.
• 00:52:17 — человек выходит из loop на этапе implementation.
• 00:53:23 — day shift / night shift metaphor.
• 00:54:26 — once.sh: читает issues из Markdown.
• 00:54:48 — последние 5 commits как контекст для агента.
• 00:55:21 — Docker sandbox для AFK-loop.
• 00:56:12 — AFK-task instructions.
• 00:57:09 — приоритеты Ralph loop.
• 00:57:24 — instruction: use TDD.
• 00:58:32 — out-of-scope decisions в PRD.
• 00:59:01 — проблема: агенты создают больше кода, чем можно легко ревьюить.
• 01:02:35 — frontend/prototyping и ограничения AI в визуальном UI.
• 01:05:12 — AI может делать review, но лучше в свежем контексте.
• 01:06:48 — TDD как необходимый метод для агентов.
• 01:07:16 — failing test first.
• 01:08:24 — TDD снижает риск «жульничества» тестов.
• 01:09:04 — результат Ralph loop: summary, commit, проверяемый outcome.
• 01:10:18 — качество feedback loops как потолок качества AI coding.
• 01:10:36 — npm run test, npm run type check, 1 type error.
• 01:10:59 — 284 tests in repository.
• 01:12:37 — manual QA как критический этап.
• 01:13:06 — опасность автоматизировать idea/research/prototype/QA полностью: получается slop.
• 01:14:22 — John Ousterhout и shallow modules.
• 01:17:03 — deep modules: small interface, lots of functionality.
• 01:18:34 — gamification service как новый deep module.
• 01:20:19 — проектировать интерфейсы, делегировать реализацию.
• 01:21:28 — Improve Codebase Architecture skill.
• 01:23:04 — совет: запустить этот skill в своём репозитории.
• 01:24:12 — documentation rot на примере старого PRD.
• 01:25:08 — BEADS framework: не тестировал, но похоже на управление Kanban/tasks.
• 01:27:15 — не стоит чрезмерно оптимизировать PRD; усилия лучше вкладывать в QA.
• 01:28:18 — push vs pull для инструкций и стандартов.
• 01:29:12 — standards via pull для implementer.
• 01:29:18 — standards via push для reviewer.
• 01:29:50 — Sandcastle: около недели разработки.
• 01:30:11 — Sandcastle как TypeScript library для loops.
• 01:31:02 — planner выбирает задачи для параллельной работы.
• 01:31:32 — на каждую задачу создаётся sandbox и implementer.
• 01:31:56 — merger agent объединяет ветки и чинит merge/type/test problems.
• 01:32:33 — Sonnet для implementation, Opus для review.
• 01:33:01 — Improve Architecture нашёл candidates; quiz scoring service без тестов.
• 01:34:07 — финальное резюме всего процесса.
• 01:34:50 — QA создаёт новые задачи для Kanban.
• 01:35:29 — workflow не навязывается как единственно правильный; это то, что у Покока работает.
• 01:35:37 — финальный совет: читать старые книги по software engineering.