KDE está preparando unas directrices para regular el uso de LLM y asistentes de programación basados en IA dentro de sus proyectos, optando por una posición intermedia entre prohibirlos y aceptar automáticamente cualquier contribución generada. Según recoge TechPowerUp a partir del borrador propuesto por el desarrollador Nate Graham, el principio central puede resumirse en una frase: “Don’t be lazy” —“no seas vago”—, trasladando toda la responsabilidad al desarrollador que utilice estas herramientas.
El documento todavía no constituye una política definitiva de KDE y continúa generando discusión dentro de la comunidad. La propuesta permite utilizar IA para producir o ayudar a producir código, pero exige que haya siempre una persona tomando decisiones, revisando el resultado y siendo capaz de comprenderlo y defenderlo. También adopta una postura mucho más restrictiva con el texto generado por LLM para commits, merge requests o conversaciones entre desarrolladores.
KDE quiere mantener siempre a una persona dentro del proceso
El borrador establece el principio de “human in the loop”, según el cual utilizar un LLM no puede reducir la participación humana a escribir un prompt y enviar directamente lo que produzca el modelo. El desarrollador debe tomar decisiones, llevar a cabo ajustes y comprender realmente la contribución antes de presentarla al proyecto.
La diferencia es importante porque KDE no está juzgando únicamente cómo se creó una línea de código, sino quién asume la responsabilidad de mantenerla después. Un cambio aparentemente correcto puede acabar generando bugs, problemas de arquitectura o mantenimiento meses después, cuando el contexto utilizado por el modelo ya no existe y son los mantenedores quienes deben resolver las consecuencias.
El documento utiliza incluso la expresión “meat proxy” para describir lo que quiere evitar: una persona convertida simplemente en intermediaria entre un LLM y el repositorio. KDE no quiere contribuciones que alguien copie, envíe y vaya modificando únicamente a partir de nuevas respuestas generadas sin entender realmente qué está cambiando. La expresión surgió también durante las discusiones previas entre desarrolladores.
Eso afecta directamente al denominado vibe coding. El borrador rechaza enviar cambios que el propio autor no comprenda o no sea capaz de realizar razonablemente por sí mismo, así como presentar prototipos desechables generados por IA esperando que los mantenedores terminen haciendo el trabajo de convertirlos en código válido.
Una contribución de IA debería parecer una contribución humana
Una de las frases más llamativas del borrador sostiene que nadie en KDE debería poder saber que se utilizó un LLM, pero el contexto resulta fundamental. La propuesta no plantea ocultarlo deliberadamente, sino que el resultado debería alcanzar un nivel de calidad indistinguible del trabajo que esa misma persona podría producir sin recurrir a IA.
En otras palabras, utilizar un modelo no serviría como justificación para reducir el estándar de aceptación. Si aparecen patrones evidentes de generación automática, código que el remitente no sabe explicar, explicaciones innecesariamente largas o cambios que trasladan trabajo adicional al mantenedor, la contribución podría quedar ignorada o cerrarse.
Ese criterio intenta resolver uno de los problemas derivados de que generar código sea cada vez más barato: producir una contribución puede requerir segundos, pero revisarla sigue consumiendo tiempo humano. Si un proyecto recibe grandes cantidades de cambios generados rápidamente, el cuello de botella deja de ser escribir código y pasa a ser verificar si ese código merece realmente integrarse.
KDE sería todavía más estricto con textos generados por LLM
La propuesta cambia notablemente de tono cuando abandona el código y entra en mensajes de commit, descripciones de merge requests y conversaciones entre desarrolladores. Para este tipo de contenido, la recomendación general es directamente no utilizar un LLM.
KDE quiere que quien presente un cambio explique personalmente qué ha hecho y por qué, en lugar de pasar el diff por un modelo para generar una descripción aparentemente profesional. La misma regla se aplicaría a responder preguntas durante una revisión: copiar el comentario de otro desarrollador dentro de un chatbot y devolver su respuesta no demostraría que el autor entiende realmente el problema.
Aquí existe también una cuestión de eficiencia. Los LLM pueden producir explicaciones extensas con muy poco esfuerzo para quien las genera, pero leerlas y revisarlas continúa teniendo un coste para otra persona. El borrador intenta evitar que esa asimetría convierta las discusiones técnicas en grandes cantidades de texto cuyo contenido útil podría haberse expresado en unas pocas líneas.
La excepción contemplada es bastante específica: escribir personalmente el texto en la lengua materna y utilizar traducción automática para pasarlo al inglés, siempre que la herramienta no modifique estilo, tono ni contenido. De esta forma, KDE separa la ayuda lingüística de delegar en un modelo la elaboración de la propia explicación.
KDE no quiere etiquetas “Assisted-by” para promocionar al proveedor
El borrador también propone no incluir etiquetas del tipo “Assisted-by: [LLM]” en los commits. Graham argumenta que hacerlo funcionaría fundamentalmente como publicidad gratuita para el proveedor del modelo, y tampoco pretende que declarar el uso de IA se convierta en una excusa anticipada frente a posibles problemas de calidad.
Este punto contrasta directamente con la política actual del kernel de Linux. Su documentación exige que el responsable humano revise el código, cumpla las obligaciones de licencia y añada personalmente su Signed-off-by, pero contempla además identificar la asistencia mediante una etiqueta Assisted-by cuando se emplean herramientas avanzadas de generación.
Ambos enfoques coinciden, sin embargo, en lo fundamental: la IA no puede asumir responsabilidad sobre una contribución. La documentación del kernel deja claro que el remitente debe comprender y poder defender todo lo que envía, mientras los mantenedores conservan la capacidad de rechazar contenido generado automáticamente cuando aumenta el coste de revisión o no alcanza el estándar esperado.
La diferencia está principalmente en la transparencia formal. Linux contempla identificar explícitamente la asistencia de herramientas, mientras el borrador de KDE prefiere juzgar el resultado y responsabilizar únicamente a la persona que lo presenta.
Debug y búsqueda de bugs seguirían permitidos, pero habría que verificar los resultados
KDE tampoco plantea impedir que un LLM se utilice para depurar código, investigar un problema o localizar bugs. Lo que exige el borrador es verificar las conclusiones antes de convertirlas en una contribución o transmitirlas a otros desarrolladores.
Esto resulta especialmente importante porque un modelo puede identificar correctamente un patrón sospechoso y, al mismo tiempo, inventar una causa, una API inexistente o una solución aparentemente convincente pero incorrecta. La utilidad de la herramienta depende entonces de que exista alguien capaz de diferenciar una hipótesis de un diagnóstico comprobado.
El kernel de Linux se enfrenta a un problema parecido. Su documentación advierte de que los informes de bugs encontrados mediante IA pueden sobrecargar a los mantenedores cuando llegan sin reproducciones, comprobaciones o validación suficiente, y exige verificar los problemas antes de presentarlos como reales.
Ahí aparece uno de los puntos comunes que empieza a consolidarse en varios proyectos abiertos: el problema no es necesariamente utilizar IA, sino trasladar el coste de comprobar su trabajo a otras personas.
Las reglas todavía no están cerradas
La propuesta de Nate Graham ha provocado una discusión considerable dentro de KDE. Una de las versiones recientes del trabajo fue cerrada temporalmente el 21 de septiembre después de recibir bastante feedback, mientras continuaba el debate sobre cómo formular las reglas y hasta dónde debía llegar la política.
Esto significa que expresiones como “Don’t be lazy”, la ausencia de etiquetas Assisted-by o determinadas restricciones sobre texto generado todavía pueden cambiar antes de convertirse en documentación oficial. No sería correcto tratarlas por ahora como normas ya aprobadas de KDE.
Lo que sí se perfila con bastante claridad es la filosofía general: KDE no parece dirigirse hacia una prohibición de los LLM, pero tampoco quiere que la facilidad para generar código multiplique el trabajo de quienes lo revisan. El desarrollador seguirá teniendo que comprender, comprobar y mantener todo aquello que presente.
Si esa línea termina consolidándose, KDE adoptará un modelo donde la herramienta utilizada importa menos que la calidad y responsabilidad final de la contribución. La IA puede acelerar partes del proceso, pero no sustituir el conocimiento técnico, la comunicación entre personas ni la obligación de responder por el código enviado.
Vía: TechPowerUp
