В последнее время среди разработчиков активно обсуждается, останутся ли они востребованы в эпоху вайб-кодинга или превратятся в «мясной прокси» между задачами и ИИ. Внедрение агентов часто начинается с простого требования: использовать их и выпускать фичи быстрее. Однако довольно быстро возникают вопросы: кто проверяет, как агент понял задачу, какие решения можно ему доверить и как убедиться, что новая фича не сломала существующие. Автор статьи на собственном опыте столкнулся и с быстрым получением работающего результата, и с регрессиями, и с многочасовыми циклами работы агента, что подчёркивает необходимость выработки требований, ограничений и проверок для эффективной работы с агентами.

В своих пет-проектах автор увлекается вайб-кодингом и создал несколько небольших игр, таких как Pocket Circuit, Lunar X и Xenodrift, а также скилл для портирования старых игр на Samsung TV. В этих экспериментах задачи ставились агенту, а оценивался получившийся игровой опыт, однако отдельного аудита кода, архитектуры и тестов не проводилось. Это демонстрирует возможность быстрого получения работающего продукта, но не гарантирует готовность к длительному сопровождению. Например, Xenodrift переделывался несколько раз, и при дальнейших изменениях переставали соблюдаться ранее принятые решения, возникали регрессии, а часть фич игры просто исчезала. Избежать этих проблем можно было через фиксацию требований и проверку их соблюдения.

Вопреки расхожему мнению, вайб-кодинг не означает, что код и архитектура будут низкого качества. В качестве примера автор приводит демо банковского приложения DemoBank, сгенерированное за пару дней с нуля на Flutter. При задании требований к производительности, повторному использованию фич и дизайн-системе, но без указания конкретной архитектуры, в итоге получилась модульная слоистая архитектура по фичам — feature-first, с принципами Clean Architecture и ports-and-adapters. Фичи, такие как счета, история, аналитика и штрафы, выделены в пакеты; слои включают UI, Cubit для управления сценарием, репозитории для работы с API и кешем, а домен отделён от Flutter, HTTP и SQLite. Зависимости передаются через конструкторы и собираются в оболочках приложений, а состояние UI управляется через BLoC/Cubit с однонаправленным потоком данных. Это практическая адаптация Clean Architecture, где UI и API-адаптер могут находиться в одном feature-пакете, а отдельные use case-классы для простых вызовов не создаются.

Структура пакетов показала, что фича «оплата штрафов» может работать как в самостоятельном приложении, так и в составе DemoBank, используя общую дизайн-систему и кодовую базу, но не притягивая лишние зависимости. Этот кейс с выделением фичи в отдельное приложение был взят из опыта, когда подобное выделение принесло больше денег, чем фича в составе супераппа. Для демонстрационного проекта автор допускал отдельные заглушки и упрощения, но в сетевом слое учтены идемпотентность, логика retry и защита от применения устаревшего ответа после изменения фильтра. Дизайн-система собрана так, что страницы можно верстать декларативно, практически без указания отступов и размеров. Одним из требований была плавная работа интерфейса на недорогом Android-устройстве: производительность проверялась на реальном realme RMX3760 с экраном 60 Гц. Для минутной контрольной прокрутки истории из 12 000 операций использовался критерий менее 1% кадров сверх бюджета 16,7 мс, и в зафиксированном прогоне этот показатель составил 0,25% при симуляции API, хотя отдельные медленные кадры сохранялись.

В более серьёзных проектах разработку можно вести через спецификацию и инструменты вроде OpenSpec вместе с Grill-With-Docs, которые помогают создавать архитектурные решения (ADR) и спецификации для генерации качественного кода и архитектуры. Существует масса готовых альтернатив с такими же целями: GitHub Spec Kit, Spec Kitty, BMAD Method, Kiro и другие. Однако это не бесплатно по времени, и важно понимать, что ИИ не даёт мгновенный результат. При обсуждении внедрения ИИ часто сталкиваются с ожиданием, что текстовое описание задачи сразу превратится в готовое изменение, зачастую приводя в пример сервис Lovable и его аналоги. На практике нужен более взвешенный подход, включающий контроль качества и итеративную проверку.

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

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