Ishraq Khan, PDG et fondateur de Kodezi Inc – Série d’entretiens

Ishraq Khan, PDG et fondateur de Kodezi Inc., est un codeur autodidacte qui a commencé à programmer à l’âge de huit ans et a lancé son premier startup alors qu’il était encore au collège. Né à Dhaka, au Bangladesh, et ayant plus tard déménagé aux États-Unis, il a construit un parcours d’entrepreneuriat précoce, obtenant des financements de capital-risque au lycée et faisant évoluer un produit à plus de 100 000 utilisateurs. Son parcours reflète une concentration sur l’apprentissage indépendant, l’expérimentation rapide et la volonté de construire des systèmes qui rendent la technologie plus accessible et puissante pour les développeurs.

Kodezi Inc. est l’entreprise derrière Kodezi OS, une plateforme autonome conçue pour fonctionner comme un « CTO IA » pour les équipes d’ingénieurs. Elle détecte et corrige en continu les problèmes, documente automatiquement les systèmes, génère des spécifications d’API, impose des normes de codage et s’intègre directement dans les pipelines CI/CD. En transformant les bases de code en systèmes auto-réparateurs et auto-régulateurs, Kodezi aide les organisations à construire des logiciels plus fiables, évolutifs et efficaces.

Vous avez commencé à coder à seulement huit ans et avez fondé votre première startup au collège. Qu’est-ce qui vous a initialement attiré vers la construction de logiciels si tôt, et comment ces expériences ont-elles façonné votre mentalité d’entrepreneur ?

Ce qui m’a attiré, c’était le contrôle. Je me suis installé aux États-Unis en tant qu’enfant qui ne parlait pas anglais, donc la première langue que j’ai apprise couramment était le code. C’était un espace où la logique avait du sens, où je pouvais construire quelque chose et voir sa réponse instantanément. Cette boucle de rétroaction instantanée est devenue addictive. Cela m’a appris à réfléchir, pas seulement à programmer.

Lorsque j’ai construit TeachMeCode au collège, ce n’était pas pour lancer une entreprise. C’était pour rendre l’apprentissage plus facile pour les gens comme moi. Mais à travers cela, j’ai appris comment les systèmes se comportent, comment les utilisateurs réagissent et comment le progrès se produit ligne par ligne. Cela a façonné ma vision de l’entrepreneuriat aujourd’hui : moins d’idées, plus de boucles de rétroaction, d’itération et de résilience.

Vous avez été accepté dans 40 collèges, dont plusieurs institutions de la Ligue Ivy, mais vous avez choisi de ne pas y aller. Quel a été le point de basculement qui vous a fait décider que construire était plus important que attendre ?

Au moment où j’ai terminé le lycée, j’avais déjà vécu ce que la plupart des gens vont à l’université pour simuler. J’avais lancé des produits, présenté des investisseurs, géré une équipe et résolu des problèmes réels. J’avais 40 lettres d’acceptation sur mon bureau, dont plusieurs écoles de la Ligue Ivy, mais j’avais également quelque chose que la plupart des étudiants n’ont pas : de l’élan.

Le plus grand risque était de ralentir. L’université m’aurait enseigné des cadres pour l’innovation, mais j’étais déjà en train de réaliser des expériences dans le monde réel. Je ne voulais pas interrompre un système actif pour étudier comment en démarrer un. Pour moi, la salle de classe est devenue le produit lui-même. Kodezi était l’éducation que je voulais.

Kodezi a commencé comme une idée lorsque vous étiez encore adolescent. Comment l’entreprise a-t-elle évolué depuis sa création en 2019, et comment votre vision d’un « CTO IA » a-t-elle émergé au fil du temps ?

Kodezi a commencé comme une autocorrection de code, une idée simple selon laquelle le débogage pouvait être plus rapide. À mesure que nous avons évolué, j’ai réalisé que le débogage n’était pas le problème de base. Le véritable problème était que les bases de code ne restent jamais immobiles. Elles évoluent, dérivent et se détériorent plus rapidement que les humains ne peuvent les maintenir.

Au fil du temps, Kodezi est passé d’un produit à un système d’exploitation, ce que nous appelons maintenant Kodezi OS, qui apprend de chaque bogue, test et commit. Le terme « CTO IA » est apparu naturellement. Les CTO n’écrivent pas seulement du code ; ils maintiennent l’architecture, guident les décisions et gardent les systèmes en vie. C’est ce que fait Kodezi, mais de manière continue et autonome.

Le dernier modèle de Kodezi, Chronos, est décrit comme le premier système IA conçu spécifiquement pour le débogage de code — et non pour la génération de code. Quelle est la différence fondamentale que cette distinction fait pour les développeurs ?

Parce que le débogage est la réalité, et non l’imagination. La génération de code concerne la supposition de ce qui pourrait fonctionner ; le débogage consiste à comprendre pourquoi quelque chose a échoué.

La plupart des outils IA d’aujourd’hui sont des assistants basés sur des invites qui réagissent lorsqu’ils sont sollicités. Chronos, en revanche, est proactif. Il se souvient des bogues précédents, comprend les graphiques de dépendance, exécute des tests, valide les corrections et les affine jusqu’à ce que le problème soit réellement résolu.

C’est la distinction qui compte. Les développeurs ne veulent pas d’un assistant qui parle. Ils veulent une infrastructure qui agit et agit correctement.

Les résultats que vous avez partagés montrent Chronos surpassant GPT-4.1 et Claude 4 Opus en termes de précision de correction de bogues. Pouvez-vous nous guider à travers le jeu de données et la méthodologie derrière ces benchmarks ?

Notre évaluation est empirique, et non promotionnelle. Chronos est testé sur des milliers de cas de débogage réels issus de jeux de données publics tels que SWE-bench, Defects4J et BugsInPy, ainsi que des données d’entreprise anonymisées.

Chaque benchmark est strict : le modèle doit générer une correction, l’appliquer et passer tous les tests sans régressions. Aucun exemple sélectionné à la main, aucun choix de succès.

Chronos atteint 67,3 % de précision de correction et 80,33 % de taux de résolution sur SWE-bench Lite, tandis que GPT-4.1 et Claude 4.5 restent en dessous de 15 %. La différence n’est pas de taille ; c’est de spécialisation. Chronos est formé sur le débogage lui-même, sur 15 millions de sessions de débogage réelles, il ne fait donc pas que faire correspondre des modèles, il diagnostique.

Vous avez décrit Kodezi comme un « CTO IA » qui maintient et fait évoluer de manière autonome la base de code d’une entreprise. À quel point sommes-nous proches d’une infrastructure auto-réparatrice en production ?

Plus proches que la plupart des gens le pensent, du moins pour les systèmes déterministes. Aujourd’hui, Kodezi peut corriger de manière autonome de nombreux échecs de CI ou de CD, des régressions de test et des erreurs de runtime en utilisant des données contextuelles et une mémoire historique.

La maintenance de production entièrement autonome, où l’infrastructure diagnostique, se rétablit et se redéploie elle-même, émerge. Je le vois évoluer par étapes : d’abord dans des environnements de CI contrôlés, puis dans des environnements de staging, et enfin en production sous surveillance humaine.

Nous allons toujours garder un humain dans la boucle pour les décisions créatives, architecturales et éthiques, mais la plupart du travail répétitif et sujet à erreurs tel que le lissage, la refactoring et la récupération de tests se fera bientôt sans intervention.

Vous avez parlé de systèmes qui « font calmement la bonne chose ». Quelle est la signification de cette philosophie dans le contexte de la gouvernance de l’IA et de l’automatisation responsable ?

Pour moi, « calme » ne signifie pas silencieux. Cela signifie digne de confiance par défaut. Un système IA bien conçu ne devrait pas avoir besoin d’une validation constante ou d’entrée. Il devrait agir de manière prévisible, transparente et sûre.

L’automatisation responsable signifie que chaque décision prise par l’IA est explicables, réversible et enregistrée. Chronos documente son raisonnement et ses actions : ce qu’il a changé, pourquoi, et comment les tests ont validé la correction.

La gouvernance est intégrée au système lui-même. Aucune modification cachée, aucun résultat de boîte noire. L’objectif n’est pas pour l’IA d’être bruyante ou tape-à-l’œil, mais d’améliorer calmement le monde en dessous de la surface où cela compte le plus.

Le terme « Quiet Tech » est convaincant — il suggère une technologie puissante mais invisible. Comment voyez-vous ce mouvement réformer la façon dont les humains et l’IA collaborent dans l’ingénierie ?

La Quiet Tech est une infrastructure puissante mais invisible. La meilleure technologie ne devrait pas interrompre ; elle devrait s’intégrer.

Dans l’ingénierie, cela signifie que l’outil ne demande pas « Que voulez-vous que je fasse ? » Il sait déjà ce qui nécessite une attention. Il voit la dépendance cassée, la corrige, met à jour la documentation et passe à autre chose.

À mesure que l’IA devient partie intégrante de la pile de développement, la collaboration passe de la commande à la coexistence. Les humains définissent l’intention et la direction. L’IA exécute, maintient et optimise calmement en arrière-plan. C’est l’ère à venir, où la productivité vient non pas de plus d’interaction, mais de moins de friction.

De nombreux développeurs s’inquiètent de l’impact des outils IA sur leur emploi. Vous avez argumenté que l’automatisation devrait libérer les humains pour réfléchir, et non les remplacer. Comment Kodezi incarne-t-il cet équilibre ?

L’IA ne remplacera pas les développeurs. Elle remplacera la monotonie qui les entoure. Les ingénieurs ne sont pas précieux parce qu’ils tapent rapidement ; ils sont précieux parce qu’ils pensent clairement.

Kodezi automatise le travail répétitif qui épuise l’attention : le débogage, la maintenance de tests, la refactoring, la documentation. La couche humaine, la créativité, la conception de systèmes et la prise de décision restent insubstituables.

À long terme, l’IA déplace l’ingénierie de l’exécution à l’orchestration. Les développeurs deviennent des architectes de comportement, et non des exécutants de syntaxe. Kodezi est conçu pour permettre cette transition, où les machines maintiennent et les humains imaginent.

Vous avez décrit Kodezi comme des « infrastructures vivantes ». En regardant cinq ans dans le futur, à quoi pourrait ressembler le rôle du développeur dans un monde où les logiciels se maintiennent eux-mêmes ?

Dans cinq ans, les développeurs ne passeront pas la moitié de leur temps à corriger ce qu’ils ont construit le trimestre précédent. Leur rôle passera de la maintenance réactive à la gouvernance proactive.

Imaginez un monde où chaque référentiel a une mémoire, où votre système suit ses propres décisions, corrige les régressions et évolue avec de nouvelles dépendances automatiquement. C’est ce que sont les infrastructures vivantes.

Dans ce monde, les développeurs agissent plus comme des intendants. Ils définissent des politiques, vérifient le comportement et conçoivent l’intention. La base de code devient un organisme vivant qui s’adapte, apprend et se maintient lui-même.

C’est ce que nous construisons avec Kodezi : des logiciels qui ne font pas que fonctionner. Ils durent.

Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Kodezi.