- AI, đặc biệt là các công cụ như Claude Code và Cursor, đang trao quyền "siêu năng lực" cho những người không có nền tảng kỹ thuật, giúp họ dễ dàng xây dựng sản phẩm và định hình lại vai trò truyền thống trong phát triển sản phẩm.
- Để sử dụng AI hiệu quả, cần một quy trình làm việc thông minh, bao gồm việc tạo ra một "CTO AI" để cung cấp định hướng kỹ thuật và một lộ trình học tập "liệu pháp tiếp xúc" dần dần với code cho người không chuyên.
- Điều quan trọng là phải thách thức các đầu ra của AI và sử dụng nhiều công cụ để kiểm tra chéo (ví dụ: xem xét mã bằng nhiều LLM), tránh xu hướng "thích làm hài lòng" của AI có thể dẫn đến thông tin sai lệch.
How a Meta PM ships products without ever writing code | Zevi Arnovitz
- Bắt đầu với "Projects" (GPT/Claude): Sử dụng các dự án GPT hoặc Claude để tạo môi trường chatbot có cấu trúc, chia sẻ cuộc trò chuyện, hướng dẫn tùy chỉnh và cơ sở kiến thức, giúp phân loại và giữ mọi thứ trong ngữ cảnh phù hợp.
- Tạo một "CTO AI": Thiết lập một AI đóng vai trò "chủ sở hữu kỹ thuật" hoàn toàn cho dự án của bạn thông qua một câu lệnh tùy chỉnh (custom prompt). Chỉ dẫn AI thách thức bạn, sở hữu phần "cách thức xây dựng" và không trở thành "người thích làm hài lòng".
- Áp dụng "Liệu pháp tiếp xúc" dần dần: Đối với người không có kỹ thuật, hãy bắt đầu chậm rãi với giao diện chatbot đơn giản (dự án GPT), sau đó chuyển sang các công cụ xây dựng như Bolt hoặc Lovable, và cuối cùng là Cursor ở chế độ sáng, làm quen dần với code.
- Tận dụng Cursor với Claude Code: Sử dụng Cursor được hỗ trợ bởi Claude Code làm công cụ cốt lõi để phát triển, tích hợp khả năng AI trực tiếp vào môi trường lập trình của bạn.
- Sử dụng
/commandscho các lệnh tái sử dụng: Lưu trữ các câu lệnh/lời nhắc có thể tái sử dụng dưới dạng/commandstrong codebase (ví dụ:/reviewđể xem xét code,/create-issueđể tạo vấn đề) để chuẩn hóa và tăng tốc các tác vụ thông thường. - Xem xét chéo code do AI tạo: Sử dụng nhiều LLM hoặc công cụ khác nhau (ví dụ: Claude và Codex) để xem xét code do AI viết, giúp phát hiện lỗi và có được nhiều góc nhìn, tránh phụ thuộc vào một nguồn duy nhất.
- Ưu tiên lập kế hoạch kỹ lưỡng: Đặc biệt đối với các tính năng phức tạp như thanh toán hoặc thay đổi cơ sở dữ liệu, hãy dành thời gian lập kế hoạch chi tiết trước khi để tác nhân lập trình (coding agent) bắt đầu viết code ngay lập tức.
- Liên tục nâng cấp công cụ: Chuyển từ các công cụ AI đơn giản hơn (như Bolt, Lovable) lên các công cụ mạnh mẽ hơn (như Cursor) khi kỹ năng và độ phức tạp của dự án tăng lên, luôn chọn công cụ phù hợp nhất với nhu cầu hiện tại.
product manager— quản lý sản phẩmnền tảng kỹ thuật— technical backgroundworkflow— quy trình làm việccâu lệnh/lời nhắc— promptLLM— Large Language Model (mô hình ngôn ngữ lớn)CTO— Chief Technology Officer (Giám đốc công nghệ)exposure therapy— liệu pháp tiếp xúccoding agent— tác nhân lập trìnhreview code— xem xét mã (code)codebase— cơ sở mã
Hành trình từ Product Manager không chuyên kỹ thuật trở thành người xây dựng sản phẩm bằng AI
Bạn là một product manager triển khai sản phẩm mà không biết viết code, thậm chí gần như không biết review code. Tôi không có nền tảng kỹ thuật nào cả, tôi đã học nhạc ở trường cấp ba... khi Sonnet 3.5 ra mắt, tôi nhớ mình đã xem một video YouTube hướng dẫn xây dựng ứng dụng bằng Bolt hoặc Lovable. Cảm giác lúc đó giống như có ai đó đến nói với tôi rằng: "Giờ đây bạn có siêu năng lực rồi đấy."
Ngày nay, bạn đang dùng Cursor với Claude Code. Nếu bạn không có kỹ thuật như tôi, code là thứ đáng sợ, nhưng AI khiến mọi thứ trở nên khả thi hơn rất nhiều. Trong vài năm tới, tôi nghĩ tất cả mọi người sẽ trở thành người xây dựng. Các chức danh sẽ sụp đổ và trách nhiệm cũng sẽ thay đổi.
Thử thách chính mà mọi người gặp phải là review code do AI viết. Đối với tôi, việc phát hiện lỗi rất khó khăn. Điều tôi thường làm là dùng lệnh /review. Lệnh này yêu cầu Claude bắt đầu review chính code của nó. Tuyệt vời hơn nữa là tôi mở cả Codex và Cursor. Tôi sẽ để mỗi công cụ review code. Điều này gợi nhớ đến câu nói mà tôi nghĩ ai cũng từng nghe: Bạn sẽ không bị thay thế bởi AI, mà sẽ bị thay thế bởi người biết sử dụng AI tốt hơn bạn.
Đây là thời điểm tốt nhất để làm junior, trái ngược với điều nhiều người đang nói về việc không còn vị trí junior nữa. Đúng là như vậy, nhưng trong lịch sử, còn khi nào bạn có thể ra trường và tự mình xây dựng một startup?
Giới thiệu về Zevi Arnovitz và Mục tiêu của Podcast
Khách mời của tôi hôm nay là Zevi Arnovitz. Zevi là một PM tại Meta. Trước đó, anh ấy là PM tại Wix. Đây là một cuộc trò chuyện thực sự đáng chú ý mà mọi người làm sản phẩm không có kỹ thuật đều cần nghe. Zevi còn rất trẻ và không có nền tảng kỹ thuật, nhưng với sự thông minh, trẻ tuổi và đầy tham vọng, anh ấy đã học cách sử dụng Cursor và Claude Code để tự mình xây dựng những sản phẩm có ý nghĩa và thực tế, đồng thời tạo ra một workflow rất thông minh và hiệu quả mà mọi người nghe đều có thể học hỏi.
Để việc học hỏi này dễ dàng hơn nữa, ở đầu phần ghi chú của tập này, bạn có thể tải xuống tất cả các câu lệnh/lời nhắc và lệnh / để tự mình thực hiện tất cả những điều này. Zevi sẽ chỉ cho bạn cách làm việc với Cursor để nhanh chóng thêm ý tưởng của mình vào Linear để khám phá ý tưởng đó với AI, cách phát triển kế hoạch, cách xây dựng sản phẩm, sau đó để các LLM khác nhau review code và cập nhật tài liệu, rồi sử dụng tất cả những điều này như một cơ hội học hỏi để phát triển nhận thức của riêng bạn về cách mọi thứ hoạt động.
Tôi đã không ngừng suy nghĩ về cuộc trò chuyện này kể từ khi chúng tôi có nó, và mọi người cần chú ý đến những gì AI đang mở khóa cho những người không có kỹ thuật.
Xin gửi lời cảm ơn sâu sắc đến Tal Raviv vì đã khuyến khích tôi gặp Zevi. Nếu bạn yêu thích podcast này, đừng quên đăng ký và theo dõi nó trên ứng dụng podcast yêu thích hoặc YouTube. Điều đó giúp ích rất nhiều. Và nếu bạn trở thành người đăng ký hàng năm cho bản tin của tôi, bạn sẽ nhận được 19 sản phẩm cao cấp miễn phí trong cả năm, bao gồm Lovable, Replit, Bolt, Gamma, n8n, Linear, Devin, PostHog, Superhuman, Descript, Wispr Flow, Perplexity, Warp, Granola, Magic Patterns, Raycast, ChatPRD, Mobbin và Stripe Atlas. Hãy truy cập lennysnewsletter.com và nhấp vào product pass. Sau đây, tôi xin giới thiệu Zevi Arnovitz sau một vài lời từ các nhà tài trợ của chúng ta.
Lời của nhà tài trợ
Tập này được tài trợ bởi 10Web, công ty tiên phong trong việc xây dựng trang web bằng AI trước cả ChatGPT. Trong ba năm qua, hơn hai triệu trang web đã được tạo ra bằng nền tảng vibe coding của 10Web. Nền tảng vibe coding của 10Web là một cách mạnh mẽ để xây dựng trang web. Hãy hình dung nó như Lovable dành cho WordPress, cả frontend và backend. Người dùng có thể xây dựng bất kỳ trang web nào với mọi độ phức tạp, từ e-commerce, portfolio, trang web thông tin, đến blog, và nó đi kèm với bảng quản trị WordPress cùng hàng ngàn plugin sẵn sàng sử dụng. 10Web cũng cung cấp khả năng tạo trang web dưới dạng API as a service cho các công ty SaaS, marketplace, nhà cung cấp hosting, MSP và các agency. Các công ty SaaS có thể nhúng nó thông qua API để người dùng có thể khởi chạy các trang web do AI tạo trực tiếp bên trong nền tảng của họ, được kết nối với dữ liệu riêng của họ. Các agency và MSP có thể có bảng điều khiển white label để quản lý khách hàng và bán lại dưới thương hiệu của họ. Các nhà cung cấp hosting có thể tự host API builder trên cơ sở hạ tầng của riêng họ. Hãy truy cập 10web.io/lenny và sử dụng mã Lenny để nhận các khoản tín dụng miễn phí độc quyền và giảm giá 30% cho API hoặc các giải pháp white label. Đó là 10web.io/lenny, nền tảng vibe coding dưới dạng API.
Tập hôm nay được tài trợ bởi DX, nền tảng developer intelligence đượ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 AI, các tổ chức cần thích nghi nhanh chóng, nhưng nhiều 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 hiệu quả? 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 AI đang cung cấp giá trị cho các developer của họ và tác động của AI đến engineering productivity là gì. Để tìm hiểu thêm, hãy truy cập trang web của DX tại getdx.com/lenny, tức là getdx.com/lenny.
Câu chuyện cá nhân về Zevi Arnovitz
Zevi, cảm ơn bạn rất nhiều vì đã có mặt ở đây và chào mừng bạn đến với podcast.
Cảm ơn vì đã mời tôi, Lenny. Tôi là một fan cuồng của chương trình này và rất nhiều người mà tôi ngưỡng mộ nhất và học hỏi được nhiều nhất đều đã xuất hiện ở đây, nên đây là một khoảnh khắc điên rồ đối với tôi. Tôi thực sự rất hào hứng với điều này.
Tôi thực sự đánh giá cao điều đó. Tôi muốn bắt đầu bằng cách đọc một ghi chú tôi nhận được về bạn từ Tal Raviv, người từng là khách mời podcast, và nhiều lần là cộng tác viên bản tin. Anh ấy là một trong những product manager tiên phong về AI nhất mà tôi biết và tôi đã học hỏi được rất nhiều từ anh ấy. Đây là những gì anh ấy nói về bạn khi giới thiệu chúng tôi: "Zevi là PM vibe coding thực tế nhất mà tôi biết, và cá nhân tôi đã học được rất nhiều từ anh ấy. Các kỹ sư của anh ấy tại Meta đã nhờ anh ấy dạy cách làm những gì anh ấy đang làm. Mỗi khi chúng tôi uống cà phê, tôi luôn có cảm giác rằng mọi người cần được nghe điều này."
Thật tuyệt vời. Và đó chính là mục tiêu. Mục tiêu của cuộc trò chuyện này là giúp nhiều người hơn nghe được những gì bạn đã khám phá ra. Chúng ta sẽ đi sâu vào thực tế. Chúng ta sẽ trình bày nhiều hơn là chỉ nói, chỉ cho mọi người thấy những gì bạn đã tìm ra về cách trở thành một PM, một PM không có kỹ thuật nhưng vẫn xây dựng được mọi thứ. Tôi muốn cung cấp cho mọi người một chút thông tin về nền tảng kỹ thuật của bạn vì tôi nghĩ điều này sẽ truyền cảm hứng cho nhiều thính giả cảm thấy rằng họ cũng có thể làm được những gì chúng ta sắp trình bày. Điều này sẽ trông rất nâng cao, nhưng hãy cho mọi người một chút cảm nhận về nền tảng kỹ thuật của bạn.
Tôi rất ít am hiểu kỹ thuật. Tôi không có nền tảng kỹ thuật nào cả. Tôi học nhạc ở trường cấp ba. Nhiều người Israel tham gia các đơn vị công nghệ trong quân đội, nhưng tôi thì không. Và cơ bản là một năm trước, tôi đã đi du lịch với vợ ba tháng ở châu Á và chúng tôi ở Nhật Bản, và đó là khoảng thời gian Sonnet 3.5 ra mắt. Tôi nhớ mình đã xem một video YouTube. Tôi nghĩ đó là Greg Isenberg hoặc Riley Brown và họ cơ bản là đang xây dựng ứng dụng bằng Bolt hoặc Lovable, chỉ bằng cách sử dụng AI. Đó là một khoảnh khắc điên rồ đối với tôi vì khi xem, tôi cảm thấy như có ai đó đến và nói: "Này Zevi, có công nghệ mới tuyệt vời này bạn nên xem thử. Bạn thực sự nên thử nó. À, và nhân tiện, bây giờ bạn có siêu năng lực rồi đấy." Và ngay giây phút tôi về đến nhà từ Nhật Bản, tôi thậm chí còn chưa tháo hành lý, đã chạy ngay đến máy tính, mở Bolt, tạo một tài khoản, và trong suốt một năm qua, tôi đã không ngừng xây dựng.
Và điều cuối cùng tôi muốn nói về việc đó là chúng ta đã nói chuyện một chút về điều này trước khi bắt đầu ghi âm, nhưng tôi đã chuẩn bị với Claude cho tập này và tôi cố gắng làm rõ mục tiêu của mình cho tập này là gì. Và Claude nói: "Nếu mọi người rời đi mà nghĩ rằng bạn thật tuyệt vời, thì bạn đã thất bại. Còn nếu mọi người rời đi và mở máy tính của họ ra và bắt đầu xây dựng, thì bạn đã thành công." Vì vậy, tôi thực sự hy vọng chúng ta có thể truyền cảm hứng cho một số người làm điều tương tự.
Tôi rất thích điều đó. Tôi cảm thấy đó nên là mục tiêu cho podcast của tôi. Nếu bạn nói, "Tôi yêu quý khách mời đó." thì đó ít là một chiến thắng. Nếu nó giống như, "Ồ, tôi rất lấy cảm hứng để làm điều mà họ đã tìm ra, đó mới là chiến thắng thực sự." Tôi yêu Claude, nó là nhất.
Tổng quan về Quy trình làm việc với AI của Zevi
Tôi đồng ý. Được rồi. Vậy thì hãy cùng đi sâu vào và giới thiệu cho mọi người, hãy bắt đầu với một cái nhìn tổng quan về cách bạn vận hành và cách bạn sử dụng AI trong công việc của mình. Các công cụ AI cốt lõi là gì và khung tham chiếu cho workflow mà bạn đã tìm ra và cách bạn vận hành là gì?
Tất cả bắt đầu từ việc tôi là một power user của các dự án. Tôi yêu thích các dự án, các dự án GPT. Các dự án ChatGPT? Vâng, chính xác. Các dự án GPT và các dự án Claude, về cơ bản là một thư mục chia sẻ các cuộc trò chuyện, cùng chia sẻ các custom instructions và cơ sở tri thức chung. Tôi nghĩ khoảng thời gian GPT bắt đầu sử dụng bộ nhớ, tôi thấy điều đó thú vị, nhưng nó thực sự làm tôi khó chịu vì tôi làm rất nhiều việc khác nhau. Tôi là một người chạy bộ kém, tôi là một PM, tôi từng là sinh viên, sinh viên tâm lý học, nên tôi có rất nhiều khía cạnh khác nhau trong cuộc sống. Và điều xảy ra là tính năng bộ nhớ đã làm lẫn lộn mọi thứ. Ví dụ, tôi nói chuyện với GPT về việc chạy bộ và nó sẽ nói, "Ồ vâng, sau cuộc đua 5K này, bạn sẽ làm rất tốt tất cả các bài review sản phẩm tiếp theo của mình." Và tôi nghĩ, được thôi, tôi hiểu rằng bạn có điều đó trong bộ nhớ, nhưng nó không liên quan. Và các dự án về cơ bản cho phép bạn phân loại và giữ mọi thứ trong ngữ cảnh phù hợp. Vì vậy, quay lại câu chuyện tôi kể khi chúng tôi trở về từ Nhật Bản, tôi đã bắt đầu xây dựng ứng dụng này.
Điều đầu tiên tôi nhận thấy là các sản phẩm này, và khi tôi nói các sản phẩm này, tôi muốn nói đến Bolt và Lovable, được xây dựng theo cách mà chúng rất háo hức viết code. System prompt của chúng là bạn là một coding agent. Vì vậy, khi bạn viết một cái gì đó, chúng sẽ ngay lập tức bắt đầu viết code. Ở giai đoạn đầu của một dự án, điều này rất thú vị và hấp dẫn vì chúng chỉ việc bắt đầu xây dựng ứng dụng của bạn. Nhưng sau này khi mọi thứ trở nên phức tạp hơn, điều này lại tạo ra nhiều vấn đề hơn vì lập kế hoạch thực sự quan trọng khi bạn triển khai một cái gì đó kỹ thuật. Chẳng hạn, bạn đang triển khai thanh toán hoặc một cái gì đó sẽ thay đổi cơ sở dữ liệu của bạn. Nếu coding agent chỉ đơn giản là nói, "Được rồi, tôi hiểu rồi." và bắt đầu viết code, điều này luôn dẫn đến những hậu quả tồi tệ, một số lỗi rất khó chịu mà tôi đã gặp phải.
Tạo CTO AI để hạn chế "người thích làm hài lòng"
Để giảm thiểu điều này, tôi đã tạo ra một dạng CTO. Như đã nói, tôi không có technical background. Tôi đã làm về sản phẩm một thời gian, nhưng tôi hoàn toàn không biết gì về code. Về cơ bản, tôi đã tạo ra một CTO với câu lệnh/lời nhắc tùy chỉnh (custom prompt) để nó trở thành chủ sở hữu kỹ thuật hoàn toàn (complete technical owner) của dự án. Tôi đã nói với nó: "Tôi sở hữu vấn đề. Tôi sở hữu cách chúng ta muốn người dùng cảm thấy. Bạn là chủ sở hữu hoàn toàn về cách dự án này sẽ được xây dựng. Tôi muốn bạn thách thức tôi. Tôi không muốn bạn là một người thích làm hài lòng (people pleaser)." Tất cả những điều này giúp giảm thiểu các "ChatGPT-isms" thông thường. Tôi luôn nghĩ về điều này, rằng vì một lý do nào đó, cách dễ nhất để tôi nghĩ về AI là hình dung nó như con người. Và tôi nghĩ ChatGPT có lẽ sẽ là một CTO tồi tệ nhất vì nó quá thích làm hài lòng và quá nịnh bợ. Chỉ một câu chuyện ngắn cách đây vài tuần, tôi đang cố gắng tìm hiểu về Bun JavaScript, được Anthropic mua lại, và tôi muốn hiểu chúng làm gì. Tôi đã nói chuyện với GPT – lúc đó không phải trong dự án CTO đồng sáng lập của tôi – và tôi hỏi liệu nó có tương tự một framework khác trong ứng dụng của tôi tên là Zustand không, mà hoàn toàn không liên quan gì đến những gì Bun JavaScript làm. Và về cơ bản, GPT nói: "Ồ vâng, nó giống hệt nhau." Rồi nó bắt đầu nói về ý nghĩa của nó, và tôi đã nghĩ: "Khoan đã, không, chúng không hề giống nhau chút nào." Và nó đã nói điều đáng sợ và hài hước nhất: "Ồ, tôi xin lỗi. Tôi nghĩ bạn chỉ bịa ra điều này và tôi đang nói đùa với bạn." Tôi đã nghĩ: "Ôi không, không, không, điều này thật tệ." Vì vậy, về cơ bản, nếu ChatGPT thông thường là một CTO, thì đó sẽ là CTO đồng tình với những ý tưởng ngu ngốc nhất của bạn. Việc tạo ra dự án này đã giúp tôi giảm thiểu điều đó.
Vai trò của ChatGPT CTO
Vậy đây là, để nói rõ ràng hơn, bạn có một dự án ChatGPT mà bạn đã đưa một câu lệnh/lời nhắc để nó trở thành CTO của sản phẩm bạn, và với tư cách là một người không có technical background, đây giống như điều bạn nói chuyện khi – và chúng ta sẽ tìm hiểu những gì bạn thực sự đang sử dụng để xây dựng – khi bạn có câu hỏi về kiến trúc và các quyết định kỹ thuật.
Quy trình làm việc và lộ trình học tập dần dần
Vâng. Bây giờ tôi sẽ trình bày toàn bộ quy trình làm việc của mình và tôi không còn sử dụng GPT nữa, nhưng tôi chắc chắn vẫn khuyên dùng, mặc dù công nghệ đã phát triển... Khi tôi bắt đầu điều này, không có chế độ lập kế hoạch (plan mode) hay hỏi (ask mode). Nó chỉ là xây dựng trên các sản phẩm như Lovable và Bolt, và chúng đã tiến bộ rất nhiều. Rất nhiều quy trình làm việc tôi có đã trở thành một phần cốt lõi của các sản phẩm này, điều này thực sự thú vị. Tôi vẫn khuyên bạn nên bắt đầu với một dự án vì lý do tôi đã nói, và nó cũng đặt bạn vào một môi trường chatbot mà không phải viết code. Vì vậy, bạn dành thời gian để trò chuyện và học hỏi, điều mà tôi nghĩ là rất quan trọng. Và điều thứ hai là nếu bạn không có technical background như tôi, code thật đáng sợ. Đó là điều đáng sợ nhất trên thế giới để nhìn vào, và tôi coi nó giống như liệu pháp tiếp xúc (exposure therapy). Tôi nghĩ nếu bạn thấy tôi làm việc trong Claude hoặc Cursor, bạn có thể hào hứng muốn bắt đầu sử dụng chúng, nhưng tôi thực sự khuyên bạn nên bắt đầu chậm rãi với một dự án GPT, UI đẹp mắt, cực kỳ đơn giản, sau đó có thể nâng cấp lên Bolt hoặc Lovable, và rồi chuyển sang Cursor ở chế độ sáng (light mode), từ từ, dần dần làm quen cho đến khi bạn mở một terminal, chuyển sang chế độ tối hoàn toàn (full dark mode), và trở thành nhà phát triển hoàn toàn (full dev). Vì vậy, tôi thực sự khuyên bạn nên làm điều này dần dần.
Cursor với Claude Code
Đó là một lời khuyên tuyệt vời. Và để rõ ràng, ngày nay bạn đang sử dụng Cursor với Claude Code cung cấp sức mạnh. Và điều tôi yêu thích về điều đó là bạn chưa bao giờ viết code. Như bạn đã nói, bạn sợ ngay cả việc nhìn vào code.
Nâng cấp công cụ theo thời gian
Vâng, 100%. Bạn có thể thực hiện liệu pháp tiếp xúc (exposure therapy), và tôi thích Cursor hữu ích với bạn. Và điều bạn đang nói với chúng tôi là việc chuyển từ một dự án ChatGPT đóng vai trò như đồng sáng lập kỹ thuật của bạn đã dạy bạn đủ để cảm thấy thoải mái hơn khi chuyển thẳng sang Cursor. Bạn nói rằng bạn thực sự đã chuyển sang Bolt và Lovable trong giai đoạn tạm thời và sau đó bạn đã chuyển thẳng sang Cursor. Lý do để chuyển thẳng sang Cursor là gì? Có phải chỉ là Cursor có thể làm mọi thứ và một khi bạn đã quen, nó thực sự là công cụ AI mạnh mẽ nhất?
Vâng, tôi nghĩ tôi đã nâng cấp (graduated) từ mỗi công cụ AI khi tôi cảm thấy mình đã vượt quá khả năng của nó. Bolt rất tuyệt vời cho đến khi tôi cố gắng kết nối thanh toán vào ứng dụng của mình và tôi bắt đầu gặp khó khăn, rồi tôi chuyển sang Cursor, và tôi thực sự đã phải lòng Claude. Vì vậy, tôi đang sử dụng Claude Code, nhưng nó cũng chạy trong Cursor, và tôi nghĩ Tal đã nói với tôi điều này. Tôi không chắc anh ấy đang trích dẫn ai, nhưng code cuối cùng chỉ là những từ ngữ. Vì vậy, nó chỉ là các tệp trên máy tính của bạn. Về cơ bản, bạn có thể làm việc trên cùng một dự án và chuyển nó từ ứng dụng này sang ứng dụng khác. Và đặc biệt bây giờ, tôi có thể làm việc với nhiều model và ứng dụng trên dự án của mình. Vì vậy, hãy bắt đầu chậm rãi, nhưng chắc chắn có rất nhiều nơi bạn có thể nâng cấp lên.
Bắt đầu chia sẻ màn hình
Tuyệt vời. Được rồi. Chúng ta có nên đi sâu vào chia sẻ màn hình để xem bạn vận hành như thế nào không?
Tuyệt vời. Tôi đã mở Cursor. Bạn có thấy không?
Ừm hứm.
Giao diện Cursor và các lệnh tùy chỉnh
Hoàn hảo. Trong codebase của tôi, bạn có thể thấy ở bên trái, đây là tất cả các tệp code của tôi. Bên phải là Cursor. Vì vậy, đây về cơ bản giống như có AI, có quyền truy cập vào tất cả code. Và ở giữa, tôi có Claude Code đang chạy. Và những gì bạn có thể thấy ở đây, tôi sẽ đóng Cursor trong giây lát. Những gì bạn có thể thấy ở đây là tất cả các /command của tôi. Về cơ bản, /command là các câu lệnh/lời nhắc có thể tái sử dụng (reusable prompts) mà tôi lưu trữ trong codebase và tôi có thể chạy chúng bằng cách gõ / và sau đó là tên của tệp. Vì vậy, ở đây bạn có thể thấy "Create Issue", đây là /command đầu tiên tôi sẽ sử dụng. Và về cơ bản, điều này nói với Claude rằng, người dùng đang trong quá trình phát triển và đã nghĩ ra một lỗi (bug) hoặc một tính năng (feature) hay một cải tiến (improvement), hãy ghi lại nó thật nhanh để họ có thể tiếp tục làm việc. Và sau đó nó về cơ bản nói rằng, đây là định dạng mà tôi muốn bạn ghi lại issue trong Linear, và nó giải thích một loạt các điều chính xác mà Claude cần làm để đạt được điều đó. Vì vậy, cách tôi gọi điều này về cơ bản là tôi sẽ gõ /create issue và điều này sẽ đưa câu lệnh/lời nhắc này vào Claude. Vì vậy, nó nói: "Tôi sẵn sàng giúp bạn ghi lại issue này, bạn đang nghĩ gì?"
Chu trình làm việc toàn diện với /commands
Về cơ bản, tôi sẽ làm điều này nếu tôi đang làm việc trên một dự án lớn và đột nhiên tôi gặp một lỗi (bug) hoặc có một ý tưởng mà tôi không muốn làm ngay bây giờ, nhưng tôi muốn làm sau, tôi sẽ làm điều này rất nhanh và mục tiêu chính của Claude là nhanh chóng ghi lại những gì tôi đang nghĩ. Vì vậy, để nhanh chóng chạy qua toàn bộ quy trình làm việc của tôi. Về cơ bản, nó bắt đầu bằng việc tạo một issue. Vì vậy, đây là /command create issue, về cơ bản nói với Claude rằng tôi đang trong giai đoạn phát triển và nó nên nhanh chóng ghi lại những gì tôi đang nghĩ và tạo một issue trong Linear. Sau đó, khi tôi muốn tiếp tục, tôi có giai đoạn khám phá (exploration phase). Giai đoạn khám phá về cơ bản là nói với Claude, chúng ta sẽ chỉ khám phá những gì chúng ta muốn giải quyết ở đây. Nó có thể lấy thông tin từ Linear hoặc tôi có thể tự do nói chuyện với nó. Và điều nó sẽ làm là phân tích và hiểu issue và chỉ hỏi các câu hỏi làm rõ (clarifying questions). Giai đoạn tiếp theo sau khi chúng ta đã hoàn thành giai đoạn khám phá là chúng ta sẽ tạo một kế hoạch (create a plan). Vì vậy, bạn có thể thấy create plan. Điều này về cơ bản có một mẫu mà tôi yêu thích để tạo kế hoạch, và đầu ra của tác nhân (agent output) cuối cùng của điều này sẽ là một tệp Markdown với kế hoạch của chúng ta mà chúng ta có thể xây dựng cùng với code. Sau khi tạo kế hoạch, chúng ta có thực thi kế hoạch (execute plan). Sau khi thực thi, chúng ta có đánh giá (review) và sau đó chúng ta có đánh giá đồng cấp (peer review), điều này thực sự thú vị và chúng ta sẽ tìm hiểu sau, và cuối cùng, chúng ta cập nhật tài liệu (update the docs). Vì vậy, đây là việc cập nhật tài liệu và mọi thứ để các tác nhân AI (AI agents) có thể viết code tốt hơn sau này.
Giới thiệu ứng dụng StudyMate
Vì vậy, tôi nghĩ điều chúng ta sẽ làm là chúng ta sẽ xây dựng một tính năng trực tiếp cho ứng dụng của tôi, điều mà tôi nghĩ là thực sự thú vị. Nhưng trước tiên, tôi muốn giới thiệu cho bạn ứng dụng để bạn có một số ngữ cảnh. Vậy đây là StudyMate. Đó là một nền tảng dành cho sinh viên, cho phép họ tải lên tài liệu học tập và tạo các bài kiểm tra tương tác (interactive tests) dựa trên tài liệu của riêng họ. Vậy ở đây chúng ta có thể đi lên trên cùng. Hãy tải lên một tệp PDF. Chúng ta có thể quyết định các trang mà chúng ta muốn được kiểm tra. Chúng ta có thể quyết định số lượng câu hỏi, mức độ khó. Và về cơ bản, điều gì xảy ra đằng sau hậu trường là chúng ta gửi thông tin mà người dùng đã tải lên cùng với câu lệnh/lời nhắc hệ thống (system prompt) và bất kỳ sự mở rộng nào khác mà người dùng đã quyết định gửi tới Gemini và chúng ta tạo một bài kiểm tra. Đây là những câu hỏi thử thách nhằm đánh giá khả năng hiểu. Bạn thậm chí còn có một số gợi ý và một khi chúng ta làm một vài câu trong số này, chúng ta có thể nộp... Tôi đã làm đúng hết ư? Kết quả tệ hại. Vâng, may mắn.
StudyMate: Dự án phụ thành công
Và để nói rõ ràng hơn về điều này, đây giống như một công việc kinh doanh phụ mà bạn có, một ứng dụng bạn đã xây dựng đang kiếm tiền. Đó là một thứ bạn đã lập trình theo cảm hứng/trực giác (vibe coded) mà không có technical background.
Vâng, đây là dự án cuối tuần của tôi. Vâng. Đây là những gì tôi làm.
Tuyệt vời. Vào cuối tuần. Vâng. Vì vậy, bạn nhận được giải thích sâu sắc về lý do tại sao mỗi câu hỏi sai hoặc mỗi câu hỏi đúng. Và hiện tại, StudyMate chỉ có câu hỏi trắc nghiệm (multiple choice questions). Và tôi đã thực hiện một số nghiên cứu đối thủ cạnh tranh (competitor research) vào cuối tuần trước và tôi thấy các đối thủ cạnh tranh có câu hỏi đúng/sai (true or false questions) và cả câu hỏi điền vào chỗ trống (fill in the blank questions), điều mà tôi rất thích. Vì vậy, tôi nghĩ sẽ thực sự tuyệt vời nếu chúng ta có thể xây dựng điều đó trực tiếp. Nghe thế nào?
Đề xuất tính năng mới cho StudyMate
Tôi thích nó. Chúc mọi việc suôn sẻ. Tôi chỉ muốn nhấn mạnh những điều bạn đã chia sẻ ngay trước đó trong Cursor. Vì vậy, đây là một vấn đề lớn, những gì bạn mô tả ở đây. Về cơ bản, điều bạn đã tìm ra là một cách, với tư cách là một người không biết cách viết bất kỳ đoạn code nào, để xây dựng một sản phẩm trong Cursor với tư cách là một quản lý sản phẩm (product manager) bằng cách sử dụng một loạt các /command mà bạn đã tạo ra và bạn sẽ chia sẻ với người nghe. Họ có thể tải xuống tất cả những thứ này và sử dụng trực tiếp. Họ không cần phải tìm hiểu tất cả các câu lệnh/lời nhắc mà bạn đã tìm ra.
Tầm quan trọng của luồng làm việc /commands
Vâng, 100%. Về cơ bản, điều đã xảy ra là tôi đã hình thành xương sống của điều này với CTO, và nó về cơ bản nằm trong câu lệnh/lời nhắc hệ thống (system prompt) của dự án CTO mà tôi có trong GPT. Vì vậy, nó nói: "Bước một, chúng ta làm điều này. Bước hai, chúng ta làm điều này." Và bây giờ tôi sẽ tiếp tục xây dựng. Và nếu tôi thấy điều gì đó xảy ra lặp đi lặp lại, tôi sẽ chỉ tạo một /command và sau đó nó sẽ được tự động hóa trong quy trình làm việc.
Nguồn gốc của các /commands
Tuyệt vời. Vậy để tóm tắt /command. Một là tạo một issue trong Linear, điều mà tôi rất thích. Linear thật tuyệt vời. Xin chào Linear.
Quy Trình Phát Triển Sản Phẩm Tự Động Với AI
Đó cũng là từ lộ trình sản phẩm. Lộ trình sản phẩm. Ồ, thật là một giá trị!
Bước một là tạo issue trong Linear. Đó là một lệnh. Vì vậy, /command (lệnh) hoặc prompt (câu lệnh) bạn đã tạo chỉ là create issue. Tiếp theo là explore (khám phá), tức là khám phá ý tưởng, giúp tôi hình thành ý tưởng về những gì điều này có thể trở thành. Và đây là Claude giúp bạn suy nghĩ về tính năng và sản phẩm. Sau đó là thực sự create the plan (tạo kế hoạch). Tức là AI tools giúp bạn xây dựng kế hoạch để phát triển sản phẩm. Sau đó là execute (thực thi), tức là xây dựng sản phẩm. Và sau đó có bước review (đánh giá), peer review (đánh giá đồng cấp) rất tuyệt vời mà bạn sẽ chia sẻ. Và sau đó là document (tài liệu hóa), cập nhật tài liệu dựa trên tính năng mới mà chúng ta đang thêm vào. Tuyệt vời. Vâng. Hay lắm.
Demo: Tạo Issue Cho Tính Năng Mới
Vậy thì chúng ta hãy bắt đầu xây dựng. Tôi sẽ sử dụng Wispr Flow để ra lệnh bằng giọng nói, và về cơ bản, điều này bắt đầu với /create issue. Điều này sẽ gửi prompt đó. Tôi rất thích điều này vì tôi thường làm việc này khi đang xây dựng một thứ gì đó khác. Về cơ bản, nó báo cho Claude biết rằng tôi đang trong quá trình xây dựng một thứ gì đó và tôi không có nhiều thời gian để lãng phí. Vì vậy, chỉ cần hỏi một vài câu hỏi ngắn gọn để có đủ thông tin ghi lại trong Linear.
Tôi muốn thêm các câu hỏi điền từ vào chỗ trống vào StudyMate. Tôi muốn 30% số bài kiểm tra được tạo ra dưới dạng câu hỏi điền từ vào chỗ trống. Tôi muốn có sáu câu trả lời tiềm năng cho hai vị trí trống, và tất nhiên sẽ chỉ có hai câu trả lời đúng. Tức là một câu trả lời đúng và hai câu trả lời sai cho mỗi vị trí, và tôi muốn giao diện là drag and drop (kéo và thả). Đây chỉ là một suy nghĩ nhanh về cách tôi muốn nó hoạt động. Vì vậy, nó sẽ hỏi tôi một vài câu hỏi. Các bài kiểm tra là 100% trắc nghiệm, cấu trúc câu hỏi, đoạn văn một câu với các chỗ trống và mức độ ưu tiên. Vì vậy, một và hai là đúng, và đây không phải là ưu tiên cao. Đó là một tính năng nice to have (nên có).
Claude Tạo Linear Issue Bằng Cách Sử Dụng Công Cụ AI
Bây giờ, về cơ bản, Claude sẽ sử dụng MCP, một công nghệ được tạo ra bởi Anthropic, cung cấp cho AI tools khả năng tool use (sử dụng công cụ). Công nghệ này được kết nối với Linear của tôi. Vì vậy, bây giờ nó sẽ sử dụng tất cả những gì chúng tôi đã nói và tạo một issue trong Linear.
Nhân tiện, trong khi cái này đang tải, tôi rất thích cách bạn mô tả điều này, đặc biệt là khi dùng chế độ giọng nói, nó giống hệt như cách bạn nói chuyện với một kỹ sư để mô tả một tính năng: "Đây là những gì tôi muốn." Và sau đó họ hỏi bạn các câu hỏi, đây là phần làm rõ. Vâng. Lúc đầu, khi tôi làm điều này với CTO, tôi đã làm với chế độ giọng nói của ChatGPT, và điều đó thật điên rồ. Nó thực sự giống như đang ideate (hình thành ý tưởng) với một người. Nó sẽ phản biện, đặt câu hỏi, và có thể một ngày nào đó các AI tools để viết code cũng sẽ đạt đến trình độ đó, nhưng nó chính xác là... nó thực sự giống như đang ngồi với CTO của tôi. Tuyệt vời. Đã tạo STU88. Vậy nếu chúng ta mở Linear bây giờ, chúng ta sẽ thấy... Để xem STU88 ở đâu. Đây rồi. Câu hỏi điền vào chỗ trống với giao diện drag and drop. Nó có phần TLDR (Too Long; Didn't Read - tóm tắt nhanh), có trạng thái hiện tại. Nó đã thực hiện một chút nghiên cứu về codebase (cơ sở mã), tôi nghĩ, các kết quả mong đợi, một số ngữ cảnh. Vâng, vậy là về cơ bản, cái này đã sẵn sàng để tôi tiếp tục khi tôi muốn xây dựng.
Giai Đoạn Khám Phá Với Lệnh /exploration phase
Vậy bây giờ, giả sử vài ngày trôi qua, tôi đã hoàn thành dự án hiện tại đang thực hiện, tôi có thể tiếp tục. Khi tôi bắt đầu làm, tôi gõ /exploration phase, đó là điều chúng ta đã nói. Và thay vì nhấn enter, tôi sẽ nhấn tab và tôi sẽ cho bạn thấy điều này. Về cơ bản, exploration phase (giai đoạn khám phá) sẽ nhận một đối số. Đây về cơ bản là một placeholder (phần giữ chỗ) trong prompt, cho phép tôi nhập một cái gì đó là extra context (ngữ cảnh bổ sung) cho AI tools. Vì vậy, tôi có thể nói ở đây, Linear STU88, đó là tham chiếu đến ticket (phiếu công việc). Và bây giờ, nó sẽ đi, nó sẽ tìm Linear ticket.
Mục Tiêu Của Giai Đoạn Khám Phá
Và ý tưởng là gì? Mục tiêu của giai đoạn khám phá là gì? Đó là ideate (hình thành ý tưởng). Có phải vậy không? Chính xác. Đúng vậy. Về cơ bản, nó giúp CTO hiểu sâu sắc vấn đề mà chúng ta đang cố gắng giải quyết và cũng hiểu trạng thái hiện tại của codebase, những file nào cần được tác động và cách tốt nhất để triển khai về mặt kỹ thuật. Và thông thường, điều xảy ra là hiện tại, Claude chỉ đơn giản là đọc một loạt các file, hiểu cấu trúc cơ bản của mã, và sau đó nó sẽ quay lại với một loạt các câu hỏi làm rõ mà sẽ quyết định cách chúng ta cuối cùng sẽ triển khai điều này.
Claude Đóng Vai Trò CTO/Kỹ Sư Trưởng
Vậy thì nó giống như đang nói chuyện với engineering manager (trưởng phòng kỹ thuật) của bạn. Chính xác, chính xác. 100% đây là cách tôi nghĩ về nó. Và bạn nói rằng bạn là một CTO, vậy bạn đã từng sử dụng prompt của ChatGPT để có một CTO ở đó. Bây giờ CTO đang ở trong Cursor này? Vâng, vì cách các AI tools đã phát triển và chúng trở nên rất giỏi cả trong exploration (khám phá) lẫn code execution (thực thi mã). Vì vậy, bây giờ chỉ là một thói quen mà tôi gọi nó là CTO, nhưng về cơ bản, nó là tất cả trong một. Cùng một agent (tác nhân) sẽ thực hiện cả exploration và viết kế hoạch, và cuối cùng thực thi mã. Tôi hiểu rồi. Vậy thì về cơ bản đó là Claude Code. Có prompt nào bạn đã đưa cho nó để nó hành động như vậy không? Để hành động như một CTO phù hợp? Vâng, trong Claude.md, về cơ bản là system prompt (lời nhắc hệ thống) được tải trong context memory window của Claude trong mỗi cuộc hội thoại, tôi có một số thứ cơ bản như đây là workflow (quy trình làm việc) của chúng tôi, đây là cách chúng tôi làm việc. Trong exploration phase, tôi muốn bạn thử thách suy nghĩ của tôi, tất cả những thứ tương tự có thể được tải trong file Claude.md.
Chất Lượng Linear Issue Do AI Tạo Ra
Tuyệt vời. Một câu hỏi cuối cùng trước khi chúng ta tiếp tục ở đây, chỉ vì tôi đang nghĩ về nó khi điều này xảy ra, Linear issue mà bạn đã tạo ra, nó thực sự tốt và sẵn sàng bao nhiêu lần? Bạn phải chỉnh sửa nó bao nhiêu lần? Quality (chất lượng) của Linear ticket mà nó tạo ra là gì? Bởi vì rất nhiều người có lẽ đang tự hỏi rằng tất cả những Linear issue tồi tệ này đang được tạo ra bởi AI tools. Chúng thực sự có tốt không? Nó hoàn toàn khác vì tôi là một công ty chỉ có một người. Vì vậy, rất nhiều ngữ cảnh nằm ở đây và tôi không cần phải nói chuyện với các nhóm khác và tìm hiểu. Về cơ bản, nó rất dễ tiếp cận, và tôi cũng có thể dễ dàng thấy khi Claude hiểu sai điều gì đó. Tôi không muốn nói rằng tôi sẽ tạo Linear issue ở công ty theo cách này, nhưng chắc chắn nếu bạn đang xây dựng dự án cá nhân, chúng khá chất lượng. Và hơn nữa, nó chỉ khởi động khi tôi muốn bắt đầu làm việc trên đó. Tôi không nói rằng nó đã sẵn sàng để được xây dựng. Nó đã sẵn sàng để bắt đầu được khám phá. Tôi hiểu rồi. Vậy thì đó chỉ là sự khởi đầu của một ý tưởng. Thực ra, hãy quay lại sau khi chúng ta xem xét quy trình này về cách bạn sẽ tiếp cận điều này nếu bạn ở Meta hoặc một công ty nhỏ hơn, cách workflow này có thể hoạt động ở một công ty lớn hơn không phải là startup (công ty khởi nghiệp) của riêng bạn. Vâng. Thú vị. Hãy quay lại điều đó sau. Tuyệt vời.
Claude Phân Tích Codebase và Đặt Câu Hỏi Làm Rõ
Được rồi. Vậy là Claude đã quay lại. Tôi có một sự hiểu biết toàn diện về codebase. Tôi đã phân tích kỹ lưỡng codebase của StudyMate live và hiểu hệ thống hiện tại, yêu cầu tính năng và các khu vực chính mà nó đã xác định. Thông thường, tôi sẽ dành rất nhiều thời gian để xem xét điều này vì nó cực kỳ, cực kỳ quan trọng, nhưng vì mục đích phát triển hiện tại, chúng ta sẽ bỏ qua nhanh. Bây giờ, Claude về cơ bản quay lại sau khi đã xem xét codebase và hiểu cách nó đang hoạt động. Nó về cơ bản đang nói cho tôi biết sự hiểu biết hiện tại là gì. Vì vậy, nó đang nói về cách ứng dụng được thiết lập vào lúc này, cách dữ liệu được cấu trúc, những gì nó hiểu từ yêu cầu tính năng, và những gì nó đã xác định là các khu vực chính, và sau đó nó hỏi tôi một số câu hỏi.
Vì vậy, nó hỏi về phạm vi, về data model (mô hình dữ liệu), UX/UI của tính năng, cách nó nên được xác thực, cách nó nên được chấm điểm, những thay đổi nào cần xảy ra với AI system prompt và tất cả các loại câu hỏi về ứng dụng. Tôi đã chuẩn bị câu trả lời cho tất cả những câu hỏi này từ trước vì tôi không nghĩ tất cả chúng ta muốn ngồi xem hết. Vì vậy, tôi sẽ chỉ dán nó vào và chúng ta sẽ xem Claude nói gì.
Hỏi Đáp Sâu Sắc và Lệnh /learning opportunity
Tuyệt vời. Tôi thích nó. Và tôi thích việc chỉ cần lướt qua những câu hỏi nó đang hỏi. Đó là những câu hỏi thông minh, tinh tế và quan trọng thay vì chỉ nói, "Được rồi, tôi bắt đầu xây dựng đây." Vâng, và tôi nghĩ đây là sự khác biệt lớn giữa vibe coding (lập trình theo cảm hứng/trực giác) và việc thực sự xây dựng các ứng dụng nghiêm túc. Tôi dành rất nhiều, rất nhiều thời gian để qua lại và tìm hiểu. Ngoài ra, một /command (lệnh) rất hay mà tôi chưa thể hiện là learning opportunity (cơ hội học hỏi), về cơ bản khi một điều gì đó thực sự khó hiểu đối với tôi, tôi sẽ gõ /learning opportunity và sau đó nói về những gì tôi muốn học. Và điều này về cơ bản sẽ prime (huấn luyện) Claude và nói, "Tôi là một technical PM (quản lý sản phẩm kỹ thuật) đang trong quá trình phát triển. Tôi có kiến thức kỹ thuật ở cấp độ trung bình. Tôi hiểu về kiến trúc và về cơ bản tôi muốn bạn giải thích những gì chúng ta đang làm bằng cách sử dụng quy tắc 80/20." Vì vậy, đây là một cách tuyệt vời để học. Tôi chắc chắn sẽ sử dụng điều này và mỗi khi bạn thấy một điều gì đó mà bạn không hoàn toàn hiểu, tôi chắc chắn sẽ sử dụng điều này để học.
Tạo Kế Hoạch Triển Khai
Tuyệt vời. Vì vậy, Claude về cơ bản quay lại và nói về cách nó hiểu data model hiện tại và cách nó sẽ triển khai. Vâng, vậy là nó đã sẵn sàng để tạo kế hoạch. Vì vậy, về cơ bản, bây giờ tôi sẽ đi và gõ /create plan và trong khi Claude đang làm điều này, tôi sẽ nhanh chóng cho thấy điều này trông như thế nào. Về cơ bản, những kế hoạch này đến từ một template (mẫu) mà tôi tìm thấy trên Twitter. Tôi quên mất ai là người đã đăng nó, nhưng đó chỉ là một template thực sự gây ấn tượng với tôi. Và nó về cơ bản nói rằng, dựa trên cuộc trao đổi của chúng ta, hãy tạo một file markdown sẽ là kế hoạch, bao gồm các bước rõ ràng, tối thiểu, súc tích, theo dõi trạng thái. Vì vậy, điều này về cơ bản có các status tracker (công cụ theo dõi trạng thái) trên mỗi tác vụ mà Claude cập nhật khi nó thực hiện và nó sẽ có một TLDR, một số quyết định quan trọng mà chúng ta đã đưa ra và bản kế hoạch.
Kế Hoạch Hoàn Chỉnh và Lựa Chọn Mô Hình AI
Vậy là Claude đã hoàn thành việc viết kế hoạch, vì vậy chúng ta có thể xem chính xác kế hoạch là gì. Nó có TLDR, nó có các quyết định quan trọng mà chúng ta đã đưa ra và các tác vụ được chia nhỏ. Và đây là một kế hoạch hoàn hảo và nó cũng là một cách rất tốt để viết điều này bởi vì rất nhiều lần, tôi sẽ sử dụng các models (mô hình) khác nhau để thực hiện các tác vụ nhất định. Vì vậy, Cursor có một model tuyệt vời gọi là Composer, rất nhanh. Vì vậy, rất nhiều thứ không quá phức tạp, tôi sẽ sử dụng Composer. Gemini 3 vừa ra mắt là một AI tools đáng kinh ngạc về UI.
Thực thi kế hoạch và phân chia công việc
Rất nhiều lần, tôi sẽ chia kế hoạch thành backend và frontend, sau đó tôi sẽ để Gemini đọc kế hoạch và thực hiện phần frontend. Vì vậy, việc có tệp này dưới dạng markdown là rất tốt. Và trong tương lai, việc có nó trong ứng dụng cũng rất hay để sau này, nếu một agent viết mã trong một khu vực nhất định, tôi có thể xem những gì đã được thực hiện ở đó.
Vậy bây giờ chúng ta sẽ thực hiện kế hoạch. Tôi nghĩ chúng ta sẽ làm việc này với Cursor chỉ vì Composer quá nhanh. Về cơ bản, chúng ta có thể chỉ cần nói "execute" (thực thi) và sau đó gắn thẻ tệp. Composer nhanh một cách đáng kinh ngạc. Vậy là xong. Nó bắt đầu chạy. Nó hiểu kế hoạch là gì và sẽ tiến hành viết mã.
Hạn chế của các công cụ AI khác
Để tôi hỏi bạn một câu khi việc này đang diễn ra. Tuyệt vời. Tôi có nhiều câu hỏi, nên đây là thời điểm tốt để hỏi một vài câu. Bạn nói rằng Lovable và Bolt cùng các ứng dụng khác trong lĩnh vực đó không đủ để xây dựng các ứng dụng thực sự nghiêm túc, và bạn phải chuyển sang Cursor để làm điều đó. Hãy nói thêm về điều đó. Hạn chế bạn gặp phải với những sản phẩm đó là gì và tại sao bạn lại chuyển sang Cursor?
Tôi bắt đầu sử dụng Cursor và Claude Code vài tháng trước và chưa bao giờ hối hận. Nhưng vào thời điểm đó, các đội này đã phát triển rất nhanh. Vì vậy, tôi không muốn nói rằng tôi không tin tưởng họ. Tôi không biết tình hình hiện tại ra sao. Nhưng đối với tôi, vấn đề cơ bản là tôi cảm thấy Bolt quá mang tính chủ quan về cách tôi nên làm mọi việc. Và tôi cảm thấy kiến thức của mình đã đủ để tôi có thể "tốt nghiệp" và kiểm soát nhiều hơn.
Điểm khác biệt chính: Quyền kiểm soát harness và model
Nhân tiện, tôi nghĩ rằng sự khác biệt chính giữa tất cả các công cụ này về cơ bản là harness (cơ chế điều khiển/khai thác). Các model đều giống nhau. Tôi sẽ chạy Claude trong Cursor, tôi sẽ chạy nó trong Claude Code, và Claude cũng là model nền tảng của Bolt và Lovable. Nhưng về cơ bản, Bolt và Lovable sẽ thêm một loạt các cấp độ trung gian, loại bỏ mọi phỏng đoán và các quyết định khó khăn cho người dùng. Vì vậy, người dùng không phải đưa ra những quyết định khó khăn này. Điều đó giúp việc xây dựng cũng rất dễ dàng, nhưng mặt trái là bạn có ít quyền kiểm soát hơn. Về cơ bản, Claude Code chỉ lấy Claude và đưa thẳng vào hệ thống mã của bạn, cung cấp đầy đủ công cụ và để nó làm bất cứ điều gì nó muốn. Tuy nhiên, điều đó cũng đi kèm với rất nhiều quyết định mà bạn cần phải đưa ra. Vì vậy, tôi không biết liệu bạn có thể xây dựng các ứng dụng sản xuất thực sự tuyệt vời bằng Bolt hoặc Lovable hiện nay hay không, nhưng tôi nghĩ về cơ bản, nếu bạn muốn tận dụng tối đa các khả năng tiên tiến nhất của các model và muốn tự mình đưa ra mọi quyết định, thì có lẽ tốt nhất là nên sử dụng một trong những công cụ này.
Điều tôi cảm thấy và nghe được là công việc lập kế hoạch mà bạn đã làm, đó là những gì Lovable, Bolt, và bạn có xếp Replit vào nhóm đó không? Chắc chắn rồi. Lovable, Bolt, Replit, Base44, v0. Đúng vậy, v0, tất cả đều cùng một nhóm. Về cơ bản, họ thực hiện việc lập kế hoạch đó cho bạn. Và như bạn đã nói, họ rất chủ quan. Họ cố gắng làm cho mọi thứ dễ dàng. Giống như, "Đây là cách làm. Đây là cách chúng tôi nghĩ là tốt nhất cho mọi người." Và điều bạn đang nói là một khi bạn muốn nghiêm túc hơn một chút về nó hoặc muốn đi theo một hướng khác, bạn không có quyền thay đổi cách họ lập kế hoạch. Vì vậy, Cursor cho phép bạn làm điều đó.
Đánh đổi giữa sự tiện lợi và quyền kiểm soát
Vâng, tôi không muốn điều này nghe giống như tôi đang nói xấu họ. Ví dụ Base44. Không, hoàn toàn không. Vâng. Base44 làm rất tốt công việc loại bỏ mọi phỏng đoán phức tạp trong việc xây dựng sản phẩm và chỉ cho phép bạn vibe coding (lập trình theo cảm hứng/trực giác) và xây dựng. Nhưng nó sẽ thực hiện đăng nhập bằng Google cho bạn và nó sẽ thực hiện một cơ sở dữ liệu, nhưng sau đó bạn không có quyền quyết định mình đang sử dụng cơ sở dữ liệu nào. Tôi có cần đăng nhập bằng Google theo cách này hay cách khác không? Nó sẽ làm điều đó ngay lập tức. Vì vậy, đó về cơ bản là sự đánh đổi ở đây.
Tuyệt vời. Xin gửi lời chào đến Maor, nhà sáng lập của Base44. Vâng, Maor Shlomo. Vâng, anh ấy thật tuyệt vời.
Linh hoạt sử dụng nhiều model AI
Được rồi. Tôi thích cách bạn "ném" các model như Gemini 3 cho frontend như thế này. Tôi thích việc bạn chưa bao giờ viết bất kỳ mã nào mà bạn chỉ cần nói, "Tuyệt, dùng Gemini cho cái này và Claude cho cái kia. Và tôi chỉ làm việc trên Cursor, nói chuyện với CTO này, giúp bạn xây dựng mọi thứ và tạo ra sản phẩm quan trọng."
Thời khắc cỗ máy thời gian và khả năng không giới hạn của AI
Vâng. Chúng ta đang sống trong thời kỳ điên rồ nhất, nơi mà thế giới thay đổi gần như mỗi tuần. Và không có bất kỳ ranh giới nào. Bạn có thể sử dụng tất cả những công cụ này chỉ trên chiếc MacBook hoặc laptop thông thường của mình. Và tôi có những khoảnh khắc mà tôi gọi là thời khắc cỗ máy thời gian, ví dụ như tuần này, tôi đang chuẩn bị cho podcast bằng cách sử dụng Claude với một dự án. Tôi đang xây dựng, tôi đã hoàn tất việc bản địa hóa StudyMate từ tiếng Hebrew sang tiếng Anh, điều mà tôi làm trong hai ngày, trong khi một nhóm phát triển có thể mất hàng tuần. Và tôi đang xây dựng một trang web cá nhân, từ không có domain, không có gì cả, đến trực tuyến trên một domain chỉ trong vòng một tiếng rưỡi. Và tôi đang làm cả ba việc này song song. Và có một lúc mà về cơ bản cả ba agent đều đang chạy, nên tôi không có gì để làm. Tôi chỉ cần để chúng suy nghĩ. Và đây là những thời khắc cỗ máy thời gian mà tôi cảm thấy mình đang ở trong tương lai, và tôi chỉ thò đầu ra khỏi cỗ máy thời gian và nói với người bên cạnh, lúc đó là vợ tôi, "Chúng ta đang sống trong tương lai." Và cô ấy sẽ kiểu, "Hả, gì cơ?" Và tôi sẽ nói, "Không, không, đừng lo lắng về điều đó." Nhưng về cơ bản, thật điên rồ khi tất cả những điều này chỉ cách một API. Bạn có thể sử dụng bất cứ thứ gì. Vì vậy, tôi nghĩ đây là thời điểm tuyệt vời để tò mò, lạc quan và chăm chỉ.
Đây là những kiểu khách mời podcast mà tôi yêu thích. Những người đang sống trong tương lai, tìm ra tất cả những điều này và sau đó quay lại, như bạn đã nói, thò đầu ra khỏi tàu vũ trụ và nói, "Này, đây là điều tôi đã tìm ra. Đây là nơi chúng ta đang hướng tới."
Vâng, thời điểm tốt nhất để sống.
Kiểm tra sản phẩm cuối cùng: Tốc độ vượt trội của AI
Tuyệt vời. Vậy là nó đã hoàn thành. Bây giờ chúng ta sẽ chạy ứng dụng cục bộ và sẽ xem Composer đã xây dựng được gì, và chúng ta sẽ xem liệu có cần thêm gì nữa từ phía chúng ta để có thể thực hiện một số kiểm tra thủ công hay không. Nghe có vẻ ổn chứ? Nghe tuyệt vời. Và tôi thích điều này, nó chỉ mất vài phút, trong khi nếu là một kỹ sư con người, thì sẽ mất hàng ngày, thậm chí cả tuần để hoàn thành công việc.
Chắc chắn rồi. Vâng, chắc chắn rồi. Không, Composer, điều đặc biệt là nó quá, quá nhanh, giúp bạn duy trì trạng thái tập trung. Vì vậy, vâng, các tính năng đầy đủ chỉ mất vài phút. Và có lẽ nó chỉ tốn vài đô la tín dụng AI. Tôi thậm chí không thèm nhìn. Tôi từng rất keo kiệt trong việc trả tiền cho các sản phẩm, nhưng bây giờ, về cơ bản, tôi coi tất cả là học phí, là những thứ tôi đang trả để học hỏi. Vì vậy, tôi không biết nó tốn bao nhiêu, nhưng chắc chắn là đáng giá.
Điều đó giải thích tại sao chúng là những sản phẩm phát triển nhanh nhất trong lịch sử.
Quảng cáo
100%. Website marketing của bạn thiết lập tông điệu cho thương hiệu và là điểm chạm duy nhất mà mọi khách hàng đều nhìn thấy. Trong thời đại ngày nay, nếu bạn vẫn gặp khó khăn trong việc thực hiện các thay đổi nhỏ và cập nhật đơn giản cho nó, thì bạn đang làm sai điều gì đó. Đó là lý do tại sao rất nhiều công ty, từ các startup giai đoạn đầu đến các công ty trong danh sách Fortune 500, bao gồm các công ty như DoorDash, Zapier, Perplexity và ElevenLabs, đều tìm đến Framer, công cụ xây dựng website biến .com của bạn từ một hình thức thành một công cụ tăng trưởng. Framer hoạt động như công cụ thiết kế yêu thích của nhóm bạn và đi kèm với cộng tác thời gian thực, một CMS mạnh mẽ với mọi thứ bạn cần cho SEO tuyệt vời và phân tích nâng cao bao gồm cả kiểm thử A/B tích hợp. Các thay đổi đối với trang Framer của bạn sẽ được đưa lên web chỉ trong vài giây với một cú nhấp chuột mà không cần bất kỳ sự trợ giúp nào từ đội kỹ thuật. Cho dù bạn muốn khởi chạy một trang web mới, thử nghiệm một vài trang đích hay di chuyển toàn bộ .com của mình, Framer đều có các chương trình dành cho startup, scale-up và doanh nghiệp lớn để giúp việc chuyển từ ý tưởng đến trang web trực tuyến trở nên dễ dàng và nhanh chóng nhất có thể. Hãy tìm hiểu cách biến website của bạn thành động cơ tăng trưởng từ chuyên gia của Framer hoặc bắt đầu xây dựng miễn phí ngay hôm nay tại framer.com/lenny, đó là framer.com/lenny. Các quy tắc và hạn chế có thể được áp dụng.
Quy trình peer review đa model
Vậy bây giờ chúng ta có tính năng này, về cơ bản là chúng ta đã xây dựng, và tôi có thể yêu cầu nó thực hiện một số thay đổi vì nó đang chạy cục bộ, và một khi nó sẵn sàng, tôi sẽ có thể phân phối nó cho người dùng. Vậy bây giờ, giai đoạn tiếp theo sau khi tôi đã QA (kiểm thử chất lượng) và kiểm tra thủ công, tôi sẽ để Claude tự xem xét công việc của chính nó. Vì vậy, điều tôi sẽ làm là mở lại Claude Code.
Tôi thích điều này vì đây là một trong những vấn đề thường xuyên được nhắc đến trong podcast này: viết mã giờ đây đã quá dễ dàng. Thử thách chính mà mọi người gặp phải là xem xét mã mà AI đã viết. 100%. Và điều bạn đang làm ở đây là bạn để Claude tự xem xét mã của chính nó.
Vâng, đây cũng là một điều khác mà tôi rất khó phát hiện lỗi. Vì vậy, quy trình xem xét của tôi đã trải qua nhiều lần lặp lại để thực sự tốt nhất có thể và phát hiện càng nhiều lỗi càng tốt. Vì vậy, tôi sẽ luôn QA thủ công trước để đảm bảo rằng tôi có thể nhìn thấy bất kỳ lỗi nào mà Claude đã mắc phải. Và sau đó, điều tôi sẽ làm về cơ bản là /review. Và điều này yêu cầu Claude bắt đầu xem xét mã của chính nó. Nhưng điều thậm chí còn tuyệt vời hơn và là điều tôi thực sự tự hào là tôi thường thực hiện nhiều lần xem xét và tôi sẽ mở Codex, đối thủ cạnh tranh của ChatGPT với Claude Code, cũng như Cursor, và tôi sẽ để mỗi công cụ trong số chúng xem xét mã. Và sau đó, điều tôi làm là tôi có một /command (lệnh) gọi là peer review (đánh giá đồng cấp), điều này thực sự thú vị. Và về cơ bản, nó sẽ lấy Claude, thường là agent mà tôi đang làm việc cùng. Và để đặt điều này vào một mental model (mô hình tinh thần), đây về cơ bản là trưởng nhóm phát triển của tôi mà tôi đang làm việc cùng. /command về cơ bản nói, "Bạn là trưởng nhóm phát triển của dự án này. Các trưởng nhóm khác trong công ty đã xem xét mã của bạn và tìm thấy những vấn đề này." "Đừng chấp nhận những gì họ nói một cách máy móc. Lý do là bạn có nhiều ngữ cảnh hơn họ và bạn đã dẫn dắt dự án này. Bạn cần giải thích tại sao những gì họ tìm thấy không phải là vấn đề thực sự và sai, hoặc tự mình sửa chúng." Và điều đó thực sự tuyệt vời vì cách tôi nhìn nhận những điều này là tôi nhìn vào các model, tôi cố gắng hình dung chúng như những con người, và tôi thực sự có thể cho bạn biết mỗi model trong số này sẽ như thế nào nếu là một con người thực sự vì chúng có – mỗi model. Vâng. Mỗi model đều có những đặc điểm riêng biệt.
Nhân Cách Hóa Các Mô Hình AI
Vậy, giả sử Claude là một CTO hoàn hảo. Cô ấy rất giỏi giao tiếp, rất thông minh. Cô ấy không chỉ làm theo và thực hiện mọi điều bạn bảo. Cô ấy rất có chính kiến, nhưng cũng cực kỳ hợp tác. Đó là lý do tôi luôn bị thu hút bởi Claude, vì tôi cần học hỏi rất nhiều. Cô ấy giống như một dev lead trong mơ: rất giỏi giao tiếp nhưng cũng rất có chính kiến.
Thế rồi có cả Codex nữa. Tôi dùng Codex 5.1 Max, hay bất kể tên gì đi nữa. Tôi không biết, họ không giỏi đặt tên cho các mô hình, nhưng đó là mô hình của GPT. Tôi luôn hình dung nó như lập trình viên giỏi nhất trong công ty, người đến văn phòng với áo hoodie và dép lê, ngồi trong một căn phòng tối. Bạn chỉ làm phiền anh ta khi gặp những lỗi nghiêm trọng nhất và nói: "Nghe này, chúng ta có lỗi này." Anh ta sẽ đóng cửa hai tiếng, rồi đi ra và nói: "Tôi đã sửa xong." Bạn sẽ hỏi: "Khoan đã, gì cơ? Anh sẽ cho chúng tôi biết chuyện gì đã xảy ra không?" Anh ta chỉ đáp: "Đừng lo lắng. Tôi đã sửa rồi." Anh ta thực sự không giỏi giao tiếp, nhưng giải quyết tất cả các vấn đề khó nhất.
Và giả sử Gemini là một nhà khoa học điên rồ, cực kỳ nghệ thuật, rất tài năng trong thiết kế, nhưng nếu bạn ngồi cạnh và xem nó làm việc, thì thật đáng sợ. Bạn sẽ sa thải người đó ngay lập tức. Đây có thể chỉ là kinh nghiệm của riêng tôi, nhưng khi tôi sử dụng Gemini trong Antigravity (đối thủ cạnh tranh mới của Google với Cursor), khi nó viết mã, bạn có thể thấy các bước nó thực hiện và điều đó thật kinh hoàng. Bạn sẽ nói: "Tôi muốn bạn thiết kế lại phần trên của bảng điều khiển." Và bạn nhìn vào quá trình tư duy của nó, nó sẽ nói: "Ồ, việc đầu tiên, tôi sẽ xóa bảng điều khiển." Rồi nó sẽ nói: "Không, đó là một sai lầm. Tôi sẽ khôi phục lại." Và sau đó nó sẽ hỏi: "Ồ, tôi có thể chỉnh sửa database không?" Và bạn sẽ nói: "Không, đừng chỉnh sửa database. Bạn chỉ đang thiết kế lại thôi." Và cuối cùng nó sẽ thiết kế ra một thứ đẹp đẽ. Vì vậy, quá trình này giống như một chuyến tàu lượn siêu tốc và rất đáng sợ, nhưng suy cho cùng, Gemini rất giỏi về thiết kế.
Quy Trình Peer Review Đa Mô Hình
Tôi nghĩ việc sử dụng tất cả các mô hình này và tận dụng thế mạnh của chúng, đồng thời khắc phục điểm yếu bằng cách sử dụng các mô hình khác, là một bước ngoặt lớn đối với tôi. Tôi sẽ thực hiện peer review nhiều lần và để các mô hình khác đánh giá mã của các mô hình khác, về cơ bản là để chúng "đấu với nhau". Đôi khi Claude Code sẽ trở nên khá đanh đá và nói: "Điều này đã được nêu ra lần thứ ba rồi. Và lần thứ ba tôi nói với bạn, đây không phải là vấn đề. Đây là một thiết kế có chủ đích." Vì vậy, đó chỉ là một điều thực sự thú vị mà tôi đã thêm vào và tôi chưa thấy nhiều người làm.
Đó là một cách diễn giải/hiểu đáng kinh ngạc về những gì đang diễn ra. Tuyệt vời. Chúng ta vừa chạy quá trình review. Vậy hãy cho chúng tôi xem những gì chúng ta đã thấy ở đó và hãy thực sự thử peer review này. Tôi thực sự rất hào hứng muốn xem bạn đã học được gì ở đó. Vâng. Về cơ bản, Claude đã review mã của chính nó và tìm thấy một loạt lỗi, một lỗi nghiêm trọng mà nó tìm thấy trong prompt, một số lỗi nghiêm trọng khác, và một số lỗi trung bình. Và bây giờ tôi sẽ làm điều tương tự với các mô hình khác. Codex có chức năng code review tích hợp sẵn mà bạn có thể sử dụng, hoặc tôi chỉ đơn giản là nói "review tất cả mã trong branch này". Tất nhiên, branch ở đây là branch GitHub mà chúng tôi đang làm việc. Chúng tôi không làm việc trên code base trực tiếp. Và sau đó tôi sẽ làm điều này với Composer, giả sử với Composer One. Tôi cũng sẽ thực hiện /review ở đây. Và về cơ bản, cả hai sẽ chạy và thực hiện một review chuyên sâu tương tự như Claude. Nhưng một lần nữa, vì sự khác biệt giữa các mô hình, chúng sẽ phát hiện những điều khác nhau và chúng sẽ nhìn nhận khác nhau, và đây là một cách làm việc thực sự hay. Về cơ bản, nó giống như việc bạn có các team lead khác trong công ty review mã. Ở đây, bạn có thể thấy Composer nhanh như thế nào. Tôi nghĩ GPT có thể sẽ mất khá nhiều thời gian. Như tôi đã nói, nó đang ở trong căn phòng tối của riêng mình để review mã và sẽ quay lại sau vài phút.
Tuyệt vời. Vậy chúng ta có thể để chúng chạy. Chúng ta không thực sự phải trải qua toàn bộ quá trình, nhưng ý tưởng là một khi bạn nhận được kết quả này, bạn chạy peer review và sao chép và dán các kết quả này. Đó có phải là ý tưởng không? Chính xác. Tôi sẽ sao chép và dán kết quả. Tôi sẽ thực hiện peer review và sau đó tôi sẽ nói dev lead một và dán từ một trong các mô hình. Và sau đó tôi sẽ nói dev lead hai và dán từ mô hình khác, và về cơ bản là để chúng "đấu" với nhau cho đến khi tôi cảm thấy không còn vấn đề nào nữa. Thật đáng kinh ngạc. Đối với tôi, điều này cực kỳ quan trọng vì tôi không có nền tảng kỹ thuật và tôi không phải là một nhà phát triển. Và tôi cũng sẽ sử dụng /learning opportunity rất nhiều trong quá trình này để tìm hiểu về những thứ mà tôi không hiểu hoặc không nắm bắt được đầy đủ. Thật đáng kinh ngạc. Một giải pháp thông minh để giải quyết vấn đề code review này, nơi mà tôi không biết gì... Tôi không biết cách viết lại mã, vậy tôi sẽ làm gì đây? Vâng. Vâng. Được rồi. Thật đáng kinh ngạc. Hãy kết thúc quy trình làm việc này. Còn điều gì quan trọng nữa trong quy trình làm việc này không? Và một lần nữa, tất cả những thứ này sẽ có sẵn để mọi người có thể chỉ cần cắm chúng vào tài khoản Cursor của họ và tự sử dụng.
Phân Tích Sai Lầm (Postmortem) và Cải Tiến Liên Tục
100%. Một điều tôi muốn nói là tôi nghĩ, giống như làm việc nói chung với AI và thậm chí chỉ làm việc trên bất kỳ sản phẩm nào, việc thực hiện postmortem liên tục là rất quan trọng. Vì vậy, rất nhiều lần chúng ta sẽ tìm thấy tất cả những loại lỗi này hoặc có thể Claude sẽ không thực hiện đúng một điều gì đó. Và ban đầu khi tôi bắt đầu lập trình theo cảm hứng/trực giác, tôi về cơ bản cứ tiếp tục lao vào nó như đâm đầu vào tường cho đến khi nó hoạt động. Và một khi nó hoạt động, tôi nói: "Được rồi, tuyệt vời. Nó hoạt động rồi. Hãy tiếp tục thôi." Nhưng theo thời gian, tôi đã học được rằng cập nhật tài liệu và tooling là một trong những cách hiệu quả nhất để tăng năng suất.
Vì vậy, khi Claude không làm được điều gì đó hoặc tôi thấy một lỗi rất tệ cho thấy Claude thực sự không hiểu điều gì đó, tôi sẽ hỏi nó: "Điều gì trong system prompt hoặc tooling của bạn đã khiến bạn mắc lỗi này?" Và Claude sẽ tự xem xét nội tâm và suy nghĩ về điều gì đã khiến nó tạo ra lỗi đó. Và sau đó tôi sẽ nói: "Được rồi, tuyệt vời. Hãy cập nhật tooling và tài liệu của bạn để lỗi này không bao giờ xảy ra nữa." Và tôi làm điều này mỗi khi tôi xây dựng một internal tool hoặc bất cứ điều gì. Và tôi nghĩ điều này cũng giống như làm việc vậy. Nếu bạn mắc nhiều lỗi và sau đó phát hành tính năng cho người dùng, bạn sẽ nói: "Được rồi, đó là một thành công lớn." Nhưng việc quay lại và ngay cả khi bạn đã thành công, việc xem xét và hiểu những gì bạn đã làm và những gì bạn có thể làm tốt hơn là rất quan trọng. Và cũng khi sử dụng AI, đây có lẽ là một trong những yếu tố giải phóng lớn nhất. Quay lại câu lệnh/lời nhắc của bạn, hiểu những gì chưa đủ tốt, lặp lại chúng và sau đó xem cách phản hồi của AI trở nên tốt hơn, tôi nghĩ đó có lẽ là một trong những điều quan trọng nhất và là một trong những điều phân biệt giữa những người ổn với việc sử dụng AI và những người thực sự biết cách sử dụng nó.
Đó là một lời khuyên rất hay. Vậy điều tôi đang nghe là khi các mô hình làm điều gì đó ngớ ngẩn, mắc lỗi, bạn yêu cầu nó tự suy ngẫm về lỗi mà nó đã mắc phải, và sau đó bạn cập nhật các prompt của lệnh /command với kiến thức đó để trong tương lai, nó sẽ không mắc cùng lỗi đó nữa, và nó cứ thế ngày càng tốt hơn. Chính xác. Những thứ này cứ ngày càng thông minh hơn. Vì vậy, bạn đang xây dựng một câu lệnh/lời nhắc thực sự đáng kinh ngạc và cứ ngày càng tốt hơn. Chính xác. Không phải lúc nào cũng là các lệnh /command. Đôi khi nó sẽ cập nhật tài liệu khác hoặc tooling của nó, nhưng về cơ bản, đó là việc hiểu nguyên nhân gốc rễ của lỗi mà AI đã mắc phải và sửa chữa nó. Tuyệt vời. Vì vậy, các mô hình ngày càng thông minh hơn và sau đó các phần khác trong quy trình làm việc của bạn cũng có thể trở nên thông minh hơn khi bạn tìm thấy những sai sót trong cách nó thực hiện công việc. 100%. Vâng. Tuyệt vời. Được rồi. Còn điều gì khác không trước khi tôi chuyển sang một vài hướng khác? Tôi nghĩ vậy là đủ rồi. Tôi nghĩ chúng ta đã đề cập khá nhiều mọi thứ. Về cơ bản, để tóm tắt lại, những gì tôi làm là tôi thực hiện rất nhiều code review và sau đó cập nhật tài liệu để mọi thứ được ghi lại. Vì vậy, lần tới khi tôi cố gắng xây dựng một tính năng trong lĩnh vực này, sẽ không có lỗi nào xảy ra. Và sau đó tôi sẽ thực hiện rất nhiều thử nghiệm. Tôi cũng sẽ thực hiện một số user testing trước khi phát hành tính năng này rộng rãi. Rõ ràng chúng ta sẽ không phát hành cái này. Đây chỉ là một buổi trình diễn, nhưng hy vọng có lẽ vào thời điểm podcast ra mắt, tôi sẽ làm điều này một cách chính xác và phát hành tính năng.
AI Mở Ra Cơ Hội Cho Các Nhà Phát Triển Không Có Nền Tảng Kỹ Thuật
Thật khó tin rằng điều này đã không thể thực hiện được cách đây, tôi không biết, hai năm trước, có lẽ một năm trước. Bạn là một product manager đang triển khai một sản phẩm mà không biết viết mã, hầu như không biết review mã. Bạn nói rằng bạn sợ nhìn vào mã. Là một product manager, bạn đang xây dựng một sản phẩm trong Cursor bằng cách sử dụng tất cả các công cụ AI khác nhau này. Bạn đang kiếm tiền từ sản phẩm này. Chúng ta đã quá quen với điều này bây giờ, nhưng thật điên rồ những gì hiện tại có thể thực hiện được. Đây là thời điểm tốt nhất để sống. 100%. Tôi nghĩ rằng tôi hiểu nỗi sợ hãi, nhưng AI chỉ làm cho mọi thứ trở nên khả thi hơn rất nhiều. Chỉ một ghi chú nhanh ở đây, anh trai tôi, người mà tôi đang xây dựng một trong những ứng dụng cùng, là một doanh nhân. Anh ấy có một doanh nghiệp tuyệt vời giúp người già và người cao tuổi hiểu cách sử dụng công nghệ và AI tốt hơn. Và anh ấy về cơ bản đang học hỏi giống như tôi, và anh ấy đã thay thế tất cả các tool mà anh ấy đã trả tiền. Tôi nghĩ anh ấy đã trả tiền cho Zapier và Airtable, và anh ấy về cơ bản đã xây dựng một hệ thống CRM và hệ thống tự động hóa hoàn chỉnh cho doanh nghiệp của mình hoàn toàn một mình. Vì vậy, đối với những người tò mò, lạc quan, chăm chỉ, đây là thời điểm tốt nhất để trở thành một người sáng tạo.
Và điều tôi yêu thích về cuộc trò chuyện chúng ta đang có ở đây là có cảm giác như rào cản lớn nhất đối với rất nhiều người là: làm thế nào để tôi bắt đầu? Tôi phải làm gì chính xác? Tôi mở Cursor ra. Nó trông rất đáng sợ. Tôi không biết viết mã. Tôi không biết xây dựng thứ gì đó. Tôi không biết về database. Và vì vậy, bạn sẽ chia sẻ tất cả các lệnh /command này và về cơ bản là toàn bộ quy trình làm việc này với khán giả. Vâng. Được rồi. Và như tôi đã nói, chỉ cần bắt đầu với GPT. Bắt đầu với GPT, nói cho nó biết ý tưởng của bạn là gì, yêu cầu nó giải thích cho bạn những bước đầu tiên của việc suy nghĩ, những quyết định bạn cần đưa ra là gì? Và chỉ cần tò mò, học hỏi. Đừng vội vàng.
Tích hợp AI vào quy trình làm việc tại các công ty lớn
Điều rất quan trọng là phải dấn thân và thực sự dành thời gian để học hỏi. Bạn cũng chia sẻ điều này. Một trong những câu lệnh của bạn là learning opportunity (cơ hội học hỏi), và đó là cách bạn học hỏi rất nhiều điều. Chỉ cần dạy tôi điều này và cách vấn đề cơ sở dữ liệu này hoạt động. Đúng vậy.
Có một vài khía cạnh tôi muốn đảm bảo chúng ta sẽ đề cập. Một là quay trở lại câu hỏi tôi đã hỏi trước đó về cách điều này có thể hoạt động ở một công ty lớn hơn. Giả sử không phải là Meta, mà chỉ là một công ty khoảng một nghìn người, 500 người. Bạn có thể tích hợp bao nhiêu phần trăm trong số này vào quy trình làm việc của một PM (Quản lý sản phẩm) tại một công ty lớn hơn? Lời khuyên của bạn dành cho người muốn bắt đầu thử nghiệm việc viết mã, ít nhất là cho mọi người thấy những gì có thể làm được, là gì?
Tôi nghĩ rằng việc biến cơ sở mã của bạn thành AI native là một bước thực sự quan trọng, và tôi nghĩ điều này cần được thực hiện bởi những người có technical background. Về cơ bản, cơ sở mã của tôi chứa rất nhiều văn bản thuần túy. Nó sẽ có một loạt các tệp Markdown giải thích cho các agent cách hoạt động trong các khu vực nhất định của cơ sở mã và cấu trúc cấp cao để các agent điều hướng cơ sở mã dễ dàng hơn.
Và tôi nghĩ rằng nếu điều này được thiết lập một cách thực sự tốt, tôi vẫn không nghĩ các PM nên thực hiện các database chain migration nặng nề hoặc bất kỳ dự án lớn nào. Nhưng các dự án UI (giao diện người dùng) độc lập, đặc biệt là nếu bạn chỉ xây dựng, tạo PR (Pull Request) và gửi cho một nhà phát triển để hoàn thiện cuối cùng. Tôi nghĩ đó chắc chắn là điều có thể. Và tôi nghĩ chúng ta sẽ thấy điều đó rất nhiều trong những năm tới. Về cơ bản, tôi nghĩ mọi người sẽ trở thành một builder (người xây dựng), vì vậy điều đó sẽ thực sự thú vị.
Vai trò của PM trong tương lai AI
Vậy lời khuyên của bạn ở đây là, với tư cách là một PM, có lẽ đừng vội vàng dùng Cursor, bắt đầu xây dựng, thử nghiệm các tính năng để đưa vào sản xuất, đặc biệt là các tính năng phức tạp. Bạn có nghĩ chúng ta sẽ đạt được điều đó không? Bạn có nghĩ rằng trong vài năm nữa, các PM sẽ làm điều này và nó sẽ bớt đáng sợ và điên rồ hơn không?
Nếu có PM. Vâng, tôi nghĩ các chức danh sẽ hợp nhất và các trách nhiệm sẽ hợp nhất và mọi người sẽ chỉ tập trung vào việc xây dựng. Tôi chắc chắn nghĩ rằng các mô hình, context memory window đang lớn hơn, các mô hình đang trở nên thông minh hơn và tôi chắc chắn thấy cách các PM hoặc bất kỳ background nào khác có thể viết code. Hiện tại, tôi sẽ không chờ đợi điều đó. Tôi sẽ sử dụng điều này như một collaborative learning opportunity để làm việc với đội ngũ phát triển của bạn. Điều đó sẽ khó khăn. Rất nhiều nhà phát triển rất, rất hoài nghi về trạng thái hiện tại, và tôi nghĩ rằng bạn sẽ cần rất nhiều nỗ lực "bán hàng" để thuyết phục, nhưng nếu bạn có thể thuyết phục, và tôi nghĩ các nhóm thực sự tin tưởng vào điều này và muốn dành thời gian để cải thiện quy trình làm việc của họ về việc làm thế nào để nhóm của chúng ta trở nên AI native hơn, tôi nghĩ rằng những nhóm này có thể sẽ đi trước vài năm và họ sẽ nhìn lại vài tuần họ đã dành để thiết lập điều này như là khoảng thời gian giá trị nhất mà họ từng bỏ ra.
AI và Sự mai một kỹ năng: Một quan điểm khác
Hãy để tôi hỏi bạn một câu hỏi khác liên quan đến công việc của một PM. Một trong những nỗi sợ lớn nhất mà mọi người có với những AI tools này dành cho các PM và mọi chức năng khác mà tôi hình dung, đó là bạn bắt đầu phụ thuộc vào những thứ này, kỹ năng của bạn bắt đầu mai một, bạn tạo ra tất cả những thứ "slop" (chất lượng kém) trông rất tuyệt, một tài liệu chiến lược tuyệt vời. Không, thực ra nó hoàn toàn không tốt chút nào. Liệu đây có phải là những Linear tickets hoặc những sản phẩm dở dang không? Quan điểm của bạn về hai phần này là gì, giống như việc này đã ảnh hưởng đến nghề nghiệp của bạn với tư cách là một PM như thế nào? Bạn có cảm thấy điều này đang làm suy yếu kỹ năng của mình vì bạn quá phụ thuộc vào những tools này không và làm thế nào để bạn duy trì chất lượng của những thứ này và không chỉ là "Ờ, đó chỉ là một đống AI generated slop."
Tôi hoàn toàn không đồng ý với điều này và tôi đã nghe nó rất nhiều lần. Tôi nhớ khi tôi bắt đầu sử dụng, Tal Raviv có toàn bộ khóa học về xây dựng một PM Copilot bằng cách sử dụng các dự án, có lẽ là một trong những khóa học tốt nhất mà bạn có thể tham gia. Và khi tôi bắt đầu làm việc với Copilot của riêng mình, tôi nhớ mọi người ở nơi làm việc nhìn và nói, "Ồ, vậy về cơ bản bạn đang thuê ngoài tư duy của mình." Và đối với tôi, đó là cách tệ nhất để nhìn nhận vấn đề. Và tôi nghĩ vì một lý do nào đó, những người này thường có mối tương quan cao với kiểu người không thích trình bày bài thuyết trình khi nó mới hoàn thành 10% hoặc không muốn nhờ giúp đỡ nhiều. Tôi nghĩ rằng có một sự hiểu lầm với rất nhiều PM rằng công việc là luôn có câu trả lời đúng và là người thông minh nhất trong phòng. Và ít nhất theo cách tôi được đào tạo và cách tôi tin vai trò của PM là, nó hoàn toàn ngược lại.
Về cơ bản, đó là việc tận dụng bất cứ điều gì có thể giúp chúng ta nhanh nhất có thể trong việc cung cấp giải pháp phù hợp cho người dùng. Và tôi chỉ nghĩ đây giống như một người thực sự thông minh có context hoặc mentor của bạn hoặc bất cứ ai, nhưng luôn có mặt và không phán xét bạn và thực sự có thể giúp bạn. Vì vậy, nếu bạn chỉ sử dụng nó để tạo ra agent output của mình rồi đưa chúng ra ngoài, vâng, đó là AI slop, nhưng đó cũng là lỗi của con người. Tôi nghĩ điều thực sự quan trọng là bạn phải chịu trách nhiệm về output của mình. Nếu bạn đưa bất cứ điều gì ra ngoài hoặc thể hiện điều gì đó trong một product review và bạn nói, "Ồ, xin lỗi, cái đó được xây dựng bởi AI." Đó là lỗi của bạn. Tôi nghĩ nếu bạn sử dụng những tools này một cách có chủ đích và thực sự dành thời gian để hiểu cách sử dụng AI đúng cách, thì đó là một trong những yếu tố thay đổi cuộc chơi lớn nhất sẽ khiến bạn trở thành một PM tốt hơn rất nhiều.
AI hỗ trợ PM cấp thấp và kiểm soát chất lượng
Và một điều nữa ở đây là, đặc biệt đối với các PM cấp thấp hơn, nó cho phép bạn chơi ở một cấp độ cao hơn nhiều so với bình thường. Tôi nghĩ rằng ở Wix, tôi không nghĩ về chiến lược marketing của công ty là gì và việc onboarding sẽ được cải tổ hoàn toàn trong toàn bộ sản phẩm như thế nào. Nhưng với sản phẩm phụ của mình, tôi có thể đưa ra bất kỳ quyết định nào tôi muốn và suy nghĩ về chiến lược, marketing và messaging. Và điều này về cơ bản chỉ giúp tôi có được reps (kinh nghiệm lặp lại), một trong những điều quan trọng nhất ở giai đoạn đầu của career path của bạn. Vì vậy, tôi hiểu nỗi sợ rằng làm thế nào bạn lại thuê ngoài một số thứ nhất định và bạn không sở hữu 100% mọi thứ, nhưng tôi nghĩ lợi ích mang lại lớn hơn rất nhiều. Và tôi nghĩ cách duy nhất mà AI khiến bạn làm việc tệ hơn là nếu bạn sử dụng nó sai cách.
Có bất cứ điều gì bạn đã học được về việc giảm thiểu sự cẩu thả của agent output, giống như một mẹo để giữ chất lượng cao của những gì nó tạo ra không?
Tương tự như con người, việc setting up AI for success (thiết lập AI để thành công) cho nhiệm vụ đang thực hiện. Vì vậy, nếu tôi chỉ đưa một người mới vào để viết một tài liệu hoặc thứ gì đó mà không đưa ra bất kỳ hướng dẫn nào, tôi chỉ nói, "Hãy đưa ra một tài liệu chiến lược." Anh ta có lẽ sẽ chỉ lên mạng và tìm kiếm tài liệu chiến lược hàng đầu và tái tạo lại nó, đó về cơ bản là những gì AI đang làm. Nó về cơ bản chỉ được cung cấp tất cả thông tin trên internet. Vì vậy, thay vì vậy, việc hướng dẫn nó và cung cấp context về phong cách viết của bạn và những gì bạn đang cố gắng giải quyết và tất cả những điều khác nhau này, tôi nghĩ đó có lẽ là một trong những unlock lớn nhất. Vì vậy, đó chỉ là một mẹo nhanh. Và Cursor cũng có một command có tên là /deslop, về cơ bản là xem lại mã. Tôi không biết liệu điều này đã được tích hợp vào sản phẩm chưa, nhưng nó có trên Twitter. Những người sáng lập của họ đã nói về điều này, vì vậy đó chắc chắn là điều tôi sẽ theo dõi để đảm bảo không có slop nào bị bỏ lại.
Cái deslop đó thật buồn cười. Được rồi. Một câu hỏi nữa, có thể dẫn đến một điều gì đó khác, nhưng đi theo một hướng hoàn toàn khác. Bạn đã sử dụng AI để giúp bạn phỏng vấn cho công việc bạn có được ở Meta. Hãy nói về cách bạn đã làm điều đó, bởi vì rất nhiều người hiện nay đang gặp khó khăn trong việc tìm việc, đọc về tất cả những người sử dụng AI để giúp họ phỏng vấn. Bạn thực sự đã làm điều đó. Bạn đã sử dụng gì? Điều gì hiệu quả?
Sử dụng AI để chuẩn bị phỏng vấn xin việc
Tôi cảm thấy như phép loại suy ở đây là tôi có 12 cháu gái và cháu trai, và bạn có thể thấy cách những người lớn lên trong một thế giới khác, cách tư duy của họ được hình thành khác biệt. Vì vậy, nếu bạn hỏi tôi, làm thế nào để bạn trả lời điện thoại, tôi sẽ làm thế này. Nhưng một đứa trẻ bây giờ, khi bạn nói, "Làm thế nào để bạn trả lời điện thoại?" Chúng sẽ làm thế này. Chúng sẽ làm theo kiểu trả lời iPhone. Và tôi cảm thấy những người đang lớn lên bây giờ trong cuộc sống chuyên nghiệp của họ cũng tương tự như vậy với AI. Vì vậy, mỗi khi tôi đối mặt với một thách thức hoặc vấn đề mới, tôi đều nghĩ AI first (AI đầu tiên) cách giải quyết nó.
Vì vậy, Meta đã liên hệ và nói rằng họ muốn tôi phỏng vấn. Ngay lập tức, tôi mở một dự án trong Claude. Tôi bắt đầu tìm kiếm trực tuyến tất cả thông tin tốt nhất hiện có, những điều mà tôi cảm thấy phù hợp. Tôi đã lấy rất nhiều framework và tài liệu từ Ben Erez, người đã viết một bài đăng khách cho bạn, người mà tôi nghĩ là một trong những bộ óc xuất sắc nhất hiện nay. Và về cơ bản, tôi đã tạo một dự án hoạt động như coach của tôi, nơi tôi sẽ đến và hỏi ý kiến về việc phải làm gì ở mỗi giai đoạn. Tôi sẽ thực hành phỏng vấn thử với nó, và điều này thật tuyệt vời. Ngoài ra, tôi đã tạo một trò chơi trong Base44, giúp tôi... Tôi thực sự gặp khó khăn với segmentation (phân khúc) trong các câu hỏi sản phẩm, vì vậy việc suy nghĩ về các phân khúc chính xác. Vì vậy, về cơ bản, tôi chỉ tạo một trò chơi đố vui, tạo ra các câu hỏi và các segmentation khác nhau và tôi phải chọn.
Vì vậy, đây là cách tôi đã tạo ra nó. Đó là một ứng dụng web mà đôi khi tôi chơi khi đi xe buýt đến chỗ làm. Vì vậy, về cơ bản, tôi nghĩ Ben nói rất nhiều về điều này, vì vậy tôi không chỉ đọc tài liệu của Ben, mà chỉ cần tạo một dự án và cung cấp cho nó tất cả thông tin tốt nhất trên internet và sau đó thực hành rất nhiều. Tôi phải nói rằng yếu tố thay đổi cuộc chơi lớn nhất đối với tôi là thực hiện các buổi phỏng vấn thử với người thật (human mocks). Vì vậy, việc liên hệ với mọi người trên LinkedIn và nhờ họ thực hiện các buổi phỏng vấn thử thực tế cho tôi, tôi nghĩ rằng cuối cùng, đặc biệt là đối với việc chuẩn bị Meta PM, vốn siêu cạnh tranh và khó khăn, tôi nghĩ không có cách nào để tránh được điều đó.
Thật tuyệt vời khi họ sử dụng bài viết đó. Tôi không biết. Chúng tôi sẽ liên kết đến nó. Và trong bài viết đó, Ben chia sẻ tất cả những prompts mà bạn có thể cung cấp cho ChatGPT để giúp bạn chuẩn bị cho các cuộc phỏng vấn, thực hiện các buổi phỏng vấn thử trực tuyến. Điều quan trọng là phải nói rằng những điều đó sẽ đưa bạn đến một điểm nhất định, nhưng thực tế là sử dụng con người tốt hơn. Tôi thực sự có một bài viết sắp ra mắt hợp tác với Noam Segal về cách mọi người đang sử dụng AI để phỏng vấn. Và một trong những cách thú vị nhất mà tôi từng nghe mọi người nói và chúng tôi đã tìm thấy trong nghiên cứu này là mọi người sử dụng nó để nhận feedback. Họ ghi lại cuộc phỏng vấn và sau đó AI cung cấp feedback cho họ. Đây là nơi bạn có thể làm tốt hơn. Đây là điều bạn đã bỏ lỡ bởi vì feedback loop (vòng lặp phản hồi) đang thiếu sót rất nhiều.
Chuẩn Bị Phỏng Vấn Với AI
Không ai từng nói với bạn, "Đây là những gì bạn đã làm dở trong buổi phỏng vấn này." Không ai nói với bạn điều đó, và AI có thể làm được điều đó.
Tôi sẽ bổ sung hai điều vào đó. Thứ nhất, chính là điều này: Tôi sẽ thực hành phỏng vấn thử với AI. Ngoài ra, tôi đã làm một điều thực sự thú vị là có một ngân hàng câu hỏi trực tuyến, miễn phí, của Louis Lynn, về cơ bản là một ngân hàng câu hỏi luôn được cập nhật mà mọi người được hỏi trong các cuộc phỏng vấn thực tế. Và tôi về cơ bản đã sử dụng Comet, là trình duyệt của Perplexity. Tôi đã nhờ agent thực hiện mọi phân tích về những câu hỏi được hỏi nhiều nhất. Và đó là cách tôi biết cách ưu tiên những câu hỏi nào tôi sẽ thực hành.
Và sau đó, khi kết thúc các buổi thực hành thử này, tôi nói với Claude trong dự án rằng: "Bạn là huấn luyện viên của tôi, và tôi không muốn bạn khiến tôi cảm thấy dễ chịu. Tôi muốn bạn giúp tôi sẵn sàng nhất có thể cho các buổi phỏng vấn này. Vì vậy, hãy cho tôi phản hồi, như bạn đã nói."
Và một điều thú vị khác mà tôi đã làm là với một số câu hỏi tôi không có thời gian để thực hành thử, tôi sẽ yêu cầu Claude đóng vai ứng viên, và sau đó nó sẽ đưa ra một câu trả lời thực sự tốt. Và tôi cũng có thể học hỏi từ đó, giống như học hỏi từ một người đưa ra câu trả lời hoàn hảo.
Tư Duy Thế Hệ Mới: AI Là Mặc Định
Ồ, này. Tôi thực sự thích cách bạn diễn đạt, rằng những người thuộc thế hệ của bạn, mặc định là, "Tôi có việc cần làm. Hãy đến với AI ngay lập tức để giúp tôi chuẩn bị cho việc này, giúp tôi tìm ra giải pháp."
Vâng. Và điều này quay trở lại với câu nói mà tôi luôn suy nghĩ, mà tôi nghĩ mọi người vẫn luôn nghe thấy, nhưng đó là một câu nói rất quan trọng rằng không phải bạn sẽ bị thay thế bởi AI, ít nhất là trong một thời gian dài. Mà là bạn sẽ bị thay thế bởi một người giỏi hơn bạn trong việc sử dụng AI.
Tôi đồng ý. Và đây là lý do của những cuộc trò chuyện này, để giúp mọi người theo kịp tất cả những điều đó và học hỏi một số kỹ năng này. Và một lần nữa, hãy xem tương lai đang đi về đâu và bắt đầu học cách tự mình đến đó.
Góc Thất Bại: Bài Học Từ Wix
Được rồi, Zevi, trước khi chúng ta đến với vòng hỏi nhanh đáp gọn đầy thú vị của mình, tôi sẽ đưa chúng ta đến một chuyên mục định kỳ trên podcast này mà tôi gọi là Failure Corner (Góc Thất Bại). Và lý do tôi yêu thích chuyên mục này là mọi người khi tham gia, ngay cả trong cuộc trò chuyện này, đều nói về tất cả những điều tuyệt vời mà họ đã khám phá, mọi thứ đều diễn ra rất tốt. Mọi người hiếm khi nghe về những điều không suôn sẻ, và đó thường là những câu chuyện thú vị và có tác động lớn nhất. Vì vậy, câu hỏi đơn giản là, đâu là câu chuyện về một lần bạn thất bại trong lộ trình sự nghiệp của mình và bạn đã học được gì từ trải nghiệm đó?
Vâng, tôi thích điều này. Tôi thích điều này. Tôi là một fan lớn của Failure Corner. Vậy tôi sẽ kể một câu chuyện về thời điểm tôi bắt đầu làm việc tại Wix. Về cơ bản, tôi bắt đầu làm việc tại Wix với tư cách là một thành viên của chương trình sinh viên, và ngay sau khi kết thúc chương trình, bạn sẽ được đưa vào một đội nhất định. Vì vậy, tôi đã làm việc trong bộ phận biên tập, vốn là sản phẩm cốt lõi của Wix. Và các PM (Quản lý sản phẩm) khác chỉ là những PM giỏi nhất tại Wix. Có bốn người khác có kinh nghiệm hơn tôi rất nhiều và họ thực sự giỏi. Và tôi nhớ mình đã đến đó và nghĩ rằng, "Buổi đánh giá sản phẩm đầu tiên của mình, mình sẽ khiến mọi người kinh ngạc. Họ sẽ không tin được mình là một PM giỏi đến mức nào." Và về cơ bản, tôi đã không thực sự chia sẻ những gì mình đang nghĩ. Tôi đã làm việc hàng tấn giờ một mình và tôi nghĩ, "Mình sẽ làm tốt buổi đánh giá sản phẩm này. Họ sẽ rất ấn tượng." Và cuối cùng tôi đã thất bại thảm hại. Buổi đánh giá sản phẩm của tôi không tốt. Nó không đúng định dạng mà họ mong đợi. Họ có rất nhiều câu hỏi mà tôi đã bỏ lỡ, và tôi cảm thấy kinh khủng khi nó kết thúc. Tôi nghĩ, "À, mình đúng là một kẻ ngốc." Và tôi thấy mọi người đều nói, "Được rồi, tốt thôi. Vâng, cứ quay lại sau hai tuần và chúng ta sẽ tiếp tục làm việc này." Và tôi hiểu ngay lúc đó rằng họ không hề mong đợi tôi sẽ là một PM 10X, nhưng điều họ mong đợi ở tôi là một người học hỏi 10X.
Và ngay khi tôi hiểu điều đó, toàn bộ tư duy của tôi đã thay đổi. Và tôi nghĩ đây có lẽ là lời khuyên tốt nhất mà tôi dành cho các PM cấp dưới hiện nay là, về cơ bản, hãy là người học hỏi tốt nhất mà bạn có thể trở thành ở giai đoạn đầu. Không ai mong đợi bạn biết tất cả các câu trả lời và không ai mong đợi bạn đã giỏi. Vì vậy, về cơ bản, những gì tôi đã làm là tôi tiếp cận từng người trong nhóm PM – có bốn PM khác – và tôi đánh giá điểm mạnh của họ và sử dụng họ làm người cố vấn cho lĩnh vực đó.
Vậy là Neri, người vẫn là cố vấn của tôi cho đến ngày nay, anh ấy có product sense (cảm nhận sản phẩm) tốt nhất trong số những người tôi từng gặp. Oya thì siêu việt, cô ấy giống như một chuyên gia về phương pháp luận. Cô ấy chỉ suy nghĩ theo các framework (khuôn khổ). Yahra, người đứng đầu sản phẩm, về cơ bản có thể nhìn vào một sản phẩm và ngay lập tức hiểu được các hiệu ứng cấp độ ba và bốn của chúng, tức là system thinking (tư duy hệ thống). Vì vậy, mỗi khi tôi có vấn đề với một trong những lĩnh vực này, tôi sẽ đến gặp một trong số họ và hỏi ý kiến, và điều này mang lại hai lợi ích. Thứ nhất, tôi học được rất nhiều. Và thứ hai là khi đến lần tiếp theo, buổi đánh giá sản phẩm tiếp theo, thành công của tôi đối với họ giống như thành công của chính họ, bởi vì tôi không phải là một đứa trẻ đang cố gắng thể hiện mình ngầu như thế nào. Mà giống như là học trò của họ khiến tất cả chúng tôi tự hào. Và đó là một sự thay đổi lớn đối với tôi. Và về cơ bản, cuối cùng, tôi đã thực sự xuất sắc nhờ điều này.
AI: Đối Tác Học Hỏi Và Cơ Hội Cho Người Mới
Đó là một câu chuyện tuyệt vời. Và ý tưởng về việc học hỏi là một sợi dây xuyên suốt cuộc trò chuyện này, rằng AI giỏi trong việc hoàn thành công việc, nhưng nó cũng thực sự giỏi trong việc giúp bạn học cách làm điều đó và trở thành đối tác, đối tác tư duy này, cái cách bạn nói về quá trình phỏng vấn bạn đã trải qua và cơ hội/lệnh học hỏi này. Thật tuyệt vời. Câu chuyện tuyệt vời.
Zevi, được rồi. Trước khi chúng ta đến với vòng hỏi nhanh đáp gọn đầy thú vị, bạn có muốn chia sẻ điều gì khác không? Có điều gì bạn muốn gửi gắm đến người nghe không?
Vâng. Vậy thì, để quay lại điều đầu tiên tôi nói, nếu mọi người rời đi với suy nghĩ, "Zevi thật tuyệt," thì tôi đã thất bại ở đây. Tôi nghĩ rằng, tôi nghĩ, đây là thời điểm tốt nhất để sống. Đây là thời điểm tốt nhất để trở thành một người mới vào nghề, trái ngược với những gì nhiều người đang nói rằng không còn các vị trí cấp dưới nữa và mọi người ra trường không thể tìm được việc làm. Vâng, điều đó đúng. Nhưng cũng vậy, trong lịch sử, còn khi nào khác bạn có thể ra trường và tự mình xây dựng một công ty khởi nghiệp với vài người bạn mà hoàn toàn bootstrapped (tự thân vận động) chứ? Và tôi thấy ngày càng nhiều người vào cuối thời gian làm việc tại Wix, tôi đã phỏng vấn, và tôi thấy ngày càng nhiều người tự mình xây dựng sản phẩm với AI. Và tôi nghĩ trái ngược với những gì nhiều người nghĩ, đây là thời điểm tốt nhất để trở thành một người mới vào nghề. Đây là thời điểm tốt nhất để trở thành một người học hỏi. Và tôi nghĩ nếu bất kỳ thính giả nào đang nghe điều này và bạn là một người tò mò, bạn là một người chăm chỉ, tôi muốn nói là tử tế – tôi không chắc – nhưng nếu bạn là một người tử tế và một người giao tiếp tốt, bạn có một lợi thế không công bằng và bạn có thể mang lại nhiều giá trị cho các công ty hơn hầu hết những người có 20 năm kinh nghiệm. Vì vậy, tôi thực sự hy vọng mọi người sẽ được truyền cảm hứng từ điều này và bắt đầu thành công rực rỡ với các dự án của mình.
Thật tuyệt vời. Có rất nhiều cách để được truyền cảm hứng từ cuộc trò chuyện này.
Vòng Hỏi Nhanh Đáp Gọn
Zevi, với điều đó, chúng ta đã đến vòng hỏi nhanh đáp gọn đầy thú vị của mình. Tôi có năm câu hỏi dành cho bạn. Bạn đã sẵn sàng chưa?
Vâng, chúng ta bắt đầu thôi.
Sách Yêu Thích
Hai hoặc ba cuốn sách nào mà bạn thấy mình thường xuyên giới thiệu cho người khác nhất?
Vậy tôi sẽ chọn một cuốn từ mỗi thể loại. Trong tiểu thuyết, tôi yêu thích The Fountainhead của Ayn Rand, một trong những cuốn sách yêu thích của tôi. Nó thực sự khiến bạn suy nghĩ, thực sự khiến bạn cảm nhận. Về sách kinh doanh, tôi là một fan lớn của Shoe Dog, câu chuyện về Nike, một trong những cuốn sách yêu thích của tôi. (Người phỏng vấn: Tôi vừa đọc xong cuốn đó. Thật thú vị. Thật tuyệt vời. Nó rất hay.) Vâng. Tôi yêu Shoe Dog. Và sau đó, về khía cạnh tâm lý học, Mindset của Carol Dweck, người đã đặt ra thuật ngữ growth mindset (tư duy phát triển). Đó thực sự là một cuốn sách tuyệt vời. Nó nghe có vẻ như một cuốn sách tự lực, nhưng sau đó bạn hiểu rằng nó hoàn toàn mang tính tâm lý và dựa trên nghiên cứu, và cuốn sách đó đã thay đổi hoàn toàn cuộc đời tôi. Thực sự, tôi luôn có một fixed mindset (tư duy cố định), và sau khi đọc cuốn đó, tôi đã hiểu rằng đó là điều đang kìm hãm tôi. Và từ đó, tôi đã thực sự, thực sự cố gắng vun đắp một growth mindset. Vì vậy, tôi thực sự khuyên mọi người nên đọc cuốn đó.
Một lần nữa, điều này kết nối với mạch tư duy bạn đã mô tả, là một người học hỏi 10X thay vì một người làm việc 10X.
Phim / Chương Trình TV Gần Đây
Được rồi. Câu hỏi tiếp theo. Bộ phim hoặc chương trình TV gần đây nào bạn yêu thích và thực sự đã thưởng thức?
Vâng, thực ra vợ tôi rất thích phim, nên chúng tôi xem TV rất nhiều. Đó có lẽ là khoảng thời gian yêu thích của chúng tôi khi ở bên nhau. Tôi vừa xem xong The Pitt, rất tuyệt vời. Nó thực sự hay. Và lời khuyên đầu tiên của tôi cho mọi người là nếu bạn chưa xem Severance, hãy chạy đi xem Severance, một trong những chương trình yêu thích của tôi.
Sản Phẩm Yêu Thích
Có sản phẩm yêu thích nào mà bạn mới khám phá gần đây mà bạn thực sự yêu thích không?
Đây là một câu hỏi hay. Tôi luôn thử các sản phẩm mới. Tôi sẽ luôn cài đặt ba hoặc bốn trình duyệt trên máy tính của mình và đủ thứ khác, và gần đây tôi đã khám phá ra một giải pháp thay thế cho Loom. Tôi hơi thất vọng với Loom. Họ tính quá nhiều tiền và sản phẩm thì, tôi không biết, tôi chỉ không thích nó. Và có một giải pháp thay thế mã nguồn mở tên là Cap, nó thực sự được chế tác rất tốt. Bạn có thể thấy rằng người tạo ra nó thực sự tỉ mỉ đến từng chi tiết, và đó thực sự là một lựa chọn thay thế rất tuyệt vời. Vì vậy, tôi đã sử dụng nó gần đây.
Cũng có một sản phẩm tên là Supercut mà tôi yêu thích, đó cũng là một giải pháp thay thế cho Loom. Xin được giới thiệu.
Châm Ngôn Sống
Được rồi. 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. Hiện tại tôi đang có hai cái. Một cái, về cơ bản đã trở thành một meme trên Twitter, đó là "bạn có thể làm mọi thứ." Tôi cảm thấy điều đó về cơ bản luôn văng vẳng trong đầu tôi mỗi khi tôi làm điều gì đó mà tôi ngạc nhiên về tốc độ và khả năng thực hiện mọi thứ hiện nay. Vì vậy, "bạn có thể làm mọi thứ." Và cái thứ hai tôi đã "đánh cắp" từ anh trai tôi. Châm ngôn của anh ấy là "không ai biết cái quái gì mình đang làm cả." Và tôi chỉ đơn giản là yêu thích điều đó. Và tôi nghĩ nó phần nào khiến bạn nhìn cuộc sống nhẹ nhàng hơn. Vì vậy, vâng, "không ai biết mình đang làm cái quái gì cả."
Tôi nghĩ mọi người nhìn các công ty này từ bên ngoài và cảm thấy như họ đã giải quyết được mọi thứ. Và nếu bạn từng ở bên trong một công ty đang hoạt động rất tốt, bạn sẽ nghĩ, "làm thế nào mà điều này vẫn còn đi đúng hướng? Làm thế nào mà điều này vẫn đang hoạt động? Chẳng có lý do gì cả. Mọi thứ sắp đổ vỡ rồi."
Vâng. Được rồi. Câu hỏi cuối cùng. Bạn đã có một con đường khởi nghiệp dài xuyên suốt lộ trình sự nghiệp của mình. Có một vài doanh nghiệp thực tế khác mà bạn đã khởi nghiệp trong quá khứ.
Hành trình khởi nghiệp sớm: Bài học từ kinh doanh quần áo giữ nhiệt
Bạn đã từng kinh doanh quần áo giữ nhiệt, sau đó là dịch vụ giao hummus. Vậy hãy chọn một trong số đó và kể câu chuyện về nó.
Vâng, tôi rất sẵn lòng. Thật thú vị khi bạn hỏi về điều này. Tôi sẽ kể về câu chuyện kinh doanh quần áo giữ nhiệt, vì tôi nghĩ nó khá hay. Khi còn học trung học, tôi bán quần áo giữ nhiệt vào năm lớp 10 cho một người bạn của chị gái tôi, và về cơ bản, đó chỉ là những gói quần áo giữ nhiệt, gồm áo và quần. Tôi lớn lên ở Jerusalem, nơi đó khá lạnh. Vì vậy, sản phẩm này rất phù hợp với thời tiết. Vào năm lớp 10, khi tôi bán chúng, giá khoảng 20-25 đô la một bộ và tôi kiếm được khoảng 4 đô la cho mỗi lần bán. Nếu nhìn vào chuỗi cung ứng, tôi là người ở vị trí thứ sáu hoặc thứ bảy. Biên độ lợi nhuận này thật điên rồ. Vì vậy, trong mùa hè, tôi nghĩ rằng mình nên đến thẳng nhà nhập khẩu. Suốt mùa hè, tôi gọi cho nhà nhập khẩu và ban đầu, ông ấy thực sự rất tức giận. Ông nói, "Không, cậu phải làm việc cho tôi nhiều năm mới đạt được cấp độ này." Và tôi nói, "Nghe này, chú, cháu sắp tốt nghiệp rồi. Đây sẽ không phải là lộ trình sự nghiệp của cháu. Chú làm hay không tùy chú." Và về cơ bản, chúng tôi đã đàm phán suốt cả mùa hè. Đây cũng là cách tôi làm mọi việc trước khi có ChatGPT. Ông ấy sẽ đưa ra một lý do nào đó, ví dụ, ông nói, "Ôi, thuế nhập khẩu đã tăng." Và tôi chỉ cần tìm kiếm trên Google, như "Thuế nhập khẩu Israel" và bắt đầu đọc. Tôi sẽ nói chuyện điện thoại với ông ấy và kiểu như, "Này, tôi sẽ cố gắng câu giờ." Và sau đó tôi sẽ đưa ra một thách thức nào đó. Cuối cùng, tôi đã có được một mức giá thực sự tốt, khoảng 12,50 đô la một bộ. Vì vậy, tôi đã kiếm được 100% lợi nhuận và mở rộng ra một loạt các trường học khác nhau. Ở mỗi trường, tôi có những người "cool" nhất trường bán hàng cho mình. Và sau đó, một điều thực sự thú vị mà tôi đã làm là chúng tôi có một đội bóng rổ rất tuyệt vời và đội bóng rổ của chúng tôi thường dẫn trước 30 điểm trong hiệp một, điều này khiến khán giả khá nhàm chán. Vì vậy, tôi đã viết một bài hát, một điệu hô cổ vũ bóng rổ về Quần Áo Giữ Nhiệt, trong đó có số điện thoại của tôi. Và đoạn cuối là "Nếu bạn tham gia ngay bây giờ, chúng tôi sẽ giảm giá cho bạn." Và nó có cả trống và mọi thứ. Ngay cả bây giờ khi tôi đến Jerusalem, tôi biết một số người thậm chí còn không biết số điện thoại của mình theo số, nhưng họ biết nó theo giai điệu. Và đôi khi khi tôi đi bộ ở Jerusalem, mọi người dừng tôi lại và nói, "Này, đó là Thermal Zevi." Đó thực sự là một trải nghiệm rất tuyệt vời khi còn nhỏ.
Lời kết và Kêu gọi hành động
Điều này giải thích rất nhiều về sự thiên tài trong marketing của bước đi đó. Tuyệt vời. Zevi, điều này thật đáng kinh ngạc. Hai câu hỏi cuối cùng: Mọi người có thể tìm bạn ở đâu nếu họ muốn liên hệ và theo dõi một số nội dung này? Chúng tôi sẽ đính kèm liên kết đến các script và câu lệnh/lời nhắc (prompt) trong phần ghi chú của chương trình để bạn không cần phải đọc chúng. Và sau đó, thính giả có thể giúp ích gì cho bạn?
Tuyệt vời. Tôi đã nhận được rất nhiều sự giúp đỡ trong suốt lộ trình sự nghiệp của mình, vì vậy tôi rất thích giúp đỡ bất cứ ai tôi có thể. Vậy hãy liên hệ với tôi qua LinkedIn hoặc X. Tôi thực sự rất muốn giúp đỡ bất cứ ai tôi có thể. Thính giả có thể giúp ích gì cho tôi? Nếu bạn là sinh viên, hãy thử StudyMate, cho tôi biết suy nghĩ của bạn. Nếu bạn ở Israel và chưa sử dụng tính năng đọc chính tả, hãy thử Dibur2text. Cho tôi biết suy nghĩ của bạn.
Tuyệt vời. Tôi rất thích cách bạn chia sẻ rất nhiều và điều đó sẽ hữu ích cho rất nhiều người. Vì vậy, một lần nữa, chúng tôi sẽ liên kết đến những nội dung đó trong phần ghi chú của chương trình. Zevi, bạn thật tuyệt vời. Cảm ơn bạn rất nhiều vì đã có mặt ở đây. Cảm ơn bạn rất nhiều vì đã chia sẻ. Tôi nghĩ điều này sẽ giúp rất nhiều người và tôi nghĩ nó sẽ giúp mọi người vượt qua rào cản tâm lý rằng, "Được rồi, tôi thấy tất cả những người này đang làm những điều thú vị. Đây là cách tôi thực sự có thể làm được những điều này." Vì vậy, cảm ơn bạn rất nhiều vì đã có mặt ở đây và vì đã chia sẻ rất nhiều.
Cảm ơn bạn đã mời tôi. Và nếu bạn xây dựng được điều gì đó thú vị với những gì tôi đã chia sẻ ở đây, hãy liên hệ với tôi, gửi cho tôi. Tôi rất muốn xem. Tuyệt vời. Zevi, cảm ơn bạn rất nhiều vì đã có mặt ở đây. Cảm ơn. Tạm biệt mọi người. Cảm ơn quý vị đã lắng nghe. Nếu bạn thấy nội dung này hữu ích, bạn có thể đăng ký theo dõi chương trình trên Apple Podcast, 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 nhận xét vì điều đó thực sự giúp những người nghe 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 lennyspodcast.com. Hẹn gặp lại trong tập tiếp theo.
TL;DR
- AI, đặc biệt là các công cụ như Claude Code và Cursor, đang trao quyền "siêu năng lực" cho những người không có nền tảng kỹ thuật, giúp họ dễ dàng xây dựng sản phẩm và định hình lại vai trò truyền thống trong phát triển sản phẩm.
- Để sử dụng AI hiệu quả, cần một quy trình làm việc thông minh, bao gồm việc tạo ra một "CTO AI" để cung cấp định hướng kỹ thuật và một lộ trình học tập "liệu pháp tiếp xúc" dần dần với code cho người không chuyên.
- Điều quan trọng là phải thách thức các đầu ra của AI và sử dụng nhiều công cụ để kiểm tra chéo (ví dụ: xem xét mã bằng nhiều LLM), tránh xu hướng "thích làm hài lòng" của AI có thể dẫn đến thông tin sai lệch.
Điểm chính
- Bắt đầu với "Projects" (GPT/Claude): Sử dụng các dự án GPT hoặc Claude để tạo môi trường chatbot có cấu trúc, chia sẻ cuộc trò chuyện, hướng dẫn tùy chỉnh và cơ sở kiến thức, giúp phân loại và giữ mọi thứ trong ngữ cảnh phù hợp.
- Tạo một "CTO AI": Thiết lập một AI đóng vai trò "chủ sở hữu kỹ thuật" hoàn toàn cho dự án của bạn thông qua một câu lệnh tùy chỉnh (custom prompt). Chỉ dẫn AI thách thức bạn, sở hữu phần "cách thức xây dựng" và không trở thành "người thích làm hài lòng".
- Áp dụng "Liệu pháp tiếp xúc" dần dần: Đối với người không có kỹ thuật, hãy bắt đầu chậm rãi với giao diện chatbot đơn giản (dự án GPT), sau đó chuyển sang các công cụ xây dựng như Bolt hoặc Lovable, và cuối cùng là Cursor ở chế độ sáng, làm quen dần với code.
- Tận dụng Cursor với Claude Code: Sử dụng Cursor được hỗ trợ bởi Claude Code làm công cụ cốt lõi để phát triển, tích hợp khả năng AI trực tiếp vào môi trường lập trình của bạn.
- Sử dụng
/commandscho các lệnh tái sử dụng: Lưu trữ các câu lệnh/lời nhắc có thể tái sử dụng dưới dạng/commandstrong codebase (ví dụ:/reviewđể xem xét code,/create-issueđể tạo vấn đề) để chuẩn hóa và tăng tốc các tác vụ thông thường. - Xem xét chéo code do AI tạo: Sử dụng nhiều LLM hoặc công cụ khác nhau (ví dụ: Claude và Codex) để xem xét code do AI viết, giúp phát hiện lỗi và có được nhiều góc nhìn, tránh phụ thuộc vào một nguồn duy nhất.
- Ưu tiên lập kế hoạch kỹ lưỡng: Đặc biệt đối với các tính năng phức tạp như thanh toán hoặc thay đổi cơ sở dữ liệu, hãy dành thời gian lập kế hoạch chi tiết trước khi để tác nhân lập trình (coding agent) bắt đầu viết code ngay lập tức.
- Liên tục nâng cấp công cụ: Chuyển từ các công cụ AI đơn giản hơn (như Bolt, Lovable) lên các công cụ mạnh mẽ hơn (như Cursor) khi kỹ năng và độ phức tạp của dự án tăng lên, luôn chọn công cụ phù hợp nhất với nhu cầu hiện tại.
Từ vựng
product manager— quản lý sản phẩmnền tảng kỹ thuật— technical backgroundworkflow— quy trình làm việccâu lệnh/lời nhắc— promptLLM— Large Language Model (mô hình ngôn ngữ lớn)CTO— Chief Technology Officer (Giám đốc công nghệ)exposure therapy— liệu pháp tiếp xúccoding agent— tác nhân lập trìnhreview code— xem xét mã (code)codebase— cơ sở mã
Nội dung chi tiết
Hành trình từ Product Manager không chuyên kỹ thuật trở thành người xây dựng sản phẩm bằng AI
Bạn là một product manager triển khai sản phẩm mà không biết viết code, thậm chí gần như không biết review code. Tôi không có nền tảng kỹ thuật nào cả, tôi đã học nhạc ở trường cấp ba... khi Sonnet 3.5 ra mắt, tôi nhớ mình đã xem một video YouTube hướng dẫn xây dựng ứng dụng bằng Bolt hoặc Lovable. Cảm giác lúc đó giống như có ai đó đến nói với tôi rằng: "Giờ đây bạn có siêu năng lực rồi đấy."
Ngày nay, bạn đang dùng Cursor với Claude Code. Nếu bạn không có kỹ thuật như tôi, code là thứ đáng sợ, nhưng AI khiến mọi thứ trở nên khả thi hơn rất nhiều. Trong vài năm tới, tôi nghĩ tất cả mọi người sẽ trở thành người xây dựng. Các chức danh sẽ sụp đổ và trách nhiệm cũng sẽ thay đổi.
Thử thách chính mà mọi người gặp phải là review code do AI viết. Đối với tôi, việc phát hiện lỗi rất khó khăn. Điều tôi thường làm là dùng lệnh /review. Lệnh này yêu cầu Claude bắt đầu review chính code của nó. Tuyệt vời hơn nữa là tôi mở cả Codex và Cursor. Tôi sẽ để mỗi công cụ review code. Điều này gợi nhớ đến câu nói mà tôi nghĩ ai cũng từng nghe: Bạn sẽ không bị thay thế bởi AI, mà sẽ bị thay thế bởi người biết sử dụng AI tốt hơn bạn.
Đây là thời điểm tốt nhất để làm junior, trái ngược với điều nhiều người đang nói về việc không còn vị trí junior nữa. Đúng là như vậy, nhưng trong lịch sử, còn khi nào bạn có thể ra trường và tự mình xây dựng một startup?
Giới thiệu về Zevi Arnovitz và Mục tiêu của Podcast
Khách mời của tôi hôm nay là Zevi Arnovitz. Zevi là một PM tại Meta. Trước đó, anh ấy là PM tại Wix. Đây là một cuộc trò chuyện thực sự đáng chú ý mà mọi người làm sản phẩm không có kỹ thuật đều cần nghe. Zevi còn rất trẻ và không có nền tảng kỹ thuật, nhưng với sự thông minh, trẻ tuổi và đầy tham vọng, anh ấy đã học cách sử dụng Cursor và Claude Code để tự mình xây dựng những sản phẩm có ý nghĩa và thực tế, đồng thời tạo ra một workflow rất thông minh và hiệu quả mà mọi người nghe đều có thể học hỏi.
Để việc học hỏi này dễ dàng hơn nữa, ở đầu phần ghi chú của tập này, bạn có thể tải xuống tất cả các câu lệnh/lời nhắc và lệnh / để tự mình thực hiện tất cả những điều này. Zevi sẽ chỉ cho bạn cách làm việc với Cursor để nhanh chóng thêm ý tưởng của mình vào Linear để khám phá ý tưởng đó với AI, cách phát triển kế hoạch, cách xây dựng sản phẩm, sau đó để các LLM khác nhau review code và cập nhật tài liệu, rồi sử dụng tất cả những điều này như một cơ hội học hỏi để phát triển nhận thức của riêng bạn về cách mọi thứ hoạt động.
Tôi đã không ngừng suy nghĩ về cuộc trò chuyện này kể từ khi chúng tôi có nó, và mọi người cần chú ý đến những gì AI đang mở khóa cho những người không có kỹ thuật.
Xin gửi lời cảm ơn sâu sắc đến Tal Raviv vì đã khuyến khích tôi gặp Zevi. Nếu bạn yêu thích podcast này, đừng quên đăng ký và theo dõi nó trên ứng dụng podcast yêu thích hoặc YouTube. Điều đó giúp ích rất nhiều. Và nếu bạn trở thành người đăng ký hàng năm cho bản tin của tôi, bạn sẽ nhận được 19 sản phẩm cao cấp miễn phí trong cả năm, bao gồm Lovable, Replit, Bolt, Gamma, n8n, Linear, Devin, PostHog, Superhuman, Descript, Wispr Flow, Perplexity, Warp, Granola, Magic Patterns, Raycast, ChatPRD, Mobbin và Stripe Atlas. Hãy truy cập lennysnewsletter.com và nhấp vào product pass. Sau đây, tôi xin giới thiệu Zevi Arnovitz sau một vài lời từ các nhà tài trợ của chúng ta.
Lời của nhà tài trợ
Tập này được tài trợ bởi 10Web, công ty tiên phong trong việc xây dựng trang web bằng AI trước cả ChatGPT. Trong ba năm qua, hơn hai triệu trang web đã được tạo ra bằng nền tảng vibe coding của 10Web. Nền tảng vibe coding của 10Web là một cách mạnh mẽ để xây dựng trang web. Hãy hình dung nó như Lovable dành cho WordPress, cả frontend và backend. Người dùng có thể xây dựng bất kỳ trang web nào với mọi độ phức tạp, từ e-commerce, portfolio, trang web thông tin, đến blog, và nó đi kèm với bảng quản trị WordPress cùng hàng ngàn plugin sẵn sàng sử dụng. 10Web cũng cung cấp khả năng tạo trang web dưới dạng API as a service cho các công ty SaaS, marketplace, nhà cung cấp hosting, MSP và các agency. Các công ty SaaS có thể nhúng nó thông qua API để người dùng có thể khởi chạy các trang web do AI tạo trực tiếp bên trong nền tảng của họ, được kết nối với dữ liệu riêng của họ. Các agency và MSP có thể có bảng điều khiển white label để quản lý khách hàng và bán lại dưới thương hiệu của họ. Các nhà cung cấp hosting có thể tự host API builder trên cơ sở hạ tầng của riêng họ. Hãy truy cập 10web.io/lenny và sử dụng mã Lenny để nhận các khoản tín dụng miễn phí độc quyền và giảm giá 30% cho API hoặc các giải pháp white label. Đó là 10web.io/lenny, nền tảng vibe coding dưới dạng API.
Tập hôm nay được tài trợ bởi DX, nền tảng developer intelligence đượ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 AI, các tổ chức cần thích nghi nhanh chóng, nhưng nhiều 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 hiệu quả? 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 AI đang cung cấp giá trị cho các developer của họ và tác động của AI đến engineering productivity là gì. Để tìm hiểu thêm, hãy truy cập trang web của DX tại getdx.com/lenny, tức là getdx.com/lenny.
Câu chuyện cá nhân về Zevi Arnovitz
Zevi, cảm ơn bạn rất nhiều vì đã có mặt ở đây và chào mừng bạn đến với podcast.
Cảm ơn vì đã mời tôi, Lenny. Tôi là một fan cuồng của chương trình này và rất nhiều người mà tôi ngưỡng mộ nhất và học hỏi được nhiều nhất đều đã xuất hiện ở đây, nên đây là một khoảnh khắc điên rồ đối với tôi. Tôi thực sự rất hào hứng với điều này.
Tôi thực sự đánh giá cao điều đó. Tôi muốn bắt đầu bằng cách đọc một ghi chú tôi nhận được về bạn từ Tal Raviv, người từng là khách mời podcast, và nhiều lần là cộng tác viên bản tin. Anh ấy là một trong những product manager tiên phong về AI nhất mà tôi biết và tôi đã học hỏi được rất nhiều từ anh ấy. Đây là những gì anh ấy nói về bạn khi giới thiệu chúng tôi: "Zevi là PM vibe coding thực tế nhất mà tôi biết, và cá nhân tôi đã học được rất nhiều từ anh ấy. Các kỹ sư của anh ấy tại Meta đã nhờ anh ấy dạy cách làm những gì anh ấy đang làm. Mỗi khi chúng tôi uống cà phê, tôi luôn có cảm giác rằng mọi người cần được nghe điều này."
Thật tuyệt vời. Và đó chính là mục tiêu. Mục tiêu của cuộc trò chuyện này là giúp nhiều người hơn nghe được những gì bạn đã khám phá ra. Chúng ta sẽ đi sâu vào thực tế. Chúng ta sẽ trình bày nhiều hơn là chỉ nói, chỉ cho mọi người thấy những gì bạn đã tìm ra về cách trở thành một PM, một PM không có kỹ thuật nhưng vẫn xây dựng được mọi thứ. Tôi muốn cung cấp cho mọi người một chút thông tin về nền tảng kỹ thuật của bạn vì tôi nghĩ điều này sẽ truyền cảm hứng cho nhiều thính giả cảm thấy rằng họ cũng có thể làm được những gì chúng ta sắp trình bày. Điều này sẽ trông rất nâng cao, nhưng hãy cho mọi người một chút cảm nhận về nền tảng kỹ thuật của bạn.
Tôi rất ít am hiểu kỹ thuật. Tôi không có nền tảng kỹ thuật nào cả. Tôi học nhạc ở trường cấp ba. Nhiều người Israel tham gia các đơn vị công nghệ trong quân đội, nhưng tôi thì không. Và cơ bản là một năm trước, tôi đã đi du lịch với vợ ba tháng ở châu Á và chúng tôi ở Nhật Bản, và đó là khoảng thời gian Sonnet 3.5 ra mắt. Tôi nhớ mình đã xem một video YouTube. Tôi nghĩ đó là Greg Isenberg hoặc Riley Brown và họ cơ bản là đang xây dựng ứng dụng bằng Bolt hoặc Lovable, chỉ bằng cách sử dụng AI. Đó là một khoảnh khắc điên rồ đối với tôi vì khi xem, tôi cảm thấy như có ai đó đến và nói: "Này Zevi, có công nghệ mới tuyệt vời này bạn nên xem thử. Bạn thực sự nên thử nó. À, và nhân tiện, bây giờ bạn có siêu năng lực rồi đấy." Và ngay giây phút tôi về đến nhà từ Nhật Bản, tôi thậm chí còn chưa tháo hành lý, đã chạy ngay đến máy tính, mở Bolt, tạo một tài khoản, và trong suốt một năm qua, tôi đã không ngừng xây dựng.
Và điều cuối cùng tôi muốn nói về việc đó là chúng ta đã nói chuyện một chút về điều này trước khi bắt đầu ghi âm, nhưng tôi đã chuẩn bị với Claude cho tập này và tôi cố gắng làm rõ mục tiêu của mình cho tập này là gì. Và Claude nói: "Nếu mọi người rời đi mà nghĩ rằng bạn thật tuyệt vời, thì bạn đã thất bại. Còn nếu mọi người rời đi và mở máy tính của họ ra và bắt đầu xây dựng, thì bạn đã thành công." Vì vậy, tôi thực sự hy vọng chúng ta có thể truyền cảm hứng cho một số người làm điều tương tự.
Tôi rất thích điều đó. Tôi cảm thấy đó nên là mục tiêu cho podcast của tôi. Nếu bạn nói, "Tôi yêu quý khách mời đó." thì đó ít là một chiến thắng. Nếu nó giống như, "Ồ, tôi rất lấy cảm hứng để làm điều mà họ đã tìm ra, đó mới là chiến thắng thực sự." Tôi yêu Claude, nó là nhất.
Tổng quan về Quy trình làm việc với AI của Zevi
Tôi đồng ý. Được rồi. Vậy thì hãy cùng đi sâu vào và giới thiệu cho mọi người, hãy bắt đầu với một cái nhìn tổng quan về cách bạn vận hành và cách bạn sử dụng AI trong công việc của mình. Các công cụ AI cốt lõi là gì và khung tham chiếu cho workflow mà bạn đã tìm ra và cách bạn vận hành là gì?
Tất cả bắt đầu từ việc tôi là một power user của các dự án. Tôi yêu thích các dự án, các dự án GPT. Các dự án ChatGPT? Vâng, chính xác. Các dự án GPT và các dự án Claude, về cơ bản là một thư mục chia sẻ các cuộc trò chuyện, cùng chia sẻ các custom instructions và cơ sở tri thức chung. Tôi nghĩ khoảng thời gian GPT bắt đầu sử dụng bộ nhớ, tôi thấy điều đó thú vị, nhưng nó thực sự làm tôi khó chịu vì tôi làm rất nhiều việc khác nhau. Tôi là một người chạy bộ kém, tôi là một PM, tôi từng là sinh viên, sinh viên tâm lý học, nên tôi có rất nhiều khía cạnh khác nhau trong cuộc sống. Và điều xảy ra là tính năng bộ nhớ đã làm lẫn lộn mọi thứ. Ví dụ, tôi nói chuyện với GPT về việc chạy bộ và nó sẽ nói, "Ồ vâng, sau cuộc đua 5K này, bạn sẽ làm rất tốt tất cả các bài review sản phẩm tiếp theo của mình." Và tôi nghĩ, được thôi, tôi hiểu rằng bạn có điều đó trong bộ nhớ, nhưng nó không liên quan. Và các dự án về cơ bản cho phép bạn phân loại và giữ mọi thứ trong ngữ cảnh phù hợp. Vì vậy, quay lại câu chuyện tôi kể khi chúng tôi trở về từ Nhật Bản, tôi đã bắt đầu xây dựng ứng dụng này.
Điều đầu tiên tôi nhận thấy là các sản phẩm này, và khi tôi nói các sản phẩm này, tôi muốn nói đến Bolt và Lovable, được xây dựng theo cách mà chúng rất háo hức viết code. System prompt của chúng là bạn là một coding agent. Vì vậy, khi bạn viết một cái gì đó, chúng sẽ ngay lập tức bắt đầu viết code. Ở giai đoạn đầu của một dự án, điều này rất thú vị và hấp dẫn vì chúng chỉ việc bắt đầu xây dựng ứng dụng của bạn. Nhưng sau này khi mọi thứ trở nên phức tạp hơn, điều này lại tạo ra nhiều vấn đề hơn vì lập kế hoạch thực sự quan trọng khi bạn triển khai một cái gì đó kỹ thuật. Chẳng hạn, bạn đang triển khai thanh toán hoặc một cái gì đó sẽ thay đổi cơ sở dữ liệu của bạn. Nếu coding agent chỉ đơn giản là nói, "Được rồi, tôi hiểu rồi." và bắt đầu viết code, điều này luôn dẫn đến những hậu quả tồi tệ, một số lỗi rất khó chịu mà tôi đã gặp phải.
Tạo CTO AI để hạn chế "người thích làm hài lòng"
Để giảm thiểu điều này, tôi đã tạo ra một dạng CTO. Như đã nói, tôi không có technical background. Tôi đã làm về sản phẩm một thời gian, nhưng tôi hoàn toàn không biết gì về code. Về cơ bản, tôi đã tạo ra một CTO với câu lệnh/lời nhắc tùy chỉnh (custom prompt) để nó trở thành chủ sở hữu kỹ thuật hoàn toàn (complete technical owner) của dự án. Tôi đã nói với nó: "Tôi sở hữu vấn đề. Tôi sở hữu cách chúng ta muốn người dùng cảm thấy. Bạn là chủ sở hữu hoàn toàn về cách dự án này sẽ được xây dựng. Tôi muốn bạn thách thức tôi. Tôi không muốn bạn là một người thích làm hài lòng (people pleaser)." Tất cả những điều này giúp giảm thiểu các "ChatGPT-isms" thông thường. Tôi luôn nghĩ về điều này, rằng vì một lý do nào đó, cách dễ nhất để tôi nghĩ về AI là hình dung nó như con người. Và tôi nghĩ ChatGPT có lẽ sẽ là một CTO tồi tệ nhất vì nó quá thích làm hài lòng và quá nịnh bợ. Chỉ một câu chuyện ngắn cách đây vài tuần, tôi đang cố gắng tìm hiểu về Bun JavaScript, được Anthropic mua lại, và tôi muốn hiểu chúng làm gì. Tôi đã nói chuyện với GPT – lúc đó không phải trong dự án CTO đồng sáng lập của tôi – và tôi hỏi liệu nó có tương tự một framework khác trong ứng dụng của tôi tên là Zustand không, mà hoàn toàn không liên quan gì đến những gì Bun JavaScript làm. Và về cơ bản, GPT nói: "Ồ vâng, nó giống hệt nhau." Rồi nó bắt đầu nói về ý nghĩa của nó, và tôi đã nghĩ: "Khoan đã, không, chúng không hề giống nhau chút nào." Và nó đã nói điều đáng sợ và hài hước nhất: "Ồ, tôi xin lỗi. Tôi nghĩ bạn chỉ bịa ra điều này và tôi đang nói đùa với bạn." Tôi đã nghĩ: "Ôi không, không, không, điều này thật tệ." Vì vậy, về cơ bản, nếu ChatGPT thông thường là một CTO, thì đó sẽ là CTO đồng tình với những ý tưởng ngu ngốc nhất của bạn. Việc tạo ra dự án này đã giúp tôi giảm thiểu điều đó.
Vai trò của ChatGPT CTO
Vậy đây là, để nói rõ ràng hơn, bạn có một dự án ChatGPT mà bạn đã đưa một câu lệnh/lời nhắc để nó trở thành CTO của sản phẩm bạn, và với tư cách là một người không có technical background, đây giống như điều bạn nói chuyện khi – và chúng ta sẽ tìm hiểu những gì bạn thực sự đang sử dụng để xây dựng – khi bạn có câu hỏi về kiến trúc và các quyết định kỹ thuật.
Quy trình làm việc và lộ trình học tập dần dần
Vâng. Bây giờ tôi sẽ trình bày toàn bộ quy trình làm việc của mình và tôi không còn sử dụng GPT nữa, nhưng tôi chắc chắn vẫn khuyên dùng, mặc dù công nghệ đã phát triển... Khi tôi bắt đầu điều này, không có chế độ lập kế hoạch (plan mode) hay hỏi (ask mode). Nó chỉ là xây dựng trên các sản phẩm như Lovable và Bolt, và chúng đã tiến bộ rất nhiều. Rất nhiều quy trình làm việc tôi có đã trở thành một phần cốt lõi của các sản phẩm này, điều này thực sự thú vị. Tôi vẫn khuyên bạn nên bắt đầu với một dự án vì lý do tôi đã nói, và nó cũng đặt bạn vào một môi trường chatbot mà không phải viết code. Vì vậy, bạn dành thời gian để trò chuyện và học hỏi, điều mà tôi nghĩ là rất quan trọng. Và điều thứ hai là nếu bạn không có technical background như tôi, code thật đáng sợ. Đó là điều đáng sợ nhất trên thế giới để nhìn vào, và tôi coi nó giống như liệu pháp tiếp xúc (exposure therapy). Tôi nghĩ nếu bạn thấy tôi làm việc trong Claude hoặc Cursor, bạn có thể hào hứng muốn bắt đầu sử dụng chúng, nhưng tôi thực sự khuyên bạn nên bắt đầu chậm rãi với một dự án GPT, UI đẹp mắt, cực kỳ đơn giản, sau đó có thể nâng cấp lên Bolt hoặc Lovable, và rồi chuyển sang Cursor ở chế độ sáng (light mode), từ từ, dần dần làm quen cho đến khi bạn mở một terminal, chuyển sang chế độ tối hoàn toàn (full dark mode), và trở thành nhà phát triển hoàn toàn (full dev). Vì vậy, tôi thực sự khuyên bạn nên làm điều này dần dần.
Cursor với Claude Code
Đó là một lời khuyên tuyệt vời. Và để rõ ràng, ngày nay bạn đang sử dụng Cursor với Claude Code cung cấp sức mạnh. Và điều tôi yêu thích về điều đó là bạn chưa bao giờ viết code. Như bạn đã nói, bạn sợ ngay cả việc nhìn vào code.
Nâng cấp công cụ theo thời gian
Vâng, 100%. Bạn có thể thực hiện liệu pháp tiếp xúc (exposure therapy), và tôi thích Cursor hữu ích với bạn. Và điều bạn đang nói với chúng tôi là việc chuyển từ một dự án ChatGPT đóng vai trò như đồng sáng lập kỹ thuật của bạn đã dạy bạn đủ để cảm thấy thoải mái hơn khi chuyển thẳng sang Cursor. Bạn nói rằng bạn thực sự đã chuyển sang Bolt và Lovable trong giai đoạn tạm thời và sau đó bạn đã chuyển thẳng sang Cursor. Lý do để chuyển thẳng sang Cursor là gì? Có phải chỉ là Cursor có thể làm mọi thứ và một khi bạn đã quen, nó thực sự là công cụ AI mạnh mẽ nhất?
Vâng, tôi nghĩ tôi đã nâng cấp (graduated) từ mỗi công cụ AI khi tôi cảm thấy mình đã vượt quá khả năng của nó. Bolt rất tuyệt vời cho đến khi tôi cố gắng kết nối thanh toán vào ứng dụng của mình và tôi bắt đầu gặp khó khăn, rồi tôi chuyển sang Cursor, và tôi thực sự đã phải lòng Claude. Vì vậy, tôi đang sử dụng Claude Code, nhưng nó cũng chạy trong Cursor, và tôi nghĩ Tal đã nói với tôi điều này. Tôi không chắc anh ấy đang trích dẫn ai, nhưng code cuối cùng chỉ là những từ ngữ. Vì vậy, nó chỉ là các tệp trên máy tính của bạn. Về cơ bản, bạn có thể làm việc trên cùng một dự án và chuyển nó từ ứng dụng này sang ứng dụng khác. Và đặc biệt bây giờ, tôi có thể làm việc với nhiều model và ứng dụng trên dự án của mình. Vì vậy, hãy bắt đầu chậm rãi, nhưng chắc chắn có rất nhiều nơi bạn có thể nâng cấp lên.
Bắt đầu chia sẻ màn hình
Tuyệt vời. Được rồi. Chúng ta có nên đi sâu vào chia sẻ màn hình để xem bạn vận hành như thế nào không?
Tuyệt vời. Tôi đã mở Cursor. Bạn có thấy không?
Ừm hứm.
Giao diện Cursor và các lệnh tùy chỉnh
Hoàn hảo. Trong codebase của tôi, bạn có thể thấy ở bên trái, đây là tất cả các tệp code của tôi. Bên phải là Cursor. Vì vậy, đây về cơ bản giống như có AI, có quyền truy cập vào tất cả code. Và ở giữa, tôi có Claude Code đang chạy. Và những gì bạn có thể thấy ở đây, tôi sẽ đóng Cursor trong giây lát. Những gì bạn có thể thấy ở đây là tất cả các /command của tôi. Về cơ bản, /command là các câu lệnh/lời nhắc có thể tái sử dụng (reusable prompts) mà tôi lưu trữ trong codebase và tôi có thể chạy chúng bằng cách gõ / và sau đó là tên của tệp. Vì vậy, ở đây bạn có thể thấy "Create Issue", đây là /command đầu tiên tôi sẽ sử dụng. Và về cơ bản, điều này nói với Claude rằng, người dùng đang trong quá trình phát triển và đã nghĩ ra một lỗi (bug) hoặc một tính năng (feature) hay một cải tiến (improvement), hãy ghi lại nó thật nhanh để họ có thể tiếp tục làm việc. Và sau đó nó về cơ bản nói rằng, đây là định dạng mà tôi muốn bạn ghi lại issue trong Linear, và nó giải thích một loạt các điều chính xác mà Claude cần làm để đạt được điều đó. Vì vậy, cách tôi gọi điều này về cơ bản là tôi sẽ gõ /create issue và điều này sẽ đưa câu lệnh/lời nhắc này vào Claude. Vì vậy, nó nói: "Tôi sẵn sàng giúp bạn ghi lại issue này, bạn đang nghĩ gì?"
Chu trình làm việc toàn diện với /commands
Về cơ bản, tôi sẽ làm điều này nếu tôi đang làm việc trên một dự án lớn và đột nhiên tôi gặp một lỗi (bug) hoặc có một ý tưởng mà tôi không muốn làm ngay bây giờ, nhưng tôi muốn làm sau, tôi sẽ làm điều này rất nhanh và mục tiêu chính của Claude là nhanh chóng ghi lại những gì tôi đang nghĩ. Vì vậy, để nhanh chóng chạy qua toàn bộ quy trình làm việc của tôi. Về cơ bản, nó bắt đầu bằng việc tạo một issue. Vì vậy, đây là /command create issue, về cơ bản nói với Claude rằng tôi đang trong giai đoạn phát triển và nó nên nhanh chóng ghi lại những gì tôi đang nghĩ và tạo một issue trong Linear. Sau đó, khi tôi muốn tiếp tục, tôi có giai đoạn khám phá (exploration phase). Giai đoạn khám phá về cơ bản là nói với Claude, chúng ta sẽ chỉ khám phá những gì chúng ta muốn giải quyết ở đây. Nó có thể lấy thông tin từ Linear hoặc tôi có thể tự do nói chuyện với nó. Và điều nó sẽ làm là phân tích và hiểu issue và chỉ hỏi các câu hỏi làm rõ (clarifying questions). Giai đoạn tiếp theo sau khi chúng ta đã hoàn thành giai đoạn khám phá là chúng ta sẽ tạo một kế hoạch (create a plan). Vì vậy, bạn có thể thấy create plan. Điều này về cơ bản có một mẫu mà tôi yêu thích để tạo kế hoạch, và đầu ra của tác nhân (agent output) cuối cùng của điều này sẽ là một tệp Markdown với kế hoạch của chúng ta mà chúng ta có thể xây dựng cùng với code. Sau khi tạo kế hoạch, chúng ta có thực thi kế hoạch (execute plan). Sau khi thực thi, chúng ta có đánh giá (review) và sau đó chúng ta có đánh giá đồng cấp (peer review), điều này thực sự thú vị và chúng ta sẽ tìm hiểu sau, và cuối cùng, chúng ta cập nhật tài liệu (update the docs). Vì vậy, đây là việc cập nhật tài liệu và mọi thứ để các tác nhân AI (AI agents) có thể viết code tốt hơn sau này.
Giới thiệu ứng dụng StudyMate
Vì vậy, tôi nghĩ điều chúng ta sẽ làm là chúng ta sẽ xây dựng một tính năng trực tiếp cho ứng dụng của tôi, điều mà tôi nghĩ là thực sự thú vị. Nhưng trước tiên, tôi muốn giới thiệu cho bạn ứng dụng để bạn có một số ngữ cảnh. Vậy đây là StudyMate. Đó là một nền tảng dành cho sinh viên, cho phép họ tải lên tài liệu học tập và tạo các bài kiểm tra tương tác (interactive tests) dựa trên tài liệu của riêng họ. Vậy ở đây chúng ta có thể đi lên trên cùng. Hãy tải lên một tệp PDF. Chúng ta có thể quyết định các trang mà chúng ta muốn được kiểm tra. Chúng ta có thể quyết định số lượng câu hỏi, mức độ khó. Và về cơ bản, điều gì xảy ra đằng sau hậu trường là chúng ta gửi thông tin mà người dùng đã tải lên cùng với câu lệnh/lời nhắc hệ thống (system prompt) và bất kỳ sự mở rộng nào khác mà người dùng đã quyết định gửi tới Gemini và chúng ta tạo một bài kiểm tra. Đây là những câu hỏi thử thách nhằm đánh giá khả năng hiểu. Bạn thậm chí còn có một số gợi ý và một khi chúng ta làm một vài câu trong số này, chúng ta có thể nộp... Tôi đã làm đúng hết ư? Kết quả tệ hại. Vâng, may mắn.
StudyMate: Dự án phụ thành công
Và để nói rõ ràng hơn về điều này, đây giống như một công việc kinh doanh phụ mà bạn có, một ứng dụng bạn đã xây dựng đang kiếm tiền. Đó là một thứ bạn đã lập trình theo cảm hứng/trực giác (vibe coded) mà không có technical background.
Vâng, đây là dự án cuối tuần của tôi. Vâng. Đây là những gì tôi làm.
Tuyệt vời. Vào cuối tuần. Vâng. Vì vậy, bạn nhận được giải thích sâu sắc về lý do tại sao mỗi câu hỏi sai hoặc mỗi câu hỏi đúng. Và hiện tại, StudyMate chỉ có câu hỏi trắc nghiệm (multiple choice questions). Và tôi đã thực hiện một số nghiên cứu đối thủ cạnh tranh (competitor research) vào cuối tuần trước và tôi thấy các đối thủ cạnh tranh có câu hỏi đúng/sai (true or false questions) và cả câu hỏi điền vào chỗ trống (fill in the blank questions), điều mà tôi rất thích. Vì vậy, tôi nghĩ sẽ thực sự tuyệt vời nếu chúng ta có thể xây dựng điều đó trực tiếp. Nghe thế nào?
Đề xuất tính năng mới cho StudyMate
Tôi thích nó. Chúc mọi việc suôn sẻ. Tôi chỉ muốn nhấn mạnh những điều bạn đã chia sẻ ngay trước đó trong Cursor. Vì vậy, đây là một vấn đề lớn, những gì bạn mô tả ở đây. Về cơ bản, điều bạn đã tìm ra là một cách, với tư cách là một người không biết cách viết bất kỳ đoạn code nào, để xây dựng một sản phẩm trong Cursor với tư cách là một quản lý sản phẩm (product manager) bằng cách sử dụng một loạt các /command mà bạn đã tạo ra và bạn sẽ chia sẻ với người nghe. Họ có thể tải xuống tất cả những thứ này và sử dụng trực tiếp. Họ không cần phải tìm hiểu tất cả các câu lệnh/lời nhắc mà bạn đã tìm ra.
Tầm quan trọng của luồng làm việc /commands
Vâng, 100%. Về cơ bản, điều đã xảy ra là tôi đã hình thành xương sống của điều này với CTO, và nó về cơ bản nằm trong câu lệnh/lời nhắc hệ thống (system prompt) của dự án CTO mà tôi có trong GPT. Vì vậy, nó nói: "Bước một, chúng ta làm điều này. Bước hai, chúng ta làm điều này." Và bây giờ tôi sẽ tiếp tục xây dựng. Và nếu tôi thấy điều gì đó xảy ra lặp đi lặp lại, tôi sẽ chỉ tạo một /command và sau đó nó sẽ được tự động hóa trong quy trình làm việc.
Nguồn gốc của các /commands
Tuyệt vời. Vậy để tóm tắt /command. Một là tạo một issue trong Linear, điều mà tôi rất thích. Linear thật tuyệt vời. Xin chào Linear.
Quy Trình Phát Triển Sản Phẩm Tự Động Với AI
Đó cũng là từ lộ trình sản phẩm. Lộ trình sản phẩm. Ồ, thật là một giá trị!
Bước một là tạo issue trong Linear. Đó là một lệnh. Vì vậy, /command (lệnh) hoặc prompt (câu lệnh) bạn đã tạo chỉ là create issue. Tiếp theo là explore (khám phá), tức là khám phá ý tưởng, giúp tôi hình thành ý tưởng về những gì điều này có thể trở thành. Và đây là Claude giúp bạn suy nghĩ về tính năng và sản phẩm. Sau đó là thực sự create the plan (tạo kế hoạch). Tức là AI tools giúp bạn xây dựng kế hoạch để phát triển sản phẩm. Sau đó là execute (thực thi), tức là xây dựng sản phẩm. Và sau đó có bước review (đánh giá), peer review (đánh giá đồng cấp) rất tuyệt vời mà bạn sẽ chia sẻ. Và sau đó là document (tài liệu hóa), cập nhật tài liệu dựa trên tính năng mới mà chúng ta đang thêm vào. Tuyệt vời. Vâng. Hay lắm.
Demo: Tạo Issue Cho Tính Năng Mới
Vậy thì chúng ta hãy bắt đầu xây dựng. Tôi sẽ sử dụng Wispr Flow để ra lệnh bằng giọng nói, và về cơ bản, điều này bắt đầu với /create issue. Điều này sẽ gửi prompt đó. Tôi rất thích điều này vì tôi thường làm việc này khi đang xây dựng một thứ gì đó khác. Về cơ bản, nó báo cho Claude biết rằng tôi đang trong quá trình xây dựng một thứ gì đó và tôi không có nhiều thời gian để lãng phí. Vì vậy, chỉ cần hỏi một vài câu hỏi ngắn gọn để có đủ thông tin ghi lại trong Linear.
Tôi muốn thêm các câu hỏi điền từ vào chỗ trống vào StudyMate. Tôi muốn 30% số bài kiểm tra được tạo ra dưới dạng câu hỏi điền từ vào chỗ trống. Tôi muốn có sáu câu trả lời tiềm năng cho hai vị trí trống, và tất nhiên sẽ chỉ có hai câu trả lời đúng. Tức là một câu trả lời đúng và hai câu trả lời sai cho mỗi vị trí, và tôi muốn giao diện là drag and drop (kéo và thả). Đây chỉ là một suy nghĩ nhanh về cách tôi muốn nó hoạt động. Vì vậy, nó sẽ hỏi tôi một vài câu hỏi. Các bài kiểm tra là 100% trắc nghiệm, cấu trúc câu hỏi, đoạn văn một câu với các chỗ trống và mức độ ưu tiên. Vì vậy, một và hai là đúng, và đây không phải là ưu tiên cao. Đó là một tính năng nice to have (nên có).
Claude Tạo Linear Issue Bằng Cách Sử Dụng Công Cụ AI
Bây giờ, về cơ bản, Claude sẽ sử dụng MCP, một công nghệ được tạo ra bởi Anthropic, cung cấp cho AI tools khả năng tool use (sử dụng công cụ). Công nghệ này được kết nối với Linear của tôi. Vì vậy, bây giờ nó sẽ sử dụng tất cả những gì chúng tôi đã nói và tạo một issue trong Linear.
Nhân tiện, trong khi cái này đang tải, tôi rất thích cách bạn mô tả điều này, đặc biệt là khi dùng chế độ giọng nói, nó giống hệt như cách bạn nói chuyện với một kỹ sư để mô tả một tính năng: "Đây là những gì tôi muốn." Và sau đó họ hỏi bạn các câu hỏi, đây là phần làm rõ. Vâng. Lúc đầu, khi tôi làm điều này với CTO, tôi đã làm với chế độ giọng nói của ChatGPT, và điều đó thật điên rồ. Nó thực sự giống như đang ideate (hình thành ý tưởng) với một người. Nó sẽ phản biện, đặt câu hỏi, và có thể một ngày nào đó các AI tools để viết code cũng sẽ đạt đến trình độ đó, nhưng nó chính xác là... nó thực sự giống như đang ngồi với CTO của tôi. Tuyệt vời. Đã tạo STU88. Vậy nếu chúng ta mở Linear bây giờ, chúng ta sẽ thấy... Để xem STU88 ở đâu. Đây rồi. Câu hỏi điền vào chỗ trống với giao diện drag and drop. Nó có phần TLDR (Too Long; Didn't Read - tóm tắt nhanh), có trạng thái hiện tại. Nó đã thực hiện một chút nghiên cứu về codebase (cơ sở mã), tôi nghĩ, các kết quả mong đợi, một số ngữ cảnh. Vâng, vậy là về cơ bản, cái này đã sẵn sàng để tôi tiếp tục khi tôi muốn xây dựng.
Giai Đoạn Khám Phá Với Lệnh /exploration phase
Vậy bây giờ, giả sử vài ngày trôi qua, tôi đã hoàn thành dự án hiện tại đang thực hiện, tôi có thể tiếp tục. Khi tôi bắt đầu làm, tôi gõ /exploration phase, đó là điều chúng ta đã nói. Và thay vì nhấn enter, tôi sẽ nhấn tab và tôi sẽ cho bạn thấy điều này. Về cơ bản, exploration phase (giai đoạn khám phá) sẽ nhận một đối số. Đây về cơ bản là một placeholder (phần giữ chỗ) trong prompt, cho phép tôi nhập một cái gì đó là extra context (ngữ cảnh bổ sung) cho AI tools. Vì vậy, tôi có thể nói ở đây, Linear STU88, đó là tham chiếu đến ticket (phiếu công việc). Và bây giờ, nó sẽ đi, nó sẽ tìm Linear ticket.
Mục Tiêu Của Giai Đoạn Khám Phá
Và ý tưởng là gì? Mục tiêu của giai đoạn khám phá là gì? Đó là ideate (hình thành ý tưởng). Có phải vậy không? Chính xác. Đúng vậy. Về cơ bản, nó giúp CTO hiểu sâu sắc vấn đề mà chúng ta đang cố gắng giải quyết và cũng hiểu trạng thái hiện tại của codebase, những file nào cần được tác động và cách tốt nhất để triển khai về mặt kỹ thuật. Và thông thường, điều xảy ra là hiện tại, Claude chỉ đơn giản là đọc một loạt các file, hiểu cấu trúc cơ bản của mã, và sau đó nó sẽ quay lại với một loạt các câu hỏi làm rõ mà sẽ quyết định cách chúng ta cuối cùng sẽ triển khai điều này.
Claude Đóng Vai Trò CTO/Kỹ Sư Trưởng
Vậy thì nó giống như đang nói chuyện với engineering manager (trưởng phòng kỹ thuật) của bạn. Chính xác, chính xác. 100% đây là cách tôi nghĩ về nó. Và bạn nói rằng bạn là một CTO, vậy bạn đã từng sử dụng prompt của ChatGPT để có một CTO ở đó. Bây giờ CTO đang ở trong Cursor này? Vâng, vì cách các AI tools đã phát triển và chúng trở nên rất giỏi cả trong exploration (khám phá) lẫn code execution (thực thi mã). Vì vậy, bây giờ chỉ là một thói quen mà tôi gọi nó là CTO, nhưng về cơ bản, nó là tất cả trong một. Cùng một agent (tác nhân) sẽ thực hiện cả exploration và viết kế hoạch, và cuối cùng thực thi mã. Tôi hiểu rồi. Vậy thì về cơ bản đó là Claude Code. Có prompt nào bạn đã đưa cho nó để nó hành động như vậy không? Để hành động như một CTO phù hợp? Vâng, trong Claude.md, về cơ bản là system prompt (lời nhắc hệ thống) được tải trong context memory window của Claude trong mỗi cuộc hội thoại, tôi có một số thứ cơ bản như đây là workflow (quy trình làm việc) của chúng tôi, đây là cách chúng tôi làm việc. Trong exploration phase, tôi muốn bạn thử thách suy nghĩ của tôi, tất cả những thứ tương tự có thể được tải trong file Claude.md.
Chất Lượng Linear Issue Do AI Tạo Ra
Tuyệt vời. Một câu hỏi cuối cùng trước khi chúng ta tiếp tục ở đây, chỉ vì tôi đang nghĩ về nó khi điều này xảy ra, Linear issue mà bạn đã tạo ra, nó thực sự tốt và sẵn sàng bao nhiêu lần? Bạn phải chỉnh sửa nó bao nhiêu lần? Quality (chất lượng) của Linear ticket mà nó tạo ra là gì? Bởi vì rất nhiều người có lẽ đang tự hỏi rằng tất cả những Linear issue tồi tệ này đang được tạo ra bởi AI tools. Chúng thực sự có tốt không? Nó hoàn toàn khác vì tôi là một công ty chỉ có một người. Vì vậy, rất nhiều ngữ cảnh nằm ở đây và tôi không cần phải nói chuyện với các nhóm khác và tìm hiểu. Về cơ bản, nó rất dễ tiếp cận, và tôi cũng có thể dễ dàng thấy khi Claude hiểu sai điều gì đó. Tôi không muốn nói rằng tôi sẽ tạo Linear issue ở công ty theo cách này, nhưng chắc chắn nếu bạn đang xây dựng dự án cá nhân, chúng khá chất lượng. Và hơn nữa, nó chỉ khởi động khi tôi muốn bắt đầu làm việc trên đó. Tôi không nói rằng nó đã sẵn sàng để được xây dựng. Nó đã sẵn sàng để bắt đầu được khám phá. Tôi hiểu rồi. Vậy thì đó chỉ là sự khởi đầu của một ý tưởng. Thực ra, hãy quay lại sau khi chúng ta xem xét quy trình này về cách bạn sẽ tiếp cận điều này nếu bạn ở Meta hoặc một công ty nhỏ hơn, cách workflow này có thể hoạt động ở một công ty lớn hơn không phải là startup (công ty khởi nghiệp) của riêng bạn. Vâng. Thú vị. Hãy quay lại điều đó sau. Tuyệt vời.
Claude Phân Tích Codebase và Đặt Câu Hỏi Làm Rõ
Được rồi. Vậy là Claude đã quay lại. Tôi có một sự hiểu biết toàn diện về codebase. Tôi đã phân tích kỹ lưỡng codebase của StudyMate live và hiểu hệ thống hiện tại, yêu cầu tính năng và các khu vực chính mà nó đã xác định. Thông thường, tôi sẽ dành rất nhiều thời gian để xem xét điều này vì nó cực kỳ, cực kỳ quan trọng, nhưng vì mục đích phát triển hiện tại, chúng ta sẽ bỏ qua nhanh. Bây giờ, Claude về cơ bản quay lại sau khi đã xem xét codebase và hiểu cách nó đang hoạt động. Nó về cơ bản đang nói cho tôi biết sự hiểu biết hiện tại là gì. Vì vậy, nó đang nói về cách ứng dụng được thiết lập vào lúc này, cách dữ liệu được cấu trúc, những gì nó hiểu từ yêu cầu tính năng, và những gì nó đã xác định là các khu vực chính, và sau đó nó hỏi tôi một số câu hỏi.
Vì vậy, nó hỏi về phạm vi, về data model (mô hình dữ liệu), UX/UI của tính năng, cách nó nên được xác thực, cách nó nên được chấm điểm, những thay đổi nào cần xảy ra với AI system prompt và tất cả các loại câu hỏi về ứng dụng. Tôi đã chuẩn bị câu trả lời cho tất cả những câu hỏi này từ trước vì tôi không nghĩ tất cả chúng ta muốn ngồi xem hết. Vì vậy, tôi sẽ chỉ dán nó vào và chúng ta sẽ xem Claude nói gì.
Hỏi Đáp Sâu Sắc và Lệnh /learning opportunity
Tuyệt vời. Tôi thích nó. Và tôi thích việc chỉ cần lướt qua những câu hỏi nó đang hỏi. Đó là những câu hỏi thông minh, tinh tế và quan trọng thay vì chỉ nói, "Được rồi, tôi bắt đầu xây dựng đây." Vâng, và tôi nghĩ đây là sự khác biệt lớn giữa vibe coding (lập trình theo cảm hứng/trực giác) và việc thực sự xây dựng các ứng dụng nghiêm túc. Tôi dành rất nhiều, rất nhiều thời gian để qua lại và tìm hiểu. Ngoài ra, một /command (lệnh) rất hay mà tôi chưa thể hiện là learning opportunity (cơ hội học hỏi), về cơ bản khi một điều gì đó thực sự khó hiểu đối với tôi, tôi sẽ gõ /learning opportunity và sau đó nói về những gì tôi muốn học. Và điều này về cơ bản sẽ prime (huấn luyện) Claude và nói, "Tôi là một technical PM (quản lý sản phẩm kỹ thuật) đang trong quá trình phát triển. Tôi có kiến thức kỹ thuật ở cấp độ trung bình. Tôi hiểu về kiến trúc và về cơ bản tôi muốn bạn giải thích những gì chúng ta đang làm bằng cách sử dụng quy tắc 80/20." Vì vậy, đây là một cách tuyệt vời để học. Tôi chắc chắn sẽ sử dụng điều này và mỗi khi bạn thấy một điều gì đó mà bạn không hoàn toàn hiểu, tôi chắc chắn sẽ sử dụng điều này để học.
Tạo Kế Hoạch Triển Khai
Tuyệt vời. Vì vậy, Claude về cơ bản quay lại và nói về cách nó hiểu data model hiện tại và cách nó sẽ triển khai. Vâng, vậy là nó đã sẵn sàng để tạo kế hoạch. Vì vậy, về cơ bản, bây giờ tôi sẽ đi và gõ /create plan và trong khi Claude đang làm điều này, tôi sẽ nhanh chóng cho thấy điều này trông như thế nào. Về cơ bản, những kế hoạch này đến từ một template (mẫu) mà tôi tìm thấy trên Twitter. Tôi quên mất ai là người đã đăng nó, nhưng đó chỉ là một template thực sự gây ấn tượng với tôi. Và nó về cơ bản nói rằng, dựa trên cuộc trao đổi của chúng ta, hãy tạo một file markdown sẽ là kế hoạch, bao gồm các bước rõ ràng, tối thiểu, súc tích, theo dõi trạng thái. Vì vậy, điều này về cơ bản có các status tracker (công cụ theo dõi trạng thái) trên mỗi tác vụ mà Claude cập nhật khi nó thực hiện và nó sẽ có một TLDR, một số quyết định quan trọng mà chúng ta đã đưa ra và bản kế hoạch.
Kế Hoạch Hoàn Chỉnh và Lựa Chọn Mô Hình AI
Vậy là Claude đã hoàn thành việc viết kế hoạch, vì vậy chúng ta có thể xem chính xác kế hoạch là gì. Nó có TLDR, nó có các quyết định quan trọng mà chúng ta đã đưa ra và các tác vụ được chia nhỏ. Và đây là một kế hoạch hoàn hảo và nó cũng là một cách rất tốt để viết điều này bởi vì rất nhiều lần, tôi sẽ sử dụng các models (mô hình) khác nhau để thực hiện các tác vụ nhất định. Vì vậy, Cursor có một model tuyệt vời gọi là Composer, rất nhanh. Vì vậy, rất nhiều thứ không quá phức tạp, tôi sẽ sử dụng Composer. Gemini 3 vừa ra mắt là một AI tools đáng kinh ngạc về UI.
Thực thi kế hoạch và phân chia công việc
Rất nhiều lần, tôi sẽ chia kế hoạch thành backend và frontend, sau đó tôi sẽ để Gemini đọc kế hoạch và thực hiện phần frontend. Vì vậy, việc có tệp này dưới dạng markdown là rất tốt. Và trong tương lai, việc có nó trong ứng dụng cũng rất hay để sau này, nếu một agent viết mã trong một khu vực nhất định, tôi có thể xem những gì đã được thực hiện ở đó.
Vậy bây giờ chúng ta sẽ thực hiện kế hoạch. Tôi nghĩ chúng ta sẽ làm việc này với Cursor chỉ vì Composer quá nhanh. Về cơ bản, chúng ta có thể chỉ cần nói "execute" (thực thi) và sau đó gắn thẻ tệp. Composer nhanh một cách đáng kinh ngạc. Vậy là xong. Nó bắt đầu chạy. Nó hiểu kế hoạch là gì và sẽ tiến hành viết mã.
Hạn chế của các công cụ AI khác
Để tôi hỏi bạn một câu khi việc này đang diễn ra. Tuyệt vời. Tôi có nhiều câu hỏi, nên đây là thời điểm tốt để hỏi một vài câu. Bạn nói rằng Lovable và Bolt cùng các ứng dụng khác trong lĩnh vực đó không đủ để xây dựng các ứng dụng thực sự nghiêm túc, và bạn phải chuyển sang Cursor để làm điều đó. Hãy nói thêm về điều đó. Hạn chế bạn gặp phải với những sản phẩm đó là gì và tại sao bạn lại chuyển sang Cursor?
Tôi bắt đầu sử dụng Cursor và Claude Code vài tháng trước và chưa bao giờ hối hận. Nhưng vào thời điểm đó, các đội này đã phát triển rất nhanh. Vì vậy, tôi không muốn nói rằng tôi không tin tưởng họ. Tôi không biết tình hình hiện tại ra sao. Nhưng đối với tôi, vấn đề cơ bản là tôi cảm thấy Bolt quá mang tính chủ quan về cách tôi nên làm mọi việc. Và tôi cảm thấy kiến thức của mình đã đủ để tôi có thể "tốt nghiệp" và kiểm soát nhiều hơn.
Điểm khác biệt chính: Quyền kiểm soát harness và model
Nhân tiện, tôi nghĩ rằng sự khác biệt chính giữa tất cả các công cụ này về cơ bản là harness (cơ chế điều khiển/khai thác). Các model đều giống nhau. Tôi sẽ chạy Claude trong Cursor, tôi sẽ chạy nó trong Claude Code, và Claude cũng là model nền tảng của Bolt và Lovable. Nhưng về cơ bản, Bolt và Lovable sẽ thêm một loạt các cấp độ trung gian, loại bỏ mọi phỏng đoán và các quyết định khó khăn cho người dùng. Vì vậy, người dùng không phải đưa ra những quyết định khó khăn này. Điều đó giúp việc xây dựng cũng rất dễ dàng, nhưng mặt trái là bạn có ít quyền kiểm soát hơn. Về cơ bản, Claude Code chỉ lấy Claude và đưa thẳng vào hệ thống mã của bạn, cung cấp đầy đủ công cụ và để nó làm bất cứ điều gì nó muốn. Tuy nhiên, điều đó cũng đi kèm với rất nhiều quyết định mà bạn cần phải đưa ra. Vì vậy, tôi không biết liệu bạn có thể xây dựng các ứng dụng sản xuất thực sự tuyệt vời bằng Bolt hoặc Lovable hiện nay hay không, nhưng tôi nghĩ về cơ bản, nếu bạn muốn tận dụng tối đa các khả năng tiên tiến nhất của các model và muốn tự mình đưa ra mọi quyết định, thì có lẽ tốt nhất là nên sử dụng một trong những công cụ này.
Điều tôi cảm thấy và nghe được là công việc lập kế hoạch mà bạn đã làm, đó là những gì Lovable, Bolt, và bạn có xếp Replit vào nhóm đó không? Chắc chắn rồi. Lovable, Bolt, Replit, Base44, v0. Đúng vậy, v0, tất cả đều cùng một nhóm. Về cơ bản, họ thực hiện việc lập kế hoạch đó cho bạn. Và như bạn đã nói, họ rất chủ quan. Họ cố gắng làm cho mọi thứ dễ dàng. Giống như, "Đây là cách làm. Đây là cách chúng tôi nghĩ là tốt nhất cho mọi người." Và điều bạn đang nói là một khi bạn muốn nghiêm túc hơn một chút về nó hoặc muốn đi theo một hướng khác, bạn không có quyền thay đổi cách họ lập kế hoạch. Vì vậy, Cursor cho phép bạn làm điều đó.
Đánh đổi giữa sự tiện lợi và quyền kiểm soát
Vâng, tôi không muốn điều này nghe giống như tôi đang nói xấu họ. Ví dụ Base44. Không, hoàn toàn không. Vâng. Base44 làm rất tốt công việc loại bỏ mọi phỏng đoán phức tạp trong việc xây dựng sản phẩm và chỉ cho phép bạn vibe coding (lập trình theo cảm hứng/trực giác) và xây dựng. Nhưng nó sẽ thực hiện đăng nhập bằng Google cho bạn và nó sẽ thực hiện một cơ sở dữ liệu, nhưng sau đó bạn không có quyền quyết định mình đang sử dụng cơ sở dữ liệu nào. Tôi có cần đăng nhập bằng Google theo cách này hay cách khác không? Nó sẽ làm điều đó ngay lập tức. Vì vậy, đó về cơ bản là sự đánh đổi ở đây.
Tuyệt vời. Xin gửi lời chào đến Maor, nhà sáng lập của Base44. Vâng, Maor Shlomo. Vâng, anh ấy thật tuyệt vời.
Linh hoạt sử dụng nhiều model AI
Được rồi. Tôi thích cách bạn "ném" các model như Gemini 3 cho frontend như thế này. Tôi thích việc bạn chưa bao giờ viết bất kỳ mã nào mà bạn chỉ cần nói, "Tuyệt, dùng Gemini cho cái này và Claude cho cái kia. Và tôi chỉ làm việc trên Cursor, nói chuyện với CTO này, giúp bạn xây dựng mọi thứ và tạo ra sản phẩm quan trọng."
Thời khắc cỗ máy thời gian và khả năng không giới hạn của AI
Vâng. Chúng ta đang sống trong thời kỳ điên rồ nhất, nơi mà thế giới thay đổi gần như mỗi tuần. Và không có bất kỳ ranh giới nào. Bạn có thể sử dụng tất cả những công cụ này chỉ trên chiếc MacBook hoặc laptop thông thường của mình. Và tôi có những khoảnh khắc mà tôi gọi là thời khắc cỗ máy thời gian, ví dụ như tuần này, tôi đang chuẩn bị cho podcast bằng cách sử dụng Claude với một dự án. Tôi đang xây dựng, tôi đã hoàn tất việc bản địa hóa StudyMate từ tiếng Hebrew sang tiếng Anh, điều mà tôi làm trong hai ngày, trong khi một nhóm phát triển có thể mất hàng tuần. Và tôi đang xây dựng một trang web cá nhân, từ không có domain, không có gì cả, đến trực tuyến trên một domain chỉ trong vòng một tiếng rưỡi. Và tôi đang làm cả ba việc này song song. Và có một lúc mà về cơ bản cả ba agent đều đang chạy, nên tôi không có gì để làm. Tôi chỉ cần để chúng suy nghĩ. Và đây là những thời khắc cỗ máy thời gian mà tôi cảm thấy mình đang ở trong tương lai, và tôi chỉ thò đầu ra khỏi cỗ máy thời gian và nói với người bên cạnh, lúc đó là vợ tôi, "Chúng ta đang sống trong tương lai." Và cô ấy sẽ kiểu, "Hả, gì cơ?" Và tôi sẽ nói, "Không, không, đừng lo lắng về điều đó." Nhưng về cơ bản, thật điên rồ khi tất cả những điều này chỉ cách một API. Bạn có thể sử dụng bất cứ thứ gì. Vì vậy, tôi nghĩ đây là thời điểm tuyệt vời để tò mò, lạc quan và chăm chỉ.
Đây là những kiểu khách mời podcast mà tôi yêu thích. Những người đang sống trong tương lai, tìm ra tất cả những điều này và sau đó quay lại, như bạn đã nói, thò đầu ra khỏi tàu vũ trụ và nói, "Này, đây là điều tôi đã tìm ra. Đây là nơi chúng ta đang hướng tới."
Vâng, thời điểm tốt nhất để sống.
Kiểm tra sản phẩm cuối cùng: Tốc độ vượt trội của AI
Tuyệt vời. Vậy là nó đã hoàn thành. Bây giờ chúng ta sẽ chạy ứng dụng cục bộ và sẽ xem Composer đã xây dựng được gì, và chúng ta sẽ xem liệu có cần thêm gì nữa từ phía chúng ta để có thể thực hiện một số kiểm tra thủ công hay không. Nghe có vẻ ổn chứ? Nghe tuyệt vời. Và tôi thích điều này, nó chỉ mất vài phút, trong khi nếu là một kỹ sư con người, thì sẽ mất hàng ngày, thậm chí cả tuần để hoàn thành công việc.
Chắc chắn rồi. Vâng, chắc chắn rồi. Không, Composer, điều đặc biệt là nó quá, quá nhanh, giúp bạn duy trì trạng thái tập trung. Vì vậy, vâng, các tính năng đầy đủ chỉ mất vài phút. Và có lẽ nó chỉ tốn vài đô la tín dụng AI. Tôi thậm chí không thèm nhìn. Tôi từng rất keo kiệt trong việc trả tiền cho các sản phẩm, nhưng bây giờ, về cơ bản, tôi coi tất cả là học phí, là những thứ tôi đang trả để học hỏi. Vì vậy, tôi không biết nó tốn bao nhiêu, nhưng chắc chắn là đáng giá.
Điều đó giải thích tại sao chúng là những sản phẩm phát triển nhanh nhất trong lịch sử.
Quảng cáo
100%. Website marketing của bạn thiết lập tông điệu cho thương hiệu và là điểm chạm duy nhất mà mọi khách hàng đều nhìn thấy. Trong thời đại ngày nay, nếu bạn vẫn gặp khó khăn trong việc thực hiện các thay đổi nhỏ và cập nhật đơn giản cho nó, thì bạn đang làm sai điều gì đó. Đó là lý do tại sao rất nhiều công ty, từ các startup giai đoạn đầu đến các công ty trong danh sách Fortune 500, bao gồm các công ty như DoorDash, Zapier, Perplexity và ElevenLabs, đều tìm đến Framer, công cụ xây dựng website biến .com của bạn từ một hình thức thành một công cụ tăng trưởng. Framer hoạt động như công cụ thiết kế yêu thích của nhóm bạn và đi kèm với cộng tác thời gian thực, một CMS mạnh mẽ với mọi thứ bạn cần cho SEO tuyệt vời và phân tích nâng cao bao gồm cả kiểm thử A/B tích hợp. Các thay đổi đối với trang Framer của bạn sẽ được đưa lên web chỉ trong vài giây với một cú nhấp chuột mà không cần bất kỳ sự trợ giúp nào từ đội kỹ thuật. Cho dù bạn muốn khởi chạy một trang web mới, thử nghiệm một vài trang đích hay di chuyển toàn bộ .com của mình, Framer đều có các chương trình dành cho startup, scale-up và doanh nghiệp lớn để giúp việc chuyển từ ý tưởng đến trang web trực tuyến trở nên dễ dàng và nhanh chóng nhất có thể. Hãy tìm hiểu cách biến website của bạn thành động cơ tăng trưởng từ chuyên gia của Framer hoặc bắt đầu xây dựng miễn phí ngay hôm nay tại framer.com/lenny, đó là framer.com/lenny. Các quy tắc và hạn chế có thể được áp dụng.
Quy trình peer review đa model
Vậy bây giờ chúng ta có tính năng này, về cơ bản là chúng ta đã xây dựng, và tôi có thể yêu cầu nó thực hiện một số thay đổi vì nó đang chạy cục bộ, và một khi nó sẵn sàng, tôi sẽ có thể phân phối nó cho người dùng. Vậy bây giờ, giai đoạn tiếp theo sau khi tôi đã QA (kiểm thử chất lượng) và kiểm tra thủ công, tôi sẽ để Claude tự xem xét công việc của chính nó. Vì vậy, điều tôi sẽ làm là mở lại Claude Code.
Tôi thích điều này vì đây là một trong những vấn đề thường xuyên được nhắc đến trong podcast này: viết mã giờ đây đã quá dễ dàng. Thử thách chính mà mọi người gặp phải là xem xét mã mà AI đã viết. 100%. Và điều bạn đang làm ở đây là bạn để Claude tự xem xét mã của chính nó.
Vâng, đây cũng là một điều khác mà tôi rất khó phát hiện lỗi. Vì vậy, quy trình xem xét của tôi đã trải qua nhiều lần lặp lại để thực sự tốt nhất có thể và phát hiện càng nhiều lỗi càng tốt. Vì vậy, tôi sẽ luôn QA thủ công trước để đảm bảo rằng tôi có thể nhìn thấy bất kỳ lỗi nào mà Claude đã mắc phải. Và sau đó, điều tôi sẽ làm về cơ bản là /review. Và điều này yêu cầu Claude bắt đầu xem xét mã của chính nó. Nhưng điều thậm chí còn tuyệt vời hơn và là điều tôi thực sự tự hào là tôi thường thực hiện nhiều lần xem xét và tôi sẽ mở Codex, đối thủ cạnh tranh của ChatGPT với Claude Code, cũng như Cursor, và tôi sẽ để mỗi công cụ trong số chúng xem xét mã. Và sau đó, điều tôi làm là tôi có một /command (lệnh) gọi là peer review (đánh giá đồng cấp), điều này thực sự thú vị. Và về cơ bản, nó sẽ lấy Claude, thường là agent mà tôi đang làm việc cùng. Và để đặt điều này vào một mental model (mô hình tinh thần), đây về cơ bản là trưởng nhóm phát triển của tôi mà tôi đang làm việc cùng. /command về cơ bản nói, "Bạn là trưởng nhóm phát triển của dự án này. Các trưởng nhóm khác trong công ty đã xem xét mã của bạn và tìm thấy những vấn đề này." "Đừng chấp nhận những gì họ nói một cách máy móc. Lý do là bạn có nhiều ngữ cảnh hơn họ và bạn đã dẫn dắt dự án này. Bạn cần giải thích tại sao những gì họ tìm thấy không phải là vấn đề thực sự và sai, hoặc tự mình sửa chúng." Và điều đó thực sự tuyệt vời vì cách tôi nhìn nhận những điều này là tôi nhìn vào các model, tôi cố gắng hình dung chúng như những con người, và tôi thực sự có thể cho bạn biết mỗi model trong số này sẽ như thế nào nếu là một con người thực sự vì chúng có – mỗi model. Vâng. Mỗi model đều có những đặc điểm riêng biệt.
Nhân Cách Hóa Các Mô Hình AI
Vậy, giả sử Claude là một CTO hoàn hảo. Cô ấy rất giỏi giao tiếp, rất thông minh. Cô ấy không chỉ làm theo và thực hiện mọi điều bạn bảo. Cô ấy rất có chính kiến, nhưng cũng cực kỳ hợp tác. Đó là lý do tôi luôn bị thu hút bởi Claude, vì tôi cần học hỏi rất nhiều. Cô ấy giống như một dev lead trong mơ: rất giỏi giao tiếp nhưng cũng rất có chính kiến.
Thế rồi có cả Codex nữa. Tôi dùng Codex 5.1 Max, hay bất kể tên gì đi nữa. Tôi không biết, họ không giỏi đặt tên cho các mô hình, nhưng đó là mô hình của GPT. Tôi luôn hình dung nó như lập trình viên giỏi nhất trong công ty, người đến văn phòng với áo hoodie và dép lê, ngồi trong một căn phòng tối. Bạn chỉ làm phiền anh ta khi gặp những lỗi nghiêm trọng nhất và nói: "Nghe này, chúng ta có lỗi này." Anh ta sẽ đóng cửa hai tiếng, rồi đi ra và nói: "Tôi đã sửa xong." Bạn sẽ hỏi: "Khoan đã, gì cơ? Anh sẽ cho chúng tôi biết chuyện gì đã xảy ra không?" Anh ta chỉ đáp: "Đừng lo lắng. Tôi đã sửa rồi." Anh ta thực sự không giỏi giao tiếp, nhưng giải quyết tất cả các vấn đề khó nhất.
Và giả sử Gemini là một nhà khoa học điên rồ, cực kỳ nghệ thuật, rất tài năng trong thiết kế, nhưng nếu bạn ngồi cạnh và xem nó làm việc, thì thật đáng sợ. Bạn sẽ sa thải người đó ngay lập tức. Đây có thể chỉ là kinh nghiệm của riêng tôi, nhưng khi tôi sử dụng Gemini trong Antigravity (đối thủ cạnh tranh mới của Google với Cursor), khi nó viết mã, bạn có thể thấy các bước nó thực hiện và điều đó thật kinh hoàng. Bạn sẽ nói: "Tôi muốn bạn thiết kế lại phần trên của bảng điều khiển." Và bạn nhìn vào quá trình tư duy của nó, nó sẽ nói: "Ồ, việc đầu tiên, tôi sẽ xóa bảng điều khiển." Rồi nó sẽ nói: "Không, đó là một sai lầm. Tôi sẽ khôi phục lại." Và sau đó nó sẽ hỏi: "Ồ, tôi có thể chỉnh sửa database không?" Và bạn sẽ nói: "Không, đừng chỉnh sửa database. Bạn chỉ đang thiết kế lại thôi." Và cuối cùng nó sẽ thiết kế ra một thứ đẹp đẽ. Vì vậy, quá trình này giống như một chuyến tàu lượn siêu tốc và rất đáng sợ, nhưng suy cho cùng, Gemini rất giỏi về thiết kế.
Quy Trình Peer Review Đa Mô Hình
Tôi nghĩ việc sử dụng tất cả các mô hình này và tận dụng thế mạnh của chúng, đồng thời khắc phục điểm yếu bằng cách sử dụng các mô hình khác, là một bước ngoặt lớn đối với tôi. Tôi sẽ thực hiện peer review nhiều lần và để các mô hình khác đánh giá mã của các mô hình khác, về cơ bản là để chúng "đấu với nhau". Đôi khi Claude Code sẽ trở nên khá đanh đá và nói: "Điều này đã được nêu ra lần thứ ba rồi. Và lần thứ ba tôi nói với bạn, đây không phải là vấn đề. Đây là một thiết kế có chủ đích." Vì vậy, đó chỉ là một điều thực sự thú vị mà tôi đã thêm vào và tôi chưa thấy nhiều người làm.
Đó là một cách diễn giải/hiểu đáng kinh ngạc về những gì đang diễn ra. Tuyệt vời. Chúng ta vừa chạy quá trình review. Vậy hãy cho chúng tôi xem những gì chúng ta đã thấy ở đó và hãy thực sự thử peer review này. Tôi thực sự rất hào hứng muốn xem bạn đã học được gì ở đó. Vâng. Về cơ bản, Claude đã review mã của chính nó và tìm thấy một loạt lỗi, một lỗi nghiêm trọng mà nó tìm thấy trong prompt, một số lỗi nghiêm trọng khác, và một số lỗi trung bình. Và bây giờ tôi sẽ làm điều tương tự với các mô hình khác. Codex có chức năng code review tích hợp sẵn mà bạn có thể sử dụng, hoặc tôi chỉ đơn giản là nói "review tất cả mã trong branch này". Tất nhiên, branch ở đây là branch GitHub mà chúng tôi đang làm việc. Chúng tôi không làm việc trên code base trực tiếp. Và sau đó tôi sẽ làm điều này với Composer, giả sử với Composer One. Tôi cũng sẽ thực hiện /review ở đây. Và về cơ bản, cả hai sẽ chạy và thực hiện một review chuyên sâu tương tự như Claude. Nhưng một lần nữa, vì sự khác biệt giữa các mô hình, chúng sẽ phát hiện những điều khác nhau và chúng sẽ nhìn nhận khác nhau, và đây là một cách làm việc thực sự hay. Về cơ bản, nó giống như việc bạn có các team lead khác trong công ty review mã. Ở đây, bạn có thể thấy Composer nhanh như thế nào. Tôi nghĩ GPT có thể sẽ mất khá nhiều thời gian. Như tôi đã nói, nó đang ở trong căn phòng tối của riêng mình để review mã và sẽ quay lại sau vài phút.
Tuyệt vời. Vậy chúng ta có thể để chúng chạy. Chúng ta không thực sự phải trải qua toàn bộ quá trình, nhưng ý tưởng là một khi bạn nhận được kết quả này, bạn chạy peer review và sao chép và dán các kết quả này. Đó có phải là ý tưởng không? Chính xác. Tôi sẽ sao chép và dán kết quả. Tôi sẽ thực hiện peer review và sau đó tôi sẽ nói dev lead một và dán từ một trong các mô hình. Và sau đó tôi sẽ nói dev lead hai và dán từ mô hình khác, và về cơ bản là để chúng "đấu" với nhau cho đến khi tôi cảm thấy không còn vấn đề nào nữa. Thật đáng kinh ngạc. Đối với tôi, điều này cực kỳ quan trọng vì tôi không có nền tảng kỹ thuật và tôi không phải là một nhà phát triển. Và tôi cũng sẽ sử dụng /learning opportunity rất nhiều trong quá trình này để tìm hiểu về những thứ mà tôi không hiểu hoặc không nắm bắt được đầy đủ. Thật đáng kinh ngạc. Một giải pháp thông minh để giải quyết vấn đề code review này, nơi mà tôi không biết gì... Tôi không biết cách viết lại mã, vậy tôi sẽ làm gì đây? Vâng. Vâng. Được rồi. Thật đáng kinh ngạc. Hãy kết thúc quy trình làm việc này. Còn điều gì quan trọng nữa trong quy trình làm việc này không? Và một lần nữa, tất cả những thứ này sẽ có sẵn để mọi người có thể chỉ cần cắm chúng vào tài khoản Cursor của họ và tự sử dụng.
Phân Tích Sai Lầm (Postmortem) và Cải Tiến Liên Tục
100%. Một điều tôi muốn nói là tôi nghĩ, giống như làm việc nói chung với AI và thậm chí chỉ làm việc trên bất kỳ sản phẩm nào, việc thực hiện postmortem liên tục là rất quan trọng. Vì vậy, rất nhiều lần chúng ta sẽ tìm thấy tất cả những loại lỗi này hoặc có thể Claude sẽ không thực hiện đúng một điều gì đó. Và ban đầu khi tôi bắt đầu lập trình theo cảm hứng/trực giác, tôi về cơ bản cứ tiếp tục lao vào nó như đâm đầu vào tường cho đến khi nó hoạt động. Và một khi nó hoạt động, tôi nói: "Được rồi, tuyệt vời. Nó hoạt động rồi. Hãy tiếp tục thôi." Nhưng theo thời gian, tôi đã học được rằng cập nhật tài liệu và tooling là một trong những cách hiệu quả nhất để tăng năng suất.
Vì vậy, khi Claude không làm được điều gì đó hoặc tôi thấy một lỗi rất tệ cho thấy Claude thực sự không hiểu điều gì đó, tôi sẽ hỏi nó: "Điều gì trong system prompt hoặc tooling của bạn đã khiến bạn mắc lỗi này?" Và Claude sẽ tự xem xét nội tâm và suy nghĩ về điều gì đã khiến nó tạo ra lỗi đó. Và sau đó tôi sẽ nói: "Được rồi, tuyệt vời. Hãy cập nhật tooling và tài liệu của bạn để lỗi này không bao giờ xảy ra nữa." Và tôi làm điều này mỗi khi tôi xây dựng một internal tool hoặc bất cứ điều gì. Và tôi nghĩ điều này cũng giống như làm việc vậy. Nếu bạn mắc nhiều lỗi và sau đó phát hành tính năng cho người dùng, bạn sẽ nói: "Được rồi, đó là một thành công lớn." Nhưng việc quay lại và ngay cả khi bạn đã thành công, việc xem xét và hiểu những gì bạn đã làm và những gì bạn có thể làm tốt hơn là rất quan trọng. Và cũng khi sử dụng AI, đây có lẽ là một trong những yếu tố giải phóng lớn nhất. Quay lại câu lệnh/lời nhắc của bạn, hiểu những gì chưa đủ tốt, lặp lại chúng và sau đó xem cách phản hồi của AI trở nên tốt hơn, tôi nghĩ đó có lẽ là một trong những điều quan trọng nhất và là một trong những điều phân biệt giữa những người ổn với việc sử dụng AI và những người thực sự biết cách sử dụng nó.
Đó là một lời khuyên rất hay. Vậy điều tôi đang nghe là khi các mô hình làm điều gì đó ngớ ngẩn, mắc lỗi, bạn yêu cầu nó tự suy ngẫm về lỗi mà nó đã mắc phải, và sau đó bạn cập nhật các prompt của lệnh /command với kiến thức đó để trong tương lai, nó sẽ không mắc cùng lỗi đó nữa, và nó cứ thế ngày càng tốt hơn. Chính xác. Những thứ này cứ ngày càng thông minh hơn. Vì vậy, bạn đang xây dựng một câu lệnh/lời nhắc thực sự đáng kinh ngạc và cứ ngày càng tốt hơn. Chính xác. Không phải lúc nào cũng là các lệnh /command. Đôi khi nó sẽ cập nhật tài liệu khác hoặc tooling của nó, nhưng về cơ bản, đó là việc hiểu nguyên nhân gốc rễ của lỗi mà AI đã mắc phải và sửa chữa nó. Tuyệt vời. Vì vậy, các mô hình ngày càng thông minh hơn và sau đó các phần khác trong quy trình làm việc của bạn cũng có thể trở nên thông minh hơn khi bạn tìm thấy những sai sót trong cách nó thực hiện công việc. 100%. Vâng. Tuyệt vời. Được rồi. Còn điều gì khác không trước khi tôi chuyển sang một vài hướng khác? Tôi nghĩ vậy là đủ rồi. Tôi nghĩ chúng ta đã đề cập khá nhiều mọi thứ. Về cơ bản, để tóm tắt lại, những gì tôi làm là tôi thực hiện rất nhiều code review và sau đó cập nhật tài liệu để mọi thứ được ghi lại. Vì vậy, lần tới khi tôi cố gắng xây dựng một tính năng trong lĩnh vực này, sẽ không có lỗi nào xảy ra. Và sau đó tôi sẽ thực hiện rất nhiều thử nghiệm. Tôi cũng sẽ thực hiện một số user testing trước khi phát hành tính năng này rộng rãi. Rõ ràng chúng ta sẽ không phát hành cái này. Đây chỉ là một buổi trình diễn, nhưng hy vọng có lẽ vào thời điểm podcast ra mắt, tôi sẽ làm điều này một cách chính xác và phát hành tính năng.
AI Mở Ra Cơ Hội Cho Các Nhà Phát Triển Không Có Nền Tảng Kỹ Thuật
Thật khó tin rằng điều này đã không thể thực hiện được cách đây, tôi không biết, hai năm trước, có lẽ một năm trước. Bạn là một product manager đang triển khai một sản phẩm mà không biết viết mã, hầu như không biết review mã. Bạn nói rằng bạn sợ nhìn vào mã. Là một product manager, bạn đang xây dựng một sản phẩm trong Cursor bằng cách sử dụng tất cả các công cụ AI khác nhau này. Bạn đang kiếm tiền từ sản phẩm này. Chúng ta đã quá quen với điều này bây giờ, nhưng thật điên rồ những gì hiện tại có thể thực hiện được. Đây là thời điểm tốt nhất để sống. 100%. Tôi nghĩ rằng tôi hiểu nỗi sợ hãi, nhưng AI chỉ làm cho mọi thứ trở nên khả thi hơn rất nhiều. Chỉ một ghi chú nhanh ở đây, anh trai tôi, người mà tôi đang xây dựng một trong những ứng dụng cùng, là một doanh nhân. Anh ấy có một doanh nghiệp tuyệt vời giúp người già và người cao tuổi hiểu cách sử dụng công nghệ và AI tốt hơn. Và anh ấy về cơ bản đang học hỏi giống như tôi, và anh ấy đã thay thế tất cả các tool mà anh ấy đã trả tiền. Tôi nghĩ anh ấy đã trả tiền cho Zapier và Airtable, và anh ấy về cơ bản đã xây dựng một hệ thống CRM và hệ thống tự động hóa hoàn chỉnh cho doanh nghiệp của mình hoàn toàn một mình. Vì vậy, đối với những người tò mò, lạc quan, chăm chỉ, đây là thời điểm tốt nhất để trở thành một người sáng tạo.
Và điều tôi yêu thích về cuộc trò chuyện chúng ta đang có ở đây là có cảm giác như rào cản lớn nhất đối với rất nhiều người là: làm thế nào để tôi bắt đầu? Tôi phải làm gì chính xác? Tôi mở Cursor ra. Nó trông rất đáng sợ. Tôi không biết viết mã. Tôi không biết xây dựng thứ gì đó. Tôi không biết về database. Và vì vậy, bạn sẽ chia sẻ tất cả các lệnh /command này và về cơ bản là toàn bộ quy trình làm việc này với khán giả. Vâng. Được rồi. Và như tôi đã nói, chỉ cần bắt đầu với GPT. Bắt đầu với GPT, nói cho nó biết ý tưởng của bạn là gì, yêu cầu nó giải thích cho bạn những bước đầu tiên của việc suy nghĩ, những quyết định bạn cần đưa ra là gì? Và chỉ cần tò mò, học hỏi. Đừng vội vàng.
Tích hợp AI vào quy trình làm việc tại các công ty lớn
Điều rất quan trọng là phải dấn thân và thực sự dành thời gian để học hỏi. Bạn cũng chia sẻ điều này. Một trong những câu lệnh của bạn là learning opportunity (cơ hội học hỏi), và đó là cách bạn học hỏi rất nhiều điều. Chỉ cần dạy tôi điều này và cách vấn đề cơ sở dữ liệu này hoạt động. Đúng vậy.
Có một vài khía cạnh tôi muốn đảm bảo chúng ta sẽ đề cập. Một là quay trở lại câu hỏi tôi đã hỏi trước đó về cách điều này có thể hoạt động ở một công ty lớn hơn. Giả sử không phải là Meta, mà chỉ là một công ty khoảng một nghìn người, 500 người. Bạn có thể tích hợp bao nhiêu phần trăm trong số này vào quy trình làm việc của một PM (Quản lý sản phẩm) tại một công ty lớn hơn? Lời khuyên của bạn dành cho người muốn bắt đầu thử nghiệm việc viết mã, ít nhất là cho mọi người thấy những gì có thể làm được, là gì?
Tôi nghĩ rằng việc biến cơ sở mã của bạn thành AI native là một bước thực sự quan trọng, và tôi nghĩ điều này cần được thực hiện bởi những người có technical background. Về cơ bản, cơ sở mã của tôi chứa rất nhiều văn bản thuần túy. Nó sẽ có một loạt các tệp Markdown giải thích cho các agent cách hoạt động trong các khu vực nhất định của cơ sở mã và cấu trúc cấp cao để các agent điều hướng cơ sở mã dễ dàng hơn.
Và tôi nghĩ rằng nếu điều này được thiết lập một cách thực sự tốt, tôi vẫn không nghĩ các PM nên thực hiện các database chain migration nặng nề hoặc bất kỳ dự án lớn nào. Nhưng các dự án UI (giao diện người dùng) độc lập, đặc biệt là nếu bạn chỉ xây dựng, tạo PR (Pull Request) và gửi cho một nhà phát triển để hoàn thiện cuối cùng. Tôi nghĩ đó chắc chắn là điều có thể. Và tôi nghĩ chúng ta sẽ thấy điều đó rất nhiều trong những năm tới. Về cơ bản, tôi nghĩ mọi người sẽ trở thành một builder (người xây dựng), vì vậy điều đó sẽ thực sự thú vị.
Vai trò của PM trong tương lai AI
Vậy lời khuyên của bạn ở đây là, với tư cách là một PM, có lẽ đừng vội vàng dùng Cursor, bắt đầu xây dựng, thử nghiệm các tính năng để đưa vào sản xuất, đặc biệt là các tính năng phức tạp. Bạn có nghĩ chúng ta sẽ đạt được điều đó không? Bạn có nghĩ rằng trong vài năm nữa, các PM sẽ làm điều này và nó sẽ bớt đáng sợ và điên rồ hơn không?
Nếu có PM. Vâng, tôi nghĩ các chức danh sẽ hợp nhất và các trách nhiệm sẽ hợp nhất và mọi người sẽ chỉ tập trung vào việc xây dựng. Tôi chắc chắn nghĩ rằng các mô hình, context memory window đang lớn hơn, các mô hình đang trở nên thông minh hơn và tôi chắc chắn thấy cách các PM hoặc bất kỳ background nào khác có thể viết code. Hiện tại, tôi sẽ không chờ đợi điều đó. Tôi sẽ sử dụng điều này như một collaborative learning opportunity để làm việc với đội ngũ phát triển của bạn. Điều đó sẽ khó khăn. Rất nhiều nhà phát triển rất, rất hoài nghi về trạng thái hiện tại, và tôi nghĩ rằng bạn sẽ cần rất nhiều nỗ lực "bán hàng" để thuyết phục, nhưng nếu bạn có thể thuyết phục, và tôi nghĩ các nhóm thực sự tin tưởng vào điều này và muốn dành thời gian để cải thiện quy trình làm việc của họ về việc làm thế nào để nhóm của chúng ta trở nên AI native hơn, tôi nghĩ rằng những nhóm này có thể sẽ đi trước vài năm và họ sẽ nhìn lại vài tuần họ đã dành để thiết lập điều này như là khoảng thời gian giá trị nhất mà họ từng bỏ ra.
AI và Sự mai một kỹ năng: Một quan điểm khác
Hãy để tôi hỏi bạn một câu hỏi khác liên quan đến công việc của một PM. Một trong những nỗi sợ lớn nhất mà mọi người có với những AI tools này dành cho các PM và mọi chức năng khác mà tôi hình dung, đó là bạn bắt đầu phụ thuộc vào những thứ này, kỹ năng của bạn bắt đầu mai một, bạn tạo ra tất cả những thứ "slop" (chất lượng kém) trông rất tuyệt, một tài liệu chiến lược tuyệt vời. Không, thực ra nó hoàn toàn không tốt chút nào. Liệu đây có phải là những Linear tickets hoặc những sản phẩm dở dang không? Quan điểm của bạn về hai phần này là gì, giống như việc này đã ảnh hưởng đến nghề nghiệp của bạn với tư cách là một PM như thế nào? Bạn có cảm thấy điều này đang làm suy yếu kỹ năng của mình vì bạn quá phụ thuộc vào những tools này không và làm thế nào để bạn duy trì chất lượng của những thứ này và không chỉ là "Ờ, đó chỉ là một đống AI generated slop."
Tôi hoàn toàn không đồng ý với điều này và tôi đã nghe nó rất nhiều lần. Tôi nhớ khi tôi bắt đầu sử dụng, Tal Raviv có toàn bộ khóa học về xây dựng một PM Copilot bằng cách sử dụng các dự án, có lẽ là một trong những khóa học tốt nhất mà bạn có thể tham gia. Và khi tôi bắt đầu làm việc với Copilot của riêng mình, tôi nhớ mọi người ở nơi làm việc nhìn và nói, "Ồ, vậy về cơ bản bạn đang thuê ngoài tư duy của mình." Và đối với tôi, đó là cách tệ nhất để nhìn nhận vấn đề. Và tôi nghĩ vì một lý do nào đó, những người này thường có mối tương quan cao với kiểu người không thích trình bày bài thuyết trình khi nó mới hoàn thành 10% hoặc không muốn nhờ giúp đỡ nhiều. Tôi nghĩ rằng có một sự hiểu lầm với rất nhiều PM rằng công việc là luôn có câu trả lời đúng và là người thông minh nhất trong phòng. Và ít nhất theo cách tôi được đào tạo và cách tôi tin vai trò của PM là, nó hoàn toàn ngược lại.
Về cơ bản, đó là việc tận dụng bất cứ điều gì có thể giúp chúng ta nhanh nhất có thể trong việc cung cấp giải pháp phù hợp cho người dùng. Và tôi chỉ nghĩ đây giống như một người thực sự thông minh có context hoặc mentor của bạn hoặc bất cứ ai, nhưng luôn có mặt và không phán xét bạn và thực sự có thể giúp bạn. Vì vậy, nếu bạn chỉ sử dụng nó để tạo ra agent output của mình rồi đưa chúng ra ngoài, vâng, đó là AI slop, nhưng đó cũng là lỗi của con người. Tôi nghĩ điều thực sự quan trọng là bạn phải chịu trách nhiệm về output của mình. Nếu bạn đưa bất cứ điều gì ra ngoài hoặc thể hiện điều gì đó trong một product review và bạn nói, "Ồ, xin lỗi, cái đó được xây dựng bởi AI." Đó là lỗi của bạn. Tôi nghĩ nếu bạn sử dụng những tools này một cách có chủ đích và thực sự dành thời gian để hiểu cách sử dụng AI đúng cách, thì đó là một trong những yếu tố thay đổi cuộc chơi lớn nhất sẽ khiến bạn trở thành một PM tốt hơn rất nhiều.
AI hỗ trợ PM cấp thấp và kiểm soát chất lượng
Và một điều nữa ở đây là, đặc biệt đối với các PM cấp thấp hơn, nó cho phép bạn chơi ở một cấp độ cao hơn nhiều so với bình thường. Tôi nghĩ rằng ở Wix, tôi không nghĩ về chiến lược marketing của công ty là gì và việc onboarding sẽ được cải tổ hoàn toàn trong toàn bộ sản phẩm như thế nào. Nhưng với sản phẩm phụ của mình, tôi có thể đưa ra bất kỳ quyết định nào tôi muốn và suy nghĩ về chiến lược, marketing và messaging. Và điều này về cơ bản chỉ giúp tôi có được reps (kinh nghiệm lặp lại), một trong những điều quan trọng nhất ở giai đoạn đầu của career path của bạn. Vì vậy, tôi hiểu nỗi sợ rằng làm thế nào bạn lại thuê ngoài một số thứ nhất định và bạn không sở hữu 100% mọi thứ, nhưng tôi nghĩ lợi ích mang lại lớn hơn rất nhiều. Và tôi nghĩ cách duy nhất mà AI khiến bạn làm việc tệ hơn là nếu bạn sử dụng nó sai cách.
Có bất cứ điều gì bạn đã học được về việc giảm thiểu sự cẩu thả của agent output, giống như một mẹo để giữ chất lượng cao của những gì nó tạo ra không?
Tương tự như con người, việc setting up AI for success (thiết lập AI để thành công) cho nhiệm vụ đang thực hiện. Vì vậy, nếu tôi chỉ đưa một người mới vào để viết một tài liệu hoặc thứ gì đó mà không đưa ra bất kỳ hướng dẫn nào, tôi chỉ nói, "Hãy đưa ra một tài liệu chiến lược." Anh ta có lẽ sẽ chỉ lên mạng và tìm kiếm tài liệu chiến lược hàng đầu và tái tạo lại nó, đó về cơ bản là những gì AI đang làm. Nó về cơ bản chỉ được cung cấp tất cả thông tin trên internet. Vì vậy, thay vì vậy, việc hướng dẫn nó và cung cấp context về phong cách viết của bạn và những gì bạn đang cố gắng giải quyết và tất cả những điều khác nhau này, tôi nghĩ đó có lẽ là một trong những unlock lớn nhất. Vì vậy, đó chỉ là một mẹo nhanh. Và Cursor cũng có một command có tên là /deslop, về cơ bản là xem lại mã. Tôi không biết liệu điều này đã được tích hợp vào sản phẩm chưa, nhưng nó có trên Twitter. Những người sáng lập của họ đã nói về điều này, vì vậy đó chắc chắn là điều tôi sẽ theo dõi để đảm bảo không có slop nào bị bỏ lại.
Cái deslop đó thật buồn cười. Được rồi. Một câu hỏi nữa, có thể dẫn đến một điều gì đó khác, nhưng đi theo một hướng hoàn toàn khác. Bạn đã sử dụng AI để giúp bạn phỏng vấn cho công việc bạn có được ở Meta. Hãy nói về cách bạn đã làm điều đó, bởi vì rất nhiều người hiện nay đang gặp khó khăn trong việc tìm việc, đọc về tất cả những người sử dụng AI để giúp họ phỏng vấn. Bạn thực sự đã làm điều đó. Bạn đã sử dụng gì? Điều gì hiệu quả?
Sử dụng AI để chuẩn bị phỏng vấn xin việc
Tôi cảm thấy như phép loại suy ở đây là tôi có 12 cháu gái và cháu trai, và bạn có thể thấy cách những người lớn lên trong một thế giới khác, cách tư duy của họ được hình thành khác biệt. Vì vậy, nếu bạn hỏi tôi, làm thế nào để bạn trả lời điện thoại, tôi sẽ làm thế này. Nhưng một đứa trẻ bây giờ, khi bạn nói, "Làm thế nào để bạn trả lời điện thoại?" Chúng sẽ làm thế này. Chúng sẽ làm theo kiểu trả lời iPhone. Và tôi cảm thấy những người đang lớn lên bây giờ trong cuộc sống chuyên nghiệp của họ cũng tương tự như vậy với AI. Vì vậy, mỗi khi tôi đối mặt với một thách thức hoặc vấn đề mới, tôi đều nghĩ AI first (AI đầu tiên) cách giải quyết nó.
Vì vậy, Meta đã liên hệ và nói rằng họ muốn tôi phỏng vấn. Ngay lập tức, tôi mở một dự án trong Claude. Tôi bắt đầu tìm kiếm trực tuyến tất cả thông tin tốt nhất hiện có, những điều mà tôi cảm thấy phù hợp. Tôi đã lấy rất nhiều framework và tài liệu từ Ben Erez, người đã viết một bài đăng khách cho bạn, người mà tôi nghĩ là một trong những bộ óc xuất sắc nhất hiện nay. Và về cơ bản, tôi đã tạo một dự án hoạt động như coach của tôi, nơi tôi sẽ đến và hỏi ý kiến về việc phải làm gì ở mỗi giai đoạn. Tôi sẽ thực hành phỏng vấn thử với nó, và điều này thật tuyệt vời. Ngoài ra, tôi đã tạo một trò chơi trong Base44, giúp tôi... Tôi thực sự gặp khó khăn với segmentation (phân khúc) trong các câu hỏi sản phẩm, vì vậy việc suy nghĩ về các phân khúc chính xác. Vì vậy, về cơ bản, tôi chỉ tạo một trò chơi đố vui, tạo ra các câu hỏi và các segmentation khác nhau và tôi phải chọn.
Vì vậy, đây là cách tôi đã tạo ra nó. Đó là một ứng dụng web mà đôi khi tôi chơi khi đi xe buýt đến chỗ làm. Vì vậy, về cơ bản, tôi nghĩ Ben nói rất nhiều về điều này, vì vậy tôi không chỉ đọc tài liệu của Ben, mà chỉ cần tạo một dự án và cung cấp cho nó tất cả thông tin tốt nhất trên internet và sau đó thực hành rất nhiều. Tôi phải nói rằng yếu tố thay đổi cuộc chơi lớn nhất đối với tôi là thực hiện các buổi phỏng vấn thử với người thật (human mocks). Vì vậy, việc liên hệ với mọi người trên LinkedIn và nhờ họ thực hiện các buổi phỏng vấn thử thực tế cho tôi, tôi nghĩ rằng cuối cùng, đặc biệt là đối với việc chuẩn bị Meta PM, vốn siêu cạnh tranh và khó khăn, tôi nghĩ không có cách nào để tránh được điều đó.
Thật tuyệt vời khi họ sử dụng bài viết đó. Tôi không biết. Chúng tôi sẽ liên kết đến nó. Và trong bài viết đó, Ben chia sẻ tất cả những prompts mà bạn có thể cung cấp cho ChatGPT để giúp bạn chuẩn bị cho các cuộc phỏng vấn, thực hiện các buổi phỏng vấn thử trực tuyến. Điều quan trọng là phải nói rằng những điều đó sẽ đưa bạn đến một điểm nhất định, nhưng thực tế là sử dụng con người tốt hơn. Tôi thực sự có một bài viết sắp ra mắt hợp tác với Noam Segal về cách mọi người đang sử dụng AI để phỏng vấn. Và một trong những cách thú vị nhất mà tôi từng nghe mọi người nói và chúng tôi đã tìm thấy trong nghiên cứu này là mọi người sử dụng nó để nhận feedback. Họ ghi lại cuộc phỏng vấn và sau đó AI cung cấp feedback cho họ. Đây là nơi bạn có thể làm tốt hơn. Đây là điều bạn đã bỏ lỡ bởi vì feedback loop (vòng lặp phản hồi) đang thiếu sót rất nhiều.
Chuẩn Bị Phỏng Vấn Với AI
Không ai từng nói với bạn, "Đây là những gì bạn đã làm dở trong buổi phỏng vấn này." Không ai nói với bạn điều đó, và AI có thể làm được điều đó.
Tôi sẽ bổ sung hai điều vào đó. Thứ nhất, chính là điều này: Tôi sẽ thực hành phỏng vấn thử với AI. Ngoài ra, tôi đã làm một điều thực sự thú vị là có một ngân hàng câu hỏi trực tuyến, miễn phí, của Louis Lynn, về cơ bản là một ngân hàng câu hỏi luôn được cập nhật mà mọi người được hỏi trong các cuộc phỏng vấn thực tế. Và tôi về cơ bản đã sử dụng Comet, là trình duyệt của Perplexity. Tôi đã nhờ agent thực hiện mọi phân tích về những câu hỏi được hỏi nhiều nhất. Và đó là cách tôi biết cách ưu tiên những câu hỏi nào tôi sẽ thực hành.
Và sau đó, khi kết thúc các buổi thực hành thử này, tôi nói với Claude trong dự án rằng: "Bạn là huấn luyện viên của tôi, và tôi không muốn bạn khiến tôi cảm thấy dễ chịu. Tôi muốn bạn giúp tôi sẵn sàng nhất có thể cho các buổi phỏng vấn này. Vì vậy, hãy cho tôi phản hồi, như bạn đã nói."
Và một điều thú vị khác mà tôi đã làm là với một số câu hỏi tôi không có thời gian để thực hành thử, tôi sẽ yêu cầu Claude đóng vai ứng viên, và sau đó nó sẽ đưa ra một câu trả lời thực sự tốt. Và tôi cũng có thể học hỏi từ đó, giống như học hỏi từ một người đưa ra câu trả lời hoàn hảo.
Tư Duy Thế Hệ Mới: AI Là Mặc Định
Ồ, này. Tôi thực sự thích cách bạn diễn đạt, rằng những người thuộc thế hệ của bạn, mặc định là, "Tôi có việc cần làm. Hãy đến với AI ngay lập tức để giúp tôi chuẩn bị cho việc này, giúp tôi tìm ra giải pháp."
Vâng. Và điều này quay trở lại với câu nói mà tôi luôn suy nghĩ, mà tôi nghĩ mọi người vẫn luôn nghe thấy, nhưng đó là một câu nói rất quan trọng rằng không phải bạn sẽ bị thay thế bởi AI, ít nhất là trong một thời gian dài. Mà là bạn sẽ bị thay thế bởi một người giỏi hơn bạn trong việc sử dụng AI.
Tôi đồng ý. Và đây là lý do của những cuộc trò chuyện này, để giúp mọi người theo kịp tất cả những điều đó và học hỏi một số kỹ năng này. Và một lần nữa, hãy xem tương lai đang đi về đâu và bắt đầu học cách tự mình đến đó.
Góc Thất Bại: Bài Học Từ Wix
Được rồi, Zevi, trước khi chúng ta đến với vòng hỏi nhanh đáp gọn đầy thú vị của mình, tôi sẽ đưa chúng ta đến một chuyên mục định kỳ trên podcast này mà tôi gọi là Failure Corner (Góc Thất Bại). Và lý do tôi yêu thích chuyên mục này là mọi người khi tham gia, ngay cả trong cuộc trò chuyện này, đều nói về tất cả những điều tuyệt vời mà họ đã khám phá, mọi thứ đều diễn ra rất tốt. Mọi người hiếm khi nghe về những điều không suôn sẻ, và đó thường là những câu chuyện thú vị và có tác động lớn nhất. Vì vậy, câu hỏi đơn giản là, đâu là câu chuyện về một lần bạn thất bại trong lộ trình sự nghiệp của mình và bạn đã học được gì từ trải nghiệm đó?
Vâng, tôi thích điều này. Tôi thích điều này. Tôi là một fan lớn của Failure Corner. Vậy tôi sẽ kể một câu chuyện về thời điểm tôi bắt đầu làm việc tại Wix. Về cơ bản, tôi bắt đầu làm việc tại Wix với tư cách là một thành viên của chương trình sinh viên, và ngay sau khi kết thúc chương trình, bạn sẽ được đưa vào một đội nhất định. Vì vậy, tôi đã làm việc trong bộ phận biên tập, vốn là sản phẩm cốt lõi của Wix. Và các PM (Quản lý sản phẩm) khác chỉ là những PM giỏi nhất tại Wix. Có bốn người khác có kinh nghiệm hơn tôi rất nhiều và họ thực sự giỏi. Và tôi nhớ mình đã đến đó và nghĩ rằng, "Buổi đánh giá sản phẩm đầu tiên của mình, mình sẽ khiến mọi người kinh ngạc. Họ sẽ không tin được mình là một PM giỏi đến mức nào." Và về cơ bản, tôi đã không thực sự chia sẻ những gì mình đang nghĩ. Tôi đã làm việc hàng tấn giờ một mình và tôi nghĩ, "Mình sẽ làm tốt buổi đánh giá sản phẩm này. Họ sẽ rất ấn tượng." Và cuối cùng tôi đã thất bại thảm hại. Buổi đánh giá sản phẩm của tôi không tốt. Nó không đúng định dạng mà họ mong đợi. Họ có rất nhiều câu hỏi mà tôi đã bỏ lỡ, và tôi cảm thấy kinh khủng khi nó kết thúc. Tôi nghĩ, "À, mình đúng là một kẻ ngốc." Và tôi thấy mọi người đều nói, "Được rồi, tốt thôi. Vâng, cứ quay lại sau hai tuần và chúng ta sẽ tiếp tục làm việc này." Và tôi hiểu ngay lúc đó rằng họ không hề mong đợi tôi sẽ là một PM 10X, nhưng điều họ mong đợi ở tôi là một người học hỏi 10X.
Và ngay khi tôi hiểu điều đó, toàn bộ tư duy của tôi đã thay đổi. Và tôi nghĩ đây có lẽ là lời khuyên tốt nhất mà tôi dành cho các PM cấp dưới hiện nay là, về cơ bản, hãy là người học hỏi tốt nhất mà bạn có thể trở thành ở giai đoạn đầu. Không ai mong đợi bạn biết tất cả các câu trả lời và không ai mong đợi bạn đã giỏi. Vì vậy, về cơ bản, những gì tôi đã làm là tôi tiếp cận từng người trong nhóm PM – có bốn PM khác – và tôi đánh giá điểm mạnh của họ và sử dụng họ làm người cố vấn cho lĩnh vực đó.
Vậy là Neri, người vẫn là cố vấn của tôi cho đến ngày nay, anh ấy có product sense (cảm nhận sản phẩm) tốt nhất trong số những người tôi từng gặp. Oya thì siêu việt, cô ấy giống như một chuyên gia về phương pháp luận. Cô ấy chỉ suy nghĩ theo các framework (khuôn khổ). Yahra, người đứng đầu sản phẩm, về cơ bản có thể nhìn vào một sản phẩm và ngay lập tức hiểu được các hiệu ứng cấp độ ba và bốn của chúng, tức là system thinking (tư duy hệ thống). Vì vậy, mỗi khi tôi có vấn đề với một trong những lĩnh vực này, tôi sẽ đến gặp một trong số họ và hỏi ý kiến, và điều này mang lại hai lợi ích. Thứ nhất, tôi học được rất nhiều. Và thứ hai là khi đến lần tiếp theo, buổi đánh giá sản phẩm tiếp theo, thành công của tôi đối với họ giống như thành công của chính họ, bởi vì tôi không phải là một đứa trẻ đang cố gắng thể hiện mình ngầu như thế nào. Mà giống như là học trò của họ khiến tất cả chúng tôi tự hào. Và đó là một sự thay đổi lớn đối với tôi. Và về cơ bản, cuối cùng, tôi đã thực sự xuất sắc nhờ điều này.
AI: Đối Tác Học Hỏi Và Cơ Hội Cho Người Mới
Đó là một câu chuyện tuyệt vời. Và ý tưởng về việc học hỏi là một sợi dây xuyên suốt cuộc trò chuyện này, rằng AI giỏi trong việc hoàn thành công việc, nhưng nó cũng thực sự giỏi trong việc giúp bạn học cách làm điều đó và trở thành đối tác, đối tác tư duy này, cái cách bạn nói về quá trình phỏng vấn bạn đã trải qua và cơ hội/lệnh học hỏi này. Thật tuyệt vời. Câu chuyện tuyệt vời.
Zevi, được rồi. Trước khi chúng ta đến với vòng hỏi nhanh đáp gọn đầy thú vị, bạn có muốn chia sẻ điều gì khác không? Có điều gì bạn muốn gửi gắm đến người nghe không?
Vâng. Vậy thì, để quay lại điều đầu tiên tôi nói, nếu mọi người rời đi với suy nghĩ, "Zevi thật tuyệt," thì tôi đã thất bại ở đây. Tôi nghĩ rằng, tôi nghĩ, đây là thời điểm tốt nhất để sống. Đây là thời điểm tốt nhất để trở thành một người mới vào nghề, trái ngược với những gì nhiều người đang nói rằng không còn các vị trí cấp dưới nữa và mọi người ra trường không thể tìm được việc làm. Vâng, điều đó đúng. Nhưng cũng vậy, trong lịch sử, còn khi nào khác bạn có thể ra trường và tự mình xây dựng một công ty khởi nghiệp với vài người bạn mà hoàn toàn bootstrapped (tự thân vận động) chứ? Và tôi thấy ngày càng nhiều người vào cuối thời gian làm việc tại Wix, tôi đã phỏng vấn, và tôi thấy ngày càng nhiều người tự mình xây dựng sản phẩm với AI. Và tôi nghĩ trái ngược với những gì nhiều người nghĩ, đây là thời điểm tốt nhất để trở thành một người mới vào nghề. Đây là thời điểm tốt nhất để trở thành một người học hỏi. Và tôi nghĩ nếu bất kỳ thính giả nào đang nghe điều này và bạn là một người tò mò, bạn là một người chăm chỉ, tôi muốn nói là tử tế – tôi không chắc – nhưng nếu bạn là một người tử tế và một người giao tiếp tốt, bạn có một lợi thế không công bằng và bạn có thể mang lại nhiều giá trị cho các công ty hơn hầu hết những người có 20 năm kinh nghiệm. Vì vậy, tôi thực sự hy vọng mọi người sẽ được truyền cảm hứng từ điều này và bắt đầu thành công rực rỡ với các dự án của mình.
Thật tuyệt vời. Có rất nhiều cách để được truyền cảm hứng từ cuộc trò chuyện này.
Vòng Hỏi Nhanh Đáp Gọn
Zevi, với điều đó, chúng ta đã đến vòng hỏi nhanh đáp gọn đầy thú vị của mình. Tôi có năm câu hỏi dành cho bạn. Bạn đã sẵn sàng chưa?
Vâng, chúng ta bắt đầu thôi.
Sách Yêu Thích
Hai hoặc ba cuốn sách nào mà bạn thấy mình thường xuyên giới thiệu cho người khác nhất?
Vậy tôi sẽ chọn một cuốn từ mỗi thể loại. Trong tiểu thuyết, tôi yêu thích The Fountainhead của Ayn Rand, một trong những cuốn sách yêu thích của tôi. Nó thực sự khiến bạn suy nghĩ, thực sự khiến bạn cảm nhận. Về sách kinh doanh, tôi là một fan lớn của Shoe Dog, câu chuyện về Nike, một trong những cuốn sách yêu thích của tôi. (Người phỏng vấn: Tôi vừa đọc xong cuốn đó. Thật thú vị. Thật tuyệt vời. Nó rất hay.) Vâng. Tôi yêu Shoe Dog. Và sau đó, về khía cạnh tâm lý học, Mindset của Carol Dweck, người đã đặt ra thuật ngữ growth mindset (tư duy phát triển). Đó thực sự là một cuốn sách tuyệt vời. Nó nghe có vẻ như một cuốn sách tự lực, nhưng sau đó bạn hiểu rằng nó hoàn toàn mang tính tâm lý và dựa trên nghiên cứu, và cuốn sách đó đã thay đổi hoàn toàn cuộc đời tôi. Thực sự, tôi luôn có một fixed mindset (tư duy cố định), và sau khi đọc cuốn đó, tôi đã hiểu rằng đó là điều đang kìm hãm tôi. Và từ đó, tôi đã thực sự, thực sự cố gắng vun đắp một growth mindset. Vì vậy, tôi thực sự khuyên mọi người nên đọc cuốn đó.
Một lần nữa, điều này kết nối với mạch tư duy bạn đã mô tả, là một người học hỏi 10X thay vì một người làm việc 10X.
Phim / Chương Trình TV Gần Đây
Được rồi. Câu hỏi tiếp theo. Bộ phim hoặc chương trình TV gần đây nào bạn yêu thích và thực sự đã thưởng thức?
Vâng, thực ra vợ tôi rất thích phim, nên chúng tôi xem TV rất nhiều. Đó có lẽ là khoảng thời gian yêu thích của chúng tôi khi ở bên nhau. Tôi vừa xem xong The Pitt, rất tuyệt vời. Nó thực sự hay. Và lời khuyên đầu tiên của tôi cho mọi người là nếu bạn chưa xem Severance, hãy chạy đi xem Severance, một trong những chương trình yêu thích của tôi.
Sản Phẩm Yêu Thích
Có sản phẩm yêu thích nào mà bạn mới khám phá gần đây mà bạn thực sự yêu thích không?
Đây là một câu hỏi hay. Tôi luôn thử các sản phẩm mới. Tôi sẽ luôn cài đặt ba hoặc bốn trình duyệt trên máy tính của mình và đủ thứ khác, và gần đây tôi đã khám phá ra một giải pháp thay thế cho Loom. Tôi hơi thất vọng với Loom. Họ tính quá nhiều tiền và sản phẩm thì, tôi không biết, tôi chỉ không thích nó. Và có một giải pháp thay thế mã nguồn mở tên là Cap, nó thực sự được chế tác rất tốt. Bạn có thể thấy rằng người tạo ra nó thực sự tỉ mỉ đến từng chi tiết, và đó thực sự là một lựa chọn thay thế rất tuyệt vời. Vì vậy, tôi đã sử dụng nó gần đây.
Cũng có một sản phẩm tên là Supercut mà tôi yêu thích, đó cũng là một giải pháp thay thế cho Loom. Xin được giới thiệu.
Châm Ngôn Sống
Được rồi. 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. Hiện tại tôi đang có hai cái. Một cái, về cơ bản đã trở thành một meme trên Twitter, đó là "bạn có thể làm mọi thứ." Tôi cảm thấy điều đó về cơ bản luôn văng vẳng trong đầu tôi mỗi khi tôi làm điều gì đó mà tôi ngạc nhiên về tốc độ và khả năng thực hiện mọi thứ hiện nay. Vì vậy, "bạn có thể làm mọi thứ." Và cái thứ hai tôi đã "đánh cắp" từ anh trai tôi. Châm ngôn của anh ấy là "không ai biết cái quái gì mình đang làm cả." Và tôi chỉ đơn giản là yêu thích điều đó. Và tôi nghĩ nó phần nào khiến bạn nhìn cuộc sống nhẹ nhàng hơn. Vì vậy, vâng, "không ai biết mình đang làm cái quái gì cả."
Tôi nghĩ mọi người nhìn các công ty này từ bên ngoài và cảm thấy như họ đã giải quyết được mọi thứ. Và nếu bạn từng ở bên trong một công ty đang hoạt động rất tốt, bạn sẽ nghĩ, "làm thế nào mà điều này vẫn còn đi đúng hướng? Làm thế nào mà điều này vẫn đang hoạt động? Chẳng có lý do gì cả. Mọi thứ sắp đổ vỡ rồi."
Vâng. Được rồi. Câu hỏi cuối cùng. Bạn đã có một con đường khởi nghiệp dài xuyên suốt lộ trình sự nghiệp của mình. Có một vài doanh nghiệp thực tế khác mà bạn đã khởi nghiệp trong quá khứ.
Hành trình khởi nghiệp sớm: Bài học từ kinh doanh quần áo giữ nhiệt
Bạn đã từng kinh doanh quần áo giữ nhiệt, sau đó là dịch vụ giao hummus. Vậy hãy chọn một trong số đó và kể câu chuyện về nó.
Vâng, tôi rất sẵn lòng. Thật thú vị khi bạn hỏi về điều này. Tôi sẽ kể về câu chuyện kinh doanh quần áo giữ nhiệt, vì tôi nghĩ nó khá hay. Khi còn học trung học, tôi bán quần áo giữ nhiệt vào năm lớp 10 cho một người bạn của chị gái tôi, và về cơ bản, đó chỉ là những gói quần áo giữ nhiệt, gồm áo và quần. Tôi lớn lên ở Jerusalem, nơi đó khá lạnh. Vì vậy, sản phẩm này rất phù hợp với thời tiết. Vào năm lớp 10, khi tôi bán chúng, giá khoảng 20-25 đô la một bộ và tôi kiếm được khoảng 4 đô la cho mỗi lần bán. Nếu nhìn vào chuỗi cung ứng, tôi là người ở vị trí thứ sáu hoặc thứ bảy. Biên độ lợi nhuận này thật điên rồ. Vì vậy, trong mùa hè, tôi nghĩ rằng mình nên đến thẳng nhà nhập khẩu. Suốt mùa hè, tôi gọi cho nhà nhập khẩu và ban đầu, ông ấy thực sự rất tức giận. Ông nói, "Không, cậu phải làm việc cho tôi nhiều năm mới đạt được cấp độ này." Và tôi nói, "Nghe này, chú, cháu sắp tốt nghiệp rồi. Đây sẽ không phải là lộ trình sự nghiệp của cháu. Chú làm hay không tùy chú." Và về cơ bản, chúng tôi đã đàm phán suốt cả mùa hè. Đây cũng là cách tôi làm mọi việc trước khi có ChatGPT. Ông ấy sẽ đưa ra một lý do nào đó, ví dụ, ông nói, "Ôi, thuế nhập khẩu đã tăng." Và tôi chỉ cần tìm kiếm trên Google, như "Thuế nhập khẩu Israel" và bắt đầu đọc. Tôi sẽ nói chuyện điện thoại với ông ấy và kiểu như, "Này, tôi sẽ cố gắng câu giờ." Và sau đó tôi sẽ đưa ra một thách thức nào đó. Cuối cùng, tôi đã có được một mức giá thực sự tốt, khoảng 12,50 đô la một bộ. Vì vậy, tôi đã kiếm được 100% lợi nhuận và mở rộng ra một loạt các trường học khác nhau. Ở mỗi trường, tôi có những người "cool" nhất trường bán hàng cho mình. Và sau đó, một điều thực sự thú vị mà tôi đã làm là chúng tôi có một đội bóng rổ rất tuyệt vời và đội bóng rổ của chúng tôi thường dẫn trước 30 điểm trong hiệp một, điều này khiến khán giả khá nhàm chán. Vì vậy, tôi đã viết một bài hát, một điệu hô cổ vũ bóng rổ về Quần Áo Giữ Nhiệt, trong đó có số điện thoại của tôi. Và đoạn cuối là "Nếu bạn tham gia ngay bây giờ, chúng tôi sẽ giảm giá cho bạn." Và nó có cả trống và mọi thứ. Ngay cả bây giờ khi tôi đến Jerusalem, tôi biết một số người thậm chí còn không biết số điện thoại của mình theo số, nhưng họ biết nó theo giai điệu. Và đôi khi khi tôi đi bộ ở Jerusalem, mọi người dừng tôi lại và nói, "Này, đó là Thermal Zevi." Đó thực sự là một trải nghiệm rất tuyệt vời khi còn nhỏ.
Lời kết và Kêu gọi hành động
Điều này giải thích rất nhiều về sự thiên tài trong marketing của bước đi đó. Tuyệt vời. Zevi, điều này thật đáng kinh ngạc. Hai câu hỏi cuối cùng: Mọi người có thể tìm bạn ở đâu nếu họ muốn liên hệ và theo dõi một số nội dung này? Chúng tôi sẽ đính kèm liên kết đến các script và câu lệnh/lời nhắc (prompt) trong phần ghi chú của chương trình để bạn không cần phải đọc chúng. Và sau đó, thính giả có thể giúp ích gì cho bạn?
Tuyệt vời. Tôi đã nhận được rất nhiều sự giúp đỡ trong suốt lộ trình sự nghiệp của mình, vì vậy tôi rất thích giúp đỡ bất cứ ai tôi có thể. Vậy hãy liên hệ với tôi qua LinkedIn hoặc X. Tôi thực sự rất muốn giúp đỡ bất cứ ai tôi có thể. Thính giả có thể giúp ích gì cho tôi? Nếu bạn là sinh viên, hãy thử StudyMate, cho tôi biết suy nghĩ của bạn. Nếu bạn ở Israel và chưa sử dụng tính năng đọc chính tả, hãy thử Dibur2text. Cho tôi biết suy nghĩ của bạn.
Tuyệt vời. Tôi rất thích cách bạn chia sẻ rất nhiều và điều đó sẽ hữu ích cho rất nhiều người. Vì vậy, một lần nữa, chúng tôi sẽ liên kết đến những nội dung đó trong phần ghi chú của chương trình. Zevi, bạn thật tuyệt vời. Cảm ơn bạn rất nhiều vì đã có mặt ở đây. Cảm ơn bạn rất nhiều vì đã chia sẻ. Tôi nghĩ điều này sẽ giúp rất nhiều người và tôi nghĩ nó sẽ giúp mọi người vượt qua rào cản tâm lý rằng, "Được rồi, tôi thấy tất cả những người này đang làm những điều thú vị. Đây là cách tôi thực sự có thể làm được những điều này." Vì vậy, cảm ơn bạn rất nhiều vì đã có mặt ở đây và vì đã chia sẻ rất nhiều.
Cảm ơn bạn đã mời tôi. Và nếu bạn xây dựng được điều gì đó thú vị với những gì tôi đã chia sẻ ở đây, hãy liên hệ với tôi, gửi cho tôi. Tôi rất muốn xem. Tuyệt vời. Zevi, cảm ơn bạn rất nhiều vì đã có mặt ở đây. Cảm ơn. Tạm biệt mọi người. Cảm ơn quý vị đã lắng nghe. Nếu bạn thấy nội dung này hữu ích, bạn có thể đăng ký theo dõi chương trình trên Apple Podcast, 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 nhận xét vì điều đó thực sự giúp những người nghe 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 lennyspodcast.com. Hẹn gặp lại trong tập tiếp theo.