Metodologia de Desenvolvimento Assistido por IA Centrada na Decisão Humana

A confiança na IA não começa no modelo, começa no processo.

Este é o primeiro de uma série sobre a metodologia que uso para continuar sendo, de fato, o responsável pelo que um agente de IA produz.

Por que resolvi compartilhar

Quantas vezes você já confiou no resultado de um agente de IA só porque ele soava certo demais para questionar? E quantas vezes, ao parar para checar de verdade, descobriu que ninguém, nem você, nem a IA, tinha de fato verificado nada?

Trabalho de forma intensiva com um agente de IA. Cheguei a uma maneira de conduzir esse trabalho que me deixa confortável para assinar embaixo do resultado, mesmo sabendo que código fluente não é sinônimo de código confiável.

A pergunta que me importa não é “a IA escreve código bom?” Quase sempre escreve algo plausível. A pergunta é outra: que processo garante que um erro seja pego, não importa quem o cometeu, humano ou agente?

Disclaimer: isto reflete minha prática pessoal, construída nos meus próprios projetos. Não reflete nenhuma equipe, nem posição de nenhuma organização à qual eu esteja afiliado.

Vale marcar uma fronteira antes de seguir. O vocabulário que uso daqui para frente (trade-off, auditoria, guardrail, registro de decisão) é o mesmo que aparece em discussões de governança corporativa de IA, mas as duas coisas não são a mesma coisa.

Esta série trata do processo de produzir código com um agente: a pergunta que ela responde é “o que saiu daqui está certo?”

Governança de IA, no sentido usado por frameworks como o NIST AI RMF ou a ISO/IEC 42001, responde a uma pergunta diferente: “o que este sistema faz com quem, e com que dado, depois de implantado?”

Por isso, esta série não cobre, e não deveria ser lida como cobrindo: viés e equidade de modelos implantados, explicabilidade para usuário final, conformidade regulatória (EU AI Act, LGPD), monitoramento contínuo em produção.

Há ainda dois pontos que ficam dentro do escopo que escolhi e que, mesmo assim, não trato nestes 13 artigos.

O primeiro é a segurança do próprio agente como superfície de ataque: prompt injection, exfiltração de segredos, escopo de permissões. O artigo Disciplina em rajada: por que o rigor não nasce junto com o código já mostra um caso em que uma instrução textual de “só leia, não implemente” não impediu o agente de implementar um backlog inteiro por conta própria. Isso é evidência de que instrução em linguagem natural é pedido, não controle técnico.

O segundo é a confidencialidade do que trafega para o provedor do modelo. Quem precisa de governança de IA para sistemas implantados vai precisar de bem mais do que estes 13 artigos oferecem.

Existe uma tentação forte, quando o agente é bom o suficiente, de deixar que ele decida cada vez mais sozinho: afinal, ele “geralmente acerta”. Resisti a essa tentação de propósito, porque o motivo é uma regra central:

O trade-off sempre volta para o humano.

A IA pode implementar, sugerir, até auditar seu próprio trabalho. Mas a decisão de aceitar um custo em nome de quem vai usar o resultado nunca é dela.

Essa regra não nasceu com esta série. Antes de escrever o primeiro destes 13 artigos, já defendia a mesma ideia num texto sobre onde realmente mora o valor de um modelo de IA: não na resposta, na pergunta e no contexto de quem pergunta, e no risco de aceitar respostas fluentes sem o devido questionamento só porque a tecnologia “parece entender tudo”. O que muda aqui é o escopo: não é mais sobre saber perguntar bem, é sobre o processo inteiro que garante que a resposta aceita foi de fato verificada, não só bem formulada.

Venho construindo isso observando oito projetos reais, testando o que funciona e o que não funciona: um processo que não considero fechado. O ponto mais importante que emergiu até agora é que a disciplina não é constante. Ela é acionada por eventos de risco.

O padrão que aprendi a respeitar: disciplina em rajada, não contínua

Em nenhum dos oito projetos a disciplina de verificação, registro de decisão e auditoria nasceu junto com o código. Todos passaram por uma fase informal: commits sem causa explicada, sem teste de regressão antes de corrigir um bug, sem nada documentado. Isso durou até um evento específico forçar a virada, como uma reescrita grande, o lançamento de uma versão importante, ou uma revisão de documentação que expôs um bug real. A partir daí, tudo aparece junto, com intensidade, num período curto.

Isso não é falta de disciplina. É o formato real de como ela surge. A questão não é “por que ninguém fez isso desde o primeiro commit”. A questão é antecipar os eventos que deveriam disparar rigor, em vez de reagir a eles depois que já aconteceram.

Isso também explica por que um agente de IA pode piorar as coisas em vez de melhorar: ele acelera a produção de código, mas não gera, sozinho, a verificação que deveria acompanhar essa velocidade.

Um relatório amplo da indústria sobre desenvolvimento assistido por IA (DORA, 2025) descreve isso bem: a IA funciona como amplificador. Times com boas práticas ficam melhores; times sem elas ficam mais instáveis, não mais produtivos. A velocidade que a IA dá precisa ser gasta em rigor, de propósito, ou vira dívida invisível que só aparece quando já é tarde.

Onde isso se aplica: venho aplicando isso em manutenção de bibliotecas, correção de bugs e preparação de release, trabalho onde causa e efeito são conhecidos. Não uso isso, e não indicaria usar, em decisões de produto genuinamente incertas, onde ninguém sabe de antemão o que vai funcionar.

O que deveria valer sempre, sem esperar nenhum evento

Três coisas são baratas o suficiente para nunca precisar de um gatilho:

Regras de trabalho fixas com o agente. Pensar antes de codificar: declarar suposições, apresentar alternativas quando o pedido admite mais de uma leitura razoável. Simplicidade em primeiro lugar: nada de abstração para código de uso único. Mudanças cirúrgicas: toda linha alterada remonta ao pedido que a motivou. Avaliar um padrão antes de adotá-lo, mesmo quando pedido por nome, e dizer o custo real dele naquele código específico.

Prova, não crença, para todo bug fix. Escreva um teste que reproduz o bug, confirme que ele falha pela razão certa (não por erro de digitação ou dependência quebrada), e só então implemente a correção, confirme que o teste passa e rode a suíte inteira. Isso é o padrão default, não uma regra sem exceção: pesquisa mostra que teste-antes-do-código tem efeito real, mas modesto, sobre qualidade de código em geral, fora desse uso específico de provar que um bug foi corrigido. O ponto não é seguir um dogma, é nunca aceitar “parece corrigido” no lugar de “está provado que corrigiu”.

Registrar decisões de arquitetura com um prazo curto, não em tempo real e não indefinidamente. Nenhum dos oito projetos registrou decisões no exato momento em que foram tomadas. Isso simplesmente não acontece na prática. O que venho usando é um teto: se uma decisão relevante ainda não foi escrita em uma semana (esse número muda com o risco do projeto, como explico mais adiante), isso já é atraso, não só falta de tempo.

O que os eventos de risco deveriam disparar

Quatro eventos, que venho observando de forma consistente, ativam disciplina mais pesada: uma reescrita de peso, a aproximação de uma versão importante, a véspera de um lançamento estável, e uma revisão de documentação que já encontrou um bug real. (Existe um quinto candidato, a própria chegada da configuração de um agente de IA a um projeto ser o gatilho, mas só vi isso acontecer uma vez até agora. Trate como hipótese a testar, não como regra.)

A recomendação prática: programe esses eventos como parte do próprio ciclo de trabalho, em vez de esperar que a pressão do calendário force a decisão. Uma reescrita grande deveria abrir a janela de rigor desde o primeiro commit, não só quando já está quase pronta.

Auditoria com várias frentes independentes

Quando um desses eventos acontece, a auditoria de qualidade não deveria ser uma revisão genérica. Deveria ser dividida em rodadas nomeadas por ângulo (estabilidade, resiliência, observabilidade, usabilidade, complexidade, desempenho, ajustando a lista ao tipo de sistema). Algumas regras tornam isso confiável de verdade:

• Cada frente roda sem compartilhar contexto com as outras.
• Achados conflitantes entre frentes nunca são resolvidos silenciosamente: são reportados como conflito, para decisão humana.
• Todo bug encontrado dispara uma busca pelo mesmo padrão em outros lugares do código, para fechar a classe do problema, não só o caso relatado.
• O critério de parada é combinado antes da última rodada: pare quando uma frente parar de encontrar coisa nova, não quando bater um número fixo de rodadas.
• Se o risco justificar, pelo menos uma frente deveria rodar num modelo de IA diferente das outras, porque frentes que usam o mesmo modelo, mesmo com instruções diferentes, tendem a ter os mesmos pontos cegos. Vale a ressalva de que isso compra menos independência do que parece: pesquisa recente mostra que mesmo painéis com várias famílias de modelos diferentes perdem boa parte da independência nominal entre si.
• Nunca aceite o relatório de uma rodada de auditoria como fato sem checar as afirmações mais fortes contra o registro bruto: o log de execução real, não o resumo que o agente escreveu sobre si mesmo. Um agente pode descrever seu próprio trabalho de forma otimista sem perceber. Fora de uma auditoria formal, uma alegação isolada do dia a dia (“corrigi isso”, “os testes passam”) merece o mesmo cuidado, em miniatura.
• Quando uma hipótese de bug plausível é investigada e não se confirma, isso não deveria ser descartado: vira um teste permanente, com um comentário explicando por que aquele medo específico não se concretiza. Um agente sem memória de sessões anteriores vai levantar a mesma suspeita de novo, e sem esse teste, alguém vai gastar tempo reinvestigando algo que já foi resolvido.

Consolidar decisões de arquitetura em lote

Durante uma janela de rigor, é normal e aceitável registrar várias decisões de uma vez, mesmo que retroativamente. Isso funciona como rede de segurança para o que o prazo curto contínuo não capturou a tempo.

As mesmas regras de sempre valem: uma decisão vigente nunca é reescrita, é substituída, apontando para a anterior. E uma decisão de não fazer algo (recusar uma funcionalidade, adiar uma correção mais profunda) merece o mesmo registro que uma decisão de fazer, porque é a mais fácil de ser desfeita sem querer por um agente que não tem esse contexto.

Um detalhe que vale a pena virar regra fixa: toda vez que uma decisão for “não agir automaticamente diante de uma falha” (não fazer retry, não reiniciar sozinho, não fazer failover automático), essa decisão precisa incluir como ela continua visível quando estiver em efeito.

Um caso real ilustra isso bem. Conto o desfecho completo no artigo ADRs em lote, e a regra da visibilidade: num desses sistemas, um componente crítico falhando uma única vez na inicialização bastou para que toda a telemetria seguinte parasse de existir silenciosamente.

Revisão de documentação como forma de achar bugs

Uma revisão que só checa se a documentação bate com o comportamento real do código deveria ser tratada como técnica de encontrar defeitos, com o mesmo peso que um teste, não como tarefa de redação. Em mais de um caso, foi exatamente esse tipo de revisão, e não uma decisão prévia de “ser mais rigoroso”, que revelou bugs reais e disparou o resto da disciplina. Vale rodar periodicamente, não só como preparação de release.

Ajustando a intensidade ao risco real

Nem todo projeto merece o mesmo nível de rigor. Três perguntas decidem quanto investir: o projeto tem estado compartilhado ou concorrência real (um bug de corrida é silencioso até virar incidente)? Quantos outros projetos dependem dele? Existe um lançamento público próximo?

Um projeto satélite, sem dependentes e sem release à vista, não justifica o mesmo nível de cerimônia que o projeto mais central e mais concorrente do portfólio. O prazo curto de registro de decisão (a semana sugerida acima) também deveria ser ajustado por esses mesmos três fatores.

Uma prática que costuma aparecer em discussões de governança de IA, mas que nenhum dos oito projetos que venho analisando chegou a demonstrar, é a capacidade de reverter rapidamente uma mudança já em produção: desligar uma feature flag, desfazer um deploy, reverter uma migração.

É boa prática de engenharia reconhecida em geral, mas sua viabilidade depende totalmente do tipo de sistema. Uma API sem estado é barata de tornar reversível; uma migração de banco já aplicada pode não ser. Vale avaliar caso a caso, não tratar como obrigação.

O papel do humano nunca é opcional

Duas coisas deveriam ser regra fixa, independente de tudo o mais: declarar por escrito, antes de qualquer código, quando e para quê o uso de IA é esperado ou vetado no projeto, sem deixar isso implícito; e nunca deixar a IA decidir sozinha um trade-off.

Especificamente, isto é sempre decisão humana: aceitar um custo em troca de um benefício; classificar algo como bug real versus comportamento intencional; escolher os ângulos de uma auditoria; decidir quando uma auditoria está de fato completa; aprovar a substituição de uma decisão de arquitetura já vigente; e aceitar o relatório de uma auditoria ou uma alegação da IA só depois de checar contra o artefato real.

Mais um ponto sobre replicar essa forma de trabalhar entre vários projetos: copiar a estrutura (o lote de ADRs, a suíte de testes) não garante copiar o julgamento por trás dela. Em pelo menos um caso, a estrutura foi copiada com sucesso entre dois projetos irmãos, mas a regra de “isso é atualização de rotina ou substituição de decisão” ainda foi aplicada errado uma vez, e só corrigida depois, numa auditoria. Ao levar uma prática de um projeto para outro, explique o critério de julgamento, não só o formato.

Sinais de que está funcionando, e erros que se repetem

Alguns indicadores que venho acompanhando: que fração das correções de bug tem prova de que o teste falhava antes e passa depois; quantas hipóteses de bug refutadas viraram teste permanente (sinal positivo, não perda de tempo); se há decisões de arquitetura pendentes de registro além do prazo combinado; há quanto tempo não se roda uma auditoria, relativo à proximidade do próximo evento de risco; e se existe uma revisão de documentação recente que não foi motivada por um release.

Os erros mais comuns, na prática: deixar que a conversa com o agente seja a única memória de uma decisão importante; aplicar a regra de registro de decisão errado sem nunca auditar se está sendo seguida direito; aceitar a saída do agente por conversa, sem teste nem auditoria por trás; tratar documentação como algo que se escreve uma vez e esquece; aplicar o mesmo nível de rigor a um projeto de baixo risco e a um projeto central; e aceitar sem checagem o próprio relatório do agente sobre o trabalho que ele fez.

De onde tirei isso, e onde ainda é fraco

A base empírica são oito projetos meus: bibliotecas de infraestrutura, uma ferramenta de gestão de decisões arquiteturais, bibliotecas de interface, e dois conjuntos de instrução para agente de IA. Nenhum deles teve um observador externo decidindo os trade-offs. Sou eu, nos oito, o único ponto de vista.

As maiores limitações honestas: tudo isso vem da minha prática sozinho nesses oito projetos, sem ninguém diferente de mim decidindo os trade-offs, o que não quer dizer que essa situação nunca aconteça fora deles, só que nenhum desses outros casos entra nesta série como evidência: cito aqui só a opinião já amadurecida por essa experiência, nunca o caso específico de um cliente.

Vale uma nota específica sobre pesquisa de IA: ela envelhece rápido.

Um estudo bastante citado do METR sobre desenvolvedores ficarem mais lentos usando IA foi medido com ferramentas de início de 2025: queda de 19% na velocidade. A mesma equipe, ao tentar repetir o experimento no início de 2026, declarou o próprio sinal não confiável. A estimativa medida para o grupo original continuou negativa, e a taxa de recusa de quem não queria mais trabalhar sem IA introduziu um viés de seleção sério o suficiente para os próprios autores desistirem de tratar aquele número como medição válida.

A leitura de que hoje existe ganho vem de conversas com os participantes do estudo, não do experimento em si. Os mesmos autores rotulam essa leitura como “evidência muito fraca” para o tamanho real do efeito. O princípio por trás do achado original (velocidade de IA sem verificação vira risco) continua de pé, mas nenhum desses números deveria ser tratado como definitivo.

Meses depois, o próprio METR publicou uma terceira medição, dessa vez por pesquisa autorreportada, não experimento controlado: ganhos entre 1,3x e 3x, segundo os próprios participantes, com os mesmos autores alertando, no mesmo relatório, que “resultado de pesquisa autorreportada não é necessariamente ancorado na realidade”.

Duas tentativas de medição controlada que o próprio grupo de pesquisa não confia mais em comparar, mais uma terceira autorreportada com sua própria ressalva de confiabilidade, em pouco mais de um ano. Esse é o tamanho real da instabilidade de que estou falando.

Conclusão

Volto à pergunta que abriu este texto: que processo garante que um erro seja pego, não importa quem o cometeu? A resposta não está na IA. Está na estrutura que você constrói ao redor dela. Sem essa estrutura, a velocidade que a IA entrega não é ganho, é dívida sendo acumulada em silêncio, esperando o evento de risco que vai cobrar a conta.

O que vem a seguir nesta série não é uma lista solta de tópicos. Cada artigo parte do anterior, com uma lógica própria.

Primeiro, entendemos por que essa disciplina nasce em rajada e não contínua. Ao lado dessa ideia, o que se acumula em silêncio nesse intervalo, mesmo com as práticas mais baratas já rodando: o código duplicado que a IA cria enquanto parece produtiva.

Depois, as três práticas que nunca esperam gatilho ganham um artigo só delas, com um caso aplicado ao lado, onde o guardrail deixa de ser princípio abstrato e vira decisão concreta: uma atualização de dependência que ninguém percebeu ter sido uma decisão.

Entramos então na maquinaria mais pesada: os quatro eventos que deveriam disparar rigor e a auditoria com frentes independentes, ao lado do caso mais direto de todos, um agente cuja taxa de acerto ninguém media de verdade.

Os ADRs consolidados em lote vêm na sequência, com o bus factor como prova concreta do que a ausência desse registro custa. Calibramos então a intensidade ao risco de cada projeto, lado a lado com o alinhamento entre produto e engenharia: o mesmo problema de onde mora a verdade sobre uma decisão, só que bem mais antigo que qualquer IA.

E fechamos revisitando, com mais honestidade do que na abertura, o papel do humano, os sinais de que está funcionando e os limites do que ainda não sei, ao lado de uma última reflexão sobre segurança psicológica, e o que significa um colaborador que discorda com dados e se compromete de verdade depois.

Se a pergunta que abriu este texto ainda faz sentido para você, o resto da série é sobre como respondê-la na prática, um pedaço de cada vez.

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

1. Metodologia de Desenvolvimento Assistido por IA Centrada na Decisão Humana (este artigo)
2. Disciplina em rajada: por que o rigor não nasce junto com o código
3. O código duplicado que a IA cria enquanto parece produtiva
4. As três práticas que nunca esperam gatilho
5. Quem autorizou essa atualização de dependência? Pode ter sido sua IA
6. Os quatro eventos de risco e a auditoria multi-frente
7. Seu agente de IA resolve a issue de verdade, ou só parece resolver?
8. ADRs em lote, e a regra da visibilidade
9. IA no time não reduz o bus factor do seu projeto — pode aumentar
10. Calibrando a intensidade ao risco real
11. O alinhamento entre produto e engenharia começa onde a decisão fica registrada
12. Segurança psicológica também vale para o time formado por você e sua IA
13. Releitura: o papel do humano, os sinais que funcionam, e onde a metodologia ainda é fraca

Referências citadas

• Kent Beck, Test-Driven Development: By Example (Addison-Wesley, 2002): ISBN 978-0321146533 — a origem do ciclo vermelho-verde-refatorar.
• Michael Nygard, “Documenting Architecture Decisions” (2011): https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions — o formato original de ADR.
• Yahya Rafique & Vojislav Mišić, “The Effects of Test-Driven Development on External Quality and Productivity: A Meta-Analysis”, IEEE Transactions on Software Engineering, vol. 39, n. 6 (2013): meta-análise mostrando efeito real, mas modesto, de TDD.
• David Heinemeier Hansson, “TDD is dead. Long live testing.” (2014): https://dhh.dk/2014/tdd-is-dead-long-live-testing.html — a crítica mais conhecida ao dogma de teste-primeiro sempre.
• DORA, “State of AI-assisted Software Development 2025”: https://dora.dev/dora-report-2025/ — a pesquisa por trás da ideia de “IA como amplificador”.
  Anthropic, “How AI assistance impacts the formation of coding skills” (2026): https://www.anthropic.com/research/AI-assistance-coding-skills — estudo controlado sobre uso de IA sem estrutura ao redor prejudicando aprendizado; testou um assistente de chat simples, não um fluxo de trabalho com verificação como o descrito aqui.
• METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” (julho de 2025): https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/, “We are Changing our Developer Productivity Experiment Design” (fevereiro de 2026): https://metr.org/blog/2026-02-24-uplift-update/, e “Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity” (maio de 2026): https://metr.org/blog/2026-05-11-ai-usage-survey/ — a segunda publicação não é uma segunda medição controlada, é o próprio grupo declarando a primeira réplica não confiável; a terceira é autorreportada, com ressalva própria de confiabilidade.
• “Nine Judges, Two Effective Votes” (Apple Machine Learning Research, 2026): https://arxiv.org/abs/2605.29800 — mesmo painéis com várias famílias de modelos diferentes perdem boa parte da independência nominal entre si.
• Dave Snowden, framework Cynefin: a ideia de que processo rígido funciona bem quando causa e efeito são conhecidos, e atrapalha quando não são.
  Nonaka & Takeuchi, sobre como conhecimento tácito vira conhecimento escrito: a base para entender por que documentação de decisão sempre chega um pouco depois da decisão em si, nunca junto.
• Fernando Cerqueira, “O valor está na resposta… ou começa na pergunta?” (enterprisearchitecture.com.br): https://enterprisearchitecture.com.br/ia-o-valor-esta-na-pergunta-ou-na-resposta/