Немного о себе
Привет, мир. Хочу начать немного с себя: меня зовут Дмитрий, я 15 лет профессионально занимаюсь разработкой ПО. Поработал в крупных компаниях и госучреждениях, последние 8 лет занимал должность руководителя разработки, а полгода назад вышел из найма — чтобы сбить оскомину от заказной разработки, изучить новые технологии в сфере ИИ и пропустить эти знания через свой опыт.
Сначала, на хайпе, я решил попробовать вайбкоддинг и создавал быстрые и простые «одноклеточные» решения. Не вникал в детали реализации, отдал всё на волю нейросетей. Некоторые из экспериментов получались интересными, и часть из них я захотел попробовать развить.
Вайбкоддинг и его слабое место
Но вайбкоддинг быстро обнажил своё главное слабое место. Как только у проекта появляется реальный потребитель, встаёт вопрос ответственности за его качество. А качественное развитие проекта в глубину невозможно без экспертизы в архитектуре и бизнес‑решениях: модели ИИ хороши в генерации по одному промпту, но теряют свою суперсилу на длинных дистанциях. Планирование продлевает жизнь проекта, который развивается с ИИ, но и это тупиковая ветвь: продукты бывают очень большими и сложными, я это знаю из опыта в бигтехе и госах.
Трудно представить начало сессии с ИИ, в которой модель легко и быстро понимает весь проект и необходимый контекст, чтобы принять от разработчика требования и качественно спроектировать внедрение, не сломав текущее стабильное состояние. Экспертиза инженера‑разработчика или системного аналитика несравненно качественнее — хотя бы потому, что он живёт с ней 24/7.
Человек обрабатывает продукт в голове не в момент начала сессии, а проживая повседневную жизнь: за обедом с коллегами, под музыку, катаясь на велосипеде, часто крутишь в голове задачу, над которой трудился в рабочее время. Это насыщает идею контекстом, порождает новые связи и маршруты оптимизации. Архитектура вызревает в голове специалиста, и порой рождается простое, на первый взгляд неочевидное и гениальное решение, к которому ИИ никогда не придёт — она обучена на большом объёме правильных, но совершенно чужих данных.
Креатив против генерации
Я приведу аллегорию.
Мы рассказываем нейросети, что существуют три основных цвета — RGB, — обучаем её комбинировать их и получать производные цвета, учим наносить краску на чистый белый холст кистью — и она рисует нам дерево. Если наша ИИ видела достаточно много деревьев, она нарисует красивое дерево, оно будет пропорционально верным. А потом какой‑то художник находит на улице и берёт в руку ветвистый прут без листьев, видит, что тот похож на ствол дерева в миниатюре (креативная ассоциация), окунает его в краску и лёгким ударом оставляет на полотне отпечаток, который становится каркасом дерева. Берёт кисть, окунает в краску и пальцем по щетине хаотично разбрызгивает её в районе «кроны», добавляет светотень — и на полотне появляется сакура. Дерево, созданное не по заученному сценарию, а через креативное , которое увидело неочевидный путь творения и получило оригинальный результат.
О чём это говорит? Человек способен увидеть решение там, где ИИ даже не пойдёт искать. Способен видеть сходство и выводить ассоциативные связи между разными явлениями. В этом процессе участвует весь жизненный опыт человека — от тактильного и визуального до эмоционального. Я уже не говорю про экспертную интуицию — специалисты с большим опытом в IT поймут, что я имею в виду.
Умрёт ли ИИ?
Так что же, скажем: ИИ умрёт быстрее, чем Сара Коннор родит Джона?
У меня на это своё мнение, и я им поделюсь без эмоций.
ИИ способна быть полезной! Это уже показывает объективная реальность, в которой мы живём. В силу строения нейросети ей хорошо удаётся находить связи в данных и выводить суждения, токены, расположенные рядом, похожи по смыслу, для этого и выводят веса при обучении. Это отлично работает там, где успех строится на повторяемости и предсказуемости процесса. Я буду говорить о своей предметной области. Код — это набор инструкций, и их число в общем и целом конечно. Поэтому ИИ хорошо справляется с тем, чтобы обучиться на опыте генерации правильного кода и получать предсказуемый результат. И если не ждать от ИИ невозможного, а использовать её сильные стороны — можно извлекать пользу, комбинируя креативность человека и предсказуемость
Spec‑kit и SDD
Как я уже писал, вайбкоддинг меня впечатлил, но на этом всё и закончилось. В любовь это не переросло. Для моих запросов и инженерных амбиций он просто не подходил: предсказуемость результата, гарантия стабильности на длинных дистанциях и безопасность решения были ценнее скорости, поэтому сопровождение человеком обязательно. Я стал искать решения, и мне попался известный многим инструмент spec‑kit. Это набор инструкций для ИИ, инструмент, который строит процесс разработки по строго заданному сценарию. Подход получил название Spec‑Driven Development (SDD). Суть его в том, что разработчик не просто пишет промпт или прозаичный план: с помощью инструмента он готовит формализованную документацию, где каждый документ‑артефакт несёт свою роль и имеет узнаваемость от сессии к сессии.
— Конституция проекта вбирает в себя строгие правила разработки — требования к ИИ, которые она будет поднимать в начале каждой сессии и выполнять неукоснительно.
— План проекта описывает общее функциональное поведение, стек, технологии, цель создаваемого продукта и так далее.
В дальнейшем каждое функциональное требование ложится в основу так называемой спеки: она состоит из своих этапов, повторяющихся циклично, и ведёт разработку по пути создаваемого продукта.
Этот подход привлёк моё внимание строгостью требований и формализацией процесса: это выглядело рабочим решением заставить вольную генеративную нейросеть выдавать предсказуемый результат. Долгое время я пользовался этим методом в своих проектах, которые хотел довести до конца. И это хорошо работало, пока я не столкнулся с новыми проблемами.
Техдолг на длинных дистанциях
Со временем стало ясно, что от модели к модели гарантия предсказуемого результата сильно менялась. Более слабые модели начинали «плыть» уже на первых 5–7 спеках. Ошибки реализации нарастали снежным комом, и негласно копилось то, что мы, разработчики, называем техдолгом. Новые фичи всё чаще были не про внедрение и развитие, а про исправление текущего. Более сильные и дорогие модели были способны удерживать контекст, мало галлюцинировали и отдавали чистый результат, но проблема техдолга с ними всё равно появлялась и росла — просто позже.
Я стал искать решение: правил руками, закрывал дыры новыми спеками, но проекты тонули в техдолге. Я даже почти отчаялся и решил, что SDD — очередная раздутая методология, которую просто никто не успел проверить на реальных больших проектах.
Озарение: SDD — это не всё
Но не будь я инженером, если бы на этом бросил затею заставить ИИ работать чисто. Однажды, в очередной битве с ИИ за чистый код, я ходил по комнате из угла в угол, находясь в мысленном потоке и поисках решения. И вдруг меня осенило: SDD неплох, его просто мало! Ему не хватает того, что есть у каждого проекта в реальном цикле разработки. Мне просто надо донести свой опыт и оформить его в процесс.
Как рождается продукт в больших компаниях
Из опыта работы в крупных компаниях я знал, как зарождается и строится продукт.
Я опущу детали, иначе статья раздуется:
1. Сначала идёт фаза ППО — предпроектное обследование. На этом этапе специалисты собирают требования у бизнеса: какую боль необходимо решить, где узкие места. Формируется карта требований, которая затем переходит в отдел аналитики (я опускаю экспертную оценку, согласования и прочее — суть аналогии не в этом).
2. Аналитика формализует требования бизнеса в метрики — данные, которые легко ложатся в основу будущей технической документации продукта.
3. Когда требования формализованы, они передаются команде разработки, где тимлид оценивает реальные сроки, нарезает работу на блоки — и формируется дорожная карта.
4. Дорожная карта ложится в основу всего продукта, и из неё команда начинает формировать эпики, истории, спринты и так далее.
Это сжатое, упрощённое описание того, как рождается продукт в больших компаниях. Есть и другие методы, но мне нужен был именно этот — более дотошный к деталям и контролируемый на каждом этапе. SDD в этом процессе проявлялся лишь во 2-м и 4-м пунктах. Ему не хватало остального. Я понял, что мне нужен весь процесс. И не просто в виде инструкций наподобие spec‑kit, а полноценный продукт, который проведёт меня через предпроектное обследование в удобном UI, оформит его в метрики, по строгим формализованным шаблонам напишет конституцию и общий план проекта, разобьёт проект на слои (инфраструктура, бэкенд, дизайн, фронтенд), построит дорожную карту для каждого слоя и нарежет работу на небольшие блоки — брифы. Каждый бриф станет той самой спекой, которая выполняется в цикле, одна за другой: сначала закрывается весь слой, затем переходим к следующему — и так далее по дорожной карте продукта.
Рождение SpecaFlow
Так родился продукт SpecaFlow (далее — SF). Первые версии были примитивны, я просто хотел создать визуальный менеджер для запуска простых команд spec‑kit и получать результат в виде документов на диске. Но по мере реализации увидел, что если и делать продукт, то делать сразу правильно. Это будет не просто и не быстро, но это будет то, в чём я лично очень нуждаюсь уже сегодня.
Начинается путь в SpecaFlow с того, что он встречает разработчика предложением пройти краткий онбординг — освоить UI‑элементы инструмента. Это понадобилось, чтобы снизить порог вхождения для специалиста и помочь освоиться в богатом наборе инструментов.
После ознакомительного демо предлагается открыть существующий проект или создать новый, указав пустую папку.
Далее начинается та самая фаза ППО: SpecaFlow предлагает пройти опросник из 70+ вопросов (часть вопросов зависит от других, поэтому на деле человек увидит меньше) с вариантами ответов, где выясняется, что именно мы будем разрабатывать, предметная область, архитектура, стек, платформа (web, мобильная, бот и так далее), будет ли UI и каким он будет — от этого зависит, какие слои лягут в дорожную карту.
Когда опросник пройден, SF передаёт ответы в ИИ, сразу открывая чат с ней. В этом чате ИИ анализирует ответы; если на какие‑то вопросы разработчик не смог ответить или пометил их «Обсудить в чате», ИИ предложит решения. Это самая важная часть проекта. Тут главное не упустить детали и в свободной форме рассказать больше о продукте. Можно спросить, как лучше реализовать то или иное решение. SF в этом чате умеет искать в интернете свежие решения, поможет найти и выбрать современные технологии и собрать необходимую информацию, проверить конкурентов.
В чате есть режим работы у доски: можно попросить ИИ нарисовать архитектурную схему будущего продукта или построить воронку продаж, на которой разработчик также может вносить изменения и просить ИИ взглянуть на правки. Мне показалось это удобным, чтобы вместе с моделью «видеть» проект до начала работы с ним.
План проекта и ассистент Спекки
Все обсуждения и чаты, которые разработчик провёл с ИИ на этапе ППО, SF в конце предлагает собрать в план проекта. Это самый большой и насыщенный документ, и формируется он нажатием одной кнопки в UI.
Все документы доступны для чтения и правки прямо в UI SpecaFlow. Я старался не рассчитывать на то, что разработчик откроет продукт в IDE. Сделать это означает приглашать человека вмешаться в формализованный документ, что несёт риски потери согласованности всего конвейера.
Далее по описанному выше сценарию разработчик генерирует все необходимые артефакты своего проекта, просто нажимая кнопки и продвигаясь по фазам — вплоть до списка брифов. Каждый этап контролируется человеком через видимые изменения в UI (для этого я реализовал удобный просмотрщик git diff), и на любом из них можно призывать Ассистента Спекки — закреплённый чат с ИИ, который выступает чисто консультантом: он знает всё о SpecaFlow и может читать документы создаваемого продукта и подсказывать по ним по ходу следования разработки.
Почему документация не спасла от техдолга
Помните проблему техдолга, о которой я писал выше? SpecaFlow уже закрывал важные этапы до начала работы самого подхода SDD: он готовил базу продукта, собирал и формализовал метрики, писал план, конституцию, готовил дорожную карту и брифы. Но без гарантий реализации и проверяемости кода даже самая подробная документация порождала техдолг — в силу особенностей разработки, о которых ниже.
Внутри цикла одной спеки (фичи) SDD‑подход многим известен:
1. specify — краткое описание фичи;
2. clarify — фаза уточнений: ИИ читает общие документы и через уточняющие вопросы (2–3 вопроса) насыщает контекст фичи деталями;
3. plan — затем ИИ, с учётом конституции и общего плана, пишет план фичи;
4. tasks — после чего план нарезается на мелкие задачи, атомарные единицы работы; таких задач на фичу могло быть от 5 до 20 в зависимости от сложности и глубины проработки;
5. analyze — после подготовки этих артефактов SDD предлагает фазу анализа, чтобы проверить написанное на согласованность и отсутствие коллизий, — важная и нужная фаза;
6. implement — после этого следовала фаза разработки: только здесь эти задачи буквально выполнялись, строго по сценарию.
Теперь, наверное, вы понимаете, почему SDD меня покорил. Но дальше его строгости было недостаточно. После реализации, конечно, шла фаза проверки (verify): ИИ проверяла сама себя на ошибки реализации и фантомные успехи — когда задача помечается выполненной без фактической реализации в коде. Но тут я заметил, что все эти проверки прозаичны, то есть оценка качества сводилась к мнению модели, а не к фактам: нужна была машинная проверяемость.
ИИ могла проверить, лежит ли код задачи в указанном месте и соответствует ли он описанному сценарию. Но разработка — это не только написание кода.
Проверке не хватало гарантий: она не могла проверить, например, запускалась ли та или иная команда по сценарию. Выполнение миграций, тестов, наполнение БД, проверка рабочего окружения, в котором, в конце концов, крутится приложение, — всё это либо нельзя было проверить на фазе верификации, либо ИИ просто пыталась быть хорошей и сама искала способы проверки, потому что никто не сказал ей, что гарантирует выполнение той или иной задачи. И успех таких проверок напрямую зависел от того, насколько много вы готовы платить за один миллион токенов, а точнее, какой глубиной и креатива обладает ваша ИИ, подключённая к проекту. Меня эта переменная в формуле не устраивала. И, следуя тому же принципу внедрения своего реального опыта в процессы инструмента, я увидел пути решения.
Tests first и deviations
Тут я понял: помимо документов проекта, расширять нужно и сам цикл фичи. В качестве первой спеки на вход фичи я передавал тот самый краткий блок описания из брифа, далее шла фаза уточнений через вопросы — так порождался план фичи, самый важный документ текущей функции. Но план генерился на чистых артефактах, на предположениях о том, что всё пройдёт штатно. На деле штатно никогда не проходило. При попытке установить пакет версия, указанная в плане, могла не подойти; несогласованность могла заставить отказаться от пакета вовсе в пользу альтернативы. В процессе реализации сервиса могло всплыть, что код падает из‑за задачи T015, потому что модель не учла функциональное поведение, которое видно только после запуска и вызова API‑метода в обработчике. Таким образом, требование к задаче устаревало ещё до того, как фаза implement успевала дойти до конца.
Это та реальность, с которой каждый программист сталкивается на рабочем месте. Здесь работали те же законы, не важно, кто писал код, — корректировка постановки в процессе реализации задачи — нормальная практика.
Что в нашем случае мы получали на выходе?
План всего проекта требует одного, а результат легально может получиться другим.
Задачи нарезаны из требований верно, но в ходе реализации мы вынужденно отошли от плана настолько, что он потерял то, ради чего создавался, — строгость требований и согласованность на длинных дистанциях.
Так в SpecaFlow появились два механизма — tests first и deviations.
Первое — tests first — старо как мир: подход написания тестов до кода используется в разработке давно. Но теперь я увидел, как именно тесты могут выстроить таблицу гарантий до написания кода. Тест — легко проверяемый атомарный факт, а писать тесты сегодня ИИ умеет прекрасно. Оставалось направить это умение в нужное русло: в SpecaFlow тесты пишутся до кода — против требований, — а их прогон я поместил на выходе из фичи, чтобы убедиться в чистоте реализации.
Второе — deviations, механизм отклонений. Если в ходе реализации реальность расходится с документами, модель не правит их молча. Модель остановится и задаст вопрос разработчику с подробным пояснением, почему нельзя выполнить требование, и предложит два‑три альтернативных решения. Разработчик выбирает из предложенных, либо пишет текстом своё. Отклонение фиксируется в реестре плана фичи, а позже фаза reconcile (восстановление согласованности) разносит его по документам; пока это не сделано, верификация и завершение фичи недоступны.
Вторая часть этого механизма выполняется рядом, в фазе ретро: по итогам фичи формируются уроки — то, что SpecaFlow извлёк из текущего прогона. У каждого урока есть свой адресат, в который его необходимо поместить: план проекта, конституция или сам процесс. SpecaFlow ведёт этот механизм последовательно и не пустит разработчика начать новую фичу, пока уроки прошлого цикла не разобраны в UI и не внесены в планы: новая фича должна начинаться с учётом принятых корректировок. Весь процесс сводится к чтению и нажатию кнопок «Одобрить» или «Отклонить» с причиной.
Вот что порождало техдолг — тихо, без шума и пыли: документ устаревал, а модель с каждым циклом получала всё более противоречивые инструкции. Тесты и deviations это исправили и вернули в процесс строгость и последовательность.
Паспорт: шаблон наследственности
Далее продукт развивался уже далеко за рамки SDD‑подхода и порождал свой собственный стиль и стандарт. Так, например, в конце каждой фазы, фичи и слоя появился паспорт. Паспорт — это формализованный итог сделанного, каждый этап передаёт его следующему. От многословной прозы, где допустимы разночтения, я пришёл к шаблону «наследственности». Это резко снизило количество блокирующих находок на этапах анализа и верификации внутри фич, повысило прозрачность для ИИ и, что важнее, сделало процесс наглядным для разработчика. Принимая изменения в документах и коде на каждом этапе через просмотр git diff в удобном интерфейсе, разработчик может контролировать детали, но со временем внимание притупляется: читать много и долго утомительно.
Паспорта показывают краткие сводки сделанного: какое решение дошло до итога, каким способом, какие трудности были в процессе и чего этап не отдаёт, а передаёт дальше. Четыре простых блока — и основные вопросы сняты.
Где SpecaFlow сейчас
Сегодня SpecaFlow находится в активной фазе отладки. Инструмент тестируется на простых проектах‑песочницах: обкатывается написанный с нуля harness SpecaFlow, оттачиваются системные промпты, формируются шаблоны оформления артефактов, проверяется удобство UI с точки зрения UX.
Слои инфраструктуры и бэкенда пройдены и отлажены до стабильного состояния. Первый гарантирует на выходе запускаемое окружение и тесты, запускаемые одной командой, а бэкенд передаёт дальше модель данных, API и набор контрактов для слоя фронтенда.
Слой дизайна находится в активной фазе тестирования: формирование токенов, выбор направления стиля, цветовая гамма, layout‑шаблоны и так далее.
На вход каждого слоя подаются те данные, которые SF собрал на ППО и оформил в измеримые машиной метрики, плюс контекст предыдущих слоёв. Так построился согласованный конвейер, корректирующий сам себя в процессе работы: разработчик выступает стейкхолдером, аналитиком, архитектором и инженером‑проектировщиком, а SpecaFlow — строгим оркестратором ИИ‑модели, который гарантирует человеку контроль строгости и качества, модель здесь — это программист, которому на понятном ему языке SpecaFlow спускает требования и инструкции, а затем проверяет качество и отчитывается человеку.
Что дальше: SaaS и сопровождение проектов
Сегодня SpecaFlow — это бинарь, написанный на Go и предназначенный для запуска на локальной машине разработчика. Эта форма останется первоклассной: есть команды с закрытым контуром, куда облако не попадёт никогда. Но в планах — выход на SaaS‑модель: продукт в браузере, с авторизацией. Главная инженерная задача на этом пути — подключение проектов к облачному инструменту. Требования здесь высокие: продукт должен работать в облаке, файлы проекта должны оставаться у разработчика на сервере, гарантия приватности лежит в основе продукта. Но и принцип «файлы — источник правды» не должен ломаться. Очевидные на первый взгляд решения имеют много недостатков, отсюда и сложность реализации, и готовность к компромиссам.
Кроме того, в планах научить SpecaFlow не просто разрабатывать, но и сопровождать текущие проекты. Задел уже есть: на этапе инициализации инструмент умеет сканировать добавленный проект с кодом и автозаполнять многие вопросы опросника на основании фактов сканирования. Но этого мало. Когда продукт написан с нуля либо подхвачен в середине, те самые формализованные документы проекта — с накопленным опытом извлечённых уроков, набором паспортов всех фаз и слоёв — должны лечь в основу формирования новых фич: SpecaFlow научит модель доносить функционал в проект с учётом всех необходимых вводных, не ломая его согласованность и единую структуру.
Вместо заключения
Рекомендую ознакомиться с сайтом проекта specaflow.com — там многое изложено и показано детальнее.
Спасибо всем, кто дочитал. Вопросы — в комментарии, постараюсь ответить на все.
Успехов в разработке новых решений!
Автор: dgalaganov
