Cinco equipos de Rust adoptan reglas sobre LLM para proteger la revisión de código realizada por humanos

Why it matters

Rust is confronting the central constraint of AI-assisted software development: models can produce code faster than experienced maintainers can judge, explain and support it.

Five equipos de Rust han adoptado una política de contribución sobre LLM escrita por Jynn Nelson, una mantenedora de Rust de larga trayectoria y líder del equipo de compilador en Ferrous Systems, dando a los revisores reglas explícitas para manejar código y texto generados por IA en el monorrepo rust-lang/rust.

Los equipos de compilador, bibliotecas, types, rustdoc y bootstrap, junto con sus subequipos, aprobaron recientemente las reglas, escribió Nelson en un Inside Rust publicado el 5 de agosto. La política no rige todo el proyecto Rust. Equipos como language y edition siguen siendo libres de establecer sus propias prácticas, y los repositorios fuera del monorrepo principal de Rust quedan fuera de su alcance.

Nelson ha pasado años trabajando en las partes de Rust donde confluyen las decisiones técnicas y la gobernanza de contribuyentes. En su currículum se le acredita haber liderado rustdoc y docs.rs, fundar el equipo bootstrap de Rust, reclutar mantenedores y reducir el tiempo de compilación de rustdoc por un factor de nueve. Antes de unirse a Ferrous Systems en septiembre de 2025, Nelson trabajó en compiladores, bases de datos e infraestructura de red en YottaDB, TCDI, Redjack y Cloudflare.

Esa trayectoria dio forma a una política centrada en la responsabilidad de los mantenedores en lugar de un juicio amplio sobre la IA. La preocupación de Nelson es que la salida generada ha debilitado las señales que los revisores de código abierto solían usar para decidir dónde invertir su tiempo. Un pull request pulido puede representar días de trabajo cuidadoso de un aspirante a mantenedor. También puede ser una salida que su autor no puede explicar, revisar o mantener después de que se fusione.

La solución de gobernanza de Nelson

El anuncio público llegó el 5 de agosto, pero la política se construyó a lo largo de varios meses. La propuesta de Rust Forge se abrió el 17 de abril tras un extenso debate privado y público. El registro de su discusión dice que las conversaciones previas en Zulip de Rust generaron más de 3,000 mensajes, sin contar el posterior debate en GitHub.

Nelson enmarcó el trabajo como una respuesta a una aplicación inconsistente. Los revisores de Rust ya se habían encontrado con docenas de pull requests asistidos por LLM, incluidas contribuciones iniciales que proponían optimizaciones de compilador arriesgadas. Los moderadores no tenían una regla de divulgación común, lo que dejaba a los contribuyentes descubrir las expectativas después de que un revisor cerrara su trabajo.

La política publicada de uso de LLM da a ambas partes un estándar por escrito. Su resumen operativo es conciso: "Está bien usar LLMs para responder preguntas, analizar, destilar, refinar, comprobar, sugerir, revisar. Pero no para crear."

La asistencia privada de IA generalmente está permitida. Los contribuyentes pueden hacer preguntas a un modelo sobre la base de código, resumir discusiones para uso personal, revisar su trabajo en privado o generar posibles enfoques antes de escribir su propia solución. Las reglas también permiten que los contribuyentes usen LLMs para encontrar errores si un humano verifica el resultado y divulga la participación del modelo al reportarlo.

La salida pública enfrenta controles más estrictos. Los contribuyentes no pueden presentar comentarios, cuerpos de issues, descripciones de pull request, documentación, diagnósticos del compilador o comentarios sustanciales en el código originalmente creados por un LLM como su propia redacción. Se permiten citas claramente marcadas cuando la contribución circundante se sostiene por sí misma. La traducción automática, las ediciones triviales y las revisiones asistidas por IA están permitidas condicionalmente con divulgación.

La distinción pone la responsabilidad en el contribuyente. Un modelo puede ayudar a alguien a pensar, inspeccionar o traducir. El humano aún tiene que presentar el argumento, entender el cambio y rendir cuentas ante el revisor.

El código generado por IA obtiene una vía experimental

Las reglas de Rust no llegan a prohibir el código generado. Crean un experimento controlado con una barrera de entrada más alta que el proceso ordinario de contribución.

Un cambio creado por LLM debe acordarse con un revisor dispuesto antes de abrir el pull request. Debe evitar áreas críticas para la solidez, cumplir los estándares de calidad de la base de código, incluir pruebas y ser entendido tanto por su autor como por el revisor. Los nuevos contribuyentes no pueden enviar primero código generado y buscar un revisor después.

Las presentaciones aceptadas reciben la etiqueta ai-assisted y se publican en un canal privado de Zulip accesible para miembros de la organización Rust. Ese canal pretende recopilar evidencia sobre si los contribuyentes están aprendiendo, regresando con trabajos adicionales y produciendo cambios que valga la pena mantener. Los revisores pueden rechazar pull requests asistidos por IA, y una revisión por LLM no puede reemplazar la aprobación humana ni la propia revisión del autor.

La política también contiene un interruptor numérico. Si los cambios creados por LLM superan el 50% de todos los pull requests fusionados durante un período móvil de seis semanas, Rust pausará más fusiones generadas por IA hasta que la proporción caiga por debajo de ese umbral. El enfriamiento dura al menos 10 días.

Ese límite es deliberadamente conservador y puede resultar en gran medida teórico. Hace explícita la prioridad subyacente de Rust: no se puede permitir que las contribuciones generadas consuman la base de código ni que las herramientas de IA se conviertan en un requisito práctico para participar.

El recurso escaso es el criterio de los revisores

Nelson reportó 1,281 pull requests abiertas en rust-lang/rust en el momento del anuncio. La cifra es una instantánea, pero captura la asimetría que impulsa la política. Los sistemas de IA pueden aumentar la oferta de código mucho más rápido de lo que un proyecto de código abierto puede reclutar personas experimentadas para evaluar decisiones arquitectónicas, costos de mantenimiento a largo plazo e implicaciones de seguridad.

El trabajo de revisión en un compilador rara vez termina con localizar una línea errónea. Los mantenedores deben decidir si una dirección propuesta pertenece en Rust, cómo interactúa con otros componentes del compilador y quién entenderá el cambio meses después. El código generado reduce el costo de presentar una implementación plausible sin reducir el costo de tomar esas decisiones.

La política también aborda una ruptura de colaboración más inmediata: contribuyentes que alimentan comentarios de revisión a un LLM y pegan su respuesta de vuelta en GitHub. Nelson sostiene que los revisores están pidiendo el razonamiento del autor. Las respuestas generadas por máquinas dejan a los mantenedores inseguros sobre si están trabajando con alguien que entiende el parche o simplemente retransmite mensajes entre un revisor y un modelo.

La respuesta de Rust es vincular los derechos de contribución al entendimiento humano. La política no pide a los revisores que detecten código escrito por IA por estilo, y les advierte que no hagan acusaciones públicas basadas en sospechas. Los autores deben divulgar su uso. La supuesta deshonestidad pasa por moderación en lugar de convertirse en una discusión dentro del pull request.

Un compromiso local, por ahora

El alcance estrecho refleja cómo toma decisiones Rust. El proyecto opera mediante consenso entre equipos con diferentes responsabilidades y puntos de vista sobre la IA. Nelson escribió que algunos contribuyentes ven valor práctico en estas herramientas, mientras que otros objetan sus costos técnicos, sociales o ambientales. La política adoptada parte de preocupaciones compartidas sobre la experiencia, la inclusión y la capacidad de los revisores.

Una respuesta a nivel de proyecto sigue por definirse. Una actualización de gestión del programa del 14 de julio dijo que el Consejo de Liderazgo de Rust estaba discutiendo un comité de LLM que podría redactar y revisar reglas más amplias. La propuesta pedía cuatro o cinco miembros que representaran puntos de vista diferentes en todo el proyecto.

Hasta que avance ese trabajo de gobernanza, la política de Nelson ofrece a las partes más ocupadas del repositorio central de Rust un modelo operativo práctico. Conserva espacio para experimentos mientras hace que el remitente asuma el costo de demostrar que el trabajo generado merece la escasa atención de los revisores. Ese intercambio probablemente se volverá familiar en el código abierto a medida que la generación de código abarate y la labor de mantenimiento siga siendo obstinadamente humana.