Кейс о вайбкодинге корпоративной системы и её тестировании

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

В один прекрасный день руководитель финансовой службы обратилась ко мне с вопросом: «У Иры отпускные за март на 4 700 рублей больше, чем должно быть. Гляньте, пожалуйста». Я открыл код, нашёл функцию расчёта отпускных, проверил формулу – она была правильной.

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

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

Кому не зайдёт?

Если вы пишете код руками и не собираетесь это менять – статья не про вас. Если вы уже выстроили тестирование сгенерированных продуктов как процесс – тоже, вы всё это проходили. Я написал для тех, кто посередине: продукт уже есть, а понимания ещё нет.

Постановка эксперимента

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

Условия оказались непростыми. Технического задания практически не было – только табличка и 20‑минутное видео с пояснениями к ней. Остальные требования поступали устно, по одному предложению. Команды тестирования не было.

Руководитель отлично понимал, что хочет получить, но с генерацией кода дела не имел. Я умел генерировать, но не знал, как на практике считаются многие штуки в 1С. Домен у одного, руки у другого, чертежа нет ни у кого.

Такие условия не создавали намеренно – они сложились сами собой. ТЗ не подготовили из‑за нехватки времени, тестировщика не привлекали, так как решили проверить, получится ли справиться силами двух человек, для которых эта задача не была основной. Именно сейчас, оборачиваясь назад, такой подход можно трактовать как своеобразный «дизайн эксперимента», а тогда это воспринималось как обычный рабочий вторник.

Что в итоге получилось?

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

Теперь о цене вопроса. За первый месяц закрыл больше двадцати исправлений, и две трети из них касались не мелких визуальных недочётов, а ошибок в расчётах. Работа над устранением ошибок продолжается до сих пор – вероятно, в подобных проектах багфиксинг становится не финальным этапом, а постоянным режимом работы.

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

И прораб этого тоже не знает, потому что прорабом выступает сам разработчик. В нашем контексте «гипсокартон» – это локально правдоподобная конструкция, чья реальная надёжность остаётся неизвестной.

Проблемы вайбкодинг-продуктов

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

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

Требование, сформулированное в одном предложении, обходится дороже, чем кажется на первый взгляд

Например, вся постановка задачи для подсистемы начисления отпусков сводилась к фразе: «Сделай начисление отпусков».

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

Так, система начала начислять отпускные дни с первого рабочего дня всем сотрудникам – в том числе подрядчикам, которым отпуск не положен. В течение трёх недель система корректно, на первый взгляд, вела расчёт, и я не проверял эти данные: просто не видел здесь зоны риска. Руководитель знал правильный подход, но не догадывался, что вопрос уже «закрыт» без его участия.

Демо‑версия обходится дешевле, чем подробное описание требований, – и в этом кроется ловушка

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

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

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

Вайбкодер, не погружённый в предметную область, не замечает нелогичных значений

Обычный разработчик, прописывая формулу вручную, нередко спотыкается на неясных моментах. В моём случае такого «момента проверки» не было: система сразу выдавала готовое число. Например, показатель окупаемости проекта – 47 % – выглядел вполне убедительно. Но когда финансист начала разбираться и задавать вопросы о логике расчёта, после нескольких раундов уточнений выяснилось, что исходная формула в системе была неверной.

Даже мой солидный опыт – в том числе в судебной бухгалтерии, управлении департаментами и ИТ – не гарантирует, что все расчёты будут корректны. Это был не первый и, вероятно, не последний случай, когда из‑за недочётов в логике выглядели неочевидными даже базовые вещи.

Суть проблемы проста: автоматизированная генерация убирает необходимость глубоко вникать в то, что создаётся. Для интерфейсов это удобно, а в бизнес‑расчётах – крайне рискованно.

Локально всё выглядит логично, а в общей картине – не согласовано

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

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

Пустые и редкие сценарии часто остаются вне зоны внимания

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

Ещё один случай – перерасчёт задним числом незаметно изменил уже выплаченные суммы. В реальной работе такие ситуации – обычная рутина, но в сгенерированном коде они не предусмотрены: система просто «не знает» о их существовании.

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

Деньги, даты и округления нередко ведут себя непредсказуемо

Так, денежные значения оказались в формате float: на экране отображалось 15 234,50, а в выгрузке – 15 234,49. Такой расхождение финансист не одобрит – и это справедливо.

Ещё одна проблема проявилась с расчётами ближе к полуночи: они «уезжали» в соседний месяц. Причина была в разнице часовых поясов: сервер работал в UTC+3, а у нас разница с Москвой превышала пять часов. Этот нюанс я не учёл заранее – столкнулся с ним уже на практике.

Тип данных зачастую выбирают, ориентируясь на типовые примеры, а не на специфику предметной области. В шаблонном коде деньги – просто число. Но в зарплатной системе такой подход чреват претензиями от бухгалтерии.

Повторное нажатие приводило к повторному начислению – и никаких следов операции не оставалось

Так, из‑за двойного нажатия на кнопку «Рассчитать» выплата задвоилась. Ситуация получилась неприятная.

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

Хуже самих дублей было их расследование: логов не было, правки задним числом никак не фиксировались. В итоге многие ошибки оставались в статусе «финансист видела, но воспроизвести нельзя».

Сгенерированные автотесты проверяют код, а не бизнес‑задачу

В проекте были тесты – и они показывали «зелёный» результат. Но строились они на основе самой реализации: просто фиксировали, что функция возвращает ожидаемое с точки зрения кода значение. Из‑за этого ошибка в формуле расчёта окупаемости прошла все проверки: тест воспринимал неверный результат как норму.

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

Чек‑лист тестировщика ИИ‑продукта

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

Эталон и требования

• Начинайте не с продукта, а с опроса заказчика – зафиксируйте требования в виде текста. Пробелы в техническом задании уже заполнены типовыми решениями, и без чётко прописанных требований вы будете сверять одно додуманное решение с другим. 
• Постройте с носителем домена эталонные кейсы: 5–10 сущностей, посчитанных руками в таблице. Сгенерированный расчёт правдоподобен по виду; отличить верное число от похожего на верное можно только внешним пересчётом. 
• Пройдите по каждой фиче с вопросом «а это кто решил?» и составьте список допущений. Каждое односложное требование незаметно обрастает молчаливыми решениями, часть из которых неверна. 
• Найдите фичи, которых никто не просил. Генерация порой добавляет «полезное» сверх запроса, а неучтённая фича – это дополнительный источник багов. 
• Сверьте словарь: одинаково ли заказчик и код понимают «ставку», «период», «начислено». Вайбкодер без домена закрепляет в коде первое попавшееся значение термина.

Дубли логики и согласованность

• Найдите все места, где считается одна и та же величина: поиском по коду, по названиям полей, по выгрузкам. Каждая сессия генерации могла построить свой расчёт, не зная о уже существующем. 
• Сверьте одно и то же число на всех экранах и во всех выгрузках до копейки. Дублированные расчёты расходятся в округлениях и версиях формулы. 
• После каждого исправления прогоняйте эталонные кейсы целиком, а не только чистые места. Связи между модулями случайны; правка в одном месте ломает соседнее без предупреждения. 
• Закладывайте регресс как основной режим работы, а не как этап перед релизом. Продукт меняется со скоростью генерации, и вчерашний прогон ничего не говорит о сегодняшней сборке.

Бизнес-расчёты

• Пересчитайте каждую формулу независимо – вне системы, на эталонных кейсах. Даже если расчёт выполняется и число выглядит корректно, сама формула может быть ошибочной. 
•  Проверяйте состав формулы, а не только результат: что входит в ставку, в базу, в период. Генерация берёт типовую формулу, а не формулу вашей компании. 
•  Прогоните сценарии с нулевыми и пустыми данными: сотрудник без ставки, проект без списаний, месяц без рабочих дней. Именно в таких случаях чаще всего заканчивается «счастливый путь» – и проявляются скрытые ошибки.
•  Прогоните отрицательные и «обратные» значения: возврат, удержание, отмена. В типовом коде их нет – значит, скорее всего, нет и у вас. 
•  Проверьте перерасчёт задним числом после уже проведённой выплаты. Это редкий сценарий с максимальной ценой ошибки; ИИ не строит его без прямой просьбы. 
•  Проверьте события в середине периода – приём, увольнение, смену ставки, например, 12‑го числа. Пропорциональные расчёты чаще всего упрощаются до целых периодов – именно это генерация нередко пропускает. 

Деньги и округления

• Проверьте тип данных для денежных значений и требуйте его замены, если используется float. В типовых примерах деньги часто представляют как число с плавающей точкой, но в реальных расчётах это приводит к расхождениям в копейках между отображением на экране и выгрузкой данных. 
•  Проверьте момент округления: до суммирования или после, и одинаково ли во всех местах. Дублированные расчёты округляются каждый по-своему. 
•  Сверьте итоги: сумма строк должна совпадать с итоговой строкой в каждой ведомости и выгрузке. Нередко итог считают отдельным сгенерированным кодом – по своей логике. Бывает и так, что сумма рассчитывается только в браузере и не участвует в дальнейших вычислениях. 
•  Гоняйте расчёты на больших суммах и большом числе строк. Ошибка плавающей точки растёт с объёмом и на демо-данных невидима. 
•  Проверьте единицы там, где их больше одной: часы и деньги, ставка в час и в месяц. Поле с именем rate генерация трактует как ей удобнее – в разных местах по-разному.

Даты, периоды, границы

• Прогоните переход через границу года: остатки, стажи, нумерацию периодов. Годовая граница – редкий сценарий; в типовом коде она либо пустая, либо неверная. 
• Запустите расчёты около полуночи, а также в первый и последний день месяца. Разница между временем сервера (UTC) и местным временем офиса – это неявное допущение, о котором часто не задумываются, но оно может приводить к ошибкам. 
•  Проверьте, включаются ли граничные даты в расчёт – в частности, попадает ли последний день периода в вычисления. Формулировки вроде «с… по…» в разных частях системы могут трактоваться по‑разному, и это нередко приводит к расхождениям. 
•  Проверьте расчёты для февраля, високосных годов и месяцев разной длины – особенно в пропорциональных вычислениях. Деление «на 30» – частое упрощение из типовых примеров, но в реальных расчётах оно даёт погрешности. 
•  Проверьте интервалы, пересекающие границу месяца, – например, отпуск с 28‑го по 3‑е или разбитый больничный. Логика разрезания периодов нетривиальна, и автоматизированные решения нередко подменяют её упрощёнными подходами.

Дубли операций, история, откаты

• Нажмите каждую «денежную» кнопку быстро дважды. Идемпотентность – это неявное требование: его обычно не прописывают в задаче «сделай кнопку», поэтому в реализации его часто упускают. 
• Прервите операцию посередине – закройте вкладку или отключите сеть – и проверьте, в каком состоянии остались данные. Частично применённая операция без отката – частая проблема: о транзакционности обычно не просят отдельно, поэтому её нередко не реализуют. 
•  Измените данные задним числом и проследите, какой след это оставит в системе. Журналирование не появляется само по себе – без него баг остаётся в статусе «видели, но воспроизвести не можем». 
• Проверьте, можно ли установить, кто и когда изменил число. В финансовых системах анонимные правки – это не просто неудобство, а полноценный инцидент. 
•  Запросите логи ошибок и убедитесь, что они есть и содержат полезную информацию. Наблюдаемость – ещё одно неявное требование: без логов разбираться в проблемах приходится, опираясь лишь на воспоминания пользователей.

Доступы и данные

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

Объём и код

• Прогоните расчёты на реалистичном объёме данных – например, за год и по сотням сотрудников. Запросы, которые без проблем работают на демо‑данных, на реальных объёмах нередко дают сбои. 
•  Проверьте систему на наличие мёртвого кода – функций и эндпоинтов, до которых нельзя добраться из интерфейса. Такие элементы могут оставаться в системе, быть доступными извне, при этом о них зачастую не знает даже разработчик. 
• Не считайте зелёные автотесты подтверждением корректности – разберитесь, на чём они основаны. Если тест создан на базе реализации, он фактически закрепляет её ошибки как норму. 
•  Требуйте пересборки тестов на основе эталонных кейсов, а не текущего кода. Только внешний эталон способен выявить неверную формулу – сам по себе код не имеет точки отсчёта для самопроверки.
• Считайте продукт частично новым после каждой доработки. Скорость изменений опережает скорость обновления документации – фиксируйте реальное поведение системы, а не изначальные планы. 

Что бы я сделал иначе?

1. Ещё до начала генерации я бы выделил час на встречу с руководителем и зафиксировал эталонные кейсы: вручную просчитал данные по десяти сотрудникам – с отпускными, выплатами и окупаемостью.
2. Завёл бы «карту продукта» – перечень модулей и мест, где прописана каждая формула, – и регулярно обновлял бы её после каждой доработки.
3. Перестроил бы процесс приёмки: фичу считал бы принятой только после прогона эталонных кейсов.
4. Вместе с кодом запрашивал бы список принятых допущений и согласовывал его с руководителем заранее – до возможных инцидентов.
5. Денежные расчёты выделил бы в отдельный модуль. После любой правки проверял бы код, чтобы не появлялись дублирующие реализации.
6. Привлекал бы тестировщиков уже на второй неделе работы: на поздних этапах им приходится восстанавливать требования по уже найденным багам – это заметно дороже.
7. Журнал изменений и логи подключал бы до первого запуска, а не после того, как появится невоспроизводимый баг.

Важно! Дом из гипсокартона – всё равно дом. Но полагаться на его прочность без проверки я не советую. Проверять можно своими силами, но быстрее и надёжнее, когда этим занимаются профессионалы.

Можно ли считать эксперимент удачным?

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

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

Сделало ли это вайбкодинг чуть дольше и сложнее? Безусловно! Исчезла иллюзия, будто достаточно набросать пару строк текста – и сразу появится рабочая функция.

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

Кстати, коллеги, поделитесь в комментариях своим опытом: уже вайбкодили что-то? Сталкивались ли с похожими проблемами и рисками? Какие приёмы помогают вам держать проект под контролем и не терять качество? Расскажите про свои рабочие лайфхаки – будет круто собрать реальные практики и поддержать друг друга! 

В «Лаборатории Качества» мы тестируем в том числе продукты, созданные с помощью ИИ: восстанавливаем требования, строим эталонные кейсы и помогаем разработчикам избавиться от бесконечного багфиксинга. Если у вас уже реализован такой проект – покажите его нам на бесплатной консультации.