O lado negro das ferramentas de programação com IA: o que mostram os dados de 2026

A subscrição é a parte mais barata de uma ferramenta de programação com IA. Quer pagues 20, 100 ou 200 dólares por mês, os custos maiores não aparecem na fatura. Aparecem mais tarde: código que passa na revisão e se parte em produção, aplicações que deixam fugir os dados dos utilizadores, mais código do que alguém consegue rever, agentes com acessos a mais a apagar bases de dados de produção e engenheiros em burnout.

Sou engenheiro de software numa grande empresa tecnológica e uso estas ferramentas todos os dias. Não odeio a IA. Mas já me deparei com muitos dos problemas deste artigo, e em 2026 há finalmente dados suficientes para lhes pôr números.

Resumo rápido

• O código de IA parece melhor na revisão do que se comporta em produção. No inquérito da New Relic de junho de 2026 a 200 líderes tecnológicos dos EUA, 94 % classificaram o código de IA como de maior qualidade do que o código escrito por pessoas, na fase de revisão. 82 % conseguiram apontar uma falha em produção causada por código de IA nos seis meses anteriores (New Relic, 2026).
• Agentes com credenciais amplas destroem coisas depressa. Um agente do Cursor a correr o Claude apagou a base de dados de produção da PocketOS em cerca de 9 segundos, e um terraform destroy executado pelo Claude apagou 2,5 anos de dados de cursos do DataTalks.Club. Em ambos os casos, permissões restritas teriam travado o agente onde as instruções não o travaram.
• A revisão é o novo gargalo. À medida que a adoção de IA subiu, num universo de cerca de 22.000 programadores, o tempo mediano de revisão de PR subiu 441 % e os bugs por programador subiram 54 % (Faros AI, 2026).
• As falhas de segurança estão a aumentar. Investigadores da Georgia Tech associaram 35 CVE a código escrito por IA só em março de 2026, contra cerca de 18 entre maio e dezembro de 2025 (Georgia Tech, 2026).
• As pessoas também pagam. Os júniores que aprenderam com IA tiveram 50 % num questionário de compreensão, contra 67 % dos que programaram à mão (Anthropic, 2026), e um inquérito a 442 programadores concluiu que a adoção de IA aumenta o burnout ao aumentar as exigências do trabalho (Feng et al., 2026).

Porque é que o código de IA passa na revisão e falha em produção?

O código de IA passa na revisão porque parece limpo, e falha em produção porque o agente que o escreveu não sabe como o teu sistema se comporta com tráfego real nem porque é que o código existente está escrito daquela maneira.

Em junho de 2026, a New Relic publicou o inquérito State of AI Coding, feito a 200 líderes tecnológicos dos EUA (New Relic, 2026). Na fase de revisão, 94 % classificaram o código gerado por IA como de maior qualidade do que o código escrito por pessoas, e 33 % disseram que era de qualidade muito superior. Depois de esse código chegar a produção, as respostas inverteram-se:

• 78 % registaram mais incidentes em produção nos últimos 12 meses
• 86 % disseram que os engenheiros séniores passam mais tempo a corrigir código
• 74 % disseram que pelo menos um quarto do seu código gerado por IA precisou de retrabalho significativo
• 82 % conseguiram apontar uma falha em produção nos últimos seis meses causada por código de IA

Se o código é melhor na revisão, porque é que continua a partir-se? No meu trabalho, vejo quatro razões.

O agente não conhece o sistema. Não consegue ver quanto tráfego um serviço aguenta, que dias têm movimento a mais, nem que dependência a jusante cai primeiro. Nada disso está no diff.

Não sabe porque é que o código está escrito assim. Todas as bases de código maduras têm condições estranhas. Talvez o fluxo de pagamentos tenha uma verificação esquisita porque um programador anterior se deparou com um bug do fornecedor e o contornou. Uma pessoa que lesse esse código perguntaria a quem o escreveu. O agente não pergunta. Faz um palpite e segue em frente, e muitas vezes o palpite está errado.

Os revisores ficam cegos perante diffs grandes. Quando um agente produz centenas de linhas de uma vez, o revisor sente-se sobrecarregado. Ao fim de algum tempo deixas de ler com atenção, e o código é aprovado porque parece estar bem. Os casos limite que um engenheiro com anos naquele código trataria sem pensar são exatamente os que ninguém verifica.

A dívida dos agentes acumula-se. É código de IA desleixado que vai para produção e nunca é limpo. Como qualquer dívida técnica, cresce, e acaba por se transformar num incidente em produção.

O que acontece quando a própria ferramenta de IA piora?

A produtividade da tua equipa cai, e é difícil de notar. Em março e abril de 2026, os programadores passaram semanas a queixar-se de que o Claude Code tinha piorado. Stella Laurenzo, diretora do grupo de IA da AMD, analisou 6.852 sessões do Claude Code e descobriu que o agente lia muito menos código antes de fazer alterações. Passou de 6,6 leituras de ficheiros por edição para 2,0 (GitHub issue #42796, 2026).

O postmortem da Anthropic atribuiu a queda a três alterações que a empresa tinha lançado, incluindo um bug de cache que apagava o raciocínio do modelo em cada turno. Esse bug «passou por várias revisões de código humanas e automáticas, bem como por testes unitários, testes end-to-end, verificação automática e dogfooding» (Anthropic, 2026).

Pensa no que isso significa para uma empresa com centenas de engenheiros que dependem destas ferramentas. Durante semanas, toda a organização de engenharia trabalha com produtividade reduzida, e quase ninguém repara, porque quando um agente tem um mau desempenho encolhes os ombros e pensas «é IA, às vezes acontece».

A Anthropic diz que nada disto foi intencional, e eu acredito. Mesmo assim, deixou-me desconfortável. Quando a tua equipa depende de um modelo da Anthropic, da OpenAI ou de qualquer outro, é o fornecedor que decide quão bom esse modelo é hoje. Se um fornecedor alguma vez decidisse reduzir a qualidade, os programadores que mais dependem da ferramenta seriam os mais afetados, e um punhado de empresas molda hoje a qualidade de uma grande parte do código novo do mundo.

Um agente de IA pode apagar a tua base de dados de produção?

Pode. Aconteceu em pelo menos três casos tornados públicos no último ano, e em todos o agente tinha muito mais acesso do que a tarefa exigia.

PocketOS: produção apagada em 9 segundos

Em abril de 2026, um agente de IA no Cursor, a correr o Claude Opus 4.6 da Anthropic, estava a trabalhar numa tarefa no ambiente de staging da PocketOS e deparou-se com um problema de credenciais. Foi à procura de credenciais e encontrou um token da API da Railway num ficheiro sem relação com a tarefa. O token tinha sido criado para gerir domínios personalizados, mas não tinha limites de âmbito. Quem o tivesse podia fazer qualquer coisa em qualquer ambiente.

O agente usou-o para apagar um volume de armazenamento através da API da Railway, convencido de que a eliminação só afetaria o staging. O volume continha a base de dados de produção. Os backups estavam no mesmo volume, por isso também desapareceram, e a cópia mais recente guardada noutro sítio tinha cerca de três meses. Tudo demorou cerca de 9 segundos (The Register, 2026).

As regras do agente diziam-lhe para nunca adivinhar e nunca executar comandos destrutivos sem que lho pedissem. Quando o fundador, Jer Crane, perguntou porque o tinha feito mesmo assim, o agente respondeu: «Adivinhei que apagar um volume de staging através da API ficaria limitado ao staging. Não verifiquei.» Mais tarde, a Railway recuperou os dados a partir dos seus próprios backups (The Register, 2026).

Podia ter sido evitado sem mexer no agente. Produção e staging não deviam partilhar infraestrutura, cada ambiente devia ter o seu próprio token, e o agente nunca devia ter tido acesso a um token de que não precisava. Mesmo assim, culpo o agente, porque ignorou instruções que lhe tinham sido dadas. Mas uma regra que escreves para um agente é só um pedido, e este ignorou-a.

DataTalks.Club: 2,5 anos de dados e um terraform destroy

Alexey Grigorev gere o DataTalks.Club, uma plataforma de cursos gratuitos de engenharia de dados, e gere a sua infraestrutura com Terraform (Alexey Grigorev, 2026). O Terraform trabalha com dois ficheiros. A configuração descreve o que queres, como servidores, uma base de dados e uma rede. O ficheiro de estado regista o que o Terraform construiu de facto. O Terraform compara os dois e constrói tudo o que o ficheiro de estado não lista.

O ficheiro de estado dele estava no portátil, em vez de num armazenamento remoto partilhado. Quando mudou de portátil, a configuração foi com ele, mas o estado não. O Terraform concluiu que ainda nada tinha sido construído e começou a construir tudo pela segunda vez. Ele interrompeu o processo a meio, o que deixou alguns recursos duplicados a correr ao lado dos verdadeiros.

Depois, o Claude, ao limpar os duplicados, descompactou um arquivo antigo do Terraform vindo do portátil anterior. Nas palavras dele: «Não reparei que o Claude estava a descompactar o meu arquivo do Terraform. Substituiu o meu ficheiro de estado atual por um mais antigo que tinha toda a informação sobre a plataforma de gestão de cursos do DataTalks.Club.» Esse estado antigo descrevia toda a plataforma de produção. O Claude executou terraform destroy, e o Terraform apagou a base de dados, a rede, os servidores e os snapshots automáticos, já que também tinham sido criados pelo Terraform. A base de dados guardava 2,5 anos de submissões dos cursos, com cerca de 1,9 milhões de linhas numa só tabela.

À meia-noite, pagou para subir o plano de suporte da AWS e conseguir falar com alguém da AWS ao telefone. A AWS tinha um snapshot do lado dela que ele não conseguia ver na sua própria consola, e a plataforma foi reposta 24 horas depois da eliminação.

Normalmente, uma pessoa reveria o plano antes de executar terraform destroy contra produção. O Claude executou-o sem questionar o que o plano ia apagar.

Amazon Kiro: 13 horas de AWS Cost Explorer em baixo

Isto não acontece só a empresas pequenas. Em dezembro de 2025, engenheiros da Amazon deixaram o Kiro, o agente de programação com IA da própria Amazon, corrigir um problema no AWS Cost Explorer, a ferramenta que os clientes usam para acompanhar os gastos na AWS. O Kiro decidiu que a melhor correção era apagar o ambiente e recriá-lo. O Cost Explorer esteve em baixo durante cerca de 13 horas numa região da China continental, segundo o Financial Times, num resumo do The Decoder (2026).

Duas salvaguardas deviam tê-lo travado. Por omissão, o Kiro pergunta antes de agir, e as alterações em produção precisam da aprovação de uma segunda pessoa. Mas o engenheiro que estava a usar o Kiro tinha permissões mais amplas do que o previsto, o Kiro herdou-as e não foi exigida uma segunda aprovação. A Amazon disse ao FT que o envolvimento de ferramentas de IA foi uma coincidência. A resposta pública da empresa classificou o incidente como «erro do utilizador, mais concretamente controlos de acesso mal configurados» (Amazon, 2026). Seja como for, o agente herdou mais acesso do que a tarefa exigia.

O que teria evitado estes incidentes?

Regras de infraestrutura comuns teriam travado os três casos:

• Dá a cada ambiente as suas próprias credenciais, para que uma tarefa de staging só consiga chegar ao staging.
• Dá a um agente o token mais restrito que faça o trabalho, nunca o acesso total de um engenheiro.
• Mantém produção e staging em infraestrutura separada. Isso vale sobretudo para o armazenamento, e os backups nunca devem ficar no mesmo volume que os dados.
• Guarda o estado do Terraform num armazenamento remoto com bloqueio. Um ficheiro de estado num portátil está à distância de um portátil perdido de uma reconstrução ou de um destroy.
• Faz com que uma pessoa aprove cada comando destrutivo contra produção, incluindo eliminações, destroy, force pushes e migrações.

Como é que os atacantes estão a visar as ferramentas de programação com IA?

Os atacantes usam agora o agente de IA na tua máquina como a ferramenta que encontra e rouba os teus segredos.

Em agosto de 2025, alguém publicou oito versões maliciosas do Nx, uma ferramenta de build de JavaScript com cerca de 6 milhões de downloads semanais (Nx, 2025). As versões comprometidas estiveram disponíveis durante cerca de quatro a cinco horas. Um script de postinstall verificava se a máquina tinha instaladas as ferramentas de linha de comandos do Claude, do Gemini ou do Amazon Q. Se encontrasse uma, executava-a com as verificações de segurança desligadas (claude --dangerously-skip-permissions, gemini --yolo ou q --trust-all-tools) e mandava o agente procurar no disco tokens do GitHub, tokens do npm, chaves SSH, ficheiros .env e carteiras de criptomoedas. Depois, usava o token do GitHub da vítima para criar um repositório público na conta dela e carregava lá o saque (StepSecurity, 2025). Mais de 1.700 programadores viram os seus segredos publicados desta forma (Wiz, 2025).

Em fevereiro de 2026, um worm atacou diretamente as ferramentas de programação com IA. Pelo menos 19 pacotes npm de duas contas usavam nomes parecidos com Claude Code e OpenClaw, por isso quem escrevesse mal o nome de um pacote instalava o errado. Depois de instalado, o worm recolhia chaves de API de fornecedores de IA e acrescentava o seu próprio servidor MCP às ferramentas de IA do programador, com instruções escondidas que mandavam o assistente reunir chaves SSH e credenciais da AWS. Propagava-se publicando mais pacotes infetados com tokens do npm roubados e fazendo commit de si próprio em repositórios através da API do GitHub (Socket, 2026).

Os ataques à cadeia de fornecimento do npm são mais antigos do que os agentes de IA, mas um agente com permissões amplas alarga os danos. Consegue ler e enviar tudo aquilo a que tu tens acesso no teu portátil. Os dois ataques também dependiam de o npm executar automaticamente os scripts de instalação de um pacote. Os módulos Go não têm scripts de instalação, por isso o go get nunca executa código de uma dependência enquanto a descarrega. Se quiseres ver o lado do ecossistema, segurança da cadeia de fornecimento: Go vs Node.js compara a forma como os dois gestores de pacotes lidam com isto.

A IA está a estragar a revisão de código?

Está. A IA escreve código mais depressa do que as pessoas o conseguem rever, e os dados mostram que, por isso, os revisores verificam menos.

A Faros AI acompanhou cerca de 22.000 programadores em mais de 4.000 equipas. À medida que a adoção de IA subiu, os problemas também subiram (Faros AI, 2026):

• Bugs por programador: +54 %
• Incidentes por pull request: +243 %
• Tempo mediano de revisão de PR: +441 %
• Tamanho dos pull requests: +51 %
• PRs integrados sem revisão: +31 %

Um estudo de 2026 acompanhou 400 revisores em 11.429 revisões de PRs de agentes de IA. Os revisores que já tinham visto mais PRs de agentes aprovaram-nos 14,5 pontos percentuais mais vezes do que os que tinham visto menos, e os comentários de revisão inline caíram 22 % ao longo do estudo. Os investigadores chamam-lhe habituação. Quanto mais código de IA os revisores viam, com menos atenção o verificavam (Yu et al., 2026).

O inquérito State of Code da Sonar, de janeiro de 2026, feito a mais de 1.100 programadores, concluiu que 38 % dizem que rever código de IA dá mais trabalho do que rever o de um colega, e 53 % já viram código de IA que parecia correto mas não era fiável. 96 % não confiam totalmente em código gerado por IA, mas só 48 % o verificam sempre antes de fazer commit (Sonar, 2026). Acho que a diferença entre esses dois números vem do cansaço de rever código de IA com cuidado, dia após dia. Também já me apanhei a ler na diagonal diffs grandes de agentes.

A Microsoft publicou dez meses de dados sobre o Copilot coding agent no repositório dotnet/runtime, onde os engenheiros lhe atribuíam tarefas e ele abriu 878 pull requests (Microsoft .NET Blog, 2026). No primeiro mês, só 41,7 % foram integrados, em parte porque faltavam ao agente instruções de build. Depois de a equipa corrigir isso, a taxa subiu, e ao longo dos dez meses 67,9 % dos PRs do agente foram integrados. Os PRs dos próprios engenheiros foram integrados em 87,1 % dos casos. Os PRs do agente também exigiram mais revisão. Os PRs do agente integrados tiveram em média 16,5 comentários de revisão, contra 12,4 nos PRs dos engenheiros, e as pessoas fizeram push de commits seus em 396 dos 878 PRs do agente, cerca de 45 %, contra 10,3 % dos PRs humanos integrados.

O código gerado por IA é menos seguro?

As vulnerabilidades atribuídas a código de IA estão a crescer depressa, e os números publicados provavelmente ficam aquém da realidade.

Um laboratório da Georgia Tech mantém o Vibe Security Radar. O projeto analisa vulnerabilidades reportadas publicamente (CVE), encontra o commit que introduziu cada bug e procura sinais de que foi escrito por IA, como uma etiqueta de coautor de IA. Só em março de 2026, encontrou 35 CVE associadas a código de IA, contra cerca de 18 entre maio e dezembro de 2025, depois do início do acompanhamento (Georgia Tech, 2026). O fundador do projeto, Hanqing Zhao, estima que o número real seja cinco a dez vezes superior ao que conseguem detetar, porque a maior parte do código escrito por IA não deixa rasto de que veio de uma IA (Infosecurity Magazine, 2026).

A GitGuardian encontrou 28,65 milhões de novos segredos hard-coded em commits públicos no GitHub em 2025, mais 34 % do que em 2024 e o maior salto anual que alguma vez registou. Os commits feitos com o Claude Code deixaram fugir segredos em 3,2 % dos casos, cerca do dobro da referência de 1,5 %, embora um programador tenha aprovado cada um desses commits (GitGuardian, 2026).

Em maio de 2026, investigadores da RedAccess encontraram cerca de 380.000 aplicações feitas com vibe coding, construídas em plataformas como Lovable, Base44, Netlify e Replit, abertas a qualquer pessoa na web. Cerca de 5.000 delas estavam a expor dados sensíveis, incluindo registos médicos, dados financeiros e estratégia interna de empresas (Axios, 2026).

A CodeScene deixa um aviso para quem deixou de ler o código. Um estudo com revisão por pares que publicou concluiu que os assistentes de programação com IA aumentam o risco de defeitos em pelo menos 30 % em código pouco saudável (CodeScene, 2026), e o próprio white paper da empresa aponta para 60 % ou mais. Quanto mais desorganizada fica uma base de código, pior o agente trabalha nela. Cada alteração não revista deixa o código um pouco mais desorganizado, por isso as equipas que deixam o agente trabalhar sem controlo estão a dificultar-lhe o trabalho futuro.

Como é que os maintainers de open source estão a reagir à IA?

Vários projetos importantes restringiram ou proibiram contribuições feitas com IA, porque os maintainers não conseguem acompanhar o volume de submissões de baixa qualidade.

• curl manteve um programa de bug bounty desde 2019 e pagou mais de 100.000 dólares por 87 vulnerabilidades confirmadas. Em 2025, cerca de 20 % das submissões eram lixo gerado por IA (Daniel Stenberg, 2025), e os maintainers não conseguiam dar conta do volume de relatórios maus. O bug bounty terminou a 31 de janeiro de 2026 (Daniel Stenberg, 2026).
• Ghostty, o terminal mantido por Mitchell Hashimoto, só aceita agora código gerado por IA de contribuidores externos para trabalho que os maintainers já tenham aprovado. Tudo o resto é fechado, e quem submete contribuições de IA más é banido. Hashimoto escreveu que a IA tinha «aumentado 10x a contagem de contribuições "más", se não mais» (Ghostty, 2026).
• Godot proibiu agentes autónomos, vibe coding e quantidades substanciais de código gerado por IA em junho de 2026, permitindo apenas pequenas tarefas assistidas, como o autocompletar de código: «A IA não pode assumir responsabilidade, e não podemos confiar que quem usa IA intensivamente perceba o seu código o suficiente para o corrigir» (Godot Foundation, 2026).
• Rust adotou uma política sobre LLM para o repositório rust-lang/rust em agosto de 2026: «Não há problema em usar LLM para responder a perguntas, analisar, destilar, refinar, verificar, sugerir, rever. Mas não para criar» (Rust Blog, 2026).
• GitHub lançou definições de repositório que permitem aos maintainers desativar os pull requests ou restringi-los a colaboradores (GitHub, 2026), e mais tarde um limite para o número de PRs abertos que um contribuidor pode ter (GitHub, 2026).

O que faz a IA às competências dos programadores júniores?

Para os júniores, o custo é a competência. Na minha experiência, os júniores que se apoiam na IA têm muitas vezes dificuldades com os fundamentos, e agora há investigação sobre isso, parte dela das próprias empresas de IA.

A Anthropic fez um ensaio aleatorizado com 52 engenheiros, na maioria júniores, a aprender o Trio, uma biblioteca assíncrona de Python que nunca tinham usado. O grupo que usou IA teve 50 % num questionário de compreensão feito depois. O grupo que programou à mão teve 67 %. O grupo com IA foi só cerca de dois minutos mais rápido, uma diferença que não foi estatisticamente significativa (Anthropic, 2026). Perderam compreensão e não ganharam velocidade mensurável em troca. Analisei esse estudo em detalhe em Ainda deves escrever código à mão?, incluindo as formas de usar a IA que mantiveram as notas altas. Para engenheiros experientes que querem evitar o mesmo declínio, Como manter as tuas competências de programação afiadas quando a IA escreve o código mostra que competências se perdem primeiro e como praticá-las.

A IA pode escrever o código por ti, mas tudo o que está acima mostra porque é que alguém ainda tem de o perceber. Acho que os fundamentos importam mais agora do que antes. Construí o LevelUpGo em torno de escreveres Go tu próprio, desde a primeira linha até código de produção, com exercícios que só passam quando o teu código compila e os testes passam. A escolha da linguagem também ajuda. Porque é que o Go é a melhor linguagem para código escrito por IA explica como o compilador e as ferramentas do Go apanham mais erros de um agente antes de chegarem a produção.

As ferramentas de programação com IA causam burnout?

A investigação diz que podem causar, sobretudo através do aumento da carga de trabalho e das expectativas que as acompanham.

Investigadores da Oregon State University inquiriram 442 programadores profissionais sobre o uso de IA e o burnout. Concluíram que a adoção de IA generativa aumenta o burnout, sobretudo porque aumenta as exigências do trabalho: mais carga de trabalho e mais pressão organizacional (Feng et al., 2026). Dois participantes disseram-no sem rodeios. Um disse: «as ferramentas estão bem, o que fizeram às expectativas das chefias é absolutamente horrível.» Outro disse: «Avanço depressa com a IA e movo montanhas de trabalho, mas estou a perder a paixão pelo trabalho.»

Investigadores da UC Berkeley passaram de abril a dezembro de 2025 dentro de uma empresa tecnológica dos EUA com cerca de 200 funcionários, a observar como as pessoas trabalhavam de facto com IA (Harvard Business Review, 2026). O trabalho cresceu de três formas:

• Expansão das tarefas. Como a IA conseguia preencher o que as pessoas não sabiam, estas começaram a assumir trabalho que nunca tinha sido delas.
• Fronteiras esbatidas. Começar uma tarefa ficou tão barato que o trabalho escorregou para o almoço, as reuniões e as noites.
• Mais multitarefa. As pessoas escreviam código à mão enquanto a IA fazia outra versão, corriam vários agentes ao mesmo tempo e reabriam tarefas antigas porque a IA agora as conseguia resolver, sem que ninguém lho pedisse.

Os investigadores descrevem um ciclo. A IA acelera algumas tarefas, o que aumenta as expectativas de velocidade, o que leva os trabalhadores a depender ainda mais da IA. Um engenheiro do estudo resumiu assim: «Tinhas pensado que talvez... pudesses trabalhar menos. Mas afinal não trabalhas menos. Trabalhas o mesmo ou até mais.»

A minha opinião

A IA pode trazer valor real e tornar-nos mais produtivos. Uso-a todos os dias. Mas não é a solução para tudo.

O que me impressionou nestes estudos foi o quanto correspondem ao que vejo no trabalho. Em todos os meus anos como engenheiro de software, nunca senti que o software em geral tivesse tão pouca qualidade como agora. Para mim, isso quer dizer que ainda não encontrámos o equilíbrio entre velocidade e qualidade, e acho que a qualidade importa mais do que a velocidade.

Por isso, trato a IA como uma ferramenta que comete muitos erros. Revejo o que escreve em vez de confiar nela, e dou-lhe apenas as permissões de que a tarefa precisa, porque não se consegue proteger a IA com prompts.

Depois de olhar para todos estes dados, continuo a perguntar-me se o custo é maior do que o valor que estas ferramentas devolvem. Ainda não tenho uma resposta definitiva. Mas tenho quase a certeza de que é muito mais do que o preço da subscrição.

Perguntas frequentes

Quais são os maiores riscos das ferramentas de programação com IA?

Os maiores riscos são código que passa na revisão mas falha em produção, agentes com acessos a mais a apagar dados, uma fila de revisões que leva a verificações menos cuidadosas, vulnerabilidades de segurança e perda de competências nos programadores que delegam a sua aprendizagem. No inquérito da New Relic de 2026, 82 % dos líderes tecnológicos conseguiram apontar uma falha em produção causada por código de IA nos seis meses anteriores (New Relic, 2026).

Porque é que o código gerado por IA falha em produção?

O agente não sabe como o teu sistema se comporta em produção. Não consegue ver padrões de tráfego, dias de muito movimento nem porque é que o código existente trata um caso limite daquela forma, e raramente para para perguntar. Os diffs grandes de IA também levam os revisores a ler na diagonal, por isso essas lacunas acabam aprovadas.

Como impedes um agente de IA de apagar dados de produção?

Limita aquilo a que pode chegar. Dá aos agentes credenciais separadas e restritas por ambiente, nunca partilhes armazenamento nem backups entre produção e staging, mantém o estado do Terraform num armazenamento remoto bloqueado e exige que uma pessoa aprove cada comando destrutivo. As instruções num prompt não são uma fronteira de segurança.

O código gerado por IA é seguro?

Não por omissão. O Vibe Security Radar da Georgia Tech associou 35 CVE a código escrito por IA só em março de 2026, e o fundador do projeto estima que o número real seja cinco a dez vezes superior (Infosecurity Magazine, 2026). Revê linha a linha a autenticação, a autorização, os pagamentos e tudo o que lide com dados de utilizadores.

Os programadores júniores devem usar ferramentas de programação com IA?

Usa-as para explicar conceitos e erros, não para escrever código que ainda não percebes. No ensaio da Anthropic de 2026, os júniores que aprenderam uma biblioteca nova com IA tiveram menos 17 pontos em compreensão e não foram significativamente mais rápidos (Anthropic, 2026).

Fontes

• New Relic, 2026 State of AI Coding press release (junho de 2026)
• Stella Laurenzo, Claude Code is unusable for complex engineering tasks with the Feb updates, GitHub issue #42796 (abril de 2026)
• Anthropic, April 23 postmortem (abril de 2026)
• The Register, Cursor Opus agent snuffs out startup's production database (abril de 2026)
• Alexey Grigorev, How I dropped our production database (março de 2026)
• The Decoder, AWS AI coding tool decided to delete and recreate a customer-facing system (fevereiro de 2026)
• Amazon, Response to the Financial Times on the AWS service outage (fevereiro de 2026)
• Nx, S1ngularity: what happened, how we responded, what we learned (2025)
• StepSecurity, Popular Nx build system package compromised with data-stealing malware (agosto de 2025)
• Wiz, s1ngularity's aftermath: AI, TTPs, and impact in the Nx supply chain attack (setembro de 2025)
• Socket, SANDWORM_MODE: npm worm hijacks CI workflows and poisons AI toolchains (fevereiro de 2026)
• Faros AI, The AI Acceleration Whiplash: ten takeaways (abril de 2026)
• Yu et al., Habituation at the Gate: Rising Approval and Declining Scrutiny in Human Review of AI Agent Code (junho de 2026)
• Sonar, 96% don't fully trust AI output, yet only 48% verify it (janeiro de 2026)
• Microsoft .NET Blog, Ten months with Copilot coding agent in dotnet/runtime (março de 2026)
• Georgia Tech, Bad Vibes: AI-generated code is vulnerable, researchers warn (abril de 2026)
• Infosecurity Magazine, Researchers sound the alarm on vulnerabilities in AI-generated code (março de 2026)
• GitGuardian, The State of Secrets Sprawl 2026 (março de 2026)
• Axios, Thousands of AI-built apps exposed sensitive corporate and personal data (maio de 2026)
• CodeScene, AI coding assistants increase defect risk by 30% in unhealthy code (janeiro de 2026)
• Daniel Stenberg, Death by a thousand slops (julho de 2025) e The end of the curl bug-bounty (janeiro de 2026)
• Ghostty, Updated AI usage policy for contributions, PR #10412 (janeiro de 2026)
• Godot Foundation, Changes to our contribution policies (junho de 2026)
• Rust Blog, rust-lang/rust is adopting an LLM policy (agosto de 2026)
• GitHub Changelog, New repository settings for configuring pull request access (fevereiro de 2026) e Limit open pull requests for users without write access (junho de 2026)
• Anthropic, How AI assistance impacts the formation of coding skills (janeiro de 2026)
• Feng, Afroz e Sarma, From Gains to Strains: Modeling Developer Burnout with GenAI Adoption, ICSE-SEIS (2026)
• Ranganathan e Ye, AI Doesn't Reduce Work, It Intensifies It, Harvard Business Review (fevereiro de 2026)