Dal founder

L'AI agentica entra in produzione più in fretta di quanto i team riescano a revisionarla. Il gap tra capability del modello e fiducia di prodotto è reale, in crescita, e oggi viene riempito da documentazione statica, pattern vendor-locked e persone che ci si arrangiano da sole. Dopo diciassette anni passati a lavorare su questioni di fiducia di prodotto in forme diverse, più di recente come AI strategy lead trasversale a design, research e brand in una travel company nel Regno Unito, ho iniziato a costruire il Blueprint come la versione di quel lavoro che non entrava nel ruolo del day job.

C'è una motivazione più silenziosa accanto a quella strategica: volevo portare avanti un tentativo da 0 a 1 fino alla sua conclusione logica, da solo, per scoprire cosa la lettura di una sola persona di una disciplina emergente riesce a produrre quando nessun comitato o roadmap dà forma al lavoro. La piattaforma potrebbe diventare un business, oppure restare come evidenza di quanto valeva la bet. Entrambi gli esiti sono onesti. Il lavoro ha valore proprio in ognuno dei due casi.

La cosa che vorrei di più dimostrare sul Blueprint non sono i principi. È il loop che la piattaforma applica a sé stessa.

Un brand agent fa l'audit di ogni pull request contro un catalogo numerato di smell di voce prima del merge. Il validator che dà uno score alle architetture agentiche di altri viene eseguito contro il source code della piattaforma stessa, con i finding ripiegati nell'iterazione successiva. Ogni readiness score sul sito è collegato a un run-id pubblico con la storia completa di iterazioni visibile a chiunque clicchi. La disciplina che la doctrine chiede agli altri, la piattaforma prova ad applicarla prima a sé stessa.

Non è perfetto. È la versione più onesta che abbia trovato del working out loud mentre si costruisce qualcosa il cui oggetto è esattamente il tipo di sistema che si sta costruendo. Il loop è visibile nel codebase, nei report di audit e nelle pagine di review pubbliche. Se qualcosa è overclaimato, l'audit lo intercetta prima del merge oppure lo si trova nel diff dopo.

Una pagina che porta in superficie il loop di audit pubblicamente, così l'integrità ricorsiva è leggibile senza dover guardare il source code. Più editoriale in registro field-report, che attinge a quello che il lavoro ha effettivamente portato in evidenza più che a quello che la doctrine suggerisce. Una presenza continuata nelle community di builder dove il wedge viene testato in conversazioni reali. La closed beta è aperta a practitioner che hanno sistemi agentici reali in produzione; il form di applicazione è onesto su cosa il validator fa e su cosa non fa ancora.

L'architettura è più larga della superficie oggi visibile. Le pagine recupereranno copertura nel tempo. I vincoli sono onesti: questo è costruito in serata e nei weekend, da una persona sola, accanto a un ruolo full-time. Il ritmo riflette quello, e così pure la velocità di cambiamento. Entrambe le cose fanno parte della bet.

Le conversazioni tra practitioner sono benvenute su LinkedIn o GitHub. Il form della closed beta è la via d'ingresso per builder che vogliono accesso al validator. I thread più utili sono di solito di due tipi: "abbiamo messo in produzione qualcosa che la doctrine dovrebbe conoscere", oppure "questa parte non regge, ecco perché". Entrambi fanno compounding sul lavoro.