Entrevistas
Ishraq Khan, CEO y Fundador de Kodezi Inc – Serie de Entrevistas

Ishraq Khan, CEO y Fundador de Kodezi Inc., es un programador autodidacta que comenzó a programar a los ocho años y lanzó su primera startup mientras aún estaba en la escuela secundaria. Nacido en Dhaka, Bangladesh y más tarde trasladado a los Estados Unidos, construyó un historial de emprendimiento temprano, asegurando financiación de riesgo en la escuela secundaria y escalando un producto a más de 100,000 usuarios. Su camino refleja un enfoque en el aprendizaje independiente, la experimentación rápida y el impulso de construir sistemas que hagan que la tecnología sea más accesible y poderosa para los desarrolladores.
Kodezi Inc. es la empresa detrás de Kodezi OS, una plataforma autónoma diseñada para funcionar como un “CTO de IA” para equipos de ingeniería. Continuamente detecta y soluciona problemas, documenta automáticamente los sistemas, genera especificaciones de API, hace cumplir los estándares de codificación e integra directamente en las tuberías de CI/CD. Al transformar las bases de código en sistemas auto-sanadores y auto-gobernados, Kodezi ayuda a las organizaciones a construir software que es más confiable, escalable y eficiente.
Empezaste a codificar a los ocho años y fundaste tu primera startup en la escuela secundaria. ¿Qué te atrajo originalmente a la construcción de software tan temprano, y cómo moldearon esas experiencias tu mentalidad emprendedora?
Lo que me atrajo fue el control. Me mudé a los Estados Unidos como un niño que no hablaba inglés, así que el primer idioma que aprendí con fluidez fue el código. Era un espacio donde la lógica tenía sentido, donde podía construir algo y ver cómo respondía instantáneamente. Ese bucle de retroalimentación instantáneo se volvió adictivo. Me enseñó a pensar, no solo a programar.
Cuando construí TeachMeCode en la escuela secundaria, no se trataba de iniciar una empresa. Se trataba de hacer que el aprendizaje fuera más fácil para personas como yo. Pero a través de eso, aprendí cómo se comportan los sistemas, cómo responden los usuarios y cómo sucede el progreso línea por línea. Eso moldeó cómo veo el emprendimiento hoy en día: menos sobre ideas, más sobre bucles de retroalimentación, iteración y resiliencia.
Fuiste aceptado en 40 colegios, incluyendo varias instituciones de la Ivy League, pero decidiste no asistir. ¿Cuál fue el punto de inflexión que te hizo decidir que la construcción era más importante que esperar?
Para cuando terminé la escuela secundaria, ya había vivido lo que la mayoría de la gente va a la universidad a simular. Había lanzado productos, había presentado propuestas a inversores, había gestionado un equipo y había resuelto problemas reales. Tenía 40 cartas de aceptación en mi escritorio, incluyendo varias escuelas de la Ivy League, pero también tenía algo que la mayoría de los estudiantes no tenían: impulso.
El mayor riesgo era frenar. La universidad me habría enseñado marcos para la innovación, pero ya estaba ejecutando experimentos en el mundo real. No quería pausar un sistema activo para estudiar cómo iniciar uno. Para mí, el aula se convirtió en el producto en sí. Kodezi fue la educación que quería.
Kodezi comenzó como una idea cuando aún eras adolescente. ¿Cómo ha evolucionado la empresa desde su inicio en 2019, y cómo surgió tu visión de un “CTO de IA” con el tiempo?
Kodezi comenzó como una autocorrección de código, una idea simple de que la depuración podía ser más rápida. A medida que escalamos, me di cuenta de que la depuración no era el problema raíz. El problema real era que las bases de código nunca permanecen quietas. Evolucionan, se desvanecen y decaen más rápido de lo que los humanos pueden mantenerlas.
Con el tiempo, Kodezi evolucionó de un producto a un sistema operativo, lo que ahora llamamos Kodezi OS, que aprende de cada error, prueba y confirmación. El término “CTO de IA” surgió de manera natural. Los CTO no solo escriben código; mantienen la arquitectura, guían las decisiones y mantienen los sistemas vivos. Eso es lo que hace Kodezi, pero de manera continua y autónoma.
El modelo más reciente de Kodezi, Chronos, se describe como el primer sistema de IA construido específicamente para la depuración de código, en lugar de la generación de código. ¿Cuál es la diferencia fundamental que hace esta distinción para los desarrolladores?
Porque la depuración es la realidad, no la imaginación. La generación de código se trata de adivinar qué podría funcionar; la depuración se trata de entender por qué algo falló.
La mayoría de las herramientas de IA de hoy son asistentes basados en comandos que reaccionan cuando se les dice. Chronos, por otro lado, es proactivo. Recuerda errores anteriores, entiende gráficos de dependencias, ejecuta pruebas, valida soluciones y las refina hasta que el problema esté realmente resuelto.
Esa es la distinción que importa. Los desarrolladores no quieren un asistente que hable. Quieren infraestructura que actúe y actúe correctamente.
Los resultados que has compartido muestran que Chronos supera a GPT-4.1 y Claude 4 Opus en precisión de solución de errores. ¿Puedes explicarnos el conjunto de datos y la metodología detrás de esas pruebas?
Nuestra evaluación es empírica, no promocional. Chronos se prueba con miles de casos de depuración del mundo real extraídos de conjuntos de datos públicos como SWE-bench, Defects4J y BugsInPy, junto con datos empresariales anonimizados.
Cada prueba es estricta: el modelo debe generar un parche, aplicarlo y pasar todas las pruebas sin regresiones. No hay ejemplos seleccionados a mano, no hay selección de éxitos.
Chronos logra una precisión de solución del 67,3 por ciento y una tasa de resolución del 80,33 por ciento en SWE-bench Lite, mientras que GPT-4.1 y Claude 4.5 se mantienen por debajo del 15 por ciento. La diferencia no es el tamaño; es la especialización. Chronos se entrena en la depuración en sí, en 15 millones de sesiones de depuración reales, así que no solo hace coincidencias de patrones, sino que diagnostica.
Has descrito Kodezi como un “CTO de IA” que mantiene y evoluciona de manera autónoma la base de código de una empresa. ¿Cuán cerca estamos de tener infraestructura completamente auto-sanadora en entornos de producción?
Más cerca de lo que la mayoría de la gente piensa, al menos para sistemas deterministas. Hoy en día, Kodezi puede solucionar de manera autónoma muchos fallos de CI o CD, regresiones de pruebas y errores de tiempo de ejecución utilizando datos contextuales y memoria histórica.
La mantenimiento de producción completamente autónomo, donde la infraestructura diagnostica, cura y redeploya por sí misma, está surgiendo. Veo que evoluciona en etapas: primero dentro de entornos de CI controlados, luego entornos de staging y finalmente producción bajo supervisión humana.
Siempre mantendremos a un humano en el bucle para decisiones creativas, arquitectónicas y éticas, pero la mayoría del trabajo repetitivo y propenso a errores, como el linting, la refactorización y la recuperación de pruebas, pronto sucederá sin intervención.
Has hablado sobre sistemas que “hacen lo correcto de manera silenciosa”. ¿Qué significa esa filosofía en el contexto de la gobernanza de IA y la automatización responsable?
Para mí, “silencioso” no significa silente. Significa confiable por defecto. Un sistema de IA bien diseñado no debería necesitar una entrada o validación constante. Debe actuar de manera predecible, transparente y segura.
La automatización responsable significa que cada decisión tomada por la IA es explicable, reversible y registrada. Chronos documenta su razonamiento y acciones: qué cambió, por qué y cómo las pruebas validaron la solución.
La gobernanza está integrada en el sistema en sí. No hay modificaciones ocultas, no hay resultados de caja negra. El objetivo no es que la IA sea ruidosa o llamativa, sino que mejore el mundo de manera silenciosa bajo la superficie donde más importa.
El término “Tecnología Silenciosa” es atractivo; sugiere tecnología que es poderosa pero invisible. ¿Cómo ves que este movimiento cambia la forma en que los humanos y la IA colaboran en ingeniería?
La Tecnología Silenciosa es infraestructura que es poderosa pero invisible. La mejor tecnología no debería interrumpir; debería integrarse.
En ingeniería, eso significa que la herramienta no pregunta “¿Qué quieres que haga?”. Ya sabe qué necesita atención. Ve la dependencia rota, la parchea, actualiza la documentación y sigue adelante.
A medida que la IA se convierte en parte de la pila de desarrolladores, la colaboración cambia de comando a coexistencia. Los humanos definen la intención y la dirección. La IA ejecuta, mantiene y optimiza de manera silenciosa en el fondo. Esa es la próxima era, donde la productividad proviene no de más interacción, sino de menos fricción.
Muchos desarrolladores se preocupan por que las herramientas de IA los reemplacen. Has argumentado que la automatización debería liberar a los humanos para pensar, no reemplazarlos. ¿Cómo encarna Kodezi ese equilibrio?
La IA no reemplazará a los desarrolladores. Reemplazará la monotonía que los rodea. Los ingenieros no son valiosos porque escriben rápido; son valiosos porque piensan con claridad.
Kodezi automatiza el trabajo repetitivo que drena la atención: depuración, mantenimiento de pruebas, refactorización, documentación. La capa humana, la creatividad, el diseño de sistemas y la razón de las compensaciones permanecen insustituibles.
A largo plazo, la IA cambia la ingeniería de ejecución a orquestación. Los desarrolladores se convierten en arquitectos de comportamiento, no en ejecutores de sintaxis. Kodezi está diseñado para permitir esa transición, donde las máquinas mantienen y los humanos imaginan.
Has descrito Kodezi como “infraestructura viva”. Mirando hacia adelante cinco años, ¿cómo podría ser el papel del desarrollador en un mundo donde el software se mantiene a sí mismo?
En cinco años, los desarrolladores no pasarán la mitad de su tiempo solucionando lo que construyeron el trimestre pasado. Su papel se moverá desde el mantenimiento reactivo hacia la gobernanza proactiva.
Imagina un mundo donde cada repositorio tiene memoria, donde tu sistema rastrea sus propias decisiones, cura regresiones y evoluciona con nuevas dependencias de manera automática. Esa es la infraestructura viva.
En ese mundo, los desarrolladores actúan más como administradores. Definen políticas, verifican el comportamiento y diseñan la intención. La base de código se convierte en un organismo vivo que se adapta, aprende y se mantiene a sí mismo.
Eso es lo que estamos construyendo con Kodezi: software que no solo se ejecuta. Perdura.
Gracias por la gran entrevista, los lectores que deseen aprender más pueden visitar Kodezi.












