Người sáng lập Cursor: Trong thời đại hậu mã hóa, "gu" sẽ ngày càng có giá trị
Tuyển chọn TechFlowTuyển chọn TechFlow
Người sáng lập Cursor: Trong thời đại hậu mã hóa, "gu" sẽ ngày càng có giá trị
Mục tiêu của Cursor là tạo ra một cách lập trình hoàn toàn mới.
Chuyên sâu báo cáo Web3Tác giả: Xin
Là một trong những sản phẩm phát triển nhanh nhất từ trước đến nay, Cursor đạt doanh thu thường niên (ARR) 100 triệu USD chỉ sau 20 tháng ra mắt. Trong hai năm tiếp theo, con số này vượt mốc 300 triệu USD ARR, đồng thời tiếp tục dẫn dắt sự thay đổi trong cách các kỹ sư và đội ngũ sản phẩm phát triển phần mềm. Tính đến đầu năm 2025, Cursor có hơn 360.000 người dùng trả phí.
Michael Truell là đồng sáng lập kiêm CEO của Anysphere - công ty mẹ của Cursor. Ông cùng ba người bạn học MIT đã thành lập Anysphere và ra mắt Cursor chỉ trong ba tháng. Michael Truell rất hiếm khi xuất hiện trên các podcast, trước đây chỉ từng tham gia Lex Fridman Podcast. Trong tập nội dung này, ông chia sẻ về dự đoán đối với "thời kỳ hậu mã nguồn (After code)", những kinh nghiệm phản trực giác trong quá trình xây dựng Cursor, cũng như quan điểm về xu hướng phát triển tương lai của ngành kỹ sư.
Nội dung này được lấy từ Lenny's Podcast, dưới đây là bản dịch toàn văn.
- Mục tiêu của Cursor là tạo ra một phương thức lập trình hoàn toàn mới: Trong tương lai, con người sẽ thấy các đoạn mã giả gần gũi với cấu trúc tiếng Anh hơn. Con người sẽ kiểm soát mạnh mẽ mọi chi tiết của phần mềm, có khả năng sửa đổi và lặp lại cực kỳ nhanh chóng.
- "Thẩm mỹ" (taste) sẽ ngày càng trở nên quý giá: Cốt lõi của "thẩm mỹ" là nhận thức rõ ràng về việc "nên xây dựng cái gì".
- Những người dùng AI xuất sắc nhất lại rất bảo thủ trong ứng dụng công nghệ: Họ đặc biệt giỏi trong việc giới hạn phạm vi nhiệm vụ giao cho AI ở mức nhỏ hơn và rõ ràng hơn.
- Khâu cốt lõi trong quy trình tuyển dụng của Cursor là một bài đánh giá kéo dài hai ngày: Các dự án đánh giá này mang tính mô phỏng nhưng cho phép ứng viên tạo ra kết quả làm việc thực sự trong vòng hai ngày. Đây không chỉ là phép thử "có muốn làm việc cùng hay không", mà còn rất quan trọng để thu hút ứng viên. Đối với các công ty khởi nghiệp giai đoạn đầu, điều duy nhất thu hút người khác gia nhập thường là một đội ngũ mà họ cảm thấy xứng đáng để cùng nhau chiến đấu.
Vấn đề chính của lập trình kiểu chatbot là thiếu độ chính xác
Lenny: Trước đây chúng ta từng nói về chuyện gì sẽ xảy ra trong thời kỳ hậu mã nguồn. Anh nhìn nhận thế nào về định hướng phát triển tương lai của Cursor? Công nghệ sẽ chuyển đổi từ mã nguồn truyền thống sang hình thái khác như thế nào?
Michael Truell:Mục tiêu của Cursor là tạo ra một phương thức lập trình hoàn toàn mới, một cách thức xây dựng phần mềm khác biệt. Bạn chỉ cần mô tả ý định của mình với máy tính theo cách đơn giản nhất, chính bạn sẽ định nghĩa phần mềm nên hoạt động và hiển thị như thế nào.
Cùng với sự trưởng thành liên tục của công nghệ hiện nay, chúng tôi tin rằng có thể mở ra một phương pháp xây dựng phần mềm hoàn toàn mới, hiệu quả hơn, cao cấp hơn và dễ sử dụng hơn so với hiện tại. Quá trình này sẽ rất khác biệt so với cách viết phần mềm ngày nay.
Tôi muốn so sánh điều này với một vài quan điểm phổ biến về hình thái phần mềm tương lai, trong đó có một vài quan điểm phổ biến hiện nay mà chúng tôi không mấy đồng tình.
Một quan điểm cho rằng, việc xây dựng phần mềm trong tương lai vẫn sẽ giống như hiện tại, chủ yếu dựa vào việc chỉnh sửa văn bản bằng các ngôn ngữ lập trình hình thức như TypeScript, Go, C, Rust. Một quan điểm khác cho rằng, bạn chỉ cần nhập lệnh vào chatbot, để nó giúp bạn xây dựng phần mềm và sửa đổi bất cứ lúc nào. Phong cách chatbot này giống như đang trò chuyện với bộ phận kỹ thuật của bạn.
Chúng tôi cho rằng cả hai viễn cảnh này đều có vấn đề.
Vấn đề chính của lập trình kiểu chatbot là thiếu độ chính xác. Nếu bạn muốn mọi người kiểm soát hoàn toàn hình dạng và chức năng phần mềm, bạn cần cung cấp cách thức chỉ định rõ ràng hơn để thực hiện những thay đổi mong muốn, chứ không phải kiểu nói với một robot trong hộp chat "sửa phần này của ứng dụng tôi" rồi toàn bộ bị xóa sạch.
Mặt khác, quan điểm cho rằng mọi thứ sẽ không thay đổi cũng sai lầm, bởi vì công nghệ sẽ ngày càng mạnh mẽ hơn.Trong thế giới "hậu mã nguồn" mà chúng tôi hình dung, cách biểu đạt logic phần mềm sẽ gần gũi với tiếng Anh hơn.
Bạn có thể hình dung nó tồn tại dưới dạng chuẩn hóa hơn, tiến dần về phía mã giả. Bạn có thể viết logic phần mềm, chỉnh sửa ở mức độ cao hơn và duyệt qua dễ dàng. Nó sẽ không phải là hàng triệu dòng mã khó hiểu, tối nghĩa. Thay vào đó, nó sẽ rõ ràng, dễ hiểu và dễ định vị hơn. Chúng tôi đang cố gắng biến các ký hiệu và cấu trúc mã phức tạp thành hình thức dễ đọc và chỉnh sửa hơn cho con người.
Trong thời kỳ hậu mã nguồn, "thẩm mỹ" sẽ ngày càng có giá trị
Lenny: Điều này rất sâu sắc, tôi muốn đảm bảo mọi người hiểu rõ quan điểm của anh. Chuyển đổi mà anh hình dung là con người sẽ không còn nhìn thấy mã nguồn, cũng không cần suy nghĩ theo dạng JavaScript hay Python nữa. Thay vào đó là một hình thức biểu đạt trừu tượng hơn, gần với mã giả theo cấu trúc tiếng Anh.
Michael Truell: Chúng tôi cho rằng cuối cùng nó sẽ phát triển đến giai đoạn đó. Chúng tôi tin rằng để đạt được giai đoạn này cần sự tham gia và thúc đẩy của các kỹ sư chuyên nghiệp hiện tại. Trong tương lai, con người vẫn sẽ ngồi ở ghế lái và giữ vai trò chủ đạo.
Con người sẽ có quyền kiểm soát mạnh mẽ mọi chi tiết của phần mềm, và sẽ không dễ dàng từ bỏ quyền kiểm soát này. Đồng thời, con người cũng có khả năng sửa đổi và lặp lại cực kỳ nhanh chóng. Tương lai sẽ không phụ thuộc vào loại kỹ thuật diễn ra phía sau, chậm chạp và mất hàng tuần để hoàn thành.
Lenny: Điều này dẫn đến một câu hỏi, đối với các kỹ sư hiện tại, hoặc những người đang cân nhắc trở thành kỹ sư, nhà thiết kế hay quản lý sản phẩm, anh cho rằng trong "thời kỳ hậu mã nguồn", kỹ năng nào sẽ ngày càng có giá trị?
Michael Truell: Tôi cho rằng "thẩm mỹ" (taste) sẽ ngày càng có giá trị. Khi người ta nói về "thẩm mỹ" trong lĩnh vực phần mềm, họ thường nghĩ đến hiệu ứng hình ảnh, hoạt ảnh mượt mà, phối màu, UI, UX, v.v.
Hình ảnh rất quan trọng đối với sản phẩm. Nhưng như đã đề cập trước đó, tôi cho rằng một nửa quan trọng khác nằm ở logic sản phẩm và cách vận hành.
Chúng ta có rất nhiều công cụ để thiết kế hình ảnh, nhưng mã nguồn vẫn là hình thức biểu đạt tốt nhất cho logic phần mềm. Bạn có thể dùng Figma để minh họa hiệu ứng, hoặc phác thảo sơ bộ trong ghi chú. Nhưng chỉ khi bạn có nguyên mẫu thực sự khả dụng, logic mới hiện rõ.
Kỹ sư tương lai sẽ ngày càng giống "nhà thiết kế logic" hơn. Họ cần diễn đạt chính xác ý định, chuyển từ "làm thế nào" ở hậu trường sang "làm gì", "là gì" ở mức độ cao hơn, điều này có nghĩa "thẩm mỹ" sẽ ngày càng quan trọng hơn trong phát triển phần mềm.
Hiện tại, trong kỹ thuật phần mềm chúng ta chưa đạt đến bước đó. Trên mạng lan truyền nhiều đoạn hài hước thú vị và sâu sắc, phản ánh việc người ta quá phụ thuộc vào AI phát triển, khiến phần mềm có lỗi rõ rệt và vấn đề chức năng.
Nhưng tôi tin rằng kỹ sư phần mềm tương lai sẽ không cần chú trọng kiểm soát chi tiết như hiện nay, chúng ta sẽ dần chuyển từ sự tỉ mỉ nghiêm ngặt sang coi trọng "thẩm mỹ" hơn.
Lenny: Điều này khiến tôi nghĩ đến vibe coding. Có phải điều này tương tự như cách lập trình mà anh mô tả, không cần quá lo lắng về chi tiết, mà thuận theo cảm hứng?
Michael Truell: Tôi cho rằng hai thứ này có liên quan. Vibe coding mà người ta đang nói đến hiện nay, theo tôi mô tả một chế độ sáng tạo gây tranh cãi, tức là tạo ra lượng lớn mã nguồn mà không thực sự hiểu chi tiết. Chế độ này sẽ gây ra nhiều vấn đề. Nếu không hiểu chi tiết nền tảng, bạn sẽ nhanh chóng nhận ra thứ mình tạo ra trở nên quá khổng lồ, khó sửa đổi.
Thực tế điều chúng tôi quan tâm là:Làm thế nào con người có thể kiểm soát hoàn hảo mọi chi tiết, dù không hoàn toàn hiểu mã nguồn nền tảng. Giải pháp cho vấn đề này liên quan mật thiết đến vibe coding.
Chúng ta hiện vẫn thiếu khả năng để "thẩm mỹ" thực sự dẫn dắt việc xây dựng phần mềm. Một vấn đề của vibe coding hoặc các mô hình tương tự là, mặc dù bạn có thể tạo ra một thứ gì đó, nhưng nhiều quyết định vụng về là do AI đưa ra, và bạn không thể kiểm soát hoàn toàn.
Lenny: Anh vừa nhắc đến "thẩm mỹ". Cụ thể là gì?
Michael Truell: Là có một ý tưởng rõ ràng về "nên xây dựng cái gì". Ý tưởng này cũng có thể ngày càng dễ dàng chuyển hóa, đây là thứ bạn muốn tạo ra, nó trông như thế này, vận hành như thế này.
Không giống như hiện nay, bạn và nhóm có ý tưởng sản phẩm, nhưng vẫn cần một lớp phiên dịch, phải tốn rất nhiều công sức và lao động để chuyển nó thành định dạng máy tính có thể hiểu và thực thi.
"Thẩm mỹ" không liên quan nhiều đến UI. Có lẽ từ "thẩm mỹ" dùng ở đây không thật sự phù hợp, nhưng cốt lõi là nhận thức đúng đắn về "nên xây dựng cái gì".
Sự ra đời của Cursor bắt nguồn từ việc khám phá một câu hỏi
Lenny: Tôi muốn quay lại nguồn gốc của Cursor, nhiều người nghe có thể chưa biết nó ra đời như thế nào. Các anh đang xây dựng một trong những sản phẩm tăng trưởng nhanh nhất lịch sử. Cursor đang thay đổi sâu sắc cách mọi người xây dựng sản phẩm, thậm chí đang thay đổi toàn ngành. Tất cả bắt đầu như thế nào? Những khoảnh khắc đáng nhớ nào trong quá trình phát triển ban đầu?
Michael Truell: Sự ra đời của Cursor bắt nguồn từ việc chúng tôi khám phá một câu hỏi, và phần lớn là từ suy nghĩ của chúng tôi về việc AI sẽ trở nên tốt hơn thế nào trong thập kỷ tới. Có hai thời điểm then chốt.
Thứ nhất là lần đầu tiên sử dụng bản beta của Copilot. Đây là lần đầu tiên chúng tôi tiếp xúc với một sản phẩm AI thực dụng, thực sự hữu ích, chứ không phải demo hoành tráng. Copilot là một trong những công cụ phát triển có giá trị nhất mà chúng tôi từng sử dụng, khiến chúng tôi cũng rất phấn khích.
Thứ hai là các công ty như OpenAI công bố loạt bài nghiên cứu về việc mở rộng mô hình (Scaling). Những nghiên cứu này cho thấy, ngay cả khi không có ý tưởng mới mang tính đột phá, chỉ cần mở rộng quy mô mô hình và tăng lượng dữ liệu huấn luyện, khả năng của AI cũng sẽ ngày càng mạnh lên. Vào cuối năm 2021 đến đầu năm 2022, chúng tôi rất tin tưởng vào triển vọng sản phẩm AI, công nghệ này chắc chắn sẽ trưởng thành trong tương lai.
Khi chúng tôi nhìn quanh, nhận thấy dù rất nhiều người đang nói về việc làm mô hình, nhưng ít ai thực sự đi sâu vào một lĩnh vực công việc tri thức cụ thể, để suy nghĩ về việc lĩnh vực đó sẽ tiến bộ ra sao khi công nghệ AI phát triển.
Điều này khiến chúng tôi tự hỏi: Khi công nghệ ngày càng trưởng thành, những lĩnh vực cụ thể này sẽ thay đổi thế nào trong tương lai? Hình thái công việc cuối cùng sẽ như thế nào? Công cụ chúng ta dùng để hoàn thành công việc sẽ tiến hóa ra sao? Mô hình cần đạt đến mức độ nào để hỗ trợ những thay đổi hình thái công việc này? Khi việc mở rộng mô hình và tiền huấn luyện (pre-training) không thể nâng cao thêm, chúng ta sẽ tiếp tục đột phá ranh giới khả năng công nghệ như thế nào?
Lỗi sai đầu tiên Cursor mắc phải là ban đầu chọn một lĩnh vực cạnh tranh ít, khá tẻ nhạt. Không ai quan tâm đến lĩnh vực buồn tẻ này.
Thời điểm đó, mọi người đều cho rằng lập trình rất nóng, rất thú vị, nhưng chúng tôi lại cảm thấy đã có quá nhiều người làm rồi.
Trong bốn tháng đầu tiên, chúng tôi thực sự đang làm một dự án hoàn toàn khác—giúp tự động hóa và tăng cường cho kỹ sư cơ khí, xây dựng công cụ cho kỹ sư cơ khí.
Nhưng ngay từ đầu đã gặp vấn đề, tôi và các đồng sáng lập đều không phải kỹ sư cơ khí, dù có bạn bè trong lĩnh vực này, nhưng chúng tôi cực kỳ xa lạ, có thể nói là "sờ voi", ví dụ như làm thế nào để áp dụng mô hình hiện tại thực sự vào kỹ thuật cơ khí? Kết luận lúc đó của chúng tôi là phải phát triển mô hình riêng từ con số 0. Cách làm này rất rắc rối, vì gần như không có dữ liệu công khai trên mạng về các mô hình 3D và bước xây dựng của các công cụ và linh kiện khác nhau, và việc lấy mô hình từ các kênh sở hữu tài nguyên này cũng rất khó khăn.
Nhưng cuối cùng chúng tôi tỉnh táo lại, nhận ra mình không thực sự hứng thú với kỹ thuật cơ khí, đây không phải điều chúng tôi sẵn sàng dành cả đời để theo đuổi.
Nhìn lại lĩnh vực lập trình, dù đã qua một thời gian khá dài, nhưng chưa có thay đổi đáng kể nào. Những người làm trong lĩnh vực này dường như lạc nhịp với suy nghĩ của chúng tôi, họ thiếu tham vọng và tầm nhìn đủ lớn về định hướng phát triển tương lai, về việc AI sẽ tái cấu trúc mọi thứ ra sao. Chính những nhận thức này đã thúc đẩy chúng tôi đi trên con đường xây dựng Cursor.
Lenny: Tôi rất thích lời khuyên kiểu như hãy theo đuổi những ngành nghề tưởng chừng tẻ nhạt, vì nơi đó cạnh tranh ít, có cơ hội, đôi khi điều này thực sự khả thi. Nhưng tôi thích hơn một tư duy khác—táo bạo theo đuổi những lĩnh vực nóng nhất, phổ biến nhất, ví dụ như lập trình AI và phát triển ứng dụng, và hóa ra điều này cũng khả thi.
Các anh cảm thấy các công cụ hiện tại thiếu tham vọng hoặc tiềm năng, còn nhiều việc có thể làm. Tôi cho rằng đây là một启示 rất có giá trị. Ngay cả khi một lĩnh vực dường như đã quá muộn, ví dụ như GitHub Copilot đã tồn tại, nếu anh phát hiện các giải pháp hiện tại còn tham vọng chưa đủ lớn, không đáp ứng được tiêu chuẩn của anh, hoặc có khuyết điểm trong phương pháp, thì vẫn ẩn chứa cơ hội to lớn. Có phải vậy không?
Michael Truell: Hoàn toàn đồng ý. Chúng tôi muốn đạt được tiến bộ đột phá, cần tìm những việc cụ thể có thể làm.Điều hấp dẫn của AI nằm ở chỗ, kể cả lập trình AI, vẫn còn rất nhiều không gian khổng lồ chưa được khám phá.
Trần nhà của rất nhiều lĩnh vực rất cao. Nhìn khắp nơi, ngay cả công cụ tốt nhất trong bất kỳ lĩnh vực nào, vẫn còn rất nhiều việc phải làm trong vài năm tới. Với không gian rộng lớn như vậy và trần nhà cao như vậy, điều này khá độc đáo trong phát triển phần mềm, ít nhất là với AI.
Cursor luôn nhấn mạnh Dogfooding từ đầu
Lenny: Hãy quay lại vấn đề IDE (Môi trường phát triển tích hợp). Các anh có vài lộ trình khác nhau, các công ty khác cũng đang thử nghiệm.
Một là xây dựng một IDE dành cho kỹ sư, tích hợp khả năng AI bên trong. Một là mô hình Agent AI hoàn toàn, ví dụ như sản phẩm Devin. Một là tập trung xây dựng một mô hình rất giỏi lập trình, nỗ lực tạo ra mô hình lập trình tốt nhất.
Điều gì khiến các anh cuối cùng quyết định IDE là lộ trình tốt nhất?
Michael Truell: Những người từ đầu chỉ tập trung phát triển mô hình, hoặc cố gắng tự động hóa lập trình end-to-end, họ đang cố xây dựng thứ gì đó rất khác biệt so với chúng tôi.
Chúng tôi quan tâm hơn đến việc đảm bảo con người có thể kiểm soát mọi quyết định trong công cụ họ xây dựng. Ngược lại, họ hình dung nhiều hơn về một tương lai mà AI hoàn thành toàn bộ quá trình, thậm chí AI chịu trách nhiệm cho mọi quyết định.
Vì vậy, một mặt, lựa chọn của chúng tôi chứa đựng yếu tố do sở thích. Mặt khác, chúng tôi luôn cố gắng nhìn nhận mức độ công nghệ hiện tại một cách rất thực tế. Chúng tôi vô cùng hào hứng với tiềm năng phát triển của AI trong vài thập kỷ tới, nhưng đôi khi người ta vì thấy AI thể hiện tốt trong một lĩnh vực nào đó, lại có xu hướng nhân cách hóa các mô hình này, cho rằng chúng thông minh hơn con người trong lĩnh vực đó, vậy thì chắc chắn cũng sẽ xuất sắc trong lĩnh vực khác.
Nhưng các mô hình này có vấn đề lớn. Việc phát triển sản phẩm của chúng tôi từ đầu luôn nhấn mạnh "Dogfooding (tự dùng sản phẩm của mình)", chúng tôi tự dùng Cursor mỗi ngày, chưa bao giờ muốn phát hành bất kỳ tính năng nào vô dụng với chính mình.
Chúng tôi chính là người dùng cuối của sản phẩm, điều này giúp chúng tôi có nhận thức thực tế về mức độ công nghệ hiện tại. Chúng tôi cho rằng việc con người ngồi ở "ghế lái" là cực kỳ quan trọng, AI không thể đảm nhiệm mọi thứ.
Do lý do cá nhân, chúng tôi cũng muốn trao quyền kiểm soát này cho người dùng. Như vậy chúng tôi không chỉ là một công ty mô hình, mà còn tránh xa tư duy phát triển sản phẩm end-to-end lấy đi quyền kiểm soát của con người.
Về việc chúng tôi chọn xây dựng IDE thay vì plugin cho môi trường lập trình hiện tại, là vì chúng tôi tin chắc lập trình sẽ được thực hiện thông qua các mô hình này, và phương thức lập trình sẽ thay đổi lớn trong vài năm tới. Khả năng mở rộng của môi trường lập trình hiện tại quá hạn chế, nếu bạn cho rằng UI và mô hình lập trình sẽ thay đổi mang tính đột phá, thì bạn phải có quyền kiểm soát hoàn toàn toàn bộ ứng dụng.
Lenny: Tôi biết hiện tại các anh đang làm IDE, có lẽ đây là thiên kiến của các anh, là định hướng mà các anh cho là tương lai. Nhưng tôi tò mò, anh có nghĩ trong tương lai một phần lớn công việc sẽ do kỹ sư AI giúp bạn hoàn thành trong các công cụ như Slack? Cách thức này có một ngày sẽ được tích hợp vào Cursor không?
Michael Truell: Tôi cho rằng trạng thái lý tưởng là bạn có thể dễ dàng chuyển đổi giữa các thứ này. Đôi khi, bạn có thể muốn để AI tự vận hành một thời gian; đôi khi bạn muốn kéo kết quả làm việc của AI ra, hợp tác hiệu quả với nó. Đôi khi có thể lại để nó tự vận hành.
Tôi cho rằng bạn cần một môi trường thống nhất, nơi các hình thức nền tảng và tiền tuyến này đều hoạt động tốt. Đối với việc chạy nền, những nhiệm vụ lập trình chỉ cần mô tả rất ít để xác định chính xác yêu cầu và tiêu chuẩn đúng rất phù hợp. Sửa lỗi là một ví dụ tốt, nhưng đây tuyệt đối không phải toàn bộ lập trình.
Bản chất của IDE sẽ thay đổi hoàn toàn theo thời gian. Lý do chúng tôi chọn xây dựng trình soạn thảo riêng là vì nó sẽ không ngừng tiến bộ. Sự tiến hóa này bao gồm việc bạn có thể tiếp quản nhiệm vụ từ các giao diện khác nhau, như Slack và hệ thống theo dõi vấn đề; bản thân màn hình thủy tinh mà bạn nhìn chằm chằm mỗi ngày cũng sẽ thay đổi lớn. Hiện tại chúng tôi xem IDE là nơi xây dựng phần mềm.
Người dùng AI thành công nhất lại rất bảo thủ trong ứng dụng công nghệ
Lenny: Tôi cho rằng khi mọi người thảo luận về Agents và các kỹ sư AI này, họ chưa nhận thức đầy đủ một điểm, đó là chúng ta sẽ phần lớn trở thành "quản lý kỹ thuật", quản lý nhiều cấp dưới còn chưa thông minh lắm, bạn phải dành rất nhiều thời gian để xem xét, phê duyệt và cụ thể hóa yêu cầu. Anh có suy nghĩ gì về vấn đề này? Có phương pháp nào đơn giản hóa quá trình này không?
Bởi vì nghe có vẻ thực sự không dễ dàng, bất kỳ ai từng quản lý đội lớn đều thấm thía—"những cấp dưới này luôn mang công việc chất lượng không đều đặn đến tìm tôi, thật tra tấn."
Michael Truell: Ừ, có lẽ cuối cùng chúng ta phải từng người một có cuộc họp một-một với tất cả các Agents này.
Chúng tôi quan sát thấy những người dùng AI thành công nhất, họ lại khá bảo thủ trong ứng dụng công nghệ. Tôi thực sự cho rằng, những người dùng thành công nhất hiện nay rất phụ thuộc vào các chức năng như "dự đoán chỉnh sửa tiếp theo (Next Edit Prediction)" của chúng tôi. Trong quy trình lập trình thông thường của họ, AI của chúng tôi thông minh dự đoán thao tác tiếp theo cần thực hiện. Họ cũng rất giỏi trong việc giới hạn phạm vi nhiệm vụ giao cho AI ở mức rõ ràng và nhỏ hơn.
Xét đến chi phí thời gian bạn bỏ ra để xem xét mã nguồn, hợp tác với Agent chủ yếu có hai mô hình. Một là bạn có thể dành rất nhiều thời gian ban đầu để mô tả chi tiết, để AI tự làm việc, sau đó xem xét kết quả của AI. Khi bạn hoàn thành việc xem xét, toàn bộ nhiệm vụ đã xong.
Một là bạn có thể chia nhỏ nhiệm vụ hơn. Mỗi lần chỉ chỉ định một phần nhỏ, để AI hoàn thành, rồi xem xét; sau đó tiếp tục đưa chỉ thị, để AI tiếp tục hoàn thành, rồi lại xem xét. Điều này giống như thực hiện chức năng tự động hoàn thiện xuyên suốt quá trình.
Tuy nhiên, chúng tôi thường quan sát thấy, những người dùng công cụ này xuất sắc nhất vẫn có xu hướng chia nhỏ nhiệm vụ và giữ cho nhiệm vụ dễ quản lý.
Lenny: Điều này rất quý giá. Tôi muốn quay lại thời điểm các anh lần đầu xây dựng Cursor. Các anh nhận ra khi nào là đã sẵn sàng? Khi nào cảm thấy nên phát hành để xem chuyện gì xảy ra?
Michael Truell: Khi mới bắt đầu xây dựng Cursor, chúng tôi rất lo lắng sẽ mất quá nhiều thời gian phát triển, mãi không thể phát hành ra bên ngoài. Phiên bản đầu tiên của Cursor hoàn toàn do chúng tôi tự "làm tay" từ con số 0. Bây giờ chúng tôi dùng VS Code làm nền tảng, giống như nhiều trình duyệt dùng Chromium làm lõi.
Nhưng ban đầu không phải vậy, chúng tôi phát triển nguyên mẫu Cursor từ con số 0, điều này bao gồm rất nhiều công việc. Chúng tôi phải tự phát triển nhiều chức năng cần thiết cho trình soạn thảo mã hiện đại, ví dụ như hỗ trợ nhiều ngôn ngữ lập trình, chức năng điều hướng giữa mã, theo dõi lỗi, v.v. Ngoài ra, còn cần dòng lệnh tích hợp, và khả năng kết nối máy chủ từ xa để xem và chạy mã.
Chúng tôi phát triển với tốc độ sét đánh, tự xây dựng trình soạn thảo từ con số 0, đồng thời phát triển thành phần AI. Khoảng năm tuần sau, chúng tôi đã bắt đầu hoàn toàn sử dụng trình soạn thảo riêng, vứt bỏ hoàn toàn trình soạn thảo cũ, chuyển sang thực hành với công cụ mới. Khi cảm thấy nó đạt đến mức độ hữu dụng nhất định, chúng tôi giao cho người khác dùng thử, thực hiện một bản beta thử nghiệm rất ngắn.
Từ dòng mã đầu tiên đến phát hành chính thức ra công chúng, Cursor chỉ mất khoảng ba tháng. Mục tiêu của chúng tôi là nhanh chóng đưa sản phẩm vào tay người dùng, và nhanh chóng lặp lại theo phản hồi công chúng.
Điều khiến chúng tôi bất ngờ là ban đầu tưởng công cụ này sẽ chỉ thu hút vài trăm người dùng trong thời gian dài, nhưng từ đầu đã có lượng lớn người dùng đổ về, mang đến rất nhiều phản hồi. Phản hồi ban đầu cực kỳ quý giá, chính những phản hồi này thúc đẩy chúng tôi quyết định từ bỏ phiên bản tự xây dựng từ con số 0, chuyển sang phát triển dựa trên VS Code. Từ đó, chúng tôi liên tục tối ưu sản phẩm trong môi trường công cộng.
Phát triển sản phẩm trong ba tháng, ARR một năm đạt 100 triệu USD
Lenny: Tôi rất trân trọng sự khiêm tốn của anh về thành tích đạt được. Theo tôi biết, các anh đã nâng ARR từ 0 lên 100 triệu USD trong khoảng một đến một năm rưỡi, đây thực sự là thành tựu mang tính lịch sử.
Anh cho rằng yếu tố then chốt thành công là gì? Anh vừa đề cập tự dùng sản phẩm là một yếu tố. Nhưng việc các anh ra mắt sản phẩm trong ba tháng thật không tưởng. Bí quyết đằng sau là gì?
Michael Truell: Phiên bản đầu tiên, tức là phiên bản hoàn thành trong ba tháng, không hoàn hảo. Vì vậy chúng tôi luôn có cảm giác khẩn trương liên tục, luôn cảm thấy còn rất nhiều chỗ có thể làm tốt hơn.
Mục tiêu cuối cùng của chúng tôi là thực sự tạo ra một khuôn mẫu lập trình hoàn toàn mới, có thể tự động hóa lượng lớn công việc mã hóa mà chúng ta biết ngày nay. Dù Cursor đã đạt được tiến triển lớn đến đâu, chúng tôi vẫn cảm thấy còn rất xa mục tiêu cuối cùng, luôn có rất nhiều việc cần làm.
Thường xuyên, chúng tôi không quá lo lắng về hiệu ứng phát hành ban đầu, mà quan tâm nhiều hơn đến sự tiến hóa liên tục của sản phẩm, nỗ lực cải thiện và hoàn thiện công cụ này không ngừng.
Lenny: Sau ba tháng đó, có điểm ngoặt nào khiến mọi thứ bắt đầu cất cánh không?
Michael Truell: Nói thật, cảm giác tăng trưởng ban đầu khá chậm, có lẽ vì chúng tôi tự thấy mình hơi thiếu kiên nhẫn. Nhưng xét về tốc độ tăng trưởng tổng thể, nó luôn khiến chúng tôi ngạc nhiên.
Theo tôi, điều bất ngờ nhất là, sự tăng trưởng này thực sự duy trì xu hướng mũ ổn định, tăng trưởng liên tục mỗi tháng, dù đôi khi việc phát hành phiên bản mới hoặc các yếu tố khác có thể tăng tốc quá trình này.
Dĩ nhiên, sự tăng trưởng mũ này ban đầu cảm giác khá chậm, cơ số cũng thực sự thấp, nên ban đầu nó không thực sự hiện ra trạng thái bùng nổ.
Lenny: Nghe giống như ví dụ "hãy tạo ra nó, mọi người sẽ đến". Các anh chỉ đơn giản tạo ra một công cụ mình thích, vừa phát hành, mọi người cũng thích, rồi truyền miệng nhau.
Michael Truell: Đúng, gần như vậy. Đội của chúng tôi tập trung phần lớn nỗ lực vào sản phẩm, không phân tâm vào việc khác. Dĩ nhiên, chúng tôi cũng dành thời gian làm nhiều việc quan trọng khác, như xây dựng đội ngũ, luân phiên phụ trách hỗ trợ người dùng, v.v.
Tuy nhiên, đối với nhiều việc thông thường mà các công ty khởi nghiệp thường dành nỗ lực giai đoạn đầu, chúng tôi "để đó", đặc biệt là trong bán hàng và tiếp thị.
Chúng tôi tập trung toàn lực vào việc mài giũa sản phẩm, trước tiên tạo ra một sản phẩm mà đội ngũ mình thích, sau đó lặp lại theo phản hồi một bộ phận người dùng cốt lõi, nghe có vẻ đơn giản, nhưng thực tế làm tốt lại không dễ.
Có rất nhiều hướng để khám phá, nhiều lộ trình sản phẩm khác nhau. Một trong những khó khăn là giữ sự tập trung, chiến lược chọn các chức năng then chốt cần xây dựng và xác định ưu tiên.
Một thách thức khác là lĩnh vực chúng tôi đang ở bản thân đại diện cho một mô hình phát triển sản phẩm hoàn toàn mới:Chúng tôi nằm giữa một công ty phần mềm truyền thống và một công ty mô hình nền tảng.
Chúng tôi đang phát triển sản phẩm cho hàng triệu người dùng, điều này đòi hỏi chúng tôi phải đạt đến đỉnh cao ở cấp độ sản phẩm. Nhưng một chiều quan trọng khác về chất lượng sản phẩm là không ngừng sâu hóa nghiên cứu khoa học và phát triển mô hình, không ngừng tối ưu mô hình trong các kịch bản then chốt. Cân bằng hai mặt này luôn đầy thách thức.
Việc phản trực giác nhất là không ngờ sẽ tự phát triển mô hình
Lenny: Cho đến nay, trong việc xây dựng Cursor, phát triển sản phẩm AI, anh cảm thấy điều gì phản trực giác nhất?
Michael Truell: Đối với tôi, điều phản trực giác nhất là ban đầu hoàn toàn không ngờ sẽ tự phát triển mô hình. Khi mới bước vào lĩnh vực này, đã có công ty từ đầu tập trung vào huấn luyện mô hình. Chúng tôi đã tính toán chi phí và tài nguyên cần thiết để huấn luyện GPT-4, rõ ràng đây không phải điều chúng tôi có khả năng làm.
Trên thị trường đã có rất nhiều mô hình xuất sắc, tại sao phải tốn công sức sao chép việc người khác đã làm? Đặc biệt là trong tiền huấn luyện (Pre-training), điều này cần một mạng thần kinh không biết gì về mọi thứ học toàn bộ internet. Vì vậy, ban đầu chúng tôi hoàn toàn không có ý định đi theo con đường này. Từ đầu chúng tôi rất rõ ràng, các mô hình hiện tại có rất nhiều việc vốn có thể làm nhưng chưa thực hiện, vì thiếu công cụ phù hợp để xây dựng cho các mô hình này. Nhưng chúng tôi vẫn dành rất nhiều nỗ lực vào phát triển mô hình.
Bởi vì mỗi "khoảnh khắc kỳ diệu" bạn cảm nhận khi dùng Cursor đều phần nào bắt nguồn từ mô hình tùy chỉnh của chúng tôi. Quá trình này là từng bước. Ban đầu chúng tôi thử nghiệm huấn luyện mô hình riêng trong một trường hợp sử dụng, vì nó không phù hợp với bất kỳ mô hình nền tảng phổ biến nào, kết quả rất thành công. Sau đó chúng tôi mở rộng tư duy này sang trường hợp sử dụng khác, cũng rất tốt, rồi tiếp tục thúc đẩy.
Khi thực hiện loại phát triển mô hình này, một điểm then chốt là chọn mục tiêu chính xác, không làm lại bánh xe. Chúng tôi không chạm vào những lĩnh vực mà các mô hình nền tảng hàng đầu đã làm rất tốt, mà tập trung vào điểm yếu của chúng, và suy nghĩ cách bổ sung.
Lenny: Nhiều người sẽ ngạc nhiên khi nghe các anh có mô hình riêng. Bởi vì khi mọi người nói về Cursor và các sản phẩm khác trong lĩnh vực này, thường gọi chúng là "vỏ GPT", cho rằng chúng chỉ là công cụ xây dựng trên các mô hình như ChatGPT hoặc Sonnet. Nhưng anh vừa đề cập, các anh thực sự có mô hình riêng. Có thể nói vài nét về stack công nghệ đằng sau không?
Michael Truell: Chúng tôi thực sự sử dụng các mô hình nền tảng phổ biến nhất trong nhiều kịch bản.
Trong các khâu then chốt tạo nên trải nghiệm Cursor cho người dùng, chúng tôi phụ thuộc nhiều hơn vào mô hình tự phát triển, ví dụ như một số trường hợp sử dụng mà mô hình nền tảng không thể đảm nhiệm do chi phí hoặc tốc độ. Một ví dụ là tự động hoàn thiện.
Đối với người không viết mã, điều này có thể khó hiểu. Viết mã là công việc độc đáo. Đôi khi, nội dung công việc trong 5 phút, 10 phút, 20 phút hoặc thậm chí nửa giờ tới của bạn, hoàn toàn có thể dự đoán được bằng cách quan sát thao tác hiện tại.
So sánh với viết văn, có lẽ nhiều người quen thuộc với chức năng tự động hoàn thiện của Gmail, và các gợi ý tự động hoàn thiện khi soạn tin nhắn, email, v.v. Nhưng các chức năng này có tác dụng hạn chế. Bởi vì chỉ qua nội dung đã viết, thường rất khó suy luận bạn sẽ viết gì tiếp theo.
Nhưng khi viết mã, khi bạn sửa đổi một phần của kho mã, thường cần đồng bộ sửa đổi các phần khác của kho mã, và những nội dung cần sửa đổi này rất rõ ràng.
Một trong những chức năng cốt lõi của Cursor là loại tự động hoàn thiện nâng cao này. Nó có thể dự đoán chuỗi thao tác tiếp theo bạn sẽ thực hiện, xuyên suốt nhiều tệp, xuyên suốt các vị trí khác nhau trong tệp.
Để mô hình thể hiện xuất sắc trong kịch bản này, tốc độ của nó phải đủ nhanh, đảm bảo đưa ra kết quả hoàn thiện trong vòng 300 miligiây. Chi phí cũng là yếu tố quan trọng, mỗi lần bạn nhấn phím chúng tôi kích hoạt hàng nghìn lần suy luận, không ngừng cập nhật dự đoán thao tác tiếp theo của bạn.
Còn có một thách thức kỹ thuật rất đặc biệt: Chúng tôi cần mô hình không chỉ giỏi hoàn thiện token tiếp theo như xử lý chuỗi văn bản thông thường, mà còn phải giỏi hoàn thiện một chuỗi diffs (thay đổi mã), tức là dựa trên các thay đổi đã xảy ra trong kho mã, dự đoán các thay đổi thêm/xóa tiếp theo có thể xảy ra.
Chúng tôi đã huấn luyện mô hình chuyên biệt cho nhiệm vụ này, rất hiệu quả. Phần này hoàn toàn do chúng tôi tự phát triển, chưa từng gọi bất kỳ mô hình nền tảng nào. Chúng tôi chưa gắn nhãn hoặc thương hiệu hóa công nghệ này, nhưng nó là cốt lõi của Cursor.
Một kịch bản khác chúng tôi dùng mô hình tự phát triển là để tăng cường hiệu suất của các mô hình lớn như Sonnet, Gemini hoặc GPT, đặc biệt trong đầu vào và đầu ra.
Ở khâu đầu vào, mô hình của chúng tôi tìm kiếm toàn bộ kho mã, xác định các phần liên quan cần hiển thị cho các mô hình lớn này. Bạn có thể hình dung nó như một "mini Google Search" chuyên tìm nội dung liên quan trong kho mã.
Ở khâu đầu ra, chúng tôi xử lý các đề xuất sửa đổi từ các mô hình lớn, dùng mô hình được huấn luyện chuyên biệt để bổ sung chi tiết hoàn thiện. Ví dụ như thiết kế logic cấp cao do mô hình tiên tiến hơn hoàn thành, chúng sẽ tốn một vài token để đưa ra định hướng tổng thể. Một vài mô hình nhỏ hơn, chuyên biệt hơn, tốc độ cực nhanh khác sẽ kết hợp với một số kỹ thuật tối ưu suy luận, chuyển các đề xuất sửa đổi cấp cao này thành chuyển đổi mã hoàn chỉnh, có thể thực thi.
Cách làm này nâng cao đáng kể chất lượng hoàn thành nhiệm vụ chuyên môn, cũng tăng tốc độ phản ứng rất lớn. Đối với chúng tôi, tốc độ cũng là chỉ số then chốt đo lường sản phẩm.
Lenny: Điều này rất thú vị. Gần đây tôi phỏng vấn Kevin Weil, CPO (Giám đốc sản phẩm) của OpenAI trên podcast, ông ấy gọi đây là tập hợp mô hình (Ensemble of models).
Họ cũng tận dụng chức năng tốt nhất của từng mô hình. Sử dụng mô hình rẻ hơn sẽ có lợi thế lớn về chi phí. Các mô hình tự huấn luyện của các anh, có phải phát triển dựa trên các mô hình mã nguồn mở như LLaMA không?
Michael Truell: Chúng tôi rất thực tế trong việc này, không muốn làm lại bánh xe. Vì vậy chúng tôi bắt đầu từ các mô hình tiền huấn luyện tốt nhất trên thị trường, thường là mã nguồn mở, đôi khi cũng hợp tác với các mô hình lớn không công khai trọng số ra bên ngoài. Chúng tôi không quan tâm liệu có thể đọc trực tiếp hoặc tra từng dòng các ma trận trọng số quyết định kết quả đầu ra, mà quan tâm hơn đến khả năng huấn luyện mô hình, huấn luyện sau (Post-train).
Trần nhà sản phẩm AI giống như máy tính cá nhân và công cụ tìm kiếm thế kỷ trước
Lenny: Nhiều doanh nhân và nhà đầu tư AI đang suy nghĩ về một câu hỏi: Hào phòng thủ và khả năng phòng vệ của AI nằm ở đâu? Phát triển mô hình tùy chỉnh dường như là một cách xây dựng hào phòng thủ. Trong bối cảnh đối thủ liên tục ra sản phẩm mới, giành thị phần của bạn, làm thế nào để rèn luyện khả năng phòng vệ lâu dài?
Michael Truell: Tôi cho rằng thực sự có một vài phương pháp truyền thống để tạo quán tính người dùng và hào phòng thủ. Nhưng cuối cùng, chúng tôi phải nỗ lực liên tục, xây dựng sản phẩm xuất sắc nhất.Tôi tin chắc trần nhà của AI rất cao, bất kể bạn xây dựng bức tường nào, đều có thể bị vượt qua bất cứ lúc nào.
Thị trường này khác biệt với thị trường phần mềm truyền thống hoặc thị trường doanh nghiệp trước đây. Một ví dụ tương tự thị trường này là công cụ tìm kiếm cuối thập niên 90 đến đầu thế kỷ 21. Một ví dụ khác là sự phát triển máy tính cá nhân và máy tính nhỏ từ những năm 70-80 đến 90.
Trần nhà sản phẩm AI rất cao, sản phẩm lặp lại nhanh chóng. Bạn có thể liên tục thu được lợi nhuận khổng lồ từ giá trị gia tăng mỗi giờ của một người thông minh, giá trị gia tăng mỗi đô la chi phí R&D. Tình trạng này có thể kéo dài rất lâu. Bạn sẽ không bao giờ thiếu tính năng mới để phát triển.
Đặc biệt trong lĩnh vực tìm kiếm, tăng kênh phân phối cũng giúp cải thiện sản phẩm, vì bạn có thể lặp lại thuật toán và mô hình liên tục dựa trên dữ liệu và phản hồi người dùng. Tôi tin rằng các động lực này cũng tồn tại trong ngành chúng tôi.
Đối với chúng tôi, đây có thể là thực tế hơi bất lực. Nhưng đối với cả thế giới, đây là sự thật đầy phấn khích. Sẽ xuất hiện nhiều sản phẩm dẫn đầu, còn quá nhiều chức năng ý nghĩa chờ được tạo ra.
Chúng tôi còn rất xa tầm nhìn 5-10 năm tới, điều chúng tôi cần làm là giữ cho động cơ đổi mới chạy ở tốc độ cao.
Lenny: Nghe có vẻ giống như xây dựng hào phòng thủ "kiểu người tiêu dùng". Liên tục cung cấp sản phẩm tốt nhất, khiến người dùng muốn tiếp tục sử dụng, chứ không phải như Salesforce, gắn hợp đồng toàn công ty, khiến nhân viên buộc phải dùng.
Michael Truell: Đúng. Tôi cho rằng chìa khóa là nếu lĩnh vực bạn ở nhanh chóng không còn nhiều thứ có giá trị để làm, thì tình hình thực sự không tích cực. Nhưng nếu trong lĩnh vực này, đầu tư lượng lớn tiền bạc, nỗ lực của nhân tài xuất sắc có thể liên tục tạo ra giá trị, thì bạn có thể tận hưởng hiệu ứng quy mô trong R&D, có thể đi sâu vào công nghệ theo hướng đúng, xây dựng rào cản.
Điều này thực sự cũng mang xu hướng định hướng người tiêu dùng. Nhưng cốt lõi của tất cả vẫn là xây dựng sản phẩm xuất sắc nhất.
Lenny: Vậy anh cho rằng tương lai sẽ là thị trường "kẻ thắng tất", hay sẽ xuất hiện nhiều sản phẩm khác biệt?
Michael Truell: Tôi cho rằng thị trường này rất lớn. Anh vừa đề cập tình hình IDE. Khi một số người nghiên cứu lĩnh vực này, họ nhìn lại thị trường IDE mười năm qua, rồi hỏi: "Rốt cuộc ai có thể kiếm tiền bằng cách làm trình soạn thảo?" Trước đây mỗi người đều có cấu hình quen thuộc. Chỉ có một công ty thương mại hóa thành công bằng cách tạo ra trình soạn thảo xuất sắc, nhưng quy mô của nó cũng rất hạn chế.
Một số người do đó kết luận, cho rằng tương lai cũng sẽ là格局 như vậy. Nhưng tôi cho rằng quan điểm này bỏ qua một điều, là vào thập niên 2010, tiềm năng xây dựng trình soạn thảo cho lập trình viên là hạn chế.
Công ty kiếm tiền bằng trình soạn thảo chủ yếu tập trung vào đơn giản hóa điều hướng kho mã, kiểm tra lỗi, làm công cụ Debugging dễ dùng. Mặc dù các chức năng này đều có giá trị, nhưng tôi cho rằng cơ hội xây dựng công cụ cho lập trình viên, và thậm chí cho các chuyên gia tri thức rộng rãi hơn, là rất lớn.
Thách thức thực sự chúng tôi đối mặt là làm thế nào tự động hóa lượng lớn công việc tri thức và hành chính phiền phức. Như vậy mới có thể đạt được sự nâng cao năng suất đáng tin cậy và hiệu quả hơn trong các lĩnh vực công việc tri thức.
Tôi cho rằng quy mô thị trường chúng tôi đang ở rất lớn, vượt xa nhận thức trước đây của mọi người về thị trường công cụ phát triển. Tương lai sẽ xuất hiện nhiều giải pháp khác nhau, cũng có thể xuất hiện một nhà dẫn đầu ngành. Có thể là chúng tôi, nhưng vẫn phải chờ xem. Công ty này sẽ tạo ra một công cụ phổ thông, có thể hỗ trợ xây dựng phần lớn phần mềm trên thế giới, sẽ là doanh nghiệp lớn mang tính thời đại. Nhưng đồng thời cũng sẽ tồn tại các sản phẩm tập trung vào thị trường ngách cụ thể, hoặc giai đoạn cụ thể trong vòng đời phát triển phần mềm.
Cuối cùng, bản thân lập trình có thể chuyển từ viết ngôn ngữ lập trình hình thức truyền thống sang cấp độ cao hơn, và các công cụ cấp cao này cũng sẽ trở thành đối tượng chính người dùng mua và sử dụng.Tôi tin rằng lập trình AI sẽ xuất hiện một nhà thống trị, nó sẽ phát triển thành doanh nghiệp quy mô cực lớn.
Lenny: Điều thú vị là, Microsoft trước đây nằm ở trung tâm cuộc biến đổi này, họ có sản phẩm tuyệt vời và kênh phân phối mạnh mẽ. Anh nói Copilot khiến anh nhận ra tiềm năng lớn của lĩnh vực này, nhưng dường như họ chưa hoàn toàn thắng thị trường. Thậm chí có phần tụt hậu. Anh cho rằng nguyên nhân là gì?
Michael Truell: Tôi cho rằng lý do Copilot chưa hoàn toàn đạt được kỳ vọng là do những nguyên nhân lịch sử và cấu trúc cụ thể.
Xét về cấu trúc, dự án Copilot của Microsoft mang đến cho chúng tôi cảm hứng lớn. Họ đã làm rất nhiều việc tuyệt vời, chúng tôi bản thân cũng là người dùng của nhiều sản phẩm Microsoft.
Nhưng tôi cho rằng thị trường này không thân thiện với doanh nghiệp trưởng thành. Thị trường thân thiện với họ thường là những thị trường không còn nhiều không gian đổi mới, nhanh chóng có thể thương mại hóa, có thể kiếm lời bằng cách bán kèm sản phẩm.
Trong thị trường này, sự khác biệt ROI giữa các sản phẩm không lớn. Việc mua giải pháp đổi mới độc lập không có nhiều ý nghĩa, ngược lại sản phẩm bán kèm hấp dẫn hơn.
Một thị trường đặc biệt có lợi cho doanh nghiệp trưởng thành khác là:Người dùng từ đầu đã phụ thuộc cao vào công cụ của bạn, và chi phí chuyển đổi rất cao.
Nhưng trong lĩnh vực của chúng tôi, người dùng có thể dễ dàng thử các công cụ khác nhau, lựa chọn sản phẩm phù hợp nhất theo đánh giá của họ. Tình huống này không có lợi cho công ty lớn, ngược lại thân thiện hơn với những công ty có sản phẩm đổi mới nhất.
Về nguyên nhân lịch sử cụ thể, theo tôi biết, nhóm tham gia phát triển phiên bản đầu tiên của Copilot, phần lớn sau đó đã đến các công ty khác làm việc khác. Việc phối hợp giữa tất cả các bộ phận và cá nhân liên quan để cùng làm một sản phẩm, thực sự có khó khăn.
Kỹ sư cao cấp kỳ vọng quá thấp, kỹ sư mới vào kỳ vọng quá cao
Lenny: Nếu anh có thể ngồi bên cạnh mỗi người dùng mới lần đầu dùng Cursor, thì thầm vài lời khuyên vào tai họ, giúp họ dùng Cursor tốt hơn, anh sẽ nói gì?
Michael Truell: Tôi cho rằng hiện tại ở cấp độ sản phẩm, chúng tôi cần giải quyết một vấn đề.
Rất nhiều người dùng hiện tại có thể dùng Cursor thành công đều có một chút "thẩm mỹ" về khả năng mô hình. Những người dùng này hiểu Cursor có thể hoàn thành nhiệm vụ ở mức độ nào, cũng hiểu cần cung cấp chỉ thị ở mức độ nào cho nó. Họ có thể hiểu chất lượng mô hình, giới hạn, có thể làm gì và không thể làm gì.
Trong sản phẩm hiện tại, chúng tôi chưa làm tốt việc giáo dục người dùng, thậm chí chưa cung cấp hướng dẫn sử dụng rõ ràng.
Để nuôi dưỡng "thẩm mỹ" này, tôi có hai lời khuyên.
Thứ nhất, đừng giao toàn bộ nhiệm vụ cho mô hình một lần. Bạn sẽ thất vọng hoặc chấp nhận toàn bộ đầu ra. Thay vào đó, tôi sẽ chia nhiệm vụ thành từng mảnh nhỏ. Bạn có thể dành cùng thời gian để đạt được kết quả cuối cùng, nhưng cần từng bước. Mỗi lần chỉ rõ nhiệm vụ nhỏ, nhận được một phần kết quả, lặp lại quá trình này, chứ không cố gắng viết một đoạn chỉ thị dài dòng. Cách làm này rất có thể dẫn đến thảm họa.
Thứ hai, tốt nhất nên thử trước trên dự án nghiệp dư, đừng dùng trực tiếp cho công việc quan trọng. Tôi khuyến khích các nhà phát triển quen với quy trình phát triển hiện tại hãy có nhiều kinh nghiệm thất bại hơn, cũng thử nghiệm phá vỡ giới hạn mô hình nhiều hơn.
Họ có thể tận dụng AI tối đa trong môi trường tương đối an toàn, ví dụ như trong công việc phụ. Rất nhiều lần, chúng tôi phát hiện một số người chưa cho AI cơ hội công bằng, và đánh giá thấp khả năng của nó.
Thông qua việc áp dụng phương pháp chia nhỏ nhiệm vụ, và chủ động khám phá giới hạn mô hình, thử nghiệm phá vỡ trong môi trường an toàn. Bạn có thể ngạc nhiên khi phát hiện trong một số kịch bản, AI không sai như dự kiến của bạn.
Lenny: Tôi hiểu là cần nuôi dưỡng một trực giác, hiểu giới hạn khả năng mô hình, nó có thể đẩy một ý tưởng đến mức độ nào, chứ không chỉ đơn thuần làm theo chỉ thị của bạn. Và mỗi khi có mô hình mới ra mắt, ví dụ như khi GPT-4 ra
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
