Ser raso não é o suficiente

Ser raso não é o suficiente

Por muito tempo, eu fui um profissional raso. Não no sentido de ser irresponsável, muito pelo contrário. Eu entregava. Cumpria prazo. Resolvia bug. Subia feature. No fim do dia, o que precisava estar funcionando, estava funcionando. E, sendo bem honesto, isso não foi necessariamente ruim pra mim. Afinal, eu era um cara que não sabia muito bem o que estava fazendo, mas entregava o que precisava entregar, certo?

Só que existe uma diferença enorme entre entregar e entender. No começo da carreira, ser raso é quase uma vantagem. Você não questiona muito, não discute arquitetura, não perde tempo tentando entender como as coisas funcionam por baixo do capô. Você copia um padrão, segue um tutorial, resolve o problema imediato e pronto. O time fica satisfeito, o gestor fica satisfeito e você sente que está evoluindo.

O problema é que o profissional raso só funciona bem enquanto tudo segue o roteiro. Ele começa a falhar quando algo foge do script, quando o bug não está no componente, quando o erro não é de sintaxe, quando o problema não é “de front” ou “de back”. Na prática, quando o problema é de sistema, de processo, de arquitetura ou de uma decisão tomada meses atrás.

É nesse momento que aparece a dependência. Alguém sempre precisa entrar para destravar, alguém precisa analisar com mais calma, alguém já viu aquele tipo de problema antes. E aí vem a parte mais dura de aceitar: não importa o quanto você entrega, você não vira referência. Você vira execução.

Durante muito tempo, eu me apoiei exatamente nisso. Eu era rápido, resolvia, apagava incêndio e seguia para a próxima tarefa. Raramente eu parava para pensar por que aquela API tinha sido desenhada daquele jeito, por que aquele fluxo era síncrono e não assíncrono, por que aquele dado morava naquele serviço e não em outro, qual seria o impacto real daquilo em escala ou o que quebraria se aquele sistema crescesse dez vezes.

Ser raso funciona muito bem enquanto você é guiado. Alguém define o problema, alguém define a solução e você implementa. Só que, em algum momento da carreira, o que passa a ser esperado de você não é mais código. É decisão. É leitura de cenário. É antecipação de problema. É conseguir olhar para um requisito aparentemente simples e enxergar a complexidade escondida nele.

E isso não se constrói com tutorial. Não se constrói apenas entregando tarefa. Se constrói ficando desconfortável, fazendo perguntas que parecem bobas, lendo código que você não escreveu, entrando em discussões técnicas mesmo sem ter certeza, errando, voltando e refazendo.

O meu ponto de virada não foi quando eu comecei a escrever código melhor. Foi quando eu comecei a me incomodar com coisas que antes eu simplesmente ignorava. Logs ruins, fluxos confusos, dependências desnecessárias, acoplamento excessivo, falta de observabilidade, deploy arriscado e ambiente inconsistente deixaram de ser detalhes e passaram a ser problemas reais para mim.

Antes, eu pensava que aquilo não era meu problema. Hoje, isso virou exatamente o meu problema.

Ser raso não é um defeito no início da carreira. É até natural. O erro é permanecer raso, porque com o tempo a régua muda. Você deixa de ser comparado por quem entrega mais cards e passa a ser comparado por quem resolve problemas maiores, problemas que não cabem em uma issue, que não têm descrição clara e que ninguém sabe exatamente por onde começar.

É nesse ponto que o profissional profundo começa a se destacar. Não porque ele sabe tudo, mas porque ele sabe pensar, sabe investigar, sabe conectar pontos e sabe assumir responsabilidade técnica de verdade.

Hoje, quando olho para trás, vejo que a fase em que eu apenas entregava foi importante, mas também vejo que ela tinha um teto. E esse teto já era baixo.

Só que existe um fator novo que deixa esse teto ainda mais baixo: a IA. Ferramentas de geração de código, copilotos e agentes já conseguem entregar, em minutos, exatamente o tipo de trabalho que durante muito tempo sustentou boa parte dos desenvolvedores rasos: CRUD simples, telas repetidas, integrações diretas, validações básicas, refactors mecânicos e até boa parte dos testes. Isso não é um cenário futuro. Já está acontecendo agora, dentro de times reais, em produtos reais, reduzindo tempo de entrega e, principalmente, diminuindo a necessidade de gente que só executa o que foi descrito.

O impacto não é sobre quem programa. É sobre quem apenas implementa. Quem se acostumou a trabalhar sem entender contexto, sem discutir solução, sem participar da definição técnica e sem assumir responsabilidade sobre o sistema como um todo, passa a competir diretamente com uma ferramenta que não cansa, não reclama e não precisa entender o negócio para gerar código aceitável. E, nesse cenário, quem está acomodado, esperando a próxima task bem especificada cair no board, provavelmente vai estar na primeira fila da substituição.

A diferença, daqui pra frente, fica ainda mais clara. IA escreve código, mas não decide arquitetura, não negocia trade-offs com produto, não enxerga risco operacional escondido em um requisito simples, não assume uma falha em produção às três da manhã e não conecta problemas técnicos com impacto real no negócio. Se antes ser raso já tinha um teto baixo, agora esse teto está sendo empurrado para baixo por ferramentas que fazem, melhor e mais rápido, exatamente o trabalho que não exige profundidade.

No fim, talvez o ponto mais importante não seja aprender a usar IA. Talvez seja não continuar sendo o tipo de profissional que a IA consegue substituir sem esforço.