Ishraq Khan, CEO e Fondatore di Kodezi Inc – Serie di Interviste

Ishraq Khan, CEO e Fondatore di Kodezi Inc., è un programmatore autodidatta che ha iniziato a programmare all’età di otto anni e ha lanciato la sua prima startup mentre era ancora alle scuole medie. Nato a Dhaka, in Bangladesh, e successivamente trasferitosi negli Stati Uniti, ha costruito un curriculum di imprenditorialità precoce, ottenendo finanziamenti per venture capital durante le scuole superiori e scalando un prodotto a più di 100.000 utenti. Il suo percorso riflette una focalizzazione sull’apprendimento indipendente, sulla sperimentazione rapida e sulla spinta a costruire sistemi che rendono la tecnologia più accessibile e potente per gli sviluppatori.

Kodezi Inc. è l’azienda dietro Kodezi OS, una piattaforma autonoma progettata per funzionare come un “CTO AI” per i team di ingegneria. Continuamente rileva e risolve problemi, documenta automaticamente i sistemi, genera specifiche API, applica gli standard di codifica e si integra direttamente nelle pipeline CI/CD. Trasformando le basi di codice in sistemi auto-risananti e auto-governanti, Kodezi aiuta le organizzazioni a costruire software più affidabili, scalabili ed efficienti.

Hai iniziato a programmare a soli otto anni e fondato la tua prima startup alle scuole medie. Cosa ti ha originariamente attirato verso la costruzione di software così presto, e come quelle esperienze hanno plasmato la tua mentalità imprenditoriale?

Ciò che mi ha attirato era il controllo. Mi sono trasferito negli Stati Uniti come un bambino che non parlava inglese, quindi la prima lingua che ho imparato fluentemente è stato il codice. Era uno spazio in cui la logica aveva senso, in cui potevo costruire qualcosa e vederlo rispondere istantaneamente. Quel ciclo di feedback istantaneo è diventato dipendente. Mi ha insegnato a pensare, non solo a programmare.

Quando ho costruito TeachMeCode alle scuole medie, non era questione di fondare un’azienda. Era questione di rendere l’apprendimento più facile per persone come me. Ma attraverso quello, ho imparato come si comportano i sistemi, come rispondono gli utenti e come avviene il progresso riga per riga. Ha plasmato come vedo l’imprenditorialità oggi: meno questione di idee, più questione di cicli di feedback, iterazione e resilienza.

Sei stato accettato in 40 college, tra cui diverse istituzioni della Ivy League, ma hai scelto di non frequentarle. Qual è stato il punto di svolta che ti ha fatto decidere che costruire era più importante dell’attesa?

Quando ho finito le scuole superiori, avevo già vissuto ciò che la maggior parte delle persone va al college per simulare. Avevo lanciato prodotti, presentato proposte a investitori, gestito un team e risolto problemi reali. Avevo 40 lettere di accettazione sulla mia scrivania, tra cui diverse scuole della Ivy League, ma avevo anche qualcosa che la maggior parte degli studenti non aveva: slancio.

Il rischio più grande era rallentare. Il college mi avrebbe insegnato framework per l’innovazione, ma io stavo già conducendo esperimenti nel mondo reale. Non volevo interrompere un sistema attivo per studiare come iniziarne uno. Per me, l’aula è diventata il prodotto stesso. Kodezi è stata l’istruzione che volevo.

Kodezi è iniziata come un’idea quando eri ancora un teenager. Come è evoluta l’azienda dal suo inizio nel 2019, e come è emersa la tua visione di un “CTO AI” nel tempo?

Kodezi è iniziata come un autocorrettore per il codice, un’idea semplice che il debugging poteva essere più veloce. Mentre abbiamo scalato, ho realizzato che il debugging non era il problema di base. Il problema reale era che le basi di codice non rimangono ferme. Evolvono, deragliano e decadono più velocemente di quanto gli esseri umani possano mantenerle.

Nel tempo, Kodezi è evoluta da un prodotto a un sistema operativo, ciò che ora chiamiamo Kodezi OS, che apprende da ogni bug, test e commit. Il termine “CTO AI” è emerso naturalmente. I CTO non scrivono solo codice; mantengono l’architettura, guidano le decisioni e mantengono i sistemi vivi. È ciò che fa Kodezi, ma in modo continuo e autonomo.

Il modello più recente di Kodezi, Chronos, è descritto come il primo sistema AI costruito specificamente per il debugging del codice, piuttosto che per la generazione del codice. Qual è la differenza fondamentale che questo distingue fa per gli sviluppatori?

Perché il debugging è la realtà, non l’immaginazione. La generazione del codice è questione di indovinare cosa potrebbe funzionare; il debugging è questione di capire perché qualcosa è fallito.

La maggior parte degli strumenti AI oggi sono assistenti basati su prompt che reagiscono quando vengono istruiti. Chronos, d’altra parte, è proattivo. Ricorda bug precedenti, comprende grafici di dipendenza, esegue test, convalida correzioni e le raffina fino a quando il problema non viene effettivamente risolto.

È la distinzione che conta. Gli sviluppatori non vogliono un assistente che parla. Vogliono un’infrastruttura che agisce e agisce correttamente.

I risultati che hai condiviso mostrano Chronos che supera GPT-4.1 e Claude 4 Opus in termini di accuratezza della correzione dei bug. Puoi spiegarci il set di dati e la metodologia dietro quei benchmark?

La nostra valutazione è empirica, non promozionale. Chronos è testato su migliaia di casi di debugging del mondo reale tratti da set di dati pubblici come SWE-bench, Defects4J e BugsInPy, insieme a dati aziendali anonimi.

Ogni benchmark è rigoroso: il modello deve generare una patch, applicarla e superare tutti i test senza regressioni. Nessun esempio selezionato a mano, nessun successo selezionato.

Chronos raggiunge il 67,3% di accuratezza delle correzioni e l’80,33% di tasso di risoluzione su SWE-bench Lite, mentre GPT-4.1 e Claude 4.5 rimangono al di sotto del 15%. La differenza non è la dimensione; è la specializzazione. Chronos è addestrato sul debugging stesso, su 15 milioni di sessioni di debugging reali, quindi non solo trova pattern, ma diagnostica.

Hai descritto Kodezi come un “CTO AI” che mantiene e evolve autonomamente la base di codice di un’azienda. Quanto siamo vicini a un’infrastruttura completamente auto-risanante in ambienti di produzione?

Più vicini di quanto pensano la maggior parte delle persone, almeno per i sistemi deterministici. Oggi, Kodezi può autonomamente correggere molti fallimenti CI o CD, regressioni di test e errori di runtime utilizzando dati contestuali e memoria storica.

La manutenzione della produzione completamente autonoma, in cui l’infrastruttura diagnostica, risana e ridistribuisce se stessa, sta emergendo. La vedo evolversi in fasi: prima all’interno di ambienti CI controllati, poi ambienti di staging e infine produzione sotto la supervisione umana.

Terremo sempre un essere umano nel ciclo per decisioni creative, architettoniche ed etiche, ma la maggior parte del lavoro ripetitivo e soggetto a errori come il linting, il refactoring e il recupero dei test sarà presto eseguito senza intervento.

Hai parlato di sistemi che “fanno la cosa giusta in silenzio”. Cosa significa questa filosofia nel contesto del governo dell’AI e dell’automazione responsabile?

Per me, “silenzioso” non significa silente. Significa degno di fiducia per default. Un sistema AI ben progettato non dovrebbe avere bisogno di costanti input o convalida. Dovrebbe agire in modo prevedibile, trasparente e sicuro.

L’automazione responsabile significa che ogni decisione presa dall’AI è spiegabile, reversibile e registrata. Chronos documenta la sua ragionamento e le sue azioni: cosa ha cambiato, perché e come i test hanno convalidato la correzione.

Il governo è incorporato nel sistema stesso. Nessuna modifica nascosta, nessun risultato in scatola nera. L’obiettivo non è che l’AI sia rumorosa o vistosa, ma che migliori silenziosamente il mondo sotto la superficie dove più conta.

Il termine “Quiet Tech” è affascinante – suggerisce tecnologia potente ma invisibile. Come vedi questo movimento ridisegnare la collaborazione tra esseri umani e AI nell’ingegneria?

La Quiet Tech è un’infrastruttura potente ma invisibile. La migliore tecnologia non dovrebbe interrompere; dovrebbe integrarsi.

Nell’ingegneria, significa che lo strumento non chiede “Cosa vuoi che faccia?”. Già sa cosa richiede attenzione. Vedono la dipendenza rotta, la patcha, aggiorna la documentazione e si sposta.

Mentre l’AI diventa parte dello stack dello sviluppatore, la collaborazione si sposta dal comando alla coesistenza. Gli esseri umani definiscono intento e direzione. L’AI esegue, mantiene e ottimizza silenziosamente in background. È l’era successiva, in cui la produttività deriva non da più interazione, ma da meno attrito.

Molti sviluppatori si preoccupano che gli strumenti AI li sostituiscano. Hai sostenuto che l’automazione dovrebbe liberare gli esseri umani per pensare, non sostituirli. Come Kodezi incarna questo equilibrio?

L’AI non sostituirà gli sviluppatori. Sostituirà la fatica intorno a loro. Gli ingegneri non sono preziosi perché digitano velocemente; sono preziosi perché pensano chiaramente.

Kodezi automatizza il lavoro ripetitivo che drena l’attenzione: debugging, manutenzione dei test, refactoring, documentazione. Il livello umano, la creatività, la progettazione del sistema e la ragionamento sulle scelte rimangono insostituibili.

Nel lungo termine, l’AI sposta l’ingegneria dall’esecuzione all’orchestrazione. Gli sviluppatori diventano architetti del comportamento, non esecutori della sintassi. Kodezi è costruito per abilitare questa transizione, in cui le macchine mantengono e gli esseri umani immaginano.

Hai descritto Kodezi come “infrastruttura vivente”. Guardando avanti cinque anni, cosa potrebbe essere il ruolo dello sviluppatore in un mondo in cui il software si mantiene da solo?

In cinque anni, gli sviluppatori non passeranno metà del loro tempo a correggere ciò che hanno costruito l’ultimo trimestre. Il loro ruolo si sposterà a monte dalla manutenzione reattiva alla governance proattiva.

Immagina un mondo in cui ogni repository ha memoria, in cui il tuo sistema traccia le sue stesse decisioni, cura le regressioni e evolve con nuove dipendenze automaticamente. È l’infrastruttura vivente.

In quel mondo, gli sviluppatori agiscono più come custodi. Definiscono politiche, verificano il comportamento e progettano l’intento. La base di codice diventa un organismo vivente che si adatta, apprende e si mantiene da solo.

È ciò che stiamo costruendo con Kodezi: software che non solo esegue. Dura.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Kodezi.