Voltar

O arquiteto que ainda escreve código deveria, na maior parte do tempo, estar lendo código

·23 min de leitura

Na edição de julho/agosto de 2003 da IEEE Software, Martin Fowler descreveu o arquiteto que admirava por meio de um único dia de trabalho: de manhã, o arquiteto programa junto com um desenvolvedor, tentando extrair o que há de comum no código de controle de concorrência, e à tarde participa de uma sessão de requisitos, em que ajuda o pessoal de requisitos a entender as consequências técnicas de suas ideias, como o custo de desenvolvimento. A mesma coluna traz uma regra prática que soa como o conselho oposto. O valor de um arquiteto, escreveu Fowler, é inversamente proporcional ao número de decisões que ele toma, porque elevar a capacidade do time rende muito mais do que ser o único decisor e virar um gargalo arquitetural.

Lidas depressa, essas passagens parecem dois campos: o arquiteto que continua programando e o arquiteto que sai da frente. Eu acho que elas descrevem um só trabalho visto de dois lados, e que esse trabalho mudou de um jeito específico desde que gerar código ficou barato. Minha tese é que o contato principal do arquiteto com o código deve ser, agora, a leitura, em particular a leitura dos diffs que outras pessoas e outras máquinas produzem, e que a escrita deve se limitar ao código que será jogado fora ou ao código pequeno, fora do caminho crítico. Um arquiteto que não lê diffs trabalha com uma imagem velha do sistema, e o que escreve o código de funcionalidades do time vira um ponto único de falha.

Isso é uma afirmação sobre ênfase, e pode estar errada. A evidência sobre código assistido por IA é mista e muitas vezes vem de fornecedores, e a objeção mais forte, a de que um arquiteto dentro dos diffs corrói a propriedade do time sobre o sistema, merece uma resposta de verdade, que vem mais adiante. Antes disso, o problema que o conselho antigo resolvia.

As duas advertências de Fowler descrevem um único trabalho

A coluna de Fowler se apoia numa definição de Ralph Johnson, que havia defendido na lista de discussão de Extreme Programming que arquitetura é o entendimento compartilhado que os desenvolvedores experientes têm do sistema, e que um componente é significativo porque esses desenvolvedores dizem que é. Nessa definição, arquitetura é um fato social que mora ao mesmo tempo na cabeça das pessoas e no código. Se os dois se afastam, suspeito que o arquiteto seja quem tem mais chance de guardar a versão desatualizada, porque é a pessoa menos obrigada a executar o código.

A coluna nomeia dois tipos. O Architectus Reloadus toma sozinho as decisões importantes, com a teoria de que uma única mente mantém o desenho coerente e, talvez, porque o time pode não ser habilidoso o bastante. O Architectus Oryzus se mantém a par do que acontece no projeto, ataca os problemas importantes antes que fiquem graves e trata a mentoria como a atividade mais importante. Fowler conta que colegas num retiro da ThoughtWorks concordaram quanto à natureza desse papel, mas não encontravam um nome para ele, e que um deles, Mike Two, propôs guia, como no montanhismo: um integrante experiente do time que ensina os outros a se virarem sozinhos e continua presente nos trechos realmente difíceis.

Essa é a primeira advertência, e ela trata da verdade do terreno. Um diagrama no wiki registra o que alguém pretendia em algum momento. Só o código mostra o que o sistema faz hoje: qual módulo de fato chama qual, onde mora o laço de retentativas, se o serviço "somente leitura" passou a escrever. No meu julgamento, o arquiteto que para de escrever código costuma parar de lê-lo também, e o entendimento compartilhado de que falava Johnson encolhe até virar uma crença privada de uma pessoa só.

A segunda advertência trata de vazão. Se toda escolha de desenho precisa passar por uma cabeça, a velocidade do time fica limitada pela agenda dessa cabeça. Escrever código de funcionalidade piora o quadro, já que o arquiteto é puxado para reuniões e não consegue dar a uma tarefa a atenção contínua que ela pede, e o código chega atrasado ou com pressa; essa parte é uma observação minha sobre como o papel costuma ser alocado, não uma afirmação de Fowler. A regra inversa dele diz onde está o ganho: elevar o nível do time rende mais do que ser o único a decidir.

Juntas, as advertências pedem duas coisas: contato com o código e distância do caminho crítico. Escrever código de funcionalidade garante o primeiro e quebra o segundo, enquanto a leitura garante o primeiro sem tocar no segundo.

Escreva código só para responder a uma pergunta que o time ainda não consegue responder

Há código que o arquiteto ainda deve escrever. Esse código se divide em poucos tipos reconhecíveis, e o que eles têm em comum é que o time não depende de ele ficar pronto numa data determinada.

Começa pelo experimento descartável. Numa entrevista de 2003 a Bill Venners, para a Artima, Andy Hunt e Dave Thomas separaram protótipos de balas traçantes. Um protótipo existe para responder a uma pergunta estreita sobre uma interface, um algoritmo ou o desempenho, e foi feito para ser descartado. O exemplo de Thomas é hipotético: os requisitos pedem 10.000 transações de banco de dados por hora, enquanto a maior vazão conhecida para aquele banco é de 5.000, e a forma de descobrir a verdade é montar às pressas um script rústico. Hunt acrescenta que esse script pode nem encostar no código da aplicação. Thomas diz que protótipos são projetados para serem jogados fora e compara um deles a uma cidade de cenário de faroeste: só fachada, nada atrás. Na entrevista, Venners pergunta se a gerência poderia tentar transformar um protótipo em bala traçante, e essa é a tentação a vigiar. O arquiteto que escreve um spike deve marcá-lo como descartável no nome do arquivo, apagá-lo na data registrada na mensagem do commit.

A segunda é a bala traçante. Na mesma entrevista, os autores descrevem um esqueleto fino que atravessa o sistema inteiro, da interface com o usuário passando pela lógica de negócio até o banco de dados, que os usuários podem ver e que cresce um caso de uso por vez, e o feedback antecipado barateia as correções de rumo. Diferente do protótipo, esse esqueleto é aquilo sobre o qual o sistema é construído. É a primeira versão do sistema real, estreita mas completa, e dá ao time uma estrutura arquitetural onde pendurar código. É o código que o arquiteto está mais bem posicionado para escrever, porque o objetivo do exercício é testar a estrutura: se as camadas conseguem conversar, se o pipeline de deploy funciona, se o log traz o suficiente para diagnosticar uma falha. Quando o esqueleto fica pronto, o arquiteto o entrega e se afasta, e o código passa a pertencer ao time.

Vem então a implementação de referência, um exemplo completo de um padrão, como a forma de um handler validar a entrada e chamar a camada de domínio, pequeno o bastante para ser copiado. Por último, o registro de decisão. Michael Nygard propôs em 2011 que cada decisão arquiteturalmente significativa fosse descrita num arquivo curto, de uma ou duas páginas, mantido no repositório, com contexto, decisão, status e consequências, com o argumento de que documentos grandes nunca são mantidos em dia. No Google, escreveu Malte Ubl em 2020, o design doc é o lugar de registrar os trade-offs, e ele observa que o custo de escrever e revisar um pode não combinar com prototipação e iteração rápida. Cada um desses artefatos custa pouco perto de uma decisão que ninguém registrou.

Nenhum deles põe o arquiteto no caminho crítico do cronograma. O spike é jogado fora, a bala traçante é entregue depois das primeiras semanas, a implementação de referência tem algumas centenas de linhas e o registro cabe numa página. Meu teste para a escrita de qualquer arquiteto é perguntar se a data da próxima entrega do time mudaria caso o arquiteto ficasse uma semana doente.

A revisão pega coisas pequenas, e por isso a estrutura escapa

Se a leitura é a atividade principal, uma objeção óbvia é que a revisão de código já existe. Existe, e a melhor evidência sobre o que ela faz vem de antes dos assistentes de IA.

Alberto Bacchelli e Christian Bird estudaram a revisão de código na Microsoft: observaram 17 desenvolvedores, entrevistaram-nos, classificaram 570 comentários de threads de revisão e aplicaram questionários a 165 gerentes e 873 programadores. Encontrar defeitos era a principal motivação declarada, a primeira para 44% dos programadores que responderam. Os comentários contavam outra história. Dos 570, 165 (29%) eram sobre melhoria do código, como boas práticas, remoção de código sem uso ou legibilidade, e só 78 (14%) eram sobre defeitos, a quarta categoria mais frequente entre nove. Desses 78 comentários de defeito, 65 tratavam de erros de lógica, como uma expressão errada num if, 6 tratavam de problemas de alto nível e 5 de segurança. Os autores também relatam que os revisores davam valor à transferência de conhecimento e à consciência do time, e que entender a mudança é a parte central de revisar. Um desenvolvedor sênior comentou que já tinha visto revisões em que alguém comentava a formatação e deixava passar um problema de segurança ou de modelo de dados.

O estudo cobre uma única empresa, com pesquisas feitas no primeiro semestre de 2012, então não é lei. Os próprios autores observam que os comentários de defeito tratam em sua maioria de preocupações pequenas e superficiais, enquanto programadores e gerentes esperavam observações sobre o desenho. Infiro dos seis comentários de defeito de alto nível que os problemas estruturais, como uma dependência apontando no sentido errado ou uma segunda implementação de algo que a base de código já tem, estão entre os que menos provocam um comentário. O revisor vê um diff, e a arquitetura é em boa parte o que fica fora do diff. Alguém precisa carregar a imagem do que não aparece, e uma revisão baseada em diff não atribui essa tarefa a ninguém.

A revisão também pressupõe que o autor entende a mudança. Uma pessoa que escreve uma alteração de 150 linhas costuma saber por que cada linha está ali e consegue explicá-la. Quando um assistente produz a mudança e o desenvolvedor a aceita depois de uma olhada rápida, essa premissa cai, e o revisor pode ser a primeira pessoa a ler o código com atenção.

O que a evidência sobre código gerado por IA sustenta, e o que não sustenta

A evidência aqui é escassa e irregular, e os números mais citados vêm de fontes que têm algo a vender.

Um estudo controlado é o de Neil Perry, Megha Srivastava, Deepak Kumar e Dan Boneh, apresentado na conferência ACM CCS em 2023. Os participantes resolveram tarefas de programação ligadas a segurança com ou sem um assistente baseado no codex-davinci-002 da OpenAI. Depois das exclusões, restaram 47 participantes, 33 com o assistente e 14 sem, em sua maioria estudantes universitários. Na tarefa de SQL, 36% do grupo com assistente escreveu código vulnerável a injeção, contra 7% dos controles. Na tarefa de assinatura, 3% do grupo com assistente produziu uma solução segura, contra 21%. Uma regressão logística que reúne as cinco questões, na Tabela 3 do artigo, dá p de 0,056 para o grupo com assistente, logo acima do limiar usual, e os autores listam a amostra pequena e com muitos estudantes entre os limites. Os participantes com o assistente também tinham mais chance de acreditar que seu código era seguro. Com um modelo antigo e em ambiente de laboratório, o resultado é um motivo para conferir, não uma medida das ferramentas de hoje.

O relatório de 2024 do programa DORA, extraído de uma grande pesquisa anual com profissionais de tecnologia, estimou que a adoção de IA vinha acompanhada de uma queda de 1,5% na vazão de entrega e de uma redução de 7,2% na estabilidade da entrega. Em seu anúncio, o Google Cloud formula esses números como associados à adoção, e não como efeitos comprovados, e o texto da RedMonk cita o relatório para associar os dois valores a um aumento de 25% na adoção. O relatório de 2025, com quase 5.000 respondentes, diz que, ao contrário do ano anterior, a adoção mostra uma relação positiva com a vazão de entrega, enquanto a relação com a estabilidade continua negativa. Seu resumo descreve a IA como um amplificador do que o time já tem. Entre os dois anos, o sinal da vazão se inverteu, enquanto o da estabilidade não.

O estudo da METR de 2025 com desenvolvedores experientes pôs 16 deles para resolver 246 issues reais em repositórios que conheciam bem, permitindo ou proibindo IA de forma aleatória. Com IA permitida, levaram 19% mais tempo, embora depois acreditassem que ela os tinha deixado cerca de 20% mais rápidos. A METR hoje marca esse resultado como desatualizado. Em fevereiro de 2026 ela divulgou um estudo de acompanhamento com 57 desenvolvedores e mais de 800 tarefas, e disse que os dados davam um sinal pouco confiável do efeito atual, principalmente porque muitos desenvolvedores se recusavam a participar se isso significasse trabalhar sem IA. A METR achava que os desenvolvedores provavelmente estavam mais acelerados àquela altura, mas chamou seus dados de evidência muito fraca sobre o tamanho da mudança. A relevância para arquitetos é indireta, e a inferência é minha: quem usa essas ferramentas julga mal os próprios resultados, na velocidade num estudo e na segurança no outro, e uma revisão que depende da confiança do autor herda a mesma fraqueza.

Os fornecedores acrescentam mais. A GitClear analisou 211 milhões de linhas alteradas entre 2020 e 2024 e relata que a parcela de linhas clonadas subiu de 8,3% para 12,3% entre 2021 e 2024, enquanto a parcela de linhas movidas, seu indicador de refatoração, caiu de 25% para menos de 10%. Ela vende análise de código, e não vi no relatório um desenho que isole os assistentes como causa da tendência. Já a CodeRabbit comparou 320 pull requests coescritos por IA com 150 só de humanos e contou 10,83 problemas por pull request contra 6,45. Ela rotulou a autoria a partir de sinais no próprio pull request e presumiu que o resto era humano, e vende um produto de revisão com IA.

A Veracode relata falhas de segurança de risco em 45% dos testes, com mais de 100 modelos em quatro linguagens, e também vende ferramentas de segurança. A pesquisa de janeiro de 2026 da Sonar, com mais de 1.100 desenvolvedores, constatou que 96% não confiavam plenamente que o código gerado por IA estivesse correto, enquanto 48% diziam sempre conferi-lo antes de fazer o commit. Na pesquisa do Stack Overflow de 2025, 46% dos que responderam à pergunta sobre confiança desconfiavam da precisão das ferramentas de IA, e 66% dos que responderam à pergunta sobre frustrações apontaram o resultado quase certo, mas não de todo.

Em conjunto, esses resultados concordam quanto a uma lacuna de confiança e a um atraso de verificação, e divergem sobre se o código é de fato pior. A evidência direta sobre arquitetura é escassa. Um piloto de dezembro de 2025 no arXiv, de Tyler Slater, deu a três modelos (GPT-5.1, Claude 4.5 Sonnet e Llama 3 8B) uma única tarefa de microsserviço sob uma restrição de arquitetura hexagonal e relatou, no resumo, 0% de violações para o GPT-5.1 e 80% para o Llama 3. Uma tarefa é uma anedota. Um estudo observacional de junho de 2026, de Oliver Larsen e Mahyar Moghaddam, comparou 74 repositórios Java que haviam adotado ferramentas agênticas com 77 controles pareados, com 1.811 instantâneos mensais analisados com uma ferramenta de recuperação de arquitetura. O total de architectural smells quase não se mexeu (+1,1%, p de 0,82), enquanto as linhas de código cresceram 12,8% e a densidade de smells caiu 6,7%, o que os autores chamam de efeito do denominador, e não de melhora. É o que mais se aproxima de uma medição no nível do repositório que encontrei. Ela diz que o crescimento não veio com mais smells detectados naquela amostra, e não consegue dizer se as mudanças individuais dos agentes respeitam as regras do próprio time, porque os detectores de smells não conhecem essas regras. O estudo do MSR 2026 sobre pull requests de agentes, de Ehsani e colegas, que cobre cerca de 33.000 pull requests de cinco agentes de código no conjunto de dados AIDev-pop, mede se os pull requests são integrados e por que são rejeitados, e não se respeitam uma arquitetura. Assim, a afirmação de que a IA corrói a estrutura é plausível e pouco testada, com um piloto apontando para erosão num modelo pequeno e um estudo observacional que não mostra aumento na contagem de smells. A afirmação de que a leitura é o gargalo tem mais respaldo, porque a pesquisa da Sonar e o estudo de revisão da Microsoft mostram uma distância entre a checagem que as pessoas dizem importar e a checagem que fazem.

Ninguém consegue ler todas as linhas, então a leitura do arquiteto precisa seguir o risco

Uma conta inventada mostra por que a leitura precisa ser seletiva. Suponha um time de 8 engenheiros em que cada um integra 2 pull requests por dia, com média de 120 linhas alteradas, o que dá 1.920 linhas por dia. Com assistentes, o time poderia passar a 3 pull requests de 200 linhas por pessoa, ou 4.800 linhas por dia. Admite-se que a leitura cuidadosa, a que confere estrutura e não sintaxe, avança a 200 linhas por hora. Esses números são inventados para ilustrar. Ler tudo tomaria 9,6 horas por dia no primeiro caso e 24 no segundo. O arquiteto não consegue ler tudo, e no segundo caso ninguém consegue.

A leitura, portanto, precisa ser dirigida, e o risco é o filtro sensato. No segundo caso, se um décimo das linhas toca fronteiras, a parte do arquiteto é de 480 linhas, ou 2,4 horas por dia. É muito, mas é possível, e na prática ele dividiria isso com engenheiros seniores. As fronteiras que merecem a atenção são poucas, e esta é a lista por onde eu começaria.

  1. Novas dependências entre módulos ou serviços, e o sentido de cada uma.
  2. Mudanças em interfaces públicas, esquemas de eventos e migrações de banco de dados.
  3. Qualquer coisa que toque autenticação, autorização ou o tratamento de dados pessoais.
  4. Novas abstrações, helpers ou utilitários, conferidos contra o que a base de código já tem.
  5. Tratamento de erros e comportamento de retentativa nas bordas do sistema.
  6. Configuração, feature flags e definições de infraestrutura que mudam o comportamento do sistema em produção.

Boa parte do resto pode ser automatizada, e deve ser. Uma regra como "o pacote de domínio não pode importar o pacote de infraestrutura" é um teste, e não assunto para discussão, e um registro de decisão que acompanha a regra em forma executável dura mais do que um que a enuncia só em prosa. A leitura do arquiteto então se concentra no que nenhuma regra ainda cobre, e cada vez que um humano encontra uma violação que nenhuma checagem pegou, o desdobramento é escrever a checagem. Aqui a escrita de código volta ao trabalho do arquiteto, na forma de pequenas ferramentas que codificam decisões, e um assistente é útil nessa parte: ele pode rascunhar uma primeira versão de uma checagem de dependências, que uma pessoa então verifica contra violações conhecidas.

Uma segunda tarefa de leitura importa tanto quanto: ler o código gerado em busca do que falta. Um assistente pode produzir um handler plausível que funciona e ainda assim duplica um helper de paginação que a base de código já tem, se ninguém o apontou para lá. A pergunta a fazer a um diff é se ele corresponde à estrutura que o time pretendia, o que exige conhecer a estrutura pretendida e a real. As duas vêm da leitura.

Um arquiteto dentro dos diffs pode tirar a propriedade do time

A objeção mais forte diz que tudo isso é razão para manter os arquitetos fora do código. Os times são donos do que decidem e constroem. Um arquiteto que lê toda mudança de fronteira vira um revisor de última instância, os desenvolvedores passam a escrever para a aprovação dele, e o julgamento do time enfraquece, que é o padrão contra o qual a regra inversa de Fowler alerta. Há também um lado prático. Engenheiros seniores que encontram o arquiteto nos seus pull requests podem concluir, com razão, que o arquiteto não confia neles, e alguns dos melhores vão embora.

A objeção vale para um desenho da prática e falha para outro. Vale se ler significar aprovar. Se uma mudança não pode ser integrada até o arquiteto olhá-la, ele volta ao caminho crítico, e o gargalo simplesmente migrou das reuniões de desenho para a fila de pull requests. Os achados de Bacchelli e Bird apontam na mesma direção, já que o artigo relata a transferência de conhecimento e a consciência do time entre os resultados da revisão, ao lado da captura de defeitos. Uma prática de leitura que preserva esses benefícios tem outra cara: roda depois da integração ou em paralelo, comenta às claras e faz perguntas antes de emitir vereditos. Quando o arquiteto encontra uma mudança de fronteira que conflita com um registro de decisão, o primeiro movimento é uma pergunta ao autor, e o segundo é uma conversa sobre se o registro está desatualizado, porque às vezes o autor achou algo que o arquiteto não viu. Nesse caso, o registro muda. A propriedade continua com o time, já que o time pode derrubar o registro, e o trabalho do arquiteto é fazer com que isso aconteça de forma visível e deliberada.

A premissa da objeção, a de que ficar fora do código protege a propriedade, é onde acho que ela falha. Um time pode ser dono de um sistema que não entende por completo, mas então a propriedade significa responsabilidade sem informação, e é num incidente que isso costuma aparecer. Suponha que o time tomou uma decisão três meses atrás e que, desde então, uma mudança gerada a desfez em silêncio. Só quem leu essa mudança pode perceber; do contrário, o time descobre pela produção.

Resta uma preocupação justa de escala. Passado certo tamanho, uma pessoa não consegue manter a imagem inteira, e a função de arquiteto precisa ser distribuída entre várias pessoas, com a leitura em rodízio entre engenheiros seniores. Para a propriedade isso é um bom resultado, porque a prática foi absorvida pelo time.

Um mês de leitura registrada mostraria se isso vale a pena

A afirmação pode ser testada a baixo custo, e o teste cabe a quem ocupa o papel de arquiteto. Durante quatro semanas, leia toda mudança que toque as seis categorias acima, até um dia depois de integrada. Para cada uma, anote num arquivo simples se a mudança correspondeu à estrutura pretendida, se contradisse um registro de decisão e se o achado virou uma pergunta, uma nova checagem ou uma alteração no registro. No fim, conte. Se o arquivo não mostrar nenhuma divergência, ou o time é disciplinado a ponto de a leitura acrescentar pouco, ou a amostragem está errada, e o próximo passo é ampliar as categorias antes de abandonar a prática. Se mostrar várias, as divergências por cem mudanças revisadas são a primeira evidência local do que a leitura vale para esse time, algo que nenhum dos estudos acima consegue fornecer. Não sei dizer de antemão qual resultado é o mais provável.

Fontes

  1. Fowler, M. (2003). Who Needs an Architect? IEEE Software, julho/agosto de 2003 (coluna Design). https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
  2. Hunt, A., Thomas, D. (2003). Tracer Bullets and Prototypes. Entrevista a Bill Venners, Artima Developer, 21 de abril de 2003. https://www.artima.com/articles/tracer-bullets-and-prototypes
  3. Nygard, M. (2011). Documenting Architecture Decisions. Blog da Cognitect, 15 de novembro de 2011. https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions
  4. Ubl, M. (2020). Design Docs at Google. Industrial Empathy, 6 de julho de 2020. https://www.industrialempathy.com/posts/design-docs-at-google/
  5. Bacchelli, A., Bird, C. (2013). Expectations, Outcomes, and Challenges of Modern Code Review. Proceedings of the 35th International Conference on Software Engineering (ICSE 2013), pp. 712-721. https://2013.icse-conferences.org/content/expectations-outcomes-and-challenges-modern-code-review.html
  6. Perry, N., Srivastava, M., Kumar, D., Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS '23), Copenhague; DOI 10.1145/3576915.3623157; arXiv:2211.03622. https://arxiv.org/abs/2211.03622
  7. Google Cloud (22 de outubro de 2024). Announcing the 2024 DORA report. https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report ; Stephens, R. (26 de novembro de 2024), texto da RedMonk que cita o relatório para o aumento de 25% (de segunda mão), https://redmonk.com/rstephens/2024/11/26/dora2024/
  8. Google Cloud (23 de setembro de 2025). Announcing the 2025 DORA report (a formulação sobre vazão, estabilidade e amplificação foi lida aqui, e não no PDF completo). https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report ; PDF do relatório: https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf
  9. METR (10 de julho de 2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ ; METR (24 de fevereiro de 2026). We are Changing our Developer Productivity Experiment Design. https://metr.org/blog/2026-02-24-uplift-update/
  10. GitClear (2025). AI Copilot Code Quality research, 211 milhões de linhas alteradas, 2020 a 2024 (análise de fornecedor). https://www.gitclear.com/ai_assistant_code_quality_2025_research
  11. CodeRabbit (2025). State of AI vs Human Code Generation report, 470 pull requests (análise de fornecedor). https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
  12. Veracode (2025). GenAI Code Security Report (análise de fornecedor). https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/
  13. Sonar (8 de janeiro de 2026). State of Code developer survey, comunicado à imprensa sobre a lacuna de verificação (pesquisa de fornecedor). https://www.sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/
  14. Stack Overflow (2025). Developer Survey 2025, seção de IA. https://survey.stackoverflow.co/2025/ai
  15. Slater, T. (2025). Quantitative Analysis of Technical Debt and Pattern Violation in Large Language Model Architectures. arXiv:2512.04273 (piloto de uma única tarefa com três modelos; só a página do resumo foi lida). https://arxiv.org/abs/2512.04273
  16. Ehsani, R., Pathak, S., Rawal, S., Al Mujahid, A., Imran, M. M., Chatterjee, P. (2026). Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub. MSR '26, com o conjunto de dados AIDev-pop; arXiv:2601.15195 (só o resumo e o sumário em HTML foram lidos). https://arxiv.org/abs/2601.15195
  17. Larsen, O. A., Moghaddam, M. T. (2026). Mining Architectural Quality Under Agentic AI Adoption: A Causal Study of Java Repositories. SEAA 2026; arXiv:2606.13298 (só a página do resumo foi lida). https://arxiv.org/abs/2606.13298
  18. Aritmética ilustrativa de revisão: 8 engenheiros, 2 ou 3 pull requests por dia de 120 ou 200 linhas alteradas, leitura a 200 linhas por hora, 10% das linhas em fronteiras. Todos os números foram inventados para o exemplo.