Darling, macOS en Linux, apuesta por IA y ARM64

Darling adopta una política de IA para sus contribuciones

El proyecto Darling, que permite ejecutar aplicaciones de macOS sobre Linux, confirmó en su actualización de desarrollo del cuarto trimestre que adoptó reglas formales para las contribuciones asistidas por IA. El equipo lo presenta como el cambio más importante del año, y no es una feature: es una política.

El propio blog reconoce que el tema «es divisivo» y que la preocupación por el código de baja calidad —el llamado slop— «es justa». Pero su conclusión es la opuesta a la de muchos maintainers: sostiene que, en manos de personas que conocen los internos del proyecto, un LLM es una herramienta muy poderosa.

Para cualquier founder que use open source como cantera de talento, de código o de validación técnica, el caso de Darling funciona como laboratorio: muestra cómo se gobierna la IA dentro de un equipo pequeño que compite contra un gigante.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Por qué Darling cambió de postura con la IA?

La respuesta está en la aritmética. El proyecto arrancó en 2012 y, según su propio relato, hasta hace poco casi ninguna aplicación real de macOS corría sobre él. La comparación con Wine —el proyecto equivalente para aplicaciones de Windows— explica el problema: Wine cuenta con el respaldo comercial de Valve y puede apoyarse en los runtimes redistribuibles de Microsoft, que herramientas como winetricks descargan por el usuario.

Darling no tiene nada de eso. Para la mayoría de los frameworks de Apple no hay nada que descargar: hay que implementarlos a mano. Y la escala es brutal. Según el conteo que cita el blog, macOS 27 incluye 464 frameworks públicos y 2.754 privados, contra 273 y 878 en macOS 10.14.

Con ese panorama, igualar la capacidad de ingeniería de Apple parecía un problema sin solución para un puñado de voluntarios. Lo que cambió fueron los forks: varios proyectos derivados que usan IA de forma intensiva lograron resultados que el proyecto original no alcanzaba. El ejemplo más visible que menciona el blog es un fork que corre League of Legends; VibeDarling consiguió que funcionaran varias aplicaciones originales de macOS.

El equipo es explícito sobre la alternativa: no usar IA habría significado volverse insignificante mientras los forks avanzaban a otra velocidad, y probablemente fragmentar la comunidad. Es la misma tensión que vive cualquier startup cuando una tecnología nueva reordena las reglas de su categoría: adoptarla antes de dominarla, o quedar fuera del mercado que estabas construyendo.

Cómo se ve una política de IA bien escrita en la práctica

La política de Darling está redactada como instrucciones para agentes de IA, pero ata a las personas que los operan. Los puntos centrales:

Quien abre un pull request responde por cada línea y debe poder explicarla con sus propias palabras.
Las preguntas de los maintainers las contestan personas, no un bot.
Reglas de clean-room: implementar el contrato documentado en vez de parches para una sola aplicación, respetar el layering de macOS, aislar y etiquetar los comportamientos no documentados.
Nunca usar material filtrado ni código restringido de Apple, como corecrypto.
Nadie debe usar desensamblado para producir código equivalente. Documentar el comportamiento mediante desensamblado y reimplementarlo en limpio puede ser aceptable según la ley local: el agente que escribe el código nunca ve el desensamblado, solo una descripción de comportamiento producida en otro contexto.

Ese último punto es el más citable para cualquier equipo que use IA en un producto con riesgo legal. Separa dos actividades que suelen confundirse: entender y escribir. Si el mismo modelo que lee el artefacto protegido es el que genera el código, el riesgo es alto; si el conocimiento se lava en una descripción intermedia revisada por un humano, el riesgo baja.

ARM64: el otro anuncio de peso

Darling sumó soporte inicial para ARM64, la arquitectura de todos los Mac desde la transición al silicio propio de Apple. Sin ese soporte, el proyecto quedaría atado a una arquitectura que Apple está abandonando, mientras el software que se escribe hoy para macOS apunta primero —o únicamente— a ARM64.

La confianza en esta parte viene de un detalle operativo: VibeDarling se desarrolla sobre ARM64, así que su trabajo diario ejercita esos caminos de código todo el tiempo. Cuando el fork se fusione de vuelta, el equipo espera tener buen soporte desde el arranque.

En el corto plazo, el objetivo es mergear el trabajo de todos los forks usando lógica de fusión manejada por agentes, que ya corrigió bugs, tanto en el código entrante como en errores preexistentes de Darling. La meta es soportar oficialmente tres arquitecturas: i386, x86-64 y ARM64 (aarch64). También hay una línea de trabajo —presentada como long shot: correr aplicaciones ARM64 sobre hosts x86-64 reutilizando Dynarmic.

¿Qué dicen los datos sobre el código generado con IA en open source?

La apuesta de Darling va contra un clima hostil. Una encuesta de la Linux Foundation a 234 contribuidores y maintainers, recogida por Help Net Security en octubre de 2026, estima que cerca de uno de cada cuatro pull requests entrantes es de baja calidad o generado con IA; en proyectos con más de 50 contribuidores, esa cifra sube a un tercio. TechPowerup reporta el mismo dato en 31% para los proyectos grandes.

El detalle contraintuitivo es que los proyectos grandes no diluyen la carga: reportan más slop, crecimiento más rápido de envíos y más quejas por demoras en las revisiones. En los grandes, la preocupación número uno de los maintainers dejó de ser el código y pasó a ser el burnout.

La gobernanza va atrás de la adopción. Solo 35% de los proyectos tiene una política formal que permite usar IA generativa, 32% no tiene ninguna y no planea tenerla, y alrededor de uno de cada diez la prohíbe. Del lado de los contribuidores, 61% revisa línea por línea y testea antes de enviar, pero uno de cada cinco nunca declara que usó IA. El kernel de Linux ya pide una línea Assisted-by: en el mensaje de commit, con el nombre de la herramienta y el modelo.

Hay una señal alentadora: el proyecto curl. Su líder, Daniel Stenberg, describió en 2025 que curl estaba desbordado por reportes de seguridad generados con IA; para abril de 2026 afirmó que dejó de recibirlos y que ahora recibe reportes de seguridad muy buenos, casi todos hechos con ayuda de IA.

Qué significa esto para tu startup

1. Escribe tu política de IA antes de que te la pida un cliente o un inversor. El dato de que solo 35% de los proyectos open source tiene una política formal se repite en las empresas: casi nadie la escribió hasta que hubo un incidente. Una política útil define quién responde por el código generado, exige que la persona pueda explicarlo y prohíbe usar material de terceros sin licencia clara. El modelo de Darling —responsabilidad humana por cada línea— es un punto de partida razonable y verificable.

2. Trata la revisión de código como el cuello de botella real, no la escritura. Si la encuesta de la Linux Foundation muestra que la IA puede reducir a la mitad el tiempo de escritura, el trabajo se mueve al otro lado: revisar. Tres de cada cuatro maintainers ya usan IA para resumir cambios y buscar bugs de lógica. Asigna tiempo y presupuesto explícito a esa revisión, y mide el tiempo de revisión como métrica de equipo, no solo el volumen de PRs mergeados.

3. Distingue comprender de reimplementar. Si tu producto convive con software propietario —APIs cerradas, protocolos no documentados, compatibilidad con plataformas de terceros—, la separación que hace Darling entre un agente que documenta y otro que escribe código reduce riesgo legal y además deja documentación útil para el equipo.

Conclusión

Darling tomó una decisión incómoda y la documentó: adoptó IA porque la alternativa era volverse irrelevante frente a sus propios forks. El proyecto no oculta el riesgo de calidad; lo gestiona con reglas verificables, responsabilidad humana por cada línea y una separación explícita entre entender y reimplementar. Sumó además soporte ARM64, que lo alinea con la arquitectura hacia la que Apple ya migró.

La lección para un founder no es «usa IA» ni «ten cuidado con la IA». Es que la ventaja competitiva dejó de estar en escribir más código y se movió a decidir qué se acepta, quién responde por ello y cuánto tiempo humano cuesta verificarlo.