Người phụ trách sản phẩm OpenAI Codex chia sẻ trực tiếp: Chúng tôi đã tạo ra sản phẩm như thế nào khi không có quy chuẩn và lộ trình?
Tuyển chọn TechFlowTuyển chọn TechFlow
Người phụ trách sản phẩm OpenAI Codex chia sẻ trực tiếp: Chúng tôi đã tạo ra sản phẩm như thế nào khi không có quy chuẩn và lộ trình?
“Sở thích và tính tự chủ là những phẩm chất cốt lõi và quan trọng nhất của con người trong kỷ nguyên AGI.”
Chuyên sâu báo cáo Web3Tổng hợp & Biên dịch: TechFlow
Khách mời: Alex, phụ trách sản phẩm Codex; Romain, chuyên gia trải nghiệm nhà phát triển (DevX) của Codex
Dẫn chương trình: Peter Yang
Nguồn podcast: Peter Yang
Tựa đề gốc: How OpenAI's Codex Team Builds with Codex (43 Phút) | Alex & Romain
Ngày phát hành: 5 tháng 4 năm 2026
Tóm tắt các điểm chính
Alex là người phụ trách sản phẩm Codex, còn Romain đảm nhiệm mảng trải nghiệm nhà phát triển. Họ đã giúp tôi có cái nhìn hiếm hoi và sâu sắc về cách đội ngũ Codex vận hành — từ việc họ sử dụng Codex để xây dựng sản phẩm ra sao, đến cách họ ra mắt sản phẩm mà không cần tài liệu đặc tả sản phẩm (spec) và lộ trình truyền thống. Alex cũng chia sẻ một số quan điểm độc đáo về định hướng phát triển nghề nghiệp của Quản lý Sản phẩm (PM) trong tương lai, cũng như những yếu tố thực sự quan trọng trong quy trình tuyển dụng.
Tóm tắt những quan điểm nổi bật
Xây dựng theo thời gian thực và “tốc độ tư duy” của Codex Spark
- “Khi bạn muốn xây dựng điều gì đó… bạn có thể chuyển sang chế độ nhanh hoặc thậm chí dùng Codex Spark — và ngay lập tức bạn sẽ có được ‘tốc độ tư duy’ phi thường để xây dựng bất cứ thứ gì. Bên trái là GPT-5.4, bên phải là Codex Spark — tốc độ trung bình đạt khoảng 1.200 token mỗi giây, nhanh đến mức điên rồ.” — Romain
Về tài liệu đặc tả và quy trình ra quyết định
- “Tôi nghĩ chúng tôi ở đội Codex viết rất, rất ít tài liệu đặc tả. Thực tế, phần lớn công việc của chúng tôi là để những người gần nhất với thực tế đưa ra càng nhiều quyết định càng tốt. Vì vậy, chúng tôi chỉ viết tài liệu đặc tả khi vấn đề trở nên quá phức tạp để một người có thể nắm bắt toàn bộ trong đầu.” — Alex
Biên giới nghề nghiệp mờ nhạt và sự tiến hóa của nhà thiết kế
- “Các nhà thiết kế trong đội chúng tôi hiện nay viết code nhiều hơn cả các kỹ sư sáu tháng trước. Trọng tâm của chúng tôi giờ đây không còn là ‘có thể sinh mã hay không’, mà là: Chúng ta quyết định làm điều gì, và làm thế nào để đảm bảo chất lượng sản phẩm ở mức cao nhất. Đó cũng là lý do vì sao đối với các tính năng cực kỳ phức tạp, tôi thiên về việc tìm một người chịu trách nhiệm vững vàng để quản lý, thay vì giao cho Quản lý Sản phẩm (PM) đảm nhiệm việc triển khai và duy trì hệ thống đó.” — Alex
Triết lý thiết kế sản phẩm: Làm cho mô hình ‘vô hình’
- “Chúng tôi thiết kế các tính năng cốt lõi một cách hết sức thận trọng, nhằm đảm bảo chúng không trở thành rào cản giữa người dùng và mô hình, mà ngược lại, khiến mô hình thông minh hơn và tự động hoàn thành nhiều tác vụ hơn.” — Alex
- “Sau đó, trên nền tảng này, chúng tôi suy nghĩ cách đóng gói sản phẩm dưới dạng linh hoạt nhất có thể dành cho người dùng nâng cao, để họ tự khám phá và sử dụng. Ví dụ, hiện đã có người dùng triển khai thành công các sub-agent (tác nhân con).” — Romain
Triết lý lập kế hoạch: Từ chối ‘giai đoạn trung hạn đầy khó xử’
- “Tại OpenAI, chúng tôi hoặc lên kế hoạch ngắn hạn, hoặc lên kế hoạch dài hạn — nhưng tuyệt đối không lập kế hoạch trung hạn, bởi kế hoạch trung hạn quá phức tạp. Kế hoạch ngắn hạn thường đề cập đến các mục tiêu trong vòng tối đa tám tuần kể từ hiện tại — tám tuần là khoảng thời gian dài nhất mà chúng tôi đặt ra; đồng thời, chúng tôi cũng xác định tầm nhìn dài hạn. Chẳng hạn, chúng tôi có thể hình dung về tương lai sau một năm, khi các mô hình sẽ thông minh hơn nhiều; tuy nhiên, kế hoạch trung hạn lại gây cảm giác khó xử — nó thường hiện hữu dưới dạng một lộ trình sản phẩm chi tiết, nhưng thực tế chúng tôi hầu như không có loại lộ trình nào như vậy. Thay vào đó, chúng tôi kết hợp tầm nhìn dài hạn với việc tập trung vào những nhiệm vụ cụ thể có thể thúc đẩy chúng tôi tiến gần hơn tới mục tiêu.” — Alex
Cuộc cách mạng giao diện nhờ ‘ủy quyền cho tác nhân thông minh’
- “Lập trình sẽ được thực hiện theo phương thức ‘ủy quyền cho tác nhân thông minh’ (agentic delegation). Bạn sẽ cảm thấy thật kỳ lạ khi mở hàng loạt tab trong terminal và để chúng chạy trong vài tiếng đồng hồ. Chúng ta cần một giao diện hoàn toàn mới — và đúng lúc này, cơ hội ấy vừa chín muồi.” — Romain
Sự biến mất của bậc thang nghề nghiệp và ‘sụp đổ chồng chất nhân tài’
- “Điều này gần như làm mờ đi mọi bậc thang thăng tiến nghề nghiệp truyền thống. Mỗi người trong chúng ta thực chất đều là một ‘người xây dựng’ (builder), cùng hợp tác để hoàn thành công việc. Nếu một công ty khởi nghiệp có PM trong khi số lượng kỹ sư dưới khoảng 20 người, thì đó có thể là một tín hiệu cảnh báo. Trong kỷ nguyên AGI, niềm đam mê và tinh thần chủ động là hai phẩm chất cốt lõi và quan trọng nhất của con người.” — Romain / Alex
Tiêu chuẩn tuyển dụng: Tác phẩm quan trọng hơn sơ yếu lý lịch
- “Khi ai đó gửi tin nhắn riêng bày tỏ mong muốn gia nhập đội ngũ của chúng tôi, phản ứng đầu tiên của tôi luôn là: ‘Có liên kết nào không?’ Nếu có, tôi luôn nhấn vào để xem — để kiểm tra xem họ thực sự đang xây dựng điều gì. Tôi thích xem ý tưởng và sản phẩm thực tế họ tạo ra hơn là đọc thư xin việc hay sơ yếu lý lịch. Tôi hoàn toàn không biết những người này từng học ở trường đại học nào.” — Alex
Trình diễn trực tiếp: Xây dựng một trò chơi chỉ trong vài giây bằng Codex Spark
Người dẫn chương trình Peter: Hôm nay tôi vô cùng háo hức được chào đón Alex và Romain từ đội Codex của OpenAI. Họ sẽ trình diễn cách xây dựng các tính năng mới của Codex, khả năng của Codex là gì, và đội Codex làm thế nào để liên tục ra mắt sản phẩm. Các bạn có muốn nhanh chóng minh họa một ví dụ về việc có thể xây dựng điều gì chỉ bằng một prompt duy nhất (one-shot) không?
Romain:
Chắc chắn rồi! Để tôi chia sẻ màn hình. Thực tế có rất nhiều thứ tôi có thể trình bày, nhưng có lẽ hãy xem nhanh một ví dụ — đây là ứng dụng iOS mà tôi đang xây dựng. Nếu tôi muốn thêm một tính năng mới cho ứng dụng này, tôi chỉ cần nói to: “Này, bạn có thể tạo một màn hình mới cho sứ mệnh trở lại Mặt Trăng của NASA không?” rồi gửi prompt này qua GPT-5.4 — và mô hình sẽ tự động tạo ra màn hình mới cho ứng dụng cụ thể này.
Nhưng chúng tôi cũng có mô hình Codex Spark, hỗ trợ bạn phác thảo và lặp lại ý tưởng với bất kỳ thứ gì chỉ trong vài giây. Hãy để tôi minh họa sự khác biệt về tốc độ phản hồi giữa mô hình Spark và các mô hình khác. Bên trái là GPT-5.4, bên phải là Codex Spark. Tốc độ trung bình đạt khoảng 1.200 token mỗi giây — nhanh đến mức điên rồ! Vì vậy, khi bạn muốn xây dựng điều gì đó — chẳng hạn như một trò chơi — ngay trước khi cuộc trò chuyện này bắt đầu, tôi thực tế đã truy cập ứng dụng Codex và tạo một trò chơi 2D nhỏ giống Animal Crossing chỉ bằng một prompt đơn giản.
Một tính năng khác tôi rất thích khi dùng Codex — đặc biệt khi đầu óc mình sáng suốt — là mở Codex, sau đó để cửa sổ hội thoại nổi trên đầu màn hình. Như vậy, nếu tôi đang thực sự phát triển trò chơi này, tôi có thể tiếp tục lặp lại và nảy sinh thêm nhiều ý tưởng. Peter, anh có gợi ý nào về việc muốn thay đổi điều gì trong trò chơi này không?
Peter: Có thể thêm một số đồ trang trí, nhà cửa, cây cối… để trò chơi sống động hơn chăng?
Romain:
Tôi sẽ gửi yêu cầu này ngay bây giờ — và cơ bản chỉ trong vài giây, Codex Spark sẽ thực hiện chỉnh sửa, chúng ta sẽ thấy thay đổi ngay lập tức, và xong! Cây mới đã xuất hiện.
Vì vậy, đây chính là lý do tôi vô cùng hào hứng với Codex: Bạn thực sự có thể sở hữu các mô hình tiên tiến như GPT-5.4, đủ sức đảm nhận các nhiệm vụ rất phức tạp — ví dụ như phân tích hoặc di chuyển hàng triệu dòng mã. Nhưng khi bạn bừng tỉnh cảm hứng và đầu óc minh mẫn, bạn có thể chuyển sang chế độ nhanh hoặc thậm chí dùng Codex Spark — và ngay lập tức bạn sẽ có được ‘tốc độ tư duy’ phi thường để xây dựng bất cứ điều gì.
Với tài liệu đặc tả sản phẩm, chúng tôi chỉ viết khoảng 10 gạch đầu dòng — thế thôi
Người dẫn chương trình Peter: Tôi thực sự tò mò về cách các bạn thực tế xây dựng sản phẩm bằng Codex trong đội. Alex, các bạn vẫn viết tài liệu đặc tả chứ? Hay để GPT viết giúp? Các bạn dùng mô hình nào để vận hành những thứ này?
Alex:
Tôi nghĩ đội Codex chúng tôi viết rất, rất ít tài liệu đặc tả. Thực tế, phần lớn công việc của chúng tôi là để những người gần nhất với thực tế đưa ra càng nhiều quyết định càng tốt, vì vậy chúng tôi chỉ viết tài liệu đặc tả khi vấn đề trở nên quá phức tạp để một người có thể nắm bắt toàn bộ trong đầu. Nhân tiện, hiện nay một người có thể ghi nhớ rất nhiều thứ, bởi họ có thể làm được rất nhiều việc — phần lớn công việc lập trình đã được họ ủy quyền cho các mô hình, nên một người giờ đây có thể làm được rất nhiều. Nhưng nếu vấn đề cuối cùng trở thành thứ đòi hỏi sự phối hợp giữa nhiều người, hoặc có thể là một quyết định cực kỳ nan giải mà chúng ta buộc phải đưa ra, thì lúc đó chúng tôi mới cân nhắc viết tài liệu đặc tả. Tuy nhiên, trong những tình huống như vậy, văn bản chúng tôi viết thường rất, rất ngắn — chỉ khoảng 10 gạch đầu dòng, rồi thôi.
Người dẫn chương trình Peter: Được thôi. Các bạn có thể cho tôi xem cách điều này vận hành không? Ví dụ, bạn đưa cho Codex vài gạch đầu dòng, rồi có thể nó sẽ tự viết ra các yêu cầu thực tế?
Romain:
Chắc chắn rồi! Nhưng trước tiên, tôi muốn giới thiệu một ví dụ đơn giản hơn. Giả sử chúng ta đang phát triển một ứng dụng iOS, và một số tính năng đã hoàn tất. Bây giờ bạn có một số ý tưởng mới cho dự án này, nhưng chưa xác định rõ hướng đi cụ thể. Đây chính là lúc sức mạnh của Codex thể hiện rõ nhất — nó có thể giúp chúng ta lên kế hoạch cho bước tiếp theo. Ví dụ, tôi chỉ cần nhấn tổ hợp Shift+Tab để vào “Chế độ Lập kế hoạch” (Plan Mode), rồi nhập câu “Chúng ta sẽ xây dựng điều gì?”, Codex sẽ tự động giúp tôi tạo ra một kế hoạch sơ bộ. Nó sẽ phân tích kho mã hiện có, hiểu trạng thái hiện tại của dự án và đề xuất một số ý tưởng tiềm năng. Đồng thời, tôi cũng có thể bổ sung ý tưởng của mình để hướng dẫn mô hình tạo ra một kế hoạch hoàn thiện hơn.
Trong quá trình này, bạn sẽ nhận thấy Codex đưa ra một số đề xuất dựa trên mã và tập tin hiện tại. Ví dụ, nó có thể hỏi: “Chúng ta có nên tiếp tục hoàn thiện tính năng đã đề cập trước đó không? Hay nên tối ưu bảng điều khiển độ tin cậy?” Nếu chúng ta quyết định tối ưu bảng điều khiển độ tin cậy, nó sẽ tiếp tục dẫn dắt chúng ta suy ngẫm: Đối tượng người dùng mục tiêu của việc tối ưu này là ai? Toàn bộ quá trình này giống như hợp tác với một đối tác cùng brainstorm vậy.
Tôi thường dùng cách này để khơi nguồn ý tưởng. Ví dụ, với những thay đổi đơn giản, tôi chỉ cần nhập prompt và để Codex sinh mã.
Alex:
Còn với những thay đổi có độ phức tạp trung bình, tôi có thể yêu cầu nó tạo một kế hoạch cụ thể hoặc hỗ trợ tôi suy luận cách triển khai. Khi tôi chỉ có một ý tưởng mơ hồ, tôi thường mở Codex ngay lập tức và nhờ nó giúp tôi suy nghĩ cách giải quyết vấn đề. Ngay cả khi trong đầu tôi chưa hình thành rõ ràng yêu cầu chức năng, Codex vẫn có thể giúp tôi làm rõ suy nghĩ thông qua việc đặt câu hỏi và khám phá.
Tuy nhiên, thành thật mà nói, đôi khi tôi không áp dụng trực tiếp giải pháp do Codex sinh ra — đặc biệt khi thay đổi khá phức tạp. Tôi thường dùng “Chế độ Lập kế hoạch” của Codex để khám phá, hình thành một luồng tư duy rõ ràng, rồi chia sẻ những ý tưởng này với đội kỹ sư. Cuối cùng, quá trình suy nghĩ này quan trọng hơn nhiều so với chính bản kế hoạch được sinh ra.
Nhân tiện, các nhà thiết kế trong đội chúng tôi hiện nay viết code nhiều hơn cả các kỹ sư sáu tháng trước — điều này trước đây là điều không thể tưởng tượng nổi. Điều này chủ yếu nhờ sự tiến bộ của các công cụ, giúp nhà thiết kế tham gia sâu hơn vào quá trình phát triển. Tuy nhiên, tôi cũng thường bị đồng đội trêu chọc vì năm ngoái tôi gửi PR (yêu cầu hợp nhất mã) quá ít. Dù nhiều thay đổi chỉ là những điều chỉnh nhỏ, tôi thực sự cảm thấy mình nên làm nhiều hơn.
Bây giờ, trọng tâm của chúng tôi không còn là ‘có thể sinh mã hay không’, bởi các tác nhân (Agent) đã có thể đảm nhận phần lớn công việc lập trình, mà là: Chúng ta quyết định làm điều gì, và làm thế nào để đảm bảo chất lượng sản phẩm ở mức cao nhất. Đó cũng là lý do vì sao đối với các tính năng cực kỳ phức tạp, tôi thiên về việc tìm một người chịu trách nhiệm vững vàng để quản lý, thay vì giao cho Quản lý Sản phẩm (PM) đảm nhiệm việc triển khai và duy trì hệ thống đó.
Nhà thiết kế viết code nhiều hơn kỹ sư sáu tháng trước
Người dẫn chương trình Peter: Ứng dụng Codex rất trực quan và dễ dùng. So với một số sản phẩm chuyên biệt bên ngoài, tôi cảm thấy đường cong học tập của Codex thấp hơn nhiều. Một số sản phẩm chuyên biệt dù mạnh mẽ nhưng lại đòi hỏi rất nhiều thời gian để học cách sử dụng. Thậm chí tôi còn cảm thấy, nếu không theo dõi thông tin liên quan trên Twitter, tôi có thể hoàn toàn không biết cách dùng chúng.
Nhưng một điều khiến tôi ấn tượng với Codex là nó không chỉ đơn giản dễ dùng, mà còn cung cấp nhiều tính năng nâng cao như skills (kỹ năng) và automations (tự động hóa). Đội các bạn có thường xuyên sử dụng những tính năng này trong nội bộ không?
Romain:
Vâng, chúng tôi dùng rất nhiều. Thực tế, tôi cho rằng skills là một trong những tính năng thú vị nhất của ứng dụng Codex. Ví dụ, hiện nay nếu bạn và một nhà thiết kế cùng dùng Figma, chỉ cần mở skill Figma, bạn có thể trích xuất trực tiếp tất cả các thành phần React, biến số… từ file Figma, sau đó Codex sẽ tự động sinh mã tương ứng. Hoặc nếu bạn đang phát triển một ứng dụng và muốn chia sẻ hoặc triển khai nó lên Vercel, Cloudflare hoặc Render, bạn chỉ cần đưa ra lệnh đơn giản thông qua skills, Codex sẽ tự động hoàn thành toàn bộ công việc.
Gần đây tôi trò chuyện với một người bạn, anh ấy nói có rất nhiều ý tưởng cải tiến sản phẩm, nên anh ấy bảo Codex: “Hãy ghi tất cả các nhiệm vụ này vào Linear để tôi dễ theo dõi.” Sau đó anh ấy dùng skill Linear. Tiếp theo, anh ấy lại bảo Codex: “Tôi đi ngủ đây, cậu cứ tiếp tục hoàn thành toàn bộ các nhiệm vụ chúng ta vừa bàn và đánh dấu chúng là đã xong.” Sáng hôm sau khi tỉnh dậy, anh ấy phát hiện tất cả các nhiệm vụ thực sự đã hoàn tất.
Alex:
Về tính đơn giản của ứng dụng mà bạn vừa đề cập, tôi muốn chia sẻ cách chúng tôi suy nghĩ về thiết kế của nó. Trong lĩnh vực này, các nhà phát triển thường rất đam mê tự xây dựng các công cụ tự động để đơn giản hóa công việc thường ngày. Chúng tôi cho rằng một đặc điểm then chốt của sản phẩm là khả năng cấu hình cao. Với Codex, nó giống như một bộ công cụ mã nguồn mở — người dùng có thể đi sâu vào bên trong và tùy chỉnh theo nhu cầu cá nhân.
Mỗi lần chúng tôi ra mắt tính năng mới, luôn có người dùng phàn nàn trên Twitter về tính năng đó (dù nó thậm chí chưa được phát hành chính thức) — và nguyên nhân thường là do họ tự sửa đổi mã hoặc fork nó. Nhưng đối với tôi, điều này lại chứng minh sản phẩm của chúng tôi thành công, bởi những người dùng tiên phong này đang cùng chúng tôi khám phá tương lai và thúc đẩy sản phẩm tiến bộ.
Tuy nhiên, chúng tôi cũng nhận ra rằng, chỉ xây dựng sản phẩm cho những người dùng nâng cao là chưa đủ, nếu không sản phẩm sẽ trở nên phức tạp và khó hiểu. Chúng tôi phải tìm được điểm cân bằng — vừa đáp ứng nhu cầu người dùng nâng cao, vừa đảm bảo sản phẩm đơn giản, trực quan với người dùng phổ thông. Do đó, chúng tôi thiết kế các tính năng cốt lõi một cách hết sức thận trọng, nhằm đảm bảo chúng không trở thành rào cản giữa người dùng và mô hình, mà ngược lại, khiến mô hình thông minh hơn và tự động hoàn thành nhiều tác vụ hơn.
Romain:
Sau đó, trên nền tảng này, chúng tôi suy nghĩ cách đóng gói sản phẩm dưới dạng linh hoạt nhất có thể dành cho người dùng nâng cao, để họ tự khám phá và sử dụng. Ví dụ, hiện đã có người dùng triển khai thành công các sub-agent (tác nhân con). Những tính năng này không phải do chúng tôi chủ động thiết kế, mà là do người dùng tự phát hiện và thử nghiệm. Qua việc quan sát cách người dùng sử dụng những tính năng này, chúng tôi học được rất nhiều điều.
Sau đó chúng tôi lại suy ngẫm: Làm thế nào để những tính năng này trở nên siêu đơn giản với những người dùng khác? Ứng dụng Codex là một ví dụ điển hình. Khoảng thời điểm GPT-5.2 Codex được phát hành vào tháng 12 năm ngoái, khả năng của mô hình bắt đầu ổn định dần, nhưng cũng vượt qua một ngưỡng then chốt. Người dùng có thể bắt đầu giao những nhiệm vụ dài hơn, phức tạp hơn cho mô hình — và mô hình có thể hoàn thành toàn bộ nhiệm vụ đó trong một lần.
Chúng tôi bắt đầu nhận thấy một số người dùng đã sử dụng tmuxing (chạy nhiều tác vụ song song trong terminal) — một cách chia cửa sổ terminal để chạy đồng thời nhiều tác vụ. Chúng tôi thấy một số ví dụ rất thú vị trên mạng xã hội, ví dụ như bức ảnh Peter Steinberger với màn hình hiển thị 18 cửa sổ terminal trải rộng trên ba màn hình, trông giống như một “cái vuốt sáng tạo mở rộng”. Chúng tôi rất phấn khích khi thấy người dùng sử dụng Codex theo cách rất nâng cao như vậy.
Đồng thời, chúng tôi tiếp tục tối ưu hóa tính năng ủy quyền tác vụ trong sản phẩm cơ bản (như CLI), đảm bảo chúng vận hành tốt. Nhưng chúng tôi cũng nhận ra rằng có thể chỉ khoảng 1% kỹ sư hàng đầu mới làm việc theo cách này. Vì vậy, chúng tôi suy ngẫm: Làm thế nào để những tính năng này trông trực quan hơn? Đó chính là lý do chúng tôi phát triển ứng dụng Codex.
Khi bạn lần đầu mở ứng dụng Codex, nó trông giống một cửa sổ chat đơn giản. Bạn có thể bắt đầu sử dụng ngay lập tức và nó hoạt động bình thường. Nhưng theo thời gian, bạn dần khám phá ra nhiều tính năng hơn — ví dụ như thanh bên, khả năng chạy nhiều tác vụ cùng lúc và dễ dàng chuyển đổi giữa các tác vụ. Bạn sẽ cảm thấy mình trở nên siêu hiệu quả. Sau đó bạn có thể để ý đến thẻ “skills”, nhấn vào để khám phá thêm các tính năng. Chúng tôi mong muốn người dùng khi dùng ứng dụng Codex có cảm giác gần như đang chơi một trò chơi — liên tục khám phá những khả năng mới.
Romain:
Hoàn toàn đồng ý. Và đây cũng chính là tầm nhìn mà chúng tôi đã có ngay từ đầu: Lập trình sẽ được thực hiện theo phương thức ‘ủy quyền cho tác nhân thông minh’ (agentic delegation). Ngay từ khoảng một năm trước, khi chúng tôi bắt đầu phát triển Codex, chúng tôi đã luôn suy ngẫm về tương lai này. Chúng tôi tin rằng các kỹ sư sẽ có thể xử lý đồng thời nhiều tác vụ, trong khi mô hình đảm nhận phần công việc chi tiết và phức tạp.
Tuy nhiên, thành thật mà nói, lúc đó khả năng của mô hình chưa đạt đến mức độ này. Chúng tôi phải đợi đến khi GPT-5.2 Codex ra mắt, rồi vượt qua ngưỡng then chốt đó — khi thấy mô hình có thể làm việc một cách triệt để và đáng tin cậy trong vài giờ, thậm chí vài ngày. Đến lúc đó, chúng tôi chợt nhận ra rằng giao diện terminal truyền thống đã không còn phù hợp với cách làm việc này. Bạn sẽ cảm thấy thật kỳ lạ khi mở hàng loạt tab trong terminal và để chúng chạy trong vài tiếng đồng hồ. Vì vậy, chúng ta cần một giao diện hoàn toàn mới — và đúng lúc này, cơ hội ấy vừa chín muồi.
Alex:
Nhìn lại hành trình phát triển Codex, chúng tôi đã trải qua hai “vibe shift” (sự chuyển dịch xu hướng) quan trọng. Đầu tiên là vào tháng 8 năm ngoái, khi chúng tôi ra mắt sản phẩm Codex Cloud. Đó là một ý tưởng tuyệt vời, người dùng lúc đó rất hào hứng — dù có thể hơi sớm một chút. Vì vậy, vào tháng 8, chúng tôi ra mắt GPT-5 — một mô hình lập trình tương tác xuất sắc — và quyết định tập trung giải quyết những vấn đề mà mô hình hiện tại có thể xử lý. Từ đó, chúng tôi ra mắt Codex CLI và plugin IDE, và lượng người dùng tăng vọt 20–30 lần chỉ trong vài tháng — thật tuyệt vời!
Sự chuyển dịch thứ hai diễn ra từ tháng 12 năm ngoái đến tháng 1 năm nay. Lúc này, chúng tôi cuối cùng cũng hiện thực hóa tầm nhìn ban đầu — ủy quyền tác vụ cho mô hình. Khả năng của mô hình đạt đến một độ cao mới, có thể độc lập hoàn thành các tác vụ phức tạp hơn, đánh dấu một giai đoạn hoàn toàn mới.
Chúng tôi chỉ lập kế hoạch ngắn hạn và dài hạn — tuyệt đối không lập kế hoạch trung hạn
Người dẫn chương trình Peter: Tôi rất tò mò về cách ứng dụng Codex được phát triển. Một năm trước, các bạn có lập một lộ trình hàng năm nào đó kiểu như “Chúng tôi sẽ ra mắt ứng dụng Codex vào thời điểm này” không? Hay các bạn chủ yếu quan sát nhu cầu thị trường và nhanh chóng tạo mẫu một số ý tưởng?
Alex:
Thực tế thì không phải cả hai. Tôi từng nghe một lời khuyên tuyệt vời từ nhà nghiên cứu Andre của chúng tôi: Tại OpenAI, chúng tôi hoặc lập kế hoạch ngắn hạn, hoặc lập kế hoạch dài hạn — nhưng tuyệt đối không lập kế hoạch trung hạn, bởi kế hoạch trung hạn quá phức tạp.
Kế hoạch ngắn hạn thường đề cập đến các mục tiêu trong vòng tối đa tám tuần kể từ hiện tại, và tám tuần là khoảng thời gian dài nhất mà chúng tôi đặt ra. Trong khung thời gian này, chúng tôi xác định một mục tiêu cụ thể và tập hợp toàn đội để dồn lực hoàn thành nó. Đây là một điểm mạnh của OpenAI — chúng tôi rất giỏi trong việc tổ chức đội ngũ xung quanh một mục tiêu rõ ràng.
Mặt khác, chúng tôi cũng xác định tầm nhìn dài hạn. Ví dụ, chúng tôi có thể hình dung về tương lai sau một năm, khi các mô hình sẽ thông minh hơn nhiều. Chẳng hạn, chúng tôi có thể tưởng tượng các mô hình trong tương lai có thể làm việc độc lập, không cần mượn tài nguyên máy tính của chúng tôi, và cũng không bị giới hạn ở việc chỉ làm một việc tại một thời điểm. Chúng tôi mong muốn có vô số mô hình, chúng có thể độc lập hoàn thành tác vụ, tự kiểm chứng mã, thậm chí tự triển khai và giám sát — mà chúng tôi hoàn toàn không cần phải nhắc nhở thủ công.
Tuy nhiên, kế hoạch trung hạn lại gây cảm giác khó xử. Nó thường hiện hữu dưới dạng một lộ trình sản phẩm chi tiết, nhưng thực tế chúng tôi hầu như không có loại lộ trình nào như vậy. Chúng tôi chủ yếu kết hợp tầm nhìn dài hạn với việc tập trung vào những nhiệm vụ cụ thể có thể thúc đẩy chúng tôi tiến gần hơn tới mục tiêu.
Lấy ví dụ ứng dụng Codex: Khi đó, một trong những mục tiêu chiến lược của chúng tôi là giải phóng người dùng khỏi các không gian làm việc (workspace) cụ thể. Các công cụ phát triển truyền thống (như VS Code) thường gắn chặt với một không gian làm việc cụ thể — ví dụ như một điểm kiểm tra (checkout) nhất định trong kho mã hoặc một thư mục. Ngay cả khi dùng git worktree, bạn cũng chỉ có thể mở một thư mục làm việc tại một thời điểm, và CLI cũng có giới hạn tương tự.
Nhưng tầm nhìn của chúng tôi là: Người dùng có thể cộng tác với các tác nhân thông minh (agent) trên đám mây — và những agent này có thể làm việc độc lập. Chúng tôi mong muốn người dùng có thể tương tác đồng thời với nhiều agent, thậm chí để một agent phối hợp công việc của nhiều agent khác cho người dùng — và trải nghiệm này phải tự nhiên và trực quan.
Đồng thời, chúng tôi cũng nhận ra rằng nếu ngay từ đầu hoàn toàn phụ thuộc vào đám mây, các nhà phát triển có thể cảm thấy không thuận tiện — bởi họ cần cấu hình môi trường, và khi mô hình thực hiện tác vụ, nếu cần can thiệp thủ công hoặc điều chỉnh, sẽ trở nên phiền phức. Vì vậy, chúng tôi quyết định phát triển một trải nghiệm cục bộ (local), vừa có thể cộng tác liền mạch với thư mục cục bộ, vừa duy trì kết nối với các tác nhân thông minh trên đám mây.
Khi bắt đầu phát triển ứng dụng này, chúng tôi có một loạt những “suy ngẫm tầm nhìn” như vậy — những ý tưởng khá trừu tượng. Đồng thời, các kỹ sư của chúng tôi cũng đang tiến hành nhiều thử nghiệm prototype. Họ nói: “Chúng tôi muốn có một ứng dụng.” Và thế là bắt đầu thử nghiệm phát triển nhiều phiên bản khác nhau. Thực tế, chúng tôi còn tổ chức một sự kiện “Tuần lễ Hackathon”, khi nhiều kỹ sư độc lập phát triển các phiên bản ứng dụng khác nhau. Anh có thể cũng đã tham gia, nhưng tôi không nhớ rõ lắm.
Khi dự án này thực sự khởi động, điều duy nhất chúng tôi cần viết rõ ràng là: Tại sao chúng tôi cho rằng việc phát triển một ứng dụng là một ý tưởng hay. Chúng tôi không viết tài liệu đặc tả sản phẩm cụ thể cho ứng dụng này — mà là thông qua công việc phát triển thực tế để dần làm rõ định hướng sản phẩm.
Tuy nhiên, lúc đó dự án này vẫn còn gây tranh cãi — liệu chúng ta thực sự cần phát triển một ứng dụng không? Plugin IDE của chúng ta đã rất phổ biến rồi, chúng ta có nên tập trung nâng cao chất lượng plugin không? CLI cũng tiềm năng rất lớn. Vậy nếu phát triển một ứng dụng, ý nghĩa của nó là gì? Chúng ta nên hướng đi nào? Đó là một số câu hỏi mà chúng tôi đối mặt khi dự án bắt đầu.
Romain:
Vâng, may mắn thay, lúc đó chúng tôi đã có một giải pháp plugin IDE rất trưởng thành và đã tối ưu sâu sắc. Người dùng có thể dùng các plugin này trên VS Code, Cursor, Windsurf và nhiều IDE khác. Chúng tôi tích lũy được rất nhiều kinh nghiệm từ kho mã plugin IDE, tạo nên một điểm khởi đầu vững chắc cho việc phát triển ứng dụng Codex.
Alex:
Đúng vậy. Thực tế, ứng dụng Codex và plugin IDE chia sẻ rất nhiều mã nền tảng. Cả hai đều kết nối tới cùng một bộ khung lõi Codex (Codex harness) — một framework mã nguồn mở được viết bằng Rust, và CLI cũng sử dụng nó. Chúng tôi cố ý áp dụng thiết kế phân tầng để chia sẻ mã và mở rộng chức năng giữa các công cụ khác nhau.
Người dẫn chương trình Peter: Về quá trình ra quyết định phát triển ứng dụng Codex… Nhìn lại, điều này dường như là một quyết định hiển nhiên, bởi dùng ứng dụng Codex trực quan hơn nhiều so với việc mở hàng loạt cửa sổ terminal. Nhưng lý do chính khiến chúng ta ra quyết định đó lúc đó là: Ứng dụng Codex thân thiện hơn với người mới bắt đầu, đồng thời cũng là giao diện tối ưu nhất để quản lý sự cộng tác giữa nhiều tác nhân thông minh.
Alex:
Tôi nghĩ cách suy nghĩ của đội chúng tôi chịu ảnh hưởng sâu sắc bởi tầm nhìn AGI (trí tuệ nhân tạo tổng quát). Chúng tôi luôn tự hỏi: Tương lai của cách làm việc sẽ như thế nào?
Thực tế, tôi muốn nói theo một góc nhìn khác: Chúng tôi rất rõ ràng rằng mình cần một giao diện, để người dùng có thể tự nhiên ủy quyền tác vụ cho nhiều tác nhân thông minh. Chúng tôi biết các mô hình trong tương lai sẽ có khả năng này — thực tế, chúng tôi đã thấy người dùng đang thử nghiệm ủy quyền tác vụ giữa các tác nhân. Chúng tôi cần một giao diện khiến cách cộng tác này trở nên hợp lý và có thể mở rộng liền mạch lên đám mây.
Chúng tôi mong muốn giao diện này được thiết kế theo nguyên tắc công thái học, để người dùng cảm thấy việc cộng tác với nhiều tác nhân thông minh là một trải nghiệm trực quan và tự nhiên — chứ không phải thứ cần thao tác phức tạp hay kỹ thuật cao mới thực hiện được.
Romain:
Vâng, và đối tượng người dùng của ứng dụng này không chỉ là người mới bắt đầu — thực tế, ngay cả những kỹ sư giàu kinh nghiệm và hàng đầu, bao gồm cả các kỹ sư hàng đầu trong nội bộ OpenAI như Peter, OpenClaw và Greg Brockman, hiện nay đều bắt đầu dùng ứng dụng Codex như công cụ phát triển chính. Điều này cho thấy tầm nhìn về ‘ủy quyền cho tác nhân thông minh’ (agentic delegation) của chúng tôi đang dần trở thành hiện thực.
Alex:
Vâng. Chúng tôi nhắc đến Peter vì anh ấy vừa gia nhập OpenAI — điều khiến chúng tôi vô cùng hào hứng. Tháng 10 năm ngoái, tôi đi dạo cùng anh ấy tại Fort Mason ở San Francisco và đề cập đến ý tưởng phát triển một giao diện mới. Tôi nói chúng tôi muốn có một giao diện mới để việc ủy quyền (delegation) trở nên tự nhiên hơn, và lúc đó anh ấy bảo: “Tôi sẽ không bao giờ dùng thứ như vậy đâu.”
Nhưng cuối tuần trước, anh ấy đăng một tweet: “Thật ra ứng dụng này khá ổn, giờ tôi đã thích nó rồi.”
Công việc hàng ngày của Alex với vai trò Quản lý Sản phẩm (PM) Codex là gì?
Người dẫn chương trình Peter: Alex, trước đây anh từng là Quản lý Sản phẩm (PM) duy nhất trong đội Codex, đúng không? Hiện nay đội Codex có bao nhiêu người? Khoảng từ 50 đến 100 người chăng?
Alex:
Gần đúng, nằm trong khoảng đó. Vào tháng Năm, đội chúng tôi chỉ có khoảng 8 người — tôi không nhớ chính xác con số nữa. Nhưng kể từ đó, đội phát triển rất nhanh, hiện nay nằm trong khoảng từ 50 đến 100 người.
Người dẫn chương trình Peter: Vậy bình thường anh phân bổ thời gian thế nào? Công việc hàng ngày của anh là gì? Hay nói cách khác, anh có một ngày làm việc “điển hình” nào không?
Alex:
Gần đây tôi cũng đang suy ngẫm về vấn đề này, bởi tôi nhận ra mình khó trả lời. Tôi nhận ra cách làm việc của tôi thực chất được chia theo giai đoạn, đây chỉ là cách riêng của tôi và không nhất thiết phù hợp với tất cả mọi người.
Ví dụ, khi chúng tôi ra mắt ứng dụng Codex, tôi hoàn toàn ở trong chế độ thực thi. Lúc đó, toàn bộ tâm trí tôi tập trung vào chất lượng sản phẩm — đảm bảo không bỏ sót chi tiết nào, thực hiện từng việc nhỏ một cách kỹ lưỡng. Trong chế độ này, tôi dành rất nhiều thời gian sử dụng các công cụ Codex.
Chúng tôi dùng Codex để thu thập phản hồi — ví dụ như theo dõi nội dung thảo luận trên Slack và phản hồi từ người dùng. Tôi nhờ Codex tổng hợp những thông tin này, rồi ghi lại trên Linear. Ngoài ra, tôi còn dùng Codex để phân tích chất lượng mã và trực tiếp chỉnh sửa mã nhỏ. Bởi đôi khi, dùng Codex xử lý một số vấn đề nhỏ nhanh hơn nhiều so với việc tìm người khác phối hợp và yêu cầu họ ưu tiên xử lý — đặc biệt khi mục tiêu của chúng tôi là ra mắt ứng dụng trong vòng hai tuần.
Trong quá trình này, dĩ nhiên còn rất nhiều công việc mang tính con người — ví dụ như khích lệ, truyền cảm hứng cho đội, đồng thời giữ thái độ phê bình đối với sản phẩm đang phát triển. Thực tế, tôi nhận ra mình có đang ở chế độ thực thi hay không thông qua việc mình có dùng Twitter thường xuyên không. Tôi cũng không rõ vì sao, nhưng khi cần giao tiếp với người khác, tôi thường dùng Twitter nhiều hơn.
Sau đó còn một chế độ khác, ví dụ như hiện tại, trong đầu tôi rất rõ ràng: Chúng ta đã đạt đến một giai đoạn mới. Hiện nay chúng ta có những mô hình rất mạnh — ví dụ như GPT-5.4 hoạt động xuất sắc. Trải nghiệm ứng dụng cũng vượt kỳ vọng, đã phủ khắp mọi nền tảng, bao gồm cả Windows. Vì vậy, tôi cảm thấy đã đến lúc thực sự quay lại đám mây và đầu tư nhiều hơn vào đó.
Khi bước vào giai đoạn này, tôi dành nhiều thời gian hơn để suy ngẫm về việc tiếp theo nên làm gì và hiểu rõ trạng thái hiện tại — đây là một chế độ phối hợp. Trong chế độ này, tôi dành ít thời gian hơn cho Codex để viết mã, mà dùng Codex nhiều hơn cho việc giao tiếp. Vì vậy, tôi ít nhất có hai chế độ làm việc như vậy — và có thể còn nhiều hơn nữa.
Người dẫn chương trình Peter: Các anh cần bao nhiêu công việc đồng bộ liên chức năng?
Alex:
Chúng tôi gần như không cần nhiều công việc đồng bộ liên chức năng trong nội bộ đội, bởi chúng tôi cố ý coi mình như một đội “tàu cướp biển”. Ngay cả trong nội bộ đội Codex hiện nay, cũng chỉ có tôi và hai Quản lý Sản phẩm mới gia nhập gần đây. Chúng tôi có một số người phụ trách, và mặc dù gần đây hầu hết mọi người đều báo cáo trực tiếp cho tôi, nhưng chúng tôi chủ yếu đẩy tiến độ dự án theo cách khá mờ nhạt — nên công việc đồng bộ nội bộ đội không nhiều.
Tuy nhiên, giờ đây ngày càng rõ ràng rằng một phần quan trọng trong việc xây dựng Codex là phát triển tác nhân lập trình (coding agent). Và mọi người cũng ngày càng hiểu rõ rằng coding agent không chỉ dùng để viết mã, mà còn rất hữu ích cho các tác vụ khác.
Ví dụ, chúng tôi phát hiện người dùng dùng ứng dụng Codex không chỉ để viết mã. Họ dùng nó để hoàn thành nhiều tác vụ trong toàn bộ vòng đời phát triển phần mềm, và hiện nay phần lớn nhân viên OpenAI đều đang dùng ứng dụng Codex — ngay cả những người không phải kỹ sư, tôi cũng thường thấy họ đang dùng ứng dụng này.
Vì vậy, nhận thức này khiến chúng tôi nhận ra rằng mình cần suy ngẫm cách làm cho Codex hữu ích không chỉ với các nhà phát triển. Điều này đòi hỏi nhiều công việc đồng bộ liên chức năng hơn, bởi với tư cách là OpenAI, chúng tôi còn có ChatGPT — rất nhiều người dùng đang dùng nó — nên chúng tôi cần rất thận trọng khi cân nhắc cách kết hợp các sản phẩm này tốt hơn.
Romain:
Theo góc nhìn của tôi, đội trải nghiệm nhà phát triển (DevX) hiện nay giống như một phần mở rộng của đội Codex. Phần lớn năng lượng của chúng tôi dành cho Codex, vì một số lý do.
Thứ nhất, đây là một sản phẩm rất thú vị, các nhà phát triển rất thích dùng Codex, và chúng tôi muốn làm cho nó trở nên tuyệt vời hơn nữa. Như Alex đã nói, cách làm việc của chúng tôi cũng được chia theo các giai đoạn — chúng tôi cùng đội Codex tập trung vào công tác chuẩn bị ra mắt sản phẩm, ví dụ như chuẩn bị tài liệu cần thiết cho việc ra mắt và hướng dẫn các nhà phát triển cách tận dụng tối đa Codex. Sau khi ra mắt, chúng tôi còn hướng dẫn các nhà phát triển khám phá cách dùng Codex trong các tình huống khác nhau.
Một điều khác khiến chúng tôi cảm thấy rất thú vị là, nếu bạn nhìn toàn bộ nền tảng OpenAI, hiện nay đã có hàng triệu nhà phát triển đang dùng API của chúng tôi để xây dựng các ứng dụng đa dạng từ hình ảnh đến giọng nói.
Bây giờ cách phát triển tốt nhất đã trở thành việc lấy Codex làm điểm vào. Nếu bạn quay lại một năm trước, hoặc thậm chí mùa hè năm ngoái khi chúng tôi vừa ra mắt GPT-5, chúng tôi vẫn cần viết rất nhiều hướng dẫn để dạy mọi người cách viết prompt cho GPT-5. GPT-5 là một mô hình suy luận mạnh mẽ, rất khác biệt so với GPT-4. Còn hiện nay, chúng tôi cố gắng giúp các nhà phát triển ngay cả trong các trường hợp sử dụng này cũng có thể hoàn thành tác vụ thông qua Codex và các skills.
Ví dụ, nếu bạn cần cập nhật một hệ thống tích hợp, chúng tôi sẽ đề nghị bạn dùng Codex và tính năng skills của nó. Kết quả là Codex gần như có thể hoàn thành toàn bộ công việc giúp bạn. Vì vậy, đội chúng tôi cũng rất chú trọng vào hợp tác liên chức năng và coi Codex là nền tảng then chốt cho toàn bộ hệ sinh thái nhà phát triển OpenAI.
Alex:
Tôi nghĩ cách làm việc của đội Codex có một đặc điểm rất thú vị — đối với tôi, phần tuyệt vời nhất là sự tương tác với cộng đồng. Dù là trực tuyến hay tại các sự kiện thực tế, chúng tôi đều rất chú trọng kết nối với cộng đồng.
Khi ra mắt sản phẩm, công việc của chúng tôi rất hướng đến việc ra mắt — xác định rõ thời điểm và nội dung ra mắt; đồng thời, chúng tôi cũng rất hướng đến phản hồi — mỗi khi cộng đồng đưa ra phản hồi, chúng tôi nhanh chóng hành động, khắc phục vấn đề và giao tiếp với họ. Vì vậy, đội chúng tôi luôn duy trì trạng thái trực tuyến cao độ — và tôi cho rằng điều này rất quan trọng.
Ví dụ, khi ra mắt ứng dụng Codex, chúng tôi hợp tác rất chặt chẽ với Dom và đội của anh ấy. Họ giúp chúng tôi tổ chức một đợt kiểm thử alpha quy mô lớn, mời rất nhiều người dùng tham gia cùng phát triển sản phẩm. Thông qua phản hồi của họ, chúng tôi không chỉ cải tiến ứng dụng mà còn hoàn thiện cả các skills và tài liệu liên quan.
Tôi nghĩ đây chính là lợi thế đặc biệt của đội Codex: Vì chúng tôi là mã nguồn mở, chúng tôi duy trì sự minh bạch cao độ với mọi việc mình làm — và cộng đồng cũng ủng hộ mạnh mẽ và phản hồi tích cực với cách làm này.
Người dẫn chương trình Peter: Hãy nói về Peter (người sáng lập OpenClaw) — tôi là người dùng đầu tiên của OpenClaw. Các anh đã tích hợp Peter vào đội như thế nào? Tầm nhìn về tác nhân cá nhân (personal agent) có liên quan đến công việc hiện tại của anh ấy không? Các anh lên kế hoạch thế nào?
Alex:
Có hai khía cạnh để nói. Thứ nhất, Peter là một người dùng Codex rất nặng. Thực tế, OpenClaw phần lớn được xây dựng bằng Codex. Anh ấy cung cấp rất nhiều phản hồi quý báu cho đội thông qua trải nghiệm sử dụng cá nhân — những phản hồi này giúp chúng tôi cải tiến Codex rất nhiều. Dù đây chỉ là công việc “kiêm nhiệm” của anh ấy, nhưng anh ấy thực sự rất đầu tư — điều khiến chúng tôi đặc biệt hào hứng.
Thứ hai, hiện tôi chưa thể tiết lộ nhiều chi tiết, nhưng có thể nói rằng anh ấy đang giúp chúng tôi xây dựng thế hệ tác nhân cá nhân (personal agent) tiếp theo và tích hợp trực tiếp vào ChatGPT.
Romain:
Tôi cho rằng điều khiến tôi ấn tượng nhất trong công việc của Peter là khi mọi người dùng OpenClaw, họ có thể đã thoáng thấy khả năng trong tương lai — nhưng điều khiến tôi kinh ngạc là Peter đã nhìn thấy tầm nhìn này từ rất sớm.
Nếu bạn nhìn lại toàn bộ năm 2025, anh ấy đã phát triển hơn 40 dự án mã nguồn mở trong năm ngoái, và tất cả đều xoay quanh một tầm nhìn cốt lõi: Truy cập các công cụ cá nhân như lịch, tweet và Gmail thông qua giao diện dòng lệnh (CLI). Thông qua những dự án này, anh ấy thực tế đã biến tầm nhìn về skills và công cụ dòng lệnh thành hiện thực. Và tác nhân lập trình (coding agent) mà chúng tôi đang dùng ngày nay chính là được xây dựng dựa trên tầm nhìn này.
Trong tương lai, tác nhân này sẽ không chỉ là một công cụ lập trình, mà sẽ trở thành bất kỳ loại tác nhân cá nhân (personal agent) nào. Vì vậy, Peter đã cung cấp cho chúng tôi những phản hồi vô cùng quý báu trong quá trình này, bởi anh ấy đã phát triển rất nhiều công cụ hiện nay trở thành phần cốt lõi của hệ sinh thái mã nguồn mở.
Người dẫn chương trình Peter:
Tôi thực sự khâm phục những người như Peter, có thể xây dựng một cộng đồng mã nguồn mở xuất sắc như vậy. Các công cụ của anh ấy rất dễ dùng, đến mức tôi không muốn mở bất kỳ ứng dụng nào khác nữa — tôi chỉ muốn trò chuyện với “robot nhỏ” của mình.
Alex:
Anh đã kết nối nó với hệ thống nào? Là kết nối với tất cả mọi thứ sao?
Người dẫn chương trình Peter:
Đúng vậy, tôi đã kết nối nó với rất nhiều dịch vụ. Ví dụ như nó có thể truy cập thông tin ngân hàng, tài khoản YouTube, trợ lý giọng nói, lịch và các dịch vụ Google của tôi. Khi tôi nằm trên giường, vợ tôi hỏi: “Anh đang nói chuyện với ai thế?” Tôi trả lời: “Tôi đang trò chuyện với robot OpenClaw của mình.”
Tuy nhiên, hiện nay có rất nhiều “kẻ投 cơ” thu phí lên tới 5.000 đô la Mỹ để giúp người khác thiết lập OpenClaw. Vì vậy, nếu các anh có thể làm cho nó trở nên đại chúng hơn, dễ tiếp cận hơn, đó sẽ là một bước đột phá lớn — và các anh thực sự đang đi đúng hướng.
Bậc thang thăng tiến nghề nghiệp truyền thống đã không còn phù hợp
Người dẫn chương trình Peter: Tôi nhớ các anh từng nói điều gì đó kiểu như “Hiện nay phần lớn các đội đã không còn cần quá nhiều PM nữa”?
Romain:
Tôi nghĩ điều khiến tôi kinh ngạc nhất về những công cụ này không chỉ là vấn đề về PM hay có cần PM hay không. Điều này gần như làm mờ đi mọi bậc thang thăng tiến nghề nghiệp truyền thống. Trước đây chúng ta có phân công rõ ràng: Nhà thiết kế phụ trách thiết kế, kỹ sư phụ trách phát triển, PM phụ trách quản lý — và có thể còn một tỷ lệ nhất định nào đó, như một “tỷ lệ vàng”.
Nhưng hiện nay, nếu bạn là một kỹ sư, năng suất của bạn tăng đáng kể. Nếu bạn là một nhà thiết kế, bạn có thể đạt được “siêu năng lực” thông qua những công cụ này và trở nên kỹ thuật hơn. Nếu bạn là một PM, trước đây chỉ có thể viết tài liệu chiến lược, còn giờ đây bạn có thể trực tiếp tạo prototype. Điều này không có nghĩa là bạn phải chịu trách nhiệm về một tính năng nào đó cho hàng tỷ người dùng, nhưng bạn thực sự có thể dùng những công cụ này để xây dựng một số thứ nhất định và trình bày tầm nhìn của mình với đội.
Vì vậy, điều khiến tôi thấy hấp dẫn nhất là biên giới giữa tất cả các bậc thang nghề nghiệp giờ đây đều đang mờ nhạt. Mỗi người trong chúng ta thực chất đều là một ‘người xây dựng’ (builder), cùng hợp tác để hoàn thành công việc.
Alex:
Tôi nhớ mình từng nói ở đâu đó trên mạng rằng nếu một công ty khởi nghiệp có PM trong khi số lượng kỹ sư dưới khoảng 20 người, thì đó có thể là một tín hiệu cảnh báo — có lẽ tôi thực sự đã nói điều gì đó tương tự.
Tôi nghĩ như bạn nói, giờ đây tất cả các vai trò này đang dần hòa nhập. Nhà thiết kế có thể làm thêm nhiều công việc kỹ thuật, kỹ sư có thể tham gia vào thiết kế, và PM cũng có thể tham gia vào việc xây dựng. Nhưng kỹ sư thường cần tập trung vào việc viết mã, nên trước đây họ không xử lý việc phân loại tác vụ hay các phần quản lý dự án khác của PM.
Tuy nhiên, hiện nay những việc này trở nên rất dễ dàng. Bạn có thể trực tiếp nhờ một tác nhân — ví dụ như Codex — phân tích phản hồi và xác định mức độ ưu tiên, để kỹ sư có thể dành nhiều thời gian hơn cho công việc chuyên môn của mình. Tôi nghĩ hiện nay mỗi người đều có thể làm công việc của người khác.
Scott Belsky từng đề xuất một ý tưởng gọi là “sụp đổ chồng chất nhân tài” (collapse the talent stack). Tôi rất thích quan điểm này và cảm thấy điều này thực sự đang xảy ra. Càng ít người trong phòng, công việc càng tiến triển thuận lợi hơn, và mỗi quyết định cũng trở nên rõ ràng hơn.
Vì vậy, câu hỏi đặt ra là: PM còn có thể làm gì? Tôi nghĩ có rất nhiều PM thực tế nên cân nhắc chuyển đổi vai trò. Ví dụ, nếu bạn là một PM, luôn muốn trở thành kỹ sư nhưng lại giỏi hơn trong việc quản lý con người và kỹ năng kỹ thuật không mạnh, thì giờ đây bạn có thể trở thành một quản lý kỹ sư (engineering manager). Với sự hỗ trợ của các tác nhân thông minh, đây có thể là một vai trò rõ ràng hơn đối với bạn. Tương tự, một số PM có thể thiên về việc trở thành nhà thiết kế, gần hơn với công việc xây dựng thực tế.
Tôi nghĩ cuối cùng vẫn phụ thuộc vào sở thích cá nhân. Đối với tôi, niềm đam mê và tinh thần chủ động là hai phẩm chất cốt lõi và quan trọng nhất của con người trong kỷ nguyên AGI. Vì vậy, nếu bạn thực sự hứng thú với việc viết mã, và trước đây chỉ đảm nhận vai trò PM vì cần có người làm công việc đó, thì giờ đây bạn hoàn toàn có thể chuyển đổi thành kỹ sư và tiếp tục hoàn thành cùng công việc đó từ góc độ kỹ thuật. Lĩnh vực thiết kế cũng tương tự.
Nhưng nếu bạn thực sự hứng thú với việc tương tác với người dùng, ngay cả khi điều đó khiến bạn xa rời công việc xây dựng thực tế — ví dụ như cố gắng hiểu nhu cầu người dùng, nắm bắt xu hướng thị trường… — thì trong một đội đủ lớn, PM vẫn còn không gian để phát huy vai trò.
Romain:
Tôi xin bổ sung thêm một điểm: Tôi vẫn cho rằng mỗi vấn đề đều cần một con người chịu trách nhiệm về lĩnh vực đó, nhưng tôi không cho rằng người đó nhất thiết phải là PM — điều này phần lớn phụ thuộc vào bản chất sản phẩm.
Chúng tôi ở đây rất may mắn, bởi chúng tôi đang làm việc cho Codex — một công cụ dành cho các nhà phát triển. Chúng tôi chính là người dùng tốt nhất của chính mình. Và vì nó là mã nguồn mở, chúng tôi có thể trực tiếp tương tác với cộng đồng và cùng phát triển.
Nhưng nếu quay lại mười năm trước, ví dụ như khi tôi làm việc tại Stripe, lúc đó công ty có 250 người nhưng không có một PM nào, thậm chí không có bất kỳ công cụ AI nào. Tại sao? Bởi Stripe là một sản phẩm API — tất cả chúng tôi đều là kỹ sư, và có sự hiểu biết trực quan rất mạnh mẽ về thế nào là một API tuyệt vời. Chúng tôi đang xây dựng chính API mà chúng tôi mơ ước — một giải pháp thanh lịch chỉ cần vài dòng mã là có thể triển khai.
Nhưng nếu bạn ở trong một lĩnh vực khác — ví dụ như kỹ sư không có sự hiểu biết trực quan nhiều về nhu cầu người dùng — thì bạn có thể cần nhiều PM hơn để giao tiếp với khách hàng và hiểu nhu cầu của họ. Đặc biệt khi ngành hoặc lĩnh vực bạn phục vụ không hoàn toàn khớp với trực quan của kỹ sư, vai trò của PM sẽ trở nên quan trọng hơn. Tuy nhiên, chúng tôi rất may mắn trong đội Codex, bởi chúng tôi đang xây dựng chính công cụ mà chính chúng tôi cũng muốn sử dụng.
Alex:
Trong môi trường này, vai trò PM có thể chỉ là một nhãn dán, để chỉ người quan tâm nhất đến người dùng và quan tâm sâu sắc nhất đến nhu cầu người dùng — và người đó hoàn toàn có thể là một kỹ sư rất gần gũi với người dùng. Vì vậy, tôi nghĩ những nhãn dán nghề nghiệp này đang dần mất đi ý nghĩa truyền thống, dù có phần lộn xộn nhưng điều đó không phải là điều xấu.
Người dẫn chương trình Peter: Trong đội của tôi cũng có phát hiện tương tự. Tôi thấy những kỹ sư giỏi nhất không hỏi tôi “Tiếp theo chúng ta nên xây dựng gì”, mà họ chủ động đi trò chuyện với người dùng, tự tìm hiểu xem cần phát triển điều gì, rồi mới bàn bạc với tôi — cách làm này khiến mục tiêu của mọi người rất thống nhất.
Romain:
Đây thực chất chính là cách làm việc của đội Codex — rất nhiều tính năng hiện nay trong ứng dụng Codex thực tế là những ý tưởng tuyệt vời do kỹ sư đề xuất từ dưới lên (bottom-up), bởi chính họ cũng cần những tính năng đó.
Alex:
Tuy nhiên, tôi muốn nói rằng có một loại kỹ sư mà tôi rất thích hợp tác. Họ thích trò chuyện với người dùng và suy ngẫm về việc nên xây dựng tính năng gì. Những người này thường cũng rất giỏi trong việc xây dựng hệ thống — nhanh, mạnh và tư duy rõ ràng. Nhưng cũng có một số kỹ sư hoàn toàn không hứng thú với việc tương tác với người dùng — họ chỉ muốn tập trung xây dựng hệ thống. Tôi nghĩ những người này cũng có tiềm năng phát triển rất lớn.
Một lần nữa, đây chính là quan điểm của tôi về kỷ nguyên AI — chúng ta đều có thể trở nên ‘chính mình hơn’. AI và đội nhóm sẽ giúp bạn hoàn thành những việc bạn không muốn làm, để bạn có thể tập trung vào sở thích và thế mạnh của mình.
Người dẫn chương trình Peter: Tôi thực sự cảm thấy nhãn dán “người xây dựng” (builder) rất quan trọng. Tôi nghĩ nhiều PM đều muốn trở thành nhà lãnh đạo, nhưng bậc thang thăng tiến nghề nghiệp truyền thống là khi bạn trở thành Phó Chủ tịch (VP) hoặc chức danh tương tự, bạn lại không còn thời gian để xây dựng nữa. Bạn dành cả ngày trong các buổi đánh giá sản phẩm, chỉ đưa ra một số phản hồi, mà không còn thời gian thực sự phát triển — tôi nghĩ nhiều PM không muốn như vậy, và tôi hy vọng mình có thể luôn gần gũi với người dùng, thực sự ra mắt sản phẩm.
Alex:
Tôi hoàn toàn đồng ý. Tôi thực sự không coi PM là một vai trò lãnh đạo — tôi thiên về việc xem nó như một ‘vai trò lấp đầy khoảng trống’. Đôi khi, vai trò này có thể đòi hỏi một số trách nhiệm lãnh đạo, nhưng ngay cả trong trường hợp đó, lãnh đạo chủ yếu là giúp đội đạt được sự thống nhất — chứ không chỉ dựa vào một người đưa ra giải pháp thiên tài.
Có một điều tôi chắc chắn: Tại OpenAI, những PM xuất sắc nhất đều đi sâu vào các chi tiết cụ thể. Và tôi nghĩ việc gia nhập OpenAI với một vị trí lãnh đạo cấp cao là một việc rất thách thức, bởi văn hóa nơi đây vẫn nhấn mạnh việc quan tâm đến chi tiết. Vì vậy, cách tốt nhất là ngay từ đầu đã đi sâu vào các chi tiết.
Đội Codex ưu tiên điều gì khi tuyển dụng? (Câu trả lời không phải là sơ yếu lý lịch của bạn)
Người dẫn chương trình Peter: Khi tuyển dụng cho đội Codex, ngoài yêu cầu ứng viên là người dùng Codex nặng, các anh còn coi trọng những phẩm chất nào khác?
Alex:
Tôi đã đề cập trước đây rằng tôi rất coi trọng “tinh thần chủ động” (agency) của ứng viên. Chúng tôi muốn tìm những người chủ động hành động — đây là phẩm chất quan trọng nhất.
Tại OpenAI, đặc biệt trong đội Codex, văn hóa của chúng tôi không phải kiểu “bạn gia nhập, rồi chúng tôi sẽ liệt kê 12 nhiệm vụ tăng dần độ khó cho bạn”. Phong cách của chúng tôi giống hơn với: “Chào mừng gia nhập! Giờ thì, hãy bắt đầu khám phá của bạn đi.”
Vì vậy, chúng tôi thiên về việc tìm những người tự chủ động — những người có hành động, có ý tưởng riêng, biết mình muốn làm gì và không ngại thách thức các ý tưởng hiện có. Bởi thực tế, một số ý tưởng hiện có có thể vốn dĩ là sai lầm — có thể chỉ là một quyết định tình cờ của chúng tôi lúc ban đầu.
Đồng đội lý tưởng trong mắt tôi là người sẵn sàng chủ động đảm nhận trách nhiệm bổ sung — thậm chí cả những lĩnh vực chưa được xác định rõ. Đây là những phẩm chất chúng tôi đặc biệt coi trọng. Về kỹ năng cụ thể, chúng tôi thường ưu tiên những ứng viên có năng lực kỹ thuật mạnh, đặc biệt liên quan đến kỹ thuật phần mềm.
Romain:
Tôi hoàn toàn đồng ý. Trong đội trải nghiệm nhà phát triển (DevX) của tôi, tôi thường tìm những người có tinh thần chủ động cao. Họ cần có năng lực kỹ thuật mạnh, đặc biệt thể hiện xuất sắc khi sử dụng các công cụ như Codex. Nhưng ngoài ra, tôi còn đặc biệt coi trọng những người nhiệt huyết với việc làm việc cùng các nhà phát triển và “người xây dựng” (builders), cũng như chia sẻ kiến thức.
Ví dụ, tuần này chúng tôi vừa thông báo Thomas sẽ gia nhập đội tôi — anh ấy là người đã phát triển công cụ giám sát Codex mã nguồn mở. Anh ấy không chỉ rất sáng tạo, mà còn là người dùng Codex nặng và rất nhiệt tình chia sẻ kinh nghiệm về cách dùng Codex để xây dựng công cụ.
Chúng tôi cần những người như vậy, bởi chúng tôi đang nỗ lực dẫn dắt hàng triệu nhà phát triển tiến vào tương lai tươi sáng mà Codex đại diện. Tôi tin rằng lập trình bằng tác nhân (agentic coding) đang hoàn toàn thay đổi cách chúng ta suy nghĩ truyền thống về phát triển phần mềm, ứng dụng và sản phẩm. Mục tiêu của chúng tôi là phô bày khả năng này với toàn thế giới và giúp các nhà phát triển học cách sử dụng các công cụ này để hiện thực hóa ý tưởng của mình. Đó chính là những phẩm chất tôi đang tìm kiếm.
Alex:
Tôi xin bổ sung: Theo quan điểm của tôi, ứng viên lý tưởng cho đội DevX có thể được mô tả đơn giản là “một kỹ sư xuất sắc, đồng thời giỏi tương tác với cộng đồng thông qua mạng xã hội”.
Romain:
Anh nói đúng một phần. Nhưng tôi xin bổ sung: Chúng tôi mong muốn ứng viên có tinh thần trách nhiệm mạnh mẽ với cộng đồng, đồng thời cũng cần cân nhắc thói quen sử dụng mạng xã hội ở các khu vực khác nhau trên toàn cầu. Ví dụ, ở một số nơi, nhà phát triển có thể thiên về dùng LinkedIn hoặc các nền tảng khác thay vì Twitter. Vì vậy, chúng tôi cần mở rộng định nghĩa này: Ứng viên cần có biểu hiện tốt trên mạng xã hội ở phạm vi toàn cầu. Chúng tôi đặc biệt coi trọng những người thích tương tác với cộng đồng, đam mê giảng dạy và chia sẻ kiến thức.
Người dẫn chương trình Peter: Thực tế, tinh thần chủ động của một người thậm chí có thể nhận ra ngay trước buổi phỏng vấn. Ví dụ, họ có đăng tải tác phẩm lên mạng không? Có các dự án cá nhân (side projects) không?
Alex:
Khi ai đó gửi tin nhắn riêng bày tỏ mong muốn gia nhập đội chúng tôi, phản ứng đầu tiên của tôi là: “Có liên kết nào không?” Nếu có, tôi gần như luôn nhấn vào để xem. Tôi tò mò kiểm tra tác phẩm của họ, để xem họ thực sự đang xây dựng điều gì.
Dĩ nhiên, một số người sẽ kèm theo một lá thư xin việc giải thích lý do họ quan tâm đến vị trí này, thậm chí đính kèm sơ yếu lý lịch — nhưng tôi thích xem ý tưởng và sản phẩm thực tế họ tạo ra hơn. Gần đây tôi còn nhận ra một điều thú vị: Tôi hoàn toàn không biết những người này từng học ở trường đại học nào.
Người dẫn chương trình Peter: Ai quan tâm chứ? Ai còn để ý điều đó? Tôi thực sự vui mừng vì chúng ta đang sống trong một thời đại mà những bằng cấp ngớ ngẩn ấy không còn quan trọng như trước — chỉ cần cho tôi xem bạn thực sự đã xây dựng điều gì là đủ rồi.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
深潮TechFlow
