La propuesta de AGENTS.md para el kernel de Linux pone a prueba si los agentes de IA pueden seguir reglas humanas
La propuesta de AGENTS.md para el kernel de Linux añade un solo enlace simbólico, pero apunta a un conflicto creciente en torno al código asistido por IA. Presentado el 24 de septiembre de 2026, el parche facilitaría que los agentes de programación encuentren automáticamente las instrucciones existentes del kernel.
El archivo propuesto no autorizaría contribuciones autónomas ni relajaría los estándares de revisión del kernel. Dirigiría a los agentes a un README que ya orienta a las herramientas de IA hacia la política detallada de contribución del proyecto. El cambio aborda un problema más acotado: los agentes a menudo actúan antes de leer documentación escrita principalmente para personas.
Esa distinción importa porque el kernel ya indica a las herramientas de IA que no deben certificar parches en nombre de una persona. También exige revisión humana, atribución adecuada, pruebas y responsabilidad. Por tanto, la propuesta de AGENTS.md para el kernel de Linux enfrenta unas instrucciones fáciles de descubrir con una realidad más difícil: un archivo del repositorio puede guiar a un agente, pero no puede hacer fiable un parche poco fiable.
La propuesta de AGENTS.md para el kernel de Linux cambia un único punto de entrada
El parche cambia cómo los agentes descubren las reglas existentes, no las reglas en sí.
El mantenedor del kernel Sasha Levin presentó un parche titulado “docs: add AGENTS.md as a symlink to README.” La propuesta crea un enlace simbólico de nivel superior llamado AGENTS.md, que apunta al archivo README existente en el repositorio.
Un enlace simbólico es una referencia del sistema de archivos que redirige un nombre de archivo a otro. En este caso, un agente que abriera AGENTS.md recibiría el mismo material ya disponible mediante README, en lugar de una segunda copia de las instrucciones.
Ese diseño evita crear dos documentos de política que los mantenedores tendrían que sincronizar. La propuesta de enlace simbólico de Levin dice que el README existente ya dirige las herramientas de IA a Documentation/process/coding-assistants.rst. El problema es que un agente debe decidir abrir el README antes de que esa referencia le resulte útil.
Muchos agentes de programación inspeccionan automáticamente archivos de instrucciones con nombres específicos. AGENTS.md se ha convertido en uno de los nombres de archivo habituales para directrices a nivel de repositorio, incluidos comandos de compilación, requisitos de pruebas, convenciones de código y límites de seguridad.
El archivo propuesto para el kernel no contendría texto independiente. Su único contenido sería el destino del enlace, README. Así se mantienen las rutas de entrada humana y de máquina vinculadas a una única fuente mantenida.
Levin incluyó un ejemplo controlado para explicar por qué la facilidad de descubrimiento importa. Dos agentes recibieron la misma solicitud: crear un commit que cambiara el nombre de la versión del kernel en el Makefile a “AI Test.”
Sin AGENTS.md, un agente generó una línea Signed-off-by para el usuario. El otro no incluyó atribución a la IA. Ambos resultados entraban en conflicto con las expectativas documentadas del kernel.
Con el enlace simbólico presente, ambos agentes habrían usado una etiqueta Assisted-by: LLM y evitaron añadir una firma humana. También siguieron más de cerca las convenciones del proyecto para los mensajes de commit. Uno añadió un cuerpo descriptivo, mientras que el otro utilizó la estructura esperada de asunto “subsystem: summary phrase”.
Se trató de una prueba limitada de comportamiento, no de una evaluación amplia de la fiabilidad de los agentes. No midió si los agentes podían encontrar errores sutiles, producir correcciones seguras ni comprender restricciones específicas de los subsistemas. Mostró que dos agentes se comportaron de forma diferente tras recibir una ruta descubierta automáticamente hacia las instrucciones existentes.
El cambio seguía en revisión cuando se informó de él. Por ello, describirlo como algo que Linux ya ha adoptado exageraría el hecho. La afirmación precisa es que un mantenedor del kernel propuso el enlace y aportó pruebas que lo respaldan.
Kees Cook, un destacado desarrollador de seguridad del kernel, respondió con una confirmación. Apoyó usar el README en lugar de mantener una política separada solo para agentes. Su respuesta de revisión también señaló que sería deseable que los agentes leyeran la documentación de contribución antes de crear parches.
El parche es lo bastante pequeño como para parecer ceremonial. Sin embargo, su propósito práctico es concreto. Intenta colocar información obligatoria sobre el proceso en la ruta que una herramienta de IA ya está entrenada o configurada para inspeccionar.
Eso convierte la propuesta en un cambio de interfaz. Los humanos pueden explorar árboles de documentación e interpretar normas comunitarias. Los agentes de programación funcionan de manera más predecible cuando los repositorios exponen esas normas mediante nombres de archivo y rutas que las herramientas reconocen.
La cuestión resultante no es si Markdown puede mejorar el código generado. Es si un punto de entrada fiable puede evitar errores recurrentes de proceso antes de que los mantenedores tengan que detectarlos manualmente.
Las reglas existentes del kernel siguen responsabilizando a los humanos
La política de IA del kernel de Linux trata a un agente como asistente, nunca como propietario legal o técnico de una contribución.
Las reglas subyacentes ya van mucho más allá del enlace simbólico propuesto. La guía de contribuciones con IA del kernel orienta a las herramientas de IA y a sus usuarios a través del proceso estándar de desarrollo, el estilo de código, los requisitos para enviar parches, las reglas de licencia y la política sobre contenido generado.
Lo más importante es que la guía indica que los agentes de IA no deben añadir una etiqueta Signed-off-by. Esa línea no es metadato decorativo de un commit. Representa la certificación de una persona conforme al Developer Certificate of Origin, comúnmente llamado DCO.
El DCO es el mecanismo mediante el cual un colaborador declara que el trabajo enviado puede incorporarse legalmente al proyecto bajo su licencia. Un modelo de lenguaje no puede hacer esa certificación por una persona. Tampoco puede determinar si esa persona realizó la revisión necesaria para asumir la responsabilidad.
El remitente humano debe revisar el código generado, confirmar el cumplimiento de licencias, añadir la firma y asumir la responsabilidad de la contribución. Un agente que inserta la firma por sí mismo reduce esos pasos separados a texto generado.
Por eso la prueba de Levin importa pese a su alcance reducido. El agente no se limitó a elegir un estilo de formato impopular. Generó una declaración que solo un humano puede hacer legítimamente.
La documentación del kernel asigna a la participación de IA un marcador diferente. Cuando contribuye una herramienta de IA, el parche debe usar una etiqueta Assisted-by. Las herramientas opcionales de análisis, como Coccinelle, Sparse, Smatch o Clang-Tidy, también pueden aparecer después de la etiqueta LLM.
Este modelo de atribución distingue la asistencia de la autoría y la certificación. Aporta contexto útil a los revisores sin fingir que el modelo puede asumir responsabilidad.
La documentación también establece un proceso exigente para el trabajo sobre errores asistido por IA. Un agente debe leer toda la documentación relevante, localizar un error específico e intentar reproducir cualquier problema no trivial. Debe abandonar un hallazgo que no sobreviva a la verificación.
Si el problema parece real, el agente debe escribir una corrección, compilarla, probarla con el reproductor o mediante un análisis completo y ejecutar las comprobaciones de parches del kernel. Debe indicar todo aquello que no haya podido verificar.
La guía también indica al agente que identifique a los mantenedores y las listas de correo pertinentes. Debe evaluar si el problema pertenece al proceso habitual de errores o al proceso confidencial de seguridad. El agente debe dejar el envío real a la persona que lo utiliza.
Esos requisitos exponen los límites de tratar AGENTS.md como una solución por sí sola. El archivo puede dirigir a un agente hacia la lista de comprobación correcta. No puede confirmar que un reproductor sea significativo, que las pruebas sean suficientes o que el humano comprenda el código.
El desarrollo del kernel también abarca miles de componentes con expectativas especializadas. Las instrucciones generales no pueden contener todas las restricciones arquitectónicas, supuestos de hardware o preferencias de los mantenedores.
Un agente podría cumplir perfectamente las reglas de formato visibles y, aun así, malinterpretar la gestión de ciclos de vida, los bloqueos, el ordenamiento de memoria o el comportamiento de los dispositivos. Un mensaje de commit pulido puede facilitar la revisión de un parche así, pero no hace correcto el razonamiento subyacente.
Eso crea un límite útil. Las instrucciones del repositorio pueden reducir errores administrativos evitables. La confianza técnica todavía debe provenir de pruebas, ensayos, revisión experta y colaboradores responsables.
Para los mantenedores, esa separación es importante. Cada envío mal formado consume atención antes de que alguien llegue a su contenido técnico. Una mejor detección de instrucciones puede reducir esa carga sin rebajar el umbral de aceptación.
Para los colaboradores, la política es igualmente clara. Usar un agente no transfiere la responsabilidad. Un desarrollador debe ser capaz de explicar y defender el resultado como si cada línea se hubiera escrito manualmente.
Por qué los agentes de programación con IA siguen ignorando el README
El conflicto se da entre documentación que existe e instrucciones que aparecen dentro del contexto automático de un agente.
Tradicionalmente, los repositorios organizan la información para colaboradores pensando en las personas. Un README presenta el proyecto, mientras que los archivos de contribución, directorios de documentación, páginas de listas de correo y scripts contienen procedimientos más especializados.
Una persona que llega al árbol de fuentes de Linux puede seguir esa jerarquía. Un agente que recibe una instrucción acotada puede, en cambio, inspeccionar solo los archivos que considera inmediatamente relevantes. Si nunca abre el README raíz, el enlace del README a la política de IA permanece invisible.
Ese comportamiento apareció en un reciente debate del kernel sobre una corrección de I2C de Qualcomm asistida por IA. Un mantenedor observó que el proceso estaba documentado mediante una cadena que empezaba en el README y continuaba en coding-assistants.rst. Sin embargo, las herramientas no seguían esa cadena de manera fiable.
El debate entre mantenedores planteó la ausencia de un archivo AGENTS.md o CLAUDE.md que las herramientas habituales inspeccionan de forma predeterminada. También advirtió que añadir un archivo así no resolvería necesariamente todo.
Esa es la presión que impulsa la nueva propuesta. Los mantenedores del kernel se enfrentan a parches asistidos por IA, independientemente de que el repositorio optimice o no su documentación para agentes. Negarse a añadir un punto de entrada no impide que los colaboradores utilicen esas herramientas.
La elección práctica es más limitada. Los mantenedores pueden dejar que los agentes descubran de forma inconsistente documentación orientada a humanos o colocar una señalización familiar en la raíz del repositorio.
La convención más amplia de AGENTS.md describe el archivo como un README para agentes. Su documentación de formato abierto afirma que más de 60.000 proyectos de código abierto usan la convención, aunque esa cifra refleja ejemplos indexados y no una medición auditada del uso activo de agentes.
El formato no impone un esquema obligatorio. Un proyecto puede enumerar comandos de configuración, reglas de estilo de código, pruebas, preocupaciones de seguridad o enlaces a documentación más detallada. Los archivos anidados pueden proporcionar instrucciones más específicas para subdirectorios.
Esa flexibilidad ayuda a explicar por qué el formato se ha extendido. Un repositorio puede usar un único archivo Markdown sencillo en varias herramientas sin comprometerse con un sistema de configuración propietario.
La propuesta para el kernel emplea una versión inusualmente conservadora de ese patrón. No crearía un gran manual para agentes ni repetiría información que ya se mantiene en otra parte. Expondría el README existente bajo un nombre que los agentes probablemente solicitarán.
Este enfoque también preserva la paridad entre las directrices para humanos y para máquinas. Kees Cook afirmó que el README fue diseñado intencionadamente para funcionar con agentes. Enlazarlo refuerza esa vía compartida en lugar de crear un conjunto privado de reglas que los colaboradores humanos quizá nunca vean.
Una fuente compartida reduce la deriva de políticas. Si los mantenedores actualizan el README o su enlace a la guía de IA, los agentes reciben el cambio a través del enlace simbólico. Un AGENTS.md copiado podría quedar desactualizado sin que nadie lo advierta.
Aun así, el uso de un enlace simbólico introduce una consideración de compatibilidad. Los sistemas similares a Unix gestionan los enlaces simbólicos de repositorios de forma natural, pero algunas configuraciones de Windows los extraen como archivos normales. En ese caso, un agente podría ver la palabra README en lugar del contenido referenciado.
Eso no invalida la propuesta, especialmente para un proyecto desarrollado principalmente mediante flujos de trabajo Linux consolidados. Sí demuestra por qué el parche debe evaluarse como infraestructura y no como metadatos mágicos.
El comportamiento de las herramientas también varía. Algunos agentes cargan AGENTS.md automáticamente, mientras que otros prefieren nombres de archivo específicos de cada herramienta o exigen configuración explícita. Un nombre de archivo que parece universal no garantiza una ingesta universal.
Por tanto, el parche mejora la ruta probable para muchos agentes sin eliminar las diferencias entre herramientas. Su beneficio depende de que el cliente siga el enlace, respete las instrucciones y las preserve durante toda la tarea.
Esas condiciones son más exigentes que simplemente contar con buena documentación. Son menos exigentes que un control técnico aplicable de forma obligatoria.
Mejores instrucciones no hacen que los parches generados sean seguros
AGENTS.md puede mejorar el cumplimiento, pero no puede establecer corrección, procedencia ni una revisión humana auténtica.
El argumento más sólido a favor de la propuesta es operativo. Los agentes ya producen parches relacionados con el kernel, por lo que los mantenedores deberían ofrecerles una ruta predecible hacia las reglas. Evitar firmas incorrectas y atribuciones ausentes ahorra tiempo de revisión.
La crítica más sólida también es operativa. Un parche generado puede seguir todas las instrucciones visibles y seguir siendo incorrecto de formas difíciles de detectar.
Las evaluaciones de seguimiento de instrucciones suelen usar resultados simples y observables. ¿Añadió el agente la etiqueta correcta? ¿Ejecutó un comando indicado? ¿Formateó correctamente un asunto? Esas comprobaciones importan, pero la calidad del kernel depende de propiedades más profundas.
Una corrección puede superar la compilación y aun así introducir una condición de carrera. Un caso de reproducción puede ejercitar una configuración de hardware mientras deja otra sin cubrir. Un agente puede citar la documentación correcta mientras malinterpreta el invariante que esa documentación presupone que los colaboradores ya conocen.
También existe el riesgo de que una presentación más cuidada aumente la confianza mal depositada. Un mensaje de commit bien estructurado, una atribución válida y comprobaciones aprobadas pueden hacer que un parche asistido por IA parezca maduro. Los revisores deben seguir tratando esas señales como cumplimiento del proceso, no como prueba de solidez técnica.
La política actual del kernel anticipa ese problema. Exige que un humano revise el código y asuma la responsabilidad. También pide a los colaboradores que revelen pruebas faltantes o verificaciones fallidas en lugar de ocultar las carencias tras una prosa segura de sí misma.
Que las personas cumplan esos requisitos queda fuera del alcance de AGENTS.md. Un colaborador puede eliminar una etiqueta de atribución, ignorar una prueba fallida o enviar código que no entiende. El archivo no cuenta con un mecanismo independiente para confirmar que la revisión humana tuvo lugar.
Otros proyectos de código abierto han respondido al mismo problema con estrategias diferentes. El repositorio linux-firmware adoptó documentación centrada en agentes a principios de 2026, incluidas reglas de contribución y orientación sobre atribución. Su guía de firmware ofrecía un precedente cercano para una política legible por agentes.
NetworkManager adoptó un enfoque más adversarial tras establecer su política de IA. Según se informó, sus instrucciones indicaban a los agentes no conformes que incluyeran una inusual palabra canario en las comunicaciones de los colaboradores. Así, los mantenedores podían detectar envíos que seguían la instrucción oculta mientras eludían la política del proyecto.
Ese mecanismo canario ilustra el uso opuesto de un archivo de instrucciones. En lugar de ayudar a un agente a producir un parche aceptable, el archivo ayuda a identificar comportamiento automatizado que debería provocar un rechazo.
Ambos enfoques reconocen el mismo hecho: los agentes leen el contexto del repositorio y modifican su salida en consecuencia. Difieren en si ese comportamiento debe orientarse hacia el cumplimiento o utilizarse como señal de detección.
La propuesta del kernel elige la orientación. Parte de la premisa de que los colaboradores que usan agentes aún pueden participar si cumplen las mismas obligaciones legales, técnicas y de revisión que todos los demás.
No es un respaldo al desarrollo no supervisado del kernel. Es un intento de hacer visible el límite existente en el momento en que un agente empieza a trabajar.
La propuesta también evita crear instrucciones que existan solo para máquinas. Dado que AGENTS.md apuntaría al README, mantenedores y colaboradores pueden examinar la misma fuente que recibe el agente.
La transparencia ayuda, pero no aborda la inyección de prompts ni el contenido malicioso en repositorios. Los agentes de programación consumen habitualmente instrucciones de archivos, textos de issues, comentarios, registros y páginas externas. Las directrices conflictivas u hostiles pueden competir con una política de confianza.
Un archivo de nivel superior puede establecer prioridades para herramientas cooperativas. No puede garantizar que todas las herramientas apliquen correctamente esa prioridad, especialmente cuando el agente lee archivos más profundos que contienen lenguaje contradictorio.
Existe un riesgo de mantenimiento relacionado. Cualquier guía de repositorio puede quedar obsoleta a medida que cambian los flujos de trabajo. El enlace simbólico propuesto limita la duplicación, pero los documentos enlazados aún necesitan revisión activa.
La escala del kernel hace que ese mantenimiento sea especialmente importante. Las instrucciones que son ampliamente correctas aún pueden resultar incompletas para un subsistema concreto. Los agentes y los colaboradores deben seguir consultando la documentación local, los mantenedores, los sistemas de compilación y la infraestructura de pruebas.
Por ello, la visión ponderada no es ni “AGENTS.md arregla el código de IA” ni “el archivo no significa nada”. Puede reducir una clase específica de errores predecibles mientras deja intacto el trabajo de verificación más difícil.
Esa afirmación modesta está respaldada por el ejemplo de Levin. Cualquier conclusión más amplia espera evidencia de contribuciones reales en diversos subsistemas y herramientas.
Lo que ocurra después importará más que el enlace simbólico
La propuesta debe juzgarse por los resultados de revisión, el comportamiento de los agentes y la carga de trabajo de los mantenedores tras su adopción.
La primera señal es el destino del parche. Una confirmación respalda el diseño, pero el cambio aún debe avanzar a través del proceso de documentación del kernel y llegar al repositorio principal antes de convertirse en infraestructura estándar del proyecto.
Los revisores podrían aceptar el enlace simbólico sin cambios, solicitar un archivo normal, pedir ajustes de compatibilidad o decidir que la ruta del README es insuficiente. Cada resultado aclararía cómo quiere el kernel exponer las reglas a las herramientas automatizadas.
La segunda señal es si los principales agentes de programación siguen el enlace de forma consistente. La comparación de dos agentes de Levin es útil, pero limitada. Las pruebas más amplias deberían cubrir distintas herramientas, prompts, directorios de trabajo y tipos de contribución.
Una implementación exitosa produciría menos firmas generadas, etiquetas Assisted-by más consistentes, mejores asuntos de commit y una divulgación más clara del trabajo no probado. Son mejoras observables en el proceso.
El fracaso tendría otro aspecto. Los agentes podrían ignorar el enlace simbólico, leer solo parte del material enlazado o seguir reglas genéricas sin cumplir requisitos específicos de cada subsistema. Los archivos de instrucciones específicos de cada herramienta podrían seguir siendo necesarios.
La tercera y más importante señal es la carga de trabajo de los mantenedores. Si el archivo reduce las correcciones repetitivas sin aumentar los envíos de baja calidad, habrá cumplido un propósito práctico.
Si una salida de agentes más pulida anima a más colaboradores a enviar parches que no pueden explicar, el enlace podría mejorar la presentación mientras empeora la carga de revisión. Ese resultado debilitaría la apuesta subyacente de la propuesta.
Los mantenedores también deberían vigilar si los colaboradores usan la atribución con honestidad. La convención Assisted-by solo aporta valor cuando las personas la conservan. El cumplimiento automatizado durante la generación no puede impedir que alguien edite el commit antes de enviarlo.
Los proyectos más allá de Linux estudiarán el resultado. El kernel es una de las bases de código colaborativas más visibles y exigentes, por lo que su tratamiento de las instrucciones para agentes tiene peso simbólico incluso cuando el parche es técnicamente diminuto.
Esa influencia no debe confundirse con una política universal. Los repositorios más pequeños, los equipos comerciales y los proyectos con perfiles de riesgo distintos pueden optar por archivos de instrucciones más completos, configuraciones específicas de herramientas, controles automatizados o prohibiciones de determinadas contribuciones generadas.
El enfoque del kernel destaca porque no construye un proceso de desarrollo paralelo. Dirige a los agentes de vuelta al proceso que ya rige para las personas.
Para los equipos de ingeniería, la lección inmediata es separar la detectabilidad de la autoridad. El contexto legible por agentes puede identificar los comandos y las restricciones correctos. Las pruebas, las revisiones, la propiedad y los sistemas de aprobación deben seguir imponiendo los requisitos del trabajo.
Los equipos que documenten esos límites también pueden mantener el contexto técnico localizable mediante una base de conocimiento de ingeniería. La clave es exponer una fuente mantenida en lugar de copiar reglas en varios archivos de agentes.
Durante los próximos meses, conviene observar el historial de parches, los envíos reales asistidos por IA y las respuestas de los mantenedores. Esas señales mostrarán si la guía AGENTS.md del kernel de Linux elimina ruido evitable o simplemente estandariza la forma en que ese ruido llega.
Los mantenedores de repositorios deberían plantearse una pregunta igual de concreta: ¿qué error repetido de los agentes proviene de la falta de contexto y cuál requiere un control aplicable de forma obligatoria? Coloque la orientación estable donde las herramientas puedan encontrarla y después mida si el comportamiento cambia. Mantenga la revisión humana como responsable de todo lo que un archivo Markdown no puede demostrar.
