La prohibición de IA en Zig y el problema del 'contributor poker'

El proyecto Zig lleva meses siendo uno de los pocos proyectos de código abierto con una postura explícita y documentada contra las contribuciones generadas por IA. Ahora, Loris Cro —uno de sus principales mantenedores— ha publicado un artículo que va más allá de los argumentos habituales sobre calidad del código y articula algo más incómodo: el problema no es solo lo que el código hace, sino lo que el acto de contribuir significa cuando hay IA de por medio.

El texto, que circuló esta semana por Hacker News, introduce el concepto de contributor poker: la idea de que, cuando alguien envía una pull request, los mantenedores están jugando una partida de información asimétrica. No saben cuánto tiempo invirtió el autor, qué comprende realmente del problema, ni si estará disponible para iterar si algo sale mal. Con código generado por IA, esa asimetría se dispara.

Qué argumenta Loris Cro

Cro distingue dos capas de preocupación que normalmente se mezclan en estos debates.

La primera es la calidad técnica. Sí, los modelos actuales cometen errores sutiles, especialmente en lenguajes de bajo nivel como Zig, donde la semántica de memoria y la ausencia de un runtime exigen precisión milimétrica. Un fallo que un compilador más permisivo atraparía en tiempo de ejecución puede aquí convertirse en comportamiento indefinido difícil de rastrear. Esto ya sería razón suficiente para ser cautelosos.

Pero la segunda capa es la que da título al artículo: el coste oculto para los mantenedores. Revisar código —sea cual sea su origen— consume tiempo y atención. Cuando ese código viene de alguien que lo generó en segundos sin entenderlo en profundidad, el esfuerzo de revisión no disminuye; en muchos casos, aumenta. El mantenedor debe hacer el trabajo cognitivo que el contribuidor delegó a la máquina. Y si la PR es rechazada o necesita refactorización sustancial, el costo total del intercambio recae casi íntegramente sobre quien no generó el código.

Cro lo plantea como un problema de incentivos: la IA reduce fricciones para quien contribuye, pero las traslada —amplificadas— a quien revisa. En un proyecto voluntario con pocos mantenedores, eso no es un detalle menor.

Por qué esta discusión importa más allá de Zig

La política de Zig no es representativa del ecosistema open source en general. La mayoría de proyectos no han tomado postura, y algunos de los más grandes —Linux kernel incluido— han optado por no prohibir explícitamente el código asistido por IA, dejando la responsabilidad al contribuidor.

Pero el marco conceptual que propone Cro sí tiene aplicación general. El contributor poker describe una dinámica que existe en cualquier proyecto donde haya asimetría entre el esfuerzo de generar y el esfuerzo de revisar. La IA no inventó ese problema, pero lo escala de forma significativa porque reduce el coste marginal de enviar una contribución casi a cero.

Esto tiene implicaciones prácticas para los equipos que mantienen proyectos activos. No necesariamente para prohibir el uso de modelos —algo difícil de verificar y potencialmente contraproducente—, sino para pensar en cómo estructurar las expectativas: ¿se exige que el autor pueda explicar cada decisión de diseño? ¿Se pide que las PRs vengan acompañadas de tests escritos por el contribuidor? ¿Se limita el tamaño de las contribuciones de nuevos participantes?

Varios proyectos ya están adoptando estas medidas de forma informal. Zig simplemente las ha hecho explícitas y ha ido un paso más allá al convertirlo en política oficial.

Para quién es relevante esto

El artículo interesa especialmente a tres perfiles: mantenedores de proyectos open source que están empezando a notar un incremento de PRs de baja densidad cognitiva; desarrolladores que usan asistentes de código y quieren entender cómo sus contribuciones son percibidas; y equipos de ingeniería que definen políticas internas sobre uso de IA en flujos de trabajo colaborativos.

No es un texto técnico en el sentido estricto —no hay benchmarks ni ejemplos de código roto—, pero ofrece un vocabulario útil para una conversación que hasta ahora se estaba teniendo de forma bastante imprecisa.

---

Desde ElephantPink, encontramos razonable la distinción que traza Cro entre calidad técnica y coste de revisión: son dos problemas distintos y merecen respuestas distintas. La prohibición total puede ser demasiado blunt para muchos contextos, pero ignorar la segunda capa del problema —como hace la mayor parte del debate público— tampoco ayuda a nadie.