Criar código ou só validar o que a IA gerou?

Esse post começou com uma mensagem no WhatsApp. Um dev que ouve o Escovando Bits, mais especificamente o episódio "A IA já roubou seu emprego?", me escreveu assim:

"Cara, tô me tornando um dev júnior que não consegue nem analisar se a IA tá me entregando um código certo."

Parei pra pensar em quanta gente está passando exatamente por isso e nem se deu conta. E, antes de qualquer conselho, preciso confessar: eu também.

Eu também cedo o volante

Uso IA todo dia. Cedo o volante pra coisa genérica sem dó: gerar um boilerplate, revisar um teste, sugerir um refactor. Isso é ótimo, não tem culpa nenhuma nisso.

O problema é quando eu passo do ponto. Já entreguei pra IA tarefa grande demais e, no fim, não sabia direito o que ela tinha feito. Sabe como eu percebo? Quando aparece no sistema uma coisa que eu não sei explicar. Um dia abri um docker-compose e tinha um Redis ali. Eu não tinha decidido colocar um Redis. Ele simplesmente apareceu, e a minha arquitetura tinha mudado sem eu acompanhar.

Isso não é um problema de IA. É um problema de delegação. Acontece igualzinho quando eu delego mal pra uma pessoa: se eu não acompanho, o resultado volta com decisões que não foram minhas, e que eu não entendo. A diferença é que com a IA isso acontece mais rápido e mais em silêncio.

E voltar atrás é literal. Revisar o que foi feito, achar o ponto onde a decisão nasceu, e refazer com mais cuidado. Principalmente com intenção, que é justamente o que faltou da primeira vez.

Gerar não é criar

É essa a linha que separa usar bem a IA de terceirizar o próprio raciocínio.

Imagina que você está sozinho num projeto, sem code review, sem par, sem sênior por perto. Precisa de uma view e vai na IA:

Prompt ruim:

"Cria uma view que lista os usuários cadastrados."

A IA manda um código. Provavelmente funciona. Mas você entendeu o que aconteceu ali? Sabe por que é daquele jeito? Se quebrar, sabe arrumar? Se a resposta é não, o código pode estar rodando, mas está além do seu domínio. Você não programou, você validou a resposta de uma máquina.

Agora o outro jeito:

Prompt bom:

"Quero uma view em Django que recebe um GET com o parâmetro user_id, valida que ele é um inteiro, busca no banco o usuário com esse id, retorna o nome se achar e um 404 se não achar."

A diferença está em quem controla. No segundo, você ditou a lógica, os passos, o que fazer quando dá errado. A IA só preencheu com código aquilo que você já tinha pensado. Você é o autor da solução, ela fez a parte braçal.

É a diferença entre dirigir e pegar carona. Quando você cria, você pilota, e a IA é o copiloto. Quando você só gera, vira passageiro cego: entra no carro e deixa ser levado pra qualquer lugar. O problema não é a carona. O problema é quando você não sabe dirigir e também não sabe se ela te pôs na estrada certa. Aí, quando der errado no meio do caminho, e vai dar, você não sabe voltar. Não sabe onde está, nem como foi parar ali.

O que o mercado pede, e o que ele cobra

Isso não é aflição de dev iniciante sozinho. É um vício que eu vejo em times inteiros.

O mercado pede entrega. Ele quase nunca pede entendimento. Então o time usa IA pra entregar feature atrás de feature e vai entendendo cada vez menos do que está no ar. Funciona, até o dia em que cai. E quando cai, o que o mercado cobra na hora é exatamente o que ninguém cultivou: entendimento. É entender o sistema que faz alguém conseguir consertar.

Tem um efeito mais sutil e mais grave nisso. Um time que não decide, porque a IA decide, é um time que não erra. E quem não erra não aprende com o erro, porque não foi ele que gerou o erro e, muitas vezes, nem é ele que conserta. No fim, não se aprende arquitetura, não se aprende a tomar decisão. Entrega-se muito e forma-se pouco.

Isso me deixa com uma pergunta que eu ainda não sei responder. Se a IA faz o trabalho que o júnior faria, o júnior não erra, não acerta na marra, não rói osso. E era roendo osso que ele virava pleno, e depois sênior. Não vou resolver isso aqui. Mas é uma conta que, mais cedo ou mais tarde, alguém vai ter que fazer.

Como saber se você soltou o volante cedo demais

Não precisa de método complicado. Umas perguntas honestas resolvem:

• Eu sei o que quero que esse código faça?
• Eu consigo descrever em passos o que precisa acontecer?
• Eu li e entendi cada linha do que a IA me devolveu?
• Eu conseguiria explicar isso pra outra pessoa?

Se apareceu algum "não", calma, isso não quer dizer que você é ruim. Quer dizer que talvez você tenha soltado o volante cedo. Aí é hora do que eu chamo de roer osso: sentar, usar o bom e velho Google, entender o caminho, e só então voltar pra IA com a pergunta certa. Pular o roer osso é um atalho que cobra juros depois.

E tem uma régua simples pra saber se o código serve. Se você entendeu, provavelmente está bom o suficiente pro seu momento. Se você não entendeu, ou ele está ruim, ou você ainda precisa entender melhor o que está usando. Rodar código que você não entende não é programar, é sortear bug pro futuro.

O código é seu

IA como apoio é maravilhoso, de verdade. Mas ela soma quando entra junto do seu raciocínio, não no lugar dele. Não quero virar engenheiro de prompt, mas repara numa coisa: um bom pedido costuma começar com "eu preciso fazer isso, isso e aquilo". Quando começa com "faz pra mim", acendeu uma luz amarela.

No fim, o código é seu. A responsabilidade é sua. E o aprendizado também.

Aquele dev que me mandou a mensagem terminou assim:

"Então tô no caminho certo, né? Porque eu tento seguir esses passos."

Tá sim. Não porque acertou tudo, mas porque está se perguntando. Quem para pra perguntar se entendeu já está num lugar diferente de quem só copia, cola e torce.