Notificaciones push para flujos de trabajo de codificacion con IA: ingenieria de entrega confiable

Claude Code puede ejecutarse durante minutos u horas en una tarea compleja. Sin notificaciones, o te quedas mirando la terminal o vuelves periodicamente esperando no haber perdido algo importante. Ninguno de los dos enfoques respeta tu tiempo.

Las notificaciones push son lo que convierte a Tactic Remote en una herramienta de flujo de trabajo en lugar de un visor remoto. Este articulo cubre como construimos el sistema de notificaciones, la integracion con los hooks de Claude Code, la ingenieria de confiabilidad en la entrega y los patrones de uso que hemos observado en desarrolladores reales.

La idea central

El valor de las notificaciones push en Tactic Remote no es "tu telefono vibra". Es que las notificaciones cambian cuando y como interactuas con tu agente de codificacion IA. En lugar de monitoreo sincronico de la terminal, obtienes gestion asincronica de tareas:

1. Inicia una tarea de Claude Code desde tu Mac (o desde la app de iPhone).
2. Alejate. Prepara un cafe. Asiste a una reunion. Vuelve a casa.
3. Tu telefono te notifica cuando la tarea se completa, encuentra un error o necesita tu aprobacion.
4. Revisas y respondes en segundos, y luego vuelves a lo que estabas haciendo.

Lo llamamos el flujo de trabajo de "revisa tu telefono, no tu escritorio". Es el mismo modelo mental que las notificaciones de CI/CD: no miras el pipeline de compilacion; esperas a que te diga el resultado.

Integracion con hooks de Claude Code

El sistema de notificaciones se basa en el mecanismo de hooks de Claude Code. Los hooks son scripts configurables por el usuario que Claude Code ejecuta en puntos definidos del ciclo de vida. La app companera de Mac de Tactic Remote registra hooks para tres tipos de eventos:

Completacion de tarea — Se dispara cuando Claude Code termina de procesar una solicitud. El hook captura el estado de salida, un resumen de los cambios realizados y las ultimas lineas de la salida de terminal.

Aprobacion requerida — Se dispara cuando Claude Code encuentra una operacion que requiere confirmacion humana (escrituras de archivos fuera del directorio del proyecto, comandos de shell, solicitudes de red, etc.). El hook captura la descripcion de la operacion pendiente y un ID de aprobacion unico.

Error — Se dispara cuando Claude Code encuentra un error fatal, una falla de herramienta o un timeout de API. El hook captura el mensaje de error y el contexto relevante.

Cada invocacion de hook envia un payload estructurado al servidor companero de Mac, que determina el enrutamiento de la notificacion, construye el payload de APNs (Apple Push Notification service) y lo despacha a traves de nuestro relay de notificaciones.

Tipos de notificaciones en la practica

Cada tipo de notificacion esta disenado para un patron de interaccion especifico:

Las notificaciones de completacion de tarea incluyen el resumen de la tarea y un indicador de estado (exito o completacion parcial). Tocar la notificacion abre la app Tactic Remote directamente en la vista de terminal de la sesion completada para que puedas revisar la salida.

Las notificaciones de aprobacion tienen la prioridad mas alta. Incluyen la descripcion de la operacion ("Claude quiere ejecutar rm -rf build/ en el directorio del proyecto") y presentan acciones de Aprobar/Rechazar directamente en el banner de notificacion. En iPhone, puedes responder a una aprobacion sin abrir la app: mantiene presionada la notificacion para ver las acciones en linea. Nuestra telemetria muestra que el 62% de las aprobaciones se manejan mediante acciones de notificacion sin abrir completamente la app.

Las notificaciones de error incluyen la categoria del error y un mensaje truncado. Son accionables: al tocarlas se abre la vista de sesion donde puedes revisar el contexto completo del error y decidir si reiniciar o modificar la tarea.

Confiabilidad en la entrega

APNs no garantiza la entrega de notificaciones push. La documentacion de Apple indica que las notificaciones son de "mejor esfuerzo" y pueden perderse debido a la gestion de energia del dispositivo, condiciones de red o limites de tasa. Para una herramienta de desarrollo donde una notificacion de aprobacion perdida significa una tarea detenida, el "mejor esfuerzo" es insuficiente.

Agregamos varias capas de mecanismos de confiabilidad sobre APNs:

Seguimiento de estado del lado del servidor. El servidor companero de Mac mantiene un registro de entrega para cada notificacion. Cada notificacion tiene un ID unico, una marca de tiempo y un estado de entrega (pendiente, enviada, confirmada, expirada).

Confirmacion del lado del cliente. Cuando la app de iPhone recibe y muestra una notificacion, envia una confirmacion al servidor companero de Mac. Si no llega confirmacion en 30 segundos, el servidor retransmite.

Retransmision con backoff exponencial. Las notificaciones no confirmadas se reintentan a intervalos de 30s, 60s y 120s. Despues de tres fallos, la notificacion se marca como potencialmente no entregable y se senala en la interfaz de estado del companero de Mac.

Sincronizacion dentro de la app. Cuando la app de iPhone se abre (o vuelve del segundo plano), consulta al companero de Mac por notificaciones no confirmadas y las muestra en el centro de notificaciones. Esto captura cualquier notificacion que APNs haya descartado completamente.

Deduplicacion. Con la retransmision viene el riesgo de entrega duplicada. Cada notificacion lleva un ID unico que el cliente de iPhone rastrea. Los duplicados se descartan silenciosamente: nunca veras la misma solicitud de aprobacion dos veces.

En la practica, nuestra tasa de exito de entrega (desde notificacion enviada hasta notificacion confirmada) es del 97.3% en 10 segundos y del 99.6% en 60 segundos en nuestra base de usuarios beta.

Detalles de la deduplicacion de notificaciones

La deduplicacion merece atencion especial porque afecta la confianza del usuario. Si un desarrollador ve la misma notificacion de "aprobar escritura de archivo" dos veces, se pregunta si ya la aprobo. Si ve una notificacion de aprobacion para una operacion que ya aprobo, se pregunta si su aprobacion fue recibida.

Nuestra deduplicacion funciona en dos niveles:

Nivel de transporte. Cada notificacion tiene un UUID que persiste a traves de las retransmisiones. El cliente de iPhone mantiene una ventana deslizante de 500 UUIDs vistos recientemente. Cualquier notificacion con un UUID previamente visto se descarta antes de mostrarse.

Nivel semantico. Para las notificaciones de aprobacion especificamente, el cliente verifica si el ID de aprobacion ya fue procesado. Si aprobaste una operacion a traves de la primera entrega de notificacion y llega una retransmision, esta se suprime incluso si su UUID de transporte difiere (lo cual puede ocurrir si el servidor genero un nuevo payload de push para el reintento).

Como usan realmente las notificaciones los desarrolladores

Despues de cuatro meses de datos beta, han surgido patrones claros:

Las horas pico de notificaciones son de 9 a 11 AM y de 2 a 4 PM en la zona horaria local del usuario, correspondiendo al inicio de las sesiones de codificacion y los bloques de productividad post-almuerzo.

El tiempo promedio de respuesta a notificaciones de aprobacion es de 12 segundos. El P95 es de 47 segundos. Esto significa que incluso en la cola, las aprobaciones humanas agregan menos de un minuto a la ejecucion de la tarea, un precio pequeno por la garantia de seguridad.

El flujo de trabajo mas comun basado en notificaciones: Iniciar una tarea de refactorizacion de multiples pasos, dejar el escritorio para una reunion, aprobar 2-3 operaciones de archivo durante la reunion mediante acciones de notificacion, y volver para encontrar la tarea completada.

Volumen de notificaciones: La mediana de usuarios activos recibe 8 notificaciones por dia. Los usuarios avanzados (P95) reciben alrededor de 30. No hemos visto fatiga de notificaciones en nuestras encuestas, probablemente porque cada notificacion representa un evento accionable, no una actualizacion de estado.

Patrones de silencio: El 15% de los usuarios configuran reglas de "modo de enfoque" que agrupan notificaciones que no son de aprobacion durante ciertas horas. Las notificaciones de aprobacion siempre se entregan inmediatamente independientemente del modo de enfoque, porque una aprobacion detenida bloquea toda la tarea.

Proximos pasos

Estamos trabajando en varias mejoras de notificaciones:

• Notificaciones enriquecidas con vista previa de codigo — Notificaciones de aprobacion que muestran una vista previa del diff directamente en la notificacion, para que puedas tomar decisiones informadas de aprobar/rechazar sin abrir la app.
• Agrupacion de notificaciones — Agrupacion de completaciones rapidas de tareas (comunes en flujos de trabajo multi-sesion) en una sola notificacion resumida.
• Sonidos de notificacion personalizados — Senales de audio distintas para completaciones, aprobaciones y errores, para que puedas clasificar por sonido sin mirar tu telefono.

Para opciones de configuracion de notificaciones, consulta la guia de Configuracion de Notificaciones. Para la referencia de hooks de Claude Code que impulsa este sistema, consulta Integracion de Hooks.