Liderança Técnica em Tempos de IA: Que Tipo de Engenheiro Você Precisa Ser Para o Próximo Ciclo

Neste artigo · 9 seções

1. A habilidade que te definia acabou de ficar barata
2. De produtor a juiz
3. De gerar a verificar
4. De escrever código a desenhar o sistema que produz código
5. De fazer a alavancar, e ensinar
6. De escolher tecnologia a negociar risco
7. A armadilha: correr atrás de brinquedo em vez de construir alavanca
8. Conclusão
9. Insights & Takeaways

A habilidade que te definia acabou de ficar barata

Tem um momento meio vertiginoso que muito engenheiro sênior viveu nos últimos dois anos. Você passou quinze anos afiando uma habilidade, escrever código bom, rápido, limpo, e de repente uma ferramenta faz 70% disso em segundos. Não tão bem quanto você. Mas rápido o suficiente, barato o suficiente, e melhorando a cada mês. A coisa que te tornava valioso virou commodity na sua frente.

Kent Beck, um dos caras que ajudou a inventar a forma como a gente desenvolve software, escreveu isso de um jeito que não sai da cabeça, em 2023: "The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x." O valor de 90% das habilidades dele foi a zero, e os 10% que sobraram passaram a valer mil vezes mais. O detalhe que importa é que nem ele sabia, de cara, quais habilidades estavam nos 90% e quais nos 10%.

Essa é a pergunta que fecha esta série e que define a próxima década pra quem é engenheiro sênior, tech lead ou arquiteto: se a geração de código ficou barata, que tipo de engenheiro você precisa ser pra continuar valendo os tais 10%? A resposta não é "aprender a usar a ferramenta". É mais profunda, e mexe com identidade. O trabalho está saindo de produzir e indo pra julgar, alavancar, desenhar e ensinar. Vale entender cada uma dessas viradas.

De produtor a juiz

Quando gerar fica barato, o gargalo deixa de ser produção e vira julgamento. Tem uma frase de um artigo da InfoQ sobre o papel do arquiteto na era da IA, de dezembro de 2025, que resume melhor que qualquer coisa: "The architect's primary skill remains judgment, not generation." A habilidade primária continua sendo julgamento, não geração.

Pensa no que isso significa na prática. Antes, a pergunta difícil era "como eu implemento isso?". Agora a máquina implementa dez versões enquanto você toma café. A pergunta difícil virou "qual dessas dez está certa, e como eu sei?". Isso é taste, é discernimento, é a capacidade de olhar pra três soluções plausíveis e saber qual vai envelhecer bem e qual vai virar uma bomba-relógio em produção. Tem um jeito bom de dizer isso que andou circulando: engenharia na escassez produz competência; engenharia na abundância exige gosto. Quando construir é fácil, saber o que construir, e o que não construir, é a parte difícil.

Esse julgamento não cai do céu. Ele é destilado de anos vendo coisas darem errado. É por isso que a experiência não desvalorizou; ela ficou mais concentrada. Os 10% do Beck, quando ele foi destrinchar, eram mais ou menos isso: saber o que pedir, ter visão do todo, e controlar os níveis de complexidade do design. Tudo coisa que a ferramenta não faz por você, porque ela não tem a cicatriz que ensina.

De gerar a verificar

Se a máquina gera e você julga, o trabalho braçal novo é verificar. E isso é mais traiçoeiro do que parece, porque verificar parece fácil e não é.

Addy Osmani descreveu bem o que ele chama de "problema dos 70%": a IA entrega rápido os primeiros 70% de uma tarefa, o scaffolding, o padrão óbvio, e os últimos 30%, os casos de borda, a integração com o mundo real, a segurança, continuam sendo onde o engenheiro sênior é insubstituível. A consequência operacional é direta: o code review virou o novo gargalo. O júnior manda um PR de aparência pronta que a IA escreveu, e o peso recai sobre quem revisa e entende.

E tem um dado que devia estar pregado na parede de todo time empolgado. A METR, em julho de 2025, mediu desenvolvedores open source experientes trabalhando nos próprios repositórios, com e sem ferramentas de IA. Os devs esperavam acelerar 24%. Na verdade, ficaram 19% mais lentos com a IA. E o mais perturbador: mesmo depois de medido o atraso, eles ainda achavam que tinham ficado mais rápidos. Sentir-se produtivo e ser produtivo descolaram. O engenheiro do próximo ciclo é o que desconfia da própria sensação de velocidade e mede de verdade. Como Simon Willison resume, ferramentas de IA amplificam a expertise que já existe; quanto mais experiente você é, melhor o resultado que tira delas. A ferramenta multiplica quem você já é, inclusive os seus pontos cegos.

De escrever código a desenhar o sistema que produz código

Aqui está a virada mais subestimada, e a mais importante pra quem lidera. Quando a máquina escreve o código, o seu trabalho sobe um nível: você passa a desenhar o sistema que produz o software, e esse sistema é metade técnico, metade social.

Isso não é jargão novo. O conceito de sistema sociotécnico vem de um estudo do Instituto Tavistock, de 1951, que mostrou que não dá pra otimizar só a parte técnica ignorando a social; as duas se otimizam juntas ou nenhuma se otimiza. E tem a Lei de Conway, de 1968, que envelheceu como vinho: "qualquer organização que desenha um sistema vai produzir um desenho cuja estrutura é cópia da estrutura de comunicação da organização". Repara no que acontece quando agentes geram o código: o gargalo deixa de ser digitar e vira desenhar a organização e o contexto que fazem bom software sair. Conway fica mais central, não menos.

Na prática do dia a dia, isso aparece num lugar inesperado: o que chamavam de "engenharia de prompt" virou "engenharia de contexto". Andrej Karpathy e Tobi Lütke cunharam o termo em 2025, e a definição do Karpathy é precisa: é a arte de preencher a janela de contexto com exatamente a informação certa pro próximo passo. Sacou? A habilidade escassa não é escrever um prompt esperto; é arquitetar o ambiente, os dados, as restrições, as ferramentas em que a IA opera. Isso é trabalho de engenharia de sistema, e de novo encosta em Conway: você está desenhando o ambiente que produz o resultado. O Martin Fowler tem uma observação afiada sobre isso, de 2025: os LLMs nos movem não só pra cima na escala de abstração, mas de lado, pra dentro do não-determinismo, e isso não tem precedente na nossa profissão. Você não está mais só programando em um nível mais alto; está programando uma coisa que não responde igual duas vezes.

De fazer a alavancar, e ensinar

Naval Ravikant tem uma frase sobre alavancagem que envelheceu de um jeito assustadoramente bom pra era dos agentes: código e mídia são alavancas sem permissão, a alavancagem por trás dos novos ricos. Ele dizia, anos atrás, que todo grande desenvolvedor já tem um exército de robôs trabalhando pra ele de madrugada enquanto dorme. Na época soava metáfora. Hoje é a descrição literal de um agente rodando.

O ponto pra liderança é este: o engenheiro 10x do próximo ciclo não é o que digita dez vezes mais. É o que multiplica dez vezes mais. E multiplicar tem dois vetores. Um é a alavanca técnica: desenhar os sistemas, as ferramentas internas, os agentes que fazem o time inteiro andar mais rápido. O outro, mais ignorado e mais valioso pra quem lidera, é ensinar. Levantar o piso do time todo vale mais que levantar o seu próprio teto. Numa época em que qualquer um gera código que parece certo, o sênior que ensina o time a julgar, a verificar, a desconfiar da própria velocidade está construindo a alavanca que mais rende. Liderança técnica sempre foi sobre isso, mas a IA tornou urgente: ou você multiplica julgamento no time, ou o time multiplica dívida cognitiva com IA.

De escolher tecnologia a negociar risco

Tem uma parte do papel do arquiteto que costumava ser sobre escolher: banco, linguagem, framework, padrão. Essa parte está encolhendo, porque muita escolha virou commodity. O que cresce no lugar é negociar risco.

Não é coincidência que esta série inteira tenha desembocado aqui. Falamos de governança, de explicabilidade, de ambientes regulados, de custo, de avaliação. Tudo isso é, no fundo, negociação de risco: quanto de autonomia você dá pra um sistema probabilístico, o que você consegue explicar, o que você consegue desligar, quem responde quando erra. O mesmo artigo da InfoQ coloca de forma certeira: a IA não elimina a responsabilidade arquitetural, ela a redistribui. A decisão técnica vira decisão de risco, e alguém precisa assumir essa decisão com nome e sobrenome. Grady Booch insiste num ponto que vale repetir: o humano é sempre o responsável. A máquina propõe; a conta fica com gente. Isso conversa direto com os três pilares do arquiteto que já explorei em Os Três Pilares do Arquiteto: skill e impact continuam, mas leadership, no sentido de assumir risco e responder por ele, é o que mais pesa no próximo ciclo. O engenheiro que vem aí é fluente em risco, não só em tecnologia. Sabe traduzir uma escolha de arquitetura pra linguagem de consequência, e sabe segurar a caneta quando precisa assinar embaixo.

A armadilha: correr atrás de brinquedo em vez de construir alavanca

Tem um jeito fácil de errar tudo isso, e é o mais comum: confundir novidade com alavanca. Toda semana tem um modelo novo, um framework de agente novo, um protocolo novo. Correr atrás de cada um é movimento que parece progresso e não é. A pergunta que separa brinquedo de alavanca é simples: isso aumenta de forma durável a capacidade do meu time de entregar valor, ou só me dá a sensação de estar atualizado?

E tem um custo escondido em delegar demais sem pensar, que já tratei em Da dívida técnica à dívida cognitiva: o time entrega rápido e, seis meses depois, ninguém entende mais o próprio sistema. O antídoto não é recusar a IA; é usá-la de um jeito que preserve, ou até aumente, o entendimento coletivo. No fim, as verdades antigas seguem firmes. Fred Brooks já dizia, em 1986, que a parte mais difícil de construir software é decidir com precisão o que construir, e nenhuma ferramenta remove essa dificuldade, porque ela é da essência do problema, não do acidente da implementação. E o Dijkstra, lá em 1972, lembrava que o bom programador tem plena consciência do tamanho limitado do próprio crânio. Essa humildade fica mais importante, não menos, quando a máquina cospe código com uma confiança que ela não tem como sustentar.

Conclusão

Essa série começou com um conselho aparentemente simples, arruma o CRUD antes de falar em IA, e termina aqui, na pergunta sobre quem você precisa ser. Não é coincidência. As duas pontas dizem a mesma coisa: a IA não substitui fundamento, ela cobra fundamento com mais força. O engenheiro que ela valoriza não é o que gera mais rápido; é o que julga melhor, verifica com rigor, desenha o sistema sociotécnico que produz bom software, multiplica o time e negocia risco com nome e sobrenome.

Já defendi que a IA não vai roubar o seu emprego, em Dev, a IA Não Vai Roubar Seu Emprego. Continuo achando isso. Mas ela vai mudar qual é o seu emprego, e quem não perceber a mudança vai sentir como se tivesse sido roubado. A diferença está em entender que os 90% que ficaram baratos eram a parte mecânica. Os 10% que valem mil vezes mais são exatamente o que faz de você um engenheiro, e não um digitador rápido.

A pergunta honesta pra fechar: se a geração de código não te diferencia mais, o que diferencia? Se você sabe a resposta e está investindo nela, o próximo ciclo é seu. Se a resposta é só "eu codo rápido", você está apostando na única habilidade que a máquina já comoditizou.

Insights & Takeaways

1. A habilidade que te definia, gerar código bom e rápido, virou commodity. Como Kent Beck disse em 2023, 90% das skills foram a zero e os 10% que sobraram valem mil vezes mais. Esses 10% são julgamento, visão de todo e controle de complexidade.

2. Quando gerar fica barato, o gargalo vira julgar e verificar. A METR mostrou em 2025 que devs experientes ficaram 19% mais lentos com IA achando que tinham acelerado. O engenheiro do próximo ciclo desconfia da própria sensação de velocidade e mede.

3. O trabalho sobe de escrever código pra desenhar o sistema sociotécnico que o produz. Conway (1968) fica mais central, não menos, e a engenharia de contexto vira habilidade escassa: arquitetar o ambiente em que a IA opera.

4. O 10x do próximo ciclo multiplica, não digita. As duas alavancas são a técnica (sistemas e agentes que aceleram o time) e a humana (ensinar o time a julgar e verificar). Levantar o piso do time rende mais que levantar o próprio teto.

5. O papel migra de escolher tecnologia pra negociar risco. A IA redistribui a responsabilidade, não a elimina; o humano continua assinando embaixo. Fluência em risco vale mais que fluência na ferramenta da semana.