O Mesa atualizou suas diretrizes de contribuição — e, com isso, abriu uma conversa que vai muito além de formatação de commits e prefixos de MR. A novidade mais visível é uma regra cristalina sobre o papel de ferramentas de IA: independentemente do editor, assistente ou gerador que você use, você é o responsável pelo código. A página “Submitting Patches” agora explicita que o(a) autor(a) deve entender o que está mudando, justificar a alteração e garantir compatibilidade com a MIT license do projeto. Ferramentas ajudam; entendimento não é terceirizável.
Essa mudança vem na esteira de um MR de documentação (“docs: Add more details about the contribution process”, por Timur Kristóf), parte de uma leva recente de ajustes que reforçam expectativas e boas práticas na colaboração via GitLab. Em outras palavras: padronizar o básico para liberar energia coletiva para o que importa — arquitetura, drivers, regressões —, enquanto pinta um contorno claro para o uso de AI no fluxo do projeto.
“Você é o responsável”: a nova regra do Mesa para IA
O coração da atualização é simples e direto: o(a) contribuidor(a) responde pela mudança, venha ela de si, de um assistente de codificação ou de outra fonte. Isso inclui assegurar que o patch pode ser submetido sob a licença do Mesa e que a commit message explique o porquê do change. O texto também lembra que nenhuma ferramenta substitui “entendimento real” do código — e que usar IA não dá privilégios extras nem reduz expectativas na revisão. É a forma Mesa de dizer: “copilot não assina Reviewed-by”.
Na prática, isso coloca a responsabilidade e a ética profissional no centro. Quer tentar um autocompletar mais esperto? Use. Vai experimentar um gerador que rascunha uma função? Ok — desde que você entenda cada linha, assuma eventuais bugs e arque com o ônus de explicar decisões e implicações. É como usar um osciloscópio novo no laboratório: ótimo, desde que você saiba ler o traço.
O debate na comunidade: proibir ou não proibir?
A atualização “não polêmica” abriu uma discussão polêmica: deveria o Mesa banir contribuições geradas por IA? Desenvolvedores de peso — gente que assina drivers e toma decisões difíceis no dia a dia — verbalizaram posições diversas. Houve quem defendesse banimento total por prudência; houve quem preferisse focar na responsabilidade individual (e num eventual parecer jurídico sobre treinamento e licenças); houve ainda quem pedisse nuance: não é o mesmo caso completar o nome de um struct e despejar um arquivo inteiro “feito pela IA”.
Esse ponto da nuance, trazido pelo autor do MR, é crucial: o ecossistema já embutiu “IA” em editores e IDEs de forma quase invisível. Tratar autocompletar como se fosse o mesmo que geração integral de código seria desproporcional. O que a diretriz aprovada faz, portanto, é estabilizar o mínimo: responsabilidade humana, entendimento do patch e licenciamento correto — enquanto a discussão maior (banir, restringir, exigir disclosure?) segue para um possível MR específico, com escopo claro para consenso entre desenvolvedores.
Paralelos no ecossistema: Gentoo e curl mostram dois caminhos
Esse debate não acontece no vácuo. Em 2024, o Gentoo cravou uma política explícita: banimento de conteúdo gerado com ferramentas de NLP/LLM nos repositórios oficiais — com três pilares de justificativa que também ecoaram no Mesa: copyright (zona cinzenta regulatória e risco de contaminação de licenças), qualidade (texto “plausível, mas sem sentido”) e ética (desde uso de energia/água até o incentivo a spam/scam). É uma escolha consciente por reduzir risco jurídico e custo de revisão.
Já o projeto curl adotou um caminho mais restritivo-com-disclosure. Em 2025, eles formalizaram diretrizes de uso de IA no arquivo de contribuição e, especificamente para relatos de segurança, passaram a exigir declaração explícita de uso de IA, com a recomendação clara: verifique tudo antes de submeter. A filosofia é pragmática: o problema não é a ferramenta em si, mas o custo imposto quando relatórios ou patches “alucinam” e drenam horas de triagem.
Colocando lado a lado, temos duas estratégias que podem inspirar a tal “Mesa AI policy”: (1) proibir e ganhar previsibilidade (ao preço de bloquear casos legítimos); (2) permitir com responsabilidade, pedindo disclosure e cravando que a revisão julga o que está no diff, não a aura tecnológica de quem o produziu. Não existe bala de prata: cada comunidade calibra conforme seu risco, cultura e banda de revisão.
E agora, qual é o norte para quem contribui?
Para quem envia patches hoje, o recado é claro e acionável:
- Entenda seu código e explique por que ele melhora o projeto.
- Garanta a compatibilidade de licença (o Mesa usa MIT) e evite qualquer fonte “contaminada”.
- Use IA como ferramenta, não como muleta — e esteja pronto(a) para defender cada linha na revisão.
No horizonte, a comunidade ainda deve decidir se e como formalizará restrições adicionais (banimento, disclosure obrigatório, escopos específicos). Mas, enquanto a conversa amadurece, a diretriz já landed cumpre bem seu papel: protege o ethos de código aberto do Mesa sem demonizar ferramentas — e lembra que, no fim do dia, quem assina o patch é gente.
