Como ser um Dev Melhor que a IA

Com o avanço da inteligência artificial e a enxurrada de manchetes sensacionalistas vindas de quem lucra com essa tecnologia, os desenvolvedores vivem uma fase de incerteza. Mas será que estamos realmente sendo substituídos? Vamos falar sobre esses medos e, mais importante, sobre como ser um dev melhor que a IA.

humano debatendo com robo como ser um dev melhor

A realidade das Inteligências Artificiais em 2025

Antes de tudo, vamos entender o cenário atual. ChatGPT, DeepSeek e outras IAs já entregam resultados impressionantes, mas altamente dependentes da qualidade de quem as opera. O mantra se repete: você não será substituído por uma IA, mas sim por alguém que sabe usá-la.

Como mencionei na introdução, estamos sendo bombardeados por notícias sensacionalistas sobre “o fim dos devs”. No entanto, a maioria dessas informações vem de CEOs que lucram com o hype e claro de entusiastas que não fazem ideia como a IA funciona, ficando maravilhados com os resultados textuais obtidos e crendo cegamente que o mesmo veio de um pensamento.

Há vários exemplos de ferramentas como o Devin gerando 500 mil linhas de commit e cometendo erros básicos em merges e deploys. Isso acontece porque elas não pensam de fato, apenas geram resultados prováveis. Sim, há avanços no entendimento de contexto, especialização e até uma ilusão de consciência, mas, no fim, tudo ainda se baseia em estatísticas e padrões.

“Ufa, isso nunca vai funcionar!” Nããão… Não, não foi isso que eu disse… Os resultados textuais são impressionantes, e sim, a internet morta está se acelerando, mas isso é outro assunto. O que importa aqui é que, em contextos mais aplicados, como geração de código específico ou execução de tarefas diretas, a IA funciona muito bem. Só não espere que ela faça tudo sozinha—o segredo está em usá-la para pequenos passos sob sua supervisão.

O que nos torna melhores que a IA

Mesmo que o cenário não seja catastrófico, você ainda precisa provar que é muito melhor do que a IA. Então, vamos refletir sobre o que realmente faz um bom dev. Afinal, as chamadas ”inteligências” artificiais foram treinadas com códigos públicos para saber fazer o que você faz hoje: código ruim.

Pois é, você acha que todo código público foi escrito por gênios que seguem as melhores práticas? Provavelmente não. Esses gênios têm coisas mais importantes para fazer. Sim, há códigos excelentes por aí, mas eles são minoria. Portanto, faz sentido concluir que o material de aprendizado das IAs é, no geral, medíocre. E se você entende o básico de IA, sabe exatamente por que ela também será medíocre.

Como ser um dev melhor ?

Chegamos ao ponto mais esperado e você deve estar pensando novamente “Ufa, isso nunca vai funcionar!” , mas novamente vou ter que te jogar para a realidade, pois não é isso que quero dizer. 

Vamos ser realistas: há grandes chances de você ser ou se tornar um dev medíocre, assim como a IA. Vai reclamar das boas práticas, odiar testes unitários, jogar classes sem qualquer organização porque “arquitetura é preciosismo”… Ah, e claro, no seu CV vai ter Orientação a Objetos, SOLID e outras palavras bonitas, mas na prática, você escreve métodos de 200 linhas e acha normal. E talvez seja por isso que tantos devs estão desesperados com o avanço da IA.

Ok, já divaguei bastante e talvez tenha te irritado, mas vamos direto ao ponto: não é tão difícil assim. No meu ambiente de trabalho, uma das coisas que mais valorizo é a confiança.

Confiança ? Estamos falando de código, como assim ?

Bom, é simples… Quando você recebe uma change ou um fix e precisa mexer em um código merda… Se você ainda não passou por isso eu vou exemplificar: 

  1. Você pega um código merda, fica perdido pois aquela porcaria não segue nenhuma arquitetura, logo fica difícil achar o início e o fim.
  2. Depois de um tempo você se acha e nota que uma mudança simples vira um monstro que você precisa alterar em diversos pontos.
  3. Quando você termina, sem chance de um suspiro de alívio, pois existem grandes chances dessa desgraça gerar um incidente em produção, já que o responsável pelo código odiava testes unitários. Agora, você precisa correr o risco de quebrar alguma lógica core que não está documentada.

Viu ? Confiança importa. e pra isso nem vou ser muito chato de falar de OO, SOLID e afins, dou apenas duas dicas simples que são uma carta de amor para o coleguinha que um dia vai mexer em seu código.

Siga a Arquitetura Estabelecida

Poxa, isso é muito simples, mas sério, é difícil achar quem siga, pois o “funcionou na minha máquina” vem sempre na frente. Organize o código de acordo com a arquitetura estabelecida para o seu trampo. Isso vai te diferenciar, mostrar que você se importa além do resultado, até porque o resultado uma IA pode fazer.

Testes Unitários

Esse tópico ficou quase por último porque, sem dúvida, é um dos mais difíceis… Ninguém gosta de escrever testes unitários. Sempre me pergunto o motivo. Acredito que, para muitos, seja pura preguiça de aprender. Depois que aprendi a fazer mocks e asserts de forma realmente eficiente, tudo ficou tão simples que não faz sentido ignorá-los.

O mais legal desse tópico é que posso dizer com tranquilidade: o povo hypa demais as IAs para fazer os testes, mas sabe por que disso? Porque eles não sabem nada de testes unitários e não percebem o quão porco é o código gerado pelo Copilot. Como já falei, o código de treinamento é medíocre, e aqui isso fica muito claro. A maioria dos devs só escreve os testes para dar cobertura de linha nos gates que são disparados nos seus commits e, adivinha… a IA aprendeu a fazer exatamente isso: testes para dar cobertura de linha.

Aqui, você pode ganhar destaque ou ódio. Difícil, né? Eu acho uma maravilha pegar um código e, quando rodo os testes, ele quebra e me avisa que fiz cagada. Mas a maioria só quer que passe logo para dar done na sua atividade.

Vamos precisar de dev melhores no futuro ?

Acredito que a IA estará cada vez mais presente no nosso dia a dia, ganhando destaque em alguns cases. O hype vai crescer e, com isso, os prompt engineers vão se destacar. Porém, com o passar do tempo, vamos perceber que precisamos de pessoas técnicas, pois os fins não vão justificar os meios. Não buscaremos apenas resultados, mas também eficiência e eficácia.

oooooouuuu….

Criaremos código porco em velocidades recordes, sem consciência de performance e organização, com a IA se atualizando apenas com lixo atrás de lixo, comprovando o efeito de poluição recursiva e afunilando cada vez mais para respostas ruins.

Chegaremos ao ponto de o código ruim virar lei ou voltaremos a valorizar conhecimento, eficiência e pessoas dedicadas? Eu acredito na segunda opção, mas e você, o que acha? Deixe aí nos comentários e ajude futuros devs indecisos que não sabem como ser um dev melhor.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Rolar para cima