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 imprenditoria precoce, ottenendo finanziamenti per la sua azienda 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 costruzione di 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. Rileva e risolve continuamente 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 all’età di otto anni e hai fondato la tua prima startup alle scuole medie. Cosa ti ha attirato verso la costruzione di software così presto e come quelle esperienze hanno plasmato la tua mentalità imprenditoriale?

Ciò che mi ha attirato è stato 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. È stato 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 il modo in cui vedo l’imprenditoria oggi: meno idee, più cicli di feedback, iterazione e resilienza.

Sei stato ammesso a 40 college, tra cui diverse istituzioni della Ivy League, ma hai scelto di non frequentarli. 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 iniziare uno. Per me, l’aula è diventata il prodotto stesso. Kodezi era l’istruzione che volevo.

Kodezi è iniziato 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 è iniziato come un’autocorrezione 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 radice. Il problema reale era che le basi di codice non rimangono ferme. Evolvono, si spostano 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 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 i bug precedenti, comprende i grafici di dipendenza, esegue test, convalida le correzioni e le raffina fino a quando il problema non è effettivamente risolto.

Questa è la differenza 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 di correzione dei bug. Puoi spiegarci il dataset 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 dataset 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 case senza regressioni. Nessun esempio selezionato a mano, nessuna selezione dei successi.

Chronos raggiunge il 67,3% di accuratezza di correzione 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 riconosce pattern, ma diagnostica.

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

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

L’infrastruttura di produzione completamente autonoma, in cui l’infrastruttura diagnostica, si ripara e si ridistribuisce da sola, 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.

Manterremo 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 avverrà presto senza intervento.

Hai parlato di sistemi che “fanno la cosa giusta in silenzio”. Cosa significa questa filosofia nel contesto della governance 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 chiedere costantemente 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 logica e le sue azioni: cosa ha cambiato, perché e come i test hanno convalidato la correzione.

La governance è incorporata nel sistema stesso. Nessuna modifica nascosta, nessun esito in scatola nera. L’obiettivo non è che l’AI sia rumorosa o appariscente, 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?

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. Vedere la dipendenza rotta, patcharla, aggiornare la documentazione e proseguire.

Man mano che l’AI diventa parte dello stack di sviluppo, la collaborazione si sposta dal comando alla coesistenza. Gli esseri umani definiscono l’intento e la 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 logica delle 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 consentire 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?

Tra cinque anni, gli sviluppatori non trascorreranno metà del loro tempo a risolvere 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 proprie decisioni, risana le regressioni e si evolve con le nuove dipendenze automaticamente. È l’infrastruttura vivente.

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

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

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