A Vibe Coder Built a Yandex Lavka Bot in 4 Days with 498 Tests and No Ability to Pay

Every week the same exchange plays out in the family: "What are we eating?" "What do we have?" "Half a pack of rice and a chicken that's about to expire." The author of a Habr article decided to put an end to this routine with a bot. He is not a professional developer, writes Python for himself, and AI agents write the code for him. The result, in 4 days and 143 commits: a Telegram bot with a Mini App that knows what's in the fridge, plans menus and assembles a cart in Yandex Lavka.

The bot cannot pay: there are simply no checkout or payment tools in the code. This is the project's first rule. The model may get a product, quantity or price wrong, so let it make those mistakes in a cart that a human reviews before paying.

The model proposes, the code verifies

This principle is worth taking into any LLM project. The model invents dishes and picks products from the candidates found. Everything that can be calculated is calculated by the code: exactly N days, calories within ±15% of the target, a total no higher than the budget plus 15%, the number of packages, stock availability. Any violation goes back to the model for correction with a specific complaint.

Take the onion example. The menu called for 950 g of onions and 900 g of beef, while the code rounded packages strictly up, so three 400 g bags ended up in the cart. The fix came in two places: the prompt gained a norm of 30–40 g per person, and the code gained a tolerance. If a full package is short by up to 15% of the weight, the extra one is not added. Another case: the fridge held "Cottage cheese", the menu said "5% cottage cheese", the bot didn't recognize it and bought more. Word-based matching instead of exact matching solved it.

The process matters too: a spec built from one-at-a-time questions, a plan of small tasks, TDD, and review by another agent running a different model. The first review found 8 serious problems. For example, saving a menu first overwrote the file and then could crash during rendering, corrupting the data. The agents' shared memory is a STATE.md file with a "Traps" section.

What the 498 tests didn't catch

All the tests ran on mocks, and a mock is the agent's fantasy of what the API looks like. The first live run uncovered nine defects.

The main one: the address determines the dark store. The cart looked perfect, but in the app half the items were marked "Sold out", even though the API answered "in stock". The agent had taken the first address from favorites, while a different one was selected in the app. The cure: the address and the place identifier change together, availability is checked against the product card, after adding items there is a 2-second pause and the cart is re-read, and the price of a control item (rice, buckwheat) must match the app to the ruble.

The remaining pitfalls are familiar too. Chromium prepends a 32-byte domain hash to the cookie value, and httpx crashes unless it is stripped off. The agent ran yesterday's server from site-packages instead of the new version, so there were 14 tools instead of 15. The model "thought" by default: about 95% of tokens went to reasoning, and the menu didn't fit into 120 seconds, so reasoning was disabled for "return JSON" tasks. One menu served the same lunch five days in a row while formally staying within budget, and now the code checks for repeats and the share of a single protein.

Limitations and takeaways

The bot works through Lavka's unofficial web API with session cookies, so it may break at any moment, and Yandex may not like it. The author is not publishing the code: cookies unlock the entire account, and distributing such a thing safely is hard. He uses a separate account with no cards or balance, and only names, package sizes and prices are sent to the model.

Practical takeaways for developers and product managers. First: move any calculations out of the LLM and into code, and send the model specific complaints. Second: prohibitions like "don't spend money" are more reliable when enforced by the absence of the needed tool rather than in the prompt. Third: run a live test as early as possible, because mocks hide the most expensive bugs. Fourth: give your agents a shared traps file; it saves more time than switching models.