# RADV pone reglas a la IA y Mesa ya no acepta cualquier parche

> El driver Vulkan de AMD en Mesa exige declarar el uso de IA en los parches. La medida llega tras un mes de contribuciones masivas al software libre.
> Por José Maldonado · Tecnología · 2026-11-03

RADV, el driver Vulkan de AMD dentro de Mesa, ha adoptado una [política propia](https://www.phoronix.com/news/RADV-Adopts-LLM-Policy) sobre el uso de modelos de lenguaje en las contribuciones que recibe. El anuncio llega el 2 de noviembre y convierte al driver en uno de los primeros proyectos de grafismo en fijar reglas explícitas para un fenómeno que hasta ahora se gestionaba caso por caso. No es una prohibición, es un marco sobre qué hay que declarar y qué se espera de quien firma un parche.

La decisión se entiende mejor mirando el mes que ha dejado atrás el software libre. La [ventana de fusión de Linux 7.4](https://observatorioblockchain.com/tecnologia/linux-7-4-rc1-ventana-merge-mas-grande/) cerró con [18.591 cambios](https://lwn.net/Articles/1102739/) sin fusión, casi tantos como todo el ciclo anterior, y el propio Linus Torvalds lo describió como un récord con una parte del mérito atribuida a la IA. [OverlayFS](https://www.phoronix.com/news/OverlayFS-Many-Fixes) recibió una tanda inusual de correcciones detectadas por revisión automática, y FreeRDP habló de un aluvión de actividad por la misma razón.

El problema que aparece cuando el volumen se multiplica no es la calidad del código generado, es el tiempo de revisión. Un maintainer que recibe cien parches por semana y dedica veinte minutos a cada uno tiene un límite que no se resuelve con entusiasmo. Las políticas de IA son, en la práctica, un mecanismo para decidir a quién se le concede ese tiempo escaso.

## ¿Qué cambia para quien manda un parche?

La política de RADV se apoya en una idea sencilla. Quien envía un cambio responde de él, lo haya escrito a mano o con ayuda de un modelo. Eso implica declarar el uso de herramientas cuando sea relevante, entender cada línea que se envía y no delegar en el modelo la responsabilidad de saber por qué el cambio funciona.

Ese principio parece obvio y no lo es. Buena parte del flujo actual consiste en generar un parche, lanzarlo a la lista de correo y esperar a que alguien lo revise. Cuando el parche viene de un modelo entrenado con el propio repositorio, la tentación de enviar sin entender es alta, porque el texto suena plausible y compila.

La política también toca la trazabilidad. Si una contribución se apoya en material generado, el revisor necesita saberlo para calibrar cuánto esfuerzo dedicar a comprobar supuestos. No es lo mismo revisar un cambio que alguien ha probado en su tarjeta gráfica que uno que sale de una predicción estadística sin ejecución real.

## El mes en que la IA desbordó los repositorios

Octubre dejó señales en todas las capas. El kernel vivió su mayor ventana de fusión, con un árbol que roza los 42 millones de líneas, y las discusiones sobre IA dejaron de ser teóricas para convertirse en algo que aparece en el correo diario. El driver RADV no es una excepción dentro de Mesa, es el primero en ponerlo por escrito.

El caso de FreeRDP es el ejemplo más claro de lo que puede pasar cuando la barrera de entrada baja. El proyecto pasó de un goteo de contribuciones a un volumen que obligó a reorganizar el trabajo de revisión, y su versión 3.33 se publicó con soporte de WebAssembly y un conjunto amplio de correcciones. Más manos y más código, sí. Y también más ruido.

Ese ruido tiene una víctima concreta. Los proyectos pequeños no tienen un equipo pagado que absorba la carga, y sus responsables son personas que revisan de noche después de su trabajo. Cuando el volumen se multiplica sin que aumente el número de revisores, la calidad de la revisión baja y con ella la del proyecto.

## El problema no es el código, es la revisión

Hay una confusión habitual en este debate. Se discute si la IA escribe buen código, cuando la pregunta relevante es si los revisores humanos pueden verificar lo que reciben. Un parche correcto, pero incomprensible para quien lo integra es una deuda que se paga más tarde, en un fallo que nadie sabe explicar.

En un driver gráfico eso tiene consecuencias visibles. Un cambio sutil en el manejo de memoria puede provocar corrupción de pantalla, bloqueos o fallos que solo aparecen en una combinación concreta de GPU y juego. La revisión en esta área siempre ha sido dura, y añadir volumen sin contexto la hace peor.

Las políticas que están surgiendo comparten un enfoque pragmático. No prohíben la herramienta, exigen que el resultado sea comprensible y verificable por un humano. Es la misma lógica que se aplica desde hace años a los parches enviados por empresas: el sello de una organización no sustituye la revisión, solo indica quién responde si algo se rompe.

## La política como filtro de confianza

Lo interesante de la decisión de RADV es que crea un criterio de admisión antes de que exista un problema grave. Los proyectos suelen reaccionar después de un incidente, cuando ya hay que reconstruir confianza a prisa. Aquí se anticipa una situación que ya está ocurriendo en el kernel y en otras bases de código.

También obliga a mirar el lado menos discutido. Si una empresa usa un modelo para generar contribuciones a un proyecto libre, está usando infraestructura ajena para validar su producto. Eso no es malo en sí, pero cambia la relación entre quien mantiene y quien consume. Las reglas de divulgación hacen visible esa relación.

Queda por ver cuánto se puede verificar de verdad. Un revisor no puede saber si un parche salió de un modelo o de una tarde de trabajo, y las declaraciones honestas dependen de la buena fe de quien envía. Lo que sí puede hacer un proyecto es exigir que el código sea defendible y castigar con la expulsión las contribuciones que no lo sean.

Mesa no improvisa. El kernel lleva meses discutiendo cómo declarar el uso de modelos en los parches, y varios proyectos han publicado guías internas antes que políticas formales. La diferencia es que RADV lo pone por escrito en un repositorio que cualquiera puede leer.

Ese gesto tiene un efecto secundario útil. Convierte una discusión difusa en un criterio que se puede citar, y da a los revisores una razón objetiva para rechazar un cambio que no se sostiene. En proyectos con pocos mantenedores, tener una regla escrita ahorra discusiones y tiempo.

## El sitio lógico para empezar

Mesa ocupa una posición peculiar. Es infraestructura crítica para cualquiera que use Linux con gráficos, la mantienen empresas con intereses comerciales y recibe contribuciones de aficionados con hardware muy distinto. Esa mezcla la convierte en un laboratorio perfecto para medir los efectos de la IA en el desarrollo abierto.

Si la política funciona en RADV, otros drivers y proyectos del ecosistema la copiarán con ajustes. Si fracasa, el argumento será que el problema no era la IA, era la falta de revisores, y la discusión se trasladará a quién paga ese trabajo. En ambos casos, lo que se decida aquí tendrá más peso del que sugiere un anuncio sobre un driver de AMD.

La pregunta que queda abierta no es si se puede usar IA para escribir parches, porque ya se está haciendo. Es si el software libre quiere seguir siendo un espacio donde el código se explica entre personas, con un nombre detrás de cada línea, o convertirse en un flujo donde nadie sabe por qué algo funciona hasta que deja de hacerlo.