La lógica detrás de la política anti-IA para contribuciones en el proyecto Zig
(simonwillison.net)- Uno de los principales proyectos de lenguaje open source aplica una regla estricta que prohíbe el uso de LLM en issues, Pull Requests, comentarios del bug tracker y traducciones
- El uso del inglés es solo una recomendación, no un requisito; quienes contribuyen pueden escribir en su idioma nativo y otras personas pueden interpretar el contenido con la herramienta de traducción que prefieran
- Bun añadió parallel semantic analysis y multiple codegen units al backend de LLVM en su propio fork de Zig, logrando una mejora de rendimiento de 4x al compilar Bun, pero por la prohibición de contribuciones escritas con LLM no hay planes actuales de enviarlo upstream
- La forma de revisión de Zig no prioriza rechazar PR incompletos, sino ayudar a nuevas personas contribuidoras a llegar hasta un trabajo que pueda hacerse merge, y da más importancia al crecimiento de quienes contribuyen que a cada aporte individual
- Los PR redactados en su mayoría por LLM hacen que el tiempo de revisión no se use para aumentar la cantidad de nuevas personas contribuidoras confiables, y además abren la posibilidad de que el maintainer ejecute directamente un LLM para resolver el mismo problema
Conflicto entre la política y el fork de Bun
- Zig deja explícito en su Code of Conduct que está prohibido usar LLM en issues, Pull Requests, comentarios del bug tracker y traducciones
- El uso del inglés es una recomendación, y quienes contribuyen pueden escribir en su idioma nativo
- Otras personas pueden interpretar el contenido con la herramienta de traducción que prefieran
- Un proyecto emblemático escrito en Zig es el runtime de JavaScript Bun, y Bun fue adquirido por Anthropic en diciembre de 2025
- Bun mantiene su propio fork de Zig y añadió “parallel semantic analysis and multiple codegen units” al backend de LLVM, logrando una mejora de rendimiento de 4x al compilar Bun
- El código relacionado está publicado en este enlace comparativo de oven-sh/zig
- Bun no tiene planes actuales de enviarlo upstream porque Zig prohíbe de forma estricta las contribuciones escritas con LLM
- Según un contributor principal de Zig, ese parche sería difícil de aceptar incluso aparte del tema de los LLM
- La parallel semantic analysis es una función planeada desde hace tiempo, pero afecta al propio lenguaje Zig
Contributor Poker y revisión centrada en quienes contribuyen
- El concepto de contributor poker en Contributor Poker and Zig's AI Ban es una metáfora clave para entender la estricta política de prohibición de Zig
- Los proyectos open source exitosos llegan a una etapa en la que reciben más PR de los que pueden procesar
- Para maximizar el ROI, Zig elige no rechazar PR incompletos de inmediato, sino ayudar a nuevas personas contribuidoras a que su trabajo pueda hacerse merge
- Este enfoque se considera no solo “lo correcto”, sino también “lo inteligente”
- Zig da más importancia a las personas contribuidoras que a cada contribución individual
- El objetivo principal al revisar y aceptar PR no es meter código nuevo, sino ayudar a personas que con el tiempo puedan convertirse en contribuidoras confiables y productivas
- Cada persona contribuidora se convierte en una inversión para el core team de Zig
- La asistencia de LLM rompe esa estructura
- Aunque un LLM ayude a redactar un PR perfecto, el tiempo que el equipo de Zig dedica a revisarlo no contribuye a aumentar la cantidad de nuevas personas contribuidoras seguras y confiables
- “contributor poker” surge de la metáfora de jugar mirando a las personas y no a las cartas
- Se acerca más a la idea de apostar por quien contribuye que por el contenido del primer PR
- Si un PR fue escrito en su mayor parte por un LLM, el maintainer del proyecto tiene la opción de ejecutar directamente un LLM para resolver el mismo problema, en lugar de revisar y discutir ese PR
1 comentarios
Comentarios en Hacker News
Según https://kristoff.it/blog/contributor-poker-and-ai/, las contribuciones basadas en LLM fueron en general negativas
PRs improvisados y sin valor aumentaron el ruido de fondo con código alucinado, no compilaban o no pasaban CI, y hasta hubo casos de personas haciendo su primera contribución y enviando un PR de 10 mil líneas
También hubo PRs que a simple vista parecían aceptables y afirmaban no haber usado LLM, pero en la discusión de seguimiento se hizo evidente de inmediato que el autor estaba consultando en secreto a un LLM y repitiendo respuestas llenas de errores
Los hooks no tienen una forma limpia de forzar su instalación al clonar, pero podría haber GHA Workflows o funciones equivalentes en otros forges
Para un proyecto con cierto tamaño y popularidad, esto me parece un requisito básico
Una parte importante del problema de “la IA no puede contribuir” parece reducible con mejores verificaciones automáticas y guardrails
Más allá de que la IA habilitó este nuevo tipo de spam, la esencia no es la IA
Aun sin IA, si la gente contratara ejércitos baratos de desarrolladores offshore para producir en masa PRs improvisados de calidad media, el efecto sería el mismo
También se puede hacer buen código con IA, pero como cualquier otra herramienta, hay que usarla con cuidado
Esto no es una contribución hecha con cuidado por alguien que conoce el proyecto y el objetivo y usa bien la herramienta; esto es spam
El ruido alrededor de la política de IA parece haber surgido porque desarrolladores de Bun dijeron que, por esa política, no podían hacer upstream de un PR de rendimiento
Pero la razón real parece ser que ese código del PR en sí estaba en mal estado e introducía complejidad poco saludable https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
Según la explicación citada, el análisis semántico en paralelo ha sido parte explícita del plan del compilador Zig desde hace mucho tiempo y también influyó mucho en el diseño del self-hosted Zig compiler, pero implementarlo correctamente requiere cambios no solo en el compilador sino también en el lenguaje Zig
Choca con el roadmap propio de Zig para obtener mejores resultados y además estorba la dirección de seguir mejorando el lenguaje completo
La política prohíbe explícitamente todo código LLM, así que esa política claramente es la “razón real”
Parece que Zig está siguiendo el camino de ZeroMQ https://zguide.zeromq.org/docs/chapter6
La idea es “forzar la propiedad colectiva del proyecto para aumentar los incentivos económicos de quienes contribuyen y reducir el riesgo de secuestro por actores hostiles”
Una comunidad de contribuyentes sana es más importante que el simple rendimiento del código, la cantidad de funciones o la cantidad de líneas
Hoy la “comunidad” de zeromq es bastante dispersa; todavía hay algunas personas excelentes activas, pero los procesos y canales de comunicación a escala humana no están bien definidos ni suficientemente operados
Como libzmq y la mayoría de los bindings son estables, esta falta de actividad e interacción humana quizá sea tolerable o justificable hasta cierto punto, pero la gran visión de Hintjens fue lo que llevó a zeromq hasta aquí, y desde que él ya no está, el proyecto da la impresión de ir a la deriva
Irónicamente para una visión centrada en la comunidad, parece que para conseguir y mantener una comunidad hace falta un líder carismático y activo, lo cual dice más sobre la naturaleza humana que sobre el desarrollo de software
Volviendo al caso de Zig, hay una premisa de que a Zig no le faltan PRs, así que puede filtrar de entrada las contribuciones sin LLM
Para ellos es una buena decisión y la idea de “contributor poker” se entiende
Pero si baja el flujo de gente nueva, el juego cambia, y si en ese momento la gente de Zig todavía quiere nuevos contribuidores, quizá tenga que ampliar la red
Aunque para cuando llegue ese momento, abrirse a contribuciones asistidas por LLM podría ser ya demasiado tarde para recuperarse
Lo que me pregunto sobre las contribuciones OSS generadas por IA es esto
Si la IA realmente aumenta tanto la productividad de los desarrolladores, ¿por qué un maintainer querría meter entre él y su LLM a un contribuyente desconocido?
El maintainer puede preguntarle directamente a Claude Code
Como dijo un colega, “no necesitamos un intermediario para hablar con un modelo de IA, y programar no es el cuello de botella”
Usa IA para crear una primera versión mala, ajusta prompts, hace correcciones manuales, le pide que arregle otras partes, detecta funciones relacionadas para agregarlas y corre benchmarks para quitar alguna función menor o elegir entre dos implementaciones parecidas
También mete más ajustes manuales por aquí y por allá, corre pruebas automáticas ampliadas para encontrar bugs raros en configuraciones extrañas, y los arregla con IA y trabajo manual
Después de 20 horas, la versión final tiene solo 50 líneas y cada línea pudo haberse reescrito 5 veces
El maintainer solo necesita revisar la versión final durante una hora más o menos
Eso es totalmente distinto de hacer que la IA escriba un parche en 5 minutos y mandarle al maintainer 1000 líneas que ni compilan, sin ni siquiera leerlas
“Eso era tan fácil que yo también podría haberlo hecho”
Sí, pero no lo hiciste
Pero no es del tipo al que le puedes lanzar solo instrucciones de alto nivel como si fuera una persona
Sospecho que quienes dicen que la IA funciona solo con instrucciones de alto nivel suelen estar trabajando en proyectos “sin pensamiento”, donde no hace falta que el desarrollador entre mucho en los detalles
Espero que tampoco quieras decir que la única ventaja de los LLM es generar código que da flojera teclear a mano
La explicación de que “Zig valora más a los contribuyentes que a las contribuciones. El objetivo principal de revisar y aceptar PRs no es meter código nuevo, sino ayudar a que con el tiempo la gente se convierta en contribuidores confiables y productivos. La asistencia de LLM rompe eso por completo. Incluso si ayudara a enviar PRs perfectos, sería igual” es la mejor justificación que he visto hasta ahora
Apoyo completamente la decisión de Zig y valoro mucho esa visión de largo plazo tanto para la comunidad como para el proyecto real
Sinceramente, no me parece que los LLM encajen tan bien en trabajo más colaborativo
Veremos cómo cambia esto en el futuro, pero cuando acepto PRs generados por IA muchas veces termino teniendo que rehacerlos yo mismo, y de forma irónica cada vez más los rehago usando LLM, lo que me genera conflicto
Aun así, creo que por lo menos durante los próximos 5 años la política de Zig es una buena idea
Me parece la forma menos hostil en que podían decirlo, y respeto que sea una decisión sobre su propio proyecto
Aun así, sigo sintiendo que están atando el proyecto innecesariamente
Los LLM son una herramienta y pueden ayudar a pensar, investigar y programar
Se puede abusar de ellos, pero donde ayudan deberían aceptarse
Está perfecto no aceptar el PR de Bun por otras razones, pero prohibir simplemente todos los PRs escritos con LLM es innecesariamente restrictivo
Solo hay que enfocarse en la calidad del trabajo
Si el maintainer usara directamente el LLM para hacer lo mismo, probablemente lo haría con mejor diseño y un enfoque más cuidadoso
El maintainer necesita dedicar tiempo a desarrollar, no solo a revisar PRs de bajo esfuerzo
La avalancha de código LLM está cambiando el equilibrio en contra de los maintainers, y entiendo perfectamente por qué simplemente quieren prohibirlo
Mi impresión general después de usar por un tiempo LLMs y coding agents es que esto es una herramienta eléctrica o una grúa, no una herramienta para tomar decisiones
Las personas dentro de una organización con gran comprensión conceptual y profundidad de ingeniería ven explotar su productividad
En cambio, quienes entienden menos, o los nuevos o juniors, están produciendo código infernal con la idea de que si corre, entonces ya quedó
Los LLM crean una brecha intelectual dentro de la organización, y mientras más se usan, más se agranda esa brecha
Más adelante puede que terminemos sin poder confiar en lo que produce la propia organización por culpa del código generado
La IA, en general, amplifica el skillset; potencia tanto lo bueno como lo malo
Un caso de uso reciente que fue excelente fue redactar el concepto de un authentication daemon
Conversé con Codex, fui seleccionando propuestas, las contrasté con búsquedas web normales, definí un borrador final y luego lo discutí con colegas
Este tipo de planning conversacional con búsqueda web integrada es increíblemente útil, y también veo puro beneficio en revisar con IA código ya escrito
Pero el caveat central de la IA sigue siendo que al final tienes que ser más inteligente que la herramienta
Si Codex propone usar el tech stack X, debes investigar por qué realmente sería una buena idea, entenderlo por completo y compararlo con otras soluciones
Mucha gente se salta ese paso, y de ahí salen muchísimos problemas; eso es fatal
Cuando termina la conversación, deberías haber quedado más inteligente que la IA, y deberías poder entender y criticar completamente lo que dijo
Una vez definida la arquitectura, el LLM implementa bastante bien
En general se le puede hacer producir código excelente y bien testeado, y a veces mucho mejor de lo que uno haría solo en el mismo tiempo
Pero seguirle el ritmo al conocimiento de todo lo que hace la IA sigue siendo un desafío
La lógica de “si el PR está escrito en su mayor parte por un LLM, ¿por qué el maintainer no usa su propio LLM para resolver el mismo problema en el tiempo que gastaría revisando y discutiendo ese PR?” también aplica al open source en sí
Si un robot puede escribirlo directamente, ¿para qué usar el proyecto de otra persona?
Sobre todo si ese proyecto open source está vibe coded
La IA y la tecnología en general abaratan y facilitan la personalización
Antes había que usar productos masivos que dejaran a todo el mundo más o menos satisfecho, pero ahora existe la esperanza de obtener algo excelente solo para mí
Además, como mucha gente está rehaciendo proyectos open source con LLM por todos lados, eso también mueve la economía del trabajo
Un LLM puede escupir eso en minutos
Lo que más quiero es historial de uso
Quiero usar software que otras personas ya hayan usado antes que yo, y espero que se hayan topado con bugs y asperezas y lo hayan ido puliendo
La idea era que nadie compraría cosas porque podrías bajar un modelo en casa, imprimirlo y personalizarlo infinitamente
La razón por la que existe la civilización es que puedes pasarle la mayoría de los problemas de tu vida a otra persona y concentrarte en hacer bien una sola cosa
Si eres dentista o tienes un muffler shop, tu tiempo diario es limitado, y probablemente prefieras pagarle a un vendor de SaaS antes que aprender vibecoding y supervisar a un subordinado raro y demandante
Hay excepciones, pero siguen siendo excepciones
Si el vendor hace un producto razonable y competente, con gusto le pago
Con el open source pasa lo mismo
Aunque un LLM pudiera crear desde cero un sistema operativo estable, ¿de verdad querría yo eso?
No quiero mantener un OS, no quiero gestionar a alguien que mantenga un OS, y ni siquiera creo tener una visión coherente sobre un OS desde el principio
Pasado cierto nivel de complejidad, es difícil esperar que el robot lea mi mente lo suficiente como para darme un resultado de alta calidad “excelente solo para mí”
Claramente el proyecto Zig está muy por fuera de ese rango de capacidad
Hay personas a las que les cuesta pagarlo, y aun teniendo acceso también aparecen problemas como caídas de Claude o una degradación general del rendimiento con el tiempo, ya sea ocasional o persistente
Hace unos meses, cuando recién empecé a usar Claude en serio, avancé con facilidad en varios proyectos dentro de una sola semana, pero últimamente siento que solo veo el spinner y que la calidad del código se desplomó, así que casi no logro hacer nada
Tengo algunos repos con como 100 estrellas, nada extraordinario, pero hasta el año pasado recibía algún PR de vez en cuando y este año hasta ahora casi nada
Mi hipótesis es que los LLM prefieren engancharse a proyectos mainstream
Como muchos desarrolladores ahora dependen mucho de los LLM, aparece un sesgo a ignorar la mayor parte de lo que yo ofrezco
También hay más reinventar la rueda con LLM porque el costo de crear algo nuevo bajó
Entonces se vuelve más fácil generar lo que necesitas que usar algo oscuro de GitHub, como mis repositorios
Veo el mismo fenómeno en cómo elijo dependencias
Si no hay una muy buena razón para no hacerlo, hay una tendencia a simplemente aceptar lo que recomiende el LLM
Estoy de acuerdo hasta cierto punto, pero no del todo
Es cierto que hacer crecer a los contribuidores es la prioridad correcta
Pero veo la IA como una tecnología de asistencia
Algo parecido a un screen reader o una magnifying glass, aunque claro que también hay muchas diferencias
Se podría pensar como un exoesqueleto robótico
Se usará para cosas malas y para tonterías, pero también servirá para que gente que antes no podía haga cosas buenas o se vuelva más capaz
Para algunas personas, la IA hace posible programar algo que antes no podían; para muchas, será una forma de aprender a programar viendo lo que hace la IA; y para otras, les permitirá programar mucho más rápido o mejor
En algunos casos puede que ciertas habilidades se atrofien mientras otras se desarrollan
Con un exoesqueleto pasaría algo parecido si saliera al mercado un producto decente, pero en conjunto seguiría siendo una herramienta que habilita capacidades
No veo por qué formar contribuidores que usan tecnología de asistencia sería peor que formar contribuidores que no la usan
Claro, sí puede ser más difícil
Los LLM no son tan inteligentes como afirmaban los vendors de LLM
Si realmente lo fueran, serían totalmente autónomos y ni siquiera estaríamos teniendo esta conversación
Quienes envían a ciegas código generado por LLM o no revelan que lo usaron realmente deberían dejar de hacerlo
El problema que queda es que sigue siendo una herramienta
Aunque le dieras a un desarrollador cualquiera la orden “haz Zig más rápido en un PR de un solo tiro”, no saldría nada bueno
En el pasado, los proyectos OSS se autofiltraban porque había que ser capaz de producir working code, y al llegar a ese punto por lo general ya tenías algunos años de aprendizaje detrás, así que solías hacer más o menos lo correcto y tenías tu propio razonamiento sobre funcionalidades o necesidades
Hoy, aunque el LLM fuera perfecto y razonara bien, al final igual ejecuta las instrucciones de quien lo promptea
En otras palabras, se perdió esa autoselección
A la gente de Zig probablemente también le resultará difícil juzgar qué código hizo un LLM y cuál hizo una persona
Puede que ya haya entrado código generado por LLM, pero al menos esos humanos que lo envían siguen teniendo que manejar bastante bien el código
Al final me pregunto si iremos hacia “solo humanos con un badge de honor confiable pueden hacer commit”, o hacia un punto en que “el LLM razone lo suficiente como para decir ‘no, vete al diablo. Esta función, plan o idea es basura y no la voy a hacer’”
Si no hay una forma efectiva de darles un golpe duro cuando lo hacen, no sé qué podría detenerlos