Continuo a vedere passare nel feed una frase di Rob Saker: "La business logic sta migrando da codice scritto da ingegneri specializzati a file markdown che chiunque abbia expertise di dominio può scrivere". Voglio fermarmi un secondo su quella frase, perché fa più lavoro di quanto la gente pensi.
I due tipi di conoscenza
Ogni prodotto software poggia su due tipi di conoscenza. Uno: come funziona il dominio. Cosa cerca davvero un radiologo. Come prezza davvero un container uno spedizioniere. Cosa segnala davvero un ispettore fiscale. Due: come trasformarlo in codice che gira.
Il founder storicamente vendeva il ponte tra i due. Trovava qualcuno con conoscenza di dominio, aggiungeva qualcuno con competenze di coding, o era lui stesso un raro ibrido. Il prodotto era il ponte. Il fossato era "so fare entrambe le cose".
Ecco la questione. La conoscenza di dominio vive nel cliente. È sempre stato così. Il radiologo è il cliente. Lo spedizioniere è il cliente. L'ispettore fiscale è il cliente. Il founder non è mai stato il depositario di quella conoscenza. Era un traduttore, assunto dalle circostanze perché il cliente non sapeva programmare.
Il fossato era la competenza di coding
Non il software. La competenza di coding. Il software era l'output. Il fossato era la cosa che generava l'output, e il fossato non aveva niente a che vedere con il capire il problema del cliente. Il fossato era sapere Python, o React, o come cablare una pipeline CI.
Quando il fossato è "so fare una cosa che il cliente non sa fare", e quella cosa è qualcosa che gli agenti AI stanno collassando verso un costo prossimo allo zero, il fossato non è un fossato. È una dilazione. Una dilazione che finirà a una data ignota, di solito prima di quanto chi la possiede speri.
Il cliente non ti ha mai pagato per il tuo codice. Ti ha pagato per il suo codice, che tu ti sei trovato a scrivere.
Cosa succede quando il compilatore si sposta
Tra due anni, forse tre, il ponte smette di aver bisogno di un traduttore. Un agente chiede al radiologo cosa gli serve. Il radiologo, che lo fa da vent'anni, spiega in linguaggio naturale. L'agente costruisce lo strumento. Il radiologo itera. Nessun intermediario. Nessun product manager. Nessuna trattativa sulla roadmap. Nessuna fattura SaaS.
Suona utopico. Non lo è. Sarà caotico, produrrà molto software pessimo, e molti clienti scopriranno che in realtà non volevano costruire i propri strumenti, volevano che qualcun altro costruisse strumenti che loro avrebbero approvato. Era sempre stata quella la value proposition vera del software verticale. Approvazione, non costruzione.
Ma una buona fetta di clienti scoprirà che sì, vogliono costruirseli da soli. E quando lo faranno, l'intermediario sparisce.
L'uscita asimmetrica
Se sei un founder dentro questa compressione, c'è una mossa che funziona. Smetti di essere il software. Diventa lo standard. O i dati. O il layer di fiducia. O la certificazione. O la relazione con il regolatore. Diventa qualcosa che il cliente non può generare, per quanto buono diventi il suo compilatore.
I solo founder che sopravviveranno al prossimo ciclo saranno quelli che capiscono, in fretta, che il codice che hanno scritto non era mai stato l'asset. L'asset era la relazione con il cliente, la conoscenza dei casi limite, la rete di altri clienti che si fidano del brand. Tutto il resto diventerà un file di testo.
C'è una frase di Jaron Lanier a cui penso ogni volta che arrivo qui. "La tecnologia non è mai la storia. La storia è sempre cosa decidiamo di fare con la tecnologia". Stiamo decidendo, in questo momento, se i prossimi cinque anni di AI renderanno ricchi i founder o indipendenti i clienti. Non è chiaro cosa stiamo scegliendo. È molto chiaro cosa stanno scegliendo gli strumenti.