- Usar LLM para resolver tickets de Django no resulta útil; es más beneficioso destinar esos recursos directamente a donar a la Django Software Foundation
- Django es un proyecto con estándares de calidad muy altos y un fuerte enfoque en la estabilidad a largo plazo, por lo que requiere una comprensión profunda que va más allá de la simple generación de código
- Si un LLM genera el código en lugar del autor y además se encarga de la descripción del PR y de responder a la revisión, surge el problema de que se vuelve difícil juzgar si la persona realmente entiende lo que hizo
- La contribución al código abierto tiene como eje la comunicación humana y la colaboración comunitaria, y si un LLM oculta eso, la confianza con quienes revisan se debilita
- Para contribuir a Django, es indispensable construir comprensión mediante aprendizaje y experimentación directa, y eso también impulsa el crecimiento como desarrollador
Límites de contribuir a Django mediante LLM
- Resolver tickets de Django con ayuda de LLM no aporta una ayuda real a la comunidad
- Si se envía un PR con código generado por un LLM y además se procesa el feedback con esa misma herramienta, resulta difícil saber cuál es el nivel de comprensión del autor
- Desde la perspectiva de quien revisa, se siente como conversar no con una persona sino con una “fachada de comprensión falsa”
- Django tiene una gran base de usuarios, un ciclo de cambios lento y además exigencias de calidad propias de un proyecto que seguirá existiendo por más de 20 años
- Por estas características, más que la generación automática de código, lo importante es una comprensión profunda y una contribución responsable
La forma correcta de usar los LLM
- Los LLM deben usarse como herramientas de apoyo para facilitar la comprensión
- Lo deseable es redactar primero la explicación con tus propias palabras y luego usar el LLM para pulir la expresión
- Si comunicarse resulta difícil, se puede usar activamente un LLM, pero debe indicarse explícitamente que se utilizó
- Al contribuir a Django, es necesario que la persona contribuya entendiendo directamente el problema, la solución y el feedback de la revisión
- El código generado sin comprensión puede perjudicar la calidad del proyecto en su conjunto
Colaboración de código abierto centrada en las personas
- Contribuir a Django es una experiencia comunitaria, e incluye transparencia humana y vulnerabilidad
- Si un LLM oculta esa dimensión humana, la colaboración se vuelve más difícil
- Quienes revisan encuentran motivación cuando pueden comunicarse a partir de “la comprensión real de una persona”
- Los LLM deben usarse solo como medio auxiliar y no deben reemplazar el papel esencial de quien contribuye
La esencia y el valor de contribuir a Django
- Django es un proyecto con 20 años de historia y una visión de largo plazo, por lo que todo código que se añade debe comprenderse a fondo
- Para lograr esa comprensión, hacen falta tiempo, experimentación y aprendizaje
- Contribuir a Django no es solo lograr que tu nombre aparezca registrado, sino una experiencia que trae crecimiento como desarrollador
- El aprendizaje obtenido durante el proceso de contribución vale mucho más que aparecer en una lista
Una propuesta para la comunidad
- No se debe usar LLM en exceso para ocultarse a uno mismo y ocultar la propia comprensión
- La comunidad de Django quiere colaborar con personas reales
- Si quieres apoyar a Django, lo más efectivo es invertir tiempo y dinero o donar a la Django Software Foundation
1 comentarios
Comentarios en Hacker News
Creo que los LLM pueden causar problemas en cualquier base de código donde haya revisores humanos
Si usas un LLM sin entender el ticket, la solución o el feedback del PR, terminas perjudicando a todo el proyecto
Contribuir a código abierto es un acto comunitario, y los LLM ocultan la transparencia y vulnerabilidad humanas
Desde la perspectiva del revisor, se siente como conversar con una “máscara” humana, y eso resulta en una experiencia desmotivadora
Por eso, los LLM deberían usarse como herramienta de apoyo, no como sustituto
Últimamente incluso en los equipos han aumentado mucho los PR escritos por IA, y se ve a Claude o Codex respondiendo también al feedback de revisión
Si esta cultura se afianza, parece que podría llevar a un colapso de la confianza y a una caída de la moral en toda la industria
Más que aumentar la productividad, solo deja una “sensación” de que todo va más rápido
Como en la práctica las organizaciones no miden bien la productividad, nadie sabe cuál es el efecto neto de estas funciones
El uso generalizado de la IA está erosionando la confianza
Por fuera todo se ve mejor, pero la autenticidad desaparece
Al final el código sí pasa, así que también me pregunto si de verdad a la gente le molesta tanto
Los mejores colegas con los que he trabajado siempre hacían que al revisor le resultara fácil criticar
Dejaban claras sus suposiciones, lo que no sabían y sus intentos fallidos, y explicaban todo de forma que el revisor pudiera rebatirlo con facilidad
Si un PR muestra esa humildad y autorreflexión, no me preocupa tanto aunque haya intervenido un LLM
El problema es que la gente que antes ya subía código que ni siquiera compilaba ahora usa LLM para producir aún más PR pésimos
Por eso no estoy de acuerdo con la idea de que “si el código funciona, da igual quién lo escribió”
La situación actual está fuera de control
Sobre todo porque la actividad en GitHub se volvió un criterio de evaluación en los procesos de contratación, y la gente intenta manipular su historial de contribuciones con LLM
En la práctica, si un PR pasa sin que la persona entienda el proyecto, ya está
Que un buen desarrollador use LLM no es el problema
El problema es que personas que ya tenían pocas habilidades ahora, gracias al LLM, envían más código de baja calidad
Antes también había quienes copiaban y pegaban de StackOverflow sin entender el código que enviaban
La IA solo amplificó eso
Si alguien deja PR parecidos en muchos repositorios y la mayoría se los rechazan, esa es una señal clarísima
Al final hay que volver a una cultura de contribución centrada en la calidad y no en la cantidad
Reconocer el problema es fácil, pero crear consenso y soluciones reales es difícil, y los técnicos suelen flojear en esa parte
Me gusta la idea de donar dinero
Parece que los contribuidores principales de Django podrían aprovechar mejor el financiamiento que los tokens
Otros proyectos han tomado medidas como declarar el uso de IA, suspender temporalmente las contribuciones externas o restringir el registro de issues
Los PR de baja calidad se generan con demasiada facilidad y están consumiendo el tiempo y la concentración de la comunidad
Por eso tal vez haga falta moverse hacia un modelo de colaboración más cerrado
También me impresionó la decisión de Debian de abordar este problema con cautela
En vez de comprar tokens, creo que sería mejor simplemente donar dinero a los contribuidores principales y dejar que ellos decidan cómo usarlo
Me identifiqué mucho con la frase “es mentalmente agotador que el revisor converse con una máscara humana”
Una de las recompensas del open source es la interacción con otras personas, y si eso desaparece, todo empieza a sentirse como simple trabajo
Al final se reduce la paciencia de todos y desaparece la alegría de colaborar
Igual que en una carnicería de confianza, quiere construir una relación
Escribir papers se volvió más fácil con LLM, pero la verificación y la revisión siguen siendo difíciles y consumen tiempo
Por eso haría falta indicar si se usó IA, o marcar los PR con algoritmos de detección de IA
Al final eso tendría el efecto de obligar a la gente a traducir las respuestas del LLM a su propio lenguaje
Aunque, siendo realistas, siempre existirán personas que ignoran las reglas
Hoy toda innovación parece orientada a perseguir recompensas de corto plazo
La estructura de incentivos no apoya a quienes tienen una visión de largo plazo
Si miras un poco de teoría de juegos, cuesta negar que el mundo está diseñado así
Por eso tiene límites para evaluar estrategias de largo plazo
Es un buen mensaje, pero quienes hacen todo con LLM probablemente ni lean este tipo de textos
Como mantenedor de open source, a mí también me resulta difícil distinguir si el código fue escrito por IA
En realidad casi no hay desarrolladores profesionales así
A veces pienso que sería mejor crear un proyecto open source exclusivo para LLM
Algo que reúna solo código creado por LLM y defina con claridad el protocolo de contribución
Aun así, es muy probable que muchas de esas contribuciones con LLM sean solo para el portafolio
Tiene miles de contribuidores y decenas de miles de commits
La IA muchas veces no aumenta la productividad, sino que solo le transfiere a otros la carga de verificar
Al final los mantenedores terminan con más trabajo y el contribuidor se queda solo con el mérito
Yo también he usado LLM para crear parches en proyectos como Django
Sin LLM ni siquiera lo habría intentado
Pero revisé personalmente el resultado y también escribí tests
Últimamente el LLM reemplaza todo: el código, la descripción del PR e incluso las respuestas a la revisión
Desde la perspectiva del revisor, ya casi da para pensar: “¿entonces mejor lo reviso yo mismo con otro LLM?”
Por eso el LLM debe usarse como herramienta de apoyo, no como sustituto