Vibecoder montou em 4 dias um bot para o Yandex Lavka com 498 testes e sem permissão para pagar

Toda semana, na família, a mesma cena: «O que vamos comer?» — «O que tem?» — «Meio pacote de arroz e um frango que está prestes a morrer». O autor de um artigo no Habr decidiu encerrar esse roteiro com um bot. Ele não é desenvolvedor profissional, escreve em Python para si mesmo e o código é escrito por agentes de IA. O resultado, em 4 dias e 143 commits: um bot de Telegram com Mini App que sabe o que há na geladeira, monta cardápios e preenche o carrinho no Yandex Lavka.

O bot não sabe pagar: simplesmente não há no código ferramentas de finalização e pagamento. Essa é a primeira regra do projeto. O modelo pode errar o produto, a quantidade ou o preço, então que erre num carrinho que uma pessoa vai revisar antes de pagar.

O modelo propõe, o código verifica

Esse princípio vale levar para qualquer projeto com LLM. O modelo inventa os pratos e escolhe o produto entre os candidatos encontrados. Tudo o que pode ser calculado é calculado pelo código: exatamente N dias, calorias dentro de ±15% da meta, valor total não superior ao orçamento mais 15%, número de embalagens, disponibilidade em estoque. Qualquer violação volta ao modelo para correção, com uma reclamação específica.

Um exemplo com a cebola. O cardápio pedia 950 g de cebola e 900 g de carne bovina, e o código arredondava as embalagens sempre para cima, de modo que três pacotes de 400 g iam parar no carrinho. A correção foi feita em dois pontos: no prompt entrou a norma de 30–40 g por pessoa, e no código, uma tolerância. Se faltar até 15% do peso para completar uma embalagem inteira, a extra não é incluída. Outro caso: na geladeira havia «Requeijão», no cardápio constava «requeijão 5%», o bot não o reconheceu e comprou mais. O que ajudou foi comparar por palavras em vez de exigir correspondência exata.

O processo também importa: especificação com perguntas feitas uma de cada vez, plano de tarefas pequenas, TDD e revisão por outro agente, em outro modelo. A primeira revisão encontrou 8 problemas graves. Por exemplo, ao salvar o cardápio o arquivo era primeiro sobrescrito e depois a renderização podia falhar, corrompendo os dados. A memória compartilhada entre os agentes é um arquivo STATE.md com uma seção de «Armadilhas».

O que os 498 testes não pegaram

Todos os testes rodavam com mocks, e um mock é a fantasia do agente sobre a API. A primeira execução real revelou nove defeitos.

O principal: o endereço define o dark store. O carrinho parecia perfeito, mas no aplicativo metade dos itens aparecia como «Esgotado», embora a API respondesse «em estoque». O agente pegou o primeiro endereço dos favoritos, enquanto no aplicativo estava selecionado outro. A solução: o endereço e o identificador do local mudam juntos, a disponibilidade é verificada na ficha do produto, após a adição faz-se uma pausa de 2 segundos e o carrinho é relido, e o preço de um item de controle (arroz, trigo-sarraceno) deve coincidir com o do aplicativo até o rublo.

Os demais tropeços também são conhecidos. O Chromium acrescenta ao valor do cookie 32 bytes do hash do domínio, e sem removê-los o httpx falha. O agente iniciou o servidor de ontem a partir do site-packages em vez da versão nova, e em vez de 15 ferramentas havia 14. O modelo «pensava» por padrão: cerca de 95% dos tokens iam para o raciocínio e o cardápio não cabia em 120 segundos, por isso o raciocínio foi desativado nas tarefas de «retorne JSON». Um dos cardápios entregou o mesmo almoço cinco dias seguidos, cumprindo formalmente o orçamento, e agora o código verifica as repetições e a participação de uma mesma proteína.

Limitações e conclusão

O bot funciona por meio da API web não oficial do Lavka, com cookies de sessão, portanto pode quebrar a qualquer momento, e a Yandex pode não gostar. O autor não publica o código: os cookies abrem toda a conta e é difícil distribuir algo assim com segurança. Ele próprio usa uma conta separada, sem cartões nem saldo, e ao modelo chegam apenas nomes, tamanhos de embalagem e preços.

Conclusões práticas para desenvolvedores e product managers. Primeira: tire do LLM qualquer cálculo, leve-o para o código e devolva ao modelo reclamações específicas. Segunda: proibições como «não gastar dinheiro» são mais confiáveis quando garantidas pela ausência da ferramenta necessária, e não no prompt. Terceira: faça uma execução real o quanto antes, porque os mocks escondem os bugs mais caros. Quarta: crie para os agentes um arquivo comum de armadilhas; ele economiza mais tempo do que trocar de modelo.