OK, esto es grande. La documentación oficial del kernel de Linux ha recibido un archivo completamente nuevo: coding-assistants.rst. No es una recomendación para usar IA — es un mensaje claro sobre lo que no es aceptable al contribuir al proyecto de código abierto más importante del mundo.
Un hilo en Hacker News que está explotando en este momento muestra que la gente en el núcleo del underground de la IA y el código abierto está genuinamente sorprendida. No porque existan las reglas, sino porque realmente han sido escritas e incluidas en el propio repositorio del kernel. Es una señal.
¿Qué dicen realmente? En resumen: los colaboradores que usan herramientas de IA para generar código que se incluirá en el kernel de Linux tienen la responsabilidad personal de verificar todo — línea por línea. Nada de «la IA lo dijo, así que está bien». Mantenedores como Greg Kroah-Hartman se han quejado durante mucho tiempo de un aumento en parches de baja calidad que huelen a IA, y ahora la paciencia claramente se ha agotado.
¿Por qué esto importa más allá de Linux? Porque el kernel de Linux es el punto de referencia de cómo se gestionan los proyectos serios de código abierto. Cuando introducen reglas formales, otros seguirán su ejemplo — Python, Apache, GNOME, todos los grandes. La investigación respalda la preocupación: un estudio de Veracode encontró fallos de seguridad en el 45 % de las tareas de codificación generadas por IA, y Black Duck informó en 2026 que dos tercios de las bases de código comerciales tenían conflictos de licencia, en parte gracias a lo que se llama «lavado de licencias» a través de herramientas de IA.
Esto no es histeria anti-IA. El propio Kroah-Hartman ha admitido que las herramientas han mejorado mucho. Pero es un mensaje claro de que el «vibe coding» y el pegado de IA sin reflexión no tienen cabida en el código que se ejecuta en miles de millones de dispositivos.
En el hilo de HN, es interesante que muchos desarrolladores experimentados del kernel realmente apoyen la medida — no para detener la IA, sino para detener la ola de parches a medio terminar que agotan la energía de los mantenedores. Seth Larson de la Python Software Foundation ha descrito el mismo problema: una explosión de informes de seguridad alucinados por LLM que nadie se molesta en leer.
¿Qué sigue? Esté atento a si otros grandes proyectos copian este archivo RST o crean sus propias variantes. Ahí es donde vendrá la próxima señal.
NB: Esta es una señal temprana basada en la actividad de la comunidad en Hacker News y la documentación del kernel disponible públicamente — no es un artículo de noticias confirmado de fuentes oficiales.