Всё сломалось. И это нормально.
Ты просишь Claude Code написать парсер CSV. Он пишет. Потом выясняется, что файл с BOM, а парсер не умеет. Ты объясняешь — он переписывает. Теперь ломается на кавычках внутри поля. Проходит час. Код всё ещё не работает. Знакомо?
Я перепробовал кучу подходов. Просто промпты — мусор. Ручное тестирование — долго. Но комбинация двух идей из наших предыдущих статей — исполняемых спецификаций и суб-агентов — дала наконец работающий процесс. Называю его Test + Spec Driven Development (TSDD).
Проблема: агент-оракул не угадывает
LLM — это не программист, а интерпретатор твоих мыслей. Если мысль размыта — код будет уродлив. Спецификация — это мост между хаосом в голове и строгими тестами. В статье про исполняемые спецификации я показывал YAML-контракты. Но это только полдела.
Второй кусок пазла — суб-агенты. Помните архитектуру из сценария с контекст-менеджером? Разделение ответственности: один агент — одна задача. Здесь то же самое.
Предостережение: не пытайтесь скормить весь spec одному агенту. Это гарантированный контекстный блот. Используйте суб-агентов для изоляции шагов (подробнее).
Что такое TSDD на практике?
TSDD — это процесс, где ты сначала пишешь исполняемую спецификацию (spec) и тесты, потом запускаешь каскад суб-агентов, которые генерируют, тестируют и фиксят код. Без итеративного пинг-понга с LLM. Всё автоматизировано.
«Спецификация — это не просто ТЗ. Это контракт, который машина может проверить до того, как запустит генерацию.»
В основе лежит тройка компонентов:
- Spec-файл — машиночитаемое описание поведения (YAML/JSON с Given-When-Then).
- Тестовый раннер — суб-агент, который прогоняет тесты из spec-файла и возвращает отчёт.
- Кодинг-агент — генерирует код, опираясь на spec и отчёт тестов.
На примере валидации email это выглядит так:
# spec/email_validator.spec.yml
test_cases:
- input: "user@example.com"
expected_result: valid
- input: "user@localhost"
expected_result: invalid
- input: "user+tag@example.com"
expected_result: valid
- input: ""
expected_result: invalid
Ты не говоришь агенту «сделай валидацию». Ты даёшь ему 20 конкретных примеров. Агент (точнее, суб-агент) генерирует функцию, которая проходит все тесты. Или возвращает ошибку с указанием проваленных кейсов.
Структура команды суб-агентов
| Роль суб-агента | Задача | Модель (на 2026) |
|---|---|---|
| Spec-парсер | Читает YAML, валидирует структуру, извлекает тестовые кейсы | DeepSeek R2 (быстрый) |
| Кодинг-агент | Генерирует код по spec и тестовому отчёту | GPT-5 / Claude 4 (мощный) |
| Тестовый раннер | Выполняет тесты, возвращает отчёт с diff | Gemini 2.5 Pro (детальный анализ) |
| Debug-агент | Анализирует ошибки, предлагает фиксы | Claude 3.5 Sonnet (оптимальный баланс) |
Это не просто абстракция — это Agent Skills на практике. Каждый суб-агент — это skill с процедурной памятью. Spec-парсер знает только YAML-схему. Кодинг-агент не трогает тесты. Изоляция контекста — ключ к стабильности.
Шаг за шагом: как внедрить
1 Пишем spec-файл
Не пиши спецификацию вручную — используй суб-агента конструктора. На вход — описание задачи на естественном языке. На выходе — готовый YAML с тестами. Совет: указывай граничные случаи и исключения. Агенты это любят.
2 Запускаем spec-парсер
Суб-агент проверяет YAML на корректность, генерирует модульные тесты (например, pytest). Он не пишет код — только подготавливает каркас тестов и документацию для следующего агента.
3 Генерируем код
Кодинг-агент получает spec, тестовые кейсы и промпт с инструкциями (Agent Skill). Он пишет реализацию, которая проходит все тесты. Если не проходит — возвращает ошибку с отчётом от тестового раннера.
4 Цикл debug-агента
Если тесты упали, в дело вступает debug-агент. Он анализирует diff, подсказывает кодинг-агенту, что исправить. Без контекстного дрейфа — возврат к spec, а не к истории диалога.
5 Деплоим
Код готов. Тесты зелёные. Можно пушить. Весь процесс — 5–15 секунд для небольшой функции. Без твоего участия.
Ошибки, которые я видел
- Слишком большой spec. Если тестов 50+, суб-агент тупит. Дроби spec на модули — как микрофронтенды.
- Забыли про Agent Skills. Без процедурной памяти агенты начинают изобретать велосипед. Упакуй знания: как писать тесты, какой стиль кода, какие библиотеки использовать.
- Все суб-агенты на одной модели. Дорого и медленно. Используй дешёвые модели для парсинга и тестов, дорогую — только для генерации кода. Вот как выжать максимум из маленьких моделей.
Лайфхак: Для тестового раннера используй Gemini 2.5 Pro — он даёт развёрнутые отчёты с примерами. Для debug-агента — Claude 3.5 Sonnet, он хорошо понимает причину ошибки. Экономия на GPT-5 составит до 70%.
А что с MCP?
Model Context Protocol (MCP) — это способ подключения внешних инструментов к агенту. В TSDD MCP используется для доступа к файловой системе, компилятору, тестовым раннерам. В статье про Agent Skills я описывал, как упаковать такие возможности. С MCP каждый суб-агент может запускать команды локально — это превращает spec в реальный цикл разработки, а не просто в симуляцию.
Резюме: не читай, а бери и делай
Хватит мучить LLM вопросами. Сделай так:
- Возьми готовый spec-файл из моей статьи про исполняемые спецификации.
- Разверни оркестратор суб-агентов (используй OpenAI Agents SDK или свой велосипед — разницы нет).
- Подключи Agent Skills для каждого суб-агента.
- Запускай цикл spec → код → тест → деплой.
Неочевидный совет: не генерируй код сразу под все кейсы. Сделай минимальную реализацию, проверь тесты, потом добавляй новые кейсы в spec. Это как Test-Driven Development, но без ручного написания тестов — их генерирует spec-суб-агент. И да, используй дешёвые модели для черновиков — DeepSeek R2 отлично справляется с 90% задач за копейки.
