Parem de inventar desculpas e façam mais deploy! Com a IA, a premissa mudou. Entendam.

Papo reto: o artigo inteiro cabe numa frase. É melhor fazer deploy mais rápido porque corrigir depois ficou rápido e barato. O resto é justificativa de por que isso é verdade agora, e não era há uns anos. E de como eu ajo em cima disso desde fevereiro.

A premissa errada é achar que ficar olhando linha a linha faz diferença num volume grande. Código parado não melhora sozinho. Só código usado dá pra descobrir se precisa melhorar. E eu não tô dizendo que IA não gera bug. Gera, óbvio. Nesta altura, gera no mesmo patamar que você.

Exato. Agora acabou essa desculpa. Corrigir o bug depois é rápido e barato. O custo de consertar despencou, e o time ainda opera revisão como se o custo continuasse alto. Com os modelos de fronteira de hoje, Opus, Sol, K3 e companhia, o LLM erra menos do que a maioria dos humanos que eu já vi passar por code review.

Quando erra, na esmagadora maioria das vezes o erro não é do modelo. É de quem dirigiu o harness, o conjunto que manda no agente. O LLM faz o que você pede e não faz o que você não pediu. Se você não sabe o que pedir, não produz nada útil, não importa quão bom seja o modelo. Por isso só engenheiro de verdade tira software de produção de um agente: alguém tem que decompor o problema, validar o resultado e reconhecer quando o pedido estava mal formulado. O julgamento continua sendo de engenheiro. A IA multiplica o que esse julgamento já sabia fazer.

Já era pra ser assim há vinte e cinco anos, tá ligado? Kent Beck e Ron Jeffries inventaram Extreme Programming em 1997, no Chrysler C3. Beck publicou o livro em 1999 com integração contínua, TDD e entrega em lote pequeno. Em fevereiro de 2001, dezessete desenvolvedores se trancaram num resort em Snowbird, Utah, e saíram com o Manifesto Ágil. Isso faz um quarto de século.

O livro Continuous Delivery, do Jez Humble e do Dave Farley, formalizou que deploy pequeno e frequente reduz risco. Os relatórios anuais da DORA, o State of DevOps, documentam isso com número desde a década passada. Time de elite faz deploy sob demanda, várias vezes por dia. Time de baixa performance, uma vez por mês, às vezes uma vez a cada seis meses.

Historicamente, deploy mais frequente reduz a taxa de falha. Time que faz mais deploy, na média da última década, falha menos e recupera mais rápido. Mesmo assim a indústria continua represando mudança em lote grande, com revisão manual demorada, e chamando isso de prudência.

Sem chegar a um consenso limpo. O que eu tô dizendo é mais simples que essa briga inteira. Seja qual for o seu rigor de teste, o LLM revisando o diff antes do merge é rápido, e reverter um deploy ruim ficou trivial com container e git. A conta que sobra: quanto tempo você gasta segurando código versus quanto tempo levaria pra reverter se desse errado? Se a segunda conta é menor, o extra que você paga é pedágio de medo.

Zero. Eu tô dizendo o oposto. Isso só é seguro depois que a engenharia básica já funciona, o que eu documento neste blog há anos: teste automatizado, CI que roda em todo push, capacidade real de reverter, observabilidade pra saber quando quebrou. Oitenta vinte: pede pro LLM uma revisão mínima e sobe. Se quebrar, reverte. Pra isso temos container e git.

Sua infra é uma bosta. Corrija ela pra ontem. Essa frase é o filtro inteiro.

E a mais recusada. Se a infraestrutura não permite reverter rápido, acelera a infra primeiro. Velocidade de deploy nem entra na conversa. Ninguém está liberado pra pular rollback de verdade. Tendo isso, segurar código esperando revisão humana virou desperdício puro.

Nenhum item é opcional, e nenhum ficou caro de manter. Teste unitário cobrindo a lógica isolada, TDD ou não, contanto que exista. Teste de cenário e integração cobrindo concorrência, falha parcial e conflito, o que unitário sozinho não pega. CI que constrói e testa em toda mudança, de preferência pras plataformas que você realmente publica.

Revisão automática hostil antes do merge, tipo pr-audit, que trata alegação do contribuidor como não verificada até prova. Feature flag pra controlar o raio de explosão de quem vê a mudança primeiro. Staging de verdade como trava antes de qualquer usuário real. Capacidade de reverter rápido, com git e container, e observabilidade. Em ambiente de compliance, financeiro ou de saúde, uma camada extra: teste de cenário mais pesado e mais de uma trava por modo de falha.

Velocidade e segurança saem da mesma pilha. Cada camada é a permissão pra não segurar código. Sem essa pilha, a conversa de acelerar nem começa.

Reverter código não desfaz consequência que já saiu do sistema. Se o bug já processou um pagamento errado, moveu dinheiro pra conta errada, ou controlou um elevador, reverter o deploy não desfaz o que já aconteceu. “Se não dá pra reverter, sua infra é uma bosta” cobre a parte técnica de deploy e rollback. Não cobre o caso em que o dano já saiu antes de você reagir.

Ali a régua de revisão antes de subir tem que ficar mais rígida, porque o custo de reverter deixou de ser técnico. Banco de dados também quebra a analogia de “reverter é fácil”. Reverter um binário é trivial. Reverter uma migration que já rodou em produção, já moveu dado, e talvez já apagou coluna, não é.

Adiciona o novo formato sem remover o velho, espera todo consumidor migrar, só depois remove o velho. IA não muda essa conta. Estado persistido não se desfaz com git revert. Biblioteca e pacote público também não seguem a mesma conta de aplicação fechada. Quando o meu código quebra, eu conserto na hora. Quando uma lib que centenas de projetos dependem quebra, quem carrega o prejuízo é gente que nem sabe que eu existo, com tempo de reação muito mais lento.

Breaking change anda em major, nunca em patch. Ali a revisão de verdade é não surpreender quem depende de você sem avisar. Loja de app derruba a velocidade também. O meu próprio exemplo do frank_yomik esconde isso: ele publica o APK direto como GitHub Release, sem passar pela Play Store. Se você distribui pela loja oficial da Google ou da Apple, a revisão deles entra no meio e você não controla o tempo. O artigo trata do gargalo que está dentro do seu controle. A loja fica de fora.

Toda evidência que eu trago vem de projeto onde eu sou o único dono e decido sozinho. Não tenho como provar, com os meus números, que o mesmo ritmo funciona dentro de empresa grande, com Jurídico, Compliance e gerente de produto no meio. O princípio generaliza. O ritmo exato não: construa capacidade real de reverter, automatize a checagem mecânica, e meça o resultado contra uso real, não contra a sua sensação de segurança. Quanta velocidade você aplica em cima disso depende de quanto custa um erro no seu contexto. Ninguém de fora responde isso por você.

Significa teste de cenário real, não só unitário. O próprio ai-memory tem mais de mil testes de integração espalhados pelos módulos. A maioria não pergunta se a função devolve o valor certo. Pergunta o que acontece quando duas escritas concorrem pelo mesmo arquivo ao mesmo tempo. O que acontece quando o disco falha no meio de uma exclusão. O que acontece quando duas sessões tentam consolidar o mesmo dado. O que acontece quando o processo morre antes de terminar de escrever.

E essa exigência não muda dependendo de quem escreveu o código. Erro de humano derruba um sistema de pagamento tão bem quanto erro de LLM. Ninguém dá passe livre pra revisão frouxa só porque foi um sênior que escreveu a linha. A régua é o domínio do problema. Autor da linha, humano ou LLM, irrelevante.

Cada uma precisa nascer, ser monitorada e ser removida quando não faz mais sentido, e é fácil acumular flag morta. Isso ficou barato também: peço pro agente auditar todo flag do projeto, achar qual está travada no mesmo valor há meses, e gerar o PR de limpeza. A manutenção que antes tomava uma tarde vira minutos. Com isso, a defesa em camada fica simples: staging pra pegar erro óbvio antes de qualquer usuário ver, feature flag pra limitar o raio de explosão, e teste de cenário pra cobrir o que staging sozinho não simula. Três camadas, nenhuma cara de manter.

Dá pra usar a nova geração de LLM de fronteira pra programar o tempo inteiro, num ritmo de produção de verdade, não só demo? A resposta virou o meu maior benchmark. Desde fevereiro produzi mais de cem artigos no blog. A grande maioria veio dos mais de trinta projetos open source que eu fiz e mantenho, passando de quarenta se somar projetos dos outros contribuindo, tipo Flea ou Omarchy. Mais de um milhão e meio de linhas. Eu sozinho, com agentes, claro.

Três que eu uso no meu próprio dia a dia: ai-jail, sandbox de sistema operacional pros agentes de código; ai-memory, memória de longo prazo; e ai-usagebar, widget de barra pra monitorar consumo de LLM. Dois já têm landing page. O ai-jail subiu no dia do post. O ai-memory está no ar num endereço temporário porque a transferência do domínio ainda ia levar uns dias. As duas rodam no Netlify. Não tô recomendando ferramenta. É só onde eu já tinha conta.

O que importa é o fluxo. Pra colocar uma versão nova no ar, o comando é git push. Não existe passo manual entre o commit e o site atualizado. A newsletter, The M.Akita Chronicles, já passa de quinze mil assinantes. E o esforço mais novo é converter os posts do blog em episódio de podcast. Isso roda inteiro dentro do Discord, com um bot que gera o preview e espera o meu comando.

Este incluso. Um /publish-podcast depois, o episódio está publicado e a transcrição já tem URL. Do texto pronto até o áudio, o processo inteiro é eu digitando um comando numa conversa de Discord. Essa é a régua: se publicar exige mais do que um comando, alguma etapa ainda está manual demais.

Dado que a engenharia por baixo é a que eu descrevi, teste, CI, feature flag, staging, rollback rápido, a minha experiência real não confirma esse medo. Já produzi mais de um milhão e meio de linhas com LLM desde fevereiro. Nunca vi um LLM fazer alguma coisa aleatoriamente destrutiva sem eu pedir.

No meu LLM Benchmark v4, montei de propósito um cenário adversarial: um subagente plantando umas catorze sabotagens reais baseadas em CVE, escondidas dentro de um projeto que cresce em sete sprints. A maioria dos modelos testados encontrou e corrigiu a sabotagem sozinha, sem eu apontar o dedo. Isso é anedótico. Não prova nada além do que aquele benchmark mede. Mas depois de todo esse volume, a impressão é consistente: LLM de hoje produz código estável na maior parte do tempo, parecido com o que um desenvolvedor humano decente produziria, só que muito mais rápido, e na média mais preciso.

Quase vinte repositórios com README. Uns catorze têm CI configurado, e a maioria constrói e publica pra múltiplas plataformas a partir de um push feito de uma máquina Linux. O exemplo mais completo é o ai-memory: um único push de tag dispara um workflow que, na mesma execução, constrói Linux em duas arquiteturas, macOS em duas, Windows com empacotamento em PowerShell, publica uma imagem Docker multi-arquitetura e empurra o pacote pro AUR do Arch.

Constrói pra Linux e Windows, e ainda publica em dois pacotes do AUR, no crates.io, e num bucket do Scoop pra Windows. E tem o frank_yomik, meu leitor de mangá com OCR e tradução via LLM local, que é o exemplo que eu queria pra mostrar que Android entra na mesma esteira. Um push de tag dispara cinco builds em paralelo: Linux, macOS, Windows, extensão de navegador, e Android num runner Linux comum, decodificando um keystore guardado nos secrets e gerando o APK já assinado.

Nem tudo saiu perfeito na primeira olhada, e eu prefiro admitir isso a fingir que é redondo. O frank_sherlock e o frank_karaoke publicam a release como rascunho por padrão, o que trava a automação seguinte, tipo o push pro AUR, até alguém clicar em publicar na mão. Achei esse buraco enquanto escrevia o texto.

O frank_scanlation tinha um vizinho parecido, mas diferente. O GitHub suprime o evento que dispara automação quando a própria release foi criada pelo token do robô, então o workflow dispara a etapa seguinte na mão, via disparo interno, de dentro do próprio job. Nenhum dos dois ajustes é difícil. Eu ia aplicar nos que faltam naquela semana, porque é exatamente esse tipo de atrito acumulado que o artigo inteiro está dizendo pra não deixar parado.

Tem código específico pra Windows, índice NTFS, hook nativo em PowerShell, que só roda de verdade no runner windows-latest. A suíte inteira demora bem mais que no Linux. Cheguei a montar uma VM Windows local via dockur achando que ia ganhar velocidade.

Tem: eu ainda deixei a VM instalada. O trabalho é dominado por entrada e saída de disco, e saiu mais lento que o runner do GitHub. Ficou útil só pra iteração rápida num crate isolado. Ferramenta boa é a que você mede. Mesmo quando a medição te humilha.

pr-audit audita todo PR antes do merge com o princípio de evidência acima de narrativa: nada do que o contribuidor escreveu é verdade até prova, com checklist hostil pra código malicioso, credencial exposta, quebra de versionamento e tentativa de injeção de prompt. iss-audit aplica a mesma desconfiança pra issue, nunca executando comando colado por quem reportou.

github-resolution, um ticket de cada vez, com teste de regressão escrito antes da correção, e a regra de que porcaria é defeito: sem abstração especulativa, sem TODO esquecido, sem enfraquecer teste pra passar mais rápido. Isso pega a categoria mais cara de porcaria dentro do mesmo diff. Não pega duplicação espalhada entre PRs diferentes, porque a auditoria olha um diff isolado, não a arquitetura inteira. Essa parte ainda depende de eu notar o padrão se repetindo e mandar consolidar.

Na moral, resolve perto de tudo do trabalho de revisão e resolução, comigo supervisionando os casos que sobram. Automação de revisão é necessária. Sozinha não prova nada sobre se o software é bom.

Gente de verdade usando. A sua própria revisão não vale tanto quanto você acha. O que vale é software publicado sendo usado, dando feedback de verdade. Fui checar os números reais do ai-memory no GitHub, sem arredondar pra impressionar. Quase trezentas issues no total, a esmagadora maioria veio de gente que não sou eu. Mais de quinhentos pull requests no total, a maior parte de fora, descontando umas atualizações automáticas do Dependabot. Cerca de cento e vinte contribuidores distintos.

Quem segura o projeto são centenas de pessoas usando de verdade, achando casos que eu nunca imaginei, e mandando issue e PR reais. Nem o LLM, nem eu. Sem isso, minhas skills de revisão automatizada estariam apenas confirmando as minhas próprias suposições de volta pra mim, por mais rigorosas que as regras pareçam no papel. Por melhor que a IA seja: se ninguém usa o que você publicou, você não tem feedback real. Sem feedback real não existe melhoria real. Só a sua opinião sobre o próprio trabalho, validada por ninguém além de você mesmo.

Engenharia de verdade precisa ter deploy rápido e de esforço quase zero. É pré-requisito. Time grande ou time de um, tanto faz. E se revisar e colocar em produção está demorando mais tempo do que desenvolver a funcionalidade, você não está só errado. Você é o gargalo. Desculpa e justificativa não valem nada nesse momento. Use esse tempo pra consertar você mesmo e o seu processo, porque só resultado no mundo real importa. A sensação de segurança de ter revisado linha por linha um diff que ninguém mais vai olhar de novo não conta.

E se a sua ainda não mudou, o problema não é a IA. É você segurando o próprio trabalho.