Người phụ trách Codex: "Mọi người đều là builder" là một ý tưởng rất tồi tệ
Tuyển chọn TechFlowTuyển chọn TechFlow
Người phụ trách Codex: "Mọi người đều là builder" là một ý tưởng rất tồi tệ
Làm sản phẩm AI còn cần PM không? Nếu cần thì PM thời đại AI cần làm gì?
Chuyên sâu báo cáo Web3Tác giả: Founder Park
Andrew Ambrosino là trưởng nhóm OpenAI Codex. Xuất thân là nhà thiết kế, từng làm kỹ sư, cũng từng làm sản phẩm, và cũng từng khởi nghiệp, hiện tại Codex do anh 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 «Sản phẩm trong kỷ nguyên AI nên được xây dựng như thế nào».
Theo anh, khi hầu hết mọi người trong công ty đều có thể nhanh chóng xây dựng một nguyên mẫu tính năng, vấn đề thực sự không còn là «có làm được hay không», mà là «có nên làm cái này hay không».
Trong cuộc đối thoại với Lenny, Andrew Ambrosino đã giới thiệu chi tiết quy trình phát triển nội bộ của OpenAI: Khi chi phí thực hiện bị AI nén lại đáng kể, mọi khâu trong phát triển sản phẩm, từ khởi động dự án, tài liệu, nguyên mẫu, thiết kế đến phân vai, 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 việc thực hiện không còn khan hiếm, đâu mới là nguồn lực thực sự khan hiếm?
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 như sẵn sàng ra mắt, thứ quý giá nhất chính là gu thẩm mỹ (taste).
- Một trong những tiêu chuẩn cứng khi tuyển dụng vào nhóm Codex là gu thẩm mỹ, khả năng phân biệt tín hiệu và nhiễu giữa海量 nội dung. Trong một thế giới «sở hữu vô hạn tokens», họ không muốn sản xuất nội dung rác.
- Nếu Codex ra mắt sớm hơn 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 phán định một tính năng là không tốt, có thể nó chỉ chưa đến thời điểm.
- Điều kiện tiên quyết để một tính năng cuối cùng có đủ tốt hay không thường không phải là hình thái của bản thân tính năng, mà là mô hình có đủ thông minh hay không.
- Giống như Codex từng颠覆 ChatGPT, Codex cũng có thể bị những thử nghiệm mới颠覆. Cần giữ văn hóa khám phá từ dưới lên, không thể指望 cùng một đội ngũ vừa mài giũa chi tiết vừa颠覆 chính mình.
Dưới đây là những nội dung tinh hoa của cuộc đối thoại.
Chi phí thực hiện giảm xuống, taste trở nên quan trọng hơn
Lenny: Bạn từng nói AI đang thay đổi hình thái của công việc sản phẩm. Bạn hiện đang làm việc tại có lẽ là đội ngũ sản phẩm AI tiên phong nhất toàn cầu. Cụ thể, cách làm việc của đội ngũ sản phẩm có gì thay đổi so với hai năm trước?
Andrew Ambrosino: Hiện tại với tư cách là trưởng nhóm, điều khó khăn nhất là quy trình đã bị đảo ngược.
Cách làm sản phẩm trước đây, mọi người đều quen thuộc: trước hết nghiên cứu, đưa ra ý tưởng, làm nguyên mẫu. Ngay cả khi chúng ta đã qua thời đại phát triển mô hình thác nước (waterfall), logic cơ bản vẫn như vậy, việc thực hiện rất đắt đỏ. Vì vậy, trước khi thực hiện, bạn phải loại bỏ mọi rủi ro thông qua tài liệu, nghiên cứu, nguyên mẫu. Vì nguyên mẫu và thiết kế rẻ hơn phát triển, đây là giả định cơ bản của quá khứ.
Giờ giả định này đã thay đổi hoàn toàn, bất kỳ ai cũng có thể làm ra bất kỳ thứ gì. Tôi thực sự tin rằng, bạn bắt đầu từ con số 0 và đối thoại 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ể xây dựng 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确实 rất thú vị.
Bạn trao cho mọi người vô hạn tokens, mọi người tại OpenAI đều rất chủ động, đều có ý tưởng hay. Vì vậy mọi người đều đang làm đủ thứ thứ. Giờ trong công ty có một tính năng chúng tôi急需 làm, tôi tin chắc đồng thời có 90 đội nhóm nhỏ khác nhau, chưa phối hợp, đang各自 thực hiện và thử nghiệm. Trong 90 lần thử nghiệm đó, cái nào là tốt? Nên gập những phần nào vào các khía cạnh khác? Nên định nghĩa nó như thế nào? Nó có nên là một phần của một tính năng khác không? Trong công tắc nên có vài tùy chọn? Chính là những chuyện này.
Vì vậy câu trả lời ngắn gọn là: đã đả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. Việc thực hiện không còn là phần đắt đỏ nhất nữa, tôi dám nói một câu, thứ đắt đỏ nhất là gu thẩm mỹ (taste).
Lenny: Vậy trước đây mọi người sẽ viết PRD, tài liệu chiến lược, 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ự, liền xuất hiện 90 thứ khác nhau, rồi từ đó chọn hướng đi?
Andrew Ambrosino: Đúng, chuyện này xảy ra rất nhiều. Không chỉ ở OpenAI, bạn đã thấy nhiều trưởng nhóm sản phẩm nói «PRD đã chết, nguyên mẫu lên ngôi», nhưng tôi thực ra hoàn toàn không đồng ý với quan điểm này.
Bởi vì việc thực hiện đã trở nên rẻ trên mọi phương tiện, việc bỏ qua suy nghĩ và trực tiếp làm nguyên mẫu trở nên rất hấp dẫn. Đặc biệt nếu bạn không phải kỹ sư, nếu bạn chưa từng viết code, không có hứng thú hoặc không có thời gian, bạn sẽ忍不住 nói: «PRD đã chết, để tôi trực tiếp cho bạn xem 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 kỹ sư, việc viết大量 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. Không phải nói người viết tài liệu không tốt, mà là khi việc thực hiện trở nên dư thừa, việc chọn đúng định dạng để biểu đạt quan điểm của bạn, trở nên thực sự quan trọng.
Nếu bạn muốn biểu đạt một sự rõ ràng về sản phẩm trong một lĩnh vực mơ hồ,那确实 nên viết tài liệu. Nếu bạn muốn mọi người bắt tay vào dùng thử, stress test một模式 tương tác,那就 làm nguyên mẫu. Chìa khóa là chọn đúng phương tiện.
Lenny: Có một khái niệm gọi là primal mark (dấu ấn nguyên thủy), nét vẽ đầu tiên của họa sĩ trên canvas, mọi thứ sau đó đều延伸 ra từ nét đó. Ý bạn là, đôi khi nguyên mẫu là nét vẽ đầu tiên sai lầm? Vì mọi người sẽ neo vào đó, thay vì nghĩ đến方案 lớn hơn?
Andrew Ambrosino: Đúng. 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 như sản phẩm chính thức上线, có nghĩa là nó đã ở giai đoạn cuối, rủi ro đã được loại bỏ, thiết kế đã xem qua, mục tiêu kinh doanh là hợp lý.
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充分, giờ ngưỡng này không còn. Vì vậy một thứ vốn chỉ là giai đoạn khám phá, trông đã có thể上线, 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 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业务.
Không phải muốn nhấn mạnh quá mức chuyện gu thẩm mỹ. Nhưng nói lại một lần nữa, biết nên làm gì, trình bày như thế nào, đạt mục tiêu ra sao, dùng phương tiện gì, đang trở thành năng lực quan trọng nhất trong mọi lĩnh vực.
Lenny: Từ gu thẩm mỹ giờ là một từ流行. Cụ thể, «gu thẩm mỹ tốt» mà bạn nói rốt cuộc là gì?
Andrew Ambrosino: Gu thẩm mỹ phải 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 đặt trong toàn bộ hệ thống như thế nào; có phần định hướng, chúng ta đi đâu, việc này là một phần của chủ đề nào; có phần biểu đạt, trình bày thông tin này ra sao; còn một phần gu thẩm mỹ là ở mức độ 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á gấp gáp, không khớp với ý nghĩa nó muốn biểu đạt.
Những này确实 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ứ, mục tiêu là gì? Làm sao đến đó?
Lenny: Khi AI ngày càng mạnh, làm ngày càng nhiều việc, não bộ con người sẽ còn giá trị ở những đâu? Gu thẩm mỹ cảm giác là một trong số đó. Nhưng đầu ra thiết kế của AI vẫn chưa ổn, tại sao các mô hình đỉnh cao không làm tốt thiết kế?
Andrew Ambrosino: Có một số lý do thực tế, cũng có một số vấn đề khó giải quyết hơn. Thiết kế khó chấm điểm hơn phần mềm, tạo một vòng lặp 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ó biên dịch được 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, trong lịch sử phòng thí nghiệm ưu tiên để mô hình giỏi những thứ có thể tăng tốc nghiên cứu AI. Mô hình có thể viết code đúng显然 có thể tăng tốc nghiên cứu, thiết kế thì không thể làm 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 flywheel đó.
Đâ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ó搞定 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 website mới đều sao chép thiết kế của Linear. Nếu mô hình mỗi lần đều xuất ra website của Linear, đó không phải là thách thức. Mức độ quan trọng của sự mới mẻ 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恨不得 mô hình hoàn toàn theo模式 đã biết, nhưng thiết kế cần một mức độ ngẫu nhiên và mới mẻ nhất định.
Thứ hai, là sự tương tác giữa thiết kế trực quan và code. Nếu ngày mai công ty đổi thương hiệu, cách làm nông cạn là cập nhật từng cái một 263 component. Cách làm sâu sắc là hiểu hai thứ trông khác nhau này, thực ra đều thuộc một kiểu danh sách, truyền tải cùng một模式 tương tác. Lớp trừu tượng này, kỹ thuật hiện tại còn với không tới.
Lenny: Jenny Wen (trưởng nhóm thiết kế Anthropic Claude Code) nói quy trình thiết kế đã chết, trực tiếp xây dựng là được, bạn nghĩ sao?
Andrew Ambrosino: Tôi và Jenny có thể nhất trí ở nhiều chuyện. Quy trình thiết kế chính quy, tôi đồng ý với cô ấy, nó chết rồi. Và tôi trước cả khi có AI cũng không phải fan của quy trình đó.
Nhiều năm trước khi tôi làm startup, có một bài viết gọi là «Nhà máy nghiên cứu điển hình», nói chính là designer được huấn luyện để tuân theo một quy trình cố định, và dần dần coi chính quy trình này quan trọng hơn kết quả. Nếu một thứ trải qua quy trình này, 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,即使没人用，nó cũng tốt, vì nó đã đi qua quy trình.
Nghiên cứu người dùng, phân kỳ, hội tụ, khung là đúng, nhưng luôn hơi mang tính học thuật. Tiền đề của quy trình đó là việc thực hiện rất đắt, bạn chỉ xây得起 một lần, vì vậy phải trước khi làm穷尽 mọi không gian vấn đề và không gian giải pháp.
Sau này Figma và Origami xuất hiện, chúng ta kéo nguyên mẫu tương tác vào quy trình. Vấn đề giờ là, bạn có thể kéo toàn bộ việc thực hiện lên đầu quy trình. Một nguyên mẫu hoàn toàn tinh tế, trông có thể trực tiếp上线. Đủ nhiều người trong công ty看到 sau đó liền hỏi: «Giờ chúng ta có thể phát hành 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 rõ.
Vì vậy nói quy trình thiết kế chết, vừa đúng vừa không đúng. Nếu bạn绑定 vào công cụ cụ thể và thao tác hàng ngày cụ thể,那 nó确实 chết rồi. Nhưng nhận thức «chúng ta đang ở giai đoạn nào của quy trình» này, quan trọng hơn bất cứ lúc nào.
绑定 quy trình thiết kế vào phương tiện cụ thể, đó mới là chỗ nguy hiểm. Designer giờ có nhiều công cụ hơn, bạn có thể trực tiếp đưa thứ vào sản phẩm hiện có, có thể làm A/B testing. Nhiều công ty đều có phiên bản baby của sản phẩm, baby Cursor, baby Codex, một codebase大幅 giản hóa, có thể mô phỏng mọi tương tác của sản phẩm chính thức. Bạn có thể拿 nó来 vibe code (lập trình theo cảm xúc), nói «Nếu sidebar变成 thế này thì sao? Nếu pop up một panel thì sao?» Đây là công cụ mới của designer, nhưng nó cần phối hợp với nhận thức cũ: bạn đang ở vị trí nào trong quy trình.
Vị trí và vai trò đang hợp nhất, nhưng PM sẽ không biến mất
Lenny: Nhiều công ty đang nói «vai trò tiêu vong». Bạn nghĩ sự phân công PM, kỹ sư, designer sẽ hoàn toàn biến mất không?
Andrew Ambrosino: Một số công ty rất thích đuổi theo xu hướng, đi cực đoan. 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 «những lĩnh vực này là chuyên môn có best practice để họ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ĩ đây là một ý tưởng rất tệ, rồi nói «mỗi người đều là builder». Kết quả là quản lý sản phẩm này vốn đã tích lũy true best practice, thực sự từng gặp hố, bị trực tiếp vứt bỏ. Vì có người viết vài dòng code,就觉得万事大吉, đó không phải trạng thái tốt.
Tôi欢迎 «đây không phải lĩnh vực của bạn, bạn không được碰» loại ranh giới này 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 việc,不论是从广度还是深度来说，đây cũng là lý do tại sao manager sẽ không biến mất.
Và mỗi学科 đều có thành phần kỹ năng. Nhiều kỹ sư không thừa nhận điểm này,觉得 kỹ thuật là có kỹ năng, các vai trò vị trí khác đều là «cảm xúc». Không phải vậy, bạn biết dùng Excel không đại diện bạn có thể đi làm việc ở đội ngũ tài chính.
Tôi nghĩ giờ đang xảy ra nhiều hơn là, mọi người hợp tác跨 vai trò trở nên dễ dàng hơn, học best practice của lĩnh vực khác cũng trở nên dễ dàng hơn, không cần绑定 hiệu suất của bạn ở một vai trò nào đó với khả năng sử dụng công cụ cụ thể.
Tôi đã spent rất nhiều thời gian cảm thấy mình không nên làm software engineer, vì tôi không quan tâm assembly language, cũng không muốn nhớ type system của TypeScript. Những vai trò này luôn tồn tại một số ngưỡng,仿佛 «làm tốt vai trò này bằng với thành thạo công cụ này». Tôi nghĩ cái này đang bắt đầu tan rã, nhưng mọi người phóng đại nó.
Lenny: Trong đội ngũ Codex của các bạn确实 có nhiều vai trò hợp nhất hơn, cụ thể là như thế nào?
Andrew Ambrosino: Trong đội ngũ Codex của chúng tôi,确实 thấy nhiều vai trò hợp nhất hơn so với các đội ngũ khác trong công ty và các ngành khác. Một phần lý do là, đây là một sản phẩm công nghệ hướng đến kỹ sư. Vì vậy designer của chúng tôi nói ngôn ngữ của kỹ sư, product manager của chúng tôi nói ngôn ngữ kỹ thuật, biết viết code.
Chúng tôi nội bộ có một cách mô tả cách hợp tác: Giờ sự chồng chéo giữa các vai trò lớn hơn nhiều so với quá khứ. Định nghĩa một người, không còn nhìn vào ranh giới trách nhiệm «thiết kế kết thúc ở đâu, kỹ thuật bắt đầu từ đâu» như vậy, mà nhìn vào phân bố trung bình của toàn bộ nội dung công việc của anh ta.
Nếu trải ra xem toàn bộ những việc một người nào đó trong đội ngũ thiết kế làm, trong đó có thể chứa大量 công việc viết code, cũng chứa大量 công việc liên quan sản phẩm. Nhưng lấy một «giá trị trung bình» của những công việc này, anh ta cuối cùng vẫn sẽ rơi vào một khu vực thiên về thiết kế nào đó.
Lenny: Bạn提到 công việc của product manager giống như zone defense (phòng thủ khu vực), cụ thể là ý gì?
Andrew Ambrosino: Nếu hai product manager hợp tác quá chặt chẽ, thường không phải tín hiệu tốt. Bạn nên giống như force-directed layout mà展开 đội ngũ ra xem, chỗ nào tồn tại khoảng trống, chỗ nào chưa có người cover?
Trong thế giới hôm nay, curation, dẫn dắt và alignment trở thành công việc quan trọng nhất. Mỗi người đều không ngừng ném ra ý tưởng, toàn bộ môi trường đầy noise, cách làm từ trên xuống dưới, lập kế hoạch theo năm trước đây đã không còn hiệu quả. Chúng ta cần có người làm gatekeeper của gu thẩm mỹ, dẫn dắt một việc từ concept走向 sản phẩm, mà điều này có nghĩa là bạn phải cover mọi ngóc ngách của công ty.
Vì vậy, bạn cần trải đội ngũ ra xem, ai giỏi cái gì? Để彼此 giữ một khoảng cách nhất định, đảm bảo độ cover đủ toàn diện. Rồi sau đó đi 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 rất mạnh.» Chúng tôi không希望 xuất hiện tình huống này, một nhóm người trước viết ra大量 code, cuối cùng còn cần toàn bộ đội ngũ sản phẩm来审核 và校准 sự nhất quán của sản phẩm. Chúng tôi希望 mỗi người đều具备 những năng lực này, chỉ là hướng đi nghiên cứu sâu của各自 cần thay đổi.
Lenny: Vậy giờ người có giá trị nhất, là người có thể từ ý tưởng đến hoàn thành toàn程 thúc đẩy, và có gu thẩm mỹ biết «cái này rất tuyệt»?
Andrew Ambrosino: Đúng, tôi nghĩ đây chính là thay đổi cốt lõi nhất hiện nay. Đ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 (individual contributor) và manager. Không phải management sẽ biến mất, cũng không phải mỗi người chỉ là IC, mà là giờ mỗi người ở một mức độ nào đó đồng thời đảm nhận cả hai vai trò này.
Nếu bạn là IC, bạn đã không còn gõ code từng ký tự một. 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 để cùng hoàn thành nhiệm vụ. Nếu bạn là team manager, về bản chất làm cũng là chuyện tương tự, chỉ là granularity quản lý khác nhau.
Tôi thường tìm kiếm người, ngoài具备 năng lực chuyên môn vững vàng, còn phải có gu thẩm mỹ. Vì trong một thế giới «sở hữu vô hạn tokens», chúng tôi không thể sản xuất nội dung rác. Bạn phải具备 năng lực phân biệt tín hiệu và nhiễu từ海量 nội dung.
Mỗi lần có người hỏi đội ngũ Codex có bao nhiêu người, câu trả lời của tôi đều là: «Khoảng giữa 10 đến vài nghìn người.» Nghe như một câu đùa, nhưng thực tế, công việc của 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, personality mô hình, infrastructure frontend, trải nghiệm người dùng, tất cả đều cấu thành một phần của sản phẩm.
Nhưng đồng thời, chúng tôi cũng không phải mỗi ngày đều接收 vài nghìn người submit PR (code commit request). Đội ngũ có quy mô kỹ sư hai con số, số lượng designer khoảng một nửa kỹ sư, cộng thêm vài product manager,绝大多数 người đều là IC. Phạm vi ảnh hưởng của đội ngũ rất lớn, nhưng层级 management không dày. Ở đây có rất nhiều người từng sáng lập công ty, cũng có rất nhiều người làm việc với «tâm thế founder» trong các công ty lớn, còn có rất nhiều người có gu thẩm mỹ cực tốt.
Toàn bộ ứng dụng Codex đều được塑造 bởi vòng lặp dogfooding. Tất cả chúng tôi đều có một nguyện vọng chung,尽可能 nhiều hoàn thành công việc của mình trong ứng dụng,即使 nó tạm thời chưa phải công cụ tốt nhất, vì chỉ có như vậy, nó cuối cùng mới có cơ hội trở thành công cụ tốt nhất. Chúng tôi thường cố ý 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ể support những quy trình này. Đây thực ra là một trạng thái rất không thoải mái. Nhưng tuần này qua tuần khác, nó确实 đang liên tục thay đổi.
Codex ra mắt sớm ba tháng sẽ chết, khác biệt duy nhất là mô hình tiến bộ
Lenny: Trong nhịp độ mọi thứ thay đổi nhanh như vậy, các bạn làm kế hoạch như thế nào? Nhìn xa bao nhiêu?
Andrew Ambrosino: Chúng tôi không có cách làm revolutionary nào trong kế hoạch. Nguyên tắc cơ bản là, việc càng接近 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à là kế hoạch đó phải giữ rất mơ hồ. 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 sản phẩm ứng dụng, những thứ bạn có thể 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 phải chuyện đó.
Ở công ty trước của tôi, khi chúng tôi bắt đầu dựa vào năng lực mô hình để drive phát triển tính năng, quy trình sản phẩm原有 cơ bản sụp đổ. Sau đó变成 liệt kê hết mọi hướng đi感兴趣, làm nguyên mẫu cho chúng, phán đoán cái nào giờ đã khả thi, rồi tạm thời搁置 những cái khác. Mỗi khi năng lực mô hình xuất hiện bước nhảy mới, liền lấy những thứ bị搁置 đó ra thử lại一遍. Vì một tính năng cuối cùng có đủ tốt hay không, tiền đề thường không phải là hình thái của bản thân tính năng, mà là mô hình rốt cuộc có đủ thông minh hay không. Rất nhiều người luôn cảm thấy bất mãn với cách kế hoạch của tôi. Nhưng chuyện này确实 rất khó.
Lenny: Có ví dụ cụ thể nào說明 thời điểm quan trọng thế nào không?
Andrew Ambrosino: Về Codex có một câu chuyện rất hay. Tôi rất chắc chắn, ứng dụng Codex mà chúng tôi phát hành vào tháng 2, nếu tháng 11 đã sẵn sàng mà phát hành, nó sẽ thất bại hoàn toàn trên thị trường. Khác biệt duy nhất là giữa tháng 11 đến tháng 2 mô hình tiến bộ了. Cùng một sản phẩm, hình thái hoàn toàn giống nhau, kết quả hoàn toàn khác, chỉ chênh vài tháng.
Lenny: Vậy giờ không được的东西 sau này có thể được? Cần giữ tham vọng lớn hơn?
Andrew Ambrosino: Đúng. Tôi recommend mọi người đừng dễ dàng认定 «thứ này giờ không được, nên nó là một tính năng xấu», nó có thể chỉ là chưa đến 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 task, nó đi làm, làm xong quay lại đưa bạn kết quả. Nghe không radical, nhưng vấn đề là nó làm không đủ tốt, hình thái đó quá超前.
Sau đó Claude Code xuất hiện, hoàn toàn local, không连云端, không giả vờ mình đa AGI. Nó sẽ hỏi bạn câu hỏi, sẽ đứng đó đợi, bạn không thể ủy thác toàn bộ nhân sinh cho nó. Nó好用太多了, vì nó khớ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ĩ bài học này. Quá khứ, một sản phẩm thất bại trên thị trường, thường có thể cho bạn biết rất nhiều về vấn đề hình thái sản phẩm hoặc cách truyền thông. Giờ không一样了, bạn có thể cần phát hành cùng một thứ sáu lần,直到 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 là tình huống như vậy. Chúng tôi từng có một phiên bản có thể hoạt động, quay lại thời kỳ Atlas, chúng tôi đã có agent thực thi task trong trình duyệt. Trước đó nữa là Operator trong ChatGPT, cái đó không thành công. Nhưng nếu nối Operator, Atlas, Codex và ChatGPT lại xem, bạn sẽ phát hiện giữa chúng thực ra có thể vẽ ra một tuyến đường演进 liên tục. Về bản chất là cùng một tính năng, chỉ là随着 mức độ thông minh thay đổi,被 liên tục phát hành lại, mà kết quả cũng vì thế彻底 thay đổi.
Một khi một sản phẩm hoặc tính năng đã tồn tại, mọi người dễ dàng tập trung sự chú ý vào各种 vấn đề chi tiết và micro-optimization, và họ确实 nên làm như vậy. Nhưng đây cũng là lý do tại sao chúng tôi luôn giữ một văn hóa khám phá từ dưới lên. Vì đôi khi, giống như ứng dụng Codex từng以 một cách nào đó颠覆 ChatGPT, bản thân Codex trong tương lai cũng có thể bị những thử nghiệm mới颠覆. Bạn không thể指望 cùng một đội ngũ vừa liên tục sản xuất đổi mới颠覆 tính, vừa luôn tập trung vào chất lượng sản phẩm và mài giũa chi tiết. Ở một giai đoạn nào đó, bạn phải thiết kế một cơ chế, để hai loại năng lực này có thể cùng tồn tại.
Lenny: Tầm nhìn của Codex là gì? Bạn muốn đưa nó đi đâu?
Andrew Ambrosino: Tháng 1 và tháng 2 năm nay, trong quá trình testing nội bộ自用, chúng tôi phát hiện trên workflow engineering và research đã hình thành PMF rất rõ ràng. Đồng thời, người của market, truyền thông, tài chính, pháp lý cũng đều đang dùng Codex,即使 ứng dụng này đối với họ không thân thiện, nó sẽ hiển thị code cho họ, để họ phê duyệt việc thực thi của công cụ tìm kiếm command line.
Chúng tôi thử thêm năng lực 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à chuyện phiền phức nhất xảy ra, không ai愿意 rời khỏi ứng dụng Codex, để đi dùng những sản phẩm được cho là专门打造 cho họ.
Điều này cho chúng tôi启示 là, giữa công cụ developer và công cụ kiến thức chung, thực ra tồn tại rất nhiều điểm chung tinh tế. Chúng tôi确实 tin, hình thái sản phẩm mà chúng tôi đang xây dựng, là hình thái đúng để承载各种 kịch bản vertical sâu. Bắt đầu từ đơn giản, rồi theo nhu cầu dần dần tăng độ phức tạp.
Nó không phải loại sản phẩm «vẽ một hình chữ nhật trên màn hình, rồi mọi chuyện đều phải hoàn thành trong đó». Giống một đại bản doanh 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 automation, mà nó sẽ gọi mọi công cụ bạn cần. Có người gọi hình thái này là «super app», tôi thực sự希望 họ lúc đó đừng gọi như vậy, vì giờ tôi hampir mỗi ngày đều phải nghe từ này.
Dan Shipper có một ý tưởng rất thú vị, anh ấy nghĩ tương lai chúng ta sẽ sử dụng công cụ SaaS «từ trong ra ngoài» trong Codex, Notion, Linear, Salesforce đều không phải là thứ bạn mở trong trình duyệt, mà là agent trong Codex giúp bạn thao tác. Chúng tôi cũng确实 đang làm những thứ này, trình duyệt trong ứng dụng, Chrome extension, computer use, tất cả đều là cách để Codex có thể tương tác với công cụ bên ngoài.
Một ví dụ tốt nhất, người làm video nội bộ của chúng tôi Brent dùng Codex để剪辑 video phát hành của Codex. Codex không phải là video editor, không có những UI đó. Nhưng nó hiểu Brent đang dùng Premiere Pro, có thể thông qua chỉnh sửa file đằng sau Premiere Pro để làm một số sửa đổi. Khi nó phát hiện không thể làm mọi thứ, nó tự viết một Premiere Pro extension plugin, cài vào Premiere Pro, rồi thông qua plugin này đối thoại với Premiere Pro. Khi thấy cái này chúng tôi đều shock.
Đây là một模式 rất tốt, có công cụ chuyên nghiệp làm chuyện chuyên nghiệp. Codex không cần trở thành video editor tốt hơn, nó có thể tương tác seamless với công cụ chuyên nghiệp là được.
Biết viết code không quan trọng nữa, biết xóa code mới quan trọng
Lenny: Từ viết code tay đến AI viết 100% code,再到 giờ là agents và loops. Đội ngũ tiên phong nhất giờ rốt cuộc làm việc như thế nào?
Andrew Ambrosino: Loops (vòng lặp)? Đó là chuyện của tuần trước rồi.
Chúng tôi luôn thảo luận «sản phẩm có bao nhiêu phần trăm là code do AI viết»这个问题. Dùng tiêu chuẩn của năm ngoái mà xem, giờ 100% code của chúng tôi đều là do AI viết. Vì vậy vấn đề không còn là «bao nhiêu là do AI viết», mà là «code được viết dưới sự giám sát hay không giám sát», đây là một chiều hoàn toàn khác. Tôi欢迎 tiêu chuẩn này không ngừng被刷新, vì điều này có nghĩa là chúng tôi đang取得 tiến bộ sản phẩm.
Chúng tôi đã làm rất nhiều khám phá trong phát triển phần mềm autonomous, ví dụ rất nhiều harness engineering, ví dụ «nếu mô hình tự động làm garbage collection và dọn dẹp codebase vào ban đêm thì sao?»
Nhưng hiện tại tất cả mô hình đều có một vấn đề, chúng luôn luôn tăng độ phức tạp. Nếu người làm research đang nghe: làm ơn, hãy để mô hình học cách xóa code吧. Khi bạn thử giao phó hoàn toàn việc phát triển cho autopilot, đây liền trở thành một vấn đề nghiêm trọng,不论 là ở mức độ con người hay ở mức độ codebase.
Feature requests (yêu cầu tính năng) cũng như vậy. Bạn nên làm thế nào để dạy mô hình phán đoán những tính năng nào đáng làm, những cái nào nên bị bỏ qua, những cái nào nên merge rồi định nghĩa lại? Lại nên làm thế nào để dạy mô hình xây dựng abstraction đúng?
Những năng lực này đều đang liên tục tiến bộ. Nhưng tôi không nghĩ chúng ta đã phát triển đến giai đoạn như vậy, setting một vòng lặp, để mô hình tự động «cải thiện ứng dụng», liên tục listen Twitter, Slack và email, rồi tự chủ hoàn thành iteration. Tuy nhiên, chúng tôi确实 đang thử biến chuyện này thành hiện thực.
Lenny: Bạn nghĩ chúng ta sẽ đến bước đó không? Chính là setting 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ờ hoặc永远 sẽ thế nào.
Lenny: Bạn với tư cách là负责人 sản phẩm và kỹ thuật, bản thân bạn dùng AI làm việc như thế nào?
Andrew Ambrosino: Tôi nghĩ giờ tôi có thể đang sở hữu công việc tốt nhất thế giới.
Lúc mới bắt đầu làm Codex, mục tiêu cá nhân của tôi là làm nó tốt đến mức tôi có thể dùng nó để viết code của Codex. Đó là một vòng lặp sản phẩm自用 siêu chặt chẽ, tôi không làm được việc nào đó,那就 sửa好 nó, rồi tôi làm được, rồi có thể làm nhiều việc hơn.
Sau đó vai trò của tôi thay đổi. Tôi cần làm nhiều product discovery hơn,搞清楚 đội ngũ đang làm gì, sửa những thứ lệch hướng. Thế là Codex变成 công cụ để tôi làm những việc này. «Giúp tôi xây một spreadsheet để整理 những dữ liệu này ra.» «Giúp tôi làm một nghiên cứu sâu nội bộ, xem quá khứ đã làm những khám phá nào trên hướng này.»
Loạt phát hành tháng 5, trình duyệt trong ứng dụng, computer use, artifact creation, đó là lần đầu tiên chúng tôi dùng vibe coordination (phối hợp theo cảm xúc) để quản lý phát hành. Tôi có một Notion document ghi lại mọi todo, rồi dùng Codex tự động đi thu thập tiến triển từ PR, kênh Slack, cập nhật status tracker, lúc đó cảm thấy đây là前沿 nhất của cách quản lý phát hành sản phẩm.
Giờ mỗi sáng tôi dậy, sẽ xem daily report mà Codex giúp tôi生成, lọc ra những việc cần tôi quan tâm từ 3000 kênh Slack mà tôi tham gia. Tôi có thể reply nói «đưa tôi năm câu hỏi, tôi来 trả lời». Nó sẽ tự điều chỉnh, tôi nói «lần sau chạy的时候, ít quan tâm workflow này hơn» hoặc «chuyện này xảy ra nhưng không xuất hiện trong daily report, đảm bảo sau này có thể bắt được», nó sẽ cập nhật cách notify, điều chỉnh trọng điểm quan tâm.
Lenny: Cái này setup thế nào? Workflow là gì?
Andrew Ambrosino: Giờ vẫn đang trong giai đoạn discovery. Chính là làm một scheduled task: «Duyệt qua kênh Slack của tôi, đây là những chuyện tôi quan tâm,整理 theo những phân loại này, ở đây có một số context.» Vài lần chạy đầu có thể cần guidance. May mà tôi không cần đi tìm cách edit instruction, tôi trực tiếp đối thoại nói «lần sau giúp tôi sửa cái này», nó liền cập nhật.
Nhưng tôi nghĩ đây cũng là vấn đề cốt lõi của hình thái chatbot, tôi biết cách setup, vì đối với tôi đây chính là product discovery. Nhưng nếu bạn không làm việc tại OpenAI, không đang phát triển thứ này, bạn sẽ không muốn đi搞清楚 những chuyện này. Chúng ta cần nghĩ rõ làm thế nào để让这些 hình thái cũng có thể dùng được cho người bình thường.
Lenny: Bản thân tôi cũng dùng Codex làm một automation lọc spam. Trong đó một bước phải đi Google Cloud console setup một đống API trigger, giao diện đó特别 phiền. Tôi liền để Codex giúp tôi làm, nó trực tiếp接管 máy tính của tôi, dùng chức năng computer use để thao tác.
Andrew Ambrosino: Nó chính là: «Tôi kệ bạn có connector hay không, ông bạn, tôi trực tiếp bắt đầu click.»
Làm thế nào để phân chia ranh giới giữa connector, trình duyệt trong ứng dụng, Chrome extension và computer use, là một chuyện rất thú vị. Rất nhiều lúc, những ranh giới này thực ra đều là凭 cảm giác mò mẫm ra.
Tôi nghĩ những personal workflow này特别 thú vị. Mọi người đều đang thử各种 thứ, mỗi người đều sẽ搭建 ra hệ thống hoàn toàn khác nhau. Nhưng dần dần, một số模式 chung sẽ nổi lên. Rồi chúng tôi sẽ nhận ra: «Cái này nên trở thành first-class experience trong sản phẩm.»
Ví dụ memory, rất nhiều người đang setup Obsidian knowledge base hoặc Notion space để xây dựng mental palace của mình. Bạn không nên cần tự làm cái này, nên có một chức năng memory đủ通用 thay bạn làm. Chúng tôi luôn sàng lọc, cái gì có hiệu quả với cá nhân nhưng nên giữ ở mức cá nhân, cái gì nên vào sản phẩm trở thành component cơ sở.
Lenny: Người bên ngoài nhìn thấy đều là bạn đang thắng. Nhưng chắc chắn có chuyện không thành công chứ?
Andrew Ambrosino: Nghe bạn mô tả挺 buồn cười. Đây thực ra là lần đầu tiên tôi cảm thấy mình không đang thất bại.
Tôi trước đây khởi nghiệp làm rất nhiều năm, cuối cùng cơ bản là拆解 công ty bán đi. Làm trong ngành bị监管 cao, toàn bộ quá trình giống như thất bại liên tục. Sau đó đi đến một startup khác, làm công cụ AI trong một ngành bị đóng kín chịu监管 khác, cũng là hết lần này đến lần khác không được. Tôi thực tế đã thất bại rất nhiều. Đôi khi chỉ là một thời điểm, kỹ năng, nhiệt huyết và cửa sổ thị trường vừa khớp nhau.
即使 là trong dự án kết hợp Codex và ChatGPT hiện tại này, cũng có vô số thất bại nhỏ. Chúng tôi nói «nên dài thế này», phát vào Slack, bên dưới liền là 2000 tin nhắn nói chúng tôi有多 ngu. Đây là chỗ tôi thích OpenAI, mọi người sẽ trực tiếp nói cho chúng tôi, đối với thất bại của sản phẩm nội bộ không留情面, đây cũng là lý do tại sao sản phẩm bên ngoài làm được不错. Tôi trước khi đến vị trí hiện tại này, đã thất bại khoảng 10 đến 15 năm. Vì vậy mỗi ngày tôi vẫn cảm thấy hơi kinh ngạc, chuyện竟然 đang diễn ra thuận lợi.
Lenny: Có lời khuyên cuối nào cho độc giả không?
Andrew Ambrosino: Đừng «bind trọn đời» với workflow hiện tại của bạn. Thứ thực sự nên kiên trì, là những kết quả mà chỉ bạn có thể交付 một cách độc đáo. Rồi, liên tục thử thay đổi workflow của bạn. Nếu kỹ năng mà bạn tự hào nhất là «tôi hiểu nhất auto layout của Figma», vậy bạn đang làm gì? AI cũng sẽ trở nên giỏi hơn bạn. Tìm ra việc đáng làm, rồi nghĩ cách đi làm những việc đó.
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
