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 ennå gikk på ungdomsskolen. Født i Dhaka, Bangladesh og senere flyttet til USA, bygde 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 til å fungere som en “AI CTO” for ingeniørteam. Den detekterer og fikser kontinuerlig problemer, dokumenterer automatisk systemer, genererer API-spesifikasjoner, påtvinger kodestandarder og integrerer direkte i CI/CD-pipelines. Ved å transformere kodebasen til selv-helende, 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 opprinnelig trakk deg til å bygge programvare så tidlig, og hvordan formede disse erfaringene din entreprenørsmindset?

Det 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 svare øyeblikkelig. Den øyeblikkelige tilbakemeldingsløkken ble avhengig. Den lærte meg å tenke, ikke bare hvordan man programmerer.

Når jeg bygde 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 brukerne reagerer og hvordan fremgang skjer linje for linje. Det formede hvordan jeg ser på entreprenørskap i dag: mindre om ideer, mer om tilbakemeldingsløkker, iterasjon og motstandskraft.

Du ble akseptert på 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 det meste av hva folk 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 man starter ett. For meg ble klasserommet selv produktet. Kodezi var utdannelsen jeg ønsket.

Kodezi begynte som en idé da du ennå 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. Da vi skalerte, innsett jeg at feilsøking ikke var det underliggende problemet. Det virkelige problemet var at kodebasen aldri forblir stille. Den utvikler seg, drifter og forfaller raskere enn mennesker kan 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 det Kodezi gjør, men kontinuerlig og autonomt.

Kodezis nyeste modell, Chronos, beskrives som det første AI-systemet bygget spesifikt for kodefeilsøking – i motsetning til kodegenerering. Hva er den grunnleggende forskjellen dette gjør for utviklere?

Fordi feilsøking er virkelighet, ikke fantasi. Kodegenerering handler om å gjette hva som kan fungere; feilsøking handler 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 den forskjellen som teller. Utviklere ønsker ikke en assistent som snakker. De ønsker infrastruktur som handler og handler korrekt.

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

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

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

Chronos oppnår 67,3 prosent feilfikseringsnøyaktighet 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øk, så den ikke bare mønster-matcher, den diagnostiserer.

Du har beskrevet Kodezi som en “AI CTO” som autonomt vedlikeholder og utvikler en bedrifts kodebase. Hvor nær er vi til fullt selv-helende infrastruktur i produksjonsmiljøer?

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

Fullt autonom produksjonsvedlikehold, hvor infrastruktur diagnostiserer, helbreder og gjensender selv, er på vei. Jeg ser det utvikle seg i stadier: først innen kontrollerte CI-miljøer, deretter stagingsmiljøer og til slutt 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 testgjenoppretting vil snart skje uten inngripen.

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

For meg betyr “i ro” ikke stille. Det betyr tillitsfullt som standard. Et godt designet AI-system bør ikke trenger å be om konstant innputt eller validering. Det bør handle forutsigbart, transparent 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 fikset.

Styring er bygget inn i systemet selv. Ingen skjulte modifikasjoner, ingen svarte boks-utfall. Målet er ikke for AI å være høylydt 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 omdefinierer hvordan mennesker og AI samarbeider i ingeniørarbeid?

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

I ingeniørarbeid 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 går videre.

Slik 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 redd 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 inkarnerer Kodezi denne balansen?

AI vil ikke erstatte utviklere. Det vil erstatte slit og sleng som omgir dem. Ingeniører er ikke verdifulle fordi de skriver raskt; de er verdifulle fordi de tenker klart.

Kodezi automatiserer det repetitive arbeidet som drainer fokus: feilsøking, testvedlikehold, refaktorering, dokumentasjon. Det menneskelige laget, kreativitet, systemdesign og avveiningsgrunn blijver uerstattelige.

På lang sikt skifter AI ingeniørarbeid fra utførelse til orkestrering. Utviklere blir arkitekter av atferd, ikke utøvere 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 rolle se ut som i en verden hvor programvare vedlikeholder seg selv?

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

Forestall en verden hvor hver repository har minne, hvor systemet ditt sporer sine egne beslutninger, helbreder regressionsfeil og utvikler seg med nye avhengigheter automatisk. Det er levende infrastruktur.

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

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

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