Disciplina em rajada: por que o rigor não nasce junto com o código
A confiança na IA não começa no modelo, começa no processo.
Esta é a segunda parte de uma série sobre a metodologia que uso para continuar sendo, de fato, o responsável pelo que um agente de IA produz. No artigo de abertura, descrevi o padrão inteiro em visão geral; aqui aprofundo por que ele assume a forma de rajada, e não de constância.
Quantas vezes você já ouviu alguém dizer que a IA “faz o trabalho por você”? E quantas vezes, quando foi checar de perto, descobriu que o trabalho estava mais rápido, mas ninguém tinha ficado, de fato, mais no controle do resultado?
Disclaimer: este texto reflete minha visão prática sobre o tema, construída em projetos pessoais e profissionais. Não representa, necessariamente, a posição oficial de nenhuma organização à qual eu esteja afiliado.
Eu já vivi as duas versões dessa pergunta. O relatório 2026 da DORA sobre retorno de investimento em desenvolvimento assistido por IA, construído sobre uma década de pesquisa do Google Cloud, colocou número numa coisa que eu já suspeitava na pele.
Citando pesquisa da Stanford com telemetria de cerca de cem mil desenvolvedores, o relatório registra que o ganho de produtividade individual com IA é real, mas desigual (35% a 40% em tarefas greenfield, 10% ou menos em código legado complexo), e não se traduz automaticamente em resultado organizacional.
Pelo contrário: o mesmo relatório assume, como parâmetro de entrada do próprio modelo financeiro, não como algo medido diretamente, que a taxa de falha de mudanças em produção sobe de 5% para 6% depois da adoção de IA. É uma hipótese de trabalho dos autores, não uma observação, mas é desconfortável o suficiente para levar a sério: o tipo de instabilidade que apareceria depois que o código já saiu de perto de quem o escreveu rápido demais. Ganho individual sobe. Controle real sobre o resultado, nem sempre.
Vale um parênteses de honestidade sobre esses números antes de usá-los: o relatório da DORA usa um cenário ilustrativo (uma organização hipotética de 500 pessoas) para tornar tangível um framework de análise financeira, não uma média medida diretamente em centenas de empresas reais.
E ele não está sozinho. Um estudo controlado e randomizado da própria Anthropic, com 52 engenheiros majoritariamente juniores aprendendo uma biblioteca nova, achou algo complementar e mais desconfortável ainda: quem estudou com apoio de IA tirou, em média, 50% num teste de retenção depois; quem estudou sem IA tirou 67%, uma diferença de quase duas notas de letra inteiras. A IA nem chegou a entregar um ganho de velocidade estatisticamente significativo, só a sensação de ter ido mais rápido.
Nenhum dos dois é lei universal. São dados reais, de contextos reais, que ilustram um risco real, nada além disso, e nada menos.
Os três sintomas que aparecem antes de qualquer disciplina existir
Antes de qualquer um dos oito projetos ter uma auditoria, um teste de regressão obrigatório ou uma decisão de arquitetura registrada, todos passaram pela mesma fase informal. Nela, três problemas específicos se repetiram, de projeto em projeto, quase sempre do mesmo jeito.
Overclaiming. Um agente reporta que uma correção cobre um cenário quando, na prática, cobriu só parte dele. Não é malícia. É o mesmo erro que qualquer desenvolvedor apressado comete ao descrever o próprio trabalho de forma otimista demais, só que aqui pode soar articulado o bastante para nunca ser questionado. Recebi, mais de uma vez, um relatório dizendo que uma correção cobria dois caminhos de código quando, no commit real, cobria só um. Ninguém mentiu. A confiança no próprio trabalho simplesmente correu na frente da verificação.
Autonomia sem escopo. Pedi, mais de uma vez, que um agente fizesse uma investigação estritamente de leitura sobre algum ponto específico do código. Em pelo menos um caso, um agente com instrução parecida de “somente leitura” simplesmente implementou um backlog inteiro por conta própria, porque aquilo parecia a coisa certa a fazer. Autonomia sem escopo explícito não é produtividade. É risco não sinalizado. O problema nunca é a intenção do agente, é a ausência de uma cerca clara que diga onde a decisão dele termina e a minha começa.
Correção que não conecta. Um fix é implementado (um método criado, testado, aparentemente funcionando), mas o trecho de código que deveria usar esse método nunca é trocado. O bug antigo continua rodando, escondido atrás de um código novo que parece certo. Os testes passam, porque testam o método isolado, não o caminho real de produção. Em mais de um dos oito projetos, esse tipo de problema só apareceu numa rodada de auditoria seguinte, quando frentes de revisão independentes bateram no mesmo ponto, ao mesmo tempo, sem saber umas das outras.
Nenhum desses três problemas é hipotético. Todos já aconteceram, de verdade, em mais de um projeto real desta amostra. E por isso a resposta certa nunca foi “confiar menos na IA”. Foi entender por que a disciplina que os preveniria não nasce sozinha, e desenhar um processo que não depende de confiança cega, minha nem dela.
O relatório 2025 da DORA sobre desenvolvimento assistido por IA descreve algo parecido, e de um jeito que resume melhor do que eu conseguiria. Em tradução livre: “o papel primário da IA é o de um amplificador, que magnifica as forças e fraquezas já existentes de uma organização”, e “os maiores retornos sobre o investimento em IA vêm não das ferramentas em si, mas de um foco estratégico no sistema organizacional por trás delas”. Times fortes usam IA e ficam mais fortes ainda. Times com processo fraco descobrem, na prática, que a IA só acelera o próprio caos.
Por que a disciplina não nasce com o código: duas explicações que se completam
Diante desses três sintomas, a pergunta óbvia é: por que ninguém simplesmente começa com disciplina, desde o primeiro commit?
Duas ideias, vindas de lugares bem diferentes, ajudam a explicar por que isso quase nunca acontece, e por que não é falha de caráter de quem desenvolve.
A primeira vem do framework Cynefin, de Dave Snowden, usado para classificar problemas pela relação entre causa e efeito. Processo rígido (testes obrigatórios, revisão estruturada, registro formal de decisão) funciona bem, e vale o custo, exatamente quando causa e efeito já são conhecidos: você sabe o que vai dar errado se pular uma etapa, então a etapa vale a disciplina.
No início de um projeto, ou numa área nova de um projeto maduro, essa relação ainda não está estabelecida. Ninguém sabe ainda quais partes vão quebrar, sob que condições, com que frequência. Impor disciplina pesada nesse momento não é prudência, é aplicar uma régua antes de saber o que ela deveria medir.
A disciplina pesada só passa a valer a pena quando o projeto já revelou, na prática (e no código), onde o risco realmente mora. É exatamente isso que um evento de risco expõe.
A segunda vem de Nonaka e Takeuchi, e da forma como eles descrevem a conversão de conhecimento tácito em conhecimento explícito. O “por que fizemos assim” vive, no início, só na cabeça de quem tomou a decisão, e só sai de lá para um documento que outra pessoa consegue ler quando alguém é forçado a explicar aquilo em voz alta.
Isso raramente acontece no momento da decisão em si. Acontece quando alguém precisa justificar a decisão para outra pessoa: um revisor, um novo integrante do time, ou, cada vez mais, um agente de IA sem memória da conversa anterior perguntando “por que isso foi feito assim?”
A documentação de decisão, por essa lógica, sempre chega um pouco depois da decisão, nunca junto. Não é preguiça. É o formato real de como conhecimento tácito vira conhecimento escrito.
Juntas, essas duas ideias explicam o padrão inteiro: a disciplina pesada não nasce com o código porque, no início, o risco ainda não está mapeado (Cynefin) e a razão das decisões ainda está só na cabeça de quem as tomou (Nonaka & Takeuchi).
O que muda tudo é um evento (uma reescrita grande, uma versão importante se aproximando, uma revisão de documentação que expôs um bug real) que força as duas coisas a ficarem visíveis ao mesmo tempo. De repente sabe-se onde o risco mora, e alguém precisa explicar, por escrito, o que estava só na cabeça.
Onde isso se aplica: venho aplicando esse raciocínio em manutenção de bibliotecas, correção de bugs e preparação de release, trabalho onde causa e efeito, mesmo que descobertos tarde, acabam conhecidos. Não uso isso, e não indicaria usar, em decisões de produto genuinamente incertas, onde a relação causa-efeito não existe ainda para ser descoberta. É exatamente a zona onde Cynefin recomenda experimentação, não processo rígido.
Conclusão
Os três sintomas que abrem este texto (overclaiming, autonomia sem escopo, correção que não conecta) não são falhas de caráter, nem de ferramenta. São o resultado esperado de tentar impor disciplina antes do risco estar mapeado e antes de alguém ser forçado a explicar o “por quê” em voz alta.
A disciplina em rajada não é o segundo melhor cenário depois de “disciplina contínua desde o início”. É a forma real, e razoavelmente eficiente, como maturidade de processo se forma, com ou sem IA no meio.
O próximo passo desta série parte exatamente daqui: as três práticas que nunca esperam gatilho, descritas no artigo de abertura, já estão rodando desde o primeiro commit, mesmo nesse intervalo antes do evento de risco chegar. Ainda assim, um tipo específico de dívida se acumula em silêncio, exatamente porque nenhuma delas, sozinha, foi desenhada para pegá-la. O exemplo mais concreto que conheço é o código duplicado que um agente de IA cria enquanto parece produtivo, tema do próximo artigo desta série.
Tenham um excelente dia!
Eu sou Fernando Cerqueira e entrego estratégias digitais para os desafios do presente, com propostas de inovação para um futuro sustentável. Como arquiteto sênior, aproveito meus mais de 30 anos de experiência em arquitetura e desenvolvimento de software para projetar e implementar soluções baseadas em nuvem que ajudam os clientes a transformar seus negócios com tecnologia.
Este texto foi escrito com apoio do Claude Code, a partir da minha experiência, minhas decisões e revisão: o próprio processo que a série descreve.
Nesta série
- Metodologia de Desenvolvimento Assistido por IA Centrada na Decisão Humana
- Disciplina em rajada: por que o rigor não nasce junto com o código (este artigo)
- O código duplicado que a IA cria enquanto parece produtiva
- As três práticas que nunca esperam gatilho
- Quem autorizou essa atualização de dependência? Pode ter sido sua IA
- Os quatro eventos de risco e a auditoria multi-frente
- Seu agente de IA resolve a issue de verdade, ou só parece resolver?
- ADRs em lote, e a regra da visibilidade
- IA no time não reduz o bus factor do seu projeto — pode aumentar
- Calibrando a intensidade ao risco real
- O alinhamento entre produto e engenharia começa onde a decisão fica registrada
- Segurança psicológica também vale para o time formado por você e sua IA
- Releitura: o papel do humano, os sinais que funcionam, e onde a metodologia ainda é fraca
Referências citadas
- DORA, “2025 State of AI-assisted Software Development Report” (citações traduzidas livremente no texto): https://dora.dev/dora-report-2025/
- DORA, “ROI of AI-assisted Software Development” (2026): https://dora.dev/ai/roi/report/
- Anthropic, “How AI assistance impacts the formation of coding skills” (2026): https://www.anthropic.com/research/AI-assistance-coding-skills
- Dave Snowden, framework Cynefin: a base para entender por que processo rígido ajuda quando causa e efeito são conhecidos, e atrapalha quando não são.
- Nonaka & Takeuchi, sobre a conversão de conhecimento tácito em conhecimento explícito: a base para entender por que documentação de decisão sempre chega um pouco depois da decisão em si.
