Archive for category: Governance

Capita in ogni progetto (soprattutto digitale): arrivano le richieste con una soluzione dentro: le richieste non sono “abbiamo questo problema”, ma “vogliamo fare questa cosa”. Quando chiedi da dove viene quella certezza, la risposta è qualcosa come: “Ho visto come l’ha fatto un competitor” oppure “L’ho provato e funziona”.Quella certezza, quasi sempre, nasce da un’esposizione superficiale a qualcosa di complesso. E oggi quella esposizione è diventata più rapida, più convincente e più accessibile che mai.

Read more: Aristotele, logica e Intelligenza Artificiale

Nuovi problemi vecchi

Claude Design, l’ultimo strumento che ha alimentato il dibattito su AI e professioni creative, non ha inventato nulla di strutturalmente nuovo, ma ha reso più visibile una dinamica che esiste da quando esistono gli strumenti digitali:

abbassare la soglia di accesso a un dominio non equivale ad abbassare la soglia di competenza in quel dominio.

La differenza è che oggi quella soglia si abbassa in dieci minuti invece che in dieci mesi e questo cambia molto, ma non nel modo in cui il dibattito tende a descriverlo.

In mano a un designer, Claude Design fa quello che ogni buono strumento fa quando viene usato da chi ha conoscenza dichiarativa: accelera l’output e ne migliora la qualità.

Il designer sa cosa sta chiedendo, sa valutare quello che ottiene, sa quando il risultato è sbagliato anche se sembra convincente. Lo strumento moltiplica la competenza esistente.

In mano a un non-designer, fa qualcosa di diverso e altrettanto utile:

consente di effettuare iterazioni, di arrivare alla conversazione con l’altra persona con qualcosa in mano, non per sostituire quella conversazione, ma per renderla molto più produttiva.

Il collo di bottiglia

Per anni, la sperimentazione iniziale in qualsiasi progetto digitale aveva un costo (a volte nascosto) importante: richiedeva l’interazione tra persone diverse prima ancora che il lavoro reale iniziasse.

• Volevi esplorare tre varianti di un’interfaccia? Serviva un designer.
• Volevi capire se una soluzione era tecnicamente praticabile? Serviva uno sviluppatore.

Nel frattempo, chi aveva l’idea aspettava, il designer riceveva un brief vago, lo sviluppatore riceveva un wireframe sbagliato, e il ciclo ricominciava in una lunghissima partita a pong.

Quel ciclo ha un nome: fase di esplorazione ¹ e aveva un costo che pochi mettevano a budget ² perché non era visibile, distribuito nel tempo di tutte le persone coinvolte.

Watt Humphrey aveva descritto questo problema con una precisione che non ha perso nulla in trent’anni:

“For a new software system, the requirements will not be completely known until after the users have used it.”

³

L’incertezza sui requisiti non è cattiveria, non è incompetenza, ma è la natura del problema. Le persone arrivano con idee confuse non perché non si siano impegnate, ma perché un requisito diventa noto solo quando viene testato. Prima di quel momento, quello che abbiamo non è un requisito: è un’ipotesi.

Agile e Lean Startup hanno portato questa idea al centro della pratica professionale e dovrebbe essere patrimonio comune ormai. L’MVP (il Minimum Viable Product – Minimo Prodotto Fattibile) non è una versione economica del prodotto finale: è uno strumento epistemico. Serve infatti a validare le assunzioni critiche prima di investire sulla realizzazione ⁴.

La sperimentazione non è “proviamo e vediamo cosa succede”; è un’attività disciplinata.

• Cosa voglio capire?
• Quale ipotesi sto testando?
• Cosa mi dirà che avevo ragione o torto?

Senza quelle domande, il prototipo non è un esperimento: è un’impressione con un’interfaccia sopra.

Un elemento costante

La versione zero, l’esplorazione, il prototipo, il wireframe grezzo, ha un costo che si è ridotto drasticamente: meno persone coinvolte, meno cicli di andata e ritorno, meno tempo perso a spiegare cosa si intende. Evviva.

Attenzione: la versione finale richiede ancora le stesse figure di prima [Ref]Da questo punto di vista ho dei dubbi sul fatto che sia effettivamente più economico: l’altro giorno è apparsa una notizia nella quale il CTO di Uber ha detto che hanno già finito il budget AI 2026 in questi primi mesi. Meno persone ok, ma il costo dei tool è interessante[/ref].

Figure che con gli strumenti AI, lavorano in modo strutturalmente diverso. Non meno: diversamente. A tal proposito è molto bello il racconto di Matteo Bossolini, co-founder di Cato, nell’ultimo episodio di Cosa Sposta: il programmatore non scrive meno codice perché è diventato pigro, ma perché è diventato architetto ⁵.

Il designer con Claude Design arriva alla soluzione più velocemente perché ha già eliminato le opzioni ovviamente sbagliate.

Lo sviluppatore con Claude Code produce l’architettura del sistema più in fretta perché ha già testato tre approcci senza scrivere una riga.

La competenza non vale meno; vale nel momento giusto, sul problema giusto.

Rispettare il tempo dei colleghi significa arrivare alla conversazione con un semilavorato che ha già attraversato un ciclo di verifica personale. Non “ho un’idea”, ma “ho testato questa ipotesi, ho visto che non funziona così, e voglio capire se la direzione è giusta”. Quella è la versione zero fatta bene.

Il rischio di distorsione

C’è però un effetto collaterale che va nominato senza eufemismi, e che Luca Sartoni ha descritto in un bel post: chi produce la versione zero tende a dimenticare che è una versione zero.

Non è pigrizia, non è malafede: quando in dieci minuti ottieni qualcosa che sembra un risultato professionale, il cervello registra competenza acquisita. E quella sensazione, quando incontra il potere decisionale, produce esattamente il danno che Luca descrive:

il lavoro degli esperti viene scavalcato, le risorse vengono allocate su basi emotive, chi ha competenza di dominio si trova a difendere scelte che non avrebbe mai fatto.

Il problema non è lo strumento, ma la mancanza di una distinzione operativa che le organizzazioni non stanno ancora facendo in modo esplicito: chi può produrre la versione zero (sempre di più) e chi può validare la versione finale (gli stessi di prima) sono due ruoli diversi e confonderli costa<.

Ma Aristotele?

C’è un concetto che Google ha sviluppato anni fa e che non ha mai ricevuto l’attenzione che merita fuori da alcune cerchie di sviluppo prodotto: il pretotyping.

In estrema sintesi il pretotyping aiuta a capire se ha senso fare qualcosa, il prototipo è già ragiona sul come fare a realizzare La distinzione con il prototipo è semplice ma fondamentale. Il pretotyping risponde alla domanda “ha senso farlo?”; il prototipo risponde alla domanda “Riusciamo a farlo?”. Sono due domande diverse, con due strumenti diversi e due momenti diversi ⁶.

La sperimentazione con gli strumenti AI vive esattamente nel primo spazio: serve a capire cosa ha senso fare prima di chiedere a qualcuno di farlo e portarlo alla finalizzazione.

Ed è qui che entra in gioco qualcosa che Aristotele aveva formalizzato ventiquattro secoli fa: il principio di non contraddizione.

A non può essere contemporaneamente A e non-A.

Il lavoro di sperimentazione non può essere contemporaneamente sperimentazione e prodotto finale. Non è una questione di contesto o di ottimismo: è una contraddizione in termini.

A è il pretotipo. Non-A è il prodotto. A non diventa non-A per accumulo di iterazioni: diventa non-A quando qualcuno con le competenze giuste decide che l’ipotesi è stata validata e che vale la pena realizzarla.

Confondere i due momenti non è efficienza; è saltare la domanda più importante.

Peccato che saltare la domanda più importante nell’era in cui gli strumenti AI rendono tutto più veloce costi più di prima perché la velocità amplifica gli errori di metodo, non li corregge.

BONUS: grafica by Gemini