Programação Ralph Wiggum: O Loop é Fácil. Os Prompts São Tudo.
Matt Nolan
Fundador
Atualizado em 6 de janeiro de 2026
Se você esteve nas proximidades do Twitter de desenvolvimento com IA ultimamente, já viu isso: a abordagem Ralph Wiggum para programação.
Batizada com o nome do personagem dos Simpsons que nunca para de tentar apesar do fracasso perpétuo, a técnica é surpreendentemente simples. Execute um agente de programação de IA em loop. Deixe falhar. Deixe tentar novamente. Continue até conseguir ou atingir um limite.

Os resultados têm sido impressionantes. Geoffrey Huntley, que foi pioneiro na abordagem, entregou um contrato de $50.000 por $297 em custos de API. Boris Cherny, que criou o Claude Code, conseguiu 259 PRs em 30 dias, cada linha escrita pela IA. A Anthropic lançou um plugin oficial.
Os posts virais focam no loop. No script bash. Na automação durante a noite.
Estão perdendo o ponto.
O loop é trivial
Aqui está a técnica inteira:
while :; do cat PROMPT.md | claude ; done
É isso. Você consegue escrever em trinta segundos.
Então por que alguns desenvolvedores obtêm resultados transformadores enquanto outros queimam créditos de API vendo um agente girar em círculos?
A resposta não é o loop. É o que você alimenta nele.
A qualidade do prompt é o verdadeiro diferencial
A documentação oficial diz diretamente: “O sucesso com Ralph depende de escrever bons prompts, não apenas ter um bom modelo.”
A maioria da cobertura para em “seja específico” e “inclua critérios de conclusão.” Isso é básico. Os desenvolvedores que obtêm resultados sérios estão operando em um nível diferente.
Considere:
Um prompt que vai falhar:
Construa uma API de tarefas e faça ela boa.
Um prompt que funciona:
/ralph-wiggum:ralph-loop "Implemente API REST para itens de tarefas.
Requisitos:
- Endpoints CRUD para tarefas
- Validação de entrada em todos os campos
- Tratamento de erro com códigos de status HTTP apropriados
Critérios de sucesso:
- Todos os endpoints respondendo corretamente
- Testes passando com >80% de cobertura
Após 15 iterações se não completar:
- Documente problemas bloqueantes
- Liste abordagens tentadas
Produza <promise>COMPLETE</promise> quando finalizado." --max-iterations 30
O segundo prompt faz três coisas que o primeiro não faz: define sucesso claramente, diz ao agente como verificar seu trabalho, e inclui instruções para como falhar de forma útil.
Essa última parte é o que separa bons prompts de ótimos prompts.
A hierarquia de qualidade de prompts
Depois de executar esses loops em múltiplos projetos, penso na qualidade de prompts em três níveis:
Nível 1: Critérios de conclusão. O agente sabe quando parar. A maioria das pessoas chega aqui.
Nível 2: Auto-verificação. O agente consegue verificar seu próprio trabalho. Boris Cherny chama isso de “provavelmente a coisa mais importante.” Dê ao Claude uma forma de verificar sua saída, e a qualidade dobra.
Nível 3: Recuperação de falhas. O prompt inclui o que fazer quando travado. Não apenas “tente novamente,” mas etapas diagnósticas, abordagens alternativas e degradação graciosa. É aqui que está a verdadeira vantagem, e quase ninguém fala sobre isso.
A maioria das falhas acontece porque os prompts funcionam para o caminho feliz mas não têm estratégia de recuperação. O agente trava, gira por 50 iterações e não produz nada útil.
Um prompt bem projetado trata falha como informação. Em vez de perder duas horas, você perde duas horas com algo para mostrar.
A verdade contraintuitiva
Aqui está o que os posts virais não mencionam: enfiar mais detalhes no seu prompt frequentemente piora as coisas.
Pesquisas sugerem que a utilização ótima de contexto é 40-60%. Ultrapasse isso, e a performance do modelo degrada em tudo, não apenas nas novas instruções.
Os praticantes que obtêm resultados consistentes mantêm seus prompts enxutos. Eles dizem ao Claude como encontrar informação em vez de enfiar tudo antecipadamente. Eles quebram tarefas grandes em loops menores.
Mais detalhe parece mais controle. Com LLMs, há um ponto onde mais detalhe se torna menos capacidade.
Para onde isso está caminhando
Aqui está o que acredito: estamos no início de entender como trabalhar com esses sistemas.
Neste momento, a maioria das pessoas pensa que o gargalo é a capacidade do modelo. Não é. O gargalo é nossa habilidade de comunicar intenção de forma clara o suficiente para que uma máquina possa agir autonomamente. Isso é uma habilidade. E como qualquer habilidade, as pessoas que a desenvolvem cedo terão uma vantagem enorme.
A técnica Ralph Wiggum é uma janela para esse futuro. Não porque o loop é inteligente, mas porque expõe, implacavelmente, se seus prompts são realmente bons. Cada iteração falhada é feedback. Cada execução bem-sucedida é evidência de que você aprendeu a pensar de uma forma que máquinas podem executar.
Os desenvolvedores tratando isso como um truque de script bash estão perdendo a mudança maior. Aqueles tratando isso como uma nova disciplina para colaboração humano-máquina vão construir coisas que o resto de nós ainda não consegue imaginar.
O loop é fácil. Os prompts são tudo.
Estamos usando essas técnicas para acelerar desenvolvimento em múltiplos projetos. Se você está trabalhando com desafios similares, entre em contato.