Обучение вайбкодингу: с чего начать и как проверить результат

Что такое вайбкодинг и кому стоит ему учиться

У Infoxchange есть карточка записи занятия для некоммерческих организаций: участникам предлагают выбрать задачу, определить минимальную полезную версию проекта и описать требования с границами безопасности. Мне близко такое начало: обучение вайбкодингу начинается с вопроса, что именно нужно человеку, который будет пользоваться результатом. Нейросеть можно выбрать позже. Здесь я сужу о содержании программы, а не о качестве самого занятия. Источник: Infoxchange.

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

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

Для меня сотрудник освоил полезный рабочий навык, когда может изменить свой проект, объяснить обнаруженную ошибку и вернуть его в рабочее состояние. Для одноразового макета это слишком высокая планка. Если нужно лишь обсудить расположение кнопок, зачем превращать знакомство с инструментом в подготовку инженера?

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

С чего начать обучение вайбкодингу с нуля

Для первого задания я бы выбрала каталог учебных материалов с поиском по названию. Это пример упражнения, а не кейс CRT. Пользователю нужно найти нужную карточку – результат легко проверить. Поиск, пустую выдачу и сброс фильтра можно отработать без подключения к рабочей базе компании.

А вот с «собери нам CRM» я бы не начинала. За этой формулировкой пока нет ответов: кто будет работать в системе, что хранить и как проверять результат. Сначала стоит записать один завершённый сценарий и убрать всё, без чего он всё ещё решает задачу.

Перед первым запросом к ИИ можно заполнить такой шаблон:

К заданию я бы добавила просьбу: «До генерации кода перечисли вопросы и неоднозначности». Ответ модели поможет заметить, где собственная мысль ещё расплывается. Но решать, что войдёт в проект, всё равно человеку.

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

Как пройти путь от запроса к проверяемому проекту

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

1. Описать ожидаемое поведение. До генерации сотрудник записывает, что увидит пользователь и какими действиями проверит результат. Для каталога – поиск существующего названия и запрос, которому ничего не соответствует.
2. Получить небольшое изменение. Сначала вывести карточки, затем добавить поиск. После каждого шага свериться с заданием. Когда просишь весь сервис сразу, труднее найти решение, из-за которого появилась ошибка.
3. Проверить результат самостоятельно. Ввести запрос руками, очистить поле, повторить действие. Рассказ нейросети о том, что она исправила, эту проверку не заменяет.
4. Сохранить проверенное состояние. Использовать Git – систему истории изменений – или доступный в учебной среде механизм версий. Подписать сохранение так, чтобы позже не пришлось гадать, что в нём работает.
5. Восстановить проект после неудачного изменения. В учебной копии наставник может предложить заведомо неудачную правку. Ученику нужно вернуться к сохранённому состоянию и снова выполнить проверки.

Техническую базу включают и в программы для людей без опыта разработки. Например, heg.ai включает в обучение устройство приложения, Git, откат изменений и запуск проекта. Я бы смотрела, дают ли ученику проделать всё это самому. Тема в оглавлении ещё не означает, что человек освоил действие.

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

Разработчику нужно задание посложнее. Я бы попросила прочитать предложенные изменения, назвать затронутые части системы и проверить, сохранилось ли прежнее поведение. Затем – объяснить, почему решение подходит требованиям. Так мы подходим к инженерной ответственности, которую в CRT предполагает разработка с ИИ-агентами.

Почему бесконечные просьбы «исправь» заводят в тупик

Автор Хабра okoloboga описал знакомый по самой логике работы тупик. Сначала он работал через чаты, затем перешёл в Cursor. Переход снял прежние трудности, но принёс другие: структура проекта размывалась, уже исправленные ошибки возвращались. Автор начал фиксировать решения и планы в документации, а для проблем, которые ходили по кругу, – записывать известные обстоятельства и неудачные попытки. Это личный опыт разработчика, а не исследование эффективности обучения. Источник: разбор okoloboga.

Этот случай я бы превратила в упражнение: остановить исправления и попросить сотрудника восстановить ход событий. Вспомнить, что работало до изменения, какое действие вызвало сбой, что уже пробовали и как проверяли результат. Иначе на чём строить следующую попытку?

Для ответа хватит короткой записи:

• Ожидали: поиск находит карточку по части названия.
• Получили: после изменения поиск работает только при полном совпадении.
• Проверили: карточка есть в исходном каталоге.
• Пробовали: изменить текст запроса к ИИ; поведение осталось прежним.
• Следующий шаг: сравнить последнюю правку с рабочей версией вместе с наставником.

Это условный пример журнала ошибки. Польза здесь в наблюдениях, которые можно проверить. «ИИ опять всё сломал» передаёт раздражение, но не помогает выбрать следующий шаг. С описанием конкретного действия уже есть что разбирать.

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

Как проверить результат обучения без сертификата

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

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

Эту таблицу я бы использовала для разговора о развитии, без общего балла. Человек может уверенно ставить задачу и пока просить помощи при восстановлении. Вот и следующая тема обучения. Объявлять весь результат неудачным из-за неё я бы не стала.

В CRT ориентиром служит роль AI Software Engineer: инженер с ИИ-инструментами ведёт задачу от бизнес-постановки до работающего решения. Такой проверкой я предлагаю оценивать, насколько сотрудник приблизился к самостоятельности. Новичок не становится инженером автоматически. И речь здесь не о действующей учебной программе CRT: программа обучения компании пока не опубликована.

Что спросить перед выбором курсов вайбкодинга

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

В программе Яндекс Практикума заявлены проекты с ревью, а для индивидуального проекта – путь от проектирования до технического разбора. За эти признаки можно зацепиться при первом отборе. Дальше я бы уточнила условия конкретного формата:

• Будет ли самостоятельное задание с требованиями, отличающимися от примера преподавателя?
• Кто проверяет работу и объясняет ошибки?
• Нужно ли после обратной связи самому внести исправления?
• Есть ли практика сохранения и восстановления проекта?
• С какими ограничениями можно принести собственную рабочую задачу?

Как работодатель я бы заранее выделила время на практику и договорилась о результате: какой проект сотрудник покажет и что выполнит самостоятельно. Просмотр уроков легко вписать в отчёт. Практике же нужно место в рабочем расписании.