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

Ishraq Khan, Kodezi Inc:n perustaja ja toimitusjohtaja, on itseopiskellut koodari, joka aloitti ohjelmoinnin 8-vuotiaana ja perusti ensimmäisen startup-yrityksensä vielä keskiasteella. Khan syntyi Dhakassa, Bangladeshissa, ja muutti myöhemmin Yhdysvaltoihin, jossa hän rakensi uransa varhaisella yrittäjyydellä, hankki venture-rahastojen rahoitusta lukioaikanaan ja laajensi tuotetta yli 100 000 käyttäjälle. Hänen polkunsa heijastaa itsenäistä oppimista, nopeaa kokeilua ja pyrkimystä luoda järjestelmiä, jotka tekevät teknologian kehittäjille helpommin käsiteltäväksi ja voimakkaammaksi.

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

Mitä sinä ajattelit, kun aloit ohjelmoinnin 8-vuotiaana ja perustit ensimmäisen startup-yrityksesi keskiasteella? Miten nämä kokemukset muovasivat sinun yrittäjämäistä ajattelutapaa?

Se, mikä minua veti puoleensa, 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. Se 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 käyttäytyvät, 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 palautekuitti, iterointi ja kestävyys.

Sinä hyväksyttiin 40 korkeakouluun, mukaan lukien useat Ivy League -laitokset, mutta päättivät ei osallistua. Mikä oli ratkaiseva tekijä, joka sai sinut päättämään, että rakentaminen oli tärkeämpää kuin odottaminen?

Lukion päättymisen aikaan minulla oli jo elänyt, mitä useimmat ihmiset menevät collegeen 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, mitä useimmat opiskelijat eivät olleet: momentum.

Suurin riski oli hidastaa. College opettaisi minulle innovaation kehykset, mutta minä olin jo käynnissä kokeita todellisessa maailmassa. En halunnut pysäyttää aktiivista järjestelmää opiskelemaan, miten aloittaa se. Minulle luokkahuoneesta tuli itse tuote. Kodezi oli se koulutus, jota halusin.

Kodezi alkoi ideana, kun sinä olit vielä teini-ikäinen. Miten yritys on kehittynyt sen perustamisesta vuonna 2019 lähtien, ja miten sinun visiosi “AI-CTO:sta” kehittyi ajan myötä?

Kodezi alkoi yksinkertaisena ideoina, jonka mukaan virheenkorjaus voisi olla nopeampaa. Kun laajensimme, tajusin, että virheenkorjaus ei ollut juurisyy. Todellinen ongelma oli, että koodipohjat eivät pysy paikallaan. Ne kehittyvät, liukuvat ja menevät rappiin ihmisten ylläpitämisen nopeammin.

Ajan myötä Kodezi kehittyi tuotteesta autonomiseksi operatiiviseksi järjestelmäksi, mitä nyt kutsutaan Kodezi OS:ksi, joka oppii jokaisesta virheestä, testistä ja committauksesta. “AI-CTO” -termi 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. Se 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 virheenkorjaukseen eikä koodin luomiseen. Mikä on tämän eron perussääntö kehittäjille?

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

Suurin osa nykyisistä AI-työkaluista on ohjausavusteisia, 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.

Se on se ero, joka on merkittävä. 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 virheenkorjausvirheyden. Voitko kertoa meille tarkemmin siitä tietokannasta ja menetelmästä, jota näissä benchmark-kokeissa käytettiin?

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

Jokainen benchmark on tiukka: mallin on luotava korjaus, sovellettava ja läpäistävä kaikki testit ilman takaiskuja. Ei käsivalikoituja esimerkkejä, ei cherry-picking-menestystä.

Chronos saavuttaa 67,3 prosentin korjausvirheyden ja 80,33 prosentin ratkaisuvirheyden SWE-bench Liten kanssa, 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 virheenkorjaukseen, 15 miljoonalla todellisella virheenkorjaustilanteella, joten se ei vain kuvioi, vaan diagnosoi.

Olet kuvaillut Kodezia “eläväksi infrastruktuuriksi”, joka ylläpitää ja kehittää yrityksen koodipohjaa autonomisesti. Miten lähellä olemme täysin itsekorjaavasta 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 kontekstuaalista tietoa ja historiallista muistia.

Täysin autonomisen tuotantoympäristön ylläpito, jossa infrastruktuuri diagnosoi, korjaa ja uudelleenjulkaisee itsensä, on kehittymässä. Näen sen kehittyvän vaiheittain: ensin säädellyissä CI-ympäristöissä, sitten esittely-ympäristöissä ja lopulta tuotantoympäristöissä ihmisen valvonnassa.

Pidämme aina ihmisen silmukassa luovien, arkkitehtuurin, eettisten päätösten tekemiseen. Useimmat toistuvat ja virheherkät työt, kuten linting, refaktorointi ja testien palauttaminen, tapahtuvat pian ilman väliintuloa.

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

Minulle “hiljainen” ei tarkoita hiljaisuutta. Se tarkoittaa luotettavuutta oletuksena. 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 sen päättelynsä 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 äänekäs tai loistava, vaan se, että se parantaa maailmaa hiljaisesti sen alla, missä se eniten merkitsee.

“Hiljainen tekniikka” on viehättävä – se viittaa teknologiaan, joka on voimakas mutta näkymätön. Miten näet tämän liikkeen muuttavan, miten ihmiset ja AI työskentelevät yhdessä insinööritöissä?

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

Insinööritöissä se tarkoittaa, että työkalu ei kysy “Mitä haluat minun tekemän?” Se jo tietää, mitä huomiota vaaditaan. Se näkee rikkinäisen riippuvuuden, korjaa sen, päivittää dokumentaation ja siirtyy eteenpäin.

Kun AI tulee osaksi kehittäjän pinorakennetta, yhteistyö siirtyy käskystä yhteiseloon. Ihmiset määrittävät aikomukset ja suunnan. AI suorittaa, ylläpitää ja optimoi hiljaisesti taustalla. Se on seuraava aikakausi, jossa tuottavuus tulee ei enemmän vuorovaikutuksesta, vaan vähemmän kitkasta.

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

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

Kodezi automatisoi toistuvan työn, joka tyhjentää fokus: virheenkorjaus, testien ylläpito, refaktorointi, dokumentaatio. Inhimillinen kerros, luovuus, järjestelmän suunnittelu ja vaihtoehtoisen päättelyn järjestelmä pysyvät korvaamattomina.

Pitkällä aikavälillä AI siirtää insinööritöitä toteutuksesta orkestraatioon. Kehittäjät tulevat käyttäjiksi käyttäytymisen arkkitehteiksi, ei syntaksin suorittajiksi. 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 on viiden vuoden kuluttua maailmassa, jossa ohjelmisto ylläpitää itseään?

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

Kuvittele maailmaa, jossa jokainen repositorio muistaa, jossa järjestelmä seuraa omia päätöksiään, korjaa regressioita ja kehittyy uusien riippuvuuksien kanssa automaattisesti. Se on elävä infrastruktuuri.

Tässä maailmassa kehittäjät toimivat enemmän kuin huoltajat. He määrittävät käytäntöjä, vahvistavat käyttäytymistä ja suunnittelevat aikomukset. Koodipohja tulee eläväksi olennoksi, joka sopeutuu, oppii ja ylläpitää itseään.

Se on sitä, mitä rakennamme Kodezilla: ohjelmisto, joka ei vain toimi. Se kestää.

Kiitos haastattelusta, lukijat, jotka haluavat oppia lisää, voivat vierailla Kodezi-sivustolla.