OpenAI’s head of platform engineering on the next 12-24 months of AI | Sherwin Wu

Các kỹ sư của OpenAI đang tích hợp sâu AI (đặc biệt là Codex) vào quy trình làm việc, với 95% sử dụng Codex hàng ngày và 100% pull request được AI xem xét, giúp tăng năng suất đáng kể (mở PR nhiều hơn 70%).
Vai trò của kỹ sư đang chuyển đổi nhanh chóng từ người viết mã thành trưởng nhóm kỹ thuật, quản lý các tác nhân AI và điều hướng luồng công việc phức tạp, mở ra kỷ nguyên "lập trình theo cảm hứng/trực giác" (vibe coding).
Lĩnh vực AI và các mô hình ngôn ngữ lớn (LLM) đang phát triển rất nhanh; cần tập trung xây dựng cho nơi mà các LLM đang hướng tới chứ không phải hiện tại của chúng, đồng thời cung cấp ngữ cảnh rõ ràng để quản lý hiệu quả các tác nhân AI.

AI — Artificial Intelligence (Trí tuệ nhân tạo)
kỹ sư — Engineer
Codex — Codex (mô hình AI của OpenAI)
pull request (PR) — Pull Request (Yêu cầu hợp nhất mã)
tác nhân (AI) — AI Agent (Tác nhân AI)
cơ sở mã — Codebase (Cơ sở mã)
mô hình ngôn ngữ lớn (LLM) — Large Language Model (Mô hình ngôn ngữ lớn)
giao diện lập trình ứng dụng (API) — Application Programming Interface (Giao diện lập trình ứng dụng)
năng suất — Productivity
xem xét mã — Code Review

Giới thiệu về Sherwin Woo và bối cảnh `AI`

95% kỹ sư sử dụng Codex. 100% pull request (PR) của chúng tôi đều được Codex xem xét cho các kỹ sư. Tôi không biết công việc nào đã thay đổi nhiều hơn trong vài năm qua. Các kỹ sư đang trở thành trưởng nhóm kỹ thuật (tech lead). Họ quản lý các đội và đội tác nhân (AI). Cảm giác thực sự như chúng ta là những phù thủy đang niệm những câu thần chú này. Và những câu thần chú này giống như đang thực hiện mọi thứ giúp bạn. Bạn nghĩ mọi người chưa tính đến điều gì? Đó là những tác động cấp độ hai hoặc ba của việc một công ty khởi nghiệp tỷ đô với một người vận hành (one-person billion dollar startup) có thể tạo ra một công ty khởi nghiệp tỷ đô với một người vận hành khác. Có thể có hàng trăm công ty khởi nghiệp nhỏ khác đang xây dựng phần mềm chuyên biệt. Và vì vậy, tôi nghĩ chúng ta có thể thực sự bước vào một thời kỳ hoàng kim của phần mềm dịch vụ (SaaS) B2B.

Tôi ngày càng nghe nhiều hơn về sự căng thẳng mà mọi người cảm thấy khi tác nhân (AI) của họ không hoạt động. Có một nhóm hiện đang thực hiện một thử nghiệm tại OpenAI, nơi họ duy trì một cơ sở mã (codebase) được viết 100% bằng Codex. Họ gặp phải chính xác những vấn đề mà bạn đang mô tả. Và thông thường, bạn sẽ nói: "Được rồi, tôi sẽ xắn tay áo lên và tìm cách giải quyết." Nhưng nhóm này không có lối thoát đó.

Bạn đã chia sẻ rằng việc lắng nghe khách hàng không phải lúc nào cũng là chiến lược đúng đ đắn trong trí tuệ nhân tạo (AI). Lĩnh vực này và bản thân các mô hình ngôn ngữ lớn (LLM) đang thay đổi quá nhanh. Chúng có xu hướng tự phá vỡ mình. Các mô hình ngôn ngữ lớn (LLM) sẽ "ăn thịt" giàn giáo của bạn cho bữa sáng. Lời khuyên của bạn dành cho những người nói: "Được rồi, tôi không muốn bỏ lỡ cơ hội này" là gì? Hãy đảm bảo rằng bạn đang xây dựng cho nơi mà các mô hình ngôn ngữ lớn (LLM) đang hướng tới, chứ không phải nơi chúng đang ở hiện tại. Có một câu nói của Kevin Whale, Phó Giám đốc Khoa học của chúng tôi tại đây. Ông ấy thích nói: "Đây là lúc các mô hình ngôn ngữ lớn (LLM) tệ nhất."

Khách mời của tôi hôm nay là Sherwin Woo, Giám đốc Kỹ thuật của giao diện lập trình ứng dụng (API) và nền tảng dành cho nhà phát triển của OpenAI. Xét rằng về cơ bản, mọi công ty khởi nghiệp trí tuệ nhân tạo (AI) đều tích hợp với giao diện lập trình ứng dụng (API) của OpenAI, Sherwin có một cái nhìn cực kỳ độc đáo và rộng lớn về những gì đang diễn ra và mọi thứ đang đi về đâu. Hãy cùng tìm hiểu sau một vài lời giới thiệu ngắn gọn từ các nhà tài trợ tuyệt vời của chúng ta.

Quảng cáo: DX – Nền tảng phân tích `nhà phát triển`

Tập hôm nay được tài trợ bởi DX, nền tảng thông minh nhà phát triển được thiết kế bởi các nhà nghiên cứu hàng đầu. Để phát triển mạnh mẽ trong kỷ nguyên trí tuệ nhân tạo (AI), các tổ chức cần thích nghi nhanh chóng. Nhưng nhiều nhà lãnh đạo tổ chức gặp khó khăn trong việc trả lời các câu hỏi cấp bách như: công cụ nào đang hoạt động? Chúng đang được sử dụng như thế nào? Điều gì thực sự mang lại giá trị? DX cung cấp dữ liệu và thông tin chi tiết mà các nhà lãnh đạo cần để điều hướng sự thay đổi này. Với DX, các công ty như Dropbox, Booking.com, Adyen và Intercom có được sự hiểu biết sâu sắc về cách trí tuệ nhân tạo (AI) đang mang lại giá trị cho các nhà phát triển của họ và tác động mà trí tuệ nhân tạo (AI) đang có đối với năng suất (productivity) kỹ thuật. Để tìm hiểu thêm, hãy truy cập trang web của DX tại getdx.com/lenny. Đó là getdx.com/lenny.

Quảng cáo: Sentry – Gỡ lỗi `AI` hiệu quả

Các ứng dụng có thể gặp lỗi theo nhiều cách: sự cố, chậm trễ, hồi quy và những vấn đề mà bạn chỉ thấy khi người dùng thực bắt đầu sử dụng. Sentry nắm bắt tất cả. Xem điều gì đã xảy ra, ở đâu và tại sao, đến cả commit đã gây ra lỗi, nhà phát triển đã phát hành nó và dòng mã chính xác, tất cả trong một chế độ xem được kết nối. Tôi chắc chắn đã thử cách tiếp cận gỡ lỗi bằng năm tab và một chuỗi Slack. Cách này tốt hơn. Sentry cho bạn biết cách yêu cầu di chuyển, những gì đã chạy, những gì bị chậm và những gì người dùng đã thấy. Seir, tác nhân (AI) gỡ lỗi của Sentry, sẽ tiếp quản từ đó. Nó sử dụng tất cả ngữ cảnh của Sentry để cho bạn biết nguyên nhân gốc rễ, đề xuất cách khắc phục và thậm chí mở một pull request (PR) cho bạn. Nó cũng xem xét mã (review code) pull request (PR) của bạn và gắn cờ bất kỳ thay đổi gây lỗi nào với các bản sửa lỗi sẵn sàng. Hãy dùng thử Sentry và Seir miễn phí tại sentry.io/lenny và sử dụng mã Lenny để nhận 100 đô la tín dụng Sentry. Đó là sentry.io/lenny.

Sherwin, cảm ơn bạn rất nhiều vì đã có mặt tại đây và chào mừng đến với podcast.

Cảm ơn bạn. Cảm ơn bạn đã mời tôi.

Tôi muốn bắt đầu với điều đang được xem như một phong vũ biểu của sự tiến bộ trong trí tuệ nhân tạo (AI), đặc biệt là trong kỹ thuật. Hiện tại, bao nhiêu phần trăm mã của bạn — nếu bạn còn viết mã nữa — và mã của nhóm bạn được trí tuệ nhân tạo (AI) viết?

Tôi vẫn thỉnh thoảng viết mã bây giờ. Và tôi thực sự muốn nói rằng đối với những quản lý như tôi, việc sử dụng các công cụ AI này dễ dàng hơn nhiều so với việc viết mã thủ công vào thời điểm này. Và vì vậy, tôi biết đối với bản thân và một số quản lý kỹ thuật (engineering managers) khác tại OpenAI, tất cả mã của chúng tôi đều được Codex viết vào thời điểm này. Nhưng nói rộng hơn, có quá nhiều năng lượng. Có một năng lượng hữu hình trong nội bộ về việc các công cụ này đã tiến xa đến mức nào, Codex với tư cách là một công cụ đã trở nên tốt như thế nào đối với chúng tôi. Và hơi khó để chúng tôi đo lường chính xác bao nhiêu mã được viết, bởi vì phần lớn trong số đó, tôi muốn nói là gần 100%, thường được trí tuệ nhân tạo (AI) tạo ra trước. Tuy nhiên, điều chúng tôi theo dõi là, vào thời điểm này, phần lớn các kỹ sư sử dụng Codex hàng ngày. Vì vậy, 95% kỹ sư sử dụng Codex. 100% pull request (PR) của chúng tôi cũng được Codex xem xét mã (review code) hàng ngày. Vì vậy, về cơ bản, bất kỳ mã nào đi vào sản xuất, được hợp nhất, Codex đều theo dõi và đề xuất cải tiến, đề xuất thay đổi trong các pull request (PR). Và đó là những gì chúng tôi đang thấy trong nội bộ. Nhưng nhìn chung, điều thú vị nhất chính là năng lượng mà nó mang lại. Một quan sát khác mà chúng tôi có là các kỹ sư có xu hướng sử dụng Codex nhiều hơn sẽ mở pull request (open PR) nhiều hơn đáng kể. Vì vậy, họ thực sự mở pull request (open PR) nhiều hơn 70% so với các kỹ sư không sử dụng Codex nhiều. Và khoảng cách đang ngày càng rộng ra. Vì vậy, tôi cảm thấy rằng những người mở pull request (open PR) nhiều hơn đang bắt đầu học cách sử dụng công cụ ngày càng hiệu quả hơn, và khoảng cách 70% đó tiếp tục tăng theo thời gian và có thể đã tăng lên kể từ lần cuối tôi xem số liệu.

Được rồi. Vậy để chắc chắn chúng tôi hiểu đúng ý bạn, bạn đang nói rằng tất cả mã của 95% kỹ sư tại OpenAI đều được trí tuệ nhân tạo (AI) viết. Nó được viết và sau đó họ xem xét mã (review code) lại.

Vâng. Vâng.

Sự phát triển của niềm tin vào `mô hình AI`

Thật điên rồ khi điều đó gần như không còn điên rồ nữa, chúng ta đang dần quen với điều này. Tôi nghĩ vẫn còn một số điều cần làm quen, nói rõ hơn. Tôi cũng nghĩ có một số kỹ sư tin tưởng Codex ít hơn một chút, nhưng về cơ bản, mỗi ngày tôi đều nói chuyện với một ai đó bị choáng ngợp bởi những gì trí tuệ nhân tạo (AI) có thể làm và mức độ tin tưởng của họ, hoặc mức độ họ tin tưởng mô hình có thể tự mình làm, ngày càng tăng lên theo thời gian. Và có một câu nói của Kevin Whale, Phó Giám đốc Khoa học của chúng tôi tại đây, ông ấy thích nói: "Đây là lúc các mô hình tệ nhất." Và đây cũng là lúc các mô hình tệ nhất đối với kỹ thuật phần mềm. Và vì vậy, theo thời gian, bạn sẽ thấy mọi người tin tưởng nó ngày càng nhiều hơn và sau đó chúng ta sẽ thấy các mô hình ngày càng tốt hơn nữa.

Vâng. Kevin Whale, khách mời podcast trước đây, ông ấy đã nói chính xác câu đó trên podcast này và vài lần rồi.

Vâng. Peter, nhà phát triển của Claudebot/Moldbotclaw (tên gọi hiện tại), gần đây đã chia sẻ rằng anh ấy sử dụng Codex cho công việc của mình và anh ấy cảm thấy bất cứ khi nào nó thực hiện mọi thứ, anh ấy chỉ tin tưởng rằng nó đã làm đúng việc và anh ấy gần như chắc chắn rằng mình có thể commit nó vào master và nó sẽ hoạt động tốt.

Vâng. Vâng. Anh ấy là một người dùng Codex tuyệt vời. Tôi biết anh ấy giữ liên lạc chặt chẽ với nhóm, cung cấp cho chúng tôi những phản hồi tuyệt vời. Không ngạc nhiên khi anh ấy sử dụng nó. Ý tôi là, xin lỗi, nó được gọi là OpenClaw.

OpenClaw. Vâng.

OpenClaw là một sản phẩm tuyệt vời. Và sau đó tôi thấy rằng điều này — ý tôi là, điều này rất gần đây, nhưng sáng nay tôi nghĩ Mold's bot cũng được chia sẻ, và việc nhìn thấy tất cả các tác nhân AI nói chuyện với nhau khá siêu thực. Về cơ bản, đó là bộ phim Her đang diễn ra ngoài đời thực, là điều tôi đang nghe.

Vâng. Vâng.

Vai trò của `Kỹ sư phần mềm` trong tương lai

Quay lại khoảnh khắc điên rồ mà chúng ta đang sống, đặc biệt là đối với các kỹ sư. Chúng ta đã đi từ việc "bạn viết mọi dòng mã" đến nay "trí tuệ nhân tạo (AI) đang viết tất cả mã của bạn." Tôi không biết công việc nào đã thay đổi nhiều hơn trong vài năm qua — một công việc mà chúng ta không ngờ lại thay đổi nhiều đến vậy — nơi mà công việc của một kỹ sư quá khác biệt. Trong suốt vòng đời của một kỹ sư, trong vài năm qua, nó giờ đây đã chuyển sang "Tôi không viết mã nữa." Bạn hình dung vai trò của một kỹ sư và công việc của một kỹ sư phần mềm sẽ như thế nào trong vài năm tới? Công việc đó sẽ ra sao?

Vâng, ý tôi là, thành thật mà nói, thật tuyệt vời khi thấy điều đó, và đó là một phần của sự hào hứng vì công việc có thể sẽ thay đổi khá đáng kể trong một đến hai năm tới. Cảm giác như chúng ta vẫn đang tìm hiểu mọi thứ, và vì vậy có một sự hào hứng, tôi biết đặc biệt là từ một số kỹ sư phần mềm, kiểu như "chúng ta đang ở trong một khoảnh khắc hiếm có," bạn biết đấy, "có thể trong 12 đến 24 tháng tới, chúng ta sẽ tự tìm hiểu mọi thứ và tự đặt ra các tiêu chuẩn cho mình" về nơi tôi thấy điều này đang di chuyển. Vì vậy, tôi nghĩ có một điều phổ biến mà mọi người đang nói, đó là các kỹ sư cá nhân (IC engineers) đang trở thành trưởng nhóm kỹ thuật (tech leads). Về cơ bản, họ giống như quản lý bây giờ. Họ đang quản lý các đội và đội tác nhân (AI). Tôi biết nhiều kỹ sư trong nhóm của tôi về cơ bản có khoảng 10 đến 20 luồng công việc đang được kéo cùng một lúc. Rõ ràng là không phải các tác vụ Codex đang chạy chủ động, mà chỉ là rất nhiều luồng song song. Họ đang kiểm tra những gì tác nhân (AI) đang làm. Họ đang điều khiển các tác nhân (AI) và Codex và đưa ra phản hồi cho nó. Và vì vậy, công việc của họ đã thực sự thay đổi từ việc chỉ viết mã sang gần như trở thành một quản lý.

`Lập trình`: Một hình thức "phép thuật" trong kỷ nguyên `AI`

Về việc tôi nghĩ điều này sẽ đi đến đâu trong một đến hai năm tới. Vậy thì, một phép ẩn dụ mà tôi luôn quay lại đây thực sự đến từ một cuốn sách giáo khoa lập trình mà tôi đã đọc hồi đại học có tên là SICP. Tôi không biết bạn đã nghe về nó chưa. "Structure and Interpretation of Computer Programs" (Cấu trúc và Giải thích các Chương trình Máy tính). SICP. Tại MIT, nó rất phổ biến và thực sự được sử dụng làm sách giáo khoa nhập môn cho khóa học lập trình giới thiệu trong một thời gian rất dài, và nó có một lượng người theo dõi cuồng nhiệt. Nó dạy bạn lập trình; nó dạy bạn một phương ngữ của Lisp tên là Scheme. Và vì vậy, nó giới thiệu bạn đến lập trình chức năng, nó rất mở mang đầu óc theo cách đó. Nhưng điều đáng nhớ đối với tôi về cuốn sách đó – tôi đã đọc nó ở đại học – ngay từ đầu nó đã mô tả lập trình như một kỷ luật và rút ra phép ẩn dụ về cơ bản như phép thuật. Giống như nó nói, kỹ sư phần mềm giống như phù thủy, và ngôn ngữ lập trình giống như những câu thần chú, và bạn đang nói, bạn đang phát ra những câu thần chú này, và những câu thần chú này giống như đang đi ra ngoài và làm mọi thứ cho bạn. Và thách thức là bạn phải nói câu thần chú nào để làm cho chương trình thực hiện điều bạn muốn. Và cuốn sách này được viết vào năm 1980, vì vậy đây là một thời gian trước, và tôi nghĩ phép ẩn dụ đó thực sự đã tồn tại theo thời gian. Và tôi nghĩ nó thực sự đang diễn ra khi chúng ta chuyển sang kỷ nguyên mới của lập trình theo cảm hứng/trực giác (vibe coding) hoặc chỉ là kỹ thuật phần mềm sẽ trông như thế nào, bởi vì ngôn ngữ lập trình về cơ bản là những câu thần chú này. Chúng đã thay đổi theo thời gian, và thách thức luôn luôn và xu hướng là ngày càng dễ dàng hơn để làm cho máy tính thực hiện điều bạn muốn thông qua lập trình. Và tôi nghĩ làn sóng trí tuệ nhân tạo (AI) hiện tại có lẽ là giai đoạn tiếp theo của sự tiến hóa đó. Giờ đây, chúng thực sự là những câu thần chú bởi vì bạn có thể nói cho Codex, bạn có thể nói cho Cursor chính xác những gì bạn muốn làm, và sau đó nó sẽ đi làm tất cả cho bạn.

Phép Ẩn Dụ "Người Học Việc Của Phù Thủy" và Đòn Bẩy Cao của AI

Tôi đặc biệt thích phép ẩn dụ về phù thủy và phép thuật, bởi vì tôi nghĩ rằng trạng thái hiện tại của chúng ta đang bắt đầu chuyển sang một dạng người học việc của phù thủy (Sorcerer's Apprentice), bạn biết đấy, từ Fantasia, nơi chuột Mickey tìm thấy chiếc mũ của phù thủy và cố gắng làm tất cả những điều này. Và tôi thực sự nghĩ đó là một phép ẩn dụ rất phù hợp bởi vì, thứ nhất, nó thực sự mạnh mẽ. Những câu thần chú bạn có thể niệm bây giờ có đòn bẩy cao (high leverage) phi thường. Nhưng bạn phải biết mình đang làm gì, phải không? Như trong Sorcerer's Apprentice, toàn bộ cốt truyện là Mickey trở nên mất kiểm soát, những cây chổi trở nên điên cuồng và mọi thứ ngập lụt. Tôi nghĩ cậu ta theo đúng nghĩa đen đã giao nhiệm vụ cho những cây chổi và sau đó đi ngủ. Và vì vậy, bạn biết đấy, nó giống như vibe coding ở mức độ cao nhất của nó. Và rồi cuối cùng, ông phù thủy già quay lại và dọn dẹp mọi thứ.

Và, bạn biết đấy, khi tôi thấy các kỹ sư đang thực hiện 20 luồng codeex khác nhau cùng một lúc, cần có kỹ năng, cần có kinh nghiệm và cần rất nhiều suy nghĩ để làm điều này, bởi vì bạn muốn đảm bảo rằng các mô hình AI không đi chệch hướng. Bạn chắc chắn không muốn chỉ hoàn toàn bỏ đi và bỏ qua mọi thứ. Nhưng nó cũng có đòn bẩy cao phi thường; một kỹ sư rất cao cấp, người thực sự thành thạo với những AI tools này, giờ đây có thể làm được nhiều việc hơn thông qua những gì họ đang làm. Và tôi nghĩ đây cũng là điều làm cho nó trở nên thú vị. Nó thực sự có cảm giác như chúng ta là những phù thủy bây giờ. Bạn biết đấy, nó có cảm giác như chúng ta đang tiến gần hơn đến việc có một trải nghiệm kỳ diệu, nơi chúng ta, bạn biết đấy, đang niệm tất cả những câu thần chú này và có phần mềm làm tất cả những điều này cho chúng ta.

Tôi cũng đang nghĩ đến Sorcerer's Apprentice chính xác là một phép ẩn dụ khi anh mô tả điều đó. Vì vậy, tôi mừng vì anh đã nói đến. Một khách mời podcast trước đây đã mô tả nó như việc bạn có một thần đèn có thể ban cho bạn những điều ước, và đó là một khuôn khổ hữu ích bởi vì bạn phải rất rõ ràng về điều ước bạn muốn. Chẳng hạn, nếu bạn muốn lớn, thì lớn đến mức nào?

Vâng. Hoặc nó có thể giống như kiểu monkey's paw nơi bạn có được điều mình muốn, nhưng tác dụng phụ là gì?

Ừm, vâng. Vâng. Tôi nghĩ đó là một phép ẩn dụ tuyệt vời. Và điều điên rồ đối với tôi chỉ là sức sống bền bỉ của cuốn sách đó. Nó được gọi là "cuốn sách phù thủy" (the wizard book). Mọi người gọi nó là "cuốn sách phù thủy" bởi vì đó là phép ẩn dụ mà họ dệt xuyên suốt cuốn sách. Và chúng ta về cơ bản đã đạt đến điểm đó bây giờ, điều này thực sự thú vị.

Những Thách Thức Khi Tương Tác với Tác Nhân AI

Có hai luồng ý tưởng tôi muốn đi sâu vào đây. Một là tôi đã nghe ngày càng nhiều về sự căng thẳng mà mọi người cảm thấy khi các tác nhân AI của họ không hoạt động. Bạn khởi động tất cả các tác nhân codeex này, và sau đó bạn phải theo dõi chúng. "Ồ, một cái không hoạt động. Tôi đang lãng phí thời gian." Anh có cảm thấy điều đó không? Anh có cảm thấy điều đó trong toàn bộ nhóm của mình không?

Vâng. Vâng. Ý tôi là, điều đó xảy ra mọi lúc. Và tôi thực sự nghĩ rằng đây là nơi chứa đựng phần thú vị của tất cả những điều này vào lúc này, bởi vì những mô hình AI này không hoàn hảo. Những AI tools này không hoàn hảo và chúng tôi vẫn đang cố gắng tìm ra cách tốt nhất để tương tác với codeex hoặc với các tác nhân AI này để hoàn thành công việc. Chúng tôi thấy điều này xảy ra mọi lúc. Chúng tôi có một nhóm nội bộ đặc biệt thú vị. Có một nhóm hiện đang thực hiện một thử nghiệm trong OpenAI, nơi họ về cơ bản đang duy trì một codebase được viết hoàn toàn bằng codeex. Vì vậy, bạn biết đấy, AI sẽ viết mã, nhưng rõ ràng bạn sẽ phải viết lại rất nhiều và bạn có thể cần phải kiểm tra lại và thay đổi mọi thứ. Nhưng nhóm này chỉ hoàn toàn dựa vào codeex và hoàn toàn tập trung vào nó. Và họ gặp phải chính xác những vấn đề mà bạn đang mô tả, đó là: "Tôi muốn xây dựng tính năng này nhưng tôi không thể khiến tác nhân AI làm điều đó."

Và thường thì có một lối thoát, nơi bạn sẽ nói: "Được rồi, tôi sẽ xắn tay áo lên và tự mình tìm ra," và thay vì sử dụng codeex, tôi có thể sử dụng tab complete và cursor và những thứ tương tự. Nhưng nhóm này, cho mục đích thử nghiệm, không có lối thoát đó. Và vì vậy, thách thức là làm thế nào để tôi khiến tác nhân AI làm điều này? Và tôi thực sự nghĩ rằng chúng tôi sẽ xuất bản một bài đăng trên blog về một số bài học của chúng tôi ở đây. Nhưng rất nhiều mô hình và best practices (thực hành tốt nhất) hấp dẫn đang xuất hiện từ thử nghiệm này.

Một điều thú vị mà chúng tôi đã nhận thấy – tôi không biết liệu bạn có cảm thấy điều này không, nhưng chúng tôi chắc chắn cảm thấy ở đây – là phần lớn thời gian, khi coding agent không làm điều bạn muốn, đó thường là vấn đề với context (ngữ cảnh) và thông tin bạn đã cung cấp cho nó. Bạn hoặc đã đặc tả không đủ, hoặc đơn giản là không có đủ thông tin về cách làm điều gì đó có sẵn cho tác nhân AI, có sẵn cho codeex. Và vì vậy, khi bạn phải giải quyết nó theo cách đó, thách thức sau đó là thêm tài liệu và thực sự khắc phục hạn chế này, và về cơ bản, mã hóa thêm tribal knowledge (kiến thức bộ lạc) trong đầu bạn vào codebase thông qua code comments (bình luận mã) hoặc code structure (cấu trúc mã), hoặc thông qua các tệp văn bản như tệp Markdown (MD files) hoặc bất kỳ loại tài nguyên bổ sung nào trong kho lưu trữ (repository) để mô hình AI có thể thực hiện nhiệm vụ (task) của nó tốt hơn. Có rất nhiều bài học khác từ nhóm này mà tôi nghĩ rất hấp dẫn để khám phá. Nhưng vâng, việc loại bỏ lối thoát không còn sử dụng AI đã cho phép họ bắt đầu ghép nối nhiều vấn đề mà chúng ta sẽ phải giải quyết nếu chúng ta thực sự muốn dựa vào các tác nhân AI.

AI Tự Động Hóa Review Code và Quy Trình CI/CD

Một vấn đề khác mà mọi người gặp phải, anh đã nói về việc mọi người ship PR (gửi yêu cầu kéo) một cách điên cuồng, nhiều PR hơn rất nhiều nếu họ làm việc với AI. Rõ ràng là review code (xem xét mã) đang trở thành một thách thức lớn hơn. Anh có phát hiện ra điều gì trong nhóm của mình để giúp tăng tốc quá trình đó, để làm cho nó có thể mở rộng và không chỉ tạo ra một công việc khủng khiếp cho mọi người khi họ chỉ ngồi đó review PR cả ngày không?

Vâng, một điều là codeex review 100% tất cả các PR của chúng tôi vào thời điểm này. Và tôi thực sự nghĩ rằng một điều thực sự thú vị đã xảy ra là những thứ mà chúng ta có xu hướng giao cho mô hình AI ngay lập tức thường là những thứ làm chúng ta khó chịu hoặc là những phần nhàm chán nhất của kỹ thuật phần mềm. Đó cũng là lý do tại sao bây giờ nó thú vị hơn, bởi vì chúng ta được làm nhiều hơn, bạn biết đấy, nhiều điều thú vị hơn. Đối với tôi, nói riêng, tôi thực sự ghét review code. Đó là một trong những điều tồi tệ nhất đối với tôi. Và sau đó tôi nhớ trong công việc đầu tiên của mình sau đại học, đó là ở Quora. Tôi chịu trách nhiệm về newsfeed (bảng tin), và vì vậy tôi sở hữu mã cho newsfeed. Và tôi là người review cho newsfeed, và nó giống như một phần mã trung tâm mà mọi người sẽ chạm vào. Và vì vậy, mỗi sáng tôi đăng nhập và thấy khoảng 20 đến 30 code review. Tôi chỉ nghĩ "Ôi trời ơi, tôi phải xử lý hết tất cả những cái này". Tôi sẽ trì hoãn và sau đó nó tăng lên đến 50. Và vì vậy có rất nhiều code review. Codeex thực sự giỏi trong việc review code.

Vì vậy, một điều mà chúng tôi đã nhận thấy rằng 52 (phiên bản codeex?) đặc biệt đã trở nên cực kỳ thành thạo là review code, đặc biệt là khi bạn hướng dẫn nó đúng hướng. Và vì vậy, đối với code review, vâng, chúng tôi tạo ra rất nhiều PR, nhưng codeex review tất cả chúng và nó làm cho code review từ một nhiệm vụ 10-15 phút đôi khi chỉ còn 2-3 phút, bởi vì bạn đã có sẵn một loạt các đề xuất. Rất nhiều lần, đặc biệt đối với các PR nhỏ, bạn thực sự thậm chí không cần người để review. Chúng tôi có phần tin tưởng codeex theo cách này. Tác giả gốc (original author) cũng xem xét codeex. Lợi ích của code review là có một cặp mắt thứ hai để đảm bảo rằng bạn không làm điều gì ngớ ngẩn. Codeex là một cặp mắt thứ hai khá thông minh vào thời điểm này, và đó là điều mà chúng tôi đã tận dụng rất nhiều.

Quy trình CI (tích hợp liên tục) tổng thể và quy trình triển khai (deployment process) sau khi đẩy mã (push) cũng đã được tự động hóa rất nhiều thông qua codeex nội bộ vào thời điểm này. Nếu bạn nói chuyện với nhiều kỹ sư, điều làm họ khó chịu nhất là sau khi bạn đã viết mã đẹp đẽ của mình, làm thế nào để đưa nó vào môi trường sản xuất (production)? Bạn phải chạy tất cả các bài kiểm tra, bạn phải kiểm tra lỗi cú pháp (lint errors), review code. Có rất nhiều thứ tự động hóa bạn có thể làm với codeex, và vì vậy chúng tôi thực sự đã xây dựng một số AI tools nội bộ giúp tự động hóa quá trình đó, tự động hóa kiểm tra lỗi cú pháp. Nếu có lỗi kiểm tra lỗi cú pháp, đó là một sửa lỗi bằng codeex (codeex fix) rất dễ dàng. Và sau đó nó có thể vá lỗi (patch it) và sau đó khởi động lại quy trình CI. Vì vậy, tất cả những điều đó chúng tôi đang cố gắng gói gọn thành càng ít công việc càng tốt cho một kỹ sư, và sản phẩm phụ của việc đó là họ có thể hợp nhất (merge) và đẩy ra (push out) nhiều PR hơn.

Tin Tưởng AI Trong Review Code và Sử Dụng Đa Mô Hình

Codeex đang viết mã, codeex đang review mã của chính nó. Tôi tò mò liệu bạn có sẵn sàng sử dụng các mô hình AI khác để review công việc của các mô hình AI của bạn không? Đó có phải là một hướng đi, hay chỉ là nó đã đủ tốt, chúng ta không cần gì khác?

Vì vậy, tôi sẽ nói rằng chắc chắn có một vòng tròn luẩn quẩn ở đây và quay trở lại với Sorcerer's Apprentice, bạn muốn đảm bảo rằng bạn không để những cây chổi trở nên mất kiểm soát. Và vì vậy, tôi phải nói rằng, chúng tôi rất cẩn trọng về việc những PR nào hoàn toàn được codeex review. Hầu hết mọi người rõ ràng vẫn xem xét các PR của họ. Và vì vậy, nó không phải là xuống mức 0. Nó giống như giảm từ 100% sự chú ý xuống khoảng 30% sự chú ý, điều này chỉ giúp mọi thứ được thông qua. Về việc sử dụng nhiều mô hình AI khác nhau, chúng tôi rõ ràng thử nghiệm rất nhiều mô hình AI nội bộ và vì vậy chúng tôi có rất nhiều thứ đó. Chúng tôi ít sử dụng các mô hình AI bên ngoài hơn. Chúng tôi nghĩ điều quan trọng là phải dog food (tự dùng sản phẩm của mình) các mô hình AI của chính mình và nhận phản hồi (feedback) ở đó. Nhưng bạn cũng có thể, bạn biết đấy, có rất nhiều biến thể nội bộ của các mô hình AI mà bạn có thể sử dụng để cung cấp cho bạn một góc nhìn (perspective) khác ở đây và chúng tôi thấy điều đó hoạt động khá tốt.

Tỷ Lệ Mã Nguồn Được AI Viết tại OpenAI

Được rồi. Chỉ để đảm bảo chúng ta có một cái nhìn tổng quan (barometer) về thế giới hiện tại tại OpenAI về trí tuệ nhân tạo (AI) và mã nguồn, để tôi hiểu rõ hơn trước khi chuyển sang một chủ đề khác. 100% mã nguồn trong toàn OpenAI hiện được viết bởi codeex. Đó có phải là cách diễn đạt đúng không?

Tôi sẽ không nói rằng 100% mã nguồn đang chạy trong môi trường sản xuất (production) ngày nay được viết bởi AI. Và khá khó để thực hiện gán công lao (attribution) ở đó. Nhưng gần như mọi kỹ sư đều sử dụng codeex rất nhiều trong tất cả các nhiệm vụ của họ vào thời điểm này. Và vì vậy, tôi nghĩ rằng, nếu tôi phải ước tính, phần lớn mã nguồn vào thời điểm này có lẽ đã được AI tạo ra. Tuyệt vời. Được rồi.

Vai Trò Thay Đổi Của Quản Lý Kỹ Thuật

Vậy là có rất nhiều cuộc thảo luận, và chúng ta đã nói về vai trò của kỹ sư cá nhân (IC engineer). Ít người nói về vai trò thay đổi của một quản lý (manager), đặc biệt là một quản lý kỹ thuật (engineering manager). Cuộc sống của anh với tư cách là một quản lý đã thay đổi như thế nào với sự trỗi dậy của AI, và anh nghĩ vai trò của một quản lý trong tương lai là gì?

Nó chắc chắn thay đổi ít hơn so với một kỹ sư. Hiện tại chưa có codeex dành cho quản lý. Tuy nhiên, tôi sử dụng codeex khá nhiều cho một số nhiệm vụ quản lý mà tôi thực hiện. Tôi có thể nói một vài điều đang thay đổi. Có một số xu hướng. Vì vậy, tôi không nghĩ rằng nó đã thay đổi nhiều đến mức đó.

Tăng Cường Năng Suất Của Các Cá Nhân Xuất Sắc

Tuy nhiên, tôi nhận thấy các xu hướng và tôi nghĩ nếu chúng ta nhìn xa hơn, chúng ta có thể thấy nhiều điều sẽ đi đến đâu. Một điều ngày càng trở nên rõ ràng là CodeX thực sự trao quyền cho những người có hiệu suất cao nhất để đạt được nhiều thành quả, trở nên năng suất hơn rất nhiều. Và điều này thực sự... Tôi nghĩ điều này có lẽ đúng với AI nói chung trên toàn xã hội, đó là những người thực sự dấn thân, những người có agency cao hoặc sẽ thành thạo các tool này sẽ tự tăng cường năng suất cho bản thân. Tôi cũng đang nhận thấy điều này bây giờ, đó là những người có hiệu suất cao nhất cuối cùng sẽ năng suất hơn rất nhiều. Và vì vậy, bạn sẽ thấy sự chênh lệch lớn hơn trong năng suất làm việc của nhóm theo cách này.

Một điều mà tôi luôn áp dụng như một triết lý quản lý là dành phần lớn thời gian của mình cho những người có hiệu suất cao nhất, chỉ để đảm bảo họ không bị cản trở, đảm bảo họ hạnh phúc, đảm bảo họ cảm thấy năng suất và được lắng nghe. Tôi nghĩ điều này thậm chí còn đúng hơn trong thế giới AI, nơi những người có hiệu suất cao nhất của bạn sẽ thực sự tăng tốc, sử dụng các tool này. Tôi nghĩ một ví dụ là đội ngũ đang duy trì một codebase được tạo ra hoàn toàn bởi CodeX; chỉ cần để họ tự do khám phá và xem điều gì đang xảy ra ở đó là một điều đã mang lại lợi ích lớn. Vì vậy, tôi nghĩ đó là một xu hướng mà tôi đang thấy, nơi các manager dành nhiều thời gian hơn cho những người có hiệu suất cao nhất có lẽ sẽ tiếp tục diễn ra.

`AI` Nâng Tầm Khả Năng Quản Lý

Điều khác là... đây là một quan sát, nhưng tôi cảm thấy với rất nhiều công cụ AI có sẵn cho các manager. Ít phải viết code hơn, nhưng những thứ như Chat GPT với kiến thức tổ chức, khả năng nghiên cứu và hiểu ngữ cảnh tổ chức tốt hơn rất nhiều. Một ví dụ điển hình khác là chúng tôi đang thực hiện đánh giá hiệu suất ngay bây giờ, và thực sự rất dễ dàng sử dụng Chat GPT với kiến thức nội bộ được kết nối với GitHub và các tài liệu Notion, Google Docs của chúng tôi để nắm bắt rất rõ những gì người này đã làm trong 12 tháng qua và viết một báo cáo nghiên cứu chuyên sâu ngắn gọn về điều đó.

Tôi cảm thấy các manager sẽ có thể quản lý các nhóm lớn hơn nhiều trong thế giới này, giống như cách các kỹ sư phần mềm đang quản lý 20 đến 30 CodeX. Tôi cảm thấy những công cụ AI này sẽ cho phép các manager (quản lý con người) có đòn bẩy cao hơn, và nó sẽ cho phép họ quản lý các nhóm lớn hơn nhiều so với best practice hiện tại mà tôi nghĩ là sáu đến tám người cho kỹ thuật phần mềm. Bạn có thể thấy điều này được áp dụng cho các lĩnh vực phi kỹ thuật như hỗ trợ hoặc vận hành, nơi trước đây quy mô của đội ngũ hỗ trợ có thể bị hạn chế, nhưng khi bạn có thể chuyển giao nhiều thứ hơn cho các tác nhân AI, bạn thực sự có thể làm được nhiều việc hơn và cũng quản lý nhiều người hơn theo cách này. Tôi nghĩ điều tương tự cũng có thể xảy ra với quản lý con người, đặc biệt là trong các công ty công nghệ. Và chúng ta đã thấy điều này. Có một số đội ngũ mà các EM (Quản lý Kỹ thuật) đang quản lý khá nhiều người và họ làm điều đó khá khéo léo nhờ một số công cụ AI này, nơi họ có thể có đòn bẩy cao hơn, hiểu được những gì nhóm của họ đang làm, hiểu rõ hơn ngữ cảnh tổ chức và vận hành theo cách đó.

Tôi thích lời khuyên này mà bạn đã mô tả: bạn luôn tập trung vào những người có hiệu suất cao nhất và dành nhiều thời gian hơn cho họ, gỡ bỏ rào cản cho họ, đảm bảo họ hạnh phúc. Cách mà Marc Andreessen – người vừa xuất hiện trên podcast – đã diễn đạt là AI giúp người giỏi trở nên tốt hơn và người xuất sắc trở nên phi thường.

Vâng. Vâng.

Và điều bạn đang nói ở đây là việc tiếp tục làm điều này ngày càng nhiều có lẽ là động thái đúng đắn. Dành nhiều thời gian hơn cho những người giỏi nhất trong nhóm của bạn để gỡ bỏ rào cản cho họ, đảm bảo họ có mọi thứ họ cần.

Vâng. Một ví dụ rất hay hiện nay là có một nhóm kỹ sư nội bộ thực sự giỏi CodeX và đang suy nghĩ về những best practice để tương tác với mô hình này, và đó là một điều có đòn bẩy cực kỳ cao để họ thực hiện. Vì vậy, với tư cách là một manager, tôi chỉ nói: "Vâng, hãy khám phá điều này. Bất kỳ best practice nào xuất hiện từ đó, chúng ta phải chia sẻ với tổ chức. Chúng ta sẽ tổ chức tất cả các buổi chia sẻ kiến thức, chúng ta sẽ chia sẻ tài liệu và best practice ở khắp mọi nơi." Vì vậy, những điều như vậy chỉ nâng cao mọi người và tôi coi đó là một ví dụ khác về xu hướng này mà chúng ta đang thấy, nơi những người có hiệu suất cao nhất thực sự trở nên phi thường.

Tương Lai Của Khởi Nghiệp: Từ "`Startup` Tỷ Đô Một Người" Đến Bùng Nổ `B2B SaaS`

Mọi người đều cảm thấy điều này rất lớn. AI đang thay đổi rất nhiều. Thế giới đang thay đổi. Sẽ là một vấn đề lớn. Bạn nghĩ điều gì mà mọi người chưa tính đến về những gì sẽ thay đổi, về nơi mọi thứ đang hướng tới? Chỉ cần một ví dụ về điều mà bạn nghĩ rằng "chúng ta chưa nhận ra điều này".

Một trong những cụm từ hoặc ý tưởng yêu thích của tôi đã xuất hiện từ làn sóng AI này là ý tưởng về "startup tỷ đô một người". Tôi thực sự nghĩ rằng Sam có thể là người đầu tiên nói điều đó, nhưng thật hấp dẫn khi nghĩ về nó, phải không? Chẳng hạn, nếu mọi người có đòn bẩy cao như vậy, tại một thời điểm nào đó, rất có thể sẽ có một startup tỷ đô một người. Và mặc dù tôi nghĩ điều đó thực sự rất thú vị, tôi nghĩ mọi người chưa thực sự tính đến những hiệu ứng bậc hai hoặc bậc ba của điều này. Bởi vì cái mà startup tỷ đô một người ngụ ý là một người có thể có nhiều agency và nhiều đòn bẩy hơn khi sử dụng một trong những công cụ AI này, đến mức việc hoàn thành mọi thứ cần thiết cho công việc kinh doanh của họ để cuối cùng tạo ra thứ gì đó trị giá một tỷ đô la là siêu dễ dàng.

Nhưng tôi nghĩ có một vài hàm ý khác của điều này. Một trong số đó là, nếu một người dễ dàng tạo ra một startup tỷ đô một người hoặc nếu một người có thể tạo ra một startup tỷ đô một người, điều đó cũng có nghĩa là việc mọi người tạo ra các startup nói chung sẽ dễ dàng hơn rất nhiều. Tôi thực sự nghĩ rằng điều này sẽ là một hiệu ứng bậc hai: tôi nghĩ sẽ có một sự bùng nổ startup lớn và một sự bùng nổ các doanh nghiệp nhỏ (kiểu SMB), nơi bất kỳ ai cũng có thể xây dựng phần mềm cho bất cứ điều gì. Ví dụ, bạn đang bắt đầu thấy điều này diễn ra trong lĩnh vực startup AI, nơi phần mềm trở nên định hướng theo chiều dọc nhiều hơn, nơi các phân khúc thị trường dọc này – như việc tạo ra một công cụ AI cho một phân khúc thị trường dọc nào đó – có xu hướng hoạt động khá tốt vì bạn thực sự tập trung vào lĩnh vực cụ thể đó, bạn thực sự hiểu use case của nó. Vì vậy, nếu bạn phát triển AI, không có lý do gì mà bạn không thể có số lượng startup này nhiều hơn gấp 100 lần.

Và vì vậy, tôi nghĩ một thế giới mà chúng ta có thể thấy xảy ra là để cho phép một startup tỷ đô một người, có thể có hàng trăm startup nhỏ khác xây dựng phần mềm đặc biệt (bespoke software) hoạt động cực kỳ hiệu quả để hỗ trợ các loại startup tỷ đô một người nhỏ khác. Và vì vậy, tôi nghĩ chúng ta thực sự có thể bước vào một thời kỳ hoàng kim của B2B SaaS và nói chung là phần mềm và các startup. Tôi nghĩ đó là một xu hướng thực sự thú vị để theo dõi, bởi vì khi việc xây dựng phần mềm ngày càng dễ dàng hơn, khi việc điều hành một công ty ngày càng dễ dàng hơn, bạn có thể thấy nhiều startup này hơn rất nhiều.

Cách tôi đã suy nghĩ về điều này là: vâng, có thể có một startup tỷ đô một người, nhưng có thể có hàng trăm startup 100 triệu đô la, có thể có hàng chục nghìn startup 10 triệu đô la, và đối với một cá nhân, việc có một công việc kinh doanh 10 triệu đô la thực sự khá tuyệt vời – như thế là đủ để bạn ổn định cuộc sống. Và vì vậy, chúng ta thực sự có thể thấy một sự bùng nổ theo cách đó, và tôi cảm thấy mọi người chưa thực sự tính đến điều đó.

Có một hiệu ứng bậc ba khác đối với điều này – và một lần nữa, tất cả những dự đoán càng xa vời thì càng có nhiều sự không chắc chắn. Tôi nghĩ nếu chúng ta cuối cùng chuyển sang thế giới này, nơi bạn có những công ty siêu nhỏ xây dựng phần mềm phục vụ cho một hoặc hai người sở hữu công ty và làm việc ở đó, tôi nghĩ hệ sinh thái startup sẽ thay đổi, tôi nghĩ hệ sinh thái VC sẽ thay đổi. Chúng ta có thể kết thúc trong một thế giới mà chỉ có một số ít người chơi lớn cung cấp platform và hỗ trợ tất cả các startup này. Nhưng, các loại startup có lợi nhuận theo quy mô quỹ đầu tư mạo hiểm (venture scale return) thực sự có thể tăng gấp 100 hoặc 1000 lần khoản đầu tư của bạn có thể thực sự bị thu hẹp nếu bạn có rất nhiều công ty nhỏ hơn, trị giá từ 10 đến 50 triệu đô la này. Điều này không tốt cho lợi nhuận quỹ đầu tư mạo hiểm vững chắc, nhưng lại rất tốt cho các cá nhân, những cá nhân siêu năng lực hiện đang thực sự dấn thân vào AI để xây dựng những công việc kinh doanh này cho chính họ.

Cái Nhìn Khác Về "`Startup` Tỷ Đô Một Người"

Tôi thích số lượng các hiệu ứng bậc cao mà chúng ta đã đi qua. Tôi muốn nghe hiệu ứng bậc bốn bây giờ, Sherwin. Tôi chỉ đùa thôi. Tôi không thể... bậc bốn quá... quá gigabrain đối với tôi. Tôi không thể nghĩ xa đến thế.

Nó giống như Inception vậy, mọi thứ chậm lại mỗi khi bạn đi sâu hơn vào một thứ, mỗi lớp.

Được rồi. Về startup tỷ đô một người, tôi đã suy nghĩ rất nhiều về điều này bởi vì tôi sẽ không có một startup tỷ đô nào cả vì những gì tôi đang làm không có quy mô quỹ đầu tư mạo hiểm (venture scale) dưới bất kỳ hình thức nào và cũng không có đòn bẩy siêu cao. Nhưng chỉ cần nhìn thấy số lượng ticket hỗ trợ tôi nhận được từ những điều vô lý nhất, tôi khó có thể tưởng tượng một người... Tôi bi quan về startup tỷ đô này. Tôi chỉ muốn chia sẻ suy nghĩ này đơn giản là vì chi phí hỗ trợ, ngay cả khi AI đang giúp bạn ở mức tỷ đô, thì trừ khi ACV (giá trị hợp đồng trung bình hàng năm) của bạn rất cao và bạn có rất ít khách hàng, việc giải quyết hỗ trợ và mọi người nói rằng họ có thể tự giải quyết vấn đề của mình nhưng họ lại gửi email hỗ trợ hỏi về điều này – việc đối phó với điều đó rất khó để mở rộng quy mô theo kinh nghiệm của tôi. Vì vậy, theo ý kiến của tôi, trừ khi bạn có một nhóm nhà thầu (contractors) – mà tôi không biết liệu đó có được tính là một công ty một người hay không – tôi cảm thấy rất khó để mở rộng quy mô một startup tỷ đô mà không có ai giúp bạn ít nhất là công việc hỗ trợ, và AI tôi nghĩ sẽ chỉ giúp bạn được một phần nào đó thôi.

Vì vậy, tôi nghĩ điều đó đúng. Và thực ra, quan điểm của tôi hơi khác một chút, đó là tôi nghĩ rằng podcast của Lenny có thể trở thành một startup tỷ đô. Nhưng điều tôi nghĩ có thể xảy ra là thay vì bạn là người duy nhất phải điều động AI để giải quyết và khắc phục các ticket hỗ trợ đó, tôi nghĩ điều có thể xảy ra là có thể có một loạt các startup khác đang xây dựng phần mềm và được tùy chỉnh siêu đặc biệt cho những gì bạn có thể cần. Và vì vậy, có thể có 10 hoặc 20 startup xây dựng phần mềm hỗ trợ cho podcast và bản tin, và đó có thể là một startup một người. Nó không cần phải là một startup lớn. Và họ có thể dễ dàng viết code cho sản phẩm này. Họ có thể tự xây dựng sản phẩm của riêng mình và vì nó rất phù hợp và độc đáo, và hy vọng hữu ích cho bạn, đó có thể là thứ mà bạn mua với tư cách là startup tỷ đô một người.

Tôi sẽ mua nó. Tôi sẽ mua nó.

Vâng.

Tương lai phát triển phần mềm và công ty `unicorn` một người

Có một câu hỏi là bạn sẽ in-house (tự thực hiện nội bộ) điều gì và outsource (thuê ngoài) điều gì. Điều tôi nghĩ có thể xảy ra là vì chi phí viết phần mềm và xây dựng sản phẩm đang giảm mạnh, bạn có thể sẽ outsource rất nhiều công việc này và qua đó giảm quy mô công ty của mình. Đó là một viễn cảnh mà tôi nghĩ có thể xảy ra. Một lần nữa, có sự bất định cao về những gì sẽ diễn ra ở đây, nhưng kết quả cuối cùng vẫn có thể là một người điều hành một công ty có đòn bẩy cao, khổng lồ và thực sự có thể đạt giá trị một tỷ đô la (unicorn).

(Người phỏng vấn): Tôi có thể thấy điều đó. Tôi cũng nghĩ về Peter tại Clawbots/Moldbot/OpenClaw, về việc anh ấy hiện đang bị "tấn công" bởi rất nhiều yêu cầu, email, tin nhắn, DM (tin nhắn trực tiếp) và PR (yêu cầu kéo mã). Tôi tò mò, và anh ấy thậm chí còn không kiếm được tiền từ việc này.

(Người trả lời): Ừm.

(Người phỏng vấn): Vâng, tôi không thể tưởng tượng được cảm giác của anh ấy bây giờ. Chắc hẳn là cực kỳ điên rồ. Nó có lẽ giống như những tháng sau khi chúng tôi ra mắt Hatch VT, sự điên rồ mà...

(Người trả lời): ...một mình anh ấy đã trải qua.

(Người phỏng vấn): À, tiện thể, anh ấy sẽ xuất hiện trên podcast trong một tuần tới.

(Người phỏng vấn): Ồ, điều đó thật thú vị. Vâng. Có lẽ hiệu ứng cấp độ thứ tư là distribution (phân phối) ngày càng trở nên quan trọng, bởi vì có quá nhiều thứ đang cố gắng thu hút sự chú ý của bạn. Vì vậy, tôi nghĩ những người có lượng khán giả và nền tảng sẽ ngày càng có giá trị, điều này thật tốt.

Triết lý quản lý: Kỹ sư như bác sĩ phẫu thuật

(Người phỏng vấn): Được rồi. Tôi thực sự muốn quay lại vấn đề quản lý của bạn. Tôi thực sự thích sự hiểu biết của bạn về việc dành nhiều thời gian hơn cho những người có hiệu suất cao (top performers) đã thực sự mang lại thành công cho bạn. Khi nghĩ về bạn với tư cách là một manager (quản lý) của một nhóm đang xây dựng nền tảng cung cấp sức mạnh cho toàn bộ nền kinh tế AI – giống như mọi công ty khởi nghiệp về AI đều đang xây dựng dựa trên API của bạn – rõ ràng bạn đang làm rất tốt. Bạn đã học được những bài học quản lý cốt lõi nào khác? Bạn thấy điều gì thực sự quan trọng và là chìa khóa cho thành công của bạn với tư cách là một manager của các kỹ sư và mọi người?

(Người trả lời): Vâng. Ừm, tôi nghĩ rằng nhiều bài học tôi đã học được ở đây, tôi không rõ chúng có đặc thù đối với OpenAI API hay các sản phẩm doanh nghiệp của chúng tôi nói riêng không. Tôi nghĩ triết lý quản lý của tôi rõ ràng đã thay đổi theo thời gian, nhưng tôi nghĩ nó có lẽ đã duy trì sự nhất quán hơn là thay đổi. Một trong những nguyên tắc đó là điều tôi đã nói với bạn trước đây: dành nhiều thời gian với những người có hiệu suất cao (top performers), thực sự dành – và để cụ thể hóa – hơn 50% thời gian của bạn cho những top performers của bạn, có lẽ là 10% top performers hàng đầu của bạn, và thực sự cố gắng hết sức để trao quyền cho họ.

Cách tôi suy nghĩ về điều này là quay trở lại phép ẩn dụ về kỹ sư phần mềm như một bác sĩ phẫu thuật – điều này đến từ cuốn sách The Mythical Man-Month. Thật thú vị, tôi lấy ý tưởng này từ cuốn sách, nhưng trong sách, họ thực sự mô tả một thế giới mà tôi nghĩ họ đang dự đoán tương lai, vì cuốn sách được viết vào khoảng những năm 70. Họ nói rằng kỹ thuật phần mềm có thể sẽ chuyển sang một thế giới nơi các kỹ sư phần mềm giống như các bác sĩ phẫu thuật trong phòng mổ, chỉ có một người làm việc. Một người sẽ thực hiện các thao tác cắt hoặc phẫu thuật, và mọi người khác trong phòng chỉ ở đó để hỗ trợ họ, đúng không? Như y tá, bác sĩ nội trú, và bác sĩ chuyên khoa. Khi bác sĩ phẫu thuật nói 'Tôi cần một dao mổ', họ sẽ đưa dao mổ. Rồi họ nói 'Tôi cần công cụ này và máy móc này', và những người khác sẽ mang đến. Mọi người đều ở đó để hỗ trợ một bác sĩ phẫu thuật duy nhất.

Và vì vậy, cuốn The Mythical Man-Month thực sự đã dự đoán rằng đó là hướng mà kỹ sư phần mềm sẽ phát triển. Tôi không nghĩ điều đó đã diễn ra chính xác như vậy, nơi mà công việc mang tính hợp tác hơn nhiều và không chỉ một người làm việc, nhưng tôi luôn thực sự thích phép ẩn dụ đó. Và phép ẩn dụ đó thực sự là điều tôi cố gắng mô phỏng trong triết lý quản lý của mình, đó là: kỹ thuật phần mềm không thực sự giống như phẫu thuật khi không chỉ một người làm việc, nhưng cách tôi đối xử với những người trong nhóm của mình và cách tôi hành động với tư cách là một manager là tôi muốn trao quyền cho họ, khiến họ cảm thấy như một bác sĩ phẫu thuật, và đảm bảo rằng tôi đang hỗ trợ họ, đảm bảo họ có mọi thứ cần thiết để làm việc của mình. Họ cảm thấy như có cả một đội quân người đang hỗ trợ họ, nhìn trước các góc khuất và cung cấp mọi thứ họ cần, trong khi thực ra chỉ có mình tôi là manager.

Ví dụ tôi đưa ra là việc nhìn trước các góc khuất và tháo gỡ khó khăn cho mọi người, đặc biệt từ góc độ tổ chức, là cực kỳ hữu ích. Và một lần nữa, quay lại các cuộc trò chuyện về AI, điều này thậm chí còn quan trọng hơn hiện nay, đúng không? Nếu mọi người chỉ liên tục tạo PR (yêu cầu kéo mã), điều chính gây tắc nghẽn tiến độ và việc shipping (phát hành) một cái gì đó thường là do tổ chức hoặc quy trình. Và nếu bạn là một manager có thể nhìn trước các góc khuất và tháo gỡ khó khăn cho nhóm, ví dụ, nếu bác sĩ phẫu thuật cần dao mổ mà manager đã có sẵn dao mổ cho họ, đó là kịch bản tốt nhất. Đó là cách tôi tiếp cận quản lý và đặc biệt là quản lý kỹ thuật. Và đó là điều thực sự đã đọng lại trong tôi theo thời gian. Và mặc dù các kỹ sư phần mềm không hẳn là bác sĩ phẫu thuật, phép ẩn dụ đó luôn ở trong tâm trí tôi suốt phần còn lại của sự nghiệp.

`AI` hỗ trợ phát hiện và dự đoán `blocker`

(Người phỏng vấn): Tôi thích điều đó. Và tôi tự hỏi liệu AI có thể giúp nhìn trước các góc khuất và dự đoán: kỹ sư này sẽ bị chặn bởi quyết định này, chúng ta cần tìm ra giải pháp, chúng ta cần...

(Người trả lời): Vâng, đó thực sự là một điểm rất hay. Tôi chưa thử điều này, nhưng tôi tự hỏi điều gì sẽ xảy ra nếu tôi hỏi AI ChatGPT được kết nối với kiến thức công ty, ví dụ: những blocker (yếu tố gây tắc nghẽn) nào đang hoạt động? Hãy xem qua tất cả các tài liệu Notion hoặc có thể là tin nhắn Slack, bạn biết đấy, có lẽ nó nằm ở đâu đó trong Slack. Những blocker nào đang hoạt động trong nhóm của tôi và liệu tôi có thể làm gì để giúp đỡ? Ừm, tôi chưa từng nghĩ về điều đó, nhưng bạn nói đúng.

(Người phỏng vấn): Bạn vừa có một insight (cái nhìn sâu sắc) ngay đây.

(Người trả lời): Vâng. Vâng. Vâng.

(Người phỏng vấn): Và tôi nghĩ điều thú vị hơn nữa là, bạn dự đoán điều gì sẽ là blocker cho kỹ sư này hoặc nhóm này trong những tháng tới?

(Người trả lời): Vâng. Bạn đã yêu cầu AI làm những việc cấp độ thứ hai và thứ ba. Dự đoán điều đó đi, bạn. Dự đoán blocker sẽ là gì vào tháng tới nữa. À,

(Người phỏng vấn): Tôi nghĩ chúng ta đã có một ý tưởng hay ngay đây.

(Người trả lời): Vâng. Vâng.

Quảng cáo: DataDog

Tập này được tài trợ bởi Data Dog, hiện là nơi của EPO, nền tảng thử nghiệm và gắn cờ tính năng hàng đầu. Các quản lý sản phẩm tại các công ty tốt nhất thế giới sử dụng Data Dog, cùng nền tảng mà các kỹ sư của họ dựa vào mỗi ngày để kết nối thông tin chi tiết về sản phẩm với các vấn đề sản phẩm như lỗi, ma sát UX (trải nghiệm người dùng kém) và tác động kinh doanh.

Nó bắt đầu với phân tích sản phẩm nơi các quản lý sản phẩm có thể xem replay (phát lại), đánh giá phễu, nghiên cứu khả năng giữ chân người dùng và khám phá các chỉ số tăng trưởng của họ. Nơi các công cụ khác dừng lại, Data Dog còn tiến xa hơn. Nó giúp bạn thực sự chẩn đoán tác động của việc giảm tỷ lệ chuyển đổi, lỗi và ma sát UX. Một khi bạn biết nên tập trung vào đâu, các thử nghiệm sẽ chứng minh điều gì hiệu quả.

Tôi đã tận mắt chứng kiến điều này khi tôi ở Airbnb, nơi nền tảng thử nghiệm của chúng tôi rất quan trọng để phân tích điều gì hiệu quả và những điều gì đã sai. Và cùng một nhóm đã xây dựng nền tảng thử nghiệm tại Airbnb đã xây dựng EPO. Data Dog sau đó cho phép bạn vượt xa các con số với phát lại phiên (session replay). Xem chính xác cách người dùng tương tác với bản đồ nhiệt và bản đồ cuộn để thực sự hiểu hành vi của họ. Và tất cả điều này được cung cấp bởi các cờ tính năng (feature flags) được liên kết với dữ liệu thời gian thực để bạn có thể triển khai an toàn, nhắm mục tiêu chính xác và học hỏi liên tục. Data Dog không chỉ là các chỉ số kỹ thuật. Đó là nơi các đội ngũ sản phẩm tuyệt vời học hỏi nhanh hơn, khắc phục thông minh hơn và phát hành với sự tự tin. Yêu cầu demo tại datadoghq.com/lenny. Đó là datadoghq.com/lenny.

Thực trạng triển khai `AI` với `ROI` âm

(Người phỏng vấn): Được rồi, tôi sẽ chuyển sang nói về API và nền tảng mà tất cả các bạn xây dựng. Bạn làm việc với rất nhiều công ty triển khai API và nền tảng của mình, xây dựng trên các công cụ của bạn. Bạn nói với tôi rằng bạn thấy nhiều công ty thực sự có ROI (tỷ suất hoàn vốn) âm đối với các triển khai AI của họ, điều mà tôi nghĩ là nhiều người đã đọc, cảm nhận và suy nghĩ. Thật thú vị khi bạn thực sự đang thấy điều đó. Chuyện gì đang xảy ra vậy? Họ đang làm gì sai? Điều gì đang xảy ra trong thế giới AI và các triển khai với ROI?

(Người trả lời): Vâng. Để rõ ràng, tôi không thực sự thấy các con số định lượng về điều này. Bạn biết đấy, rất khó để đo lường những điều này, nhưng đặc biệt khi quan sát một số công ty đang cố gắng triển khai AI, tôi sẽ không ngạc nhiên nếu nhiều triển khai AI thực sự có ROI âm. Ý tôi là, một phần của điều này là tôi nghĩ cũng có một tâm lý chung từ những người dân trên khắp đất nước, những người về cơ bản là nằm ngoài ngành công nghệ, rằng AI đang bị ép buộc lên họ. Và tôi nghĩ một phần của điều này có lẽ là một triệu chứng của một số triển khai AI có ROI âm.

Một vài điều tôi đã quan sát được về điều này. Một điều là – và tôi nghĩ tôi nhắc lại điều này nhiều lần – chúng ta ở Thung lũng Silicon chỉ đơn giản là quên rằng chúng ta đang sống trong một bong bóng. Giống như chúng ta đang rất, Twitter là một bong bóng, xin lỗi, X là một bong bóng. Thung lũng Silicon là một bong bóng. Kỹ thuật phần mềm là một bong bóng. Hầu hết mọi người trên thế giới, hầu hết mọi người ở Mỹ, không phải là kỹ sư phần mềm, không hiểu rõ về AI hay không theo dõi mọi bản phát hành mô hình mới. Và vì vậy, chúng ta hoàn toàn lạc hậu về cách sử dụng công nghệ này.

Vì vậy, bạn biết đấy, chúng ta luôn nói về tất cả những thực tiễn tốt nhất cho codec, tất cả những codec mà những người trong OpenAI xây dựng. Tôi chắc chắn rằng mọi người trên X đăng bài đều là những người dùng thành thạo (power users) của những công cụ AI này, bạn biết đấy, họ dựa vào kỹ năng, họ dựa vào agent. MCPS. Vâng. Vâng. Tất cả những thứ đó. Và khi tôi nói chuyện với một số công ty này và tôi nói chuyện với những nhân viên thực sự đang sử dụng chúng, họ đang cố gắng làm những điều cơ bản nhất và họ hiểu rất ít về cách công nghệ này hoạt động chính xác. Và đó là một quan sát lớn đối với tôi, đó là họ đang yêu cầu AI những câu hỏi rất đơn giản. Họ thực sự chưa thúc đẩy nó.

Và điều đó quay trở lại và liên quan đến những gì tôi nghĩ nhiều công ty nên làm, hoặc có thể làm, hoặc một thiết lập triển khai AI lý tưởng hơn trông như thế nào. Và đây cũng là cách chúng tôi đã vận hành mọi thứ trong OpenAI. Các công ty mà tôi nghĩ nó bắt đầu hoạt động rất tốt đều có sự kết hợp giữa sự ủng hộ từ trên xuống (top-down buy-in). Tức là, từ C-suite (cấp điều hành), họ nói rằng chúng tôi muốn trở thành một công ty ưu tiên AI (AI-first company). Vì vậy, có sự ủng hộ, họ mua công cụ, họ có sự hỗ trợ điều hành, nhưng nó cũng có sự chấp nhận và ủng hộ từ dưới lên (bottoms-up adoption and buy-in). Ý tôi là, có những nhân viên thực sự đang làm việc, những người thực sự hào hứng với công nghệ và sẵn sàng học hỏi, truyền bá, xây dựng thực tiễn tốt nhất và chia sẻ kiến thức trong tổ chức. Chúng tôi đã thấy điều này rất nhiều trong nội bộ.

Thúc Đẩy Áp Dụng AI Từ Dưới Lên

OpenAI luôn mong muốn trở thành một công ty tập trung vào AI. Nhưng khi mọi thứ thực sự bắt đầu cất cánh là khi codec và các công cụ này được giới thiệu, giúp chính các nhân viên có thể bắt đầu áp dụng chúng vào công việc của mình. Tôi nghĩ bạn thực sự cần điều này bởi vì, cuối cùng, công việc của mỗi người rất khác nhau, rất độc đáo. Kỹ thuật phần mềm khác với tài chính, khác với vận hành, khác với tiếp cận thị trường và bán hàng. Vì vậy, có rất nhiều những chi tiết phức tạp cuối cùng trong công việc cần được thực hiện theo phương pháp từ dưới lên.

Cảm nhận của tôi là nhiều triển khai AI này không có sự áp dụng từ dưới lên. Nó giống như một chỉ đạo điều hành và cực kỳ từ trên xuống, rất tách rời khỏi thực tế công việc. Kết quả là, bạn có một lực lượng lao động khổng lồ không thực sự hiểu công nghệ. Họ kiểu như, "Tôi biết tôi phải sử dụng cái này, và có thể nó cũng nằm trong đánh giá hiệu suất của tôi, nhưng tôi không chắc phải làm gì." Và họ nhìn xung quanh, không ai khác làm điều đó. Không có ai để học hỏi.

Vì vậy, lời khuyên của tôi cho các công ty đang thúc đẩy điều này là hãy tìm, hoặc thậm chí tuyển dụng/bố trí nhân sự một đội ngũ toàn thời gian trong nội bộ – một kiểu đội đặc nhiệm (tiger team) – có thể khám phá toàn bộ khả năng, áp dụng chúng vào các quy trình làm việc (workflow) cụ thể, thực hiện chia sẻ kiến thức, tạo sự hào hứng trong những người có thể muốn sử dụng công nghệ này, bởi vì nếu không có điều đó, việc tiếp thu thực sự rất khó khăn.

Thành Phần Lý Tưởng Cho Đội Đặc Nhiệm AI

"Và bạn sẽ chọn ai vào đội đặc nhiệm (tiger team) này? Liệu có phải là những người do kỹ sư dẫn dắt không? Theo kinh nghiệm của bạn, đó có phải là một đội ngũ đa chức năng (cross-functional team) không?"

"Vâng, điều này khá thú vị. Nhiều công ty không có kỹ sư. Và mô hình tôi thấy là những người liên quan đến kỹ thuật phần mềm (software engineering adjacent) – về cơ bản là những người có nền tảng kỹ thuật (technical background) nhưng không phải kỹ sư (software engineers). Tôi nghĩ đó là những người có xu hướng hào hứng nhất với điều này. Giống như, có thể là trưởng nhóm vận hành hỗ trợ (support team operations lead) – người không lập trình (code) nhưng lại yêu thích sử dụng các công cụ này và là một phù thủy Excel (Excel wizard) chẳng hạn. Vì vậy, đó là những người có kỹ năng liên quan đến kỹ thuật (technical adjacent) hoặc liên quan đến lập trình (coding adjacent) và khá am hiểu kỹ thuật (technical). Đó là những kiểu người tôi thấy ở các công ty thực sự bùng cháy và hào hứng với điều này. Bạn thường có thể xây dựng một đội ngũ xung quanh đó. Nhưng vâng, thường thì đó không phải là kỹ sư. Kỹ sư, tôi nghĩ, sẽ hiểu điều này, nhưng không phải công ty nào cũng có kỹ sư. Thực ra đó là một điều khá hiếm có. Họ khó tìm và đắt đỏ. Vì vậy, đó là những kiểu người khác."

Mô Hình Phản Tác Dụng Và Lời Khuyên

"Điều tôi đang nghe là mô hình phản tác dụng (anti-pattern) là từ trên xuống. Đây là việc CEO và Đội ngũ điều hành (exec team) chỉ đơn thuần nói rằng chúng ta sẽ ưu tiên AI (AI first). Chúng ta sẽ đi sâu vào AI. Mọi người sẽ được đánh giá hiệu suất dựa trên việc sử dụng công cụ AI (AI tools), năng suất (productivity) của bạn tăng lên bao nhiêu nhờ AI. Và khi việc này chỉ mang tính từ trên xuống và không tạo ra một đội ngũ lan tỏa từ dưới lên, bạn thấy nó không hiệu quả."

"Vâng. Vâng. Chính xác. Chính xác."

"Và lời khuyên là hãy tìm những người hào hứng nhất, và thay vì để họ phân tán khắp tổ chức, bạn nhận thấy cách hiệu quả là tạo một đội ngũ truyền bá AI (AI evangelist team) nhỏ để tìm cách sử dụng nó và lan tỏa trong công việc."

"Vâng, khi nghe bạn nhắc lại, một cách khác để suy nghĩ về nó, liên hệ với triết lý quản lý (management philosophies) của tôi, là hãy tìm những người có thành tích cao (high performers) trong việc áp dụng AI và trao quyền cho họ. Hãy để họ tổ chức các hackathon, hội thảo, chia sẻ kiến thức, và gieo mầm sự hào hứng trong nội bộ. Tuyệt vời."

Nghe Khách Hàng Trong Lĩnh Vực AI: Con Dao Hai Lưỡi

Có một vài nhận định táo bạo (hot takes) tôi muốn nghe từ bạn. Một điều tôi thấy bạn đã nói và chia sẻ là việc trò chuyện và lắng nghe khách hàng không phải lúc nào cũng là chiến lược đúng đắn trong AI và có thể thường xuyên đưa bạn đi sai hướng.

"Tôi không biết liệu đó có phải là một nhận định táo bạo (hot take) đến vậy không. Điều chính ở đây là rõ ràng bạn nên nói chuyện với khách hàng – việc đó hữu ích. Tôi chỉ nghĩ rằng lĩnh vực AI, đặc biệt là những gì tôi đã thấy trong khoảng ba năm qua khi làm việc với API và chứng kiến tất cả những thay đổi đó, là lĩnh vực và bản thân các mô hình đang thay đổi quá nhanh đến mức chúng có xu hướng tự phá vỡ chính mình, đặc biệt là trong không gian công cụ (tooling) và khung hỗ trợ (scaffolding)."

"Vì vậy, có một trích dẫn tôi đã đọc vào đầu tuần này từ một bài viết của Nicholas, nhà sáng lập (founder) của một startup tên là FinTool – nơi mà tôi nghĩ anh ấy đã chia sẻ nhiều thực tiễn tốt nhất (best practices) học được qua việc xây dựng tác nhân AI (AI agents) cho dịch vụ tài chính (financial services) tại startup FinTool. Anh ấy có một câu nói mà tôi nghĩ rất hay: 'Các mô hình sẽ nuốt chửng khung hỗ trợ (scaffolding) của bạn vào bữa sáng.'"

Mô Hình Phát Triển và Các Khung Hỗ Trợ AI

Nếu bạn nhìn lại năm 2022, ngay khi ChatGPT ra mắt, các mô hình này còn khá thô sơ và có rất nhiều khung hỗ trợ sản phẩm (product scaffolding) cũng như các thứ khác, đặc biệt là trong lĩnh vực phát triển, để cố gắng điều hướng mô hình và xây dựng một khung hỗ trợ (scaffolding) xung quanh nó để đạt được điều bạn muốn, như các khung tác nhân (agent frameworks), các kho vector (vector stores) tôi nghĩ đã rất phổ biến vào thời điểm đó, và cả một loạt các công cụ khác.

Như bạn đã thấy lĩnh vực này phát triển, các mô hình đã thay đổi rất nhiều và trở nên tốt hơn đến mức chúng thực sự đã nuốt chửng một phần khung hỗ trợ (scaffolding). Và tôi nghĩ điều này vẫn đúng cho đến ngày nay. Theo bài viết của Nicholas, khung hỗ trợ (scaffolding) hiện tại đang thịnh hành là quản lý ngữ cảnh (context management) dựa trên tệp kỹ năng (skills files). Tôi có thể hình dung một thế giới nơi mà tại một thời điểm nào đó, điều đó sẽ không còn hữu ích, khi mô hình thực sự có thể tự quản lý tất cả hoặc chuyển sang một mô hình mới (new paradigm) mà bạn không cần kỹ năng dựa trên tệp (file based skills) này.

Bạn đã thực sự chứng kiến điều này xảy ra, phải không? Các khung tác nhân (agent frameworks) tôi nghĩ giờ đây ít hữu ích hơn một chút. Có một khoảng thời gian vào năm 2023 mà chúng ta nghĩ rằng kho vector (vector stores) sẽ là cách chính để bạn đưa ngữ cảnh tổ chức (organizational context) vào các mô hình, và bạn cần phải vectorize và nhúng (embed) mọi bit dữ liệu của mình, sau đó làm tất cả công việc để tìm ra tìm kiếm vector (vector search) nhằm tối ưu hóa việc điền đúng thông tin vào đúng thời điểm. Tất cả những điều đó đều là khung hỗ trợ (scaffolding) vì mô hình khi đó chưa đủ tốt. Và hóa ra, trong trường hợp này, khi các mô hình trở nên tốt hơn, một cách tiếp cận tốt hơn thực sự là loại bỏ nhiều logic đó và tin tưởng mô hình, cung cấp cho nó một bộ công cụ để tìm kiếm. Nó không cần phải là một kho vector (vector store). Bạn thực sự có thể kết nối nó với bất kỳ loại tìm kiếm nào. Nó có thể chỉ đơn thuần là các tệp trên một hệ thống tệp (file system) như kỹ năng (skills) và agent MD để điều hướng nó.

Rõ ràng, kho vector (vector stores) vẫn có chỗ đứng. Tôi biết nhiều công ty vẫn đang sử dụng chúng, nhưng toàn bộ khung hỗ trợ (scaffolding) xung quanh đó và việc xây dựng toàn bộ hệ sinh thái (ecosystem) xung quanh đó, giả định rằng đó là khung hỗ trợ duy nhất bạn cần, đã thực sự thay đổi. Vì vậy, liên hệ điều này trở lại với việc bạn không phải lúc nào cũng phải lắng nghe khách hàng của mình, bởi vì lĩnh vực này đang thay đổi quá nhiều. Tại bất kỳ thời điểm nào, rất nhiều người đang ở một cực đại cục bộ (local maximum), và nếu bạn chỉ mù quáng lắng nghe khách hàng của mình, họ sẽ nói: "Vâng, tôi muốn một kho vector tốt hơn", hay "tôi muốn một khung tác nhân (agent framework) tốt hơn cho cái này". Và nếu bạn chỉ theo đuổi con đường đó, nó thực sự sẽ dẫn bạn đến việc xây dựng một thứ mà một lần nữa lại là cực đại cục bộ (local maximum). Trong khi đó, khi các mô hình trở nên tốt hơn, chúng ta đã phải tái tạo và suy nghĩ lại về các trừu tượng hóa (abstractions) phù hợp và các công cụ (tools) cũng như khung (frameworks) phù hợp để xây dựng xung quanh các mô hình này.

Và phần thú vị / hào hứng / hơi điên rồ và khó chịu là nó là một mục tiêu di động (moving target). Vì vậy, vâng, tập hợp các công cụ và khung (smattering of tools and frameworks) hiện tại có thể sẽ cần phải phát triển và thay đổi đáng kể theo thời gian khi các mô hình trở nên thông minh hơn và tốt hơn. Nhưng đó chỉ là bản chất của việc xây dựng trong lĩnh vực này. Tôi nghĩ đó là điều làm cho nó trở nên thú vị. Nhưng điều đó cũng có nghĩa là khi bạn nói chuyện với khách hàng, bạn cần phải cân bằng phản hồi (feedback) chính xác mà họ muốn với việc bạn nghĩ các mô hình đang đi đến đâu và mọi thứ sẽ xu hướng (trend) như thế nào trong một đến hai năm tới.

Bài Học Cay Đắng và Tầm Nhìn Phát Triển AI

Thật thú vị khi đây là bài học cay đắng (the bitter lesson) – một bài học lớn mà những người làm AI và học máy (ML folks) đã rút ra, đó là càng ít phức tạp hóa (overcomplicate), càng ít logic bạn thêm vào học máy (machine learning) hay AI, thì nó càng có khả năng mở rộng và phát triển (scale and grow). Hãy loại bỏ tất cả và để nó tự tính toán, về cơ bản là cung cấp cho nó nhiều sức mạnh hơn để tự trở nên thông minh hơn.

Vâng, thực sự có một phiên bản của bài học cay đắng (the bitter lesson) được áp dụng cho việc xây dựng với AI, nơi mà chúng ta đã cố gắng kiến trúc (architect) tất cả những thứ xung quanh, và hóa ra các mô hình chỉ đơn giản là nuốt chửng tất cả. Và thành thật mà nói, đội ngũ API của OpenAI cũng đã từng mắc lỗi này, khi chúng tôi đã rẽ trái, rẽ phải những lúc không cần thiết. Nhưng vâng, các mô hình vẫn tốt hơn, và tất cả chúng ta đều đang học bài học cay đắng (the bitter lesson) mỗi ngày.

"Vậy, điều mấu chốt (key takeaway) dành cho những người xây dựng trên API hoặc chỉ xây dựng các tác nhân (agents) và phải xây dựng một chút khung hỗ trợ xung quanh chúng hiện tại là gì? Lời khuyên của bạn là gì?"

"Lời khuyên chung của tôi, và tôi đã đưa ra điều này cho mọi người trong một thời gian dài và tôi nghĩ rằng nó vẫn đúng cho đến ngày nay, là hãy đảm bảo bạn đang xây dựng cho nơi các mô hình đang hướng tới, chứ không phải nơi chúng đang ở hiện tại. Nó rõ ràng là một mục tiêu di động (moving target), và tôi nghĩ rất nhiều công ty, các startup mà tôi đã thấy thực sự thành công là họ xây dựng một sản phẩm cho một khả năng lý tưởng (ideal capability) mà hiện tại có thể chỉ đạt được 80%. Và họ cuối cùng có một sản phẩm gần như hoạt động, gần như hoàn hảo, nhưng sau đó khi các mô hình tốt hơn, đột nhiên nó có thể 'khớp' và sản phẩm của họ trở nên đáng kinh ngạc vì nó hoạt động. Giống như, có thể với GPT-3, tại một thời điểm nào đó nó đột nhiên hoạt động với GPT-5.1, GPT-5.2 thì đột nhiên nó được khai mở. Nhưng họ đang xây dựng những sản phẩm này với những cải tiến khả năng của mô hình (model capability improvements) trong tâm trí. Và với điều đó, bạn sẽ tạo ra một trải nghiệm tốt hơn nhiều so với việc bạn giả định rằng nó tĩnh (static) ngay từ đầu. Và đó sẽ là lời khuyên chung của tôi, đó là hãy xây dựng cho nơi các mô hình đang hướng tới chứ không phải nơi chúng đang ở hiện tại. Bạn sẽ xây dựng được một sản phẩm tốt hơn. Bạn có thể cần phải chờ đợi một chút, nhưng các mô hình đang trở nên tốt hơn rất nhanh chóng, nên bạn thường không cần phải chờ đợi quá lâu."

Hướng Đi Tương Lai Của API và Mô Hình AI

"Vậy để theo dõi dòng suy nghĩ đó, trong 6 đến 12 tháng tới, API sẽ đi đến đâu? Nền tảng sẽ đi đến đâu? Các mô hình sẽ đi đến đâu? Bạn có thể chia sẻ bao nhiêu tùy ý, tôi biết có rất nhiều bí mật ở đây mà có thể bạn hào hứng nhất hoặc bạn nghĩ rằng mọi người nên chuẩn bị cho điều gì và bạn có thể chia sẻ bao nhiêu?"

"Vâng, điều hiển nhiên nhất là độ dài của một nhiệm vụ mà các mô hình này có thể thực hiện một cách nhất quán (coherently)."

Thời Gian Thực Hiện Tác Vụ của AI và Xu Hướng Phát Triển

Có một tiêu chuẩn meter benchmark mà tôi nghĩ là theo dõi các tác vụ kỹ thuật phần mềm và thời gian mà các mô hình này có thể hoàn thành, cụ thể là 50% hoặc 80% số tác vụ. Tôi nghĩ chúng ta đang ở mức các tác vụ kỹ thuật phần mềm kéo dài nhiều giờ có thể được hoàn thành bởi các mô hình tiên tiến này 50% thời gian, và 80% là các tác vụ dưới một giờ. Nhưng điều đáng suy ngẫm về biểu đồ đó là họ cũng vẽ tất cả các mô hình trước đó lên cùng biểu đồ. Vì vậy, bạn thực sự có thể thấy xu hướng này. Đó là điều tôi thực sự rất hào hứng, tức là tôi thực sự nghĩ rằng các sản phẩm hiện nay tối ưu hóa cho các tác vụ mà mô hình có thể làm trong vài phút. Ngay cả codecs và các công cụ lập trình, tôi có thể nói rằng bạn thấy nó tương tác trong CLI. Nó thực sự được tối ưu hóa tốt cho các tác vụ kéo dài tối đa 10 phút. Tôi đã thấy mọi người đẩy codecs đến giới hạn và thực hiện các tác vụ kéo dài nhiều giờ. Nhưng một lần nữa, tôi nghĩ đó là ngoại lệ. Tuy nhiên, nếu bạn theo dõi xu hướng này, tôi nghĩ trong 12 đến 18 tháng tới, chúng ta có thể thấy các mô hình có thể thực hiện các tác vụ kéo dài nhiều giờ một cách rất mạch lạc. Đến một lúc nào đó, nó có thể đạt đến mức tác vụ kéo dài 6 giờ mỗi ngày, nơi bạn có thể điều phối nó và để nó tự thực hiện công việc trong một thời gian. Các loại sản phẩm bạn xây dựng xung quanh đó sẽ rất khác biệt. Bạn muốn cung cấp phản hồi cho mô hình. Rõ ràng bạn không muốn nó hoàn toàn tự ý hoạt động cả ngày. Có thể bạn muốn, nhưng có lẽ là không. Và sau đó, phạm vi những việc bạn có thể giao cho mô hình làm sẽ thực sự mở rộng. Đó là điều tôi thực sự rất hào hứng khi được chứng kiến.

Cải Tiến Mô Hình Đa Phương Thức, Đặc Biệt là Âm Thanh

Một điều nữa trong 12 đến 18 tháng tới mà tôi nghĩ sẽ rất tuyệt vời là những cải tiến trong các mô hình đa phương thức. Và thực ra, khi nói về đa phương thức, tôi chủ yếu nghĩ đến âm thanh ở đây, nơi các mô hình khá tốt với âm thanh. Tôi nghĩ chúng sẽ trở nên tốt hơn rất nhiều với âm thanh trong 6 đến 12 tháng tới, đặc biệt là các mô hình đa phương thức tự nhiên, các mô hình chuyển đổi giọng nói sang giọng nói. Tôi nghĩ cũng có những nghiên cứu thú vị đang được thực hiện xung quanh các loại mô hình và kiến trúc mới về phía âm thanh đa phương thức. Nhưng âm thanh, đặc biệt trong môi trường doanh nghiệp và kinh doanh, tôi nghĩ vẫn là một lĩnh vực bị đánh giá thấp rất lớn. Mọi người đều nói về lập trình, mọi thứ đều là văn bản, nhưng chúng ta đang nói chuyện bằng âm thanh. Rất nhiều hoạt động kinh doanh trên thế giới được thực hiện qua âm thanh. Rất nhiều dịch vụ và hoạt động được thực hiện qua việc nói và âm thanh. Vì vậy, tôi nghĩ lĩnh vực đó sẽ trông rất thú vị trong 12 đến 18 tháng tới. Và tôi nghĩ sẽ có nhiều đột phá hơn nữa cho những gì chúng ta có thể làm với các mô hình âm thanh ở đó.

Tóm Tắt Xu Hướng Phát Triển AI

Tuyệt vời. Tóm tắt nhanh gọn: Hãy kỳ vọng các tác nhân và công cụ AI sẽ hoạt động lâu hơn, quỹ đạo đó sẽ tiếp tục tăng, và sau đó âm thanh cùng giọng nói sẽ trở thành một vấn đề lớn hơn, được ưu tiên hơn, tự nhiên hơn, tốt hơn và trở thành trọng tâm của trải nghiệm.

Tự Động Hóa Quy Trình Nghiệp Vụ - Một Cơ Hội Lớn

Vâng, cực kỳ tuyệt vời. Được rồi, tôi muốn quay lại một trong những quan điểm táo bạo khác của bạn mà tôi từng thấy bạn thảo luận. Bạn rất lạc quan về tự động hóa quy trình nghiệp vụ như một cơ hội trong thế giới AI. Hãy nói về điều đó. Vâng, điều này quay trở lại những gì tôi đã nói trước đây, đó là chúng ta đang sống trong một bong bóng ở Thung lũng Silicon, và rất nhiều công việc mà chúng ta làm – những công việc chúng ta quen thuộc như kỹ thuật phần mềm, quản lý sản phẩm, xây dựng sản phẩm – có hình dạng rất khác so với những công việc đang diễn ra và vận hành toàn bộ nền kinh tế của chúng ta. Tôi thấy điều này liên tục khi nói chuyện với khách hàng. Nếu bạn nói chuyện với bất kỳ công ty nào không phải là công ty công nghệ, thì có rất nhiều quy trình nghiệp vụ.

Và ý tôi ở đây là, tôi thường phân định nó như sau: kỹ thuật phần mềm giống như một công việc tri thức mở, đúng không? Và đây là lý do tại sao tôi nghĩ các công cụ như codecs có xu hướng khá tốt, vì nó mang tính khám phá và bạn đang cung cấp cho nó những thứ mở như vậy, nhưng kỹ thuật phần mềm về cơ bản là khá mở và không lặp lại được. Tức là, bạn xây dựng một tính năng, bạn không cố gắng xây dựng chính xác tính năng đó lặp đi lặp lại. Và rất nhiều công việc công nghệ nằm trong không gian này. Tôi nghĩ khoa học dữ liệu cũng nằm trong không gian này. Ngay cả một số công việc tài chính chiến lược cũng vậy. Nhưng khi bạn rời xa kỹ thuật phần mềm và những gì là cốt lõi trong công nghệ, rất nhiều công việc chỉ là quy trình nghiệp vụ. Chúng là những việc lặp lại, những hoạt động lặp lại mà một người quản lý tại một công ty nào đó đã lặp đi lặp lại. Thường có một quy trình vận hành tiêu chuẩn mà mọi người muốn thực hiện. Và bạn không muốn đi chệch khỏi nó nhiều. Bạn biết đấy, trong kỹ thuật phần mềm, sự khéo léo nằm ở việc đi chệch khỏi cái cũ, nhưng rất nhiều công việc đang được thực hiện trên thế giới thực ra chỉ là việc chạy qua các quy trình và hoạt động này. Nếu tôi gọi đến một đường dây hỗ trợ, họ đang thực hiện một trong các quy trình này. Nếu tôi gọi công ty điện nước của mình, có một loạt các quy trình và những điều mà họ có thể và không thể làm cho tôi.

Vì vậy, tôi cực kỳ lạc quan về lĩnh vực tổng quát này, và tôi nghĩ nó bị đánh giá thấp vì nó quá khác biệt so với những gì chúng ta nghĩ ở Thung lũng Silicon, mọi người có xu hướng không nghĩ về nó. Nhưng làm thế nào chúng ta có thể áp dụng AI và một số công cụ, khuôn khổ mà chúng ta có để tự động hóa quy trình nghiệp vụ này? Làm thế nào để tự động hóa và làm cho các quy trình nghiệp vụ lặp lại với tính xác định cao trở nên dễ dàng hơn? Điều đó được tích hợp hoàn toàn với dữ liệu nghiệp vụ và các quyết định kinh doanh, cũng như các hệ thống khác nhau trong một doanh nghiệp. Và làm thế nào chúng ta có thể thực sự làm cho quy trình đó tốt hơn? Bởi vì tôi thực sự nghĩ có rất nhiều cơ hội và rất nhiều việc phải làm trong lĩnh vực đó, và chúng ta chỉ là không nói về nó vì nó hơi ít nằm trong phạm vi hiểu biết của chúng ta.

Phạm Vi Tác Động Của AI Ngoài Kỹ Thuật

Vì vậy, quan điểm của bạn ở đây, để tôi chắc chắn rằng mình hiểu đầy đủ, là bạn nghĩ có một cơ hội lớn hơn nhiều bên ngoài kỹ thuật để AI tác động đến năng suất của các công ty và cả công việc của những người đang thực hiện các tác vụ lặp đi lặp lại, dễ tự động hóa này? Tác động đến công việc và cả cách thức công việc được thực hiện. Rất nhiều công việc được thực hiện theo cách này. Bạn nghĩ về... bạn biết đấy, ví dụ như chúng tôi luôn nói chuyện với các khách hàng là các doanh nghiệp lớn về việc AI sẽ biến đổi công ty của họ như thế nào, nó sẽ vận hành như thế nào trong một thế giới có AI trong 20 năm tới. Và, bạn biết đấy, kỹ thuật phần mềm là một phần của câu chuyện, nhưng còn rất nhiều điều khác ở khía cạnh quy trình nghiệp vụ. Và tôi thực sự nghĩ rằng nó có thể trông còn khác biệt hơn nữa ở khía cạnh quy trình nghiệp vụ. Và công việc ở đó là khá đáng kể. Thực ra thì thú vị. Tôi không biết, xét về tỷ lệ phần trăm tuyệt đối hay cơ sở tuyệt đối, liệu nó có lớn hơn hay nhỏ hơn kỹ thuật phần mềm hay không. Kỹ thuật phần mềm cũng khá lớn và rộng lớn. Nhưng nó thực sự rất lớn và chắc chắn lớn hơn so với những gì bạn nghĩ dựa trên cách mọi người nói về nó hoặc không nói về nó trên X hay Twitter.

OpenAI và Hệ Sinh Thái Khởi Nghiệp

Di chuyển theo một hướng hơi khác một chút. Sau khi xây dựng nền tảng, xây dựng API, những người đang xây dựng trên API luôn có câu hỏi lớn nhất trong tâm trí là "Làm thế nào để tôi không bị OpenAI chèn ép ý tưởng của mình và xây dựng sản phẩm riêng của họ, rồi sau đó phá hủy thị trường mà tôi đã tạo ra?" Chính sách chung là gì? Triết lý chung về cách các công ty khởi nghiệp nên suy nghĩ về những lĩnh vực mà OpenAI khó có thể tham gia là gì?

Câu trả lời chung của tôi ở đây là thị trường quá lớn và rộng lớn, tôi thực sự nghĩ rằng các công ty khởi nghiệp không nên quá bận tâm về việc OpenAI hay các phòng thí nghiệm lớn này sẽ đi đâu. Tôi đã nói chuyện với rất nhiều công ty khởi nghiệp, những công ty đã không thành công, và những công ty đang làm rất tốt. Mọi công ty khởi nghiệp mà tôi từng thấy không thành công không phải vì OpenAI hay một phòng thí nghiệm lớn hoặc Google nào đó đã đến để chèn ép họ. Mà là vì họ đã xây dựng một cái gì đó và nó thực sự không tạo được tiếng vang với khách hàng. Trong khi đó, những công ty thành công, ngay cả trong những không gian rất cạnh tranh như lập trình, ví dụ như Cursor đã rất lớn ở thời điểm này, là vì họ đã xây dựng một cái gì đó mà mọi người thực sự yêu thích.

Vì vậy, lời khuyên chung của tôi là đừng quá căng thẳng về điều này. Chỉ cần xây dựng một cái gì đó mà mọi người thích và bạn sẽ có một không gian trong thị trường này. Tôi không thể nhấn mạnh hết mức độ lớn của cơ hội hiện tại. Không gian cơ hội để xây dựng với AI là quá lớn. Một ví dụ điển hình là không gian này lớn đến mức "cửa sổ Overton" về những gì các VC chấp nhận được và không chấp nhận được đã hoàn toàn thay đổi. Các VC đang đầu tư vào các công ty cạnh tranh khắp nơi, đơn giản vì không gian quá lớn, bởi vì cơ hội không giống bất kỳ điều gì chúng ta từng thấy trước đây. Và trong khi điều đó ảnh hưởng đến cách các VC hoạt động, từ góc độ công ty khởi nghiệp, đó là điều trao quyền nhất trên thế giới, bởi vì ngay cả khi bạn chỉ xây dựng một cái gì đó mà một số người thực sự, thực sự yêu thích, bạn sẽ có được một doanh nghiệp cực kỳ có giá trị. Và đó là lý do tại sao tôi nói mọi người đừng quá nghĩ về nó.

Điều khác mà tôi cũng nghĩ là quan trọng để nhớ, ít nhất là từ góc độ OpenAI. Một điều mà chúng tôi luôn coi trọng, mà cả Sam và Greg đều giúp củng cố từ trên xuống, là chúng tôi thực sự xem mình về cơ bản là một công ty nền tảng hệ sinh thái. API là sản phẩm đầu tiên của chúng tôi. Chúng tôi nghĩ điều rất quan trọng là chúng tôi phải thúc đẩy hệ sinh thái này và tiếp tục hỗ trợ nó chứ không phải chèn ép nó. Và nếu bạn xem xét các quyết định chúng tôi đưa ra, điều này đều được lồng ghép xuyên suốt. Mỗi mô hình chúng tôi phát hành trong một trong các sản phẩm của mình đều được phát hành trong API. Ngay cả, bạn biết đấy, chúng tôi phát hành các mô hình codecs này hiện được tối ưu hóa hơn một chút cho công cụ Codex, nhưng chúng luôn tìm đường vào API và tất cả các khách hàng của chúng tôi đều sử dụng chúng. Chúng tôi không giữ lại bất kỳ điều gì. Chúng tôi nghĩ điều rất quan trọng là giữ cho nền tảng của chúng tôi trung lập, vì vậy chúng tôi không chặn đối thủ cạnh tranh. Chúng tôi cho phép mọi người truy cập vào các mô hình của chúng tôi. Chúng tôi cũng muốn, bạn biết đấy, chúng tôi gần đây đã thử nghiệm nhiều hơn với sản phẩm đăng nhập bằng ChatGPT. Vì vậy, chúng tôi muốn thúc đẩy hệ sinh thái này và tôi nghĩ điều rất quan trọng là chúng tôi phải làm như vậy.

Suy nghĩ chung về điều này là "nước lên thuyền lên", và chúng tôi có thể là một tàu sân bay, chúng tôi khá lớn ở thời điểm này, nhưng chúng tôi nghĩ điều quan trọng là phải làm cho nước dâng lên vì tất cả mọi người đều được hưởng lợi và tôi nghĩ chúng tôi cũng sẽ được hưởng lợi. Bản thân API của chúng tôi đã phát triển đáng kể vì chúng tôi hành động theo cách này. Vì vậy, tôi thực sự khuyến khích mọi người đừng coi OpenAI là một thứ gì đó sẽ gạt mọi người sang một bên, mà thay vào đó hãy tập trung vào việc xây dựng một thứ gì đó có giá trị và chúng tôi vẫn cam kết cung cấp một hệ sinh thái mở.

Tầm Quan Trọng Của Hệ Sinh Thái Đối Với OpenAI

Tại sao điều đó lại quan trọng đối với OpenAI? Chỉ riêng việc tập trung vào việc xây dựng một nền tảng, tạo ra một cách để mọi người xây dựng doanh nghiệp, đó có phải là tầm nhìn từ ban đầu không? Chúng tôi muốn đây là một nền tảng.

Đó là tầm nhìn từ ban đầu. Nó quay trở lại hiến chương, sứ mệnh của chúng tôi. Sứ mệnh của OpenAI luôn là một, đó là xây dựng AGI.

Sứ Mệnh Phổ Biến AI và Vai Trò của API

Vì vậy, chúng tôi đương nhiên đang thực hiện điều đó, nhưng điều thứ hai là lan tỏa lợi ích của nó đến toàn nhân loại. Và có rất nhiều, bạn biết đấy, phần chính ở đây là "toàn nhân loại". Rõ ràng, ChatGPT đang cố gắng làm điều này; chúng tôi đang cố gắng tiếp cận toàn thế giới. Nhưng từ rất sớm, và đây là lý do tại sao chúng tôi ra mắt API vào khoảng năm 2020 hay gì đó, thực sự sớm, chúng tôi không nghĩ rằng chúng tôi, với tư cách là một công ty, sẽ có thể tiếp cận toàn bộ nhân loại. Bạn biết đấy, mọi ngóc ngách trên thế giới đều khá... khá sâu sắc. Và vì vậy, chúng tôi thực sự cảm thấy rằng để hoàn thành sứ mệnh của mình, chúng tôi cần có một thứ gì đó theo phong cách platform ở đây, nơi chúng tôi có thể trao quyền cho những người khác xây dựng, bạn biết đấy, bot hỗ trợ khách hàng cho các nhà sản xuất podcast và người quản lý bản tin. Bởi vì chúng tôi sẽ không thể tự mình làm điều đó. Và chúng tôi phần lớn đã thấy điều này diễn ra với API. Đây là lý do tại sao chúng tôi đã nói chuyện với rất nhiều khách hàng của mình và thực sự, bạn biết đấy, rất thích nhìn thấy sự đa dạng của những thứ được xây dựng trên đó. Nhưng vâng, nó đã có ở đó ngay từ ngày đầu tiên vì chúng tôi coi đó là sự thể hiện của sứ mệnh.

ChatGPT App Store và Chiến Lược Nền Tảng

Bạn thậm chí còn chưa đề cập đến App Store mà các bạn đang ra mắt, ChatGPT App Store.

Vâng. Nó có thuộc phạm vi của bạn không, hay là một đội ngũ khác?

Đó là một đội ngũ khác. Vì vậy, nó thuộc ChatGPT. Rõ ràng chúng tôi hợp tác rất chặt chẽ với họ và bạn biết đấy, họ đã xây dựng một SDK dành cho ứng dụng, được xây dựng với sự hợp tác chặt chẽ với đội ngũ của chúng tôi. Nhưng điều đó nằm nhiều hơn trong phạm vi của ChatGPT. Nhưng đó cũng là một ví dụ khác về điều này, phải không? Giống như ChatGPT... chúng tôi có khoảng 800 triệu người dùng hoạt động hàng tuần đang truy cập lặp đi lặp lại. Đó là một tài sản tuyệt vời để có với tư cách là một doanh nghiệp, nhưng sẽ tốt hơn nếu chúng ta có thể bằng cách nào đó cho phép các công ty khác tham gia và tận dụng điều này, cũng như xây dựng cho đối tượng này. Và cuối cùng, chúng tôi nghĩ rằng nó sẽ giúp chúng tôi mở rộng nhóm đó nữa, phải không? Vì vậy, tất cả đều quay trở lại sứ mệnh, và chúng tôi thấy rằng việc trở thành một platform cởi mở thường hữu ích ở đây.

Con số 800 triệu đó, tôi nghĩ đó là người dùng hàng tuần, chỉ là hàng tuần.

800 triệu người dùng hàng tuần, giống như thật vô lý khi những con số này bây giờ chúng ta đã quen thuộc, nhưng đó là điều điên rồ và chưa từng có.

Vâng, thực sự rất khó tin đối với tôi khi nghĩ về nó từ góc độ quy mô. Và cách tôi nghĩ về nó là khoảng 10% dân số thế giới – và đang tăng lên, nó đang tăng vọt – truy cập ChatGPT và sử dụng nó mỗi tuần.

Dân Chủ Hóa AI và Khả Năng Tiếp Cận

Và tại thời điểm này, tôi chỉ muốn nhấn mạnh lại điểm bạn đang nói. Sứ mệnh của OpenAI là làm cho AI có sẵn cho toàn nhân loại. Và tôi nghĩ một số người đã phản đối điều đó. Họ nói, "Ồ, bạn biết đấy, nó tốn tiền," và giống như, thực tế là có một phiên bản ChatGPT miễn phí mà bất kỳ ai cũng có thể sử dụng, không khác biệt nhiều so với mô hình AI mạnh mẽ nhất tồn tại trên thế giới, miễn phí, không bị giới hạn, mà bất kỳ ai cũng có thể sử dụng. Giống như nếu bạn là một tỷ phú, bạn chỉ có thể nhận được nhiều hơn một chút từ AI so với những gì một người ở một ngôi làng ở châu Phi có thể nhận được. Và tôi biết điều đó luôn rất quan trọng đối với OpenAI.

Vâng, vâng. Ý tôi là, đó là lý do tại sao tôi nghĩ chúng tôi đã tập trung vào công việc y tế. Chúng tôi đã tập trung vào, bạn biết đấy, giáo dục sẽ rất thú vị ở đây. Một xu hướng điên rồ khác ở đây là mô hình miễn phí đã trở nên thông minh hơn theo thời gian. Mô hình miễn phí vào năm 2022, bạn biết đấy, lúc đó khá tốt, nhưng không là gì so với những gì bạn nhận được hôm nay, vì hôm nay bạn nhận được GPT-3.5. Và vì vậy, việc nâng cao mức sàn trên toàn thế giới là điều mà chúng tôi thực sự đang cố gắng làm và chúng tôi coi đó là một phần của sứ mệnh.

Mặt khác của vấn đề này, nhân tiện, là việc nói về các tỷ phú hay bất cứ ai. Tôi biết mọi người đã nói rằng bạn đang sử dụng cùng một chiếc iPhone mà, bạn biết đấy, Mark Zuckerberg có lẽ đang sử dụng, hoặc các tỷ phú đang sử dụng. Nhưng với khoảng 20 đô la một tháng, bạn về cơ bản đang sử dụng AI tương tự mà các tỷ phú đang sử dụng. Với khoảng 200 đô la một tháng, bạn nhận được cùng một mô hình pro mà tất cả các tỷ phú đang sử dụng, nhưng họ có lẽ không sử dụng pro cho mọi thứ. Họ có lẽ chỉ sử dụng các gói plus tier cho công việc hàng ngày của họ. Và vì vậy, vâng, sự dân chủ hóa này và việc lan tỏa lợi ích này trên toàn thế giới là điều thực sự có ý nghĩa đối với chúng tôi và là điều thúc đẩy rất nhiều những gì chúng tôi làm.

Khám Phá Khả Năng của OpenAI API và Nền Tảng

Một câu hỏi cuối cùng dành cho những người đang nghĩ đến việc xây dựng trên API hoặc chỉ đơn giản là, "Ồ, mình có thể làm những điều thú vị với các mô hình mở và API." API và platform của bạn cho phép mọi người làm gì? Tôi biết bạn có thể xây dựng các agent trên platform. Hãy nói về những gì bạn cho phép.

Về cơ bản, API cung cấp một loạt các developer endpoint, và những developer endpoint này về cơ bản cho phép bạn lấy mẫu từ các mô hình của chúng tôi. Cái phổ biến nhất mà chúng tôi có hiện tại là một cái gọi là responses API. Và đây là một endpoint được tối ưu hóa để xây dựng các agent chạy dài. Vì vậy, các agent sẽ hoạt động trong một thời gian. Về cơ bản, ở cấp độ rất thấp, bạn chỉ cần cung cấp văn bản cho mô hình. Mô hình sẽ hoạt động trong một thời gian, bạn có thể truy vấn nó để xem nó sẽ làm gì, và sau đó bạn sẽ nhận được phản hồi của mô hình tại một thời điểm nào đó. Đó là cấp độ nguyên thủy thấp nhất mà chúng tôi có cho mọi người, và đó thực sự là điều mà rất nhiều người sử dụng. Đó là cách phổ biến nhất để xây dựng trên API với nó. Nó cực kỳ unopinionated (không đưa ra ý kiến cụ thể về cách sử dụng), và bạn có thể làm bất cứ điều gì bạn muốn. Nó giống như điều cấp độ thấp nhất.

Chúng tôi cũng đã bắt đầu xây dựng ngày càng nhiều lớp trừu tượng ở trên để giúp mọi người xây dựng một số thứ này. Và vì vậy, lớp tiếp theo, chúng tôi có thứ gọi là Agents SDK, cũng đã trở nên cực kỳ phổ biến. Điều này cho phép bạn sử dụng responses API hoặc một số API endpoint khác mà chúng tôi có để xây dựng thứ mà bạn có thể nghĩ theo truyền thống là một agent, giống như một AI hoạt động trong một vòng lặp vô hạn. Nó có thể có các sub-agent để ủy quyền. Nó bắt đầu xây dựng tất cả các framework, tất cả các scaffolding này. Bạn biết đấy, chúng ta sẽ xem tất cả những điều này sẽ đi đến đâu. Nhưng nó giúp bạn dễ dàng hơn rất nhiều để xây dựng các loại agent này, cung cấp cho nó các guardrail, cho phép nó phân công các subtask cho các agent khác và điều phối một swarm of agents. Agents SDK cho phép bạn làm điều đó.

Và sau đó, trên đó, chúng tôi hiện đã bắt đầu xây dựng các công cụ để giúp giải quyết cấp độ meta của việc triển khai một agent. Vì vậy, chúng tôi có sản phẩm gọi là Agent Kit và widgets, về cơ bản là một loạt các UI component mà bạn có thể sử dụng để rất dễ dàng xây dựng một giao diện người dùng rất đẹp trên API hoặc Agents SDK của chúng tôi. Bởi vì, bạn biết đấy, rất nhiều lần các agent này trông khá giống nhau từ góc độ UI. Và vì vậy, có Agent Kit. Chúng tôi cũng có một loạt các sản phẩm eval, giống như một eval API, nơi nếu bạn muốn kiểm tra và xem liệu các mô hình hoặc agent hoặc quy trình làm việc của bạn có hoạt động hay không. Bạn có thể kiểm tra nó một cách định lượng bằng cách sử dụng sản phẩm eval của chúng tôi. Và vâng, tôi coi đó là các lớp khác nhau này. Tất cả chúng đều giúp bạn xây dựng những gì bạn muốn với AI và các mô hình của chúng tôi, với các cấp độ trừu tượng ngày càng tăng và mức độ "có ý kiến" của nó. Và vì vậy, bạn có thể bắt đầu, bạn có thể sử dụng toàn bộ stack và nó sẽ rất nhanh chóng cho phép bạn xây dựng một agent. Hoặc bạn có thể đi sâu xuống stack thấp nhất có thể, về cơ bản là đến responses API, và xây dựng bất cứ điều gì bạn muốn vì cấp độ thấp của nó.

Tương Lai Hứa Hẹn của Ngành Công Nghệ

Sherwin, bạn có muốn chia sẻ điều gì khác không? Có điều gì khác bạn muốn để lại cho người nghe không? Có điều gì chúng ta chưa đề cập mà bạn nghĩ có thể hữu ích trước khi chúng ta đến vòng hỏi đáp nhanh rất thú vị của chúng ta không?

Điều duy nhất tôi muốn chia sẻ với mọi người là, vâng, tôi nghĩ hai đến ba năm tới sẽ là một trong những khoảng thời gian thú vị nhất trong lĩnh vực công nghệ và trong startup world mà chúng ta có trong một thời gian rất dài. Và tôi chỉ muốn khuyến khích mọi người đừng bỏ lỡ cơ hội này. Tôi gia nhập lực lượng lao động vào năm 2014. Mọi thứ thật tuyệt vời trong vài năm. Tôi cảm thấy như có một giai đoạn khoảng năm đến sáu năm không thực sự thú vị trong lĩnh vực công nghệ. Và sau đó, trong ba năm qua, đó là giai đoạn thú vị và tràn đầy năng lượng nhất trong sự nghiệp của tôi, và tôi nghĩ hai đến ba năm tới sẽ là sự tiếp nối của điều đó. Và vì vậy, tôi muốn khuyến khích mọi người đừng bỏ lỡ cơ hội này. Tôi đang cố gắng không bỏ lỡ nó. Đến một lúc nào đó, làn sóng này sẽ qua đi và mọi thứ sẽ trở nên mang tính gia tăng hơn nhiều. Nhưng trong thời gian chờ đợi, chúng ta sẽ được khám phá rất nhiều điều thú vị, phát minh ra nhiều thứ mới và thay đổi thế giới, thay đổi cách chúng ta làm việc. Và đó là điều chính tôi muốn để lại cho mọi người.

Lời Khuyên Để Không Bỏ Lỡ Làn Sóng AI

Tôi thích thông điệp này. Tôi muốn dành thêm một chút thời gian cho nó. Khi bạn nói "đừng bỏ lỡ", bạn khuyên mọi người nên làm gì? Chỉ là xây dựng, dấn thân, học hỏi, tham gia một công ty đang xây dựng những điều thực sự thú vị? Lời khuyên của bạn dành cho những người nghĩ, "Được rồi, tôi không muốn bỏ lỡ cơ hội này," là gì?

Vâng, tôi chỉ muốn nói là hãy dấn thân vào nó. Về cơ bản là những gì bạn đã nói. Hãy dấn thân. Xây dựng các công cụ trên nền tảng này là một phần của câu chuyện. Chỉ cần sử dụng các công cụ, bạn không cần phải là một kỹ sư phần mềm để dấn thân vào điều này. Tôi nghĩ rất nhiều công việc sẽ thay đổi ở đây. Vì vậy, chỉ cần sử dụng các công cụ, hiểu được những hạn chế của những gì nó có thể và không thể làm để bạn có thể theo dõi xu hướng những gì nó có thể bắt đầu làm khi các mô hình được cải thiện. Và vâng, về cơ bản là hãy làm quen với công nghệ thay vì lùi lại và để nó vượt qua bạn.

Xử Lý Áp Lực Thông Tin và Sự Lo Lắng Bỏ Lỡ

Mặt khác, có rất nhiều áp lực và lo lắng kiểu như "có quá nhiều thứ đang diễn ra." Làm thế nào để tôi theo kịp? Tôi phải học Claude bot tuần này. Ôi trời. Có điều gì bạn đã học được không, giống như bạn đang ở trung tâm của điều này? Làm thế nào để bạn không quá căng thẳng và lo lắng về việc bỏ lỡ những gì đang diễn ra và chỉ cần cập nhật tin tức? Bạn đã làm gì hoặc học được những gì?

Vâng, tôi nghĩ cá nhân tôi là một ví dụ không tốt về điều này bởi vì tôi về cơ bản là luôn trực tuyến trên X và Slack của công ty chúng tôi. Vì vậy, tôi thực sự cố gắng và cuối cùng hấp thụ rất nhiều thông tin. Tuy nhiên, điều tôi muốn nói là chỉ từ việc quan sát những người khác ít nghiện những thứ này hơn tôi. Vâng, rất nhiều trong số đó là nhiễu. Bạn không cần phải có 110% những thứ này đi vào tâm trí bạn. Thành thật mà nói, chỉ cần tập trung vào một hoặc hai công cụ khác nhau, bắt đầu từ những điều nhỏ, đã là quá đủ ở đây. Tôi nghĩ sự kết hợp giữa tốc độ điên cuồng của ngành công nghiệp và X với tư cách là một sản phẩm đã tạo ra một nhịp độ tin tức điên rồ, mà thành thật mà nói là rất choáng ngợp.

Khuyến khích thử nghiệm công cụ AI

Tuy nhiên, điều chính yếu là bạn không cần phải biết tất cả những điều đó để thực sự tham gia vào những gì đang diễn ra hiện nay. Ngay cả một việc đơn giản như cài đặt Codeex client và thử nghiệm nó, hoặc cài đặt Chad GBHEN, kết nối nó với một vài nguồn dữ liệu nội bộ của bạn như Notion, Slack, GitHub và xem nó có thể làm được gì và không thể làm được gì. Tôi nghĩ tất cả những điều đó đều là một phần quan trọng.

Tuyệt vời. Sherwin, với điều đó, chúng ta đã đến vòng hỏi nhanh đáp gọn đầy thú vị. Tôi có năm câu hỏi dành cho bạn. Bạn đã sẵn sàng chưa?

Vâng, hoàn toàn sẵn sàng. Câu hỏi đầu tiên, hai hoặc ba cuốn sách mà bạn thường xuyên giới thiệu cho người khác nhất là gì?

Sách khuyên đọc

Ồ, tôi sẽ nói về một cuốn sách phi hư cấu và một cuốn sách hư cấu. Cuốn sách hư cấu mà tôi vừa đọc xong, tôi thực sự rất khuyến khích. Đó là cuốn "There is no anti-mimetics division" của Q&M. Tôi nghĩ đó là một tác giả viết trực tuyến, nhưng tôi thấy nó được chia sẻ trên X. Đây là một cuốn sách khoa học viễn tưởng. Tôi đã đọc ngấu nghiến nó trong khoảng hai ngày. Nó được viết rất, rất hay, rất cuốn hút. Sách kể về một cơ quan chính phủ chiến đấu chống lại những thứ khiến bạn quên đi sự tồn tại của chúng. Đó là một cuốn sách rất thông minh, sáng tạo và thực sự mới mẻ về mặt chất liệu. Vì vậy, tôi sẽ giới thiệu cuốn đó. Cuốn sách cũng hài hước một cách không chủ ý. Nó được viết theo phong cách khoa học viễn tưởng, gần như kinh dị, nhưng nó đã khiến tôi bật cười vài lần. Đó là về sách hư cấu.

Về sách phi hư cấu, tôi sẽ gian lận một chút và giới thiệu hai cuốn. Trong năm ngoái, tôi đã đọc nhiều hơn về Trung Quốc và mối quan hệ Mỹ-Trung. Tôi nghĩ có hai cuốn sách ra mắt trong năm ngoái thực sự đã mở mang tầm mắt tôi về vấn đề này. Cuốn đầu tiên là "Breakneck" của Dan Wang. Cuốn đó rất, rất hay. Tôi thực sự thích sự so sánh của anh ấy rằng Mỹ là một xã hội do luật sư lãnh đạo, còn Trung Quốc là một xã hội do kỹ sư lãnh đạo, và mỗi bên đều có ưu và nhược điểm riêng. Tôi đọc xong và nghĩ, "Ừm, đúng là dường như chúng ta ở Mỹ đang được điều hành bởi các luật sư." Đó là một cuốn.

Và cuốn kia là cuốn sách của Patrick McGee về Apple và Trung Quốc, cực kỳ thú vị. Tôi là một người hâm mộ cuồng nhiệt của Apple. Nếu bạn nhìn thấy bàn làm việc của tôi bây giờ, tất cả đều là đồ Apple. Thứ nhất, việc tìm hiểu về mối quan hệ của Apple với Trung Quốc thực sự rất hấp dẫn. Và thứ hai, nó có rất nhiều thông tin nội bộ về Apple với tư cách là một công ty mà tôi thấy cuốn hút. Vì vậy, đó cũng là một cuốn sách hấp dẫn và rất kịp thời.

Cuốn sách "anti-mimetics" nghe thật tuyệt vời. Tôi đang mua nó ngay khi bạn nói đây. Vâng, vâng, vâng. Nó chỉ khoảng vài trăm trang thôi. Tôi thực sự đã đọc xong trong hai ngày. Nó thực sự rất hay.

Phim/Chương trình TV yêu thích gần đây

Được, mẹo hay. Được rồi. Bộ phim hoặc chương trình TV yêu thích gần đây mà bạn thực sự thích là gì?

Chà, câu này khó đấy, vì tôi có hai con và một công việc bận rộn nên tôi thực sự không có nhiều thời gian để xem TV. Tôi sẽ nói rằng trong vài tuần gần đây tôi đã xem vài tập. Thực ra tôi là một người rất mê anime nên tôi đã xem vài tập. Có một mùa mới của anime tên là Jujutsu Kaisen vừa ra mắt. Mùa 3 của JJK thực sự rất hay. Nói chung, tôi là một người hâm mộ cuồng nhiệt anime Nhật Bản. Tôi nghĩ họ tạo ra những cốt truyện và vũ trụ độc đáo và mới lạ nhất mà truyền thông phương Tây đã tránh né. Vì vậy, tôi thường rất thích thể loại này, nhưng đúng là tôi không xem nhiều, chỉ mới xem vài tập JJK gần đây. Hoàn toàn dễ hiểu với vai trò của bạn. Vâng.

Sản phẩm yêu thích mới khám phá

Sản phẩm yêu thích mà bạn mới khám phá gần đây là gì?

Vâng. Được rồi. Gần đây tôi phải thiết lập Wi-Fi và mạng gia đình, và tôi đã đầu tư toàn bộ vào các bộ định tuyến Ubiquiti và camera an ninh Unifi. Tôi chưa bao giờ nghe nói về nó trước đây cho đến khi tôi phải làm điều này. Tôi luôn có một thiết lập rất đơn giản. Và nó thực sự là một sản phẩm được xây dựng rất tốt. Tôi không biết bạn đã dùng nó bao giờ chưa, nhưng về cơ bản, nó giống như Apple của mạng gia đình vậy. Sản phẩm rất đẹp. Nhưng điều thực sự khiến nó cực kỳ tốt là phần mềm của nó cũng rất tốt. Họ có một ứng dụng di động tuyệt vời để giúp quản lý tất cả mạng gia đình. Về cơ bản, bạn có thể dùng Ubiquiti để mua các bộ định tuyến không dây. Bạn cần hệ thống dây Ethernet khắp nhà để sử dụng nó. Nhưng tôi thực sự nghĩ rằng điều làm nên sự tuyệt vời của nó là các camera an ninh. Nếu bạn có camera an ninh được cắm vào hệ sinh thái Ubiquiti, họ có một ứng dụng di động, ứng dụng Apple TV và ứng dụng iPad tuyệt vời để xem nguồn cấp dữ liệu trực tiếp từ camera của bạn. Chúng có giá hơi cao, nhưng không quá đắt. Nhưng đó thực sự là một trải nghiệm sản phẩm đáng kinh ngạc. Được rồi, tôi dùng Eero nên tôi đã mắc sai lầm rồi. Mẹo hay đấy. Eero cũng khá tốt, nhưng tôi đã hoàn toàn chuyển sang Ubiquiti tại thời điểm này. Mẹo hay.

Châm ngôn sống và yếu tố bất ngờ ảnh hưởng giá nhà

Được rồi, còn hai câu hỏi nữa. Bạn có một châm ngôn sống yêu thích nào mà bạn thường xuyên suy ngẫm trong công việc hay cuộc sống không? Vâng. Điều mà tôi luôn nhắc nhở bản thân là đừng bao giờ cảm thấy tiếc cho chính mình. Có rất nhiều điều sẽ xảy ra trong công việc, trong cuộc sống. Và việc nhắc nhở bản thân đừng bao giờ cảm thấy tiếc và rằng bạn luôn có cảm giác tự chủ để tự mình đứng dậy là điều tôi đã phải tự nhủ rất nhiều, và cũng là điều tôi lặp lại với rất nhiều người khác nữa.

Câu hỏi cuối cùng. Trong công việc trước đây, bạn làm việc tại Open Door, nơi bạn dẫn dắt công việc về việc định giá nhà. Về cơ bản, bạn đã xây dựng một mô hình cho công ty biết: "Đây là số tiền chúng tôi sẽ trả cho ngôi nhà này." Có yếu tố nào trong giá nhà mà bạn không ngờ lại quan trọng và ảnh hưởng lớn đến giá nhà không? Có khá nhiều yếu tố bất ngờ. Tôi sẽ liệt kê một vài yếu tố thú vị nhất. Đường dây điện và đường dây điện cao thế thực sự ảnh hưởng rất nhiều đến giá nhà của bạn. Tôi chưa thực sự nhận ra điều này cho đến khi tôi đến Dallas và quan sát, ví dụ như khi nhà bạn nằm cạnh một trong những đường dây điện khổng lồ này, nó ù ù, và hầu hết mọi người đều có gia đình, bạn không muốn con cái mình ở gần đó. Vì vậy, tôi nghĩ đó là một yếu tố thực sự khiến tôi ngạc nhiên.

Điều đó có lý. Vâng. Và yếu tố khác mà chúng tôi luôn gặp khó khăn khi định lượng là sơ đồ mặt bằng. Vì vậy, điều đó rất quan trọng, vâng, tất nhiên là rất quan trọng, nhưng việc định lượng thế nào là một sơ đồ mặt bằng tốt và thế nào là một sơ đồ mặt bằng thực sự tệ thì rất khó. Chúng tôi đã làm đủ mọi thứ như chiều rộng của nhà bếp là bao nhiêu, kiểu bếp là gì, rồi vị trí phòng ngủ chính ở đâu. Vì vậy, rất khó để định lượng, nhưng tôi nhớ sơ đồ mặt bằng là một yếu tố lớn vì chúng tôi sẽ có một ngôi nhà không bán được, và sau đó đội ngũ vận hành của chúng tôi sẽ vào và nói, "Vâng, đây là vấn đề về sơ đồ mặt bằng." Vậy làm thế nào bạn biết? Bạn đi vào bên trong và bạn chỉ cảm thấy nó, sơ đồ mặt bằng đó khiến bạn có cảm giác. Vâng, đó là những yếu tố gây bất ngờ.

Và yếu tố cuối cùng có tác động lớn hơn tôi nghĩ là vẻ ngoài tổng thể của ngôi nhà và thậm chí cả cửa trước. Tôi thực sự nghĩ có một cuốn sách của Zillow nói về điều này, rằng việc thay thế cửa trước có xu hướng mang lại ROI cao nhất cho các ngôi nhà. Nhưng chỉ cần cảm giác khi bạn bước đến ngôi nhà với tư cách là người mua, những gì bạn tương tác và những khoảnh khắc đầu tiên của ngôi nhà, tôi nghĩ là tôi đã đánh giá thấp tầm quan trọng của nó. Điều đó cực kỳ thú vị. Và tôi thích việc bạn phải tìm cách làm tất cả những điều này trong mã chứ không phải đi bộ xem sơ đồ mặt bằng. Tôi có rất nhiều câu chuyện xung quanh sơ đồ mặt bằng, ví dụ như nó không được số hóa. Vì vậy, có một số ít người có sơ đồ mặt bằng giấy của tất cả các ngôi nhà ở Phoenix và Dallas. Vâng, rất nhiều câu chuyện thú vị từ những ngày ở Open Door.

Tìm Sherwin Woo trực tuyến và cách liên hệ

Được rồi, Sherwin, cảm ơn bạn rất nhiều vì đã tham gia. Đây là một cuộc trò chuyện tuyệt vời. Mọi người có thể tìm bạn trực tuyến ở đâu và thính giả có thể giúp ích gì cho bạn? Vâng. Tôi có mặt trực tuyến trên Twitter, trên X. Tôi chỉ đơn giản là Sherwin Woo và vâng, tôi chủ yếu đăng tweet về OpenAI và API cũng như một số sản phẩm mà chúng tôi đang ra mắt. Còn về việc mọi người có thể giúp ích gì cho tôi. Tôi rất thích nghe về những điều mọi người đang xây dựng, vì vậy nếu bạn đang làm việc trong một công ty khởi nghiệp, nếu bạn đang phát triển một ý tưởng, hãy liên hệ với tôi trên X. Tôi rất muốn nghe về những gì bạn đang xây dựng và tìm hiểu xem OpenAI có thể hỗ trợ bạn như thế nào.

Tuyệt vời. Sherwin, cảm ơn bạn rất nhiều vì đã có mặt ở đây. Vâng, cảm ơn Lenny. Tạm biệt mọi người. Cảm ơn bạn rất nhiều vì đã lắng nghe. Nếu bạn thấy nội dung này có giá trị, bạn có thể đăng ký theo dõi chương trình trên Apple Podcasts, Spotify hoặc ứng dụng podcast yêu thích của bạn. Ngoài ra, vui lòng cân nhắc đánh giá hoặc để lại bình luận vì điều đó thực sự giúp những thính giả khác tìm thấy podcast. Bạn có thể tìm tất cả các tập trước hoặc tìm hiểu thêm về chương trình tại lennispodcast.com. Hẹn gặp lại trong tập tiếp theo.

TL;DR

Các kỹ sư của OpenAI đang tích hợp sâu AI (đặc biệt là Codex) vào quy trình làm việc, với 95% sử dụng Codex hàng ngày và 100% pull request được AI xem xét, giúp tăng năng suất đáng kể (mở PR nhiều hơn 70%).
Vai trò của kỹ sư đang chuyển đổi nhanh chóng từ người viết mã thành trưởng nhóm kỹ thuật, quản lý các tác nhân AI và điều hướng luồng công việc phức tạp, mở ra kỷ nguyên "lập trình theo cảm hứng/trực giác" (vibe coding).
Lĩnh vực AI và các mô hình ngôn ngữ lớn (LLM) đang phát triển rất nhanh; cần tập trung xây dựng cho nơi mà các LLM đang hướng tới chứ không phải hiện tại của chúng, đồng thời cung cấp ngữ cảnh rõ ràng để quản lý hiệu quả các tác nhân AI.

Điểm chính

Tăng cường năng suất với AI: Các kỹ sư sử dụng AI (như Codex) thường xuyên có thể mở pull request nhiều hơn đáng kể (70%), cho thấy tiềm năng tăng cường năng suất mạnh mẽ.
Chuyển đổi vai trò kỹ sư: Công việc của kỹ sư đang tiến hóa thành quản lý các đội và tác nhân AI, đòi hỏi kỹ năng điều khiển và cung cấp phản hồi cho AI thay vì chỉ viết mã.
Định hướng phát triển AI tương lai: Cần tập trung phát triển các giải pháp và chiến lược dựa trên dự đoán về sự tiến hóa của LLM, thay vì chỉ dựa vào khả năng hiện tại của chúng ("Đây là lúc các mô hình tệ nhất").
Tầm quan trọng của ngữ cảnh và đặc tả rõ ràng: Khi tác nhân AI không hoạt động như mong muốn, nguyên nhân thường là do thiếu ngữ cảnh hoặc thông tin đặc tả không đủ, đòi hỏi người dùng phải cung cấp chi tiết hơn.
Quản lý "Sorcerer's Apprentice": Các công cụ AI có đòn bẩy cao nhưng yêu cầu kỹ năng và kinh nghiệm để kiểm soát, đảm bảo các tác nhân AI thực hiện đúng việc và không đi chệch hướng.
Tự động hóa đánh giá mã: AI có khả năng xem xét mã trong pull request, đề xuất cải tiến và thay đổi, góp phần nâng cao chất lượng mã và quy trình phát triển.
Nhu cầu về công cụ phân tích nhà phát triển: Các nền tảng như DX giúp lãnh đạo tổ chức hiểu cách các công cụ AI đang được sử dụng và tác động của chúng đến năng suất kỹ thuật.
Gỡ lỗi hiệu quả trong kỷ nguyên AI: Các công cụ gỡ lỗi chuyên biệt (như Sentry với Seir) có thể sử dụng ngữ cảnh để xác định nguyên nhân gốc rễ, đề xuất cách khắc phục và tự động tạo pull request sửa lỗi.

Từ vựng

AI — Artificial Intelligence (Trí tuệ nhân tạo)
kỹ sư — Engineer
Codex — Codex (mô hình AI của OpenAI)
pull request (PR) — Pull Request (Yêu cầu hợp nhất mã)
tác nhân (AI) — AI Agent (Tác nhân AI)
cơ sở mã — Codebase (Cơ sở mã)
mô hình ngôn ngữ lớn (LLM) — Large Language Model (Mô hình ngôn ngữ lớn)
giao diện lập trình ứng dụng (API) — Application Programming Interface (Giao diện lập trình ứng dụng)
năng suất — Productivity
xem xét mã — Code Review

Nội dung chi tiết

Giới thiệu về Sherwin Woo và bối cảnh `AI`

Tôi ngày càng nghe nhiều hơn về sự căng thẳng mà mọi người cảm thấy khi tác nhân (AI) của họ không hoạt động. Có một nhóm hiện đang thực hiện một thử nghiệm tại OpenAI, nơi họ duy trì một cơ sở mã (codebase) được viết 100% bằng Codex. Họ gặp phải chính xác những vấn đề mà bạn đang mô tả. Và thông thường, bạn sẽ nói: "Được rồi, tôi sẽ xắn tay áo lên và tìm cách giải quyết." Nhưng nhóm này không có lối thoát đó.

Bạn đã chia sẻ rằng việc lắng nghe khách hàng không phải lúc nào cũng là chiến lược đúng đ đắn trong trí tuệ nhân tạo (AI). Lĩnh vực này và bản thân các mô hình ngôn ngữ lớn (LLM) đang thay đổi quá nhanh. Chúng có xu hướng tự phá vỡ mình. Các mô hình ngôn ngữ lớn (LLM) sẽ "ăn thịt" giàn giáo của bạn cho bữa sáng. Lời khuyên của bạn dành cho những người nói: "Được rồi, tôi không muốn bỏ lỡ cơ hội này" là gì? Hãy đảm bảo rằng bạn đang xây dựng cho nơi mà các mô hình ngôn ngữ lớn (LLM) đang hướng tới, chứ không phải nơi chúng đang ở hiện tại. Có một câu nói của Kevin Whale, Phó Giám đốc Khoa học của chúng tôi tại đây. Ông ấy thích nói: "Đây là lúc các mô hình ngôn ngữ lớn (LLM) tệ nhất."

Quảng cáo: DX – Nền tảng phân tích `nhà phát triển`

Quảng cáo: Sentry – Gỡ lỗi `AI` hiệu quả

Sherwin, cảm ơn bạn rất nhiều vì đã có mặt tại đây và chào mừng đến với podcast.

Cảm ơn bạn. Cảm ơn bạn đã mời tôi.

Tôi muốn bắt đầu với điều đang được xem như một phong vũ biểu của sự tiến bộ trong trí tuệ nhân tạo (AI), đặc biệt là trong kỹ thuật. Hiện tại, bao nhiêu phần trăm mã của bạn — nếu bạn còn viết mã nữa — và mã của nhóm bạn được trí tuệ nhân tạo (AI) viết?

Tôi vẫn thỉnh thoảng viết mã bây giờ. Và tôi thực sự muốn nói rằng đối với những quản lý như tôi, việc sử dụng các công cụ AI này dễ dàng hơn nhiều so với việc viết mã thủ công vào thời điểm này. Và vì vậy, tôi biết đối với bản thân và một số quản lý kỹ thuật (engineering managers) khác tại OpenAI, tất cả mã của chúng tôi đều được Codex viết vào thời điểm này. Nhưng nói rộng hơn, có quá nhiều năng lượng. Có một năng lượng hữu hình trong nội bộ về việc các công cụ này đã tiến xa đến mức nào, Codex với tư cách là một công cụ đã trở nên tốt như thế nào đối với chúng tôi. Và hơi khó để chúng tôi đo lường chính xác bao nhiêu mã được viết, bởi vì phần lớn trong số đó, tôi muốn nói là gần 100%, thường được trí tuệ nhân tạo (AI) tạo ra trước. Tuy nhiên, điều chúng tôi theo dõi là, vào thời điểm này, phần lớn các kỹ sư sử dụng Codex hàng ngày. Vì vậy, 95% kỹ sư sử dụng Codex. 100% pull request (PR) của chúng tôi cũng được Codex xem xét mã (review code) hàng ngày. Vì vậy, về cơ bản, bất kỳ mã nào đi vào sản xuất, được hợp nhất, Codex đều theo dõi và đề xuất cải tiến, đề xuất thay đổi trong các pull request (PR). Và đó là những gì chúng tôi đang thấy trong nội bộ. Nhưng nhìn chung, điều thú vị nhất chính là năng lượng mà nó mang lại. Một quan sát khác mà chúng tôi có là các kỹ sư có xu hướng sử dụng Codex nhiều hơn sẽ mở pull request (open PR) nhiều hơn đáng kể. Vì vậy, họ thực sự mở pull request (open PR) nhiều hơn 70% so với các kỹ sư không sử dụng Codex nhiều. Và khoảng cách đang ngày càng rộng ra. Vì vậy, tôi cảm thấy rằng những người mở pull request (open PR) nhiều hơn đang bắt đầu học cách sử dụng công cụ ngày càng hiệu quả hơn, và khoảng cách 70% đó tiếp tục tăng theo thời gian và có thể đã tăng lên kể từ lần cuối tôi xem số liệu.

Được rồi. Vậy để chắc chắn chúng tôi hiểu đúng ý bạn, bạn đang nói rằng tất cả mã của 95% kỹ sư tại OpenAI đều được trí tuệ nhân tạo (AI) viết. Nó được viết và sau đó họ xem xét mã (review code) lại.

Vâng. Vâng.

Sự phát triển của niềm tin vào `mô hình AI`

Thật điên rồ khi điều đó gần như không còn điên rồ nữa, chúng ta đang dần quen với điều này. Tôi nghĩ vẫn còn một số điều cần làm quen, nói rõ hơn. Tôi cũng nghĩ có một số kỹ sư tin tưởng Codex ít hơn một chút, nhưng về cơ bản, mỗi ngày tôi đều nói chuyện với một ai đó bị choáng ngợp bởi những gì trí tuệ nhân tạo (AI) có thể làm và mức độ tin tưởng của họ, hoặc mức độ họ tin tưởng mô hình có thể tự mình làm, ngày càng tăng lên theo thời gian. Và có một câu nói của Kevin Whale, Phó Giám đốc Khoa học của chúng tôi tại đây, ông ấy thích nói: "Đây là lúc các mô hình tệ nhất." Và đây cũng là lúc các mô hình tệ nhất đối với kỹ thuật phần mềm. Và vì vậy, theo thời gian, bạn sẽ thấy mọi người tin tưởng nó ngày càng nhiều hơn và sau đó chúng ta sẽ thấy các mô hình ngày càng tốt hơn nữa.

Vâng. Kevin Whale, khách mời podcast trước đây, ông ấy đã nói chính xác câu đó trên podcast này và vài lần rồi.

Vâng. Peter, nhà phát triển của Claudebot/Moldbotclaw (tên gọi hiện tại), gần đây đã chia sẻ rằng anh ấy sử dụng Codex cho công việc của mình và anh ấy cảm thấy bất cứ khi nào nó thực hiện mọi thứ, anh ấy chỉ tin tưởng rằng nó đã làm đúng việc và anh ấy gần như chắc chắn rằng mình có thể commit nó vào master và nó sẽ hoạt động tốt.

Vâng. Vâng. Anh ấy là một người dùng Codex tuyệt vời. Tôi biết anh ấy giữ liên lạc chặt chẽ với nhóm, cung cấp cho chúng tôi những phản hồi tuyệt vời. Không ngạc nhiên khi anh ấy sử dụng nó. Ý tôi là, xin lỗi, nó được gọi là OpenClaw.

OpenClaw. Vâng.

OpenClaw là một sản phẩm tuyệt vời. Và sau đó tôi thấy rằng điều này — ý tôi là, điều này rất gần đây, nhưng sáng nay tôi nghĩ Mold's bot cũng được chia sẻ, và việc nhìn thấy tất cả các tác nhân AI nói chuyện với nhau khá siêu thực. Về cơ bản, đó là bộ phim Her đang diễn ra ngoài đời thực, là điều tôi đang nghe.

Vâng. Vâng.

Vai trò của `Kỹ sư phần mềm` trong tương lai

Quay lại khoảnh khắc điên rồ mà chúng ta đang sống, đặc biệt là đối với các kỹ sư. Chúng ta đã đi từ việc "bạn viết mọi dòng mã" đến nay "trí tuệ nhân tạo (AI) đang viết tất cả mã của bạn." Tôi không biết công việc nào đã thay đổi nhiều hơn trong vài năm qua — một công việc mà chúng ta không ngờ lại thay đổi nhiều đến vậy — nơi mà công việc của một kỹ sư quá khác biệt. Trong suốt vòng đời của một kỹ sư, trong vài năm qua, nó giờ đây đã chuyển sang "Tôi không viết mã nữa." Bạn hình dung vai trò của một kỹ sư và công việc của một kỹ sư phần mềm sẽ như thế nào trong vài năm tới? Công việc đó sẽ ra sao?

Vâng, ý tôi là, thành thật mà nói, thật tuyệt vời khi thấy điều đó, và đó là một phần của sự hào hứng vì công việc có thể sẽ thay đổi khá đáng kể trong một đến hai năm tới. Cảm giác như chúng ta vẫn đang tìm hiểu mọi thứ, và vì vậy có một sự hào hứng, tôi biết đặc biệt là từ một số kỹ sư phần mềm, kiểu như "chúng ta đang ở trong một khoảnh khắc hiếm có," bạn biết đấy, "có thể trong 12 đến 24 tháng tới, chúng ta sẽ tự tìm hiểu mọi thứ và tự đặt ra các tiêu chuẩn cho mình" về nơi tôi thấy điều này đang di chuyển. Vì vậy, tôi nghĩ có một điều phổ biến mà mọi người đang nói, đó là các kỹ sư cá nhân (IC engineers) đang trở thành trưởng nhóm kỹ thuật (tech leads). Về cơ bản, họ giống như quản lý bây giờ. Họ đang quản lý các đội và đội tác nhân (AI). Tôi biết nhiều kỹ sư trong nhóm của tôi về cơ bản có khoảng 10 đến 20 luồng công việc đang được kéo cùng một lúc. Rõ ràng là không phải các tác vụ Codex đang chạy chủ động, mà chỉ là rất nhiều luồng song song. Họ đang kiểm tra những gì tác nhân (AI) đang làm. Họ đang điều khiển các tác nhân (AI) và Codex và đưa ra phản hồi cho nó. Và vì vậy, công việc của họ đã thực sự thay đổi từ việc chỉ viết mã sang gần như trở thành một quản lý.

`Lập trình`: Một hình thức "phép thuật" trong kỷ nguyên `AI`

Phép Ẩn Dụ "Người Học Việc Của Phù Thủy" và Đòn Bẩy Cao của AI

Vâng. Hoặc nó có thể giống như kiểu monkey's paw nơi bạn có được điều mình muốn, nhưng tác dụng phụ là gì?

Những Thách Thức Khi Tương Tác với Tác Nhân AI

AI Tự Động Hóa Review Code và Quy Trình CI/CD

Tin Tưởng AI Trong Review Code và Sử Dụng Đa Mô Hình

Tỷ Lệ Mã Nguồn Được AI Viết tại OpenAI

Vai Trò Thay Đổi Của Quản Lý Kỹ Thuật

Tăng Cường Năng Suất Của Các Cá Nhân Xuất Sắc

`AI` Nâng Tầm Khả Năng Quản Lý

Vâng. Vâng.

Và điều bạn đang nói ở đây là việc tiếp tục làm điều này ngày càng nhiều có lẽ là động thái đúng đắn. Dành nhiều thời gian hơn cho những người giỏi nhất trong nhóm của bạn để gỡ bỏ rào cản cho họ, đảm bảo họ có mọi thứ họ cần.

Vâng. Một ví dụ rất hay hiện nay là có một nhóm kỹ sư nội bộ thực sự giỏi CodeX và đang suy nghĩ về những best practice để tương tác với mô hình này, và đó là một điều có đòn bẩy cực kỳ cao để họ thực hiện. Vì vậy, với tư cách là một manager, tôi chỉ nói: "Vâng, hãy khám phá điều này. Bất kỳ best practice nào xuất hiện từ đó, chúng ta phải chia sẻ với tổ chức. Chúng ta sẽ tổ chức tất cả các buổi chia sẻ kiến thức, chúng ta sẽ chia sẻ tài liệu và best practice ở khắp mọi nơi." Vì vậy, những điều như vậy chỉ nâng cao mọi người và tôi coi đó là một ví dụ khác về xu hướng này mà chúng ta đang thấy, nơi những người có hiệu suất cao nhất thực sự trở nên phi thường.

Tương Lai Của Khởi Nghiệp: Từ "`Startup` Tỷ Đô Một Người" Đến Bùng Nổ `B2B SaaS`

Mọi người đều cảm thấy điều này rất lớn. AI đang thay đổi rất nhiều. Thế giới đang thay đổi. Sẽ là một vấn đề lớn. Bạn nghĩ điều gì mà mọi người chưa tính đến về những gì sẽ thay đổi, về nơi mọi thứ đang hướng tới? Chỉ cần một ví dụ về điều mà bạn nghĩ rằng "chúng ta chưa nhận ra điều này".

Cái Nhìn Khác Về "`Startup` Tỷ Đô Một Người"

Tôi thích số lượng các hiệu ứng bậc cao mà chúng ta đã đi qua. Tôi muốn nghe hiệu ứng bậc bốn bây giờ, Sherwin. Tôi chỉ đùa thôi. Tôi không thể... bậc bốn quá... quá gigabrain đối với tôi. Tôi không thể nghĩ xa đến thế.

Nó giống như Inception vậy, mọi thứ chậm lại mỗi khi bạn đi sâu hơn vào một thứ, mỗi lớp.

Tôi sẽ mua nó. Tôi sẽ mua nó.

Vâng.

Tương lai phát triển phần mềm và công ty `unicorn` một người

(Người trả lời): Ừm.

(Người trả lời): ...một mình anh ấy đã trải qua.

(Người phỏng vấn): À, tiện thể, anh ấy sẽ xuất hiện trên podcast trong một tuần tới.

Triết lý quản lý: Kỹ sư như bác sĩ phẫu thuật

`AI` hỗ trợ phát hiện và dự đoán `blocker`

(Người phỏng vấn): Bạn vừa có một insight (cái nhìn sâu sắc) ngay đây.

(Người trả lời): Vâng. Vâng. Vâng.

(Người phỏng vấn): Và tôi nghĩ điều thú vị hơn nữa là, bạn dự đoán điều gì sẽ là blocker cho kỹ sư này hoặc nhóm này trong những tháng tới?

(Người phỏng vấn): Tôi nghĩ chúng ta đã có một ý tưởng hay ngay đây.

(Người trả lời): Vâng. Vâng.

Quảng cáo: DataDog

Thực trạng triển khai `AI` với `ROI` âm

Thúc Đẩy Áp Dụng AI Từ Dưới Lên

Thành Phần Lý Tưởng Cho Đội Đặc Nhiệm AI

Mô Hình Phản Tác Dụng Và Lời Khuyên

"Vâng. Vâng. Chính xác. Chính xác."

Nghe Khách Hàng Trong Lĩnh Vực AI: Con Dao Hai Lưỡi

Mô Hình Phát Triển và Các Khung Hỗ Trợ AI

Bài Học Cay Đắng và Tầm Nhìn Phát Triển AI

Hướng Đi Tương Lai Của API và Mô Hình AI

"Vâng, điều hiển nhiên nhất là độ dài của một nhiệm vụ mà các mô hình này có thể thực hiện một cách nhất quán (coherently)."

Thời Gian Thực Hiện Tác Vụ của AI và Xu Hướng Phát Triển

Cải Tiến Mô Hình Đa Phương Thức, Đặc Biệt là Âm Thanh

Tóm Tắt Xu Hướng Phát Triển AI

Tự Động Hóa Quy Trình Nghiệp Vụ - Một Cơ Hội Lớn

Phạm Vi Tác Động Của AI Ngoài Kỹ Thuật

OpenAI và Hệ Sinh Thái Khởi Nghiệp

Tầm Quan Trọng Của Hệ Sinh Thái Đối Với OpenAI

Đó là tầm nhìn từ ban đầu. Nó quay trở lại hiến chương, sứ mệnh của chúng tôi. Sứ mệnh của OpenAI luôn là một, đó là xây dựng AGI.

Sứ Mệnh Phổ Biến AI và Vai Trò của API

ChatGPT App Store và Chiến Lược Nền Tảng

Bạn thậm chí còn chưa đề cập đến App Store mà các bạn đang ra mắt, ChatGPT App Store.

Vâng. Nó có thuộc phạm vi của bạn không, hay là một đội ngũ khác?

Con số 800 triệu đó, tôi nghĩ đó là người dùng hàng tuần, chỉ là hàng tuần.

800 triệu người dùng hàng tuần, giống như thật vô lý khi những con số này bây giờ chúng ta đã quen thuộc, nhưng đó là điều điên rồ và chưa từng có.

Dân Chủ Hóa AI và Khả Năng Tiếp Cận

Khám Phá Khả Năng của OpenAI API và Nền Tảng

Tương Lai Hứa Hẹn của Ngành Công Nghệ

Lời Khuyên Để Không Bỏ Lỡ Làn Sóng AI

Xử Lý Áp Lực Thông Tin và Sự Lo Lắng Bỏ Lỡ

Khuyến khích thử nghiệm công cụ AI

Tuyệt vời. Sherwin, với điều đó, chúng ta đã đến vòng hỏi nhanh đáp gọn đầy thú vị. Tôi có năm câu hỏi dành cho bạn. Bạn đã sẵn sàng chưa?

Vâng, hoàn toàn sẵn sàng. Câu hỏi đầu tiên, hai hoặc ba cuốn sách mà bạn thường xuyên giới thiệu cho người khác nhất là gì?

Sách khuyên đọc

Cuốn sách "anti-mimetics" nghe thật tuyệt vời. Tôi đang mua nó ngay khi bạn nói đây. Vâng, vâng, vâng. Nó chỉ khoảng vài trăm trang thôi. Tôi thực sự đã đọc xong trong hai ngày. Nó thực sự rất hay.

Phim/Chương trình TV yêu thích gần đây

Được, mẹo hay. Được rồi. Bộ phim hoặc chương trình TV yêu thích gần đây mà bạn thực sự thích là gì?

Chà, câu này khó đấy, vì tôi có hai con và một công việc bận rộn nên tôi thực sự không có nhiều thời gian để xem TV. Tôi sẽ nói rằng trong vài tuần gần đây tôi đã xem vài tập. Thực ra tôi là một người rất mê anime nên tôi đã xem vài tập. Có một mùa mới của anime tên là Jujutsu Kaisen vừa ra mắt. Mùa 3 của JJK thực sự rất hay. Nói chung, tôi là một người hâm mộ cuồng nhiệt anime Nhật Bản. Tôi nghĩ họ tạo ra những cốt truyện và vũ trụ độc đáo và mới lạ nhất mà truyền thông phương Tây đã tránh né. Vì vậy, tôi thường rất thích thể loại này, nhưng đúng là tôi không xem nhiều, chỉ mới xem vài tập JJK gần đây. Hoàn toàn dễ hiểu với vai trò của bạn. Vâng.

Sản phẩm yêu thích mới khám phá

Sản phẩm yêu thích mà bạn mới khám phá gần đây là gì?

Vâng. Được rồi. Gần đây tôi phải thiết lập Wi-Fi và mạng gia đình, và tôi đã đầu tư toàn bộ vào các bộ định tuyến Ubiquiti và camera an ninh Unifi. Tôi chưa bao giờ nghe nói về nó trước đây cho đến khi tôi phải làm điều này. Tôi luôn có một thiết lập rất đơn giản. Và nó thực sự là một sản phẩm được xây dựng rất tốt. Tôi không biết bạn đã dùng nó bao giờ chưa, nhưng về cơ bản, nó giống như Apple của mạng gia đình vậy. Sản phẩm rất đẹp. Nhưng điều thực sự khiến nó cực kỳ tốt là phần mềm của nó cũng rất tốt. Họ có một ứng dụng di động tuyệt vời để giúp quản lý tất cả mạng gia đình. Về cơ bản, bạn có thể dùng Ubiquiti để mua các bộ định tuyến không dây. Bạn cần hệ thống dây Ethernet khắp nhà để sử dụng nó. Nhưng tôi thực sự nghĩ rằng điều làm nên sự tuyệt vời của nó là các camera an ninh. Nếu bạn có camera an ninh được cắm vào hệ sinh thái Ubiquiti, họ có một ứng dụng di động, ứng dụng Apple TV và ứng dụng iPad tuyệt vời để xem nguồn cấp dữ liệu trực tiếp từ camera của bạn. Chúng có giá hơi cao, nhưng không quá đắt. Nhưng đó thực sự là một trải nghiệm sản phẩm đáng kinh ngạc. Được rồi, tôi dùng Eero nên tôi đã mắc sai lầm rồi. Mẹo hay đấy. Eero cũng khá tốt, nhưng tôi đã hoàn toàn chuyển sang Ubiquiti tại thời điểm này. Mẹo hay.

Châm ngôn sống và yếu tố bất ngờ ảnh hưởng giá nhà

Điều đó có lý. Vâng. Và yếu tố khác mà chúng tôi luôn gặp khó khăn khi định lượng là sơ đồ mặt bằng. Vì vậy, điều đó rất quan trọng, vâng, tất nhiên là rất quan trọng, nhưng việc định lượng thế nào là một sơ đồ mặt bằng tốt và thế nào là một sơ đồ mặt bằng thực sự tệ thì rất khó. Chúng tôi đã làm đủ mọi thứ như chiều rộng của nhà bếp là bao nhiêu, kiểu bếp là gì, rồi vị trí phòng ngủ chính ở đâu. Vì vậy, rất khó để định lượng, nhưng tôi nhớ sơ đồ mặt bằng là một yếu tố lớn vì chúng tôi sẽ có một ngôi nhà không bán được, và sau đó đội ngũ vận hành của chúng tôi sẽ vào và nói, "Vâng, đây là vấn đề về sơ đồ mặt bằng." Vậy làm thế nào bạn biết? Bạn đi vào bên trong và bạn chỉ cảm thấy nó, sơ đồ mặt bằng đó khiến bạn có cảm giác. Vâng, đó là những yếu tố gây bất ngờ.

Tìm Sherwin Woo trực tuyến và cách liên hệ

Tuyệt vời. Sherwin, cảm ơn bạn rất nhiều vì đã có mặt ở đây. Vâng, cảm ơn Lenny. Tạm biệt mọi người. Cảm ơn bạn rất nhiều vì đã lắng nghe. Nếu bạn thấy nội dung này có giá trị, bạn có thể đăng ký theo dõi chương trình trên Apple Podcasts, Spotify hoặc ứng dụng podcast yêu thích của bạn. Ngoài ra, vui lòng cân nhắc đánh giá hoặc để lại bình luận vì điều đó thực sự giúp những thính giả khác tìm thấy podcast. Bạn có thể tìm tất cả các tập trước hoặc tìm hiểu thêm về chương trình tại lennispodcast.com. Hẹn gặp lại trong tập tiếp theo.

Góp ý / Báo lỗiPhát hiện sai sót hoặc có ý tưởng cải thiện?

Giới thiệu về Sherwin Woo và bối cảnh AI

Quảng cáo: DX – Nền tảng phân tích nhà phát triển

Quảng cáo: Sentry – Gỡ lỗi AI hiệu quả

Sự phát triển của niềm tin vào mô hình AI

Vai trò của Kỹ sư phần mềm trong tương lai

Lập trình: Một hình thức "phép thuật" trong kỷ nguyên AI

Phép Ẩn Dụ "Người Học Việc Của Phù Thủy" và Đòn Bẩy Cao của AI

Những Thách Thức Khi Tương Tác với Tác Nhân AI

AI Tự Động Hóa Review Code và Quy Trình CI/CD

Tin Tưởng AI Trong Review Code và Sử Dụng Đa Mô Hình

Tỷ Lệ Mã Nguồn Được AI Viết tại OpenAI

Vai Trò Thay Đổi Của Quản Lý Kỹ Thuật

Tăng Cường Năng Suất Của Các Cá Nhân Xuất Sắc

AI Nâng Tầm Khả Năng Quản Lý

Tương Lai Của Khởi Nghiệp: Từ "Startup Tỷ Đô Một Người" Đến Bùng Nổ B2B SaaS

Cái Nhìn Khác Về "Startup Tỷ Đô Một Người"

Tương lai phát triển phần mềm và công ty unicorn một người

Triết lý quản lý: Kỹ sư như bác sĩ phẫu thuật

AI hỗ trợ phát hiện và dự đoán blocker

Quảng cáo: DataDog

Thực trạng triển khai AI với ROI âm

Thúc Đẩy Áp Dụng AI Từ Dưới Lên

Thành Phần Lý Tưởng Cho Đội Đặc Nhiệm AI

Mô Hình Phản Tác Dụng Và Lời Khuyên

Nghe Khách Hàng Trong Lĩnh Vực AI: Con Dao Hai Lưỡi

Mô Hình Phát Triển và Các Khung Hỗ Trợ AI

Bài Học Cay Đắng và Tầm Nhìn Phát Triển AI

Hướng Đi Tương Lai Của API và Mô Hình AI

Thời Gian Thực Hiện Tác Vụ của AI và Xu Hướng Phát Triển

Cải Tiến Mô Hình Đa Phương Thức, Đặc Biệt là Âm Thanh

Tóm Tắt Xu Hướng Phát Triển AI

Tự Động Hóa Quy Trình Nghiệp Vụ - Một Cơ Hội Lớn

Phạm Vi Tác Động Của AI Ngoài Kỹ Thuật

OpenAI và Hệ Sinh Thái Khởi Nghiệp

Tầm Quan Trọng Của Hệ Sinh Thái Đối Với OpenAI

Sứ Mệnh Phổ Biến AI và Vai Trò của API

ChatGPT App Store và Chiến Lược Nền Tảng

Dân Chủ Hóa AI và Khả Năng Tiếp Cận

Khám Phá Khả Năng của OpenAI API và Nền Tảng

Tương Lai Hứa Hẹn của Ngành Công Nghệ

Lời Khuyên Để Không Bỏ Lỡ Làn Sóng AI

Xử Lý Áp Lực Thông Tin và Sự Lo Lắng Bỏ Lỡ

Khuyến khích thử nghiệm công cụ AI

Sách khuyên đọc

Phim/Chương trình TV yêu thích gần đây

Sản phẩm yêu thích mới khám phá

Châm ngôn sống và yếu tố bất ngờ ảnh hưởng giá nhà

Tìm Sherwin Woo trực tuyến và cách liên hệ

TL;DR

Điểm chính

Từ vựng

Nội dung chi tiết

Giới thiệu về Sherwin Woo và bối cảnh AI

Quảng cáo: DX – Nền tảng phân tích nhà phát triển

Quảng cáo: Sentry – Gỡ lỗi AI hiệu quả

Sự phát triển của niềm tin vào mô hình AI

Vai trò của Kỹ sư phần mềm trong tương lai

Lập trình: Một hình thức "phép thuật" trong kỷ nguyên AI

Phép Ẩn Dụ "Người Học Việc Của Phù Thủy" và Đòn Bẩy Cao của AI

Những Thách Thức Khi Tương Tác với Tác Nhân AI

AI Tự Động Hóa Review Code và Quy Trình CI/CD

Tin Tưởng AI Trong Review Code và Sử Dụng Đa Mô Hình

Tỷ Lệ Mã Nguồn Được AI Viết tại OpenAI

Vai Trò Thay Đổi Của Quản Lý Kỹ Thuật

Tăng Cường Năng Suất Của Các Cá Nhân Xuất Sắc

AI Nâng Tầm Khả Năng Quản Lý

Tương Lai Của Khởi Nghiệp: Từ "Startup Tỷ Đô Một Người" Đến Bùng Nổ B2B SaaS

Cái Nhìn Khác Về "Startup Tỷ Đô Một Người"

Tương lai phát triển phần mềm và công ty unicorn một người

Triết lý quản lý: Kỹ sư như bác sĩ phẫu thuật

AI hỗ trợ phát hiện và dự đoán blocker

Quảng cáo: DataDog

Thực trạng triển khai AI với ROI âm

Thúc Đẩy Áp Dụng AI Từ Dưới Lên

Thành Phần Lý Tưởng Cho Đội Đặc Nhiệm AI

Mô Hình Phản Tác Dụng Và Lời Khuyên

Nghe Khách Hàng Trong Lĩnh Vực AI: Con Dao Hai Lưỡi

Mô Hình Phát Triển và Các Khung Hỗ Trợ AI

Bài Học Cay Đắng và Tầm Nhìn Phát Triển AI

Hướng Đi Tương Lai Của API và Mô Hình AI

Giới thiệu về Sherwin Woo và bối cảnh `AI`

Quảng cáo: DX – Nền tảng phân tích `nhà phát triển`

Quảng cáo: Sentry – Gỡ lỗi `AI` hiệu quả

Sự phát triển của niềm tin vào `mô hình AI`

Vai trò của `Kỹ sư phần mềm` trong tương lai

`Lập trình`: Một hình thức "phép thuật" trong kỷ nguyên `AI`

`AI` Nâng Tầm Khả Năng Quản Lý

Tương Lai Của Khởi Nghiệp: Từ "`Startup` Tỷ Đô Một Người" Đến Bùng Nổ `B2B SaaS`

Cái Nhìn Khác Về "`Startup` Tỷ Đô Một Người"

Tương lai phát triển phần mềm và công ty `unicorn` một người

`AI` hỗ trợ phát hiện và dự đoán `blocker`

Thực trạng triển khai `AI` với `ROI` âm

Giới thiệu về Sherwin Woo và bối cảnh `AI`

Quảng cáo: DX – Nền tảng phân tích `nhà phát triển`

Quảng cáo: Sentry – Gỡ lỗi `AI` hiệu quả

Sự phát triển của niềm tin vào `mô hình AI`

Vai trò của `Kỹ sư phần mềm` trong tương lai

`Lập trình`: Một hình thức "phép thuật" trong kỷ nguyên `AI`

`AI` Nâng Tầm Khả Năng Quản Lý

Tương Lai Của Khởi Nghiệp: Từ "`Startup` Tỷ Đô Một Người" Đến Bùng Nổ `B2B SaaS`

Cái Nhìn Khác Về "`Startup` Tỷ Đô Một Người"

Tương lai phát triển phần mềm và công ty `unicorn` một người

`AI` hỗ trợ phát hiện và dự đoán `blocker`

Thực trạng triển khai `AI` với `ROI` âm