La app de escritorio de Claude Code cambió mi forma de construir software
Hace tres semanas, borré VS Code de mi máquina.
No porque se rompiera. No porque encontrara algo técnicamente superior en el sentido de una lista de funcionalidades. Lo borré porque me di cuenta de que no lo había abierto en catorce días — y cada proyecto que había entregado en ese período había salido de la app de escritorio de Claude Code.
Esa revelación me impactó de una forma que no esperaba. VS Code ha estado en cada máquina que he tenido desde 2018. Mi oficina, mi taller, mi segundo cerebro lleno de extensiones como desarrollador. Y en algún punto entre entregar una app generadora de miniaturas en una tarde y ver a dos agentes de IA rediseñar simultáneamente mi interfaz y optimizar mi API — dejé de necesitarlo.
Esto es lo que hace incómodo admitirlo: yo era escéptico. Muy escéptico. He visto anuncios de "IDE potenciado por IA" circular por la prensa tecnológica durante dos años, y casi todos resultaron ser Copilot con una nueva capa de pintura. Autocompletado disfrazado de colaboración. Así que cuando la app de escritorio de Claude Code salió para Mac y Windows, miré la lista de funcionalidades y pensé — vale, múltiples agentes, vista previa en vivo, ejecución en la nube. Demuéstramelo.
Lo que encontré fue algo estructuralmente diferente. Y esa diferencia estructural vale la pena entenderla antes de simplemente descargarla y empezar a curiosear — porque si te acercas a esta herramienta de la misma forma que te acercas a un IDE tradicional, te perderás lo que realmente la hace funcionar.
Hay un momento específico al que quiero llegar — una revelación sobre el flujo de trabajo que ocurrió alrededor del quinto día de usar esto en serio — que cambió mi forma de pensar sobre la construcción de software. Pero para entender por qué importó, primero necesitas entender la arquitectura de permisos. Suena como un detalle menor de la interfaz. No lo es.
Por qué el sistema de permisos es el punto central
La app de escritorio de Claude Code viene con cuatro modos de permisos. En la superficie parecen un simple control deslizante entre "cauteloso" y "arriesgado". Lo que realmente representan es un marco para calibrar la confianza dinámicamente según lo que está en juego en cada tarea.
Ask Permissions es la línea base. Cada edición de archivo, cada comando de terminal, cada acción requiere tu aprobación explícita antes de ejecutarse. Esto es más lento por diseño — te conviertes en una puerta en el sistema humano-en-el-bucle — pero es invaluable en dos situaciones específicas: cuando estás trabajando en un código base de producción donde una escritura inesperada podría causar daño real, y cuando estás aprendiendo cómo Claude aborda un tipo de problema desconocido. Los avisos de aprobación son lo suficientemente descriptivos como para que observarlos sea genuinamente educativo. Ves el razonamiento.
Auto Accept Edits es donde paso la mayor parte de mi tiempo. Las escrituras de archivos ocurren automáticamente. Los comandos siguen requiriendo aprobación. Claude puede estructurar, escribir y modificar archivos libremente, pero cuando quiere ejecutar npm install o una migración de base de datos, tú sigues viendo el comando, confirmas que tiene sentido y luego lo apruebas. No estás aprobando a ciegas — estás ejerciendo tu juicio al nivel de abstracción que realmente importa.
Planning Mode es el subestimado. No se construye nada. No se escribe nada. Tienes una conversación sobre arquitectura — cómo debería verse el esquema, cuáles son las compensaciones entre el enfoque A y el enfoque B, qué es probable que lamentemos en seis semanas si elegimos este camino. Usé Planning Mode durante treinta minutos antes de construir un sistema de autenticación reciente, y me salvó de un callejón sin salida arquitectónico en el que yo mismo había caído antes. La estructura de claves foráneas que discutimos en la planificación habría causado una migración dolorosa si hubiera construido primero y pensado después. Usa esto más de lo que crees que necesitas.
Bypass Permissions (YOLO Mode) — el nombre es honesto. Claude ejecuta sin interrupción. Archivos, comandos, instalaciones, arranques de servidores, lectura de errores, correcciones — todo autónomo. Genuinamente poderoso para prototipos desechables y proyectos nuevos sin contexto sensible. En cualquier cosa conectada a producción, trátalo con la seriedad apropiada. El sistema de work trees (que cubriré en breve) existe específicamente para hacer el modo YOLO más seguro — lo ejecutas en una copia aislada, revisas la salida y luego decides qué fusionar.
La capacidad de cambiar de modo en medio de una sesión es algo que suena menor hasta que lo usas en un momento de alto riesgo. Estaba en modo Auto Accept construyendo una funcionalidad, llegué a la capa de base de datos e inmediatamente bajé a Planning Mode antes de dejar que Claude tocara el esquema. Ese cambio de contexto tomó cinco segundos y probablemente me ahorró dos horas de depurar una migración que no tenía intención de escribir.
Pero el sistema de permisos es realmente solo la base. El techo es lo que sucede con los flujos de trabajo multi-agente — y para llegar ahí, necesitas entender qué más vive en este entorno.
El ecosistema: qué hay realmente dentro de esta cosa
Antes de hablar de agentes, déjame recorrer el ecosistema que lo rodea, porque hay algunas piezas que no reciben mucha atención pero importan en la práctica.
Los conectores vinculan Claude Code con servicios externos. Gmail está en la lista; la extensión de navegador de Claude es la que más uso. El uso práctico: si estoy leyendo documentación de una API en mi navegador y le hago una pregunta a Claude sobre la implementación, el conector muestra el contexto relevante de la documentación sin que yo tenga que copiar y pegar nada. Diez segundos ahorrados por pregunta suena trivial. A lo largo de una sesión de cuatro horas con cuarenta consultas de contexto, se acumula en algo real.
El marketplace de plugins merece una hora de exploración genuina. Los plugins extienden las capacidades de Claude de maneras específicas y componibles — instálalos como extensiones de navegador, úsalos cuando sean relevantes, ignóralos en caso contrario. El plugin de habilidad de diseño front-end es el que más notablemente cambió mi output de interfaz. El Claude estándar escribe código de interfaz funcional. El plugin escribe código de interfaz considerado — jerarquías de espaciado adecuadas, estructura de componentes cohesiva, estados hover que realmente se sienten intencionales. La diferencia es visible en treinta segundos de mirar la salida lado a lado. He dejado de escribir interfaces sin él.
Superpowers es la funcionalidad paraguas para flujos de trabajo de nivel superior: sesiones de lluvia de ideas con sub-agentes, revisiones de código que incluyen razonamiento real sobre las decisiones (no solo "esto se ve bien"), depuración que traza rutas de ejecución en lugar de solo sugerir correcciones, y desarrollo guiado por pruebas donde los tests que fallan se escriben antes de cualquier implementación. La capacidad de revisión de código se ha vuelto innegociable para mí antes de cualquier PR. La semana pasada detectó dos bugs que mi revisión manual pasó por alto — ambos casos límite en el manejo de errores asíncronos que habrían aparecido en producción bajo condiciones de temporización específicas. Uno de ellos habría sido un error grave de cara al cliente. Yo no escribí ese bug. Claude lo encontró. Estamos del mismo lado aquí.
Los work trees merecen una mención específica porque son la red de seguridad para todo lo agresivo. Cuando Claude trabaja en un work tree, opera sobre una copia aislada de tu repositorio. Tu rama principal queda completamente intacta hasta que fusionas explícitamente. Revisa el diff, toma lo que quieras, deja lo que no. He empezado a usar work trees por defecto para cualquier tarea en la que no estoy seguro de antemano de cómo debería verse la salida — que es la mayoría de las tareas.
La ejecución local vs. en la nube vs. SSH es la capa de infraestructura final. Los agentes locales se ejecutan en tu máquina — necesitan que tu máquina esté encendida y conectada. Los agentes en la nube se ejecutan en la infraestructura de Anthropic — siguen trabajando después de que cierras tu portátil. Las conexiones SSH te permiten apuntar Claude Code a un servidor remoto o VPS y ejecutar el mismo flujo de trabajo contra él desde la app de escritorio. He estado usando sesiones SSH para manejar mantenimiento rutinario en un entorno de staging. Configura la sesión, deja que el agente se ejecute, vuelve a una tarea completada. Esa capacidad no existía de ninguna forma coherente antes de esta app.
Y aquí es donde llegamos a la parte que realmente cambió mi velocidad de producción.
El flujo de trabajo multi-agente que duplica lo que entregas
Esta es la revelación a la que quería llegar.
Estaba construyendo una app web de generación de miniaturas — una herramienta que llamaré Thumb Forge, diseñada para generar miniaturas de YouTube usando una API de generación de imágenes. Tres líneas de trabajo necesitaban suceder: integración del API en el backend, implementación de la interfaz y pruebas de QA. Mi instinto por defecto era secuenciarlas. Primero el API, luego la interfaz, luego las pruebas. Cinco o seis días para un desarrollador solo si le metía ganas.
Lo que hice en cambio: abrí tres sesiones en paralelo.
La sesión uno empezó en Planning Mode. Subí la documentación relevante del API, describí el flujo de trabajo previsto para el usuario, y le pedí a Claude que hiciera preguntas aclaratorias sobre casos límite. Una de esas preguntas — sobre cómo manejar diferentes resoluciones de imagen (1K, 2K, 4K) en la respuesta del API — era algo que yo no había pensado explícitamente. Lo resolvimos en la planificación antes de escribir una sola línea de código. Esa sesión duró veinte minutos y eliminó toda una clase de decisiones que me habrían frenado durante la implementación.
La sesión dos manejó la implementación del backend localmente, en modo Auto Accept Edits. Le di el plan de implementación de la sesión uno, las variables de entorno relevantes (agregadas manualmente a .env.local — más sobre esto en un momento), y una descripción del comportamiento esperado del API. Estructuró el proyecto, conectó la integración del API, manejó los estados de error. Cuando quiso ejecutar el servidor de desarrollo, preguntó; yo aprobé. Aparecieron errores en los logs del servidor; Claude los leyó, rastreó la causa raíz, propuso una corrección, yo aprobé. Ese ciclo de depuración se ejecutó unas cuatro veces antes de que el backend estuviera limpio. Revisé los diffs en cada punto de control. Nada me sorprendió.
Un error en particular destaca porque ilustra algo que vale la pena entender sobre cómo este flujo de trabajo difiere de una sesión de depuración tradicional. La llamada al API estaba devolviendo un 400 con un cuerpo JSON que contenía un campo unsupported_model — algo que no era inmediatamente obvio solo por el mensaje de error. En un flujo de trabajo normal, yo habría leído el log, buscado el código de error, consultado la documentación, intentado una corrección. Claude leyó el log, cruzó referencias con la documentación del API que tenía en contexto, identificó que yo había pasado un identificador de modelo con el sufijo de versión incorrecto, generó la llamada corregida y ejecutó la prueba de nuevo — todo en un ciclo ininterrumpido. Estaba observando la terminal. Tiempo total desde el error hasta la resolución: unos noventa segundos. Ese ciclo de depuración específico, hecho manualmente, me habría tomado cinco minutos como mínimo porque habría empezado asumiendo que era un problema de autenticación.
La sesión tres se ejecutó en la nube — una sesión de rediseño de interfaz usando el plugin de habilidad de diseño front-end. La configuré antes de irme a almorzar. El agente en la nube trabajó mientras yo estaba desconectado. Cuando volví, un pull request estaba esperando con un resumen completo de los cambios y capturas de pantalla del antes y después de la interfaz. Lo revisé, hice dos pequeños ajustes y lo fusioné.
Dos líneas de trabajo paralelas que había estimado en cinco o seis días secuenciales tomaron dos. Y la calidad de la salida fue mayor que la que mi trabajo secuencial típicamente produce, porque cada agente tenía un contexto enfocado en lugar de la sobrecarga cognitiva que degrada el juicio humano a lo largo de una sesión larga.
El detalle crítico de implementación que hizo que esto funcionara: cada agente recibió un contexto exhaustivo desde el principio. No descripciones vagas — información específica. La estructura del código existente para los archivos que iba a tocar. Secciones relevantes de la documentación, no solo enlaces. Restricciones que no eran obvias a partir de la descripción de la tarea. Mensajes de error que ya había visto. La diferencia entre un agente bien contextualizado y uno con contexto insuficiente no es incremental — es la diferencia entre algo que entregas y algo que reescribes.
Sobre la gestión de claves del API: agregué la clave del API de Gemini manualmente a .env.local. No dejé que Claude la escribiera. Esto no se trata de desconfianza — se trata de mantener una única fuente de verdad que yo controlo explícitamente. Claude debería trabajar con variables de entorno que ya existen; no debería ser la entidad que crea o gestiona secretos. Esto aplica a cualquier flujo de trabajo con IA, no solo a este.
La integración con GitHub cerró el ciclo. El agente en la nube hace cambios en un work tree, abre un PR con documentación detallada de los cambios, yo reviso y fusiono. El historial de Git se mantiene limpio. Cada decisión tiene un rastro documentado. El flujo de trabajo es compatible con las prácticas de equipo existentes sin requerir que nadie cambie sus hábitos de revisión de PRs.
Lo que me sorprendió del PR en la nube: el resumen de cambios no fue solo "se actualizaron archivos de interfaz". Fue un desglose estructurado — qué componentes cambiaron y por qué, qué decisiones de diseño se tomaron, dónde existían compensaciones entre opciones, y qué se dejó explícitamente sin cambiar para evitar la expansión del alcance. Ese nivel de documentación en un PR, escrito de forma autónoma, es algo que normalmente me tomaría treinta minutos escribir yo mismo. Ahora paso cinco minutos revisándolo.
La función de vista previa en vivo es más útil de lo que suena de forma aislada. Claude puede tomar capturas de pantalla de la aplicación en ejecución, identificar problemas visuales sin que tú describas qué se ve mal, y corregirlos en la misma sesión. Probé esto intencionalmente introduciendo un bug de diseño móvil y viendo cómo Claude lo detectaba desde la vista previa. Señaló el problema, propuso una corrección, yo aprobé, verificó visualmente la corrección. Ese ciclo se ejecutó en unos cuatro minutos. Anteriormente, esa misma iteración requería que yo describiera el problema con palabras, lo que agrega una capa de traducción que cuesta tiempo e introduce ambigüedad.
La verdad sin filtros: lo que nadie menciona
Algunas cosas honestas que vale la pena saber antes de reorganizar todo tu flujo de trabajo de desarrollo alrededor de esta herramienta.
La curva de aprendizaje no es la app. La interfaz es genuinamente intuitiva. La curva de aprendizaje es reaprender cómo dar buenas instrucciones.
Mi primera semana, usé Claude Code de escritorio como una terminal ligeramente más inteligente. Instrucciones vagas: "hazlo más performante", "limpia la interfaz", "arregla el flujo de autenticación". La salida fue mediocre. El techo de salida que alcancé en la primera semana no fue significativamente más alto que lo que había logrado con flujos de trabajo de copiar y pegar IA en una pestaña del navegador.
El cambio ocurrió cuando dejé de describir estados finales y empecé a darles a los agentes restricciones, contexto y autoridad para tomar decisiones dentro de un alcance definido. "Haz que la interfaz se vea mejor" es un mal prompt. "Refactoriza el formulario de generación de miniaturas a un diseño de dos columnas — entradas a la izquierda, vista previa a la derecha — usando las clases de Tailwind existentes, preserva el esquema de colores actual, agrega un estado de carga al botón de generación, y no toques la lógica de validación del formulario" es un buen prompt. Misma intención. Salida dramáticamente diferente.
Lo segundo que tuve que desaprender: interrumpir a los agentes a mitad de tarea. Cuando Claude está trabajando en una tarea compleja en modo Auto Accept, el impulso es verificar cada cinco minutos. Resiste. Las interrupciones rompen el contexto de trabajo del agente y consistentemente producen peores resultados que dejarlo ejecutarse hasta un punto de control natural y revisar el diff. Confía en el work tree. Revisa al completar, no a medio camino.
Aprendí esto específicamente ignorando mi propio instinto. En una sesión donde seguí interviniendo para redirigir — "en realidad, espera, haz esto en su lugar" — la salida fue fragmentada y requirió más tiempo de limpieza que si simplemente lo hubiera hecho manualmente. En la siguiente sesión, me contuve, dejé que el agente trabajara durante cuarenta minutos, revisé el diff completo al final y lo entregué con tres pequeños ajustes. Mismo tipo de tarea. Experiencia completamente diferente. La disciplina es real.
Tercera admisión honesta: los agentes en la nube son poderosos pero no son infalibles. He tenido agentes en la nube que volvieron con PRs que resolvieron el 80% de una tarea e introdujeron un caso límite sutil. Revisar los PRs de agentes necesita ser al menos tan riguroso como revisar PRs de un desarrollador junior en tu equipo. El valor está en la ejecución paralela — la responsabilidad por la corrección sigue siendo tuya.
Y el modo YOLO merece honestidad específica: un prototipo desechable nuevo sin conexiones a producción está bien. Una rama de producción conectada a tu repositorio principal merece reflexión cuidadosa, configuración adecuada del work tree y un plan de reversión. La funcionalidad existe por buenas razones y casos de uso reales. El nombre no debería hacerte actuar con descuido respecto al contexto.
Una cosa más que no voy a endulzar: las refactorizaciones grandes que requieren una conciencia sostenida de un código base complejo son donde los agentes más luchan todavía. Cuando el alcance del contexto es demasiado amplio, los agentes pierden hilos. Mi práctica actual es limitar a los agentes a módulos específicos en lugar de pedir refactorizaciones a nivel de todo el código base. Esto está mejorando con cada versión de Claude — pero es una limitación real actual que vale la pena planificar.
Cómo se ven los números después de ocho semanas
He estado rastreando la producción a través de proyectos desde que cambié mi flujo de trabajo principal, así que déjame darte datos reales.
Tiempo de entrega de una app web de complejidad media — autenticación, integración de API, interfaz básica, configuración de despliegue — antes promediaba de 8 a 12 días para desarrollo en solitario. Promedio actual: 3-4 días. Eso no es una ganancia marginal. Es la diferencia entre entregar 4 proyectos al mes y entregar de 8 a 12.
Detecciones en revisión de código: la capacidad de revisión de código detecta consistentemente casos límite asíncronos y manejo de errores inconsistente entre funciones similares — una categoría que mi revisión manual pasa por alto a un ritmo notable. Dos bugs detectados la semana pasada. Ambos habrían llegado a producción sin ella.
Cambio de contexto eliminado: solía tener un promedio de 7-8 ventanas de aplicación abiertas durante una sesión de desarrollo. Actual: una. La reducción de carga cognitiva tiene un efecto real en la calidad de las decisiones que tomo en las últimas horas de una sesión, cuando la fatiga normalmente empezaría a degradar el juicio.
Donde las ganancias son menores: código sensible a la seguridad y lógica de negocio compleja que requiere decisiones humanas secuenciales y deliberadas. En esas tareas, las ganancias son reales pero modestas — un 30-40% más rápido. La herramienta no es apropiada para cada contexto con máxima autonomía. Saber cuándo retroceder es parte de usarla bien.
SSH y ejecución remota están aportando valor para trabajo de infraestructura del que solía desconectarme por completo. La capacidad de apuntar Claude Code a un servidor de staging vía SSH y que maneje una actualización rutinaria mientras yo me enfoco en otra cosa es algo pequeño que se acumula a lo largo de una semana.
El archivo de sesiones es una funcionalidad que casi pasé por alto hasta que resultó útil. Las sesiones completadas pueden archivarse en lugar de cerrarse permanentemente — así que si necesito consultar exactamente qué hizo un agente en el pasado, cómo razonó sobre un problema, o qué contexto tenía cuando tomó una decisión específica, puedo recuperarlo. Solo para propósitos de depuración, esto me ha ahorrado tiempo dos veces.
El benchmark honesto: los flujos de trabajo con agentes en paralelo aproximadamente duplicaron mi velocidad de entrega en proyectos adecuados para ellos. En proyectos que requieren juicio secuencial cuidadoso, las ganancias son reales pero acotadas. Ambas categorías importan.
El cambio que ya está ocurriendo
Lo que quiero que reflexiones: esto no se trata de que una herramienta sea mejor que otra. Se trata de un modelo diferente de cómo se construye el software.
Los IDEs tradicionales están diseñados alrededor de la suposición de que tú escribes el código. Todo en ellos optimiza para ti como autor principal. La app de escritorio de Claude Code está diseñada alrededor de la suposición de que un agente de IA maneja la mayoría del trabajo de implementación, y tú diriges, revisas y tomas las decisiones que requieren juicio. Esa es una relación fundamentalmente diferente entre el desarrollador y la herramienta.
Los desarrolladores que se vuelvan genuinamente buenos en esto — que aprendan a escribir restricciones en lugar de descripciones vagas, que estructuren cargas de trabajo paralelas intencionalmente, que revisen la salida de los agentes con el rigor apropiado — esos desarrolladores no estarán operando a una versión ligeramente superior del mismo juego. Estarán haciendo algo cualitativamente diferente. La brecha de producción entre ellos y los desarrolladores que siguen usando IA como un autocompletado sofisticado se va a ampliar rápido.
Así que aquí tienes tu desafío específico: elige un proyecto que hayas estado posponiendo porque se sentía como demasiado para abordarlo solo. Inicia una sesión de Claude Code de escritorio esta semana. Pasa los primeros treinta minutos en Planning Mode — sin pedirle a Claude que construya nada, solo pensando juntos en la arquitectura. Luego configura el contexto adecuado y déjalo ejecutarse.
No solo lo observes trabajar. Estudia cómo aborda los problemas. Nota dónde toma una decisión que tú habrías tomado de forma diferente y entiende por qué. Nota dónde te sorprende con un enfoque que no habías considerado.
Borré VS Code hace tres semanas. No lo extraño. Eso no es algo que esperaba decir — y no es algo que diría si no fuera verdad.
Let's Work Together
Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.
- Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise solutions): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (security services): xcybersecurity.io
