Agente de codificação Pi: Construindo ferramentas de IA flexíveis para fluxos de trabalho reais

Introdução

Código nunca é gratuito. Esse é o argumento central que Mario Zechner, criador do Pi, defende ao discutir o estado do desenvolvimento assistido por IA em 2026. Embora agentes possam gerar grandes quantidades de código rapidamente, as consequências desse código eventualmente alcançam você. O Pi existe porque Zechner descobriu que os agentes de codificação existentes não se encaixavam em seus fluxos de trabalho e, em vez de se adaptar, ele construiu uma ferramenta que se adapta a ele.

Esta conversa aborda por que a estabilidade do fluxo de trabalho é mais importante do que a velocidade de lançamento de recursos, como trabalhar com agentes de codificação sem sofrer burnout e por que a indústria pode estar repetindo um erro de 30 anos com o desenvolvimento orientado a especificações.

Por que o Pi existe: Flexibilidade de fluxo de trabalho sobre estabilidade

Quando o Claude Code foi lançado, Zechner ficou satisfeito. Com o tempo, no entanto, o ritmo de lançamento de alta frequência da ferramenta tornou-se um problema. O Claude Code recebe de uma a três atualizações por dia, e com cada lançamento vêm mudanças nas definições de ferramentas, prompts de sistema e comportamento subjacente. Para alguém que constrói modelos de prompt personalizados, comandos slash e descrições de fluxo de trabalho, essas mudanças invisíveis quebram as coisas.

O modelo em si parecia se comportar de maneira diferente dia após dia, mesmo que a versão do modelo permanecesse a mesma. Zechner atribui isso, em parte, a mudanças no “harness” — a infraestrutura e os prompts de sistema que moldam como um modelo responde. Testar os efeitos das mudanças no harness na qualidade da saída é difícil porque não há uma maneira determinística de medi-la. O resultado é que desenvolvedores como Zechner não podem confiar que a ferramenta se comportará de forma consistente, o que anula o propósito de construir fluxos de trabalho personalizados em torno dela.

O Pi nasceu dessa frustração. É um agente de codificação minimalista e extensível que pode se modificar para se ajustar aos seus fluxos de trabalho, em vez de forçá-lo a se adaptar às suas restrições. A arquitetura subjacente abstrai provedores de LLM, inclui uma biblioteca de interface de usuário de terminal e fornece abstrações gerais de loop de agente. Mas a principal diferença é o controle: Zechner dita o design e pode alterá-lo sem esperar pelo ciclo de lançamento de um fornecedor.

Como o Pi realmente funciona: Processamento paralelo e revisão manual

O fluxo de trabalho diário de Zechner com o Pi é metódico e deliberadamente de baixa tecnologia. Ele não executa um exército de agentes em paralelo. Em vez disso, ele usa uma abordagem “homem das cavernas”: enfileira várias sessões, cada uma analisando um problema diferente do rastreador, e então revisa e itera sobre cada uma.

Para correções de bugs e implementações de recursos, o processo começa com uma descrição da issue. Zechner alimenta a issue para um agente com um modelo de prompt personalizado que diz: extraia todas as informações relevantes, ignore a análise na issue e faça sua própria análise com base no que queremos alcançar. Esta etapa de análise leva cerca de cinco minutos por issue. Ele abre uma segunda sessão para a próxima issue, uma terceira para outra, criando um pipeline de pré-processamento paralelo.

Assim que o agente termina de analisar uma issue, Zechner revisa as sugestões, verifica o código ele mesmo e reproduz os problemas manualmente, se necessário. Ele usa o agente como um “rubber duck” — um parceiro de pensamento — até que ele concorde consigo mesmo sobre a abordagem de implementação. Quando ele diz ao agente para implementar, o contexto contém tantas salvaguardas que o agente sabe exatamente quais interfaces modificar, quais módulos tocar e como os testes devem funcionar.

A implementação leva de 10 a 30 minutos. Quando o agente sinaliza a conclusão, Zechner abre um visualizador de diff e anota linhas individuais com feedback. Ele clica em finalizar, o feedback retorna ao agente automaticamente e a iteração continua até que o código esteja bom. Para mecânicas principais, ele revisa cada alteração como faria com um humano. Para outras partes, ele aprova sem inspeção profunda.

Este fluxo de trabalho funciona porque Zechner tem mais de 10 anos de experiência em bases de código. Ele sabe o que funciona e o que não funciona. Para novos desenvolvedores ou aqueles sem essa experiência, a abordagem seria diferente — e mais arriscada.

A realidade do desenvolvimento orientado a especificações

A indústria está repetindo um erro de 30 anos. O desenvolvimento em cascata (waterfall) provou ser ineficaz décadas atrás, mas com agentes de IA, voltamos ao hiper-waterfall: escrever especificações detalhadas e fazer com que agentes as implementem. A única diferença é que agora você nem escreve a especificação — você faz um “vibe prompt” para um agente escrever uma especificação muito detalhada, que então outro agente implementa.

O problema é fundamental. Uma especificação completa é essencialmente o próprio programa. Se você escreve uma especificação em prosa de linguagem natural, você está deixando lacunas. O agente preenche essas lacunas com quaisquer padrões que aprendeu com 20 anos de código na internet — muito do qual é lixo. O resultado é uma base de código que parece um software “vibe-coded”, porque é.

Existe um contra-argumento: o código agora é barato e a iteração é rápida. Anteriormente, uma especificação waterfall poderia levar meses para ser implementada. Agora pode levar um dia. Você pode testar tudo manualmente. Mas Zechner ainda não viu evidências de que isso realmente funcione para software em produção. Ele suspeita que, eventualmente, os desenvolvedores acordarão à noite percebendo que tudo está quebrado.

Dito isso, existem restrições onde o desenvolvimento orientado a agentes faz sentido. A reescrita do Bun de Zig para Rust funcionou porque o projeto tinha uma suíte de testes extensa. O agente pôde verificar seu próprio trabalho até certo ponto. Nesses casos, ferramentas como esta são genuinamente úteis. Mas para a maioria dos softwares, a abordagem é arriscada.

Gerenciando código aberto em escala: O problema dos “Clankers”

Antes dos agentes, um projeto de código aberto bem-sucedido poderia receber um ou dois pull requests por semana. O Pi agora recebe de 50 a 60 pull requests por dia — todos de agentes (Zechner os chama de “clankers”). Cada PR tem uma descrição como um livro inteiro de Harry Potter e inclui de 10 a 1.000 alterações de arquivo.

A posição padrão é declarar cada PR gerado por agente como lixo e fechá-lo automaticamente. Mas Zechner encontrou uma solução: exigir que as pessoas primeiro escrevam uma issue com sua própria voz, não mais longa que uma tela, explicando exatamente o que querem fazer e por quê. Se a issue for boa, ele a aprova e a pessoa pode enviar um PR. Isso prova que eles são humanos, entendem o problema e entendem a solução.

Uma vez aprovados, PRs significativos aparecem. Os PRs dos “clankers” param de aparecer. As issues ainda inundam, mas Zechner as tria manualmente. Ele lê de 30 a 60 issues fechadas por dia, identificando quais são legítimas e quais são lixo. Em sua última triagem, 50 issues chegaram e 2 sobreviveram. Leva cerca de 30 minutos porque a maioria é fácil de identificar como ruído.

Para projetos na escala do OpenClaw, essa abordagem manual não funciona. O consumo de tokens de Peter Steinberger atingiu 1,3 milhão de dólares por mês, em parte porque automatizar a filtragem de issues e PRs nessa escala requer infraestrutura sofisticada. Zechner escreveu algumas ferramentas de visualização para ajudar a agrupar issues semelhantes, mas nem isso foi suficiente. O volume é ordens de magnitude maior.

Inferência local e o futuro de modelos menores

Zechner está otimista quanto à execução de modelos de IA capazes localmente em hardware de consumo. Para seu projeto de robô — um brinquedo com um smartphone como microcontrolador executando um agente de codificação — ele usa Gemma 4 e Qwen 3.6, modelos menores de “mixture-of-experts”. Eles são mais do que adequados para um chatbot com controle de motor e câmera, e são rápidos.

A configuração é acessível. Speech-to-text com Parakeet leva cerca de 10 gigabytes de memória unificada. Text-to-speech com Qwen TTS leva outros 10 gigabytes. Qwen 3.6 leva 4 gigabytes. Total: 14 gigabytes de memória unificada no macOS ou uma configuração NVIDIA equivalente no Windows. Isso é acessível para muitas pessoas, não para o mundo inteiro, mas para uma parcela significativa.

Denise Asaves, da DeepMind, sugeriu que os modelos gigantes atuais não precisam de todos os seus parâmetros e podem ser destilados para modelos muito menores sem perder muita qualidade de saída. A esperança de Zechner é que o futuro envolva destilar modelos grandes em menores que retenham a maioria das capacidades, em vez de treinar modelos especializados para tarefas específicas. Antirez, do Redis, começou a trabalhar em um motor de inferência personalizado para o DeepSeek V4 chamado ds4, executando-o em um laptop de 128 gigabytes. É um modelo realmente capaz que poderia lidar com 60 a 70 por cento das issues que Zechner lida com o Pi.

O custo do código e a disciplina do ofício

Zechner viu pessoas gerarem 500.000 linhas de código via agentes em uma semana. O resultado é sempre o mesmo: desastre. Código nunca é gratuito porque as consequências eventualmente atingem você. Se você acha que qualquer quantidade de código é boa agora, você apenas adiou a punição.

O verdadeiro gargalo no desenvolvimento de software não é a velocidade de digitação ou a geração de código. É pensar, projetar e explorar o espaço da solução. Agentes são genuinamente úteis para essa fase — você pode dizer a vários agentes para explorar abordagens diferentes e ver os resultados mais rapidamente. Mas a saída dessas explorações não é automaticamente reutilizável. Você ainda precisa entendê-la, refatorá-la e mantê-la.

Para Zechner, o maior aumento de produtividade dos agentes vem da natureza assíncrona do trabalho. Ele pode dar uma tarefa a um agente, ir a uma reunião e voltar para ver os resultados. Mas ele não acredita que executar 10 agentes em paralelo aumentará sua produção em 10x. A troca de contexto por si só é exaustiva. Ele fez isso uma ou duas vezes por mês, processando 30 issues em um dia, e seu cérebro fica exausto depois.

O aspecto colaborativo é o que ele mais valoriza. Ter um agente como parceiro de pair programming — fazendo perguntas, propondo opções, explicando código — é como uma bicicleta para a mente. Isso o ajuda a pensar melhor sobre os problemas do que ficar sentado sozinho. Mas isso requer disciplina: não delegar tudo para a máquina, porque toda vez que ele faz isso, ele acaba em um canto chorando porque nada está bom e tudo desmorona.

Refatorando o Pi: Construindo para o futuro

O Pi acumulou bagagem histórica. Partes dele precedem o uso de agentes por Zechner e são sólidas. Outras partes, como a exportação HTML, ele nunca olhou e não se importa, desde que renderize. Algumas peças são “vibe-coded”.

O esforço de refatoração tem vários objetivos. Primeiro, expandir para outros tipos de interfaces de usuário mais facilmente — web, nativa, o que for — sem quebrar extensões existentes. Segundo, habilitar a capacidade remota: executar uma sessão do Pi em uma máquina e conectar-se a ela de outra, com durabilidade e observabilidade adequadas. Terceiro, tornar o SDK do Pi implantável em Cloudflare Workers, Vercel e outros ambientes, não apenas em computadores locais com bash.

Zechner está refatorando na branch principal porque não se importa com a estabilidade no sentido tradicional. Ele está fazendo isso peça por peça, começando pelos pacotes de nível mais baixo que conversam com provedores de LLM. O agente de codificação em si ainda parecerá e funcionará da mesma forma, mas toda a infraestrutura subjacente será limpa e reutilizável. Ele espera terminar essa fase em uma ou duas semanas, depois passar mais algumas semanas no novo mecanismo de extensão, onde as extensões têm componentes do lado do servidor e do lado da interface do usuário.

Por que o Pi roda em modo YOLO por padrão

O Pi não pede permissão antes de executar código. Isso é intencional. Ao dizer às pessoas que o modo YOLO é perigoso e que elas devem pensar sobre isso, Zechner realmente faz com que as pessoas pensem sobre segurança. Ele quer que elas olhem para dentro de si mesmas em busca de consciência de segurança e decidam como proteger o trabalho agentico em seu próprio ambiente.

A resposta geralmente é a conteinerização. Se você não quer que o agente quebre seu computador, conteinerize o agente ou as ferramentas que ele usa — leitura/escrita de arquivos, bash, o que for. Isso resolve o problema. Mas Zechner não pode decidir isso por você. Ele poderia incluir o sandbox da Anthropic ou bubble wrap, mas essas são soluções incompletas. Em um ambiente corporativo com restrições de infraestrutura específicas, um sandbox embutido pode não funcionar de forma alguma.

O que existe no Claude Code é principalmente teatro de segurança. O Claude Code agora pergunta a um LLM se um comando bash é seguro antes de executá-lo no modo automático. Zechner não acha que isso seja bom. Um LLM não pode determinar de forma confiável se um comando é seguro — ele só pode adivinhar com base em padrões.

Conclusão

O Pi representa uma filosofia diferente: construir ferramentas que os desenvolvedores possam possuir e modificar, não ferramentas que possuam os desenvolvedores. O sucesso do Pi não é medido em recursos ou benchmarks, mas em se Zechner consegue manter uma pequena equipe viva e continuar explorando aplicações de trabalho agentico — da codificação à robótica e inferência local.

A lição mais ampla é que fluxos de trabalho importam mais do que o hype. Estabilidade, previsibilidade e a capacidade de personalizar suas ferramentas valem mais do que o recurso mais recente. E código nunca é gratuito — as consequências de suas ações eventualmente alcançarão você.