The rise of the professional vibe coder (a new AI-era job)

• "Vibe coding" là một vai trò mới nổi, linh hoạt, tập trung vào việc tận dụng AI để nhanh chóng hiện thực hóa và triển khai các ý tưởng sản phẩm, thường do những người không có nền tảng kỹ thuật đảm nhiệm.
• Thành công với AI không nằm ở khả năng viết mã mà ở sự rõ ràng và cụ thể của người dùng khi đưa ra yêu cầu, coi AI như một "đồng sáng lập kỹ thuật" cần được hướng dẫn rõ ràng.
• Tư duy cởi mở, "lạc quan một cách ảo tưởng" và dành phần lớn thời gian cho việc lập kế hoạch, trò chuyện với AI (80%) trước khi thực thi (20%) là những chiến lược cốt lõi để vượt qua các giới hạn của AI và đạt được kết quả chất lượng.

• Vibe coding là một lộ trình sự nghiệp mới: Có thể tự thuê mình làm "vibe coder" chuyên nghiệp bằng cách "building in public" hoặc tìm kiếm các vai trò linh hoạt trong các công ty để nhanh chóng hiện thực hóa ý tưởng.
• Độ rõ ràng là yếu tố then chốt: Khi yêu cầu AI, hãy cực kỳ cụ thể để tránh những kết quả không mong muốn hoặc vô dụng, giống như việc Aladdin ước được cao hơn mà không rõ ràng về chiều cao mong muốn.
• Không có nền tảng kỹ thuật có thể là lợi thế: Tư duy không định kiến và sự lạc quan giúp khám phá những khả năng mới của AI mà những người có kinh nghiệm kỹ thuật có thể cho là bất khả thi.
• Tối ưu hóa thời gian cho việc lập kế hoạch và trò chuyện: Dành 80% thời gian để lên kế hoạch chi tiết và tinh chỉnh các câu lệnh (prompt) với AI, chỉ 20% cho việc thực thi, để đảm bảo đạt được "tốc độ đúng" và chất lượng đầu ra.
• Coi AI như đồng sáng lập kỹ thuật và nhà giáo dục: Học hỏi trong quá trình xây dựng, đọc kỹ "agent output" (lời giải thích của AI) thay vì chỉ chăm chú vào "code output" (mã code), để hiểu sâu hơn và hướng dẫn AI tốt hơn.
• Hiểu các giới hạn của AI: Nhận thức về "context memory window" (giới hạn token) của LLM và luôn ghi nhớ rằng AI chỉ là công cụ cần sự hướng dẫn rõ ràng của con người.
• Tập trung vào các kỹ năng con người: Tối ưu hóa các kỹ năng như "good judgment" (đánh giá tốt), "clarity" (sự rõ ràng), "quality" (chất lượng) và "taste" (thẩm mỹ) vì AI là bộ khuếch đại cho những kỹ năng này.
• Đừng ngại thử những điều tưởng chừng không thể: Với AI, nhiều ý tưởng ban đầu được cho là bất khả thi (như xây dựng tiện ích mở rộng Chrome hay ứng dụng desktop) đã có thể được hiện thực hóa.

• vibe coding — lập trình theo cảm hứng/trực giác
• building in public — xây dựng công khai (minh bạch các bước phát triển sản phẩm/dự án)
• ask of the AI — yêu cầu AI
• clarity — sự rõ ràng
• career path — lộ trình sự nghiệp
• technical background — nền tảng kỹ thuật
• prompt — câu lệnh/lời nhắc (dành cho AI)
• AI tools — công cụ AI
• agent output — đầu ra của tác nhân (AI, thường là giải thích, kế hoạch)
• context memory window — cửa sổ bộ nhớ ngữ cảnh (giới hạn thông tin AI có thể xử lý cùng lúc)

Giới thiệu về Vibe Coding và Tầm quan trọng của Sự Rõ ràng với AI

Tôi là kỹ sư vibe coding chính thức đầu tiên tại Lovable. Bạn đang ở cấp độ tinh hoa 0.1% của vibe coding. Đó là một công việc mơ ước đối với rất nhiều người. Công việc này trở thành hiện thực bằng cách building in public. Bạn không cần một công ty thuê bạn. Bạn có thể tự thuê mình làm một vibe coder chuyên nghiệp trước tiên. Bạn chưa từng lập trình, bạn không muốn xem code. Lập trình sẽ giống như thư pháp. Mọi người sẽ nói, "Ôi Chúa ơi, bạn đã viết đoạn code đó. Thật tuyệt vời. Nó sẽ hiếm đến mức trở thành một nghệ thuật." Các biểu đồ Venn của engineer, designer, PM (quản lý sản phẩm) từng rất riêng biệt, giờ đây chúng đang hội tụ. AI, bất kể nền tảng của bạn, là một bộ khuếch đại. Nếu bạn không biết mình đang làm gì, bạn sẽ chỉ tạo ra rác nhanh hơn.

Có vẻ như một kỹ năng cốt lõi mới nổi là học cách diễn đạt rõ ràng khi ask of the AI (yêu cầu AI). Tôi thích sử dụng phép ẩn dụ về Aladdin và thần đèn. Bạn xoa cây đèn, một thần đèn xuất hiện. Tôi sẽ ban cho bạn ba điều ước. Điều ước đầu tiên là tôi muốn cao hơn. Thần đèn biến tôi cao 13 mét vì tôi không cụ thể. Này, tôi không hiểu. Bạn muốn nói gì khi bạn nói "bạn biết ý tôi không"? Vì vậy, bạn cần phải cụ thể. Tôi đang tối ưu hóa 100% thời gian của mình hôm nay vào good judgment, clarity, quality, taste.

Lazar Jovanovic – Vibe Coder Chuyên nghiệp

Hôm nay, khách mời của tôi là Lazar Jovanovic. Lazar là một vibe coder chuyên nghiệp. Anh ấy được trả lương để vibe code cả ngày và xây dựng internal and external products. Cuộc trò chuyện này sẽ làm bạn ngạc nhiên theo nhiều cách. Đây không chỉ là một career path mới thực sự thú vị để mọi người xem xét. Nếu bạn lắng nghe những gì Lazar chia sẻ, đó cũng là một cái nhìn quan trọng về nơi mà các vai trò tech đang hướng tới. Tôi thấy mình suy nghĩ sâu sắc hơn về tương lai của product management, engineering và design trong cuộc trò chuyện này hơn bất kỳ lúc nào trong một thời gian dài. Chúng tôi cũng dành nhiều thời gian cho lời khuyên tốt nhất của Lazar với tư cách là một elite vibe coder để tận dụng tối đa AI tools. Anh ấy có một loạt frameworks thực sự thú vị và hữu ích mà tôi chưa từng nghe ai khác chia sẻ, điều này sẽ ngay lập tức nâng cao thành công của bạn khi sử dụng tất cả các AI tools mới nhất.

Giới thiệu Nhà Tài trợ

Stella: Nền tảng Nghiên cứu Khách hàng dành cho Kỷ nguyên AI

Tập này được tài trợ bởi Stella, customer research platform được xây dựng cho AI era. Sự thật về user research là: nó chưa bao giờ quan trọng hơn hoặc gây khó khăn hơn. Các nhóm muốn hiểu tại sao khách hàng làm những gì họ làm. Nhưng việc recruiting users, running interviews và analyzing insights mất hàng tuần. Khi kết quả có được, thời điểm để hành động đã qua. Stella thay đổi điều đó. Đây là nền tảng đầu tiên sử dụng AI để tự động thực hiện và phân tích các cuộc phỏng vấn chuyên sâu, mang lại nghiên cứu người dùng nhanh chóng và liên tục cho mọi nhóm. AI moderator của Stella đặt các câu hỏi tiếp theo thực tế, tìm hiểu sâu hơn khi câu trả lời mơ hồ và nhận diện các mẫu trong hàng trăm cuộc trò chuyện chỉ trong vài giờ, không phải vài tuần. Các nhóm product design và research tại các công ty như Amazon và Duolingo đã sử dụng Stella để Figma prototype testing, concept validation và customer journey research, nhận được thông tin chi tiết chỉ sau một đêm thay vì chờ đợi sprint tiếp theo. Nếu nhóm của bạn muốn hiểu khách hàng với tốc độ bạn ship products, hãy dùng thử Stella. Hãy thực hiện nghiên cứu tiếp theo của bạn tại strea.io/lenny.

Samsara: Xây dựng Công nghệ cho Thế giới Vật lý

Tập này được tài trợ bởi Samsara. Nếu bạn lắng nghe podcast này, bạn biết rằng chúng tôi dành nhiều thời gian nói về việc xây dựng những thứ trên màn hình: onboarding funnels, mobile apps và checkout flows. Samsara đang xây dựng products for the physical world. Những người phản ứng đầu tiên lao tới các trường hợp khẩn cấp, tài xế xe tải chở vật tư quan trọng, công nhân xây dựng các thành phố và trung tâm dữ liệu của chúng ta. Đây là những người đặt mọi thứ vào nguy hiểm mỗi ngày. Và công nghệ của Samsara bảo vệ họ. Samsara đang giải quyết các vấn đề phức tạp tại giao điểm của hardware, software và edge AI. Và AI của họ không chỉ phát hiện sự kiện. Nó suy luận về ý định và trả lời các câu hỏi như: liệu người lái xe tải đó có phanh đột ngột vì bị phân tâm? Hay đó là một hành động anh hùng? Nếu bạn muốn ground LLMs trong real-world telemetry phức tạp hoặc giải quyết edge constraints ở planetary scale, Samsara muốn trò chuyện với bạn. Nếu bạn thích làm việc với enormous data sets, di chuyển nhanh và làm việc trong small teams, hãy đến giúp xây dựng công nghệ giúp physical world an toàn hơn và hiệu quả hơn. Truy cập samsara.com/lenny để tìm hiểu thêm.

Vai trò và Trách nhiệm Hàng ngày của Vibe Coder

Cảm ơn bạn rất nhiều vì đã đến đây và chào mừng bạn đến với podcast, Lazar. Lazar: Cảm ơn vì đã mời tôi, anh bạn. Lenny: Được rồi, tôi đã có Elena Verna trong podcast. Cô ấy là head of growth của Lovable. Cô ấy đề cập rằng cô ấy làm việc với một vibe coder chuyên nghiệp. Tôi có rất nhiều câu hỏi. Tôi gần như muốn đi on a tangent với cô ấy để cố gắng hiểu vai trò này. Thay vào đó, tôi đã mời bạn đến podcast. Có rất nhiều điều tôi muốn nói. Tôi muốn nói về career path này và cách bạn đến với nó, cách những người khác có thể tham gia, bạn nghĩ tất cả những điều này sẽ đi đến đâu, toàn bộ khái niệm vibe coding này. Ngoài ra, tôi muốn tìm hiểu những gì bạn đã học được về việc thành công khi sử dụng tất cả các AI tools này vì đây là công việc của bạn. Đầu tiên, tôi muốn bắt đầu với việc hiểu rõ công việc thực tế này. Bạn làm gì hàng ngày? Về cơ bản, bạn được trả lương full-time job để vibe code. Thật không thể tin được. Bạn chịu trách nhiệm về những gì? Bạn làm gì hàng ngày? Lazar: Vâng, như bạn đã nói, đó là một dream job, đúng không? Tôi được trả tiền để làm những gì tôi đã làm. Đó là công việc tốt nhất trên thế giới. Tôi được sử dụng các tool như Lovable mỗi ngày để push projects to production dù là cho mục đích internal hay external. Chúng có thể bao gồm bất cứ thứ gì từ các templates khác nhau về marketing side, sales side hay bất cứ điều gì, hoặc chúng có thể sâu sắc như việc xây dựng một số internal tools với nhiều integrations and connections và những thứ khác. Đúng không? Vì vậy, surface area mà tôi bao phủ khá rộng khắp các phòng ban vì đây là một flexible role và nó bổ sung cho rất nhiều thứ, đúng không? Đó là một ideas role. Rất nhiều người có nhiều ý tưởng tuyệt vời nhưng họ không biết cách xây dựng chúng và/hoặc họ chỉ không có bandwidth và đó là lúc tôi can thiệp để đảm bảo rằng những ý tưởng này được hiện thực hóa nhanh chóng với quality and security mà chúng cần có để có sẵn cho người dùng trong production. Lenny: Và một điều thực sự thú vị ở đây là nó bao gồm cả internal and external tools. Rất nhiều công ty có người xây dựng một loạt các internal tools bằng AI. Bạn ship những thứ thực sự public và nó giống như product level products. Lazar: Vâng, chắc chắn rồi. Giống như một số thứ tôi đã shipped mà là public là khi chúng tôi ra mắt Shopify integration của mình, hầu hết, nếu không phải tất cả các templates mà người dùng đang remixing đều do tôi xây dựng, đúng không? Những thứ như vậy hoặc cửa hàng merch vì chúng tôi muốn chứng minh khái niệm rằng: Lovable và Shopify hoạt động rất đơn giản, bất cứ ai cũng có thể làm được. Tôi đã vibe code cửa hàng merch của chúng tôi. Vì vậy, tất cả merch bao gồm chiếc áo này mà mọi người đã mua trực tuyến, họ đã mua nó từ một cửa hàng do tôi xây dựng. Nhưng sau đó, một lần nữa, về phía internal, chúng tôi muốn theo dõi rất nhiều thứ như một trong những điều thú vị mà chúng tôi muốn xây dựng bây giờ chẳng hạn là feature adoption matrix như nếu chúng tôi xây dựng một feature, có bao nhiêu người thực sự đang sử dụng nó, adopting nó, và đó là một custom build khá phức tạp, đúng không? Chúng tôi có một custom stack rất tùy chỉnh, chúng tôi đang xây dựng custom features, không có gì ở ngoài kia mà tôi có thể chỉ cần pick off the shelf và xây dựng hoặc adopt nhanh hơn tôi tự xây dựng nó. Tại thời điểm này, tôi đang ở giai đoạn mà nếu tôi mất một hoặc hai giờ để thiết lập một big enterprise account ở đâu đó. Tôi sẽ tự xây dựng nó nhanh hơn. Vì vậy, bạn biết đấy, tôi đang ở vị trí build versus buy. Tôi đang ở trong "con thuyền build" như người ta thường nói. Vâng.

Cấu trúc Báo cáo và Phát triển Vai trò

Lenny: Và sau đó bạn report to ai? Bạn có phải là một người "lang thang" giúp đỡ ở bất cứ đâu hay bạn làm việc với một nhóm cụ thể? Lazar: Tôi nghĩ có lẽ gần với điều trước đây hơn. Tôi bắt đầu ở growth, đúng không? Elena đã mời tôi về ngay từ đầu và bạn biết đấy, vì cô ấy có rất nhiều ý tưởng tuyệt vời và cô ấy chỉ cần ai đó với đúng loại mindset, velocity và ownership để chỉ cần thực hiện chúng, xây dựng chúng, đưa chúng vào production dù chúng dựa trên giáo dục hay bất cứ điều gì go to market hay bất cứ điều gì. Nhưng sau đó, rõ ràng là khi bạn có thể ship fast, mọi người đều cần điều đó trong một môi trường mà chúng tôi với tư cách là một công ty hiện đang sống trong đó, đó là nơi startup phát triển nhanh nhất trong lịch sử. Vì vậy, mọi phòng ban đều cần một Lazar bây giờ hoặc hôm qua. Vì vậy, bây giờ tôi đang hơi chuyển dịch một chút, tôi đoán, sang một số go to market roles và thậm chí xây dựng lại một số internal tools cho enterprise team nhưng tôi cũng đang làm việc trên một số community tools ngay lúc này. Vì vậy, tôi hơi linh hoạt, nhưng tôi phát triển mạnh trong môi trường mà tôi được giao một rough concept, một rough idea, và tôi chỉ được giao nhiệm vụ bring it to life càng sớm càng tốt.

Lợi thế của việc không có Nền tảng Kỹ thuật

Lenny: Ok. Tôi hy vọng với cuộc trò chuyện này, chúng ta sẽ tạo ra nhiều Lazar hơn, và tôi muốn tìm hiểu về career path, cách bạn đến với điều này và những gì cần thiết để thực sự trở thành một vibe coder full-time. Nhưng tôi muốn bắt đầu với việc vì bạn làm công việc này full-time. Bạn đang ở cấp độ tinh hoa 0.1% của vibe coding. Bạn đang làm công việc này full-time. Họ đã thuê bạn làm công việc này. Tôi rất tò mò về những gì bạn đã học được. Một số pro tips mà bạn đã phát triển để thành công với AI tools, Lovable là gì? Và rộng hơn nữa, có lẽ hai hoặc ba điều bạn đã học được giúp bạn thực sự giỏi trong công việc này là gì? Lazar: Sự hiểu biết đầu tiên mà tôi có được rất sớm, mặc dù tôi, một cách minh bạch hoàn toàn trước khi chúng ta bắt đầu, tôi không có technical background. Tôi chưa bao giờ viết một dòng code nào trong đời, gần như vậy. Tôi chỉ viết vài console logs thủ công và thế là xong, đúng không? Vì vậy, tôi rất dựa vào AI assistance. Lenny: Cho phép tôi theo dõi điều đó vì đó là một điểm rất hay và đó là điều mà khi chúng ta trò chuyện trước đây, bạn đã chỉ ra rằng cảm giác của bạn là việc không có technical background thực sự là một lợi thế khi bạn bước vào lĩnh vực này. Lazar: Vâng. Đúng vậy. Tôi thực sự cảm thấy rằng nó là như vậy vì những người như tôi không biết rằng họ không nên xây dựng XYZ và đó là cách chúng tôi thực sự có thể xây dựng nó. Hãy để tôi đưa ra một ví dụ: sáu, bảy tháng trước, ai đó trong cộng đồng của chúng tôi nói: "Ồ, tôi ước Lovable có thể xây dựng Chrome extensions" và sau đó những người không chuyên kỹ thuật sẽ nói: "Ồ, tại sao điều đó không thể?" và sau đó những người chuyên kỹ thuật bắt đầu giải thích cho bạn: "Ồ, bạn biết đấy, đó là một React, đó là một different stack, đó là điều này..." và những người như tôi, bao gồm cả bản thân tôi, sẽ chỉ vào Lovable và nói: "Hãy xây dựng cho tôi một Chrome extension dựa trên ứng dụng này" và tôi đã có thể làm điều đó với Lovable, có những người đã có thể xây dựng desktop applications trên Lovable.

Lợi thế của tư duy không định kiến và những thách thức phi kỹ thuật

Một lần nữa, một điều tưởng chừng không thể lại trở thành hiện thực. Quản lý cộng đồng của chúng tôi, tại một thời điểm nào đó, đang xây dựng một bản trình bày cho một dự án. Cô ấy nói: "Sẽ thật tuyệt nếu đây là một video, phải không?" Và sau đó, cô ấy chỉ cần dùng prompt để tạo ra một video thực sự bên trong Lovable trước khi tính năng này được cung cấp. Bây giờ đó là một tính năng, bạn có thể prompt Lovable để làm điều đó. Nhưng khi cô ấy làm điều đó, ngay cả tôi cũng nghĩ là không thể. Tôi chưa bao giờ thử. Vì vậy, tôi nghĩ đó là lợi thế mà chúng tôi có so với những người có chuyên môn kỹ thuật. Chúng tôi tiếp cận vấn đề này hoàn toàn không định kiến và rất lạc quan một cách "ảo tưởng tích cực", điều mà tôi nghĩ bạn phải có khi làm việc với các AI tools. Bạn phải có niềm tin rằng mọi thứ đều có thể cho đến khi được chứng minh là sai. Và đó chính là sự theo đuổi mà tôi có trong tâm trí, điều đã giúp tôi, trong số những thứ khác mà chúng ta sẽ trò chuyện hôm nay, phát triển trong vai trò mà tôi đang đảm nhiệm tại Lovable.

Hai trong số những mối lo ngại, hoặc có thể là những cái bẫy mà những người không có nền tảng kỹ thuật thường mắc phải trên lý thuyết là: thứ nhất, nếu bạn bị mắc kẹt, không rõ cách giải quyết vấn đề; và thứ hai là liệu bạn có đang xây dựng một "sản phẩm chắp vá" dễ đổ vỡ vào một ngày nào đó hay không, vì bạn không biết system architecture, bạn không biết liệu nó có thể mở rộng quy mô (scale) hay không, và tất cả những điều tương tự. Vậy, quay trở lại những gì bạn đã học về cách để thành công và xây dựng các sản phẩm thành công, hãy chia sẻ những điều bạn đã làm và những điều bạn đã học để tránh những điều đó, và bạn làm gì khi bị mắc kẹt.

Tầm quan trọng của tự nhận thức và sự rõ ràng

Tôi mừng vì bạn đã đề cập đến những hạn chế đó. Tôi có một vài điều khác muốn bổ sung, nhưng trước tiên hãy giải quyết vấn đề quan trọng nhất này, đó là bạn phải tự nhận thức. Tôi không đến với lĩnh vực này. Vâng, tôi có sự "ảo tưởng" như tôi đã đề cập, theo nghĩa là tôi không muốn chấp nhận rằng điều gì đó là không thể, nhưng tôi cũng nhận thức rõ rằng tôi cần phải tốt hơn để biến điều đó thành hiện thực từ góc độ và lợi ích của riêng tôi. Vì vậy, tôi hiểu rất sớm rằng coding không phải là vấn đề chúng ta đang giải quyết ở đây. Vấn đề chúng ta đang giải quyết là sự rõ ràng. Bởi vì output mà AI có thể tạo ra nhanh hơn nhiều so với output của con người.

Vì vậy, ngay từ rất sớm, tôi đã bắt đầu tận dụng chat mode, và cho đến ngày nay, tôi có thể nói rằng tôi dành 80% thời gian của mình để lập kế hoạch và trò chuyện, và chỉ 20% để thực sự thực hiện kế hoạch. Tôi đang tối ưu hóa cho tốc độ đúng, hầu hết mọi người tối ưu hóa cho tốc độ sai. Đó là bài học đầu tiên tôi học được, theo đúng nghĩa đen là vào ngày thứ hai, bởi vì tôi mới tiếp xúc với Lovable lần đầu. Tôi đã thử nghiệm và chơi với tất cả các tools khác, rõ ràng, nhưng dù ai đó đang làm việc trong Cursor hay Claude Code, không quan trọng bạn ở đâu, vấn đề vẫn như cũ: bạn cần phải rõ ràng về những gì bạn muốn làm và bạn cần biết mình đang làm gì, bởi vì đây vẫn chỉ là tools. Vâng, AGI đang đến, nhưng nó chưa đến. Vì vậy, cho đến khi nó đến, bạn vẫn đang điều khiển con tàu. Để điều khiển con tàu, bạn phải biết các hướng dẫn, phải không?

Và cách tốt nhất để học là bằng cách xây dựng, nhưng coi những tools này gần như là technical co-founders và nhà giáo dục, và học trong khi làm, và đọc một cách kỹ lưỡng agent output, không phải code output. Tôi không quan tâm đến code. Cú pháp không phải là điều tôi quan tâm. Điều quan trọng đối với tôi là những gì agent nói với tôi. Tôi đặt rất nhiều niềm tin vào LLM và AI ngày nay. Và tôi hiểu rằng có thể có một số người không tự tin như tôi. Tôi chỉ cảm thấy rằng các model ngày nay đủ tốt để tôi tin tưởng vào syntax output của chúng. Tuy nhiên, tôi lo ngại về agent output và vì hai hạn chế mà tôi muốn giải quyết tiếp theo.

Giới hạn của AI: Cửa sổ bộ nhớ ngữ cảnh và sự cụ thể của con người

Hạn chế đầu tiên là có một giới hạn khi bạn làm việc với các LLM. Có một giới hạn ở cấp độ máy móc (machine level limitation) và một giới hạn ở cấp độ con người (human level limitation). Hạn chế đầu tiên là có một điều được gọi là context memory window. Đối với những người không chuyên về kỹ thuật, tôi thích sử dụng ví dụ về Aladdin và Thần đèn khi giải thích. Nó rất đơn giản. Mọi người đều biết câu chuyện. Bạn xoa cây đèn, một Thần đèn hiện ra và nói: "Được rồi, ta sẽ ban cho ngươi ba điều ước. Không phải 3.000 điều ước, không phải 3 triệu, chỉ ba điều một lúc thôi."

Đối với tôi, khi tôi chuyển dữ liệu đó sang làm việc với AI, điều đó đơn giản có nghĩa là: này, tôi chỉ có thể đưa ra rất nhiều yêu cầu trong một yêu cầu tại một thời điểm để AI có thể lắng nghe, hiểu những gì nó cần làm, khoanh vùng, thực hiện nghiên cứu, đọc, thực hiện tất cả các hành động, tất cả các đầu vào và thành phần mà nó cần để tạo ra một output chất lượng cao. Vì vậy, đó là phần đầu tiên, hiểu rằng có một giới hạn và nó được tính bằng tokens. Có thể điều đó sẽ khác một năm nữa, nhưng ngày nay có một giới hạn về token. Tôi sẽ lấy một con số tùy ý là 100.000 tokens chẳng hạn. Vì vậy, khi bạn đưa ra một yêu cầu, một phần của những tokens đó AI dành để đọc tài liệu, một phần khác để duyệt web, một phần khác để suy nghĩ và sau đó một phần khác để thực thi code.

Sau đó đến hạn chế thứ hai, đó là bạn, tôi và chúng ta, con người. Hãy quay lại ví dụ về Thần đèn và Aladdin. Tôi ước điều đầu tiên và điều ước đầu tiên là tôi muốn cao hơn. Và đoán xem điều gì xảy ra? Thần đèn khiến tôi cao 13 feet. Đột nhiên, tôi không thể ngồi vào ô tô. Tôi không thể vào nhà. Tôi là một con người không còn chức năng. Đúng vậy. Bởi vì tôi không cụ thể. Vì vậy, phần mà chúng ta cần tối ưu hóa ngày nay (nó sẽ tốt hơn, nhưng ngày nay nó vẫn chưa hoàn hảo) là AI chỉ đơn giản là không hiểu. Bạn muốn nói gì khi bạn nói, bạn biết ý tôi chứ? Giống như bạn hiểu khi tôi nói với bạn rằng chúng ta, con người, tôi 36 tuổi, vì vậy tôi có 36 năm kinh nghiệm sống như một con người để biết bạn muốn nói gì, nhưng AI thì không có điều đó. Vì vậy, bạn cần phải cụ thể, bạn cần cung cấp các tài liệu tham khảo, bạn cần cung cấp context phù hợp. Vì vậy, điều tôi đã học được là cách để khắc phục phần đó, và tôi nghĩ bạn biết đấy, bởi vì tôi không thể kiểm soát phần đầu tiên là token memory window, chất lượng của các LLM models, bạn hoàn toàn kiểm soát phần sau. Và đó là điều tôi muốn đi sâu vào hôm nay và cố gắng dạy mọi người, okay, nếu tôi là phần dễ uốn nắn, làm thế nào để tôi sửa chữa phần đó? Tôi nghĩ đó là bài học chính ở đây. Điều này rất hữu ích và tôi yêu thích phép ẩn dụ về Thần đèn này. Phần về sự rõ ràng này là một sợi dây xuyên suốt mà tôi đã nhận thấy ở những người thành công khi sử dụng AI tools, và nó cảm giác như một kỹ năng cốt lõi đang nổi lên là học cách làm rõ yêu cầu với AI. Bạn có lời khuyên hay điều gì bạn làm ở đó để giúp mình rõ ràng hơn với những gì bạn muốn không?

Phát triển sự rõ ràng và óc phán đoán tốt

Vâng, trước hết, bạn cần phải, như bạn vừa nói, giỏi trong việc hiểu ý nghĩa của sự rõ ràng và cách chuyển đổi nó. Theo cách hiểu của tôi, sự rõ ràng có nghĩa là hiểu điều gì trông "có gu", điều gì là "đủ tốt" so với điều gì là "đẳng cấp thế giới", điều gì là "phép màu". Và tôi đã phát triển điều đó thông qua một điều tôi nghe được từ bạn. Bạn đã đề cập trước đây, đó là exposure time, tức là đảm bảo rằng tôi đang tiếp xúc với nội dung, với con người và với các mối quan hệ hoặc bất cứ điều gì sẽ giúp tôi nâng cao trình độ trong lĩnh vực đó.

Một lần nữa, nó quay trở lại sự tự nhận thức. Giống như tôi biết, ngay cả trước khi tôi gia nhập Lovable, tôi đã nghĩ: "Được rồi, ngay cả trước khi tôi bắt đầu sử dụng Lovable hoặc bất kỳ AI tools nào, điều đầu tiên tôi biết là tôi không biết code." Vì vậy, điều đầu tiên của tôi là: "Ồ, tôi có thể xây dựng. Tuyệt vời!" Nhưng một tuần sau, tôi lại nghĩ: "Ồ, tôi có thể xây dựng, nhưng tôi không đủ nhanh." Vì vậy, tôi đã tối ưu hóa tốc độ. Tôi đã nghĩ: "Ồ, tôi có thể xây dựng và tôi có thể xây dựng rất nhanh." Và sau đó hai tuần sau, chu kỳ phát triển mà tôi đang theo đuổi bắt đầu và nó vẫn đang tiếp diễn, đó là: "Khoan đã, lẽ ra tôi có nên xây dựng cái này ngay từ đầu không?" Bởi vì một khi bạn tìm ra rằng chúng ta đã giải quyết được vấn đề "làm thế nào" – đó là AI assistant hoặc rapid engineering. Hãy gọi nó là bất cứ điều gì bạn muốn. Bạn có thể gọi nó là vibe coding nếu bạn muốn. Nhưng chúng ta đã giải quyết được vấn đề đó. Bây giờ chúng ta phải giải quyết mọi thứ khác. Và mọi thứ khác là điều quan trọng. Thiết kế tốt, gu thẩm mỹ tốt, trải nghiệm người dùng tốt.

Khi bạn nghĩ về những người bạn đang xây dựng mọi thứ cho họ bằng những tools này, bạn đang xây dựng cho con người. Con người là những sinh vật cảm xúc và tất cả chúng ta đưa ra quyết định mua hàng hoặc bất kỳ loại quyết định nào dựa trên cảm xúc. Vì vậy, tôi nghĩ rằng kỹ năng cốt lõi để làm việc và phát triển ngày nay không phải là coding nữa. Mặc dù tôi không có gì chống lại traditional engineering và tôi sẽ nói sau tại sao tôi thực sự là một fan hâm mộ lớn của elite engineering. Nhưng những người như tôi, những người đang xem và đang nghĩ: "Tôi có nên bắt đầu học code không?" Nếu bạn chưa làm điều đó, tôi thành thật mà nói là không. Bạn đang tối ưu hóa cho bộ kỹ năng sai. Chúng ta sẽ không được khen thưởng trong thế giới AI vì raw output nhanh hơn. Chúng ta sẽ được khen thưởng vì better judgment.

Vì vậy, tôi nghĩ rằng better judgment đi kèm với, một lần nữa quay lại câu hỏi của bạn: bạn đang giải quyết vấn đề đó như thế nào? Bạn đang giải quyết vấn đề này như thế nào? Chà, nó bắt đầu bằng exposure. Vì vậy, tôi cố tình tiếp xúc với những người và tài nguyên mà tôi biết mình cần tiêu thụ để nâng cao trình độ. Và sau đó rất nhiều điều chỉ đến từ việc xây dựng. Nếu chúng ta thành thật mà nói, đó là một muscle. Mọi thứ đều là một muscle. Bạn cần luyện tập. Bạn cần xem điều gì có thể xảy ra. Và bạn biết đấy, đó là nơi mà một số kỹ thuật và thay đổi tư duy mà tôi cũng muốn tận dụng cơ hội hôm nay để khắc sâu vào tâm trí mọi người sau này trong cuộc trò chuyện có thể hữu ích.

Cách tiếp cận thực tế để đạt được sự rõ ràng: "Brain Dump" và lặp lại

Vâng, tôi đang hiểu ở đây là vì coding bây giờ về cơ bản là một vấn đề đã được giải quyết. Tôi rất thích việc bạn không nhìn vào code. Bạn thậm chí không, bạn chưa bao giờ code. Bạn không muốn nhìn vào code. Bạn không quan tâm đến những gì đang xảy ra ở đó, thay vào đó bạn đang theo dõi agent output. Tôi thực sự muốn hỏi về điều đó, nhưng điều tôi đang hiểu ở đây là các lĩnh vực bạn đang đầu tư để xây dựng cho bản thân là ở khâu đầu, sự rõ ràng về nó là gì, và tôi muốn nghe cách bạn thực sự làm điều đó, bạn làm gì ở đó. Bạn có một hệ thống thực sự thú vị ở đó, và sau đó là gu thẩm mỹ và óc phán đoán để biết liệu đây có phải là điều tôi muốn hay không. Cảm giác như đó là hai mặt bây giờ ngày càng quan trọng hơn.

Và về mặt gu thẩm mỹ và óc phán đoán, bạn chia sẻ khái niệm này. Đây là điều mà GM Marous đã chia sẻ trong cuộc trò chuyện của chúng ta. Ý tưởng về exposure time, exposure hours, được tiếp xúc với những thứ tuyệt vời. Đây là một user experience tuyệt vời. Đây là một luồng onboarding tuyệt vời. Đây là một trang web tuyệt vời. Vì vậy, tôi thực sự thích lời khuyên đó bởi vì những hành động đó rất khả thi. Được rồi. Tôi sẽ dành nhiều thời gian hơn với những thứ tuyệt vời để hình thành gu thẩm mỹ và óc phán đoán của mình. Và sau đó về phần rõ ràng, tôi muốn chúng ta thực sự nói về điều đó. Bạn làm gì ở đó để rõ ràng hơn với Lovable và các AI tools khác để giúp nó xây dựng đúng thứ?

Đây là sự thay đổi tư duy đầu tiên mà tôi muốn đưa vào tâm trí mọi người. Nếu bạn chỉ có một ý tưởng mơ hồ, hãy để đó là phiên bản đầu tiên của dự án của bạn. Mở Cursor, Lovable, hoặc bất cứ thứ gì bạn đang sử dụng, và chỉ cần nhập một brain dump prompt. Cứ thế nói vào đó. Lovable đặc biệt, tôi không biết về các tools khác, có một chức năng giọng nói rất hay. Bạn nhấp vào nó, bạn chỉ cần đọc tất cả những gì bạn nghĩ và nhấn gửi. Đừng chờ đợi nó hoàn thành. Mở một cửa sổ mới. Lovable.dev. Ở đây, bạn sẽ nghĩ: "Được rồi, khi tôi brain dump, tôi nghĩ tôi đã tìm thấy một luồng ý tưởng hay. Mọi thứ đang trở nên rõ ràng hơn." Vì vậy, hãy bắt đầu một dự án khác bây giờ với sự rõ ràng hơn, khả năng phân phối cao hơn. Giống như tôi biết những tính năng nào tôi muốn, những trang nào tôi muốn.

Tinh Chỉnh Thiết Kế và Tiết Kiệm Credit Bằng Cách Cung Cấp Mã Code

Có lẽ tôi có thể tìm một tài liệu tham khảo tốt. Tôi có thể lên Maven, có thể lên Dribbble, có thể lên bất cứ đâu, lấy một ảnh chụp màn hình đẹp, một hoạt ảnh đẹp và đính kèm nó vì hầu hết các công cụ này đều chấp nhận tập tin như một phần của đầu vào. Vậy là bạn đã bắt đầu dự án thứ hai. Bây giờ mọi thứ thậm chí còn rõ ràng hơn. Bạn đã tiếp xúc với chất lượng và bây giờ bạn tự hỏi, "Điều gì sẽ xảy ra nếu tôi tìm thấy một template đã có sẵn ngoài kia? Tại sao phải tái phát minh bánh xe? Tôi đang xây dựng một nền tảng mà người khác đã xây dựng rồi. Tại sao không cho AI biết chất lượng trông như thế nào?" Đúng không?

Vì vậy, điều tôi sẽ làm là tôi sẽ tìm một thư viện như 21st dev hoặc build hoặc bất kỳ nơi nào cho phép tôi không chỉ xuất ảnh chụp màn hình mà còn xuất các code snippet. Bởi vì, bạn biết đấy, mặc dù tiếng Anh là ngôn ngữ lập trình số một, Lovable và tất cả các công cụ khác vẫn giao tiếp tốt nhất bằng code. Nếu bạn muốn nhận kết quả hoàn hảo đến từng pixel, chỉ cần cung cấp cho chúng code. Nó sẽ diễn giải tốt hơn tiếng Anh, tiếng Tây Ban Nha hoặc bất kỳ ngôn ngữ nào bạn sử dụng trong các công cụ này. Đó là cách thứ ba. Bạn sẽ nghĩ, "Được rồi, bây giờ tôi thậm chí còn chủ động hơn. Tôi không còn đưa ra các khái niệm mơ hồ nữa. Tôi đang cung cấp các code snippet như tôi muốn thiết kế chính xác này, tôi muốn chức năng chính xác này." Đó là dự án thứ ba của bạn.

Và khi bạn hoàn thành cả ba điều này, bạn đã đạt đến mức độ rõ ràng mà bạn sẽ không có được nếu chỉ ngồi với một tờ giấy trắng hoặc chỉ trò chuyện với ChatGPT mà không hành động. Tôi nghĩ hành động ngày nay rất rẻ và thậm chí miễn phí. Tất cả các công cụ tôi đề cập đều có gói miễn phí. Hầu hết thời gian bạn có thể làm điều này mà không tốn một xu nào, chỉ bằng cách bắt đầu nhiều dự án. Bởi vì, bạn biết đấy, điều đó cũng không tốn thêm chi phí nào khác ngoài credit của công cụ xây dựng. Bạn sẽ nhận được ba, bốn, năm, sáu ý tưởng khác nhau để so sánh. Khi bạn so sánh chúng, sự rõ ràng sẽ liên tục đến, và mọi thứ trở nên dễ hiểu hơn.

Bạn cũng đang giải quyết một vấn đề lớn mà bạn đã đề cập. Bạn đã dùng thuật ngữ AI slop, và tôi thích nó vì nhiều người khi nói AI slop họ không đề cập đến việc làm đẹp mã code mà là làm đẹp thiết kế. Quy trình tôi vừa đề cập thực sự cung cấp cho bạn bốn hoặc năm tùy chọn thiết kế khác nhau và về lâu dài sẽ giúp bạn tiết kiệm một lượng lớn credit. Bởi vì rất nhiều người bị ám ảnh bởi khái niệm, "Ồ, khi tôi đưa cho họ hack này, họ nói, "Nhưng điều đó không tốn nhiều tiền hơn sao?" Tôi nói, "Đúng, ban đầu nó có thể tốn hơn một chút. Về lâu dài, nếu bạn thực sự muốn hoàn thành dự án này, bạn thực sự đang tiết kiệm hàng trăm credit và thậm chí có thể hàng trăm đô la, chưa kể số ngày, đơn giản vì bạn bắt đầu từ một điểm rõ ràng hơn và quy trình tinh chỉnh tốt hơn." Vậy đó là bước đầu tiên để giải quyết sự rõ ràng. Còn nhiều bước nữa, đó là lớp thứ hai. Nhưng tôi nghĩ bạn có thể có một số câu hỏi về điều này.

Phương Pháp Xây Dựng Song Song Để Đạt Được Sự Rõ Ràng

[Người hỏi:] Câu hỏi và cả... wow, đây thực sự là một điều tuyệt vời. Nó cho thấy sức mạnh của việc có một người không có nền tảng kỹ thuật bước vào thế giới này. Lời khuyên này, "chỉ cần xây dựng nó năm lần song song, bạn yêu cầu AI thử đủ loại thứ," không phải là cách mà một kỹ sư phần mềm, một PM, hay một nhà thiết kế sẽ tiếp cận mọi thứ. Vì vậy, lời khuyên của bạn ở đây, rất thú vị, là khi bạn bắt đầu một dự án, hãy thử năm cách tiếp cận khác nhau ngay từ đầu.

1. Đầu tiên là brain dump: Đây là những gì tôi đang nghĩ. Đây là một ý tưởng tổng thể. Hãy sử dụng Whisper flow hoặc mic tích hợp.
2. Thứ hai là, được rồi, bây giờ tôi có một ý tưởng tổng thể. Hãy thử gõ nó ra. Hãy thực sự suy nghĩ về prompt.
3. Thứ ba là, hãy tìm một thiết kế mẫu trực tuyến ở đâu đó. Và các trang bạn gợi ý là Mobin và Dribbble. Đó là hai trang bạn thường dùng?

[Người trả lời:] Vâng, hầu hết thời gian.

[Người hỏi:] Được rồi. Và sau đó, thứ tư (tất cả những điều này đều song song, thật tuyệt vời), là tìm một template code thực tế trông giống với thứ bạn muốn xây dựng. Tải xuống file zip về cơ bản và đính kèm nó, hay chỉ là HTML và CSS? Đại loại như vậy?

[Người trả lời:] Bất cứ thứ gì bạn có. Đây.

[Người hỏi:] Được rồi. Và sau đó, tuyệt vời. Đây là prompt đây. "Làm cho tôi thứ tôi muốn." Và điều tôi thích là có hai lợi ích ở đây.

1. Thứ nhất, nó giúp bạn làm rõ ý tưởng khi bạn thấy công cụ xây dựng nó, kiểu như "Ồ không, đó không phải là ý tôi, hãy thử lại."
2. Thứ hai là, bạn đã chỉ ra rằng bạn có thể chọn đúng hướng để không bị mắc kẹt với thiết kế và kiến trúc đầu tiên của mình. Theo ý bạn, nếu bạn dành tất cả thời gian này để cố gắng tinh chỉnh thiết kế và định hướng, thì tất cả những token này đang bị lãng phí. Bạn có thể chỉ cần bắt đầu lại. Điều này thật tuyệt vời. Ai đó có thể nghĩ, "Đương nhiên, bạn chỉ đang khiến chúng tôi tiêu tốn tất cả những token của Lovable. Đây là điều mà một người của Lovable sẽ nói với tôi." Nhưng điều tôi cảm thấy là đây là nơi bạn có thể tiết kiệm nhiều tiền nhất, bởi vì nếu bạn làm đúng ngay từ đầu, bạn sẽ tiết kiệm được rất nhiều công sức khi cố gắng đưa nó trở lại nơi bạn muốn.

[Người trả lời:] Một triệu phần trăm là tôi thực sự đang giúp mọi người tiết kiệm. Tôi thực sự đang đi ngược lại những gì tôi nên nói. Nếu tôi nghĩ về Lovable, tôi sẽ nói, "Không, không, chỉ cần cố gắng sửa chữa nó mãi mãi." Nhưng đó không phải là mục tiêu kinh doanh của chúng tôi. Mục tiêu kinh doanh của chúng tôi là trao quyền cho bất kỳ ai xây dựng bất cứ thứ gì họ muốn. Và bạn biết đấy, đó là sứ mệnh cá nhân của tôi mà tôi rất đồng cảm, bởi vì nếu không có Lovable, có lẽ tôi đã không bao giờ xây dựng được bất cứ thứ gì trong đời. Và tôi không nghĩ đó sẽ là một cuộc sống thú vị. Vì vậy, bạn biết đấy, tôi đảm bảo với mọi người rằng tôi đã thử nghiệm khung này với nhiều người và mọi người đều nói với tôi điều tương tự: "Thật là một sự khai sáng. Thật đơn giản nhưng lại không trực quan," như bạn đã nói. Mặc dù đối với tôi, nó không... như bạn đã nói, tôi cho rằng đó là do nền tảng phi kỹ thuật. Đối với tôi, đó là điều đầu tiên tôi sẽ làm. Tôi chỉ làm vậy thôi. Tôi chưa bao giờ nghĩ về nó như kiểu, "Ồ, tôi đang phát triển một hack tuyệt vời này." Tôi chỉ nghĩ, "Tôi đang chờ đợi bấy lâu nay để những agent này hoàn thành công việc. Tôi cũng có thể bắt đầu một dự án khác, và một dự án khác, và một dự án khác." Và đó cũng là một mẹo tăng năng suất. Khi mọi người hỏi tôi, "Wow, làm thế nào mà bạn lại đưa ra nhiều thứ như vậy?", tôi nói, "Tôi chưa bao giờ chỉ xây dựng một dự án một lúc. Tôi xây dựng năm hoặc sáu dự án." Tôi có sáu tab Lovable và tôi chỉ chuyển đổi giữa chúng.

Giải Quyết Vấn Đề Context Switching Với LLM

Đó là hack tiếp theo mà tôi muốn nói đến, nếu bạn cho phép tôi, đó là câu hỏi hiển nhiên ngược lại, đó là làm thế nào để bạn chuyển đổi ngữ cảnh? Bạn nói rất nhiều về ngữ cảnh nhưng bạn lại liên tục chuyển đổi giữa các ứng dụng. Làm thế nào bạn quản lý để làm điều đó một cách hiệu quả và không tạo ra mã kém chất lượng hoặc sản phẩm kém chất lượng? Và đó là cách tôi giải quyết vấn đề của LLM. Lại là câu chuyện Aladdin và cây đèn thần, đó là nếu có một cửa sổ token giới hạn, làm thế nào để tôi làm cho nó linh hoạt?

Và ý tôi là thế này: nếu bạn chỉ prompt và prompt và prompt và prompt, bạn sẽ nhận ra rằng bất kể bạn sử dụng công cụ nào, bộ nhớ không phải là vô hạn. Đến khi bạn đạt đến tin nhắn số 10, 15, 20, 30, 40, các đoạn tin nhắn ban đầu dường như bị mất đi trong quá trình dịch. Bởi vì agent đang tối ưu hóa cho tốc độ. Nếu nó phải đọc toàn bộ cuộc hội thoại và toàn bộ luồng yêu cầu bạn đã thực hiện, việc phát triển bất cứ thứ gì khả thi hoặc lớn sẽ là không thể, bởi vì nó chỉ tốn rất nhiều thời gian, rất nhiều bộ nhớ và rất nhiều token.

Vì vậy, một lần nữa, điều mà tôi đã sớm nhận ra khi đang xây dựng là, "Được rồi, nếu nó không thể nhớ mọi thứ, công việc của tôi là cung cấp tài liệu tham khảo cho nó." Vì vậy, hãy coi Lovable hoặc bất kỳ công cụ nào khác như một kỹ sư mà tôi phải cung cấp ngữ cảnh liên tục khi dự án tiến triển. Và bạn có thể làm điều đó bằng nhiều cách, nhưng cách hiệu quả nhất mà tôi tìm thấy là tôi sẽ thực hiện bốn lần xây dựng song song. Hãy tiếp tục với ví dụ đó. Rất nhanh sau khi bạn đã xây dựng hàng trăm dự án như tôi đã làm, bạn sẽ thấy người chiến thắng. Người chiến thắng rõ ràng đến mức không cần phải cạnh tranh. Bạn có thể thực hiện một hoặc hai prompt để hiệu chỉnh nó. Và khi bạn nói, "Được rồi, người chiến thắng đây rồi," tại thời điểm đó, tôi hoặc yêu cầu công cụ tôi đang sử dụng, hoặc tôi sẽ đi đến ChatGPT hoặc bất cứ đâu và yêu cầu LLM tạo ra một loạt các PRD.

Xây Dựng PRD và Lập Kế Hoạch Chi Tiết

PRD (Project Requirements Documents - Tài liệu Yêu cầu Dự án) là gì, đối với những người không quen thuộc với thuật ngữ này? Chúng là tài liệu yêu cầu dự án, hoặc đối với tôi, tôi gọi chúng là nguồn thông tin đáng tin cậy. Những gì cần phải đúng để dự án này thành công từ một vài góc độ? Tôi thường xây dựng một thứ mà tôi gọi là kế hoạch tổng thể. Về cơ bản, nó là một la bàn nói rằng đây là những gì chúng ta đang xây dựng, giống như nói chuyện với một con người. Tôi thực sự coi Lovable như một con người. Vì vậy, nó giống như đây là những gì chúng ta đang xây dựng.

Sau đó, tôi xây dựng kế hoạch triển khai, đó là cách chúng ta sẽ xây dựng nó, đây là trình tự. Điều này rất quan trọng đối với tôi, một lần nữa quay lại chất lượng, thẩm mỹ, bản chất con người. Tôi cần xác định vì tôi vẫn đang làm việc với một hệ thống chưa có trí tuệ cảm xúc. Tôi cần xác định cách tôi muốn ứng dụng trông và cảm nhận. Vì vậy, một PRD khác mà tôi xây dựng là hướng dẫn thiết kế.

Và cuối cùng, một thứ bao quát tất cả, đó là, được rồi, khi chúng ta biết mọi thứ trông như thế nào và khi chúng ta biết cách chúng ta đang xây dựng nó, hành trình người dùng sẽ trông như thế nào? Một người dùng đăng ký và sau đó thì sao? Và khi họ đăng ký và thực hiện bước đầu tiên, bước thứ hai là gì và bước thứ ba là gì, v.v. Vì vậy, tôi xây dựng ít nhất bốn PRD. Và sau đó, khi những tài liệu này được xây dựng, tôi đọc chúng. Đó là phần lập kế hoạch và trò chuyện. Đó là nơi tôi sẽ dành rất nhiều thời gian bây giờ. Khi tôi chốt hạ thiết kế đầu tiên, tôi sẽ dành cả một ngày nếu cần chỉ để lập kế hoạch phần này, như tài liệu hóa và phân tách mọi thứ, bởi vì đó là cách tôi thiết lập lộ trình. Mọi thứ sẽ phụ thuộc vào phần cụ thể này của quy trình.

tasks.md và rules.md: Ủy Quyền Context Cho Agent

Khi tôi hoàn thành việc đó, tôi xây dựng một tài liệu cuối cùng mà tôi gọi là plan.md hoặc tasks.md. Phần MD là Markdown. Về cơ bản, tôi chỉ sử dụng định dạng Markdown vì tôi đã học được rằng AI thích đọc Markdown. Và điều đó phục vụ như một nguồn thông tin đáng tin cậy về các nhiệm vụ và nhiệm vụ con thực tế mà nó sẽ cần thực hiện để đạt được mục tiêu.

Và sau đó có lớp cuối cùng, tùy thuộc vào công cụ bạn sử dụng, Claude Code hoặc Cursor có cái được gọi là rules.md hoặc agent.md. Về cơ bản, bạn đang làm gì với các tệp rules hoặc agent là bạn đang cho agent biết bạn muốn nó hoạt động như thế nào và nó nên tập trung vào điều gì về lâu dài để bạn không phải lặp lại bản thân với mỗi prompt.

Vì vậy, trong Lovable, có một menu riêng cho điều đó trong cài đặt dự án của bạn, nơi bạn có thể định nghĩa kiến thức dự án. Và thường thì tôi sẽ nói, "Này, hãy đọc tất cả các tệp trước khi bạn làm bất cứ điều gì. Đừng làm bất cứ điều gì trước khi bạn đọc tất cả các PRD, đọc tasks.md để xem nhiệm vụ nào tiếp theo, sau đó thực hiện tập hợp các nhiệm vụ tiếp theo đó. Và khi bạn hoàn thành, hãy cho tôi biết bạn đã làm gì và tôi nên kiểm tra nó như thế nào." Và đó là lúc cuộc trò chuyện về việc tôi đọc kỹ lưỡng đầu ra của agent trở nên quan trọng. Tôi đã nói với AI, tôi đã cung cấp cho agent mọi thứ, tất cả các công cụ và tài nguyên mà nó cần để thành công. Tôi đã cung cấp cho nó các quy tắc. Tôi đã cung cấp cho nó các tài liệu. Tôi đã nói với nó phải làm gì với chúng. Và tại thời điểm đó, tôi chỉ ngồi và đọc. Tôi không còn prompt nữa. Từ thời điểm đó trở đi, tôi có thể chuyển đổi bao nhiêu cửa sổ tùy thích. Các prompt của tôi đã trở thành "tiếp tục với nhiệm vụ tiếp theo." Tôi không cần ngữ cảnh. Tôi đã thuê ngoài và ủy quyền điều đó cho agent. Agent cần ngữ cảnh và tôi cần đảm bảo rằng nó là động.

Chiến lược cập nhật tài liệu và tối ưu hóa kỹ năng với AI

Tôi cần đảm bảo rằng mình thường xuyên cập nhật tài liệu để dịch chuyển token window mà LLM sử dụng, và cách nó sử dụng token theo thời gian. Nhưng tôi không prompt liên tục, tôi không làm gián đoạn luồng làm việc. Có, tôi sẽ kiểm tra, có thể đặt một prompt ở đây hoặc ở kia, nhưng đó là cách tôi có thể xây dựng năm dự án cùng lúc mà không bao giờ mất đi phần năng suất. Mà, như tôi đã nói, hôm nay tôi làm việc này thủ công. Hãy gọi cho tôi 3 tháng nữa, một agent sẽ làm việc này cho tôi. Tôi sẽ thất nghiệp mất thôi. Đó là lý do tại sao tôi không tối ưu hóa kỹ năng này một chút nào. Tôi đang sử dụng nó ngày nay để vượt qua những hạn chế của bản chất con người và các LLM. Nhưng tôi đang tối ưu hóa 100% thời gian của mình ngày hôm nay vào khả năng đánh giá tốt, sự rõ ràng, chất lượng, thẩm mỹ, nội dung hay, và phông chữ đẹp. Mọi người làm việc với AI hoàn toàn không nói về phông chữ. Chúng chiếm khoảng 60% trong tâm trí tôi, thậm chí có thể nhiều hơn, trong việc định hình kết quả đầu ra của bạn sẽ trông như thế nào. Đó là nỗi ám ảnh của tôi. Tôi không ám ảnh về những điều tôi đang nói ngày hôm nay vì tôi biết điều gì sắp đến. Các agent sẽ trở nên tốt hơn, các models sẽ tốt hơn. Chúng sẽ không cần tôi mở rộng context. Chúng sẽ tự làm điều đó. Vì vậy, đối với tôi, kỹ năng mà tôi tối ưu hóa là kỹ năng đòi hỏi khả năng ra quyết định tốt hơn, chứ không phải kết quả đầu ra tốt hơn hay khả năng alignment tốt hơn.

Tầm quan trọng của việc lập kế hoạch chi tiết với Agent AI

Người phỏng vấn: Ôi Chúa ơi, có quá nhiều điều hay ở đây. Điều này thật tuyệt vời. Về cơ bản, điều đang xảy ra ở đây là bạn bắt đầu một dự án, thử nhiều thứ, chọn một hướng đi mà bạn cảm thấy đúng đắn nhất, và một khi bạn đã có một hướng đi cố định, bạn dành về cơ bản một ngày không phải để xây dựng mà là để làm việc với agent AI này để lập kế hoạch. Và tôi muốn nói về điều đó. Và một khi bạn đã có kế hoạch, thì điều đáng kinh ngạc là bạn có thể làm những điều như vậy với những tool mà một số người có thể cảm thấy không đủ tinh vi, nhưng lại có thể xây dựng những thứ cực kỳ mạnh mẽ. Bạn có thể làm rất nhiều điều này với các tool như Lovable, như có các kế hoạch và quy tắc trong các MD files. Bạn biết đấy, nhiều người có thể không nghĩ hoặc không biết điều đó. Và vì vậy, ý tưởng là dành tất cả thời gian này để lập kế hoạch, bởi vì một lần nữa, điều đó sẽ giúp bạn tiết kiệm rất nhiều thời gian về sau. Và chỉ khi bạn có kế hoạch, bạn mới bắt đầu thực hiện. Và một phần quan trọng của điều này, quy tắc ba điều ước này thực sự quan trọng. Lý do bạn làm điều này, phần lớn không chỉ là để có một kế hoạch thực sự rõ ràng, mà còn là ý tưởng về việc thực hiện một nhiệm vụ tại một thời điểm sẽ giữ cho context window của agent nhỏ, để nó không bị lạc mất mình đang ở đâu. Phần đó có vẻ quan trọng, đúng không? Kiểu như làm điều này trước, và sau đó, được rồi, làm điều tiếp theo, đúng không?

Người nói: Đúng vậy. Bởi vì một lần nữa, nếu bạn không làm điều này, hãy giả định bạn bỏ qua nó. Bạn kiểu như, "Tôi chỉ muốn làm theo cảm hứng." Được thôi, không vấn đề gì. Bạn làm việc, làm việc, làm việc. Đến một lúc nào đó, có gì đó sẽ hỏng, đúng không? Bạn chưa ghi lại bất cứ điều gì. Không có điểm tham chiếu nào cả. Bạn báo cáo một vấn đề. Bạn hoàn toàn không tham chiếu các tệp hoặc kiến trúc. Bạn chỉ mô tả vấn đề. Đây là điều sẽ xảy ra. Bất kỳ tool nào như Lovable, Cursor hay Clo – bất kể tool nào bạn nhắc đến – đều sẽ làm điều này. Nó sẽ kiểu như, "Được rồi, để tôi bắt đầu điều tra." Và rồi codebase của bạn cứ lớn dần, lớn dần, lớn dần. Khi bạn mới bắt đầu, bạn có khoảng 20 tệp. Nó có thể đọc 20 tệp. Nhưng điều gì xảy ra khi bạn có... tôi đang xây dựng một dự án bây giờ có khoảng 60, 70 edge functions, đúng không? Điều gì xảy ra khi tôi nói điều này bị hỏng và không có tham chiếu nào cho biết edge function nào làm gì? Đoán xem? Lovable sẽ đọc tất cả chúng và sẽ tiêu thụ 80% token allocation vào việc đọc để có được sự rõ ràng, chỉ để lại 20% cuối cùng cho việc suy nghĩ và thực thi. Điều tôi đoán, và tôi không thể chứng minh điều này, một chuyên gia LLM trong phần bình luận có thể nói rằng tôi sai, nhưng đây là phỏng đoán tốt nhất của tôi với tư cách là một người không có học vấn. Những tool này rất tuân thủ và rất dễ đồng ý. Chúng sẽ nói dối bạn. Chúng sẽ nói với bạn rằng chúng đã khắc phục vấn đề mặc dù chúng không làm thế. Chúng chỉ cố gắng làm cho bạn cảm thấy vui vẻ và nói, "Vâng, tôi đã tìm thấy vấn đề và tôi đã khắc phục nó." Khi chúng không làm được điều đó, mọi người đổ lỗi cho máy móc. Và đến một mức độ nào đó, tôi sẽ nói điều đó là đúng. Đó là lỗi của bạn, bạn của tôi. Bạn đã không cung cấp bất kỳ sự rõ ràng hoặc context nào cho tool này. Bạn chỉ sử dụng sức mạnh thô của nó và tự đào một cái hố sâu hơn khi bạn quay bánh xe của mình vào bùn, đúng không? Và bạn biết đấy, rõ ràng tôi nghĩ chúng ta đang tiến vào một thế giới nơi AI trung thực hơn là tuân thủ, và nói rằng, "Này, tôi chỉ khắc phục một phần thôi. Bạn không cung cấp cho tôi đủ context." Đúng không? Lỗi lớn hơn mà mọi người mắc phải sau đó là họ tin rằng tool đã khắc phục nó. Họ kiểm tra, họ thấy không được, rồi họ tức giận với nó, bắt đầu chửi rủa và la hét như chúng ta nói, và rồi mọi thứ trở nên tệ hơn nữa bởi vì đoán xem một đặc điểm xấu khác của AI là gì? Nó cố gắng hết sức để không làm tổn thương cảm xúc của bạn và không bao giờ nói bạn là người ngốc nghếch. Nó nói, "Không, tôi là người ngốc nghếch." Vì vậy, trong yêu cầu tiếp theo, thay vì tập trung vào việc đọc, nó dành thêm 30% token để cố gắng đưa ra lời xin lỗi. Đúng không? Một lần nữa, tôi không có học vấn, nhưng đó là nếu bạn từng đọc một luồng suy nghĩ của ChatGPT trong các thinking models, bạn sẽ thấy chính xác ý tôi muốn nói. Khi tôi lăng mạ nó, tôi thấy rằng tin nhắn đầu tiên là "được rồi, người dùng đang tức giận, vì vậy tôi cần nghĩ cách để giảm bớt lo lắng của họ hoặc gì đó." Tôi kiểu như, "Ôi trời, tôi vừa mắc phải sai lầm tệ hại nhất. Tôi đã làm cho nó tiêu tốn tài nguyên khan hiếm nhất, đó là những token, vào việc suy nghĩ cách giải quyết sự lo lắng của tôi thay vì tập trung vào vấn đề thực tế." Vì vậy, lời khuyên của tôi dành cho mọi người là: vâng, hãy làm theo cảm hứng để vui vẻ và làm theo cảm hứng trong khi bạn đang tạo mẫu, bởi vì đó là phần khám phá. Tôi yêu phần đó. Nhưng khi việc khám phá đã xong, làm ơn, làm ơn, làm ơn hãy sử dụng tài liệu tham chiếu, hãy sử dụng tất cả các agent files mà bạn có thể, bởi vì token allocation đó quá khan hiếm. Nó sẽ được mở rộng theo thời gian. Mọi thứ sẽ trở nên rẻ hơn, nhanh hơn, nhưng ngay bây giờ nó vẫn rất có giá trị và quý giá. Bạn thực sự cần đảm bảo rằng chúng được phân bổ đúng hướng.

Giới hạn của AI: Quan trọng là Context và Tài liệu đầu vào

Điều này thật hài hước. Tôi nghĩ ẩn dụ thần đèn ở đây rất hay. Chỉ cần nghĩ về thần đèn này, bạn đang cố gắng làm rõ những gì bạn muốn, và nếu bạn chỉ kiểu như "làm theo cảm hứng", "ước theo cảm hứng", nó sẽ làm sai điều. Vì vậy, lời khuyên ở đây là hãy cung cấp càng nhiều context càng tốt về những gì bạn muốn nó làm. Và chúng ta sẽ nói về những tệp này ngay sau đây, nhưng ý tưởng ở đây chỉ đơn giản là hãy dùng laser chỉ thẳng vào nơi bạn muốn nó khắc phục vấn đề. Đừng chỉ cho rằng nó sẽ tự tìm ra, bởi vì nó sẽ cố gắng rất nhiều và nó sẽ lãng phí tất cả token của bạn. Nó sẽ lấp đầy context window, và tôi nhớ có lần bạn đã đề cập trước khi ghi âm rằng vì nó bắt đầu hết không gian trong context window, nên giải pháp cuối cùng của nó không thực sự được đầu tư nhiều công sức để tìm ra, bởi vì nó đã dành tất cả năng lượng vào việc đọc và suy nghĩ, và sau đó nó kiểu như, "được rồi, đây, vào giây cuối cùng, đây là một giải pháp." Tôi nghĩ nó chỉ chọn thứ đầu tiên nó nghĩ là bị hỏng. Một lần nữa, đây chỉ là tôi, một người hoàn toàn không có học vấn, tham gia cuộc trò chuyện và chỉ suy nghĩ thành lời. Đó chỉ là cảm giác ruột của tôi và cách tôi suy nghĩ logic về nó, đó là: nếu nó tiêu thụ hầu hết window của mình và biết rằng nó sắp hết, có thể nó nhận thức được rằng nó sắp hết, có thể không. Nhưng dù sao đi nữa, tôi đã có kinh nghiệm thực tế là khi yêu cầu của tôi không rõ ràng, tôi cảm thấy nó chọn cách khắc phục dễ nhất trong tất cả. Chỉ là cách dễ nhất, ngược lại với trường hợp tôi dành rất nhiều thời gian để tìm đúng tệp, tham chiếu tệp đó, thực sự nỗ lực hướng dẫn nó trong bóng tối, có thể cho nó một chiếc đèn pin, và sau đó nói, "Đây là vấn đề. Tôi nghĩ đây là tệp có vấn đề." Và sau đó nó kiểu như, "Ồ, vâng, bạn đúng rồi. Và bây giờ tôi sẽ thực sự khắc phục hết lần này đến lần khác." Và tôi đã thấy điều đó bởi vì một lần nữa, tất cả những gì tôi làm là đọc đầu ra. Agent khiến tôi học cách sử dụng nó, vì vậy mọi người đọc... tôi không biết mọi người đọc gì, nhưng tất cả những gì tôi đọc là đầu ra. Tôi không đọc mã và sẽ là sau này, bởi vì tôi biết rằng nó có thể làm tốt hơn tôi rất nhiều. Một lần nữa, tôi cảm thấy nếu có một câu nói hay mà tôi từng đọc, tôi xin lỗi tác giả vì tôi không thể nhớ ngay, nhưng nó kiểu như: giới hạn của AI không phải là trí thông minh của model. Mà là những gì model nhìn thấy trước khi nó hành động, đúng không? Vì vậy, đó là giới hạn hiện tại. Bạn đang để lộ điều gì? Chúng ta nói về thời gian tiếp xúc đối với con người. Những gì bạn đang để lộ agent của mình cũng quan trọng, nếu không muốn nói là quan trọng hơn, trước khi nó thực hiện các chỉnh sửa mã.

Các tệp lập kế hoạch cốt lõi (MD files) cho Agent AI

Người phỏng vấn: Quay lại những tệp này, tôi nghĩ điều này thực sự quan trọng. Vậy hãy nghĩ về MVP cho một người muốn làm điều này tốt hơn. Bạn đã liệt kê tất cả các loại tệp này, những MD files này về cơ bản, mà bạn xây dựng trong một ngày trước khi thực sự bắt đầu xây dựng. Bạn có design guidelines, user journey tasks, agents MD, rules MD. Giả sử bạn muốn tiến thêm một bước và làm tốt hơn những điều này. Bạn sẽ tạo những tệp nào? Và chúng trông như thế nào? Nội dung bên trong những tệp này là gì?

Người nói: Vâng. master plan là cái đầu tiên, nó giống như một cái nhìn tổng quan từ 10.000 feet. Nó giải thích rất tổng quát về ý định của tôi với ứng dụng này.

Người phỏng vấn: Đây là master plan.MD? Bạn gọi nó là vậy à?

Người nói: Đúng vậy. Vâng. Master plan.MD. Và nó thực sự chỉ là, "Này, đây là lý do tại sao tôi làm điều này. Đây là đối tượng tôi làm cho." đây là cách tôi muốn họ cảm nhận. Và rất nhiều lần trong master plan tôi sẽ tham chiếu các PRDs khác, tôi sẽ nói kiểu như design cần phải hiện đại và bóng bẩy, nhưng để biết các thông số cụ thể, hãy tham khảo và đọc design guidelines.MD. Vì vậy, tôi chỉ sử dụng master plan như một cái nhìn tổng quan cấp cao để đưa agent vào trạng thái "Ồ, được rồi, chúng ta đang xây dựng XYZ." Sau đó là implementation plan, bởi vì cần phải có một thứ tự nhất định. Nếu bạn chỉ đổ mọi thứ lên nhau mà không có thứ tự, bạn sẽ không bao giờ đạt được mục tiêu cuối cùng.

Người phỏng vấn: Và đây là tasks.md? Bạn gọi nó là vậy à?

Người nói: Không, đó là implementation plan. Tôi gọi nó là implementation plan. Vâng.

Người phỏng vấn: Được rồi.

Người nói: Và implementation plan kiểu như phục vụ cho tasks.md trong tương lai. Tất cả các tệp này đều phục vụ cho việc xây dựng tasks.md. Khi bạn xây dựng tasks.md thì phần còn lại gần như không liên quan. Nó chỉ là cơ sở để bạn xây dựng tasks để thực thi, đúng không? implementation plan là lớp đầu tiên, một lần nữa, là cái nhìn tổng quan cấp cao hơn. Nó không đi sâu vào chi tiết về cách đạt được điều đó. Nó chỉ giải thích kiểu như, "Ồ, nếu chúng ta đang xây dựng cái này, tôi nghĩ chúng ta nên bắt đầu với backend và chúng ta nên bắt đầu với tables, rồi sau đó là authentication, và sau đó chúng ta sẽ đưa API vào, và sau đó chúng ta sẽ làm điều này." Nó giống như, một lần nữa, hãy nghĩ về nó như việc tôi đang tiết kiệm. Tôi là một người chuyên về ý tưởng. Tôi đang ngồi với một người kỹ thuật. Là tôi và bạn. Chúng ta đang xây dựng công ty khởi nghiệp của mình. Tôi biết bạn là một software engineer theo nền tảng, và tôi đang kể cho bạn ý tưởng của tôi, đúng không? Tôi đưa cho bạn master plan. Và bạn quay lại với tôi và nói, "Được rồi, nếu bạn muốn làm điều này, nó khả thi. Đây là cách tôi sẽ sắp xếp nó." Giống như bạn có một roadmap. Bạn không mở Linear của mình và bắt đầu viết features và RFCs và các thứ khác. Bạn chỉ đang nói ở cấp độ cao về thứ tự của mọi việc.

Phát triển sản phẩm với sự hỗ trợ của AI

Sau đó, tôi và bạn, với tư cách là hai nhà đồng sáng lập, sẽ thảo luận và nói: "Được thôi, nếu chúng ta đồng ý với điều này, thì nó nên trông như thế nào, nó nên mang lại cảm giác gì?" Chúng ta sẽ mô tả ở cấp độ cao, nhưng vì tôi sử dụng AI, tôi có thể đi sâu hơn một chút. Đó là nơi tôi muốn thấy Lovable hoặc bất kỳ tool nào khác phát huy tác dụng – ChatGPT làm rất tốt điều này. Tôi thậm chí đã tự xây dựng các custom GPT của riêng mình. Vì vậy, nếu mọi người muốn bắt đầu ở đâu đó trước khi sử dụng bất kỳ tool nào, họ có thể vào ChatGPT Store, tìm kiếm GPT và chỉ cần gõ "Lovable Bass Prom Generator" hoặc "Lovable PRD Generator" để tìm những GPT mà tôi đã tạo. Chỉ cần "đổ" tất cả ý tưởng vào đó và nhận được các tệp đầu ra.

Đúng không? Tôi muốn thấy một số yếu tố CSS trong các hướng dẫn thiết kế, bởi vì bạn biết đấy, với thiết kế thì hơi phức tạp một chút. AI đôi khi quá sáng tạo. Đó là lúc tôi thực hiện việc điều hướng kỹ thuật nhiều hơn. Cuối cùng, đó là về hành trình người dùng: nếu chúng ta biết mọi thứ trông như thế nào, nếu chúng ta biết chúng mang lại cảm giác gì, nếu chúng ta biết chúng ta đang xây dựng gì ở cấp độ cao – chỉ rất cao thôi – thì mọi người sẽ điều hướng như thế nào? Những tính năng nào có trong đó? Và những thứ tương tự, rồi đến tasks.mmd. Nó đi sâu vào chi tiết như: "À, nếu bạn muốn những hành trình người dùng này và muốn backend được xây dựng trước, thì đây là một bộ task mà tôi cần thực hiện." Nó chỉ nhận đầu vào đó. Tôi chỉ để tool thực hiện công việc tỉ mỉ mà con người từng phải bỏ ra rất nhiều thời gian. Tôi cảm thấy với những tool này, chúng ta đều đang trở thành những quản lý sản phẩm được cường hóa. Chúng ta chỉ đơn giản là tận dụng AI, nhưng tôi nghĩ những quản lý sản phẩm giỏi không được trả công cho việc viết PRD tốt; họ được trả công cho việc đánh giá tốt. Ai đó khác có thể làm phần viết. Bạn, với tư cách là người định hướng và xây dựng sản phẩm này, cần biết cái gì sẽ hữu ích, cái gì sẽ có gu thẩm mỹ, cái gì thực sự tạo ra sự khác biệt.

Tôi muốn nói một điều: chỉ vì tôi quá nhấn mạnh vào việc bạn cần "rèn luyện gu thẩm mỹ" không có nghĩa là bạn không nên xây dựng. Bạn sẽ giỏi hơn bằng cách thực sự xây dựng. Vì vậy, mọi người đang nghe điều này nên thực sự đi và xây dựng một cái gì đó ngay hôm nay. Một, hai, ba, bốn, năm dự án. Hãy thử tất cả những tool này, vì đó là cách bạn đạt được sự rõ ràng, không chỉ bằng cách đọc mà còn bằng cách thực hiện.

Nhà tài trợ: WorkOS - Giải pháp cho phần mềm doanh nghiệp

Đây là một câu đố dành cho bạn: OpenAI, Cursor, Perplexity, Vercel, Platt và hàng trăm công ty thành công khác có điểm chung gì? Câu trả lời là tất cả đều được hỗ trợ bởi nhà tài trợ của chúng tôi hôm nay, WorkOS. Nếu bạn đang xây dựng phần mềm cho doanh nghiệp, bạn có thể đã cảm thấy khó khăn khi tích hợp single sign-on, SCIM, RBAC, audit logs và các tính năng khác mà khách hàng lớn yêu cầu. WorkOS biến những trở ngại trong giao dịch đó thành các API có thể tích hợp dễ dàng với một nền tảng nhà phát triển hiện đại được xây dựng [nhạc nền] đặc biệt cho B2B SaaS. Cho dù bạn là một seed-stage startup đang cố gắng giành được khách hàng doanh nghiệp đầu tiên hay một unicorn đang mở rộng toàn cầu, WorkOS là con đường nhanh nhất để trở nên sẵn sàng cho doanh nghiệp và mở khóa tăng trưởng. Về cơ bản, họ là Stripe cho các tính năng dành cho doanh nghiệp. Truy cập workos.com để bắt đầu hoặc chỉ cần liên hệ với bộ phận hỗ trợ Slack của họ, nơi có các kỹ sư thực sự trả lời câu hỏi của bạn cực nhanh. WorkOS cho phép bạn xây dựng như những người giỏi nhất với các API dễ sử dụng, tài liệu toàn diện và trải nghiệm nhà phát triển mượt mà. Hãy truy cập works.com để làm cho ứng dụng của bạn sẵn sàng cho doanh nghiệp.

ROI vượt trội và tầm nhìn về coding chuyên nghiệp

Hôm nay, tôi hình dung những người nghe điều này có thể bắt đầu cảm thấy: "Ôi chao, việc này tốn quá nhiều công sức. Tôi chỉ cần ngồi đây và tạo tất cả các quy tắc này, tìm ra tất cả những chi tiết nhỏ này." Một mặt, đúng là như vậy. Mặt khác, bạn chỉ mất vài giờ, có thể một ngày để lên kế hoạch, và sau đó bạn có AI xây dựng thứ mà lẽ ra phải mất hàng tuần, hàng tháng. Khoản đầu tư để đạt được điều này mang lại ROI (Tỷ suất hoàn vốn) phi lý. Điều này cũng cho bạn thấy phong cách coding chuyên nghiệp trông như thế nào. Mọi người hình dung VIP code: "Tôi chỉ ngồi đây gõ gõ mấy thứ, làm cái này đi." Nếu bạn thực sự muốn xây dựng một thứ gì đó thực sự tuyệt vời, tạo ra sự khác biệt như bạn đã nói, giải quyết vấn đề thực sự của mọi người, tồn tại lâu dài, mở rộng được quy mô, thì đây là cách bạn làm điều đó nếu bạn thực sự muốn làm công việc này một cách chuyên nghiệp và cũng nếu bạn muốn xây dựng những thứ thực sự tuyệt vời.

Ưu điểm của nguyên mẫu (Prototyping) với Lovable

Đừng hiểu lầm tôi, rõ ràng là có rất nhiều giá trị trong việc xây dựng nguyên mẫu (prototyping). Có rất nhiều người có thể đang xem điều này và nghĩ: "Được rồi, tôi muốn sử dụng Lovable tại nơi làm việc nhưng tôi không thể" hoặc đại loại vậy. Có nhiều lý do khác nhau. Có thể bạn làm trong ngành y tế hoặc tài chính hoặc có một quy định nào đó ngăn cản bạn push to production. Việc xây dựng vì mục đích tạo nguyên mẫu là một trong những trường hợp sử dụng tốt nhất. Phương châm của chúng tôi cho năm 2025 là "thực hiện bản demo thay vì viết báo cáo", tức là thay vì viết tất cả các tài liệu này, nói chuyện và ngồi họp với các kỹ sư để truyền đạt tầm nhìn của bạn với tư cách là một nhà tiếp thị hoặc nhân viên bán hàng trong văn phòng, hãy vào Lovable và xây dựng nguyên mẫu trong 30 phút rồi giao nó.

Tôi có một công việc thực tế mà tôi đã làm trước Lovable và đó chính xác là những gì đã xảy ra. Vào thời điểm này năm ngoái, tôi cần xây dựng một thứ gì đó đạt tiêu chuẩn doanh nghiệp (enterprise grade) và Lovable cùng bản thân tôi lúc đó chưa đủ khả năng để xây dựng nó. Nhưng tôi có một nhóm kỹ sư mà tôi đã làm việc cùng. Tôi đã xây dựng nguyên mẫu trong bốn giờ và họ thực sự đã có thể tái tạo nó sáu đến bảy tháng sau đó để đưa vào sản xuất, kết nối tất cả các đường ống và mọi thứ. Nhưng nếu tôi phải mô tả nó, tôi sẽ nói rằng tôi sẽ mất ít nhất một hoặc hai tuần chỉ để viết ra lời. Tôi chỉ ngồi và xây dựng nó trong bốn giờ. Và đó là Lovable của tháng 1 năm ngoái. Lovable ngày nay, tháng 1 năm 2026, đã vượt xa hàng thế kỷ về các chức năng. Nó tốt hơn rất nhiều. Nó thậm chí không phải là một cuộc cạnh tranh.

Vì vậy, tôi nghĩ bây giờ chúng ta đang ở giai đoạn mà, chẳng hạn, tôi dám nói rằng ít nhất một nửa số công ty trong S&P 500 có người làm việc trong đó đang sử dụng Lovable ở một mức độ nào đó. Và chúng tôi có rất nhiều công ty doanh nghiệp thực sự sử dụng các gói doanh nghiệp của Lovable để tạo ra những dự án siêu có ý nghĩa, chẳng hạn như (tôi sẽ không nêu tên) các công ty chia sẻ chuyến đi hàng đầu thế giới, các công ty viễn thông hàng đầu thế giới, các công ty hàng đầu thế giới trong nhiều lĩnh vực: y tế, tài chính. Họ đang tích cực sử dụng Lovable với các nhóm của mình và phản hồi luôn giống nhau: "Vâng, chúng tôi có thể không push to prod, nhưng các nhà tiếp thị của chúng tôi không còn phải chờ đợi kỹ sư nữa. Những người trong bộ phận go-to-market hoặc bán hàng hoặc HR hoặc bất kỳ vai trò nào khác giờ đây tự tin xây dựng các công cụ nội bộ để chúng tôi quản lý chi phí hoặc quản lý việc tiếp nhận nhân viên." Có rất nhiều trường hợp sử dụng như vậy mà bạn đang thấy Lovable và các tool khác được sử dụng để đưa mọi thứ vào sản xuất.

Chia sẻ mẫu và phương pháp tạo tài liệu

Để giúp mọi người thực hiện quy trình làm việc mà bạn đang mô tả với tất cả các tệp MD này, bạn có nghĩ rằng bạn có thể chia sẻ sau khi chúng ta ghi âm những template đơn giản về các tệp này trông như thế nào để mọi người xem và sao chép không?

Tôi sẽ thực sự vào ChatGPT như tôi đã nói và "đổ" ý tưởng vào đó, chỉ cần gõ "Lovable GPT" hoặc "Lovable PRD generator". Bạn sẽ thấy tên tôi ở đó, đúng không? Và tôi là tác giả. Hãy vào đó, "đổ" ý tưởng. Nó sẽ hỏi bạn một vài câu hỏi để làm rõ và chỉ tạo ra bốn tệp cho bạn, và bạn chỉ cần tiếp tục tải lên những tệp đó.

Tuyệt vời. Tuyệt vời. Chúng tôi sẽ liên kết đến điều đó. Vì vậy, không chỉ là: "Đây là một đống tệp." Hãy nói chuyện với tool này. Nó sẽ tạo ra các tệp phù hợp cho bạn và sau đó bạn cắm nó vào Lovable hoặc các tool khác.

Vâng, nó được huấn luyện để suy nghĩ như tôi. Vì vậy, vâng.

Vai trò của AI và sự thay đổi trong phát triển sản phẩm

Ồ, tuyệt vời. Được rồi, đó là hoàn hảo. Nhân tiện, tôi muốn nói về cách bạn đã tự mở khóa bản thân, vì bạn có cả một loạt các mẹo khác ở đó. Nhưng tôi chỉ muốn suy nghĩ lại: thật thú vị khi bạn đang "hóa giải" cách xây dựng sản phẩm từ những nguyên tắc cơ bản, với tư cách là một quản lý sản phẩm, một kỹ sư, một nhà thiết kế. Và bạn đang tìm ra một quy trình làm việc trong đó AI đang giúp lấp đầy tất cả những khoảng trống mà bạn không có với tư cách là một kỹ sư, với tư cách là một quản lý sản phẩm, giúp bạn tạo ra PRD và thiết kế. Vì vậy, tôi nghĩ điều đó thật thú vị, rằng những chức năng này vẫn hoạt động và cần thiết. Bây giờ là bạn và AI giúp tạo ra toàn bộ bộ ba này, vốn luôn tồn tại: quản lý sản phẩm, kỹ thuật và thiết kế.

Và một điều tôi luôn nghĩ là có câu hỏi về việc nền tảng nào sẽ có giá trị nhất trong tương lai này. Có phải là quản lý sản phẩm? Có phải là kỹ sư? Có phải là nhà thiết kế? Tôi luôn nghĩ rằng chức năng quản lý sản phẩm là: công việc của họ là làm rõ, tìm ra cái gì để xây dựng, làm rõ cái gì để xây dựng, rất rõ ràng về các yêu cầu, tìm ra thành công trông như thế nào. Có vẻ như đó là nơi kỹ năng cần thiết nhất. Cũng có một thành phần thiết kế như: làm cho cái này trông tuyệt vời, và có vẻ như đó sẽ là một giá trị đang nổi lên, rằng việc giỏi thiết kế và gu thẩm mỹ và đánh giá sẽ chỉ tăng lên.

Trước khi chúng ta đến những điều bạn đã học được về việc tự mở khóa bản thân, bởi vì rất nhiều lần bạn biết, mọi thứ không đi đúng hướng, có một lỗi. Mà không phải là một kỹ sư, bạn làm gì? Trước khi chúng ta đến đó, bạn có muốn chia sẻ điều gì khác về các mẹo để thành công không?

Nếu chúng ta đo lường thành công theo đúng nghĩa một lần nữa, AI, như bạn đã chỉ ra, bất kể nền tảng của bạn là gì, là một công cụ khuếch đại. Vì vậy, nếu bạn không biết mình đang làm gì, bạn sẽ chỉ tạo ra rác nhanh hơn. Một điều nữa tôi muốn nhấn mạnh là trong thế giới cũ, "đủ tốt là đủ tốt", đúng không? Bởi vì ngay cả việc tạo ra "đủ tốt" cũng không dễ dàng. 10, 15 năm trước, chỉ cần tạo ra là quá đủ. Bạn đã xây dựng một SaaS, ai quan tâm nó trông như thế nào? Nó hoạt động. Nó làm được việc như "Ôi trời ơi, hôm nay tôi làm việc hiệu quả hơn rất nhiều." Nếu "đủ tốt" ở đây, hãy hình dung nó cho mọi người: nếu đây là mức khá tệ, có thể tốt hơn, trung bình, đủ tốt, đẳng cấp thế giới. Nếu đây là khoảng cách giữa "đủ tốt" và "đẳng cấp thế giới", thì bạn đoán xem? Khoảng cách bây giờ là thế này, bởi vì mọi người đều tạo ra "đủ tốt" với AI. Hoàn toàn mọi người đều làm được. Vì vậy, bây giờ việc học hỏi và tối ưu hóa để làm thế nào tôi tạo ra "đẳng cấp thế giới" và "phép màu" là bài học chính cần rút ra hôm nay.

Như bạn đã chỉ ra, tôi nghĩ các quản lý sản phẩm là những người chiến thắng của AI ngày nay vì họ mang lại sự rõ ràng. Nếu tôi là một người thích cá cược, như người ta nói, tôi sẽ đặt cược rằng lớp tiếp theo chiến thắng là các nhà thiết kế, bởi vì chúng ta đang huấn luyện những tool này để trở nên rõ ràng hơn, tốt hơn, đưa ra các quyết định kỹ thuật tốt hơn. Tôi không nghĩ chúng ta sẽ huấn luyện chúng ngay lập tức để đưa ra các quyết định cảm xúc tốt hơn. Và tôi nghĩ thiết kế là tất cả về cảm xúc. Và đó là nơi cần có sự nâng cấp, nâng cao kỹ năng. Đó là sự nâng cấp lớn nhất. Nếu bạn hỏi tôi: "Ồ, điều chính bạn đã khám phá khi tham gia Lovable là gì?" "Kỹ năng cá nhân lớn nhất được nâng cấp là gì?" Làm việc với Felix, Nad, Abby, tất cả những người là nhà thiết kế đã thực sự tạo ra sự thay đổi lớn cho tôi. Tôi nghĩ: "Ồ, vậy đây là cách đẳng cấp thế giới trông như thế nào và đây là những gì cần thiết." Tôi luôn sử dụng phép tương tự rằng tôi muốn "đánh cắp" một trong những thiết kế của họ và đưa nó vào dự án Lovable của tôi. Vì vậy, tôi vào Figma và tôi nghĩ: "Để tôi lấy nền này và chỉ cần đặt nó vào đó." Tôi vào và nhận ra rằng cái mà có thể được giải thích là một hiệu ứng gradient khá đơn giản hoặc tương đối đơn giản lại cần đến 50 lớp khác nhau để tạo ra. Vì vậy, tôi đã nhấp vào thành phần đó.

Tối ưu hóa Thiết kế và Prompt

Tôi từng nghĩ, "Ôi trời ơi, đây không phải ba màu. Đây là 50 màu." Và không chỉ 50 màu, mà là 50 màu với các sắc độ độ mờ khác nhau. Tôi nghĩ, "À, được rồi. Vậy thì đó chính là sự thiếu kết nối lớn mà tôi đã gặp phải từ trước đến nay." Vì vậy, một lần nữa, nếu tôi trả lời trực tiếp câu hỏi của bạn về những mẹo khác là gì, những điều khác là gì thì đó chính là thiết kế, các bạn ạ. Hãy tiếp xúc với những thiết kế tinh xảo. Hãy theo dõi Felix từ Lovable. Anh ấy có một bản tin tuyệt vời. Và để dạy bạn cách prompt cho thiết kế tốt, hãy tìm hiểu về các design style. Tôi không biết Bow House hay glass morphism nghĩa là gì. Hoàn toàn không biết. Vì vậy, tôi đã tự xây dựng một ứng dụng cho việc đó trong Lovable. Tôi cảm thấy cần phải xây dựng một ứng dụng để tìm hiểu những style này. Bây giờ nó đã công khai. Bất kỳ ai cũng có thể xem nó. Nó là một cái gì đó như UI style.loable.app. Tôi không biết chính xác là gì. Nó có khoảng 18 style khác nhau và các prompt để tái tạo chúng. Vì vậy, hãy tìm hiểu ý nghĩa của thiết kế tốt, tìm hiểu tất cả các design style, học cách prompt để đạt được chúng có lẽ là điều mà tôi sẽ tối ưu hóa ở giai đoạn này.

Tương lai của Kỹ thuật phần mềm

Người phỏng vấn: Trong khi chúng ta đang bàn về chủ đề này, anh nghĩ thế nào về vai trò kỹ thuật? Anh có nghĩ rằng sẽ có một tương lai mà các software engineer vẫn cần thiết không? Anh có nghĩ rằng điều đó sẽ biến mất dựa trên kinh nghiệm của anh không?

Người được phỏng vấn: Nó sẽ không bao giờ biến mất. Chúng ta sẽ cần elite engineering hơn bao giờ hết. Bởi vì hãy để tôi nói cho bạn biết điều này: trong một thế giới mà mọi người đều xây dựng và mọi người đang xây dựng mọi thứ, ai sẽ là người bảo trì? Bảo trì các codebase, mở rộng các codebase, duy trì các dự án, bạn biết đấy, những điều đó chắc chắn vẫn sẽ tồn tại. Và rõ ràng AI sẽ giỏi trong việc này, nhưng một lần nữa, điều đó đòi hỏi một cấp độ kỹ năng khác. Xây dựng một cái gì đó là một kỹ năng. Mở rộng, kéo dài và bảo trì nó lại là một bộ kỹ năng hoàn toàn khác. Và chưa kể rằng, trong một thế giới mà mọi người đều xây dựng, infrastructure (cơ sở hạ tầng) sẽ gặp vấn đề. Giống như tất cả chúng ta đều biết và trải nghiệm việc Cloudflare đã gặp sự cố hai hoặc ba lần trong hai hoặc ba tháng qua. Toàn bộ Internet sập. Các elite engineer là những người sửa chữa điều này. Lovable trải qua lượng lớn người dùng mới đổ về. Infrastructure ở đó gặp vấn đề. Các elite engineer là những người xây dựng infrastructure để giữ vững hệ thống. Phải không? Vì vậy, tôi nghĩ chúng ta sẽ cần rất nhiều người với kỹ năng thực sự tốt, kiểu như, ai thực sự xây dựng thế giới cần hỗ trợ hàng tỷ builder bây giờ, bởi vì mọi người sẽ muốn học cách xây dựng mọi thứ. Làm thế nào chúng ta dạy họ? Làm thế nào chúng ta duy trì mọi thứ họ cần, hosting, security, email, connector, API, và những thứ tương tự? Vì vậy, tôi nghĩ sẽ có chỗ cho nó. Nhưng tôi cũng đồng tình với quan điểm của những người như: nếu tôi có một người em trai 18 tuổi và nó hỏi tôi nên làm gì, tôi sẽ nói với nó, hãy đi làm thợ sửa ống nước, bạn biết đấy, đừng đi học bằng CS, hãy học một nghề tốt, bạn biết đấy, vì thế hệ triệu phú mới ở Mỹ thực ra là thợ điện và thợ sửa ống nước, v.v. Phải không? Vì vậy, nó giống như một sự cân bằng, tôi muốn nói vậy. Tôi không biết. Tôi vẫn nghĩ rằng những engineer giỏi với cái nhìn tốt về nơi tương lai đang hướng tới sẽ luôn được cần đến và khan hiếm.

Hội tụ vai trò và "Kỹ sư siêu tốc"

Người phỏng vấn: Một câu hỏi thú vị như vậy. Tôi nghĩ rằng, đúng như anh nói, chắc chắn sẽ có những người cần tiếp tục xây dựng các cỗ máy cung cấp năng lượng cho tất cả những thứ này. Liệu chúng ta có cần các engineer để xây dựng các sản phẩm thực tế, tầng ứng dụng (application layer) không? Đó mới là câu hỏi. Liệu mọi người có trở thành như anh không? Liệu mọi thứ có trở thành hoặc designer là tất cả những gì chúng ta cần không?

Người được phỏng vấn: Mọi người sẽ trở thành một engineer, và hãy nói về điều đó: tôi cảm thấy mình là một rapid engineer. Tôi sẽ gọi mình là một rapid engineer trong một năm tới, bởi vì vibe coding sẽ chỉ là coding trong 12 tháng tới, và ngay cả hôm nay, chúng ta đã nói về điều này trước đó, có bao nhiêu elite engineer công khai thừa nhận rằng họ không còn hand-coding hoặc manually coding nữa, bất kể bạn muốn gọi nó là gì. AI viết tất cả code. Tôi dùng phép so sánh ở đây là coding sẽ giống như thư pháp. Việc bạn viết code sẽ tương đương với việc bạn in ấn tinh xảo lên một tấm vải canvas và mọi người sẽ nói "Ôi trời ơi, bạn đã viết code đó, thật tuyệt vời." Nó sẽ trở nên hiếm đến mức trở thành một nghệ thuật. Nó sẽ không bị commoditized hoàn toàn như nó đã từng ở một khía cạnh nào đó. Hầu hết các elite vibe coder đều dựa vào AI. Một lần nữa, đó là một công cụ khuếch đại, phải không? Vì vậy, tôi nghĩ mọi người sẽ trở thành một engineer trong thế giới tương lai, một designer, một PM, mọi người đều là một forward deployed engineer hoặc một AI assistant engineer hoặc một LLM engineer hoặc một vibe coder. Thuật ngữ đó không quan trọng. Tất cả chúng ta đều đang sử dụng các LLM để tạo ra đầu ra thô dựa trên những đánh giá đúng đắn. Hoặc đánh giá sai lầm.

Người phỏng vấn: Ồ, đúng vậy. Về cơ bản, những biểu đồ Venn của engineer, designer, PM từng rất tách biệt. Bây giờ chúng đang hội tụ, và những người có chuyên môn sâu hơn về PM, engineering, design sẽ có thể làm được những điều tương tự. Về cơ bản, tất cả các vai trò đang hội tụ. Thật là một thời đại để sống và thật khó để dự đoán chính xác tất cả những điều này sẽ diễn ra như thế nào, nhưng thật vui khi suy đoán.

Khắc phục sự cố: Khung 4x4 để gỡ lỗi

Tôi muốn quay trở lại việc khi bạn gặp bế tắc. Nói về các elite engineer, có những điều thực tế là bạn vẫn đang viết code bằng các tool này. Đôi khi code gặp lỗi, bug được đưa vào, có một vấn đề lạ về database, có một vấn đề mạng nào đó. Bạn làm gì khi bị mắc kẹt? Bạn có một workflow nào để tự mình tháo gỡ không?

Người được phỏng vấn: Vâng, câu hỏi tuyệt vời và hoàn toàn đúng. Dù bạn có một kế hoạch tốt đến đâu, bạn vẫn sẽ gặp vấn đề cuối cùng. Và tôi có một khung nhỏ mà tôi gọi là 4x4. Chỉ là một phép ẩn dụ thôi, phải không? 4x4. Nếu xe của bạn có nó, bạn sẽ thoát khỏi bùn dễ dàng hơn nhiều. Vì vậy, theo nghĩa đó, bốn cách khác nhau để gỡ lỗi (debug). Hãy thử mỗi cách chỉ một lần và tôi sẽ giải thích lý do sau.

1. Sử dụng tính năng tự sửa lỗi của agent: Cách đầu tiên là, một lần nữa, mỗi tool đều khác nhau. Tôi sẽ tham chiếu đến workflow của Lovable. Khi có điều gì đó hỏng, agent của Lovable đủ thông minh để nói rằng nó đã mắc lỗi, nó sẽ đánh dấu tin nhắn đó bằng màu cam và thường có một nút nhỏ gọi là "Try to fix" (Thử sửa lỗi). Vì vậy, agent của bạn về cơ bản thừa nhận nó đã mắc lỗi, bạn nhấp vào nút đó và hầu hết các lần khi đó là một vấn đề nhỏ hơn, nó sẽ điều chỉnh hướng đi, khắc phục nó mà không gặp vấn đề gì.

   Bây giờ, rõ ràng có những tình huống khi vấn đề sâu hơn một chút. Bạn nhấp vào "Try to fix" nhưng vấn đề vẫn tiếp diễn, và đôi khi vấn đề vẫn tiếp diễn nhưng agent của Lovable không hề hay biết rằng nó vẫn tiếp diễn, vì vậy không còn nút "Try to fix" nữa. Lovable nghĩ mọi thứ đang hoạt động nhưng thực tế thì không. Thủ phạm ở đó thường là bạn đang sử dụng tích hợp bên thứ ba (third party integration), bạn không cung cấp đủ ngữ cảnh cho Lovable biết phải quan sát cái gì và nhìn thấy cái gì, vì vậy nó không thể thấy rằng vấn đề tồn tại. Bởi vì Lovable, Cursor, Claude Code, bạn có thể gọi tên bất kỳ, tất cả những tool này ngày nay đủ tốt để khắc phục bất kỳ vấn đề nào mà chúng nhận thức được. Một lần nữa, nhận thức là chìa khóa ở đây.

2. Tăng cường nhận thức bằng console logs: Khi chúng không nhận thức được vấn đề, sẽ đến phần thứ hai, đó là: "Được rồi, tôi cần mang lớp nhận thức vào." Và điều tôi làm ở đó là tôi đi và rất đơn giản là mở preview sandbox dev environment của ứng dụng của mình, bất kể là gì, cố gắng chạy hàm bị lỗi, right-click và đọc console log. Mọi trình duyệt đều cho phép bạn chỉ cần đi và đọc console log. Và rất nhiều lần nó sẽ ghi lại mọi thứ. Nếu không, bạn có thể prompt bất kỳ tool nào và nói: "Này, tôi không nghĩ bạn đang nhìn thấy vấn đề, vì vậy thay vì tôi la hét với bạn, hãy cùng nhau tìm nó. Tôi nghĩ đó là vấn đề với XYZ. Tôi muốn bạn viết console logs vào các tệp liên quan để chúng ta có thể giám sát mọi bước trên đường đi. Hãy đưa lớp nhận thức vào phương trình." Nó viết các console logs. Bạn chạy lại nó. Đoán xem? Bây giờ bạn có toàn bộ lịch sử của mọi thứ đã xảy ra. Bạn sao chép nó. Bạn dán nó vào chat của mình. 99% thời gian, điều đó là đủ. Điều đó đã đủ. AI sẽ nói: "Được rồi, hiểu rồi, tìm thấy rồi, đã sửa rồi."

3. Sử dụng tool đánh giá code bên ngoài: Nhưng sau đó có những tình huống mà ngay cả điều đó cũng không đủ. Vì vậy, bạn nghĩ: "Được rồi, tôi cần đi sâu hơn nữa." Và đó là lúc các đánh giá code (code review) và đánh giá (evaluation) phát huy tác dụng. Tool yêu thích của tôi hiện nay cho việc đó là CodeX OpenAI. Điều tôi làm là bất kỳ bản dựng nào tôi thực hiện, tôi sẽ export nó sang GitHub. Lovable cho phép bạn sở hữu code của mình, Cursor cũng vậy, tất cả những tool này đều cho phép bạn có một bản sao của code mà bạn có thể export sang GitHub và sau đó import nó vào bất cứ đâu bạn muốn. Vì vậy, tôi, bạn biết đấy, sử dụng CodeX từ bản beta. Tôi import nó vào đó và sau đó tôi đang sử dụng một external tool. Vì vậy, giống như trong lần thử đầu tiên, nếu bạn nhớ, tôi đã sử dụng tool và tôi hoàn toàn tin tưởng vào tool đó. Trong lần thử thứ hai, tôi tự mình đóng vai trò là người hỗ trợ nhận thức. Trong lần thứ ba, tôi đang sử dụng một external tool làm người hỗ trợ. Giống như tôi sẽ kết nối với CodeX và trò chuyện với CodeX để sau đó khắc phục vấn đề trong Lovable. Tôi không cho phép CodeX thực hiện thay đổi code cho tôi. Rất nhiều người sẽ hỏi tại sao, nó là một mô hình tốt. Tôi chỉ không biết agent của nó đủ rõ. Tôi không muốn đi và sử dụng một tool mà tôi không biết cách điều khiển. Vì vậy, tôi chỉ sử dụng nó cho mục đích chẩn đoán. Và tôi cũng sẽ làm thủ công. Đó là một workflow cũ mà tôi đã có trước CodeX và trước Claude Code, đó là có một tool gọi là RepoMix cho phép bạn nén toàn bộ codebase của mình vào một tệp duy nhất. Bạn tải xuống nó và sau đó tôi tải lên Claude thông thường hoặc ChatGPT và tôi nói: "Đây là những gì tôi đang xây dựng, hãy đọc nó, và đây là vấn đề tôi đang gặp phải, đây là các console logs." Một lần nữa, nó gần giống như có một chuyên gia tư vấn bên ngoài vào thời điểm đó. Bạn đang thuê trợ giúp từ nơi khác vì nhóm của bạn không thể xử lý được.

Người phỏng vấn: Đúng vậy.

4. Quay lại và suy nghĩ lại prompt của bạn: Người được phỏng vấn: Và lần thứ tư thường là tốt nhất, bởi vì vào thời điểm có vấn đề, đó là lỗi của tôi. Dù ego của bạn có lớn đến đâu, các bạn đang xem, đó là lỗi của bạn, tin tôi đi. Bạn đã có một prompt tồi. Bạn đã đưa ra yêu cầu của mình sai cách. Bạn chỉ không muốn thừa nhận điều đó hoặc bạn không thể nhớ rằng mình đã làm vậy, nhưng đó là lỗi của bạn. Vì vậy, một lần nữa, trong Lovable và tất cả các tool khác, bạn có thể hoàn tác (revert back). Có version control được tích hợp trong Lovable, Cursor, Claude Code. Bạn đi và nói: "Được rồi, tôi đã thử ba điều này. Tôi sẽ lùi lại ba bước và tôi sẽ suy nghĩ về prompt của mình nhiều hơn một chút. Hít thở vài hơi, đi dạo, uống cà phê, trở lại với một tâm trí minh mẫn và thử lại." Bởi vì đoán xem? AI chỉ viết code rất nhanh và đôi khi nó vấp phải một hòn đá rất nhỏ và điều đó chỉ xảy ra một lần và không bao giờ nữa. Vì vậy, bạn chỉ cần thực hiện cùng một yêu cầu một lần nữa và thường thì điều đó sẽ khắc phục vấn đề. Nó chỉ là một trở ngại. Nó là một lỗi syntax. Nó là một cái gì đó nhỏ nhặt.

Bước bổ sung: Học hỏi từ agent để cải thiện prompt: Và sau đó tôi làm điều cuối cùng này. Và đây thực sự là điều then chốt. Khi vấn đề được khắc phục, tôi vào chế độ chat và tôi hỏi Lovable. Tôi nói: "Được rồi, tôi cần làm bốn điều khác nhau để khắc phục điều này. Làm thế nào bạn có thể giúp tôi học cách prompt bạn tốt hơn để lần sau tôi gặp vấn đề, chúng ta có thể làm nó chỉ trong một lần?" 99% thời gian tôi nhận được một câu trả lời tuyệt vời đến mức tôi không còn gặp vấn đề không biết phải làm gì lần tới nữa. Một lần nữa, chúng ta tất cả đều cần phải nhận thức và thực tế. Những tool này rất giỏi trong việc làm mọi thứ đúng cách nếu chúng được sử dụng đúng cách. Luôn luôn là lỗi của chúng ta. Tôi nói 90% nhưng thực sự là 100% lỗi của chúng ta. Bởi vì chúng đủ tốt.

Khắc Phục Sự Cố và Tạo Prompt Hiệu Quả với AI

Tôi không động đến việc thay đổi động các token allocation, không tham chiếu đúng tệp, không diễn đạt đúng cách. Với tư cách là một người không phải designer, tôi không biết bất kỳ thuật ngữ nào. Chẳng hạn như không biết các tiêu đề và những thứ tương tự, và đến tận bây giờ tôi vẫn không biết. Vì vậy, khi tôi gặp khó khăn với các prompt rất nhiều lần, tôi sử dụng chat mode để giúp tôi tạo ra một prompt tốt. Bất cứ ai cũng có thể làm điều này. Nếu bạn đang bế tắc, đã 10 giờ tối và không biết phải hỏi gì, hãy chuyển sang chat mode, brain dump (trút bỏ mọi ý tưởng), và nói, "Giúp tôi soạn một prompt tốt hơn. Giúp tôi prompt bạn tốt hơn," và để tool tự prompt một cách hiệu quả. Rất nhiều lần bạn sẽ giải quyết được vấn đề của mình bằng cách không đưa ra chúng ngay từ đầu với những input kém chất lượng.

Ồ, mọi thứ bạn chia sẻ đều rất thú vị. [tiếng cười] Tôi chỉ muốn đào sâu hơn. Để tóm tắt lại chuỗi các bước bạn thực hiện khi gặp khó khăn, điều mà ai cũng sẽ gặp phải.

1. Hỏi tool để tự sửa lỗi: Nhiều lúc nó sẽ báo [tiếng hít mũi] có gì đó sai. "Tôi có thể sửa nó cho bạn không?" và bạn sẽ trả lời, "Làm ơn sửa." Đôi khi cách này sẽ hiệu quả.
2. Thêm debugging message vào console log: Lời khuyên này tôi rất thích, chỉ cần yêu cầu nó thêm nhiều dòng debug vào console log của chính nó để xem điều gì đang xảy ra. Sau đó, bạn có thể hỏi nó, "Được rồi, bây giờ bạn đang xem, hãy nhìn tất cả output của console log của bạn, xem liệu bạn có thể giúp tìm ra vấn đề không."
3. Sử dụng Codeex: Bước thứ ba là đến với Codeex, điều này thật buồn cười. Tôi thường nghe nói rằng Codeex giống như một kỹ sư AI xuất sắc nhất. Karpathy từng đăng tweet về điều này, và chúng tôi cũng đã mời người đứng đầu Codeex tham gia podcast. Anh ấy nói, "Bất cứ khi nào tôi gặp bug khó nhằn nhất, tôi chỉ cần đến với Codeex, để nó chạy trong nửa giờ, và nó sẽ giải quyết được không giống bất kỳ tool nào khác." Vì vậy, việc bạn sử dụng nó là hoàn toàn hợp lý. Ý tưởng ở đây là bạn chỉ Codeex vào code của bạn. Bạn cho nó xem tất cả các console output log, nói cho nó biết vấn đề là gì, và để nó tự tìm ra giải pháp. Tuyệt vời.

Bước cuối cùng này rất tuyệt vời, và đây là điều tôi muốn tập trung. Bạn sử dụng nó như một cơ hội học hỏi để lần sau bạn giải quyết vấn đề nhanh hơn hoặc tránh hoàn toàn. Vậy bạn làm gì ở đó? Bạn hỏi agent, "Được rồi, đây là những gì đã xảy ra. Tôi có thể làm gì? Tôi đáng lẽ phải nói gì? Làm thế nào tôi có thể prompt bạn tốt hơn để có thể giải quyết được ngay lập tức?"

Tối Ưu Hóa Quy Trình với Sự Học Hỏi của Agent

Và thậm chí sâu sắc hơn thế nữa là một khi bạn đã trải qua cuộc hội thoại này, bạn sẽ nghĩ, "Được rồi, hãy loại bỏ hoàn toàn bản thân tôi ra khỏi phương trình một lần nữa, vì tôi sẽ không nhớ cách prompt bạn tốt hơn hai ngày sau đâu." Hãy đưa điều này vào rules. Hãy đưa những gì chúng ta vừa học vào rules.mmd vì dù sao tôi cũng bắt bạn đọc rules mỗi lần. Vậy thì bạn cũng nên ghi lại nó ở đó. Vì vậy, tôi sẽ không prompt bạn tốt hơn đâu. Bạn sẽ tự học rằng tôi ngốc nghếch và bạn sẽ tự prompt mình tốt hơn, đúng không? Một lần nữa, hãy loại bỏ bản thân và di chuyển context. Bạn sẽ giải quyết 99% vấn đề với AI ngày nay.

Quan Sát Agent Output để Học Hỏi

Ý tưởng ở đây là giúp AI xây dựng bộ não và các rule của riêng nó cũng như cách suy nghĩ dựa trên những vấn đề bạn gặp phải. Tuyệt vời. Được rồi. Tôi muốn quay lại điểm bạn đã đề cập vài lần, điều này rất thú vị: ý tưởng bạn quan sát output của agent để tìm hiểu điều gì đang xảy ra. Điều này tôi đã thấy những người khác, Ben Tossel, người mà tôi nghĩ hiện đang ở một factory, đã chia sẻ gần đây. Anh ấy cũng về cơ bản là VIP coding mọi lúc. Anh ấy từng rất giỏi các no code tools trước đây và bây giờ anh ấy hoàn toàn tập trung vào coding. Anh ấy chia sẻ rằng anh ấy đang học cách mọi thứ, cách coding hoạt động và cách các system hoạt động bằng cách xem agent output.

Điều này kết nối với những gì Michael Terrell, CEO của Cursor, đã chia sẻ khi anh ấy tham gia podcast. Anh ấy có tầm nhìn về Cursor sẽ trở thành cái gì đó sau code. Lớp nào chúng ta đang thêm vào trên code mà mọi người không cần phải lo lắng về code nữa? Và tại thời điểm đó là khoảng một năm trước khi chúng tôi trò chuyện, và có vẻ như đây chính là lớp đó: cuộc trò chuyện với agent về những gì nó đang nghĩ và sau đó những gì bạn nói lại với nó. Về cơ bản, đó là tiếng Anh trong một cuộc hội thoại, không giống như pseudo code. Thật thú vị khi cảm thấy mọi thứ đang đi theo hướng đó. Lớp trên code chỉ là suy nghĩ của nó và cuộc trò chuyện của bạn với nó.

Đúng vậy, chính xác. Ý tôi là, một lần nữa, theo một cách nào đó, tôi thực sự tối ưu hóa cho khả năng phán đoán tốt, và một phần của khả năng phán đoán tốt đến từ việc học cách các tool này hoạt động. Bạn cần biết điều gì là có thể. Chúng ta đã nói về điều đó, và tôi biết đôi khi tôi có thể nghe có vẻ mâu thuẫn, phải không? Nhưng đó là bởi vì, như bạn đã nói, thế giới chúng ta đang sống thật thú vị khi mọi thứ mâu thuẫn với nhau. Không biết điều gì là có thể là một lợi thế, nhưng đồng thời, bạn không thể hoàn toàn thờ ơ với một điều gì đó mang tính thực tế.

Bài Học từ Sự Ảo Tưởng về Khả Năng của AI

Để tôi kể về một thất bại của mình đến từ sự ảo tưởng. Hồi đó, khi OpenAI bắt đầu — hay nói đúng hơn là phát hành tính năng image generation nguyên bản trong ứng dụng của họ, đúng không? Vì vậy, bạn có thể vào ChatGPT và yêu cầu "Tạo một hình ảnh của XYZ." Cả thế giới đã bùng nổ, đó là điều lớn nhất từng có. Rõ ràng, điều đầu tiên tôi nghĩ đến là tôi muốn xây dựng một ứng dụng Lullabable. Tôi chỉ muốn xây dựng một wrapper và tạo một công cụ image gen với Lullabable mà không hề nghĩ rằng OpenAI chưa phát hành API cho tính năng đó. Vì vậy, tôi đã dành ít nhất một tuần để cố gắng brute force (ép buộc) làm cho nó hoạt động thay vì chỉ đợi thêm một tuần, vì một tuần sau họ đã có API và tôi đã xây dựng ứng dụng này trong 30 giây. Vấn đề là tôi đã cố gắng làm điều đó khi nó là bất khả thi, bất khả thi.

Tôi nghĩ rằng một lần nữa, đó chỉ là vấn đề thực sự học được điều gì là có thể thông qua việc giao tiếp với agent layer. Và Lullabable cùng tất cả các tool khác hiện đã trở thành agentic, nghĩa là chúng không chỉ viết code mà còn có thể browse the web (duyệt web), read files (đọc tệp), chúng có reasoning and thinking capabilities (khả năng lập luận và tư duy). Đó là lý do tại sao tôi rất đầu tư vào cuộc trò chuyện đó, vì rất nhiều lần nó sẽ nói với tôi, "Này, điều bạn đang cố gắng làm là không thể thực hiện được vào lúc này vì XYZ." Vì vậy, tôi luôn sử dụng những điều đó như một cơ hội học hỏi, và tôi level up nhiều nhất bằng cách ở trong chat mode cho các mục đích planning (lập kế hoạch) và learning (học hỏi), và bởi vì nó một lần nữa phát triển sự rõ ràng, khả năng phán đoán của bạn, hơn là khả năng coding.

Tốc Độ Phát Triển của AI và Tương Lai Công Việc

Một điểm khác bạn đưa ra ở đây mà tôi nghĩ là rất quan trọng là theo thời gian, những tool này sẽ làm được nhiều hơn những gì bạn làm thủ công. Tôi đã nghe điều này từ những người khác đang làm việc này full-time. Về cơ bản, VIP coding là họ có tất cả các workflow, tất cả các file, và sau đó Cursor thêm chúng. Lullabable thêm chúng.

Thật đáng buồn. Ôi, tôi có workflow tuyệt vời này. Nhưng mặt khác, bây giờ nó chỉ đang thực hiện tất cả những điều này trong giây lát.

Một năm trước, một năm trước, nếu chúng ta có một cuộc phỏng vấn, tâm trí bạn sẽ bị thổi bay. Những thứ mà tôi phải làm như những workaround để giải quyết các thiếu sót. Giống như tôi đã xây dựng một course rất thành công về điều đó với Starter Story trong một năm, mọi người cứ nói, "Ôi Chúa ơi, bạn là người duy nhất trên thế giới biết bí mật này." Bây giờ Lullabable giải quyết 99% vấn đề đó một cách nguyên bản. Tôi gần như có thể nói hầu hết những thứ tôi đã dạy mọi người hoặc tôi có một kênh YouTube được đánh giá cao, nhưng có một series 7-day learn how to vibe code with Lullabable mà tôi đã làm vào tháng 3 hoàn toàn obsolete (lỗi thời). Giống như không có gì trong số đó là đúng nữa. Không có gì trong số đó là một vấn đề nữa. Tất cả những điều tôi từng nói, "Ôi, cái này thiếu và cái kia thiếu," thì bây giờ không còn thiếu nữa. Nó có sẵn trong product. Bạn không phải work your way around it (tìm cách khắc phục) nữa, nó chỉ đơn giản là hoạt động, đúng không?

Vì vậy, như tôi nói, đó là horses analogy (ngụ ý về những con ngựa). Tôi không biết bạn đã nghe chưa, rất nhiều người đang tweet về nó, đó là chúng ta bắt đầu chế tạo steam machine vào những năm 1700, phải không? Mất khoảng 200 năm để chế tạo nó. Khi engine được chế tạo và car được đưa lên đường, tôi nghĩ rằng 90% horse population đã bị loại bỏ ở US trong vòng 20 năm. Người đã tweet điều này làm việc tại Clogged Code, phải không? Vì vậy, anh ấy nói, "Bây giờ khi tôi chuyển sang AI, tôi được thuê để làm một công việc, technical job, technical writer, hoặc bất cứ điều gì. Tôi trở nên obsolete sáu tháng sau đó." Giống như con người không có được 20 năm như những con ngựa. Anh chàng được thuê để làm một việc, sáu tháng sau, tôi cần reinvent my role (tái định nghĩa vai trò của mình). Tôi cần evolve nó thành một cái gì đó khác, phải không?

Vì vậy, tôi nghĩ rằng có một evolution (sự tiến hóa) đang đến rất, rất nhanh. Nhưng rất nhiều người sợ hãi trong khi tôi lại cực kỳ phấn khích, bởi vì bạn không thấy sao, vai trò của chúng ta cuối cùng đang đi theo một hướng mà chúng ta đang outsourcing (thuê ngoài) những gì chúng ta vốn ghét phải làm, phải không? Ngồi trong meeting, ghi note, làm spreadsheet. Có thể có những người thích điều đó, nhưng hầu hết mọi người không thích. Chúng ta đang tiến đến một nơi mà chúng ta được thưởng cho những gì thực sự quan trọng: sự rõ ràng, khả năng phán đoán, tư duy. Chúng ta thực sự sẽ được trả tiền để think longer (suy nghĩ lâu hơn) và ponder longer (trầm tư lâu hơn) bởi vì ý tưởng càng được ấp ủ lâu và phân tích kỹ lưỡng thì càng tốt, vì việc xây dựng nó sẽ diễn ra trong chớp mắt, phải không? Nó sẽ diễn ra như thế này. Vấn đề chỉ là bạn có đủ sự rõ ràng về nó, bởi vì đoán xem? Nếu một tool cực kỳ mạnh mẽ và bạn đưa cho nó wrong input, output cũng sẽ tệ hại. Đó là lý do tại sao tôi cảm thấy mình không bao giờ đủ giỏi ở Claude Code, bởi vì tôi không bắt đầu project của mình với đủ sự rõ ràng, và tool quá mạnh mẽ đến nỗi tôi đã misdirected (chỉ sai hướng) hoàn toàn ngay từ đầu, và tôi đã nghĩ, "Ôi, chết tiệt. Đây không phải là điều tôi muốn làm." Vì vậy, đó là lý do tại sao tôi vẫn thấy mình giỏi trong việc sử dụng các tool thuộc về exploratory prototyping path (con đường khám phá nguyên mẫu) hơn là con đường mà các elite engineer (kỹ sư ưu tú) sẽ sử dụng, chẳng hạn.

Kỹ Năng Quan Trọng trong Kỷ Nguyên AI

Tôi yêu sự lạc quan và phấn khích của bạn về những điều này. Tôi nghĩ đối với rất nhiều người, các software engineer, PM, designer hiện tại, có rất nhiều nỗi sợ hãi về tương lai sự nghiệp của họ. Liệu họ có còn phù hợp không? Liệu software engineering skills của tôi có biến mất không? Vậy để tiếp nối chủ đề một chút, nếu bạn đưa ra lời khuyên cho ai đó về những skill nào bạn nghĩ sẽ có giá trị nhất, hoặc AI sẽ đảm nhận ngày càng nhiều động lực mà bạn đang thấy AI đang lấp đầy ngày càng nhiều gap (khoảng trống). Lời khuyên của bạn sẽ là gì về những gì mọi người nên tập trung vào? Điều gì sẽ tiếp tục có giá trị trong tương lai?

Chắc chắn là emotional intelligence (trí tuệ cảm xúc). Chỉ cần hiểu bản chất con người, những thứ đời thực. Tôi nghĩ tất cả chúng ta sẽ trở nên quá mệt mỏi với mọi thứ giả mạo: fake images (hình ảnh giả), fake posts (bài đăng giả), fake profiles (hồ sơ giả), fake this, fake that, fake videos (video giả). Mọi thứ đang trở nên giả mạo và được AI generated (AI tạo ra). Tôi nghĩ rằng con người, khao khát con người, một cách tự nhiên sẽ muốn làm những điều live (trực tiếp) nhiều hơn. Vì vậy, bất cứ điều gì human to human (giữa người với người) sẽ là một điều lớn để scale up (mở rộng), hiểu được dynamics (động lực). Bất cứ điều gì liên quan đến toán học. Nếu đó là một math problem (bài toán), tôi nghĩ Peter Thiel gần đây đã nói rằng những người chỉ làm math stuff (công việc toán học), AI sẽ đến để thay thế bạn. Bất cứ điều gì rất deterministic (có tính xác định), nghĩa là X input bằng Y output và line (đường truyền) khá rõ ràng. AI đã got eaten for lunch (đã nuốt chửng chúng), phải không? Nhưng nếu bạn hiểu cách X đến Y diễn ra trong human dynamic (động lực con người), human relationship layer (lớp quan hệ con người), tôi nghĩ đó là nơi mọi thứ sẽ trở nên tốt đẹp. Vì vậy, nếu chúng ta chuyển nó lại thành một specific skill (kỹ năng cụ thể), tôi sẽ nói lại. Good design (thiết kế tốt), thực sự good design, great design (thiết kế tuyệt vời). Khi tôi nói design, đó là images (hình ảnh), fonts (phông chữ) cũng như copy (nội dung văn bản), copy là một điều lớn.

AI và Tương Lai của Các Kỹ Năng Con Người

Chúng ta, những người đã và đang sống trong kỷ nguyên AI được khoảng hai năm. Tôi cá rằng, nếu có 10 đoạn văn được đặt trước mặt tôi và bạn, chúng ta có thể phân biệt đâu là nội dung do AI tạo ra và đâu là không chỉ trong khoảng 3 giây. Mà chúng ta mới chỉ ở giai đoạn đầu. Vì vậy, kỹ năng viết lách tốt thực sự sẽ trở thành một kỹ năng rất đáng giá, bởi vì mọi người sẽ dễ dàng nhận ra đó là nội dung do AI viết chỉ sau ba từ hoặc ba câu. Thậm chí tôi cũng không còn đọc nội dung do AI tạo ra nữa. Tôi không thích nhìn thấy nó. Tôi muốn trải nghiệm chân thực, nguyên bản của con người.

Vì vậy, tôi nghĩ các kỹ năng của con người... Tôi thậm chí không biết phải diễn tả thế nào, vì tôi không nghĩ chúng ta đang làm tốt việc gán nhãn cho những gì con người giỏi bẩm sinh. Nhưng tôi nghĩ chúng ta sẽ mô tả các mô tả công việc tốt hơn. Chúng ta sẽ có những kỹ sư "ưu tiên con người" (human-first engineers), tôi không biết, hoặc các nhà thiết kế "ưu tiên con người" (human designers). Tôi không biết cách mô tả những vai trò đó. Tương tự như cách Karpathy đã đặt ra thuật ngữ vibe coding. Tôi đã vibe coded trước khi anh ấy làm. Tôi không biết gọi nó là gì. Giống như tôi bắt đầu vibe coding vào tháng 7 năm 2024 và tôi nghĩ anh ấy đã đặt ra thuật ngữ này vào khoảng đầu năm 2025. Vì vậy, tôi đã làm việc đó trong bảy tháng và tôi đã dạy mọi người cách làm trong khoảng ba hoặc bốn tháng thông qua các khóa học, và tôi thậm chí không biết gọi nó là gì vì không có tên. Nó giống như "ồ, tôi chỉ đang sử dụng AI để làm điều này cho mình. Tôi không biết, đại loại thế."

Vì vậy, tôi nghĩ chúng ta sẽ tái định nghĩa một số thuật ngữ, vai trò và những thứ tương tự, nhưng những thứ mang tính tương tác giữa người với người sẽ vẫn tồn tại. Những thứ như "ồ, bạn chỉ là một quản lý trung gian, một người trung gian chỉ dịch thuật mọi thứ"... Tôi có thể dùng lại phép ẩn dụ đó: những người dịch thuật có thể sẽ mất việc. Nhưng những người viết truyện cười, các diễn viên hài thì không. AI sẽ không bao giờ có thể viết một câu chuyện cười hay. Không bao giờ, không bao giờ, không bao giờ. Nó chỉ đơn giản là không có lớp khả năng đó, không hiểu được điều gì là hài hước. Nếu bạn đã từng thử dùng AI để viết truyện cười, chúng thật tệ. Chúng sẽ luôn luôn tệ.

Nhưng nếu bạn dùng AI để dịch mọi thứ từ ngôn ngữ này sang ngôn ngữ khác, nó lại rất giỏi. AI sẽ thay thế những người dịch thuật. Nó sẽ thay thế hầu hết các nhà báo vì nó có khả năng nghiên cứu tốt, nó có thể viết nội dung tốt, vân vân. Nhưng không phải là báo chí ưu tú. Nó sẽ không thể thay thế tất cả các nhà văn. Nó sẽ khuếch đại khả năng của những nhà văn tài năng, những người có thể huấn luyện AI cách viết sách. Ví dụ, một nhà văn xuất chúng có thể đột nhiên viết bảy cuốn sách mỗi năm thay vì chỉ một, đúng không? Vì vậy, điều đó rất nguy hiểm. Nếu bạn là một nhà văn bình thường, hãy cẩn thận. Sẽ không có bất kỳ diễn viên hài nào bị thay thế. Không một ai. Và đó chỉ là niềm tin cá nhân của tôi. AI sẽ không bao giờ có thể tạo ra hài kịch tốt. Điều đó là bất khả thi. Vì vậy, hãy cố gắng tìm sự tương đồng trong ngành của bạn. Tôi vừa đưa ra một ví dụ về kỹ năng viết lách. Viết truyện cười là một kỹ năng siêu tốt đáng để có. Còn việc dịch thuật, tôi rất tiếc phải nói rằng, bạn sẽ không còn có việc làm trong bao lâu nữa. Bạn tốt hơn nên tìm việc khác để làm. Nhưng đó là cách tôi nhìn nhận vấn đề.

Dự đoán về AI và Hài Kịch

[transcript bị gián đoạn] Điều tôi thấy thú vị là phần hài kịch này. Tôi đã gặp một trong những nhà sáng lập của một công ty data labeling, tôi không nhớ là Merkore hay Serge, và anh ấy nói rằng Anthropic đã thuê một nhóm các nhà biên kịch hài của National Lampoon để giúp họ huấn luyện các mô hình. Vì vậy, họ đang làm việc về vấn đề này. Tôi rất yêu thích dự đoán mạnh mẽ này của bạn. Tôi rất tò mò trong một năm tới khi nhìn lại, liệu bạn đã hoàn toàn đúng hay "không, họ cũng đã làm được điều đó."

[transcript bị gián đoạn] Tôi sẽ sai về 95% những điều tôi nói hôm nay, chỉ trong 3 tháng tới. Đó là điều duy nhất tôi có thể nói một cách rất rất tự tin.

[transcript bị gián đoạn] Điều đó có vẻ đúng. Được rồi. Nói về sự nghiệp, một lựa chọn nghề nghiệp thú vị là làm những gì bạn đang làm. Như bạn đã nói, đây là công việc mơ ước của bạn. Đó cũng là công việc mơ ước của rất nhiều người. Con đường nào đã đưa bạn đến công việc này? Và theo bạn, cần những gì để một người có thể theo đuổi nghề này?

Hành trình Sự Nghiệp và Lời Khuyên cho Vibe Coders

Chà, con đường và hành trình cá nhân của tôi không hề tuyến tính. Tôi đã làm rất nhiều thứ trong đời, như các công việc lao động phổ thông, thậm chí làm ở Subway khi còn đang học và những thứ tương tự. Tôi là một kỹ sư theo chuyên môn, nhưng không phải kỹ sư phần mềm. Tôi là kỹ sư lâm nghiệp, không liên quan đến coding, nhưng kỹ thuật vẫn là kỹ thuật. Tôi cảm thấy bạn vẫn phát triển một số kỹ năng nhất định khi làm việc đó. Tôi đã làm phục vụ bàn trong một thời gian dài, vì vậy bạn phát triển một số kỹ năng mềm, bạn hiểu mọi người thích gì, không thích gì. Một lần nữa, các công việc lao động phổ thông dạy bạn sự chăm chỉ và như tôi đã nói, con đường không tuyến tính, nhưng tôi cảm thấy mình giống như một câu chuyện trong bộ phim Slumdog Millionaire, nơi mọi thứ xảy ra với nhân vật đều đưa họ vào vị trí có thể trả lời các câu hỏi trong cuộc thi tốt hơn.

Tôi cũng cảm thấy tương tự, như thể tôi đã làm rất nhiều thứ. Bảy đến tám năm gần đây rõ ràng là dành cho các công ty khởi nghiệp, nhưng làm mọi thứ trừ viết mã: bắt đầu từ community management, social media. Một lần nữa, phân phối đóng vai trò rất quan trọng. Đó là điều chúng ta chưa hề đề cập đến. Trong một thế giới khi mọi người đều đang xây dựng và số lượng người tiêu dùng trên thế giới tương đối giống nhau, làm thế nào để bạn thu hút sự chú ý, đúng không? Và có được sự chú ý, vốn là tài nguyên khan hiếm nhất và sẽ còn khan hiếm hơn nữa.

Nhưng quay trở lại vai trò vibe coder, nếu ai đó nói, "Được rồi, tôi cũng có một nền tảng khá đa dạng và tôi đang vibe coding, làm thế nào để điều này trở thành một công việc?" Với tôi, tôi cảm thấy nó trở thành một công việc bằng cách building in public. Tôi đã trò chuyện với Elena một lần duy nhất, và tôi đã hỏi, "Tại sao lại là tôi? Có rất nhiều vibe coders giỏi. Làm thế nào bạn chọn tôi trong số đông?" Và tôi nghĩ, bạn biết đấy, cô ấy đã cho tôi một vài lý do, nhưng để tóm gọn lại thành một khái niệm, đó là tôi đã building in public và chia sẻ. Như tôi đã nói, tôi đã lập một kênh YouTube và tôi đã chia sẻ tất cả những thất bại và tất cả kiến thức, tất cả các dự án mà tôi đang xây dựng. Tôi đã sử dụng mạng xã hội rất nhiều, LinkedIn là lựa chọn hàng đầu của tôi vì tôi có kiểu nhịp độ đó. Như bạn có thể thấy, tất cả các câu trả lời của tôi đều rất dài và X (Twitter) không phù hợp với điều đó. Bạn cần phải rất đúng trọng tâm để thành công trên X. Vì vậy, tôi thì không.

Vì vậy, tôi đoán, đó chỉ là build in public, chia sẻ kiến thức của bạn, tiết lộ tất cả các bí mật, vì thực sự không có bí mật nào cả. Nếu bạn đang nắm giữ một ý tưởng hay, bạn đang bỏ lỡ cơ hội. Hãy chia sẻ nó ngay lập tức nếu bạn tìm ra điều gì đó. Tôi đã nhận ra điều đó rất sớm. Và, bạn biết đấy, tôi nghĩ rất nhiều người tham gia hackathons những ngày này. Tôi muốn khuyến khích mọi người làm điều đó, hãy tìm những cơ hội đó tại địa phương để kết nối với các builders khác. Lovable đang tuyển dụng trên toàn diện. Hãy xem các vị trí tuyển dụng của chúng tôi. Nó dễ dàng như vậy, đúng không? Chỉ cần ứng tuyển. Thực sự hãy tìm các công ty đang tuyển dụng và tuyển dụng ở các vai trò khác nhau.

Và tôi đã thấy mọi người làm một điều gì đó. Tôi sẽ tiết lộ một bí mật. Một vài người được thuê không phải bằng cách gửi hồ sơ, mà bằng cách gửi Lovable apps. Họ đã xây dựng Lovable apps để thể hiện lý do tại sao họ phù hợp với một vai trò. Và chúng tôi, với tư cách là nhân viên của Lovable, sẽ luôn mở một ứng dụng sử dụng tên miền lovable.appd. Luôn luôn. Nếu bạn gửi tin nhắn trực tiếp (DM) cho tôi, hãy gửi cho tôi một Lovable app. Đừng gửi cho tôi bất cứ thứ gì dài. Hãy gửi cho tôi một ứng dụng cho tôi biết bạn muốn gì từ tôi hoặc bạn hình dung chúng ta sẽ hợp tác và làm việc cùng nhau như thế nào. Đúng không? Vì vậy, có những người tìm cách sáng tạo để thu hút sự chú ý của những người ra quyết định như Elena.

Và tôi muốn nói về kỹ năng. Một lần nữa, chúng ta chỉ đang nhắc lại những điều đã nói ở đây, nhưng tôi nghĩ điều quan trọng là phải lặp lại nó nhiều lần nhất có thể: thực sự phát triển khả năng phán đoán tốt. Thực sự hiểu sâu hơn cách mọi thứ thay đổi khi vibe coding phát huy tác dụng. Có một công ty ngoài kia, tôi sẽ không nêu tên, nhưng họ sử dụng Lovable một cách nghiêm túc. Nó sẽ là một trong những nghiên cứu điển hình chính của chúng tôi, nơi họ thực sự đã thuê các Vibe Coders trước khi Lovable làm. Tôi là kỹ sư Vibe Coding chính thức đầu tiên tại Lovable với chức danh đó, nhưng tôi đã gặp những người ở các công ty mà họ đã thuê họ trước chúng tôi. Những người chỉ là vibe coders, những người chỉ hiểu rằng tốc độ rất quan trọng. Tốc độ vẫn rất quan trọng. Và có một công ty có ba vibe coders làm việc toàn thời gian, tất cả những gì họ làm là chuyển đổi mã nguồn cũ sang Lovable, mang mọi thứ - CRM, CMS, tất cả các bộ công cụ mà họ có và cần - sang đó. Hiện có những người đang tích cực di chuyển mọi thứ sang đó. Có cả các công ty S&P 500 đang đưa kỹ năng Lovable vào mô tả công việc, nói rằng "kỹ năng Lovable được khuyến nghị" trong mục đề xuất.

Vì vậy, để quay lại câu hỏi làm thế nào để trở thành vibe coder chuyên nghiệp. Chà, bạn không cần một công ty để thuê bạn. Bạn có thể tự thuê mình làm một viber chuyên nghiệp trước. Tôi nghĩ lý do tôi phù hợp với Anton và với Elena và với mọi người khác là vì tôi đã làm việc đó rồi. Tất cả những gì tôi làm là thay đổi phương tiện, nhưng tôi đã làm việc đó một cách chuyên nghiệp trước khi được thuê. Vì vậy, đó là chìa khóa: hãy làm công việc mà bạn sẽ làm dù có được thuê hay không.

Đam Mê Xây Dựng và Vượt Qua Nỗi Sợ Hãi

[transcript bị gián đoạn] Thật là một cuộc trò chuyện mở mang tư duy. Tôi yêu cái cách bạn đầy đam mê, hào hứng và có động lực về tất cả những điều này. Cảm giác như có rất nhiều người ngoài kia hiện đang kiệt sức, vỡ mộng, sợ hãi, và bạn thì ngược lại. Bạn đang tận dụng cơ hội này, không chắc nó sẽ đi đến đâu, nhưng cứ đi theo con đường đó.

[transcript bị gián đoạn] Đúng vậy. Và tôi không muốn ngắt lời bạn, nhưng hãy nhìn xem, Lovable cụ thể không phải là một công ty. Bạn có thể nói về nó như một công ty, nhưng tôi không coi nó là một công ty. Nó là một ý tưởng. Nó là một sứ mệnh. Nó là thứ gì đó mạnh mẽ hơn cả internet trong tâm trí tôi, bởi vì internet cho phép chúng ta tiêu thụ, còn Lovable cho phép chúng ta xây dựng. Và bản chất, bản năng của con người là xây dựng, là sáng tạo, đúng không? Và việc có một công cụ ngày nay mà bạn có thể sử dụng, đưa một ý tưởng vào và có thứ gì đó ra đời từ nó, và ai đó sử dụng nó và thấy nó hữu ích. Với tôi, đó là khái niệm điên rồ nhất từ trước đến nay. Đó là ước mơ cả đời của tôi. Tôi có chiếc máy tính đầu tiên khi tôi sáu tuổi và tôi đã tin cả đời rằng tôi sẽ trở thành một kỹ sư phần mềm hoặc tôi sẽ xây dựng, nhưng cuộc sống không đơn giản như vậy đối với tôi. Nó rất phức tạp và thành thật mà nói, trong 5 đến 10 năm qua, tôi gần như đã từ bỏ ước mơ đó. Tôi nghĩ mình sẽ không bao giờ xây dựng được gì cả. Tôi đã thử. Tôi đã cố gắng xây dựng với các đồng sáng lập kỹ thuật, nhưng tôi chỉ không thể tìm thấy sự đồng điệu. Tôi đã từ bỏ nó. Và bây giờ, ở tuổi 36, 30 năm sau, tôi lại cảm thấy như đứa trẻ đó. Tôi mơ mỗi ngày. Thật tuyệt vời những gì điều này cho phép chúng ta làm. Và bất cứ ai đang sợ hãi, hãy thử nó. Nó sẽ chuyển từ sợ hãi sang phấn khích ngay lập tức, bởi vì sau đó bạn sẽ thấy những gì có thể xảy ra tận mắt. Chỉ cần đi vào, xây dựng một cái gì đó, xây dựng bất cứ thứ gì, và nỗi sợ hãi sẽ tan biến. Bạn chỉ nên sợ hãi nếu bạn không làm gì cả. Nếu bạn không làm gì cả, vâng, hãy sợ hãi bằng mọi cách. Và sau đó hãy bắt đầu hành động. Và tin tôi đi, bước nhảy vọt không còn lớn như trước nữa. Nó chỉ lớn như bạn bước vào và nói ra suy nghĩ của mình và chỉ cần triển khai.

Lời Kêu Gọi Hành Động

[transcript bị gián đoạn] Tôi nghĩ một phần lớn của điều này là hãy ngừng nghe podcast này. Hãy bắt tay vào làm việc. Bạn sẽ thực sự thử, đúng không?

[transcript bị gián đoạn] Lý tưởng nhất là mọi người dừng lại ngay bây giờ. Họ đã nghe đủ rồi. Tôi đã đưa ra những gì tốt nhất tôi có thể, hãy ngừng nghe và bắt tay vào làm.

[transcript bị gián đoạn] Được rồi. Tạm biệt mọi người. Được rồi.

Tổng kết và lời khuyên cuối cùng

Tôi chỉ đùa thôi. Nhưng chúng ta hãy kết thúc tại đây. Tôi sẽ bỏ qua phần hỏi nhanh để tập này ngắn gọn hơn. Trước khi kết thúc, ngoài việc "hãy bắt tay vào xây dựng một số thứ", bạn có muốn nói điều gì khác, hay nhắn gửi gì đến người nghe không? Nếu không, chúng tôi sẽ để bạn đi.

Vâng. Tech stack (ngăn xếp công nghệ) không còn quan trọng nữa, đúng không? Nó không quan trọng. Mọi người cứ ám ảnh về việc "cái này được viết bằng HTML à?", "cái này được viết bằng React à?". Điều đó không quan trọng. Thực ra nó chưa bao giờ quan trọng, nhưng bây giờ lại càng ít quan trọng hơn. Người dùng cuối chỉ muốn một trải nghiệm tuyệt vời. Chúng ta đang sống trong một thế giới mà bất kỳ ai cũng có thể tạo ra những thứ "đủ tốt". Vì vậy, bạn nên bắt đầu học cách tạo ra "phép thuật", bởi nếu không, bạn sẽ chỉ hòa mình vào đám đông với hàng triệu người khác.

Nhưng đồng thời, nếu bạn không biết "phép thuật" trông như thế nào, đừng nản lòng mà hãy bắt đầu xây dựng bất cứ thứ gì, bắt đầu từ "đủ tốt" và dần nâng cấp. Cách tốt nhất để nâng cấp là exposure time (thời gian tiếp xúc). Hãy dành nhiều thời gian cho việc học hơn là xây dựng. Đọc agent output (đầu ra của tác nhân). Học cách nó tư duy để bạn biết điều gì là có thể.

Nhưng sau đó, cũng hãy đi tìm cảm hứng. Theo dõi các nhà thiết kế giỏi trên X. Tìm những công cụ tạo ra thiết kế tuyệt vời và theo dõi người sáng tạo của chúng. Có một công cụ mà tôi đang theo dõi chính người đã tạo ra nó, vì anh ấy đăng video gần như hàng ngày, dài 40-50 phút về quá trình thiết kế của mình. Tôi muốn xem một nhà thiết kế đẳng cấp thế giới làm điều đó như thế nào. Tôi muốn thấy anh ấy nói chuyện với tool (công cụ). Tôi muốn thấy anh ấy prompt (nhắc lệnh) và đó là cách tôi học để trở nên giỏi hơn.

Vì vậy, một lần nữa, exposure time. Hãy cố tình dành nhiều thời gian hơn cho việc học hỏi hơn là coding (viết mã), bởi vì bạn có thể code (viết mã) nhanh, nhưng bạn cũng có thể code garbage (viết mã rác) nhanh như code magic (viết mã "phép thuật") vậy. Đó là cùng một lượng thời gian. Chính bạn và đầu vào của bạn mới là điều quan trọng. Hãy quên đi những quyết định về tech stack. Quên việc bạn đang sử dụng backend nào, front end nào. Điều đó không quan trọng. Quality (chất lượng), taste (gu thẩm mỹ), design (thiết kế). Đó là tất cả những gì bạn cần tối ưu trong tương lai phía trước.

Liên hệ và lời kêu gọi tham gia Lovable

Lazar, cuộc trò chuyện này, tôi nghĩ nó sẽ khiến nhiều người phải suy nghĩ rất nhiều. Bạn đã làm tôi ngạc nhiên theo nhiều cách. Thật là một cuộc trò chuyện với chủ đề hấp dẫn. Một cái nhìn thoáng qua về tương lai. Một thời điểm thú vị. Tôi rất tò mò không biết mọi thứ sẽ ra sao trong 6 tháng nữa và liệu chúng ta có thể xem lại cuộc trò chuyện này không. Tôi thực sự cảm ơn bạn đã đến chia sẻ tất cả những điều này. Bạn thật tuyệt vời. Mọi người có thể tìm thấy bạn ở đâu nếu họ muốn liên hệ, có thể hỏi thêm một số câu hỏi và người nghe có thể giúp ích gì cho bạn?

Tuyệt vời. Vâng. À, như tôi đã đề cập rồi. LinkedIn có lẽ là nơi tốt nhất để tìm tôi. Tôi rất hay phản hồi ở đó. Nếu bạn muốn theo dõi tôi, tôi hy vọng sẽ tái khởi động kênh YouTube của mình một chút. Tôi nghĩ tôi có rất nhiều mẹo và thủ thuật hay mà tôi muốn chia sẻ và dạy mọi người cách sử dụng Lovable và vibe code nói chung, cũng như cách nâng cấp bản thân.

Về cách mọi người có thể giúp ích cho tôi: tôi rất đam mê việc đảm bảo mọi người đều trải nghiệm được điều mà tôi đã trải nghiệm vào cái ngày tôi nhận được prompt đầu tiên của mình. Tôi ghen tị với người sẽ dùng thử Lovable lần đầu tiên sau khi xem tập này, vì cảm giác chuyển từ một consumer (người tiêu dùng) sang một builder (người xây dựng) thực sự không thể sánh bằng. Nhưng trong quá trình đó, sẽ có một số trận chiến phải chiến đấu. Tôi muốn giảm thiểu số lượng những trận chiến và hurdles (trở ngại) đó.

Vì vậy, nếu bạn có thể giúp tôi bằng bất kỳ cách nào, hãy nhắn tin cho tôi. Điều gì có thể tốt hơn trong trải nghiệm đó? Đặc biệt nếu bạn vừa xem tập này và nghĩ, "Tôi sẽ làm điều đó. Tôi đã phân vân và giờ tôi sẽ làm." Nếu có gì đó hỏng hóc, nếu có gì đó không kết nối và không liên quan, tôi cần biết điều đó. Công việc của tôi là 100% trao quyền cho bạn để xây dựng công việc tốt nhất trong cuộc đời bạn, đúng không?

Và, bạn biết đấy, tôi cũng cần phải nói điều này vì rất nhiều người có thể được truyền cảm hứng không phải từ việc xây dựng hoặc sử dụng Lovable mà là xây dựng Lovable. Hãy tham gia đội ngũ của chúng tôi. Chúng tôi đang tuyển dụng cho rất nhiều vị trí. Tôi nghĩ nhiều người nên cảm thấy được truyền cảm hứng bởi vì tôi hy vọng năng lượng mà tôi mang lại sẽ gây được tiếng vang. Đây là cảm giác khi làm việc tại Lovable. Đây là cảm giác khi làm việc với những bộ óc tốt nhất, sáng giá nhất trên thế giới. Chúng tôi không phải là số một một cách tình cờ. Đó không phải là một sự trùng hợp. Những người giỏi nhất đang tụ họp và chúng tôi cũng muốn bạn là một phần trong đó. Vì vậy, nếu năng lượng và cuộc trò chuyện này gây được tiếng vang với bạn hoặc nếu bạn nghe về một vấn đề hôm nay và bạn nghĩ, "Chà, tôi nghĩ tôi có thể giải quyết được nó", hãy đến tham gia cùng chúng tôi. Hãy giúp chúng tôi xây dựng và định hình tương lai của phát triển phần mềm.

Thông tin tuyển dụng và lời kết

Thật không thể tin được. Và, trang web là gì? Tôi hình dung đó chỉ là một liên kết trên trang web của Lovable để tìm các vị trí đang tuyển. Chúng tôi sẽ dẫn người nghe đến đó.

Vâng.

Thật tuyệt vời. Lazar, cảm ơn bạn rất nhiều vì đã có mặt ở đây.

Tôi cảm ơn vì cơ hội này.

Tạm biệt mọi người. Cảm ơn các bạn rất nhiều vì đã lắng nghe. Nếu bạn thấy tập này giá trị, bạn có thể đăng ký theo dõi chương trình trên Apple Podcasts, Spotify hoặc ứng dụng podcast yêu thích của bạn. Ngoài ra, xin hãy 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.