🛰 Глаза боятся, руки делают

История о том, почему не всегда нужно верить документации и инструкциям ИИ.

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

Загрузила в V0 список user stories. Агент разложил всё по экранам и карточкам забегов. Визуально логика совпала с человеческой, структура интерфейса выглядела идеально готовой. Оставалось перенести это в репозиторий, не сломав текущий стек.

По документации V0 и после переписки с ассистентом поддержки V0 алгоритм получился линейным: • Подключить текущий GitHub-репозиторий • Попросить V0 выгрузить код в отдельную ветку и создать PR • Смержить → интерфейс обновится

🔻 Точка трения

Я подвисла на этой инструкции почти на три дня. Внутренний контролёр не давал нажать merge: «Не может интеграция фронтенда в кастомную архитектуру занимать три клика. Где засада?»

Ходила, читала документацию по интеграциям, прокручивала сценарии. Ждала, пока внутренний фильтр отработает.

🔻 Момент диагностики

С утра, на чистую голову, загрузила PR в Kiro в режиме анализа ветки скрестив пальцы и уточнив "ПРОВЕДИ ПОЛНЫЙ АНАЛИЗ ИЗМЕНЕНИЙ, ничего не загружай". Через несколько минут агент вывел строки с предупреждениями и чётким маркером: ⚠️ ЭТО НЕЛЬЗЯ МЕРДЖИТЬ.

V0 генерирует изолированные компоненты на Next.js, тогда как мой проект работает на React. Несмотря на прямой доступ к репозиторию, агент просто перезаписал папку front целиком, не учитывая состояние приложения, существующие зависимости и контракты бэкенда. Слияние без подготовки привело бы не к тихой ошибке, а к полной поломке фронта, и пришлось бы долго разбираться, что именно пошло не так. V0 не ошибся — он просто решал задачу интерфейса в своём контексте.

🔻 Как я выстроила процесс для этой связки

Вместо того чтобы форсировать выгрузку, я добавила буфер нормализации. Теперь перед каждым переносом фронтенда от V0 в проект действует такой порядок:

• Сначала настраиваю skill для Kiro — он проверяет входящие PR на конфликты типов, импортов и структуры • Даю V0 системный промт-ограничение перед генерацией: чёткие правила по библиотекам, путям и архитектуре папок • Переношу компоненты через Build Feature режим, где каждый элемент проходит адаптацию под текущий стек бэкенда

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

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

🔻 Рефлексия

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

ИИ генерирует инструкции, но у него нет опыта и интуиции. Он не чувствует, когда «это слишком просто» — на самом деле сигнал к тому чтобы подумать. Поэтому, если внутренний голос подсказывает, что что-то не так, не спешите нажимать кнопку. Дайте себе время. Разберитесь, задайте вопросы, проверьте контекст. Ценность не в скорости выполнения, а в пространстве для исследования, которое есть только у человека. Прислушивайтесь к своему опыту — это то, чего не умеет ни один алгоритм. А когда почувствуете, что картина сложилась и риски просчитаны