El Gráfico de Crecimiento que Nadie te Muestra

Preludio

Conoces esos gráficos de crecimiento exponencial. Los que abren cada pitch deck, cada keynote, cada publicación entusiasta sobre cómo la IA va a cambiar el mundo. Ingresos subiendo. Usuarios subiendo. Adopción por las nubes. Palo de hockey. Hasta la luna.

Aquí está mi gráfico de crecimiento exponencial.

Esa es la cola de issues de GitHub de Claude Code. 31.995 issues registrados hasta la fecha. 6.093 actualmente abiertos. Cien nuevos issues registrados antes del desayuno esta mañana. Crecimiento de 30x interanual.

Esto no es una métrica de fracaso. Esto es lo que parece cuando la herramienta de programación con IA más capaz jamás construida se despliega más rápido de lo que su ecosistema puede estabilizarse. Este es el gráfico que te dice cómo es realmente el desarrollo con IA en 2026. No desde el escenario. Desde las trincheras.

Yo construyo EntendIA, una plataforma para la gobernanza de IA y la gestión de plugins. Nuestro panel de control ingiere datos de Claude a través de HTTP hooks. Simples webhooks. El tipo de integración que ha funcionado de forma fiable desde los primeros días de la web. Envías un payload JSON a una URL con POST. Recibes un 200. Hecho.

No funciona. O mejor dicho, funciona en algunas superficies, en algunos sistemas operativos, parte del tiempo. El resto del tiempo, falla silenciosamente, falla ruidosamente, o falla de maneras que requieren construir herramientas de depuración completamente nuevas solo para entender el fallo.

Esta es una historia sobre cinco problemas específicos, profundamente técnicos, que surgen cuando intentas construir un producto que funcione en todas las superficies de Claude. Cada uno está documentado, es reproducible y está respaldado por issues reales en esa cola exponencial.

El Problema

Claude ahora se distribuye en cinco superficies distintas. Claude Code es la herramienta de línea de comandos. Claude Desktop es la aplicación Electron. Claude Cowork ejecuta tareas dentro de una VM con sandbox. Claude Chat vive en el navegador en claude.ai. Y todos estos se comportan de manera diferente dependiendo de si estás ejecutando Linux, macOS, Windows o WSL.

Si estás construyendo una plataforma que se integra con Claude --no solo usándolo, sino construyendo infraestructura a la que las instancias de Claude de otras personas se conectan-- necesitas que funcione en todas partes. Cada superficie. Cada sistema operativo. Cada configuración.

La promesa de HTTP es que una solicitud POST funciona igual en todas partes. La realidad del ecosistema de IA de 2026 es que la misma solicitud HTTP tiene éxito desde la línea de comandos, falla desde la aplicación de escritorio, hace crash a la VM y es bloqueada por la CDN. Misma URL. Mismo payload. Misma máquina. Resultados diferentes dependiendo de qué capa de abstracción origina tu solicitud.

Estos son los cinco muros contra los que nos chocamos.

El Camino

Dos Marketplaces, Dos Esquemas

Claude Code y Claude Desktop admiten plugins. Ambos tienen marketplaces. Ambos usan un manifiesto marketplace.json para describir los plugins disponibles. No son el mismo esquema.

No es una incompatibilidad sutil. Un plugin que se valida e instala correctamente en Claude Code CLI falla en Claude Desktop, y viceversa. La herramienta CLI acepta type: "http" en las configuraciones de servidores MCP. La aplicación Desktop no lo reconoce. La aplicación Desktop tiene un sistema de gestión de extensiones que la CLI desconoce por completo.

Se pone peor. El propio marketplace oficial de Anthropic distribuye plugins que fallan en la validación en Claude Code. El marketplace.json en claude-plugins-official define campos category y source en cada entrada de plugin. Cuando Claude Code obtiene estos plugins, esos campos de metadatos a nivel de marketplace se filtran al plugin.json cacheado por plugin. El validador de esquemas entonces los rechaza como claves no reconocidas. Plugins del propio marketplace oficial de Anthropic --Figma, Sentry, Vercel, PostHog, Notion-- todos fallan con Unrecognized keys: "category", "source".

La superficie Cowork tiene sus propios problemas distintos. La interfaz LocalPlugins lanza continuamente errores de validación de esquema, haciendo imposible usar plugins personalizados incluso cuando pasan claude plugin validate en la línea de comandos. Un plugin que Claude Code CLI dice que es válido, que se instala correctamente, que funciona perfectamente desde la terminal -- hace crash a Cowork con una redirección silenciosa a la página principal y sin error en la UI.

Luego está la trampa de la actualización automática. Claude Desktop migró silenciosamente de una configuración manual de mcpServers a un sistema de gestión basado en extensiones. Cada usuario que configuró servidores MCP usando el método previamente documentado --editar a mano claude_desktop_config.json, que era el único método documentado-- vio su configuración silenciosamente rota por una actualización. Tanto el servidor antiguo como el nuevo se lanzan simultáneamente, entran en conflicto, y la capa de enrutamiento expone cero herramientas. Sin advertencia. Sin error en la UI. Sin ruta de migración.

Nuestra solución en EntendIA fue dejar de mantener manifiestos estáticos por completo. Construimos un sistema de exportación del lado del servidor que genera dinámicamente marketplace.json bajo demanda, adaptando la salida para manejar las diferencias de esquema a nivel de servidor. Cuando el CLI de Claude Code de un usuario solicita nuestro marketplace, obtiene una forma. Cuando Cowork lo solicita, obtiene otra. Un conjunto de plugins, dos esquemas, generados al vuelo porque las superficies consumidoras no se ponen de acuerdo en cómo es un plugin válido.

Así no funcionan los ecosistemas maduros. En los ecosistemas maduros, publicas un manifiesto una vez y cada consumidor lo lee de la misma manera. En este ecosistema, necesitas negociación de contenido del lado del servidor para los metadatos de tus plugins.

La Pesadilla del TLS

Claude Code está construido sobre Bun. Bun incluye su propia implementación TLS a través de BoringSSL. Este stack TLS incluido no usa el almacén de certificados de tu sistema operativo. No respeta NODE_EXTRA_CA_CERTS. No respeta SSL_CERT_FILE. No respeta NODE_TLS_REJECT_UNAUTHORIZED=0. No respeta nada.

Registré este issue después de que nuestros HTTP hooks empezaron a fallar con unknown certificate verification error en cada evento. Nuestro servidor usa un certificado ECDSA de Let's Encrypt perfectamente estándar -- el intermedio E7, firmado por ISRG Root X1. Todos los navegadores confían en él. Todos los sistemas operativos confían en él. curl confía en él. node confía en él. openssl s_client confía en él. Claude Code no confía en él.

El bundle de CA del sistema en la máquina contiene 146 certificados raíz, incluyendo ISRG Root X1. Nada de eso importa. El stack TLS del binario es una caja sellada. Probé todas las variables de entorno estándar. Probé combinaciones de variables de entorno. Nada penetró el BoringSSL incluido.

La madriguera del conejo se hace más profunda. Otro investigador ejecutó strace en el proceso de Claude Code y descubrió que el cliente HTTP hook establece el TLS SNI incluyendo el número de puerto. El campo Server Name Indication -- la parte del handshake TLS que le dice al servidor qué certificado presentar -- se establece como example.com:443 en lugar de example.com. Esto es un bug en el cliente HTTP de Bun. El SNI malformado rompe el handshake TLS porque ningún servidor espera un puerto en el campo de hostname. El error que llega al usuario es ECONNREFUSED, que es engañoso -- la conexión TCP tiene éxito, el handshake TLS falla, y Bun mapea ese fallo a un error de conexión rechazada.

A modo de comparación, la propia conexión API de Anthropic en el mismo proceso usa SNI api.anthropic.com sin el puerto. Funciona. El cliente de hooks, en el mismo binario, en el mismo proceso, establece el SNI de forma diferente. Uno funciona. El otro no.

La causa raíz se remonta a la función de búsqueda DNS personalizada de Bun. Claude Code usa una función llamada B2L para protección contra SSRF que valida las IPs resueltas contra rangos privados. Pasar esta búsqueda personalizada al cliente HTTP de Bun desencadena bugs en la capa de red de BoringSSL. La corrección upstream se fusionó en Bun el 8 de marzo de 2026. Al momento de escribir esto, Claude Code todavía incluye Bun v1.3.11 sin la corrección.

La historia de mTLS es igualmente sombría. Los certificados de cliente que funcionaban en v2.1.22 se rompieron en v2.1.23. Los entornos corporativos que usan proxies Zscaler no pueden usar WebFetch en absoluto porque el runtime de Bun incluido ignora los certificados CA del proxy. La aplicación Claude Desktop no reenvía NODE_EXTRA_CA_CERTS al subproceso CLI que lanza, creando un modo de fallo diferente en cada superficie.

HTTPS es un problema resuelto. Ha sido un problema resuelto durante más de una década. Incluir tu propia implementación TLS que ignora la cadena de confianza del sistema operativo lo desresolvió.

Cloudflare contra Claude

Cuando tu implementación TLS rechaza los certificados de Let's Encrypt, necesitas una solución alternativa. La solución estándar es hacer proxy de tu tráfico a través de Cloudflare, que termina TLS con sus propios certificados en los que el BoringSSL incluido sí confía.

Esto crea un nuevo problema. Todo el modelo de negocio de Cloudflare se basa en distinguir el tráfico real del tráfico de bots. Claude Code haciendo solicitudes HTTP a tu servidor es, por cualquier definición razonable, tráfico de bot. Cloudflare lo bloquea.

El flujo de login OAuth falla completamente desde entornos VPS en la nube. La solicitud de intercambio de tokens recibe un desafío JavaScript de Cloudflare. La CLI no puede ejecutar desafíos JavaScript. La autenticación falla. La solución sugerida en el issue -- eximir el endpoint de intercambio de tokens de los desafíos de bots -- requiere que controles la configuración de Cloudflare para claude.ai, lo cual solo Anthropic puede hacer.

En Windows, Claude Desktop entra en un bucle de redirección infinito cuando encuentra un desafío Cloudflare Turnstile. El webview de Electron no puede resolver el desafío. La aplicación dispara errores Cloudflare challenge detected, redirecting... treinta veces por segundo. Se activa la advertencia de fuga de memoria del EventEmitter. La aplicación se vuelve completamente inutilizable. Claude.ai funciona perfectamente en un navegador normal en la misma máquina.

Incluso el propio producto de Cloudflare entra en conflicto con Claude Code. Ejecutar Cloudflare Warp -- el producto VPN de Cloudflare -- junto con Claude Code produce errores Unable to connect to API due to poor internet connection. Desactivar Warp lo soluciona inmediatamente.

El flujo de autenticación MCP queda atrapado en medio. Los servidores HTTP MCP que requieren OAuth fallan silenciosamente. El handshake initialize tiene éxito sin autenticación. El servidor anuncia sus capacidades de herramientas. Entonces tools/list devuelve Unauthorized. Claude Code se traga este error por completo. Sin notificación. Sin solicitud de autenticación. Sin indicación de que el servidor existe o necesita atención. El usuario tiene que descubrir independientemente el comando /mcp y activar manualmente el flujo OAuth.

Así que aquí está la cadena: tu servidor necesita HTTPS. El TLS incluido de Claude Code rechaza tu certificado de Let's Encrypt. Haces proxy a través de Cloudflare. Cloudflare bloquea a Claude Code como bot. Configuras Cloudflare para permitirlo. Ahora el flujo OAuth de MCP se rompe porque la redirección de autenticación pasa por Cloudflare, que desafía al cliente automatizado. Cada solución crea el siguiente problema.

La VM que no Reinicia

Claude Cowork ejecuta código dentro de una máquina virtual Hyper-V. La idea es correcta -- aislar la ejecución de código no confiable en un entorno sandbox. La implementación en Windows es catastrófica.

Las VMs arrancan correctamente pero hacen crash en cinco minutos. El registro de eventos de Hyper-V confirma que la VM se inicializa, se conecta a la red virtual, funciona durante aproximadamente cinco minutos, y luego se apaga. Todos los intentos posteriores de reiniciar el servicio fallan. Borrar los directorios de la VM, reiniciar los servicios de Hyper-V, reinicios completos del sistema -- nada lo recupera.

La capa de montaje del sistema de archivos es el punto de fallo principal. El sandbox-helper falla al desmontar los recursos compartidos del host usando tanto virtiofs como protocolos Plan9 con invalid argument. Esto corrompe el flujo de salida JSON -- la salida de depuración del sandbox helper contamina stdout, que Claude Code analiza como JSON, lo cual falla. Después del primer fallo, el servicio de VM no arranca en absoluto. El error dice VM service not running. The service failed to start. El ciclo se repite indefinidamente.

Los fallos de montaje virtiofs producen RPC error -1: Plan9 mount failed: bad address. Son intermitentes, desencadenados por condiciones ambientales en lugar de acciones específicas del usuario. La propia descarga de la VM falla con EXDEV: cross-device link not permitted al intentar renombrar archivos de imagen de VM -- una operación básica del sistema de archivos que nunca debería fallar en un disco local.

Los usuarios reportan espacios de trabajo que quedan permanentemente inutilizados después del uso normal. Una tarea de automatización de Chrome se ejecuta, el workspace se corrompe y no existe ninguna ruta de recuperación. Limpiar la caché no hace nada. Borrar el bundle de la VM y reinstalar no hace nada. La instalación nueva falla con el mismo error VM service not running. La única opción es reinstalar Claude Desktop completamente.

Quizás el issue más revelador es que Claude Desktop lanza una VM Hyper-V de 1,8 GB en cada arranque, incluso para uso exclusivo de chat. Un usuario encontró 2.689 archivos de sesión obsoletos de sesiones anteriores de Cowork que nunca se limpiaron, siguiendo convenciones de nomenclatura al estilo Docker como nifty-dreamy-volta y tender-vigilant-goodall. En un portátil de 16 GB, la VM consume el 11% de la memoria total antes de que el usuario haya escrito un solo mensaje.

Algunas máquinas reportan Virtualization is not enabled a pesar de que Hyper-V está completamente habilitado y confirmado como funcional. El sandbox ignora sandbox.enabled: false en la configuración, lo que significa que no puedes desactivarlo incluso cuando sabes que va a fallar.

El patrón en todos estos issues es el mismo: la VM se rompe, no hay ruta de recuperación excepto una reinstalación completa, y los mensajes de error no son accionables. VM service not running no te dice nada. Plan9 mount failed: bad address no te dice nada. La información de diagnóstico que ayudaría -- registros de eventos de Hyper-V, estado de montaje virtiofs, salida del sandbox-helper -- está enterrada en logs del sistema que la mayoría de los usuarios no saben cómo acceder.

La Matriz de Fragmentación

Cada superficie de Claude se comporta de manera diferente en cada plataforma. Esto no es una exageración. Aquí hay una matriz parcial de lo que funciona y lo que no, a fecha de 12 de marzo de 2026:

Esta mañana, pasamos dos horas depurando por qué los HTTP hooks funcionan desde WSL pero fallan con ECONNREFUSED en Claude Desktop de Windows. Misma máquina. Misma red. Mismo endpoint. Mismo plugin. 56 hooks registrados en 5 plugins. Todos disparándose correctamente. Cada POST fallando en Windows.

Los hooks están registrados. Coinciden. Se disparan. El servidor está sano -- curl y node desde la misma máquina devuelven HTTP 401 (esperado sin credenciales). El servidor nunca ve una solicitud de Claude Desktop.

Lo rastreamos a través de múltiples capas. La aplicación Claude Desktop está instalada desde la Microsoft Store como un paquete MSIX. Las aplicaciones MSIX se ejecutan dentro de un sandbox AppContainer. El paquete declara la capacidad internetClient pero no internetClientServer. Claude Code CLI se lanza como un proceso hijo de la aplicación Desktop empaquetada como MSIX. El hijo hereda las restricciones del sandbox AppContainer.

El descubrimiento crítico: el sandbox de red del AppContainer MSIX bloquea el cliente HTTP en proceso que dispara los hooks, pero los procesos hijo generados como bash y node no se ven afectados. Lo probamos ejecutando exactamente la misma solicitud HTTPS desde un proceso node generado por Claude Code -- tuvo éxito con HTTP 401. El cliente de hooks en proceso, en la misma instancia de Claude Code, obtuvo ECONNREFUSED.

WSL funciona porque se ejecuta en su propio namespace de red con un adaptador virtual, completamente fuera del sandbox AppContainer MSIX. La CLI lanzada directamente desde una terminal funciona porque no es hija de la aplicación MSIX. Solo la combinación específica de Claude Desktop (edición Store) generando Claude Code como subproceso desencadena el fallo.

Este es el tipo de bug del que ninguna documentación te advierte. Requiere entender el empaquetado MSIX de Windows, el aislamiento de red AppContainer, la red virtual Hyper-V, el TLS incluido de Bun y la arquitectura de despacho de hooks de Claude Code. Requiere habilidades de depuración en cinco stacks tecnológicos diferentes simultáneamente. Y afecta a todos los que instalan Claude Desktop desde la Microsoft Store e intentan usar HTTP hooks -- que es el caso de uso principal para la integración de plataformas.

El Bucle Recursivo

Aquí está la parte que debería hacerte reír, o posiblemente llorar.

Construimos EntendIA. Nuestra plataforma distribuye plugins a través del marketplace de Claude Code. Uno de nuestros plugins se llama "Debugging claude on windows". Contiene cuatro skills: debug-claude-hooks, debug-cowork-vm, debug-mcp-connections y claude-windows-file-locations.

Construimos un plugin de marketplace, distribuido a través del sistema de marketplace que tiene bugs de validación de esquemas, usando Claude Code que tiene bugs de TLS, para depurar los hooks de Claude Code que tienen bugs de ECONNREFUSED, ejecutándose en Claude Desktop que tiene bugs de sandbox MSIX, conectándose a un servidor con proxy a través de Cloudflare que tiene bugs de detección de bots.

La herramienta que está rota es la herramienta que usamos para construir las herramientas que diagnostican por qué la herramienta está rota. La plataforma con la que estamos intentando integrarnos es la plataforma que usamos para escribir el código de integración. El marketplace en el que publicamos es el marketplace que no puede instalar consistentemente lo que publicamos.

Esto no es una metáfora. Esta es una captura de pantalla de la sesión de depuración de esta mañana: comandos bash buscando ECONNREFUSED en segundo plano mientras el menú de plugins de Claude Desktop muestra nuestros skills de "Debugging claude on windows" en primer plano. La IA nos está ayudando a depurar la IA. El bucle recursivo es el flujo de trabajo de desarrollo.

Y de alguna manera, a pesar de todo esto, funciona. No de forma fiable. No en todas las superficies. No sin soluciones alternativas. Pero el hecho de que podamos usar Claude Code para construir un plugin de depuración, distribuirlo a través de un marketplace y que ese plugin realmente ayude a diagnosticar los propios bugs de la plataforma -- eso es notable. Es exasperante y notable a partes iguales.

La Lección

La cola de issues no es una métrica de fracaso. Es un indicador de madurez, y lo que indica es que el ecosistema de desarrollo de IA en 2026 está aproximadamente donde estaba el desarrollo web en 2004. Las herramientas son potentes. El ritmo de innovación es asombroso. Y el número de aristas cortantes que te van a cortar crece más rápido de lo que nadie puede limarlas.

232 issues en febrero de 2025. 7.081 en febrero de 2026. Ese crecimiento de 30x no es porque el producto empeoró. Es porque la superficie se expandió. Y no es solo la cola de issues. El propio servicio ha sido inestable. Solo en los primeros doce días de marzo de 2026: una gran caída mundial el 2 de marzo que tumbó todas las superficies orientadas al consumidor con más de 2.000 reportes en Downdetector -- Anthropic citó "demanda sin precedentes". Luego tasas de error elevadas de Haiku 4.5 el 7 de marzo. Luego otra caída el 11 de marzo con más de 1.400 reportes. A finales de febrero, la API de informes de uso devolvió errores y datos de analítica faltantes durante dos días. Una transición de horario de verano causó un bucle infinito en las tareas programadas de Cowork y Claude Code. Timeouts de conexión API por degradación de peering de red upstream. Esto no es una mala semana. Esto es la línea base. Claude pasó de ser una herramienta CLI a una herramienta CLI más una aplicación de escritorio más un entorno de VM con sandbox más una interfaz web más un marketplace de plugins más un protocolo MCP más HTTP hooks. Cada nueva superficie multiplicó la matriz de integración. Cada multiplicación creó nuevos modos de fallo que solo se manifiestan en combinaciones específicas de plataforma, superficie y configuración.

El patrón más profundo es que las herramientas de IA se están distribuyendo sobre stacks tecnológicos que son en sí mismos inmaduros. Bun no es Node.js. Es un runtime más nuevo y más rápido con su propia implementación TLS, su propia resolución DNS, sus propios comportamientos de cliente HTTP. Cuando Claude Code incluye Bun, hereda las aristas de Bun. Cuando Bun incluye BoringSSL, hereda las opiniones de BoringSSL sobre las cadenas de certificados. Cuando el paquete MSIX envuelve la aplicación Electron que genera la CLI basada en Bun que hace la solicitud HTTP que llega al proxy de Cloudflare que desafía al bot que construyó la casa que Jack construyó -- cada capa añade su propio modo de fallo, y ningún equipo entiende todas las capas.

Este es el desafío fundamental de construir sobre el ecosistema de IA hoy. No es que las herramientas sean malas. Claude Code es genuinamente extraordinario. El modelo detrás de él produce código que habría parecido imposible hace dos años. El problema es que la infraestructura alrededor del modelo -- el empaquetado, la red, el sandbox, el marketplace, el sistema de plugins, el flujo de autenticación -- se está construyendo al mismo ritmo que el modelo mejora, lo que significa que se está construyendo demasiado rápido para ser estable.

Para quienes construimos plataformas sobre este ecosistema, las implicaciones prácticas son claras:

Prueba en cada superficie, cada vez. La matriz de fragmentación no es teórica. Una funcionalidad que trabaja en CLI Linux se romperá en Desktop Windows de maneras que no puedes predecir leyendo la documentación.

Construye soluciones del lado del servidor. No confíes en que el cliente se comporte de manera consistente. Genera tus manifiestos de marketplace dinámicamente. Maneja las diferencias de esquema a nivel de servidor. Asume que el cliente te enviará algo inesperado y acertarás la mitad de las veces.

Registra bugs detallados. Los 6.093 issues abiertos no se van a resolver solos. Pero cada informe de bug detallado con pasos de reproducción, salida de strace y análisis de causa raíz hace avanzar el ecosistema. Los investigadores de la comunidad en estos issues -- las personas ejecutando strace en handshakes TLS, las personas diseccionando manifiestos MSIX, las personas construyendo matrices de prueba entre Bun y Node.js -- están haciendo el trabajo que hace que el ecosistema sea eventualmente estable.

Presupuesta para la depuración. Si tu plan de proyecto asume que los webhooks HTTP simplemente funcionarán, que TLS simplemente funcionará, que los plugins se instalarán igual en todas partes -- añade un multiplicador. Pasamos dos horas esta mañana en un solo ECONNREFUSED. Esa es una mañana normal.

Conclusión

El gráfico de crecimiento al principio de este artículo va a seguir creciendo. Marzo de 2026 va camino de superar los 9.000 nuevos issues. Ese número probablemente se duplicará de nuevo antes de que termine el año. Esto no es una crisis. Esto es lo que parece construir en público cuando toda la industria se mueve a velocidad de escape.

Las herramientas de IA que tenemos hoy son genuinamente transformadoras. Escribo esto usando la misma herramienta que pasé la mañana depurando. La ironía no se me escapa. Tampoco la ganancia de productividad. Incluso con cada bug documentado en este artículo, incluso con las pesadillas de TLS y las trampas del sandbox MSIX y los conflictos de esquemas del marketplace, construir con Claude Code es más rápido y más capaz que construir sin él.

Pero la brecha entre lo que estas herramientas pueden hacer y cuán fiablemente lo hacen -- esa brecha es donde ocurre la ingeniería real. No en el prompt. No en el modelo. En la fontanería. En los handshakes TLS y las políticas de AppContainer y los puntos de montaje virtiofs. En la infraestructura aburrida y poco glamurosa que tiene que funcionar perfectamente para que la extraordinaria IA encima de ella cumpla su promesa.

Ese es el gráfico de crecimiento que nadie te muestra. No las capacidades del modelo subiendo. La complejidad de integración subiendo justo al lado. Y hasta que el ecosistema madure lo suficiente para cerrar esa brecha, seguiremos construyendo herramientas de depuración para depurar las herramientas que usamos para construir herramientas de depuración.

Ese es el trabajo. Alguien tiene que hacer la fontanería.