Uma afirmação viral está circulando nos círculos de desenvolvedores: “Se você não consegue reconstruir um Cursor em 300 linhas de código, sua próxima entrevista será muito difícil.” Quem disse foi Geoffrey Huntley — criador do Ralph Loop e contribuidor fundador da filosofia central de design do Claude Code. Em um podcast, ele acrescentou: “Na PyCon Lituânia, há algumas semanas, um adolescente de 13 anos demonstrou ao vivo um agente de programação que havia construído e deixou todos os engenheiros seniores da sala de queixo caído.” Isso não é exagero. O Ralph Loop — originalmente ridicularizado como um esquema de gerenciamento de contexto “demente” — foi adotado pelo Claude Code, Cursor, Copilot e outras ferramentas de programação com IA do mercado. Sua ideia central é desconcertantemente simples: dar ao agente um objetivo, usar o mínimo de contexto e deixá-lo convergir autorregressivamente para o resultado. A solução ótima para problemas complexos às vezes é a mais simples. Esta não é uma história sobre modelos de IA ficando mais fortes. É uma história sobre “como impedir a IA de esquecer o que está fazendo” — e suas lições vão muito além da programação.
O Pior Inimigo do Agente de Programação Não é a Capacidade do Modelo — é a Amnésia
Se você já usou qualquer ferramenta de programação com IA, conhece a cena: pede para refatorar um módulo, ela gera um código decente. Você diz “continue” — ela esquece onde parou. Diz “tente de novo” — ela gera algo completamente sem relação. O modelo não ficou mais burro. A janela de contexto transbordou.
Geoffrey nomeou a dor no podcast: “A janela de contexto é apenas memória. Quanto mais você usa, pior fica o desempenho.” É um problema gravemente subestimado. A maioria dos produtos de IA despeja energia em tornar os modelos mais inteligentes e os recursos mais ricos, enquanto quase ninguém enfrenta seriamente: quando um agente precisa trabalhar por horas ou dias, como impedir que ele pare após uma rodada?
A resposta do Ralph Loop: não tente lembrar de tudo. Esqueça deliberadamente. O mecanismo é de uma simplicidade desarmante: dê ao agente um único objetivo, fixe todo o contexto relevante ao redor dessa tarefa formando um array de contexto focado, e deixe o agente fazer loop dentro desse limite controlado. Após cada rodada, limpe o contexto — mantendo apenas o mínimo de informação necessário para o objetivo — e entre na próxima rodada. Enquanto outros constroem computação paralela complexa entre agentes, Geoffrey roda pequenos loops sequenciais. Parecem “dementes”, mas funcionam surpreendentemente bem. Após melhorias, o Claude Code adicionou contagem máxima de iterações, safe words e stop hooks às sessões individuais, permitindo que os agentes continuem rodando até que as tarefas sejam concluídas.
Esse mecanismo modesto empurrou os agentes de programação da “geração única” para a “operação de longa duração”. A mudança de ferramenta de conversação para executor autônomo se esconde dentro daquelas poucas centenas de linhas de lógica de loop.
Divergência em K: a IA Está Dividindo os Desenvolvedores em Dois Caminhos
Na AI:Engineer Miami, Geoffrey propôs uma estrutura afiada — a divergência em K. Um caminho vai para cima: empresas model-first. Menos pessoas, construindo no espaço latente, custos operacionais extremamente baixos, receita e margens exponenciais. Elas não competem com os players tradicionais em escala — competem em uma dimensão diferente. O outro caminho vai para baixo: empresas tradicionais que ainda resistem à IA — cobrando por número de funcionários, movidas por tickets, controlando qualidade por meio de code review rígido. Essas regras estão falhando.
O verdadeiro poder dessa moldura não é descrever o presente, mas revelar uma mudança estrutural irreversível: a mesma tarefa agora absolutamente exige menos pessoas. O impacto no software é abrangente. Se sua empresa opera um modelo SaaS cobrando por cabeça, seus clientes também precisarão de menos pessoas, sua base de receita diminui, e a sua diminui junto. Geoffrey chama isso de “legacy SaaS”. Se o seu trabalho é “estimar tickets do Jira e escrever código”, Geoffrey te chama de “macaco de tickets do Jira”, acrescentando: “Se você não manteve a curiosidade nos últimos dois anos, você é substituível.” Não é crueldade — é um sinal real de uma indústria passando por mutação estrutural.
Mas a divergência em K também significa que o caminho para cima é real. A chave não é se você consegue usar ferramentas de IA — é se você entende por que as ferramentas funcionam.
O Novo Fosso: de Escrever Código para Verificar Código
O ponto que Geoffrey mais repete merece a atenção de todo desenvolvedor: a geração de código se tornou gratuita. Se o que foi gerado está correto — esse problema de verificação é o verdadeiro gargalo. Ele oferece uma estrutura clara de prioridades. Camada um: verificação de software. Aprenda TLA+, Lean, Coq — provadores de teoremas. O problema da geração de código está resolvido; o da verificação, não. Camada dois: testes de propriedade e testes determinísticos de sistema. Uma dimensão acima dos testes unitários: testes unitários verificam o que você sabe que precisa checar; testes de propriedade verificam casos extremos que você jamais imaginou. Camada três: linguagens com sistemas de tipos mais fortes. Rust, Haskell — dados inválidos simplesmente não podem ser modelados. Falha na compilação, recusa a alucinação, o ciclo de geração não se completa, o commit nunca acontece, o code review nunca o vê. Python e Ruby: gerar, rodar e torcer — o custo de verificação é alto demais.
Aqui está um insight contraintuitivo: a escolha da linguagem de programação está se tornando uma decisão de infraestrutura para a era da IA. Os laboratórios de fronteira (OpenAI, Anthropic, Google DeepMind) que desenvolvem software autônomo usam “dog food” em apenas quatro linguagens — Python, Rust, Go, TypeScript. Ruby, Java, .NET, Kotlin não estão na lista; são apenas um número de benchmark. Se você usa essas linguagens, a qualidade do código gerado por IA é naturalmente um nível inferior, porque o modelo acumulou a maior parte dos dados de treinamento de uso próprio em ambientes de linguagens “abençoadas”. Nas palavras de Geoffrey: “É como marcenaria — siga a veia da madeira, não contra ela.”
O Fim do Code Review? Não — Sua Evolução
Geoffrey detonou uma posição mais controversa: “Eu não acredito mais em code review.” Não é “nunca revisar código” — é um desafio à forma atual da revisão: “um carimbo”, “correr atrás de colegas por checkmarks”, “não é mentoria para engenheiros juniores, é tortura psicológica”. Sua alternativa é a estratificação baseada em risco: mudanças em textos de marketing vão direto para produção; mudanças que tocam certificação ou índices de banco de dados disparam revisão. E, à medida que os modelos melhoram, a própria IA pode rodar múltiplos caminhos de código checando problemas de segurança e lógica, reduzindo ainda mais a superfície que exige revisão humana. Isso não é radical — é uma lógica negligenciada: o objetivo da engenharia não é manter o processo de revisão, mas minimizar a dependência de revisão humana por meio de melhor design, sistemas de tipos mais fortes e verificação mais completa. Isso ecoa a filosofia central do Ralph Loop — não tente resolver tudo em uma rodada. Use pequenos loops de múltiplas rodadas com resultados intermediários verificáveis para convergir à correção — o mesmo espírito de entrega incremental e integração contínua.
Uma Estratégia em Três Níveis para o Engenheiro da Era da IA
Este artigo não está vendendo ansiedade — Geoffrey Huntley é o melhor contraponto. Ele não está dizendo “vocês todos ficarão desempregados”, mas “aqui está o que vocês podem fazer para se manter acima da curva K”. Três níveis de ação, do mais urgente ao mais importante: Se você escreve código: na próxima semana, dedicate quatro horas para construir um agente de programação você mesmo. Nada complexo — 300 linhas: um loop while mais gerenciamento de contexto. Ser capaz de explicar por que funciona vale mais do que usá-lo. Se você não conseguir, o título de “engenheiro sênior” precisa de reavaliação. Se você lidera um time: pare de auditar “o código gerado pela IA é bom” e comece a construir “o mecanismo de verificação é forte o suficiente”. Introduza testes de propriedade, exija rigor nos sistemas de tipos, estabeleça estratificação de revisão baseada em risco. Mude a energia de “ler cada linha” para “desenhar a verificabilidade do código”. Se você é um executivo: pare de perguntar “quantas pessoas a IA pode substituir” e comece a perguntar “como faço cada membro do time produzir dois níveis acima do seu output atual usando IA”. A vantagem da divergência em K não é a redução de custos — é a alavancagem de capacidade. Fazer cinco engenheiros produzirem qualidade de cinquenta pessoas é a verdadeira vantagem competitiva das empresas model-first.
Referências: Podcast Geoffrey Huntley & Hendrik Krack — youtube.com/watch?v=fbqAh46eMkc · Palestra de Geoffrey Huntley na AI:Engineer Miami — youtube.com/watch?v=7Pkwv353DeI · Blog original do Ralph Loop — ghuntley.com/loop/ · Compilação da InfoQ — 36kr.com/p/3885317858865154
