Вайбкодер за 4 дня собрал бота для Яндекс Лавки с 498 тестами и без права платить

Каждую неделю в семье одно и то же: «Что едим?» — «А что есть?» — «Полпачки риса и курица, которая скоро умрёт». Автор материала на Habr решил закрыть этот сценарий ботом. Он не профессиональный разработчик, пишет на Python для себя, а код за него пишут ИИ-агенты. Результат за 4 дня и 143 коммита: Telegram-бот с Mini App, который знает содержимое холодильника, составляет меню и собирает корзину в Яндекс Лавке.

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

Модель предлагает, код проверяет

Этот принцип стоит забрать в любой проект с LLM. Модель придумывает блюда и выбирает товар из найденных кандидатов. Всё, что можно посчитать, считает код: ровно N дней, калории в пределах ±15% от цели, сумма не больше бюджета плюс 15%, число упаковок, наличие на складе. Нарушение возвращается модели на правку с конкретной претензией.

Пример с луком. Меню требовало 950 г лука и 900 г говядины, а код округлял упаковки строго вверх, и в корзину попадали три пачки по 400 г. Фикс в двух местах: в промпте появилась норма 30–40 г на человека, а в коде допуск. Если до целой упаковки не хватает до 15% веса, лишнюю не берут. Другой случай: в холодильнике лежал «Творог», в меню стоял «творог 5%», бот не узнал его и купил ещё. Помогло сопоставление по словам вместо точного совпадения.

Процесс тоже важен: спека с вопросами по одному, план из мелких задач, TDD и ревью другим агентом на другой модели. Первое ревью нашло 8 серьёзных проблем. Например, сохранение меню сначала перезаписывало файл, а потом могло упасть на отрисовке и испортить данные. Памятью между агентами служит файл STATE.md с разделом «Ловушки».

Что не поймали 498 тестов

Все тесты работали на моках, а мок — это фантазия агента об API. Первый живой прогон выявил девять дефектов.

Главный: адрес определяет даркстор. Корзина выглядела идеально, но в приложении половина позиций была «Раскупили», хотя API отвечал «в наличии». Агент взял первый адрес из избранного, а в приложении был выбран другой. Лечение: адрес и идентификатор места меняются вместе, наличие проверяется по карточке товара, после добавления делается пауза 2 секунды и корзина перечитывается, а цена контрольного товара (рис, гречка) должна совпасть с приложением до рубля.

Остальные грабли тоже знакомы. Chromium приписывает к значению cookie 32 байта хеша домена, и без их отрезания httpx падает. Агент запускал вчерашний сервер из site-packages вместо новой версии, и вместо 15 инструментов было 14. Модель по умолчанию «думала»: около 95% токенов уходило на рассуждения, и меню не укладывалось в 120 секунд, поэтому для задач «верни JSON» рассуждения отключили. Одно из меню выдало один и тот же обед пять дней подряд, формально уложившись в бюджет, и теперь код проверяет повторы и долю одного белка.

Ограничения и вывод

Бот работает через неофициальный веб-API Лавки с сессионными cookies, поэтому может сломаться в любой момент, а Яндексу это может не понравиться. Автор не публикует код: cookies открывают весь аккаунт, и безопасно раздавать такое сложно. Сам он использует отдельный аккаунт без карт с балансом, а в модель уходят только названия, фасовки и цены.

Практический вывод для разработчиков и продактов. Первое: выносите любые расчёты из LLM в код и возвращайте модели конкретные претензии. Второе: запреты вроде «не тратить деньги» надёжнее держать не в промпте, а в отсутствии нужного инструмента. Третье: запускайте живой прогон как можно раньше, потому что моки скрывают самые дорогие баги. Четвёртое: заведите агентам общий файл ловушек, он экономит больше времени, чем смена модели.