A proliferação de ferramentas de IA generativa criou uma situação paradoxal no mercado de tecnologia: enquanto plataformas como GitHub Copilot, Claude Code e Cursor democratizaram a capacidade de gerar código funcional, observa-se um aumento significativo na busca por líderes técnicos experientes. Empreendedores de diversas áreas — do setor jurídico ao comercial — utilizam assistentes de IA para desenvolver aplicações que, à primeira vista, funcionam adequadamente. O problema surge na etapa seguinte: ao tentar escalar esses projetos ou prepará-los para ambiente de produção com usuários reais, surgem limitações técnicas que ferramentas automatizadas não conseguem resolver, exigindo a intervenção de profissionais de engenharia de software qualificados.

Essa tendência não indica que a engenharia de software está sendo automatizada. Pelo contrário, evidencia uma distinção fundamental que a indústria de tecnologia está apenas começando a compreender completamente: existe uma diferença crítica entre programar e construir software.

A distinção entre programação e engenharia de software

Um estudo da METR de 2025 demonstrou que desenvolvedores experientes de código aberto levam 19% mais tempo para completar tarefas quando utilizam ferramentas de IA em comparação com trabalhar sem assistência artificial. Este resultado contraintuitivo revela algo importante sobre a natureza do desenvolvimento de software profissional.

Enquanto CEOs de big tech fazem declarações ambiciosas sobre as capacidades de programação da IA, pesquisas com engenheiros de software mostram que apenas cerca de metade dos entrevistados confia “moderadamente” nas respostas da IA, enquanto 30% escolhem “pouco” ou “nada”. Cada linha de código gerada por IA ainda é revisada por humanos, e alguns engenheiros relatam dificuldades ao desembaraçar código gerado por IA que colegas lhes entregaram.

As melhores ferramentas de IA para desenvolvedores em 2025 são Claude Code, Aider, Cursor, Windsurf e GitHub Copilot. Essas plataformas são excepcionalmente eficazes em resolver problemas isolados e bem definidos. Segundo Jared Friedman, managing partner da Y Combinator, quase um quarto das startups o programa de incubação W25 possuem bases de código quase inteiramente geradas por IA. No entanto, existe uma barreira significativa entre gerar código funcional e construir sistemas de software robustos e escaláveis.

A sabedoria antiga da indústria permanece válida: programar é fácil, engenharia de software que é difícil. Os grandes modelos de linguagem de grande escala (LLMs) já conseguem automatizar grande parte da programação. Ferramentas como GPT-5 e similares resolvem problemas isolados com uma taxa de sucesso considerável. Porém, programação não é o que a maioria dos profissionais está sendo paga para fazer. Construir uma aplicação pronta para produção não é programação — é engenharia de software.

A transição de programação para engenharia de software ocorre precisamente no momento em que se tenta transformar uma demonstração em um produto real. É exatamente nesse ponto que empreendedores não técnicos procuram cofundadores técnicos para suas startups, munidos de protótipos funcionais que não podem ser facilmente transformados em produtos comerciais.

O desafio da complexidade e manutenibilidade

Código complexo frequentemente requer 2,5 a 5 vezes mais esforço de manutenção comparado a bases de código mais simples do mesmo tamanho. Estudos mostram que métricas automatizadas de saúde de código podem detectar módulos propensos a defeitos melhor que revisões manuais.

Quando se escreve software profissionalmente, a tarefa principal é lidar com complexidade. O software de produção médio executa um conjunto de tarefas fáceis. O desafio está em fazer centenas dessas tarefas fáceis simultaneamente, mantendo o sistema inteiro gerenciável e manutenível. Reformulando no contexto atual: é uma coisa demonstrar um recurso; é algo muito mais difícil construir esse recurso de maneira que suporte integração, expansão e manutenibilidade de longo prazo.

A complexidade de software se manifesta de várias formas. Há a complexidade essencial, inerente ao problema que o software tenta resolver, geralmente inevitável mas gerenciável através de design cuidadoso e abstração. E há a complexidade acidental, introduzida por ferramentas, tecnologias e escolhas de implementação, que pode ser reduzida ou eliminada por meio de refatoração e melhores práticas de design.

Atalhos técnicos tomados para cumprir prazos acumulam dívida técnica ao longo do tempo, adicionando complexidade e tornando mudanças futuras mais difíceis. Alta complexidade de código apresenta desafios significativos, mas com diligência na análise de complexidade e medidas apropriadas para reduzi-la, engenheiros de software podem melhorar significativamente o desempenho e a manutenção de sistemas.

O relatório DORA 2025 do Google revelou que 90% dos entrevistados adotaram ferramentas de IA para tarefas como escrever código e analisar dados. Universidades como a Carnegie Mellon University criaram cursos experimentais sobre ferramentas de IA para desenvolvimento de software, onde estudantes aprendem a aplicar uma mentalidade de engenharia de software para tornar as ferramentas de IA mais confiáveis, em vez de simplesmente “vibe code” e esperar que funcione.

Por que IA não consegue construir software (ainda)?

A razão pela qual a IA não consegue construir software completo pode estar relacionada à natureza do trabalho de engenharia de software. Software de produção não se trata de realizar um único feito impressionante; trata-se de executar centenas de tarefas relativamente simples simultaneamente, enquanto permanece manutenível, escalável e seguro, antecipando casos extremos, lidando com erros de forma eficiente e garantindo integração perfeita com outros sistemas.

Quando se examina o código que essas pessoas enviam, percebe-se que “tornar o app pronto para produção” realmente significa descartar tudo e começar do zero. Essa realidade fala muito sobre o momento atual da tecnologia e seus limites práticos.

Muitos empreendedores estão descobrindo que seus aplicativos criados por “vibe coding”, embora funcionais em ambiente de demonstração, desmoronam quando confrontados com as realidades do uso no mundo real, atingindo uma barreira — o ponto onde transformar uma prova de conceito em produto sustentável requer um nível de profundidade técnica que a IA simplesmente não pode fornecer.

Os desenvolvedores mais valiosos no futuro próximo não serão apenas programadores proficientes, mas “wranglers de complexidade” — indivíduos que podem navegar por ambiguidade, projetar sistemas robustos e integrar ferramentas de IA em um fluxo de trabalho de desenvolvimento coeso. A habilidade de entender o contexto de negócios, antecipar necessidades futuras e tomar decisões técnicas estratégicas será mais crítica do que nunca.

Ferramentas como Cursor se destacam em tarefas sérias de engenharia, incluindo geração de APIs backend escaláveis usando ferramentas como Prisma e MongoDB, sendo adequadas para sistemas de nível empresarial e modernização de bases de código legadas. Contudo, nenhuma ferramenta de IA substitui revisão humana crítica — antes do lançamento, é necessário auditar manualmente o produto quanto a segurança, conformidade, desempenho e casos extremos, especialmente em domínios regulamentados ou sensíveis ao usuário.

Ilustração mostra mulher escrevendo num notebook e um robô a auxiliando
Freepik/pikisuperstar

Métricas técnicas que revelam a qualidade do código

Para avaliar objetivamente a qualidade de código, engenheiros de software utilizam métricas técnicas específicas que vão além da mera contagem de linhas. A Complexidade Ciclomática, desenvolvida por Thomas McCabe em 1976, é uma das mais importantes. Esta métrica quantifica o número de caminhos linearmente independentes através do código-fonte de um programa, baseando-se em pontos de decisão como declarações if-else, loops e estruturas de controle.

A complexidade ciclomática é calculada usando o grafo de fluxo de controle do programa, onde cada nó representa um bloco indivisível de comandos e as arestas conectam comandos que podem ser executados sequencialmente. Um código sem declarações condicionais teria complexidade 1, enquanto cada decisão adicional incrementa esse valor. O limite recomendado historicamente é 10, embora valores até 15 possam ser aceitáveis para projetos com equipes experientes e processos rigorosos de teste.

Organizações como Microsoft incorporam limites de complexidade ciclomática em suas diretrizes de desenvolvimento, enquanto a NASA utiliza essa métrica em seus padrões para código de missões críticas. A razão é simples: quando se combina complexidade ciclomática com linhas de código, obtém-se uma visão muito mais clara do potencial de erros, já que módulos com alta complexidade e grande tamanho tendem a ter a menor confiabilidade.

No entanto, a complexidade ciclomática possui limitações significativas. Código com baixa complexidade ciclomática ainda pode ser difícil de manter se sofrer de nomenclatura pouco clara de variáveis, documentação inadequada ou lógica confusa. Por isso, métricas complementares como a Complexidade Cognitiva ganharam relevância. Diferentemente da ciclomática, a Complexidade Cognitiva penaliza estruturas aninhadas mais pesadamente do que sequenciais, alinhando-se melhor com como desenvolvedores processam código mentalmente.

Outras métricas essenciais incluem o Índice de Manutenibilidade, que combina complexidade ciclomática, linhas de código e volume de Halstead para produzir uma pontuação entre 0 e 100, e a Densidade de Defeitos, que mede a quantidade de bugs por mil linhas de código. Código complexo frequentemente requer de 2,5 a 5 vezes mais esforço de manutenção comparado a bases de código mais simples do mesmo tamanho.

O principal desafio com código gerado por IA é que ele frequentemente otimiza para funcionalidade imediata, ignorando completamente essas métricas de qualidade. Ferramentas de IA não consideram dívida técnica, aderência a padrões de projeto ou impacto na manutenibilidade de longo prazo ao gerar código.

Casos práticos de falhas em produção causadas por problemas de qualidade

O ano de 2024 foi marcado por algumas das falhas de software mais catastróficas da história recente, evidenciando precisamente os problemas que código mal planejado pode causar em ambientes de produção. Essas falhas ilustram perfeitamente a diferença entre código funcional e software robusto.

Em julho de 2024, uma atualização de rotina da CrowdStrike transformou-se em um pesadelo de cibersegurança quando sua atualização do Falcon Sensor causou falhas em 8,5 milhões de dispositivos Windows em todo o mundo, deixando setores críticos em caos com tempo de inatividade de até 72 horas para grandes organizações. As perdas financeiras foram estimadas em US$ 3 bilhões, com impactos em bancos (30%), saúde (25%) e transporte (20%). Uma atualização mal configurada entrou em conflito com configurações existentes do Windows, levando a travamentos generalizados.

Leia também: Apagão cibernético global afeta voos e serviços bancários

Em março de 2024, o McDonald’s sofreu uma falha global de sistema de TI que afetou seus sistemas de pedidos em filiais no mundo todo, ocorrida durante uma mudança de configuração feita por um provedor externo. Embora a falha tenha sido corrigida em horas em muitos mercados, os danos reputacionais e empresariais já estavam feitos. Este caso destacou a importância de testes minuciosos antes de fazer atualizações e mudanças em sistemas de produção, especialmente em sistemas críticos dos quais milhões de usuários dependem.

As estatísticas gerais sobre falhas de projetos de software são igualmente alarmantes. De acordo com relatório recente do The Standish Group, 31,1% dos projetos de software são cancelados antes da conclusão, e 52,7% excedem seus orçamentos originais em 189%. A má coleta de requisitos é citada como causa principal em 39,03% das falhas, enquanto 57% dos projetos que falham são atribuídos a quebras de comunicação. Além disso, 29% das falhas são devido a testes pobres ou inadequados, destacando uma lacuna crítica nas práticas de garantia de qualidade.

O impacto do código gerado por IA nesse cenário é preocupante. A equipe da Sonar, provedora de produtos de qualidade e segurança de código, ouviu histórias em primeira mão de interrupções consistentes até mesmo em grandes instituições financeiras, onde desenvolvedores responsáveis pelo código culpam a IA. Pesquisadores da Universidade Bilkent descobriram que as versões mais recentes de ChatGPT, GitHub Copilot e Amazon CodeWhisperer geraram código correto apenas 65,2%, 46,3% e 31,1% das vezes, respectivamente.

Pesquisadores da GitClear inspecionaram 153 milhões de linhas de código e notaram um aumento na quantidade de código que teve que ser corrigido ou revertido em menos de duas semanas após ser escrito, um fenômeno chamado “code churn” que indica instabilidade. Eles projetam que instâncias de “code churn” dobrariam em 2024 em comparação com a linha de base pré-IA de 2021, e que mais de 7% de todas as mudanças de código serão revertidas dentro de duas semanas.

Segundo estudo da CodeFlash apresentado na Conferência Infobip Shift, 62% das otimizações de código geradas por IA contêm bugs. A CodeFlash testou 100.000 funções de código aberto e os resultados foram perturbadores: dos 38% corretos, 73% resultaram em ganhos abaixo de 5% ou até redução de desempenho.

O que esses estudos não revelam é que a verdadeira dificuldade não é gerar o código, é entendê-lo quando algo quebra. Quando há uma falha de produção, históricos de commit vagos e sugestões genéricas de IA não ajudam a encontrar a raiz do problema. A falta de transparência e compreensão profunda do sistema mata a velocidade da equipe quando mais importa.

Esses casos demonstram que ferramentas de IA, embora úteis para acelerar o desenvolvimento inicial, introduzem riscos significativos quando o código gerado não passa por revisão rigorosa e testes abrangentes antes de chegar à produção. A engenharia de software bem-sucedida exige não apenas código funcional, mas código resiliente, seguro e de baixa manutenção.

IA