abri três terminais essa semana e percebi uma coisa estranha.
no primeiro, um agente refatorava um módulo legado. no segundo, um sub-agente lia documentação e cuspia um plano de migração. no terceiro, eu revisava o que o primeiro tinha feito enquanto o segundo me esperava.
em nenhum dos três eu estava desenvolvendo. eu estava orquestrando. decidindo como esses três pedaços iam conversar, definindo até onde cada um podia ir sozinho, validando saída de um pra virar entrada do outro.
e aí caiu a ficha: isso aqui não é desenvolvimento. isso aqui é engenharia.
um pouco de palavra
a palavra engenharia vem do latim ingenium — habilidade natural, talento, gênio. evoluiu para ingeniator no latim medieval, que designava quem construía engenhos: máquinas, dispositivos, artefatos.
engenheiro é quem cria engenhos.
já desenvolvedor… desenvolve. pode ser código, pode ser uma fotografia, pode ser uma criança. é um termo bem mais frouxo. a indústria abraçou developer nos anos 2000 e a gente foi junto, mas tem uma diferença sutil: developer escreve código. engineer decide qual código merece existir.
por muito tempo as duas palavras descreviam praticamente a mesma coisa, porque o trabalho era o mesmo: alguém escrevendo as linhas que iam pra produção. a distinção era só semântica. agora deixou de ser.
o que mudou
hoje o agente escreve as linhas. eu não digito for (let i = 0; i < array.length; i++) há meses. o claude code digita pra mim. o cursor digita. o copilot digita.
o que sobra pra mim?
sobra projetar. decidir qual agente faz o quê. definir contratos. orquestrar a conversa entre eles. escolher arquitetura. decidir o que entra no contexto e o que fica de fora. validar saída. gerenciar trade-offs.
engenho. eu construo engenhos.
e isso muda completamente o que significa ser bom no nosso trabalho.
e quando eu paro pra olhar o time inteiro de agentes que eu tenho rodando — agentes pessoais que lembram preferências, sub-agentes que coordenam entre si, hooks, skills, mcps — não tem como fingir que isso é só “desenvolver um produto”. é projetar um sistema. pequeno, pessoal, mas sistema.
os clássicos não envelheceram. a gente que estava distraído.
aqui é onde a coisa fica engraçada.
lembra do programador pragmático? aquele livro do hunt e thomas que todo bootcamp manda ler e quase ninguém termina? pega ele de novo agora. a maioria daqueles princípios não só ainda vale como ficou mais importante. não porque os princípios mudaram, mas porque o ambiente em que eles operam mudou.
vou pegar alguns.
plain text vence sempre
defenderam texto puro como formato durável. ninguém leu direito. hoje o stack inteiro de agente é plain text — claude.md, specs em markdown, .agents/, prompts em arquivo. o capítulo virou profecia.
design by contract
bertrand meyer, 86. você define o que o componente promete, o que exige, e os limites. é exatamente assim que se fala com um agente: input, output, invariantes. specs, schemas, json contracts. sem o contrato você não tem nem como começar.
tracer bullets
uma vertical fina ligando o ponto a ao ponto z, mesmo que feia, em vez de planejar tudo no papel. a ia turbina o tiro, não a pontaria — você ainda decide onde mira.
orthogonality
componentes independentes, mudanças isoladas. acoplamento alto deixou de ser só problema humano — agora estoura tokens, confunde o agente, derruba a saída. ortogonalidade saiu de “boa prática” e virou pré-requisito de produtividade.
configure, don’t integrate
o capítulo era sobre não compilar configuração no código. mcp é configure, don’t integrate elevado a protocolo. cada conector novo é uma config, não uma integração — hunt e thomas escreveram a spec 25 anos antes dela existir.
programming by coincidence
o mais perigoso. é quando o código funciona e você não sabe por quê — mas segue, porque tá funcionando. com ia virou o caminho de menor resistência: o agente entrega, parece ok, você dá merge. se você não entende o que aceitou, você não é engenheiro do sistema, é o cara que apertou enter.
conway’s law
sistemas espelham as estruturas de comunicação de quem os constrói. vale pra agente também. se um faz o trabalho de três e os outros ficam parados, você desenhou um time disfuncional. conway tá rindo no túmulo.
e aí?
tem um meme antigo de alguém olhando pra um livro de 1995 e percebendo que ele descreve, com outras palavras, exatamente o problema que você está resolvendo hoje. é assim que me sinto relendo hunt e thomas, brooks, fowler, mcconnell.
não é que eles previram a ia. eles estavam descrevendo princípios que sobrevivem a qualquer geração de ferramenta. a pá mudou — agora a pá cava sozinha — mas o terreno é o mesmo.
a diferença é que antes a gente conseguia ignorar e ainda assim entregar. tinha tempo pra refazer, pra retrabalhar, pro arquiteto sênior salvar a pátria no fim do quarter. hoje, com agente cuspindo pr a cada 20 minutos, se sua arquitetura é fraca o agente derruba ela numa tarde. se seus contratos são vagos, o agente faz mil interpretações diferentes na mesma sprint. se seu código é acoplado, ele fica perdido no contexto e gera ruído.
a ia não inventou a engenharia. só tirou a desculpa que a gente tinha pra ignorar.
e talvez — só talvez — a gente sempre tenha sido engenheiro. só estava distraído escrevendo for loop.
ps: o programador pragmático é um livro excelente e vale ser revisitado. ele sobrevive bem se você entender o timing de quando foi escrito e souber separar o que é princípio do que ficou datado. dois episódios de um dos meus podcasts favoritos cobrem isso melhor do que eu conseguiria aqui: o grandes livros de tecnologia do hipsters, e a versão revisitada que eu tive a alegria de participar.