Ishraq Khan, CEO i założyciel Kodezi Inc – seria wywiadów

Ishraq Khan, CEO i założyciel Kodezi Inc., jest samoukiem programistą, który zaczął programować w wieku ośmiu lat i uruchomił swoją pierwszą firmę, gdy jeszcze był w szkole średniej. Urodzony w Dhaka, w Bangladeszu, a później przeniósł się do Stanów Zjednoczonych, zbudował rekord wczesnego przedsiębiorczości, zdobywając fundusze venture w szkole średniej i skalując produkt do ponad 100 000 użytkowników. Jego ścieżka życiowa odzwierciedla skupienie na samodzielnym uczeniu się, szybkim eksperymentowaniu i dążeniu do budowy systemów, które sprawiają, że technologia jest bardziej dostępna i potężna dla programistów.

Kodezi Inc. to firma za Kodezi OS, autonomiczną platformą zaprojektowaną do funkcjonowania jako „AI CTO” dla zespołów inżynierskich. Ciągle wykrywa i naprawia problemy, automatycznie dokumentuje systemy, generuje specyfikacje API, egzekwuje standardy kodowania i integruje się bezpośrednio z potokami CI/CD. Przekształcając kodowanie w samouzdrawiające, samorządzące systemy, Kodezi pomaga organizacjom budować oprogramowanie, które jest bardziej niezawodne, skalowalne i wydajne.

Zacząłeś programować w wieku ośmiu lat i założyłeś swoją pierwszą firmę w szkole średniej. Co cię pierwotnie skłoniło do budowy oprogramowania tak wcześnie, a jak te doświadczenia ukształtowały twoją przedsiębiorczą mentalność?

To, co mnie przyciągnęło, to kontrola. Przeprowadziłem się do Stanów Zjednoczonych jako dziecko, które nie mówiło po angielsku, więc pierwszym językiem, który nauczyłem się płynnie, był kod. Był to przestrzeń, w której logika miała sens, gdzie mogłem coś zbudować i zobaczyć, jak reaguje natychmiast. Ten natychmiastowy obiekt stał się uzależniający. Nauczył mnie, jak myśleć, a nie tylko jak programować.

Gdy zbudowałem TeachMeCode w szkole średniej, nie chciałem założyć firmy. Chciałem tylko ułatwić naukę ludziom takim jak ja. Ale dzięki temu nauczyłem się, jak zachowują się systemy, jak reagują użytkownicy i jak postępuje się krok po kroku. Ukształtowało to, jak widzę przedsiębiorczość dzisiaj: mniej idei, więcej pętli sprzężenia zwrotnego, iteracji i wytrwałości.

Zostałeś przyjęty do 40 college’ów, w tym kilku instytucji Ligi Ivy, ale zdecydowałeś się nie uczęszczać. Jaki był punkt zwrotny, który sprawił, że zdecydowałeś, że budowanie jest ważniejsze niż czekanie?

Do czasu, gdy skończyłem szkołę średnią, już doświadczyłem tego, co większość ludzi idzie na studia, aby to symulować. Uruchomiłem produkty, przedstawiłem inwestorom, zarządzałem zespołem i rozwiązywałem prawdziwe problemy. Miałem 40 listów przyjęcia na biurku, w tym kilka szkół Ligi Ivy, ale miałem też coś, czego większość studentów nie miała: momentum.

Ryzyko było większe, gdybym zwolnił. College nauczyłby mnie ram dla innowacji, ale ja już prowadziłem eksperymenty w świecie rzeczywistym. Nie chciałem zatrzymać aktywnego systemu, aby uczyć się, jak go uruchomić. Dla mnie klasa stała się produktem samym w sobie. Kodezi była edukacją, której potrzebowałem.

Kodezi zaczęło się jako pomysł, gdy jeszcze byłeś nastolatkiem. Jak ewoluowała firma od swojego powstania w 2019 roku, a jak twoja wizja „AI CTO” wyłoniła się z czasem?

Kodezi zaczęło się jako autocorrect dla kodu, prosty pomysł, że debugowanie mogłoby być szybsze. Gdy skalowaliśmy, zrealizowałem, że debugowanie nie było głównym problemem. Prawdziwy problem polegał na tym, że kodowanie nigdy nie pozostaje w miejscu. Ewoluuje, dryfuje i ulega degradacji szybciej, niż ludzie mogą je utrzymać.

W miarę upływu czasu Kodezi ewoluowało z produktu w system operacyjny, który teraz nazywamy Kodezi OS, który uczy się z każdego błędu, testu i commitu. Termin „AI CTO” wyłonił się naturalnie. CTO nie tylko pisze kod; utrzymuje architekturę, kieruje decyzjami i utrzymuje systemy przy życiu. To właśnie robi Kodezi, ale w sposób ciągły i autonomiczny.

Najnowszy model Kodezi, Chronos, jest opisany jako pierwszy system AI zbudowany specjalnie do debugowania kodu — a nie generowania kodu. Jaka fundamentalna różnica ta odróżnia dla programistów?

Ponieważ debugowanie jest rzeczywistością, a nie wyobraźnią. Generowanie kodu dotyczy tego, co mogłoby działać; debugowanie dotyczy zrozumienia, dlaczego coś nie powiodło się.

Większość narzędzi AI dzisiaj są oparte na reakcjach na polecenia. Chronos jest proaktywny. Pamięta poprzednie błędy, rozumie grafy zależności, uruchamia testy, waliduje poprawki i udoskonala je, aż problem zostanie naprawiony.

To jest różnica, która ma znaczenie. Programiści nie chcą asystenta, który mówi. Chcą infrastruktury, która działa i działa poprawnie.

Wyniki, które podzieliłeś, pokazują, że Chronos przewyższa GPT-4.1 i Claude 4 Opus w dokładności naprawy błędów. Czy możesz nas przeprowadzić przez zestaw danych i metodologię za tymi benchmarkami?

Nasza ocena jest empiryczna, a nie promocyjna. Chronos jest testowany na tysiącach przypadków debugowania z rzeczywistych zestawów danych, takich jak SWE-bench, Defects4J i BugsInPy, wraz z anonimowanymi danymi przedsiębiorstw.

Każdy benchmark jest ścisły: model musi wygenerować poprawkę, zastosować ją i przejść wszystkie testy przypadków bez regresji. Nie ma ręcznie wybranych przykładów, nie ma selekcji sukcesu.

Chronos osiąga 67,3 procent dokładności naprawy i 80,33 procent wskaźnika rozwiązania na SWE-bench Lite, podczas gdy GPT-4.1 i Claude 4.5 pozostają poniżej 15 procent. Różnica nie polega na rozmiarze; polega na specjalizacji. Chronos jest szkolony na debugowaniu samym w sobie, na 15 milionach rzeczywistych sesjach debugowania, więc nie tylko dopasowuje wzorce, ale diagnozuje.

Mówiłeś o Kodezi jako o „AI CTO”, który autonomicznie utrzymuje i rozwija kodowanie firmy. Jak blisko jesteśmy do pełnej samouzdrawiającej się infrastruktury w środowiskach produkcyjnych?

Bliżej, niż większość ludzi myśli, przynajmniej dla systemów deterministycznych. Dzisiaj Kodezi może autonomicznie naprawiać wiele awarii CI lub CD, regresji testowych i błędów czasu wykonywania przy użyciu danych kontekstowych i pamięci historycznej.

Pełna autonomiczna konserwacja produkcji, gdzie infrastruktura diagnozuje, leczy i ponownie wdraża sama siebie, jest w powijakach. Widzę, jak ewoluuje w etapach: najpierw w kontrolowanych środowiskach CI, potem w środowiskach testowych i w końcu w produkcji pod nadzorem ludzkim.

Zawsze będziemy trzymać człowieka w pętli sprzężenia zwrotnego dla kreatywnych, architektonicznych i etycznych decyzji, ale większość powtarzalnej i podatnej na błędy pracy, takiej jak linting, refactoring i odzyskiwanie testów, wkrótce będzie się odbywać bez interwencji.

Mówiłeś o systemach, które „cicho robią to, co słuszne”. Co oznacza ta filozofia w kontekście zarządzania AI i odpowiedzialnej automatyzacji?

Dla mnie „cicho” nie oznacza cicho. Oznacza godne zaufania domyślnie. Dobrze zaprojektowany system AI nie powinien potrzebować ciągłego wejścia lub walidacji. Powinien działać przewidywalnie, transparentnie i bezpiecznie.

Odpowiedzialna automatyzacja oznacza, że każda decyzja podjęta przez AI jest wyjaśnialna, odwracalna i zalogowana. Chronos dokumentuje swoje rozumowanie i działania: co zmienił, dlaczego i jak testy potwierdziły poprawkę.

Zarządzanie jest wbudowane w sam system. Nie ma ukrytych modyfikacji, nie ma wyników czarnej skrzynki. Celem jest nie to, aby AI było głośne czy efektowne, ale to, aby cicho poprawiało świat pod powierzchnią, gdzie to się najbardziej liczy.

Termin „Quiet Tech” jest przekonywujący — sugeruje technologię, która jest potężna, ale niewidoczna. Jak widzisz ten ruch zmieniający sposób, w jaki ludzie i AI współpracują w inżynierii?

Quiet Tech to infrastruktura, która jest potężna, ale niewidoczna. Najlepsza technologia nie powinna przerywać; powinna integrować.

W inżynierii oznacza to, że narzędzie nie pyta „Co chcesz, abym zrobił?” Wiele już wie, co wymaga uwagi. Widzi złamaną zależność, łata ją, aktualizuje dokumentację i przechodzi dalej.

W miarę jak AI staje się częścią stosu programistycznego, współpraca przechodzi od polecenia do współistnienia. Ludzie definiują intencję i kierunek. AI wykonuje, utrzymuje i optymalizuje cicho na tle. To jest następna era, w której produktywność pochodzi nie z większej interakcji, ale z mniejszego tarcia.

Wielu programistów obawia się, że narzędzia AI zastąpią ich. Twierdziłeś, że automatyzacja powinna uwolnić ludzi, aby myśleli, a nie zastąpić ich. Jak Kodezi uosabia ten balans?

AI nie zastąpi programistów. Zastąpi monotonną pracę wokół nich. Inżynierowie nie są cenni, ponieważ piszą szybko; są cenni, ponieważ myślą wyraźnie.

Kodezi automatyzuje powtarzalną pracę, która pochłania uwagę: debugowanie, konserwację testów, refactoring i dokumentację. Warstwa ludzka, kreatywność, projektowanie systemów i rozumowanie dotyczące kompromisów pozostają niezastąpione.

W długiej perspektywie AI przenosi inżynierię z wykonania do orkiestracji. Programiści stają się architektami zachowania, a nie wykonawcami składni. Kodezi jest zbudowany, aby umożliwić tę transformację, w której maszyny utrzymują, a ludzie wyobrażają.

Opisałeś Kodezi jako „żywą infrastrukturę”. Spójrzając pięć lat do przodu, jaki może być rolą programisty w świecie, w którym oprogramowanie utrzymuje się samo?

W ciągu pięciu lat programiści nie będą spędzać połowy swojego czasu na naprawie tego, co zbudowali w poprzednim kwartale. Ich rola przesunie się od reaktywnej konserwacji do proaktywnej kontroli.

Wyobraź sobie świat, w którym każde repozytorium ma pamięć, w którym system śledzi własne decyzje, leczy regresje i ewoluuje z nowymi zależnościami automatycznie. To jest żywa infrastruktura.

W tym świecie programiści działają bardziej jak opiekunowie. Definiują politykę, weryfikują zachowanie i projektują intencję. Kodowanie staje się żywym organizmem, który adaptuje się, uczy i utrzymuje się sam.

To jest to, co budujemy z Kodezi: oprogramowanie, które nie tylko działa. Trwa.

Dziękujemy za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Kodezi.