MicroZig, el Zig para sistemas embebidos, prohíbe la IA

MicroZig veta la IA: ni código, ni edición, ni traducción

El 28 de octubre de 2026 entró en vigor el nuevo código de conducta de MicroZig, el proyecto de Zig Embedded Group: ningún contenido generado por un modelo de lenguaje puede circular por su organización de GitHub ni por su servidor de Discord. La regla no distingue entre código y prosa, y tampoco perdona los usos aparentemente menores, como corregir una falta de ortografía.

Para un founder que mantiene o depende de software open source, la decisión importa por una razón concreta: el tiempo de revisión es el recurso más escaso de cualquier proyecto comunitario, y las políticas de IA se están escribiendo justamente para protegerlo.

¿Qué prohíbe exactamente la nueva política?

El documento, alojado en el repositorio de MicroZig, enumera los casos uno por uno:

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Contenido generado por un LLM, sea código o prosa.
Parafrasear contenido generado por un LLM.
Usar un LLM para editar, incluida la corrección de errores ortográficos o gramaticales.
Usar un LLM para traducir. El inglés se recomienda pero no es obligatorio: puedes escribir en tu idioma nativo y confiar en que cada quien use su propia herramienta de traducción.
Hacer brainstorming con un chatbot y compartir el resultado, incluso si la redacción final es tuya. Si le pides consejo a un chatbot sobre un comentario en el issue tracker, ese comentario no es bienvenido.
Usar un LLM para encontrar bugs.
Hablar del uso de servicios de chatbot o LLM.

El punto de la traducción es el más llamativo, porque va en la dirección opuesta a lo que hicieron otras comunidades. Mientras r/opensource cerró el acceso a quienes no escriben en inglés, MicroZig prefiere el idioma nativo antes que una traducción automática.

El origen: Zig ya había vetado la IA y llamó «basura» a las contribuciones

El propio documento aclara que está «en gran medida tomado del código de conducta de Zig». No es casualidad: el lenguaje Zig ya había adoptado una prohibición equivalente, y su presidente, Andrew Kelley, explicó el razonamiento en el podcast de JetBrains, según reportó Business Insider.

Kelley describió las contribuciones asistidas por IA como «invariablemente basura». «La gente nos está enviando contribuciones que no tienen ningún valor», dijo. «Tienen valor negativo, porque nos quitan tiempo de revisión al equipo».

El cuello de botella es humano: el código lo revisan un puñado de miembros del equipo central y, al momento de la grabación, Zig tenía 200 pull requests abiertos. Kelley llamó «drive-by contributors» a quienes mandan uno o dos parches y nunca se suman al equipo, y defendió la regla por su simplicidad: «Si digo que ninguna en absoluto, es una política muy fácil de aplicar».

También hay un argumento de misión. Zig no tiene un mandato de eficiencia máxima como las grandes tecnológicas; la mentoría es parte de su propósito, y una contribución generada por IA no entrena a nadie. Business Insider recuerda además que Zig fue el lenguaje con el que se construyó Bun, adquirido después por Anthropic, y que el veto a la IA generó roces entre ambos proyectos.

La ola: por qué las comunidades open source están poniendo reglas

MicroZig no está sola. El 24 de octubre de 2026 entró en vigor la prohibición de r/opensource, una comunidad de más de 500.000 miembros, que veta los proyectos hechos con IA, por IA o destinados a la IA, según reportó YourStory. La moderadora Wolvereness lo justificó así: «La IA, tal como existe hoy, es incongruente con esta comunidad open source».

La política de Reddit sumó requisitos que van más allá de la IA: proyectos con al menos un año de vida, mantenimiento activo, tres o más contribuyentes y licencia aprobada por la Open Source Initiative, según TechRepublic. El resultado fue una revuelta: se crearon comunidades alternativas como r/TrueOpenSource y r/OpenSourceAIAllowed, y un desarrollador contó que un proyecto que mantuvo solo durante nueve años y con más de 300 estrellas en GitHub quedaría fuera aunque no tuviera nada de IA.

La dificultad de fondo es de verificación. «No hay una forma ‘objetiva’ de implementar esta política», admitió Wolvereness. The Verge señaló un caso incómodo: el kernel de Linux ya contiene algo de código generado por IA, así que cualquier proyecto que lo use podría quedar alcanzado por una regla escrita a la ligera.

¿Cómo se aplica una regla así?

MicroZig resuelve el problema de la verificación de una forma que conviene estudiar: no lo resuelve. En lugar de auditar cada aporte, prohíbe la categoría completa y traslada la responsabilidad al contribuyente. Es la misma lógica que describió Kelley: una regla binaria es más barata de aplicar que un estándar de calidad caso por caso.

El documento también define el canal de aplicación: los reportes van a Matthew Knight y Felix Queißner, y el alcance se extiende al acoso privado. Si una persona hostiga a otra, puede ser bloqueada incluso si el hostigamiento ocurrió fuera de GitHub o Discord.

Hay un detalle de gobernanza que vale la pena leer dos veces: discutir públicamente el código de conducta está listado como comportamiento inaceptable. Las objeciones se canalizan por correo directo, no en el issue tracker. Es un modelo de reglas claras y meta-discusión cero que reduce el ruido, pero también concentra el poder de interpretación en quien mantiene el proyecto.

¿Qué significa esto para tu startup?

Tres frentes concretos.

1. Audita las políticas de los proyectos de los que dependes. Si tu producto corre sobre un framework con veto total a la IA, tu equipo no puede mandar un parche upstream generado o editado con asistencia. Eso no rompe nada hoy, pero sí cambia tu estrategia: o mantienes un fork interno, o aceptas que tus correcciones se queden en casa. Revisa el CODE_OF_CONDUCT.md y el CONTRIBUTING.md de tus cinco dependencias críticas antes de tu próximo sprint de mantenimiento.

2. Define tu propia regla antes del primer pull request. Si mantienes un proyecto open source, la ambigüedad es tu peor enemigo: un contribuyente que no sabe si su PR será rechazado por venir de un chatbot simplemente no vuelve. Elige una postura —prohibición total, prohibición con declaración obligatoria, o permiso con revisión— y escríbela en el repositorio. Si eliges el punto medio, necesitas un mecanismo: una línea en la plantilla de PR donde se declare el uso de IA y un muestreo en revisión.

3. Separa la política interna de la externa. Nada impide que tu equipo use IA para escribir tests, documentación interna o refactors locales. Lo que cambia es el flujo hacia afuera. Documenta esa distinción en tu guía de ingeniería: qué herramientas están permitidas en código propietario y qué reglas aplican cuando el destino es un repositorio de terceros.

Conclusión

MicroZig eligió el camino más simple y el más costoso a la vez: vetar la IA por completo en un espacio pequeño, técnico y con recursos de revisión limitados. No es una postura contra la tecnología, sino una decisión sobre dónde se gasta el tiempo escaso de un equipo voluntario. Para los founders, la lección no es copiar la regla, sino entender el mecanismo: cuando el cuello de botella es la revisión, la política de contribución es una decisión de producto, no de estilo.