Continuamos a medir engenheiros pela parte que foi automatizada.

Há uma frase que engenheiros com vinte anos de experiência dizem agora baixinho, como quem confessa qualquer coisa: já não escrevo código.

Costuma vir com um pequeno pedido de desculpa colado. Não devia. O que essa frase tem de interessante não é o que diz sobre quem a diz. É o que diz sobre os instrumentos que usamos para decidir se essa pessoa é boa no que faz.

O quadro de pontuação foi deitado fora, e quase ninguém deu por isso

Durante cerca de uma década, a indústria classificou a entrega em quatro números e arrumou as equipas em low, medium, high e elite. Esses escalões eram citados em apresentações de administração por gente que nunca tinha lido o relatório de origem, o que costuma ser o sinal de que uma medição passou mesmo a ser estrutural.

Em 2025 o DORA abandonou-os. Os escalões desapareceram e foram substituídos por sete arquétipos de equipa, descritos sobre oito medidas: throughput, estabilidade, desempenho da equipa, desempenho do produto, eficácia individual, tempo passado em trabalho com valor, fricção e esgotamento. Os arquétipos têm nomes em vez de posições, do género que não se põe num diapositivo a fingir que é uma nota.

Pode discutir-se com razão que isto é mais difícil de aplicar do que quatro números e uma escada. É. Mas o motivo da mudança é a parte que vale a pena assentar: metade daquelas oito medidas não é sobre produção nenhuma. Fricção, esgotamento, tempo em trabalho com valor e eficácia individual medem se uma organização está a desperdiçar o juízo que emprega.

É uma admissão muito concreta. Diz que o instrumento antigo media o volume de trabalho e perdia o interesse em saber se o trabalho era o certo, e que essa distinção deixou de ser comportável.

O que os números dizem, e porque é que incomodam

Os dados de 2025 explicam a urgência. Cerca de 90% dos inquiridos declararam usar IA no trabalho, com uma mediana à volta de duas horas por dia, quando no ano anterior eram 75%. Comparando pessoas com características e ambientes em tudo o resto iguais, mais adoção de IA aparece associada a maior eficácia individual, maior throughput, melhor desempenho organizacional e melhor qualidade reportada de código e produto.

E a maior instabilidade na entrega de software.

Vale a pena ler esse par devagar, porque o seu formato é o argumento. A IA moveu quase todas as métricas na direção certa, menos a que diz se o sistema se mantém de pé. As medidas que melhoraram são as que contam produção. A medida que piorou é a que conta consequências.

Se a sua ideia de um engenheiro se construir com as primeiras cinco linhas, os últimos dois anos parecem um triunfo. Se se construir com a última, parecem um aviso. As duas leituras saem do mesmo conjunto de dados, e é exatamente por isso que o quadro teve de mudar.

Isto já aconteceu antes, e sabemos como acaba

Há vinte anos, um bom administrador de sistemas era alguém que configurava bem um servidor. A competência era real e era escassa, e media-se por uma espécie de throughput: quantas máquinas, com que rapidez, com que poucos erros.

Depois chegou a gestão de configuração, e a seguir a infraestrutura como código. O engenheiro deixou de escrever a configuração e passou a descrever o estado pretendido. Hoje ninguém acha que um engenheiro que usa Terraform é menos capaz do que um que configura máquinas à mão. Pelo contrário: consideramos a configuração à mão um risco, porque não se revê, não se reproduz e não se reverte.

O trabalho não desapareceu. Subiu um nível. O que era um ato de produção passou a ser um ato de especificação, e a dificuldade mudou de sítio: deixou de estar em executar bem e passou a estar em decidir bem, porque um erro num módulo passa agora para quatrocentas máquinas em vez de uma.

Nunca chamámos a isso uma queda. Chamámos-lhe maturidade, e subimos os salários em conformidade.

A mesma escada, em três degraus:

O software aplicacional está agora a subir os mesmos degraus, e quem está a passar por isso descreve-o na linguagem da perda. Repare em que degrau a automatização pegou de cada vez. Pegou no da esquerda, e deixou o da direita exatamente onde estava.

O que subiu mesmo de nível

Vale a pena ser preciso sobre que parte do trabalho mudou, porque a resposta é mais pequena do que o entusiasmo sugere e maior do que os céticos admitem.

O que ficou barato foi a transcrição. Passar para sintaxe que uma máquina aceita uma decisão que já estava tomada. Era sempre a parte menos interessante, e consumia uma fatia enorme do dia.

O que não ficou barato é tudo o que vem antes da primeira linha: se aquilo deve ser um serviço ou uma função, qual é o modo de falha quando o terceiro está em baixo, qual destes dois modelos de dados vai doer daqui a dezoito meses, se aquela integração cria uma dependência de que o negócio não consegue sair. Escrevemos sobre o lado da qualidade do código em a IA resolveu a sintaxe, não resolveu o julgamento. Isto é a versão organizacional da mesma fronteira.

Um agente já escreve o código, gera os testes, abre o pull request e atualiza a documentação. São tarefas de produção e estão a ser automatizadas por essa ordem. O que nenhum agente faz hoje é dizer que aquilo que acabou de construir com todo o cuidado não devia existir.

A coluna da direita não é uma lista de coisas que os modelos nunca farão. É uma lista de coisas que exigem conhecer a organização, a sua história, os seus contratos e o seu apetite pelo risco. Isso não são capacidades de um modelo. É contexto que na maior parte não está escrito em lado nenhum, e é por isso que quem o tem passou a valer mais, e não menos.

As decisões que não têm sugestão automática

Na prática, as decisões que determinam se um sistema sobrevive tomam-se antes de se escrever seja o que for, e são menos do que se pensa. Num projeto normal contamos talvez uma dúzia que importem.

• Onde cai a fronteira entre dois sistemas, porque essa fronteira passa a ser um contrato e contratos são caros de mudar.
• O que acontece quando uma dependência não está disponível, que é uma decisão de negócio disfarçada de técnica.
• Que dados são o sistema de registo, porque tudo a jusante herda essa escolha.
• O que o sistema pode fazer sem uma pessoa, que passou de pergunta teórica a pergunta a sério.
• O que se decide deliberadamente não construir, que é a decisão menos escrita e mais lamentada.

Cada uma cabe numa frase e nenhuma se delega a algo que não leu os últimos quatro anos de decisões da sua organização. Acertando nelas, código medíocre sobrevive. Errando, código excelente, gerado depressa, chega mais depressa a um sítio onde não queria estar.

Um exemplo recente, e de propósito sem brilho nenhum. Uma equipa precisava de um passo de aprovação de documentos. A implementação óbvia era um fluxo na plataforma onde os documentos já viviam, e um assistente produz isso numa tarde, corretamente. A pergunta que ninguém fez primeiro foi se a aprovação era uma propriedade do documento ou um facto de negócio. Era um facto de negócio: a mesma aprovação tinha de ser visível a um sistema que nunca teria acesso à biblioteca de documentos. A tarde de código correto teria sido deitada fora dentro do ano, e o custo não teria sido a tarde. Teriam sido os seis meses em que dois sistemas discordavam sobre o que tinha sido aprovado.

Aquela decisão levou vinte minutos e nenhuma linha de código. É também a razão inteira pela qual o projeto não teve de ser refeito, e não apareceria em medição nenhuma da produção daquele engenheiro naquela semana.

A frase não é uma confissão

Portanto, quando um engenheiro experiente diz que já não escreve muito código, a leitura honesta costuma ser o contrário da leitura envergonhada.

É a mesma frase que um administrador de sistemas teria dito em 2012 sobre configurar servidores à mão, e hoje ninguém ouve aquilo como uma queda. Significa que a pessoa passou de produzir artefactos a decidir quais devem ser os artefactos, que é a direção para onde todas as disciplinas de engenharia foram à medida que as suas ferramentas amadureceram. Os engenheiros de estruturas deixaram de desenhar cada linha à mão. Isso não fez deles desenhadores com menos competências.

O risco da frase é outro, e vale a pena nomeá-lo. Um engenheiro que deixa de escrever código por completo acaba por deixar de conseguir avaliar o código que está a aprovar, e juízo sem contacto com o material passa a opinião. Quem faz isto bem não está a escrever nada. Está a escrever menos, de propósito, e a ler muitíssimo mais.

O que medir em vez disso

Se o throughput melhorou enquanto a estabilidade piorou, então o throughput deixou de funcionar como aproximação de valor, e continuar a premiá-lo não é neutro. Seleciona ativamente o comportamento que produziu a instabilidade.

As medidas que vale a pena discutir são as que sobrevivem à automatização da produção:

Todas as linhas da direita são mais difíceis de recolher do que as da esquerda, e isso não é acaso. O que prevê se um sistema sobrevive sempre foi mais caro de medir do que o que prevê o quanto a equipa pareceu ocupada. Automatizar o passo da produção tirou a última desculpa para usar as baratas.

A parte que envelhece bem

As ferramentas vão continuar a mexer-se. O modelo que hoje está em produção será substituído duas vezes antes de isto ficar velho, e o agente que este ano abre pull requests fará no ano que vem coisa mais ambiciosa.

O que não se vai mexer é o sítio onde mora a dificuldade. Ela subiu a escada da abstração em todas as disciplinas de engenharia que alguma vez foram automatizadas, e nunca voltou a descer. De cada vez aconteceram as mesmas três coisas: o passo de produção ficou mais barato, o custo de uma decisão errada ficou maior porque passou a propagar-se mais longe, e a profissão passou uns anos incómodos a medir a coisa errada até os instrumentos apanharem o atraso.

Estamos nos anos incómodos. O DORA mudou o instrumento em 2025; a maior parte das organizações ainda não mudou o seu.

O valor de um engenheiro nunca foi de facto o teclado. Só era mensurável assim, que é uma afirmação diferente, e essa acabou de caducar.