Создание на основе спецификаций

ИИ в разработке

Искусственный интеллект активно занимается разные сферы деятельности, и разработка программного обеспечения не исключение, ИИ уже меняет подходы к разработке ПО.

Это изменение неоднородно — есть подходы, которые открывают возможности, но создают риски. И есть подходы, которые эти риски снимают.

Вайб-кодинг

В феврале 2025 года Андрей Карпатый (ученый и сооснователь OpenAI) предложил концепцию вайб-кодинга (vibe-coding). Благодаря возможностям искусственного интеллекта можно забыть о традиционных правилах разработки. Можно рассказать АИ-агенту голосом, что вы хотите и агент сам напишет весь необходимый код.

Код перестает быть важным, важным становится намерение - что вы хотите создать.

Вайб-кодинг выглядит заманчиво, позволяя сфокусироваться на намерении и не заботиться больше о коде. И это действительно отлично работает:

для быстрого создания прототипов
для типовых и небольших решений
- создать лендинг
- создать чат-бота

Однако, попытка создать что-то более сложное, чаще всего приводит к проблемам.

Потеря управляемости - вы не управляете ни архитектурой, ни безопасностью, ни процессом.
Угроза безопасности - согласно исследованиям, 30-40% кода, созданного AI содержат известные уязвимости. В 2025 году несколько взломов (Base44, Tea App) произошли именно из-за потери контроля над безопасностью в vibe-coded приложениях.
Галлюцинации - ИИ теряет контекст, забывает сделанное, ломает систему, создавая новое

SDD или управление через спецификации

Spec-Driven Development - методология разработки, которая старается решить проблемы, которые есть у вайб-кодинга.

Методология нацелена на возврат управляемости, повышение качества и безопасности кода.

В SDD архитектурно заложен двухступенчатый процесс:

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

По сути это возвращение к истокам инженерной разработки (software engineering), очередной виток эволюции.

Важные отличия:

предназначение - спецификации теперь должны быть одинаково понятны не только людям, но и ИИ-исполнителям.
живая спецификация - спецификация является основным источником истины, всегда актуальным контрактом между командой, ИИ-агентами и бизнес-заказчиком. Это не классическое техническое задание (ТЗ), которое дали на вход, а потом в процессе реализации многое изменилось и ТЗ уже не актуально. Это версия, которая все время актуализируется исходя из реальных изменений.

Благодаря спецификациям:

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

Практика внедрения

Ключевые элементы

Что стандартизируется в процессе SDD:

Артефакты

Шаблоны документов - описание продукта, дорожная карта, технические решения, архитектура и журнал архитектурных решений, набор спецификаций по каждой фиче - спецификация, решения, сценарии тестирования

Правила

Правила, которыми должен руководствоваться агент в процессе создания

общие - лучшие мировые практики кодирования, стиля, OWASP и другие
корпоративные - внутренние стандарты компании или команды

Команды (промпты)

Спецификация алгоритмов действия агентов для решения конкретных задач.

входные артефакты - что команда использует для входа
выходные артефакты - что создает на выходе
алгоритм - многошаговый алгоритм, описывающий ЧТО, но не КАК действовать - изучи, сравни, проверь, сделай
правила - какие правила используются в процессе выполнения шагов
инструменты - какими инструментами разрешено пользоваться в процессе
ограничения - чего нельзя делать в рамках выполнения данной команды, явные правила

Агенты

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

Роль - зона ответственности агента
Компетенции - какими компетенциями он должен обладать для выполнения работы
Команды - набор команд, которые агент будет выполнять
Модель - возможно детализация до модели или ее типа (думающая, выполняющая инструкции и другие)

Процесс

Процесс выполнения работ, последовательность создания, правила применения агентов, команд, их взаимодействия

Напоминает ГОСТы? Да, так и есть. Именно такая стандартизация приводит к получению предсказуемого результата.

Структура проекта

Типовая схема - в репозитории (или нескольких) проекта находится код и тесты.

Отдельно живут:

внутренние стандарты и правила, которым должны следовать разработчики
документаци по проекту - описание целей, дорожной карты, спецификация эпиков и историй

В случае SDD ситуация меняется, как внутренние правила и стандарты, так и все спецификации продукта теперь живут вместе с кодом. Они используются агентами для выполнения задач, актуализируются и корректируются по ходу реализации.

Практически все зрелые бизнесы сталкиваются с ситуацией, что продукт есть, но актуальной информации по нему нет, есть отдельные ценные “носители знаний”, от которых компания начинает зависеть.

Работая только с командой из людей обеспечить актуальную документацию затратно, при работе через SDD актуальность документов обеспечивается автоматически самим процессом.

Что с людьми?

AI не заменяет всех людей, хотя и серьезно перераспределяет роли и задачи.

Владельцы продуктов - получают возможность быстрее проверять гипотезы, самостоятельно делать прототипы, использовать AI-аналитиков
Ведущие (senior) разработчики - получают возможность расти в архитекторов и уделять больше внимания проектированию и принципиальным решениям, чем рутине
Мидл (middle) разработчики - становятся наставниками и ревьюверами для AI-сотрудников
Тестировщики - получают возможность роста до инженеров тестирования, которые в Google являются элитой, разработчиками, которые умеют не только создавать, но и разрушать.
Соло-предприниматели - могут в одиночку создавать продукты, при наличии соответствующего опыта.

Происходит не замена, а переход на совершенно новый уровень задач, который решают люди. От рутины к стратегическим и архитектурным решениям.

Этот переход требует переподготовки и переориентации команды, меняет привычное мышление, что является одной из самых сложных частей пути.

Потенциал использования

Масштабируемость процессов

Вместо одного разработчика вы можете нанять сотню ИИ-разработчиков, которые:

не будут болеть, выгорать, саботировать работу
не будут часами сидеть в переговорных с “лавандовым рафом”
готовы работать 24/7

Главное - добавление новых ИИ-разработчиков, все они будут сделовать тому же установленному процессу и правилам работы.

Отчуждаемость

Люди все разные и могут меняться под влиянием обстоятельств.

Сегодня этот человек - ваша правая рука, надежда и опора.

Завтра он может

выгореть и отстраниться, “тихо уволиться” и перестать приносить пользу
уйти, чтобы начать свой собственный проект
серьезно заболеть или умереть

Как руководителю и предпринимателю, вам надо управлять этим риском.

За счет стандартизации и “живых спецификаций”, снижается зависимость от конкретных людей.

Продукт становится отчуждаемым. Когда вся логика и процесс зафиксированы в спецификациях, новая команда может продолжить работу без потери контекста.

Повышение безопасности и надежности

Финансовые организации опасаются использовать AI для генерации кода. Ведь критически важно иметь надежный и безопасный код.

Посмотрите на это с другой стороны.

Вы делаете финансовое приложение и Центробанк требует обязательную сертификацию по ОУД-4.
Вы описали процесс безопасной разработки и согласовали его с сертифицирующей организацией

Но, теперь спросите себя и ответьте честно:

Вы уверены в том, что ваша команда будет работать по этому процессу?

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

Если в большинстве команд безопасный процесс остается лишь на бумаге, что вам дает уверенность в том, что люди делают безопасный код???

SDD помогает реально работать в рамках формализованного безопасного процесса.

создавать необходимые спецификации
следовать им в работе и поддерживать их в актуальности
разделять полномочия - каждый агент выполняет свою роль в соответствии со своими навыками
- создает код согласно спецификациям
- создает тесты и проверяет на соответствие функциональным возможностям
- проверяет соответствие архитектуре и принятым архитектурным решениям
- актуализирует спецификации и документацию продукта
- создает тесты на выявление уязвимостей
- проверяет на стандарты безопасности и требования сертификации

В итоге разрабатывать продукт, требующий сертификации, с помощью SDD и быстрее и надежнее.

Ограничения и вызовы

Избыточность спецификаций

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

Неточное исполнение

Несмотря на четкие правила и инструкции, AGENTS.md, детальные спецификации, AI-агенты не всегда им следуют. Результат обычно требует верификации людьми и нескольких итераций работы. Сейчас это норма работы с AI-агентами, к ней надо быть готовым.

Замедление в работе

Неподготовленное использование ИИ может не только не ускорить работу, но и сильно замедлить ее. Лично наблюдал, как ряд команд бессистемно пытаются через промпты добиться от ИИ идеального результата за один подход. Время, потраченное на эти бесплодные попытки значительно больше, чем время, за которое разработчик написал бы все сам. Естественная реакция - “ИИ не работает”. Однако здесь не работает не сам ИИ, а такой способ работы с ним.

Новизна

Методология новая, устоявшихся стандартов нет, она активно валидируется и модифицируется.

Примеры:

Слабое управление продуктом

Все подходы пока еще в основном сфокусированы на генерации кода, на управлении спецификациями и содержат слабые функции для управления жизненным циклом продукта, его дорожной картой, управлением приоритетами.

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

Живые примеры

Гипотезная - мой продукт для работы с картами гипотез.

Мои “шляпы”, как соло-предпринимателя:

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

Этот продукт целиком создан по методологии SDD, код и авто-тесты полностью написаны AI.

Продукт развивается, можете посмотреть по его истории изменений. Используется не только мною, но и другими сертифицированными фасилитаторами карт гипотез для построения стратегий разного уровня.

Вместе с ним развиваются мои навыки по управлению командой своих ИИ-исполнителей, растет скорость реализации. Последние фичи, которые при планировании спецификации оценивались в несколько дней работы, были реализованы за считанные часы.

Часто задаваемые вопросы

Что такое вайб-кодинг?

Вайб-кодинг (vibe-coding) - или программирование "на вайбе" - процесс, при котором человек ставит задачи ИИ на естественном языке, а AI-агенты их реализуют.

При таком стиле разработки человек фокусируется на намерении - что он хочет получить, а АИ самостоятельно находит и реализует варианты решения.

Вайб-кодинг отлично подходит для создания прототипов, тестирования гипотез, решения типовых простых задач - создать лендинг, телеграмм-бота.

Что такое Spec-Driven Development?

SDD (Spec-Driven Development), управление через спецификации - это методология процесса разработки , позволяющая разрабатывать цифровые продукты промышленного уровня с помощью ИИ.

Ключевая смена парадигмы - спецификация становится источником истины вместо кода. Код перестает быть ключевым игроком. Он может быть заменен, модифицирован, перенесен на другую платформу аввтоматически или полу-автоматически на основе спецификаций.

Фокус команды смещается с разработки в части написания кодов и тестов на проектирование и моделирование. Рутину забирают AI-агенты.

Безопасно ли использовать AI для написания программ?

Кратко - SDD - безопасно, вайб-нет.

При вайб-кодинге вы не управляете процессом, вы управляете только своим желанием и намерением. Процессы управляются выбранным вами инструментом. Код чаще всего избыточный, не оптимальный и не безопасный.

При управлении через спецификации вы управлете процессом. Создаете правила, стандарты, спецификации, декомпозируете задачи, проверяете результат. Весь процесс под вашим управлением.

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

Можно ли использовать AI-разработчиков в финансовом секторе?

Нужно. При помощи Spec-Driven Development процессы безопасной разработки будут не просто описаны на бумаге, а будут реально работать.

Практические рекомендации

Быть готовым к пересмотру методологии процесса разработки.
Подготовить команду
Выбрать задачу для пилота
Пригласить проводника

Пересмотр процесса

Важным элементом управления через спецификации является стандартизация.

В первую очередь стандартизация процесса проектирования.

Проектирование - обычно самый неформализованный процесс. Когда его результаты начинают выполнять ИИ-агенты, все недочеты становятся явными.

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

Для улучшения процесса проектирования рекомендую обратить внимание на раннее вовлечение.

Практика нацелена на сдвиг рисков влево, на выработку единого видения на старте между бизнес-заказчиком, командой, информационной безопасностью и комплаенс. Эффект от хорошего проектирования и декомпозиции превышает любую оптимизацию процессов реализации.

Подготовить команду

Процесс будет меняться, инструменты будут меняться. Это гарантированный стресс. Чтобы с ним справиться, команде нужна помощь.

Важно замотивировать команду и снять барьеры, которые будут мешать:

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

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

Пилотная команда - первопроходцы, которые проложат путь для остальной компании.

Важно это признавать и ценить.

Выбрать задачу

Лучше всего новый проект (greenfield), где команда может сразу начать “с нуля”.

Получив этот опыт и построив процесс для новых продуктов, можно будет постепенно адаптировать части этого процесса для поддержки старых (legacy) систем, повышая управляемость в их поддержке.

Напомню, что у задачи не должны сильно “гореть сроки”, работа “по другому” имеет большую неопределенность и непредсказуемость. Надо дать команде время на исследования и эксперименты.

Пригласить проводника

Пригласите в помощь команде людей, у кого есть большой опыт в управлении разработкой как с помощью ИИ, так и без нее. Эта помощь точно окупится в разы.

Свяжитесь со мной и я помогу вам пройти этот путь быстрее и эффективнее.