Un vibecoder montó en 4 días un bot para Yandex Lavka con 498 pruebas y sin permiso para pagar

Cada semana, en la familia, se repite lo mismo: «¿Qué comemos?» — «¿Qué hay?» — «Medio paquete de arroz y un pollo que está a punto de morir». El autor de un artículo en Habr decidió acabar con este guion mediante un bot. No es desarrollador profesional, programa en Python para sí mismo y el código se lo escriben agentes de IA. El resultado, en 4 días y 143 commits: un bot de Telegram con Mini App que sabe qué hay en la nevera, elabora menús y arma el carrito en Yandex Lavka.

El bot no sabe pagar: en el código simplemente no hay herramientas de tramitación ni de pago. Es la primera regla del proyecto. El modelo puede equivocarse con el producto, la cantidad o el precio, así que mejor que se equivoque en un carrito que una persona revisará antes de pagar.

El modelo propone, el código verifica

Este principio merece llevarse a cualquier proyecto con LLM. El modelo inventa platos y elige productos entre los candidatos encontrados. Todo lo que se puede calcular lo calcula el código: exactamente N días, calorías dentro de ±15 % del objetivo, importe no superior al presupuesto más un 15 %, número de envases, disponibilidad en almacén. Cualquier incumplimiento se devuelve al modelo para que lo corrija, con una queja concreta.

Un ejemplo con la cebolla. El menú requería 950 g de cebolla y 900 g de ternera, y el código redondeaba los envases siempre hacia arriba, de modo que al carrito iban a parar tres bolsas de 400 g. La solución fue doble: en el prompt apareció una norma de 30–40 g por persona y en el código, una tolerancia. Si para completar un envase entero faltan hasta un 15 % del peso, no se añade el extra. Otro caso: en la nevera había «Requesón», en el menú figuraba «requesón 5 %», el bot no lo reconoció y compró más. Ayudó comparar por palabras en lugar de exigir coincidencia exacta.

El proceso también importa: una especificación con preguntas de una en una, un plan de tareas pequeñas, TDD y revisión por otro agente con otro modelo. La primera revisión encontró 8 problemas graves. Por ejemplo, al guardar el menú primero se sobrescribía el archivo y luego podía fallar el renderizado, corrompiendo los datos. La memoria compartida entre agentes es un archivo STATE.md con una sección de «Trampas».

Lo que no detectaron las 498 pruebas

Todas las pruebas se ejecutaban con mocks, y un mock es la fantasía del agente sobre cómo es la API. La primera ejecución real destapó nueve defectos.

El principal: la dirección determina el dark store. El carrito parecía perfecto, pero en la aplicación la mitad de los artículos aparecían como «Agotado», aunque la API respondía «disponible». El agente tomó la primera dirección de favoritos, mientras que en la aplicación estaba seleccionada otra. La solución: la dirección y el identificador del local cambian juntos, la disponibilidad se comprueba en la ficha del producto, tras añadir se hace una pausa de 2 segundos y se vuelve a leer el carrito, y el precio de un producto de control (arroz, trigo sarraceno) debe coincidir con la aplicación hasta el rublo.

El resto de los tropiezos también resultan familiares. Chromium antepone al valor de la cookie 32 bytes del hash del dominio, y sin recortarlos httpx falla. El agente lanzó el servidor de ayer desde site-packages en lugar de la versión nueva, y en vez de 15 herramientas había 14. El modelo «pensaba» por defecto: cerca del 95 % de los tokens se iba en razonamientos y el menú no cabía en 120 segundos, por lo que para las tareas de «devuelve JSON» se desactivó el razonamiento. Uno de los menús sirvió el mismo almuerzo cinco días seguidos, cumpliendo formalmente el presupuesto, y ahora el código comprueba las repeticiones y la proporción de una misma proteína.

Limitaciones y conclusión

El bot funciona a través de la API web no oficial de Lavka con cookies de sesión, por lo que puede romperse en cualquier momento, y a Yandex puede no gustarle. El autor no publica el código: las cookies abren toda la cuenta y distribuir algo así de forma segura es difícil. Él usa una cuenta aparte, sin tarjetas ni saldo, y al modelo solo llegan nombres, formatos de envase y precios.

Conclusiones prácticas para desarrolladores y product managers. Primera: saque del LLM cualquier cálculo, llévelo al código y devuelva al modelo quejas concretas. Segunda: prohibiciones como «no gastar dinero» son más fiables si se garantizan por la ausencia de la herramienta necesaria y no en el prompt. Tercera: haga una ejecución real cuanto antes, porque los mocks esconden los errores más caros. Cuarta: cree para los agentes un archivo común de trampas; ahorra más tiempo que cambiar de modelo.