Gli agenti AI entrano nel lavoro quotidiano di chi sviluppa software per pianificare i percorsi. Un’indagine condotta da Kardinal, specialista nell’ottimizzazione delle rotte dal 2015, tra il 1° luglio e l’8 settembre 2026 rileva che il 35% degli sviluppatori, CTO e responsabili tecnici intervistati li utilizza ogni giorno. Il problema principale resta però la distanza tra pianificazione e operatività: per il 56%, i percorsi elaborati dagli strumenti non corrispondono alle condizioni reali. Una difficoltà che riguarda sia le soluzioni costruite internamente sia quelle acquistate.
Accanto agli utilizzatori quotidiani, il 23% dichiara di ricorrere agli agenti occasionalmente, mentre il 17% non li usa affatto. Claude Code è lo strumento più citato, davanti a GitHub Copilot, e la maggior parte degli utenti combina più strumenti. L’adozione descritta dall’indagine riguarda dunque il processo di sviluppo dei software di pianificazione: gli agenti affiancano i team tecnici nella costruzione delle applicazioni con cui vengono organizzati i percorsi.
Nella graduatoria delle difficoltà, dopo lo scarto tra rotte pianificate e realtà vengono le prestazioni e i tempi di calcolo, indicati dal 47% degli intervistati, e il continuo cambiamento delle esigenze aziendali, segnalato dal 43%. Il 39% fatica persino a stabilire se un percorso pianificato sia valido. Un partecipante descrive così il problema: «È difficile sapere se un percorso ottimizzato sia davvero migliore di uno costruito empiricamente da un autista esperto». Seguono il costo degli strumenti, al 37%, e l’integrazione nel sistema informativo, al 30%.
Lo sviluppo interno rimane la scelta più diffusa: il 56% dei team ha realizzato un proprio strumento di pianificazione. Il panorama operativo comprende però anche soluzioni più tradizionali. Quasi un terzo degli intervistati, il 31%, utilizza ancora fogli di calcolo, almeno per una parte delle attività. La stessa quota ricorre a software pronti all’uso o a un’API. Queste modalità spesso convivono: quasi metà dei team che sviluppano internamente affianca alla propria soluzione almeno un altro strumento.
La costruzione di un sistema proprietario non elimina il divario con le condizioni sul campo. Nel confronto riportato dall’indagine, questa difficoltà interessa il 51% dei team che sviluppano internamente e il 50% degli altri. I valori sono quasi identici: la scelta di realizzare il software in azienda lascia quindi aperto il problema di rappresentare ciò che accade durante l’esecuzione delle consegne.
Alla realizzazione del prodotto si aggiunge il lavoro necessario per mantenerlo. Tra gli intervistati che gestiscono una propria soluzione, il 35% segnala una manutenzione regolare e il 18% un impegno elevato, con risorse dedicate. Soltanto il 12% dichiara che lo strumento richiede uno sforzo quasi nullo. Per questi team, il carico di lavoro prosegue quindi anche dopo lo sviluppo iniziale, assorbendo tempo e personale.
Quando valutano i fornitori, i responsabili tecnici chiedono maggiore trasparenza economica. Il 65% è fortemente infastidito dall’assenza di prezzi pubblici e il 26% rifiuta persino di prendere in esame uno strumento che non li esponga. La preoccupazione principale, indicata dal 41%, è una fattura che possa crescere eccessivamente. La valutazione commerciale comprende così anche la possibilità di conoscere la spesa prima di adottare il prodotto, oltre alle caratteristiche tecniche della soluzione.
Sul piano tecnologico, algoritmi e risolutori potenti sono già disponibili come open source. La differenza passa dalla capacità di tradurre in un modello i vincoli operativi: finestre temporali di consegna, baie di carico, veicoli refrigerati e abitudini dei clienti. Sono questi elementi a collegare il calcolo alle esigenze delle imprese e di chi riceve la merce. Finché restano fuori dal modello, anche il percorso ottimale conserva un valore teorico, distante dalle condizioni che autisti e operatori devono affrontare.