A programação com IA está tornando o código-fonte abundante, mas a verificação continua escassa

O Google News destacou uma afirmação contundente sobre inteligência artificial e software: o código está se tornando somente para escrita e descartável. A expressão captura uma mudança real. Agentes de programação podem gerar implementações mais rápido do que muitas equipes conseguem entender, revisar ou incorporar com segurança.

O conflito não é simplesmente humanos versus máquinas. É a velocidade de geração versus a compreensão organizacional. A IA pode reduzir o custo de produzir código e, ao mesmo tempo, elevar o custo de provar que o sistema resultante continua correto, seguro e sustentável.

Essa distinção importa porque as evidências mais fortes não sustentam uma narrativa simples de que o código de IA é rapidamente descartado. Em vez disso, elas apontam para uma inversão mais profunda. O código-fonte está se tornando abundante, enquanto especificações, julgamento arquitetural, verificação e responsabilização continuam escassos.

O que a matéria do Google News realmente mudou

A tese do código somente para escrita desloca o debate sobre programação com IA da velocidade de digitação para o controle de todo o sistema de software.

O termo ganhou visibilidade por meio de Joseph Ruscio, sócio geral da Heavybit. Seu ensaio de fevereiro de 2026, write-only code, descreve um futuro empresarial em que os agentes geram tanta implementação que os humanos deixam de ler cada linha.

“Somente para escrita” não significa que o código seja literalmente ilegível. Significa que ler cada linha gerada deixa de ser o principal mecanismo de controle. Em vez disso, humanos revisam especificações, restrições, testes, arquitetura e comportamento observável.

Essa é uma afirmação mais incisiva do que dizer que os desenvolvedores usarão um preenchimento automático melhor. Um programador em dupla com IA ainda pressupõe que um humano escreva ou revise de perto a implementação. Um agente de programação pode inspecionar um repositório, editar vários arquivos, executar comandos, rodar testes e revisar seu trabalho com intervenção limitada.

O artigo destacado pelo Google News também se encaixa em uma discussão mais ampla que já acontece em conferências de engenharia. Na QCon London 2026, Hannah Foxwell argumentou que revisar grandes volumes de código gerado não é nem agradável nem sustentável.

A resposta proposta por ela foi antecipar a revisão por pares. As equipes examinariam a especificação, a estratégia de testes e a arquitetura antes que um agente escrevesse a implementação. A cobertura da QCon da InfoQ conectou essa proposta diretamente ao conceito de código somente para escrita de Ruscio.

Portanto, o evento significativo não é o lançamento de um produto. É o surgimento de um modelo operacional coerente para o desenvolvimento assistido por IA.

Nesse modelo, os desenvolvedores definem a intenção e os limites aceitáveis. Os agentes traduzem esses limites em código. Sistemas automatizados testam o resultado, enquanto as pessoas se concentram em decisões que exigem contexto de negócio ou julgamento arquitetural.

Esse modelo muda a unidade de revisão. Um pull request contendo milhares de linhas geradas se torna menos útil como principal limite de confiança. Os artefatos importantes passam a ser o requisito, o modelo de ameaças, a suíte de testes, a política de dependências, o plano de implantação e as evidências em tempo de execução.

O código descartável de IA está na ponta mais agressiva desse modelo. Um agente pode gerar uma migração temporária, uma ferramenta de diagnóstico, um conversor de dados, um fixture de teste ou um protótipo. A equipe pode descartar o código-fonte depois que a tarefa imediata termina.

Ainda assim, os efeitos raramente desaparecem junto com o arquivo. Um script de curta duração ainda pode alterar um banco de dados, expor um segredo, criar recursos na nuvem ou incorporar uma suposição incorreta aos dados dos clientes. O código-fonte pode ser descartável, enquanto as consequências permanecem duradouras.

É por isso que o enquadramento do Google News merece atenção. Ele dá um nome memorável a uma mudança genuína, mas o nome também pode induzir ao erro. A questão central não é se os humanos leem cada linha. É se as equipes retêm evidências e conhecimento suficientes para governar o que essas linhas fazem.

A geração mais rápida coloca as organizações de engenharia sob pressão

A IA transforma a implementação em um insumo mais barato, mas não torna a entrega de software igualmente barata.

Os processos tradicionais de engenharia presumem que a geração de código seja uma restrição significativa. As equipes distribuem trabalho, implementam mudanças, revisam pull requests, executam testes e levam builds aprovados à produção.

Os agentes de programação comprimem a etapa de implementação. Eles não comprimem automaticamente o esclarecimento de produto, a revisão de segurança, os testes de integração, a prontidão operacional ou a coordenação organizacional.

A pesquisa DORA do Google Cloud descreve a IA como um amplificador. Ela fortalece organizações capazes e amplia as fragilidades das que têm dificuldades. O relatório DORA de 2025 argumenta que os retornos dependem mais do sistema organizacional ao redor do que da ferramenta em si.

Essa conclusão coloca líderes de engenharia sob pressão imediata. Se os agentes produzem mais mudanças, os revisores enfrentam filas maiores. A infraestrutura de testes recebe mais carga. As equipes de plataforma precisam dar suporte a mais experimentos, ambientes e tentativas de implantação.

O antigo gargalo se desloca em vez de desaparecer. A implementação dá lugar à capacidade de absorção, isto é, à capacidade da organização de entender, integrar, verificar e operar um fluxo crescente de mudanças.

É aí que o código somente para escrita se torna operacionalmente significativo. Um desenvolvedor pode pedir a um agente que adicione um endpoint, corrija um teste, migre uma biblioteca ou crie uma pequena aplicação interna. Cada solicitação pode produzir código plausível antes de o desenvolvedor explorar por completo o sistema ao redor.

Plausibilidade não é o mesmo que correção. O código gerado pode satisfazer o prompt enquanto viola uma convenção não documentada. Pode duplicar um serviço existente, selecionar uma dependência inadequada, enfraquecer uma verificação de autorização ou criar um caminho operacional caro.

Antes, os humanos aprendiam muitas dessas restrições enquanto implementavam a mudança. Eles encontravam interfaces difíceis, liam o código próximo, faziam perguntas aos mantenedores e descobriam por que decisões anteriores existiam.

Um agente pode pular grande parte desse processo de aprendizado. Isso costuma ser útil, mas também remove uma fonte de compreensão organizacional. A implementação chega sem garantir que alguém tenha assimilado o conhecimento necessário para mantê-la.

O ônus recai primeiro sobre desenvolvedores seniores e mantenedores. Eles detêm o contexto necessário para distinguir um patch localmente correto de um patch sistemicamente prejudicial. Quando a geração acelera, seu julgamento se torna um serviço compartilhado e cada vez mais escasso.

As equipes de segurança enfrentam um problema semelhante. O código descartável de IA pode entrar por meio de protótipos, painéis internos, scripts de migração, utilitários de suporte e automação temporária. Esses artefatos muitas vezes evitam os controles aplicados a aplicações voltadas ao cliente.

Um protótipo pode se tornar permanente porque os colegas passam a depender dele. Um script de uso único pode ser executado novamente meses depois. Credenciais temporárias podem parar em logs. Dados de teste podem escapar para um ambiente ativo.

A pressão também alcança engenheiros juniores. Se os agentes assumem a implementação rotineira, desenvolvedores mais novos perdem parte do trabalho por meio do qual antes aprendiam a estrutura da base de código, a depuração e a disciplina de produção.

As equipes não podem resolver esse problema banindo a IA ou exigindo que humanos inspecionem cada token gerado. Elas precisam de trajetórias deliberadas de aprendizado, propriedade explícita e mudanças menores que possam ser revisadas.

Um registro pesquisável de decisões arquiteturais pode ajudar a preservar o contexto ausente. Equipes que constroem uma base de conhecimento técnica podem conectar especificações, relatórios de incidentes e restrições de design ao código que os agentes modificam.

A pressão organizacional, portanto, é clara. Ferramentas de programação com IA recompensam equipes que já possuem testes sólidos, limites documentados, interfaces estáveis e feedback rápido. Elas expõem equipes que dependem de conhecimento não escrito e de revisores heroicos.

O código somente para escrita inverte o contrato tradicional de revisão

O contrato antigo dizia que humanos confiam no código depois de lê-lo; o contrato emergente diz que confiam no comportamento depois de restringi-lo e testá-lo.

Por décadas, manutenibilidade significou que outro engenheiro poderia ler uma função, entender sua intenção e modificá-la com segurança. Nomenclatura, estrutura, comentários, modularidade e documentação serviam todos à compreensão humana.

O código somente para escrita desafia a economia por trás desse padrão. Se um agente puder regenerar um componente a partir de uma especificação precisa, preservar cada detalhe da implementação poderá se tornar menos valioso.

Isso não elimina a manutenibilidade. Muda o que precisa ser mantido.

O ativo duradouro pode ser a especificação, em vez da implementação atual. Testes podem se tornar declarações executáveis de intenção. Contratos de interface podem importar mais do que a elegância interna. Regras de arquitetura podem se tornar restrições aplicadas por máquinas, em vez de orientações em um documento.

Essa inversão se assemelha a mudanças anteriores na abstração de software. A maioria dos desenvolvedores já não inspeciona instruções de máquina geradas antes de lançar uma aplicação. Eles confiam em compiladores, sistemas de tipos, testes, sistemas operacionais e monitoramento em tempo de execução.

O código gerado por IA difere em um aspecto importante. Um compilador realiza uma tradução determinística e delimitada. Um agente de programação toma decisões probabilísticas sobre design, dependências, APIs e comportamento.

Essa diferença impede as equipes de tratar um agente como apenas mais um compilador. O agente precisa de uma estrutura de controle, isto é, as ferramentas, permissões, contexto, testes e ciclos de feedback que restringem seu trabalho.

Uma boa estrutura de controle pode rejeitar dependências proibidas, impor limites entre módulos, limitar o acesso à rede, executar scanners de segurança e exigir testes antes de aceitar uma mudança. Ela também pode manter as edições geradas pequenas o suficiente para uma revisão significativa de código com IA.

A própria revisão precisa se tornar em camadas. Verificações automatizadas rápidas devem cobrir formatação, tipos, política de dependências, vulnerabilidades conhecidas, testes e regras de arquitetura. Revisores humanos devem se concentrar em intenção, trade-offs, limites de ameaça e modos de falha.

Isso não é permissão para integrar um patch enorme e opaco porque a suíte de testes foi aprovada. Os testes verificam apenas os casos que expressam. Eles não podem proteger suposições que ninguém identificou.

As especificações enfrentam o mesmo limite. Um agente pode seguir uma solicitação detalhada e ainda assim criar o produto errado. O requisito pode omitir uma necessidade de acessibilidade, uma política de retenção, uma regra regional ou uma restrição operacional.

Portanto, o contrato de revisão emergente tem vários pontos de controle. As pessoas aprovam o que deve mudar. As máquinas verificam se as restrições definidas são respeitadas. A telemetria de produção revela se o comportamento resultante corresponde à realidade.

Cada ponto cobre uma classe de falha diferente. Nenhum é suficiente por si só.

A mudança também altera como as equipes devem avaliar a produtividade dos desenvolvedores. Linhas geradas, tarefas concluídas e pull requests abertos medem atividade. Eles não mostram se os usuários receberam valor ou se o sistema se tornou mais difícil de operar.

A análise posterior da DORA constatou que uma maior adoção de IA estava associada tanto a maior vazão quanto a maior instabilidade. Sua discussão sobre as tensões da entrega com IA afirma que o tempo economizado durante a criação costuma ser realocado para auditoria e verificação.

Esse resultado explica por que programar pode parecer mais rápido sem tornar a entrega proporcionalmente mais rápida. Os desenvolvedores vivenciam o benefício imediato da geração. As organizações herdam o custo tardio da integração.

A linha divisória prática não é entre código escrito manualmente e código gerado. É entre mudanças governadas e não governadas.

Código de IA descartável e governado pode ser razoável para uma transformação isolada executada em um sandbox. Código gerado e não governado pode ser perigoso mesmo quando cada linha parece convencional e permanece no repositório por anos.

As Evidências Complicam a Tese do Código de IA Descartável

Código produzido por IA não é automaticamente efêmero, de baixa qualidade ou mais rápido de produzir em todos os contextos reais de desenvolvimento.

Um preprint de 2026, de Musfiqur Rahman e Emad Shihab, examinou mais de 200.000 unidades de código em 201 projetos de código aberto. Seu estudo sobre a sobrevivência do código chegou a um resultado que contraria a narrativa do código descartável.

No nível das linhas, o código produzido por agentes apresentou uma taxa de modificação 15,8 pontos percentuais menor e um risco de modificação 16 por cento menor do que o código produzido por humanos. Em outras palavras, o código de IA observado permaneceu por mais tempo.

Isso não prova que o código de IA era melhor. O código pode permanecer inalterado porque funciona, porque ninguém o utiliza ou porque os mantenedores hesitam em mexer nele. A longevidade, por si só, não consegue distinguir essas explicações.

O estudo também encontrou uma taxa modestamente maior de modificações corretivas em código produzido por agentes: 26,3 por cento, em comparação com 23 por cento para código humano. A variação entre agentes individuais superou a diferença geral entre agentes e humanos.

Esses resultados sugerem que o rótulo de origem é simplista demais. A escolha do modelo, o tipo de tarefa, a qualidade do repositório, a supervisão humana e as práticas organizacionais podem importar mais do que o fato de uma IA ter produzido o primeiro rascunho.

Um experimento separado chegou a outra conclusão desconfortável. A METR recrutou 16 desenvolvedores experientes que trabalhavam em seus próprios repositórios maduros de código aberto. O teste abrangeu 246 issues reais e permitiu ou proibiu aleatoriamente o uso de ferramentas de IA.

Os desenvolvedores que usaram ferramentas de IA do início de 2025 levaram 19 por cento mais tempo para concluir as issues atribuídas. O teste de produtividade também identificou uma marcante lacuna de percepção.

Os participantes esperavam que a IA os tornasse 24 por cento mais rápidos antes de concluir o trabalho. Depois, ainda acreditavam que ela os havia acelerado em 20 por cento, apesar da desaceleração medida.

Os pesquisadores alertaram contra a generalização do resultado para todos os desenvolvedores ou tarefas. Seus participantes conheciam bem grandes repositórios, e as ferramentas representavam um período específico em um mercado que evolui rapidamente.

Mesmo com essas limitações, o estudo expõe uma fragilidade central nas alegações sobre código de IA descartável. Geração rápida não é o mesmo que conclusão rápida. Formular prompts, esperar, verificar, corrigir e integrar pode consumir o ganho aparente.

O sentimento dos desenvolvedores reforça essa cautela. A pesquisa de 2025 do Stack Overflow relatou que o uso de IA continuou crescendo enquanto a confiança caiu. Apenas 29 por cento dos respondentes confiavam na precisão da IA, abaixo dos cerca de 40 por cento em pesquisas anteriores.

Sua análise sobre a confiança dos desenvolvedores afirma que mais de 84 por cento dos respondentes usavam ou planejavam usar ferramentas de IA. A adoção e a confiança estavam se movendo em direções opostas.

Essas descobertas não invalidam o código write-only. Elas esclarecem as condições que ele exige.

Primeiro, a regeneração precisa ser genuinamente mais barata do que entender e reparar a implementação atual. Isso é mais plausível para um pequeno adaptador ou fixture de teste do que para um livro-razão de pagamentos.

Segundo, a especificação precisa capturar uma parcela suficiente do requisito real. Um prompt que descreve apenas o caminho feliz não pode sustentar uma regeneração segura.

Terceiro, o ambiente precisa detectar comportamentos inaceitáveis. Sem testes, verificações de políticas, controles de acesso e observabilidade em tempo de execução, a equipe não consegue distinguir uma geração bem-sucedida de uma falha plausível.

Quarto, alguém precisa ser responsável pelo resultado. Um agente não pode ser responsabilizado por uma indisponibilidade, violação de privacidade ou incidente de segurança. A responsabilidade humana e organizacional sobrevive a qualquer mudança de autoria.

A leitura cética é, portanto, importante. “Descartável” pode se tornar uma desculpa conveniente para negligenciar a qualidade do design e da documentação. As equipes podem supor que conseguirão regenerar um componente mais tarde e então descobrir que sua especificação real existia apenas no comportamento em produção e na memória dos funcionários.

O código pode ser barato de recriar enquanto o contexto permanece caro de recuperar.

Código-Fonte Descartável Pode Deixar Efeitos Duradouros na Segurança e nos Dados

Excluir código-fonte gerado não desfaz as ações executadas por esse código-fonte.

Considere um desenvolvedor que pede a um agente para criar uma migração única de dados de clientes. O script lê um esquema antigo, transforma os registros e os grava em um novo serviço.

A equipe pode excluir o script após a migração. Os registros alterados permanecem. O mesmo vale para campos corrompidos, identificadores vazados, entradas de auditoria incompletas ou permissões não intencionais.

Um script de infraestrutura gerado cria o mesmo problema. Ele pode provisionar um bucket de armazenamento público, uma conta de serviço com permissões amplas ou uma credencial de longa duração. Remover o arquivo não remove necessariamente o recurso.

Aplicações internas temporárias também têm o hábito de se tornar permanentes. Uma equipe de vendas começa a usar um dashboard gerado. A área de operações passa a depender de sua saída. O desenvolvedor original muda para outro projeto.

O que começou como código de IA descartável agora sustenta um processo de negócios. Pode não ter responsável, política de dependências, plano de backup, revisão de acessibilidade ou procedimento de incidentes.

Esse risco aumenta quando os agentes recebem permissões amplas. Um agente de programação que pode executar comandos de shell, acessar serviços de rede, consultar bancos de dados e publicar mudanças tem um efeito muito maior do que uma ferramenta de autocompletar.

Solicitações de permissão oferecem proteção limitada. As pessoas se habituam às aprovações, especialmente quando uma ferramenta produz muitos pedidos. A defesa mais forte é a contenção determinística.

Um agente deve receber o mínimo de acesso a sistema de arquivos, rede, credenciais e implantação necessário para a tarefa. Ações de alto risco devem ocorrer em ambientes isolados, com logs claros e regras de expiração.

As equipes também devem distinguir operações reversíveis e irreversíveis. Gerar um arquivo local normalmente é reversível. Enviar uma mensagem, excluir dados de produção, rotacionar um segredo compartilhado ou alterar uma conta externa pode não ser.

O sistema deve exigir evidências mais robustas antes de permitir ações irreversíveis. Essas evidências podem incluir uma execução de teste, aprovação humana, prévia da mudança, confirmação de backup ou avaliação de políticas.

A revisão de código de IA deve examinar efeitos colaterais, não apenas o estilo do código-fonte. Os revisores devem perguntar quais dados o programa lê, quais sistemas ele contata, que estado ele altera e como a operação pode ser revertida.

A procedência também importa. As equipes precisam saber qual modelo ou agente produziu uma mudança, qual especificação recebeu, quais ferramentas invocou, quais testes foram executados e quem aprovou o resultado.

Esse registro não é uma decoração burocrática. Ele ajuda investigadores a reconstruir falhas quando a implementação gerada foi posteriormente substituída ou excluída.

O risco na cadeia de suprimentos cria outro efeito duradouro. Um agente pode selecionar uma dependência com base na semelhança de nomes ou em exemplos desatualizados. Esse pacote pode introduzir vulnerabilidades ou obrigações de licenciamento muito tempo depois de o código inicial desaparecer.

Controles de repositório podem bloquear pacotes desconhecidos, exigir lockfiles, verificar licenças e restringir fontes de instalação. Os agentes devem operar dentro desses controles, em vez de contorná-los por conveniência.

O objetivo não é preservar todo código-fonte descartável para sempre. É preservar as evidências necessárias para explicar e governar os efeitos do código-fonte.

Um programa temporário pode permanecer temporário quando seu ambiente é isolado, suas entradas são controladas, suas saídas são validadas e sua vida útil é aplicada. Sem essas condições, “temporário” descreve uma intenção, e não uma propriedade.

O Que os Leitores do Google News Devem Observar a Seguir

O futuro write-only será decidido pela economia da verificação, não por demonstrações de geração de código.

O primeiro sinal a observar é se as organizações transferem a revisão para etapas anteriores. Especificações, planos de teste, modelos de ameaças e restrições arquiteturais devem receber atenção mais formal antes que os agentes iniciem a implementação.

Evidências dessa mudança fortaleceriam a tese do código write-only. As equipes tratariam a intenção como o artefato duradouro e a implementação como uma expressão substituível dessa intenção.

Se os pull requests continuarem crescendo enquanto as práticas de revisão permanecerem inalteradas, a tese se enfraquece como modelo operacional. Ela descreveria o volume de código sem resolver o problema de compreensão resultante.

O segundo sinal é se as métricas de entrega melhoram junto com a produtividade individual. As organizações devem medir lead time, taxa de falha de mudanças, tempo de recuperação, defeitos que chegam à produção e carga operacional.

Mais código gerado não é sucesso. Mais recursos concluídos com comportamento estável em produção é sucesso.

O trabalho da DORA sugere que a IA pode aumentar a produtividade enquanto também aumenta a instabilidade. Uma melhoria sustentada em ambas as dimensões mostraria que testes, engenharia de plataforma e governança estão alcançando a geração.

A instabilidade contínua sustentaria a conclusão oposta. Significaria que as organizações estão produzindo implementações mais rapidamente do que conseguem absorvê-las com segurança.

O terceiro sinal é se os agentes de programação obtêm contenção mais forte e mensurável. Observe sandboxing por padrão, credenciais restritas, políticas legíveis por máquina, logs completos de ferramentas e aprovação obrigatória para ações irreversíveis.

Esses controles tornariam o código de IA descartável mais seguro porque restringem seu efeito mesmo quando humanos não inspecionam cada linha. Eles também dariam às empresas uma base crível para delegar tarefas maiores.

Um aumento de vazamentos relacionados a agentes, mudanças não autorizadas ou aplicações internas abandonadas exporia a fragilidade do modelo. Mostraria que o descarte reduziu a visibilidade sem reduzir as consequências.

Os leitores também devem resistir a tratar todo fluxo de trabalho de programação com IA como uma única categoria. Um teste unitário gerado, uma migração de repositório e uma mudança autônoma em produção apresentam riscos diferentes.

O nível adequado de supervisão depende da sensibilidade dos dados, da reversibilidade, da criticidade do sistema e da confiança na verificação. As equipes precisam de categorias explícitas, e não de um único processo universal de aprovação.

O Google News trouxe uma expressão provocativa à vista, mas a expressão deve iniciar a análise, e não encerrá-la. O código pode se tornar write-only sem se tornar irresponsável. Pode se tornar substituível sem ficar livre de consequências.

O desafio prático é tornar a intenção, as restrições, os testes, a procedência e as evidências operacionais mais duradouros do que qualquer implementação individual. As equipes que alcançarem esse equilíbrio podem se beneficiar de uma geração mais barata sem abrir mão do controle.

As equipes que não conseguem descrever esses controles devem pausar antes de chamar seu código de descartável. Elas devem fazer uma pergunta mais difícil: se nenhuma pessoa lê integralmente esta implementação, qual sistema confiável detectará o erro antes dos clientes?