Пишем код с кайфом или вайбкодинг без нервотрепки

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

Основоположник направления Андрей Карпатый (экс-директор по ИИ Tesla, сооснователь OpenAI) называет вайбкодинг способом «полностью отдаться вайбу и забыть, что код существует». Но «отдаться вайбу» не всем легко, поэтому расскажу о своем недавнем кейсе.

Передо мной стояла задача создать ИИ-агента для известной соцсети, чтобы он проводил онбординг бизнес-пользователей, настраивал рабочее расписание и отвечал на сообщения от лица пользователя, консультируя клиентов и записывая их на встречи.

Запуск MVP требовался «еще вчера», поэтому пришлось «вайбкодить».

Задачу разделил на две части:

1. Агент для онбординга (жесткий сценарий, где пользователь только отвечает на вопросы);

2. Агент для консультаций и записи на встречи (гибкий сценарий, где пользователь может вести себя непредсказуемо).

Я использовал LangGraph, так как он удобен для удерживания пользователей в определенных узлах графа (своего рода «когнитивная архитектура» ИИ-агента), не давая перескочить куда не надо.

Если бы все делал вручную «с нуля» (включая интеграцию и тестирование), ушло бы пару недель. Но я решил использовать Cursor с режимами чата (как ChatGPT) и агента (главная магия, которая генерирует и исправляет код).

Сперва я описывал функционал каждого узла графа в режиме чата в виде ТЗ: какие входы и выходы и как обрабатывается контекст. Затем переключался в режим агента, чтобы Cursor сгенерировал код и внес необходимые правки.

Первый агент (онбординг) ведет пользователя по жесткому флоу: спрашивает информацию об услугах, проверяет ее, а затем настраивает расписание. Свернуть пользователь не может. Состояния графа запоминаются, и при любом новом сообщении процесс продолжает идти с того же места.

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

Это две разные архитектуры, и ИИ пока сам не совсем удачно выбирает архитектурные паттерны. Теперь роль программиста - быть архитектором, который четко формулирует ТЗ и задает видение результата, тогда итог становится предсказуемым, а нервы остаются целы.

ИИ не всегда генерирует рабочий код с первого раза, но «автопочинка» помогает быстро исправлять ошибки. Планирую добавить ИИ-симулякру пользователя, чтобы экономить время на тестировании.

В итоге MVP сделал за неделю вместо двух, включая тестирование и интеграцию, то есть вдвое быстрее. С должной сноровкой и автотестами можно ускориться еще.

Итак, 5 советов по использованию ИИ-копилотов:

1. Четкое ТЗ: сформулируйте архитектуру и функциональность, учитывая различные юзкейсы.

2. Правила: определите стиль кода, стек, процессы и окружения, это убережет от неожиданных изменений.

3. Узконаправленные команды. Разбивайте сложные задачи на мелкие шаги, чтобы минимизировать творческую вольность ИИ и сразу проверяйте результат.

4. Небольшой контекст. Слишком большой объем информации снижает качество работы модели, поэтому иногда начинайте новый чат.

5. Тестирование. Пишите end-to-end и модульные тесты, это защитит уже работающий функционал от поломок, а также делайте частые коммиты, чтобы быстро откатиться к стабильной версии.

Сегодня один технически подкованный человек может запустить стартап буквально за неделю, используя всего пару инструментов и вайбкодинг. Для бизнес-пользователей копилоты пока что сложны, а автопилоты еще не готовы к сложным проектам.

Остается автоматизировать маркетинг для привлечения пользователей, но об этом расскажу в другой раз.

А какой опыт использования ИИ-копилотов у вас?

#кейсы