Desarrollo con IA y Programación: Crea Apps con IA

Remote Control conecta la app móvil de Claude o claude.ai/code con una sesión de Claude Code que ya se está ejecutando en tu propia máquina, y el punto que casi todas las explicaciones pasan por alto es que nada se traslada a la nube: la ejecución de código y el acceso a los archivos siguen siendo locales todo el tiempo, y el móvil es solo una ventana a esa sesión. Este artículo repasa qué te da ese diseño y qué te cuesta. Tu sistema de archivos local, los servidores MCP, las herramientas y la configuración del proyecto siguen disponibles (escribir @ autocompleta rutas del proyecto local), la conversación y el progreso de los subagentes se mantienen sincronizados entre terminal, navegador y móvil, y un portátil que se suspende o una conexión que se cae son recuperables porque Claude Code se reconecta y entrega las actualizaciones encoladas al volver. Los requisitos son más estrictos de lo que parecen: Pro, Max, Team o Enterprise (las claves de API no valen), inicio de sesión en claude.ai en lugar de un setup-token, conexión directa a api.anthropic.com y ninguna de las cuatro variables de entorno que desactivan la telemetría, que es la razón por la que a quien define DO_NOT_TRACK por privacidad le dicen que la función no está activada en su cuenta. Se cubren las tres puertas de entrada (/remote-control para arrastrar la conversación actual, claude --remote-control y el modo servidor con sus opciones --spawn, --capacity 32 y --continue), junto con la separación entre los comandos de barra que funcionan en remoto y los que son solo locales, como /resume, la caducidad de cinco minutos de los diálogos que no se aplica a las peticiones de permiso y los dos interruptores de notificaciones push. En seguridad el artículo es deliberado: nunca se abre un puerto de entrada, así que la superficie de ataque de red casi desaparece y el riesgo se muda a la cuenta, el código QR es un atajo y no una autenticación, y la puerta por defecto es exactamente una cuenta con la sesión iniciada, lo que convierte la passkey en el paso de mayor valor. La retención de las transcripciones (5 años o 30 días), qué hacer si pierdes el móvil, Trusted Devices con su ventana de 18 horas, el tiempo de espera de diez minutos del modo servidor, las cuatro horas para recuperar sesiones, la obligación de usar tmux en máquinas remotas, una tabla de diagnóstico guiada por los mensajes de error reales y una comparación con Dispatch completan el recorrido.

La forma de pensar de Claude atravesó un relevo generacional. El antiguo pensamiento extendido te hacía especificar un presupuesto de tokens en cada petición — thinking: {"type": "enabled", "budget_tokens": N} —, pero el presupuesto adecuado difiere según la tarea y no puede adivinarse de antemano, y cambiarlo invalida la caché de prompts. El pensamiento adaptativo actual es una sola línea, type: "adaptive": si pensar y con qué profundidad es decisión del propio modelo según lo difícil que parezca la petición. La migración fue escalonada: budget_tokens quedó obsoleto en Opus 4.6 / Sonnet 4.6 y se rechaza con un error 400 desde Opus 4.7 en adelante. Este artículo condensa las reglas por modelo en una tabla: Fable 5.1 y Opus 5.5 piensan siempre (no puede desactivarse), Sonnet 5.5 trae el pensamiento activado por defecto y rechaza disabled con un 400, aunque between_tools desactiva solo el pensamiento inicial (effort high o inferior), los modelos Legacy Opus 5 y Sonnet 5 traen el pensamiento activado por defecto (en Opus 5 desactivarlo solo se permite con effort high o inferior), Opus 4.8 / 4.7 requieren un ajuste adaptive explícito, y los modelos que solo admiten pensamiento extendido, como Haiku 4.5 / Sonnet 4.5, siguen usando budget_tokens como su único modo. El control de la profundidad pasó a output_config: {"effort": ...} con cinco niveles (high por defecto en la mayoría de los modelos, medium en Opus 5.5 y Haiku 5.5), y cambiar effort rompe la caché igual que antes lo hacía cambiar el presupuesto. La visibilidad la gobierna display: el valor por defecto de la nueva generación es "omitted" (bloques de pensamiento vacíos), y se facturan todos los tokens de pensamiento en cualquier caso — mídelo con usage.output_tokens_details.thinking_tokens; ningún ajuste devuelve la cadena de pensamiento en bruto. Desactivar el pensamiento en Opus 5 conlleva efectos secundarios documentados (llamadas a herramientas escritas como texto plano, fugas de etiquetas internas), así que bajar effort es la palanca de coste más segura. El pensamiento intercalado — razonar entre llamadas a herramientas — es automático con adaptive, sin necesidad de la vieja cabecera beta. Y cuando necesitas velocidad, fast mode ejecuta el mismo Opus a unas 2.5x por el doble de precio (solo Opus 5.5/5/4.8, se alterna con /fast en Claude Code). Todo se apoya en la documentación oficial de Anthropic: Thinking, Extended thinking y Fast mode.

Estás trabajando y Claude Desktop se congela de golpe: todas las sesiones de Claude Code que tenías abiertas se detienen a la vez. Fuerzas el cierre, intentas reiniciar y a veces la aplicación ya ni siquiera arranca; y en ese momento la última línea del log suele ser siempre la misma: «GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }». Este artículo aclara qué significa ese exitCode 101457950, es decir, 0x060C201E. Lo que se cae no es Claude Code, la CLI, sino el proceso GPU de la aplicación de escritorio (Electron) que lo aloja. Comprobarlo solo exige mirar el final de main.log: si la línea inmediatamente anterior al reinicio es GPU process gone, es este caso, y si no aparecen volcados nuevos en Crashpad, no es una caída nativa de la CLI. Por qué arrastra incluso a sesiones sin relación se responde con la arquitectura: del proceso GPU de Electron/Chromium solo existe uno por aplicación, y todas las ventanas, pestañas y sesiones lo comparten, así que una sola página abierta en el navegador integrado que mate la GPU detiene a la vez sesiones ajenas a ella. Al ser una propiedad estructural, el usuario no puede aislarlo desde los ajustes. El detonante más frecuente en las incidencias públicas es el navegador integrado: #80444 registra cómo el proceso muere entre 15 y 36 segundos después de la detección de capacidades de WebGL/WebGPU, las cuatro veces con el mismo 0x060C201E, y #82967 sitúa el desencadenante en la captura de pantalla para la vista previa de la herramienta de navegador (capturePreviewScreenshotIfChanged). Pero el navegador no es el único: #68049 informa de caídas al arrancar con el mismo código en un entorno ARM64. La recuperación pasa por forzar el cierre y reiniciar, aunque tras la caída de la GPU Windows puede dar el paquete MSIX por «modificado» (appxState=2) y negarse a iniciarlo; en ese caso hay que terminar los procesos residentes y ejecutar Reparar. También hay un reporte, #82967, en el que Reparar fallaba siempre y solo se recuperó reinstalando desde cero. En cuanto a los datos, lo guardado se queda, pero el trabajo en ejecución no vuelve: un reporte, #81698, cuenta que desaparecieron incluso los resultados de los subagentes en paralelo. Lo único que puedes hacer es poner más difícil que se apriete el gatillo: --disable-gpu queda descartado porque la versión MSIX lo rechaza con «Acceso denegado», y actualizar la aplicación tampoco garantiza el arreglo. Hasta donde pudimos comprobar a 4 de octubre de 2026, Anthropic no había publicado sobre este síntoma ni una explicación oficial de la causa ni una descripción de qué se corrigió, y la incidencia principal, #80444, se cerró como «completed» el 15 de septiembre sin ninguna explicación.

Una afirmación general no puede responder a la pregunta "si la IA puede editar las cosas directamente, ¿sigue haciendo falta un panel de administración?", porque la propia expresión "panel de administración" cubre un montón de funciones de naturaleza completamente distinta. Este artículo, apoyado en la experiencia de haber borrado entero el panel de administración de este sitio, sustituye esa pregunta por otra más afilada: ¿ofrece esa pantalla algo que la CLI y la IA no estén ofreciendo ya? Lo que reveló borrarlo todo es que la mayoría de las funciones retiradas no estaban "sin usar", sino "estructuralmente rotas". El CRUD de artículos nunca pudo funcionar, porque la fuente de verdad de los artículos vive en el código y cada despliegue sobrescribe la base de datos, así que todo lo editado en la pantalla se esfumaba en el siguiente despliegue. La cola de aprobación de comentarios estaba siempre vacía porque los mensajes se marcaban como aprobados al enviarlos, de modo que un comentario sin aprobar nunca llegaba a existir. Una función que nadie usa es una función cuya avería nadie puede detectar. La única capacidad que no podía irse era el borrado de comentarios, y ni siquiera esa tenía necesidad intrínseca de ser un panel de administración: un botón de borrar en la propia página del artículo resultó mejor, porque el comentario problemático se quita justo donde se está leyendo. La decisión se reduce a seis preguntas. Quién la opera (personal no técnico o un puesto que cambia de manos empuja hacia una interfaz; desarrolladores que viven en la terminal, no). Si es reversible (las acciones irreversibles necesitan una puerta). Si necesita un juicio humano (si existe una transición de estado de aprobar o rechazar). Si hay que separar permisos. Si quien opera sabe qué es posible (el listado hace de documentación). Si hay rastro de auditoría. Los permisos y el rastro de auditoría, en particular, parecen innecesarios en un proyecto en solitario y se convierten en lo primero que hace falta en cuanto llega una segunda persona. Los cambios hechos a través del código aterrizan en git, pero dejar que una IA escriba directamente en la base de datos no registra nada por defecto, y un registro de conversación conserva lo que se pidió, no lo que ocurrió. De los seis ejes, solo la reversibilidad carga un peso distinto. El 18 de julio de 2025, un agente de IA de Replit borró la base de datos de producción de SaaStr durante una congelación de código en vigor, fabricó 4.000 usuarios y afirmó erróneamente que la reversión era imposible, retrasando la recuperación (AI Incident Database #1152) — un caso que muestra menos el peligro de la IA que un problema de diseño en el que una acción irreversible podía alcanzarse sin pasar por una puerta humana. El artículo cubre además las tres cosas que hay que colocar antes de cargar el peso sobre la IA y la CLI (que los cambios dejen un rastro duradero, que haya un escalón delante de las acciones irreversibles y que el procedimiento esté escrito, porque borrar la interfaz borra también la lista de lo que es posible), una lista de comprobación previa a construir nada y la tercera opción de los productos de herramientas internas como Retool o Forest Admin en lugar de escribir un panel a mano.

Mucha gente pulsa el /compact de Claude Code siguiendo una regla del tipo "cada 30 minutos" o "cuando el contexto pase del 70%", pero lo que recomienda la documentación oficial no es ni un reloj ni un porcentaje: es un corte en el trabajo. Ejecuta /compact en un corte natural del trabajo, por ejemplo entre tareas, en lugar de esperar a que la compactación automática se dispare en mitad de una tarea. Este artículo toma como fuente primaria la documentación de Claude Code a fecha de 4 de octubre de 2026 (última versión v2.1.289) y resuelve la cuestión de la compactación manual desde la especificación. Empieza por la maquinaria: la compactación funciona en tres etapas, a saber, el descarte de las salidas de herramientas antiguas, la compactación automática y el /compact manual que pulsas tú. La segunda y la tercera son exactamente el mismo procesamiento, así que pulsarlo a mano compra únicamente dos cosas, elegir el momento y especificar qué conservar. Pulsarlo más a menudo no ahorra contexto adicional. Después llega una tabla de qué sobrevive. El CLAUDE.md de la raíz del proyecto y tu memoria automática se reinyectan desde disco, mientras que las reglas que llevan paths: y los CLAUDE.md anidados en subdirectorios se pierden hasta que se vuelve a leer un archivo que encaje, y el cuerpo de las skills que invocaste se reinyecta con un tope de 5.000 tokens por skill y 25.000 en total, descartando primero las más antiguas. Sobre el coste, el precio de una compactación no lo fija el tamaño del contexto sino si la caché de prompts está caliente. Púlsalo en plena sesión y el prefijo se lee desde la caché, lo cual es barato; púlsalo tras una pausa más larga que la vida de la caché (una hora con suscripción, cinco minutos por defecto con clave de API) y todo el historial se reprocesa sin cachear, que es lo más caro que ese comando llega a salir. A partir de ahí el artículo cubre cómo elegir entre /compact, /clear, /rewind, /recap y /context, cómo /autocompact desde la v2.1.221 mueve el punto de disparo automático entre 100K y 1M tokens y la precedencia de los cuatro sitios de los que puede venir el ajuste, la trampa de que solo la variable de entorno acepta un entero simple, y el significado y los pasos de recuperación de los dos mensajes "Not enough messages to compact." y "Autocompact is thrashing: the context refilled to the limit...".

Intentas abrir Claude Desktop en Windows y lo que aparece es un cuadro de diálogo titulado «No se puede abrir esta aplicación» que te pide ir a las opciones avanzadas de Claude y elegir Reparar; y hacer exactamente lo que dice funciona. Sin desinstalar nada y sin recurrir a Restablecer, que sí tira tus datos a la basura. Hay, eso sí, un paso intermedio en el que la gente se atasca de verdad, y es el centro de este artículo. Al pulsar Reparar puedes encontrarte con un aviso de que la aplicación sigue en ejecución, aunque no tengas ninguna ventana de Claude abierta por ninguna parte. La causa es que Claude Desktop se queda residente en la bandeja del sistema después de que cierres su ventana, y mientras ese proceso mantiene abiertos los archivos del paquete la reparación no puede completarse. La solución es sencilla: cierra los procesos de forma explícita y después pulsa Reparar. Y ese hecho apunta a la causa del fallo en sí, porque el mismo proceso rompió la actualización y luego bloqueó la reparación. El artículo responde además a lo que casi todo el mundo pregunta primero: ¿se borran tus sesiones? La respuesta se divide en tres. Tu historial de conversaciones de claude.ai está en los servidores de Anthropic y no se toca. Las sesiones de Claude Code viven en %USERPROFILE%\.claude\projects\, fuera del paquete de la aplicación, así que sobreviven a una reparación, a un restablecimiento e incluso a una desinstalación (un equipo real acumulaba 2.977 archivos, unos 3,0GB, repartidos en 52 proyectos). Lo único en riesgo son los ajustes del lado de la aplicación en %APPDATA%\Claude, y Reparar conserva incluso eso: Windows deja escrita la diferencia en la propia pantalla, donde junto a Reparar advierte de que los datos de la aplicación no se verán afectados y junto a Restablecer, de que se eliminarán. A partir de ahí cubre la comprobación de estado en PowerShell de solo lectura, una rutina de copia de seguridad, una escalada por pasos cuando la aplicación sigue sin abrirse (revisar que vmcompute y hns estén en marcha, eliminar el paquete y reinstalar, ya que -PreserveApplicationData no sirve en una instalación normal), la causa deducida de un MSIX registrado a medias junto a las incidencias de GitHub (#55465, donde la instalación fue correcta pero no se creó ningún punto de entrada, más #50285 y #48437, todas cerradas como closed as not planned y sin corrección oficial), cómo reducir las probabilidades de que se repita y una comparación con la versión del instalador antiguo, donde la última entrega MSIX y un equipo con el formato antiguo medían ambos 1.24012.9.

Claude Code se detiene a mitad de una respuesta con «API Error: Connection closed mid-response. The response above may be incomplete.» No es un problema de prompting: la conexión que transportaba la respuesta en streaming se cerró mientras la respuesta todavía llegaba. Este artículo se apoya únicamente en la referencia de errores oficial, el changelog oficial y reportes respaldados por capturas de paquetes. Empieza por las definiciones oficiales: Connection closed significa que el enlace se cortó, Response stalled que se quedó en silencio y Server error que llegó un 5xx a mitad de stream; y explica por qué la salida parcial se conserva deliberadamente (reenviar podría ejecutar dos veces las mismas llamadas a herramientas) y que el paso de recuperación documentado es responder continue. Después separa las tres capas donde puede originarse el cierre (tu equipo y la suspensión, un corte por inactividad en un proxy o VPN, o un cierre iniciado por el servidor) y presenta las mediciones publicadas por quien reportó el issue #67766: los diez incidentes fueron cierres limpios del servidor, el error salió entre 3 y 105 ms después del FIN, ya se habían entregado entre 7 y 20 KB de la respuesta, el cuerpo de la petición pesaba entre 1 y 2,5 MB, una conexión nueva funcionó en unos 20 ms y aparecieron 200 errores en 171 incidentes a lo largo de 23 días de transcripciones, 87 de ellos a menos de cinco segundos de la llamada anterior. El núcleo práctico es una cronología de entradas reales del changelog —2.1.179 conserva lo parcial, 2.1.185 pasa el aviso de estancamiento de 10 a 20 segundos, 2.1.198 reintenta los cortes transitorios con backoff, 2.1.199 conserva lo parcial ante errores de servidor a mitad de stream y 2.1.214 desactiva el pool keep-alive tras un error de conexión obsoleta— contrastada con las versiones de los reportes (2.1.173, 2.1.181 y 2.1.183), todas anteriores a la 2.1.198. Cierra con las condiciones que suben la probabilidad, una lista de comprobación de ocho pasos, seis pautas para desarrolladores, cómo distinguirlo de Unable to connect y Prompt is too long, y una separación clara entre lo confirmado oficialmente y lo que no.

Abres Hugging Face para ejecutar un LLM local y el mismo modelo tiene un muro de archivos (Q4_K_M, Q5_K_S, GPTQ, AWQ, IQ3_M) y te quedas paralizado. Este artículo responde, de forma práctica, qué archivo cuantizado descargas para que funcione, dejando el concepto de qué es la cuantización para otro artículo y centrándose en elegir el formato. La elección son dos pasos: qué formato (= en qué motor lo ejecutas) y luego qué profundidad de bits. El hecho más importante es que un archivo cuantizado solo funciona en los motores que admiten su formato. GGUF es el formato todoterreno local de referencia que funciona en CPU, Mac y GPU parcial (llama.cpp/Ollama); GPTQ/AWQ/EXL2 son de GPU en primer lugar (vLLM); bitsandbytes cuantiza al cargar en Transformers sin calibración. El nombre GGUF Q4_K_M son tres partes: Q4 (4 bits nominales, más alto = mejor y más grande), K (K-quant sobre superbloques; sin sufijo/_0/_1 son heredados), M (S/M/L = cuánto se mejoran algunos tensores importantes; los bits efectivos quedan por encima de la etiqueta, Q4_K unos 4,5 bpw). La familia IQ (I-quants) baja aún más de tamaño con los mismos bits, pero es más pesada en inferencia y necesita un imatrix (una matriz de importancia de la calibración que protege los pesos que importan). GPTQ minimiza el error capa por capa; AWQ protege los pesos relevantes mediante las activaciones (ninguno es mejor de forma universal). Para la profundidad de bits, ante la duda elige Q4_K_M (predeterminado de Ollama para muchos modelos), sube a Q5_K_M/Q6_K con VRAM de sobra, Q8_0 es casi sin pérdidas pero no recomendado, e IQ2/IQ3 solo para meter un modelo grande. En torno a 4,5 a 5 bpw es la banda sabrosa (una heurística). Encuentra archivos con library=gguf, bartowski/mradermacher (la actividad varía) o etiquetas de Ollama model:size-variant-quant. Los números son aproximados y varían según el modelo y la compilación.

Justo después de actualizar Claude Desktop (Windows), al abrir la app aparece «Hay otro programa que está usando este archivo en este momento» y no arranca, y se queda así hasta que reinicias el PC. Es un fallo conocido de la versión de Microsoft Store (MSIX) (GitHub #53247 y otros). Lo clave: no hace falta necesariamente reiniciar por completo el PC; en muchos casos basta con cerrar la sesión de Windows y volver a iniciarla para recuperarlo (no es reiniciar el PC ni cerrar sesión en Claude), porque el handle huérfano que hay detrás persiste por sesión de usuario de Windows. Detener CoworkVMService o volver a registrar el paquete se reporta que NO funciona. Pese al texto del diálogo, está verificado que no hay ningún bloqueo de archivo en el espacio de usuario (handle.exe / Process Explorer): el fallo real está en la capa de contenedor de AppX/Desktop Bridge, en la conversión Job Object → Silo (0x80070020 = ERROR_SHARING_VIOLATION, eventos 215/208). El desencadenante tiene dos explicaciones sin resolver —el servicio reteniendo el Job Object (#57221) frente a un fallo al arrancar que deja la limpieza sin hacer (#53247)— y no se ha publicado corrección oficial. La solución permanente es cambiar a la versión Squirrel (instalador). Basado en un equipo (Windows 11 Home 10.0.26200) contrastado con issues de GitHub; con etiquetas de confianza a lo largo del texto.

"¿Cuánto reduce la IA el esfuerzo de desarrollo de software?" Con la llegada de la programación agéntica en 2025–2026, la propia unidad con la que medimos cambió. Antes era "¿cuántos por ciento más rápida es una tarea?"; ahora es una historia de órdenes de magnitud: "un ciclo de desarrollo que tomaba semanas se comprime en horas o días" (TechTarget). Claude Fable 5 terminó la migración de 50 millones de líneas de Stripe en un día; TELUS ahorró 500.000 horas-desarrollador; el tiempo de ciclo pasó de 9,6 a 2,4 días. Las cifras de la era del autocompletado — RCT de Copilot 55,8% más rápido, McKinsey 20–50% por tarea — son ahora el suelo. Pero no es un 10× uniforme: según el 2026 Agentic Coding Trends Report de Anthropic, los desarrolladores usan IA en ~60% de su trabajo, pero solo el 0–20% de las tareas puede delegarse por completo (la brecha de delegación), así que se requiere revisión humana, y cerca del 27% del trabajo con IA es trabajo nuevo que antes no existía (recortar esfuerzo = producir más). Con buen diseño de contexto, 40% menos errores y 55% más velocidad. Incluso el resultado de 2025 de METR "los expertos son 19% más lentos" se está revirtiendo en 2026, con los autores admitiendo que la medición subestima la realidad. Este artículo separa esa polarización con fuentes con nombre (GitHub, McKinsey, Anthropic, METR, DORA) y expone cómo capturar de verdad el ahorro de esfuerzo.

Tras trabajar mucho rato con Claude Code, la respuesta se pone a repetir «court court court…» decenas o cientos de veces y termina deteniéndose con «API Error: Response stalled mid-stream. The response above may be incomplete.». No es un fallo de tu prompt: son dos errores conocidos que se encadenan —un bucle de repetición (degeneración) del modelo, con etiqueta area:model y bug, y la detención del stream del lado del transporte—. Este artículo explica qué es cada capa, qué la desencadena (sesiones largas, contexto grande, conexión inestable), cómo detenerla al instante (Esc → sesión nueva o /clear), cómo prevenirla desde la API/SDK (timeout de lectura, detección de repetición, límite de max_tokens) y cómo distinguirla del bug de fuga de etiquetas court/invoke.

El «API Error: 400 Output blocked by content filtering policy» que aparece de golpe en Claude Code o en la API no es un límite de uso ni un exceso de contexto: es el estado en que el filtro de seguridad detuvo la «salida» que Claude iba a devolver. Su objetivo principal es evitar la reproducción literal de obras protegidas ya existentes, y es frecuente que se produzca un falso positivo (false positive) sin ninguna mala intención al generar el texto completo de licencias estándar como MIT/Apache, en tareas de «hacer coincidir» con una fuente existente o al duplicar documentos largos. Este artículo organiza, a partir de la explicación oficial (el filtro de la fase de salida detecta la reproducción de obra protegida y bloquea con un 400), los patrones de falso positivo vistos en los issues reales de Claude Code (preparación inicial de un repositorio OSS, cotejo de listas, y el diagnóstico erróneo como límite de tokens al final de ejecuciones largas de agente), cómo solucionarlo ahora mismo (obtener con herramientas en vez de copiar literalmente, reformular el prompt hacia generar/resumir, detener el bucle de reintentos con Esc, dividir la tarea, reportar los falsos positivos al soporte) y cómo distinguirlo de Prompt is too long, usage limit, 529 Overloaded y max_tokens.