Dez anos atrás, uma empresa de 15 pessoas comprava software. Hoje essa mesma empresa constrói. Um painel interno sob medida. Um portal para clientes. Talvez uma funcionalidade com IA que a concorrência ainda não tem. Nada disso veio de um fornecedor. Um ou dois devs construíram tudo dentro de casa.
Isso é novo e está se espalhando rápido. As ferramentas de IA derrubaram o custo de escrever código. Um time pequeno agora entrega coisas que antes exigiam um departamento de engenharia inteiro. Quem fundou a empresa adora: recebe exatamente o que quer, em vez de adaptar o negócio ao produto de outra pessoa.
Aí começam as perguntas. Esse código presta? Vai aguentar quando tivermos dez vezes mais usuários? Esse dev é forte de verdade ou só parece confiante? A maioria das pessoas que constrói software pela primeira vez não tem como responder.
Construir ficou barato. Julgar, não.
O que mudou foi isto. Escrever uma funcionalidade que funciona era a parte difícil e cara. Você precisava de alguém capaz de transformar uma ideia em código rodando, e essa habilidade era escassa. O gargalo era construir, e dava para medir o progresso pelo fato de a coisa funcionar.
Esse gargalo mudou de lugar. Com ajuda de IA, fazer algo funcionar é a parte fácil. Um dev júnior entrega numa tarde uma funcionalidade que fica ótima na demonstração. A tela carrega. O botão faz o que deveria. Parece pronto.
Mas "funciona na demonstração" e "funciona" são afirmações diferentes. É no espaço entre as duas que mora todo o custo: os casos de borda que ninguém testou, a consulta ao banco que cai com volume, a falha de segurança, o código tão enrolado que a próxima mudança leva três semanas. Nada disso aparece na demonstração. Tudo isso aparece depois, geralmente na pior hora.
Julgar esse espaço continua sendo uma habilidade escassa. Sempre foi. A diferença é que você não pode mais usar "funciona" como sinal de "essa pessoa é boa", porque quase qualquer um consegue fazer algo funcionar.
Por que a IA deixa isso mais difícil, não mais fácil
Seria de esperar que a IA deixasse os devs fracos em evidência. Acontece o contrário. Ela esconde esses devs.
O código gerado por IA é confiante e parece limpo. Usa os padrões certos, dá nomes que fazem sentido e parece escrito por alguém competente. Quem não sabe ler código vê um resultado com cara de profissional e conclui que a pessoa por trás também é. Às vezes é verdade. Muitas vezes, não.
O risco novo é o dev que produz muito código plausível e não percebe quando ele está errado. Aceita o que a IA entrega. Sobe para produção. Parece tudo bem. Seis meses depois, você está pagando outra pessoa para desembaraçar tudo, e essa conta é maior do que o que você economizou.
O sinal que você quer não é "essa pessoa produz código". Hoje todo mundo produz. É "essa pessoa sabe separar código bom de código ruim, inclusive o dela e o da IA". Essa habilidade não aparece no print de um portfólio. Aparece no jeito como a pessoa pensa.
Como é um bom profissional de verdade
Um dev forte nesse cenário tem algumas características que você reconhece sem ler uma linha de código.
Ele explica as próprias decisões. Pergunte por que ele construiu algo de determinado jeito e você vai ouvir uma resposta de verdade sobre trade-offs, não um "é assim que se faz". Bons devs sabem que escolheram uma opção entre várias e conseguem dizer do que abriram mão.
Ele conta o que pode quebrar. Devs fracos dizem que está tudo bem. Devs fortes apontam os riscos por conta própria: essa parte não escala depois de certo ponto, isso depende de um serviço que pode cair, cortamos esse caminho para entregar mais rápido e vamos precisar corrigir em tal momento. Ser honesto sobre os limites mostra que a pessoa entende o sistema.
Ele trata a IA como ferramenta, não como muleta. Os melhores devs usam IA o tempo todo e revisam cada linha. Vão dizer a você onde ela economiza tempo e onde eles não confiam nela. Quem se recusa a usar IA ou aceita tudo sem olhar está mostrando um problema de julgamento.
O trabalho dele resiste ao contato com o usuário. O teste real não é a demonstração. É o segundo mês, quando pessoas de verdade usam o produto de jeitos que ninguém previu. Bons devs constroem pensando nesse dia. Dá para perceber pela quantidade pequena de incêndios que eles provocam.
O que perguntar quando você não sabe ler o código
Você não precisa ser técnico para ter uma conversa útil. Estas perguntas revelam julgamento:
- "Em que parte disso você tem menos confiança, e por quê?"
- "Se tivermos dez vezes mais usuários no mês que vem, o que quebra primeiro?"
- "Onde você usou IA para construir isso, e onde decidiu não usar?"
- "O que você cortou para entregar no prazo, e quanto isso vai nos custar depois?"
- "Se um dev novo entrasse amanhã, quanto tempo levaria até ele mexer nesse código com segurança?"
Você não está dando nota para a precisão técnica das respostas. Está prestando atenção se a pessoa pensa em trade-offs e riscos, ou se para ela tudo é "sem problema". O primeiro tipo protege o seu negócio. O segundo entrega a você uma conta que você não vê chegando.
O que uma liderança não técnica pode fazer
Você não consegue avaliar um código que não sabe ler. Então pare de tentar e monte um processo que não dependa disso.
Peça uma segunda opinião técnica antes de se comprometer. Uma revisão de código curta e paga, feita por alguém independente, diz mais do que qualquer entrevista. Um bom revisor olha um código por uma hora e diz se você está pisando em terreno firme ou em areia movediça. Essa hora é o seguro mais barato que você vai contratar.
Contrate pelo julgamento, não pela velocidade de entrega. O dev que entrega um pouco mais devagar, mas explica o raciocínio e avisa dos riscos cedo, vai custar bem menos ao longo de um ano do que aquele que entrega rápido e deixa bagunça. Velocidade é fácil de ver e é a coisa errada para otimizar.
Observe o que acontece depois do lançamento, não durante a demonstração. Conte os incêndios. Um dev cujo trabalho continua rodando em silêncio vale mais do que um que impressiona na estreia e deixa uma fila de bugs para trás.
E quando você não consegue separar o bom do ruim sozinho, trabalhe com quem faz exatamente isso como profissão. É a parte que a maioria das empresas pequenas pula, e é a parte que decide se construir o próprio software foi a melhor decisão que você tomou ou a mais cara.
O risco real
Construir o próprio software é uma vantagem real. Empresas que fazem isso bem andam mais rápido do que concorrentes presos esperando fornecedor. Não estamos argumentando contra.
O risco é achar que a parte difícil acabou quando algo funciona. Não acabou. A parte difícil é saber se a pessoa que construiu merece confiança para a próxima entrega, e para a seguinte, à medida que o seu negócio depende cada vez mais desse software.
A IA deixou fácil construir. Deixou mais difícil avaliar devs. Se você vai construir, leve a sério a segunda parte. É ela que está escassa agora, e é ela que decide como essa história termina.
