Agentes de código para executivos · Capítulo 5 de 24 · 16 min
Medir o reflexo do agente antes de pagar para mudá-lo
Quatro números mostram se o comportamento padrão do agente mudou mesmo depois da promessa do fornecedor.
Este capítulo faz parte do curso gratuito Agentes de código para executivos. Para marcar como concluído e salvar o progresso, abra este capítulo na página do curso.
A alteração passou pela revisão de dois desenvolvedores, entrou na esteira, subiu para produção e ficou lá três semanas. A falha estava na primeira versão gerada pelo agente, e ninguém pediu que ela estivesse: o pedido descrevia apenas o que a funcionalidade deveria fazer. Em uma avaliação de mais de 150 modelos sobre 80 tarefas de código, 45% do que foi gerado continha vulnerabilidade conhecida quando o pedido não mencionava segurança, enquanto a correção de sintaxe passava de 95%.
O código compila, roda e faz o que foi pedido. O problema mora exatamente no que ninguém pediu.
Você decide aqui o que exigir de um fornecedor que promete mudar o comportamento padrão do agente: o que ele precisa mostrar antes e depois, e em quanto tempo.
O manual da empresa e a cultura que se observa no corredor
Toda empresa tem dois conjuntos de regras. Um está escrito no código de conduta, foi aprovado pelo comitê e assinado na admissão. O outro é o que as pessoas fazem quando o prazo aperta e ninguém está olhando, e é ele que explica o resultado do trimestre. Quando os dois divergem, o segundo ganha, porque é o segundo que está ligado ao que a empresa de fato premia. Com um modelo acontece a mesma coisa, e a divergência é mais fácil de medir: o pedido é o manual, e o comportamento observado é a cultura.
Onde a analogia para de valer: uma pessoa às vezes segue o valor declarado contra o próprio incentivo, por convicção, e em alguns casos você pode contar com isso. O modelo segue o incentivo, sempre. Não existe funcionário íntegro dentro do modelo, então não adianta apelar para o bom senso dele nem escrever um parágrafo pedindo responsabilidade.
O comportamento que sobra quando o pedido cala tem nome. Chama-se política, e é o comportamento padrão do modelo, o que ele faz por reflexo quando ninguém especifica. Você não escolhe a política do modelo que contratou. Ela veio pronta do treino, é a maior parte do que você recebe, e nenhuma cláusula de contrato altera isso sozinha.
Em uma tarefa comum, o pedido cobre a funcionalidade. O reflexo cobre o resto: qual biblioteca usar, como tratar o erro, o que registrar em log, como guardar a credencial, o que fazer quando a entrada chega fora do formato. Nenhuma dessas decisões estava no pedido, e todas elas chegam à produção junto com a funcionalidade.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Aprovação em segurança do código gerado, por linguagem
| Linguagem | Aprovação em segurança | O que isso muda na sua decisão |
|---|---|---|
| Python | 62% | A melhor da amostra, e ainda assim quase quatro em cada dez entregas reprovam |
| C# | 58% | Perto da média, sem margem para dispensar conferência humana |
| JavaScript | 57% | Volume alto de código de tela, e a falha chega direto ao usuário final |
| Java | 29% | O pior caso por larga margem, e é onde mora o sistema de banco e de seguradora |
Mesma avaliação, mesmas tarefas. O que muda entre as linhas é a linguagem, não o modelo nem o pedido.
Fonte: Veracode, Spring 2026 GenAI Code Security Update, 24/03/2026
A mesma amostra quebrada por categoria de falha: o reflexo é bom onde existe material publicado e ruim onde não existe
86%
de aprovação em criptografia
a categoria mais documentada e mais repetida em tutorial
82%
de aprovação em injeção de SQL
vinte anos de material público sobre como evitar
15%
de aprovação em scripts injetados na página
mesmo modelo, mesma tarefa, outra categoria de falha
13%
de aprovação em injeção em log
a categoria com menos material publicado das quatro
Fonte: Veracode, Spring 2026 GenAI Code Security Update, 24/03/2026
Os dois pares de números dizem a mesma coisa por caminhos diferentes. O reflexo acerta onde existe muita coisa publicada e erra onde existe pouca. Ele imita o que está documentado, e imitar documentação é diferente de raciocinar sobre segurança. Daí sai uma consequência que quase ninguém coloca na conta: trocar de linguagem muda o risco mais do que trocar de fornecedor.
Falta a pergunta que todo comitê faz em seguida. Se a capacidade dos modelos subiu tanto entre 2025 e 2026, a segurança não deveria ter subido junto?
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
O formato mais caro de risco aparece quando a confiança sobe e a qualidade não. Quase 80% dos desenvolvedores acreditam que a IA gera código mais seguro do que humanos escrevem, e quem usa assistente mostrou-se ao mesmo tempo mais propenso a submeter código inseguro e mais confiante no que submeteu. Se a sua conferência depende da percepção de quem escreveu, ela já falhou antes de começar.
Verificação rápida
Um fornecedor promete mudar o comportamento padrão do seu agente e apresenta como prova um pedido muito melhor escrito, com uma seção de segurança de duas páginas. O que essa prova demonstra?
As quatro coisas que o agente decide sozinho, e o número que mede cada uma
- Como ele trata segurança quando ninguém pede: 55% de aprovação global, ou 45% das entregas com falha conhecida.
- Em que linguagem o risco se concentra: Java aprova 29%, contra 62% do Python, na mesma avaliação e nas mesmas tarefas.
- Que categoria de falha ele domina e qual ele ignora: 86% de aprovação em criptografia contra 13% em injeção em log.
- Quanto disso melhora sozinho na próxima versão do modelo: a faixa ficou em torno de 55% de 2025 até março de 2026.
Três perguntas para testar a decisão antes da próxima reunião: (1) Um fornecedor promete melhorar o comportamento padrão do seu agente em 90 dias. Que medição você exige antes de começar, e sobre quais tarefas? (2) O seu time vai delegar ao agente uma frente inteira escrita em Java. O que muda na sua exigência de conferência, e quem paga por essa mudança? (3) A pesquisa interna diz que o time confia no código gerado. Você trata isso como boa notícia ou como fator de risco, e o que faz na semana seguinte?
Exija do fornecedor os quatro números desta aula medidos antes e depois da mudança prometida, no mesmo lote de tarefas. Dê quinze dias úteis para a resposta. Proposta que chegar sem a medição de antes volta sem análise, e a renovação espera até ela chegar.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Explore os conceitos e compare abordagens em outros cursos. As conexões indicam assuntos relacionados; a sequência de estudo continua no índice do curso.
Conceitos deste capítulo
O mesmo assunto em outros cursos
- Engenharia de Software para ExecutivosFechar a porta dos fundos por onde entra o riscoExaminar conexões de Fechar a porta dos fundos por onde entra o risco
- Do Agile ao Agentic Operating ModelNinguém consegue provar que a entrega do agente funcionouExaminar conexões de Ninguém consegue provar que a entrega do agente funcionou
- Prompt Engineering para ExecutivosConter a injeção de prompt antes que ela alcance o agenteExaminar conexões de Conter a injeção de prompt antes que ela alcance o agente
- Frontends com VibecodingSupervisionar o modelo que opera o computadorExaminar conexões de Supervisionar o modelo que opera o computador