Godot baniu código de IA: o recado para devs

O Godot não proibiu desenvolvedores de usarem IA; ele proibiu contribuições em que a autoria e o entendimento do código não possam ser assumidos por uma pessoa. A decisão, publicada em 30 de junho de 2026, é um aviso direto para empresas e projetos open source: IA pode acelerar desenvolvimento, mas não pode substituir responsabilidade técnica.

O que o Godot mudou na prática?

Em seu comunicado oficial, a Godot Foundation afirmou que vai atualizar as diretrizes de contribuição para exigir que todo código seja escrito por humanos. A política permite usos limitados de IA para tarefas mecânicas, como autocomplete, regex, busca e substituição, mas veta código substancial gerado por IA, pull requests enviados por agentes autônomos e textos gerados por IA em comunicações entre pessoas.

A regra também exige transparência: se o contribuidor usou IA de alguma forma relevante para escrever código, precisa declarar isso na discussão do PR. Segundo a própria fundação, o objetivo é preservar mentoria, confiança e capacidade de manutenção. A cobertura do PC Gamer destacou a frase que resume a tensão: mantenedores não podem confiar que usuários pesados de IA entendem o código o suficiente para corrigi-lo depois.

O ponto mais relevante para desenvolvedores é que a política não trata IA como uma ferramenta proibida, mas como uma fonte de risco quando remove o elo de responsabilidade. Isso muda a pergunta de “foi feito com IA?” para “quem consegue explicar, testar, corrigir e manter isso daqui a seis meses?”.

• Permitido: autocomplete, pequenas transformações mecânicas, regex, refatorações simples e tradução automática de texto humano.
• Restrito: uso relevante de IA sem divulgação no PR.
• Proibido: código substancial gerado por IA, agentes autônomos abrindo PRs e comunicação humana escrita por IA.
• Consequência: uso autônomo ou “vibe coding” pode levar a banimento do repositório do projeto.

Por que isso importa para times de software?

Porque o custo real da IA no desenvolvimento não aparece no momento em que o código é gerado. Ele aparece no review, no bug de produção, na auditoria de segurança e na próxima migração de arquitetura. Em projetos open source grandes, cada PR ruim consome tempo de mantenedores que já trabalham com filas longas e regressões delicadas.

Esse é o mesmo diagnóstico que Carson Gross, criador do htmx, descreveu em Working With AI: A Concrete Example: a IA ajudou em partes do raciocínio, mas também produziu caminhos plausíveis e errados. A diferença entre usar IA bem e mal estava no “laço curto”: o humano mantinha contexto, executava testes, lia o código e interrompia a ferramenta quando ela começava a inventar.

O blog okTurtles chamou uma abordagem parecida de short leash AI coding method. A ideia é simples: o agente pode sugerir, mas não pode dirigir o projeto sozinho. Para sistemas críticos, bibliotecas compartilhadas ou bases com alta dívida técnica, essa diferença é enorme.

Na prática, empresas que adotaram IA apenas para aumentar volume podem estar transferindo custo para etapas mais caras do ciclo. Um PR gerado em 10 minutos pode exigir duas horas de revisão se o autor não souber justificar decisões, reproduzir testes ou reduzir o escopo.

Como adaptar o fluxo de desenvolvimento com IA?

A resposta não é banir Copilot ou Cursor de todos os repositórios. A resposta é criar limites explícitos por tipo de código, criticidade e responsabilidade. Um CRUD interno, um script descartável e uma engine open source usada por milhares de jogos não têm o mesmo perfil de risco.

Uma política prática pode começar com três níveis. No nível 1, IA é assistente de edição: autocomplete, documentação, testes simples e busca por padrões. No nível 2, IA pode propor implementações pequenas, mas o autor precisa explicar o diff, executar testes e declarar o uso. No nível 3, para segurança, infraestrutura, autorização, billing, criptografia, concorrência e APIs públicas, IA só entra sob revisão humana rígida e escopo pequeno.

Um template simples de PR já reduz muito ruído:

## Uso de IA
- [ ] Não usei IA neste PR
- [ ] Usei IA apenas para autocomplete ou edição mecânica
- [ ] Usei IA para sugerir parte da implementação

## Responsabilidade técnica
Explique a mudança com suas palavras:

## Verificação
- Testes executados:
- Riscos conhecidos:
- Como reverter:

Esse tipo de checklist parece burocrático, mas resolve uma parte essencial do problema: obriga o autor a transformar geração em entendimento. Se a pessoa não consegue preencher “explique a mudança com suas palavras”, o PR ainda não está pronto, independentemente de ter sido escrito por IA ou não.

Para empresas, o impacto também chega na gestão de custos. Em 2026, várias organizações já estão percebendo que tokens, revisões extras e retrabalho entram na mesma conta. A produtividade prometida por IA só se sustenta quando há métricas de qualidade: taxa de rollback, bugs por PR, tempo de review, cobertura de testes, incidentes pós-deploy e manutenção após 30 ou 90 dias.

Qual é o recado para desenvolvedores?

O recado é direto: saber usar IA não substitui saber programar. Pelo contrário, quanto mais poderosa a ferramenta, maior precisa ser a capacidade do desenvolvedor de revisar arquitetura, isolar escopo, escrever testes e reconhecer respostas convincentes, mas erradas.

Para quem contribui com open source, a postura mais segura é tratar IA como par de programação júnior: útil para levantar hipóteses, gerar rascunhos e acelerar tarefas mecânicas, mas nunca como autora final. O commit continua levando seu nome. O bug também.

Perguntas frequentes

Godot proibiu o uso de IA por desenvolvedores?

Não. O Godot proibiu contribuições de código substancialmente geradas por IA e PRs enviados por agentes autônomos. Usos mecânicos, como autocomplete e regex, continuam permitidos com responsabilidade do autor.

Posso usar Copilot ou Cursor em projetos open source?

Depende da política do projeto. A tendência é que repositórios grandes passem a exigir divulgação do uso de IA e prova de que o contribuidor entende, testou e consegue manter o código.

O que é short leash AI coding?

É uma forma de usar IA com controle humano próximo: tarefas pequenas, revisão constante, testes frequentes e interrupção quando a ferramenta começa a sair do contexto. A IA sugere, mas o desenvolvedor decide.

Empresas devem banir código gerado por IA?

Na maioria dos casos, não. O melhor caminho é classificar riscos, exigir transparência em PRs e limitar IA em áreas críticas como segurança, pagamentos, permissões, infraestrutura e APIs públicas.