Я Java-разработчик: пишу на Java 5 лет, из них последние 3 — в коммерческих проектах. Последние 10 месяцев из которых был тимлидом небольшой команды. Сейчас месяц как собираю портфолио через Spec-Driven Development — связку Spec Kit и Claude Code. Первый проект в этой методологии —smart-task-bot, Telegram-бот для задач на Spring Boot 3.5.
Идея написать именно Telegram-бот пришла в самый удачный момент: как раз когда Telegram заблокировали в России — есть шанс стать автором последнего бота в Рунете!) Если серьёзно — мне нужен был простой, но не тривиальный проект для обкатки SDD, и бот хорошо подходил.
С шести вечера до двух ночи одного вторника я прошёл полный SDD-цикл — от конституции проекта до MVP с шестью командами, миграциями PostgreSQL, напоминаниями по расписанию и мержем в main.
Восемь часов. Один вечер. Рабочий продукт.
Но не это главное. Главное — что в моём инженерном процессе за этот вечер что-то сдвинулось. Разбираю, что именно — и где методология мне мешала.
[ССЫЛКА: GitHub smart-task-bot]
Хронология того вечера
Покажу реальный git log без прикрас. Это чтобы дальше разговор шёл не про абстрактную методологию, а про конкретный таймлайн.
Что произошло
Запустилspeckit.constitution. Конституция проекта написана
speckit.specify→spec.mdготов (34 минуты)
speckit.plan→plan.mdготов (27 минут)
speckit.tasks→tasks.mdготов (12 минут)
Реализация Фазы 1 — скелет приложения
Фаза 2 часть 1 — миграции Liquibase и JPA-сущности
Фаза 2 часть 2 — репозитории и инфраструктура бота
Первый запуск — бот отвечает на/start
Команда/newtaskреализована
Команда/tasksреализована
Команда/remindс напоминаниями по расписанию
Команда/doneреализована
README +.env.example+ финальная проверка
Merge ветки в main
Время между коммитами — реальное время кодинга. За 8 часов — спека, план, задачи, шесть рабочих команд, миграции, репозитории, сервисы, хендлеры, Javadoc, README. Полный MVP одной сессией.
Что конкретно умел бот в 2:20: регистрация пользователя с выбором часового пояса (/start), создание задачи (/newtask), список активных задач (/tasks), установка напоминания с доставкой в Telegram по cron-расписанию (/remind), отметка выполнения (/done), help-меню.
Стек: Java 21, Spring Boot 3.5, PostgreSQL 15, Liquibase, TelegramBots Spring Boot Starter 6.9.7.1, Maven. Всё — как в обычном продакшн-проекте.
Дальше разбираю, за счёт чего это случилось и что Spec Kit сделал с моим процессом.
Сдвиг первый: я смотрел на проект как пользователь, а не как разработчик
Обычно, когда я беру новую технологию (в моём случае — Telegram Bot API), первый час уходит на то, чтобы разобраться в документации и понять, как эта штука устроена технически. Только после этого можно думать про продукт.
В тот вечер я начал сspec.md. Вот фрагмент изspecs/001-task-bot-mvp/spec.md:
Яписал спеку, не зная, как будет устроена авторизация Telegram, и не зная, как отдаются сообщения в бот. И это нормально — я описывал продукт, а не реализацию. Вопросы «а как это сделать технически» пришли позже, во времяplan.md, когда Claude предложил конкретную библиотеку и конкретную структуру модулей.
Раньше моя готовка к проекту былатехнической: найти документацию, пойти по туториалу, собрать hello world, потом думать про фичи. Сейчас готовка сталаархитектурной: что должно работать, в какой последовательности, какие edge cases учесть. Техническая часть —после, и её значительную часть можно отдать Claude Code.
Важный нюанс: это не «теперь не надо думать». Думать нужнобольше, просто о других вещах. Когда вы пишетеspec.md, у вас нет права быть ленивым — надо перечислить все сценарии, все ошибки, все неочевидные случаи. Это инженерная работа в чистом виде, без технического шума.
Я давно искал, как более точно управлять AI-ассистированной разработкой. Спецификация как первый шаг стала той самой находкой, которая меня вдохновила на все последующие проекты.
Сдвиг второй: делегирование никуда не делось, сменился исполнитель
10 месяцев я руководил небольшой командой — и делегировал задачи. Описывал, что нужно сделать, объяснял граничные случаи, принимал результат, ревьюил, возвращал на доработку.
Сейчас с Claude Code я делаюровно то же самое. Описываю задачу вtasks.md, Claude Code делает, я ревьюю, иногда возвращаю на доработку. Смысл не поменялся — поменялся исполнитель.
Это наблюдение, на мой взгляд, точнее описывает текущее состояние AI-coding, чем громкие лозунги «AI заменит разработчиков». Инструменты стали лучше. Инженерная работа — проектирование, делегирование, ревью — нужна ровно в той же форме, что и пять лет назад. Просто раньше вы делегировали человеку, а теперь — модели.
Claude Code — инструмент, а не коллега. Он может не заметить неоптимальность архитектурного выбора, взять популярную библиотеку вместо правильной для задачи, упустить edge case, который вы проговорили два часа назад в другом чате. Поэтому код надо читать. Каждый PR — ваш PR, независимо от того, кто его написал.
Сдвиг третий: два чата — один для думания, другой для исполнения
К концу первого вечера я понял одну рабочую схему, которую потом использовал во всех последующих проектах.
Claude Code живёт в терминале IDEA и пишет код. Это основной инструмент: он генерирует спеки черезspeckit.*, пишет файлы, запускает команды. Но есть нюанс: по умолчанию Claude Code стартует с чистого контекста в каждой новой терминальной сессии. История сохраняется в~/.claude/projects/, и её можно поднять флагами--continueили--resume, но на практике это не всегда работает надёжно — есть активные баги с восстановлением контекста. Проще держать внешний носитель контекста, чем полагаться на resume.
Поэтому параллельно я держуотдельный чат с Claude. Это мой внешний блокнот контекста. Там я обсуждаю решения перед тем, как дать команду в Claude Code. Там остаются цепочки «почему мы выбрали именно такой подход», «в какой фазе SDD-цикла мы сейчас», «что обсудили два дня назад и к чему пришли».
Потом нужный кусок обсуждения япереношув Claude Code как промт или контекст — и он кодит. Получается разделение:думание — в отдельном чате, исполнение — в терминале.
Это не очевидная схема — мне её никто не подсказывал, она выработалась сама. Если вы начинаете со Spec Kit — рекомендую сразу так и делать, экономит часы фрустрации.
Что в SDD работает плохо
Если бы в статье не было этого раздела, она стала бы рекламой Spec Kit. А она — честная оценка.
Claude Code переспрашивает разрешение на каждое действие.Каждая операция записи, каждыйbash-вызов — подтверждение. В первый вечер это мешало: бот во время активной работы постоянно останавливается и спрашивает. Решается запуском в режиме с расширенными доступами — флагом в конфиге. Ищется за 5 минут в документации, но в первый вечер это стоит знать заранее.
Тесты вtasks.mdоткладываются на конец.Мой инженерный вкус — писать тест вместе с фичей. Spec Kit выдаётtasks.md, где вся фаза тестирования идёт в конце — после реализации всех фич. Сначала меня это смутило. Потом я понял — это тоже работает, просто по-другому: у вас есть цельная картина перед написанием тестов, вы лучше видите, что именно тестировать. Номенее защищённый процесс: если заложили архитектурную ошибку, она не вскроется, пока вы не дойдёте до тестов.
Мой практический вывод:выполнятьtasks.mdпо одной фазе, коммитить после каждой. Не «запускать все задачи разом», хотя это соблазнительно. Пофазный режим даёт точки отката и осмысленный git log. Отдельный приятный бонус — если Claude сбился, вы теряете одну фазу, а не весь вечер.
Большие чаты теряют контекст.Если вы работаете в одном чате Claude Code весь вечер, к концу он начинает забывать детали начала. Это не катастрофа — просто не забывайте открывать новую сессию на каждой новой крупной задаче и давать короткий контекст вручную. Подробныеspec.md,plan.md,tasks.mdтут тоже помогают: Claude Code может их читать каждый раз заново, вместо того чтобы помнить.
Главная опасность
Самая главная ловушка, на мой взгляд, вообще не техническая.
Новый подход искушает не думать, а верить.Claude Code выдаёт готовое решение — хочется принять, не разбираясь. Особенно когда устал, особенно когда поздно, особенно когда «уже работает». Проблема в том, что ответственность за код всё равно на вас. Если в проде через полгода выстрелит баг — виноваты вы.
Я пытаюсь следовать простому правилу:на каждом архитектурном решении останавливаться и проговаривать его вслух (или писать в отдельный чат) — почему именно так, какие альтернативы, что мы теряем в этом выборе. Если не можете сами себе ответить — не принимайте решение. Попросите Claude разложить варианты, выберите сами.
Краткое резюме того, что сдвинулось за этот месяц:
- Подготовка к проекту стала архитектурной, а не технической. Время не сократилось, оно переместилось на более интересные задачи.
- Делегирование осталось, исполнитель сменился. Инженерная работа — проектирование, ревью, управление — нужна в прежнем объёме.
- Схема «отдельный чат для думания + Claude Code для исполнения» компенсирует короткую память терминала.
- За вечер реально собрать рабочий MVP не-тривиального проекта — еслиправильно подготовить спеку и план. Без спеки это станет vibe coding, у которого короткая дистанция.
- SDD — дисциплина, а не магия. Он не пишет код за тебя — он заставляет тебя писать спеку.
Цифры первого проекта:smart-task-bot, Java 21, Spring Boot 3.5, Maven, 15 коммитов в первый вечер, 6 команд бота, работающий MVP за 8 часов, релиз 1.0.0 с добавлением тестов, UX на кнопках и мультиязычности через отдельные SDD-спринты в последующие дни.
Что дальше
Это первая статья цикла про SDD. В следующих — разбор FullStack web-приложенияLifeSync(B2C-трекер привычек с гексагональной архитектурой, Kafka и jOOQ вместо JPA, React 19 + TypeScript, 251 тест).
Отдельной публикацией разберу практическую часть: как настроить Claude Code в IDEA, какой план выбрать, какие способы оплаты работают из России в 2026 году.
