Ishraq Khan, CEO và Người sáng lập của Kodezi Inc – Loạt phỏng vấn

Ishraq Khan, CEO và Người sáng lập của Kodezi Inc., là một lập trình viên tự học bắt đầu lập trình từ khi mới 8 tuổi và đã ra mắt công ty khởi nghiệp đầu tiên của mình khi còn đang học trung học. Sinh ra tại Dhaka, Bangladesh và sau đó chuyển đến Hoa Kỳ, anh đã xây dựng một hồ sơ về sự khởi nghiệp sớm, đảm bảo được vốn đầu tư mạo hiểm khi còn học trung học và mở rộng một sản phẩm đến hơn 100.000 người dùng. Con đường của anh phản ánh sự tập trung vào việc học độc lập, thử nghiệm nhanh và mong muốn xây dựng các hệ thống làm cho công nghệ trở nên dễ tiếp cận và mạnh mẽ hơn cho các nhà phát triển.

Kodezi Inc. là công ty đứng sau Kodezi OS, một nền tảng tự động được thiết kế để hoạt động như một “CTO AI” cho các đội kỹ sư. Nó liên tục phát hiện và sửa lỗi, tự động ghi lại hệ thống, tạo ra các thông số kỹ thuật API, thực thi các tiêu chuẩn mã hóa và tích hợp trực tiếp vào các đường ống CI/CD. Bằng cách biến các cơ sở mã thành các hệ thống tự chữa lành, tự quản lý, Kodezi giúp các tổ chức xây dựng phần mềm đáng tin cậy, có thể mở rộng và hiệu quả hơn.

Bạn bắt đầu lập trình từ khi mới 8 tuổi và thành lập công ty khởi nghiệp đầu tiên của mình khi còn đang học trung học. Điều gì đã thu hút bạn đến việc xây dựng phần mềm từ rất sớm, và những trải nghiệm đó đã định hình tư duy khởi nghiệp của bạn như thế nào?

Điều thu hút tôi là sự kiểm soát. Tôi chuyển đến Hoa Kỳ khi còn là một đứa trẻ không nói được tiếng Anh, vì vậy ngôn ngữ đầu tiên tôi học thành thạo là mã. Đó là một không gian nơi logic có ý nghĩa, nơi tôi có thể xây dựng một thứ gì đó và thấy nó phản hồi ngay lập tức. Vòng phản hồi tức thời đó trở nên gây nghiện. Nó đã dạy tôi cách suy nghĩ, không chỉ cách lập trình.

Khi tôi xây dựng TeachMeCode khi còn học trung học, nó không phải là về việc bắt đầu một công ty. Đó là về việc làm cho việc học trở nên dễ dàng hơn cho những người như tôi. Nhưng thông qua đó, tôi đã học được cách các hệ thống hoạt động, cách người dùng phản hồi và cách tiến bộ xảy ra theo từng dòng. Điều đó đã định hình cách tôi nhìn về khởi nghiệp ngày nay: ít hơn về ý tưởng, nhiều hơn về vòng phản hồi, lặp lại và sự kiên nhẫn.

Bạn đã được chấp nhận vào 40 trường đại học, bao gồm cả các trường Ivy League, nhưng đã chọn không theo học. Điểm chuyển đổi nào đã khiến bạn quyết định rằng việc xây dựng quan trọng hơn việc chờ đợi?

Đến khi tôi tốt nghiệp trung học, tôi đã sống qua những gì mà hầu hết mọi người đi học đại học để mô phỏng. Tôi đã ra mắt sản phẩm, trình bày với các nhà đầu tư, quản lý một đội và giải quyết các vấn đề thực tế. Tôi đã có 40 thư chấp nhận trên bàn làm việc của mình, bao gồm cả các trường Ivy League, nhưng tôi cũng có điều mà hầu hết sinh viên không có: động lực.

Rủi ro lớn hơn là làm chậm lại. Trường đại học sẽ dạy tôi các khuôn khổ cho sự đổi mới, nhưng tôi đã chạy các thí nghiệm trong thế giới thực. Tôi không muốn tạm dừng một hệ thống hoạt động để học cách bắt đầu một hệ thống. Đối với tôi, lớp học trở thành sản phẩm chính. Kodezi là nền giáo dục mà tôi muốn.

Kodezi bắt đầu như một ý tưởng khi bạn còn là một thiếu niên. Công ty đã phát triển như thế nào kể từ khi thành lập vào năm 2019, và tầm nhìn của bạn về một “CTO AI” đã xuất hiện như thế nào theo thời gian?

Kodezi bắt đầu như một công cụ tự động sửa lỗi cho mã, một ý tưởng đơn giản rằng việc gỡ lỗi có thể nhanh hơn. Khi chúng tôi mở rộng, tôi nhận ra rằng gỡ lỗi không phải là vấn đề gốc. Vấn đề thực sự là các cơ sở mã không bao giờ đứng yên. Chúng tiến hóa, trôi dạt và suy giảm nhanh hơn những gì con người có thể duy trì.

Theo thời gian, Kodezi đã phát triển từ một sản phẩm thành một hệ điều hành, những gì chúng tôi gọi là Kodezi OS, học hỏi từ mọi lỗi, thử nghiệm và commit. Thuật ngữ “CTO AI” xuất hiện một cách tự nhiên. CTO không chỉ viết mã; họ duy trì kiến trúc, hướng dẫn quyết định và giữ cho các hệ thống hoạt động. Đó là những gì Kodezi làm, nhưng liên tục và tự động.

Mô hình mới nhất của Kodezi, Chronos, được mô tả là hệ thống AI đầu tiên được xây dựng đặc biệt cho việc gỡ lỗi mã – chứ không phải là tạo mã. Sự khác biệt cơ bản đó có ý nghĩa gì đối với các nhà phát triển?

Bởi vì gỡ lỗi là thực tế, không phải là tưởng tượng. Tạo mã là về việc đoán xem điều gì có thể hoạt động; gỡ lỗi là về việc hiểu tại sao một thứ gì đó đã thất bại.

Hầu hết các công cụ AI ngày nay là các trợ lý dựa trên lời nhắc, phản ứng khi được yêu cầu. Chronos, mặt khác, là chủ động. Nó nhớ lại các lỗi trước đó, hiểu các đồ thị phụ thuộc, chạy thử nghiệm, xác thực các bản sửa lỗi và tinh chỉnh chúng cho đến khi vấn đề thực sự được giải quyết.

Đó là sự khác biệt quan trọng. Các nhà phát triển không muốn một trợ lý nói. Họ muốn cơ sở hạ tầng hoạt động và hoạt động chính xác.

Kết quả bạn đã chia sẻ cho thấy Chronos vượt trội so với GPT-4.1 và Claude 4 Opus về độ chính xác của việc sửa lỗi. Bạn có thể giải thích bộ dữ liệu và phương pháp luận đằng sau cácbenchmark đó không?

Đánh giá của chúng tôi là thực nghiệm, không phải là quảng cáo. Chronos được thử nghiệm trên hàng nghìn trường hợp gỡ lỗi thực tế được rút ra từ các tập dữ liệu công khai như SWE-bench, Defects4J và BugsInPy, cùng với dữ liệu doanh nghiệp ẩn danh.

Mỗi điểm chuẩn là nghiêm ngặt: mô hình phải tạo ra một bản vá, áp dụng nó và vượt qua tất cả các trường hợp thử nghiệm mà không có hồi quy. Không có ví dụ được chọn lọc, không chọn lọc thành công.

Chronos đạt được 67,3% độ chính xác sửa lỗi và 80,33% tỷ lệ giải quyết trên SWE-bench Lite, trong khi GPT-4.1 và Claude 4.5 vẫn còn dưới 15%. Sự khác biệt không phải là kích thước; nó là chuyên môn hóa. Chronos được đào tạo về việc gỡ lỗi chính nó, trên 15 triệu phiên gỡ lỗi thực, vì vậy nó không chỉ khớp mẫu, nó chẩn đoán.

Bạn đã mô tả Kodezi như một “CTO AI” tự động duy trì và phát triển cơ sở mã của một công ty. Chúng ta đang gần với việc có cơ sở hạ tầng tự chữa lành trong môi trường sản xuất đến mức nào?

Gần hơn những gì hầu hết mọi người nghĩ, ít nhất là đối với các hệ thống quyết định. Ngày nay, Kodezi có thể tự động sửa lỗi nhiều lỗi CI hoặc CD, hồi quy thử nghiệm và lỗi thời gian chạy bằng cách sử dụng dữ liệu ngữ cảnh và bộ nhớ lịch sử.

Cơ sở hạ tầng sản xuất hoàn toàn tự động, nơi cơ sở hạ tầng chẩn đoán, tự chữa lành và tái triển khai chính nó, đang xuất hiện. Tôi nhìn thấy nó phát triển theo các giai đoạn: đầu tiên trong các môi trường CI được kiểm soát, sau đó là môi trường staging và cuối cùng là sản xuất dưới sự giám sát của con người.

Chúng tôi sẽ luôn giữ một con người trong vòng lặp cho các quyết định sáng tạo, kiến trúc và đạo đức, nhưng hầu hết công việc lặp đi lặp lại và dễ xảy ra lỗi như linting, tái cấu trúc và phục hồi thử nghiệm sẽ sớm xảy ra mà không cần can thiệp.

Bạn đã nói về các hệ thống “làm đúng việc một cách im lặng”. Triết lý đó có ý nghĩa gì trong bối cảnh quản trị AI và tự động hóa có trách nhiệm?

Đối với tôi, “im lặng” không có nghĩa là im lặng. Nó có nghĩa là đáng tin cậy theo mặc định. Một hệ thống AI được thiết kế tốt nên không cần phải hỏi liên tục đầu vào hoặc xác nhận. Nó nên hành động một cách dự đoán, minh bạch và an toàn.

Tự động hóa có trách nhiệm có nghĩa là mọi quyết định được thực hiện bởi AI đều có thể giải thích, đảo ngược và được ghi lại. Chronos ghi lại lý do và hành động của nó: những gì nó đã thay đổi, tại sao và cách thử nghiệm đã xác thực bản sửa lỗi.

Quản trị được tích hợp vào hệ thống chính nó. Không có sửa đổi ẩn, không có kết quả hộp đen. Mục tiêu không phải là AI phải lớn hoặc sặc sỡ, mà là cải thiện thế giới một cách im lặng dưới bề mặt nơi nó quan trọng nhất.

Thuật ngữ “Quiet Tech” rất hấp dẫn – nó gợi ý công nghệ mạnh mẽ nhưng vô hình. Bạn nhìn thấy phong trào này đang thay đổi cách con người và AI cộng tác trong kỹ thuật như thế nào?

Công nghệ Quiet là cơ sở hạ tầng mạnh mẽ nhưng vô hình. Công nghệ tốt nhất không nên gián đoạn; nó nên tích hợp.

Trong kỹ thuật, điều đó có nghĩa là công cụ không hỏi “Bạn muốn tôi làm gì?”. Nó đã biết những gì cần chú ý. Nó nhìn thấy sự phụ thuộc bị hỏng, vá nó, cập nhật tài liệu và di chuyển.

Khi AI trở thành một phần của ngăn xếp phát triển, sự hợp tác chuyển từ lệnh đến sự tồn tại. Con người xác định ý định và hướng. AI thực hiện, duy trì và tối ưu hóa một cách im lặng ở hậu trường. Đó là kỷ nguyên tiếp theo, nơi năng suất đến từ ít ma sát hơn.

Nhiều nhà phát triển lo lắng về việc các công cụ AI sẽ thay thế họ. Bạn đã lập luận rằng tự động hóa nên giải phóng con người để suy nghĩ, không phải thay thế họ. Kodezi thể hiện sự cân bằng đó như thế nào?

AI sẽ không thay thế các nhà phát triển. Nó sẽ thay thế sự nhàm chán xung quanh họ. Các kỹ sư không có giá trị vì họ gõ nhanh; họ có giá trị vì họ suy nghĩ rõ ràng.

Kodezi tự động hóa công việc lặp đi lặp lại mà làm cạn kiệt sự tập trung: gỡ lỗi, duy trì thử nghiệm, tái cấu trúc, ghi lại. Lớp con người, sự sáng tạo, thiết kế hệ thống và lý do thương mại vẫn không thể thay thế.

Trong dài hạn, AI chuyển đổi kỹ thuật từ thực hiện sang điều phối. Các nhà phát triển trở thành kiến trúc sư của hành vi, không phải người thực hiện cú pháp. Kodezi được xây dựng để cho phép sự chuyển đổi đó, nơi máy móc duy trì và con người tưởng tượng.

Bạn đã mô tả Kodezi như một “cơ sở hạ tầng sống”. Nhìn về tương lai 5 năm, vai trò của nhà phát triển sẽ như thế nào trong một thế giới mà phần mềm tự duy trì?

Trong 5 năm, các nhà phát triển sẽ không dành nửa thời gian của mình để sửa những gì họ đã xây dựng vào quý trước. Vai trò của họ sẽ di chuyển từ bảo trì phản ứng sang quản trị chủ động.

Hãy tưởng tượng một thế giới nơi mọi kho lưu trữ có bộ nhớ, nơi hệ thống của bạn theo dõi các quyết định của chính nó, tự chữa lành các hồi quy và phát triển với các phụ thuộc mới một cách tự động. Đó là cơ sở hạ tầng sống.

Trong thế giới đó, các nhà phát triển hành động nhiều hơn như những người quản lý. Họ xác định chính sách, xác thực hành vi và thiết kế ý định. Cơ sở mã trở thành một sinh vật sống mà thích nghi, học hỏi và tự duy trì.

Đó là những gì chúng tôi đang xây dựng với Kodezi: phần mềm không chỉ chạy. Nó tồn tại.

Cảm ơn vì cuộc phỏng vấn tuyệt vời, độc giả muốn tìm hiểu thêm có thể truy cập Kodezi.