Como vamos definir os novos devs sêniors?

Tem uma pergunta que anda martelando na minha cabeça toda vez que vejo alguém se apresentando como "sênior em X" ou "domino a linguagem Y": domina como, exatamente?

Não é implicância ou algo assim. É que a régua mudou muito de uns tempos pra cá, e acho que muita gente ainda não percebeu direito o tamanho da mudança.

Até pouco tempo atrás, bom, pouco tempo não, uns 5 anos ou até mais
dizer que alguém "sabia programar rápido" ou "resolvia problemas complexos com facilidade" dizia alguma coisa sobre a pessoa. Hoje, isso diz também, e talvez principalmente, sobre qual ferramenta ela está pagando.

Uma pessoa com acesso a uma IA de ponta, na versão mais forte, paga, com contexto longo e boa integração no editor, entrega código num ritmo que simplesmente não é comparável ao de alguém usando uma versão gratuita, mais limitada, de outro modelo.
Mas claro que o conhecimento da pessoa tem um peso nisso, o canal da Codecon já mostrou muito bem que júnior com IA conseguem entregar mais que um Sênior sem IA(muitas vezes com qualidade menor, mas entregam mais)

E aí mora o problema: a programação virou uma bolha relativística. A régua de "quão bom você é" se esticou ou encolheu dependendo de qual ferramenta está nas suas mãos, e isso é quase invisível de fora. Nenhum recrutador pergunta "qual plano de IA você usa" numa entrevista técnica. Mas talvez devesse.

Uma coisa que me incomoda, hoje é extremamente fácil parecer dominar uma linguagem enquanto, na prática, quem está resolvendo o problema é o modelo. Você lê o código, entende o suficiente pra saber que funciona, ajusta um detalhe aqui e ali, e entrega. Isso é uma habilidade real, saber orquestrar, revisar, validar. Mas é a mesma habilidade que a gente historicamente chamou de "senioridade"?

Antes, senioridade era proxy pra um conjunto de coisas, profundidade técnica, capacidade de debugar sem ajuda, intuição sobre trade-offs de arquitetura, cicatrizes de produção. Hoje, uma pessoa júnior com boa IA paga pode simular boa parte dessas entregas sem ter, ainda, internalizado nada disso. E o inverso também é verdade: tem gente sênior de verdade que, sem IA, entrega mais devagar que um júnior turbinado, e isso bagunça completamente os sinais que a indústria usava pra avaliar gente.

Mas ao mesmo tempo, negar a IA é viver em um passado que já ficou muito para trás, e os devs que no começo eram contra o uso da IA, hoje em dia usam, e os que mesmo assim se negam, muitos foram demitidos.

Não tenho a resposta pronta, é literalmente por isso que tô escrevendo isso aqui, pra jogar pro debate. Mas algumas perguntas que acho que precisamos encarar:

• Separar velocidade de entendimento. Se tirarmos a IA da mesa por uma hora, a pessoa ainda resolve o problema? Ainda explica o porquê das decisões, não só o quê?
• Avaliar debug, não só criação. Escrever código com IA ficou trivial. Debugar um sistema em produção, sob pressão, quando a IA não tem contexto suficiente pra ajudar de verdade, continua sendo um filtro difícil de fraudar.
• Redefinir o que "saber uma linguagem" significa. Talvez não seja mais escrever sintaxe de cabeça, mas ler criticamente o que a IA gerou e identificar o que está sutilmente errado, que é uma habilidade bem mais difícil e bem menos ensinada.
• Considerar o acesso como variável, não como mérito. Se a ferramenta paga entrega mais rápido, isso é uma vantagem competitiva real, tipo ter um computador mais potente. Faz sentido continuar avaliando "resultado" sem contextualizar "com o quê"?

O TabNews tem gente do mercado todo, de quem contrata a quem tá começando agora. Por isso quero perguntar direto pra comunidade:

Se você fosse montar um processo seletivo hoje, como você separaria sinal de ruído nessa história toda? Você mudaria como avalia entrevistas técnicas? Acha que "senioridade" precisa ser redefinida, ou é balela e os fundamentos continuam os mesmos de sempre, só que com uma ferramenta nova no meio?

Quero muito ler o que vocês pensam nos comentários.