Aquele if duplicado em três controllers diferentes? O Copilot viu. Aprendeu. E agora repete em todo handler novo que sugere. Parabéns: você criou um estagiário que nunca questiona e copia tudo, inclusive os atalhos que você jurou que ia refatorar “depois”.

Eu sei porque já passei por isso. Aceitei sugestões do Cursor sem pensar, mergei PRs “que funcionam” sem olhar estrutura, e três meses depois o codebase virou um espelho distorcido das minhas piores decisões. A IA não inventou código ruim. Ela amplificou o que já estava lá.

Os números de 2026 confirmam o estrago: código gerado por IA introduz 1.7x mais issues que código escrito por humanos. Custos de manutenção chegam a 4x em dois anos. E a Gartner prevê aumento de 2.500% em defeitos de software até 2028 por causa de abordagens prompt-to-app.

Isso não é alarmismo. É estatística.

O loop de feedback que ninguém te contou

Quando você aceita um snippet do Copilot e faz merge, está enviando um sinal: “é assim que a gente faz aqui”. O modelo aprende com o contexto do seu repositório. Cada atalho vira padrão. Cada gambiarra vira template.

O artigo “Write Code Like a Human Will Maintain It”, que estourou no Hacker News essa semana com quase 300 upvotes, descreve exatamente esse ciclo. O autor conta como duplicou a mesma condicional de controle de acesso em route handlers, background jobs, endpoints de API e webhooks. Funcionava? Funcionava. Mas quando pediu para a IA adicionar um novo endpoint, adivinha o que ela fez: copiou o bloco inteiro mais uma vez.

O problema não é a duplicação em si. É que a IA normaliza a duplicação. Ela vê cinco ocorrências do mesmo padrão e conclui: “aqui a gente duplica”. Extrair para um helper? Criar um middleware? A IA não vai sugerir isso se o codebase inteiro diz o contrário.

# O que a IA aprende com seu código:
# "Ah, aqui eles copiam e colam controle de acesso"

@app.route("/users")
def list_users():
    if not current_user.has_role("admin") and not current_user.has_permission("users:read"):
        abort(403)
    # ... lógica

@app.route("/reports")
def list_reports():
    if not current_user.has_role("admin") and not current_user.has_permission("reports:read"):
        abort(403)
    # ... lógica

# Você pede um novo endpoint e a IA gera:
@app.route("/invoices")
def list_invoices():
    if not current_user.has_role("admin") and not current_user.has_permission("invoices:read"):
        abort(403)
    # ... lógica

O que deveria existir desde o começo:

# Um decorator resolve tudo
def require_permission(permission):
    def decorator(f):
        @wraps(f)
        def wrapper(*args, **kwargs):
            if not current_user.has_role("admin") and not current_user.has_permission(permission):
                abort(403)
            return f(*args, **kwargs)
        return wrapper
    return decorator

@app.route("/users")
@require_permission("users:read")
def list_users():
    # ... lógica limpa

@app.route("/invoices")
@require_permission("invoices:read")
def list_invoices():
    # ... lógica limpa

Mas a IA não vai criar o decorator se você nunca usou decorators no projeto. Ela trabalha com o que tem.

Os números que assustam (e deveriam)

Um estudo publicado em janeiro de 2026 analisou pull requests com código gerado por IA versus código humano em projetos de produção. Os resultados:

Fonte: pesquisa compilada por Second Talent e corroborada por estudos da OWASP e artigos no arxiv.

Não é que a IA escreva código horrível. O código parece bom. Compila. Passa nos testes superficiais. O problema é que por baixo da superfície ele é redundante, acoplado e cheio de edge cases ignorados.

Seniores gastam 20 a 35% mais tempo em code review quando juniors usam pesadamente assistentes de IA. Organizações com alta dívida técnica entregam features 50% mais devagar e gastam 40% mais em manutenção.

“Mas funciona!” e a ilusão da velocidade

Eu ouço isso toda semana. “O Cursor gerou em 10 segundos, funciona, mergei.”

Funcionar é o mínimo. Um SELECT * sem paginação funciona com 50 registros. Com 5 milhões, derruba o banco. Uma query N+1 funciona em desenvolvimento. Em produção com tráfego real, multiplica latência por 100.

A ilusão é confundir velocidade de escrita com velocidade de entrega. Você escreveu 200 linhas em 2 minutos com o Copilot? Ótimo. Agora conta quanto tempo vai levar para debugar quando aquele código quebrar às 3 da manhã num sábado.

Pesquisa da Forrester estima que 75% dos líderes de tecnologia vão enfrentar dívida técnica moderada a severa em 2026. E o déficit estimado de qualidade é de 40%: a diferença entre o volume de código sendo gerado e o volume sendo propriamente revisado.

Estamos produzindo código na velocidade de uma Ferrari e revisando na velocidade de uma carroça.

O efeito Cursor: sessões longas, estado perdido

O Cursor é uma ferramenta incrível. Eu uso diariamente. Mas tem armadilhas que pouca gente discute.

Em março de 2026, o time do Cursor rastreou bugs até três causas raízes: a aba de Agent Review sobrescrevia estado de arquivos, sincronização na nuvem competia com saves locais, e o Format On Save disparava depois de edições da IA. Resultado: o agente fazia mudanças que conflitavam com o que estava realmente no disco.

Pior: sessões de agente rodando por mais de 2 horas podem “dessincronizar” com o estado real do projeto. A IA chama funções que não existem mais ou esquece mudanças que ela mesma fez. Você literalmente tem um assistente com amnésia trabalhando no seu código.

Isso não é defeito do Cursor especificamente. É uma limitação de qualquer ferramenta que opera com contexto limitado num codebase que muda constantemente. O ponto é: confiar cegamente é o erro.

O que acontece quando o junior só sabe IA

Tenho conversado com tech leads de empresas brasileiras e o padrão se repete. Juniors que começaram a carreira já com Copilot e Cursor produzem código rápido, mas quando algo quebra, ficam paralisados. Não entendem por que o código funciona, muito menos por que parou de funcionar.

Não é culpa deles. É culpa de uma indústria que vendeu IA como substituto de fundamento, quando na verdade é um amplificador. Se o fundamento é sólido, a IA amplifica produtividade. Se o fundamento é fraco, amplifica fragilidade.

Um colega me contou de um PR que recebeu: 400 linhas geradas pelo Cursor, testes passando, tudo bonito. Ele rejeitou. Motivo: o código criava uma dependência circular entre três módulos que ia explodir no próximo deploy. A IA não sabia (e não podia saber) que aqueles módulos eram carregados em ordem específica em produção.

Contexto de negócio, arquitetura de deployment, restrições de infraestrutura. Essas coisas não estão no autocomplete.

5 sinais de que sua codebase está no loop destrutivo

Eu compilei esses padrões depois de auditar projetos que usam pesadamente IA. Se você reconhece três ou mais, atenção:

1. Copy-paste disfarçado de pattern

Mesmo bloco de código aparece em 5+ lugares com variações mínimas. A IA aprendeu que “é assim que se faz” e propaga. Refatorar vira pesadelo porque ninguém sabe qual das 5 versões é a “canônica”.

2. Testes que testam a implementação, não o comportamento

A IA gera testes que espelham exatamente o código, incluindo detalhes de implementação. Troca o nome de uma variável interna e 15 testes quebram. São testes frágeis que dão falsa confiança.

3. Abstrações prematuras (ou ausentes)

Dois extremos: ou a IA cria hierarquias de classes desnecessárias para resolver problemas simples, ou nunca extrai abstrações porque o codebase nunca teve uma.

4. Error handling inconsistente

Em um endpoint, erros viram exceções customizadas. No outro, são return None. No terceiro, print("erro") e segue a vida. A IA vê os três padrões e usa qualquer um, aleatoriamente.

5. “Código fantasma” que ninguém usa

Funções, classes e módulos que a IA gerou, ninguém deletou, e agora ninguém sabe se são usados ou não. O codebase cresce sem que a funcionalidade real cresça junto.

Como escapar: o framework “IA como Junior”

Eu trato toda sugestão de IA como se viesse de um junior talentoso que não conhece o projeto. Isso muda completamente a dinâmica.

Review cada sugestão como review de PR

Não aceite autocomplete no piloto automático. Leia. Pergunte: isso se encaixa na arquitetura? Existe um pattern melhor já estabelecido no projeto?

Mantenha o codebase limpo ANTES de usar IA

A IA reflete seu código. Se o código é limpo, as sugestões são melhores. Investir em refatoração não é “perder tempo”. É treinar seu copiloto.

Use linters e formatters agressivos

ESLint com regras estritas, Ruff no Python, clippy no Rust. Faça a máquina rejeitar automaticamente o que a outra máquina sugere de errado. Automatize o que o humano esquece.

# .github/workflows/quality-gate.yml
name: Quality Gate
on: [pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Ruff
        run: ruff check . --select ALL --fix --unsafe-fixes
      - name: Run type checker
        run: mypy . --strict
      - name: Complexity check
        run: radon cc . -a -nc

Documente decisões arquiteturais

ADRs (Architecture Decision Records) dão contexto que a IA não tem. Quando um novo dev (ou a IA) perguntar “por que fazemos assim?”, a resposta está documentada.

Limite o escopo das sessões de IA

Sessões curtas e focadas produzem código melhor que maratonas de 4 horas onde a IA perde o contexto. Peça uma coisa de cada vez. Revise. Commite. Repita.

A ironia da produtividade

Ferramentas de IA prometiam que desenvolvedores iam produzir 10x mais. E de certa forma, produzem. O problema é que 7x desses 10x são código que vai precisar ser reescrito, deletado ou refatorado em 6 meses.

O artigo “Good Tools Are Invisible”, também viral no HN essa semana, argumenta que boas ferramentas desaparecem: você esquece que estão ali porque fluem naturalmente com seu trabalho. Ferramentas ruins chamam atenção para si mesmas, criam atrito, geram complexidade.

IA de código está num ponto intermediário estranho. É produtiva demais para ignorar e perigosa demais para confiar. A solução não é abandonar (seria burrice) nem adotar cegamente (seria negligência).

A solução é tratar qualidade de código como mais importante na era da IA, não menos. Quando um humano escrevia todo o código, o gargalo natural de velocidade era também um filtro de qualidade. Você pensava antes de escrever porque escrever era lento. Agora que escrever é instantâneo, o filtro sumiu.

Reconstruir esse filtro, com processos, com cultura, com ferramentas de análise estática, é o trabalho real de engenharia em 2026.

Checklist prático: antes de aceitar qualquer sugestão de IA

Eu imprimi isso e colei do lado do monitor. Sério. Antes de dar Tab em qualquer autocomplete:

1. Esse código já existe no projeto? Se sim, por que estou duplicando em vez de reutilizar?
2. O error handling segue o padrão do projeto? Ou a IA inventou um jeito novo?
3. Tem efeito colateral escondido? Mutação de estado global, escrita em disco, chamada de rede que não é óbvia?
4. Os nomes fazem sentido no contexto do domínio? Ou são genéricos tipo data, result, temp?
5. Eu entendo cada linha? Se não consigo explicar para um colega, não deveria fazer merge.
6. Esse código sobrevive a um refactor? Se eu mudar a interface de um módulo vizinho, esse código quebra silenciosamente?

Parece básico? É. Mas quantas vezes você pulou todos esses checks porque “a IA gerou e os testes passaram”?

A disciplina de review é a última barreira entre produtividade e caos. Sem ela, você não está programando com IA. Está terceirizando decisões para um modelo estatístico que não sabe o que é deploy, SLA ou cliente ligando às 2 da manhã.

O que vem pela frente

A tendência é clara: modelos cada vez mais poderosos gerando cada vez mais código. O GPT-5.6 Sol, lançado essa semana, já opera sessões de coding agentic de horas. O Claude Code, o Cursor Agent, o Copilot Workspace, todos caminham na direção de “diga o que quer e a IA implementa”.

Quem não construir barreiras de qualidade agora vai pagar caro. Não daqui a 5 anos. Daqui a 6 meses, quando a dívida técnica acumular, os bugs em produção explodirem e o time gastar mais tempo consertando do que construindo.

Código bom continua sendo código que um humano consegue ler, entender e modificar. A IA é uma ferramenta. Poderosa, sim. Mas ferramenta na mão de quem não entende o que está fazendo é só uma forma mais rápida de cavar um buraco fundo demais para sair.

Escreva código como se um humano fosse manter. Porque, por enquanto, ainda vai ser.

—

Inspiração: Write Code Like a Human Will Maintain It (Hacker News, 286 pontos)