Godot Acaba de Desenhar uma Linha no Chão

Se você mandou um pull request para a Godot Engine nos últimos meses usando “vibe coding” — aquele esquema de jogar um prompt no ChatGPT e colar o resultado no PR — tenho uma notícia: você provavelmente já foi banido. E se não foi, está na fila.

A Godot Foundation publicou nesta semana uma atualização nas suas políticas de contribuição que, na prática, proíbe código gerado por IA em qualquer contribuição ao engine. Uso de agentes autônomos? Ban automático. PR com código que você não entende o suficiente para consertar sozinho? Rejeitado. Texto gerado por IA na discussão do PR? Nem pensar.

E o mais interessante: a Godot não está sozinha. Ela é apenas o caso mais recente de uma onda que vem varrendo o open source desde o final de 2025.

O Que Mudou Exatamente na Política da Godot

Vamos ao que a fundação realmente disse, sem filtro:

Código gerado por IA é proibido em contribuições substanciais. O uso de IA fica restrito a tarefas “menores” — code completion, regex, find and replace. Basicamente, o que um autocomplete glorificado faria.

Se você usou IA, tem que declarar. Qualquer assistência de IA no código precisa ser divulgada na discussão do PR. Esconder é motivo para rejeição.

Agentes autônomos e vibe coding resultam em ban automático do repositório GitHub. Sem aviso, sem segunda chance. Mandou um agente de IA abrir um PR? Tchau.

Texto gerado por IA em comunicação humana é proibido. Quando um mantenedor voluntário gasta seu tempo revisando seu PR, ele quer falar com uma pessoa — não com um modelo de linguagem. A exceção é tradução automática, desde que o conteúdo original tenha sido escrito por um humano.

Contribuidores novos (3 PRs ou menos aceitos) não podem submeter features novas ou refatorações significativas sem permissão explícita de um mantenedor. Precisa primeiro provar seu valor com correções de bugs e documentação.

A fundação resumiu o espírito da coisa numa frase que vale guardar: “IA não pode assumir responsabilidade, e nós não podemos confiar que usuários pesados de IA entendam seu código o suficiente para consertá-lo.”

Por Que Agora? O Problema É Mais Prático Do Que Filosófico

Quem acompanha a Godot sabe que o número de PRs abertos virou piada na comunidade. A fila é enorme, e o time de revisores é pequeno — como em todo projeto open source mantido por voluntários.

O que aconteceu com a explosão das ferramentas de IA foi previsível: o custo de criar um PR despencou. Qualquer pessoa com acesso ao Copilot ou ao Claude consegue gerar um PR que parece razoável em minutos. Mas o custo de revisar esse PR continua o mesmo — ou pior, porque código gerado por IA frequentemente tem bugs sutis que exigem atenção redobrada.

O resultado? Os mantenedores estão esgotados. Eles gastam horas dando feedback em PRs que foram gerados em 5 minutos, e muitas vezes o contribuidor nem consegue implementar o feedback porque não entende o código que submeteu.

Esse é o ponto que a Godot martela: se eu te peço para ajustar a implementação e você precisa voltar ao ChatGPT para “consertar”, o ciclo de revisão se torna infinito. Eu não estou mentorando um futuro contribuidor — estou treinando o prompt de alguém.

A Godot Não Está Sozinha — E a Lista Só Cresce

Nas primeiras três semanas de janeiro de 2026, três projetos open source tomaram medidas defensivas drásticas por causa de IA:

curl encerrou seu programa de bug bounty que funcionava havia seis anos. O motivo? Uma avalanche de relatórios de segurança gerados por IA que pareciam legítimos à primeira vista mas eram completamente sem fundamento. Daniel Stenberg, criador do curl, estava gastando mais tempo rejeitando lixo do que corrigindo bugs reais.

Ghostty implementou tolerância zero para contribuições de IA. PRs gerados por IA só são aceitos para issues já aprovadas. Contribuições “drive-by” são fechadas imediatamente. Reincidentes são banidos permanentemente — e, segundo os mantenedores, “publicamente ridicularizados”. Pesado? Talvez. Efetivo? Aparentemente sim.

tldraw decidiu fechar automaticamente todos os PRs externos. Ponto final. A situação ficou tão insustentável que a solução foi nuclear: ninguém de fora contribui mais.

E tem mais:

• Git, QEMU e NetBSD proibiram código de IA completamente
• Gentoo Linux baniu contribuições de IA
• Linux Kernel adotou uma abordagem pragmática: exige uma tag Assisted-by para contribuições com assistência de IA e mantém responsabilidade estritamente humana. Linus Torvalds chamou o debate de “postura vazia” mas implementou as regras mesmo assim

Essa tabela resume as abordagens:

O Elefante na Sala: IA É Ferramenta ou Muleta?

Eu consigo ouvir o argumento do outro lado: “Mas IA é só uma ferramenta! É como proibir o uso de IDE ou de Stack Overflow!”

A diferença é sutil mas real. Quando você copia um snippet do Stack Overflow, você (em teoria) lê, entende, adapta e testa. O snippet passa pelo seu cérebro antes de entrar no codebase. Quando você usa IA para gerar blocos inteiros de código, esse filtro humano frequentemente não existe.

Eu já vi PRs onde o contribuidor submeteu 500 linhas de código gerado por IA e, quando um mantenedor perguntou “por que você usou essa abordagem aqui na linha 247?”, a resposta foi: “Hmm, deixa eu perguntar pro Claude.” Isso não é contribuição — é intermediação.

# Isso é usar IA como ferramenta:
# Você sabe o que quer, pede ajuda com sintaxe
regex = re.compile(r'(?P<year>\d{4})-(?P<month>\d{2})-(?P<day>\d{2})')

# Isso é vibe coding:
# Você não sabe o que quer e pede pro modelo decidir
# "me faça um sistema de ECS para a Godot que suporte
#  serialização, networking e rollback"
# [cola 2000 linhas sem ler]

A questão não é se a IA escreveu o código. A questão é se você entende o código. Se entende, ótimo — use todas as ferramentas que quiser. Se não entende, você está transferindo o custo da sua ignorância para os mantenedores.

O Custo Invisível: Burnout dos Mantenedores

Esse é o assunto que pouca gente fala, mas que está no centro de tudo.

Manter um projeto open source grande já era ingrato antes da IA. Agora, com o volume de contribuições de baixa qualidade multiplicado por 10, o burnout entre mantenedores atingiu níveis críticos.

Um dado que circulou bastante: segundo uma pesquisa da Tidelift em 2025, 60% dos mantenedores de projetos open source relataram burnout. Em 2026, com a explosão do vibe coding, esse número só subiu.

O ciclo é perverso:

1. Ferramenta de IA facilita criação de PRs
2. Volume de PRs explode
3. Mantenedores gastam mais tempo revisando lixo
4. Mantenedores desistem ou reduzem atividade
5. Fila de PRs legítimos cresce
6. Contribuidores legítimos desistem de esperar
7. Projeto perde contribuidores bons e ganha contribuidores ruins

A Godot percebeu que estava nesse ciclo e decidiu quebrá-lo com uma política explícita. É uma decisão corajosa? Sim. É controversa? Com certeza. Mas é compreensível quando você vê que os revisores estavam gastando mais energia dando feedback para máquinas do que mentorando humanos.

Como Ficam os Devs que Usam IA de Forma Responsável?

Essa é a pergunta de um milhão de dólares. E a resposta da Godot é razoavelmente nuançada, apesar da manchete sensacionalista.

Usar code completion? Pode. Pedir para a IA gerar uma regex? Pode. Usar IA para entender um trecho de código que você não conhece? Pode (e até deveria).

O que não pode é terceirizar o entendimento. Se você usou IA para escrever uma implementação, precisa ser capaz de:

• Explicar por que cada decisão arquitetural foi tomada
• Modificar o código quando o revisor pedir mudanças
• Debugar problemas sem depender da IA
• Assumir responsabilidade pelo código a longo prazo

Na prática, a regra é: se você removesse a IA do processo, ainda conseguiria ter escrito esse código? Se sim, a IA é uma ferramenta legítima. Se não, você é o intermediário — e o projeto não precisa de intermediários.

# Teste mental antes de submeter um PR:
echo "Eu consigo explicar cada linha deste código?" # sim → submit
echo "Eu consigo modificar sem consultar IA?"        # sim → submit
echo "Eu entendo os edge cases?"                      # sim → submit
# Se qualquer resposta for "não" → não submeta

O Futuro: Mais Projetos Vão Seguir ou Isso É Temporário?

Eu apostaria que mais projetos vão adotar políticas similares nos próximos 12 meses. Não necessariamente bans totais — o modelo do Linux Kernel com a tag Assisted-by pode se tornar o padrão para projetos maiores que não querem ser tão restritivos.

Mas existe uma tendência clara: o open source está se protegendo. E isso faz sentido evolutivo. Projetos que não implementarem algum tipo de controle de qualidade contra contribuições de IA vão afundar em PRs mediocres e perder seus melhores revisores.

Algumas previsões:

Ferramentas de detecção de IA para PRs vão se tornar mais comuns. Já existem bots experimentais que analisam padrões de código gerado por LLMs — estilo de comentários, estrutura de funções, até a distribuição de tokens.

Plataformas como GitHub podem adicionar flags nativas para código assistido por IA, similar ao que o Copilot já faz internamente com telemetria.

CLA (Contributor License Agreements) vão ser atualizados para incluir cláusulas sobre uso de IA, responsabilidade e propriedade intelectual do código gerado.

A distinção entre “assistido por IA” e “gerado por IA” vai ficar cada vez mais difícil. A linha 60 de um arquivo foi escrita por um humano e a 61 por um LLM? E se o humano editou a linha do LLM? Onde termina a ferramenta e começa o autor?

Isso Afeta Quem Usa Godot para Fazer Jogos?

Não diretamente. As restrições se aplicam a contribuições ao engine em si — o código-fonte da Godot no GitHub. Se você está usando a Godot para fazer seu jogo indie, pode usar toda a IA que quiser no seu projeto.

A ironia não passa despercebida: a engine que bane IA do seu desenvolvimento é usada por milhares de devs que dependem de IA para criar seus jogos. Mas faz sentido. O código do engine é mantido por uma comunidade de voluntários que precisa entender, revisar e manter cada linha por anos. O código do seu jogo é responsabilidade sua.

O Que Outros Engines Estão Fazendo

Vale olhar pro outro lado da moeda. A Unity e a Unreal Engine — as duas maiores engines comerciais — não só aceitam IA como estão integrando profundamente nos seus workflows.

A Unity lançou o Muse em 2025, um conjunto de ferramentas de IA generativa para criação de assets, código e level design. A Epic Games integrou IA no Unreal Editor para geração procedural e assistência de código desde o UE 5.4.

Mas tem uma diferença fundamental: essas são empresas com centenas de engenheiros pagos para revisar código. O custo do review é absorvido pela corporação. No open source, o custo cai nos ombros de voluntários que doam seu tempo livre.

Essa assimetria é o que torna a comparação injusta. Dizer “a Unity aceita IA, por que a Godot não?” é como dizer “o restaurante aceita cartão, por que a barraca de feira não?” — os contextos são radicalmente diferentes.

E Se a Godot Estiver Errada?

Pode ser. É possível que, daqui a dois anos, a qualidade dos modelos de IA tenha melhorado a ponto de gerar código que é genuinamente melhor do que a maioria dos contribuidores humanos. É possível que ferramentas de verificação formal integradas com IA eliminem o problema de confiança. É possível que a Godot mude de ideia.

Mas hoje, em julho de 2026, com o estado atual das ferramentas e do ecossistema, a decisão parece acertada. O open source funciona porque humanos se importam o suficiente para doar seu tempo. Quando essa relação se quebra — quando o feedback vai para uma máquina e o código vem de uma máquina — o modelo colapsa.

A verdadeira pergunta não é “devemos usar IA no open source?” É: “quem assume a responsabilidade quando o código quebra às 3 da manhã?”

Se sua resposta for “o modelo que gerou”, o open source não é pra você. Pelo menos não a Godot.

Fonte de inspiração: Changes to our Contribution Policies – Godot Engine