Ở phần trước, Py đã thử nhìn SaaS-pocalypse như một quá trình phân hóa, thay vì “trận đại hồng thủy” sẽ cuốn mọi công ty phần mềm đi cùng lúc. Nhưng nếu code và giao diện ngày càng dễ tạo, còn AI agent dần đứng giữa user với phần mềm, điều gì sẽ làm nên một product khó bị thay thế?

Code không phải product

Py từng viết về vibe coding như một cách “bình dân hóa” việc viết code. Nhờ AI, khoảng cách từ một ý tưởng đến phiên bản chạy thử đang ngắn lại đáng kể. Một người không có nền tảng kỹ thuật vẫn có thể dựng giao diện, kết nối dữ liệu và tạo ra một ứng dụng tương đối hoàn chỉnh.

Nhưng sau vài lần tự làm prototype, Py nhận ra một điều: tạo ra được phần mềm chưa đồng nghĩa với việc đã tạo ra một product. Một prototype thường chỉ cần chứng minh rằng ý tưởng có thể chạy được. Product thật phải trả lời thêm nhiều câu hỏi khác: dữ liệu được lưu và bảo vệ như thế nào, mỗi người được phép làm gì, hệ thống xử lý ra sao khi có lỗi, kết quả do AI tạo ra có thể kiểm tra lại không, và ai sẽ chịu trách nhiệm nếu kết quả đó sai. Đây đều là những phần ít được nhìn thấy trên giao diện, nhưng lại quyết định liệu user có đủ tin tưởng để sử dụng sản phẩm trong công việc thật hay không.

Trong bài về prompt, context và harness engineering, Py từng ghi lại rằng chất lượng của một AI product không chỉ nằm ở việc chọn model nào. Nó còn phụ thuộc vào thông tin mà AI được phép sử dụng, những quy tắc nghiệp vụ cần tuân theo và cách team định nghĩa một kết quả “đúng”. Đây cũng là lợi thế mà nhiều công ty SaaS lâu năm đang nắm giữ. Họ không chỉ sở hữu code hay giao diện, mà còn có dữ liệu đã được tổ chức, lịch sử hoạt động, hệ thống phân quyền, các quy tắc vận hành và khả năng kết nối với nhiều phần mềm khác trong doanh nghiệp. AI agent có thể trở thành giao diện mới để user làm việc với những tài sản này. Nhưng bản thân agent không tự tạo ra được chúng.

Dữ liệu thị trường cũng chưa cho thấy mọi công ty SaaS đang đồng loạt suy yếu. Theo SaaS Capital, mức tăng trưởng trung vị của các công ty B2B SaaS tư nhân trong năm 2025 vẫn đạt 22%; chỉ 7,3% không tăng trưởng hoặc tăng trưởng âm.¹ Vì vậy, có lẽ câu hỏi không còn là SaaS có biến mất hay không. Câu hỏi phù hợp hơn là: SaaS nào đang nắm giữ những giá trị khó thay thế, và SaaS nào chỉ đang bán một lớp giao diện mà AI có thể dễ dàng skip?

Value sẽ nằm ở đâu?

Đây là lý giải của bản thân Py, dĩ nhiên không đại diện cho lập trường, quan điểm của bất kỳ tổ chức nào.

Đầu tiên là từ tính năng sang bối cảnh. Khi một tính năng có thể được tạo lại tương đối nhanh, lợi thế không chỉ nằm ở việc phần mềm làm được gì, mà còn ở việc nó hiểu ai đang sử dụng, được phép truy cập dữ liệu nào và phải tuân theo những quy tắc gì. Một chatbot có thể trả lời câu hỏi chung chung. Nhưng một AI agent dùng trong doanh nghiệp phải hiểu chính sách nội bộ, lịch sử giao dịch, trạng thái hiện tại của từng trường hợp và quyền hạn của từng người. Những thông tin này không tự xuất hiện chỉ vì model thông minh hơn; chúng cần được tích lũy, tổ chức và liên tục cập nhật trong quá trình vận hành.

Tiếp theo là từ hỗ trợ thao tác sang hoàn thành công việc. Trước đây, phần mềm cung cấp công cụ để user tự thực hiện từng bước. Với AI agent, product có thể nhận yêu cầu rồi chủ động hoàn thành một phần quy trình. Khi đó, thiết kế product không còn chỉ xoay quanh việc giúp user bấm ít nút hơn. Team phải xác định rõ phần việc nào AI được phép tự làm, lúc nào cần hỏi lại và trường hợp nào phải chuyển quyền quyết định về cho con người.

Cuối cùng là từ mức độ sử dụng sang mức độ tin cậy. Trước đây, một product có nhiều lượt đăng nhập và thời gian sử dụng dài thường được xem là có mức độ gắn bó tốt. Nhưng nếu agent có thể hoàn thành công việc mà không cần user trực tiếp mở ứng dụng, thời gian sử dụng ít hơn chưa chắc là tín hiệu xấu. Những chỉ số đáng quan tâm hơn có thể là tỷ lệ công việc được hoàn thành chính xác, số lần con người phải sửa kết quả và khả năng của hệ thống khi phát hiện hoặc phục hồi sau sai sót.

Nói cách khác, value không nhất thiết biến mất khi giao diện bị thay thế. Nó có thể dịch chuyển xuống những lớp nằm sâu hơn: bối cảnh, dữ liệu, quy trình và trust.

Quay lại product

Với Py, SaaS-pocalypse không chỉ là câu chuyện của nhà đầu tư hay các công ty phần mềm. Nó chạm khá trực tiếp đến cách một PO nhìn vào backlog và roadmap. Khi code và giao diện ngày càng dễ tạo, một roadmap có nhiều tính năng chưa chắc đã đồng nghĩa với một product mạnh. Team có thể phát triển nhanh hơn, nhưng nếu kết quả chỉ là thêm màn hình, thêm nút bấm và thêm thao tác cho user, phần giá trị thật sự chưa chắc đã tăng tương ứng.

Nó khá giống điều Py từng viết trong bài Tokenmaxxing: số lượng đầu ra tăng lên rất nhanh, nhưng tác động cuối cùng đi về đâu thì vẫn chưa rõ. Vì vậy, Py đang thử đặt câu hỏi “build gì?” sau ba câu hỏi khác:

• Product đang sở hữu dữ liệu, bối cảnh hay quy trình nào mà một AI model phổ thông không có?
• Phần việc nào user thật sự muốn giao cho hệ thống hoàn thành, thay vì chỉ nhận thêm một công cụ hỗ trợ?
• Nếu một AI agent khác trở thành giao diện chính, product còn giữ lại giá trị gì ở phía sau?

Py cũng bắt đầu chú ý nhiều hơn đến những phần khá “chán” của product: chất lượng dữ liệu, phân quyền, cách đánh giá kết quả AI, phương án dự phòng khi hệ thống gặp lỗi và khả năng kiểm tra lại lịch sử hoạt động.

Trước đây, Py thường nhìn những phần này như các yêu cầu kỹ thuật phải hoàn thiện sau. Bây giờ, Py nghĩ chúng có thể chính là phần tạo nên trust, mà trust thì khó có thể được vibe code trong một buổi chiều.

Sau lớp giao diện

Sau hai phần của bài viết này, Py vẫn chưa nghĩ SaaS đang đi đến tận thế. Nhưng Py cũng không nghĩ một công ty phần mềm sẽ tiếp tục có lợi thế chỉ vì họ biết code, có nhiều tính năng hay đã tồn tại đủ lâu.

Khi việc tạo ra phần mềm trở nên dễ hơn, code và giao diện dần chuyển từ lợi thế cạnh tranh thành điều kiện cơ bản. Phần khó hơn nằm phía sau những thứ user có thể nhìn thấy: dữ liệu có đủ tốt không, hệ thống có hiểu đúng bối cảnh không, quy trình có đủ sâu không, kết quả có thể kiểm tra lại không và user có đủ tin để giao một phần công việc cho product hay không. Nhìn theo cách này, AI agent không nhất thiết thay thế toàn bộ SaaS. Nó có thể thay thế lớp giao diện của một số sản phẩm, lấy đi một vài thao tác từng được bán như tính năng, đồng thời làm lộ rõ đâu mới là phần value thật sự ở phía sau.

Với người làm product, điều đó cũng khiến câu hỏi “build được gì?” bớt quan trọng hơn một chút. Vì khi gần như ai cũng có thể build, khác biệt sẽ nằm ở việc mình hiểu vấn đề sâu đến đâu, nắm giữ context gì và có thể biến một phiên bản chạy được thành một hệ thống đủ đáng tin để người khác sử dụng hay không.

¹ SaaS Capital, 2026 Private B2B SaaS Company Growth Rate Benchmarks

Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này.

Chúc bạn nhiều may mắn và bình an.

Anpy