Лид

Я 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 без прикрас. Это чтобы дальше разговор шёл не про абстрактную методологию, а про конкретный таймлайн.

Время между коммитами — реальное время кодинга. За 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:

## User Stories

As a user, I want to register in the bot with my timezone,
so that reminders arrive at the correct local time.

As a user, I want to create a task via /newtask <text>,
so that I can quickly capture something I need to do.

As a user, I want to set a reminder on a task,
so that the bot notifies me at the scheduled time.

Я писал спеку, не зная, как будет устроена авторизация 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 году.