Pular para o conteúdo
Um programador com óculos e um capuz digital, cercado por linhas de código e uma representação abstrata de IA, simbolizando a interação humana com a inteligênci
Voltar para o Blog

Programar com IA Não É Copiar e Colar: Como Nasce o Frankenstein Digital e o Método de Cinco Regras Que Evita Ele

Equipe Golber.
8 min de leitura
Inteligência Artificial

Entre na sua conta para curtir e guardar o que gostou.

Ouça este artigo

Programar com IA Não É Copiar e Colar: Como Nasce o Frankenstein Digital e o Método de Cinco Regras Que Evita Ele

0:00 / 9:42
1×
Sincronia do destaque
no ponto
Se a voz parecer atrás do trecho marcado, atrase o destaque
Um programador com óculos e um capuz digital, cercado por linhas de código e uma representação abstrata de IA, simbolizando a interação humana com a inteligênci

O Frankenstein digital existe, mas a causa não é a IA: é colar sem ler. A diferença entre copiloto e piloto automático, os dois estudos que provam que revisar não é opcional e o método que eu uso num sistema com pagamento e dado de cliente.

"Quem programa com IA não é programador de verdade." Eu ouço isso de gente boa, e entendo de onde vem: todo mundo já herdou um projeto costurado de trechos gerados, cada um com um estilo, nenhum com teste, que funciona até alguém tocar. O Frankenstein digital existe. Só que a causa dele não é a IA. É o copiar e colar, e copiar e colar sem entender já quebrava sistema muito antes de existir modelo de linguagem.

Programar com IA é outra coisa, e eu faço isso o dia inteiro num sistema que tem escala de trabalho, pagamento, nota fiscal e dado de cliente. Este post é sobre a diferença entre gerar código e guiar a geração de código: o que separa o Frankenstein do produto, e o método que eu uso pra ficar do lado certo.

  • Como o Frankenstein nasce, passo a passo

  • Copiloto e piloto automático: a diferença é quem lê

  • O método de cinco regras que eu uso no meu código

  • Os dois números que provam que revisar não é opcional

Como nasce o Frankenstein

O Frankenstein nasce de um ciclo curto: pedir, colar, rodar, ver funcionar, seguir. Nunca ler. Cada pedido resolve o problema da hora e ignora o que já existe no projeto, então a terceira função que formata moeda convive com as duas anteriores, cada uma com um arredondamento. O sistema funciona porque cada pedaço funciona sozinho. Ele quebra quando um pedaço precisa conversar com o outro, e aí ninguém sabe onde mexer, porque ninguém leu nada.

Isso não é defeito da IA. É o mesmo defeito de copiar resposta de fórum sem entender, que a minha geração fez à exaustão. A IA só acelerou o ciclo: agora dá pra montar um Frankenstein de dez mil linhas em uma semana. E o sintoma mais claro aparece quando o dono do código pede uma correção e a IA, sem contexto de por que aquilo está daquele jeito, "corrige" quebrando outra parte. A pessoa pede de novo. Entra em loop. É o loop que faz o dev experiente dizer que não é programação. Nessa parte, ele tem razão.

Código que ninguém leu não é código. É um pedido que deu certo por enquanto.

Copiloto ou piloto automático: quem lê?

A diferença entre usar a IA como copiloto e como piloto automático não está na ferramenta nem no prompt. Está em uma pergunta: alguém lê o que foi gerado antes de subir? Se sim, é copiloto, e a pessoa que lê é a programadora, com ou sem diploma. Se não, é piloto automático, e não existe programador no processo, só um usuário e um modelo.

Dois estudos mostram por que essa leitura não é frescura. A Veracode testou mais de cem modelos gerando código em quatro linguagens e 45% das amostras reprovaram em segurança, com falhas do OWASP Top 10; e os modelos maiores não foram mais seguros que os menores. Já a METR pôs desenvolvedores experientes pra trabalhar com IA em projetos grandes e mediu que eles ficaram 19% mais lentos, acreditando estar 20% mais rápidos. Juntando os dois: o código gerado tem quase 50% de chance de trazer uma falha, e a sensação de velocidade mente. A única defesa contra os dois é ler.

Copiloto, então, não é metáfora bonita. É uma divisão de trabalho concreta: a IA escreve, propõe, refatora e explica; a pessoa decide o desenho, lê o resultado, testa o que importa e responde pelo que subiu. Quando essa divisão existe, o Frankenstein não nasce, porque cada pedaço novo passa por alguém que conhece os pedaços antigos.

O método que eu uso

No golber.net eu programo com agente (o Claude Code, sobre o qual já escrevi prós, contras e usos práticos) e o sistema tem pagamento, dado de cliente e nota fiscal. Se eu fosse piloto automático, vazar dado de alguém seria questão de tempo. O que evita isso é um método chato, e chato é o ponto:

  1. O agente lê o projeto antes de escrever. Ele recebe as convenções da base (onde fica cada coisa, o que é proibido, qual helper usar) e é obrigado a procurar se já existe algo parecido antes de criar. Isso mata a terceira função de formatar moeda no nascimento.

  2. Teste antes nos fluxos críticos. Pagamento, webhook, permissão, isolamento de dado entre clientes: o teste existe antes da implementação, e a implementação só está pronta quando ele passa. Não é cobertura, é seguro contra o que me faria perder cliente.

  3. Todo teste é validado por mutação. Eu quebro a implementação de propósito e confirmo que o teste falha. Teste que não pega a quebra é decoração, e a IA adora escrever decoração que passa.

  4. Regra que vira lint, não vira memória. O que não pode acontecer (importar o cliente de banco errado numa rota de aluno, usar controle nativo que ignora o tema) vira regra automática que reprova o código. Nem eu nem o agente precisamos lembrar.

  5. Eu leio o diff inteiro antes de subir. Sem exceção, sem "é só uma linha". A linha que derruba o site é sempre "só uma linha".

Repare que nenhuma regra é "escreva prompt melhor". Prompt bom ajuda, mas o que evita o Frankenstein é o que acontece depois da geração: leitura, teste, regra automática. É o mesmo que separa um agente útil de um loop de agentes que só produz erro mais rápido.

Refatorar com IA, do jeito certo

Onde a IA mais brilha como copiloto é na refatoração, e é onde o piloto automático mais estraga. O jeito certo: você diz o que quer que mude e o que não pode mudar ("extraia a validação pra uma função, mantenha o comportamento, os testes atuais precisam continuar passando"), o agente propõe, você lê, roda os testes, e só então aceita. O jeito errado: "melhora esse código". O agente vai melhorar de acordo com o gosto dele, mudar comportamento sem avisar, e os testes (se existem) vão contar a história depois.

O mesmo vale pra estruturar uma solução nova. Antes de pedir código, eu peço um plano: quais arquivos, qual ordem, o que pode dar errado. Leio o plano. Corrijo o plano. Só depois vem o código, em passos pequenos que eu consigo ler. Quem pula o plano recebe dez mil linhas coerentes com uma decisão errada tomada na primeira.

A IA multiplica o que você faz. Se você lê, ela multiplica leitura. Se você cola, ela multiplica Frankenstein.

Se o seu projeto já é um Frankenstein

Não jogue fora. Faça o que eu faço com base herdada: primeiro os testes dos fluxos onde passa dinheiro e dado de cliente, pra saber o que não pode quebrar; depois o agente lê o projeto inteiro e lista as duplicações; depois uma refatoração por vez, com o teste segurando. Em algumas semanas o monstro vira sistema. Se não sabe se é hora de chamar alguém, a hora certa de pedir ajuda técnica tem os sinais. Se o projeto foi feito por outra pessoa e você não sabe por onde começar, o post sobre contratar programador e por que o contrato de manutenção vale mais que o projeto explica o que pedir.

E se você quer ver esse método aplicado no seu código, com o agente configurado, as regras automáticas e os testes dos fluxos críticos escritos, é o que eu faço numa sessão de consultoria técnica: duas horas com o repositório aberto, e você sai com o copiloto no lugar do piloto automático.

Perguntas frequentes

Quem programa com IA é programador de verdade?

Se lê o que a IA gera, decide o desenho e responde pelo que sobe, é. Se só pede, cola e roda, não há programador no processo, só um usuário e um modelo. A diferença está na leitura, não na ferramenta.

O que é o Frankenstein digital?

Um sistema costurado de trechos gerados sem leitura, cada um resolvendo o problema da hora e ignorando o que já existe. Funciona enquanto os pedaços não precisam conversar; quebra quando precisam, e ninguém sabe onde mexer.

Código gerado por IA é seguro?

Não por padrão. No relatório da Veracode, 45% das amostras geradas por mais de cem modelos reprovaram em testes de segurança, e modelos maiores não foram melhores. A defesa é revisão, teste e regra automática.

IA deixa qualquer programador mais rápido?

Não automaticamente. A METR mediu desenvolvedores experientes 19% mais lentos com IA em projetos grandes, enquanto eles achavam que estavam 20% mais rápidos. Ganho real vem de método: contexto pro agente, passos pequenos, teste antes.

Como refatorar com IA sem quebrar tudo?

Diga o que deve mudar e o que não pode mudar, exija que os testes atuais continuem passando, leia a proposta e aceite em passos pequenos. "Melhora esse código" sem limite é convite pra mudança de comportamento silenciosa.

Gostou?
Compartilhar

Quer mais conteúdo desse?

Receba toda semana o que escrevo sobre stack, IA aplicada e negócios solo. Zero spam, descadastro num clique.