Liderar uma equipa de engenharia nativa de IA: em que se tornou o trabalho quando o output deixou de ser escasso (2026)

Diagrama que mostra métricas de engenharia partidas ao lado de três coisas que os líderes têm de proteger: a compreensão, o discernimento e a autonomia

A maior parte do que se escreve sobre a IA e as equipas de engenharia é sobre efetivos — quem contratar, quem cortar. Escreve-se muito menos sobre a parte que realmente consome a semana de um fundador: liderar as pessoas que continuam lá. Esse trabalho mudou de forma mais silenciosa e mais completa do que as contas das contratações, e a mudança tem uma única causa de fundo. Em toda a história do software, o recurso escasso foi o output. Liderar era sobretudo a prática de conseguir mais: desbloquear, priorizar, proteger o foco, contratar. O output já não é escasso.

O que é escasso agora é a compreensão, o discernimento e a vontade dos bons engenheiros de continuarem a fazer este trabalho. São essas três coisas que um líder de engenharia nativo de IA gere de facto, e nenhuma aparece nos painéis que a maioria das equipas ainda usa. Eis o que se parte, o que as equipas que o fazem bem descobriram, e onde os fundadores se estão a enganar sem darem por isso.

As suas métricas tornaram-se ruído

Comecemos pela instrumentação, porque liderar com números errados é pior do que liderar sem eles. Quando os agentes geram a maior parte do código integrado, as linhas de código, a velocidade de pull requests e o tempo de ciclo deixam de medir aquilo que julga que medem. Passam a medir quanto as suas ferramentas geraram, o que é uma decisão de orçamento e não um sinal de desempenho. Qualquer equipa as consegue duplicar esta tarde.

As métricas que sobreviveram são as que acompanham o fluxo através da restrição, e não o volume que entra nela. A profundidade da fila de revisão e a frequência das mudanças de contexto são os indicadores antecipados úteis — preveem estrangulamentos antes de os números de entrega os mostrarem, porque medem a parte do processo que não ficou mais rápida. A par delas, as práticas que vale a pena adotar são a velocidade de decisão, o cumprimento das políticas e a análise por coortes para detetar a manipulação de métricas, porque um quadro de indicadores que premeia o volume numa era de volume gratuito vai ser manipulado num sprint, normalmente sem que ninguém o pretenda.

Uma ressalva honesta: os ganhos de produtividade medidos graças à IA variam enormemente entre equipas, e a variação acompanha quanto uma equipa investiu em avaliação, governação e na canalização da integração, e não o modelo que escolheu. A fronteira das capacidades raramente é o estrangulamento. Tudo o que está entre um modelo de fronteira e um resultado mensurável é.

A dívida de compreensão é o passivo que ninguém regista

O conceito mais útil que vi ser nomeado este ano é a dívida de compreensão: engenheiros que lançam depressa sem perceberem os sistemas onde estão a lançar para lá de duas ou três camadas, e que vão perdendo aos poucos a capacidade de diagnóstico e de raciocínio que os tornava valiosos. É a irmã da dívida técnica e bastante mais difícil de ver, porque o código parece estar bem. O défice só aparece durante um incidente, quando ninguém na chamada consegue raciocinar sobre porque é que o sistema se está a comportar daquela maneira.

O diagnóstico é reconfortantemente pouco tecnológico: demos semanais. Não relatórios de estado — demos, em que um engenheiro percorre o que construiu e responde a perguntas sobre o porquê. Uma equipa conseguir explicar o seu próprio trabalho é um sinal muito melhor do que produzir mais, e ao contrário de qualquer métrica de painel, um agente não a consegue manipular. O princípio orientador, segundo as equipas que o fazem deliberadamente: delegue o trabalho pesado, não o pensamento.

A questão da qualidade, respondida

Isto não é um argumento de que o código feito com IA é pior. A Shopify reporta taxas de reversão do código feito com IA mais ou menos equivalentes à sua referência anterior à IA — a paridade de qualidade é alcançável. O risco não é o código ser mau. É as pessoas deixarem de o perceber, o que não lhe custa nada este trimestre e lhe custa tudo na sua primeira falha séria.

Padronize a infraestrutura, não as ferramentas

O erro de liderança mais comum neste momento é impor uma ferramenta. Um fundador lê que um assistente está à frente, declara que a equipa o vai usar e trata a adoção como uma métrica de cumprimento. É a camada errada para padronizar, e custa-lhe boa vontade sem benefício duradouro — a classificação vai mudar antes de a implementação terminar.

A abordagem da Shopify é o melhor padrão: em vez de impor um assistente, construíram um proxy de LLM interno — um gateway central que encaminha os pedidos do Claude Code, do Copilot, do Cursor ou de qualquer outra ferramenta por uma única plataforma. Isso dá à liderança aquilo de que realmente precisa: controlo de custos, análise de utilização por equipa e por projeto, e a possibilidade de mudar de modelo sem mexer no fluxo de trabalho de ninguém. Os engenheiros mantêm as suas ferramentas. A empresa mantém a sua opcionalidade. O raciocínio é de uma honestidade desarmante: ninguém sabe ainda que empresa, que fluxo de trabalho ou que modelo vai ganhar.

Isto generaliza-se. Padronize o que é caro de mudar e invisível para cada engenheiro — o gateway, o harness de avaliação, os requisitos de revisão, o caminho de implementação. Deixe em paz o que é barato de mudar e profundamente pessoal — editor, assistente, estilo de prompt.

Dois níveis de lançamento, para que a velocidade deixe de lutar com a qualidade

Quando o output se multiplica, o processo de lançamento torna-se o sítio onde a liderança acontece de facto, e uma única porta para produção transforma-se numa fila com um gestor à frente a tomar decisões apressadas. A resposta da Ramp é um sistema de dois níveis: as equipas implementam em acesso antecipado quando estão prontas, chegando a cerca de 10% dos clientes, e chegar à disponibilidade geral exige provas segundo uma lista de verificação padrão — justificação da funcionalidade, vídeo de demonstração, resumo de KPI, feedback de clientes, análise do percurso do utilizador, prontidão da equipa, estratégia de implementação —, com a liderança a responder às revisões em menos de 48 horas.

A ideia de fundo merece ser interiorizada: velocidade e qualidade deixam de ser um compromisso no momento em que se tem dois níveis de lançamento. Os engenheiros podem lançar continuamente, que é o que torna o trabalho gratificante. O negócio tem uma fasquia real antes de algo chegar a toda a gente. E, sobretudo, o líder deixa de ser o estrangulamento de cada decisão individual, porque a lista de verificação torna explícito o que significa «pronto» em vez de o deixar na cabeça de uma pessoa.

A diferença de perceção que os fundadores estão a ler mal

Esta é a parte que recebe pouco peso, e é um problema de liderança e não técnico. Cerca de 84% dos programadores usam ou tencionam usar ferramentas de IA — mas a perceção piorou, e cerca de 46% dizem desconfiar do que essas ferramentas produzem. A principal frustração não é a IA ser inútil; é o sofrimento específico do output «quase certo» e o trabalho árduo de depurar código que ninguém escreveu.

Adoção não é aprovação. Se está a ler uma utilização elevada das ferramentas como prova de que a sua equipa está satisfeita com a transição, está a ler um número que não diz isso. E nos fóruns onde os engenheiros falam com mais liberdade, as queixas são coerentes e concretas: aumentos de produtividade impostos, métricas impostas, pressão para rever o dia todo código gerado por máquinas, e uma sensação de declínio no seu próprio desenvolvimento profissional. Alguns dizem sem rodeios que aceitariam ganhar menos para não passarem cinquenta horas por semana a orquestrar agentes em vez de exercerem o ofício para que se inscreveram.

Ponha isso ao lado do que realmente impulsiona a satisfação dos programadores, que os inquéritos situam de forma consistente na autonomia e na confiança, à frente da remuneração. Depois repare que o manual habitual — impor a ferramenta, medir a adoção, subir a meta de output — ataca diretamente a autonomia e a confiança. É assim que um líder acaba com uma equipa que usa muito a IA, cumpre os números e começa discretamente a ir a entrevistas.

Dê o exemplo, não imponha

A história de adoção mais eficaz que encontrei não envolve nenhuma imposição. O vice-presidente da Shopify, Farhan Thawar, impulsionou a adoção mostrando o seu próprio uso e apresentando-o como alavanca e não como genialidade: «Não disse vejam quanto trabalho fiz e como sou esperto. Disse: "Vejam como sou preguiçoso."» Esse enquadramento espalhou-se para lá da engenharia, porque dava permissão em vez de uma obrigação.

Também resolve um problema de estatuto que os líderes costumam ignorar. Quando o uso da IA é imposto e medido, usá-la passa a ser admitir que precisava de ajuda. Quando um líder sénior a usa publicamente para evitar o trabalho aborrecido, passa a ser o que devia ser: uma ferramenta que os bons engenheiros usam porque têm coisas melhores para fazer. Esses dois enquadramentos produzem culturas muito diferentes a partir das mesmas ferramentas.

Lidere para a sua fase, não para o ensaio que leu

Um corretivo útil para tudo isto: a liderança técnica certa muda com o tamanho da equipa. Da fase seed até cerca de dez engenheiros, quer construtores que metem as mãos na massa e otimizam a velocidade, não arquitetos que planeiam uma escala que não tem. Entre dez e vinte está o verdadeiro ponto de inflexão, em que as decisões de arquitetura irreversíveis — bases de dados, modelo de DevOps, infraestrutura de testes — endurecem até se tornarem alicerces culturais muito difíceis de reverter. Entre vinte e cinquenta, a pergunta de liderança torna-se de diagnóstico: os seus problemas são de pessoas ou de arquitetura, e a sua estrutura corresponde à resposta?

A maioria dos fundadores que leem isto está no primeiro escalão, em que o conselho honesto é que ainda não precisa da maior parte do aparato acima. Precisa de demos semanais, de um gateway em vez de uma ferramenta imposta, e da disciplina de continuar a perceber o seu próprio sistema.

O que mudar este mês

Retire as métricas de volume das suas revisões. Se linhas de código, PR integradas ou pontos de história aparecem em algum painel de liderança, remova-os. Substitua-os pela profundidade da fila de revisão e pelo tempo até à primeira revisão.
Comece demos semanais, com perguntas. Quinze minutos: alguém mostra o que construiu e responde a perguntas sobre o «porquê». É o seu único instrumento real para a dívida de compreensão.
Ponha um gateway à frente dos modelos, não uma imposição à frente dos engenheiros. Centralize o encaminhamento, os custos e a análise; deixe as pessoas escolherem o seu assistente.
Divida os seus lançamentos em dois níveis. Lançamento contínuo para um grupo pequeno, uma lista de provas para todos os outros. Escreva a lista para que «pronto» deixe de viver na sua cabeça.
Pergunte pela confiança, não pela utilização. Nas próximas reuniões individuais: quanto do que as ferramentas lhe dão é que confia de facto, e onde é que o «quase certo» lhe custa mais tempo? As respostas são o seu verdadeiro roadmap.
Passe orçamento das ferramentas para as pessoas. As organizações destinam cerca de 93% dos orçamentos de IA à tecnologia e 7% a formação, processos e gestão da mudança. Se a sua divisão se parece com isso, a melhoria mais barata disponível é reequilibrá-la.
Use-a o próprio, de forma visível, para as partes aborrecidas. A permissão espalha-se mais depressa do que as políticas.

Esse último número do orçamento é todo o argumento comprimido num rácio. As equipas estão a gastar quase tudo em capacidade e quase nada nas pessoas que a têm de absorver, e depois perguntam-se porque é que a adoção é irregular e a perceção está a piorar. A restrição nunca foi o modelo.

Os líderes que saírem bem desta era não serão os que adotaram mais depressa. Serão aqueles cujos engenheiros ainda percebem o sistema, ainda exercem o seu discernimento sobre o que deve ser construído, e ainda querem lá estar daqui a dois anos. O output nunca foi a parte difícil do trabalho. Só parecia ser.