Ishraq Khan, CEO und Gründer von Kodezi Inc. – Interviewreihe

Ishraq Khan, CEO und Gründer von Kodezi Inc., ist ein selbstständiger Programmierer, der im Alter von acht Jahren mit dem Programmieren begann und sein erstes Startup noch in der Mittelschule gründete. Geboren in Dhaka, Bangladesch, und später in die Vereinigten Staaten gezogen, baute er eine Erfolgsbilanz als junger Unternehmer auf, indem er Risikokapital in der High School sicherte und ein Produkt auf über 100.000 Benutzer skalieren konnte. Sein Weg spiegelt eine Konzentration auf selbstständiges Lernen, schnelles Experimentieren und den Wunsch wider, Systeme zu entwickeln, die die Technologie für Entwickler zugänglicher und leistungsfähiger machen.

Kodezi Inc. ist das Unternehmen hinter Kodezi OS, einer autonomen Plattform, die als “AI-CTO” für Ingenieursteams fungiert. Sie erkennt und behebt kontinuierlich Probleme, dokumentiert Systeme automatisch, generiert API-Spezifikationen, überwacht die Einhaltung von Codierstandards und integriert sich direkt in CI/CD-Pipelines. Durch die Umwandlung von Codebasen in selbstheilende und selbstregulierende Systeme hilft Kodezi Organisationen dabei, zuverlässigere, skalierbarere und effizientere Software zu entwickeln.

Sie haben im Alter von acht Jahren mit dem Programmieren begonnen und Ihr erstes Startup in der Mittelschule gegründet. Was hat Sie ursprünglich dazu gebracht, so früh mit der Softwareentwicklung zu beginnen, und wie haben diese Erfahrungen Ihre unternehmerische Denkweise geprägt?

Was mich anzog, war die Kontrolle. Als ich als Kind in die Vereinigten Staaten zog, sprach ich kein Englisch, also war die erste Sprache, die ich fließend lernte, die Programmiersprache. Es war ein Bereich, in dem Logik Sinn ergab, in dem ich etwas aufbauen und es sofort reagieren sehen konnte. Diese sofortige Rückkopplungsschleife wurde süchtig machend. Sie lehrte mich, wie man denkt, nicht nur, wie man programmiert.

Als ich TeachMeCode in der Mittelschule aufbaute, ging es nicht darum, ein Unternehmen zu gründen. Es ging darum, das Lernen für Menschen wie mich zu erleichtern. Durch diese Erfahrung lernte ich jedoch, wie Systeme funktionieren, wie Benutzer reagieren und wie Fortschritte Schritt für Schritt erfolgen. Das prägte meine Sicht auf Unternehmertum heute: weniger auf Ideen, mehr auf Rückkopplungsschleifen, Iteration und Widerstandsfähigkeit.

Sie wurden an 40 Hochschulen angenommen, darunter mehrere Ivy-League-Universitäten, aber entschieden sich dagegen, zu studieren. Was war der Wendepunkt, der Sie dazu brachte, zu erkennen, dass Bauen wichtiger war als Warten?

Als ich die High School beendete, hatte ich bereits das erlebt, was die meisten Menschen auf dem College simulieren wollen. Ich hatte Produkte gestartet, Investoren angesprochen, ein Team geleitet und reale Probleme gelöst. Ich hatte 40 Zulassungsbriefe auf meinem Schreibtisch, darunter mehrere Ivy-League-Universitäten, aber ich hatte auch etwas, das die meisten Studenten nicht haben: Schwung.

Das größere Risiko bestand darin, den Schwung zu verlieren. Das College würde mir Rahmenbedingungen für Innovation vermitteln, aber ich führte bereits Experimente in der realen Welt durch. Ich wollte das aktive System nicht pausieren, um zu lernen, wie man es startet. Für mich wurde das Produkt selbst zur Klasse. Kodezi war die Ausbildung, die ich wollte.

Kodezi begann als Idee, als Sie noch ein Teenager waren. Wie hat sich das Unternehmen seit seiner Gründung im Jahr 2019 entwickelt, und wie entstand Ihre Vision von einem “AI-CTO” im Laufe der Zeit?

Kodezi startete als Autokorrektur für Code, eine einfache Idee, dass das Debuggen schneller sein könnte. Als wir skalierten, erkannte ich, dass das Debuggen nicht das eigentliche Problem war. Das eigentliche Problem war, dass Codebasen nie stillstehen. Sie entwickeln sich, verändern sich und verfallen schneller, als Menschen sie aufrechterhalten können.

Im Laufe der Zeit entwickelte sich Kodezi von einem Produkt zu einem Betriebssystem, das wir jetzt Kodezi OS nennen, das von jedem Bug, jedem Test und jedem Commit lernt. Der Begriff “AI-CTO” entstand natürlich. CTOs schreiben nicht nur Code; sie pflegen die Architektur, leiten Entscheidungen und halten Systeme am Leben. Das ist, was Kodezi tut, aber kontinuierlich und autonom.

Kodezis neuestes Modell, Chronos, wird als erstes AI-System beschrieben, das speziell für die Fehlersuche in Code und nicht für die Codegenerierung entwickelt wurde. Welchen grundlegenden Unterschied macht diese Unterscheidung für Entwickler?

Weil das Debuggen die Realität ist, nicht die Vorstellung. Codegenerierung ist darum, zu erraten, was funktionieren könnte; Debuggen ist darum, zu verstehen, warum etwas fehlgeschlagen ist.

Die meisten AI-Tools heute sind promptbasierte Assistenten, die reagieren, wenn sie angewiesen werden. Chronos hingegen ist proaktiv. Es erinnert sich an vorherige Fehler, versteht Abhängigkeitsgraphen, führt Tests durch, validiert Korrekturen und verfeinert sie, bis das Problem tatsächlich gelöst ist.

Das ist der Unterschied, der zählt. Entwickler wollen keinen Assistenten, der spricht. Sie wollen Infrastruktur, die handelt und richtig handelt.

Die Ergebnisse, die Sie geteilt haben, zeigen, dass Chronos GPT-4.1 und Claude 4 Opus bei der Fehlersuchgenauigkeit übertrifft. Können Sie uns durch die Datenbank und die Methodik hinter diesen Benchmarks führen?

Unsere Bewertung ist empirisch, nicht werblich. Chronos wird auf Tausenden von realen Fehlersuchen getestet, die aus öffentlichen Datenbanken wie SWE-bench, Defects4J und BugsInPy sowie aus anonymisierten Unternehmensdaten stammen.

Jeder Benchmark ist streng: Das Modell muss einen Patch generieren, anwenden und alle Testfälle ohne Rückfälle bestehen. Keine handverlesenen Beispiele, keine Cherry-Picking von Erfolgen.

Chronos erreicht eine Fehlersuchgenauigkeit von 67,3 Prozent und eine Lösungsrate von 80,33 Prozent bei SWE-bench Lite, während GPT-4.1 und Claude 4.5 unter 15 Prozent bleiben. Der Unterschied liegt nicht in der Größe, sondern in der Spezialisierung. Chronos ist auf Fehlersuche trainiert, auf 15 Millionen realen Fehlersuchen, also macht es nicht nur Mustererkennung, sondern Diagnose.

Sie haben Kodezi als “AI-CTO” beschrieben, der autonom die Codebasis eines Unternehmens wartet und weiterentwickelt. Wie nahe sind wir an einer vollständig selbstheilenden Infrastruktur in Produktionsumgebungen?

Näher, als die meisten Menschen denken, zumindest für deterministische Systeme. Heute kann Kodezi viele CI- oder CD-Fehler, Testrückschläge und Laufzeitfehler autonom beheben, indem es kontextuelle Daten und historisches Gedächtnis nutzt.

Die vollständig autonome Wartung von Produktionsumgebungen, bei der die Infrastruktur selbst diagnostiziert, heilt und neu bereitstellt, ist im Entstehen. Ich sehe es in Stufen entstehen: Zuerst in kontrollierten CI-Umgebungen, dann in Staging-Umgebungen und schließlich in der Produktion unter menschlicher Aufsicht.

Wir werden immer einen Menschen in der Schleife halten für kreative, architektonische und ethische Entscheidungen, aber die meisten repetitiven und fehleranfälligen Arbeiten wie Linting, Refactoring und Testwiederherstellung werden bald ohne Eingreifen erfolgen.

Sie haben von Systemen gesprochen, die “leise das Richtige tun”. Was bedeutet diese Philosophie im Kontext der AI-Governance und verantwortungsvollen Automatisierung?

Für mich bedeutet “leise” nicht still. Es bedeutet vertrauenswürdig von Beginn an. Ein gut konzipiertes AI-System sollte nicht ständig nach Input oder Validierung fragen. Es sollte vorhersehbar, transparent und sicher handeln.

Verantwortungsvolle Automatisierung bedeutet, dass jede Entscheidung, die das AI-System trifft, erklärbar, rückgängig machbar und protokolliert ist. Chronos dokumentiert seine Argumentation und Aktionen: Was es geändert hat, warum und wie die Tests die Korrektur validierten.

Die Governance ist in das System selbst integriert. Keine versteckten Modifikationen, keine Black-Box-Ergebnisse. Das Ziel ist nicht, dass AI laut oder auffällig ist, sondern dass es leise die Welt unter der Oberfläche verbessert, wo es am meisten zählt.

Der Begriff “Quiet Tech” ist überzeugend – er suggeriert Technologie, die leistungsstark, aber unsichtbar ist. Wie sehen Sie diese Bewegung die Zusammenarbeit zwischen Menschen und AI in der Ingenieurwissenschaft verändern?

Quiet Tech ist Infrastruktur, die leistungsstark, aber unsichtbar ist. Die beste Technologie sollte nicht unterbrechen; sie sollte integrieren.

In der Ingenieurwissenschaft bedeutet das, dass das Werkzeug nicht fragt: “Was soll ich tun?” Es weiß bereits, was Aufmerksamkeit benötigt. Es sieht den fehlerhaften Abhängigkeitsgraphen, patcht ihn, aktualisiert die Dokumentation und bewegt sich weiter.

Wenn AI Teil des Entwicklerstapels wird, verlagert sich die Zusammenarbeit von Befehl zu Koexistenz. Menschen definieren die Absicht und Richtung. Das AI führt aus, wartet und optimiert leise im Hintergrund. Das ist die nächste Ära, in der Produktivität nicht durch mehr Interaktion, sondern durch weniger Reibung entsteht.

Viele Entwickler befürchten, dass AI-Tools sie ersetzen. Sie haben argumentiert, dass Automatisierung Menschen dazu befreien sollte, zu denken, und nicht ersetzen. Wie verkörpert Kodezi diese Balance?

AI wird Entwickler nicht ersetzen. Es wird die Routinearbeiten ersetzen, die ihre Konzentration schwächen. Ingenieure sind nicht wertvoll, weil sie schnell tippen; sie sind wertvoll, weil sie klar denken.

Kodezi automatisiert die repetitiven Arbeiten, die die Konzentration schwächen: Debuggen, Testwartung, Refactoring, Dokumentation. Die menschliche Ebene, Kreativität, Systemdesign und Abwägung bleiben unersetzlich.

Langfristig verlagert AI die Ingenieurarbeit von der Ausführung zur Orchestrierung. Entwickler werden zu Architekten des Verhaltens, nicht zu Ausführenden von Syntax. Kodezi ist darauf ausgelegt, diesen Übergang zu ermöglichen, bei dem Maschinen warten und Menschen imaginieren.

Sie haben Kodezi als “lebende Infrastruktur” bezeichnet. Wie könnte die Rolle des Entwicklers in fünf Jahren in einer Welt aussehen, in der Software sich selbst erhält?

In fünf Jahren werden Entwickler nicht die Hälfte ihrer Zeit damit verbringen, das zu reparieren, was sie im letzten Quartal gebaut haben. Ihre Rolle wird sich von reaktiver Wartung zu proaktiver Governance verlagern.

Stellen Sie sich eine Welt vor, in der jedes Repository ein Gedächtnis hat, in der Ihr System seine eigenen Entscheidungen verfolgt, Rückschläge behebt und sich automatisch an neue Abhängigkeiten anpasst. Das ist lebende Infrastruktur.

In dieser Welt agieren Entwickler mehr als Verwalter. Sie definieren Richtlinien, überprüfen das Verhalten und entwerfen die Absicht. Die Codebasis wird zu einem lebenden Organismus, der sich anpasst, lernt und sich selbst erhält.

Das ist, was wir mit Kodezi aufbauen: Software, die nicht nur läuft. Sie überdauert.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten Kodezi besuchen.