Вайб-кодинг: что это и как аналитику работать с Claude Code и Cursor
Вайб-кодинг — создание программы через запросы к ИИ на обычном языке. Для аналитика показываем, как читать diff, тестировать код и сверять результат.
Содержание статьи
Вы просите ассистента посчитать CSV, через минуту уже видите график. Вайб-кодинг — создание и исправление программы через запросы к ИИ на обычном языке, часто без подробного чтения кода. Для отчётной аналитики такой черновик нужно превратить в проверенный расчёт: прочитать diff, выполнить тест и сверить итог.
Вайб-кодинг — короткий ответ
Аналитику дали CSV с рейсами и попросили к вечеру показать выручку. Можно описать задачу ИИ-помощнику, получить скрипт и быстро увидеть таблицу. Это один из вариантов работы, которую называют вайб-кодингом: человек ведёт разработку естественным языком, а модель пишет и исправляет код по обратной связи. В исходном употреблении акцент был на свободном эксперименте, когда автор почти не читает код. Для отчётной аналитики эту часть нельзя переносить буквально.
Разница между прототипом и принятым расчётом — проверка. Попросить модель написать код полезно. Отправить число руководителю, не прочитав фильтры, JOIN, обработку пропусков и контрольный итог, — риск. Даже скрипт, который успешно запускается, может считать не ту метрику. Поэтому у аналитика рабочий цикл выглядит так: маленькая задача → diff → запуск на учебных данных → известный итог → только затем реальная выгрузка.
В этой статье не будет рейтинга «лучшей нейросети для кода». Мы разберём, где подход экономит время, где создаёт невидимую ошибку и какие вопросы нужно задать самому себе перед тем, как назвать результат готовым.
| Задача | Хороший первый шаг | Граница публикации |
|---|---|---|
| Разовый парсер учебной выгрузки | Черновик с ИИ и маленький тест | Проверить пропуски и типы |
| Прототип дашборда | Собрать на синтетических данных | Сверить метрики с контрактом |
| Еженедельный финансовый отчёт | Попросить код и тесты | Код-ревью, независимый итог, владелец |
| Запись в production | Не давать доступ на стадии черновика | Отдельная инженерная проверка |
Откуда взялся термин и что он означает
Термин vibe coding ввёл Андрей Карпаты в посте на X в феврале 2025 года. Он описывал программирование, при котором человек формулирует желания и смотрит на поведение программы, почти не погружаясь в исходный код. Это было описание личной практики для небольших проектов, а не стандарт качества финансовых расчётов. Для отчётной работы важнее различать свободный прототип и проверенный расчёт.
Сегодня слово употребляют шире: иногда так называют любое написание кода с ИИ. Для честного разговора полезно разделять два режима. В первом модель помогает написать функцию, а аналитик читает diff, запускает тесты и отвечает за логику. Во втором человек принимает результат «по ощущениям», лишь бы экран выглядел правильно. Второй режим может годиться для одноразовой игрушки, но в аналитическом отчёте создаёт неясный источник цифр.
Ни модель, ни редактор не знают ваше определение выручки, пока вы не дали его явно. Если менеджер под «выручкой» имеет в виду только выполненные рейсы, код без фильтра статуса может аккуратно сложить все строки. Компьютер выполнит именно написанное правило; ошибка будет в постановке и проверке, а не в арифметике.
Какие задачи аналитику удобно прототипировать
Первый кандидат — разовая обработка файла с понятной структурой. Например, выгрузка из системы приходит в двух кодировках, с лишними пробелами в названиях колонок и датой как текстом. Модель может быстро предложить загрузку, нормализацию заголовков и сообщение об ошибке для неподходящего формата. После этого проверьте файл с пустой строкой, неверной датой и неожиданным столбцом.
Второй кандидат — прототип дашборда на синтетических данных. Можно попросить простой фильтр периода и график по категориям, чтобы согласовать расположение и вопросы пользователей. Но перед подключением реального источника нужно переписать требования: какие статусы входят, какой часовой пояс, что делать с возвратами и как проверять сумму в графике. Внешне законченный экран не равен принятой модели данных.
Третий — парсер регулярной выгрузки. Модель помогает собрать код чтения CSV/Excel и нормализации типов. Здесь проверка особенно важна: формат файла меняется, разделитель отличается, десятичная запятая превращает число в текст. Хороший парсер отказывает понятной ошибкой вместо того, чтобы тихо отбросить строки и показать уменьшившийся итог.
Пример на таблице рейсов: запрос к помощнику
Возьмём учебный day.csv из нашего эксперимента с базой «Авиаперевозки». Одна строка — рейс за 5 августа 2026 года; в файле 548 строк и колонка revenue. Правильная сумма по файлу — 438 406 200 ₽, медиана — 209 750 ₽. Числа получены воспроизводимым скриптом по сохранённому CSV, а не ответом модели. Ссылка на весь эксперимент и ограничения — ниже.
Не просите «напиши анализ рейсов». Дайте контракт: прочитать CSV, проверить обязательные колонки, преобразовать выручку в число, показать число строк, сумму и медиану; не выбрасывать строки молча. Отдельно скажите, что статус не фильтруется в этом учебном контроле, иначе код посчитает другой показатель. Попросите вывести сам код и проверки, а не только конечное число.
После получения черновика откройте diff. Посмотрите, не появились ли сетевые запросы, пакетные установки, чтение других файлов, запись назад в исходный CSV. Это не паранойя: агент с терминалом имеет гораздо больший радиус действия, чем функция sum. Даже если инструкция короткая, перечень реально совершённых действий важнее обещанного поведения.
Напиши Python для локального day.csv. Одна строка = один рейс.
Проверь колонки revenue и flight_no. Не фильтруй status.
Преобразуй revenue в число; при ошибке остановись, не удаляй строки.
Выведи число строк, сумму revenue и медиану.
Добавь assert: строк 548, сумма 438406200, медиана 209750.
Не читай другие файлы, не обращайся к сети и не переписывай CSV.
Покажи код и объясни каждую проверку.Код, который можно выполнить и проверить
Ниже минимальный вариант после вычитки. Он не пытается объяснить бизнесовую причину и не строит график — это только контроль данных. errors="raise" останавливает выполнение на нечисловом значении; проверка notna() не допускает пропуск в выручке. Если файл изменился и число строк перестало совпадать, assert не следует просто удалять: сначала выясните, обновился источник или потерялись записи.
В примере используется pandas. Тот же принцип применим к SQL: модель пишет запрос, а база выполняет его; аналитик сверяет зерно, фильтры и итог. Получить ожидаемую сумму в этом файле — необходимая, но недостаточная проверка для новой выгрузки. Для неё нужен новый известный итог, контроль хотя бы нескольких строк и правило обработки неожиданных статусов.
Команда запускается локально из каталога с CSV. В репозитории сохранён отдельный проверочный скрипт, который читает исходный файл эксперимента. Он запускается и фиксирует фактический вывод. Если в чужом ответе есть та же цифра без кода и пути к файлу, одинаковый результат может быть случайным совпадением.
import pandas as pd
df = pd.read_csv("day.csv")
required = {"flight_no", "revenue"}
assert required <= set(df.columns)
assert len(df) == 548
revenue = pd.to_numeric(df["revenue"], errors="raise")
assert revenue.notna().all()
assert int(revenue.sum()) == 438_406_200
assert int(revenue.median()) == 209_750
print(len(df), int(revenue.sum()), int(revenue.median()))Почему успешный запуск не доказывает верную метрику
Интерпретатор точно сложит то, что передали, но не решит, какие рейсы относятся к отчёту. Если выручка в файле включает отменённые рейсы, а нужен доход по выполненным, код без фильтра даст правильную сумму по столбцу и неправильную бизнесовую цифру. Для принятого расчёта нужен словарь метрик: входная таблица, зерно, включённые статусы, дата, валюта, возвраты и точность округления.
Ещё одна ловушка — заранее подсказать модели эталон и поверить assert. Нечестный или ошибочный черновик может просто напечатать известное число или подогнать фильтр под него. Поэтому проверяйте тело расчёта: сумма должна происходить из колонки, а тест — сравнивать её с эталоном. На новых данных контролируйте не только итог, но и строки по нескольким сегментам.
В нашем эксперименте текстовые ответы моделей по длинной таблице часто ошибались, а Python с выполнением кода по загруженному файлу дал 99 верных ответов из 108 попыток. Один прогон завершился без итогового ответа. Это не испытание Claude Code или Cursor и не гарантия для вашего кода: там были четыре модели OpenAI и конкретный учебный набор.
Ошибка 1: JOIN размножает строки
ИИ-помощник предлагает объединить orders и order_items, затем сложить orders.total. Если у заказа три позиции, общая сумма заказа повторится трижды. SQL или pandas merge выполнятся без ошибок, график будет выглядеть правдоподобно, а выручка завысится. Это одна из опасных аналитических ошибок: её нельзя увидеть по красной строке исключения.
Перед соединением назовите зерно обеих таблиц и ожидаемую кардинальность. Если нужна выручка по заказам, считайте её в таблице заказов до JOIN либо агрегируйте строки позиций до одного заказа. Сравните число уникальных заказов и сумму до и после. Для pandas используйте validate="one_to_one" или другой ожидаемый режим там, где он соответствует данным; проверка должна падать, когда предположение нарушено.
Смысл чтения diff здесь не в стиле кода. Вы ищете место, где изменилось зерно. Если модель заменила groupby(order_id) на прямой merge, это изменение бизнесовой логики даже при десяти строках кода. Отдельный разбор типичных ошибок pandas полезен, если ваш черновик работает с DataFrame.
Ошибка 2: пропуски и даты исчезают из расчёта
В pandas groupby по ключу с пропуском по умолчанию может не показать эту группу. Код модели вернёт сумму по видимым сегментам, а общий итог станет меньше. Если доля пропусков значима, исследователь может принять это за падение бизнеса в одном канале. Вопрос кода — считать NULL отдельной группой, исправить источник или исключить строки по явно согласованному правилу.
Даты как строки тоже опасны. Сортировка текстовых значений может дать неожиданный порядок, а сравнение с границей периода — неверный срез при разных форматах. Преобразуйте колонку в дату с явным форматом и часовым поясом, а невозможные значения выводите отдельно. Не позволяйте черновику молча использовать errors="coerce" и затем выбросить NaT.
Эта пара ошибок редко заметна на демонстрации из трёх строк. Добавьте маленькие тестовые файлы: один с пустым ключом, один с некорректной датой, один с пограничным временем. Хороший код либо выдаст правильную группу, либо остановится с понятным сообщением. Если он «успешно» построил график без этих строк, проверка не пройдена.
Ошибка 3: неочевидное округление и валюты
Вы просите средний чек, а модель считает revenue / orders и округляет каждый заказ перед суммированием. Или складывает суммы в двух валютах, потому что в выгрузке есть колонка currency, но в промпте о ней забыли. Результат может отличаться от бухгалтерского отчёта без единой ошибки выполнения.
Зафиксируйте единицы до кода: ₽ или копейки, валовая или чистая сумма, момент конвертации, порядок округления. Если в данных смешаны валюты, код должен отказаться складывать их без курса и даты курса. Для финансовой суммы часто удобнее целое число минимальных единиц или Decimal; тип float может принести дополнительное округление.
На ревью ищите не только round(), но и скрытые приведения типов. Модель может заполнить пустую выручку нулём, посчитать невалидный текст как 0 или перевести строку с разделителем тысяч неправильно. Изменение такого правила меняет смысл показателя и требует согласования, даже если скрипт стал короче.
Ошибка 4: агент пишет дальше границы задачи
Задача звучала как «посчитать CSV», а ассистент добавил пакет, создал файл отчёта и предложил отправить его в чат команды. Иногда это удобно. Иногда новый пакет имеет неподходящую лицензию или получает сетевой доступ, а отчёт содержит клиентские строки. Вайб-кодинг соблазняет принять все изменения разом, потому что на экране появился результат.
Ограничьте рабочую папку и доступы. Перед запуском прочитайте команды терминала и список изменённых файлов. После работы посмотрите git diff: не переписан ли исходный файл, не исчезли ли старые тесты, не добавлены ли секреты. Для чувствительной выгрузки используйте локальный обезличенный образец, а не продовые данные в промпте.
Если модель предлагает «починить» несовпадение эталона удалением assert, остановитесь. Тест — сигнал для расследования, а не помеха генерации. Запросите объяснение расхождения по строкам: сколько вошло, сколько отфильтровано, какие ключи отсутствуют и почему изменился результат.
Практический цикл: маленькая задача, дифф, тест
Начните с одного шага: «прочитай CSV и выведи число строк». Проверьте код и фактический вывод. Следующий шаг — типы и пропуски, потом агрегат, затем контроль. Так ошибка локализуется между двумя изменениями. Большой запрос «сделай аналитический проект» даёт больше кода за раз, но резко усложняет поиск места, где поменялся смысл данных.
Просите модель сначала перечислить допущения: зерно, фильтр, дата, единица, обработка NULL. Если допущение неизвестно, лучше уточнить у владельца метрики. После генерации смотрите diff строка за строкой и запускайте статическую проверку или тесты проекта. Отдельно проверьте граничные случаи, которые модель не выбрала сама: пустой файл, дубликат ключа, новое значение статуса, две строки с одним идентификатором.
Когда тесты проходят, сохраните рабочий запрос или скрипт в системе версий. В отчёте укажите версию данных и ссылку на код. На следующей неделе повторите запуск без переписывания всего с нуля. Если приходится каждый раз просить ассистента «посчитай так же, как вчера», процесс ещё не воспроизводим.
Какие инструменты существуют и что подтверждено
Claude Code по официальной документации работает с проектом через чтение и редактирование файлов, запуск команд и взаимодействие с инструментами. Cursor Agent описывает поиск по коду, изменение файлов и терминальные вызовы. GitHub Copilot в режиме агента также предлагает правки и команды. Это полезные классы инструментов для создания аналитического кода; какой из них подходит команде, зависит от среды, политики данных и навыка ревью.
Jupyter-помощники работают ближе к ячейкам ноутбука. Здесь особенно важно проверять порядок исполнения: результат старой ячейки может остаться в памяти и создавать иллюзию воспроизводимости. Независимо от продукта перезапустите ноутбук сверху вниз на чистом ядре и сохраните выходные данные только после этого.
Возможности, интерфейсы и условия доступа продуктов меняются. Мы не сравниваем цены и не обещаем доступность в какой-либо стране. Проверяйте текущую документацию и политику компании перед отправкой данных в сервис. У аналитика критерий выбора практический: может ли он видеть действия, ограничивать права и повторить расчёт без скрытого состояния.
Где вайб-кодинг лучше остановить
Если код будет начислять выплаты, обновлять production-таблицу, формировать внешнюю отчётность или обрабатывать персональные данные, скорость генерации не должна быть единственным критерием. Нужны принятая спецификация, ревью владельца данных, тесты на граничных случаях и контролируемая среда запуска. ИИ может помочь написать черновик, но право на выполнение и публикацию должно быть отделено.
Для расчёта, который идёт менеджеру разово, уровень проверки тоже зависит от последствий. Сумма в презентации о бюджете требует как минимум независимого итога и чтения фильтров. Для исследовательской заметки можно пометить результат предварительным и открыть код. Самая вредная ситуация — назвать демонстрационный скрипт проверенной метрикой только потому, что график выглядит убедительно.
Не полагайтесь на «модель всё проверила». Попросите список проверок и выполните их сами. Если нет времени прочитать diff и сравнить итог, лучше показать честный черновик с пометкой об ограничении, чем точное на вид число без источника.
Чек-лист перед тем, как принять код
Прочитайте исходную задачу рядом с diff. Проверьте список файлов, новые зависимости и команды. Назовите зерно таблицы и ключ каждого JOIN. Выпишите фильтр, дату, часовую зону, единицу и правило пропусков. Запустите код на учебном файле с известным результатом и одном плохом файле, который должен вызвать ошибку.
Сверьте число строк до и после преобразований, общий итог и хотя бы один сегмент независимым способом. Убедитесь, что программа не читает и не отправляет лишние файлы. Сохраните версию входного файла и скрипта. Если код попадает в расписание или отчёт, добавьте тесты в репозиторий и назначьте владельца обновлений.
Эти действия занимают время, но экономят его на поиске тихой ошибки после публикации. Вайб-кодинг полезен как быстрый способ получить первый рабочий вариант. Аналитик превращает его в результат тогда, когда делает вычисление проверяемым.
- Задача и допущения записаны.
- Diff прочитан, побочные действия известны.
- Тест с эталоном прошёл на реальном исполнении.
- Есть проверка пустых и дублированных данных.
- Число в отчёте связано с версией кода и источника.
Частые вопросы
Что такое вайб-кодинг простыми словами? Это способ делать программу через просьбы к ИИ и итерации по результату. В исходном смысле человек может почти не читать код; для аналитики с отчётными числами такой режим рискован.
Можно ли аналитику писать Python с помощью Claude Code или Cursor? Да, эти инструменты умеют работать с кодом и файлами по своей документации. Ответственность за определение метрики, доступ к данным и тесты остаётся у аналитика и команды.
Чем вайб-кодинг отличается от обычной помощи ИИ с кодом? Когда вы читаете изменения, запускаете тесты и понимаете логику, это уже контролируемая работа с помощником. Когда принимаете результат по внешнему виду и не разбираете исходник, риск скрытой ошибки выше.
Как проверить код нейросети для анализа данных? Запустите на сохранённом наборе с известным числом строк и итогом, проверьте JOIN и фильтры, прочитайте diff, повторите на граничном случае. Одного «программа не упала» недостаточно.
Где лучше не использовать такой подход без ревью? В продовых изменениях, финансовой отчётности, обработке персональных данных и автоматической отправке результата. Черновик можно попросить у модели, но принятие требует независимой проверки.
Материалы по теме

Нейросеть для Python: как писать и проверять код анализа
Как использовать нейросеть для Python и pandas: проверенный пример на 548 рейсах, пять ошибок с кодом до и после, тесты загрузки, merge, группировок и дат.

LLM: что это — токены, контекст и температура на примерах
LLM — большая языковая модель, которая строит ответ из токенов. Объясняем контекст, температуру и границы расчётов на реальном примере аналитика.

Нейросеть для анализа данных: эксперимент на 548 рейсах
Проверили четыре нейросети на таблице рейсов с известными ответами: ответ текстом, SQL и код на Python. Какая нейросеть лучше для анализа данных и как её проверить.