Ishraq Khan, administrerende direktør og grundlægger af Kodezi Inc – Interviewserie

Ishraq Khan, administrerende direktør og grundlægger af Kodezi Inc., er en selvuddannet programmør, der begyndte at programmere som 8-årig og lancerede sin første startup, mens han stadig var i mellemskolen. Født i Dhaka, Bangladesh, og senere flyttet til USA, opbyggede han en rekord for tidlig iværksættervirksomhed, sikrede venturekapital, mens han stadig var i gymnasiet, og skalaerede et produkt til over 100.000 brugere. Hans vej afspejler en fokus på selvstændig 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 selskab bag Kodezi OS, en autonom platform designet til at fungere som en “AI CTO” for ingeniørteam. Den detekterer og fikser fejl, dokumenterer systemer, genererer API-specifikationer, gennemtvinger kodestandarder og integrerer direkte i CI/CD-pipelines. Ved at omdanne kodebaser til selvhegnende, selvstyrende systemer hjælper Kodezi organisationer med at bygge software, der er mere pålidelig, skalerbar og effektiv.

Du begyndte at programmere som 8-årig 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ættermentalitet?

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 afhængighedsskabende. Den lærte mig, hvordan man tænker, ikke bare hvordan man programmerer.

Da jeg byggede TeachMeCode i mellemskolen, var det ikke om at starte et selskab. 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ættervirksomhed i dag: mindre om idéer, mere om feedback-løkker, iteration og resilience.

Du blev optaget på 40 kollegier, 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 gymnasiet, havde jeg allerede oplevet, 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 ned. 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 begyndte som en idé, da du stadig var teenager. Hvordan er selskabet udviklet siden dets 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 fejlfinding kunne være hurtigere. Da vi skalaerede, indså jeg, at fejlfinding ikke var roden til problemet. Det virkelige problem var, at kodebaser aldrig bliver stille. De udvikler sig, driver 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 bare kode; de vedligeholder arkitektur, vejleder 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 bygget specifikt til fejlfinding i kode – snarere end kodegenerering. Hvad er den fundamentale forskel, denne distinktion gør for udviklere?

Fordi fejlfinding er virkelighed, ikke fantasi. Kodegenerering handler om at gætte, hvad der måske virker; fejlfinding 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 forskel, 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 fejlretningens nøjagtighed. Kan du føre os igennem datasettet og metoden bag disse benchmarks?

Vores evaluering er empirisk, ikke promoverende. Chronos testes på tusindvis af virkelige fejlfindingssager trukket fra offentlige datasets som SWE-bench, Defects4J og BugsInPy samt anonymiseret virksomhedsdata.

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

Chronos opnår 67,3 procent fejlretningens 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å fejlfinding selv, på 15 millioner virkelige fejlfindingssessioner, så den ikke bare mønster-matcher, men diagnosticerer.

Du har beskrevet Kodezi som en “AI CTO”, der autonomt vedligeholder og udvikler et selskabs kodebase. Hvordan tæt er vi på at have fuldt selvhegnende infrastruktur i produktionsmiljøer?

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

Fullyd autonom produktionsservice, hvor infrastruktur diagnosticerer, healer og geninstallerer sig selv, er under udvikling. Jeg ser det udvikle sig i faser: først indenfor kontrollerede CI-miljøer, derefter stagingsmiljø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 fejlbehæftede arbejde som f.eks. linting, refactoring og testgenopretning vil snart ske uden indgriben.

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 godt 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 tages af AI, er forklarlig, omvendelig og logget. Chronos dokumenterer sin begrundelse og handlinger: hvad den ændrede, hvorfor og hvordan tests validerede rettelsen.

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

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

Stille Teknologi 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 flytter videre.

Som AI bliver en del af udviklerstakken, skifter samarbejdet 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 friktion, ikke mere interaktion.

Mange udviklere er bange 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: fejlfinding, testvedligehold, refactoring, dokumentation. Det menneskelige lag, kreativitet, systemdesign og kompromisforståelse forbliver uerstattelige.

På længere 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 muliggøre denne overgang, hvor maskiner vedligeholder og mennesker forestiller sig.

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

Om fem år vil udviklere ikke bruge halvdelen af deres tid på at fikse, 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 regressioner og udvikler sig med nye afhængigheder automatisk. Det er levende infrastruktur.

I den verden fungerer 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. Den består.

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