Estou programando com IA há um ano. Não apenas dando comandos — construindo software de verdade. Dois projetos open-source: GStack, que melhora agentes de codificação de IA, e GBrain, que transforma tudo que você lê e escreve em uma base de conhecimento pesquisável que sua IA pode usar. Juntos, cerca de 970.000 linhas de código e 665 arquivos de teste. Quase tudo escrito pelo Claude Code e Codex sob minha orientação (15 sessões simultâneas do Conductor na maioria das vezes).
Na semana passada, fiz merge de quatorze pull requests em 72 horas. Quase 29.000 linhas de código novo. Cada versão era melhor testada que a anterior.
Isso deveria ser impossível. Velocidade e qualidade deveriam ser opostas. Entregue rápido, quebre coisas. Vá devagar, entregue certo. Escolha um.
Você não precisa mais escolher. O segredo é 90% de cobertura de testes — e os agentes de IA tornaram isso gratuito. Por cinquenta anos, esse nível de verificação custava força de vontade humana demais para ser sustentado. Agora o agente escreve os testes junto com o código. O resultado é o que chamo de catraca de complexidade: um sistema que só pode melhorar, nunca piorar.
(Este é o sétimo de uma série sobre construção com IA: 1 2 3 4 5 6
O software costumava ser frágil
Por cinquenta anos, toda a disciplina de engenharia de software foi organizada em torno de uma ideia: prevenir erros, porque erros são catastróficos.
Você tinha que acertar o código na primeira vez. Perdesse um caso de borda e você crashava em produção. Enviasse uma migração de banco de dados ruim e você perdia dados de clientes. Escrevesse uma função que faz algo sutil, e quando a única pessoa que a entendia saía, ninguém sabia por que funcionava. O sistema inteiro dependia de humanos serem cuidadosos, e humanos não são cuidadosos. Então construímos processos elaborados — revisões de código, ambientes de staging, equipes de QA, trens de release — todos projetados para pegar erros antes que chegassem aos usuários.
Meio que funcionava. Mas era lento. E significava que a complexidade de qualquer sistema de software tinha um teto duro: o número de coisas que uma equipe conseguia manter na cabeça simultaneamente.
Agora o software é maleável
Não quero dizer desleixado. Quero dizer resiliente de uma forma que não era possível antes.
Quando digo "os modelos estão aqui", quero dizer que agentes de codificação de IA — Claude, GPT, Codex e o ecossistema crescendo ao redor deles — agora conseguem ler código, entender contexto, diagnosticar erros e escrever correções. Não perfeitamente. Mas bem o suficiente para que o modelo de erro para software tenha mudado.
A migração quebrou? O agente lê a mensagem de erro, entende o histórico do esquema do banco de dados em 45 versões, escreve a correção, escreve o teste. A sincronização de arquivos trava em um milhão de symlinks? O agente diagnostica o timeout do parser, limita em 30 segundos, envia a correção com testes. Um pipeline de extração tem um bug de atribuição? Uma avaliação entre modelos o pega, o prompt é iterado, a aplicação é adicionada na camada do banco de dados.
Para a maioria dos erros de nível de código — bugs de lógica, falhas de parsing, casos de borda quebrados — os agentes agora podem diagnosticar e corrigir na próxima rodada. Isso é genuinamente novo. Os erros que permanecem catastróficos são aqueles que destroem estado: migrações ruins em dados de produção, brechas de segurança exploradas antes da detecção, vazamentos de privacidade que não podem ser desfeitos. A catraca ajuda aqui também (bons testes pegam a maioria desses antes da produção), mas a verdadeira mudança é que a grande maioria dos erros em uma base de código é do tipo corrigível.
Esta é uma mudança de fase em como o software é construído. Mas só funciona se você tiver a catraca.
A Catraca de Complexidade do Agente
Uma catraca é um mecanismo que permite movimento em apenas uma direção. Uma chave de catraca gira um parafuso para frente e impede que ele volte. Essa é a metáfora.
Em software codificado por agente, cada sessão de codificação com um agente de IA adiciona três coisas à base de código:
- Testes que codificam o que "correto" significa — verificações automatizadas que rodam toda vez que alguém muda o código e falham alto se a mudança quebrar algo
- Documentação que registra por que as decisões foram tomadas — não apenas o que o código faz, mas o raciocínio e as compensações por trás dele
- Resultados de avaliação que estabelecem limites de qualidade — avaliações estruturadas da qualidade da saída com pontuações, para que você saiba se a próxima versão é melhor ou pior
Na próxima vez que um agente trabalhar na base de código, ele carrega todos os três em sua janela de contexto (o texto que a IA pode ver e raciocinar). Ele não pode regredir abaixo do conjunto de testes — os testes falhariam. Ele não pode ignorar a documentação — está ali no contexto. Ele não pode enviar qualidade abaixo da linha de base da avaliação — as pontuações estão registradas.
O piso de qualidade sobe a cada rodada. Movimento apenas para frente. Essa é a catraca.
Como isso funciona na prática
Vou tornar isso concreto. GBrain é um sistema de conhecimento que estou construindo — ele dá aos agentes de IA memória de longo prazo armazenando, indexando e pesquisando anotações, reuniões, conversas e pesquisas de uma pessoa. Pense nisso como um segundo cérebro que seu assistente de IA pode realmente ler.
Uma de suas funcionalidades é a extração epistemológica: ele lê milhares de páginas e extrai quem acredita no quê, com qual confiança, ao longo do tempo. "Garry acha que o Bitcoin vai chegar a US$ 300K (confiança: 0,45)." "Jared acha que esta startup tem forte retenção (confiança: 0,80)." Assim, mas em 28.000 páginas.
A primeira execução de extração puxou 100.720 alegações. Usei uma avaliação entre modelos para classificar a qualidade — fiz o GPT-5.5 e o Claude pontuarem a saída de forma independente. No geral: 6,8 de 10.
O maior problema? Algo que chamo de confusão de titular. Pegue a alegação "A IA substituirá 80% dos engenheiros de software até 2027." Quem detém essa crença? É a pessoa que a escreveu? É alguém que eles estão citando? Ou é o mecanismo de análise do sistema, que a inferiu de uma transcrição de podcast? A Versão 1 errou essa distinção 35% das vezes. Isso importa — se você está construindo um sistema que rastreia o que as pessoas acreditam, você precisa saber QUEM acredita.
Então os resultados da avaliação foram documentados. Seis modos de falha específicos foram identificados. O prompt da Versão 2 abordou todos os seis. O arredondamento de peso (as pontuações de confiança) foi aplicado na camada do banco de dados — sem mais falsa precisão como 0,74 quando 0,75 é a resposta honesta. Dezessete testes travaram o contrato.
Agora, nenhuma versão futura da extração pode ser enviada sem que esses 17 testes passem. Ninguém precisa lembrar por que o arredondamento de peso importa ou o que é confusão de titular. Os testes lembram.
O piso de qualidade subiu permanentemente. Essa é uma volta da catraca.
Por que a maioria dos projetos vibecoded morre
"Vibecoding" é o termo de Andrej Karpathy para programar com IA descrevendo o que você quer em linguagem natural e deixando o modelo gerar o código. É poderoso e é como eu construo. Mas pelo que vi em aplicações YC e repositórios open-source, a maioria dos projetos vibecoded que pulam os testes começa a desmoronar quando atinge complexidade moderada — algumas milhares de linhas, um punhado de funcionalidades interagindo.
Eles pulam a catraca. Sem testes, sem docs, sem avaliações. O agente adiciona complexidade, mas nada impede a regressão. Cada nova funcionalidade tem chance de quebrar uma antiga, e sem testes, você só descobre quando um usuário reporta. Na versão 0.5, a base de código é uma casa mal-assombrada onde cada mudança quebra algo inesperado. Então o desenvolvedor escreve um post no blog sobre como a codificação com IA não funciona.
A codificação com IA funciona bem. Eles só não construíram a catraca.
Você poderia argumentar que o tipo de pessoa que escreve testes também é o tipo que escreve boa arquitetura desde o início. Justo. Mas o mecanismo da catraca não é sobre a pessoa — é sobre o que acontece na próxima rodada. Quando um novo contribuidor abre um PR, ou quando uma versão do modelo muda, ou quando você está programando às 2h da manhã e seu julgamento está prejudicado, os testes pegam regressões independentemente de quem os escreveu. A catraca funciona mesmo quando o humano não está no seu melhor. Esse é o ponto.
Sem testes, a melhoria é um processo ruidoso — agentes tentam melhorar as coisas, mas sem sinais de regressão, mudanças boas e ruins são igualmente invisíveis. Com um conjunto denso de testes, você obtém uma catraca na superfície testada: a qualidade só pode subir para os comportamentos que você codificou. Isso é a maior parte do sistema, não tudo. Mas é suficiente para sustentar o movimento para frente em velocidade.
Testes como memória institucional
Em empresas de software tradicionais, a memória institucional vive em humanos. O engenheiro sênior que sabe por que aquela camada de cache existe. O arquiteto que lembra a migração que quase destruiu o banco de dados. O tech lead que pode explicar o caso de borda estranho no sistema de faturamento.
Humanos vão embora. Eles se aposentam, são roubados por outras empresas, se esgotam. Quando vão, o conhecimento vai com eles. Toda empresa de software já teve a experiência de abrir um arquivo crítico e encontrar um comentário que diz // NÃO MEXA NISSO — pergunte ao Dave e o Dave saiu há três anos.
A janela de contexto do agente não pede demissão. Não é roubado por outra empresa. Não esquece. Quando o conjunto de testes codifica "o arredondamento de peso deve usar incrementos de 0,05" e a documentação explica "porque a avaliação entre modelos mostrou que a falsa precisão degrada a confiança nas pontuações", esse conhecimento é durável. Qualquer agente, qualquer modelo, a qualquer momento pode carregar esse contexto e entender a restrição.
Testes são memória institucional que sobrevive à rotatividade de funcionários. Para um projeto de uma pessoa, são ainda mais críticos — são a única memória institucional que você tem.
Tudo que pode ser aproveitado é testável
A catraca não funciona apenas para código tradicional. Funciona para qualquer coisa que um computador possa observar.
Pense nas camadas de um sistema moderno. O SO te dá árvores de processos, estado do sistema de arquivos, sockets de rede, agendamentos cron. O terminal te dá cada tecla pressionada, cada linha de saída, cada prompt interativo. O navegador te dá páginas renderizadas, estados de botões, eventos de navegação. APIs te dão respostas estruturadas que você pode analisar e validar. E agentes de IA te dão comportamento observável — o que dizem, quais ferramentas chamam, em que ordem fazem as coisas, se perguntam antes de agir.
Tudo isso é aproveitável. E se você pode aproveitar, pode observar. Se pode observar, pode fazer asserções. Se pode fazer asserções, pode colocar na catraca.
Esta é uma área de superfície muito maior do que testes unitários tradicionais. Deixe-me mostrar.
GStack é meu framework de agente de codificação open-source — 93.000 estrelas no GitHub, 701.000 linhas de código, 46 habilidades. Uma de suas funcionalidades principais é a revisão interativa de planos: você pede para ele revisar sua arquitetura, e ele percorre o plano seção por seção, fazendo perguntas, sondando casos de borda, desafiando suas suposições. Como ter um gerente de engenharia que realmente lê o código.
O problema: o Claude Code às vezes pulava toda a parte interativa. Ele lia o arquivo de plano, despejava todas as descobertas de uma vez e saía — sem fazer uma única pergunta ao usuário. O objetivo principal da revisão é o diálogo de ida e volta. Pular isso derrota o propósito.
Como você testa isso? Você não pode testar unitariamente "se a IA teve uma conversa". Nenhum framework de teste tradicional cobre isso.
Então usei a funcionalidade TTY do Bun para construir um harness de teste (PR #1354) que literalmente spawna o Claude Code dentro de um pseudo-terminal, alimenta com um cenário de repositório específico, aciona a habilidade de revisão e observa a saída do terminal em tempo real. O teste observa se o agente dispara uma pergunta interativa antes de terminar. Se ele despejar descobertas e sair sem perguntar nada, o teste falha.
Isso não é testar código. É testar se um agente de IA segue um contrato comportamental. No nível do TTY. Observando-o literalmente trabalhar.
A resposta da catraca foi em três camadas:
- Gates STOP nas instruções da habilidade — regras explícitas que dizem "você DEVE perguntar ao usuário antes de prosseguir para a próxima seção", com cláusulas anti-racionalização que nomeiam o modo de falha específico para que o modelo não possa se convencer a pular
- Cláusula anti-atalho — "o arquivo de plano é a SAÍDA da revisão interativa, não um substituto para ela." Uma frase que fecha a brecha exata que o modelo continuava explorando.
- Testes de piso de gate — os testes do harness TTY que spawnam o Claude Code em cenários controlados e falham se o agente não fizer pelo menos uma pergunta interativa
Agora, quando a Anthropic envia uma nova versão do modelo, ou quando mudo um prompt de habilidade, o conjunto de testes pega qualquer regressão no contrato interativo. O agente não pode parar silenciosamente de fazer perguntas. O teste observa o terminal e verifica.
Ou pegue o PR #880, que enviou um novo plugin OpenClaw. O teste não verifica apenas se o código compila. Ele constrói o plugin a partir da fonte, spawna uma instância real do OpenClaw em um perfil isolado, instala o plugin via CLI, executa plugins inspect para verificar se o runtime o carregou, define o slot de configuração, valida a configuração e executa plugins doctor para confirmar zero diagnósticos. Uma viagem completa de ponta a ponta entre dois programas separados. 359 linhas de código de teste. O tipo de teste que um humano quase nunca escreveria manualmente porque a configuração é muito tediosa. Claude o escreveu em cerca de cinco minutos. Essa é a parede de esforço desaparecendo em tempo real.
O princípio se generaliza. Você pode testar no nível do SO: a migração criou as tabelas certas, o cron job disparou, o processo ainda está vivo? No nível do navegador: a página renderizou, o agente preencheu o formulário corretamente? No nível da API: o modelo retornou JSON válido com o esquema certo? No nível comportamental: o agente seguiu o protocolo, perguntou antes de deletar, parou quando foi instruído a parar?
Toda a pilha é testável. A catraca se aplica a tudo isso. A maioria das pessoas ainda não percebeu isso porque ainda estão pensando em cobertura de teste como "minha função retornou o número certo". A verdadeira superfície de teste é tudo que o computador pode ver.
O número 90%
Então, o que 90% de cobertura de teste realmente compra para você?
Capers Jones estudou mais de 10.000 projetos de software e mediu a eficiência de remoção de defeitos (DRE) — a porcentagem de bugs pegos antes de chegarem aos usuários. Seus dados de Applied Software Measurement mostram uma curva não linear: abaixo de 70% de cobertura, a DRE fica em torno de 65-75%. Em 85-95% de cobertura, a DRE salta para 92-97%. A relação não é linear. Há um joelho na curva em torno de 85% onde as fugas de defeitos caem drasticamente.
A indústria de aviônicos descobriu isso décadas atrás. DO-178C, o padrão da FAA para software crítico de voo, exige cobertura de condição/decisão modificada (MC/DC) para sistemas Nível A — aqueles onde um bug significa um acidente de avião. A cobertura de ramo sozinha perde 10-20% das falhas. MC/DC, que é mais rigorosa que a cobertura de linha, atinge >99% de DRE. Eles não exigem isso porque burocratas gostam de papelada. Eles exigem porque os dados mostraram que abaixo de certos limites de cobertura, defeitos críticos escapam em taxas incompatíveis com não matar pessoas.
O paralelo com a engenharia de confiabilidade é claro. Fábricas usam um sistema chamado Seis Sigma para medir qualidade. A ideia: conte quantos defeitos você obtém por milhão de unidades produzidas, depois expresse isso como um "nível sigma" — sigma mais alto significa menos defeitos. Um processo de 3 sigma produz cerca de 67.000 defeitos por milhão (muito ruim). Um processo de 4 sigma produz cerca de 6.200 (dez vezes melhor). Um processo de 5 sigma produz 233 (outras 27 vezes melhor). O salto de 4 para 5 sigma não é uma melhoria incremental. É uma mudança de fase.
A cobertura de teste segue a mesma curva. Ir de 70% para 90% de cobertura não é 30% melhor. É uma ordem de magnitude a menos de fugas. Os defeitos que escapam em 70% estão escondidos nos 30% de código não testado. Em 90%, os esconderijos encolhem para 10% e a maioria dos caminhos perigosos está bloqueada.
Agora, devo ser honesto sobre o que a pesquisa também mostra. Mockus, Nagappan e Dinh-Trong estudaram o Windows Vista e descobriram que, embora a cobertura se correlacione com menos defeitos pós-lançamento, o esforço para atingir 90%+ aumenta acentuadamente. Os últimos 20% de cobertura levam desproporcionalmente mais trabalho do que os primeiros 70%. Isso é verdade há décadas. É por isso que a maioria das equipes para em 70-80% e considera bom o suficiente.
Mas algo mudou: Agentes de codificação de IA não sentem esforço.
Eles não ficam entediados escrevendo o décimo quarto teste de caso de borda. Eles não cortam caminhos às 17h de uma sexta-feira. Eles não olham para um teste de integração complicado e pensam "volto a isso mais tarde". A curva de esforço que parou equipes humanas em 70% não se aplica a agentes. Você pode pedir ao Claude para escrever testes para cada caso de borda em um módulo e ele o fará alegremente, minuciosamente, às 2h da manhã, sem reclamar. Os brutais últimos 20% que tornaram a cobertura de 90% impraticável para equipes humanas são exatamente o tipo de trabalho em que os agentes de IA são melhores.
Este é o verdadeiro segredo. Não é que a IA permita que você escreva código mais rápido. Muitas pessoas já notaram isso. É que a IA permite que você verifique em um nível que antes era caro demais para sustentar. O limite de 90% que os dados dizem ser mágico? Costumava custar força de vontade humana demais para alcançar. Agora é gratuito.
Essa é a distinção chave. A catraca não é sobre cobertura de linha como uma métrica de vaidade. É sobre testes que codificam contratos comportamentais — o teste de confusão de titular, o teste de arredondamento de peso, o gate de revisão interativa. Cada teste trava uma lição específica aprendida. A cobertura é o proxy que te diz quanto do comportamento do sistema está sob contrato. Em 90%, quase toda mudança de comportamento dispara um sinal de teste. O agente ou passa (seguro para enviar) ou quebra um teste (pego imediatamente).
Os 10% restantes são pontos de integração, encanamento de infraestrutura e casos de borda que são genuinamente difíceis de testar. Tudo bem. Os 90% são o que transforma o caos em uma catraca.
Chegar a 90% costumava ser um esforço heróico. Agora é uma terça-feira. Essa é a mudança de jogo.
Prova de conceito
Comecei ambos os projetos sozinho. Eles não são mais solo.
GStack agora tem 37 contribuidores. A v1.30 incorporou 21 PRs da comunidade em um único release. GBrain tem 25 contribuidores. A v0.31.1.1 recebeu 22 correções da comunidade em um PR — fluxo de autenticação, inicialização de esquema, sincronização, privacidade.
A catraca é o que torna isso seguro. Cada PR externo tem que passar pelo conjunto de testes existente. Um novo contribuidor não precisa entender todo o sistema. Eles precisam fazer os testes passarem.
Os releases do GBrain da semana passada contam a história:
- v0.31.0: uma nova tabela de fatos para memória em tempo real, mais uma fase de consolidação de sonhos que promove memórias de curto prazo em conhecimento de longo prazo
- v0.31.1: corrigiu 25 comandos CLI que estavam roteando silenciosamente para um banco de dados local vazio em vez do cérebro real do usuário
- v0.31.1.1: vinte e duas correções reportadas pela comunidade em um PR
- v0.31.2: corrigiu uma sincronização de código que travava para sempre em grandes repositórios com symlinks adicionando um timeout de 30 segundos
Cada release foi enviado com mais testes que o anterior. O agente escreve os testes junto com o código. A cobertura não cai porque o esforço para mantê-la não é mais um fardo humano.
O novo teto de complexidade
O teto de complexidade para software acabou de ficar muito mais alto.
Costumava ser limitado pela capacidade de uma equipe manter o sistema na cabeça. Agora é limitado por uma pessoa mais agentes que podem carregar toda a base de código, histórico de esquema, conjunto de testes e documentação no contexto.
Esse é um número muito maior. E continua crescendo à medida que as janelas de contexto ficam maiores e os modelos ficam melhores em raciocinar sobre código.
Toda empresa de software que não adota este modelo — agentes mais bom gosto mais um conjunto de testes que só sobe — já está entregando mais devagar e com menos qualidade do que uma pessoa que o tem.
As ferramentas estão aqui. O código é aberto. Testes são a catraca. 90% de cobertura, todo PR, sem exceções.
Por cinquenta anos, 90% de cobertura foi um luxo reservado para aviônicos e dispositivos médicos — equipes com orçamento para jogar horas humanas na parede de esforço. Agentes de IA demoliram essa parede. O limite de cobertura que torna o software confiável não é mais caro. É apenas uma configuração. A pergunta não é se você pode pagar por 90%. É se você pode pagar por não ter.
A catraca, as habilidades e todo o sistema de conhecimento são open source e gratuitos no GitHub. Vá construir.
Meus projetos open-source com licença MIT:
- GStack — torna o Claude Code drasticamente melhor. 93K estrelas. Grátis.
- GBrain — seu segundo cérebro para agentes de IA. 14K estrelas. Grátis.
A série AI Explainer:
- Fat Skills, Fat Code, Thin Harness — a arquitetura
- Resolvers — a tabela de roteamento para inteligência
- The LOC Controversy — o que 600K linhas realmente produziram
- Naked Models Are Stupider — o modelo é o motor, não o carro
- The Skillify Manifesto — todo fluxo de trabalho se torna uma habilidade testável
- Meta-Meta-Prompting — habilidades compostas produzem capacidades emergentes
- The Agent Complexity Ratchet — você está aqui
https://x.com/garrytan/status/2054055071017538028
https://x.com/garrytan/status/2042925773300908103
https://x.com/garrytan/status/2044479509874020852
https://x.com/garrytan/status/2045404377226285538
https://x.com/garrytan/status/2045798603059548364
https://x.com/garrytan/status/2046876981711769720
