- Usar LLM para lidar com tickets do Django não ajuda, e é mais útil doar esses recursos diretamente para a Django Software Foundation
- O Django é um projeto com padrões de qualidade muito altos e foco em estabilidade de longo prazo, exigindo compreensão profunda além da simples geração de código
- Se um LLM criar o código no lugar do autor e também cuidar da descrição do PR e das respostas ao review, surge o problema de ficar difícil avaliar se o colaborador realmente entende o que está fazendo
- A contribuição em open source tem como núcleo a comunicação humana e a colaboração comunitária, e quando um LLM encobre isso, a confiança com os revisores enfraquece
- Para contribuir com o Django, é indispensável acumular entendimento por meio de aprendizado e experimentação diretos, e isso leva ao crescimento como desenvolvedor
Limites da contribuição ao Django via LLM
- Resolver tickets do Django com ajuda de LLM não traz ajuda prática para a comunidade
- Quando um PR é enviado com código gerado por LLM e o feedback também é tratado por ele, fica difícil entender o nível de conhecimento real do autor
- Do ponto de vista do revisor, passa a parecer que ele está conversando não com uma pessoa, mas com uma “casca de falsa compreensão”
- O Django tem uma grande base de usuários, um ciclo lento de mudanças e exigências de qualidade próprias de um projeto que deve durar mais de 20 anos
- Por essas características, mais do que geração automatizada de código, o que importa é compreensão profunda e contribuição responsável
A forma correta de usar LLM
- O LLM deve ser usado como ferramenta auxiliar para apoiar a compreensão
- O ideal é primeiro escrever a explicação com suas próprias palavras e depois usar o LLM para refinar a forma de expressão
- Se houver dificuldade de comunicação, use LLM ativamente, mas deixe claro que ele foi utilizado
- Ao contribuir com o Django, o colaborador precisa entender diretamente o problema, a solução e o feedback do review
- Código gerado sem entendimento pode prejudicar a qualidade do projeto como um todo
Colaboração open source centrada em pessoas
- Contribuir com o Django é uma experiência comunitária, que inclui transparência humana e vulnerabilidade
- Quando um LLM encobre essa dimensão humana, colaborar fica mais difícil
- Os revisores se sentem motivados quando a comunicação acontece com base na “compreensão real de uma pessoa”
- O LLM deve ser usado apenas como meio de apoio e não deve substituir o papel essencial do colaborador
A essência e o valor de contribuir com o Django
- O Django é um projeto com 20 anos de história e uma visão de longo prazo, por isso todo código adicionado precisa ser profundamente compreendido
- Para alcançar esse entendimento, tempo, experimentação e aprendizado são indispensáveis
- Contribuir com o Django é uma experiência que traz crescimento como desenvolvedor, mais do que apenas ter o nome registrado
- O aprendizado obtido no processo de contribuição vale muito mais do que ver seu nome em uma lista
Uma proposta para a comunidade
- Não use LLM em excesso para esconder a si mesmo e o seu entendimento
- A comunidade Django quer colaborar com pessoas de verdade
- Se você quer apoiar o Django, o mais eficaz é investir tempo e dinheiro ou doar para a Django Software Foundation
1 comentários
Comentários do Hacker News
Acho que LLMs podem causar problemas em qualquer base de código que tenha revisores humanos
Usar LLM sem entender o ticket, a solução ou o feedback do PR prejudica o projeto inteiro
Contribuir para open source é um ato comunitário, mas o LLM encobre a transparência e vulnerabilidade humanas
Do ponto de vista do revisor, parece que você está conversando com a ‘máscara’ de um humano, uma experiência desmotivadora
Por isso, LLM deve ser usado como ferramenta de apoio, não como substituto
Hoje em dia, até nas equipes vejo um aumento enorme de PRs escritos por IA, e Claude ou Codex até respondendo ao feedback de revisão
Se essa cultura se firmar, acho que isso vai levar a um colapso da confiança e à queda de moral em toda a indústria
Em vez de aumentar a produtividade, só fica uma “sensação” de que tudo ficou mais rápido
Na prática, como as organizações não medem produtividade direito, ninguém sabe qual é o efeito líquido dessas funções
O uso generalizado de IA está erodindo a confiança
A aparência melhora, mas a autenticidade desaparece
No fim, o código entra, então também fico curioso se talvez as pessoas não se incomodem tanto assim
Os melhores colegas com quem já trabalhei sempre facilitavam a vida do revisor para criticar
Eles deixavam claras as suposições, o que não sabiam e os erros e tentativas, e explicavam de um jeito fácil de contestar
Se um PR mostra essa humildade e autorreflexão, não me preocupo mesmo que um LLM tenha participado
O problema é que pessoas que antes já subiam código que nem compilava agora usam LLM para produzir ainda mais PRs ruins
Por isso, não concordo com a ideia de que “se o código roda, tanto faz quem escreveu”
A situação atual está fora de controle
Especialmente porque atividade no GitHub virou critério em processos seletivos, as pessoas tentam manipular o histórico de contribuições com LLM
Na prática, se o PR passa sem que a pessoa entenda o projeto, acabou
Não há problema em bons desenvolvedores usarem LLM
O problema é que pessoas que já tinham pouca habilidade agora conseguem enviar ainda mais código de baixa qualidade graças ao LLM
Antes já existia gente copiando e colando do StackOverflow sem entender e enviando código assim mesmo
A IA só amplificou isso
Se alguém sai espalhando PRs parecidos em vários repositórios e a maioria é rejeitada, isso é um sinal claro
No fim, precisamos voltar a uma cultura de contribuição focada em qualidade, não em volume
É fácil reconhecer o problema, mas difícil criar consenso e soluções práticas, e engenheiros costumam ser fracos nessa parte
Gosto da ideia de doar dinheiro
Acho que os principais contribuidores do Django conseguiriam usar melhor recursos financeiros do que tokens
Outros projetos adotaram medidas como divulgação do uso de IA, pausa temporária em contribuições externas, ou limitação no registro de issues
Os PRs de baixa qualidade estão sendo gerados com tanta facilidade que o tempo e o foco da comunidade estão sendo prejudicados
Por isso, talvez seja necessário migrar para modelos de colaboração mais fechados
Também achei marcante a decisão do Debian de lidar com esse problema com cautela
Em vez de comprar tokens, acho melhor simplesmente doar dinheiro aos contribuidores centrais e deixá-los decidir como usar
Concordo muito com a frase “é mentalmente exaustivo para o revisor conversar com a máscara de um humano”
Uma das recompensas do open source é justamente o contato humano, e quando isso some, tudo parece só trabalho braçal
No fim, a paciência de todos diminui e a alegria da colaboração desaparece
Como numa conversa com o açougueiro de confiança, elas querem criar vínculo
Escrever artigos ficou mais fácil com LLM, mas verificação e revisão continuam difíceis e demoradas
Por isso, pode ser necessário declarar o uso de IA ou marcar PRs com algoritmos de detecção de IA
No fim, isso teria o efeito de fazer as pessoas traduzirem para sua própria linguagem as respostas do LLM
Mas, na prática, sempre existem pessoas que ignoram as regras
Hoje toda inovação parece operar na direção de buscar apenas recompensas de curto prazo
A estrutura de incentivos não apoia quem tem visão de longo prazo
Basta olhar um pouco para teoria dos jogos para ser difícil negar que o mundo foi desenhado assim
Então ela tem limitações para avaliar estratégias de longo prazo
A mensagem é boa, mas quem faz tudo com LLM provavelmente nem vai ler um texto desses
Como mantenedor de open source, eu também tenho dificuldade para distinguir código escrito por IA
Na prática, quase não existem desenvolvedores profissionais assim
Já pensei que talvez fosse melhor criar um projeto open source dedicado a LLM
Algo como reunir apenas código gerado por LLM e definir um protocolo claro de contribuição
Ainda assim, é bem possível que muitas contribuições com LLM sejam só para montar portfólio
Tem milhares de contribuidores e dezenas de milhares de commits
Muitas vezes a IA não aumenta a produtividade, só transfere para outras pessoas o custo da verificação
No fim, os mantenedores ficam com mais trabalho, e o contribuidor acaba ficando com o crédito
Eu também já usei LLM para criar patches em projetos como o Django
Sem LLM, provavelmente eu nem teria tentado
Mas revisei o resultado com minhas próprias mãos e também escrevi testes
Hoje em dia, LLM acaba fazendo tudo: o código, a descrição do PR e até as respostas à revisão
Do ponto de vista do revisor, dá até a sensação de “então eu mesmo não deveria revisar isso com um LLM?”
Por isso, LLM deve ser usado como ferramenta de apoio, não como substituto