Агент пишет не то, что нужно? Верните контроль

Как часто, работая с агентом над новой фичей, вы остаётесь недовольны результатом? То что-то не работает, то качество кода неприемлемо. Вы просите агента ещё раз и ещё раз, пытаетесь подобрать «идеальный» промпт — и всё равно не выходит. Уверен: чем дольше вы работаете с агентом, тем чаще разочаровываетесь. И это неудивительно: агент пишет код очень быстро — и именно поэтому ОЧЕНЬ просто получить ОЧЕНЬ много кода, который вам не нужен. Но код — это как раз простая часть. Настоящая задача инженера — строить системы: надёжные, быстрые и поддерживаемые. Именно за это нам и платят — и вот этого агент пока за нас не делает.

Индустрия быстро придумывает на это ответы, и один из самых заметных сейчас — Spec-Driven Development. Многие разработчики приходят к этой идее сами, а инструменты вроде OpenSpec и GitHub SpecKit дают полноценные методологии работы со спецификациями. Отличные инструменты, попробуйте. Но лично мне в них не хватает одного — удобного UX.

Я живу в IDE и не думаю, что они исчезнут. Код в них почти не пишу — а вот спецификации пишу. Вот только агент в IDE сегодня — это, по сути, приклеенное сбоку окно чата. Он почти не пользуется тем, в чём IDE сильна: структурированными документами, диффами, комментариями прямо по коду. Все общение с агентом идет непрерывном чатом, где контекст засоряется и тонет (вы же помните про U-образную кривую внимания — модель хуже держит середину длинного диалога?). Спецификация устроена иначе: это устойчивый, структурированный документ, который живёт вне отдельного чата и никуда не девается — я в любой момент могу к нему обратиться и указать на него агенту. Вот я и подумал: а может ли IDE стать местом, которое будет ПОМОГАТЬ мне писать эти самые спецификации и ПОМОГАТЬ контролировать то, как агент их реализует? Ведь даже идеальная спецификация не гарантирует результат: агент физически не выгрузит ВЕСЬ контекст из моей головы. А значит, написать спеку — это только половина дела; вторую половину, контроль того, как агент её реализует, кто-то тоже должен взять на себя.

По этим причинам я и начал работать над SpecBuddy. SpecBuddy — плагин для IDE от JetBrains, который превращает вашу IDE в пульт управления агентом: помогает писать спецификации, планировать работу и контролировать её выполнение. По-моему, без этих трёх вещей стабильного результата от агента не добиться.

Как это работает

Давайте посмотрим, как это работает. Представим, что перед нами, как перед разработчиком, стоит задача: реализовать систему управления запасами товаров в некотором интернет-магазине. Сценарий простой — пользователь хочет сделать заказ, но перед этим система должна убедиться, что нужный товар вообще есть в наличии. Звучит просто? На деле, даже если приложение совсем небольшое (а я специально беру несложный пример), возникает огромное количество вопросов. Сколько у нас складов? Есть ли между ними сообщение? Нужно ли резервировать товар под заказ — и если да, то в какой момент и на какой срок? Кого и когда уведомлять об исчерпании запаса? Как отслеживать перемещение товара? И так далее, и так далее. Если поставить такую задачу агенту в чате, часть этих вопросов он поднимет, на часть придумает ответ сам. Код, который мы в итоге получим, нам, скорее всего, не понравится — и мы встанем перед выбором: начать сначала, уточнив промпт, или вносить в чате правку за правкой.

SpecBuddy позволяет начать с намерения. Мы создаём черновик спецификации, пишем свой запрос (чем подробнее, тем лучше) и нажимаем кнопку Explode — она разворачивает короткое намерение в детальную спецификацию.

SpecBuddy запустит вашего любимого агента (Claude Code или Codex) и превратит черновик в полноценный документ. Мы его прочитаем. Идеально с первого раза почти никогда не выходит — и это нормально: первый черновик и не должен быть финальным, его задача — показать, как агент видит наш запрос сходу. Следующая задача, получить документ, который не страшно отдать агенту. Но как? В чате — только новыми сообщениями, которые тонут в контексте. А в SpecBuddy — классическим UX код-ревью: мы оставляем комментарии прямо в документе, и агент дорабатывает его по ним.

После пары итераций мы получаем документ, очень похожий на то, что нам нужно. Если задача несложная и вы уверены в силах агента, можно сразу отправить её на выполнение — останется только следить. Но в задачах посложнее сначала лучше создать план.

Возможно, вы уже знаете, как именно должна быть выполнена задача, — особенно если проект вам хорошо знаком. Тогда будет вдвойне обидно, если агент пойдёт каким-то другим путём. План можно точно так же отревьюить и отдать агенту на доработку — пока не появится уверенность, что он справится. Помните: поймать ошибку на этапе плана — дёшево. Это совсем не то же самое, что найти её в уже сгенерированном коде, откатить всё и молиться на попытку номер N. Здесь мы правим одну строчку плана до того, как написана хоть одна строчка кода.

После этого шаги плана можно поочерёдно запускать на выполнение. После каждого шага можно провести ревью кода и внести корректировки — как в код, так и в сам план. Можно думать об этом так: агент — автопилот, а инженер — командир. Автопилот ведёт, но курс задаёт человек и в любой момент может вмешаться.

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

Кстати, с комментариями SpecBuddy позволяет поступать по-разному. Мелкое замечание можно закрыть правкой одного лишь кода, не трогая план. А для критической архитектурной ошибки есть вариант жёстче — откатить результат последнего шага целиком и переделать его с нуля, уже с учётом замечания.

Так, с помощью SpecBuddy, я могу сначала точно задать направление работы, а затем контролировать её выполнение и вносить правки.

Параллельные задачи

Работая с агентами, я постоянно ловлю такой момент: агент ушёл выполнять шаг, а мне нечего делать — и я берусь за следующую задачу, запуская второго агента. Вот только два агента на одном проекте наступают друг другу на пятки: правят одни и те же файлы и затирают изменения. Управлять одним агентом — навык; управлять несколькими — уже работа.

Тут выручает git worktree — отдельная рабочая копия проекта, где правки не пересекаются. SpecBuddy берёт это на себя: запускаете новую спецификацию, не закрыв предыдущую, — и он предлагает завести под неё отдельный worktree и вести задачу там, изолированно, но с тем же пошаговым ревью. А когда всё готово — смержите ветки, руками (конечно нет) или агентом. Это тот же пульт управления — только теперь на несколько агентов сразу.

Наши планы

Сегодня SpecBuddy реализует один простой Spec-Driven-воркфлоу — и уже он даёт мне ощутимый эффект каждый день. Кстати SpecBuddy мы разрабатывали с самого начала использую сам SpecBuddy. Но этого конечно недостаточно. Планы у нас следующие:

• Больше воркфлоу. GitHub SpecKit и OpenSpec задали сильные методологии, но живут вне IDE.

• Больше агентов. Сейчас это Claude Code и Codex, на очереди OpenCode и другие. Любимый агент — ваш выбор, а не моё ограничение. Также планирую переписать интеграцию с агентом через ACP вместо терминала.

• Больше IDE. Я большой фанат IntelliJ-based IDE, но Cursor и VS Code тоже в планах.

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

Попробуйте сами. SpecBuddy бесплатен. Скачайте его в JetBrains Marketplace (установка — пара минут), подключите свой Claude Code или Codex и запустите на ближайшей задаче.

А чтобы не пропускать новые релизы — подписывайтесь в X.

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