Ishraq Khan, VD och grundare av Kodezi Inc – Intervjuerien

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 mer än 100 000 användare. Hans bana speglar en fokusering på oberoende lärande, snabb experimentering och en drivkraft att bygga system som gör tekniken 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-VD” för ingenjörsteam. Den upptäcker och åtgärdar kontinuerligt problem, dokumenterar automatiskt system, genererar API-specifikationer, upprätthåller kodstandarder 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 redan 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 ett barn 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 återkopplingsloopen blev beroendeframkallande. Den lärde mig att tänka, inte bara hur man programmerar.

När jag byggde TeachMeCode i mellanstadiet handlade det inte om att starta ett företag. Det handlade om 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 beslutade att byggande var viktigare än att vänta?

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

Den större risken var att sakta ner. College skulle ha lärt mig ramverk för innovation, men jag var redan i färd med att köra experiment i den riktiga 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 start 2019, och hur uppstod din vision om en “AI-VD” över tid?

Kodezi började som en autocorrect för kod, en enkel idé om att felsökning kunde gå snabbare. När vi skalfade insåg jag att felsökning inte var det grundläggande problemet. Det riktiga problemet var att kodbasen aldrig står 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 som vi nu kallar Kodezi OS, som lär sig av varje bugg, test och commit. Begreppet “AI-VD” uppstod naturligt. VD:ar 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 byggts specifikt för kodfelsökning – snarare än kodgenerering. Vilken grundläggande skillnad gör denna distinktion 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 beroendegrafik, kör tester, validerar korrigeringar och finslipar dem tills problemet är verkligen löst.

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

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

Vår utvärdering är empirisk, inte marknadsföringsinriktad. Chronos testas på tusentals riktiga felsökningsfall från offentliga datamängder som SWE-bench, Defects4J och BugsInPy, samt anonymiserad företagsdata.

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

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

Du har beskrivit Kodezi som en “AI-VD” 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 de flesta människor tror, åtminstone för deterministiska system. Idag kan Kodezi autonomt fixa många CI- eller CD-fel, testregressioner och körningsfel med hjälp av kontextdata och historisk minnesförmåga.

Fullt autonom produktionunderhåll, där infrastruktur diagnostiserar, läker och återdistribuerar sig själv, är på väg att utvecklas. Jag ser det 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 loopen 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 förtroendefullt 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 handlingar: vad den ändrade, varför och hur tester validerade korrigeringen.

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

Begreppet “Tyst Tech” ä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örskonst?

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

Inom ingenjörskonst 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 flyttar vidare.

Sådan är den distinktion som spelar roll. Utvecklare vill inte ha en assistent som pratar. De vill ha infrastruktur som agerar och agerar korrekt.

När AI blir en del av utvecklarstapeln skiftar samarbetet från kommando till samexistens. Människor definierar avsikt och riktning. AI utför, underhåller och optimerar tyst i bakgrunden. Det är den kommande 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örskonst från exekvering till orkestrering. Utvecklare blir arkitekter av beteende, inte exekverare 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 lägga 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 er en värld där varje repository har minne, där systemet 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 policyer, verifierar beteende och designerar 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.