Người phụ trách Codex: "Mọi người đều là builder" là một ý tưởng rất tệ.

Andrew Ambrosino là trưởng nhóm OpenAI Codex. Xuất thân là nhà thiết kế, từng làm kỹ sư, làm sản phẩm, và từng khởi nghiệp, hiện tại nhóm Codex do anh ấy phụ trách đã có hơn 5 triệu người dùng hoạt động hàng tuần. Anh ấy có lẽ là một trong những người phù hợp nhất hiện nay để trả lời câu hỏi "Nên làm sản phẩm như thế nào trong thời đại AI".

Theo quan điểm của anh ấy, khi hầu như mọi người trong công ty đều có thể nhanh chóng tạo ra một nguyên mẫu tính năng, thì vấn đề thực sự không còn là "có làm được hay không", mà là "có nên làm hay không".

Trong cuộc trò chuyện với Lenny, Andrew Ambrosino đã giới thiệu chi tiết về quy trình phát triển nội bộ của OpenAI: Khi chi phí hiện thực hóa bị AI nén xuống đáng kể, mọi khâu trong quá trình phát triển sản phẩm, từ lập dự án, tài liệu, nguyên mẫu, thiết kế đến phân chia vai trò, hợp tác nhóm, hoạch định sản phẩm, đều đang thay đổi. Những quy tắc cũ nào đang mất hiệu lực? Những tiêu chuẩn mới nào đang hình thành? Khi hiện thực hóa không còn là thứ hiếm có, thì nguồn lực thực sự hiếm có là gì?

Một số quan điểm cốt lõi:

Khi 90 người đều có thể tạo ra 90 nguyên mẫu sản phẩm trông có vẻ sẵn sàng ra mắt, thì thứ quý giá nhất là gu thẩm mỹ (taste).

Một trong những tiêu chuẩn cứng khi tuyển người của nhóm Codex là gu thẩm mỹ, khả năng phân biệt tín hiệu và nhiễu từ lượng lớn nội dung. Trong một thế giới "có token vô hạn", họ không muốn sản xuất nội dung rác.

Nếu Codex ra mắt sớm ba tháng, nó sẽ thất bại hoàn toàn, biến số duy nhất là mô hình đã tiến bộ. Đừng dễ dàng kết luận một tính năng là không tốt, nó có thể chỉ chưa tới thời điểm.

Tiền đề cuối cùng để một tính năng đủ tốt thường không phải là hình thái của chính tính năng đó, mà là liệu mô hình có đủ thông minh hay không.

Giống như Codex từng lật đổ ChatGPT, Codex cũng có thể bị lật đổ bởi những nỗ lực mới. Cần duy trì văn hóa khám phá từ dưới lên, không thể kỳ vọng cùng một nhóm vừa trau chuốt chi tiết vừa tự lật đổ chính mình.

Dưới đây là nội dung tinh túy của cuộc trò chuyện.

Chi phí hiện thực hóa giảm xuống, gu thẩm mỹ càng trở nên quan trọng hơn

Lenny: Anh từng nói AI đang thay đổi hình thái công việc sản phẩm. Hiện tại anh đang làm việc trong nhóm sản phẩm AI tiên tiến nhất thế giới. Cụ thể, cách làm việc của nhóm sản phẩm so với hai năm trước có gì thay đổi?

Andrew Ambrosino: Hiện tại với tư cách là trưởng nhóm, điều khó nhất là quy trình đã bị đảo ngược.

Trước đây làm sản phẩm thế nào, ai cũng quen: đầu tiên nghiên cứu, đưa ra ý tưởng, làm nguyên mẫu. Dù chúng ta đã vượt qua thời đại phát triển waterfall, logic cơ bản vẫn như cũ, hiện thực hóa là đắt đỏ. Vì vậy bạn phải loại bỏ mọi rủi ro trước khi hiện thực hóa thông qua tài liệu, nghiên cứu, nguyên mẫu. Bởi vì nguyên mẫu và thiết kế rẻ hơn phát triển, đó là giả định cơ bản trước đây.

Bây giờ giả định đó đã hoàn toàn thay đổi, bất kỳ ai cũng có thể làm ra bất cứ thứ gì. Tôi thực sự tin rằng, bạn bắt đầu từ con số không và trò chuyện với các mô hình này, dù là mô hình của chúng tôi hay của công ty khác, bạn đều có thể dựng lên bất kỳ tính năng nào bạn muốn. Đây không nhất thiết là phần khó nhất trong phát triển phần mềm, nhưng nó thực sự rất tuyệt.

Bạn cho mọi người token vô hạn, mọi người ở OpenAI đều rất chủ động, đều có ý tưởng tốt. Vì vậy mọi người đều đang làm đủ thứ. Hiện tại trong công ty có một tính năng chúng tôi cần gấp, tôi chắc chắn có 90 nhóm nhỏ khác nhau, chưa từng phối hợp, đang tự hiện thực hóa và thử nghiệm. Trong 90 nỗ lực đó, cái nào tốt? Nên gấp phần nào vào các khía cạnh khác? Nên định nghĩa nó thế nào? Nó có nên là một phần của tính năng khác không? Nên có bao nhiêu tùy chọn trong công tắc? Là những thứ này.

Vì vậy câu trả lời ngắn gọn là: đã bị đảo ngược. Không phải mọi người đang làm những vai trò hoàn toàn khác, cũng không phải kỹ năng biến mất, vai trò không tồn tại. Hiện thực hóa không còn là phần đắt đỏ nhất nữa, tôi dám nói, đắt nhất là gu thẩm mỹ (taste).

Lenny: Vậy trước đây mọi người viết PRD, tài liệu chiến lược, bây giờ mọi người trực tiếp làm nguyên mẫu. Nhiều người trong công ty có ý tưởng tương tự, xuất hiện 90 thứ khác nhau, rồi chọn hướng từ đó?

Andrew Ambrosino: Đúng vậy, những chuyện như vậy xảy ra rất nhiều. Không chỉ ở OpenAI, bạn đã thấy nhiều người phụ trách sản phẩm nói "PRD đã chết, nguyên mẫu lên ngôi", nhưng tôi thực sự hoàn toàn không đồng ý với quan điểm đó.

Bởi vì hiện thực hóa trở nên rẻ trên mọi phương tiện, nên rất dễ bị cám dỗ bỏ qua suy nghĩ và làm nguyên mẫu trực tiếp. Đặc biệt nếu bạn không phải là kỹ sư, nếu bạn chưa bao giờ viết code, không có hứng thú hoặc không có thời gian, bạn sẽ không thể không nói: "PRD đã chết, để tôi cho bạn xem trực tiếp tôi muốn gì."

Nhưng tôi cũng nhận thấy một hiện tượng ngược lại. Đối với các kỹ sư, viết nhiều tài liệu trở nên rất hấp dẫn, rất nhiều tài liệu không đáng đọc. Điều này không có nghĩa là người viết tài liệu không tốt, mà là khi hiện thực hóa trở nên dồi dào, việc chọn đúng định dạng để truyền đạt quan điểm của bạn trở nên thực sự quan trọng.

Nếu bạn muốn thể hiện sự rõ ràng về sản phẩm trong một lĩnh vực mơ hồ, thì có lẽ nên viết tài liệu. Nếu bạn muốn mọi người dùng thử, kiểm tra áp lực một mô hình tương tác, thì hãy làm nguyên mẫu. Quan trọng là chọn đúng phương tiện.

Lenny: Có một khái niệm gọi là primal mark (dấu ấn đầu tiên), nét vẽ đầu tiên của họa sĩ lên canvas, mọi thứ sau đó đều mở rộng từ nét đó. Ý anh là, đôi khi nguyên mẫu là dấu ấn đầu tiên sai? Vì mọi người sẽ neo vào đó, thay vì nghĩ đến giải pháp lớn hơn?

Andrew Ambrosino: Đúng vậy. Trước đây có một tín hiệu ngầm, một thứ trông như thế nào có nghĩa là nó đang ở giai đoạn nào của quy trình. Nếu bạn thấy một thứ trông giống như sản phẩm chính thức ra mắt, điều đó có nghĩa là nó đã ở giai đoạn cuối, rủi ro đã được loại bỏ, thiết kế đã được xem xét, mục tiêu kinh doanh đã hợp lý.

Bây giờ những thứ này đã tách rời. Lý do là trước đây để có được nguồn lực để xây dựng, bạn phải giảm thiểu rủi ro đầy đủ, bây giờ ngưỡng đó không còn nữa. Vì vậy, một thứ chỉ mới ở giai đoạn khám phá, trông đã có thể ra mắt, về mặt hình ảnh nó đã sẵn sàng. Nhưng nó có thể hoàn toàn không phải hướng đi đúng, không phù hợp với kết luận nghiên cứu, không phải thứ người dùng thực sự cần, cũng không phải lựa chọn tối ưu cho kinh doanh.

Không phải để quá nhấn mạnh vào gu thẩm mỹ. Nhưng một lần nữa, biết nên làm gì, trình bày thế nào, đạt được mục tiêu ra sao, dùng phương tiện nào, đang trở thành năng lực quan trọng nhất trong mọi lĩnh vực.

Lenny: Gu thẩm mỹ bây giờ là một từ thông dụng. Cụ thể, "gu thẩm mỹ tốt" mà anh nói là gì?

Andrew Ambrosino: Gu thẩm mỹ phải được tách ra để xem.

Có phần thẩm mỹ, nhưng cũng có phần tư duy hệ thống, thứ này được đặt trong toàn bộ hệ thống như thế nào; có phần định hướng, chúng ta sẽ đi đâu, việc này là một phần của chủ đề nào; có phần trình bày, truyền đạt thông tin này như thế nào; và một phần gu thẩm mỹ là ở cấp độ tương tác, animation này không phù hợp với ngữ nghĩa nó muốn truyền tải, nó quá vội vàng, không khớp với ý nghĩa nó muốn diễn đạt.

Những điều này thực sự rất quan trọng, nhưng vấn đề gu thẩm mỹ thực sự là, nếu chúng ta có thể làm mọi thứ, thì mục tiêu là gì? Làm thế nào để đến đó?

Lenny: Khi AI ngày càng mạnh, làm ngày càng nhiều việc, thì bộ não con người sẽ tiếp tục có giá trị ở những điểm nào? Gu thẩm mỹ có vẻ là một trong số đó. Nhưng đầu ra thiết kế của AI vẫn chưa tốt lắm, tại sao các mô hình hàng đầu không làm tốt được thiết kế?

Andrew Ambrosino: Có một số lý do thực tế, và một số vấn đề khó giải quyết hơn. Thiết kế khó đánh giá hơn phần mềm, việc tạo ra một vòng phản hồi để huấn luyện mô hình thế nào là thiết kế tốt phức tạp hơn nhiều so với huấn luyện code có thể biên dịch hay không, vì gu thẩm mỹ của con người là một phần của cơ chế phản hồi.

Ngoài ra, lịch sử phòng thí nghiệm ưu tiên làm cho mô hình giỏi những thứ có thể tăng tốc nghiên cứu AI. Mô hình viết code đúng rõ ràng có thể tăng tốc nghiên cứu, còn thiết kế thì không thể lập luận tương tự. Không phải nói thiết kế không quan trọng, mà là nó không nằm trong vòng lặp đó.

Đây là những lý do thực tế, chúng sẽ biến mất. Mô hình sẽ trở nên khá giỏi trong thiết kế, nhưng có một số thứ khó giải quyết hơn.

Thứ nhất, thiết kế có thuộc tính văn hóa. Bạn còn nhớ năm ngoái mọi trang web mới đều sao chép thiết kế của Linear. Nếu mô hình luôn xuất ra trang web của Linear, đó không phải là thách thức. Tầm quan trọng của tính mới lạ trong thiết kế cao hơn nhiều so với kỹ thuật phần mềm. Kỹ thuật phần mềm bạn muốn mô hình hoàn toàn tuân theo các mẫu đã biết, nhưng thiết kế cần một số tính ngẫu nhiên và mới lạ.

Thứ hai, là sự tương tác giữa thiết kế hình ảnh và code. Nếu ngày mai công ty đổi thương hiệu, cách nông cạn là cập nhật lần lượt 263 component. Cách sâu sắc là hiểu rằng hai thứ trông khác nhau này thực ra đều thuộc cùng một kiểu danh sách, truyền tải cùng một mẫu tương tác. Lớp trừu tượng này, công nghệ hiện tại chưa với tới được.

Lenny: Jenny Wen (Giám đốc thiết kế Claude Code của Anthropic) nói quy trình thiết kế đã chết, cứ trực tiếp xây dựng, anh nghĩ sao?

Andrew Ambrosino: Tôi và Jenny có thể đồng ý với nhau về nhiều điều. Về quy trình thiết kế chính thống, tôi đồng ý với cô ấy, nó đã chết. Và tôi đã không phải là người hâm mộ quy trình đó ngay cả trước thời AI.

Nhiều năm trước khi tôi làm công ty khởi nghiệp, có một bài báo tên là "Nhà máy nghiên cứu trường hợp", nói về việc các nhà thiết kế được huấn luyện để tuân theo một quy trình cố định, và dần dần coi trọng quy trình này hơn cả kết quả. Nếu một thứ gì đó đã trải qua quy trình này, nó sẽ mặc định có hai kết luận: thứ nhất, nó sẽ tốt, quy trình đảm bảo chất lượng; thứ hai, dù không ai dùng, nó vẫn tốt, vì nó đã đi theo quy trình.

Nghiên cứu người dùng, phân kỳ, hội tụ, khung này đúng, nhưng luôn hơi học thuật. Tiền đề của quy trình đó là hiện thực hóa rất đắt, bạn chỉ đủ khả năng xây dựng một lần, vì vậy phải khám phá hết không gian vấn đề và không gian giải pháp trước khi làm.

Sau đó Figma và Origami xuất hiện, chúng tôi kéo nguyên mẫu tương tác vào quy trình. Vấn đề bây giờ là, bạn có thể kéo toàn bộ hiện thực hóa lên đầu quy trình. Một nguyên mẫu hoàn toàn tinh xảo, trông có thể ra mắt ngay. Đủ nhiều người trong công ty thấy nó và hỏi: "Chúng ta có thể phát hành ngay bây giờ không?" Nhưng thực tế, các bạn vẫn đang ở giai đoạn khám phá thiết kế sớm, chỉ là không ai nói ra.

Vì vậy nói quy trình thiết kế đã chết, vừa đúng vừa sai. Nếu bạn gắn chặt với các công cụ cụ thể và các thao tác hàng ngày cụ thể, thì nó thực sự đã chết. Nhưng nhận thức "chúng ta đang ở giai đoạn nào của quy trình" quan trọng hơn bao giờ hết.

Gắn quy trình thiết kế với một phương tiện cụ thể, đó mới là nơi nguy hiểm. Các nhà thiết kế bây giờ có nhiều công cụ hơn, bạn có thể đặt thứ trực tiếp vào sản phẩm hiện tại, có thể làm thử nghiệm A/B. Nhiều công ty có phiên bản baby của sản phẩm, baby Cursor, baby Codex, một codebase đơn giản hóa nhiều, có thể mô phỏng tất cả tương tác của sản phẩm chính thức. Bạn có thể dùng nó để vibe code (code theo cảm hứng), nói "Nếu thanh bên trông thế này thì sao? Nếu một bảng điều khiển bật ra thì sao?" Đây là công cụ mới của nhà thiết kế, nhưng nó cần đi kèm với nhận thức cũ: bạn đang ở vị trí nào trong quy trình.

Công việc và vai trò đang hòa trộn, nhưng PM sẽ không biến mất

Lenny: Nhiều công ty nói về "sự biến mất của vai trò". Anh nghĩ sự phân chia giữa PM, kỹ sư, nhà thiết kế sẽ hoàn toàn biến mất không?

Andrew Ambrosino: Một số công ty rất thích chạy theo xu hướng, đi đến cực đoan. Sự nguy hiểm của việc xóa bỏ khái niệm vai trò là nó có thể đồng thời xóa bỏ nhận thức rằng "các lĩnh vực này là những chuyên môn có những thực hành tốt nhất có thể học được".

Tôi nghe nhiều công ty nói "Chúng tôi sẽ hủy bỏ vai trò sản phẩm", tôi nghĩ đó là một ý tưởng rất tồi, và sau đó nói "mọi người đều là người xây dựng". Kết quả là quản lý sản phẩm, một ngành đã tích lũy được những thực hành tốt nhất thực sự, đã thực sự vấp ngã, bị vứt bỏ trực tiếp. Bởi vì ai đó viết vài dòng code, nghĩ rằng mọi thứ đều ổn, đó không phải là trạng thái tốt.

Tôi hoan nghênh ranh giới "đây không phải lĩnh vực của bạn, bạn không được động vào" biến mất, nhưng cần cân bằng. Không phải ai cũng có thể làm mọi thứ, dù về bề rộng hay chiều sâu, đó cũng là lý do tại sao người quản lý sẽ không biến mất.

Và mỗi ngành đều có thành phần kỹ năng. Nhiều kỹ sư không thừa nhận điều này, cho rằng kỹ thuật có kỹ năng, còn các vai trò khác đều là "bầu không khí". Không phải vậy, bạn biết dùng Excel không có nghĩa là bạn có thể làm việc trong nhóm tài chính.

Tôi nghĩ điều đang xảy ra hiện tại là, mọi người hợp tác xuyên vai trò trở nên dễ dàng hơn, học các thực hành tốt nhất từ lĩnh vực khác cũng dễ dàng hơn, mà không cần gắn hiệu quả của bạn trong một vai trò nào đó với khả năng sử dụng công cụ cụ thể.

Tôi đã mất nhiều thời gian nghĩ rằng mình không nên làm kỹ sư phần mềm, vì tôi không quan tâm đến hợp ngữ, cũng không muốn nhớ hệ thống kiểu của TypeScript. Những vai trò này luôn có một số rào cản, như thể "làm tốt vai trò này đồng nghĩa với việc thành thạo công cụ này". Tôi nghĩ điều này bắt đầu tan rã, nhưng mọi người đã phóng đại nó.

Lenny: Trong nhóm Codex của anh, thực sự có nhiều sự hòa trộn vai trò hơn, cụ thể là như thế nào?

Andrew Ambrosino: Trong nhóm Codex, chúng tôi thực sự thấy nhiều sự hòa trộn vai trò hơn so với các nhóm khác trong công ty và các ngành khác. Một phần lý do là vì đây là một sản phẩm kỹ thuật hướng đến các kỹ sư. Vì vậy các nhà thiết kế của chúng tôi nói ngôn ngữ của kỹ sư, các quản lý sản phẩm của chúng tôi nói ngôn ngữ kỹ thuật, biết viết code.

Trong nội bộ, chúng tôi có một cách mô tả sự hợp tác: hiện tại sự chồng chéo giữa các vai trò lớn hơn nhiều so với trước đây. Định nghĩa một người, không còn là nhìn vào ranh giới trách nhiệm như "thiết kế kết thúc ở đâu, kỹ thuật bắt đầu từ đâu", mà là nhìn vào phân bố trung bình của tất cả công việc của anh ta.

Nếu bạn trải ra tất cả những việc một người trong nhóm thiết kế làm, có thể bao gồm rất nhiều công việc viết code, và cũng rất nhiều công việc liên quan đến sản phẩm. Nhưng lấy "giá trị trung bình" của những công việc đó, cuối cùng anh ta vẫn nằm ở một khu vực thiên về thiết kế hơn.

Lenny: Anh đề cập rằng công việc của quản lý sản phẩm giống như zone defense (phòng thủ khu vực), cụ thể là gì?

Andrew Ambrosino: Nếu hai quản lý sản phẩm hợp tác quá chặt chẽ, thường không phải là tín hiệu tốt. Bạn nên trải nhóm ra như bố trí lực, xem ở đâu có khoảng trống, ở đâu chưa có người phủ sóng?

Trong thế giới ngày nay, việc tuyển chọn, định hướng và căn chỉnh trở thành công việc quan trọng nhất. Mọi người liên tục tung ra ý tưởng, toàn bộ môi trường đầy nhiễu, cách tiếp cận từ trên xuống, lập kế hoạch theo năm đã không còn hiệu quả. Chúng ta cần ai đó làm người gác cổng về gu thẩm mỹ, dẫn dắt một thứ từ ý tưởng đến sản phẩm, và điều đó có nghĩa là bạn phải phủ sóng mọi góc của công ty.

Vì vậy, bạn cần trải nhóm ra xem, ai giỏi gì? Giữ khoảng cách với nhau, đảm bảo phủ sóng đầy đủ. Sau đó lấp đầy khoảng trống, ví dụ: "Chúng tôi muốn tuyển một kỹ sư có tư duy sản phẩm mạnh." Chúng tôi không muốn xảy ra trường hợp, một nhóm người viết một lượng lớn code trước, cuối cùng cả nhóm sản phẩm phải xem xét và hiệu chỉnh sự nhất quán của sản phẩm. Chúng tôi hy vọng mỗi người đều có những khả năng này, chỉ là hướng đi sâu của mỗi người cần thay đổi.

Lenny: Vậy người có giá trị nhất bây giờ, là người có thể thúc đẩy từ ý tưởng đến hoàn thành và có gu thẩm mỹ để biết "cái này tuyệt vời"?

Andrew Ambrosino: Đúng vậy, tôi nghĩ đó là sự thay đổi cốt lõi nhất hiện tại. Điều này cũng phản ánh hiểu biết của tôi về mối quan hệ giữa IC (người đóng góp cá nhân) và người quản lý. Không phải nói quản lý sẽ biến mất, cũng không phải mọi người chỉ là IC, mà là bây giờ mỗi người ở một mức độ nào đó đều đồng thời đảm nhận cả hai vai trò.

Nếu bạn là IC, bạn không còn gõ từng ký tự code. Bạn thực ra đang quản lý một số thứ, quản lý agents, quản lý những công việc được tổ chức lại để hoàn thành nhiệm vụ chung. Nếu bạn là người quản lý nhóm, về bản chất cũng làm điều tương tự, chỉ khác về độ chi tiết của quản lý.

Những người tôi thường tìm kiếm, ngoài năng lực chuyên môn vững chắc, còn phải có gu thẩm mỹ. Bởi vì trong một thế giới "có token vô hạn", chúng tôi không thể sản xuất nội dung rác. Bạn phải có khả năng phân biệt tín hiệu và nhiễu từ lượng lớn nội dung.

Mỗi lần ai đó hỏi nhóm Codex có bao nhiêu người, câu trả lời của tôi là: "Khoảng từ 10 đến vài nghìn người." Nghe như một câu nói đùa, nhưng thực tế, công việc của tất cả mọi người đều hội tụ vào sản phẩm này, nghiên cứu mô hình, sử dụng trình duyệt, tính cách mô hình, cơ sở hạ tầng front-end, trải nghiệm người dùng, tất cả đều tạo thành một phần của sản phẩm.

Nhưng đồng thời, không phải ngày nào chúng tôi cũng nhận vài nghìn PR (yêu cầu kéo code) do mọi người gửi. Nhóm có quy mô hai con số kỹ sư, số nhà thiết kế khoảng một nửa kỹ sư, thêm vài quản lý sản phẩm, đại đa số là IC. Tầm ảnh hưởng của nhóm rất lớn, nhưng số cấp quản lý không dày. Ở đây có nhiều người từng thành lập công ty, cũng có nhiều người làm việc với "tư duy người sáng lập" trong các công ty lớn, và nhiều người có gu thẩm mỹ rất tốt.

Toàn bộ ứng dụng Codex được định hình bởi vòng lặp dogfooding. Tất cả chúng tôi đều có một mong muốn chung, hoàn thành công việc của mình trong ứng dụng nhiều nhất có thể, dù tạm thời nó chưa phải là công cụ tốt nhất, bởi vì chỉ có như vậy, cuối cùng nó mới có cơ hội trở thành công cụ tốt nhất. Chúng tôi thường cố tình không cải thiện một số quy trình nội bộ, mà để sản phẩm tự trở nên tốt hơn, từ đó có thể hỗ trợ các quy trình này. Đây thực sự là một trạng thái rất khó chịu. Nhưng tuần này qua tuần khác, nó thực sự liên tục thay đổi.

Nếu Codex ra mắt sớm ba tháng, nó sẽ chết, điểm khác biệt duy nhất là mô hình đã tiến bộ

Lenny: Trong nhịp độ thay đổi nhanh như vậy, các anh làm kế hoạch thế nào? Nhìn xa bao nhiêu?

Andrew Ambrosino: Chúng tôi không có cách làm cách mạng nào trong việc lập kế hoạch. Nguyên tắc cơ bản là, càng gần hiện tại, kế hoạch càng cần cụ thể. Không phải không làm kế hoạch chín tháng, mà kế hoạch đó phải giữ rất mơ hồ. Bởi vì bất kỳ độ chính xác nào bạn thêm vào kế hoạch chín tháng hiện tại đều là độ chính xác giả, chỉ lãng phí thời gian.

Ở phía ứng dụng sản phẩm, những gì bạn lên kế hoạch vào tháng 11, đến tháng 12 có thể vẫn đúng, nhưng đến tháng 2 thì hoàn toàn không còn đúng nữa.

Ở công ty trước của tôi, khi chúng tôi bắt đầu dựa vào khả năng của mô hình để thúc đẩy phát triển tính năng, quy trình sản phẩm ban đầu về cơ bản đã sụp đổ. Sau đó chúng tôi liệt kê tất cả các hướng quan tâm, làm nguyên mẫu cho chúng, đánh giá cái nào hiện tại khả thi, rồi tạm gác những cái khác. Mỗi khi khả năng mô hình có bước nhảy vọt mới, chúng tôi lấy những thứ bị gác lại ra thử lại. Bởi vì tiền đề cuối cùng để một tính năng đủ tốt thường không phải là hình thái của chính tính năng đó, mà là liệu mô hình có đủ thông minh hay không. Nhiều người luôn không hài lòng với cách lập kế hoạch của tôi. Nhưng việc này thực sự rất khó.

Lenny: Có ví dụ cụ thể nào về tầm quan trọng của thời điểm không?

Andrew Ambrosino: Có một câu chuyện hay về Codex. Tôi rất chắc chắn rằng, ứng dụng Codex mà chúng tôi phát hành vào tháng 2, nếu đã sẵn sàng vào tháng 11 và phát hành, nó sẽ thất bại hoàn toàn trên thị trường. Điểm khác biệt duy nhất là mô hình đã tiến bộ từ tháng 11 đến tháng 2. Cùng một sản phẩm, cùng một hình thái hoàn toàn, kết quả hoàn toàn khác, chỉ chênh lệch vài tháng.

Lenny: Vậy những thứ không được bây giờ có thể được trong tương lai? Cần giữ tham vọng lớn hơn?

Andrew Ambrosino: Đúng vậy. Tôi khuyên mọi người đừng dễ dàng kết luận "cái này bây giờ không được, nên nó là tính năng xấu", nó có thể chỉ chưa tới thời điểm.

Quay lại lần phát hành đầu tiên của Codex, Codex web. Về cơ bản bạn giao cho mô hình một nhiệm vụ, nó làm, xong rồi quay lại cho bạn kết quả. Nghe không có gì cấp tiến, nhưng vấn đề là nó làm chưa đủ tốt, hình thái đó quá sớm.

Sau đó Claude Code ra mắt, hoàn toàn cục bộ, không kết nối đám mây, không giả vờ AGI. Nó hỏi bạn câu hỏi, nó đợi ở đó, bạn không thể giao phó cả cuộc đời cho nó. Nó tốt hơn nhiều, vì nó phù hợp với mức năng lực của mô hình lúc đó.

Chúng tôi lúc đó quá "AGI", tôi thường nghĩ về bài học này. Trước đây, sự thất bại của một sản phẩm trên thị trường thường nói cho bạn nhiều điều về hình thái sản phẩm hoặc cách truyền thông. Bây giờ khác rồi, bạn có thể cần phát hành cùng một thứ sáu lần, cho đến khi nó thành công, hình thái có thể hoàn toàn không đổi.

Trình duyệt trong ứng dụng cũng vậy. Chúng tôi từng có một phiên bản hoạt động được, trở lại thời kỳ Atlas, chúng tôi đã có agent thực hiện nhiệm vụ trong trình duyệt. Xa hơn nữa là Operator trong ChatGPT, cái đó không thành công. Nhưng nếu bạn nối Operator, Atlas, Codex và ChatGPT lại với nhau, bạn sẽ thấy giữa chúng thực sự có thể vẽ ra một lộ trình tiến hóa liên tục. Về bản chất là cùng một tính năng, chỉ là với mức độ thông minh thay đổi, nó được phát hành lại nhiều lần, và kết quả do đó thay đổi hoàn toàn.

Một khi sản phẩm hoặc tính năng đã tồn tại, mọi người dễ dàng tập trung vào các vấn đề chi tiết và tối ưu nhỏ, và họ thực sự nên làm vậy. Nhưng đó cũng là lý do tại sao chúng tôi luôn duy trì văn hóa khám phá từ dưới lên. Bởi vì đôi khi, giống như ứng dụng Codex từng lật đổ ChatGPT theo một cách nào đó, chính Codex trong tương lai cũng có thể bị lật đổ bởi những nỗ lực mới. Bạn không thể kỳ vọng cùng một nhóm vừa liên tục tạo ra những đổi mới mang tính đột phá, vừa luôn tập trung vào chất lượng sản phẩm và trau chuốt chi tiết. Ở một giai đoạn nào đó, bạn phải thiết kế một cơ chế để cả hai năng lực này có thể tồn tại đồng thời.

Lenny: Tầm nhìn của Codex là gì? Anh muốn đưa nó đến đâu?

Andrew Ambrosino: Vào tháng 1 và tháng 2 năm nay, trong quá trình tự kiểm tra nội bộ, chúng tôi phát hiện ra sự phù hợp rõ ràng giữa sản phẩm và thị trường (PMF) trong các workflow kỹ thuật và nghiên cứu. Nhưng đồng thời, những người trong bộ phận thị trường, truyền thông, tài chính, pháp lý cũng đều dùng Codex, dù ứng dụng này không thân thiện với họ, nó sẽ cho họ xem code, yêu cầu họ phê duyệt việc thực thi công cụ tìm kiếm dòng lệnh.

Chúng tôi đã thử thêm khả năng của Codex vào các sản phẩm khác, ứng dụng desktop ChatGPT, trình duyệt Atlas. Kết quả là điều phiền phức nhất đã xảy ra, không ai muốn rời khỏi ứng dụng Codex để dùng những sản phẩm được cho là được tạo ra riêng cho họ.

Điều này cho chúng tôi thấy, giữa công cụ dành cho nhà phát triển và công cụ làm việc tri thức tổng quát, thực sự có nhiều điểm chung tinh tế. Chúng tôi thực sự tin rằng, hình thái sản phẩm mà chúng tôi đang xây dựng là hình thái đúng đắn để mang lại các tình huống chuyên sâu theo chiều dọc. Bắt đầu đơn giản, sau đó tăng độ phức tạp khi cần.

Nó không phải là loại sản phẩm "vẽ một hình chữ nhật trên màn hình, và mọi thứ phải được thực hiện bên trong nó". Nó giống một căn cứ hơn, bạn bắt đầu làm việc ở đây, kết thúc công việc, quản lý quy trình tự động hóa, và nó sẽ gọi tất cả các công cụ bạn cần. Một số người gọi hình thái này là "super app", tôi ước gì họ đã không gọi như vậy, vì bây giờ tôi gần như phải nghe từ này mỗi ngày.

Dan Shipper có một ý tưởng rất thú vị, anh ấy nghĩ trong tương lai chúng ta sẽ sử dụng các công cụ SaaS "từ trong ra ngoài" trong Codex, Notion, Linear, Salesforce không phải bạn mở trong trình duyệt, mà agent sẽ thao tác chúng trong Codex. Chúng tôi cũng đang làm những điều này, trình duyệt trong ứng dụng, tiện ích mở rộng Chrome, computer use, tất cả đều là cách để Codex tương tác với các công cụ bên ngoài.

Một ví dụ điển hình nhất, nhà sản xuất video nội bộ Brent của chúng tôi đã dùng Codex để chỉnh sửa video phát hành của Codex. Codex không phải là trình chỉnh sửa video, không có giao diện người dùng đó. Nhưng nó hiểu Brent đang dùng Premiere Pro, và có thể thực hiện một số sửa đổi bằng cách chỉnh sửa các tệp đằng sau Premiere Pro. Khi nó thấy không thể làm mọi thứ, nó tự viết một tiện ích mở rộng cho Premiere Pro, cài đặt nó vào Premiere Pro, và sau đó giao tiếp với Premiere Pro thông qua tiện ích mở rộng đó. Khi thấy điều này, tất cả chúng tôi đều bị sốc.

Đây là một mô hình tốt, có công cụ chuyên nghiệp làm việc chuyên nghiệp. Codex không cần trở thành trình chỉnh sửa video tốt hơn, nó có thể tương tác liền mạch với các công cụ chuyên nghiệp là đủ.

Viết code không còn quan trọng, xóa code mới quan trọng

Lenny: Từ viết code tay đến AI viết 100% code, đến bây giờ là agents và loops. Các nhóm tiên tiến nhất hiện nay thực sự làm việc thế nào?

Andrew Ambrosino: Loops (vòng lặp)? Đó là chuyện của tuần trước.

Chúng tôi liên tục thảo luận về vấn đề "bao nhiêu phần trăm sản phẩm là code do AI viết". Theo tiêu chuẩn của năm ngoái, bây giờ 100% code của chúng tôi là do AI viết. Vì vậy câu hỏi không còn là "bao nhiêu do AI viết", mà là "code được viết dưới sự giám sát hay không có giám sát", đó là một chiều hoàn toàn khác. Tôi hoan nghênh việc tiêu chuẩn này liên tục được làm mới, vì điều đó có nghĩa là chúng tôi đang đạt được tiến triển về sản phẩm.

Chúng tôi đã khám phá nhiều về phát triển phần mềm tự chủ, ví dụ như rất nhiều kỹ thuật harness, như "Nếu mô hình tự động thu gom rác và dọn dẹp codebase vào ban đêm thì sao?"

Nhưng hiện tại tất cả các mô hình đều có một vấn đề, chúng luôn làm tăng độ phức tạp. Nếu những người làm nghiên cứu đang nghe: làm ơn, hãy dạy mô hình biết xóa code. Khi bạn cố gắng giao hoàn toàn việc phát triển cho chế độ lái tự động, đây trở thành một vấn đề nghiêm trọng, cả ở cấp độ con người lẫn cấp độ codebase.

Yêu cầu tính năng (feature requests) cũng vậy. Làm thế nào bạn dạy mô hình đánh giá tính năng nào đáng làm, cái nào nên bỏ qua, cái nào nên kết hợp và định nghĩa lại? Và làm thế nào dạy mô hình xây dựng các abstraction đúng?

Những khả năng này đều đang tiến bộ liên tục. Nhưng tôi không nghĩ chúng ta đã phát triển đến giai đoạn thiết lập một vòng lặp, để mô hình tự động "cải thiện ứng dụng", liên tục lắng nghe Twitter, Slack và email, sau đó tự hoàn thành vòng lặp. Mặc dù, chúng tôi thực sự đang cố gắng biến điều này thành hiện thực.

Lenny: Anh nghĩ chúng ta sẽ đến được bước đó không? Đặt một mục tiêu: "Thắng"?

Andrew Ambrosino: "/goal kiếm cho tôi một tỷ đô la." Tôi không biết. Tôi sẽ không nói không bao giờ hay luôn luôn thế nào.

Lenny: Anh là người phụ trách sản phẩm và kỹ thuật, anh tự dùng AI làm việc thế nào?

Andrew Ambrosino: Tôi nghĩ bây giờ tôi có lẽ có công việc tốt nhất thế giới.

Khi bắt đầu làm Codex, mục tiêu cá nhân của tôi là làm cho nó đủ tốt để tôi có thể dùng nó viết code cho Codex. Đó là một vòng lặp sản phẩm tự dùng siêu chặt chẽ, tôi không thể làm một việc gì đó, sửa nó, rồi tôi có thể làm, rồi có thể làm nhiều hơn.

Sau đó vai trò của tôi thay đổi. Tôi cần làm nhiều việc khám phá sản phẩm hơn, tìm hiểu nhóm đang làm gì, điều chỉnh những thứ đi sai hướng. Vì vậy Codex trở thành công cụ để tôi làm những việc này. "Giúp tôi xây dựng một bảng tính tổng hợp dữ liệu này." "Giúp tôi làm một nghiên cứu chuyên sâu nội bộ, xem trước đây đã có những khám phá nào theo hướng này."

Loạt phát hành tháng 5, trình duyệt trong ứng dụng, computer use, tạo artifact (artifact creation), đó là lần đầu tiên chúng tôi dùng vibe coordination (phối hợp theo cảm hứng) để quản lý phát hành. Tôi có một tài liệu Notion ghi lại tất cả các việc cần làm, sau đó dùng Codex tự động đi PR, kênh Slack để thu thập tiến độ, cập nhật trình theo dõi trạng thái, lúc đó cảm thấy đó là cách tiên tiến nhất để quản lý phát hành sản phẩm.

Bây giờ mỗi sáng tôi dậy, tôi xem báo cáo hàng ngày do Codex tạo ra, lọc ra những việc cần tôi quan tâm từ 3000 kênh Slack tôi đã tham gia. Tôi có thể trả lời "Đưa tôi năm câu hỏi, tôi sẽ trả lời." Nó tự điều chỉnh, tôi nói "Lần chạy sau, bớt chú ý workflow này" hoặc "Việc này đã xảy ra nhưng không xuất hiện trong báo cáo hàng ngày, đảm bảo lần sau bắt được", nó cập nhật cách thông báo, điều chỉnh trọng tâm chú ý.

Lenny: Việc này được thiết lập thế nào? Workflow là gì?

Andrew Ambrosino: Hiện tại vẫn ở giai đoạn khám phá. Chỉ là tạo một tác vụ định kỳ: "Lướt qua các kênh Slack của tôi, đây là những việc tôi quan tâm, sắp xếp theo các danh mục này, đây là một số ngữ cảnh." Vài lần chạy đầu có thể cần hướng dẫn. May mắn là tôi không cần phải tìm cách chỉnh sửa hướng dẫn, tôi trực tiếp nói "Lần sau giúp tôi sửa cái này", nó cập nhật.

Nhưng tôi nghĩ đó cũng là vấn đề cốt lõi của hình thái chatbot, tôi biết cách thiết lập vì với tôi đây là khám phá sản phẩm. Nhưng nếu bạn không làm việc ở OpenAI, không phát triển thứ này, bạn sẽ không muốn tìm hiểu những điều này. Chúng tôi cần nghĩ ra cách làm cho nó có thể sử dụng được cho người bình thường.

Lenny: Tôi cũng tự dùng Codex để làm một automation lọc thư rác. Trong đó có một bước phải vào bảng điều khiển Google Cloud để thiết lập một loạt API trigger, giao diện đó rất khó chịu. Tôi bảo Codex làm giúp, nó trực tiếp chiếm máy tính của tôi, sử dụng computer use để thao tác.

Andrew Ambrosino: Nó kiểu: "Tôi không quan tâm bạn có connector hay không, anh bạn, tôi bắt đầu click trực tiếp."

Việc phân chia ranh giới giữa connector, trình duyệt trong ứng dụng, tiện ích mở rộng Chrome và computer use là một điều rất thú vị. Nhiều khi, những ranh giới này thực sự được mò mẫm.

Tôi nghĩ những workflow cá nhân này rất thú vị. Mọi người đều đang thử nghiệm đủ thứ, mỗi người sẽ xây dựng các hệ thống hoàn toàn khác nhau. Nhưng dần dần, một số mẫu chung sẽ nổi lên. Và rồi chúng tôi sẽ nhận ra: "Cái này nên trở thành trải nghiệm cấp một trong sản phẩm."

Ví dụ như memory (bộ nhớ), nhiều người thiết lập kho tri thức Obsidian hoặc không gian Notion để xây dựng cung điện tâm trí của riêng mình. Bạn không nên tự làm việc này, nên có một chức năng memory đủ tổng quát làm thay bạn. Chúng tôi liên tục sàng lọc, cái gì hiệu quả với cá nhân nhưng nên giữ ở cấp độ cá nhân, cái gì nên vào sản phẩm trở thành thành phần cơ bản.

Lenny: Bên ngoài nhìn vào, mọi người thấy anh toàn thắng. Nhưng chắc chắn có lúc mọi thứ không thành công?

Andrew Ambrosino: Nghe anh mô tả thật buồn cười. Đây thực sự là lần đầu tiên tôi cảm thấy mình không thất bại.

Tôi đã khởi nghiệp nhiều năm, cuối cùng cơ bản là tháo dỡ công ty và bán đi. Làm việc trong các ngành có quy định cao, toàn bộ quá trình giống như thất bại liên tục. Sau đó đến một công ty khởi nghiệp khác, làm công cụ AI trong một ngành đóng kín có quy định khác, cũng nhiều lần không được. Tôi thực sự đã thất bại nhiều. Đôi khi chỉ là một điểm thời gian, kỹ năng, nhiệt huyết và cửa sổ thị trường tình cờ trùng khớp.

Ngay cả trong dự án kết hợp Codex và ChatGPT này, cũng có vô số thất bại nhỏ. Chúng tôi nói "nên trông thế này", gửi lên Slack, bên dưới là 2000 tin nhắn nói chúng tôi ngu ngốc thế nào. Đây là điểm tôi thích OpenAI, mọi người nói trực tiếp với chúng tôi, không khoan nhượng với thất bại của sản phẩm nội bộ, đó cũng là lý do tại sao sản phẩm bên ngoài làm tốt. Tôi đã thất bại khoảng 10 đến 15 năm trước khi đến được vị trí hiện tại. Vì vậy mỗi ngày tôi vẫn còn hơi ngạc nhiên, mọi việc đang diễn ra suôn sẻ.

Lenny: Có lời khuyên cuối cùng cho độc giả không?

Andrew Ambrosino: Đừng "ràng buộc suốt đời" với workflow hiện tại của bạn. Điều thực sự nên giữ vững, là những kết quả chỉ có bạn mới có thể mang lại một cách độc đáo. Sau đó, liên tục cố gắng thay đổi workflow của bạn. Nếu kỹ năng bạn tự hào nhất là "tôi hiểu rõ nhất auto layout của Figma", thì bạn đang làm gì? AI cũng sẽ trở nên giỏi hơn bạn. Tìm ra những việc đáng làm, và sau đó tìm cách làm những việc đó.