Ishraq Khan, VD och grundare av Kodezi Inc – Intervjuserie

Ishraq Khan, VD och grundare av Kodezi Inc., är en självlärd programmerare som började programmera vid åtta års ålder och lanserade sitt första företag medan han fortfarande gick i mellanstadiet. Född i Dhaka, Bangladesh och senare flyttade till USA, byggde han upp en meritlista av tidig entreprenörskap, säkrade riskkapital i high school och skalfade en produkt till över 100 000 användare. Hans bana speglar en fokusering på oberoende lärande, snabb experiment och en strävan att bygga system som gör teknologi mer tillgänglig och kraftfull för utvecklare.

Kodezi Inc. är företaget bakom Kodezi OS, en autonom plattform som är utformad för att fungera som en “AI CTO” för ingenjörsteam. Den upptäcker och fixar kontinuerligt problem, dokumenterar automatiskt system, genererar API-specifikationer, upprätthåller kodningsstandarder och integrerar direkt i CI/CD-pipelines. Genom att omvandla kodbasen till självläkande, självstyrande system hjälper Kodezi organisationer att bygga programvara som är mer tillförlitlig, skalbar och effektiv.

Du började koda vid åtta års ålder och grundade ditt första företag i mellanstadiet. Vad var det som ursprungligen drog dig till att bygga programvara så tidigt, och hur formade dessa upplevelser din entreprenöriella synsätt?

Det som drog mig in var kontroll. Jag flyttade till USA som en pojke som inte talade engelska, så det första språket jag lärde mig flytande var kod. Det var ett utrymme där logik hade mening, där jag kunde bygga något och se det svara direkt. Den omedelbara återkopplingsloop som blev beroendeframkallande. Den lärde mig hur man tänker, inte bara hur man programmerar.

När jag byggde TeachMeCode i mellanstadiet var det inte för att starta ett företag. Det var för att göra lärande lättare för människor som jag. Men genom det lärde jag mig hur system beter sig, hur användare svarar och hur framsteg sker rad för rad. Det formade hur jag ser på entreprenörskap idag: mindre om idéer, mer om återkopplingsloopar, iteration och motståndskraft.

Du antogs till 40 college, inklusive flera Ivy League-institutioner, men valde att inte gå. Vad var den avgörande faktorn som gjorde att du bestämde dig för att bygga var viktigare än att vänta?

När jag avslutade high school hade jag redan upplevt det som de flesta människor går till college för att simulera. Jag hade lanserat produkter, pitchat investerare, hanterat ett team och löst verkliga problem. Jag hade 40 antagningsbrev på mitt skrivbord, inklusive flera Ivy League-skolor, men jag hade också något som de flesta studenter inte hade: momentum.

Den större risken var att sakta ner. College skulle ha lärt mig ramverk för innovation, men jag körde redan experiment i den verkliga världen. Jag ville inte pausa ett aktivt system för att studera hur man startar ett. För mig blev klassrummet själva produkten. Kodezi var den utbildning jag ville ha.

Kodezi började som en idé när du fortfarande var tonåring. Hur har företaget utvecklats sedan dess tillkomst 2019, och hur uppstod din vision om en “AI CTO” över tid?

Kodezi började som en autocorrect för kod, en enkel idé som sa att felsökning kunde vara snabbare. När vi skalfade insåg jag att felsökning inte var det grundläggande problemet. Det verkliga problemet var att kodbasen aldrig stannar still. Den utvecklas, glider och försämras snabbare än människor kan underhålla den.

Över tid utvecklades Kodezi från en produkt till ett operativsystem, det vi nu kallar Kodezi OS, som lär sig av varje bugg, test och commit. Begreppet “AI CTO” uppstod naturligt. CTO:er skriver inte bara kod; de underhåller arkitektur, vägleder beslut och håller systemen vid liv. Det är vad Kodezi gör, men kontinuerligt och autonomt.

Kodezis senaste modell, Chronos, beskrivs som det första AI-systemet som är byggt specifikt för kodfelsökning – snarare än kodgenerering. Vad är den grundläggande skillnaden som denna distinktion gör för utvecklare?

För att felsökning är verklighet, inte fantasi. Kodgenerering handlar om att gissa vad som kan fungera; felsökning handlar om att förstå varför något misslyckades.

De flesta AI-verktyg idag är promptbaserade assistenter som reagerar när de blir tillsagda. Chronos, å andra sidan, är proaktiv. Den minns tidigare buggar, förstår beroendegraf, kör tester, validerar korrigeringar och finslipar dem tills problemet är verkligen löst.

Det är den skillnad som spelar roll. Utvecklare vill inte ha en assistent som pratar. De vill ha infrastruktur som agerar och agerar korrekt.

Resultaten du delat visar att Chronos överträffar GPT-4.1 och Claude 4 Opus när det gäller felkorrigering. Kan du gå igenom datamängden och metodiken bakom dessa benchmark?

Vår utvärdering är empirisk, inte promotionsinriktad. Chronos testas på tusentals verkliga felsökningsfall som hämtats från offentliga datamängder som SWE-bench, Defects4J och BugsInPy, tillsammans med anonymiserad företagsdata.

Varje benchmark är strikt: modellen måste generera en korrigering, applicera den och klara alla testfall utan regression. Inga handplockade exempel, inga cherry-picking av framgång.

Chronos uppnår 67,3 procents korrigeringsexakthet och 80,33 procents lösningstakt på SWE-bench Lite, medan GPT-4.1 och Claude 4.5 ligger under 15 procent. Skillnaden ligger inte i storlek; det handlar om specialisering. Chronos är tränad på felsökning i sig, på 15 miljoner verkliga felsökningsessioner, så den diagnostiserar inte bara mönster, den diagnostiserar.

Du har beskrivit Kodezi som en “AI CTO” som autonomt underhåller och utvecklar ett företags kodbas. Hur nära är vi att ha fullt självläkande infrastruktur i produktionsmiljöer?

Närmare än vad de flesta människor tror, åtminstone för deterministiska system. Idag kan Kodezi autonomt fixa många CI- eller CD-fel, testregressioner och runtime-fel med hjälp av kontextuell data och historiskt minne.

Fullt autonomt produktionsunderhåll, där infrastruktur diagnostiserar, läker och återdistribuerar sig själv, är på väg att utvecklas. Jag ser det som utvecklas i etapper: först inom kontrollerade CI-miljöer, sedan staging-miljöer och slutligen produktion under mänsklig övervakning.

Vi kommer alltid att ha en människa i slingan för kreativa, arkitektoniska och etiska beslut, men det mesta av det repetitiva och felbenägna arbetet som t.ex. linter, refactoring och teståterhämtning kommer snart att ske utan ingripande.

Du har talat om system som “gör rätt sak tyst”. Vad betyder den filosofin i sammanhanget med AI-styrning och ansvarsfull automatisering?

För mig betyder “tyst” inte tyst. Det betyder tillförlitligt som standard. Ett välutformat AI-system bör inte behöva be om konstant inmatning eller validering. Det bör agera förutsägbart, transparent och säkert.

Ansvarsfull automatisering betyder att varje beslut som fattas av AI är förklarbart, återställbart och loggat. Chronos dokumenterar sin resonemang och åtgärder: vad den ändrade, varför och hur tester validerade korrigeringen.

Styrning är inbyggd i systemet själv. Inga dolda ändringar, inga svarta lådor. Målet är inte att AI ska vara högljudd eller flashig, utan att tyst förbättra världen under ytan där det betyder mest.

Begreppet “Tyst Teknik” är övertygande – det antyder teknik som är kraftfull men osynlig. Hur ser du att den här rörelsen omformar hur människor och AI samarbetar inom ingenjörskap?

Tyst Teknik är infrastruktur som är kraftfull men osynlig. Den bästa tekniken bör inte avbryta; den bör integreras.

Inom ingenjörskap betyder det att verktyget inte frågar “Vad vill du att jag ska göra?” Det vet redan vad som behöver uppmärksamhet. Det ser den trasiga beroendet, patchar det, uppdaterar dokumentationen och fortsätter.

Sådan är den nästa eran, där produktivitet kommer inte från mer interaktion, utan från mindre friktion.

Många utvecklare är oroliga för att AI-verktyg ska ersätta dem. Du har hävdat att automatisering bör frigöra människor att tänka, inte ersätta dem. Hur kroppar Kodezi den balansen?

AI kommer inte att ersätta utvecklare. Den kommer att ersätta tråkigheten runt dem. Ingenjörer är inte värdefulla för att de skriver snabbt; de är värdefulla för att de tänker klart.

Kodezi automatiserar det repetitiva arbetet som dränerar fokus: felsökning, testunderhåll, refactoring, dokumentation. Den mänskliga nivån, kreativitet, systemdesign och avvägningsbeslut förblir oumbärliga.

På lång sikt skiftar AI ingenjörskap från exekvering till orkestrering. Utvecklare blir arkitekter för beteende, inte exekutörer av syntax. Kodezi är byggt för att möjliggöra den övergången, där maskiner underhåller och människor föreställer sig.

Du har beskrivit Kodezi som “levande infrastruktur”. Om fem år, vad kan utvecklarens roll se ut i en värld där programvara upprätthåller sig själv?

Om fem år kommer utvecklare inte att spendera halva sin tid på att fixa det de byggde förra kvartalet. Deras roll kommer att flytta uppströms från reaktivt underhåll till proaktiv styrning.

Föreställ dig en värld där varje repository har minne, där ditt system spårar sina egna beslut, läker regressioner och utvecklas med nya beroenden automatiskt. Det är levande infrastruktur.

I den världen agerar utvecklare mer som förvaltare. De definierar policys, verifierar beteende och utformar avsikt. Kodbasen blir en levande organism som anpassar sig, lär sig och upprätthåller sig själv.

Det är vad vi bygger med Kodezi: programvara som inte bara körs. Den består.

Tack för den underbara intervjun, läsare som vill lära sig mer kan besöka Kodezi.