Ishraq Khan, CEO og grundlægger af Kodezi Inc – Interview Serie

Ishraq Khan, CEO og grundlægger af Kodezi Inc., er en selv-lært programmør, der begyndte at programmere i en alder af otte og lancerede sin første startup, mens han stadig gik i mellemskole. Født i Dhaka, Bangladesh og senere flyttede til USA, opbyggede han en track record af tidlig iværksætterånd, sikrede venturekapital i high school og skalaerede et produkt til mere end 100.000 brugere. Hans vej reflekterer en fokus på uafhængig læring, hurtig eksperimentering og en drivkraft til at bygge systemer, der gør teknologi mere tilgængelig og kraftfuld for udviklere.

Kodezi Inc. er det firma bag Kodezi OS, en autonom platform designet til at fungere som en “AI CTO” for ingeniørteam. Den detekterer og retter fejl, dokumenterer systemer, genererer API-specifikationer, gennemtvinger kodestandarde og integrerer direkte i CI/CD-pipelines. Ved at omdanne kodebaser til selv-healende, selv-styrende systemer, hjælper Kodezi organisationer med at bygge software, der er mere pålidelig, skalerbar og effektiv.

Du startede med at programmere, da du var otte år gammel, og grundlagde din første startup i mellemskolen. Hvad var det, der oprindeligt tiltrak dig til at bygge software så tidligt, og hvordan formede disse oplevelser din iværksætter-mindset?

Det, der trak mig ind, var kontrol. Jeg flyttede til USA som en dreng, der ikke talte engelsk, så det første sprog, jeg lærte flydende, var kode. Det var et rum, hvor logik gjorde mening, hvor jeg kunne bygge noget og se det reagere øjeblikkeligt. Den øjeblikkelige feedback-løkke blev vanedannende. Det lærte mig, hvordan jeg skulle tænke, ikke bare hvordan jeg skulle programmere.

Da jeg byggede TeachMeCode i mellemskolen, var det ikke om at starte et firma. Det var om at gøre læring lettere for mennesker som mig. Men gennem det lærte jeg, hvordan systemer opfører sig, hvordan brugere reagerer, og hvordan fremgang sker linje for linje. Det formede, hvordan jeg ser på iværksætterånd i dag: mindre om idéer, mere om feedback-løkker, iteration og resilience.

Du blev optaget på 40 colleges – herunder flere Ivy League-institutioner – men valgte ikke at gå. Hvad var vendepunktet, der fik dig til at beslutte, at bygning var vigtigere end at vente?

Da jeg havde afsluttet high school, havde jeg allerede levet, hvad de fleste mennesker går på college for at simulere. Jeg havde lanceret produkter, præsenteret for investorer, ledet et hold og løst reelle problemer. Jeg havde 40 optagelsesbreve på mit skrivebord, herunder flere Ivy League-skoler, men jeg havde også noget, som de fleste studerende ikke havde: momentum.

Den største risiko var at bremse farten. College ville have lært mig rammer for innovation, men jeg var allerede i gang med at køre eksperimenter i den virkelige verden. Jeg ville ikke pause et aktivt system for at studere, hvordan man starter et. For mig blev klasselokalet selv produktet. Kodezi var den uddannelse, jeg ønskede.

Kodezi startede som en idé, da du stadig var teenager. Hvordan er firmaet udviklet siden sin oprettelse i 2019, og hvordan opstod din vision om en “AI CTO” over tid?

Kodezi startede som en autocorrect til kode, en simpel idé om, at fejlrettelse kunne være hurtigere. Da vi skalaerede, indså jeg, at fejlrettelse ikke var rodproblemet. Det virkelige problem var, at kodebaser aldrig forbliver stille. De udvikler sig, drifter og forfald hurtigere, end mennesker kan vedligeholde dem.

Over tid udviklede Kodezi sig fra et produkt til et operativsystem, som vi nu kalder Kodezi OS, der lærer af hver fejl, test og commit. Begrebet “AI CTO” opstod naturligt. CTO’er skriver ikke kun kode; de vedligeholder arkitektur, guider beslutninger og holder systemer i live. Det er, hvad Kodezi gør, men kontinuerligt og autonomt.

Kodezis nyeste model, Chronos, beskrives som det første AI-system, der er bygget specifikt til kode-fejlrettelse – og ikke kode-generering. Hvad er den fundamentale forskel, denne distinktion gør for udviklere?

Fordi fejlrettelse er virkelighed, ikke fantasi. Kode-generering handler om at gætte, hvad der måske virker; fejlrettelse handler om at forstå, hvorfor noget fejlede.

De fleste AI-værktøjer i dag er prompt-baserede assistenter, der reagerer, når de bliver bedt om det. Chronos, på den anden side, er proaktiv. Den husker tidligere fejl, forstår afhængighedsgrafer, kører tests, validerer rettelser og forbedrer dem, indtil problemet er løst.

Det er den distinktion, der betyder noget. Udviklere ønsker ikke en assistent, der taler. De ønsker infrastruktur, der handler og handler korrekt.

Resultaterne, du har delt, viser, at Chronos overgår GPT-4.1 og Claude 4 Opus i fejlrettelses-nøjagtighed. Kan du føre os gennem datasettet og metoden bag disse benchmarks?

Vores evaluering er empirisk, ikke promotionsmæssig. Chronos testes på tusindvis af virkelige fejlrettelsessager hentet fra offentlige dataset som SWE-bench, Defects4J og BugsInPy, samt anonymiseret virksomhedsdata.

Hver benchmark er streng: modellen skal generere en patch, anvende den og bestå alle testcases uden regression. Ingen håndplukkede eksempler, ingen cherry-picking af succes.

Chronos opnår 67,3 procent fejlrettelses-nøjagtighed og 80,33 procent løsningsrate på SWE-bench Lite, mens GPT-4.1 og Claude 4.5 forbliver under 15 procent. Forskellen er ikke størrelse; det er specialisering. Chronos er trænet på fejlrettelse i sig selv, på 15 millioner virkelige fejlrettelsessessioner, så den ikke bare mønster-matcher, men også diagnosticerer.

Du har beskrevet Kodezi som en “AI CTO”, der autonomt vedligeholder og udvikler en virksomheds kodebase. Hvor tæt er vi på at have fuldt selv-healende infrastruktur i produktionsmiljøer?

Tættere, end de fleste mennesker tror, i hvert fald for deterministiske systemer. I dag kan Kodezi autonomt rette mange CI- eller CD-fejl, test-regression og runtime-fejl ved hjælp af kontekstdata og historisk hukommelse.

Fuldt autonom produktionsservice, hvor infrastruktur diagnosticerer, healer og geninstallerer sig selv, er under udvikling. Jeg ser det udvikle sig i faser: først inden for kontrollerede CI-miljøer, derefter staging-miljøer og til sidst produktion under menneskelig overvågning.

Vi vil altid holde et menneske i løkken for kreative, arkitektoniske og etiske beslutninger, men det meste af det repetitive og fejl-prædisponerede arbejde som f.eks. linting, refactoring og test-gendannelse vil snart ske uden intervention.

Du har talt om systemer, der “stille gør det rigtige”. Hvad betyder denne filosofi i sammenhæng med AI-styring og ansvarlig automation?

For mig betyder “stille” ikke stille. Det betyder tillidsværdigt som standard. Et vel-designet AI-system skal ikke behøve at bede om konstant input eller validering. Det skal handle forudsigeligt, gennemsigtigt og sikkert.

Ansvarlig automation betyder, at hver beslutning, der træffes af AI, er forklarbar, omvendelig og logget. Chronos dokumenterer sin begrundelse og handling: hvad den ændrede, hvorfor og hvordan tests validerede rettelsen.

Styring er bygget ind i systemet selv. Ingen skjulte ændringer, ingen sorte kasser-resultater. Målet er ikke, at AI skal være højlydt eller flashy, men at forbedre verden under overfladen, hvor det betyder noget.

Begrebet “Quiet Tech” er overbevisende – det antyder teknologi, der er kraftfuld, men usynlig. Hvordan ser du denne bevægelse forme, hvordan mennesker og AI samarbejder i ingeniørarbejde?

Quiet Tech er infrastruktur, der er kraftfuld, men usynlig. Den bedste teknologi skal ikke afbryde; den skal integrere.

I ingeniørarbejde betyder det, at værktøjet ikke spørger “Hvad vil du have mig til at gøre?” Det ved allerede, hvad der kræver opmærksomhed. Det ser den brudte afhængighed, retter den, opdaterer dokumentationen og fortsætter.

Samarbejdet skifter fra kommando til sameksistens. Mennesker definerer intention og retning. AI udfører, vedligeholder og optimerer stille i baggrunden. Det er den næste æra, hvor produktivitet kommer fra mindre interaktion, men mindre friktion.

Mange udviklere er bekymrede for, at AI-værktøjer skal erstatte dem. Du har argumenteret for, at automation skal frigøre mennesker til at tænke, ikke erstatte dem. Hvordan inkarnerer Kodezi denne balance?

AI vil ikke erstatte udviklere. Det vil erstatte det kedelige arbejde omkring dem. Ingeniører er ikke værdifulde, fordi de skriver hurtigt; de er værdifulde, fordi de tænker klart.

Kodezi automatiserer det repetitive arbejde, der dræner fokus: fejlrettelse, test-vedligehold, refactoring, dokumentation. Det menneskelige lag, kreativitet, system-design og tradeoff-reasoning forbliver uerstattelige.

På lang sigt skifter AI ingeniørarbejde fra udførelse til orkestrering. Udviklere bliver arkitekter af adfærd, ikke udførere af syntaks. Kodezi er bygget til at enable denne transition, hvor maskiner vedligeholder og mennesker forestiller sig.

Du har beskrevet Kodezi som “levende infrastruktur”. Hvad kunne udviklernes rol se ud til at være om fem år i en verden, hvor software selv vedligeholder sig?

Om fem år vil udviklere ikke bruge halvdelen af deres tid på at rette, hvad de byggede sidste kvartal. Deres rol vil flytte sig fra reaktiv vedligehold til proaktiv styring.

Forestil dig en verden, hvor hver repository har hukommelse, hvor dit system sporer sine egne beslutninger, healer regression og udvikler sig med nye afhængigheder automatisk. Det er levende infrastruktur.

I den verden handler udviklere mere som vogtere. De definerer politikker, verificerer adfærd og designer intention. Kodebasen bliver et levende væsen, der tilpasser sig, lærer og vedligeholder sig selv.

Det er, hvad vi bygger med Kodezi: software, der ikke bare kører. Det udholder.

Tak for det gode interview. Læsere, der ønsker at lære mere, skal besøge Kodezi.