Однажды я случайно создал приложение в стиле vibe coding. Случайно — потому что не собирался отдавать весь процесс на откуп ИИ, но всё к этому и шло. Проект был простой: консольное приложение на C#, которое отправляет текст в языковую модель, извлекает имена людей и сохраняет их в Postgres. В теории — пара дней работы. На практике — неделя отладки и несколько важных уроков.
Откуда взялись ошибки
Первая ошибка — предположение, что ассистент помнит, как я люблю работать. В прошлом у меня был один небольшой проект с помощью ИИ, и я ожидал, что второй пройдёт в том же стиле: мы вместе обсуждаем решения, шаг за шагом. Но я не сказал об этом явно. Поэтому, когда я разрешил ассистенту действовать самостоятельно и включил субагентов, он просто понёсся вперёд.
Вторая ошибка — слишком общее одобрение. Я думал: «Он остановится, уточнит, продолжит». Не остановился. Итог — код, который я не до конца понимал и который вёл себя не так, как я хотел.
Что пошло хорошо
Начало было обнадёживающим. Мы обсудили выбор модели: сравнивали OpenAI и Gemini, взвешивали стоимость и риски. Я выбрал бесплатный тариф Gemini — для экспериментов подходит. Затем с помощью скилла /superpowers ассистент составил спецификацию и план. Он задавал вопросы, уточнял детали, обсуждали безопасность переменных окружения, чтобы ключи не утекли на GitHub. Это было похоже на парное программирование — именно то, чего я ждал от всего проекта.
Баг, который я не писал
Первая проблема — жёстко зашитый текст для анализа. В начальной версии приложение отправляло фиксированный абзац. Я сохранял результаты в базу для тестов, и одинаковые записи выглядели одинаково — невозможно было понять, какая из них свежая. Пришлось добавить ручной ввод текста. Так я смог протестировать разные сценарии: повторяющиеся имена, отсутствие имён.
Вторая проблема — модель, зашитая в URL. Код выглядел так:
var geminiUrl = $"https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent?key={geminiApiKey}";Посреди тестирования модель перестала быть доступной — её вывели из эксплуатации. Я не знал, какие модели вообще доступны. Пришлось вынести название модели в отдельную переменную окружения, чтобы менять её без правки кода.
Как надо было делать
Из этого опыта можно вытащить несколько практических правил. Они пригодятся всем, кто работает с ИИ-ассистентами.
- Определите стиль работы заранее. Напишите инструкцию: хочешь ли ты, чтобы ассистент спрашивал на каждом шагу, или можешь действовать самостоятельно. Положите её в файл в репозитории — и тогда не придётся полагаться на «память» модели.
- Не давайте общее одобрение. Разрешая ассистенту «просто делать», вы теряете контроль. Лучше разбивать задачу на этапы и согласовывать каждый.
- Проверяйте код вручную. Автор запускал тесты, находил несоответствия и обсуждал исправления. Это нормально: доверяй, но проверяй.
- Следите за внешними зависимостями. API меняются, модели устаревают. Не хардкодьте то, что может измениться, — выносите в конфигурацию.
- Используйте инструкционные файлы. Планирование — это хорошо, но недостаточно. Подробный файл с правилами работы экономит часы отладки.
Ожидание vs реальность
| Ожидание | Реальность |
|---|---|
| Ассистент помнит мой стиль и спрашивает | Забыл всё и понёсся вперёд |
| Код легко понять и поддерживать | Пришлось разбираться и переделывать |
| Ошибки всплывут на этапе тестирования | Ошибки всплыли, потому что я сам проверял |
| Модель будет доступна всегда | Модель вывели из эксплуатации посреди работы |
Итог
Главный урок: ассистент — это инструмент, а не партнёр. Он не запоминает ваши предпочтения, если вы их не зафиксировали. Он не остановится, если вы не скажете. И он не гарантирует, что код работает правильно, — это ваша зона ответственности.
Простые решения — инструкция в репозитории, явные ограничения, ручные тесты — превращают хаотичный vibe coding в управляемую разработку. Планирование — это только начало. Настоящая работа начинается, когда вы начинаете проверять.
Fluxs
Комментарии (3)
Войдите, чтобы комментировать.