Ser ultrapassado em desenvolvimento: bagagem técnica ou falta de hype?

Existe um tipo de crítica que dói de um jeito diferente.

Não é a crítica direta — essa você processa, responde, concorda ou refuta. É a outra. Aquela que chega de segunda mão, sem tom de voz, sem contexto, sem chance de réplica.

Essa chegou pelo meu cliente.

Ele ouviu de alguém que eu era bom — mas estava meio ultrapassado.

Eu precisei de alguns segundos. Depois dei uma risada curta. E fui trabalhar.

Mas a frase ficou.

#A primeira pergunta que eu não pude fazer na hora

Ultrapassado por quê, exatamente?

Essa é a pergunta que fica sem resposta quando a crítica não é feita pra você. Você não tem como pedir contexto. Não tem como perguntar o que motivou. Não tem como entender o critério usado.

O que eu sei é que quem disse isso usa HTML, CSS e JavaScript puro. Sem framework. Sem ORM. Sem estrutura.

E eu quero ser cuidadoso aqui, porque não estou interessado em humilhar ninguém que está começando. Todo mundo começa em algum lugar. Eu também comecei sem saber nada.

O problema não é o nível técnico. O problema é outra coisa.

#Tem uma diferença entre não usar e não entender por que existe

Escolher não usar um framework porque você entende o que ele resolve e avaliou que não faz sentido pro seu contexto — isso é decisão técnica. Válida, discutível, mas válida.

Não usar porque você nunca parou pra entender por que frameworks existem — isso é diferente.

Frameworks modernos não nasceram do nada. Eles nasceram do caos. Da bagunça real de manter sistemas grandes sem convenção. Das vulnerabilidades que surgiam quando cada dev reinventava autenticação do zero. Da impossibilidade de trabalhar em equipe quando não existe nenhum padrão compartilhado.

PSRs, ORMs, injeção de dependência, validação centralizada, CSRF automático — cada um desses existe porque alguém apanhou de um problema real antes.

Quando você copia e cola o que a IA gera sem entender o que está rodando, você não aprende por que aquelas proteções existem. Você não aprende a fazer a pergunta certa. E mais importante: você não sabe o que está faltando.

Dificilmente uma IA vai te contar espontaneamente que aquele endpoint sem rate limit é um problema. Que aquele ID incremental na URL é um vetor de IDOR. Que aquela validação só no frontend não vale nada contra um curl direto.

Ela vai te entregar o que você pediu. O que você não pediu, ela não entrega.

#Eu comecei antes de existir metade disso

Tenho 34 anos. Comecei a programar aos 15.

HTML, CSS e PHP — sem Composer, sem PSR, sem nada do que existe hoje, porque não existia. Aprendi jQuery quando jQuery era considerado moderno. Aprendi Bootstrap quando Bootstrap era o que diferenciava um site bonito de um feio.

Aprendi PHP numa época em que PHP não tinha namespace, não tinha tipagem, não tinha autoload nativo. Aprendi fazendo sistema que caía em produção. Aprendi refatorando código que eu mesmo tinha escrito e já não entendia mais. Aprendi mantendo sistema com cliente ligando.

Esse caminho tem um valor que não aparece no currículo. Você vê tecnologia evoluir, entende por que ela evoluiu, e essa compreensão muda como você toma decisões.

Quando eu uso um ORM, eu sei o que ele resolve. Quando eu uso uma framework opinativa, eu sei o que ela me poupa. E quando eu escolho não usar algo, é porque entendi o tradeoff — não porque não conheço a opção.

Isso é bagagem. Não é vaidade. É o que separa executar uma task de pensar como arquiteto.

#O que muda quando você começa a pensar como arquiteto

Tem um momento na carreira de um desenvolvedor em que a pergunta muda.

Ela deixa de ser "como eu faço isso funcionar?" e vira "o que acontece quando esse sistema crescer?"

Isso não aparece do dia pra noite. Aparece depois de você ter mantido sistema grande, depois de ter visto dívida técnica virar auditoria de dois dias, depois de ter acordado de madrugada porque algo foi pra produção sem rate limit.

Hoje, quando eu construo alguma coisa, eu estou pensando em múltiplas camadas ao mesmo tempo: a segurança antes do deploy, a escala antes da feature, a manutenção antes do prazo, o devops antes do código. E ainda o design — porque interface funcional, leve e bem construída não é responsabilidade só de quem "faz o front". É responsabilidade de quem entende o produto inteiro.

Não é sobre saber mais tecnologias. É sobre saber o que perguntar antes de escrever a primeira linha.

#O que "ultrapassado" virou

Antigamente, um desenvolvedor ultrapassado era alguém que não entendia orientação a objetos. Que não entendia banco de dados. Que não entendia segurança básica.

Hoje, em alguns círculos, a definição mudou.

Hoje ultrapassado pode ser sinônimo de ainda usar PHP. De não falar React como língua materna. De não aparecer toda semana no LinkedIn dizendo que acabou de aprender o que vai mudar tudo. De não tratar a IA como substituta de raciocínio.

O problema é que nenhum desses critérios tem a ver com qualidade técnica real.

PHP está na base de mais de 70% da web. Laravel tem ecossistema, maturidade e comunidade que a maioria das stacks emergentes vai levar anos pra atingir. Vue 3 com Inertia e SSR entrega performance, SEO e experiência de desenvolvimento que projetos React mal configurados não chegam perto.

Mas isso provavelmente não foi o critério da crítica.

#O que me incomodou de verdade

Não foi ser chamado de ultrapassado. Isso eu consigo processar.

O que me incomodou foi a direção.

A crítica não veio pra mim. Foi dita para outra pessoa — meu amigo, que também confia o negócio dele às minhas mãos. Isso tem um peso diferente.

Se você tem uma avaliação técnica sobre como eu trabalho, eu estou aqui. Você pode vir, perguntar por que eu uso framework em vez de código puro, por que eu prefiro ORM a SQL concatenado na string, por que eu me preocupo com CSRF em projeto que "é pequenininho mesmo". Eu explico com prazer.

Mas fazer isso a terceiros, sem vir perguntar, é diferente.

Principalmente quando o código que você escreve ainda não chegou no nível de entender o que está criticando.

#Sem framework não é "mais puro". É mais frágil.

Existe um romantismo no código sem framework. Soa independente. Soa como alguém que entende tudo do zero porque não precisa de abstração.

Mas na prática, o que você vê é:

Validação só no cliente, que qualquer curl burla sem esforço. Nenhuma proteção automática contra replay de requisição. Sanitização feita na mão — quando é feita. Lógica de negócio, acesso a banco e resposta HTTP no mesmo bloco de código, crescendo sem limite porque não existe separação de responsabilidade.

Isso não é pureza técnica. É um projeto de exercício de aula que chegou em produção.

Framework não é muleta. Framework é experiência coletiva de anos empacotada em convenção. Você não precisa reinventar proteção contra injeção. Você não precisa descobrir sozinho que senha em texto puro é um problema. Alguém já apanhou por você.

Saber usar isso com consciência é mais sofisticado, não menos.

#O que a IA não substitui

Eu uso IA no meu fluxo de trabalho. Uso bastante. Ela é uma ferramenta que, bem aplicada, muda o que é possível fazer sozinho.

Mas tem uma diferença enorme entre usar IA para trabalhar melhor e usar IA porque você não sabe trabalhar sem ela.

A IA entrega o que você pede. Se você não sabe o que pedir, ela vai entregar algo que parece funcionar. Vai validar no browser. Vai mostrar resultado na tela. E vai deixar vulnerabilidades que você não vai perceber porque nunca parou pra entender o que estava pedindo.

Quem conhece o problema consegue fazer a pergunta certa. Consegue avaliar a resposta. Consegue perceber quando algo está faltando.

Quem não conhece, copia e cola. E às vezes chega pra terceiros dizendo que quem usa framework é ultrapassado.

#Então sim. Talvez eu seja ultrapassado.

Ultrapassado o suficiente para pensar em arquitetura antes de pensar em feature.

Para me preocupar com segurança antes de fazer o deploy.

Para preferir código que dura a código que impressiona.

Para acreditar que escalabilidade começa na modelagem, não no servidor.

Para tratar devops como parte do trabalho, não como responsabilidade de outra pessoa.

Para ainda achar que entender por que a tecnologia existe é mais importante do que saber o nome dela.

Se isso for ser ultrapassado, eu aceito o título.

#A parte mais irônica de tudo isso

Esse artigo foi redigido por uma inteligência artificial.

Não escrito — redigido. A experiência é minha. As decisões são minhas. Os sistemas em produção são meus. Mas quem organizou as palavras foi uma IA.

Uma IA que não existia quando eu tinha 15 anos e estava escrevendo PHP sem namespace.

Uma IA que hoje é usada como argumento de que quem a usa bem é moderno — e quem tem 19 anos construindo sistema real é ultrapassado.

Existe uma certa elegância nisso.

A ferramenta que deveria me tornar irrelevante foi exatamente a que escreveu esse texto.

E ela só conseguiu fazer isso porque eu sabia exatamente o que eu queria dizer.

Esse post faz parte da série de insights do blog da MC — pensamentos diretos sobre desenvolvimento, arquitetura e o que aprendi construindo sistemas reais.

Tem um projeto que cresceu além do controle? Fala comigo.