Menos programação humana, mais arquitetura humana

Se a IA produzisse amanhã cada linha da implementação de um sistema, o que a engenharia ainda teria de projetar, decidir e verificar? A pergunta é hipotética, mas já não é ociosa, e este artigo argumenta que a resposta é arquitetura, num sentido específico e executável. Ele mantém separados três tipos de afirmação: o que estudos mediram, com a fonte citada; o que decorre dessas medições por raciocínio, marcado como inferência; e a própria tese, uma hipótese a ser testada, não uma constatação.

A capacidade medida é real e cresceu depressa. O SWE-bench pede a um sistema que resolva issues reais do GitHub em repositórios Python reais e avalia o resultado com os testes dos próprios projetos; em 2023, o melhor modelo resolveu 1,96% deles. No SWE-Bench Pro, mais difícil, construído a partir de mudanças maiores e em parte de código comercial que nunca foi público, o melhor resultado relatado na primeira versão do artigo, em setembro de 2025, foi de cerca de 23%; em meados de 2026, o ranking mantido pelo dono do benchmark mostrava cerca de 60% no conjunto público e cerca de 50% no comercial, com harnesses que variam entre as entradas. O horizonte de tempo do METR é a extensão de uma tarefa, cronometrada por uma pessoa qualificada, que um agente de IA conclui na metade das vezes. Nas suas tarefas bem especificadas e avaliadas automaticamente, essa extensão dobrou aproximadamente a cada sete meses entre 2019 e o início de 2025, e cerca de a cada quatro meses desde 2023, pela sua estimativa de 2026.

Dentro das organizações, a mudança aparece como volume, relatado pelas próprias empresas. O Google relatou em janeiro de 2025 que sugestões de IA aceitas somavam 67% dos caracteres de código digitados nos editores dos seus engenheiros, sem contar código colado, e que 80% das modificações numa série de grandes migrações internas, um tipo de tarefa bem especificado, foram escritas inteiramente por IA, cada uma revisada como qualquer outro código. Numa pesquisa não anônima com 132 funcionários, os engenheiros da Anthropic relataram usar o seu modelo em cerca de 59% do trabalho, enquanto mais da metade disse que conseguia delegar por completo no máximo um quinto dele.

As evidências de produtividade são mais mistas do que a curva de capacidade sugere. Num ensaio controlado randomizado realizado no início de 2025 com 16 desenvolvedores experientes que trabalhavam em projetos maduros aos quais contribuíam havia anos, o METR constatou que o acesso a ferramentas de IA fez as tarefas levarem 19% mais tempo, enquanto os desenvolvedores acreditavam ter ficado cerca de 20% mais rápidos. Um estudo de acompanhamento no início de 2026 apontou para acelerações modestas, com intervalos de confiança que incluem zero, e o METR chamou esses dados de sinal pouco confiável, porque os desenvolvedores recusavam cada vez mais trabalhar sem IA. Experimentos de campo com 4.867 desenvolvedores na Microsoft, na Accenture e numa terceira empresa, com coautores da Microsoft e feitos com o autocompletar de 2022 a 2024, encontraram 26% mais tarefas concluídas, com ganhos maiores, mas estimados com muita incerteza, entre os menos experientes. Um ensaio randomizado que o Google fez com 96 dos seus próprios engenheiros estimou cerca de 21% menos tempo numa tarefa, com um intervalo de confiança largo o bastante para incluir efeito nenhum. A pesquisa DORA de 2024 associou cada aumento de 25% na adoção de IA a uma queda estimada de 1,5% na vazão de entrega e de 7,2% na estabilidade de entrega; o relatório de 2025 constatou que a vazão agora sobe com a adoção enquanto a instabilidade continua subindo, e descreveu a IA como amplificadora das forças e disfunções que uma organização já tem.

Lidos em conjunto, esses estudos não mostram que a IA torna a engenharia de software barata. São compatíveis com algo mais estreito, que este artigo infere em vez de medir: produzir uma implementação candidata está ficando barato mais depressa do que estabelecer que uma candidata é aceitável. A IA também está automatizando partes da verificação, de testes gerados a provas verificadas por máquina. O que ela não resolve sozinha é o que as verificações devem verificar. Essa assimetria é o ponto de partida de tudo o que vem a seguir.

Um benchmark conta uma tarefa como resolvida quando um patch faz passar os testes designados. Um sistema é aceito quando as pessoas responsáveis por ele estão dispostas a depender dele. A maior parte da dificuldade mora na distância entre as duas coisas.

Os próprios benchmarks mostram essa distância. O SWE-bench Verified existe porque, quando 93 desenvolvedores revisaram uma amostra das tarefas originais em 2024, 38,3% foram marcadas por enunciados subespecificados e 61,1% por testes que podiam rejeitar soluções válidas, um filtro que os próprios autores consideram provavelmente rigoroso demais. Em 2026, a OpenAI deixou de relatar o benchmark, depois que uma auditoria de 138 tarefas, escolhidas porque o seu próprio modelo falhava nelas repetidamente, encontrou problemas relevantes nos testes ou nos enunciados de 59,4%, e todo modelo de ponta testado conseguiu reproduzir, para algumas tarefas, a correção original ou detalhes do enunciado. Um estudo apresentado no ICSE 2026 constatou que 29,6% dos patches de agentes contados como plausíveis se comportavam de modo diferente da correção feita pelos próprios desenvolvedores, nem todos de forma errada; somado a outras fragilidades dos testes, isso inflou as taxas de resolução relatadas em cerca de seis pontos percentuais. E o METR pediu a mantenedores do scikit-learn, do Sphinx e do pytest que revisassem patches que passavam nos testes, sem saber quem os escrevera. Os patches vinham de agentes lançados até o fim de 2025, cada um com uma tentativa e sem retorno, e cerca de metade não teria sido incorporada; o METR ressalta que isso não é um teto do que os agentes conseguem fazer.

Para além dos testes funcionais, o quadro é parecido. No BaxBench, um benchmark de aplicações de backend apresentado no ICML 2025, o melhor modelo produziu um programa correto em 62% das vezes, e, na média dos modelos, exploits de segurança tiveram êxito contra cerca de metade dos programas corretos. Em 576.000 amostras de código geradas em 2024 por 16 modelos, 19,7% dos pacotes de software a que os modelos se referiam não existiam, 5,2% nos modelos comerciais e 21,7% nos abertos; um atacante pode registrar esses nomes. Num estudo de 2022 com 47 participantes, na maioria estudantes, e um modelo antigo, quem tinha um assistente de IA escreveu código menos seguro e acreditou com mais frequência que ele era seguro. Um estudo quase experimental de projetos públicos no GitHub que adotaram um editor de código com IA, o Cursor, encontrou um ganho de produção grande, mas passageiro, enquanto os alertas de análise estática subiram 30% e a complexidade do código 41,6%, e ficaram lá.

As evidências também apontam no outro sentido, e isso importa. Um ensaio pré-registrado com 151 participantes não encontrou diferença significativa na facilidade com que outros desenvolvedores conseguiam evoluir depois código escrito com assistência de IA. A maioria dos estudos de segurança citados não tem uma linha de base humana equivalente. Nada disso mostra que código gerado é pior do que código humano.

O que mostra é que código gerado deve ser tratado como o que é: uma implementação candidata. Uma mudança candidata deve ser verificada contra as restrições da arquitetura e contra os seus testes, validações e políticas; deve deixar evidências do que foi verificado; e deve ser aceita ou rejeitada com base nisso. Onde uma decisão carrega um risco que nenhuma verificação consegue resolver, uma pessoa deve ser consultada. Esse modelo não depende de quem produziu a candidata.

Se implementações candidatas se tornam abundantes, a pergunta escassa passa a ser qual delas é aceitável, e respondê-la exige saber o que aceitável significa. Este artigo argumenta que, à medida que a implementação fica mais fácil de gerar, aumenta o valor relativo de decidir o que precisa continuar verdadeiro. Isso é uma inferência, não uma medição, e não diz que código não tem valor.

Há evidências de apoio nas bordas. Mais de um terço das tarefas revisadas para o SWE-bench Verified foi marcado como subespecificado. Modelos percebem mal quando uma instrução está subespecificada, e agentes que fazem perguntas de esclarecimento se saem bem melhor, em até 74% em termos relativos, com um usuário simulado, num estudo do ICLR 2026. O Google descreve o autor de código assistido por IA tornando-se cada vez mais o seu revisor, e os engenheiros da Anthropic descrevem um paradoxo da supervisão: usar bem o modelo exige supervisioná-lo, e supervisioná-lo exige justamente as habilidades que delegação demais pode desgastar. O relatório DORA de 2025 observa que o atrito não desaparece tanto quanto muda de lugar, do trabalho manual para decidir e verificar. Na pesquisa do Stack Overflow de 2025, mais desenvolvedores desconfiavam da precisão das ferramentas de IA do que confiavam nela, 46% contra 33%, e a frustração mais comum eram resultados quase certos, mas não exatamente.

Uma forma útil de descrever a mudança é separar duas perguntas. A arquitetura responde: o que precisa continuar verdadeiro? A implementação responde: como isso é realizado aqui? Tome uma propriedade: um resultado probabilístico não pode se tornar silenciosamente um dado oficial. Ela pode ser realizada por validação de esquema em tempo de execução, por uma fronteira tipada que só um serviço de validação consegue construir, por um adaptador na camada de aplicação, ou por um teste de arquitetura na integração contínua que falha quando um cliente de modelo é importado no núcleo. Cada uma cobre parte da propriedade, com força diferente; uma regra de importação, por exemplo, impõe a direção de uma dependência, não a propriedade em si. A tecnologia pode mudar. A propriedade permanece.

Uma IA pode produzir cada vez mais o segundo tipo de resposta. O primeiro continua sendo uma questão de intenção, compreensão do domínio, risco e responsabilidade. A linha não é totalmente nítida: um cache ou uma política de novas tentativas escolhidos durante a implementação criam propriedades próprias, e por isso código gerado ainda precisa de revisão contra a arquitetura, não só contra os seus testes.

A arquitetura de software já tem uma noção de intenção executável. Em Building Evolutionary Architectures, Ford, Parsons e Kua definem uma função de aptidão arquitetural como uma avaliação objetiva da integridade de uma ou mais características arquiteturais. Ferramentas como o ArchUnit fazem as regras de dependência entre camadas rodarem como testes unitários comuns. Contratos, esquemas, sistemas de tipos, testes baseados em propriedades e, onde o custo se justifica, verificação formal expressam a mesma ideia em profundidades diferentes.

A definição de trabalho usada aqui é simples. Uma restrição se torna arquitetural no sentido que interessa a este artigo, aplicada e não apenas enunciada, quando violá-la faz o sistema ou o seu processo de entrega rejeitar o resultado. Por essa definição, um princípio que nenhum build, nenhum deploy e nenhuma verificação em tempo de execução consegue fazer falhar ainda é uma descrição, por mais cuidadosamente que esteja escrito. Nem tudo o que é arquitetural pode ser aplicado assim; como um sistema é decomposto, ou quem é dono de quais dados, é algo que se julga, não que se verifica.

Quando a implementação se torna abundante, a arquitetura passa a ser menos sobre desenhar diagramas de sistema e mais sobre definir fronteiras executáveis: restrições verificáveis por máquina, propriedades de aceitação, requisitos de evidência, testes de arquitetura, requisitos de observabilidade, fronteiras de política e comportamento definido em caso de falha. Posto como tese, e não como definição da disciplina: o artefato do arquiteto já não é só um diagrama. É também o conjunto de propriedades que o sistema é incapaz de violar em silêncio.

Executável não significa provado. Testes amostram comportamento; podem revelar defeitos, mas não mostrar que não resta nenhum. Propriedades diferentes pedem garantias de natureza diferente: tipos e esquemas para a forma dos dados, análise estática e testes de arquitetura para dependências, testes baseados em propriedades para comportamento sobre muitas entradas, verificação formal onde uma propriedade é crítica e pode ser especificada, controles em tempo de execução para o que só pode ser observado em operação, e revisão humana para o que nenhum mecanismo consegue julgar.

A pesquisa sobre gerar especificações junto com o código mostra ao mesmo tempo a promessa e o limite. Modelos de linguagem transformaram intenção em linguagem natural em pós-condições que detectaram 64 bugs históricos reais do conjunto de dados Defects4J. No benchmark VERINA, o melhor modelo escreveu código correto para 72,6% das tarefas, mas uma especificação correta e completa para apenas 52,3%. Lahiri formula o limite de fundo: verificar uma implementação contra uma especificação pode ser definido mecanicamente, mas não há caminho algorítmico para assegurar que a especificação capture o que o usuário pretendia. Esse é o problema arquitetural numa frase.

Um sistema não está sob controle porque um modelo foi instruído sobre o que não fazer. Um prompt de sistema, uma política escrita, uma instrução para evitar algo, a aparente disposição de um modelo em seguir uma regra e uma pessoa que passa os olhos em tudo depois descrevem um comportamento esperado. Nenhum deles bloqueia de forma confiável um estado inaceitável quando o modelo não coopera; uma pessoa que passa os olhos depois pega uma parte, tarde e de forma irregular.

Controle, no sentido usado aqui, existe quando um estado inaceitável pode ser detectado, bloqueado, rejeitado ou escalado independentemente da cooperação do modelo. Seus instrumentos são conhecidos: restrições de arquitetura executáveis, fronteiras de tipo, esquemas, validadores determinísticos, testes de arquitetura e de contrato, verificações na integração contínua que fazem o build falhar, aplicação de políticas, admissão no deploy, proveniência e rastreabilidade, testes de aceitação, revisão humana controlada e portões de publicação. Uma regra que uma IA pode ignorar ainda não é um controle arquitetural.

Uma consequência é que os controles não precisam saber quem escreveu o código. A mesma fronteira restringe uma mudança digitada por uma pessoa, uma mudança sugerida por um assistente e uma mudança produzida de ponta a ponta por um agente. A pergunta importante já não é só quem escreveu o código, mas se o sistema resultante preserva as propriedades exigidas. O perfil do NIST para o desenvolvimento seguro em equipes que constroem modelos de IA generativa adota a mesma posição para vulnerabilidades: suas práticas não distinguem entre código-fonte escrito por humanos e gerado por IA, porque todo código deve ser avaliado antes do uso. Isso não é um regime de policiamento de código escrito por máquina. É arquitetura que restringe a implementação qualquer que seja a sua origem, incluindo os erros que as pessoas cometem.

Muda também o que um sistema deve deixar para trás. Um sistema gerado que apenas parece correto não deixou evidência do que foi verificado. Propriedades importantes devem deixar evidências de que foram avaliadas: quais testes rodaram, qual versão de política se aplicou, o que uma validação retornou, como uma mudança se liga ao requisito a que serve, de onde vieram as suas entradas e o que o portão de liberação decidiu. Frameworks de cadeia de suprimentos já tratam registros desse tipo como algo que um build produz e um consumidor verifica: o SLSA especifica a proveniência de como um artefato foi construído, e o in-toto verifica que cada etapa de uma cadeia de suprimentos foi executada como previsto. A proveniência mostra como um artefato foi produzido, não que ele esteja correto.

Voltemos à pergunta inicial. Se a IA produzisse amanhã cada linha da implementação, a engenharia ainda teria de estabelecer o que a implementação pode significar e fazer, quais propriedades ela não pode violar em silêncio e que evidências são necessárias antes que se possa confiar nela.

Na prática, é uma lista de responsabilidades: definir o propósito do sistema, decidir quais resultados são inaceitáveis, determinar o que conta como evidência, resolver ambiguidade semântica, fixar a tolerância a risco, definir invariantes, revisar casos excepcionais, validar a arquitetura, aceitar o risco residual e continuar responsável. Nem todo item precisa de uma pessoa executando-o à mão toda vez. Cada um precisa de uma pessoa ou função nomeada, atuando dentro de um processo definido, que seja responsável por ele. Um sistema pode automatizar trabalho sem tornar a responsabilidade indefinida. Menos programação humana não significa menos responsabilidade humana.

A intenção humana não é automaticamente correta, nem está automaticamente disponível. Um requisito que vive só na cabeça de alguém não é um controle arquitetural. Para restringir a implementação gerada, a intenção precisa ser tornada explícita, representada numa forma que possa ser verificada, revisada, versionada quando muda e ligada à verificação que a aplica.

É no significado que isso é mais difícil. Um gerador pode produzir um sistema sintaticamente impecável que entende mal o seu domínio, porque os termos carregam contexto: o mesmo rótulo significa coisas diferentes em duas organizações, as definições de uma norma mudam entre versões, e dados que cruzam uma fronteira entram num vocabulário jurídico diferente. Gerar sintaxe não resolve o alinhamento semântico. Decidir o que um campo significa, e manter esse significado estável enquanto os dados passam entre sistemas, organizações e jurisdições, é trabalho de arquitetura que mais implementação não substitui.

A atenção humana também é um recurso limitado, com modos de falha conhecidos. Bainbridge observou em 1983 que a automação deixa aos operadores as tarefas que os projetistas não conseguiram automatizar e lhes pede que monitorem um sistema instalado justamente porque faz o trabalho melhor do que eles. Uma revisão sistemática sobre o viés de automação, a tendência a confiar demais em resultados automatizados, inclui a ênfase na responsabilização do usuário entre as medidas que o reduzem. A conclusão não é que as pessoas devam ler cada linha gerada, o que não escala. É que os sistemas devem concentrar a atenção humana no julgamento e no risco não resolvidos, e dar consequência a essa atenção.

Este artigo argumenta que só se pode contar com a autonomia na implementação na medida em que o comportamento resultante pode ser restringido e verificado de forma independente. Dito como princípio, e não como fórmula: a autonomia concedida a um agente de implementação deve estar relacionada a quão independentemente o seu resultado pode ser verificado. Onde as propriedades estão bem especificadas e as verificações são fortes, como numa migração mecânica, numa atualização de dependência sob uma suíte de testes rigorosa ou num adaptador atrás de uma fronteira tipada, muito pode ser delegado. Onde as propriedades são vagas, as verificações fracas ou o custo de um erro alto, a autonomia deve crescer devagar ou simplesmente não crescer.

Por esse argumento, a implementação pode se tornar cada vez mais autônoma sem que o controle se torne autônomo. A autonomia é concedida pelas restrições, medida contra as evidências e retirada quando as evidências deixam de sustentá-la. Os critérios de aceitação não precisam depender de quem escreveu o código; quanto um produtor pode fazer antes que uma pessoa olhe ainda pode depender do seu histórico.

É também por isso que o argumento não depende de uma linguagem ou plataforma específica. A mesma propriedade arquitetural pode ser verificada em tempo de compilação por um tipo em TypeScript, em tempo de execução por um esquema em Python, por uma fronteira de módulo em Java ou por uma política de admissão no Kubernetes. Quando a implementação muda, inclusive quando é gerada de novo, a propriedade é o que sobrevive.

O COADF, o Compliance-Oriented AI Development Framework, é uma exploração prática desta tese, e apenas uma. É um método de desenvolvimento para sistemas de IA que precisam se sustentar diante da regulação europeia. Lido à luz desta tese, ele pergunta quais propriedades precisam continuar verdadeiras quando componentes probabilísticos participam da produção, transformação ou publicação de informação, e como um build pode perceber quando elas deixam de ser verdadeiras. Ele nasce do projeto de pesquisa e desenvolvimento AnyLAI, que investiga como a intenção arquitetural pode continuar aplicável em sistemas que contêm cada vez mais comportamento probabilístico e gerado por máquina.

Seus princípios aplicam a tese a um caso mais estreito: o que a saída de um modelo pode se tornar enquanto o sistema funciona. O P-1 mantém o comportamento probabilístico limitado pelo comportamento determinístico do sistema: um modelo devolve um valor junto com a sua confiança e o método por trás dele, nunca um valor nu. O P-4 mantém rastreáveis as transformações importantes, de uma saída publicada até as evidências em que ela se apoia. O P-6 transforma barreiras de proteção em fences, verificações que bloqueiam uma liberação em vez de conselhos num documento, e pede a cada fence que mostre que dispara. O P-7 mantém normas externas, sistemas de classificação e serviços de terminologia em adaptadores fora do núcleo. O P-8 mantém as regras explícitas e versionadas como dados, para que uma decisão nomeie a versão da regra que a produziu. O P-2 e o P-3 estabelecem que confiança baixa nunca chega a uma saída publicada e que ali uma pessoa decide, um fato de cada vez, diante da sua fonte.

Só os seus modelos de governança tratam do outro caso, agentes de IA que escrevem código de produção. Uma escada de autonomia define quanto um agente pode fazer antes que uma pessoa olhe: no degrau mais baixo, uma pessoa lê cada linha; no mais alto, uma pessoa lê os resultados dos testes e a saída dos guardiões, um degrau que exige cobertura madura de fences e um histórico e que, segundo o framework, deveria continuar raro. Uma lista curta de decisões, entre elas mudanças de esquema de banco de dados, configuração de segurança, contratos de interface cuja mudança quebra quem os chama e mudanças no próprio sistema de fences, fica com uma pessoa em todos os degraus.

O COADF não torna seguro o desenvolvimento autônomo de código e não estabelece que software gerado está correto. Não é um framework de programação autônoma. Ele torna algumas premissas arquiteturais explícitas e testáveis, e é publicado para que essas premissas possam ser examinadas e contestadas.

Ela não afirma que desenvolvedores de software deixarão de ser necessários, que a programação humana está obsoleta ou que desenvolvedores serão substituídos por arquitetos. Boa parte do que este artigo chama de arquitetura é feita por desenvolvedores. A tese trata de onde o esforço de engenharia cria mais valor, não de cargos.

Ela não afirma que a IA já consegue construir software de produção de forma autônoma, que a arquitetura elimina alucinações ou que os controles certos são tudo de que uma IA precisa. As evidências citadas acima incluem mantenedores que rejeitam cerca de metade dos patches que passam nos testes, benchmarks que superestimam a correção e falhas de segurança em código gerado.

E ela não afirma que a transição que descreve está completa, é universal ou inevitável. É uma hipótese sobre uma direção, com um mecanismo que pode ser examinado: à medida que a implementação fica mais fácil de gerar, a verificação se torna mais importante, e o trabalho de decidir o que precisa continuar verdadeiro passa a ser uma parcela maior da engenharia.

Uma tese só é útil se produzir perguntas que possam ser respondidas. Estas parecem as mais urgentes.

1. 01Quanto detalhe de implementação pode ser delegado antes que a verificação se torne o custo dominante?
2. 02Quais propriedades arquiteturais podem ser verificadas automaticamente, e quais ainda exigem julgamento humano?
3. 03Como a arquitetura deve ser representada para que pessoas e máquinas possam raciocinar sobre ela?
4. 04A intenção arquitetural pode se tornar verificável por máquina sem ficar presa a uma tecnologia de implementação?
5. 05Quanta autonomia deve ser concedida quando as técnicas de garantia diferem em força?

Nenhuma delas tem resposta definitiva. Entre a afirmação de que a IA apenas ajuda desenvolvedores a programar mais depressa e a de que desenvolvedores já não são necessários está a pergunta de que trata esta pesquisa: o que um sistema deve ser incapaz de fazer, quem decide isso e como a decisão é aplicada.