MeowKit для Claude Code: проверяем, помогают ли жесткие этапы и TDD

Что именно проверяем

Гипотеза проста: жесткий процесс должен уменьшить число пропущенных требований и дефектов, но может увеличить длительность сессии, количество действий и размер контекста. Поэтому одного показателя «тесты прошли» недостаточно.

Нужны два независимых прогона одной задачи:

1. Контрольный прогон: обычный Claude Code с минимальными правилами проекта.
2. Экспериментальный прогон: тот же Claude Code, модель, код и запрос, но с активным процессом MeowKit.

В обоих случаях фиксируем четыре группы данных:

• результаты заранее подготовленного набора тестов;
• число итераций до приемлемого решения;
• полное время работы;
• объем и направленность изменений в Git.

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

Выбираем задачу без подыгрывания TDD

Подойдет небольшая, но не тривиальная задача из вашего репозитория: исправление пограничного случая, добавление валидации или изменение функции с несколькими ветвями. Она должна укладываться примерно в 15–40 минут ручной работы и не требовать внешних сервисов.

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

Карточка задачи

Цель:
  Кратко описать требуемое поведение.

Входные условия:
  Какие данные принимает изменяемый код.

Критерии приемки:
  1. Нормальный сценарий.
  2. Пограничный сценарий.
  3. Ошибочный сценарий.
  4. Существующее поведение не сломано.

Ограничения:
  - не менять публичный API без необходимости;
  - не добавлять зависимости;
  - не выполнять сетевые запросы;
  - не изменять файлы вне обозначенного модуля без объяснения.

Команда проверки:
  <команда тестов вашего проекта>

Это шаблон, а не описание проведенного редакцией теста. Заполните его реальным поведением своего проекта до запуска Claude Code. Иначе второй прогон невольно получит уточнения, появившиеся после первого.

Подготовка воспроизводимого стенда

Сначала убедитесь, что рабочее дерево чистое и текущий коммит сохранен удаленно либо доступен в локальной истории.

git status --short
git rev-parse HEAD
git branch --show-current

Если первая команда показывает изменения, не удаляйте их ради эксперимента. Зафиксируйте работу отдельным коммитом, сохраните ее удобным вам безопасным способом или создайте новую копию репозитория.

Создайте две ветки от одного исходного коммита:

git switch -c experiment/claude-baseline
git switch -c experiment/claude-meowkit HEAD

После этого вернитесь в контрольную ветку:

git switch experiment/claude-baseline

Для более надежной изоляции удобно использовать два рабочих дерева. Команды ниже создают дополнительные каталоги и ничего не удаляют:

git worktree add ../lab-baseline experiment/claude-baseline
git worktree add ../lab-meowkit experiment/claude-meowkit

Фиксируем исходное состояние

До запуска агента выполните штатные тесты отдельно в каждом рабочем дереве. Используйте команду именно вашего проекта: например, npm test, pytest, go test ./... или эквивалент. Не подставляйте команду из статьи вслепую.

# Выполнить в каждом рабочем дереве
git status --short
<команда тестов вашего проекта>

Запишите:

• исходный commit SHA;
• версию Claude Code и выбранную модель;
• команду тестов и ее результат;
• версию среды выполнения и менеджера пакетов;
• активные проектные инструкции;
• наличие пользовательских правил вне репозитория.

Последний пункт особенно важен. «Обычный Claude Code» перестает быть контрольной группой, если на него продолжают действовать глобальные агенты, навыки или правила с TDD.

Прогон A: обычный Claude Code

Откройте Claude Code в каталоге lab-baseline. Используйте новую сессию и один заранее сохраненный запрос. Не добавляйте подсказки, которых нет в карточке задачи.

Реализуй задачу из приведенной ниже карточки.

Сначала кратко изучи затронутый код. Затем внеси минимальные изменения,
выполни указанную команду проверки и сообщи:
1) какие файлы изменены;
2) какие проверки запущены;
3) что осталось непроверенным.

<вставьте неизмененную карточку задачи>

Одна итерация — это законченный цикл «запрос пользователя → работа Claude → ответ с результатом». Если после ответа приходится просить исправить тест, вернуть случайно удаленный код или выполнить пропущенную проверку, это новая итерация.

Не исправляйте код вручную между итерациями: тогда сравниваться будут уже не два процесса Claude Code, а две разные пары «человек плюс агент».

Прогон B: Claude Code с MeowKit

Откройте отдельную новую сессию в lab-meowkit. До запуска проверьте файлы комплекта как обычный код: какие инструкции загружаются постоянно, какие навыки вызываются по необходимости, какие агенты получают доступ к shell и какие hooks способны запускать команды.

Устанавливайте MeowKit только по инструкции той версии, которую вы действительно используете. Если комплект уже хранится локально, безопаснее сначала просмотреть список файлов и diff, а затем перенести его штатным способом. Статья намеренно не приводит универсальную команду установки: без привязки к конкретному репозиторию и версии такая команда была бы недостоверной.

Перед экспериментом зафиксируйте конфигурацию:

git status --short
git diff -- .claude CLAUDE.md
find .claude -maxdepth 3 -type f -print 2>/dev/null

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

Передайте Claude тот же запрос и ту же карточку задачи. Не дописывайте «обязательно используй TDD», если это уже обязанность MeowKit: иначе вы одновременно проверяете комплект и усиленный промпт.

Какие этапы должны быть видимыми

1. Анализ: агент находит затронутое поведение и ограничения.
2. Красный тест: новая проверка падает по ожидаемой причине.
3. Минимальная реализация: изменение делает тест зеленым.
4. Регрессия: запускается полный релевантный набор проверок.
5. Ревью: diff проверяется на лишние изменения и обход теста.

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

Как проверить результат независимо от рассказа агента

В каждом рабочем дереве выполните одну и ту же команду проверки самостоятельно. Затем соберите статистику Git.

git status --short
git diff --check
git diff --stat
git diff --numstat
git diff --name-only
<команда тестов вашего проекта>

git diff --check помогает обнаружить некоторые пробельные ошибки, но не оценивает корректность программы. --numstat показывает добавленные и удаленные строки по файлам; бинарные файлы обозначаются отдельно.

Проверка качества теста

Зеленый тест может быть бесполезным. Проверьте вручную:

• падал ли новый тест до реализации;
• проверяет ли он внешне наблюдаемое поведение, а не детали реализации;
• не заменена ли содержательная проверка слишком общим утверждением;
• не удалены ли существующие случаи;
• не исключен ли проблемный путь из запуска тестов;
• проходит ли тест после чистой установки зависимостей в доверенной среде.

Если красная фаза не была зафиксирована, отмечайте TDD как «не подтвержден», даже если итоговый diff содержит новый тест.

Таблица сравнения

Заполните таблицу фактическими данными своих двух прогонов. Нули и пустые значения нельзя заменять оценками «примерно».

Публиковать заполненную таблицу как результат можно только вместе с исходным commit SHA, запросом, конфигурацией, командами и правилами подсчета. Без них числа не воспроизводимы.

Как интерпретировать сравнение

MeowKit приносит практическую пользу, если при одинаковой задаче дает более надежное покрытие требований или предотвращает дефект, а дополнительное время остается приемлемым. Если оба решения одинаково корректны, сравнение сводится к цене процесса.

Больше времени, но найден пропущенный пограничный случай

Жесткие этапы, вероятно, окупились для этой задачи.

Больше тестов, но они повторяют существующие проверки

Количество выросло, доказательность — нет. Это не улучшение.

Меньше пользовательских итераций, но больше внутренних действий

Процесс снизил нагрузку на человека, однако мог увеличить вычислительную стоимость.

Большой diff без улучшения критериев приемки

Набор правил, вероятно, стимулировал избыточную архитектуру или рефакторинг.

Контрольный прогон сразу дал минимальное корректное решение

Для небольшой и понятной задачи MeowKit мог оказаться лишним слоем.

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

Типовые ошибки эксперимента

Второй прогон получает улучшенный запрос

После первого запуска становятся заметны неоднозначности задачи. Если исправить карточку только для второго прогона, преимущество будет связано с новым контекстом, а не с MeowKit.

Обе сессии работают в одной ветке

Вторая сессия увидит тесты, заметки или код первой. Используйте две ветки от одного коммита, лучше — отдельные worktree.

Считаются сообщения, а не итерации

Внутренние вызовы агентов и пользовательские уточнения — разные затраты. Фиксируйте их раздельно, если MeowKit показывает внутреннюю работу.

Зеленая полоса принимается за TDD

Тест, написанный после реализации, тоже может пройти. Для подтверждения TDD нужен наблюдаемый цикл «падение по правильной причине → минимальное исправление → успешный прогон».

Сравниваются разные модели или режимы

Модель, уровень разрешений, версия Claude Code и доступные инструменты должны совпадать. Иначе невозможно отделить эффект процесса от эффекта среды.

Размер diff принимается за качество

Маленький diff может пропустить важный случай, а большой — содержать оправданные тесты. Строки кода являются стоимостью проверки, а не самостоятельной оценкой качества.

Контекст оценивается на глаз

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

Ограничения

• Одна задача показывает поведение на одной задаче, а не универсальное превосходство процесса.
• Результаты агента могут различаться между повторами даже при одинаковом запросе.
• Эффект зависит от качества правил MeowKit и их соответствия стеку проекта.
• Подготовленные человеком критерии приемки сами по себе повышают дисциплину контрольного прогона.
• Работа нескольких агентов может сократить внимание разработчика, но увеличить суммарные вычисления.
• Локальные тесты не заменяют ревью безопасности, интеграционную проверку и наблюдение после выпуска.

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

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

Жесткий workflow полезен не потому, что в нем много агентов и файлов, а потому, что он делает проверяемыми важные переходы: требование сформулировано, тест действительно падал, реализация минимальна, регрессия запущена, diff просмотрен.

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

Начните не со включения всех компонентов, а с минимального профиля: карточка задачи, красный тест, реализация, полный прогон и ревью diff. Добавляйте специализированных агентов только там, где повторные измерения показывают конкретную пользу.