Ishraq Khan, CEO og grunnlegger av Kodezi Inc – Intervju-serie

Ishraq Khan, CEO og grunnlegger av Kodezi Inc., er en selv-lært kodeforfatter som begynte å programmere da han var åtte år gammel og lanserte sin første startup mens han fortsatt var på ungdomsskolen. Født i Dhaka, Bangladesh og senere flyttet til USA, bygget han en rekord med tidlig entreprenørskap, sikret venturekapital i high school og skalerte et produkt til over 100 000 brukere. Hans vei reflekterer en fokus på uavhengig læring, rask eksperimentering og en drivkraft til å bygge systemer som gjør teknologi mer tilgjengelig og kraftfull for utviklere.

Kodezi Inc. er selskapet bak Kodezi OS, en autonom plattform designet for å fungere som en “AI CTO” for ingeniørteam. Den detekterer og fikser problemer kontinuerlig, dokumenterer systemer automatisk, genererer API-spesifikasjoner, påtvinger kode-standarder og integrerer direkte i CI/CD-pipelines. Ved å transformere kodebasen til selv-healende, selv-styrte systemer, hjelper Kodezi organisasjoner med å bygge programvare som er mer pålitelig, skalerbar og effektiv.

Du startet å kode da du var bare åtte år gammel og grunnla din første startup på ungdomsskolen. Hva var det som først trakk deg til å bygge programvare så tidlig, og hvordan har disse erfaringene formet din entreprenørsmindset?

Hva som trakk meg inn var kontroll. Jeg flyttet til USA som en gutt som ikke snakket engelsk, så det første språket jeg lærte flytende var kode. Det var et rom hvor logikk gjorde mening, hvor jeg kunne bygge noe og se det respondere øyeblikkelig. Den øyeblikkelige tilbakemeldingsløkken ble avhengig. Det lærte meg hvordan å tenke, ikke bare hvordan å programmere.

Når jeg bygget TeachMeCode på ungdomsskolen, var det ikke om å starte et selskap. Det var om å gjøre læring lettere for mennesker som meg. Men gjennom det, lærte jeg hvordan systemer oppfører seg, hvordan brukere responderer og hvordan fremgang skjer linje for linje. Det formet hvordan jeg ser på entreprenørskap i dag: mindre om ideer, mer om tilbakemeldingsløkker, iterasjon og motstandskraft.

Du ble akseptert til 40 colleger, inkludert flere Ivy League-institusjoner, men valgte å ikke delta. Hva var vendepunktet som gjorde deg til å bestemme at bygging var viktigere enn å vente?

Da jeg fullførte high school, hadde jeg allerede levd hva de fleste mennesker går på college for å simulere. Jeg hadde lansert produkter, pitchet investorer, ledet et team og løst virkelige problemer. Jeg hadde 40 aksepterbrev på skrivebordet, inkludert flere Ivy League-skoler, men jeg hadde også noe som de fleste studenter ikke hadde: momentum.

Den større risikoen var å sakke ned. College ville ha lært meg rammeverk for innovasjon, men jeg var allerede i gang med eksperimenter i den virkelige verden. Jeg ville ikke pause et aktivt system for å studere hvordan å starte ett. For meg ble klasserommet selv produktet. Kodezi var utdannelsen jeg ønsket.

Kodezi begynte som en idé da du fortsatt var tenåring. Hvordan har selskapet utviklet seg siden oppstarten i 2019, og hvordan oppstod visjonen om en “AI CTO” over tid?

Kodezi startet som en autocorrect for kode, en enkel idé om at feilsøking kunne være raskere. Mens vi skalerte, innsett jeg at feilsøking ikke var rotproblemet. Det virkelige problemet var at kodebasen aldri forblev stille. Den utviklet seg, drøftet og forfalt raskere enn mennesker kunne vedlikeholde den.

Over tid utviklet Kodezi seg fra et produkt til et operativsystem, det vi nå kaller Kodezi OS, som lærer av hver feil, test og commit. Begrepet “AI CTO” oppstod naturlig. CTO-er skriver ikke bare kode; de vedlikeholder arkitektur, guider beslutninger og holder systemer i live. Det er hva Kodezi gjør, men kontinuerlig og autonomt.

Kodezis nyeste modell, Chronos, beskrives som det første AI-systemet bygget spesifikt for kode-feilsøking – i stedet for kode-generering. Hva er den grunnleggende forskjellen dette gjør for utviklere?

Fordi feilsøking er virkelighet, ikke fantasi. Kode-generering er om å gjette hva som kan fungere; feilsøking er om å forstå hvorfor noe feilet.

De fleste AI-verktøy i dag er prompt-baserte assistenter som reagerer når de blir fortalt. Chronos, på den andre siden, er proaktiv. Den husker tidligere feil, forstår avhengighetsgrafer, kjører tester, validerer fikser og finjusterer dem til problemet er faktisk løst.

Det er forskjellen som teller. Utviklere ønsker ikke en assistent som snakker. De ønsker infrastruktur som handler og handler riktig.

Resultatene du har delt viser at Chronos overgår GPT-4.1 og Claude 4 Opus på feil-fiks-aksurat. Kan du gå gjennom datasettet og metoden bak disse benchmarkene?

Vår evaluering er empirisk, ikke promotiv. Chronos testes på tusenvis av virkelige feilsøkings-tilfeller hentet fra offentlige datasett som SWE-bench, Defects4J og BugsInPy, samt anonymisert bedriftsdata.

Hver benchmark er streng: modellen må generere en fiksering, aplikere den og bestå alle test-tilfeller uten regresser. Ingen håndplukkede eksempler, ingen cherry-picking av suksess.

Chronos oppnår 67,3 prosent fikserings-aksurat og 80,33 prosent løsningsrate på SWE-bench Lite, mens GPT-4.1 og Claude 4.5 holder under 15 prosent. Forskjellen er ikke størrelse; det er spesialisering. Chronos er trent på feilsøking selv, på 15 millioner virkelige feilsøkings-sesjoner, så det ikke bare mønster-matcher, det diagnostiserer.

Du har beskrevet Kodezi som en “AI CTO” som autonomt vedlikeholder og utvikler et selskaps kodebase. Hvor nær er vi til fullt selv-healende infrastruktur i produksjons-miljøer?

Nærere enn de fleste mennesker tror, i hvert fall for deterministiske systemer. I dag kan Kodezi autonomt fikse mange CI- eller CD-feil, test-regresser og runtime-feil ved hjelp av kontekstuell data og historisk minne.

Fullt autonom produksjons-vedlikehold, hvor infrastruktur diagnostiserer, healer og gjennopprett selv, er under utvikling. Jeg ser det utvikle seg i stadier: først i kontrollerte CI-miljøer, deretter i staging-miljøer og til slutt i produksjon under menneskelig tilsyn.

Vi vil alltid holde et menneske i løkken for kreative, arkitektoniske og etiske beslutninger, men det meste av det repetitive og feil-utsatte arbeidet som f.eks. linting, refaktorering og test-gjenopprettelse vil snart skje uten inngripen.

Du har snakket om systemer som “gjør det riktige uten å si noe”. Hva betyr denne filosofien i sammenheng med AI-styring og ansvarlig automatisering?

Til meg betyr “stille” ikke stille. Det betyr tillitsfullt som standard. Et godt designet AI-system bør ikke trenge å spørre om konstant inndata eller validering. Det bør handle forutsigbart, gjennomsiktig og trygt.

Ansvarlig automatisering betyr at hver beslutning gjort av AI er forklarlig, reversibel og logget. Chronos dokumenterer sin begrunnelse og handlinger: hva den endret, hvorfor og hvordan tester validerer fikseringen.

Styring er bygget inn i systemet selv. Ingen skjulte modifikasjoner, ingen sorte boks-utfall. Målet er ikke for AI å være høylytt eller flashy, men å forbedre verden under overflaten hvor det betyr mest.

Begrepet “Quiet Tech” er tiltrekkende – det antyder teknologi som er kraftfull, men usynlig. Hvordan ser du på denne bevegelsen som former hvordan mennesker og AI samarbeider i ingeniør-arbeid?

Quiet Tech er infrastruktur som er kraftfull, men usynlig. Den beste teknologien bør ikke avbryte; den bør integrere.

I ingeniør-arbeid betyr det at verktøyet ikke spør “Hva ønsker du at jeg skal gjøre?” Det vet allerede hva som trenger oppmerksomhet. Det ser den ødelagte avhengigheten, fikser den, oppdaterer dokumentasjonen og fortsetter.

Som AI blir en del av utvikler-stakken, skifter samarbeidet fra kommando til sameksistens. Mennesker definerer intensjon og retning. AI utfører, vedlikeholder og optimaliserer stille i bakgrunnen. Det er den neste æraen, hvor produktivitet kommer ikke fra mer interaksjon, men fra mindre friksjon.

Mange utviklere er bekymret for at AI-verktøy skal erstatte dem. Du har argumentert for at automatisering bør frigjøre mennesker til å tenke, ikke erstatte dem. Hvordan inkorporerer Kodezi denne balansen?

AI vil ikke erstatte utviklere. Det vil erstatte slitsamen rundt dem. Ingeniører er ikke verdifulle fordi de skriver raskt; de er verdifulle fordi de tenker klart.

Kodezi automatiserer det repetitive arbeidet som drener fokus: feilsøking, test-vedlikehold, refaktorering, dokumentasjon. Den menneskelige laget, kreativitet, system-design og avveinings-grunnlag forblir uerstattelige.

På lang sikt skifter AI ingeniør-arbeid fra utførelse til orkestrering. Utviklere blir arkitekter av atferd, ikke utførere av syntaks. Kodezi er bygget for å muliggjøre denne overgangen, hvor maskiner vedlikeholder og mennesker forestiller seg.

Du har beskrevet Kodezi som “levende infrastruktur”. Ser vi fem år frem i tid, hva kan utviklerens rol se ut som i en verden hvor programvare vedlikeholder seg selv?

I fem år vil utviklere ikke bruke halve tiden sin på å fikse hva de bygget forrige kvartal. Deres rolle vil flytte seg oppstrøms fra reaktiv vedlikehold til proaktiv styring.

Forestiller deg en verden hvor hver repository har minne, hvor systemet ditt sporer sine egne beslutninger, healer regresser og utvikler seg med nye avhengigheter automatisk. Det er levende infrastruktur.

I den verden fungerer utviklere mer som forvaltere. De definerer politikker, verifiserer atferd og designer intensjon. Kodebasen blir et levende vesen som tilpasser seg, lærer og vedlikeholder seg selv.

Det er hva vi bygger med Kodezi: programvare som ikke bare kjører. Den varer.

Takk for det flotte intervjuet, lesere som ønsker å lære mer kan besøke Kodezi.