Déjà vu: Uma reflexão sobre engenharia e competência na era da IA

Introdução

Você sabe implementar QuickSort? Bubble Sort? Merge Sort? Ótimo. Agora uma pergunta mais interessante... quando foi a última vez que você implementou um deles? Provavelmente faz bastante tempo. Ainda assim, aposto que desde então você ordenou dados diversas vezes, seja usando sort(), um ORDER BY em SQL, a função de ordenação do Excel ou qualquer uma das incontáveis bibliotecas que abstraem esse problema. Você deixou de entender algoritmos de ordenação? Claro que não. Você apenas deixou de implementá-los manualmente, porque passou a existir uma abstração melhor. Na computação, isso acontece o tempo todo. Quem estudou arquitetura de computadores provavelmente já implementou circuitos combinacionais (que saudades de PCS2355 #sqn!), montou somadores, escreveu programas em Assembly ou precisou se preocupar com gerenciamento manual de memória. Hoje, a maioria de nós trabalha em linguagens de alto nível, utiliza bibliotecas desenvolvidas por outras pessoas, executa aplicações em containers e consome serviços em nuvem sem sequer pensar na enorme quantidade de camadas existentes abaixo disso. Cada uma dessas camadas provocou resistência. Sempre houve quem confundisse a nova abstração com uma perda de competência. Como se deixar de manipular registradores significasse entender menos de computação. Como se programar em Python fosse "menos engenharia" do que programar em C. Talvez toda grande abstração seja inicialmente percebida como uma perda, antes de ser reconhecida como um ganho. Curiosamente, tenho uma forte sensação de déjà vu. Lembro de defender Python para colegas que praticamente afirmavam que C era a única linguagem "séria" para programar. Os argumentos eram que C era mais rápido, permitia controlar a memória, produzia programas mais eficientes e mantinha o programador no controle da máquina. Python, por outro lado, era interpretado, dinamicamente tipado (que sacrilégio!), lento e escondia detalhes que até então eram vistos como parte indispensável do trabalho de um bom programador e que, inevitavelmente, produziria profissionais que entendiam cada vez menos de computação. Eu nunca enxerguei dessa forma. Meu argumento era diferente; era prático, não dogmático. Quando implementava algoritmos criptográficos onde estavamos em busca de milisegundos, utilizar C (com rotinas em Assembly!) era adequado. Em outras situações, o Python abstraía uma enorme quantidade de detalhes que, para muitos problemas, já não criavam mais valor. Isso me permitia dedicar muito mais tempo ao domínio da aplicação do que à mecânica da implementação. Hoje percebo que estamos vivendo uma discussão muito parecida. Existe uma frase atribuída a David Wheeler que é notável:

"Any problem in computer science can be solved by another level of indirection."

Acho ela absolutamente correta. Mas hoje eu acrescentaria uma segunda:

Toda abstração bem-sucedida muda a definição de competência.

IA como a próxima abstração

Até aqui, as grandes abstrações da computação atuavam principalmente sobre a máquina. A IA representa um salto diferente: pela primeira vez, começamos a abstrair parte do próprio trabalho cognitivo envolvido na engenharia de software e, de forma mais ampla, na computação. Hoje ela escreve código, produz documentação, sugere arquiteturas, gera testes, traduz entre linguagens, explica APIs, resume artigos, constrói consultas, revisa pull requests e auxilia em tantas outras tarefas. Mais importante do que a qualidade de cada resultado individual é o fato de que conseguimos automatizar, de maneira útil, atividades que antes dependiam quase exclusivamente da capacidade intelectual de especialistas. Eu já não trabalho da mesma forma. Hoje escrevo menos código, mas produzo mais. O tempo que antes era gasto implementando passou a ser investido decidindo o que implementar, por que implementar e, principalmente, qual é a melhor forma de implementar. A implementação continua importante. Mas ela deixou de ser o principal gargalo. O gargalo passou a ser compreender corretamente o problema, decompor sistemas complexos, tomar decisões arquiteturais, integrar tecnologias diferentes e validar criticamente aquilo que a IA produz.

A mesma história na cibersegurança

Quem trabalha com segurança provavelmente já viveu um movimento semelhante. Durante muitos anos, boa parte da inteligência de ameaças era distribuída na forma de IoCs: hashes, IPs, domínios e URLs. David Bianco sintetizou a limitação dessa abordagem na Pirâmide da Dor. O avanço não foi abandonar os IoCs. Foi compreender que eles eram apenas representações de algo mais profundo. Quanto mais subimos a pirâmide em direção aos TTPs, mais deixamos de perseguir artefatos específicos e passamos a modelar o comportamento do adversário. A abstração aumentou! E, com ela, aumentou também nossa capacidade de construir defesas mais robustas. Talvez estejamos vivendo exatamente a mesma transição na computação. Código é uma representação. Uma consulta KQL é uma representação. Uma regra Sigma é uma representação. Um IoC é uma representação. Até um prompt é uma representação! Durante muito tempo, dominar essas representações era uma excelente aproximação para medir competência. A IA rompe parcialmente essa associação. Ela consegue produzir representações extremamente competentes. Mas isso não significa que compreenda o problema que elas representam. O diferencial passa a ser dominar os conceitos por trás dessas representações: compreender o problema, formular boas hipóteses, projetar soluções, identificar limitações, avaliar trade-offs e exercer julgamento técnico. Em outras palavras:

O conhecimento não perdeu valor. Ele apenas mudou de lugar.

Método

Se você estiver de acordo com a tese, a solução então é "usar IA"? Isso seria tão vazio quanto dizer "programe para resolver seu problema". O diferencial nunca esteve na ferramenta. Sempre esteve no método. "Trabalhar com IA" não é uma habilidade. É uma disciplina. Significa aprender a decompor problemas, construir contexto, validar respostas, compreender limitações, integrar ferramentas e desenvolver processos confiáveis e reproduzíveis. Tenho aprendido muito acompanhando Matt Pocock. Uma observação dele me marcou particularmente: a IA desloca nosso trabalho em direção ao pensamento estratégico. Quanto mais observo minha rotina, mais concordo. Hoje gasto menos tempo produzindo artefatos técnicos e mais tempo projetando como eles devem existir.

Conclusão

Tenho visto colegas tratando "trabalhos produzidos com [auxílio de] IA" como se fossem, por definição, inferiores. Sinceramente, penso o contrário. A história da computação é, em grande parte, a história de pessoas que aprenderam a produzir mais valor utilizando níveis cada vez maiores de abstração. Compiladores não diminuíram o valor de quem escrevia Assembly. Linguagens de alto nível não diminuíram o valor de quem programava em C. Frameworks não diminuíram o valor de quem conhecia protocolos. A IA apenas nos apresenta o próximo nível de abstração. E, como aconteceu tantas vezes antes, ela também muda a definição de competência. Continuaremos precisando compreender profundamente os fundamentos da computação. Talvez mais do que nunca. A diferença é que esse conhecimento deixará de se manifestar principalmente pela capacidade de produzir representações e passará a se manifestar pela capacidade de formular problemas, projetar soluções, orientar sistemas inteligentes e exercer julgamento técnico. A IA não reduz a importância da engenharia. Ela aumenta. Porque, quando a execução deixa de ser o principal fator limitante, aquilo que realmente diferencia um grande profissional fica muito mais evidente. A história da computação não é a história de escrever mais código. É a história de precisar escrever cada vez menos para resolver problemas cada vez maiores. O desafio posto não é decidir se vamos "utilizar IA". É aprender, de verdade, a trabalhar com ela.