Ishraq Khan, CEO e Fundador da Kodezi Inc – Série de Entrevistas

Ishraq Khan, CEO e Fundador da Kodezi Inc., é um programador autodidata que começou a programar aos oito anos e lançou sua primeira startup ainda no ensino fundamental. Nascido em Dhaka, Bangladesh, e mais tarde mudou-se para os Estados Unidos, ele construiu um histórico de empreendedorismo precoce, garantindo financiamento de venture capital no ensino médio e escalando um produto para mais de 100.000 usuários. Seu caminho reflete um foco no aprendizado independente, experimentação rápida e um impulso para construir sistemas que tornam a tecnologia mais acessível e poderosa para os desenvolvedores.

Kodezi Inc. é a empresa por trás do Kodezi OS, uma plataforma autônoma projetada para funcionar como um “CTO de IA” para equipes de engenharia. Ela detecta e corrige continuamente problemas, documenta automaticamente sistemas, gera especificações de API, impõe padrões de codificação e integra-se diretamente aos pipelines de CI/CD. Ao transformar repositórios de código em sistemas auto-curativos e auto-governados, a Kodezi ajuda as organizações a construir software mais confiável, escalável e eficiente.

Você começou a programar aos oito anos e fundou sua primeira startup no ensino fundamental. O que o atraiu originalmente para construir software tão cedo, e como essas experiências moldaram sua mentalidade empreendedora?

O que me atraiu foi o controle. Eu me mudei para os Estados Unidos como uma criança que não falava inglês, então a primeira linguagem que eu aprendi fluentemente foi a codificação. Era um espaço onde a lógica fazia sentido, onde eu podia construir algo e ver sua resposta instantaneamente. Esse loop de feedback instantâneo se tornou viciante. Ele me ensinou a pensar, não apenas a programar.

Quando eu construí o TeachMeCode no ensino fundamental, não era sobre iniciar uma empresa. Era sobre tornar o aprendizado mais fácil para pessoas como eu. Mas através disso, eu aprendi como os sistemas se comportam, como os usuários respondem e como o progresso acontece linha por linha. Isso moldou como eu vejo o empreendedorismo hoje: menos sobre ideias, mais sobre loops de feedback, iteração e resiliência.

Você foi aceito em 40 faculdades – incluindo várias instituições da Ivy League – mas escolheu não frequentar. Qual foi o ponto de inflexão que o fez decidir que construir era mais importante do que esperar?

No momento em que terminei o ensino médio, eu já havia vivido o que a maioria das pessoas vai à faculdade para simular. Eu havia lançado produtos, apresentado pitches para investidores, gerenciado uma equipe e resolvido problemas reais. Eu tinha 40 cartas de aceitação na minha mesa, incluindo várias escolas da Ivy League, mas eu também tinha algo que a maioria dos estudantes não tem: momentum.

O maior risco era desacelerar. A faculdade teria me ensinado estruturas para inovação, mas eu já estava executando experimentos no mundo real. Eu não queria pausar um sistema ativo para estudar como iniciar um. Para mim, a sala de aula se tornou o próprio produto. Kodezi era a educação que eu queria.

Kodezi começou como uma ideia quando você ainda era um adolescente. Como a empresa evoluiu desde sua criação em 2019, e como sua visão de um “CTO de IA” surgiu ao longo do tempo?

Kodezi começou como um autocorreção para código, uma ideia simples de que a depuração poderia ser mais rápida. À medida que escalamos, eu percebi que a depuração não era o problema raiz. O problema real era que os repositórios de código nunca param. Eles evoluem, derivam e decaem mais rápido do que os humanos podem manter.

Ao longo do tempo, Kodezi evoluiu de um produto para um sistema operacional, o que agora chamamos de Kodezi OS, que aprende com cada bug, teste e commit. O termo “CTO de IA” surgiu naturalmente. CTOs não apenas escrevem código; eles mantêm a arquitetura, orientam decisões e mantêm os sistemas vivos. É isso que Kodezi faz, mas de forma contínua e autônoma.

O novo modelo da Kodezi, Chronos, é descrito como o primeiro sistema de IA construído especificamente para depuração de código – e não para geração de código. Qual é a diferença fundamental que essa distinção faz para os desenvolvedores?

Porque a depuração é a realidade, não a imaginação. A geração de código é sobre adivinhar o que pode funcionar; a depuração é sobre entender por que algo falhou.

A maioria das ferramentas de IA hoje são assistentes baseados em prompts que reagem quando solicitados. Chronos, por outro lado, é proativo. Ele lembra de bugs anteriores, entende gráficos de dependência, executa testes, valida correções e as refina até que o problema seja realmente resolvido.

Essa é a distinção que importa. Os desenvolvedores não querem um assistente que fale. Eles querem infraestrutura que atue e atue corretamente.

Os resultados que você compartilhou mostram o Chronos superando o GPT-4.1 e o Claude 4 Opus em precisão de correção de bugs. Você pode nos levar pelo conjunto de dados e pela metodologia por trás desses benchmarks?

Nossa avaliação é empírica, não promocional. O Chronos é testado em milhares de casos de depuração reais extraídos de conjuntos de dados públicos, como SWE-bench, Defects4J e BugsInPy, juntamente com dados empresariais anonimizados.

Cada benchmark é estrito: o modelo deve gerar um patch, aplicá-lo e passar em todos os testes sem regressões. Nenhum exemplo escolhido a dedo, nenhum sucesso selecionado.

O Chronos alcança 67,3 por cento de precisão de correção e 80,33 por cento de taxa de resolução no SWE-bench Lite, enquanto o GPT-4.1 e o Claude 4.5 ficam abaixo de 15 por cento. A diferença não é o tamanho; é a especialização. O Chronos é treinado na própria depuração, em 15 milhões de sessões de depuração reais, então ele não apenas faz correspondência de padrões, ele diagnostica.

Você descreveu a Kodezi como um “CTO de IA” que mantém e evolui autonomamente a base de código de uma empresa. Quão perto estamos de ter infraestrutura completamente auto-curativa em ambientes de produção?

Mais perto do que a maioria das pessoas pensa, pelo menos para sistemas determinísticos. Hoje, a Kodezi pode autonomamente corrigir muitas falhas de CI ou CD, regressões de testes e erros de tempo de execução usando dados contextuais e memória histórica.

A manutenção de produção completamente autônoma, onde a infraestrutura diagnostica, cura e reimplanta a si mesma, está surgindo. Eu vejo isso evoluindo em estágios: primeiro dentro de ambientes de CI controlados, então ambientes de staging e finalmente produção sob supervisão humana.

Nós sempre manteremos um humano no loop para decisões criativas, arquiteturais e éticas, mas a maioria do trabalho repetitivo e propenso a erros, como linting, refatoração e recuperação de testes, logo acontecerá sem intervenção.

Você falou sobre sistemas que “fazem a coisa certa silenciosamente”. O que essa filosofia significa no contexto da governança de IA e automação responsável?

Para mim, “silencioso” não significa silente. Significa confiável por padrão. Um sistema de IA bem projetado não deve precisar de entrada ou validação constante. Ele deve agir de forma previsível, transparente e segura.

A automação responsável significa que cada decisão tomada pela IA é explicável, reversível e registrada. O Chronos documenta seu raciocínio e ações: o que ele mudou, por quê e como os testes validaram a correção.

A governança é incorporada ao próprio sistema. Nenhuma modificação oculta, nenhum resultado de caixa preta. O objetivo não é para a IA ser barulhenta ou chamativa, mas para melhorar silenciosamente o mundo sob a superfície, onde mais importa.

O termo “Tecnologia Silenciosa” é atraente – sugere tecnologia poderosa, mas invisível. Como você vê esse movimento redesenhando a colaboração entre humanos e IA na engenharia?

Tecnologia Silenciosa é infraestrutura poderosa, mas invisível. A melhor tecnologia não deve interromper; deve integrar.

Na engenharia, isso significa que a ferramenta não pergunta “O que você quer que eu faça?”. Ela já sabe o que precisa de atenção. Ela vê a dependência quebrada, a corrige, atualiza a documentação e continua.

À medida que a IA se torna parte da pilha de desenvolvimento, a colaboração muda de comando para coexistência. Os humanos definem a intenção e a direção. A IA executa, mantém e otimiza silenciosamente em segundo plano. Essa é a próxima era, onde a produtividade vem não de mais interação, mas de menos fricção.

Muitos desenvolvedores se preocupam com as ferramentas de IA substituindo-os. Você argumentou que a automação deve libertar os humanos para pensar, não substituí-los. Como a Kodezi incorpora esse equilíbrio?

A IA não substituirá os desenvolvedores. Ela substituirá a rotina ao redor deles. Os engenheiros são valiosos não porque digitem rápido; são valiosos porque pensam com clareza.

A Kodezi automatiza o trabalho repetitivo que drena o foco: depuração, manutenção de testes, refatoração, documentação. A camada humana, criatividade, design de sistema e raciocínio de trade-off permanecem insubstituíveis.

No longo prazo, a IA muda a engenharia de execução para orquestração. Os desenvolvedores se tornam arquitetos de comportamento, não executores de sintaxe. A Kodezi é construída para permitir essa transição, onde as máquinas mantêm e os humanos imaginam.

Você descreveu a Kodezi como “infraestrutura viva”. Olhando para os próximos cinco anos, como pode ser o papel do desenvolvedor em um mundo onde o software se sustenta sozinho?

Em cinco anos, os desenvolvedores não passarão metade do tempo corrigindo o que construíram no trimestre passado. Seu papel mudará de manutenção reativa para governança proativa.

Imagine um mundo onde cada repositório tem memória, onde o seu sistema rastreia suas próprias decisões, cura regressões e evolui com novas dependências automaticamente. É isso que estamos construindo com a Kodezi: software que não apenas roda. Ele persevera.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Kodezi.