5 ошибок при работе с ИИ-кодингом: разбор на реальном проекте

Однажды я случайно создал приложение в стиле vibe coding. Случайно — потому что не собирался отдавать весь процесс на откуп ИИ, но всё к этому и шло. Проект был простой: консольное приложение на C#, которое отправляет текст в языковую модель, извлекает имена людей и сохраняет их в Postgres. В теории — пара дней работы. На практике — неделя отладки и несколько важных уроков.

Откуда взялись ошибки

Первая ошибка — предположение, что ассистент помнит, как я люблю работать. В прошлом у меня был один небольшой проект с помощью ИИ, и я ожидал, что второй пройдёт в том же стиле: мы вместе обсуждаем решения, шаг за шагом. Но я не сказал об этом явно. Поэтому, когда я разрешил ассистенту действовать самостоятельно и включил субагентов, он просто понёсся вперёд.

Вторая ошибка — слишком общее одобрение. Я думал: «Он остановится, уточнит, продолжит». Не остановился. Итог — код, который я не до конца понимал и который вёл себя не так, как я хотел.

Что пошло хорошо

Начало было обнадёживающим. Мы обсудили выбор модели: сравнивали OpenAI и Gemini, взвешивали стоимость и риски. Я выбрал бесплатный тариф Gemini — для экспериментов подходит. Затем с помощью скилла /superpowers ассистент составил спецификацию и план. Он задавал вопросы, уточнял детали, обсуждали безопасность переменных окружения, чтобы ключи не утекли на GitHub. Это было похоже на парное программирование — именно то, чего я ждал от всего проекта.

Баг, который я не писал

Первая проблема — жёстко зашитый текст для анализа. В начальной версии приложение отправляло фиксированный абзац. Я сохранял результаты в базу для тестов, и одинаковые записи выглядели одинаково — невозможно было понять, какая из них свежая. Пришлось добавить ручной ввод текста. Так я смог протестировать разные сценарии: повторяющиеся имена, отсутствие имён.

Вторая проблема — модель, зашитая в URL. Код выглядел так:

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

Как надо было делать

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

• Определите стиль работы заранее. Напишите инструкцию: хочешь ли ты, чтобы ассистент спрашивал на каждом шагу, или можешь действовать самостоятельно. Положите её в файл в репозитории — и тогда не придётся полагаться на «память» модели.
• Не давайте общее одобрение. Разрешая ассистенту «просто делать», вы теряете контроль. Лучше разбивать задачу на этапы и согласовывать каждый.
• Проверяйте код вручную. Автор запускал тесты, находил несоответствия и обсуждал исправления. Это нормально: доверяй, но проверяй.
• Следите за внешними зависимостями. API меняются, модели устаревают. Не хардкодьте то, что может измениться, — выносите в конфигурацию.
• Используйте инструкционные файлы. Планирование — это хорошо, но недостаточно. Подробный файл с правилами работы экономит часы отладки.

Ожидание vs реальность

Итог

Главный урок: ассистент — это инструмент, а не партнёр. Он не запоминает ваши предпочтения, если вы их не зафиксировали. Он не остановится, если вы не скажете. И он не гарантирует, что код работает правильно, — это ваша зона ответственности.

Простые решения — инструкция в репозитории, явные ограничения, ручные тесты — превращают хаотичный vibe coding в управляемую разработку. Планирование — это только начало. Настоящая работа начинается, когда вы начинаете проверять.