Как не выстрелить себе в ногу если вы решили навайбкодить свой продукт Этот пост - часть большой подборки по вайб-кодингу, которую, как я вижу, вы уже массово себе сохранили (она случайно улетела в канал чуть раньше времени). Здесь хочется поговорить о типичных подводных камнях, с которыми вы неизбежно столкнетесь, если решите собрать свой продукт с помощью ИИ. 1. Продумывайте UX и пользовательские сценарии до мелочей Кодинговые модельки не понимают контекста удобства по умолчанию. Например, если вы делаете приложение, где есть редактирование контента, агент сам не догадается, что нужен автосейв, это нужно четко прописать в ТЗ. Однако если вы не работали плотно с дизайнерами, то сделать идеальное ТЗ со всеми возможными сценариями нереально. В таком случае - создайте базовый флоу, потыкайте его руками и отловите моменты, где вам самому неудобно или чего-то не хватает. ИИ делает то, что ему сказали, а не то, что логично. 2. Экономьте на API при тестировании пайплайнов Сразу сделать production-ready решение не выйдет. Будет куча тестов, перезапусков докеров, прогонов кода. Если использовать для этого дорогие модели, можно легко сливать по $2 за один сложный запрос. Лайфхак: на этапе разработки подключайтесь через OpenRouter к бесплатным моделям. Вам сейчас важна работоспособность системы в целом, а мелкие недочеты легко правятся. А вот уже сам финальный промпт можно точечно тестировать в Google AI Studio или интерфейсах нужных вам LLM. 3. Тестируйте адаптивы вашего приложения Даже если на вашем 16-дюймовом ноутбуке веб-приложение выглядит идеально, это не значит, что оно так же откроется у всех. Модель часто использует классы, которые криво адаптируются под разные экраны. В итоге у кого-то на iPhone едет верстка, а на 13-дюймовом экране ломаются блоки. Тестируйте разные размеры экрана через Dev Tools браузера или просите знакомых дать фидбек, чтобы вовремя поправить адаптив (хотя даже после тестов у меня периодически проскакивают проблемы адаптива). 4. Для динамического контента используйте БД и JSON Цены, промпты, описания - все, что будет регулярно меняться, сразу выносите из кода в отдельные .json файлы или БД. Заодно попросите агента накидать простенький интерфейс для их редактирования. Зачем? Если забить все тексты в код, файл сильно раздувается. Модель начинает терять контекст и делает синтаксические ошибки. Меньше кода - проще поддержка. 5. Заставьте агента писать документацию и тесты Прямо в системном промпте зафиксируйте два жестких правила: • Писать документацию. • Писать тесты к новому функционалу. Отличная практика - держать в корне проекта PRD с описанием функционала, план реализации и файл README. Заставляйте агента постоянно с ними сверяться и обновлять их. Если проект пойдет в долгосрок, это спасет вашу архитектуру. 6. Защита от халявщиков и статусы оплаты Интеграция платежек - отдельная боль. ИИ не учитывает, что какая-то крыса может открыть DevTools и поменять цену подписки на 1 рубль. Особое внимание обращайте на промежуточные статусы. Например, пользователь нажал "назад" при оплате, и платеж повис в статусе pending. Если агент написал базовую логику "оплачено / не оплачено" (if / else), то при возврате пользователь получит ваш продукт бесплатно. Просите агента прописывать цепочку условий (if / elif / else if), чтобы обрабатывать каждый статус отдельно: успешную оплату, отмены, и ожидания. После - тестируйте руками. 7. Берегите свои API-ключи Агенты до сих пор периодически хардкодят API-ключи прямо в код, игнорируя .env файлы. Если вы просто на вайбе жмете Accept и пушите код в прод, ключи рано или поздно утекут. В лучшем случае вы обнулите баланс карты, в худшем - влезете в огромные долги. • Всегда ставьте жесткие лимиты трат в кабинетах API. • Перед пушем в продакшн просите агента: "Проверь код на наличие захардкоженных значений, ключей и доменов". Хоть с ИИ и можно затащить сложный продукт в соло, но архитектором, который держит в голове безопасность, удобство и логику, все равно остаетесь