Ishraq Khan, Kodezi Inc:n toimitusjohtaja ja perustaja – Haastattelusarja

Ishraq Khan, Kodezi Inc:n toimitusjohtaja ja perustaja, on itseopiskellut koodari, joka aloitti ohjelmoinnin kahdeksanvuotiaana ja perusti ensimmäisen startup-yrityksensä vielä keskiasteella. Dhakassa, Bangladeshissä syntynyt ja myöhemmin Yhdysvaltoihin muuttanut Khan on luonut uransa aikana merkittävän uran varhaisesta yrittäjyydestä, hankkiessaan venture-rahastojen rahoitusta lukioaikanaan ja skaalaten tuotteen yli 100 000 käyttäjälle. Hänen polkunsa heijastaa itsenäistä oppimista, nopeaa kokeilua ja intohimoa luoda järjestelmiä, jotka tekevät teknologian kehittäjille helpommin saatavilla ja tehokkaammin.

Kodezi Inc. on yritys, joka on kehittänyt Kodezi OS:n, autonomisen alustan, joka toimii “AI-johtajana” insinööritiimille. Se havaitsee ja korjaa jatkuvasti ongelmia, dokumentoi automaattisesti järjestelmiä, luo API-määrityksiä, valvoo koodin standardeja ja integroi suoraan CI/CD-putkiin. Muuttaessaan koodipohjat itsestään parantaviksi ja itsehallinnollisiksi järjestelmiksi Kodezi auttaa organisaatioita kehittämään ohjelmistoja, jotka ovat luotettavampia, skaalautuvampia ja tehokkaampia.

Aloittit koodaamisen vasta kahdeksanvuotiaana ja perustit ensimmäisen startup-yrityksesi keskiasteella. Mikä aluksi veti sinut ohjelmistojen kehittämiseen niin varhain, ja miten nuo kokemukset muovasivat yrittäjämäisyyttäsi?

Se, mikä minua veti, oli hallinta. Muutin Yhdysvaltoihin lapsena, joka ei puhunut englantia, joten ensimmäinen kieli, jonka opin sujuvasti, oli koodi. Se oli tila, jossa logiikka oli järkevää, jossa voisin rakentaa jotain ja nähdä sen reagoivan välittömästi. Tuo välitön palautekuitti tuli riippuvaiseksi. Se opetti minulle, miten ajatella, ei vain miten ohjelmoida.

Kun rakensin TeachMeCode-ohjelman keskiasteella, se ei ollut yrityksen perustamisesta. Se oli helpottamasta oppimista ihmisille kuten minulle. Mutta sen kautta opin, miten järjestelmät toimivat, miten käyttäjät reagoivat ja miten edistys tapahtuu rivin rivin jälkeen. Se muovasi, miten näen yrittäjyyden tänään: vähemmän ideoita, enemmän palautekuureja, iterointia ja kestävyyttä.

Hyväksytiin 40 korkeakouluun, mukaan lukien useat Ivy League -laitokset, mutta päättiät olla käymättä. Mikä oli käännekohta, joka sai sinut päättämään, että rakentaminen oli tärkeämpää kuin odottaminen?

Lukion päättymisen aikaan olin jo elänyt sen, mihin useimmat ihmiset menevät korkeakouluun simuloimaan. Olin jo lanseerannut tuotteita, esittänyt sijoittajille, johtanut tiimiä ja ratkaissut todellisia ongelmia. Minulla oli 40 hyväksymiskirjettä pöydälläni, mukaan lukien useat Ivy League -koulut, mutta minulla oli myös se, minkä useimmilla opiskelijoilla ei ollut: momentum.

Suurempi riski oli hidastaa. Korkeakoulu olisi opettanut minulle innovaation kehykset, mutta olin jo suorittamassa kokeita oikeassa maailmassa. En halunnut keskeyttää aktiivista järjestelmää opiskelemaan, miten aloittaa sellainen. Minulle luokkahuoneesta tuli itse tuote. Kodezi oli se koulutus, jota halusin.

Kodezi alkoi ideana, kun olit vielä teini-ikäinen. Miten yritys on kehittynyt sen perustamisesta lähtien vuonna 2019, ja miten näkymä “AI-johtajasta” kehittyi ajan myötä?

Kodezi alkoi koodin oikoluvusta, yksinkertaisesta ideasta, jonka mukaan virheidenkorjaus voisi olla nopeampaa. Kun skaalasimme, tajusin, että virheidenkorjaus ei ollut juuriongelma. Todellinen ongelma oli, että koodipohjat eivät pysy paikallaan. Ne kehittyvät, liukuvat ja menevät rappiin nopeammin kuin ihmiset voivat ylläpitää niitä.

Ajan myötä Kodezi kehittyi tuotteesta Kodezi OS:ksi, joka oppii jokaisesta virheestä, testistä ja commitista. Termi “AI-johtaja” tuli luonnostaan. CTO:t eivät vain kirjoita koodia; he ylläpitävät arkkitehtuuria, ohjaavat päätöksiä ja pitävät järjestelmiä elossa. Tämä on sitä, mitä Kodezi tekee, mutta jatkuvasti ja autonomisesti.

Kodezin uusin malli, Chronos, on kuvattu ensimmäiseksi AI-järjestelmäksi, joka on suunniteltu erityisesti koodin virheidenkorjaamiseen eikä koodin luomiseen. Mikä on tämän eron perussääntö kehittäjille?

Koska virheidenkorjaus on todellisuutta, ei kuvitelmaa. Koodin luominen on arvaamista siitä, mitä voisi toimia; virheidenkorjaus on ymmärtämistä siitä, miksi jokin epäonnistui.

Useimmat nykyiset AI-työkalut ovat perustuvia avustajia, jotka reagoivat, kun niille kerrotaan. Chronos on toisaalta proaktiivinen. Se muistaa aiemmat virheet, ymmärtää riippuvuuskaavioita, suorittaa testejä, vahvistaa korjauksia ja parantaa niitä, kunnes ongelma on todella ratkaistu.

Tämä on se ero, joka merkitsee. Kehittäjät eivät halua avustajaa, joka puhuu. He haluavat infrastruktuuria, joka toimii ja toimii oikein.

Tulokset, joita olet jakanut, osoittavat Chronosin ylittävän GPT-4.1:n ja Claude 4 Opusin virheidenkorjaustarkkuudessa. Voitko käydä läpi tietojoukon ja menetelmän, jota näissä vertailuissa käytettiin?

Arviomme on empiirinen, ei mainonnallinen. Chronos on testattu tuhansilla todellisilla virheidenkorjaustapauksilla, jotka on poimittu julkisista tietoja kuten SWE-bench, Defects4J ja BugsInPy, sekä anonymisoiduista yritystiedoista.

Jokainen vertailu on tiukka: mallin on luotava korjaus, sovellettava se ja läpäistävä kaikki testit ilman takaiskuja. Ei valikoituja esimerkkejä, ei onnistumisen valikoimista.

Chronos saavuttaa 67,3 prosentin korjaustarkkuuden ja 80,33 prosentin ratkaisuvauhdin SWE-bench Liten osalla, kun taas GPT-4.1 ja Claude 4.5 jäävät alle 15 prosentin. Ero ei ole koko, vaan erikoistuminen. Chronos on koulutettu itse virheidenkorjaamiseen, 15 miljoonalla todellisella virheidenkorjaustilanteella, joten se ei vain tunnista kuvioita, vaan diagnosoi.

Olet kuvaillut Kodezia “eläväksi infrastruktuuriksi”, joka ylläpitää ja kehittää autonomisesti yrityksen koodipohjaa. Miten lähellä olemme täysin itsestään parantuvasta infrastruktuurista tuotantoympäristöissä?

Lähempänä kuin useimmat ihmiset ajattelevat, ainakin deterministisille järjestelmille. Tänään Kodezi voi autonomisesti korjata monia CI- tai CD-virheitä, testiregressioita ja suoritusaikavirheitä käyttäen kontekstidataa ja historiallista muistia.

Täysin autonomisen tuotannon ylläpidon, jossa infrastruktuuri diagnosoi, parantaa ja uudelleen käynnistää itsensä, on kehittymässä. Näen sen kehittyvän vaiheittain: ensin sisäisissä CI-ympäristöissä, sitten esittelyympäristöissä ja lopulta tuotannossa ihmisen valvonnassa.

Pidämme aina ihmisen silmän alla luovia, arkkitehtuurisia ja eettisiä päätöksiä, mutta suurin osa toistuvasta ja virhealttiista työstä, kuten linttaamisesta, uudelleenjärjestelystä ja testien palauttamisesta, tapahtuu pian ilman väliintuloa.

Olet puhunut järjestelmistä, jotka “tekevät oikein ilman melua”. Mitä tämä filosofia merkitsee AI-hallinnan ja vastuullisen automaation kontekstissa?

Minulle “hiljainen” ei tarkoita hiljaisuutta. Se tarkoittaa luotettavuutta oletusarvoisesti. Hyvin suunniteltu AI-järjestelmä ei tarvitse jatkuvaa syötettä tai vahvistusta. Se toimii ennustettavasti, avoimesti ja turvallisesti.

Vastuullinen automaatio tarkoittaa, että jokainen AI:n tekemä päätös on selitettävissä, peruuttavissa ja kirjattu. Chronos dokumentoi päätöksenteonsa ja toimintansa: mitä se muutti, miksi ja miten testit vahvistivat korjauksen.

Hallinto on sisäänrakennettu itse järjestelmään. Ei piilotettuja muutoksia, ei mustan laatikon tuloksia. Tavoitteena ei ole, että AI olisi melkasta tai näyttävää, vaan se, että se parantaa maailmaa hiljaisesti sen alla, missä se eniten merkitsee.

“Hiljainen tekniikka” on viehättävä – se viittaa tekniikkaan, joka on voimakas mutta näkymätön. Miten näet tämän liikkeen muuttavan, miten ihmiset ja AI tekevät yhteistyötä insinöörintyössä?

Hiljainen tekniikka on infrastruktuuria, joka on voimakas mutta näkymätön. Parasta teknologiaa ei pitäisi keskeyttää; se pitäisi integroida.

Insinöörintyössä se tarkoittaa, että työkalu ei kysy “Mitä haluat, että teen?” Se jo tietää, mihin on kiinnitettävä huomiota. Se näkee rikkoontuneen riippuvuuden, korjaa sen, päivittää dokumentaation ja jatkaa.

Tämä on se ero, joka merkitsee. Kehittäjät eivät halua avustajaa, joka puhuu. He haluavat infrastruktuuria, joka toimii ja toimii oikein.

Monet kehittäjät pelkäävät AI-työkalujen korvaavan heidät. Olet väittänyt, että automaatio pitäisi vapauttaa ihmiset ajattelemaan, ei korvata heitä. Miten Kodezi kehittää tämän tasapainon?

AI ei korvaa kehittäjiä. Se korvaa työn, joka on työlästä heille. Insinöörit eivät ole arvokkaita, koska he kirjoittavat nopeasti; he ovat arvokkaita, koska he ajattelevat selkeästi.

Kodezi automatisoi toistuvan työn, joka vie fokus: virheidenkorjaus, testien ylläpito, uudelleenjärjestely ja dokumentaatio. Inhimillinen kerros, luovuus, järjestelmäsuunnittelu ja kompromissiratkaisu säilyvät korvaamattomina.

Pitkällä tähtäimellä AI siirtää insinöörintyötä suorittamisesta orkestraatioon. Kehittäjät tulevat käymään käyttäytyminen arkkitehteina, ei syntaksin suorittajina. Kodezi on rakennettu mahdollistamaan tämä siirtymä, jossa koneet ylläpitävät ja ihmiset kuvittelevat.

Olet kuvaillut Kodezia “eläväksi infrastruktuuriksi”. Mitä kehittäjän rooli näyttää viiden vuoden kuluttua, maailmassa, jossa ohjelmisto ylläpitää itseään?

Viiden vuoden kuluttua kehittäjät eivät vie puolta ajastaan korjaamiseen sitä, mitä he rakensivat edellisellä neljänneksellä. Heidän roolinsa siirtyy reaktiivisesta ylläpidosta proaktiiviseen hallintoon.

Kuvittele maailmaa, jossa jokaisella varastolla on muisti, jossa järjestelmä seuraa omia päätöksiään, korjaa regressioita ja kehittyy uusien riippuvuuksien mukaan automaattisesti. Tämä on elävä infrastruktuuri.

Tässä maailmassa kehittäjät toimivat enemmän talonvalvojina. He määrittelevät käytäntöjä, vahvistavat käyttäytymisen ja suunnittelevat aikomusta. Koodipohja muuttuu eläväksi olennoksi, joka sopeutuu, oppii ja ylläpitää itseään.

Tämä on sitä, mitä rakennamme Kodezilla: ohjelmistoa, joka ei ainoastaan suorita. Se kestää.

Kiitos haastattelusta, lukijat, jotka haluavat oppia lisää, voivat vierailla Kodezi:ssa.