APP Motors verifica tarefas na fábrica a cada cinco minutos e alerta sobre trabalhos parados

O projetista não terminou o desenho, o montador está esperando e o gestor faz ligações para descobrir o motivo. Em uma pequena operação industrial, essa cadeia pode facilmente ficar esquecida diante do próximo pedido urgente. O criador do APP Motors descreveu no Habr seu próprio sistema: as tarefas são criadas por voz pelo celular, conectadas por dependências e acompanhadas por um programa que envia lembretes sobre atrasos. Para desenvolvedores, o ponto útil é uma forma concreta de separar a automação convencional do trabalho de um modelo de linguagem.

Segundo o criador, o desenvolvimento levou cerca de três semanas de trabalho efetivo, à noite e nos fins de semana. O sistema reúne tarefas, ordens de produção, estoque, ferramentas e versões de desenhos. Funcionários da produção já o utilizam, embora o material apresentado não inclua uma verificação independente dos resultados.

Da instrução verbal à tarefa

O fluxo começa no próprio chão de fábrica. Um gestor dita uma tarefa, o celular transcreve a fala e o modelo distribui o texto entre os campos: título, descrição, urgência, prazo e responsável. Uma pessoa revisa o resultado antes da criação da tarefa.

Por exemplo, um pedido para comprar vinte anéis de vedação se transforma em um cartão de compra. Se faltarem as dimensões e o material, o sistema sugere esclarecer a especificação. Ele também pode sugerir um vínculo com uma tarefa existente referente ao mesmo produto. Isso encurta o caminho entre o surgimento de uma necessidade e a tarefa que o responsável pela execução verá.

O servidor procura o funcionário em sua própria base de dados antes de consultar o modelo. Segundo a descrição do criador, o nome é substituído por um marcador interno no texto enviado. Isso reduz a transmissão de dados pessoais, mas não comprova, por si só, que os demais campos não contenham informações sensíveis.

Nessa etapa também surgiu um bug revelador: uma função recebia contexto sobre projetos e tarefas semelhantes, mas não o incluía na requisição ao modelo. Os testes passavam porque simulavam a chamada em um nível acima. O criador acrescentou uma verificação da requisição completa depois de montada. Para uma equipe que esteja implementando um LLM, a lição é prática: também é preciso verificar os dados que realmente chegam ao modelo.

O que envia os lembretes sobre trabalhos parados

A cada cinco minutos, uma tarefa em segundo plano percorre as atribuições ativas. Os lembretes de prazos, a detecção de atrasos e a escolha dos destinatários seguem regras no código. Se o modelo estiver indisponível, esse mecanismo continua funcionando.

As tarefas podem ser conectadas por uma relação de “necessário para”: o desenho é necessário para a peça, e a peça, para a montagem. O programa procura uma tarefa ativa sem subtarefas em aberto e verifica quanto tempo passou desde a última atividade. O limite é de quatro horas para uma cadeia crítica e de dois dias para uma normal. A prioridade é definida pela tarefa mais urgente da cadeia.

Quando o limite é ultrapassado, o responsável recebe um lembrete explicando quem está esperando por seu trabalho. Quem espera recebe uma mensagem sobre o bloqueio. Após a aprovação da subtarefa, o sistema informa que o trabalho pode continuar. As repetições são limitadas, e as notificações não são enviadas à noite.

O modelo entra em ação para preparar recomendações no resumo destinado ao gestor. Durante a varredura noturna dos dados de produção, o SQL identifica primeiro os atrasos; depois, o modelo define as prioridades e redige um resumo. Segundo o criador, o papel atribuído ao agente de IA não tem permissões de escrita nas tabelas de referência da produção. Uma pessoa envia as mensagens sugeridas em nome do gestor.

O que adotar e o que verificar

Um aspecto útil do caso são as regras explícitas de responsabilidade. O responsável pela execução entrega o resultado para revisão com uma fotografia ou um arquivo, e quem criou a tarefa aprova o trabalho ou o devolve com um comentário. Erros de estoque são corrigidos por lançamentos de estorno, as versões dos desenhos são mantidas como registros separados e as ações importantes ficam em um log de auditoria.

O artigo, porém, descreve o funcionamento do sistema, sem demonstrar economia. Não há comparação do tempo de inatividade antes e depois da implantação, nem a proporção de tarefas interpretadas incorretamente ou o custo completo de manutenção. O prazo de desenvolvimento também não pode ser aplicado automaticamente a outra fábrica com processos diferentes.

A métrica escolhida levanta outra questão: um comentário conta como atividade e reinicia a contagem do tempo de inatividade. Isso ajuda a considerar uma explicação para o atraso, mas pode esconder trabalhos que, de fato, não avançam. Ao reproduzir a abordagem, vale acompanhar separadamente a atividade no cartão da tarefa e as mudanças no resultado esperado.

Um ponto de partida prático para a própria equipe é um único processo, como o caminho entre a solicitação de um desenho e a aprovação de uma peça. Primeiro, definir os status, as dependências e os destinatários das notificações; depois, acrescentar a entrada por voz. O impacto deve ser medido pelas tarefas perdidas, pelo tempo de espera e pelo número de lembretes manuais que o gestor precisa enviar.