Il nostro prodotto non usa l'AI. È una decisione, non una mancanza.

C’era, in questo progetto, un posto ovvio in cui mettere un modello, ed è esattamente quello in cui abbiamo deciso di non metterlo.

Metroquadro, il marketplace di spazi di stoccaggio a cui stiamo lavorando, chiede all’operatore di pubblicare il proprio deposito unità per unità, così che chi cerca un magazzino ne veda l’interno reale invece della solita fotografia della facciata; il primo compito che gli tocca, però, è anche il più ingrato, perché prima di affittare qualunque cosa deve disegnare la planimetria, vale a dire la sagoma del capannone, i corridoi e i box che intende ricavarne. È lì che la dimostrazione si scriverebbe da sé: si caricano le misure, si scrive «disegnami la planimetria migliore» e in pochi secondi compare sullo schermo qualcosa di plausibile, tanto che nel 2026 nessuno si prende più la briga di chiedere come funzioni. Noi abbiamo scelto di non farlo.

Che cosa abbiamo messo al posto del modello

Al suo posto c’è un algoritmo di impacchettamento a righe, deterministico, lungo poche decine di righe di Python e privo di qualunque chiamata di rete, il cui commento di apertura dichiara con una certa franchezza che cosa voglia essere e, soprattutto, che cosa non voglia essere:

«Un punto di partenza che il venditore poi modifica, non un ottimizzatore. Nessuna casualità: lo stesso input produce sempre lo stesso layout.»

Si inseriscono la sagoma, la larghezza del corridoio e il mix di unità desiderato, e i box vengono disposti in righe nell’ordine in cui sono stati chiesti; ciò che non entra, poi, non svanisce nel nulla ma torna indietro sotto forma di elenco esplicito raggruppato per misura — tre unità da sei metri quadri non ci stanno — e non si tratta di un caso limite risolto con eleganza, bensì di metà del valore della funzione. Non è un algoritmo furbo, va detto; ma il problema non chiedeva astuzia, chiedeva prevedibilità.

Perché quello era il punto sbagliato

Le ragioni sono tre, e sono tutte più noiose dell’idea di un modello linguistico che disegna capannoni.

La prima è che la bozza esiste per essere modificata: l’operatore la riceve e comincia immediatamente a lavorarci sopra, trascina, ruota, sposta il pilastro dove sta davvero e allarga il corridoio perché di lì deve passare il muletto, cosicché, se rigenerandola ottenesse ogni volta un risultato diverso, quella bozza smetterebbe di essere un punto di partenza per diventare un oracolo, qualcosa che si consulta anziché qualcosa su cui si costruisce; e la riproducibilità, in un contesto simile, non è un vezzo tecnico ma la condizione stessa perché lo strumento risulti utilizzabile.

La seconda è che il risultato deve poter essere spiegato a chi paga l’affitto, giacché «perché in questo corridoio ci stanno sei box e non sette?» è una domanda che l’operatore prima o poi si sentirà rivolgere, e alla quale dovrà rispondere con una regola — la larghezza, la tolleranza, il passaggio minimo da garantire — e non con un imbarazzato «l’ha proposto il sistema».

La terza, e la più concreta, è che in questo mestiere l’errore è geometrico e definitivo: un’unità che si sovrappone a un pilastro non è una risposta appena peggiore delle altre, ma un metro quadro che non esiste affittato a qualcuno che ha in mano un contratto, e non c’è soglia di confidenza che renda accettabile un risultato del genere.

Il criterio, ridotto all’osso

L’intelligenza artificiale rende dove l’input è vario e il costo dell’errore è basso, e un assistente che riscrive la descrizione di un annuncio ne è l’esempio perfetto, perché gli si può dare qualunque cosa e nel peggiore dei casi lo sbaglio costa una rilettura; lo stesso vale per un estrattore che ricava dati da documenti eterogenei, che ha esattamente la medesima forma. Qui accade il contrario, dal momento che l’input sono tre numeri e una lista — metri, larghezza del corridoio, mix di unità — che non hanno nulla di ambiguo, non sono testo libero e non chiedono affatto di essere interpretati, mentre l’errore, come si è visto, costa un contratto. Nel nostro documento di prodotto l’ottimizzatore di layout resta comunque iscritto tra i candidati successivi all’MVP, accompagnato da una nota che vale come regola generale — prima un risolutore di vincoli, il machine learning soltanto se giustificato — perché lasciare la porta aperta non equivale ad averla già varcata.

Dove i vincoli li abbiamo messi sul serio

In questo prodotto la certezza non si compra con la potenza del modello, ma con i vincoli, e a patto di collocarli dove nessuno possa aggirarli. Le due regole geometriche — nessuna unità sovrapposta a un’altra, niente che sporga dalla sagoma — valgono tanto nel browser quanto sul server, e se la prima verifica è una cortesia verso chi disegna, la seconda è quella che conta davvero; allo stesso modo le doppie prenotazioni sono impossibili perché lo stabilisce il database e non perché il codice stia attento, dato che un vincolo di esclusione su Postgres rifiuta due prenotazioni sovrapposte sulla stessa unità qualunque cosa faccia l’applicazione e sotto qualsiasi concorrenza, cosicché due clienti che facciano clic nel medesimo istante ottengono un errore gestito e un messaggio chiaro, e mai due contratti sullo stesso box.

La parte che di solito non si racconta

Questa storia ha un epilogo a nostre spese, ed è accaduto proprio su queste pagine. Il chatbot che risponde alle domande sul nostro sito è un sistema RAG e, interrogato su Metroquadro, ha spiegato con disinvoltura che il prodotto offre «un editor con vincoli intelligenti», contraddicendo la scheda di conoscenza che noi stessi gli avevamo fornito e nella quale è scritto nero su bianco che qui dentro non c’è alcuna componente di intelligenza artificiale. La colpa, tuttavia, non era del modello, bensì del modo in cui avevamo spezzettato il testo, con finestre di lunghezza fissa e cieche rispetto alle sezioni: la precisazione si trovava in fondo alla scheda, ossia nel secondo frammento, mentre la ricerca semantica, sollecitata da una domanda sull’editor, restituiva soltanto il primo, sicché il modello ha ricevuto l’affermazione priva del vincolo che la limitava e ha colmato il vuoto con l’aggettivo che aveva più a portata di mano. La correzione, come si intuisce, è stata editoriale e non architetturale, ed è consistita nello spostare il vincolo dentro il medesimo frammento dell’affermazione che esso vincola.

È il principio che ci portiamo dietro da quel giorno: un modello non sa ciò che non gli abbiamo dato, e quel vuoto non resterà vuoto, perché verrà riempito con qualcosa di verosimile, spesso proprio con la parola che si voleva escludere.

A che punto siamo

Metroquadro è in pilota: i pagamenti e la verifica dell’identità sono simulati dietro un’interfaccia già predisposta per l’integrazione vera, non c’è un prezzo perché un modello di ricavo ancora non esiste, e non è dunque un prodotto che si compra, cosa che preferiamo dire adesso piuttosto che dopo. Quello che cerchiamo sono da tre a cinque operatori self-storage italiani, con un accordo tanto semplice da stare in una riga: tu ci porti una struttura vera, noi la mappiamo su Metroquadro e la facciamo funzionare insieme; come si comporta, del resto, lo si capisce in un paio di minuti — planimetria, vista isometrica, prenotazione — nella pagina del prodotto.

Hai un problema davanti al quale non sei certo che serva un modello? Scrivici: a volte la risposta onesta è no, e vale comunque la pena parlarne.