Текущее состояние AI Driven Development: от вайбкодинга к спецификациям и обратно

За плечами более 10 лет фулстек разработки в различных областях — от энтерпрайза до стартапов. Последние 3 года посвятил ИИ-инженерии, работая над собственными продуктами в сегментах b2b и b2c.

Сейчас руковожу своей студией разработки, специализирующейся на быстрой и эффективной реализации ИИ стартапов. С командой из 20 разработчиков мы активно экспериментируем и внедряем подходы разработки с помощью ИИ. Эти методологии позволяют нам не только значительно ускорить процессы, но и иметь существенное конкуретное преимущество в индустрии заказной разработки.

Создание приложения — это комплексный процесс, включающий продуктовую проработку, выявление всех эдж-кейсов, поиск оптимальных архитектур и стеков, изучение существующих решений и паттернов. Написание кода приходит только в конце этой цепочки.

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

Настоящий потенциал оптимизации сейчас находится в области ассистировании квалифицированных специалистов при исследованиях, формализации и детализации высокоуровневых задач, принятии архитектурных решений и создании качественной документации для имплементации. Именно эти аспекты критически влияют на производительность, скорость доставки, поддерживаемость и общую стабильность проекта.

Именно на этом фокусируется spec-driven подход к разработке. В индустрии активно формируются методологии и инструменты для автоматизации процесса создания спецификаций. Среди наиболее заметных решений — Kiro от Amazon, Qoder от китайских разработчиков и Spec-kit от Github.

Если говорить абстрактно, спецификация становится высокоуровневым языком программирования, а генерация исполняемого кода с помощью ИИ — своего рода "транспиляцией" в низкоуровневый код.

Эта концепция хорошо описана в манифесте GitHub Spec-kit, хотя сам инструмент пока не полностью реализует заявленные принципы.

Spec-Driven Development (SDD) от GitHub переворачивает разработку: спецификации становятся исполняемым source of truth, который генерирует код через ИИ, устраняя разрыв между планами и реализацией. Три команды (/specify, /plan, /tasks) автоматизируют весь цикл от идеи до задач за 15 минут вместо 12+ часов традиционного документирования. Изменения требований превращаются из препятствий в систематические регенерации — код автоматически обновляется при изменении спецификации. Разработчики переходят от механического кодинга к архитектурному мышлению и креативности, а ИИ берет на себя трансляцию намерений в код. Это фундаментальная смена парадигмы: от "код как истина" к "спецификация как истина" с непрерывной обратной связью от продакшена к спецификациям. (Summary of spec-driven.md)

Детальный обзор методологий, spec-driven IDE и наши собственные подходы я планирую осветить в ближайших материалах.

С высокого уровня абстракции становится видно, что вайбкодинг олицетворяет итеративный подход к разработке. Здесь осознание проблемы и её решение происходят в рамках одной итерации — мы быстро переходим от идеи к практике, не застревая в теоретизировании. Это подход "решаем проблемы по мере поступления". Однако у него есть обратная сторона: повышенный риск тупиковых решений и накопление технического долга с каждой итерацией.

Spec-driven подход представляет противоположную философию — более планомерную и структурированную. Мы стремимся заранее выявить потенциальные проблемы и продумать их решения. Но и здесь есть свои риски: можно увлечься теоретизированием, отдалиться от практической валидации и создать красивую спецификацию, которая окажется нежизнеспособной при столкновении с реальностью.

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

Индустрия в целом и наша студия в частности находятся в поиске оптимального баланса методологий AI Driven Development. Тренд явно смещается в сторону spec-driven подхода, который уже демонстрирует существенные преимущества в эффективности. По нашим оценкам, для сегмента небольших стартапов с трёхмесячным циклом разработки MVP этот подход даёт ускорение на 30-40% от базовой скорости.

Spec-driven подход влияет не только на процессы, но и на технологический выбор: Монорепозитории становятся выгоднее — ИИ нужен полный контекст в одном месте. Infrastructure as Code — декларативное описание инфраструктуры идеально ложится в парадигму спецификаций. Developer Experience меняется — разработчик теперь архитектор и валидатор, а не "писатель кода".

По сути, формируется новая культура разработки и эта культура требует новых инструментов для работы.

Сейчас мы пишем спеки в markdown-файлах прямо в AI-редакторах, версионируем через Git и проводим ревью в pull-request'ах. Для технической команды это работает, но когда нужно обсудить спецификацию с заказчиком или получить от него комментарии — начинаются сложности. Хотелось бы иметь что-то более коллаборативное, где можно было бы публично делиться документами, редактировать их совместно и оставлять комментарии прямо в контексте.

Но даже с текущими ограничениями результаты впечатляют. Мы находимся в самом начале трансформации индустрии разработки с осязаемыми конкурентными приемуществами.