Imagine uma equipe de desenvolvimento onde metade das linhas de código são geradas por sugestões automáticas em vez de digitação manual. Isso já não é ficção: grandes organizações relatam que volumes significativos de código são produzidos com assistência de modelos como GitHub Copilot, GPT-4 e Claude, com ganhos reportados de produtividade e satisfação dos desenvolvedores. Ao mesmo tempo, estudos mostram que 25–30% dos trechos de código gerados por essas ferramentas podem conter vulnerabilidades de segurança, cobrindo dezenas de categorias de falhas críticas. A tensão entre velocidade e qualidade, assistência e dependência, "inteligência" e simples reconhecimento de padrões está no centro do debate atual sobre IA generativa na Engenharia de Software. Após compreendermos o que está mudando na Aula 1, mergulhamos agora no como — os fundamentos técnicos que tornam possível essa aparente "inteligência" para código.
A Revolução Transformer: O Paradigma que Mudou Tudo
Antes de 2017, modelos de linguagem processavam texto sequencialmente, palavra por palavra, como quem lê um livro sem poder voltar atrás. Redes Neurais Recorrentes (RNNs) e suas variantes LSTM sofriam de um problema crítico: ao processar sequências longas, "esqueciam" o contexto inicial — imagine tentar entender o final de um código complexo tendo esquecido as declarações de variáveis do início.
O paper "Attention Is All You Need" (Vaswani et al., 2017) introduziu a arquitetura Transformer, fundamentalmente diferente. Em vez de processar sequencialmente, Transformers analisam toda a sequência em paralelo através de um mecanismo chamado self-attention. Na prática, ao analisar um trecho como for (let i = 0; i < array.length; i++), o modelo pode "conectar" diretamente o uso de array.length ao controle do laço, independentemente da distância em tokens.
A inovação central está nas attention heads (cabeças de atenção). Modelos modernos utilizam múltiplas cabeças trabalhando em paralelo — GPT-4 usa 96 — cada uma especializada em capturar diferentes tipos de relações: algumas focam em estrutura sintática (parênteses, chaves), outras em relações semânticas (tipos, funções), outras ainda em padrões de chamada de funções. Essa paralelização não apenas acelera o processamento — permite capturar padrões que arquiteturas sequenciais simplesmente não conseguem ver.
Transformers são compostos por blocos empilhados de camadas de atenção e camadas feed-forward, cada um seguido de normalização e conexões residuais que facilitam o treinamento de redes muito profundas. LLMs atuais possuem dezenas de camadas e bilhões de parâmetros, capturando regularidades estatísticas complexas em corpora gigantes de texto e código. Esse escalonamento segue leis de potência: dobrar o número de parâmetros tende a produzir ganhos consistentes em métricas como HumanEval.
A chave conceitual é que Transformers não "entendem" sintaxe ou semântica de forma simbólica — aprendem distribuições de probabilidade sobre sequências de tokens. Para código, isso é particularmente relevante porque código fonte contém estruturas hierárquicas e regras rígidas de sintaxe, mas também padrões idiomáticos que se manifestam estatisticamente. Modelos treinados sobre esse material conseguem completar chamadas de API, sugerir padrões de tratamento de erro e até reproduzir estilos de codificação específicos.
Anatomia do Aprendizado: Tokens, Embeddings e Attention
O ponto de partida é a tokenização: antes de "ler" código, o LLM converte o input em uma sequência de tokens — caracteres, subpalavras (como no BPE) ou unidades híbridas. Em muitos modelos, a tokenização foi originalmente pensada para linguagem natural e só depois reutilizada para código, o que pode levar a problemas como fragmentar identificadores de variáveis de forma pouco intuitiva. A palavra getUserById pode ser tokenizada como ["get", "User", "By", "Id"], preservando subpalavras significativas. GPT-4 possui vocabulário de aproximadamente 100.000 tokens.
Pesquisas recentes mostram que essa tokenização genérica contribui para uma compreensão superficial: quando se aplicam mutações que preservam a semântica — como renomear variáveis ou inserir código morto — o desempenho na detecção de bugs cai drasticamente, com perdas superiores a 80% em alguns cenários. Isso sugere que o modelo está sensível a pistas superficiais mais do que à lógica subjacente.
Cada token é mapeado para um embedding — vetor de alta dimensionalidade (4.096 a 12.288 dimensões) que codifica seu "significado" matemático. Tokens semanticamente relacionados ficam próximos no espaço vetorial: Promise e async têm embeddings mais similares entre si do que com console. O mecanismo de attention então calcula, para cada posição, uma combinação ponderada de todos os outros embeddings, usando projeções conhecidas como queries, keys e values:
// Ao processar 'user.email', o modelo calcula attention scores
interface User {
id: string;
email: string;
preferences: UserPreferences;
}
async function notifyUser(userId: string, message: string): Promise<void> {
const user = await userRepository.findById(userId); // Alta atenção para User.id
await emailService.send(user.email, message); // Conecta user com interface
}
O pré-treinamento utiliza a tarefa de modelagem de linguagem: prever o próximo token, minimizando perda de log-verossimilhança em grandes corpora. O fine-tuning supervisionado ajusta para tarefas específicas usando datasets com pares entrada–saída. Uma etapa adicional frequente é o alinhamento por reforço com feedback humano (RLHF), em que avaliadores classificam respostas e o modelo é ajustado para preferir saídas consideradas mais úteis ou seguras.
O Panorama de Modelos: GPT-4, Claude, Gemini e CodeLlama
Benchmarks como HumanEval, MBPP e SWE-bench tornaram-se referências para avaliar capacidades de LLMs em código. No trabalho que introduziu o Codex (Chen et al., 2021), um modelo de 12B parâmetros resolveu 28,8% do HumanEval com uma única amostra (pass@1), chegando a 70,2% com pass@100. Desde então, os números saltaram dramaticamente.
GPT-4 estabeleceu benchmark para modelos generalistas. Com janela de contexto de até 128.000 tokens e treinamento multilíngue, alcança resultados na faixa de 67-87% no HumanEval (dependendo da variante). Sua capacidade de chain-of-thought reasoning permite resolver problemas que exigem múltiplos passos.
Claude (Anthropic, família Sonnet/Opus) diferencia-se pela janela de contexto expandida (até 200.000 tokens) e destaca-se em benchmarks como SWE-bench, onde algumas versões atingem mais de 60% de resolução em tarefas de manutenção de software real — não apenas funções isoladas, mas issues completas de repositórios GitHub.
Gemini (Google), particularmente no AlphaCode 2, mostra força em programação competitiva: resolveu cerca de 43% dos problemas avaliados e atingiu desempenho estimado superior a 85% dos competidores em plataformas como Codeforces — rivalizando com desenvolvedores experientes.
CodeLlama (Meta) exemplifica modelos especializados open-source. A variante Python alcança 53.6% no HumanEval, notável para modelo que pode rodar em hardware próprio — crucial para organizações com restrições de privacidade.
A métrica pass@k merece atenção: representa a probabilidade de que pelo menos uma de k tentativas resolva corretamente o problema. GPT-4 com pass@10 alcança aproximadamente 90% no HumanEval — revelando que, mesmo quando a primeira sugestão falha, o modelo frequentemente contém o conhecimento necessário.
Na prática industrial, mais de 50 mil organizações já adotaram GitHub Copilot. Estudos em empresas como Accenture mostram que mais de 80% dos desenvolvedores adotaram rapidamente a ferramenta, relatando velocidade aumentada e maior satisfação. Contudo, a aceitação média fica em torno de 30% das sugestões — desenvolvedores ainda filtram e julgam o código em vez de aceitá-lo em massa.
Limitações Críticas: Hallucination, Segurança, Raciocínio e Contexto
A fascinação com capacidades frequentemente obscurece limitações fundamentais com consequências práticas sérias.
Alucinações representam o problema mais insidioso. Em código, manifestam-se desde erros lógicos sutis até invenção de APIs ou pacotes inexistentes. O fenômeno de "package hallucination" é particularmente perigoso: LLMs recomendam bibliotecas inexistentes que podem ser exploradas por atacantes que registram pacotes com esses nomes em repositórios públicos, introduzindo malware na cadeia de suprimentos:
// Código gerado por LLM - bug sutil
function calculateFibonacci(n: number): number {
if (n <= 0) return 0;
if (n === 1) return 1;
return calculateFibonacci(n - 1) + calculateFibonacci(n - 2);
}
// Problemas: 1) n negativo não tratado adequadamente
// 2) Complexidade O(2^n) - extremamente ineficiente
// 3) Stack overflow para n > ~40
// Versão correta exigiria memoization ou abordagem iterativa
function fibonacciCorrect(n: number): number {
if (n < 0) throw new Error("Input must be non-negative");
if (n <= 1) return n;
let prev = 0, curr = 1;
for (let i = 2; i <= n; i++) {
[prev, curr] = [curr, prev + curr];
}
return curr;
}
Do ponto de vista de segurança, análises empíricas identificaram que aproximadamente 29–30% dos snippets do GitHub Copilot em projetos reais continham fraquezas de segurança, cobrindo mais de 30 categorias CWE — injeção de comandos, valores aleatórios inseguros, problemas de validação de entrada. Outro estudo comparou Copilot com desenvolvedores humanos e concluiu que, embora não fosse "pior" em geral, repetia vulnerabilidades conhecidas em cerca de um terço dos casos, especialmente padrões de bugs mais antigos presentes nos dados de treinamento.
Limites de raciocínio são evidentes além de problemas sintéticos. Trabalhos sobre "compreensão de código" mostram que LLMs são altamente sensíveis a mutações semânticas-preservadoras: alterar nomes de variáveis ou inserir código morto reduz dramaticamente a capacidade de localizar bugs. Em benchmarks realistas como SWE-bench, mesmo sistemas avançados apresentaram taxas abaixo de 5% quando se corrigem problemas de qualidade do dataset e vazamentos de solução.
Janela de contexto continua sendo limitador prático. Embora modelos ofereçam centenas de milhares de tokens, a precisão tende a cair para partes do código que aparecem mais tarde no contexto ou que exigem integrações de dependências distantes.
"Entendimento" ou Estatística Sofisticada? O Debate que Importa
O debate sobre se LLMs "entendem" código é intenso tanto em IA quanto em filosofia da mente. Alguns argumentam que, por exibirem comportamentos consistentes em tarefas complexas, generalizarem para casos não vistos e corrigirem seus próprios erros, demonstram forma operacional de entendimento. Outros sustentam que, por basearem-se em correlações estatísticas e falharem em cenários que exigem raciocínio causal explícito, são apenas mecanismos sofisticados de associação de padrões.
No contexto de código, estudos como benchmarks semânticos sugerem que, embora LLMs sejam bons em completamento em contextos familiares, seu desempenho degrada quando se introduzem variações estruturais que não alteram a semântica. Isso reforça a visão de "compreensão" frágil e dependente de regularidades superficiais. Por outro lado, a capacidade de resolver 43% de problemas competitivos em AlphaCode 2 levanta a questão prática: se um modelo atua como competidor de alto nível, em que medida a distinção filosófica é operacionalmente relevante?
Para engenheiros, a resposta pragmática pode ser: a distinção importa menos que o comportamento. Se LLMs produzem código correto 67% das vezes em problemas padronizados e requerem supervisão para os 33% restantes, o modelo de uso fica claro — assistente poderoso, não substituto de julgamento humano. A pergunta "entende ou não" é menos relevante que "em quais contextos posso confiar?"
Se se assume que LLMs não "entendem", a postura recomendada é tratá-los como ferramentas assistivas mas não autônomas, exigindo revisão minuciosa em componentes críticos. Se se considera que "entendimento suficiente" foi alcançado para certas tarefas, pode-se delegar mais etapas, concentrando esforço humano em design de alto nível e validação. Entre esses extremos, muitas organizações adotam estratégias híbridas: uso intenso para tarefas rotineiras (boilerplate, testes, documentação) e uso cauteloso em funcionalidades núcleo.
Os fundamentos que exploramos — Transformers, attention, tokenização, embeddings — não são abstrações distantes do trabalho diário. São os mecanismos que determinam por que seu assistente de código às vezes produz soluções brilhantes e outras vezes, alucinações plausíveis. Compreender capacidades e limitações prepara você para as aplicações específicas que exploraremos nas próximas aulas: como LLMs transformam cada fase do SDLC. A tecnologia é poderosa, mas como toda ferramenta poderosa, seu valor depende de quem a empunha saber exatamente o que ela pode — e o que não pode — fazer.
REFERÊNCIAS PARA APROFUNDAMENTO
Papers Fundamentais
Vaswani, A. et al. (2017). Attention Is All You Need. NeurIPS.
Por que ler: Paper seminal que introduz a arquitetura Transformer, base de todos os LLMs modernos.- Link:
Brown, T. et al. (2020). Language Models are Few-Shot Learners. NeurIPS.
Por que ler: Introduz GPT-3 e demonstra capacidades de in-context learning.- Link:
Gemini Team, Google (2023). AlphaCode 2 Technical Report.
Por que ler: Mostra sistema baseado em Gemini alcançando desempenho superior a 85% dos competidores em programação competitiva.- Link:
Segurança e Limitações
Pearce, H. et al. (2022). Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions. IEEE S&P.
Por que ler: Estudo sistemático identificando ~30% de snippets com fraquezas de segurança.- Link:
Lanyado, I. et al. (2024). Measuring LLM Package Hallucination Vulnerabilities.
Por que ler: Analisa package hallucination e como pode ser explorado em ataques à cadeia de suprimentos.- Link:
Fan, A. et al. (2023). Large Language Models for Software Engineering: Survey and Open Problems. arXiv.
Por que ler: Survey abrangente sobre aplicações de LLMs em todas as fases do SDLC.
Material do Curso
Meira, S. (2024). The Impact of AI on Software Engineering: A Holistic Perspective. TDS Books.
Por que ler: Contexto brasileiro e perspectiva estratégica sobre transformações no SDLC.
Garcia, V. & Medeiros, R. (2025). Sinfonia: Orquestrando a Inteligência Artificial. ASSERT Lab.
Por que ler: Framework metodológico usado nos projetos da disciplina.
SOCIAL SHARE CARD GENERATOR