A primeira onda de adoção de IA no desenvolvimento de software program foi sobre produtividade. Nos últimos
anos, a IA pareceu um truque de mágica para desenvolvedores de software program: fazemos uma pergunta e, aparentemente,
código perfeito aparece. Os ganhos de produtividade são inegáveis e uma geração de desenvolvedores está
agora crescendo com um assistente de IA como companheiro constante. Este é um grande salto em frente
o mundo do desenvolvimento de software program e veio para ficar.
A próxima onda – e muito mais crítica – será a gestão de riscos. Embora os desenvolvedores tenham
adotaram grandes modelos de linguagem (LLMs) por sua notável capacidade de resolver desafios de codificação,
é hora de conversar sobre a qualidade, a segurança e o custo a longo prazo do código que esses
modelos produzem. O desafio não é mais fazer com que a IA escreva um código que funcione. É sobre
garantindo que a IA escreva códigos duradouros.
E até agora, o tempo gasto pelos desenvolvedores de software program para lidar com as questões de qualidade e risco
gerado por LLMs não tornou os desenvolvedores mais rápidos. Na verdade, desacelerou o seu desempenho geral
trabalho em quase 20%, de acordo com pesquisa do METR.
A dívida de qualidade
O primeiro e mais difundido risco da precise abordagem da IA é a criação de uma enorme e duradoura
dívida técnica a prazo em qualidade. O foco da indústria em benchmarks de desempenho incentiva
modelos para encontrar uma resposta correta a qualquer custo, independentemente da qualidade do código em si. Enquanto
modelos podem alcançar altas taxas de aprovação em testes funcionais, essas pontuações não dizem nada sobre o
estrutura ou capacidade de manutenção do código.
Na verdade, uma análise profunda de seus resultados em nosso relatório de pesquisa, “The Coding Personalities of
Main LLMs”, mostra que, para cada modelo, mais de 90% dos problemas encontrados eram “cheiros de código” — a matéria-prima da dívida técnica. Esses não são bugs funcionais, mas são indicadores de problemas
estrutura e alta complexidade que levam a um custo whole de propriedade mais elevado.
Para alguns modelos, o problema mais comum é deixar para trás “código morto/não utilizado/redundante”.
o que pode ser responsável por mais de 42% dos seus problemas de qualidade. Para outros modelos, o principal problema é a
falha em aderir às “práticas recomendadas de design/estrutura. Isso significa que, embora a IA esteja acelerando
a criação de novos recursos, também está incorporando sistematicamente os problemas de manutenção de
o futuro em nossas bases de código hoje.
O déficit de segurança
O segundo risco é um défice de segurança sistémico e grave. Este não é um erro ocasional; é um
falta basic de consciência de segurança em todos os modelos avaliados. Isto também não é uma questão de
alucinações ocasionais, mas uma falha estrutural enraizada em seu design e treinamento. Luta de LLMs
para evitar falhas de injeção porque isso requer uma análise de fluxo de dados não native conhecida como
rastreamento de contaminação, que muitas vezes está além do escopo de sua janela de contexto típica. LLMs também geram segredos codificados — como chaves de API ou tokens de acesso — porque essas falhas existem em
seus dados de treinamento.
Os resultados são nítidos: todos os modelos produzem uma “porcentagem assustadoramente alta de vulnerabilidades com as classificações de gravidade mais altas”. Para o Llama 3.2 90B da Meta, mais de 70% das vulnerabilidades que ele introduz são da mais alta severidade “BLOCKER”. As falhas mais comuns em geral são vulnerabilidades críticas como “Path-traversal & Injection” e “Credenciais codificadas”. Isto revela uma lacuna crítica: o próprio processo que torna os modelos poderosos geradores de código também os torna eficientes na reprodução dos padrões inseguros que aprenderam a partir de dados públicos.
O paradoxo da personalidade
O terceiro e mais complexo risco vem da “codificação” única e mensurável dos modelos.
personalidades.” Essas personalidades são definidas por características quantificáveis como Verbosidade (a pura
quantity de código gerado), Complexidade (a complexidade lógica do código) e Comunicação
(a densidade dos comentários).
Diferentes modelos introduzem diferentes tipos de risco, e a procura de personalidades “melhores” pode, paradoxalmente, levar a resultados mais perigosos. Por exemplo, um modelo como o Claude Sonnet 4 da Anthropic, o “arquiteto sênior” introduz risco através da complexidade. Possui a habilidade funcional mais alta com uma taxa de aprovação de 77,04%. No entanto, ele consegue isso escrevendo uma enorme quantidade de código – 370.816 linhas de código (LOC) – com a pontuação de complexidade cognitiva mais alta de qualquer modelo, 47.649.
Essa sofisticação é uma armadilha, levando a uma alta taxa de simultaneidade difícil e bugs de threading.
Em contraste, um modelo como o OpenCoder-8B de código aberto, o “protótipo rápido” introduz risco
pela pressa. É o mais conciso, escrevendo apenas 120.288 LOC para resolver os mesmos problemas. Mas
esta velocidade tem o custo de ser uma “máquina de dívida técnica” com a maior densidade de emissões de todos os modelos (32,45 emissões/KLOC).
Este paradoxo da personalidade é mais evidente quando um modelo é atualizado. O mais novo Claude
O Sonnet 4 tem uma pontuação de desempenho melhor que seu antecessor, melhorando sua taxa de aprovação em 6,3%.
No entanto, esta personalidade “mais inteligente” é também mais imprudente: a percentagem dos seus bugs que são de
A gravidade do “BLOCKER” disparou em mais de 93%. A busca por um scorecard melhor pode criar um
ferramenta que é, na prática, um passivo maior.
Crescendo com IA
Este não é um chamado para abandonar a IA – é um chamado para crescer com ela. A primeira fase do nosso relacionamento com
AI foi uma maravilha de olhos arregalados. Esta próxima fase deve ser de pragmatismo lúcido.
Esses modelos são ferramentas poderosas e não substitutos para desenvolvedores de software program qualificados. A velocidade deles
é um trunfo incrível, mas deve ser combinado com a sabedoria, o julgamento e a supervisão humanos.
Ou, como afirmou um relatório recente do programa de investigação DORA: “O papel principal da IA no desenvolvimento de software program
desenvolvimento é o de um amplificador. Amplia os pontos fortes das organizações de alto desempenho
e as disfunções dos que estão em dificuldades.”
O caminho a seguir requer uma abordagem de “confiança, mas verificação” para cada linha de código gerado por IA. Nós
devemos expandir nossa avaliação desses modelos além dos benchmarks de desempenho para incluir o
atributos cruciais e não funcionais de segurança, confiabilidade e capacidade de manutenção. Precisamos escolher
a personalidade de IA certa para a tarefa certa — e construir a governança para gerenciar seus pontos fracos.
O aumento de produtividade proporcionado pela IA é actual. Mas se não tivermos cuidado, pode ser apagado pelo longo prazo
custo de manter o código inseguro, ilegível e instável que deixa em seu rastro.