Claude Code Te Permite Programar Desde Tu Teléfono. Esto Es Lo Que Aprendí Por Las Malas.
Iba en un taxi camino a la playa cuando llegó el email de Vercel.
Producción caída. Deploy fallido.
Me quedé mirando el teléfono un segundo. Entonces recordé: Claude Code ahora tiene versión web. Funciona desde móvil. Llevaba tiempo queriendo probarlo.
Así que hice lo más sensato. Abrí Claude Code web, describí el error, y vi cómo un agente de IA arreglaba mi sistema de producción mientras literalmente iba camino a nadar.
Tres minutos después: fix listo, branch pusheado, PR preparado.
Lo mergeé desde GitHub mobile.
Viva la Vida. 😎
Luego guardé el teléfono y me fui a la playa. Porque eso es lo que haces cuando una IA maneja tu infraestructura.
Diez minutos después, Vercel envió otro email.
TL;DR: Sí, Claude Code Web te permite arreglar producción desde el móvil. Sí, lo probé desde un taxi. Sí, "funcionó." El resto de este artículo es lo que pasó después.
Esto es lo que NO hice antes de mergear: ejecutar git diff. O npm run build. O literalmente cualquier cosa que hubiera tomado treinta segundos y me habría ahorrado cuarenta minutos.
En mi defensa, estaba en un taxi. Y el fix se veía razonable. Tres archivos modificados, un mensaje de commit limpio. Qué podría salir mal.
(Todo. Todo podría salir mal.)
El Container No Vive en Tu Proyecto
Déjame explicar qué está haciendo realmente Claude Code web cuando toma una tarea, porque las demos lo hacen ver como magia y no lo es (es algo más interesante y más limitado a la vez).
Cuando envías una tarea, Claude Code web levanta un container aislado en la nube, clona tu repositorio ahí, y se pone a trabajar. Lo que tiene: tu código. Lo que no tiene: tu archivo .env, tus paquetes locales, tu versión específica del framework, tu configuración de deployment, y cualquier contexto de commits que pasaron antes de que apareciera.
Lee tus archivos. Ejecuta comandos. Observa los errores que producen esos comandos. Luego arregla lo que ve.
El desajuste es tan sutil que es fácil pasarlo por alto. La IA no está equivocada (está diagnosticando desde un entorno diferente al que donde tu código realmente corre). Sus fixes son coherentes. Solo que son coherentes con un contexto que no coincide con el tuyo.
Piénsalo como enviar una foto de tu bici rota a un mecánico por WhatsApp. La mira, dice "es la cadena." Cambias la cadena. La bici sigue sin funcionar. El problema real era el cable del freno (no visible en la foto). ¿Era incompetente el mecánico? No. Trabajó con lo que podía ver. El resto era invisible para él.
Claude Code web es el mecánico. Tu repo sin contexto de entorno es la foto. Tu bug real de producción es el cable del freno.
En mi caso, esto se desarrolló con precisión impresionante.
Un Tour por Mis Fixes Fantasma
Esto es lo que el sandbox documentó en su propia sesión, y esto es lo que realmente estaba pasando:
Fix #1: El cambio de paquete de fuentes.
El sandbox notó: "El problema de deployment más probable es que el fetch de Google Fonts falle durante el build de Turbopack. Cambiar a un paquete local evita requests de red durante el build."
Completamente lógico. En un container aislado con acceso de red saliente restringido, hacer fetch de fuentes desde un CDN externo en tiempo de build falla. Así que cambió a una alternativa local. Inteligente.
En mi entorno real de producción, el import original funciona perfectamente y ha funcionado por meses. El sandbox arregló un problema que nunca he tenido, usando una dependencia que nunca había instalado. Genial. Gracias.
Fix #2: La URL placeholder.
Variable de entorno faltante en el container → cliente crasheó en build time → solución: agregar un fallback a una URL muerta en la nube para que el build no se rompa.
En producción, la variable real existe. Así que el fallback no haría nada silenciosamente, a menos que la variable desaparezca (momento en el que la app se conectaría silenciosamente a la nada en lugar de crashear ruidosamente).
Perfecto. Un fix que funciona correctamente en un entorno que no existe, y se degrada silenciosamente en uno que sí existe.
Fix #3: La inicialización lazy.
Este sí estaba correcto. Instanciar un cliente al cargar el módulo causa problemas reales con el prerendering estático, independientemente de las env vars. El refactor a inicialización lazy es genuinamente mejor práctica.
Uno de tres. Me lo quedo.
Ninguno de los tres tocó la razón real por la que mi deployment estaba fallando.
El Bug Real (Era un Ícono)
Unos commits antes de todo esto, había agregado un favicon personalizado. Un archivo pequeño, metido en un directorio donde el framework estaba corriendo. Lo que no sabía: en mi versión del framework, poner un archivo con ese patrón específico de naming en ese directorio hace que se trate como un route handler, no como un asset estático. El build había estado silenciosamente roto desde ese commit.
El sandbox nunca lo mencionó. Por qué lo haría (los errores en sus logs de build eran el fetch de fuente y la env var faltante). El problema del ícono estaba produciendo un tipo diferente de falla, una que solo aparece en un entorno específico de build. Invisible desde el container.
Cuando finalmente me senté en mi laptop y ejecuté un build local, el output apuntó directamente al archivo del ícono. Treinta segundos para identificar. Cinco minutos para arreglar.
Ese fix no está en el branch del sandbox. No podría estar. El sandbox no tenía idea de que existía.
Así que recapitulando: mergeé un branch que agregó una dependencia que no necesitaba, introdujo un modo de falla silencioso, y refactorizó correctamente una cosa (mientras la causa real de mi caída de producción se quedó intacta, esperando a que abriera mi laptop como un adulto).
El Revert (Sí, Tuve que Revertir el Fix)
El paquete de fuentes local no estaba en mis dependencias originales. El sandbox lo había agregado. Así que después de mergear, ejecutar un build local produjo una falla completamente nueva: paquete listado como dependencia, pero no instalado realmente.
Saqué el archivo de layout original del historial de git. Quité el paquete nuevo. Reinstalé. Reverté la URL placeholder de vuelta a un crash duro con env var faltante (porque si esa variable desaparece en producción, quiero una explosión ruidosa, no una conexión educada a la nada).
Me quedé con la inicialización lazy. Esa se ganó su lugar.
Commit. Push. Deployment limpio.
Tiempo total transcurrido entre "laptop se queda cerrada" y "laptop se cierra otra vez": cuarenta minutos. La playa estuvo bien. El debugging no.
Tres Reglas que Sí Funcionan
Trata cada branch de sandbox como código de alguien que nunca ha ejecutado tu proyecto.
No porque la IA sea mala en su trabajo. Porque literalmente no ha ejecutado tu proyecto (ha ejecutado una reconstrucción de él, sin las partes que viven fuera de tu repositorio). Revisa el diff. git diff main..origin/branch-name son quince segundos. Si ves un paquete nuevo, una URL de fallback, una dependencia que no pusiste ahí (el sandbox estaba compensando por algo que no tenía). Averigua si ese algo es real antes de que se envíe.
Ejecuta un build localmente antes de mergear cualquier cosa cerca de la config de build.
npm run build. O lo que sea que te acerque a tu entorno real de deploy. Este solo paso habría terminado toda mi aventura antes de que empezara. El fix fantasma de fuentes habría fallado inmediatamente (paquete no instalado). Treinta segundos de output de terminal vencen a cuarenta minutos de arqueología post-merge.
Los tres minutos que esto agrega a tu workflow no son el cuello de botella. Lo sabes. Admítelo.
Dale al sandbox tu entorno antes de pasarle una tarea.
La pantalla de creación de tareas de Claude Code web tiene un campo de variables de entorno. Pega tus env vars reales ahí. El container ahora corre con algo que se parece a tu contexto real. La mayoría de fixes fantasma desaparecen. El agente deja de resolver problemas que no tienes y empieza a resolver el que realmente tienes.
La Versión Honesta del Sueño
Hablemos de la fantasía de "codear desde cualquier lado" por un segundo.
Nadie realmente quiere debuggear una falla de producción en una playa. Eso no es un sueño, es un castigo. Entrecerrar los ojos en una pantalla de teléfono bajo sol directo, arena en tu teclado, tratando de entender un stack trace. Eso es una pesadilla con buena iluminación.
El sueño real es diferente. Poder encolar algo y alejarse. Empezar un refactor, dejarlo corriendo, volver a un resultado. Esa parte funciona. Claude Code web maneja tareas autocontenidas limpiamente (cualquier cosa donde clonar el repositorio le da al agente todo lo que necesita). Escribir tests. Limpiar un componente. Actualizar documentación. Renombrar cosas. Tareas que viven enteramente en el código, sin env vars requeridas, sin peculiaridades del entorno de build.
El workflow taxi-a-playa se rompe específicamente cuando el problema es ambiental. Lo cual, resulta, las fallas de deployment de producción a menudo son.
Encola la tarea. Ve a la playa. Vuelve y revisa el diff en tu laptop como un profesional.
Ese es el sueño real. El resto es un tweet esperando a pasar. 😬
Mismo principio subyacente que vibe coding sin restricciones: una IA trabaja coherentemente dentro de cualquier contexto que tenga. Dale uno incompleto, y obtienes soluciones coherentes al problema equivocado. Env vars en el sandbox, build local antes del merge, git diff antes de aprobar (el mismo movimiento cada vez). No estás peleando con la IA. Le estás dando tu realidad en lugar de una fotocopia.
En seis meses, alguna devtool enviará "sincronización inteligente de contexto de sandbox" como feature premium. Habrá lista de espera. El email de onboarding dirá "codea desde cualquier lado."
Los desarrolladores que ya ejecutan un build local antes de mergear no lo necesitarán.
Ya saben lo que el container no puede ver.
Ya fueron a la playa. Sin su laptop. A propósito.
Ese es el futuro real del dev.
Recursos: Documentación de Claude Code — Guía de sandboxing de Anthropic
Escribo sobre construir sistemas de producción con herramientas de IA (las partes que no llegan a los threads de lanzamiento). Sin horario, sin relleno. Sale cuando hay algo que vale la pena decir.
(*)La portada es generada por IA. Podría haber ido a la playa en lugar de promptearla. En retrospectiva, habría sido la decisión más inteligente.
Cuando la IA 'arregla' tu código desde un sandbox, no todo es lo que parece. Cada semana, compartimos lecciones reales de infraestructura y producción con agentes de IA.