La política preliminar de Rust sobre LLM traza la línea correcta

Una pull request de Rust Forge abierta el 17 de abril de 2026 propone una política de uso de LLM para rust-lang/rust. Al 17 de mayo de 2026, la pull request sigue abierta, con 65 comentarios de issues y 284 comentarios de revisión, así que la propuesta todavía no es una política adoptada.¹

El borrador importa desde ahora porque nombra el límite que la mayoría de las guías de programación con IA evita: los LLM pueden ayudar a pensar, aprender, comprobar y experimentar, pero no deberían reemplazar la autoría humana en los lugares donde un proyecto preserva criterio, gusto, responsabilidad y comprensión compartida.²

La propuesta también encaja con las normas actuales de contribución de Rust. La guía vigente de Rust Forge para contribuir ya pide a quienes contribuyen que construyan confianza, respeten el tiempo de quienes revisan, envíen trabajo que entienden por completo, revisen su trabajo en detalle antes de enviarlo y mantengan los comentarios concisos.³ La política de revisión del compilador también dice que quienes revisan necesitan entender lo suficiente el código bajo revisión y que su tiempo de revisión es limitado.⁴ El borrador sobre LLM vuelve concretas esas expectativas previas para el trabajo asistido por IA.

Resumen rápido

El borrador de Rust permite el uso privado de LLM para aprender, resumir, revisar en privado, crear herramientas personales y experimentar.² Prohíbe comentarios públicos, textos de issues, descripciones de pull requests, documentación, diagnósticos del compilador y cualquier proceso que trate una revisión de LLM como suficiente para fusionar o rechazar código.² También crea un experimento acotado para cambios de código creados con LLM: solicitados, no críticos, declarados, de alta calidad, bien probados y plenamente entendidos tanto por la persona autora como por quien revisa.² Mi lectura: la política funciona porque optimiza la custodia intelectual, no el volumen de producción.

Ideas clave

• Para quienes mantienen proyectos: la política debe proteger la capacidad de revisión, la voz del proyecto y la responsabilidad antes de hablar de productividad.
• Para equipos de programación con IA: permite ampliamente el uso privado, pero traza una línea más firme en la autoría pública, la documentación, los diagnósticos y la autoridad para fusionar cambios.
• Para quienes contribuyen: declarar el uso solo ayuda cuando la persona sigue haciéndose cargo del trabajo. “Lo escribió el modelo” no puede convertirse en excusa.
• Para quienes crean herramientas: los bots de revisión necesitan identidades separadas, posibilidad de bloqueo, baja presión por falsos positivos y estatus consultivo.
• Para equipos de agentes: la mejor regla del borrador es cultural, no técnica: usa IA para escribir mejor, no más rápido.²

El borrador separa pensamiento de autoría

La mayoría de las políticas sobre LLM comprime dos actos distintos en una sola categoría: usar IA. El borrador de Rust separa el acto en cognición privada y autoría pública.

La cognición privada recibe un permiso amplio. Quien contribuye puede hacerle preguntas a un LLM sobre la base de código, resumir comentarios para entenderlos en privado, revisar en privado su propio código o escritura, crear herramientas personales de desarrollo y generar posibles soluciones para aprender de ellas antes de escribir su propia solución.²

La autoría pública recibe el límite firme. El borrador prohíbe comentarios desde una cuenta personal cuando fueron creados originalmente por un LLM. La misma regla cubre textos de issues y descripciones de pull requests.² El borrador también prohíbe documentación creada originalmente por un LLM, incluidos comentarios de código fuente no triviales, comentarios de documentación, comentarios de seguridad, comentarios de varios párrafos y diagnósticos del compilador.²

Esa distinción se siente correcta porque los artefactos públicos llevan la voz del proyecto. Los diagnósticos del compilador, los comentarios de seguridad y la documentación no solo trasladan información. Enseñan cómo piensa Rust. También pasan a formar parte de la carga de mantenimiento a largo plazo del proyecto.

La prosa generada por LLM puede sonar pulida mientras agrava esa carga. Quien revisa ahora debe preguntarse: ¿quién eligió esta formulación, quién entiende la implicación, quién se hace cargo del caso límite y quién corregirá la confusión más adelante? El borrador se niega a permitir que alguien delegue esa responsabilidad y conserve al mismo tiempo la credibilidad de una cuenta humana.

La regla más fuerte: no usar revisión de IA como autoridad para fusionar

El borrador prohíbe tratar una revisión de LLM como condición suficiente para fusionar o rechazar un cambio.² Los bots de revisión pueden existir, pero el borrador exige que sigan siendo consultivos. Quien revisa debe respaldar explícitamente un comentario de LLM antes de bloquear una pull request, y la persona autora sigue debiendo hacer su propia revisión.²

Esa regla evita un modo de falla tentador. Los equipos pueden agregar revisión con IA y decir que el flujo de trabajo es más seguro, incluso cuando la nueva herramienta solo crea una segunda corriente de afirmaciones que nadie tiene tiempo de evaluar. Un bot puede encontrar errores reales. También puede producir objeciones triviales, consejos de estilo obsoletos, restricciones inventadas o comentarios seguros sobre código que no entendió.

El borrador de Rust aborda ese problema de forma estructural:

La idea no es que la revisión con LLM no tenga valor. La idea es que la autoridad de revisión pertenece a las personas y al proceso del proyecto. Una máquina puede asistir a quien revisa. No puede convertirse en la revisora oficial.

La excepción para código es estrecha a propósito

El borrador no prohíbe todo código creado con LLM. Crea un experimento para cambios de código que cumplen cinco condiciones: solicitados, no críticos, de alta calidad, bien probados y bien revisados.²

Cada palabra tiene peso.

Solicitados significa que quien revisa aceptó de antemano revisar una pull request creada con LLM. Las personas nuevas que contribuyen no pueden usar un LLM por esa vía a menos que primero hablen con la misma persona asignada a revisar la PR.²

No críticos mantiene los cambios creados con IA lejos de áreas donde un error podría causar una regresión de soundness. El borrador menciona herramientas internas como un terreno más plausible y áreas como el sistema de traits, la construcción de MIR o el sistema de consultas como probablemente no adecuadas.²

Alta calidad significa que el código debe cumplir al menos el mismo estándar que otros cambios. El borrador rechaza explícitamente las PR que degradan la calidad de la base de código.²

Bien probados eleva la exigencia. Las PR creadas con LLM enfrentan una expectativa de pruebas más alta porque los LLM facilitan escribir pruebas. Si ninguna suite de pruebas existente cubre el código, la persona autora debe escribir una nueva o cerrar la PR.²

Bien revisados significa que tanto la persona autora como quien revisa se comprometen a entender completamente el código. La revisión de alguien del proyecto no reemplaza la revisión propia.²

Ese experimento tiene una forma útil. No finge que el código creado con IA no puede ayudar. También rechaza la versión perezosa de la “contribución asistida por IA”, donde alguien genera un parche, pide a quienes mantienen el proyecto que lo ordenen y no invierte esfuerzo humano en entenderlo.

Mejor, no más rápido

La frase más importante del borrador dice que los LLM funcionan mejor cuando las personas los usan para escribir mejor, no más rápido.²

Esa frase debería convertirse en el estándar por defecto para programar con IA.

La rapidez por sí sola traslada trabajo de quienes escriben a quienes revisan. Una persona ahorra una hora generando un parche y luego quienes mantienen el proyecto pasan tres horas separando código útil de pruebas extrañas, comentarios inflados, diagnósticos vagos y decisiones de diseño sin dueño. El proyecto pierde incluso si el diff termina compilando.

Mejor plantea otra pregunta: ¿la herramienta ayudó a la persona a formar una comprensión más precisa? ¿Encontró un caso límite que la autora verificó? ¿Ayudó a redactar una prueba que la autora entiende? ¿Hizo que la contribución final fuera más fácil de revisar, mantener y confiar?

El borrador de Rust vuelve exigible esa distinción. El uso privado de LLM puede mejorar la comprensión de quien escribe. La autoría pública originada en LLM puede degradar la comprensión compartida del proyecto. El código experimental creado con IA solo puede avanzar cuando la solicitud previa, el alcance, la calidad, las pruebas y la revisión cargan con la exigencia adicional.

Esa combinación supera tanto el optimismo absoluto como la prohibición absoluta. Dice que la tecnología puede ayudar, pero que el proyecto no absorberá resultados de baja custodia solo porque un modelo los hizo baratos.

La sección de moderación evita las cacerías

El borrador también maneja la aplicación de la política con una cautela poco común. Les dice a quienes contribuyen que no necesitan jugar a detectives sobre el uso de LLM. Si una infracción parece clara, señala la política. Si un caso parece estar en el límite, repórtalo a moderación y sigue adelante.²

La misma sección trata la deshonestidad sobre el uso de LLM como un asunto del código de conducta, pero también afirma que acosar a quienes contribuyen por usar LLM no es aceptable.² Esa combinación importa. Una política que invita a la sospecha puede intoxicar una comunidad más rápido que el contenido generado por IA que intenta frenar.

Una buena política de IA necesita dos límites:

El borrador pone la responsabilidad en quien contribuye sin convertir a cada persona revisora en investigadora. Eso protege la cultura de revisión tanto como el código.

Qué deberían copiar otros proyectos

La propuesta de Rust merece atención porque define roles, no impresiones vagas.

Usa LLM como:

• tutor privado;
• revisor privado;
• resumidor para tu propia comprensión;
• ayuda para descubrir errores cuando la persona verifica el error;
• fuente de experimentos cuando quien revisa acepta participar y el alcance se mantiene de bajo riesgo.

No uses LLM como:

• autor público de tu comentario;
• voz de la documentación del proyecto;
• autor de diagnósticos del compilador;
• sustituto de la revisión humana;
• excusa para pruebas que no escribiste;
• forma de hacer que quienes mantienen el proyecto revisen código que no entiendes.

Esa lista les da a quienes mantienen proyectos algo mejor que un argumento moral. Les da una política operativa.

Mi lectura

El borrador coincide con el problema de calidad que crea programar con IA. Producir código se vuelve más barato. La atención de revisión, el gusto, la coherencia, la voz del proyecto y la confianza social no se abaratan. La escasez sube de nivel.

Un proyecto que optimiza el volumen de producción ahogará a quienes lo mantienen en diffs plausibles. Un proyecto que optimiza la custodia aún puede usar IA, pero solo de maneras que vuelvan más capaz a la persona autora y reduzcan la carga de quien revisa.

El borrador de Rust protege la capa escasa. Trata los diagnósticos, comentarios, documentación y autoridad de revisión como parte del proyecto, no como texto intercambiable. Trata las pruebas y la revisión propia como obligaciones, no como accesorios. Le da una vía a la experimentación, pero no un cheque en blanco.

Esa es la dirección correcta para proyectos de software serios. Las reglas exactas pueden cambiar antes de que Rust adopte algo. La forma de fondo no debería cambiar: la IA puede ayudar a las personas a trabajar mejor, pero el ser humano todavía debe hacerse cargo de la contribución.

FAQ

¿Esta política de Rust ya fue adoptada?

No. Al 17 de mayo de 2026, la política existe como una pull request abierta de Rust Forge titulada “Add an LLM policy for rust-lang/rust”. La rama principal actual de rust-lang/rust-forge todavía no contiene src/policies/llm-usage.md.¹⁵

¿El borrador prohíbe todo uso de IA?

No. El borrador permite condicionalmente el uso privado de LLM para aprender, resumir, revisar, crear herramientas personales y generar ideas. También crea un experimento acotado para código creado con LLM que sea declarado, solicitado, no crítico, de alta calidad, bien probado y bien revisado.²

¿Qué prohíbe el borrador?

El borrador prohíbe comentarios públicos, textos de issues, descripciones de pull requests, documentación y diagnósticos del compilador originados en LLM, además de tratar una revisión de LLM como suficiente para fusionar o rechazar código.²

¿Por qué el borrador trata la documentación y los diagnósticos con tanta severidad?

La documentación y los diagnósticos llevan la voz del proyecto, la guía para usuarios y obligaciones de mantenimiento a largo plazo. El borrador permite que los LLM ayuden con la lógica circundante en algunos casos, pero les impide crear los mensajes en sí.²

¿Qué deberían aprender los equipos de programación con IA de esta propuesta?

Separa la asistencia privada de la autoría pública. Exige declaración cuando la IA afecta a otras personas. Mantén la autoridad de revisión en manos humanas. Eleva el estándar de pruebas y revisión propia cuando la IA ayuda a crear código. Optimiza para hacer mejor trabajo, no para producir más.

Referencias