Simon Willison encontró que la app de escritorio de ChatGPT/Codex incluye una copia completa de LibreOffice adentro del bundle. Lo publicó en su blog y la discusión llegó rápido a la portada de Hacker News, con más de 400 puntos y casi 200 comentarios. No hay bug ni filtración: es una decisión de empaquetado que quedó a la vista de cualquiera que abriera el paquete.
Por qué importa
La lectura fácil es "qué gordas están las apps de Electron". Me parece la lectura equivocada. Lo que muestra el hallazgo es que un cliente de IA de escritorio dejó de ser una interfaz de chat y pasó a ser un entorno de ejecución. Si el agente tiene que abrir un .docx, convertir un .xlsx o renderizar un .pptx a PDF, alguien tiene que hacer ese trabajo, y ese alguien es una suite ofimática real corriendo localmente.
La señal, entonces, es de arquitectura: las capacidades del agente se están moviendo del servidor a la máquina del usuario. Es coherente con lo que pasa alrededor. El mismo día, Sonos anunció Sonos 27, con una capa llamada Sonos 27mcp para conectar asistentes externos a los parlantes, y Google lanzó Pics, que se integra dentro de Docs y Slides en vez de vivir como app aislada. Tres movimientos distintos, la misma dirección: el modelo solo no alcanza, lo que se disputa es el acceso a las herramientas que ya usás.
Y cuando el acceso a herramientas se resuelve empaquetando binarios de terceros, el problema deja de ser de producto y pasa a ser tuyo, el de quien mantiene la distribución.
Qué cambia en la práctica
Si estás construyendo cualquier cosa que ejecute acciones en la máquina del usuario, este hallazgo te da tres tareas concretas.
Primero: auditá tu propio bundle. No des por sentado que sabés qué hay adentro. Es literalmente un comando:
du -sh /Applications/TuApp.app
du -sh /Applications/TuApp.app/Contents/Resources/* | sort -h | tail -20El segundo comando ordena por tamaño y te muestra los veinte pesos pesados. Si aparece algo que no sabías que estaba ahí, ese es tu punto de partida. En un proyecto en el que trabajé, el ganador era un runtime de Python completo que había entrado como dependencia transitiva de una librería de conversión de imágenes.
Segundo: decidí explícitamente entre empaquetar, depender o delegar. Son tres estrategias con costos distintos y conviene elegir a conciencia, no por default del bundler.
| Estrategia | Peso del instalador | Determinismo | Superficie a mantener |
|---|---|---|---|
| Empaquetar el binario | Alto | Total: misma versión para todos | Toda: parches y licencias son tuyos |
| Usar lo que ya está instalado | Bajo | Bajo: depende de la máquina | Mínima, pero soporte impredecible |
| Delegar al servidor | Mínimo | Alto | Infraestructura y datos que salen del equipo |
OpenAI eligió la primera. Tiene sentido para un producto masivo donde el soporte de "me falla la conversión" cuesta más caro que unos cientos de megas de descarga. Para un producto interno con diez usuarios, probablemente no.
Tercero: revisá licencias. Redistribuir software de terceros arrastra obligaciones. No voy a afirmar cuáles aplican en este caso puntual porque el material que tengo no las detalla, y no es un tema para improvisar. Pero si tu build mete binarios ajenos adentro del instalador, alguien de tu equipo tiene que haber leído esas licencias antes del release, no después del mail del abogado.
Cuándo NO usarlo
Empaquetar una suite completa para resolver conversión de archivos es una decisión razonable en pocos contextos y mala en varios otros.
- Cuando el instalador es parte de la experiencia. Si distribuís a usuarios con conexión pobre o a través de MDM corporativo, cada cien megas extra son fricción real de adopción. En Argentina esto no es teórico.
- Cuando solo necesitás una fracción de la funcionalidad. Si tu caso es "convertir docx a texto plano", meter una suite ofimática entera es traer una fábrica para clavar un clavo. Hay parsers específicos, mucho más chicos, con menos superficie de ataque.
- Cuando no podés sostener el ciclo de parches. Empaquetar un binario grande te convierte en su distribuidor: cada CVE del upstream es un release tuyo. Si tu equipo no tiene un proceso para eso, estás acumulando deuda de seguridad que no ves hasta que explota.
- Cuando el entorno del usuario ya lo tiene. En una flota corporativa estandarizada, depender de lo instalado es más barato y más honesto.
Hay un tradeoff más, menos técnico. WIRED en Español recogió estudios que advierten sobre el efecto homogeneizador de la IA en lenguaje y creatividad. Traducido al plano de la arquitectura: si todos copiamos el mismo patrón de "empaquetá todo por las dudas" porque es lo que hace el líder del mercado, terminamos con un ecosistema de apps de un giga que nadie decidió, solo imitó. La decisión de OpenAI está justificada por su escala. La tuya, casi seguro, no tiene esa escala.
Qué haría hoy
Correría el du -sh sobre mi propio bundle antes de opinar del ajeno. Después armaría una tarea de CI que falle si el instalador crece más de un umbral fijado por el equipo, para que el peso sea una decisión consciente y no un descubrimiento de Hacker News. Y si necesito conversión de documentos, empezaría por la librería más chica que resuelva mi caso puntual, midiendo antes de escalar a algo más grande.
El hallazgo de Willison no es un escándalo. Es un recordatorio de que los clientes de IA cargan cada vez más máquina adentro, y que esa máquina la mantiene alguien.