Todos os artigos

Blog

Melhor IA para programar: nenhuma escreve código seguro sem revisão

Claude, GPT-5, Gemini: a melhor IA para programar ainda deixa passar vulnerabilidades. O ranking em números e o que protege o seu código.

  • Por Azziz ERRIME
  • 11 min de leitura
Fila de máquinas de escrever antigas idênticas, como as candidatas a melhor IA para programar, com uma única folha levantada e riscada a vermelho

TL;DR

  • Em matéria de segurança, nenhum modelo torna a revisão desnecessária, e a escolha do modelo não substitui uma code review focada na segurança.
  • Segundo a Veracode, a melhor IA para programar do ranking produz código seguro em 72 % das tarefas, e o Claude Sonnet 4.5 em 50 %.
  • Eu escolheria o modelo pela produtividade da equipa e concentraria o esforço de segurança na code review.

Em março de 2025, um investigador analisa 1 645 aplicações geradas com IA e encontra 170 cuja base de dados responde a qualquer pessoa. Não encontrei em lado nenhum que modelo escreveu esse código. E, no entanto, é a primeira pergunta que se faz quando se procura a melhor IA para programar. Em termos de segurança, a resposta nada diz sobre o que acontece ao código depois de gerado.

Nos dias 20 e 21 de março de 2025, Matt Palmer passa a pente fino projetos publicados com o Lovable, um serviço que gera aplicações web com IA. Em 1 645 projetos, conta 303 pontos de acesso expostos em 170 deles. Avisa a empresa no dia 21. Depois, num texto publicado mais tarde, descreve o que lá se podia ler: endereços de e-mail, números de telefone, informações de pagamento e chaves de API de serviços de terceiros.

Em abril, o Lovable lança uma versão 2.0 equipada com um scanner de segurança. A 14 de abril, um engenheiro da Palantir dá com a mesma falha por conta própria e publica-a no X. A 29 de maio, a falha recebe um identificador público, CVE-2025-48757. Matt Palmer critica o novo scanner por se ficar pela presença de uma regra de proteção: nas palavras dele, o scanner «merely checks for the existence of any RLS policy, not its correctness».

As aplicações funcionavam, os ecrãs apareciam, e a falha só se via se alguém a fosse procurar. Antes de comparar modelos, tenho esta cena presente: a pergunta útil diz também respeito ao que se faz ao código depois de escrito.

Uma base de dados aberta não se vê em nenhuma demonstração

A regra que faltava nestas aplicações chama-se RLS, de Row Level Security. Definida na base de dados, decide que linhas cada utilizador tem o direito de ler. Sem ela, a interface pode mostrar a cada pessoa apenas os seus dados, enquanto a base, por trás, responde a todas as perguntas que lhe fazem.

Na prática, o atacante não tem nada para forçar. Abre a aplicação no browser e observa os pedidos enviados à base de dados. Identifica o endereço e a chave pública que servem para a consultar e reenvia o pedido, agora a solicitar a tabela inteira, que a base devolve se nenhuma regra filtrar.

Uma falha deste tipo é uma ausência. Falta uma linha de configuração, e nenhum teste funcional a exige, já que tudo funciona. É um defeito que a geração de código produz em silêncio, porque não estraga nada de visível. Resta saber se o modelo mais bem classificado produz menos defeitos destes do que os outros, e sobre isso há medições.

A melhor IA para programar ainda falha 28 % das tarefas de segurança

A Veracode, fornecedora de ferramentas de segurança aplicacional, submete regularmente os principais modelos à mesma bateria de tarefas de programação. Cada tarefa expõe o código a uma vulnerabilidade conhecida, e a Veracode verifica se o código produzido a evita. A atualização publicada a 18 de novembro de 2025 dá o ranking abaixo. É o último ranking por modelo que consegui ler. A medição de março de 2026 só apresenta uma média.

Modelo Percentagem de tarefas em que o código produzido é seguro
GPT-5 Mini 72 %
GPT-5 (com raciocínio) 70 %
Gemini 2.5 Pro 59 %
Grok 4 55 %
GPT-5-chat (sem raciocínio) 52 %
Gemini 2.5 Flash 51 %
Qwen3 Coder 50 %
Claude Sonnet 4.5 50 %
Claude Opus 4.1 49 %

O topo da tabela pertence aos modelos que raciocinam antes de responder. Na mesma família, o GPT-5 passa de 52 % sem raciocínio para 70 % com raciocínio. A Veracode explica-o com uma imagem que me parece certeira: as etapas de raciocínio «function like an internal code review». O modelo compara várias formas de escrever a função e descarta as menos seguras antes de responder.

Para quem procura a melhor IA para programar apenas com este critério, a tabela dá uma indicação de compra. Lida com atenção, deixa duas perguntas em aberto. Quanto vale o código dos 28 % de tarefas que até o primeiro classificado falha? E o que mede exatamente este ranking, que só olha para vulnerabilidades conhecidas em tarefas escolhidas de antemão?

Um modelo melhor no benchmark pode introduzir bugs mais graves

A Sonar, fornecedora de ferramentas de análise de código, pôs vários modelos a resolver exercícios em Java e analisou depois o código obtido. O relatório de 13 de agosto de 2025 aponta um paradoxo. Do Claude 3.7 Sonnet para o Claude Sonnet 4, a pontuação no benchmark sobe. Ainda assim, os bugs que o novo modelo introduz têm uma probabilidade mais de 93 % superior de ser classificados como BLOCKER, a categoria de bloqueio.

O ranking da Veracode também não vê as dependências. Uma IA que gera código propõe também bibliotecas para instalar, e algumas não existem. O estudo de Spracklen e colegas, apresentado no USENIX Security em 2025, mede esses nomes inventados. Encontra 3,59 % entre os pacotes recomendados pelo GPT-4 Turbo, o valor mais baixo, 13,63 % no melhor modelo aberto, um DeepSeek, e 19,7 % em média. E 43 % desses nomes inventados repetem-se em dez execuções. Um atacante que identifique um nome inventado de forma recorrente pode publicar um pacote malicioso com esse nome e esperar que um programador o instale.

Por fim, o benchmark BaxBench faz a pergunta que falta aos outros dois. Põe onze modelos a escrever serviços completos, verifica que funcionam e depois ataca-os: cerca de metade dos programas funcionalmente corretos continuam exploráveis. A falha do Lovable pertence a esta família, a de um código que faz o que lhe pedem, e nada do que se esqueceram de lhe pedir.

Resta um argumento sério a favor do ranking: os modelos de raciocínio estão a progredir depressa, e bastaria seguir o primeiro classificado.

Duas pontes suspensas lado a lado, a mais bem acabada com um cabo principal partido

A mais bem acabada das duas foi a primeira a ceder.

Sem contar o raciocínio, nenhum modelo progrediu desde julho de 2025

O progresso dos modelos de raciocínio é real, e não o desvalorizo. Entre o GPT-5-chat e o GPT-5 com raciocínio, a diferença chega aos dezoito pontos. Para uma equipa que gera muito código, não é pouco.

O mesmo relatório descreve, ainda assim, um mercado parado: «Models from Anthropic, Google, Qwen, and xAI released between July and October 2025 did not show meaningful security improvements.» Os modelos destas empresas continuam agrupados entre 50 e 59 %, o intervalo já observado no verão. A medição seguinte, publicada a 24 de março de 2026, conta 55 % de tarefas que resultam em código seguro, números que «have barely budged» desde o primeiro relatório de 2025.

Vejo nisto um indício, não uma prova: o único ganho claro vem de uma etapa que a Veracode compara a uma revisão. Nenhum estudo que li mede o que uma revisão humana acrescenta a código gerado.

Falta ainda saber quem revê, e de que maneira.

Uma instrução de segurança muda o que o revisor vê

A tentação natural é pôr outra IA a rever o código de uma IA. Kim e colegas mediram até que ponto os modelos erram em conjunto, num trabalho apresentado na ICML em 2025. Num conjunto de dados de classificação, quando dois modelos erram ambos, cometem o mesmo erro em cerca de 60 % dos casos. Este número só vale para esse conjunto de dados. Basta para me fazer duvidar que um segundo modelo veja o que o primeiro deixou escapar.

A revisão humana tem o seu próprio ponto fraco, e corrige-se com facilidade. Pedir explicitamente a um revisor que olhe para a segurança multiplica por oito a probabilidade de encontrar a falha, segundo Braz e colegas, em código escrito por pessoas.

Na prática, uma code review focada na segurança, aplicada a código gerado por IA, procura primeiro o que falta, antes do que está escrito. Uma regra de acesso em cada tabela, uma validação em cada entrada, uma dependência que existe mesmo e que é realmente aquela que se julga. Expliquei num artigo anterior porque é que a code review já não acompanha o ritmo da IA.

Porta de cofre entreaberta, com a fechadura presente mas o trinco recolhido

A fechadura está lá. Ninguém verificou se estava trancada.

Escolher a melhor IA para programar por um ranking é verificar que uma regra existe

Segundo Matt Palmer, o scanner do Lovable verificava que existia uma regra de proteção, sem verificar se ela protegia. Escolher a melhor IA para programar com base num ranking, e depois confiar nessa escolha, assenta no mesmo atalho. Confirma-se a presença de uma garantia, sem medir o efeito que tem no seu código.

Eu escolheria o modelo pela produtividade da equipa, pelas linguagens que usa e pelo sítio para onde vão os seus dados, e poria noutro lado o esforço de segurança do código:

  • uma linha no template de pull request que peça explicitamente para rever a segurança, já que essa instrução, por si só, multiplica a deteção;
  • uma verificação de cada dependência acrescentada por um modelo: confirmar que o pacote existe e que é o certo;
  • uma revisão que comece pelo que falta, regras de acesso e validações, antes do que está escrito;
  • um novo olhar sobre o ranking a cada trimestre, sem fazer dele uma política.

É também o que estou a medir neste momento: o que os programadores detetam, ou deixam passar, quando reveem código escrito por uma IA. Os modelos mudam mais depressa do que os hábitos de revisão.

Mantenho uma reserva. Os modelos de raciocínio ganharam dezoito pontos na Veracode, e nada impede que a geração seguinte torne a revisão menos necessária. Mudarei de opinião quando uma medição independente o mostrar. Até lá, continuo a rever.

Perguntas frequentes sobre a melhor IA para programar

Qual é a melhor IA para programar?

Em segurança, nenhuma se destaca o suficiente para tornar a revisão desnecessária. Na medição publicada pela Veracode a 18 de novembro de 2025, o GPT-5 Mini produz código seguro em 72 % das tarefas e o GPT-5 em 70 %. O Claude Sonnet 4.5 e o Qwen3 Coder ficam nos 50 %. Em produtividade, a melhor IA para programar depende das suas linguagens e das suas ferramentas: teste-a no seu próprio código.

Claude ou ChatGPT para programar?

No duelo Claude vs ChatGPT, a medição da Veracode dá 70 % de tarefas seguras ao GPT-5 com raciocínio e 50 % ao Claude Sonnet 4.5. Sem raciocínio, o GPT-5-chat desce para 52 %, o que mostra que a diferença depende mais do modo do que da marca. As duas famílias exigem uma revisão focada na segurança.

O código gerado por IA é seguro?

Não por defeito. Segundo a medição da Veracode publicada a 24 de março de 2026, só 55 % das tarefas de geração resultam em código seguro, uma taxa que quase não mexeu desde 2025. O benchmark BaxBench conclui que cerca de metade dos programas funcionalmente corretos continuam exploráveis. O código gerado por IA tem de passar por uma code review focada na segurança, tal como o código escrito por pessoas.

O Copilot é seguro?

O estudo de Pearce e colegas, publicado em 2021, encontrava cerca de 40 % de programas vulneráveis entre 1 689 programas gerados pelo Copilot em 89 cenários. Uma replicação mais recente, feita com versões mais recentes da ferramenta, mede 27,25 %. O progresso é real, e mais de um programa em cada quatro continua vulnerável nestes cenários.

Fontes