Prohibición de IA en Zig: la confianza del revisor por encima de la productividad de los LLM

Una pull request nunca es solo una pull request. Es una pequeña factura enviada por correo a los mantenedores, pagadera en atención, contexto y esas malditas horitas después de cenar en las que realmente ocurre el código abierto. Zig ha estampado un enorme “no” rojo sobre una categoría de factura: las contribuciones asistidas por modelos grandes de lenguaje quedan fuera. Eso convierte al proyecto Zig en un caso de estudio útil para quienes construyen IA y ML, porque el argumento no trata realmente sobre si los asistentes de código pueden producir código. Obviamente pueden. También pueden hacerlo los becarios, la arqueología de Stack Overflow y un ingeniero sénior privado de sueño impulsado por café de aeropuerto. La pregunta es quién paga por verificar el resultado.

La prohibición es más amplia que el código, según Simon Willison y Business

Simon Willison describe a Zig como uno de los proyectos importantes de código abierto con una de las políticas anti-LLM más estrictas, y cita directamente el lenguaje del proyecto: “No LLMs for issues.” También cita: “No LLMs for pull requests.” El mismo texto de la política, según lo cita Willison, cubre los comentarios del rastreador de errores, incluida la traducción, al tiempo que anima a los colaboradores a publicar en su lengua materna y dejar que otros usen herramientas de traducción si hace falta.

Business Insider informa que Zig prohíbe a los colaboradores usar IA para programar, depurar o generar ideas, y su titular cita al presidente de Zig, Andrew Kelley, diciendo que las contribuciones de código con IA son “invariablemente basura”. La cita picante consigue los clics, porque claro que sí, pero el mecanismo importa más que el picante. Zig está tratando la procedencia como parte de la revisabilidad: si los mantenedores no confían en cómo se produjo un artefacto, pueden decidir no gastar su escaso tiempo de revisión desenredándolo.

Let’s Data Science añade que la regla cubre código, ediciones, traducciones, lluvia de ideas, búsqueda de errores e incluso mencionar el uso de LLM en los espacios del proyecto. AI Weekly dice de forma similar que la prohibición cubre artefactos tocados por LLM, incluidos issues, comentarios y pull requests. En otras palabras, Zig no solo está diciendo: por favor, no pegues código de un chatbot en el compilador. Está diciendo que el propio canal de comunicación del proyecto tiene un requisito de calidad de origen, que es la gobernanza llevando una sudadera de compilador.

El ancho de banda de los revisores es

el recurso escaso, según Loris Cro y Let’s Data Science

Loris Cro, escribiendo desde su experiencia con la Zig Software Foundation, plantea las contribuciones de código abierto como un intercambio más que como una cesta de regalos. Argumenta que las pull requests pueden convertirse por sí mismas en trabajo adicional y fricción, y que es común que a un mantenedor le cueste menos esfuerzo implementar un cambio directamente que revisar un parche enviado. Esa es la parte que muchos debates sobre programación con IA rodean educadamente, como una Roomba evitando un calcetín.

Let’s Data Science informa que Zig tenía alrededor de 200 pull requests abiertas y un pequeño grupo central de revisores cuando se articuló la política. Ese contexto hace que la prohibición parezca menos pureza estética y más gestión de cola. Si un proyecto ya tiene más demanda de revisión que oferta de revisores de confianza, los envíos generados pueden comportarse como pruebas de carga sintéticas para humanos, excepto que nadie presentó un plan de capacidad.

AI Weekly dice que Kelley enmarcó la política como una priorización de recursos, citando el valor de revisión negativo de los envíos con IA. Esa frase es la viga de carga aquí. Un parche generado puede ser barato localmente para el colaborador y caro globalmente para los mantenedores, lo que básicamente es la tragedia de los comunes, pero con autocompletado y más YAML.

Bun muestra el riesgo aguas arriba, según AI Weekly y Simon Willison

AI Weekly informa que Bun, propiedad de Anthropic y dependiente de flujos de trabajo asistidos por IA, bifurcó Zig después de no poder incorporar cambios aguas arriba. Simon Willison también señala que Bun opera su propia bifurcación de Zig y dice que Bun fue adquirida por Anthropic en diciembre de 2025. Para los equipos que construyen productos comerciales sobre bases de código abierto, esa es la lección de gobernanza con dientes.

La fantasía empresarial habitual es que el upstream es una cinta transportadora amigable: contribuyes mejoras, se fusionan, reduces la divergencia y todo el mundo choca los cinco en el pasillo de una conferencia. La política de Zig muestra un modo de fallo diferente. Si tu flujo de trabajo de ingeniería depende de la asistencia de IA y un proyecto upstream rechaza contribuciones creadas por LLM, puede que tengas que mantener una bifurcación, reescribir el trabajo manualmente o cambiar cómo se preparan las contribuciones.

Eso no convierte a Zig en anti-productividad en algún sentido cósmico. Significa que Zig está optimizando la confianza de los mantenedores por encima del volumen de contribuciones. Ambos son valores reales, y fingir que nunca entran en conflicto es la forma de terminar con un backlog con forma de formación geológica.

Esto es más grande que Zig, según Research Information

Research Information informa que arXiv advirtió a los autores que podrían enfrentarse a una prohibición de envío de un año por trabajos que contuvieran evidencia clara de salida no revisada de modelos grandes de lenguaje. No es el mismo dominio que las pull requests de un compilador, pero el patrón rima con fuerza. Las instituciones están pasando de una etiqueta de IA basada en sensaciones a reglas explícitas de responsabilidad.

Para quienes construyen IA, la conclusión práctica no es entrar en pánico ni realizar un destierro ritual de chatbots bajo la luna llena. Es diseñar flujos de contribución que hagan la revisión más barata: revelar el uso de herramientas donde esté permitido, mantener los parches pequeños, proporcionar pruebas, explicar la intención y estar listo para hacerse responsable de cada línea como si un loro estocástico no la hubiera susurrado hasta hacerla existir.

Si un proyecto prohíbe la asistencia de LLM, respeta ese límite o contribuye en otro lugar. Lo siguiente que habrá que observar es si más proyectos de código abierto copian la línea clara de Zig o eligen reglas más suaves sobre divulgación y verificación. De cualquier manera, las herramientas de programación con IA están dejando la etapa de demostración y entrando en la hoja de cálculo de gobernanza. Resulta que la parte más difícil del código generado siguen siendo los humanos que tienen que creer en él.