Programar com AI Agents: os 20% de que ninguém fala
Na LayerX, todos os engenheiros programam com assistentes de IA. Não como experiência, não em paralelo com o trabalho principal, nem apenas para as tarefas mais simples. Programação, revisão, planeamento. Tudo passa pelo Claude Code e pelo Cursor, todos os dias, em toda a equipa.
Isto não é um piloto que ainda estamos a avaliar. Faz parte do nosso processo de engenharia, da mesma forma que o controlo de versões e as code reviews. E neste momento, digo-o sem rodeios: é inegociável. Para a forma como desenvolvemos software, é assim que se faz. Não tenho dúvidas.
Quase todas as funcionalidades que a equipa da LayerX lança passam agora por um coding agent antes de chegarem a um revisor humano. A alavancagem é real, a velocidade é real, e num bom dia parece que três engenheiros sénior entraram na equipa do nada. Honestamente, não vamos voltar atrás.
Mas há um senão 🤔
Também passei muito tempo a limpar o que estas ferramentas deixaram para trás. Por isso, quando leio mais uma publicação a dizer que alguém reconstruiu anos de engenharia com um único prompt, ou que "já ninguém lê o código", sinto a necessidade de dizer o que não se diz em voz alta. 😱
Não é assim que o software em produção parece. Nem de perto.
O problema não é que as ferramentas sejam más. É que só compensam quando há engenharia de verdade por trás delas. Aqui está o que construir desta forma me ensinou. Onze lições. As coisas que gostava que alguém me tivesse dito antes de começar a confiar nos modelos de IA que temos hoje.
Lição 1: Os primeiros 80% são os 80% fáceis
Um coding agent chega-te aos oitenta por cento de uma funcionalidade depressa. Estrutura, liga as peças, escolhe nomes razoáveis e produz algo que corre. Na primeira vez que o vês, parece batota.
A armadilha é acreditar que os restantes vinte por cento também estão quase feitos. Não estão. Esses vinte por cento são os casos extremos, os modos de falha, a concorrência, as fronteiras de segurança, o problema que aparece às três da manhã com uma carga que nunca simulaste.
Esses vinte por cento são engenharia. São também a parte que separa a maioria de quem realmente consegue colocar software fiável em produção. O agent entrega a toda a gente os mesmos oitenta por cento. O que fazes com os últimos vinte é o que decide tudo.
Lição 2: A história do "um prompt reconstruiu anos de trabalho" é um truque de ilusionismo
Já estou farto dessas histórias. Um prompt, e supostamente anos de engenharia de alguém são reproduzidos numa tarde.
Não é verdade, e a razão é simples. O que estás a ver é um protótipo, não um produto. A demo corre bem. Não tem utilizadores reais, não tem concorrência, não tem abusos, não tem compliance, não tem migrações de dados, não tem histórico de chamadas de emergência gravado no seu design.
Anos de engenharia não são anos a escrever código. São anos de decisões. Cada ramo estranho num codebase maduro é normalmente a cicatriz de um incidente real. Um agent consegue reproduzir a superfície numa tarde. Não consegue reproduzir o julgamento, e o julgamento é o produto.
Lição 3: Nunca deixas de ler o código
A outra afirmação em que não acredito: "já não leio o código."
Com o tempo desenvolves de facto uma sensibilidade. Aprendes a sentir quando algo está torto, onde o agent tende a cortar caminho, que tipo de prompts produzem output frágil. Essa sensibilidade tem valor e vale a pena construí-la.
Mas a sensibilidade diz-te onde olhar. Não olha por ti. Cada alteração significativa continua a ter uma revisão cuidada, a mesma revisão que daria a um engenheiro júnior que é rápido, confiante e ocasionalmente muito errado. Saltar esse passo não é um ganho de produtividade. É um incidente adiado.
Lição 4: Sem um design, o agent inventa um por ti
Este é o modo de falha que custa mais, e é silencioso.
Pede uma funcionalidade a um agent sem design nem restrições, e ele entrega de bom grado. Vai também escrever uma segunda versão de um helper que já existe, introduzir lógica que ninguém pediu, e resolver o mesmo problema de três maneiras diferentes em três ficheiros diferentes. Nenhuma está errada isoladamente. Em conjunto, é entropia.
O agent optimiza para "fazer este prompt passar", não para "encaixar limpo num sistema coerente". Se não trazeres a arquitectura, ele improvisa uma, e arquitectura improvisada é como acabas com um codebase que ninguém consegue manter. Dá-lhe o design, as restrições, os padrões existentes. Diz-lhe explicitamente o que não deve fazer. A orientação não é opcional. É o trabalho.
Lição 5: Um protótipo é uma promessa, não um produto
O vibe coding é fantástico para o primeiro quilómetro. Consegues criar algo real num dia, mostrá-lo a pessoas, e aprender depressa. A equipa da LayerX faz isto constantemente, e é um dos melhores usos das ferramentas.
Depois começa a parte difícil.
Polir é a parte difícil. Fazê-lo aguentar pressão é a parte difícil. O protótipo é uma promessa de que a coisa pode funcionar. Transformar essa promessa em software que resiste em produção é trabalho lento, sem glamour, profundamente técnico. O agent ajuda, mas não encurta a distância tanto quanto a demo te fez acreditar.
Lição 6: A produção ganha-se com testes e performance, não com prompts
No momento em que queres milhares de utilizadores, as regras mudam. No momento em que queres vender a outras empresas, mudam outra vez.
Nessa altura, unit tests deixam de ser um nice-to-have. O trabalho rigoroso de performance deixa de ser um problema para depois. Como o sistema se comporta sob carga, o que acontece quando uma dependência é lenta, onde degrada e como recupera — estas são as perguntas que decidem se tens um negócio ou uma responsabilidade.
Um agent escreve testes por ti. Não decide o que vale a pena testar, qual é o teu orçamento de performance, ou o que significa "bom o suficiente para cobrar". Essas são decisões de engenharia, e são as que os clientes estão realmente a pagar.
Lição 7: Cada nova versão de modelo reescreve a personalidade do teu assistente
Esta é a frustração mais subestimada de trabalhar com estas ferramentas.
Com cada nova versão, cada novo modelo, o comportamento muda. Um padrão de prompt que funcionava lindamente no mês passado produz agora algo subtilmente diferente. Os defaults mudam. A forma como interpreta a ambiguidade muda. Passas tempo real a reaprender como fazer o assistente fazer a coisa certa.
Aprendi a tratar cada versão maior como uma nova contratação. Talentoso, provavelmente uma melhoria, mas por provar no nosso codebase. Por isso fico conservador. Durante algum tempo depois de uma actualização, o código gerado recebe mais escrutínio, não menos. A melhoria costuma valer a pena. A confiança cega durante a transição, não.
Lição 8: O agent amplifica o engenheiro que já és
Um coding agent é um multiplicador, e os multiplicadores funcionam nos dois sentidos.
Dá-o a um engenheiro forte com standards claros e torna-o dramaticamente mais rápido a produzir bom código. Dá-o a alguém que salta o design e evita revisões, e torna-o dramaticamente mais rápido a produzir mau código. A mesma ferramenta, resultados opostos.
É por isso que não me preocupa que os agents tornem os engenheiros irrelevantes. Fazem o contrário. Aumentam o valor do julgamento, do gosto e da disciplina, porque esses são agora os inputs escassos. Escrever código nunca foi o bottleneck. O pensamento sempre foi.
Lição 9: Escrevo em linguagens que nunca aprendi de raiz
Não esperava isto quando começámos. Hoje movo-me entre Python, Swift e Zig sem nunca ter pago o preço completo de aprender nenhuma delas da forma tradicional.
Havia um custo em cada nova linguagem. Semanas de sintaxe, idiomas, tooling, bibliotecas standard, e convenções que só fazem sentido depois de te terem queimado. Esse custo manteve muitos bons engenheiros presos a uma ou duas linguagens durante toda a carreira.
O agent eliminou esse custo. Consigo começar numa linguagem desconhecida e fazer perguntas ao código conforme avanço. Por que está escrito desta forma. O que faz este idiom na prática. Esta é a escolha idiomática, ou apenas uma que compila. Estou a aprender a linguagem enquanto a uso, não durante meses antes de ter permissão para começar.
Esta é uma das partes de que mais gosto, e mudou o que estou disposto a tentar. Mas funciona por uma razão. Já sei engenharia. Não estou a aprender a programar, estou a mapear ideias que já entendo para nova sintaxe, e o julgamento sobre se o resultado é sólido vem de experiência que não tem nada a ver com a linguagem. O agent traduz. A engenharia continua a ser minha.
Lição 10: O processo de engenharia é o moat agora
Quando o código se torna barato de gerar, o que continua caro é manter um sistema coerente.
Isso significa processo. Code reviews que realmente revêem. Convenções que o agent é instruído a seguir. Decisões de arquitectura escritas. CI que falha com barulho. Uma definição real de "feito". Nada disto é novo. O que é novo é que já não é o overhead aborrecido à volta do trabalho real. É o trabalho.
O processo de engenharia é o que separa o software que escala do software que apodrece silenciosamente enquanto ship rápido. Na LayerX, essa disciplina não é negociável. As nossas convenções partilhadas, as nossas revisões e as nossas decisões de arquitectura escritas são o que permite a uma equipa pequena mover-se depressa sem que o codebase se desintegre por baixo. As equipas que vencerem com estas ferramentas serão as que tiverem maior disciplina, não as que tiverem os prompts mais inteligentes.
Lição 11: Não conseguimos trabalhar sem elas, e é exactamente por isso que a disciplina importa
Vou ser honesto sobre onde a equipa da LayerX está com tudo isto. Dependemos muito de coding agents, em todas as partes de como construímos, e nenhum de nós argumentaria seriamente a favor de voltar atrás. Mudaram a velocidade a que nos movemos e quão pequena uma equipa pode continuar a ser enquanto o faz.
Mas não é só rosas 🌷
Usadas sem orientação, estas ferramentas trabalham silenciosamente contra ti. Vão encher o teu codebase de duplicação, desviar-se do teu design, e entregar-te um protótipo disfarçado de produto. Usadas com engenharia forte à volta, são a melhor alavancagem que vi na minha carreira.
A tecnologia já não é o diferenciador. Toda a gente tem os mesmos agents. O diferenciador é o engenheiro que os guia, e o processo que mantém tudo unido. Os outros vinte por cento. Isso ainda somos nós, e importa mais do que nunca.
Onde realmente estamos
Tudo o que está acima é o estado de facto de construir software hoje. Não é uma previsão. É a realidade actual, vivida dia a dia pela nossa equipa.
E está a mover-se depressa. Cada versão de modelo empurra forte, e as melhorias não são cosméticas. Já consigo ver os modelos a melhorar a seguir as nossas guidelines, a respeitar as nossas convenções, e a aplicar boas práticas de software sem precisar de o dizer duas vezes. Essa trajectória é real, e espero que se mantenha.
Mas esta é a minha leitura honesta para os próximos meses. O modelo vai continuar a precisar de orientação adequada, e vai continuar a precisar de engenheiros de software rigorosos nos bastidores a guiá-lo para as coisas certas. Melhor não significa autónomo. Uma ferramenta mais afiada ainda precisa de uma mão que saiba onde cortar, e na equipa da LayerX essa mão é sempre um engenheiro real.
O ganho de produtividade em si não está em discussão. Um assistente de programação aumenta o que consegues fazer e eleva o teu output por uma ordem de grandeza. É inegável, e qualquer pessoa que tenha usado estas ferramentas a sério já o sabe.
O que não faz é substituir anos de decisões de engenharia, nem deixar-te replicá-las depressa. Essas decisões são julgamento acumulado, e o julgamento não se comprime num prompt.
Por isso não acho que a IA está a devorar o almoço do software. Acho que está a fazer algo mais interessante. Está a transformar o engenheiro numa espécie de super-herói, proficiente a uma escala e em situações que o engenheiro sozinho nunca teria alcançado, fluente em cantos do sistema que nunca pensaria em explorar. O engenheiro não desaparece nessa história. O engenheiro é amplificado.
É no futuro em que estou a apostar. Modelos melhores, todos os meses. E logo a seguir, mais engenharia do que nunca.
A engenharia é o novo moat 🏰
