APP Motors revisa las tareas del taller cada cinco minutos y avisa cuando el trabajo se estanca

El ingeniero de diseño no ha terminado el plano, el operario de montaje espera y el responsable llama para averiguar el motivo. En una pequeña empresa de fabricación, esta cadena puede quedar fácilmente eclipsada por el siguiente encargo urgente. El creador de APP Motors describió en Habr su propio sistema: las tareas se crean por voz desde el teléfono, se enlazan mediante dependencias y el programa envía recordatorios sobre los retrasos. Para los desarrolladores, lo interesante es una forma concreta de separar la automatización convencional del trabajo de un modelo de lenguaje.

Según su creador, el desarrollo requirió unas tres semanas de trabajo efectivo, por las tardes y los fines de semana. El sistema reúne tareas, órdenes de producción, inventario, herramientas y versiones de planos. El personal de producción ya lo utiliza, aunque el material presentado no incluye una verificación independiente de los resultados.

De la instrucción verbal a la tarea

El proceso empieza en el propio taller. Un responsable dicta un encargo, el teléfono transcribe la voz y el modelo distribuye el texto entre los campos: título, descripción, urgencia, plazo y persona encargada. Antes de crear la tarea, una persona revisa el resultado.

Por ejemplo, una petición para comprar veinte juntas de estanqueidad se convierte en una ficha de compra. Si faltan las dimensiones y el material, el sistema propone aclarar las especificaciones. También puede sugerir un vínculo con una tarea existente relacionada con el mismo producto. Así se acorta el recorrido entre la aparición de una necesidad y el encargo que verá la persona responsable de ejecutarlo.

El servidor busca al empleado en su propia base de datos antes de consultar al modelo. Según explica el creador, el nombre se sustituye por un marcador interno en el texto enviado. Esto reduce la transmisión de datos personales, pero no demuestra por sí solo que los demás campos estén libres de información sensible.

Aquí también apareció un fallo revelador: una función recibía contexto sobre proyectos y tareas similares, pero no lo incluía en la solicitud al modelo. Las pruebas pasaban porque simulaban la llamada en un nivel superior. El creador añadió una comprobación de la solicitud completa una vez construida. Para un equipo que implemente un LLM, la lección es práctica: también hay que verificar los datos que realmente llegan al modelo.

Qué envía los recordatorios sobre trabajos estancados

Cada cinco minutos, una tarea en segundo plano recorre los encargos activos. Los recordatorios de plazos, la detección de retrasos y la selección de destinatarios se rigen por reglas en el código. Si el modelo no está disponible, este mecanismo sigue funcionando.

Las tareas pueden vincularse mediante una relación de «necesario para»: el plano hace falta para fabricar la pieza, y la pieza, para el montaje. El programa busca una tarea activa sin subtareas pendientes y comprueba cuánto tiempo ha pasado desde la última actividad. El umbral es de cuatro horas para una cadena crítica y de dos días para una normal. La prioridad viene determinada por la tarea más urgente de la cadena.

Cuando se supera el umbral, la persona encargada recibe un recordatorio que explica quién está esperando su trabajo. Quienes esperan reciben un mensaje sobre el bloqueo. Tras la aceptación de la subtarea, el sistema avisa de que el trabajo puede continuar. Las repeticiones están limitadas y no se envían notificaciones por la noche.

El modelo interviene para preparar recomendaciones en el resumen destinado al responsable. Durante la revisión nocturna de los datos de producción, SQL detecta primero los retrasos; después, el modelo los prioriza y redacta un resumen. Según el creador, el rol del agente de IA no tiene permisos de escritura en las tablas de referencia de producción. Una persona envía los mensajes propuestos en nombre del responsable.

Qué adoptar y qué comprobar

Un aspecto útil del caso son sus reglas explícitas de responsabilidad. La persona encargada entrega el resultado para su revisión con una fotografía o un archivo, y quien creó la tarea acepta el trabajo o lo devuelve con un comentario. Los errores de inventario se corrigen mediante asientos de reversión, las versiones de los planos se conservan como registros separados y las acciones importantes quedan recogidas en un registro de auditoría.

Sin embargo, el artículo describe el funcionamiento del sistema, sin demostrar un ahorro. No compara los tiempos de inactividad antes y después de la implantación, ni aporta la proporción de encargos interpretados incorrectamente o el coste completo de mantenimiento. Tampoco se puede trasladar automáticamente el plazo de desarrollo a otra fábrica con procesos distintos.

La métrica elegida plantea otra cuestión: un comentario cuenta como actividad y reinicia el contador de inactividad. Esto permite tener en cuenta una explicación del retraso, pero puede ocultar trabajos que en realidad no avanzan. Al reproducir el esquema, conviene registrar por separado la actividad en la ficha y los cambios en el resultado esperado.

Un punto de partida práctico para un equipo es un único proceso, por ejemplo, el recorrido desde la solicitud de un plano hasta la aceptación de una pieza. Primero hay que definir los estados, las dependencias y los destinatarios de las notificaciones; después, añadir la entrada por voz. El impacto debe medirse por los encargos perdidos, el tiempo de espera y el número de recordatorios manuales que debe enviar el responsable.