O Engenheiro na Era da IA: Por Que o Julgamento Virou a Nova Moeda

Tenho ouvido muito ultimamente o argumento de “Só sobe pra produção. A IA pode mudar depois. Qualidade não importa tanto agora” e queria parar um pouco pra pensar e responder a isso.

Parece pragmático na superfície. Parece moderno. Parece quase o próximo passo natural. Se a máquina escreve o código, por que eu vou passar uma tarde inteira agonizando com o nome de uma função ou com um modelo de dados? Só sobe e deixa a máquina cuidar da próxima iteração.

Mas quanto mais eu penso nesse argumento, mais acho que ele inverte a equação. A IA não fez a qualidade ser menos importante. Ela fez o entendimento virar a única coisa que ainda é escassa de verdade. E eu queria explicar por que acredito nisso.

A Premissa do Código Barato

O argumento do “só sobe” se apoia numa ideia simples: se gerar código é barato, então qualquer pedaço de código é barato, e portanto descartável. Se quebrar, gera de novo. Toca o barco.

O problema é que código nunca foi a parte cara. A parte cara sempre foram as decisões codificadas no código. O modelo de dados que vai viver por cinco anos. A abstração da qual trinta outros módulos vão depender. O formato da API que vira um contrato que você não consegue mais quebrar sem quebrar clientes junto. A IA reduz o custo de digitar. Ela não reduz o custo de estar errado sobre essas decisões. Se é que faz algo, ela aumenta esse custo, porque decisões erradas agora se propagam mais rápido e se acumulam em volumes maiores do que antes.

Subir rápido sempre foi uma virtude quando significava aprender rápido. Vira um vício no momento em que significa não entender o que você subiu.

O Que Eu Tenho Visto Acontecer Quando a Qualidade Cai

Já vi esse padrão se repetir vezes o suficiente pra reconhecer o formato dele.

Uma feature sobe rapidinho. Funciona no caminho feliz. Duas semanas depois, aparece um bug em produção. Algo sutil, uma race condition ou um state update disparando duas vezes. O dev pede pra IA arrumar. A IA produz um patch que parece razoável. O patch resolve o caso reportado. Mas o dev na verdade não entende o código original bem o suficiente pra saber se o patch resolveu a causa raiz ou só mascarou o sintoma. Então ele sobe o patch do mesmo jeito.

Um mês depois, aparece um bug relacionado. Depois mais um. A base de código agora tem três camadas de patches gerados por IA em cima de uma fundação também gerada por IA que ninguém entende direito. Nem o autor original, nem o time, nem a IA na próxima rodada. Refatorar vira algo aterrorizante porque ninguém sabe o que depende do que. Cada mudança vira um cara ou coroa.

E não é hipótese. É exatamente isso que “qualidade não importa tanto” te entrega no sexto mês.

O Risco Silencioso: Virar um Proxy

A versão mais perigosa desse desvio nem é técnica. É cognitiva, e eu acho que vale a pena falar disso abertamente porque entra na vida da gente devagarinho.

Quando você para de ler o código com atenção, quando para de perguntar por que isso está escrito assim, quando aceita a primeira sugestão plausível porque compilou e os testes passaram, algo silencioso acontece: você deixa de ser o autor. Você vira um proxy. Um intermediário. Uma pessoa que encaminha prompts pra um modelo e encaminha o output dele pra um repositório, sem a responsabilidade do julgamento passando por você em nenhuma das direções.

Pra ficar concreto, deixa eu contar uma coisa que vi recentemente. Um dev colocou as variáveis de ambiente direto no objeto window, dentro do index.html de uma aplicação React. Alguém apontou o problema real. Qualquer coisa que você cola no window vai junto com o HTML pra cada navegador que carrega a página, então chave de API, token, URL de serviço interno, tudo fica a um DevTools de distância de qualquer visitante, indexável, cacheável, e fora do seu controle no segundo em que o usuário recebe a resposta. E ele não parou pra pensar. Não abriu a documentação. Não foi atrás do porquê. Ele só voltou pra IA, formulou a pergunta de um jeito que já carregava a resposta que ele queria ouvir, algo na linha de “isso aqui tá correto, né?”, e a IA, sendo IA, achou um caminho pra validar. Pronto, problema “resolvido”. Só que o problema nunca foi o código. O problema foi que o julgamento dele virou um carimbo automático, terceirizado pra uma máquina que não vai sentar no post-mortem quando aquilo virar um incidente de segurança.

E vale gastar um parágrafo no que “incidente de segurança” realmente quer dizer aqui, porque é fácil ler isso como nitpicking de purista e seguir em frente. Não é. Se naquele blob de variáveis tinha uma chave de API de algum provedor de IA ou de pagamento, alguém rodando um scanner básico encontra em minutos. Existem bots varrendo GitHub, CDN, Wayback Machine, archive.org, indo atrás exatamente desse tipo de coisa, e eles começam a queimar a sua cota antes mesmo de você terminar o café da manhã. Você acorda com uma fatura de cinco dígitos e nenhum jeito limpo de provar que não foi você quem usou. Se tinha um token de serviço interno, um atacante agora tem um mapa da sua infraestrutura e um caminho pra dentro dela: endpoint, hostname, padrão de URL, às vezes versão do serviço. Se tinha qualquer coisa que toca dado de cliente, parabéns, você acabou de entrar num cenário de notificação de incidente, com jurídico envolvido, compliance envolvido, e aquela conversa muito difícil com cliente que ninguém quer ter. E o pior, a parte que machuca de verdade: você não consegue “desfazer”. Pode rotacionar a chave amanhã de manhã, mas cada navegador que baixou aquele HTML, cada CDN que cacheou, cada crawler que indexou, todos têm a versão antiga, e você não tem nenhum controle sobre o que vai ser feito com ela. O segredo deixou de ser segredo no instante em que o primeiro usuário carregou a página, e isso é irreversível.

Isso é confortável por um tempo. Parece produtivo. Mas é uma transferência de agência, e junto com a agência vai a responsabilidade, e junto com a responsabilidade vai a parte do trabalho que efetivamente te faz crescer. O engenheiro sênior daqui a cinco anos não vai ser o que mais subiu tickets gerados por IA em 2026. Vai ser aquele que, mesmo usando IA pesado, ainda leu cada diff com intenção, ainda discordou quando algo cheirava errado, ainda perguntou essa é a abstração certa antes de aceitar a que a máquina ofereceu.

Se você terceiriza o pensamento, você não fica com as partes do trabalho que dependem de ter pensado.

Por Que “Saber o Que É Bom” Importa Mais, Não Menos

Aqui tem uma parte que acho que é fácil deixar passar. A habilidade de reconhecer código bom hoje é mais difícil e mais valiosa do que era antes, não menos.

Quando o código é escrito à mão, você geralmente pode confiar que o autor tinha uma razão pra cada escolha. A razão pode estar errada, mas ela existe, e você pode questioná-la. Quando o código é gerado por IA, cada escolha é estatisticamente plausível por construção. Parece código que já funcionou antes, porque foi treinado em código que já funcionou antes. Mas “plausível” e “correto pra esse sistema” não são a mesma coisa. A IA não sabe que o seu time decidiu trimestre passado parar de usar useEffect pra data fetching. Ela não sabe que esse componente específico é renderizado dentro de uma lista virtualizada e não pode segurar estado caro. Ela não conhece o seu domínio.

Você conhece. Esse conhecimento, o contexto acumulado do seu time, da sua base de código, dos seus usuários, das suas restrições, é o que faz um diff ser realmente bom ao invés de apenas plausível. E a única forma de trazer esse conhecimento pra mesa é ler com cuidado, pensar devagar, e se recusar a aceitar output que você não entende.

Boas práticas não ficaram obsoletas. Elas viraram o filtro entre a plausibilidade superficial da IA e as necessidades reais do seu sistema. Naming, separação de responsabilidades, funções pequenas, dependências explícitas, tratamento de erro deliberado. Isso não é ritual de uma era mais lenta. É o que permite um humano ler um diff de mil linhas e notar o único ponto onde o modelo entendeu o domínio errado.

Então o Que o Engenheiro Faz Agora?

Basicamente a mesma coisa que sempre fez, sinceramente, só que em outra altitude.

A gente ainda projeta sistemas. Ainda decide quais problemas valem a pena resolver e quais são distração. Ainda negocia escopo com produto e design. Ainda assume a consequência quando algo quebra às 2 da manhã. Ainda escreve aquele punhado de linhas onde o modelo teria produzido algo quase-certo-mas-não-quite, e essas linhas costumam ser justo as que mais importam. Ainda mentora, revisa, e ajuda a moldar o gosto das pessoas em volta.

O que muda é a proporção. Menos tempo digitando boilerplate. Mais tempo lendo, decidindo, recusando, refinando. Menos mecânico, mais editorial. E uma coisa crucial: o trabalho de entender, esse esforço paciente de construir um modelo mental fundo o bastante pra prever como um sistema vai se comportar, não foi automatizado. Não pode ser. A IA consegue descrever o código pra você, mas ela não consegue fazer o entendimento por você, do mesmo jeito que ler o resumo de um livro não substitui ter lido o livro.

Algumas Coisas que Eu Tento Manter

Se eu tivesse que comprimir tudo isso nos hábitos práticos que tento manter, seriam estes:

Leia cada linha que você commita. Não passe o olho, leia. Se você não entende por que uma linha está ali, ou aprende até entender, ou apaga.

Trate o output da IA como o draft de um colaborador rápido mas cego pro contexto. É um bom ponto de partida. Não é a resposta final.

Mantenha o ofício afiado de propósito. Escreve algo do zero, na mão, de vez em quando. Resolve um problema com o autocomplete desligado. O músculo atrofia rápido e em silêncio, e você só vai notar que ele foi embora quando precisar dele.

Contesta o argumento do “qualidade não importa” quando ouvir isso no seu time. Não como purista, mas como realista. Pergunta como a base de código vai estar em dois anos se todo mundo operar assim. Depois pergunta quem vai ser cobrado pra consertar.

E lembre-se: você é a parte do sistema que carrega a responsabilidade. A IA não recebe uma ligação do suporte às 8 da noite durante o jantar com a família. A IA não lida com o cliente que insiste em algo. A IA não tem que ser responsável por post-mortem. O que sobe com o seu nome sobe com o selo do seu julgamento atrelado, tendo você de verdade o exercido ou não.

Essa responsabilidade não é um peso que a IA está tirando da gente. É a coisa que o trabalho sempre foi, e agora, mais do que nunca, é a coisa que só nós conseguimos fazer.