Rate limit na raspagem no vibe coding: troque de método

Quando a raspagem trava num rate limit, o que destrava a sessão é trocar de método. Martin Blume tinha ligado o assistente de código à base de dados de startups que ele usa na pesquisa e pedido uma varredura para montar uma tabela de produtos. A coleta andou 10 páginas e parou.

Já deu o rate limit, ó. Ele não tá deixando mais puxar porque deu algum algum bo ali.

Ele não abriu log, não reescreveu o prompt e não mandou tentar de novo. Leu a causa, decidiu voltar para o método manual, anotou uma ferramenta melhor para outro dia e foi tocar uma tarefa que precisava sair naquele dia de qualquer jeito. Essa sequência dá para copiar inteira na próxima vez que uma coleta sua morrer no meio.

Rate limit é o serviço dizendo que você passou da conta

O primeiro acerto foi na leitura. Antes de pensar em solução, ele já tinha posto a causa na própria conta:

A gente puxou muitos dados

Mais adiante, com o assistente ainda sem trazer resultado, ele repetiu a explicação: "Já deve ter meio que dado uma bugada porque a gente fez muita pesquisa ali". A palavra que ele usa é "bugada", mas o culpado que ele nomeia é o volume da pesquisa dele, não um defeito do assistente e não um defeito da base.

Essa leitura decide a hora seguinte. Quem trata o bloqueio como bug começa a caçar defeito: reescreve o prompt, refaz a conexão, e cada tentativa gasta requisição justamente onde o serviço acabou de dizer que não quer mais. O bloqueio veio de uma regra do serviço, e regra de serviço não se conserta do seu lado do teclado. Dá para perder a tarde inteira tentando fazer funcionar de novo uma coisa que não está quebrada.

Ele também parou para contar o que já tinha chegado, lendo a tela: "Ó, página 1 2 3 4 5 6 7 8 9 10". Saber quanto entrou antes do corte é o que permite decidir se o que falta ainda vale uma segunda rodada em outro momento.

O objetivo era a lista, e o vibe coding tinha outro caminho até ela

A varredura automática era o meio. O que ele queria em mãos era a tabela de produtos para triar depois. Assim que ficou claro que o caminho automático estava fechado, ele repetiu a mesma avaliação com outras palavras, "Eu acho que ele não vai deixar mais" e "Eu acho que ele não vai mais deixar a gente buscar", e não veio nenhuma tentativa nova.

A instrução que ele dá em seguida é curta:

Pode voltar pro método manual e retoma essa varredura

Ele já tinha feito uma varredura parecida em outra live, então sabia o que estava aceitando. O método manual entrega a mesma lista mais devagar, e devagar continua entregando.

Essa troca some da cabeça de quem faz vibe coding, porque o assistente destrava tanta coisa que a gente esquece que a tarefa tinha um jeito antigo de ser feita. Quando o caminho automático fecha, a pergunta que resolve é qual o outro caminho até o mesmo entregável, e quanto ele custa em tempo. Reabrir o que travou raramente está entre as respostas, e não depende de você.

Anotar a ferramenta melhor em vez de instalar no meio do bloqueio

Enquanto o assistente ainda tentava, ele cogitou em voz alta a solução mais adequada:

Existe uma maneira mais fácil de varrer, fazer uma varredura dentro do site deles

Existe mesmo: varrer site com frequência é trabalho de ferramenta de raspagem dedicada, feita para isso, e não de um assistente de código puxando página por página por uma conexão que ninguém desenhou para lote grande. A live não prova que essa ferramenta resolveria o caso dele, porque ele não chegou a testar. E não testou de propósito, deixou anotada para outra hora e seguiu.

Instalar uma ferramenta nova no meio de uma tarefa travada é começar uma segunda tarefa. Você instala, resolve credencial, entende o formato que ela devolve, reescreve o pedido, e no fim da hora tem duas coisas inacabadas em vez de uma. A melhoria vira uma linha numa lista, e a tarefa que já estava aberta continua sendo a tarefa da vez. Quando a decisão envolve custo de mudar de ferramenta, a mesma avaliação de referência que funciona em precificar usando hábito aplica-se aqui.

O bloqueio parou a raspagem, não o dia dele

Com a varredura travada, ele avisou para onde ia:

Eu vou continuar fazendo a minha agenda aqui enquanto isso

A agenda é uma tarefa que ele escreve à mão, que "tenho que fazer todos os dias", e que naquele dia ainda não tinha saído. Foi ali, com a raspagem bloqueada, que ele sentou para anotar as tarefas.

O detalhe que faz isso funcionar é que a tarefa substituta não dependia do serviço que tinha travado. Adiantar outra parte da mesma pesquisa cairia no mesmo bloqueio. Ter na lista pelo menos uma coisa que não toca a dependência quebrada é o que separa um intervalo bloqueado de uma sessão perdida.

O que fazer na próxima vez que a raspagem travar

Leia a mensagem e conte o que já chegou antes do corte, do jeito que ele contou as 10 páginas na tela. Depois pergunte qual era o entregável de verdade e se existe um caminho mais lento até ele, porque quase sempre existe e quase sempre é a mão. A ferramenta certa para raspar você escreve numa lista de melhorias, com uma linha, e volta para ela quando o entregável já estiver com você. Quando você está escolhendo qual ideia construir, a mesma avaliação de trade-offs aparece na matriz de dimensões. E quando você está na etapa de validar o app que vai construir, avaliar as reclamações negativas é tão importante quanto validar a ferramenta. E o intervalo em que nada anda rende mais se você já tiver, na lista do dia, alguma coisa que não depende do serviço que travou. Vale ver como isso terminou em resposta ruim da IA no vibe coding. Foi o mesmo caminho de vibe coding para não ficar preso na pesquisa.

Dá para assistir à live e ver o quanto essa decisão é rápida quando o diagnóstico está certo. Aceitar o limite de um serviço de terceiro e procurar a via adequada é uma das horas em que o vibe coding mais se parece com trabalho comum: a ferramenta parou, e o trabalho segue por outro caminho.