Kể từ ngày 26 tháng 4 năm 2026, sản phẩm Sora không còn khả dụng.
Vào tháng 11, chúng tôi đã ra mắt ứng dụng Sora Android cho toàn thế giới, cho phép bất kỳ ai có thiết bị Android có thể biến một lời nhắc ngắn thành một video sống động. Vào ngày ra mắt, ứng dụng đã đạt vị trí số 1 trên Play Store. Người dùng Android đã tạo hơn một triệu video trong 24 giờ đầu tiên.
Đằng sau sự ra mắt là một câu chuyện: phiên bản đầu tiên của ứng dụng Android sản xuất của Sora được xây dựng trong 28 ngày, nhờ vào cùng một tác nhân có sẵn cho bất kỳ nhóm hoặc nhà phát triển nào: Codex.
Từ ngày 8 tháng Mười đến ngày 5 tháng Mười Một năm 2025, một nhóm kỹ sư tinh gọn làm việc cùng với Codex và tiêu tốn khoảng 5 tỷ token, đã triển khai Sora cho Android từ nguyên mẫu đến ra mắt toàn cầu. Dù có quy mô lớn, ứng dụng này có tỷ lệ không bị treo là 99,9% và một kiến trúc mà chúng tôi tự hào. Nếu bạn đang tự hỏi liệu chúng tôi có sử dụng một mô hình bí mật hay không, chúng tôi đã sử dụng phiên bản đầu tiên của mô hình GPT‑5.1‑Codex – cùng một phiên bản mà bất kỳ nhà phát triển hoặc doanh nghiệp nào có thể sử dụng hôm nay thông qua CLI, tiện ích mở rộng IDE, hoặc ứng dụng web.
Prompt: figure skater performs a triple axle with a cat on her head
Khi Sora ra mắt trên iOS, mức độ sử dụng bùng nổ. Mọi người ngay lập tức bắt đầu tạo ra một loạt video. Ngược lại, trên Android, chúng tôi chỉ có một nguyên mẫu nội bộ nhỏ và số lượng người dùng đã đăng ký trước trên Google Play đang tăng lên.
Phản ứng phổ biến đối với lần ra mắt có tính rủi ro cao và áp lực thời gian là tăng cường nguồn lực và thêm quy trình. Một ứng dụng sản xuất có phạm vi và chất lượng như thế này thường sẽ cần nhiều kỹ sư làm việc trong nhiều tháng, bị chậm lại do sự phối hợp.
Kiến trúc sư máy tính người Mỹ Fred Brooks nổi tiếng đã cảnh báo rằng "việc thêm nhiều người vào một dự án phần mềm đang trễ sẽ làm nó trễ hơn nữa." Nói cách khác, khi cố gắng triển khai nhanh một dự án phức tạp, việc thêm nhiều kỹ sư thường có thể làm giảm hiệu quả do tăng gánh nặng giao tiếp, phân mảnh nhiệm vụ và chi phí tích hợp. Chúng tôi đã tận dụng hiểu biết này thay vì phớt lờ nó; chúng tôi đã tập hợp một nhóm mạnh gồm bốn kỹ sư - tất cả đều được trang bị Codex để tăng đáng kể tác động của mỗi kỹ sư.
Bằng cách làm việc theo cách này, chúng tôi đã phát hành một bản dựng nội bộ của Sora cho Android tới các nhân viên trong 18 ngày và ra mắt công khai 10 ngày sau đó. Chúng tôi duy trì một tiêu chuẩn cao trong các nguyên tắc kỹ thuật Android, đầu tư vào khả năng bảo trì và giữ cho ứng dụng đạt tiêu chuẩn tin cậy mà chúng tôi kỳ vọng từ một dự án truyền thống hơn. (Ngày nay, chúng tôi cũng tiếp tục sử dụng Codex rộng rãi để phát triển và mang đến các tính năng mới cho ứng dụng).
Để hiểu rõ cách chúng tôi làm việc với Codex, điều quan trọng là biết được những điểm mạnh của ứng dụng và những chỗ cần định hướng. Coi Codex như một kỹ sư cao cấp mới được tuyển dụng là cách tiếp cận tốt. Khả năng của Codex có nghĩa là chúng tôi có thể dành nhiều thời gian hơn để chỉ đạo và xem xét mã thay vì tự viết.
Nơi Codex cần được hướng dẫn
- Codex chưa thực sự giỏi trong việc suy luận những điều mà nó chưa được chỉ dẫn (ví dụ: các mẫu hình kiến trúc ưa thích của bạn, chiến lược sản phẩm, hành vi thực tế của người dùng, và các quy tắc hoặc lối tắt nội bộ).
- Tương tự, Codex không thể thấy ứng dụng thực sự chạy: Nó không thể mở Sora trên một thiết bị, nhận thấy rằng việc cuộn không ổn, hoặc nhận biết rằng luồng thông tin gây nhầm lẫn. Chỉ có nhóm của chúng tôi mới có thể đảm nhận những nhiệm vụ trải nghiệm này.
- Mỗi trường hợp cần được tích hợp. Việc chia sẻ ngữ cảnh với các mục tiêu rõ ràng, ràng buộc và hướng dẫn về “cách chúng ta thực hiện mọi việc” là điều cần thiết để Codex hoạt động tốt.
- Tương tự, Codex gặp khó khăn khi đánh giá kiến trúc sâu: Nếu để tự hoạt động, nó có thể giới thiệu một mô hình hiển thị bổ sung trong khi chúng tôi thực sự muốn mở rộng một mô hình hiện có hoặc đẩy logic vào lớp giao diện người dùng mà rõ ràng thuộc về một kho lưu trữ. Bản năng của Codex là làm cho mọi thứ hoạt động, chứ không phải ưu tiên độ thuần khiết về lâu dài.
Chúng tôi thấy hữu ích khi để Codex tạo và duy trì một lượng lớn các tệp AGENT.md trong toàn bộ cơ sở mã. Điều này giúp dễ dàng áp dụng cùng một hướng dẫn và các nguyên tắc tốt nhất cho các phiên. Ví dụ, để đảm bảo Codex viết mã theo hướng dẫn phong cách của chúng tôi, chúng tôi đã thêm nội dung sau vào tệp AGENTS.md cấp cao nhất:
Nơi Codex thể hiện sự vượt trội
- Đọc và hiểu các cơ sở mã lớn một cách nhanh chóng: Codex hiểu rõ hầu hết tất cả các ngôn ngữ lập trình chính, điều này giúp dễ dàng tận dụng các khái niệm tương tự trên nhiều nền tảng mà không cần các trừu tượng phức tạp.
- Phạm vi kiểm thử: Codex (rất) nhiệt tình trong việc viết các bài kiểm thử đơn vị để bao quát nhiều trường hợp khác nhau. Không phải mọi bài kiểm thử đều sâu sắc, nhưng việc có độ bao phủ rộng rất hữu ích trong việc phòng ngừa hồi quy.
- Áp dụng ý kiến phản hồi: Tương tự, Codex rất giỏi trong việc phản ứng với ý kiến phản hồi. Khi CI thất bại, chúng tôi có thể dán đầu ra nhật ký vào một lời nhắc và yêu cầu Codex đề xuất các cách sửa lỗi.
- Thực thi song song quy mô lớn, dùng một lần: Hầu hết sẽ không đẩy giới hạn số lượng phiên mà chúng có thể thực sự chạy cùng một lúc. Rất khả thi để thử nghiệm nhiều ý tưởng song song và coi mã là dùng một lần.
- Cung cấp góc nhìn mới: Trong các cuộc thảo luận thiết kế, chúng tôi đã sử dụng Codex như một công cụ tạo sinh để khám phá các điểm thất bại tiềm năng và tìm ra những cách mới để giải quyết vấn đề. Ví dụ, trong khi chúng tôi thiết kế các tối ưu hóa bộ nhớ cho trình phát video, Codex đã sàng lọc qua nhiều SDK để đề xuất các phương pháp mà chúng tôi không có thời gian để phân tích. Những hiểu biết từ nghiên cứu của Codex là vô giá trong việc giảm thiểu dung lượng bộ nhớ trong ứng dụng cuối cùng.
- Tăng cường công việc có giá trị cao hơn: Trong thực tế, chúng tôi đã dành nhiều thời gian hơn để xem xét và chỉ đạo mã thay vì tự viết. Điều đó nói rằng, Codex cũng rất giỏi trong việc rà soát mã, thường phát hiện lỗi trước khi chúng được hợp nhất, cải thiện độ tin cậy.
Khi chúng tôi thừa nhận những đặc điểm này, mô hình làm việc của chúng tôi trở nên đơn giản hơn. Chúng tôi đã dựa vào Codex để thực hiện một lượng lớn công việc nặng nhọc trong các mẫu đã hiểu rõ và phạm vi được giới hạn tốt, trong khi nhóm của chúng tôi tập trung vào kiến trúc, trải nghiệm người dùng, các thay đổi hệ thống và chất lượng cuối cùng.
Ngay cả nhân viên cấp cao mới giỏi nhất cũng không có góc nhìn đúng đắn để đưa ra các quyết định đánh đổi dài hạn ngay lập tức. Để tận dụng Codex và đảm bảo công việc của nó mạnh mẽ và có thể duy trì, điều then chốt là chúng tôi tự giám sát thiết kế hệ thống của ứng dụng và các quyết định đánh đổi quan trọng. Những điều này bao gồm việc định hình kiến trúc của ứng dụng, phân chia mô-đun, nội xạ phụ thuộc và điều hướng; chúng tôi cũng đã triển khai các luồng xác thực và mạng cơ bản.
Từ nền tảng này, chúng tôi đã viết một vài tính năng tiêu biểu từ đầu đến cuối. Chúng tôi đã sử dụng các quy tắc mà chúng tôi muốn toàn bộ cơ sở mã tuân theo và đã lập tài liệu các mẫu trên toàn bộ án khi chúng tôi thực hiện. Bằng cách hướng Codex đến các tính năng tiêu biểu, Codex có thể hoạt động độc lập hơn theo các tiêu chuẩn của chúng tôi. Đối với một dự án mà chúng tôi ước tính có 85% do Codex viết, một nền tảng được lên kế hoạch cẩn thận đã tránh được việc rút lui và tái cấu trúc tốn kém. Đó là một trong những quyết định quan trọng nhất mà chúng tôi đã đưa ra.
Ý tưởng không phải là làm “một thứ gì đó hoạt động” càng nhanh càng tốt, mà là làm “một thứ gì đó theo cách chúng ta muốn nó hoạt động.” Có nhiều cách “đúng” để viết mã. Chúng tôi không cần phải nói cho Codex biết chính xác phải làm gì; chúng tôi cần chỉ cho Codex thấy điều gì là “đúng” trong nhóm của chúng tôi. Khi chúng tôi đã thiết lập được điểm khởi đầu và cách chúng tôi muốn xây dựng, Codex đã sẵn sàng để bắt đầu.
Để xem điều gì sẽ xảy ra, chúng tôi đã thử yêu cầu: “Xây dựng ứng dụng Sora Android dựa trên mã iOS. "Thực hiện nào," nhưng nhanh chóng từ bỏ hướng đi đó. Về mặt kỹ thuật, dù những gì Codex đã tạo ra đã hoạt động, nhưng trải nghiệm sản phẩm lại dưới mức trung bình. Và nếu không có sự hiểu biết rõ ràng về các điểm cuối, dữ liệu và luồng người dùng, mã một lần của Codex không đáng tin cậy (Ngay cả khi không sử dụng tác nhân, việc hợp nhất hàng nghìn dòng mã cũng rất rủi ro.)
Chúng tôi đã giả định rằng Codex sẽ phát triển mạnh mẽ trong môi trường thử nghiệm với các ví dụ được viết tốt; và chúng tôi đã đúng. Việc yêu cầu Codex “xây dựng màn hình cài đặt này” mà gần như không có ngữ cảnh là không đáng tin cậy. Yêu cầu Codex “xây dựng màn hình cài đặt này bằng cách sử dụng cùng kiến trúc và mẫu như màn hình khác mà bạn vừa thấy” hoạt động tốt hơn nhiều. Con người đã đưa ra các quyết định cấu trúc và thiết lập các bất biến; sau đó Codex điền vào một lượng lớn mã bên trong cấu trúc đó.
Bước tiếp theo trong việc tối đa hóa tiềm năng của Codex là tìm ra cách để cho phép Codex hoạt động trong thời gian dài (gần đây, trên 24 giờ), mà không cần giám sát.
Ngay từ đầu khi sử dụng Codex, chúng tôi đã chuyển sang các lời nhắc như, “Đây là tính năng. Đây là một số tệp tin. Hãy dựng nó.” Điều đó đôi khi có hiệu quả, nhưng phần lớn tạo ra mã mà về mặt kỹ thuật có thể biên dịch được, nhưng lại lệch khỏi kiến trúc và mục tiêu của chúng tôi.
Vì vậy, chúng tôi đã thay đổi quy trình làm việc. Đối với bất kỳ thay đổi quan trọng, trước tiên chúng tôi yêu cầu Codex giúp chúng tôi hiểu cách hệ thống và mã hoạt động. Ví dụ, chúng tôi sẽ yêu cầu Codex đọc một tập hợp các tệp liên quan và tóm tắt cách tính năng đó hoạt động; chẳng hạn như cách dữ liệu di chuyển từ API qua lớp kho lưu trữ, mô hình hiển thị, và vào giao diện người dùng. Sau đó, chúng tôi sẽ điều chỉnh hoặc tinh chỉnh sự hiểu biết của nó. (Ví dụ, chúng tôi sẽ chỉ ra rằng một sự trừu tượng cụ thể thực sự thuộc về một tầng khác hoặc rằng một lớp nhất định chỉ tồn tại cho chế độ ngoại tuyến và không nên được mở rộng.)
Tương tự như cách bạn có thể hợp tác với một đồng đội mới có năng lực cao, chúng tôi đã làm việc với Codex để tạo kế hoạch triển khai chắc chắn. Kế hoạch đó thường trông giống như một tài liệu thiết kế thu nhỏ, chỉ đạo những tệp nào cần thay đổi, những trạng thái mới nào nên được giới thiệu, và cách logic nên được triển khai. Chỉ sau đó chúng tôi mới yêu cầu Codex bắt đầu áp dụng kế hoạch, từng bước một. Một mẹo hữu ích: đối với các nhiệm vụ rất dài, khi chúng ta đạt đến giới hạn của cửa sổ ngữ cảnh, chúng tôi sẽ yêu cầu Codex lưu kế hoạch vào một tệp, cho phép chúng tôi áp dụng cùng một hướng dẫn trên các phiên bản.
Vòng lặp lập kế hoạch bổ sung này hóa ra đáng giá về mặt thời gian. Điều đó cho phép chúng tôi để Codex chạy “không giám sát” trong thời gian dài, vì chúng tôi đã biết kế hoạch của nó. Việc xem xét mã trở nên dễ dàng hơn, vì chúng tôi có thể kiểm tra việc triển khai so với kế hoạch của mình thay vì đọc sự khác biệt mà không có ngữ cảnh. Và khi sự cố xảy ra, chúng tôi có thể gỡ lỗi kế hoạch trước và mã sau đó.
Sự năng động tạo cảm giác tương tự như cách một tài liệu thiết kế tốt mang lại sự tự tin cho trưởng nhóm kỹ thuật trong một dự án. Chúng tôi không chỉ tạo mã: chúng tôi đang sản xuất mã hỗ trợ một lộ trình chung.
Vào thời điểm cao điểm của dự án, chúng tôi thường chạy nhiều phiên Codex song song. Một phiên bản chạy việc phát lại, phiên bản khác chuyên về tìm kiếm, phiên bản khác về xử lý lỗi, và đôi khi một phiên bản khác về kiểm thử hoặc tái cấu trúc. Ít có cảm giác giống như đang sử dụng một công cụ mà cảm giác như đang quản lý một nhóm.
Mỗi phiên sẽ định kỳ báo cáo lại tiến trình cho chúng tôi. Một phiên bản có thể cho biết, "Tôi đã hoàn thành việc lập kế hoạch cho mô-đun này; đây là những gì tôi đề xuất," trong khi phiên bản khác sẽ đưa ra sự thay đổi lớn cho một tính năng mới. Mỗi phiên bản đều cần sự chú ý, phản hồi và xem xét. Giống một cách kỳ lạ với việc làm Trưởng nhóm kỹ thuật với một số kỹ sư mới, tất cả đều đang tiến triển và đều cần sự hướng dẫn.
Kết quả là một quy trình hợp tác. Khả năng mã hóa thô của Codex đã giải phóng chúng tôi khỏi nhiều công việc gõ tay. Chúng tôi có nhiều thời gian hơn để suy nghĩ về kiến trúc, đọc kỹ các yêu cầu kéo, và thử nghiệm ứng dụng.
Đồng thời, tốc độ tăng thêm đó có nghĩa là chúng tôi luôn có thứ gì đó đang chờ trong hàng đợi đánh giá. Codex không bị chặn bởi việc chuyển đổi ngữ cảnh, nhưng chúng tôi thì có. Điểm nghẽn trong phát triển của chúng tôi đã chuyển từ việc viết mã sang việc ra quyết định, đưa ra phản hồi và tích hợp các thay đổi.
Đây là nơi những hiểu biết của Brooks được thể hiện theo cách mới mẻ. Bạn không thể chỉ đơn giản thêm các phiên Codex và mong đợi tăng tốc độ tuyến tính, cũng như không thể cứ thêm kỹ sư vào một dự án và mong đợi lịch trình sẽ thu hẹp theo tuyến tính. Mỗi "đôi tay" bổ sung, ngay cả những đôi tay ảo, đều gia tăng gánh nặng phối hợp. Chúng tôi đã trở thành nhạc trưởng của một dàn nhạc thay vì chỉ là những nghệ sĩ solo nhanh hơn.
Chúng tôi đã bắt đầu dự án của mình với một bước đệm lớn: Sora đã được phát hành trên iOS. Chúng tôi thường xuyên chỉ định Codex vào các cơ sở mã iOS và backend để giúp nó hiểu các yêu cầu và ràng buộc chính. Trong suốt dự án, chúng tôi đùa rằng chúng tôi đã tái phát minh ra ý tưởng về một khung làm việc đa nền tảng. Hãy quên React Native hay Flutter đi; tương lai của đa nền tảng chỉ là Codex.
Ẩn dưới câu nói đùa là hai nguyên tắc:
- Logic mang tính di động. Dù mã được viết bằng Swift hay Kotlin, logic ứng dụng cơ bản – mô hình dữ liệu, các cuộc gọi mạng, quy tắc xác thực, logic kinh doanh – đều giống nhau. Codex rất giỏi trong việc đọc một triển khai Swift và tạo một phiên bản tương đương trong Kotlin mà vẫn giữ nguyên ngữ nghĩa.
- Các ví dụ cụ thể cung cấp ngữ cảnh ấn tượng. Một phiên Codex mới có thể thấy “đây là cách hoạt động chính xác trên iOS” và “đây là kiến trúc của Android” thì hiệu quả hơn nhiều so với một phiên chỉ làm việc từ các mô tả ngôn ngữ tự nhiên.
Áp dụng những nguyên tắc này, chúng tôi đã làm cho các kho lưu trữ iOS, backend và Android khả dụng trong cùng một môi trường. Chúng tôi đã cung cấp cho Codex những lời nhắc như:
"Hãy đọc các mô hình và điểm cuối này trong mã iOS, sau đó đề xuất một kế hoạch để triển khai hành vi tương đương trên Android bằng cách sử dụng máy khách API và các lớp mô hình hiện có của chúng tôi."
Một mẹo nhỏ nhưng hữu ích là ghi chi tiết trong ~/.codex/AGENTS.md nơi có các kho lưu trữ cục bộ và nội dung của chúng. Điều đó đã giúp Codex dễ dàng hơn trong việc khám phá và điều hướng mã liên quan.
Chúng tôi thực hiện phát triển đa nền tảng một cách hiệu quả thông qua dịch thuật thay vì sử dụng các trừu tượng chia sẻ. Vì Codex đã xử lý phần lớn công việc dịch thuật, chúng tôi đã tránh được việc tăng gấp đôi chi phí triển khai.
Bài học quan trọng hơn là đối với Codex, ngữ cảnh là tất cả. Codex đã làm việc tốt nhất khi nó hiểu rõ cách tính năng đã hoạt động trên iOS, kết hợp với sự hiểu biết về cách cấu trúc ứng dụng Android của chúng tôi. Khi Codex thiếu ngữ cảnh đó, nó không phải là "từ chối hợp tác"; nó đang phỏng đoán. Càng coi Codex như một đồng đội mới và đầu tư vào việc cung cấp đầu vào phù hợp, nó càng hoạt động tốt hơn.
Đến cuối đợt chạy nước rút bốn tuần của chúng tôi, việc sử dụng Codex không còn cảm giác như thử nghiệm mà đã trở thành vòng lặp phát triển mặc định của chúng tôi. Chúng tôi đã sử dụng nó để hiểu rõ mã hiện có, lập kế hoạch thay đổi và triển khai các tính năng. Chúng tôi đã xem xét đầu ra của nó giống như cách chúng tôi sẽ xem xét đầu ra của một đồng đội. Đó chỉ đơn giản là cách chúng tôi phát hành phần mềm.
Rõ ràng là phát triển có sự hỗ trợ của AI không làm giảm nhu cầu về sự nghiêm ngặt; ngược lại, còn làm tăng nhu cầu đó. Dù Codex có khả năng, mục tiêu của nó là đạt được từ A đến B ngay lập tức. Đây là lý do lập trình được AI hỗ trợ không thể hoạt động nếu thiếu con người. Các kỹ sư phần mềm có thể hiểu rõ và áp dụng các ràng buộc thực tế của hệ thống, các phương pháp tốt nhất để thiết kế phần mềm, và cách xây dựng với sự phát triển trong tương lai và kế hoạch sản phẩm trong tâm trí. Siêu năng lực của kỹ sư phần mềm trong tương lai sẽ là hiểu biết sâu sắc về hệ thống và khả năng làm việc hợp tác với AI trong các khoảng thời gian dài.
Những phần thú vị nhất của kỹ thuật phần mềm là xây dựng các sản phẩm hấp dẫn, thiết kế các hệ thống có khả năng mở rộng, viết các thuật toán phức tạp và thử nghiệm với dữ liệu, mẫu và mã. Tuy nhiên, thực tế của kỹ thuật phần mềm trong quá khứ và hiện tại thường nghiêng về những điều tẻ nhạt hơn: căn chỉnh các nút, kết nối các điểm cuối, và viết mã mẫu. Giờ đây, Codex giúp chúng ta có thể tập trung vào những phần có ý nghĩa nhất của kỹ thuật phần mềm và những suy luận chúng ta yêu thích nghề của mình.
Khi Codex được thiết lập trong môi trường giàu ngữ cảnh, nơi nó hiểu được mục tiêu của bạn và cách bạn thích xây dựng, bất kỳ nhóm nào cũng có thể nhân đôi khả năng của mình. Buổi họp tổng kết sau khi ra mắt của chúng tôi không phải là công thức áp dụng chung cho tất cả, và chúng tôi không tuyên bố đã giải quyết xong việc phát triển có sự hỗ trợ của AI. Nhưng chúng tôi hy vọng kinh nghiệm của mình sẽ giúp dễ dàng hơn trong việc tìm ra những cách tốt nhất để trao quyền cho Codex nhằm trao quyền cho bạn.
Khi Codex ra mắt ở bản xem trước nghiên cứu bảy tháng trước, kỹ thuật phần mềm đã trông rất khác biệt. Thông qua Sora, chúng tôi đã khám phá chương tiếp theo của kỹ thuật. Khi các mô hình và công cụ của chúng tôi tiếp tục được cải thiện, AI sẽ trở thành một phần không thể thiếu và ngày càng quan trọng trong việc xây dựng.
Bạn sẽ tạo ra gì với đội ngũ Codex của riêng mình?
