Del prototipo al producto: El viaje de desarrollo de Tactic Remote

Tactic Remote comenzo como una pregunta a principios de enero de 2026: que pasaria si pudieras verificar una sesion de Claude Code en ejecucion desde tu telefono? Esa pregunta se convirtio en un prototipo en un fin de semana, una herramienta utilizable en dos semanas, y un producto con 13 hitos completados antes de que publicaramos nuestra primera version numerada. Esta es la historia de ese arco de desarrollo: que construimos, que descartamos y que aprendimos al publicar rapido sin publicar algo roto.

El prototipo del fin de semana (Principios de enero 2026)

La primera version de Tactic Remote tenia aproximadamente 200 lineas de codigo. Un script de shell lanzaba Claude Code dentro de una sesion tmux, un servidor Python Flask exponia un endpoint que ejecutaba tmux capture-pane y devolvia la salida como texto plano, y una app iOS basica consultaba ese endpoint cada 2 segundos y mostraba el resultado en una vista de texto monoespaciado.

Era feo y lento. El modelo de sondeo significaba 2 segundos de latencia en cada actualizacion. La captura en texto plano perdia todo el formato. No habia autenticacion: cualquier persona en la misma red Wi-Fi podia leer tu terminal. Pero demostro el concepto: se podia seguir de manera significativa una sesion de codificacion con IA desde la pantalla de un telefono.

Ese prototipo sobrevivio unos 4 dias antes de que comenzaramos a reconstruir.

Arquitectura por hitos

Adoptamos un modelo de desarrollo basado en hitos en lugar de sprints de calendario. Cada hito tenia un objetivo tecnico especifico, una definicion de finalizado y ninguna fecha limite fija. Esto nos permitio publicar cuando algo estaba listo en lugar de cuando terminaba un sprint. En la practica, los hitos duraron un promedio de 4-5 dias, aunque algunos tomaron tan solo 2 dias y uno tomo casi dos semanas.

Aqui esta la progresion resumida:

Hitos 1-3: Fundamentos. Reemplazar Flask con un servidor embebido nativo en Swift. Establecer WebSocket para streaming en tiempo real en lugar de sondeo HTTP. Implementar autenticacion basada en tokens. Despues del Hito 3, teniamos un sistema funcional donde el iPhone recibia actualizaciones del terminal en 200ms y el acceso no autorizado era bloqueado.

Hitos 4-5: Gestion de sesiones. Soporte para multiples sesiones tmux concurrentes. Construir el ciclo de vida de las sesiones (crear, monitorear, inactivo, completar, limpiar). Agregar persistencia de sesiones a traves de reinicios de la app companera reconectandose a sesiones tmux existentes al arrancar. Este fue el punto donde Tactic Remote dejo de ser una demo y se convirtio en algo usable para trabajo real.

Hitos 6-7: Humano en el bucle. Integracion con el sistema de hook de Claude Code para interceptar solicitudes de aprobacion. Construir la interfaz de aprobacion en iOS: mostrar que quiere hacer la IA, mostrar el contexto relevante y proporcionar acciones de aprobar/rechazar. Agregar notificaciones push para que las aprobaciones no requieran que la app este abierta. Estos dos hitos fueron el punto de inflexion. Antes de ellos, Tactic Remote era un visor de terminal. Despues, era una superficie de control.

Hitos 8-9: Robustez de conexion. Manejar transiciones de Wi-Fi a celular. Implementar reconexion automatica con retroceso exponencial. Agregar indicadores de calidad de conexion. Construir el flujo de conexion rapida por codigo QR para eliminar la entrada manual de IP y token. El Hito 9 fue el hito individual mas dificil: los casos extremos de red en iOS son numerosos y estan pobremente documentados.

Hitos 10-11: Cloudflare Tunnel. Integrar cloudflared como proceso hijo gestionado. Construir la arquitectura de conexion de modo dual (local y tunel). Manejar el monitoreo de salud del tunel, reinicio automatico y retroceso elegante. Agregar la URL del tunel a la generacion de codigos QR.

Hitos 12-13: Preparacion para produccion. Localizacion (7 idiomas). Prevencion de suspension del Mac. Pulido de la interfaz de barra de menu. Reportes de fallos y diagnosticos. Optimizacion de rendimiento para reducir el uso de memoria de aproximadamente 60 MB a menos de 25 MB en reposo. Auditoria de seguridad final de las capas de autenticacion y transporte.

Decisiones tecnicas clave

Varias decisiones tomadas durante el desarrollo definieron el caracter del producto:

tmux sobre gestion personalizada de PTY

Debatimos esto extensamente durante el Hito 1. La gestion personalizada de PTY nos daria un control mas fino sobre la captura del terminal y eliminaria la dependencia de tmux. Pero tambien significaria reimplementar la persistencia de sesiones, la emulacion de terminal y la gestion del ciclo de vida de procesos, problemas que tmux ha resuelto durante 15 anos. Elegimos apoyarnos en esa base en lugar de reconstruirla.

WebSocket sobre Server-Sent Events

Para streaming en tiempo real, ambos protocolos funcionan. Elegimos WebSocket porque necesitabamos comunicacion bidireccional: el iPhone envia comandos y aprobaciones de vuelta al Mac, no solo recibe salida del terminal. SSE habria requerido un canal separado para la comunicacion ascendente, anadiendo complejidad.

Servidor embebido sobre daemon independiente

Un daemon independiente (gestionado por launchd) habria sido mas "correcto" desde la perspectiva de la arquitectura macOS. Pero habria duplicado la complejidad de instalacion y creado una clase de errores de "el servidor esta corriendo pero la app no". Integrar el servidor en la app de barra de menu significa una cosa para instalar, una cosa para ejecutar, una cosa para cerrar.

Token estatico sobre OAuth/autenticacion basada en sesiones

El modelo de amenazas de Tactic Remote es directo: prevenir acceso no autorizado desde la red. Un token aleatorio criptografico de 256 bits almacenado en el Llavero logra esto sin la complejidad de renovacion de tokens, expiracion de sesiones o flujos de inicio de sesion. Para casos de uso empresariales que requieren autenticacion por usuario, recomendamos Cloudflare Access como capa externa.

Sondeo de tmux sobre vigilancia del sistema de archivos

Sondeamos tmux capture-pane a intervalos de 200ms en lugar de usar APIs de notificacion del sistema de archivos (kqueue/FSEvents) en un PTY. Esto suena poco elegante, pero el comando de captura de tmux es extremadamente rapido (sub-milisegundo), y la vigilancia del sistema de archivos en dispositivos PTY resulto poco fiable entre versiones de macOS en nuestras pruebas. El enfoque de sondeo ha sido solido como una roca en macOS 13, 14 y 15.

Lo que descartamos

No todo sobrevivio. Algunos recortes notables:

Un cliente basado en web. Construimos una interfaz web responsiva durante el Hito 6 que podia ejecutarse en cualquier navegador. Funcionaba, pero la experiencia era significativamente peor que una app nativa: sin notificaciones push, sin reconexion en segundo plano, sin retroalimentacion haptica en las aprobaciones. Lo archivamos para enfocarnos en la experiencia nativa de iOS.

Color y formato del terminal. Las versiones tempranas intentaron preservar los codigos de color ANSI y renderizarlos en el iPhone. El renderizado era inconsistente y anadia complejidad significativa al protocolo de streaming. Cambiamos a un modelo de renderizado simplificado que preserva la estructura sin intentar una emulacion de terminal pixel por pixel. El soporte completo de ANSI sigue en la hoja de ruta.

Sugerencias automaticas de tareas. Prototipamos una funcion donde Tactic Remote sugeriria tareas de Claude Code basadas en tu actividad reciente de git. Era tecnicamente interesante pero se sentia presuntuoso: los desarrolladores saben en que quieren trabajar. Lo eliminamos antes de que cualquier beta tester lo viera.

La transicion de versionado

Despues del Hito 13, hicimos la transicion del seguimiento por hitos al versionado semantico. La primera version numerada fue 1.2.0 (no 1.0.0, porque teniamos compilaciones internas numeradas 1.0 y 1.1 durante las pruebas cerradas y no queriamos crear confusion).

La progresion desde entonces: 1.2.0, 1.3.0, 1.4.0, 1.4.2 y 1.5.0-beta.1. Cada version corresponde a un conjunto claro de cambios orientados al usuario documentados en nuestro registro de cambios. El sistema de hitos nos sirvio bien durante la creacion rapida de prototipos, pero el versionado semantico comunica mas claramente a los usuarios que necesitan evaluar el riesgo de actualizacion.

Lo que aprendimos

Publica lo mas pequeno util. El prototipo del fin de semana era vergonzoso por cualquier estandar de ingenieria, pero respondio a la unica pregunta que importaba: monitorear Claude Code desde un telefono realmente ayuda? Cada hito posterior fue una respuesta incremental a "cual es la siguiente mejora mas util?"

La red es la parte dificil. Dedicamos mas tiempo a la fiabilidad de la conexion que a cualquier otro aspecto del producto. Transiciones de Wi-Fi a celular, reconexion WebSocket despues de la suspension, monitoreo de salud de Cloudflare Tunnel: cada uno de estos consumio un hito completo. La captura real del terminal y la gestion de sesiones fue comparativamente sencilla.

Las dependencias deben ser aburridas. tmux, cloudflared, Llavero, IOKit: las tecnologias de las que depende Tactic Remote son estables y estan bien documentadas. Cada vez que consideramos adoptar algo mas nuevo o novedoso, nos preguntamos si la opcion aburrida existente era suficientemente buena. Generalmente lo era.

El desarrollo basado en hitos funciona para equipos pequenos. Sin la sobrecarga de planificacion de sprints, reuniones diarias y seguimiento de velocidad, nos movimos mas rapido. Cada hito tenia una linea de meta clara, y podiamos ajustar el alcance en tiempo real basandonos en lo que aprendiamos durante la implementacion. Este modelo se descompone en equipos mas grandes, pero para nuestro desarrollo temprano fue el adecuado.

Resumen del cronograma

Ocho semanas desde una idea hasta una beta abierta. No porque tomamos atajos, sino porque recortamos el alcance sin piedad y construimos sobre bases probadas.

Para un vistazo detallado de cada version publicada, consulta nuestro Registro de cambios.