El proyecto Rust ha adoptado una política que regula el uso de LLM en las contribuciones al repositorio principal rust-lang/rust. Cinco equipos han firmado el documento, redactado por Jynn Nelson. La política define qué es aceptable y qué no cuando se usa un modelo para abrir pull requests, reportar issues o responder a comentarios de revisión.

Este movimiento llega mientras Debian aún vota sobre cuatro propuestas similares, como contábamos el 26 de julio. Los dos proyectos open source más estructurados que escriben reglas explícitas en el mismo período señalan un cambio de fase: la gobernanza de contribuciones con IA se vuelve operativa.

Por qué te importa. Si integras LLM en flujos de trabajo técnicos colaborativos, estos documentos son el modelo de partida. Rust identifica tres problemas concretos: los PR generados por un modelo parecen cuidados pero no indican comprensión real, el volumen de contribuciones satura la capacidad de revisión, y quienes pegan respuestas de un LLM en comentarios de revisión desperdician el tiempo de quien revisa. Son dinámicas que cualquier equipo técnico enfrenta cuando los miembros usan asistentes de IA en el trabajo compartido.

La política formaliza reglas que antes eran implícitas y se aplicaban de forma inconsistente. Ahora los contribuidores saben qué se espera de ellos antes de enviar un PR, y los revisores tienen una referencia explícita cuando cierran uno que no las cumple.

En detalle

Antes de esta política, el proyecto Rust aplicaba un enfoque que Nelson describe como “west salvaje”: ninguna regla publicada sobre el uso de LLM, moderación inconsistente, contribuidores nuevos que descubrían las reglas solo cuando su PR era cerrado por razones que no entendían. La falta de reglas explícitas iba en contra de los objetivos de transparencia y acogida del proyecto.

El problema de fondo es que un pull request bien escrito, con tests y documentación, era tradicionalmente una señal de compromiso y comprensión. Influía en la cultura de Rust de formas específicas: los revisores eran reacios a cerrar PR porque representaban el trabajo de alguien, el proceso enfatizaba la discusión incremental, y un PR se interpretaba como interés en unirse a la comunidad a largo plazo.

Con los LLM, ninguno de estos señales es más confiable. Un PR cuidado ya no indica esfuerzo real. El autor no necesariamente entiende el código que produjo. En el caso de agentes autónomos, no hay nadie del otro lado. Nelson escribe que en el momento de la publicación hay 1.281 PR abiertos en rust-lang/rust, frente a una capacidad de revisión ya insuficiente antes de la llegada de los modelos. Facilitar la escritura de código empeora un problema que el proyecto ya tenía.

La política se aplica a cuatro categorías de personas: quienes revisan o moderan PR, quienes escriben PR con código generado por LLM, quienes reportan issues encontrados con un modelo, y quienes citan directamente el output de un LLM en issues o comentarios. Quienes no entran en estas categorías no necesitan cambiar nada.

El punto para quienes gestionan equipos técnicos. Nelson es explícita: la mayor parte del trabajo de revisión consiste en decidir si una dirección es correcta y si el PR tiene sentido. Enviar decenas de PR a los revisores tiene un costo mental alto. El código en sí es la parte más pequeña y en algunos casos menos importante de la contribución. Lo que importa es que el autor entienda qué hace el código, haya planificado cómo evolucionará, y haya decidido cómo debería verse. Un LLM no ayuda en ninguno de estos pasos.

La política es un documento operativo para un repositorio específico. Se aplica a cinco equipos entre todos los del proyecto, y la gobernanza sigue siendo local. Los límites están declarados: la política solo concierne a rust-lang/rust y no se extiende a todo el ecosistema Rust.

El paralelo con Debian es directo. Ambos proyectos están escribiendo reglas sobre el mismo tema en el mismo período, partiendo de problemas similares: contribuidores que usan LLM sin saber qué se espera de ellos, revisores sin referencias explícitas para rechazar contribuciones inaceptables, y una tensión entre la acogida de recién llegados y la calidad de la colaboración. La diferencia es que Rust ya tiene un documento firmado por cinco equipos, mientras que Debian aún está en fase de votación sobre cuatro propuestas que van desde la prohibición total hasta el enfoque gradual.

Para quienes llevan IA a los procesos colaborativos, el precedente es doble: las reglas escritas vienen antes de los problemas, y el código generado por un modelo no sustituye el juicio de quien lo produce.