AudioCassetta | by Cassetta degli AI-trezzi
AudioCassetta | by Cassetta degli AI-trezzi · 15 lug 2026 · 1:00:25
Ascolta nell'app Podli 🎧
Segui i tuoi podcast preferiti, ascolta offline e in auto con CarPlay e Android Auto, e riprendi sempre da dove eri rimasto. Provala gratis.
Qualche settimana fa a Guido è capitata questa scena: manda un link a un cliente per fargli vedere la nuova app. Il cliente clicca, non si apre niente. Era un localhost. Cioè un indirizzo che gira solo sul computer di chi l’ha creato, non su internet.
È capitato anche a me di vedere la stessa scena, se vi state chiedendo perché ve lo racconto con un certo imbarazzo.
Ho intervistato Guido Frigeri, co-fondatore di Kosuke, la startup che ho conosciuto un anno e mezzo fa quando eravamo tra i primi in Italia a “sfondare” i limiti gratuiti di Lovable (lo so è una storia divertente, se vuoi scoprirla senti l’edizione completa di audiocassetta).
Biotecnologo di formazione, laurea a Bologna, tirocinio all’EMBL di Barcellona a contatto con i modelli che poi hanno portato ad AlphaFold, era il 2021, quindi prima di ChatGPT. Poi consulenza sull’innovazione in Italia, poi la startup. Il pattern, dice lui, è sempre lo stesso: gente che smanetta e si costruisce le cose da sola. La sua tesi triennale era una biostampante 3D che stampava cellule umane al posto della plastica.
Il problema che nessuno vede finché non ci sbatte contro
Nell’estate 2025 Guido e i suoi tre co-fondatori guardavano l’esplosione di Lovable e del vibe coding, cioè costruire software parlando in linguaggio naturale invece di scrivere codice. Da un lato la barriera d’ingresso crolla: chiunque può chiedere una feature, un sito, un’app intera. Dall’altro, due limiti che nessuno raccontava con lo stesso entusiasmo: la qualità del codice e la sicurezza.
“Per me era: finalmente non dovrò più parlare con i developer”
mi dice Guido, ricordando la sua fase da utilizzatore sfegatato di Lovable. Poi arriva il problema vero, quello che non si vede finché il prodotto non è in produzione: chi ha creato quell’app non ha idea dei rischi che si porta dietro. Login fatti male, dati esposti, vulnerabilità che nessuno ha mai controllato perché il tool ti fa vedere solo il risultato, non quello che c’è sotto.
Kosuke nasce da qui. Non da un piano industriale scritto a tavolino, ma da un cliente svedese che aveva esattamente questo problema e da un team che si accorgeva di gestirlo bene.
Prima: ticket e attese. Dopo: chi non sa scrivere codice apre una pull request
Il primo prodotto di Kosuke era quasi un servizio: prendevano il codice generato dal team non tecnico di un’azienda e ci mettevano sopra un controllo umano, come una revisione di un documento condivisa che qualcuno deve approvare prima che diventi definitiva. Funzionava, ma non scalava: era troppo legato alla consulenza, un progetto alla volta.
La piattaforma che vendono oggi fa un salto diverso.
Prende tutto lo stack tecnologico di un’azienda, frontend, backend e database, e lo fa girare in cloud dentro un browser. Chiunque nel team, non solo chi scrive codice, può aprire una chat, chiedere una nuova funzione, testarla live, mandare il link a un collega o al cliente. Quando è pronta, apre una pull request, cioè chiede al team tecnico il via libera prima che la modifica finisca online.
I numeri che mi ha dato Guido: l’85% delle richieste va in produzione senza modifiche, il 10% ha bisogno di piccoli aggiustamenti, il 5% viene respinto con una spiegazione scritta del perché. Un CTO cliente gli ha regalato una cassa di vino perché finalmente il backlog di richieste minori veniva smaltito dal team non tecnico, e lui poteva dedicarsi al refactoring vero.
La differenza con Replit o Lovable, mi spiega, non è la produttività individuale del developer che apre venti chat in parallelo invece di venti terminali. È rendere produttivo tutto il team, comprese le persone che un ticket lo scrivono e poi aspettano. Qui aspettano molto meno, ma soprattutto la revisione umana resta un passaggio obbligato: “Non succederà mai che io possa modificare una parte della piattaforma senza che passi da un controllo tecnico,” dice Guido, ed è la frase che mi ha convinto che non stanno vendendo l’ennesimo tool di autonomous coding.
Il pen test nato per errore, diventato il secondo prodotto
Quando Kosuke ha iniziato a fare onboarding di aziende vere, mid-market da 30 a 150 dipendenti, con team tecnici già esistenti che usavano Cursor o Claude Code per generare codice, si sono trovati davanti a un problema collaterale: c’erano già vulnerabilità di sicurezza al momento dell’ingresso. Non necessariamente colpa del vibe coding, spesso solo la normale distanza tra velocità e code review che si accumula quando un team smette di rileggere quello che l’AI scrive.
Hanno iniziato a offrire gratis un penetration test black box, in pratica un tentativo controllato di sfondare l’applicazione da fuori. Prima per i clienti in onboarding, poi per gli amici, poi qualcuno ha chiesto di pagarlo. Le due alternative sul mercato erano un estremo automatizzato e veloce ma qualitativamente debole, oppure il pen test consulenziale classico, settimane di lavoro e costi che una startup non si può permettere. Kosuke ha costruito una pipeline con controllo umano su ogni vulnerabilità trovata e l’ha benchmarkata su XBOW, uno standard di riferimento per la qualità dei penetration test. Primo posto.
Non è un pivot. È un secondo prodotto, dice Guido, perché il core business resta la piattaforma, quella su cui hanno chiuso un round da 1,2 milioni in SAFE. A settembre aprono la sede a San Francisco, quattro persone a tempo pieno, perché lì c’è il mercato dei fondi che hanno raccolto e i partner con cui parlare. Restano un team agnostico rispetto ai modelli: non costruiscono LLM propri, li integrano tutti, aggiornandosi ogni volta che esce qualcosa di nuovo, perché un cliente che vede mancare l’ultimo modello in piattaforma se ne accorge subito.
Critica alla cr
Episodi: AudioCassetta | by Cassetta degli AI-trezzi