Recentemente me deparei com uma pesquisa conduzida por Nicholas Carlini que me fez parar e refletir com mais calma sobre o estágio real das IAs atuais. Para quem não conhece, Nicholas Carlini é pesquisador reconhecido na área de segurança e robustez de modelos de machine learning, com passagens por instituições como o Google e forte atuação em adversarial machine learning. Ele não é exatamente o tipo de pesquisador que se impressiona facilmente com hype. Pelo contrário: boa parte do trabalho dele, ao longo dos anos, foi justamente mostrar onde os modelos falham.
Dessa vez, o experimento foi direto ao ponto: pegar 16 modelos de IA diferentes e pedir que eles criassem um compilador C funcional.
Não era para escrever uma função simples. Não era para gerar um script trivial. Era para construir algo estruturalmente complexo: um compilador. Isso envolve parsing, análise léxica, análise sintática, geração de código, manipulação de memória, controle de tipos, semântica, e uma série de detalhes técnicos que qualquer desenvolvedor que já mexeu minimamente com compiladores sabe que são tudo, menos triviais.
A primeira coisa que me chamou atenção foi o desenho do experimento. Não se tratava de um prompt genérico do tipo “escreva um compilador em C”. A ideia era avaliar até que ponto os modelos conseguiam produzir um sistema coerente, minimamente funcional, capaz de traduzir código C para outra representação executável. Ou seja: sair do nível de snippet e ir para arquitetura de sistema.
E aqui começa a parte interessante.
O que a pesquisa mostra, na prática, é que existe uma diferença brutal entre gerar código plausível e gerar software correto. Muitos modelos conseguem produzir algo que, à primeira vista, parece sofisticado. Estrutura organizada, funções bem nomeadas, comentários coerentes, divisão em módulos. Mas quando você tenta compilar, executar ou validar o comportamento, os problemas aparecem: inconsistências internas, chamadas para funções inexistentes, suposições incorretas sobre tipos, lacunas lógicas.
Isso não é trivial. Estamos falando de modelos treinados com gigantescos volumes de código aberto, incluindo implementações reais de compiladores, parsers, interpretadores. Ainda assim, quando colocados na tarefa de construir um compilador do zero sob especificação, a maioria falha em produzir algo realmente funcional.
Esse tipo de experimento é importante porque ele tira a discussão do campo do marketing e leva para o campo da engenharia. Não importa se o código “parece bom”. A pergunta relevante é: ele funciona? Ele compila? Ele respeita a semântica da linguagem? Ele gera saída correta para um conjunto amplo de testes?
O que fica evidente é que modelos de linguagem não “entendem” compiladores no sentido clássico. Eles aprendem padrões estatísticos de como compiladores costumam ser escritos. Conseguem recombinar esses padrões de forma impressionante. Mas coerência global, manutenção de invariantes complexas e consistência ao longo de centenas ou milhares de linhas ainda são um grande desafio.
Ao mesmo tempo, eu não leio essa pesquisa como um argumento contra o uso de IA em desenvolvimento de software. Pelo contrário. Para mim, ela delimita claramente onde a IA é extremamente forte e onde ainda é frágil.
Para tarefas locais, bem definidas, com escopo controlado, os modelos são absurdamente produtivos. Gerar funções utilitárias, estruturar endpoints, criar testes unitários básicos, sugerir refatorações, documentar código existente — tudo isso já está em um patamar muito alto.
Mas quando entramos em sistemas complexos com múltiplas camadas de abstração, regras formais rígidas e necessidade de consistência estrutural profunda, o humano ainda é o arquiteto principal. A IA atua melhor como copiloto do que como engenheiro-chefe.
Outro ponto que considero central na pesquisa é o recorte metodológico. Avaliar 16 IAs diferentes evita a armadilha de focar em um único modelo específico. Não é sobre “qual modelo ganhou”. É sobre o padrão de comportamento que emerge quando colocamos LLMs diante de um problema formalmente exigente.
E o padrão é claro: quanto maior a exigência de coerência sistêmica, maior a taxa de falhas estruturais.
Isso conversa diretamente com algo que eu venho observando na prática. No dia a dia de desenvolvimento, especialmente em projetos maiores — como sistemas modulares com múltiplos apps, integrações, regras de negócio e camadas de persistência — a IA ajuda muito na aceleração, mas exige supervisão constante. Ela raramente mantém a integridade arquitetural sozinha ao longo de muitas interações.
O experimento com o compilador C é quase simbólico. Compiladores são, historicamente, um dos exemplos clássicos de software que exige rigor formal. Não há espaço para “quase certo”. Ou o parser reconhece corretamente a gramática ou não reconhece. Ou o código gerado é semanticamente válido ou não é.
Quando modelos falham nessa tarefa, isso não diminui sua utilidade. Mas deixa evidente que ainda estamos longe de uma autonomia plena para engenharia de sistemas complexos.
Também é interessante pensar no aspecto epistemológico. Um compilador envolve uma gramática formal, regras explícitas, transformações determinísticas. Modelos de linguagem operam por aproximação probabilística. Eles não executam prova formal de corretude. Eles estimam a próxima sequência de tokens mais plausível.
Essa diferença de natureza explica muita coisa.
Para mim, a grande contribuição da pesquisa de Nicholas Carlini não é provar que “IA não consegue”. É mostrar, de forma concreta e técnica, onde estão os limites atuais. E limites bem definidos são fundamentais para qualquer engenharia séria.
Estamos vivendo um momento em que há uma tendência natural ao exagero. De um lado, discursos dizendo que programadores serão substituídos em massa. De outro, resistência completa ao uso de IA. A realidade, como quase sempre, está no meio.
A IA é uma ferramenta de amplificação cognitiva extremamente poderosa. Mas não é, pelo menos ainda, um agente autônomo capaz de projetar, validar e garantir a corretude de sistemas complexos sem supervisão humana.
Se 16 IAs diferentes têm dificuldade real em criar um compilador C funcional sob critérios rigorosos, isso não significa que estamos no início da jornada. Significa que estamos em uma fase intermediária: já superamos tarefas triviais, mas ainda não dominamos coerência sistêmica profunda.
E isso, para mim, é um sinal de maturidade do debate.
Eu prefiro muito mais pesquisas como essa — objetivas, técnicas, reproduzíveis — do que narrativas baseadas em demonstrações isoladas. É assim que a área evolui: testando limites, medindo desempenho real, expondo falhas.
No fim, a lição que eu tiro é simples: use IA. Explore ao máximo. Mas mantenha senso crítico. Valide. Teste. Estruture. Arquitetura ainda é responsabilidade humana. Formalismo ainda é responsabilidade humana. Garantia de corretude ainda é responsabilidade humana.
E enquanto isso for verdade, o papel do engenheiro de software não diminui. Ele se transforma.
Se existe algo que a pesquisa de Nicholas Carlini deixa claro é que estamos diante de ferramentas extraordinárias, mas não mágicas. A diferença entre parecer inteligente e ser estruturalmente correto ainda é grande. E é justamente nessa diferença que mora o trabalho sério de engenharia.