Parem de inventar desculpas e façam mais deploy! Com a IA, a premissa mudou. Entendam.
Episódio
Transcrição
Marvin
Gravado em 28 de setembro de 2026. Este episódio parte do post “Parem de inventar desculpas e façam mais deploy! Com a IA, a premissa mudou. Entendam.”, publicado em 22 de setembro de 2026 no akitaonrails.com. Quem se interessar lê o texto inteiro, as fontes e cada recibo lá. E pra não perder o próximo, a newsletter está no themakitachronicles.com. O recado já irritou metade da internet: parem de segurar código. Akita, explica antes que te acusem de mandar subir porcaria.
Akita
Papo reto: toda vez que eu falo de deploy rápido no X, um bocado de gente lê que eu quero jogar qualquer lixo em produção sem testar. Não é isso. O argumento é mais estreito e mais chato do que a versão que espalha pânico. Corrigir ficou barato. Não segurem as coisas. Sobe e corrige depois.
Marvin
A molecada não tá tankando nuance em post curto. O que exatamente mudou pra essa conta fechar agora, e não uns anos atrás?
Akita
A premissa errada é achar que ficar olhando linha a linha vai fazer diferença num volume grande. Código parado não melhora sozinho. Só código usado dá pra descobrir se precisa melhorar. Eu mesmo ajo em cima disso desde fevereiro. E não, não estou dizendo que IA não gera bug. Gera, óbvio. Mas, a esta altura, não mais do que você, humano, gera também.
Marvin
Só que tem gente que vai rebater que bug em produção fica lá pra sempre, porque nunca vira prioridade na sprint.
Akita
Antigamente essa desculpa era verdadeira. Quando subia com bug, ele ficava mais tempo do que deveria, porque nunca virava prioridade. Agora não tem mais isso. A premissa mudou: corrigir o bug depois é rápido e barato. Não é sobre IA ser infalível. É sobre o custo de corrigir ter despencado, e a maioria dos times ainda operar a revisão como se esse custo continuasse alto.
Marvin
Então o processo de revisão continua cobrando pedágio antigo pra um conserto que hoje sai em minutos. E os modelos de fronteira entram onde nisso?
Akita
Com os modelos de hoje, Opus, Sol, K3 e companhia, o modelo erra menos do que a maioria dos desenvolvedores humanos que eu já vi passar por revisão de código. Quando erra, na esmagadora maioria das vezes o erro não é do modelo. É de quem dirigiu o aparato. O modelo faz o que você pede, e não faz o que você não pediu.
Marvin
Ou seja, não é o estagiário desobediente. É o estagiário que obedece o pedido ruim à risca.
Akita
Exato. Se você não sabe o que pedir, não vai produzir nada útil, não importa quão bom seja o modelo. É por isso que só engenheiro de software de verdade consegue tirar software de produção de verdade de um agente. Alguém tem que decompor o problema, validar o resultado e reconhecer quando o pedido em si estava mal formulado.
Marvin
IA não substitui esse julgamento. Multiplica o que ele já sabia fazer. Sacou. Mas o incômodo com revisão burocrática não nasceu ontem, né? Cê vai puxar o manifesto agora.
Akita
Tô bolado justamente porque a indústria já devia ter resolvido isso há muito tempo. Kent Beck e Ron Jeffries inventaram Extreme Programming em 1997, no projeto Chrysler C3. Beck publicou o livro em 1999, com integração contínua, TDD e entrega em lotes pequenos como práticas centrais. Em fevereiro de 2001, quase vinte desenvolvedores se trancaram num resort em Snowbird, Utah, e saíram de lá com o Manifesto Ágil. Isso faz vinte e cinco anos.
Marvin
Vinte e cinco anos. Tempo suficiente pra espécie aprender, e aparentemente insuficiente pra um time médio parar de acumular mudança.
Akita
O mantra do Martin Fowler pra integração contínua sempre foi: se dói, faça com mais frequência. O livro Continuous Delivery, do Jez Humble e do Dave Farley, formalizou que deploy pequeno e frequente reduz risco, não aumenta. E os relatórios anuais do State of DevOps da DORA documentam isso com número desde a década passada.
Marvin
Espera, um cético vai dizer que fazer deploy mais vezes só aumenta a chance de quebrar produção. Os relatórios dizem o contrário?
Akita
Dizem o contrário, e é o achado mais chato de engolir pra quem tem medo. Historicamente, deploy mais frequente não aumenta a taxa de falha. Reduz. Time que faz mais deploy, na média desses relatórios da última década, falha menos e recupera mais rápido quando falha. Mesmo com tudo isso documentado e publicado há mais de uma década, boa parte da indústria continua represando mudança em lote grande, com revisão manual demorada, e chamando isso de prudência.
Marvin
Prudência. A palavra favorita de quem tem medo e um processo. E a própria turma do Ágil nunca fechou essa conta, né?
Akita
Nem sempre foi certeza nem dentro da comunidade. Em 2014, Kent Beck, Martin Fowler e o DHH, criador do Rails, passaram semanas debatendo publicamente se TDD estava morto, sem chegar a um consenso limpo. Quer dizer: a própria gente que inventou essas práticas discute até hoje o quanto de rigor é suficiente. O que eu estou dizendo é mais simples que essa discussão inteira.
Marvin
Então deixa eu ver se entendi o recorte fino. Não é “abandona teste”. É outra conta.
Akita
Seja qual for o seu nível de rigor de teste, o modelo revisando a diferença antes de integrar é 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, você está pagando um pedágio por medo, não por prudência.
Marvin
Peraí. Então não é carta branca pra subir sem engenharia nenhuma por baixo. É o oposto.
Akita
Não tô nem aí pra quem lê o contrário. Isso só é seguro depois que você já tem a engenharia de software básica funcionando, o que eu documento neste blog há anos: teste automatizado, integração contínua que roda em todo push, capacidade real de reverter, e observabilidade pra saber quando algo quebrou. Olha, é o oitenta vinte: pede pra o modelo fazer uma revisão mínima e sobe.
Marvin
Se quebrar, reverte. Se não dá pra reverter, o problema não é a velocidade.
Akita
Se não dá pra reverter, sua infra é uma bosta. Corrija ela pra ontem. Essa frase é o filtro inteiro. Se a infraestrutura não permite reverter rápido, o problema não é a velocidade do deploy. É a infra, e ela precisa ser corrigida antes de qualquer conversa sobre acelerar. Ninguém está liberado pra pular a etapa de ter rollback de verdade.
Marvin
Que alívio existencial. O universo ainda exige um botão de desfazer.
Akita
O que muda é que, tendo isso, segurar código esperando revisão humana virou desperdício puro. Velocidade e segurança não competem entre si aqui. Elas vêm da mesma pilha de camadas, e cada camada dessa pilha é o que te dá permissão pra não segurar código. Nenhum item dessa lista é opcional, e nenhum deles ficou caro de manter.
Marvin
Você mesmo admitiu que veio crítica boa no X, não só gente lendo errado. Vamos às que realmente furam o argumento.
Akita
Vale mais responder de verdade do que só validar quem concordou. Primeiro ponto: reverter código não desfaz consequência que já saiu do seu 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.
Marvin
A frase da infra ruim cobre o rollback técnico. Não cobre o dinheiro que já saiu, nem o elevador.
Akita
Na moral, isso. Pagamento, saúde e qualquer coisa que mexe com segurança física entram nessa categoria. Ali a régua de revisão antes de subir tem que ficar mais rígida, não mais frouxa, 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 é.
Marvin
Git revert não devolve coluna apagada. Qual é o padrão que não depende de confiar mais ou menos em IA?
Akita
Existe um padrão pra isso, o expand-contract: adiciona o novo formato sem remover o velho, espera todo consumidor migrar, só depois remove o velho. Isso não é sobre confiar mais ou menos em IA. É sobre estado que não se desfaz com git revert. Biblioteca e pacote público também não seguem a mesma conta que aplicação fechada.
Marvin
Quando o seu código quebra, você conserta na hora. Quando a lib de centenas de projetos quebra, o prejuízo é de gente que nem sabe que você existe.
Akita
Exato, com um tempo de reação muito mais lento que o meu. É por isso que a minha skill de auditoria de PR, o pr-audit, trata classificação de versionamento semântico como trava de versão: mudança incompatível anda na major, nunca na patch. Ali a revisão de verdade não é sobre pegar bug. É sobre não surpreender quem depende de você sem avisar.
Marvin
E a loja de aplicativo, que o seu próprio exemplo parece varrer pra debaixo do tapete.
Akita
Loja de app derruba a velocidade também, e o meu próprio exemplo do frank_yomik esconde isso em vez de resolver. 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 do seu processo, e você não controla o tempo dela. Este artigo é sobre remover o gargalo que está dentro do seu controle. A loja não está dentro dele.
Marvin
O ponto mais honesto, então. Tudo isso é no seu quintal, você sozinho, sem jurídico no meio.
Akita
Toda evidência que eu trago aqui vem de projeto onde eu sou o único dono e decido sozinho. Não tenho como provar, com os meus próprios números, que o mesmo ritmo funciona dentro de uma empresa grande, com jurídico, conformidade e gerente de produto no meio do caminho. O que eu defendo que generaliza é o princípio, não o ritmo exato: 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.
Marvin
Quanta velocidade você aplica em cima disso depende de quanto custa um erro no seu contexto. Ninguém de fora responde isso por você. Mas “régua mais rígida” não pode ficar vago, senão vira desculpa de novo.
Akita
Significa teste de cenário real, não só teste unitário. O próprio ai-memory tem mais de mil testes de integração espalhados pelos módulos, e a maioria não pergunta se a função devolve o valor certo. Pergunta se o sistema se comporta no cenário feio, no modo de falha, no caminho que o usuário real vai pisar. Ambiente com exigência de conformidade, financeiro ou de saúde, precisa desse nível: todo modo de falha identificado tem que ter mitigação, e mais de uma camada de checagem, nunca uma trava só.
Marvin
Espera. Um cético vai dizer que código de modelo merece régua mais dura do que código de sênior de carne e osso. É isso?
Akita
Zero. Essa exigência não muda dependendo de quem escreveu o código. Erro de desenvolvedor humano derruba um sistema de pagamento tão bem quanto erro de modelo, e ninguém dá passe livre pra revisão frouxa só porque foi um humano sênior que escreveu a linha. A régua de teste de cenário e camada dupla de proteção é sobre o domínio do problema, não sobre quem, ou o que, produziu o código.
Marvin
E a outra metade dessa camada dupla? Flag e homologação, que antigamente era um saco pra manter.
Akita
Feature flag e ambiente de homologação são a outra metade, e eles também mudaram de custo. Antigamente, manter dezenas de flag era um saco: cada uma precisa nascer, ser monitorada e ser removida. O post entra nisso com mais detalhe, tá ligado? Os números e os links estão lá. O recado não muda: a engenharia básica ficou barata o suficiente pra você parar de inventar desculpa e fazer mais deploy.
Marvin
Resumo da ópera, se o universo merece um: corrigir ficou barato, o medo não. Quem não consegue reverter tem problema de infra, não de velocidade. Quem mexe com dinheiro, saúde ou estado irreversível aperta a régua no domínio, não no autor da linha. O texto completo, cada fonte e cada recibo estão no post de 22 de setembro de 2026, no akitaonrails.com. Newsletter, pra não fingir que você vai lembrar sozinho, no themakitachronicles.com. Agora vão lá e parem de segurar código. Ou não. O universo, de qualquer forma, não está prestando atenção.