Tem um tipo novo de pesadelo aparecendo no trabalho de quem desenvolve para cliente: o projeto ainda nem foi para produção, mas o dono do negócio já descobriu os agentes de código, saiu empilhando feature por conta própria e depois quer que alguém assine embaixo da manutenção.
Foi exatamente esse o caso relatado em uma thread recente do Hacker News. O autor vinha tocando há um ano um marketplace com integração de fornecedores, pagamentos, catálogo e sincronização de estoque. Aí o cliente começou a brincar com uma plataforma no-code com IA, se empolgou e decidiu levar a mesma lógica para o sistema principal. Em uma semana, segundo o relato, entraram cerca de 10 mil linhas de código novo produzidas com ajuda de agentes.
O detalhe mais importante da história não é que parte desse código “funcionava”. O problema é outro: o projeto deixou de ter dono técnico claro, mas a responsabilidade continuou sendo empurrada para quem conhecia a base de verdade. É aí que a conta começa a ficar cara.
Não é sobre proibir IA. É sobre quem responde pelo que entra no repo.
O autor do post não parece anti-IA. Pelo contrário: ele mesmo disse que usa LLM para tarefas mais chatas e que trabalha com agente de código no próprio dia a dia. A bronca não é com a ferramenta. É com a falsa ideia de que gerar código e assumir software em produção são a mesma coisa.
Quem já segurou sistema vivo sabe que escrever feature é só uma parte do trabalho. Tem performance, rollback, segurança, custo de infra, revisão, deploy, suporte, comportamento em borda e manutenção meses depois. Quando o cliente joga código novo no repositório, mas quer que outra pessoa absorva todo esse risco sem renegociar escopo, o combinado mudou — mesmo que ninguém tenha falado isso em voz alta.
Na thread, uma das respostas foi direta ao ponto: se o cliente vai contribuir com código, ele também precisa aceitar a manutenção desse trecho no longo prazo. Se não aceitar, o preço muda, porque a carga cognitiva mudou junto.
O que assusta no relato é a perda do modelo mental
A melhor frase do relato talvez seja a mais simples: antes, o desenvolvedor tinha um modelo mental claro de como o sistema tinha sido montado. Depois da enxurrada de mudanças, isso começou a se perder. E esse pedaço quase nunca aparece no pitch da IA.
A LeadDev chamou isso de verification debt: a máquina acelera a produção, mas a revisão humana não cresce no mesmo ritmo. Você passa a ter mais código entrando do que consegue verificar com calma. O efeito prático é familiar para qualquer time: mais superfície para bug, mais chance de regressão, mais dificuldade para descobrir de onde veio a decisão ruim quando algo quebra.
Martin Fowler foi na mesma linha ao comentar que a IA funciona como acelerador do que sua operação já é. Se o pipeline já é disciplinado, ela ajuda. Se o processo já é bagunçado, ela vira debt accelerator. Em bom português: a ferramenta não cria governança do nada. Ela só amplifica a falta dela.
Cliente mexendo no código não é novidade. O volume e a velocidade é que mudaram.
Tem um comentário ótimo na discussão lembrando dos tempos em que cliente cancelava projeto porque um sobrinho “fazia no Dreamweaver mais barato”. A tecnologia mudou, mas a ilusão continua parecida: parece fácil porque a parte visível do trabalho ficou mais acessível.
Só que agora a diferença de escala é brutal. Antes, o estrago vinha em páginas tortas ou em um CMS remendado. Agora pode vir em milhares de linhas, com aparência de software sério, espalhadas por partes críticas da aplicação. E justamente por parecerem plausíveis, essas mudanças entram com menos resistência do que deveriam.
Esse ponto conversa bastante com uma recomendação antiga — e ainda válida — de gestão de projeto: todo mundo precisa entender bem o escopo, as prioridades e a ordem das entregas. Quando essa camada some, a IA vira atalho para confundir prototipagem com evolução segura de produto.
Se o cliente quiser usar IA no projeto, os guardrails precisam aparecer antes do caos
O relato do Hacker News é interessante justamente porque ele não pede uma resposta ideológica. Ele pede uma resposta operacional. E aí tem quatro limites que fazem diferença:
1. Código de cliente entra por PR, não por impulso
Se a outra ponta vai mexer no sistema, precisa existir fluxo formal de revisão. Sem isso, você transforma o repositório em balcão.
2. Quem cria uma parte nova assume suporte daquela parte
Não dá para socializar só a autoria e privatizar o prejuízo. Se o cliente quer autonomia técnica, autonomia de manutenção vem no pacote.
3. Escopo e preço precisam ser renegociados
Manter código gerado por terceiros — humanos ou agentes — muda o trabalho. A leitura fica mais lenta, a depuração fica mais cara e o risco de produção sobe.
4. Teste, deploy e rollback viram pré-requisito, não detalhe
Teve comentário na thread lembrando que projeto há mais de um ano sem produção já é um alerta por si só. Quanto mais gente e mais IA mexendo ao mesmo tempo, mais o time precisa de caminho claro entre mudança, validação e rollback.
No fim, o valor do dev continua no julgamento
Talvez essa seja a parte que mais incomoda em histórias assim. Muita gente compra a ideia de que o valor técnico estava só na capacidade de digitar mais rápido. Quando o cliente vê um agente entregando blocos de código em minutos, parece que o resto virou frescura de engenharia.
Mas o que esse caso mostra é o contrário. O valor continua muito ligado ao julgamento: saber o que pode entrar, o que precisa de teste, o que compromete performance, o que vai doer daqui a três meses e o que ainda não está maduro para produção. É esse filtro que impede um sistema importante de virar um amontoado de coisas que “funcionam até a próxima terça”.
Se a IA entrou no projeto, ótimo. Só não dá para fingir que ela também herdou responsabilidade, contexto e accountability. Isso continua sendo humano — e continua custando caro quando some.
