Một bài viết được gán thẻ "phát triển ứng dụng"

Các quản lý sản phẩm (PM) bị thu hút bởi Bolt.new và Lovable để tạo mẫu ứng dụng nhanh chóng với AI. Các công cụ này hứa hẹn biến “ý tưởng thành ứng dụng trong vài giây,” cho phép PM tạo ra giao diện người dùng (UI) hoặc sản phẩm khả dụng tối thiểu (MVP) mà không cần đội ngũ phát triển đầy đủ. Tuy nhiên, phản hồi thực tế từ người dùng đã chỉ ra một số vấn đề nhức nhối. Những khó khăn phổ biến bao gồm trải nghiệm người dùng (UX) cồng kềnh gây ra sự kém hiệu quả, khó khăn trong việc cộng tác với các nhóm, tích hợp hạn chế vào các chuỗi công cụ hiện có, thiếu hỗ trợ cho việc lập kế hoạch sản phẩm dài hạn và các tính năng phân tích hoặc theo dõi không đầy đủ. Dưới đây, chúng tôi sẽ phân tích các vấn đề chính (kèm theo bình luận trực tiếp từ người dùng) và so sánh hiệu suất của từng công cụ.

Vấn đề UX/UI cản trở hiệu quả​

Cả Bolt.new và Lovable đều tiên tiến nhưng không hoàn hảo, và các PM thường gặp phải những điểm kỳ lạ về UX/UI làm chậm họ:

• Hành vi AI không thể đoán trước & Lỗi: Người dùng báo cáo rằng các công cụ xây dựng AI này thường xuyên tạo ra lỗi hoặc thay đổi bất ngờ, buộc họ phải thử và sai tẻ nhạt. Một người dùng không chuyên về kỹ thuật mô tả đã dành “3 giờ [cho] các lỗi lặp đi lặp lại” chỉ để thêm một nút, đốt hết token của họ trong quá trình này. Trên thực tế, Bolt.new trở nên nổi tiếng vì tạo ra “màn hình trống, thiếu tệp và triển khai không đầy đủ” khi các dự án phát triển vượt ra ngoài các nguyên mẫu cơ bản. Sự không thể đoán trước này có nghĩa là các PM phải giám sát chặt chẽ đầu ra của AI. Một người đánh giá trên G2 lưu ý rằng các lời nhắc của Lovable “có thể thay đổi bất ngờ, điều này có thể gây nhầm lẫn,” và nếu logic ứng dụng bị rối, “sẽ mất rất nhiều công sức để đưa nó trở lại đúng hướng” – trong một trường hợp họ phải khởi động lại toàn bộ dự án. Những lần đặt lại và làm lại như vậy gây khó chịu khi một PM đang cố gắng làm việc nhanh chóng.

• Chi phí lặp lại cao (Token & Thời gian): Cả hai nền tảng đều sử dụng các mô hình giới hạn sử dụng (Bolt.new thông qua token, Lovable thông qua tín dụng tin nhắn), điều này có thể cản trở thử nghiệm hiệu quả. Một số người dùng phàn nàn rằng hệ thống token của Bolt tiêu tốn quá mức – “Bạn cần nhiều token hơn bạn nghĩ,” một người dùng viết, “ngay khi bạn kết nối cơ sở dữ liệu… bạn sẽ gặp rắc rối mà [AI] gặp vấn đề trong việc giải quyết chỉ trong một hoặc hai lời nhắc”. Kết quả là các chu kỳ lặp lại của việc nhắc nhở và sửa lỗi tiêu hết hạn mức. Một người dùng Bolt.new thất vọng khác châm biếm: “30% token của bạn được dùng để tạo một ứng dụng. 70% còn lại… để tìm giải pháp cho tất cả các lỗi và sai sót mà Bolt đã tạo ra.” Điều này được lặp lại bởi một câu trả lời: “rất đúng! [Tôi] đã gia hạn [đăng ký] ba lần trong một tháng!”. Mô hình sử dụng của Lovable cũng không ngoại lệ – gói cơ bản của nó có thể không đủ cho một ứng dụng đơn giản (một người đánh giá “đã đăng ký gói cơ bản và đó không thực sự cung cấp đủ cho tôi để xây dựng một ứng dụng đơn giản”, lưu ý một sự tăng chi phí đáng kể cho gói tiếp theo). Đối với các PM, điều này có nghĩa là đạt giới hạn hoặc phát sinh thêm chi phí chỉ để lặp lại một nguyên mẫu, một yếu tố giết chết hiệu quả rõ ràng.

• Tùy chỉnh & Kiểm soát UI hạn chế: Mặc dù cả hai công cụ đều tạo UI nhanh chóng, người dùng đã nhận thấy chúng thiếu khả năng tinh chỉnh. Một người dùng Lovable ca ngợi tốc độ nhưng than thở “các tùy chọn tùy chỉnh [hơi] bị hạn chế”. Các mẫu có sẵn trông đẹp, nhưng điều chỉnh chúng ngoài những điều chỉnh cơ bản có thể cồng kềnh. Tương tự, AI của Lovable đôi khi thay đổi mã mà nó không nên thay đổi – “Nó thay đổi mã không nên thay đổi khi tôi thêm một cái gì đó mới,” một người dùng lưu ý – có nghĩa là một thay đổi nhỏ của PM có thể vô tình làm hỏng một phần khác của ứng dụng. Bolt.new, mặt khác, ban đầu cung cấp rất ít chỉnh sửa trực quan. Mọi thứ được thực hiện thông qua lời nhắc hoặc chỉnh sửa mã phía sau, điều này đáng sợ đối với những người không phải nhà phát triển. (Lovable đã bắt đầu giới thiệu chế độ “chỉnh sửa trực quan” cho các thay đổi về bố cục và kiểu dáng, nhưng nó đang trong giai đoạn truy cập sớm.) Việc thiếu một trình chỉnh sửa WYSIWYG mạnh mẽ hoặc giao diện kéo và thả (trong cả hai công cụ) là một điểm khó khăn đối với các PM không muốn đi sâu vào mã. Ngay cả tài liệu của Lovable cũng thừa nhận khoảng trống này, nhằm mục đích cung cấp thêm chức năng kéo và thả trong tương lai để làm cho quá trình “dễ tiếp cận hơn với người dùng không chuyên về kỹ thuật” – ngụ ý rằng hiện tại, tính dễ sử dụng vẫn còn chỗ để cải thiện.

• Lỗi quy trình làm việc UI: Người dùng đã chỉ ra các vấn đề UX nhỏ hơn làm gián đoạn sự mượt mà khi sử dụng các nền tảng này. Ví dụ, trong Bolt.new, giao diện cho phép người dùng nhấp vào “Deploy” mà không cần cấu hình mục tiêu triển khai, dẫn đến sự nhầm lẫn (nó “nên nhắc bạn cấu hình Netlify nếu bạn cố gắng triển khai nhưng chưa,” người dùng gợi ý). Bolt cũng thiếu bất kỳ chế độ xem khác biệt (diff) hoặc lịch sử nào trong trình chỉnh sửa của nó; nó “mô tả những gì nó đang thay đổi… nhưng mã thực tế không hiển thị sự khác biệt,” không giống như các công cụ phát triển truyền thống. Điều này làm cho PM khó hiểu hơn về những gì AI đã thay đổi trong mỗi lần lặp lại, cản trở việc học hỏi và tin tưởng. Ngoài ra, lịch sử trò chuyện phiên của Bolt rất ngắn, vì vậy bạn không thể cuộn lại xa để xem lại các hướng dẫn trước đó – một vấn đề đối với một PM có thể rời đi và quay lại sau cần ngữ cảnh. Tổng hợp lại, những lỗi giao diện này có nghĩa là thêm gánh nặng tinh thần để theo dõi các thay đổi và trạng thái.

Tóm lại, Bolt.new có xu hướng ưu tiên sức mạnh thô hơn sự trau chuốt, điều này có thể khiến các PM vật lộn với những điểm thô ráp của nó, trong khi UX của Lovable thân thiện hơn nhưng vẫn còn hạn chế về chiều sâu. Như một so sánh đã nói: “Bolt.new rất tuyệt nếu bạn muốn tốc độ thô và kiểm soát hoàn toàn… tạo ứng dụng full-stack nhanh chóng, nhưng bạn sẽ phải dọn dẹp mọi thứ để sản xuất. Lovable có cấu trúc hơn và thân thiện với thiết kế hơn… với mã sạch hơn ngay từ đầu.” Đối với một quản lý sản phẩm, thời gian “dọn dẹp” là một cân nhắc nghiêm túc – và nhiều người đã nhận thấy rằng những gì các công cụ AI này tiết kiệm được trong thời gian phát triển ban đầu, chúng lại phải trả lại một phần trong thời gian gỡ lỗi và tinh chỉnh.

Ma sát trong quy trình làm việc nhóm và cộng tác​

Một phần quan trọng trong vai trò của PM là làm việc với các nhóm – thiết kế, phát triển, các PM khác – nhưng cả Bolt.new và Lovable đều có những hạn chế khi nói đến cộng tác nhiều người và tích hợp quy trình làm việc.

• Thiếu tính năng cộng tác gốc: Cả hai công cụ này ban đầu đều không được xây dựng với mục đích cộng tác đa người dùng theo thời gian thực (như Google Docs hoặc Figma). Các dự án thường được gắn với một tài khoản duy nhất và chỉ được chỉnh sửa bởi một người tại một thời điểm. Sự cô lập này có thể tạo ra ma sát trong môi trường nhóm. Ví dụ, nếu một PM tạo ra một bản thử nghiệm trong Bolt.new, không có cách dễ dàng nào để một nhà thiết kế hoặc kỹ sư đăng nhập và chỉnh sửa cùng dự án đó đồng thời. Việc bàn giao rất cồng kềnh: thông thường người ta sẽ xuất hoặc đẩy mã lên một kho lưu trữ để người khác làm việc (và như đã lưu ý bên dưới, ngay cả điều đó cũng không đơn giản trong trường hợp của Bolt). Trong thực tế, một số người dùng phải tạo ra sản phẩm bằng các công cụ này rồi chuyển mã đi nơi khác. Một người tham gia thảo luận trên Product Hunt thừa nhận: sau khi sử dụng Bolt hoặc Lovable để có ý tưởng, họ “đặt nó lên GitHub của tôi và cuối cùng sử dụng Cursor để hoàn thành việc xây dựng” – về cơ bản là chuyển sang một công cụ khác để phát triển nhóm. Điều này cho thấy rằng để cộng tác bền vững, người dùng cảm thấy cần phải rời khỏi môi trường Bolt/Lovable.

• Kiểm soát phiên bản và chia sẻ mã: Ban đầu, Bolt.new không có tích hợp Git sẵn có, điều mà một nhà phát triển gọi là một thiếu sót “điên rồ”: “Tôi hoàn toàn muốn mã của mình… nằm trong Git.” Không có kiểm soát phiên bản gốc, việc tích hợp đầu ra của Bolt vào cơ sở mã của nhóm rất cồng kềnh. (Bolt cung cấp một tệp ZIP mã có thể tải xuống, và các tiện ích mở rộng trình duyệt của bên thứ ba đã xuất hiện để đẩy mã đó lên GitHub.) Đây là một bước phụ có thể làm gián đoạn luồng công việc của một PM đang cố gắng cộng tác với các nhà phát triển. Lovable, ngược lại, quảng bá tính năng “không khóa, đồng bộ GitHub”, cho phép người dùng kết nối một kho lưu trữ và đẩy các bản cập nhật mã. Đây là một điểm bán hàng cho các nhóm – một người dùng lưu ý rằng họ “đã sử dụng… Lovable để tích hợp Git (môi trường nhóm cộng tác)” trong khi Bolt chỉ được sử dụng cho công việc cá nhân nhanh chóng. Về mặt này, Lovable giúp việc bàn giao nhóm dễ dàng hơn: một PM có thể tạo ra một ứng dụng và ngay lập tức có mã trong GitHub để các nhà phát triển xem xét hoặc tiếp tục. Bolt.new kể từ đó đã cố gắng cải thiện, thêm một trình kết nối GitHub thông qua StackBlitz, nhưng phản hồi của cộng đồng cho thấy nó vẫn chưa liền mạch. Ngay cả với Git, mã do AI tạo ra có thể khó để các nhóm phân tích cú pháp nếu không có tài liệu, vì mã được tạo tự động và đôi khi không tự giải thích.

• Tích hợp quy trình làm việc (Nhóm thiết kế & phát triển): Các quản lý sản phẩm thường cần thu hút các nhà thiết kế sớm hoặc đảm bảo những gì họ xây dựng phù hợp với thông số kỹ thuật thiết kế. Cả hai công cụ đều đã cố gắng tích hợp ở đây (sẽ thảo luận chi tiết hơn bên dưới), nhưng vẫn còn ma sát. Một lợi thế của Bolt.new đối với các nhà phát triển là nó cho phép kiểm soát trực tiếp hơn về ngăn xếp công nghệ – “nó cho phép bạn sử dụng bất kỳ framework nào,” như người sáng lập Lovable đã nhận xét – điều này có thể làm hài lòng một thành viên nhóm phát triển muốn chọn công nghệ. Tuy nhiên, sự linh hoạt tương tự đó có nghĩa là Bolt gần giống một sân chơi của nhà phát triển hơn là một công cụ PM có hướng dẫn. Ngược lại, cách tiếp cận có cấu trúc của Lovable (với ngăn xếp được đề xuất, backend tích hợp, v.v.) có thể hạn chế sự tự do của nhà phát triển, nhưng nó cung cấp một lộ trình có hướng dẫn hơn mà những người không phải kỹ sư đánh giá cao. Tùy thuộc vào nhóm, sự khác biệt này có thể là một điểm khó khăn: hoặc Bolt cảm thấy quá thiếu quan điểm (PM có thể vô tình chọn một thiết lập mà nhóm không thích), hoặc Lovable cảm thấy quá bị hạn chế (không sử dụng các framework mà nhóm phát triển ưa thích). Trong cả hai trường hợp, việc điều chỉnh bản thử nghiệm với các tiêu chuẩn của nhóm đòi hỏi sự phối hợp thêm.

• Công cụ cộng tác bên ngoài: Cả Bolt.new và Lovable đều không tích hợp trực tiếp với các bộ công cụ cộng tác phổ biến (không có tích hợp Slack trực tiếp cho thông báo, không có tích hợp Jira để theo dõi vấn đề, v.v.). Điều này có nghĩa là mọi cập nhật hoặc tiến độ trong công cụ phải được thông báo thủ công cho nhóm. Ví dụ, nếu một PM tạo một bản thử nghiệm và muốn nhận phản hồi, họ phải tự chia sẻ liên kết đến ứng dụng đã triển khai hoặc kho lưu trữ GitHub qua email/Slack – các nền tảng sẽ không tự động thông báo cho nhóm hoặc liên kết với các phiếu công việc dự án. Việc thiếu tích hợp với quy trình làm việc của nhóm có thể dẫn đến khoảng cách giao tiếp. Một PM không thể giao nhiệm vụ trong Bolt/Lovable, hoặc để lại nhận xét cho đồng đội về một yếu tố giao diện người dùng cụ thể, theo cách họ có thể làm trong một công cụ thiết kế như Figma. Mọi thứ phải được thực hiện một cách ngẫu hứng, bên ngoài công cụ. Về cơ bản, Bolt.new và Lovable được thiết kế là môi trường một người chơi, điều này đặt ra một thách thức khi một PM muốn sử dụng chúng trong bối cảnh nhiều người chơi.

Tóm lại, Lovable nhỉnh hơn Bolt.new một chút trong các kịch bản làm việc nhóm (nhờ đồng bộ GitHub và cách tiếp cận có cấu trúc mà những người không phải lập trình viên thấy dễ theo dõi hơn). Một quản lý sản phẩm làm việc độc lập có thể chấp nhận thiết lập cá nhân của Bolt, nhưng nếu họ cần có sự tham gia của người khác, các công cụ này có thể trở thành nút thắt cổ chai trừ khi nhóm tạo ra một quy trình thủ công xung quanh chúng. Khoảng cách cộng tác là lý do chính khiến chúng ta thấy người dùng xuất công việc của họ và tiếp tục ở nơi khác – AI có thể khởi động một dự án, nhưng các công cụ truyền thống vẫn cần thiết để tiếp tục dự án một cách cộng tác.

Thách Thức Tích Hợp Với Các Công Cụ Khác​

Phát triển sản phẩm hiện đại liên quan đến một bộ công cụ – nền tảng thiết kế, cơ sở dữ liệu, dịch vụ của bên thứ ba, v.v. Các PM đánh giá cao phần mềm có thể hòa nhập tốt với bộ công cụ hiện có của họ, nhưng Bolt.new và Lovable lại có một hệ sinh thái tích hợp hạn chế, thường yêu cầu các giải pháp thay thế:

• Tích Hợp Công Cụ Thiết Kế: Các nhà quản lý sản phẩm thường bắt đầu với bản phác thảo thiết kế hoặc wireframe. Cả Bolt và Lovable đều nhận ra điều này và giới thiệu các cách để nhập thiết kế, nhưng phản hồi của người dùng về các tính năng này còn trái chiều. Bolt.new đã thêm tính năng nhập Figma (được xây dựng trên plugin Anima) để tạo mã từ thiết kế, nhưng nó chưa đáp ứng được kỳ vọng. Một người thử nghiệm ban đầu đã lưu ý rằng các video quảng cáo cho thấy việc nhập liệu đơn giản, không lỗi, “nhưng còn những phần không [hoạt động] thì sao? Nếu một công cụ muốn trở thành yếu tố thay đổi cuộc chơi, nó phải xử lý được sự phức tạp – không chỉ những thứ dễ dàng.” Trên thực tế, Bolt gặp khó khăn với các tệp Figma không được gọn gàng. Một nhà thiết kế UX đã thử tích hợp Figma của Bolt và thấy nó không mấy ấn tượng đối với bất cứ thứ gì ngoài bố cục cơ bản, cho thấy tích hợp này có thể “chùn bước trước các thiết kế phức tạp”. Lovable gần đây đã ra mắt quy trình Figma-sang-mã của riêng mình thông qua tích hợp Builder.io. Điều này có khả năng mang lại kết quả sạch hơn (vì Builder.io diễn giải Figma và chuyển nó cho Lovable), nhưng vì còn mới nên nó chưa được chứng minh rộng rãi. Ít nhất một so sánh đã ca ngợi Lovable vì “các tùy chọn UI tốt hơn (Figma/Builder.io)” và cách tiếp cận thân thiện với thiết kế hơn. Tuy nhiên, “chậm hơn một chút trong việc tạo bản cập nhật” là một đánh đổi được báo cáo cho sự kỹ lưỡng trong thiết kế đó. Đối với các PM, mấu chốt là việc nhập thiết kế không phải lúc nào cũng đơn giản chỉ bằng một cú nhấp chuột – họ có thể mất thời gian điều chỉnh tệp Figma để phù hợp với khả năng của AI hoặc dọn dẹp giao diện người dùng được tạo sau khi nhập. Điều này làm tăng ma sát trong quy trình làm việc giữa các nhà thiết kế và công cụ AI.

• Tích Hợp Backend và Cơ Sở Dữ Liệu: Cả hai công cụ đều tập trung vào việc tạo giao diện người dùng (front-end), nhưng các ứng dụng thực tế cần dữ liệu và xác thực. Giải pháp được chọn cho cả Bolt.new và Lovable là tích hợp với Supabase (một dịch vụ cơ sở dữ liệu PostgreSQL được lưu trữ + dịch vụ xác thực). Người dùng đánh giá cao sự tồn tại của các tích hợp này, nhưng có những sắc thái trong việc thực thi. Ban đầu, tích hợp Supabase của Bolt.new còn sơ khai; tích hợp của Lovable được coi là “chặt chẽ hơn [và] đơn giản hơn” khi so sánh. Người sáng lập Lovable đã nhấn mạnh rằng hệ thống của Lovable được tinh chỉnh để ít bị “kẹt” hơn, kể cả khi tích hợp cơ sở dữ liệu. Điều đó nói lên rằng, việc sử dụng Supabase vẫn yêu cầu PM phải có một số hiểu biết về lược đồ cơ sở dữ liệu. Trong bài đánh giá Lovable trên Medium, tác giả đã phải tự tạo bảng trong Supabase và tải dữ liệu lên, sau đó kết nối nó qua khóa API để có được một ứng dụng hoạt động đầy đủ (ví dụ: cho các sự kiện và địa điểm của một ứng dụng bán vé). Quá trình này có thể thực hiện được, nhưng không hề tầm thường – không có tính năng tự động phát hiện mô hình dữ liệu của bạn, PM phải tự định nghĩa nó. Nếu có bất kỳ lỗi nào xảy ra trong kết nối, việc gỡ lỗi lại thuộc về người dùng. Lovable cố gắng trợ giúp (trợ lý AI đã đưa ra hướng dẫn khi xảy ra lỗi trong quá trình kết nối Supabase), nhưng nó không hoàn hảo. Bolt.new chỉ gần đây “đã triển khai nhiều cải tiến cho tích hợp Supabase của họ” sau khi nhận được khiếu nại từ người dùng. Trước đó, như một người dùng đã nói, “Bolt… xử lý công việc front-end nhưng không hỗ trợ nhiều về backend” – ngoài các cài đặt sẵn đơn giản, bạn phải tự lo về logic máy chủ. Tóm lại, mặc dù cả hai công cụ đều đã giúp tích hợp backend có thể thực hiện được, nhưng đó là một tích hợp nông. Các PM có thể thấy mình bị giới hạn bởi những gì Supabase cung cấp; bất cứ thứ gì tùy chỉnh hơn (ví dụ: một cơ sở dữ liệu khác hoặc logic máy chủ phức tạp) đều không được hỗ trợ (Bolt và Lovable không tạo mã backend tùy ý bằng các ngôn ngữ như Python/Java, chẳng hạn). Điều này có thể gây khó chịu khi yêu cầu của sản phẩm vượt quá các thao tác CRUD cơ bản.

• Dịch Vụ & API Của Bên Thứ Ba: Một phần quan trọng của các sản phẩm hiện đại là kết nối với các dịch vụ (cổng thanh toán, bản đồ, phân tích, v.v.). Lovable và Bolt có thể tích hợp API, nhưng chỉ thông qua giao diện nhắc lệnh chứ không phải các plugin được xây dựng sẵn. Ví dụ, một người dùng trên Reddit đã giải thích cách người ta có thể nói với AI điều gì đó như “Tôi cần một API thời tiết,” và công cụ sẽ chọn một API miễn phí phổ biến và yêu cầu khóa API. Điều này rất ấn tượng, nhưng nó cũng không rõ ràng – PM phải tin tưởng rằng AI chọn một API phù hợp và triển khai các lệnh gọi một cách chính xác. Không có kho ứng dụng tích hợp hoặc cấu hình đồ họa; tất cả phụ thuộc vào cách bạn ra lệnh. Đối với các dịch vụ phổ biến như thanh toán hoặc email, Lovable dường như có lợi thế hơn bằng cách tích hợp sẵn chúng: theo người sáng lập của nó, Lovable có “tích hợp cho thanh toán + email” trong số các tính năng của mình. Nếu đúng như vậy, điều đó có nghĩa là PM có thể dễ dàng hơn yêu cầu Lovable thêm biểu mẫu thanh toán Stripe hoặc gửi email qua một dịch vụ tích hợp, trong khi với Bolt, người ta có thể phải thiết lập thủ công thông qua các lệnh gọi API. Tuy nhiên, tài liệu về những điều này còn thưa thớt – có khả năng vẫn được xử lý thông qua tác nhân AI thay vì thiết lập bằng cách nhấp chuột. Việc thiếu các mô-đun tích hợp rõ ràng, hướng đến người dùng có thể được coi là một điểm khó khăn: nó yêu cầu thử và sai để tích hợp một cái gì đó mới, và nếu AI không biết một dịch vụ cụ thể, PM có thể gặp bế tắc. Về cơ bản, các tích hợp có thể thực hiện được nhưng không phải là “cắm và chạy.”

• Tích Hợp Chuỗi Công Cụ Doanh Nghiệp: Khi nói đến việc tích hợp với chuỗi công cụ quản lý sản phẩm (Jira cho các tác vụ, Slack cho thông báo, v.v.), Bolt.new và Lovable hiện không cung cấp gì sẵn có. Các nền tảng này hoạt động độc lập. Do đó, một PM sử dụng chúng phải tự cập nhật các hệ thống khác. Ví dụ, nếu PM có một câu chuyện người dùng trong Jira (“Với tư cách là người dùng, tôi muốn tính năng X”) và họ tạo nguyên mẫu tính năng đó trong Lovable, không có cách nào để đánh dấu câu chuyện đó là đã hoàn thành từ bên trong Lovable – PM phải vào Jira và thực hiện. Tương tự, không có bot Slack nào sẽ thông báo “nguyên mẫu đã sẵn sàng” khi Bolt hoàn thành việc xây dựng; PM phải lấy liên kết xem trước và chia sẻ nó. Khoảng cách này không đáng ngạc nhiên khi xem xét sự tập trung ban đầu của các công cụ này, nhưng nó cản trở hiệu quả quy trình làm việc trong môi trường nhóm. Về cơ bản, đó là chuyển đổi ngữ cảnh: bạn làm việc trong Bolt/Lovable để xây dựng, sau đó chuyển sang các công cụ PM của mình để ghi lại tiến độ, sau đó có thể chuyển sang các công cụ giao tiếp của bạn để hiển thị cho nhóm. Phần mềm tích hợp có thể hợp lý hóa điều này, nhưng hiện tại gánh nặng đó đổ lên vai PM.

Tóm lại, Bolt.new và Lovable tích hợp tốt ở một số lĩnh vực kỹ thuật (đặc biệt là với Supabase cho dữ liệu), nhưng chưa tích hợp đầy đủ vào hệ sinh thái công cụ rộng lớn hơn mà các nhà quản lý sản phẩm sử dụng hàng ngày. Lovable đã có những bước tiến nhỏ hơn trong việc cung cấp các đường dẫn tích hợp sẵn (ví dụ: triển khai một cú nhấp chuột, GitHub trực tiếp, một số dịch vụ tích hợp sẵn), trong khi Bolt thường yêu cầu các dịch vụ bên ngoài (Netlify, thiết lập API thủ công). Một bài đánh giá của NoCode MBA đã tương phản rõ ràng điều này: “Lovable cung cấp tính năng xuất bản tích hợp sẵn, trong khi Bolt dựa vào các dịch vụ bên ngoài như Netlify”. Nỗ lực để thu hẹp những khoảng cách này – cho dù bằng cách sao chép mã thủ công, mày mò với các plugin của bên thứ ba hoặc nhập lại các bản cập nhật vào các hệ thống khác – là một sự khó chịu thực sự đối với các PM tìm kiếm trải nghiệm liền mạch.

Hạn Chế Trong Lập Kế Hoạch Sản Phẩm và Quản Lý Lộ Trình​

Ngoài việc xây dựng một bản thử nghiệm nhanh, các nhà quản lý sản phẩm còn chịu trách nhiệm lập kế hoạch tính năng, quản lý lộ trình và đảm bảo sản phẩm có thể phát triển. Phạm vi của Bolt.new và Lovable ở đây rất hẹp – chúng giúp tạo ra một ứng dụng, nhưng không cung cấp công cụ nào để lập kế hoạch sản phẩm rộng hơn hoặc quản lý dự án liên tục.

• Không có Quản lý Backlog hoặc Yêu cầu: Các công cụ xây dựng ứng dụng AI này không bao gồm bất kỳ khái niệm nào về backlog, user story hay nhiệm vụ. Một PM không thể sử dụng Bolt.new hoặc Lovable để liệt kê các tính năng và sau đó xử lý chúng từng cái một theo cách có cấu trúc. Thay vào đó, việc phát triển được thúc đẩy bởi các câu lệnh (“Xây dựng X”, “Bây giờ thêm Y”), và các công cụ sẽ tạo hoặc sửa đổi ứng dụng tương ứng. Điều này hiệu quả cho việc tạo mẫu ngẫu hứng nhưng không thể chuyển thành lộ trình được quản lý. Nếu một PM muốn ưu tiên các tính năng nhất định hoặc lập kế hoạch phát hành, họ vẫn cần các công cụ bên ngoài (như Jira, Trello, hoặc một bảng tính đơn giản) để làm điều đó. AI sẽ không nhắc nhở bạn về những gì đang chờ xử lý hoặc các tính năng liên quan đến nhau như thế nào – nó không có khái niệm về dòng thời gian dự án hoặc sự phụ thuộc, chỉ có các hướng dẫn tức thì bạn đưa ra.

• Khó khăn trong việc Quản lý các Dự án Lớn hơn: Khi các dự án trở nên phức tạp hơn, người dùng nhận thấy các nền tảng này gặp phải giới hạn. Một người đánh giá trên G2 đã lưu ý rằng “khi tôi bắt đầu phát triển danh mục đầu tư của mình, tôi nhận ra không có nhiều công cụ để xử lý các dự án phức tạp hoặc lớn hơn” trong Lovable. Tình cảm này cũng áp dụng cho Bolt.new. Chúng được tối ưu hóa cho các ứng dụng nhỏ, mới; nếu bạn cố gắng xây dựng một sản phẩm đáng kể với nhiều module, vai trò người dùng, logic phức tạp, v.v., quá trình này sẽ trở nên khó quản lý. Không có hỗ trợ cho các module hoặc gói ngoài những gì các framework mã nguồn cơ bản cung cấp. Và vì cả hai công cụ đều không cho phép kết nối với một codebase hiện có, bạn không thể dần dần tích hợp các cải tiến do AI tạo ra vào một dự án dài hạn. Điều này có nghĩa là chúng không phù hợp với việc phát triển lặp đi lặp lại trên một sản phẩm đã trưởng thành. Trên thực tế, nếu một bản thử nghiệm được xây dựng bằng Lovable cần trở thành một sản phẩm thực sự, các nhóm thường viết lại hoặc tái cấu trúc nó bên ngoài công cụ một khi nó đạt đến một kích thước nhất định. Từ góc độ của PM, hạn chế này có nghĩa là bạn coi các sản phẩm của Bolt/Lovable như những bản thử nghiệm dùng một lần hoặc điểm khởi đầu, chứ không phải là sản phẩm thực tế sẽ được mở rộng – bản thân các công cụ không hỗ trợ hành trình đó.

• Tính chất Một Lần của Việc Tạo AI: Bolt.new và Lovable hoạt động giống như các thuật sĩ hơn là môi trường phát triển liên tục. Chúng tỏa sáng trong giai đoạn ý tưởng ban đầu (bạn có một ý tưởng, bạn đưa ra câu lệnh, bạn nhận được một ứng dụng cơ bản). Nhưng chúng thiếu các tính năng để lập kế hoạch và giám sát liên tục tiến độ của sản phẩm. Ví dụ, không có khái niệm về dòng thời gian lộ trình nơi bạn có thể sắp xếp “Sprint 1: triển khai đăng nhập (do AI thực hiện), Sprint 2: triển khai quản lý hồ sơ (việc cần làm)”, v.v. Bạn cũng không thể dễ dàng quay lại phiên bản trước hoặc tạo nhánh cho một tính năng mới – những thực hành tiêu chuẩn trong phát triển sản phẩm. Điều này thường buộc các PM phải có tư duy dùng một lần: sử dụng AI để xác thực ý tưởng nhanh chóng, nhưng sau đó khởi động lại quá trình phát triển “đúng đắn” trong môi trường truyền thống cho bất cứ điều gì ngoài bản thử nghiệm. Việc chuyển giao đó có thể là một điểm khó khăn vì nó về cơ bản là trùng lặp nỗ lực hoặc yêu cầu chuyển đổi bản thử nghiệm sang định dạng dễ bảo trì hơn.

• Không có Tính năng Tương tác với Các Bên Liên Quan: Trong lập kế hoạch sản phẩm, các PM thường thu thập phản hồi và điều chỉnh lộ trình. Các công cụ AI này cũng không giúp ích gì cho việc đó. Chẳng hạn, bạn không thể tạo các kịch bản khác nhau hoặc các tùy chọn lộ trình sản phẩm trong Bolt/Lovable để thảo luận với các bên liên quan – không có chế độ xem dòng thời gian, không có tính năng bỏ phiếu cho tính năng, không có gì tương tự. Mọi cuộc thảo luận hoặc quyết định về những gì sẽ xây dựng tiếp theo phải diễn ra bên ngoài nền tảng. Một PM có thể đã hy vọng, ví dụ, khi AI xây dựng ứng dụng, nó cũng có thể cung cấp danh sách các tính năng hoặc một đặc tả đã được triển khai, sau đó có thể dùng làm tài liệu sống cho nhóm. Nhưng thay vào đó, tài liệu bị hạn chế (lịch sử trò chuyện hoặc các bình luận mã nguồn là ghi chép duy nhất, và như đã lưu ý, lịch sử trò chuyện của Bolt bị giới hạn về độ dài). Việc thiếu tài liệu tích hợp hoặc hỗ trợ lập kế hoạch này có nghĩa là PM phải tự tay ghi lại những gì AI đã làm và những gì còn lại phải làm cho bất kỳ loại lộ trình nào, đây là công việc phát sinh.

Về bản chất, Bolt.new và Lovable không phải là công cụ thay thế cho các công cụ quản lý sản phẩm – chúng là các công cụ hỗ trợ phát triển. Chúng “tạo ra các ứng dụng mới” từ đầu nhưng sẽ không cùng bạn phát triển hoặc quản lý sự tiến hóa của sản phẩm. Các nhà quản lý sản phẩm đã nhận thấy rằng một khi bản thử nghiệm ban đầu được tạo ra, họ phải chuyển sang các chu trình lập kế hoạch & phát triển truyền thống, bởi vì các công cụ AI sẽ không hướng dẫn quá trình đó. Như một blogger công nghệ đã kết luận sau khi thử nghiệm, “Lovable rõ ràng tăng tốc quá trình tạo mẫu nhưng không loại bỏ nhu cầu về chuyên môn của con người… nó không phải là một viên đạn thần kỳ sẽ loại bỏ mọi sự tham gia của con người trong phát triển sản phẩm”. Điều đó nhấn mạnh rằng việc lập kế hoạch, ưu tiên và tinh chỉnh – các hoạt động cốt lõi của PM – vẫn phụ thuộc vào con người và các công cụ tiêu chuẩn của họ, để lại một khoảng trống trong những gì các nền tảng AI này có thể hỗ trợ.

(Lovable.dev vs Bolt.new vs Fine: So sánh các công cụ xây dựng ứng dụng AI và tác nhân mã hóa cho các startup) Hầu hết các công cụ xây dựng ứng dụng AI (như Bolt.new và Lovable) xuất sắc trong việc tạo ra một bản thử nghiệm giao diện người dùng nhanh chóng, nhưng chúng thiếu khả năng xử lý mã backend phức tạp, kiểm thử kỹ lưỡng hoặc bảo trì dài hạn. Các nhà quản lý sản phẩm nhận thấy rằng các công cụ này, mặc dù tuyệt vời cho việc chứng minh khái niệm, không thể xử lý toàn bộ vòng đời sản phẩm ngoài giai đoạn xây dựng ban đầu.

Các Vấn Đề Với Phân Tích, Thông Tin Chuyên Sâu và Theo Dõi Tiến Độ​

Khi một sản phẩm (hoặc thậm chí là một bản thử nghiệm) được xây dựng, một PM muốn theo dõi hiệu suất của nó – cả về tiến độ phát triển lẫn mức độ tương tác của người dùng. Tuy nhiên, Bolt.new và Lovable lại cung cấp hầu như không có công cụ phân tích hoặc theo dõi tích hợp sẵn, điều này có thể là một vấn đề lớn.

• Không có Phân Tích Người Dùng Tích Hợp Sẵn: Nếu một PM triển khai ứng dụng thông qua các nền tảng này, sẽ không có bảng điều khiển nào để xem các chỉ số sử dụng (ví dụ: số lượng người dùng, lượt nhấp, chuyển đổi). Mọi phân tích sản phẩm phải được thêm thủ công vào ứng dụng đã tạo. Chẳng hạn, để có được dữ liệu lưu lượng truy cập cơ bản, một PM sẽ phải chèn Google Analytics hoặc một đoạn mã tương tự vào mã nguồn của ứng dụng. Các tài liệu hỗ trợ của Lovable cũng ghi rõ điều này: “Nếu bạn đang sử dụng Lovable… bạn cần thêm mã theo dõi Google Analytics theo cách thủ công… Không có tích hợp trực tiếp.”. Điều này có nghĩa là cần thêm các bước thiết lập và kỹ thuật mà một PM phải phối hợp (có thể cần sự giúp đỡ của nhà phát triển nếu họ không am hiểu về mã hóa). Việc thiếu phân tích tích hợp sẵn gây rắc rối vì một lý do lớn để tạo mẫu nhanh là để thu thập phản hồi của người dùng – nhưng các công cụ sẽ không thu thập điều đó cho bạn. Nếu một PM ra mắt MVP được tạo bằng Lovable cho một nhóm thử nghiệm, họ sẽ phải tự cài đặt hoặc sử dụng các dịch vụ phân tích bên ngoài để tìm hiểu bất cứ điều gì về hành vi người dùng. Điều này có thể thực hiện được, nhưng làm tăng chi phí và đòi hỏi sự quen thuộc với việc chỉnh sửa mã hoặc sử dụng giao diện hạn chế của nền tảng để chèn các đoạn mã.

• Thông Tin Chuyên Sâu Hạn Chế về Quy Trình của AI: Về phía phát triển, các PM cũng có thể muốn có phân tích hoặc phản hồi về cách tác nhân AI đang hoạt động – ví dụ, các chỉ số về số lần thử để làm đúng một việc, hoặc những phần mã nào nó thay đổi thường xuyên nhất. Những thông tin chuyên sâu như vậy có thể giúp PM xác định các khu vực rủi ro của ứng dụng hoặc đánh giá mức độ tin cậy vào các thành phần do AI xây dựng. Tuy nhiên, cả Bolt.new lẫn Lovable đều không hiển thị nhiều thông tin này. Ngoài các số liệu thô như số token đã sử dụng hoặc tin nhắn đã gửi, không có nhật ký phong phú về quá trình ra quyết định của AI. Thực tế, như đã đề cập, Bolt.new thậm chí không hiển thị sự khác biệt (diffs) của các thay đổi mã. Sự thiếu minh bạch này đủ gây khó chịu đến mức một số người dùng đã cáo buộc AI của Bolt tiêu tốn token chỉ để có vẻ bận rộn: “được tối ưu hóa cho vẻ ngoài hoạt động hơn là giải quyết vấn đề thực sự,” như một người đánh giá đã nhận xét về mô hình tiêu thụ token. Điều đó cho thấy các PM nhận được rất ít thông tin chuyên sâu về việc “công việc” của AI có hiệu quả hay lãng phí, ngoài việc xem kết quả cuối cùng. Nó về cơ bản là một hộp đen. Khi mọi thứ không ổn, PM phải tin tưởng một cách mù quáng vào lời giải thích của AI hoặc đi sâu vào mã nguồn thô – không có phân tích nào để xác định, chẳng hạn, “20% số lần tạo thất bại do X.”

• Theo Dõi Tiến Độ và Lịch Sử Phiên Bản: Từ góc độ quản lý dự án, cả hai công cụ đều không cung cấp các tính năng để theo dõi tiến độ theo thời gian. Không có biểu đồ burn-down, không có phần trăm tiến độ, thậm chí không có danh sách kiểm tra đơn giản các tính năng đã hoàn thành. Dòng thời gian duy nhất là lịch sử cuộc trò chuyện (đối với giao diện dựa trên trò chuyện của Lovable) hoặc chuỗi các lời nhắc (prompts). Và như đã lưu ý trước đó, cửa sổ lịch sử của Bolt.new bị giới hạn, nghĩa là bạn không thể cuộn lại về đầu một phiên làm việc dài. Nếu không có lịch sử hoặc tóm tắt đáng tin cậy, một PM có thể mất dấu những gì AI đã làm. Cũng không có khái niệm về các mốc quan trọng (milestones) hoặc phiên bản. Nếu một PM muốn so sánh bản thử nghiệm hiện tại với phiên bản của tuần trước, các công cụ không cung cấp khả năng đó (trừ khi PM tự lưu một bản sao mã nguồn). Việc thiếu lịch sử hoặc quản lý trạng thái này có thể làm cho việc đo lường tiến độ trở nên khó khăn hơn. Ví dụ, nếu PM có mục tiêu như “cải thiện thời gian tải của ứng dụng lên 30%,” không có công cụ đo lường hoặc phân tích hiệu suất tích hợp sẵn trong Bolt/Lovable để giúp đo lường điều đó – PM sẽ cần xuất ứng dụng và sử dụng các công cụ phân tích bên ngoài.

• Vòng Lặp Phản Hồi Người Dùng: Việc thu thập phản hồi định tính (ví dụ: từ người dùng thử nghiệm hoặc các bên liên quan) cũng nằm ngoài phạm vi của các công cụ này. Một PM có thể đã hy vọng có một cách dễ dàng để người thử nghiệm gửi phản hồi từ bên trong bản thử nghiệm hoặc để AI đề xuất cải tiến dựa trên tương tác của người dùng, nhưng các tính năng như vậy không tồn tại. Bất kỳ vòng lặp phản hồi nào cũng phải được tổ chức riêng biệt (khảo sát, các buổi thử nghiệm thủ công, v.v.). Về cơ bản, một khi ứng dụng được xây dựng và triển khai, Bolt.new và Lovable sẽ đứng sang một bên – chúng không giúp theo dõi cách ứng dụng được đón nhận hoặc hoạt động. Đây là một khoảng cách kinh điển giữa phát triển và quản lý sản phẩm: các công cụ xử lý phần trước (ở một mức độ nào đó), nhưng không cung cấp gì cho phần sau.

Để minh họa, một PM tại một công ty khởi nghiệp có thể sử dụng Lovable để xây dựng một ứng dụng demo cho một dự án thí điểm, nhưng khi trình bày kết quả cho nhóm hoặc nhà đầu tư của họ, họ sẽ phải dựa vào các giai thoại hoặc phân tích bên ngoài để báo cáo mức độ sử dụng vì bản thân Lovable sẽ không hiển thị dữ liệu đó. Nếu họ muốn theo dõi xem một thay đổi gần đây có cải thiện mức độ tương tác của người dùng hay không, họ phải tự trang bị cho ứng dụng các công cụ phân tích và có thể là logic kiểm thử A/B. Đối với các PM đã quen với các nền tảng tích hợp hơn (ngay cả một công cụ như Webflow cho trang web cũng có một số dạng thống kê, hoặc Firebase cho ứng dụng cũng có phân tích), sự im lặng của Bolt/Lovable sau khi triển khai là điều đáng chú ý.

Tóm lại, việc thiếu các công cụ phân tích và theo dõi đồng nghĩa với việc các PM phải quay lại các phương pháp truyền thống để đo lường thành công. Đây là một kỳ vọng bị bỏ lỡ – sau khi sử dụng một công cụ AI tiên tiến như vậy để xây dựng sản phẩm, người ta có thể mong đợi sự trợ giúp AI tiên tiến trong việc phân tích nó, nhưng điều đó (chưa) phải là một phần của gói. Như một hướng dẫn đã nói, nếu bạn muốn có phân tích với Lovable, bạn sẽ cần phải làm theo cách cũ vì “GA không được tích hợp”. Và khi nói đến việc theo dõi tiến độ phát triển, trách nhiệm hoàn toàn thuộc về PM để tự duy trì bất kỳ trạng thái dự án nào bên ngoài công cụ. Sự ngắt kết nối này là một vấn đề lớn đối với các nhà quản lý sản phẩm đang cố gắng hợp lý hóa quy trình làm việc của họ từ ý tưởng cho đến phản hồi của người dùng.

Kết luận: Góc nhìn so sánh​

Từ các câu chuyện và đánh giá thực tế của người dùng, rõ ràng rằng Bolt.new và Lovable đều có những điểm mạnh nhưng cũng tồn tại những vấn đề lớn đối với các nhà quản lý sản phẩm (PM). Cả hai đều thực hiện rất tốt lời hứa cốt lõi của mình – tạo ra các nguyên mẫu ứng dụng hoạt động nhanh chóng – đó là lý do tại sao chúng thu hút hàng ngàn người dùng. Tuy nhiên, khi nhìn từ góc độ của một PM, người không chỉ phải xây dựng sản phẩm mà còn phải cộng tác, lập kế hoạch và lặp lại trên đó, các công cụ này cho thấy những hạn chế tương tự.

• Bolt.new có xu hướng cung cấp sự linh hoạt hơn (bạn có thể chọn framework, chỉnh sửa mã trực tiếp hơn) và tốc độ thô, nhưng phải trả giá bằng chi phí bảo trì cao hơn. Các PM không có chuyên môn về mã hóa có thể gặp khó khăn khi Bolt báo lỗi hoặc yêu cầu sửa chữa thủ công. Mô hình dựa trên token và các tính năng tích hợp ban đầu còn hạn chế thường dẫn đến sự thất vọng và các bước bổ sung. Bolt có thể được coi là một công cụ mạnh mẽ nhưng thô sơ – tuyệt vời cho việc thử nghiệm nhanh hoặc người dùng kỹ thuật, ít phù hợp hơn cho quy trình làm việc nhóm chuyên nghiệp.

• Lovable tự định vị mình là một “kỹ sư AI full-stack” thân thiện với người dùng hơn, điều này mang lại trải nghiệm mượt mà hơn cho những người không phải là kỹ sư. Nó trừu tượng hóa nhiều khía cạnh khó khăn hơn (với triển khai tích hợp, đồng bộ hóa GitHub, v.v.) và có xu hướng hướng dẫn người dùng với các đầu ra có cấu trúc (mã ban đầu sạch hơn, tích hợp thiết kế). Điều này có nghĩa là các PM thường “tiến xa hơn với Lovable” trước khi cần sự can thiệp của nhà phát triển. Tuy nhiên, Lovable chia sẻ nhiều vấn đề cốt lõi của Bolt: nó không phải là phép thuật – người dùng vẫn gặp phải các hành vi AI khó hiểu, đôi khi phải khởi động lại và phải rời khỏi nền tảng cho bất cứ điều gì ngoài việc xây dựng nguyên mẫu. Hơn nữa, các tính năng bổ sung của Lovable (như chỉnh sửa trực quan hoặc một số tích hợp nhất định) vẫn đang phát triển và đôi khi khá cồng kềnh (ví dụ: một người dùng thấy quy trình triển khai của Lovable khó chịu hơn của Bolt, mặc dù nó chỉ là một cú nhấp chuột – có thể do thiếu tùy chỉnh hoặc kiểm soát).

Khi so sánh, cả hai công cụ đều rất giống nhau ở những gì chúng còn thiếu. Chúng không thay thế nhu cầu quản lý sản phẩm cẩn thận; chúng tăng tốc một khía cạnh của nó (triển khai) nhưng lại tạo ra những thách thức mới ở các khía cạnh khác (gỡ lỗi, cộng tác). Đối với một nhà quản lý sản phẩm, việc sử dụng Bolt.new hoặc Lovable giống như tua nhanh để có một phiên bản sớm của sản phẩm của bạn – điều này cực kỳ giá trị – nhưng sau đó nhận ra bạn phải chậm lại để giải quyết tất cả các chi tiết và quy trình mà các công cụ không bao gồm.

Để quản lý kỳ vọng, các PM đã học cách sử dụng các công cụ AI này như những bổ sung, chứ không phải là giải pháp toàn diện. Như một đánh giá trên Medium đã nói một cách khôn ngoan: các công cụ này “nhanh chóng biến ý tưởng của tôi thành một khung ứng dụng hoạt động,” nhưng bạn vẫn “cần sự giám sát trực tiếp của con người khi thêm độ phức tạp”. Các vấn đề chung – vấn đề UX, khoảng trống quy trình làm việc, nhu cầu tích hợp, thiếu sót trong lập kế hoạch và phân tích – nhấn mạnh rằng Bolt.new và Lovable phù hợp nhất cho việc tạo nguyên mẫu và khám phá, hơn là quản lý sản phẩm từ đầu đến cuối. Biết được những hạn chế này, một nhà quản lý sản phẩm có thể lập kế hoạch xung quanh chúng: tận hưởng những thành công nhanh chóng mà chúng mang lại, nhưng sẵn sàng sử dụng các công cụ thông thường và chuyên môn của con người để tinh chỉnh và thúc đẩy sản phẩm tiến lên.

Nguồn tham khảo:

• Các cuộc thảo luận thực tế của người dùng trên Reddit, Product Hunt và LinkedIn làm nổi bật sự thất vọng với Bolt.new và Lovable.
• Các đánh giá và bình luận từ G2 và Product Hunt so sánh hai công cụ và liệt kê các điểm thích/không thích.
• Các bài đánh giá blog chi tiết (NoCode MBA, Trickle, Fine.dev) phân tích giới hạn tính năng, việc sử dụng token và các vấn đề tích hợp.
• Tài liệu và hướng dẫn chính thức chỉ ra việc thiếu một số tích hợp nhất định (ví dụ: phân tích) và nhu cầu sửa chữa thủ công.