sobre IA, engenharia de software e o valor de entender o que a gente constrói.
2026 começou com uma promessa que estava ficando cada vez mais difícil de ignorar: o desenvolvimento de software estava mudando, talvez muito mais rápido do que a maioria de nós imaginava.
Com a evolução rápida dos grandes modelos de linguagem, principalmente dos modelos de ponta, o desenvolvimento assistido por IA estava indo além do autocomplete e da geração de trechos isolados de código. Os agentes estavam se tornando capazes de navegar por repositórios, implementar funcionalidades, rodar testes e participar de fluxos de engenharia cada vez mais complexos.
Na época, eu trabalhava para uma empresa americana do setor de criptomoedas. Tínhamos um time de engenharia relativamente pequeno, e a pressão para aumentar a produtividade não parava de crescer. Naturalmente, começamos a incorporar IA de forma mais intensa no nosso processo de desenvolvimento, e acho que isso está acontecendo em boa parte da nossa área.
Toda semana apareciam novos modelos, ferramentas, benchmarks e promessas sobre o que os desenvolvedores não precisariam mais fazer por conta própria. Em algum ponto entre o entusiasmo com essas tecnologias e a pressão crescente para adotá-las, comecei a me fazer uma pergunta diferente:
Se todo mundo tem acesso a agentes de IA cada vez mais capazes, o que vai realmente diferenciar um bom engenheiro de software de alguém que simplesmente sabe usá-los?
Depois de terminar aquele projeto, decidi fazer uma mudança deliberada na minha carreira. Reduzi o tempo que estava dedicando ao trabalho com clientes e comecei a investir mais em experimentação, projetos open source e no estudo das tecnologias que estavam surgindo em torno do desenvolvimento assistido por IA.
Explorei fluxos de trabalho com agentes, geração aumentada por recuperação (RAG), Model Context Protocol (MCP), gestão de contexto, skills e diferentes formas de orquestrar interações com modelos de linguagem.
Minha intenção não era simplesmente produzir mais. Eu queria entender como essas tecnologias estavam mudando a nossa profissão, quais habilidades estavam perdendo valor e, principalmente, que conhecimento continuaria relevante independentemente de quão capazes os modelos se tornassem.
Curiosamente, essa investigação acabou me levando de volta a algo familiar: os fundamentos da ciência da computação.
a gente não está mais só escrevendo código
Já comparei muitas vezes o desenvolvimento de software com a engenharia civil. Tradicionalmente, esperava-se que um desenvolvedor desempenhasse vários papéis ao mesmo tempo: o pedreiro, o engenheiro e, às vezes, até o arquiteto, embora essa dinâmica tenha mudado durante a pandemia. A gente projeta a estrutura, toma decisões de engenharia e implementa a solução por conta própria.
A IA está mudando a lógica econômica desse arranjo. Transformar requisitos em código funcionando está ficando cada vez mais barato. Um agente consegue gerar em minutos o que antes poderia exigir horas de trabalho manual. Isso faz parte da mudança que explorei em o que vem depois do vibe coding?.
Mas conseguir construir alguma coisa não significa necessariamente entender o que precisa ser construído ou por quê. Imagine construir uma casa com máquinas capazes de assentar tijolos, instalar tubulações e montar estruturas inteiras quase automaticamente. A existência dessas máquinas não elimina a necessidade de entender o projeto, a integridade estrutural, os materiais, a segurança ou as restrições arquitetônicas. E algumas decisões irresponsáveis podem acabar colocando a casa no chão.
Na verdade, conseguir construir mais rápido também faz as consequências de decisões ruins de engenharia chegarem mais rápido. Com software não é diferente. Um agente de IA pode produzir uma implementação que funciona sem necessariamente tomar as melhores decisões sobre alocação de memória, concorrência, uso de recursos, limites entre sistemas ou manutenção no longo prazo. Mesmo quando a implementação gerada está correta, alguém ainda precisa entender por que ela está correta.
Essa diferença fica ainda mais importante quando o software deixa de ser um protótipo e começa a atender usuários reais. Sistemas em produção têm restrições que nem sempre cabem em um prompt: cargas de trabalho imprevisíveis, requisitos operacionais, integrações legadas, limitações de infraestrutura e trade-offs de negócio.
Gerar código é só uma parte da solução desses problemas.
a diferença entre fazer funcionar e entender por que funciona
Nesse período, também participei de vários processos de entrevista técnica. Apesar da adoção crescente de IA na indústria, muitas empresas continuavam avaliando candidatos por meio de exercícios de algoritmos, problemas no estilo LeetCode e entrevistas de system design.
Certamente há espaço para questionar o quanto essas entrevistas conseguem medir a capacidade de alguém como engenheiro. Já discuti algumas dessas limitações no meu texto sobre entrevistas técnicas. Mesmo assim, elas revelam uma contradição interessante. Enquanto os desenvolvedores são cada vez mais incentivados a delegar a implementação à IA, ainda se espera que demonstrem raciocínio técnico sem depender dessas ferramentas. E existe um bom motivo para preservar pelo menos parte dessa expectativa.
Um desenvolvedor que consegue gerar uma solução não necessariamente consegue explicar sua complexidade, identificar suas limitações ou adaptá-la quando as premissas mudam. A capacidade de raciocinar de forma independente ainda importa. Foi isso também que mudou minha visão sobre LeetCode: usá-lo para treinar o raciocínio, em vez de tratá-lo como um julgamento de valor.
Mas fiquei ainda mais convencido disso com meus estudos técnicos e com o contato com o material de engenharia da Ardan Labs. Quanto mais eu estudo os mecanismos internos das linguagens de programação e dos sistemas computacionais a partir desse material, mais percebo que esses conhecimentos não estão ficando obsoletos por causa da IA.
Eles estão me tornando melhor em usar IA.
Entender mais profundamente como o software realmente é executado muda a forma como você revisa código gerado, as perguntas que faz e as otimizações que consegue identificar. Diferentemente do conhecimento preso a um framework ou ferramenta específica, esses conceitos tendem a continuar relevantes ao longo de gerações de tecnologia.
E esse tipo de conhecimento não vem barato. Você pode ter um modelo mental de como o seu sistema operacional funciona, mas chegar a esse entendimento já é difícil. Relacionar isso a uma linguagem e encaixar tudo no mesmo modelo mental leva tempo. E nem sempre esse conteúdo é acessível ou fácil de encontrar.
os frameworks mudam. os mecanismos por trás deles continuam
Pense no que significa dominar uma linguagem de programação.
No começo, boa parte do aprendizado gira em torno de sintaxe, bibliotecas padrão, frameworks e padrões comuns de desenvolvimento. São habilidades necessárias, mas representam só uma parte da história. Conforme você se aprofunda, sua atenção vai saindo do que a linguagem permite escrever e se voltando para como ela realmente se comporta.
Recentemente, tenho explorado essa diferença por meio de Java, Go e Rust.
Essas linguagens oferecem abordagens diferentes para gerenciamento de memória, compilação, comportamento em tempo de execução e concorrência. Java normalmente depende de um runtime gerenciado e de um garbage collector. Go também usa um garbage collector, mas seu runtime escalona goroutines sobre threads do sistema operacional. Os modelos de escalonamento e gerenciamento de memória diferem entre as duas linguagens. Rust enfatiza ownership e borrowing, permitindo verificar várias garantias de segurança de memória em tempo de compilação sem exigir um garbage collector convencional.
Essas diferenças não são meramente acadêmicas. Elas influenciam padrões de alocação, latência, consumo de recursos, características de desempenho e os trade-offs envolvidos no projeto de aplicações. Quando você entende esses mecanismos, sua relação com o código muda.
Em vez de pedir a um agente de IA para simplesmente otimizar uma função, você consegue investigar se o gargalo real vem de alocações desnecessárias, contenção, estruturas de dados, comportamento do coletor de lixo ou de uma decisão arquitetural ruim.
Para isso, você pode usar profiling e benchmarks para descobrir o que está acontecendo, em vez de assumir que uma implementação é eficiente porque parece limpa ou porque um modelo de IA disse que é. E também passa a ter mais condições de reconhecer quando uma otimização proposta é desnecessária ou até contraproducente.
É aqui que a diferença entre familiaridade e domínio fica especialmente visível.
Saber usar uma linguagem permite produzir software. Entender o modelo por trás dela permite raciocinar sobre o comportamento desse software. E a segunda capacidade fica ainda mais valiosa quando boa parte da implementação é delegada a um agente.
a IA não elimina a engenharia. ela cria mais uma camada dela
Existe outra dimensão dessa transformação que merece atenção.
Trabalhar bem com agentes de IA está se tornando, por si só, uma disciplina de engenharia. A diferença entre simplesmente mandar um prompt para um modelo e projetar um fluxo confiável de trabalho com agentes pode ser grande. Toquei nessa transição em do vibe coding ao fluxo de trabalho com IA, principalmente na pressão para transformar implementação mais rápida em maior produtividade.
Quando você começa a explorar gestão de contexto, execução de ferramentas, loops de agentes, memória, skills e estratégias de orquestração, percebe que a qualidade do resultado depende de muito mais do que a forma de escrever um prompt.
Importa como as tarefas são decompostas. Importa como o contexto é selecionado. Importa como o agente valida o próprio trabalho. E importa como você decide quando intervir.
Um desenvolvedor que entende o sistema que está sendo construído consegue definir restrições melhores, estabelecer etapas de validação que fazem sentido e identificar problemas antes que fiquem caros. Isso não significa que todo desenvolvedor precisa se tornar especialista nos mecanismos internos dos modelos de linguagem. Significa que o julgamento de engenharia continua relevante mesmo quando o mecanismo de implementação muda.
O objetivo não precisa ser produzir uma funcionalidade inteira com um único prompt. Às vezes, um fluxo bem projetado, com restrições explícitas, testes e etapas de verificação, produz um resultado melhor com menos iterações e menos desperdício computacional. Seu modelo mental pode ajudar a conduzir esse processo com menos tokens, menos alucinações e menos tempo. A IA pode acelerar a implementação, mas aceleração sem qualidade não é necessariamente progresso.
o conhecimento que ninguém pode tirar de você
Não acredito que todo desenvolvedor precise se tornar especialista em construção de compiladores, gerenciamento de memória ou mecanismos internos de runtimes. A profundidade necessária depende dos problemas que você resolve e do momento da sua carreira.
Para quem está começando, entender estruturas de dados, algoritmos, sistemas operacionais, redes, testes e projeto de software cria uma base para raciocinar de forma independente.
Para um desenvolvedor mais experiente, conhecer mais profundamente os mecanismos internos das linguagens, os modelos de concorrência, as características de desempenho e os trade-offs arquiteturais pode se tornar uma vantagem competitiva importante.
E, para especialistas, entender os mecanismos por trás das ferramentas muitas vezes é o que permite resolver problemas que não cabem apenas nos padrões convencionais.
São níveis diferentes de profundidade, mas todos compartilham algo fundamental: desenvolvem a capacidade de entender problemas, em vez de apenas reproduzir soluções. É a mesma distinção entre conhecimento e experiência que discuti em sobre senioridade em projetos de sistema.
Também não acredito que a IA vá continuar incapaz de realizar trabalhos sofisticados de otimização, arquitetura ou depuração. Os modelos estão melhorando, e muitas tarefas que hoje exigem a intervenção de um especialista podem acabar sendo altamente automatizadas. Mas isso não torna o entendimento irrelevante.
Uma ferramenta ficar mais capaz não torna automaticamente quem a opera mais conhecedor do assunto. E produzir um sistema que funciona não prova que você entende as decisões que fizeram aquilo funcionar. Na verdade, a facilidade de gerar software pode introduzir um novo tipo de dívida técnica: sistemas criados mais rápido do que as pessoas responsáveis por mantê-los conseguem entendê-los.
Essa dívida pode continuar invisível enquanto tudo funciona. Ela fica muito mais cara quando alguma coisa quebra.
A maior oportunidade que a IA oferece aos desenvolvedores, na minha visão, não é simplesmente escrever mais código. É a possibilidade de usar o tempo economizado na implementação para entender melhor os sistemas que construímos. Podemos explorar linguagens desconhecidas, comparar estratégias de implementação, investigar o comportamento em tempo de execução e testar hipóteses mais rápido do que antes.
Mas ter acesso à informação não é a mesma coisa que adquirir conhecimento.
Conhecimento exige raciocinar, experimentar, errar, validar premissas e construir aos poucos modelos mentais que nos permitam reconhecer padrões de forma independente. Esse processo não pode ser substituído por simplesmente aceitar uma resposta. Porque os frameworks que usamos vão mudar. As linguagens com que trabalhamos podem mudar. Os modelos e agentes dos quais dependemos certamente vão mudar.
O que continua valioso é a nossa capacidade de entender os sistemas por trás dessas abstrações, adaptar esse entendimento a novos contextos e tomar decisões de engenharia bem fundamentadas.
Porque a coisa mais valiosa que você pode construir como engenheiro de software não é o código que produz. É o entendimento que desenvolve enquanto aprende como e por que esse código funciona.
E isso é conhecimento que ninguém pode tirar de você.