A Nova Droga da Programação Que Está a Matar Engenheiros

Este texto contém doses perigosas de ironia, provocações que podem ferir egos frágeis e verdades que nem o Copilot consegue corrigir. Se alguma vez disseste “o prompt não funcionou, deve ser culpa do modelo”, continua a ler — és o paciente perfeito para esta reabilitação.

Lembras-te de quando programar exigia pensar? Quando resolver um problema implicava abrir o caderno, desenhar caixas e setas, discutir soluções com a equipa e planear cada passo? Pois… isso era antes da era das LLMs.

Hoje, o ritual é outro: abres o ChatGPT, escreves “faz-me um CRUD com testes e clean arch…” e lá está. Código pronto, ego inflado, dopamina no teto.

É a mesma sensação de abrir o Instagram “só por um segundo” e perceber três horas depois que sabes tudo sobre a vida de um influencer que nem segues. Só que aqui a droga chama-se Dopamine Coding — barato, rápido, legal e altamente viciante. O problema? O crash vem no deploy.

O primeiro “pico” ninguém esquece

A primeira dose é sempre especial. Estás farto de escrever as mesmas funções e decides experimentar IA. Abres um chat, escreves umas linhas, carregas em Enter e de repente tens centenas de linhas de código elegante, testes incluídos e variáveis com nomes mais criativos do que muitos copywriters.

O teu cérebro liberta dopamina em níveis que nem o TikTok consegue igualar. Sentes-te dez vezes mais produtivo. Convences-te de que atingiste o estado de “engenheiro iluminado”.

E até acreditas que, se alguém te perguntasse numa entrevista “como isso funciona?”, terias resposta. (Spoiler: não terias. E se tiveres, provavelmente está errada.)

A ressaca bate mais rápido do que um build falhado

O paraíso dura até à primeira bad trip:

• O código não escala.
• A lógica de negócio está invertida.
• O endpoint responde mais devagar do que tu numa reunião de sexta-feira à tarde.

E agora? Ficas parado, a olhar para o ecrã, com a mesma energia de quem terminou uma maratona de scroll no Reels: não sabes o que aconteceu, não sabes porque estás ali e definitivamente não sabes o que fazer a seguir.

Como qualquer bom viciado, entras em negação:

• “Deve ser o modelo.”
• “Talvez seja a stack…”
• “Deve ser a IDE.”
• “A empresa devia era pagar o Copilot.”
• “E se experimentar outro?”

E lá vais tu abrir novas abas: Claude, ChatGPT, Gemini. Qual vai dar a moca mais forte desta vez?

E se adicionares MCPs à mistura… parabéns, estás no crack da programação. Convences-te de que agora vai correr tudo bem e no fim continuas no mesmo sítio: sem solução e com menos neurónios a funcionar.

Quando a IA estraga mais do que ajuda

O problema não é a ferramenta. O problema é aquilo que deixas de fazer quando a tens: pensar.

E aqui começam os verdadeiros estragos:

• Arquiteturas desastrosas: a IA sugere padrões que fazem sentido… no universo paralelo onde ela vive.
• Negócios incompreendidos: o código resolve um “como” que nunca devia ter sido resolvido.
• Bugs invisíveis: o código funciona, mas ninguém sabe porquê.
• Testes inúteis: a cobertura está a 100%, mas não cobre cenários reais.
• Overengineering: usas ferramentas que nunca tinhas ouvido falar — e ninguém vai conseguir manter — só porque a IA disse que eram “melhores”.

E o final boss? Quando os testes automáticos passam todos, mas o produto rebenta em produção. A cobertura está impecável — e o teu sistema também, desde que nunca seja usado por humanos reais.

O verdadeiro trabalho de um engenheiro: entender o problema

Aqui está a parte que a dopamina te faz esquecer: engenharia não é escrever código. É resolver problemas. E resolver problemas começa por os entender.

Perceber o “negócio” não significa decorar requisitos ou saber os KPI do trimestre. Significa perceber o que estás a tentar resolver, porquê, para quem e com que impacto. É compreender o contexto, as restrições, as prioridades e a dor real que está por trás do pedido.

Sem isso, estás a fazer engenharia às cegas — e o código que a IA gera é só uma resposta bonita a uma pergunta mal feita.

Mas quando sabes o que queres resolver, a história muda completamente. Consegues fazer perguntas melhores. Consegues avaliar soluções com mais clareza. E, de repente, a IA deixa de ser uma muleta e passa a ser um turbo.

Usada neste contexto, a IA é como cafeína de alta qualidade: mantém-te focado e acelera o raciocínio, mas não pensa por ti. Se só a usas para “ver se cola”, estás mais perto do açúcar barato do que da inteligência artificial.

Utilizo IA para resolver o que não merece o meu cérebro

Apesar de tudo isto, continuo a usar IA todos os dias. A diferença é que não a trato como um deus do código, mas sim como um estagiário hiperativo: escreve rápido, não precisa de férias e faz tarefas que não merecem um segundo do meu córtex pré-frontal.

Exemplos concretos:

• TDD mais eficiente: eu defino os cenários e a IA trata da parte GREEN e REFACTOR (às vezes).
• Scripts auxiliares: migração de dados, transformações pontuais, tarefas repetitivas.
• DevOps sem dores: comandos complexos no terminal ou pipelines de CI/CD que não quero decorar.
• Exploração de código legado: para entender rapidamente partes obscuras de sistemas antigos.
• Aprendizagem técnica: rever conceitos como concorrência em Go ou protocolos HTTP mais recentes.

A regra é simples: eu penso, a IA executa. Nunca o contrário.

A linha entre engenheiro e operador de prompts

Se continuarmos a usar IA como substituto do raciocínio, daqui a uns anos não haverá engenheiros. Haverá apenas operadores de prompts a competir para ver quem escreve o “prompt mágico” mais depressa — como ratinhos de laboratório a carregar no botão da dopamina à espera de outra dose.

A verdade é simples:

• A IA pode escrever código, mas não entende o problema.
• Pode sugerir soluções, mas não percebe os trade-offs.
• Pode construir funcionalidades, mas não sabe porquê.

O cérebro humano ainda é a tecnologia mais poderosa que existe. E se o deixares enferrujar, nenhuma LLM vai substituí-lo.

Conclusão – A moral do vício digital

Programar com IA é como açúcar refinado: doce no início, viciante no meio e cheio de efeitos colaterais no fim. No início, tudo parece produtividade e euforia. Depois chegam as desculpas (“deve ser o modelo”, “devia mudar de stack”, “a empresa devia pagar o Copilot”). E, quando dás por ti, passaste mais tempo a afinar prompts do que a resolver problemas.

A moral?

• Pensa primeiro, pede ajuda depois.
• Faz perguntas melhores, em vez de prompts maiores.
• Se a IA for a droga, que o teu cérebro seja o traficante.
• E nunca te esqueças: quem entende profundamente o problema nunca será substituído por quem apenas escreve código.

Porque engenheiros resolvem problemas reais com impacto real. O resto só recarrega tokens e chama a isso trabalho.

Em resumo: a IA não te torna menos engenheiro. Tu é que te tornas, se a deixares pensar por ti. Usa-a como aliada para explorar soluções e acelerar ideias, mas lembra-te de que o verdadeiro diferencial está em perceber o que precisa de ser resolvido e porquê. Essa clareza é a diferença entre quem cria valor e quem só gera linhas de código — e entre quem está a conduzir o futuro e quem está apenas a carregar no botão da dopamina.