Введение
Главная боль работы с любым кодогенерирующим ИИ — не в том, что он плохо пишет код. Он-то как раз пишет неплохо. Проблема в том, что вы сами не всегда знаете, что именно просите. «Сделай мне авторизацию» — это пожелание, а не задача. Под этой фразой может скрываться JWT с refresh-токенами и rate-limiting, а может и наивный сравнение пароля в открытом виде. Модель угадает что-то посередине, вы вздохнёте и пойдёте переписывать.
EvanFlow — свежий открытый плагин для Claude Code от разработчика Эвана Клема (evanklem), — переворачивает этот разговор. Сначала вы пишете тесты, описывающие поведение, и только потом ИИ пишет реализацию. Тест становится исполняемой спецификацией — однозначной, проверяемой, и, что особенно ценно, такой, которую модель не может подделать словами. Либо тест зелёный, либо нет. Серых зон не остаётся.
И вот что мне в этом нравится больше всего: это не очередной маркетинговый «AI-first фреймворк», а тонкая оркестрация из 16 связанных скиллов и пары субагентов с жёсткими правилами. Давайте разберём, как это устроено внутри, и почему за этим стоит следить даже если вы не планируете использовать именно EvanFlow.
Что внутри: не просто TDD, а полноценный конвейер
В исходной новости звучит формулировка «строгий цикл TDD», и это правда — но только часть правды. На деле EvanFlow выстраивает целый маршрут:
brainstorm → plan → execute (sequential or parallel) → tdd → iterate → STOP
Запускается всё одной командой — буквально фразой «let's evanflow this», после которой стартует скилл-дирижёр evanflow-go. Дальше каждая стадия имеет чекпоинт, на котором агент останавливается и ждёт вашего «ок». Это не автопилот. Это, как формулирует сам автор, «дирижёр, а не самокат».
Раскладка такая:
🧠 Brainstorm — модель уточняет намерение, предлагает 2–3 архитектурных подхода и сразу прогоняет их через «grill» (стресс-тест из неудобных вопросов). Без вашего одобрения дальше не идёт.
🗂️ Plan — сначала рисуется файловая структура (с применением «deletion test» — что мы потеряем, если этот модуль удалить?), потом задачи дробятся на «откусываемые» куски.
⚙️ Execute — выполнение задача за задачей с инлайн-проверкой. Если упёрлось в блокер — стоп, поднимаем вопрос наверх.
🧪 TDD (vertical-slice) — один падающий тест, минимальная реализация, повторяем. Тесты пишутся через публичный интерфейс, а не через внутренности — поэтому переживают рефакторинг.
🔁 Iterate — модель перечитывает свой же diff «свежими глазами», прогоняет typecheck/lint/тесты, делает скриншот UI через headless Chromium и сверяется с чеклистом «Five Failure Modes». Жёсткий лимит — 5 итераций. Не справился — выходим, зовём человека.
🛑 STOP — никаких авто-коммитов, авто-stage и автоматических PR. Агент рапортует и замолкает.
Этот «STOP» — на самом деле принципиальная вещь, к которой я ещё вернусь.
Почему vertical-slice TDD, а не классический
Классический TDD пишут «снизу вверх»: тестируем хелпер, потом класс, потом модуль. У ИИ-агента это превращается в катастрофу — он начинает мокать всё подряд, пишет тесты на приватные методы, и через два часа у вас сто зелёных тестов, а интеграции нет.
Vertical-slice TDD идёт через тонкую вертикаль через все слои сразу: один пользовательский сценарий — один тест по публичному API — минимальная сквозная реализация. Это ровно то, что в академической литературе называется behaviour-driven testing, и для ИИ это работает в разы лучше: модель не может «срезать угол», потому что тест видит результат снаружи, через тот же интерфейс, что и реальный пользователь.
Самая интересная цифра в репозитории
Если читать README внимательно, там между делом упомянуты вещи, от которых становится не по себе. Вот те, что зацепили меня сильнее всего:
📊 Согласно исследованию TDD для генерации кода (arXiv 2402.13521), около 62% сгенерированных LLM ассертов в тестах — неверные. То есть когда вы просите модель «напиши тесты», она с большой вероятностью пишет тесты, которые пройдут даже если в коде есть баг в один символ. EvanFlow явно вкручивает в скилл evanflow-tdd правило: проверь, что одиночная ошибка в реализации действительно завалит тест. Это ровно та проверка, которую большинство live-coding-демонстраций ИИ-агентов скромно пропускают.
📊 По данным индустриальных отчётов 2025–2026, примерно 65% провалов корпоративных ИИ-агентов в коде — это context drift, а не упирание в лимит токенов. Модель вроде бы помнит контекст, но начинает противоречить ранее принятым решениям. EvanFlow вводит отдельный скилл evanflow-compact с симптомами дрейфа: «агент задаёт уже отвеченный вопрос», «противоречит собственному решению пятью сообщениями назад». Это, пожалуй, самая недооценённая проблема в текущей волне «сделай мне приложение за 10 минут».
📊 Хук block-dangerous-git.sh блокирует git push, git reset --hard, git clean -f, git branch -D, git checkout ., git restore . на уровне PreToolUse. Если вы хоть раз ловили момент, когда автономный агент случайно сделал reset --hard HEAD~5 — вы понимаете, насколько это критично. Хук, кстати, требует jq для парсинга JSON, и, по предупреждению автора, при отсутствии jq молча перестаёт работать — это, на мой взгляд, единственный реальный косяк дизайна, потому что failure-mode тут хуже всего: вы думаете, что защищены, а вы нет.
Two-agent dance: почему read-only субагент — это гениально
Самая красивая инженерная идея в EvanFlow — разделение ролей через ограничение инструментов, а не через системный промпт.
В репозитории есть два кастомных субагента:
🛠️ evanflow-coder — может Read, Edit, Write, Glob, Grep, Bash, TodoWrite. То есть это «писатель кода».
👁️ evanflow-overseer — может только Read, Grep, Glob. Ни Edit, ни Write, ни Bash. Это ревьюер, и он физически не способен что-либо исправить. Только написать отчёт.
Почему это важно? Если дать ревьюеру право чинить — он будет чинить. Тихо, незаметно, без вашего внимания, и вы потеряете контроль над тем, что вообще изменилось. А когда у ревьюера руки физически связаны, он вынужден формулировать претензии словами — и вы видите ровно те проблемы, которые модель сама в себе нашла. Это ровно тот подход, который Anthropic разрабатывает в своих best practices для агентов: разделять полномочия через возможности (capabilities), а не через инструкции, потому что инструкции модель может «забыть», а отсутствующий инструмент — нет.
Для параллельных задач эти двое работают парами: на каждый независимый юнит свой evanflow-coder + свой evanflow-overseer, плюс отдельный «integration overseer», который гоняет интеграционные тесты на стыках. Эти интеграционные тесты — исполняемый контракт между подсистемами. Если одна сторона начнёт дрейфовать — общий тест упадёт, и дрейф остановится в зародыше.
Five Failure Modes: чеклист, который должен быть прибит над столом каждого
Перед каждым «done» агент проходит по пяти сценариям провала, специально подобранным из failure-таксономий 2025–2026. Я выпишу их явно, потому что это полезно даже без EvanFlow:
🪤 Hallucinated actions — модель выдумывает имена файлов, переменных окружения, ID сущностей, методы библиотек. Самая опасная категория, потому что выглядит правдоподобно. Правило EvanFlow: не уверен — остановись и спроси.
🪤 Scope creep — попросили починить логирование, заодно переписали половину middleware. Классика.
🪤 Cascading errors — одна неверная ранняя предпосылка тянет за собой 30 последующих неверных решений.
🪤 Context loss — забыли договорённость, принятую в начале сессии.
🪤 Tool misuse — использовали grep там, где нужен AST-парсер, или Bash там, где есть специализированный API.
Эти пять — буквально пять способов, которыми ИИ-агент может тихо сломать вам проект, и наличие явной проверки против каждого — то, что отличает плагин от очередной демо-игрушки.
Где это место в общем тренде
Исходная новость справедливо упоминает, что EvanFlow — часть более широкого движения. Действительно, в open-source последний год мы видим расцвет «агентских контуров» вокруг Claude Code и аналогов: проекты вроде mattpocock/skills (откуда EvanFlow позаимствовал vertical-slice TDD, deep modules, design-it-twice), superpowers Джесси Винсента (parallel agent dispatch, verification-before-completion), и упомянутые в новости evo (автономный исследовательский цикл с самонастройкой метрик) и humansintheloop-dev (жёсткое разделение «человек = спецификация, ИИ = исполнение»). Все они сходятся в одной точке: давать ИИ структуру и проверяемые границы, а не больше свободы.
Это, на мой взгляд, главный сдвиг 2026 года. Год-полтора назад все спорили, насколько умной получится модель. Сейчас спор сместился: «насколько хорошим может быть рабочий процесс вокруг модели?». И ответ, кажется, — намного лучше, чем мы думали, если перестать пытаться скармливать ей одно гигантское «сделай хорошо» и начать строить ступеньки.
Моё мнение: это то, как должна выглядеть работа с ИИ
Если честно, после внимательного чтения README я хочу попробовать EvanFlow в собственных проектах — особенно для FastAPI-микросервисов, где edge-кейсы валидации и обработка ошибок обычно отжирают столько же времени, сколько и happy path. Тесты как контракт — здесь это работает идеально.
Но мне кажется, главная ценность EvanFlow — даже не в конкретных скиллах, а в философии «STOP». Слишком много современных агентских инструментов идут по противоположному пути: «пусть ИИ сам коммитит, сам создаёт PR, сам мержит, а ты только проверяй». Это, мягко говоря, не работает. Модель отлично оптимизирует то, что можно измерить, и совершенно не замечает того, что нельзя — а в коммите без ревью невидимого больше, чем видимого. Жёсткий запрет на авто-коммит и обязательная пауза перед каждым git-write — это здравый смысл, который, к сожалению, в индустрии становится исключением.
И ещё одно: лимит «5 итераций — и зовём человека» кажется банальностью, но за ним стоит реальное наблюдение. Модели, оставленные в бесконечном цикле «попробуй ещё раз», начинают деградировать — каждая следующая попытка ломает чуть больше, чем чинит. Жёсткий cap — это страховка не от модели, а от самонадеянности оператора, который думает, что «ну ещё одна итерация, и всё получится». Не получится. Это нужно встраивать в процесс.
Заключение
EvanFlow — не серебряная пуля, и его автор это честно подчёркивает: «proposals to add ceremony or auto-actions will be politely declined». Это инструмент для тех, кто понимает, что ИИ — мощный, но беспринципный исполнитель, и которому нужны рамки. Тесты как контракт, чекпоинты вместо автопилота, capability-based ограничения для субагентов и явный чеклист failure modes — всё это выглядит как набор практик, которые в ближайший год превратятся из экзотики в стандарт.
Прогноз простой: фразы вроде «я попросил Claude сделать фичу» постепенно будут вытесняться формулировками типа «я написал acceptance-тесты, и Claude довёл их до зелёного». И это, пожалуй, самая здоровая трансформация индустрии за последнее время — потому что она возвращает разработчику роль архитектора, а ИИ задвигает в роль очень быстрого, очень дисциплинированного, но всё ещё подчинённого исполнителя. Где, по совести, ему сейчас и место.
Источники
🔗 Оригинальная новость: Как превратить ИИ из соавтора в подчинённого: революция в разработке с EvanFlow (telegra.ph)
🔗 Репозиторий проекта: github.com/evanklem/evanflow
🔗 Источник идей vertical-slice TDD, deep modules, design-it-twice: mattpocock/skills
🔗 Источник идей parallel agent dispatch и verification-before-completion: superpowers (Jesse Vincent)
🔗 Anthropic 2026 Agentic Coding Trends Report: resources.anthropic.com
🔗 9 Critical Failure Patterns of Coding Agents (DAPLab, Columbia): daplab.cs.columbia.edu
🔗 Test-Driven Development for Code Generation (источник цифры о 62% ошибочных ассертов): arXiv 2402.13521
🔗 Документация Claude Code: claude.com/claude-code