---
title: "O Peso da Experiência: Quando o Sênior de Ontem Vira o Gargalo de Amanhã"
description: "As empresas contratam liderança técnica pela maestria em Scrum e na velha guarda ágil, um paradigma que a engenharia com IA está tornando obsoleto. A analogia é cruel: é como nomear o bancário do boleto para liderar na era do Pix."
author: "Anderson Henrique"
date: "2026-06-30T23:43:48.308522Z"
updated: "2026-06-30T23:55:41.503069Z"
category: "philosophy"
tags: ["IA","Engenharia de Software","Liderança Técnica","Cyborg Developer","Contratação","NTLabs"]
canonical: "https://www.ntlabs.dev/blog/peso-experiencia-engenharia-ia"
locale: "pt"
---

Tenho conversado com muita gente nos últimos meses, em entrevistas, em processos seletivos, em conversas de bastidor sobre quem deveria liderar a engenharia de quem. E saí de quase todas com a mesma sensação incômoda: **os processos estão invertidos.**

As empresas continuam contratando liderança técnica pelo mesmo critério de sempre: anos de estrada, domínio de Scrum, fluência no vocabulário ágil, cicatrizes de mil sprints. Currículos que provam, acima de tudo, **maestria em um paradigma**. O problema é que esse paradigma, o do desenvolvimento "ágil" como o conhecemos, está virando a moda antiga diante dos nossos olhos. E a experiência acumulada nele, que deveria ser ativo, está silenciosamente virando passivo.

## A analogia do boleto

Imagine que estamos em 2021, com o Pix já consolidado como rotina nacional, e uma fintech decide contratar como diretor de produto um bancário com 40 anos de carreira impecável. Quatro décadas de domínio do boleto, do cheque, do DOC, do TED com janela de compensação, da fila do caixa. Ninguém entende de "dinheiro" como ele.

Só que o dinheiro mudou de natureza. Ele virou instantâneo, programável, 24/7, sem intermediário. E aqui está a parte cruel: **toda aquela experiência não é neutra.** Ela não é um zero que apenas falha em ajudar: é um número negativo. Quarenta anos de boleto criaram intuições, "boas práticas" e reflexos profundos que, no mundo do Pix, são exatamente os movimentos errados. A experiência, nesse caso específico, não é vantagem. É **ruína.**

Não porque a pessoa não seja brilhante. Mas porque o ativo mais valioso dela, um modelo mental refinado por décadas, foi construído sobre uma fundação que o chão acabou de engolir.

## Por que "ágil" é o boleto desta história

Sejamos honestos sobre o que o Scrum resolvia. Ele foi uma resposta organizacional a uma **escassez fundamental: a de produção de código.** Escrever software era lento, caro e arriscado. Então criamos cerimônias para gerenciar essa lentidão: estimar a incerteza em story points, fatiar o trabalho em sprints, sincronizar humanos em dailies, proteger o time da mudança de escopo com rituais.

Quase todo o aparato ágil existe para administrar o **custo e a imprevisibilidade de digitar código.** Era a contabilidade da escassez.

E essa escassez está acabando. Quando uma parte significativa da implementação passa a ser orquestrada com IA, a restrição deixa de ser "quanto código conseguimos produzir nesta sprint" e passa a ser **"quão bem conseguimos especificar, validar e arquitetar a intenção".** O gargalo migra das mãos para o julgamento. E quando o gargalo se move, todo processo otimizado para o gargalo antigo vira teatro: a daily vira teatro, o story point vira teatro, a sprint vira teatro.

O CTO contratado pela maestria nesse teatro vai, com a melhor das intenções, **otimizar o navio para um vento que parou de soprar.**

## Os processos invertidos que vejo nas entrevistas

O sintoma mais claro não é a falta de conhecimento. É a **inversão da pergunta.** Repare na ordem dos fatores:

- Discute-se *velocity* e capacidade do time antes de discutir o que torna uma especificação boa o suficiente para uma máquina executar com fidelidade.
- Mede-se produtividade por código entregue, num mundo onde gerar código virou commodity e o caro virou **revisar, validar e entender** o que foi gerado.
- Trata-se a IA como uma ferramenta de autocomplete que "acelera os devs", quando ela é, na verdade, uma **mudança de paradigma na unidade de trabalho.**
- Protege-se o processo da mudança, quando a vantagem competitiva passou a ser a velocidade de *re-arquitetar* diante dela.

São lideranças tentando encaixar uma realidade nova nas categorias antigas. E categorias antigas são pegajosas precisamente quando são bem-sucedidas. **Ninguém abandona um mapa que funcionou a vida inteira só porque o território mudou.**

## A distinção que salva a tese de virar preconceito

Aqui preciso ser cirúrgico, porque é fácil ler tudo isso como "demita os sêniores e contrate os juniores que mexem em IA". Não é isso. Seria trocar um dogma por outro.

Experiência e obsolescência **não são a mesma coisa**. Elas só costumam andar juntas. O que envelhece mal não é o conhecimento; é o **apego ao paradigma** em que esse conhecimento foi adquirido. Há dois tipos de senioridade, e elas estão sendo confundidas no mercado:

1. **A senioridade-como-acervo:** o valor está em *saber as respostas* de um paradigma específico. Essa, sim, deprecia na velocidade em que o paradigma muda, e nunca o paradigma mudou tão rápido.
2. **A senioridade-como-método:** o valor está em *saber fazer boas perguntas*, modelar problemas, ler trade-offs, cheirar risco. Essa é antifrágil. Um engenheiro com vinte anos de bom gosto arquitetural e a humildade de jogar fora os próprios reflexos é, hoje, **a pessoa mais valiosa da sala.**

O problema do mercado não é contratar gente experiente. É contratar pela experiência *errada*: premiar o acervo de um paradigma morto em vez do método que sobrevive à sua morte. A pergunta certa numa entrevista de liderança técnica em 2026 não é *"quantos anos de Scrum você tem?"*. É *"conte-me sobre a última vez que você teve que jogar fora algo que sabia fazer muito bem."*

## O que estamos construindo no lugar

Na **NTLabs**, nossa aposta tem nome: o **Cyborg Developer**. Não acreditamos em "IA que substitui o engenheiro", nem na nostalgia de que "no fundo nada muda". Acreditamos que a unidade de competência deixou de ser o indivíduo ou o modelo, e passou a ser a **intra-ação** entre os dois, a tese central do nosso *Developer Mental Model Framework (DMMF)*.

Na prática, isso reescreve o que pedimos de uma liderança técnica. Menos guardião de cerimônias, mais **arquiteto de intenção**: alguém que projeta as fronteiras dentro das quais humano e IA colaboram, que transforma julgamento em especificação executável, e que mede o time pela qualidade das decisões e das validações, não pela quantidade de linhas que sobreviveram ao fim da sprint.

A experiência continua importando. Só mudou para *onde* ela importa. O bancário do boleto que entende, no osso, o que é liquidez, risco e confiança tem tudo para ser brilhante na era do Pix, desde que aceite que a forma como o dinheiro se move agora é outra. O sênior que prospera nos próximos anos não é o que tem mais respostas. É o que tem o método para **continuar fazendo as perguntas certas depois que as respostas antigas pararam de funcionar.**

A obsolescência nunca vem do tempo de estrada. Vem do dia em que se decide que a estrada já acabou.

---

*Este post faz parte da nossa reflexão sobre **engenharia transparente** na NTLabs: como construímos, contratamos e pensamos software na era do Cyborg Developer.*