Os agentes engenheiros de software chegaram

Os novos engenheiros de software

Engenheiros, claro, têm uma queda pela ideia de serem substituídos. O CTO da Microsoft e os CEOs da Meta e da Anthropic fizeram previsões ousadas e dizem que IA substituirá cerca de 90% do código e engenheiros de nível médio em um prazo surpreendentemente curto. No início, era difícil de acreditar, os primeiros assistentes de código eram desajeitados, geravam código inválido e mostravam não entender o que estavam fazendo. Porém, eles melhoraram muito rapidamente.

Mesmo assim, o paradigma dos assistentes de código não tem sido convincente. Os ganhos de produtividade são inconsistentes, muitas vezes insignificantes. Um estudo da METR¹ mostrou uma redução de 19% na produtividade dos engenheiros quando usavam assistentes. Um estudo do Google² mostrou melhorias — 21% de redução no tempo de execução de tarefas —, mas nenhuma foi estatisticamente significativa. Em um espaço que evolui semanalmente, não há como generalizar resultados e eles dependem de variáveis como novas interfaces, contexto e a experiência do desenvolvedor utilizando-os. Em qualquer caso, acredito que o problema é mais profundo: os assistentes sempre foram a interface errada.

Há alguns anos, pensei que utilizar abordagens guiadas por especificações era a estratégia vencedora . Focar os humanos em manter o núcleo e as interfaces, deixando a IA regenerar as implementações sempre que os requisitos mudassem. Contexto estreito, restrições rígidas, máxima alavancagem. Isso ainda faz sentido — mas a realidade avançou. A recente adoção mais ampla de agentes para desenvolver, embora esteja sujeita a quase as mesmas nuances dos assistentes, não é apenas possível que substituam engenheiros de nível médio; acredito que esse seja o cenário mais provável. A questão não é se isso vai acontecer — mas o quão rapidamente serão substituídos. Não me refiro a “vibe-coding”, mas sim a software de produção escrito majoritariamente por agentes como o Codex e o Claude CLI.

É ingenuidade não reconhecer que o trabalho de engenharia será irreconhecível em um prazo de dez anos. A mudança já chegou e exige experimentação rápida tanto com modelos organizacionais quanto com processos de engenharia.

As empresas que descobrirem isso liberarão engenheiros capazes de alcançar múltiplos do output atual. As que não descobrirem simplesmente ficarão para trás. Apesar de assustador, é com toda certeza fascinante!

No curto prazo, a demanda por talentos juniores vai diminuir; algumas empresas vão explorar agentes apenas para reduzir custos. Mas isso é apenas uma parte da história. Tem a outra metade meio cheia do copo. Primeiramente, os ganhos de produtividade abrirão portas para novas indústrias e os avanços em IA abrirão outras, como por exemplo:

Software totalmente customizado em microescala. Consultorias e software houses vão atacar o long-tail.
Funcionalidades “just-in-time”. Plugins instantâneos. Primeiro, em softwares que já são comumente customizados de forma precária por power users, abaixando a barreira técnica consideravelmente. Por exemplo, Excel, Photoshop.
Sistemas self-healing, inicialmente em volta de integrações, processamento e extração de dados. Posteriormente de forma generalizada.
Assistentes em todos os tipos de domínios e revoluções em interfaces.
Até mesmo coisas absurdas como “departamentos de Recursos Artificiais” para manter os agentes felizes 😂

Produtos alternativos podem inundar mercados existentes com equipes muito menores ou até desenvolvedores solo. Similar ao que aconteceu em gaming por volta de 2011, quando equipes minúsculas — ou até devs solo — começaram a lançar produtos bem-sucedidos que rivalizavam com estúdios estabelecidos. O futuro do software pode seguir uma curva semelhante. De qualquer forma, os engenheiros precisarão entender que será necessário se adaptar a novos métodos de trabalho e processos de desenvolvimento.

Importante entender que se o seu produto depende de software e você não abraçar essa mudança nos próximos 2 anos, talvez não consiga ser competitivo. Não é opcional, é existencial.

Assim como o artigo da METR lista propriedades que poderiam explicar ganhos ou perdas de produtividade, os resultados com agentes dependem fortemente de variáveis sob nosso controle. Compilei minha própria lista que, não surpreendentemente, também se aplica a desenvolvedores. Muitos dos desafios que enfrentamos com agentes também são desafios com desenvolvedores inexperientes ou novos no problema.

Contexto

Humanos enterram contexto como conhecimento tribal. Dizemos a nós mesmos que está em um wiki — mas nunca está. Regras de negócio vivem nas cabeças dos devs. A integração de novos desenvolvedores é lenta porque eles não conhecem a história daquela função antiga que ninguém ousa tocar.

Ao apresentar qualquer problema para a IA, sempre negligenciamos a relevância do contexto. Por mais que gostemos de documentar e testar, a realidade de um codebase médio e de uma organização de engenharia é que muitas práticas são implícitas, e algumas regras de negócio podem não estar documentadas em nenhum lugar além da mente de alguns desenvolvedores. O tempo investido em estabelecer contexto para o agente tem enorme impacto. Desde tarefas do dia a dia, como acessar bancos de dados, gerenciar dependências, executar testes e configurar infraestrutura de testes, até contextos menos óbvios, como por que aquele código antigo ainda existe.

Agentes enfrentam o mesmo desafio que novos desenvolvedores, só que muito pior: eles não podem perguntar. Sentam quietos, como uma pessoa júnior com medo de incomodar a equipe, até que alguém perceba. Por isso, até desenvolvermos organizações e sistemas que permitam acesso ao contexto orgânico, as organizações bem documentadas terão vantagem e antecipar o contexto será uma habilidade essencial na engenharia.

Arquitetura

Separar responsabilidades é necessário não apenas devido a limites do tamanho do contexto, mas também por razões organizacionais. Os mesmos problemas que nos levam a quebrar monolitos ou reclamar de 500 microsserviços se aplicam tanto às organizações quanto aos agentes.

Os limites de contexto dos modelos ainda são relativamente pequenos se comparados com as maiores codebases. Desenvolvedores enfrentam o mesmo problema: abstrair partes que não entendem fazendo suposições sobre elas. Abstração da complexidade é uma habilidade que se aprende com o tempo. Às vezes, o código mantém interfaces claras que nos permitem ignorar completamente detalhes da implementação, beneficiando também agentes. Mas essa não é a realidade da maioria dos códigos. Ser capaz de direcionar um agente para partes específicas sem exigir deduções ou acesso às outras torna o processo mais rápido. Para agentes — especialmente em monorepos ❤️— a estrutura importa. Explicar as partes do projeto e fornecer ferramentas que funcionem em subpartes do projeto ajuda muito.

À medida que o custo marginal de entregar features despenca, a régua para os processos e organização dos sistemas cresce. Seu código precisará sustentar uma equipe significativamente maior trabalhando simultaneamente.

Alavancando pontos fortes

Futuramente, a vantagem dos engenheiros humanos pode ser a criatividade (assunto polêmico) — ou talvez sua motivação. Por outro lado, ja sabemos onde os agentes brilham, por exemplo:

Combinar conjuntos de habilidades raras (engenharia reversa + criptografia, engenharia de software + design de RF, etc). Agentes conseguem ir muito mais a fundo em qualquer área do que o desenvolvedor médio.
Refatorações grandes e detalhistas. Mesmo em códigos extensos, agentes são excelentes para refatorações que, embora simples, exigem manter uma grande pilha mental de mudanças encadeadas. Notei um avanço significativo nesse aspecto com o lançamento do GPT-5 esta linha.
Manter uma consistência brutal entre vários repositórios e sistemas.
Imunes ao tédio. Por exemplo, acho altamente tedioso refatorar grandes blocos de IaC, como repositórios Terraform ou Tofu, de forma mecânica.

Aprender a alavancar esses pontos fortes será muito importante no médio prazo (2 anos).

Eles também apresentam fraquezas:

Extremamente autoconfiantes (talvez por falsa percepção de segurança no emprego 😂), podem se perder em rabbit holes.
Falta de proatividade e incapacidade de fazer perguntas espontaneamente. Parte vem de limitações técnicas; agentes não veem nossas telas nem ouvem nossas discussões. O contexto deles é mais estático, como devs remotos sem acesso a Zoom.
Limitações de interface exigem setups especializados, por exemplo, para lidar com navegadores ou até prompts interativos simples (como Git abrindo o editor, igual que um dev que ainda não aprendeu ":wq").
Humanos avançam a engenharia de software ao abordar problemas desde um novo ponto de vista, permanece incerto se agentes podem expandir fronteiras de forma semelhante — por exemplo, criando novos frameworks e paradigmas de forma independente.

Objetividade & validação

A tarefa “crie um jogo de tênis que seja divertido” é muito subjetiva, mas existe por um motivo — humanos lidam com objetivos nebulosos porque podemos perguntar, adaptar e alinhar. Já agentes, nem tanto.

Quanto mais objetivo e testável for a meta, melhor o desempenho do agente. Quando a subjetividade é inevitável, ciclos de feedback curtos são essenciais. Caso contrário, você vai se afogar em inúmeras soluções medíocres,até mesmo fora do que consideraríamos domínios criativos. Por exemplo, startups lidam com muitas tarefas subjetivas. Escrever definições detalhadas é contraproducente porque ninguém sabe quais soluções realmente funcionam. Uma excelente estratégia é empoderar devs, favorecendo iterações rápidas para desambiguar e avaliar soluções.

Em entornos criativos tende a se confundir volume com baixa qualidade. A realidade e que pode ser extremadamente poderoso como ferramenta de alinhamento no inicio para aumentar a qualidade no final

Idealmente, queremos avaliar uma solução de forma automática e em prazos muito mais curtos que a iteração de desenvolvimento. Semelhante ao que engenheiros “orgânicos” fazem: é mais simples obter bons resultados se o stakeholder conseguir descrever o resultado de forma objetiva. Quanto mais eficientemente os devs conseguirem validar a solução, melhores serão os primeiros resultados.

Algumas tarefas são não apenas complexas, mas inviáveis de descrever. Você pode treinar um dev em mecânicas de jogo divertidas e interfaces visualmente atraentes. Porém, é muito trabalho especificar e quase impossível avaliar de forma programática. Em qualquer processo com alto grau de subjetividade, comunicação síncrona e avaliações parciais frequentes se tornam cada vez mais importantes. Isso, combinado com as limitações de interface atuais dos agentes, torna difícil alcançar bons resultados.

Descrever uma tarefa de forma abrangente não é só sobre seu objetivo funcional; também é necessário incluir restrições relevantes para aceitar a solução. Por exemplo, definir precisamente o que acontece durante a criação de um usuário pode ser suficiente. Mas assim como com um engenheiro real, você também espera que ele não introduza novas vulnerabilidades. Devemos considerar essas expectativas ocultas desde o início, incluindo a própria arquitetura. Idealmente, o sistema já reforça esse comportamento, e o restante deverá ser checado em pipelines de CI ou assumiremos que é parte dos critérios nos code reviews.

Os detalhes de implementação podem ser irrelevantes, desde que possamos afirmar que avaliações funcionais são suficientes. Se atingimos aquela condição, o código pode nem precisar ser mantido, já que pode ser mais simples reescrevê-lo sempre que aparecer um requisito novo. Frameworks ajudam nesse sentido, assim como arquiteturas intencionais ou uso de diferentes paradigmas (como declarativo ou orientado a dados, etc.). Em geral, um agente cometerá menos erros se limitado por uma arquitetura bem definida, especialmente em projetos que começam de zero. A habilidade de projetar com esses objetivos em mente se torna mais relevante, e a experiência dos desenvolvedores se torna uma vantagem significativa.

Setup unificado

Ao contrário da maioria dos desenvolvedores, os agentes não têm medo de falhar; eles absolutamente precisam ser isolados e protegidos de acessos destrutivos. Não é que sejam burros; agentes não tem os incentivos que nos levam a pensar duas vezes antes de agir. Isso pode mudar, mas a solução não é óbvia; eles não parecem incomodados em escrever relatórios de incidentes e assumir responsabilidade mais efetivamente que muitos de nós.

As ferramentas ainda são bagunçadas. Os servidores MCP podem resolver problemas de interface reais, mas trazem riscos enormes, como vazamento de código-fonte ou dados. Estes recursos fazem muito sentido em assistentes rodando remotamente sem acesso a um ambiente completo. No caso dos agentes, ferramentas de CLI funcionam já e resolvem. A regra é simples: só adicione ferramentas se ela resolve uma limitação própria dos agentes. Um exemplo é a comparação entre o MCP do GitHub e usar apenas a bem testada GitHub CLI.

Um exemplo clássico de limitação é a utilização de um navegador. Os desenvolvedores também precisam de um, mas assumimos que eles têm olhos para olhar a tela e mãos para controlar o mouse. A ferramenta neste caso precisa preencher um gap funcional ou de eficiência causado por limitações específicas do agente, em lugar de criar novas formas de fazer a mesma coisa.

Quanto a permissões, às vezes faz sentido que os desenvolvedores deleguem seu acesso. Porém, na maioria dos casos, isso traz riscos inaceitáveis. A capacidade de isolar os agentes e fornecer acesso granular é essencial.

Acima de tudo: contar com setups padronizados importa. Assim como code reviews e PRs se tornaram universais, processos para utilização e gerenciamento de agentes também se tornarão parte das ferramentas core dos times.

O que está em jogo

Na Enter, nossa missão é alavancar IA para trabalhos críticos — isso inclui engenharia de software. Nosso objetivo não é reduzir engenheiros, mas sim fornecer para eles infraestrutura, guardrails e workflows para utilizar agentes com máxima eficiência e multiplicar o potencial de cada um.

A verdade é dura:

As empresas que dominarem agentes vão multiplicar sua força de engenharia.
As empresas que não vão ficar atrás.

Esse futuro não é opcional. É inevitável.

Agradeço a @dmacvicar pelos comentários que fizeram o artigo muito melhor🙏.