Da qualche parte nella scheda di un cliente, in mezzo a una nota qualunque su una telefonata qualunque, c’è una frase come questa: “Il budget al momento è stretto, siamo d’accordo di risentirci tra due mesi per riparlarne.”
Scritta una volta. Mai più riguardata. Non perché a qualcuno sia sfuggito che fosse importante, ma perché niente in essa somigliava a un compito. Non era una voce in agenda. Non era un promemoria. Era solo una frase, che faceva quello che le frasi nelle note fanno: stare lì, tecnicamente vera, funzionalmente invisibile.
Volevamo capire se il sistema riuscisse a coglierla da solo, senza che nessuno dovesse ricordarsi di tornare indietro e trasformare a mano una frase in un compito.
Cosa abbiamo davvero costruito, e cosa deliberatamente no
L’istinto con una funzione del genere è lasciare che l’IA gestisca tutto — legga la nota, calcoli la data, decida che è in ritardo, magari abbozzi pure il promemoria. Abbiamo invece diviso il lavoro di proposito.
L’unico compito del modello è la comprensione del linguaggio: leggere le note recenti di un cliente e riconoscere un impegno rivolto al futuro, tipo “ne riparliamo tra due mesi” oppure “risentiamoci dopo il loro consiglio d’amministrazione.” Stima il ritardo implicito in termini semplici. Tutto qui. Ogni calcolo di data vero e proprio — la scadenza, se oggi l’ha superata — avviene dopo, in codice ordinario e deterministico. Il modello non fa mai i calcoli e non prende mai la decisione finale su cosa sia in ritardo. Lui legge. Il codice decide.
Questa divisione conta più di quanto sembri. La comprensione del linguaggio è esattamente il tipo di compito vago, dipendente dal contesto, in cui un modello è bravo. Il calcolo delle date è esattamente il tipo di compito in cui non vuoi che un modello improvvisi, nemmeno un po’.
Il vero test
Non ci siamo limitati a verificare che l’endpoint restituisse qualcosa di ragionevole. Abbiamo scritto una nota vera su una scheda cliente vera: “…siamo d’accordo di risentirci tra 2 mesi per riparlare del budget.” Abbiamo chiamato l’endpoint. Ha estratto correttamente l’impegno, calcolato un ritardo implicito di 60 giorni, ed è arrivato a una scadenza esattamente 60 giorni dopo il timestamp reale della nota, segnalata correttamente come non ancora in ritardo.
Piccolo, ed è proprio questo il punto. Il sistema non ha avuto bisogno che gli si dicesse che c’era un impegno da trovare. Ha letto una frase che una persona aveva scritto per sé, non per un modulo, e ne ha tirato fuori una scadenza reale.
La parte facile da perdere
Le note in Craft11 si possono solo aggiungere. Nessuno le modifica, nessuno le cancella, nemmeno Stark. È lo stesso principio che tiene onesto il lato grezzo di ogni scheda: quello che hai davvero scritto resta esattamente come l’hai scritto. Quando dopo abbiamo dovuto rimuovere la nota di test, non c’era un pulsante elimina a cui ricorrere, perché non deve essercene uno. C’è voluta un’operazione diretta sul database, prima confermata, subito dopo disfatta.
Per noi, in fase di test, è un piccolo fastidio. Ed è la stessa ragione per cui la funzione di rilevamento degli impegni è affidabile fin dall’inizio: legge scrittura umana vera, non alterata, non ripulita, non una sua versione sanitizzata.
Perché vale comunque la pena farlo
Niente di tutto questo sostituisce un gestore di attività. Sostituisce quella specifica, silenziosa modalità di fallimento in cui l’unica traccia di una promessa è una frase che nessuno rileggerà mai. Il sistema non ha bisogno che tu scriva in modo diverso, che strutturi le tue note, o che ti ricordi di segnalare qualcosa. Ha solo bisogno che tu scriva quello che è successo davvero, nel modo in cui lo scriveresti a te stesso, e ci pensa lui a notarlo.