Có một thay đổi khá thú vị đang diễn ra với SaaS.

Trước đây, chúng ta mua phần mềm để làm việc.

Mua Jira để quản lý task. Mua Salesforce để quản lý khách hàng. Mua Figma để thiết kế. Mua Slack để trao đổi.

Phần mềm cung cấp công cụ, còn con người thực hiện công việc.

Nhưng nếu AI có thể tự đọc dữ liệu, gọi API, tạo task, gửi email, kiểm tra kết quả và tiếp tục thực hiện bước tiếp theo thì mô hình này bắt đầu thay đổi.

Lúc đó, câu hỏi không còn là:

"Phần mềm giúp tôi làm việc này như thế nào?"

Mà có thể trở thành:

"Tôi giao việc này cho phần mềm như thế nào?"

Đây, theo tôi, mới là thay đổi đáng chú ý của SaaS trong giai đoạn tiếp theo.

---

SaaS truyền thống đang bán công cụ

Hãy lấy một workflow rất đơn giản.

Một developer phát hiện production có bug.

Với cách làm quen thuộc, họ sẽ:

Check monitoring
    ↓
Open logs
    ↓
Tìm nguyên nhân
    ↓
Mở Jira
    ↓
Tạo ticket
    ↓
Mở GitHub
    ↓
Tạo branch
    ↓
Fix code
    ↓
Create PR
    ↓
Review
    ↓
Deploy
    ↓
Update Jira
    ↓
Thông báo Slack

Không có bước nào quá khó.

Vấn đề nằm ở chỗ có rất nhiều bước nhỏ.

Và phần lớn SaaS hiện nay được xây dựng để giúp con người thực hiện từng bước đó nhanh hơn.

Jira giúp tạo và quản lý ticket.

GitHub giúp quản lý code.

Slack giúp giao tiếp.

Monitoring giúp quan sát hệ thống.

Mỗi sản phẩm giải quyết một phần của workflow.

Con người vẫn là người kết nối tất cả chúng lại.

Đó chính là giới hạn tương đối tự nhiên của SaaS truyền thống.

---

AI-native SaaS thay đổi interface trước tiên

Khi AI được đưa vào SaaS, bước thay đổi đầu tiên khá dễ thấy.

Thay vì phải tìm đúng menu, mở đúng form rồi nhập dữ liệu, người dùng có thể nói:

"Tạo một ticket cho lỗi login trên iOS, priority high và assign cho frontend team."

AI hiểu yêu cầu rồi thực hiện thao tác.

User intent
    ↓
AI
    ↓
SaaS API
    ↓
Create ticket

Đây là AI-assisted SaaS.

Nó đã tốt hơn UX truyền thống, nhưng về bản chất vẫn chưa thay đổi quá nhiều.

AI đang giúp con người sử dụng phần mềm.

Con người vẫn là người quyết định workflow.

---

Bước tiếp theo mới đáng chú ý: Agent

Agent khác chatbot ở chỗ nó không chỉ trả lời.

Nó có thể có:

• mục tiêu;
• context;
• khả năng lập kế hoạch;
• tools;
• quyền truy cập hệ thống;
• khả năng thực hiện nhiều bước;
• khả năng quan sát kết quả và quyết định bước tiếp theo.

Ví dụ:

"Chuẩn bị release version 2.5."

Một chatbot thông thường có thể trả lời:

"Bạn nên kiểm tra ticket, pull request và CI trước khi release."

Một agent có thể thực sự làm:

                    Release Agent
                          │
              ┌───────────┼───────────┐
              ↓           ↓           ↓
            Jira       GitHub        CI/CD
              │           │           │
              ↓           ↓           ↓
        Check tickets   Check PR    Check build
              │           │           │
              └───────────┼───────────┘
                          ↓
                  Generate release note
                          ↓
                    Human approval
                          ↓
                       Release

Đây là lúc khái niệm Agentic SaaS trở nên thú vị.

SaaS không còn chỉ cung cấp UI để con người thao tác.

Nó trở thành một tập hợp các capability mà agent có thể sử dụng.

---

Một thay đổi rất quan trọng: UI không còn là trung tâm

Đây có lẽ là implication mà frontend developer nên quan tâm nhất.

Trong SaaS truyền thống:

User
  ↓
UI
  ↓
Business logic
  ↓
API
  ↓
Database

UI là cửa ngõ chính.

Nhưng trong một hệ thống có agent:

                  User
                   ↓
                 Intent
                   ↓
                 Agent
              ↙    ↓    ↘
           API    Tools    UI
            ↓       ↓       ↓
                 Systems

UI vẫn còn.

Thậm chí có thể còn quan trọng hơn ở một số workflow.

Nhưng vai trò của UI thay đổi.

Nó không nhất thiết phải là nơi người dùng thực hiện từng thao tác.

Nó có thể trở thành nơi để:

• xem agent đang làm gì;
• kiểm tra reasoning/evidence phù hợp;
• approve một hành động nguy hiểm;
• chỉnh lại mục tiêu;
• xem kết quả;
• rollback;
• can thiệp khi agent đi sai hướng.

Nói cách khác:

Frontend có thể chuyển từ việc xây "màn hình thao tác" sang xây "human control layer" cho software có khả năng tự hành động.

Đây là một thay đổi khá lớn về cách thiết kế UX.

---

Từ Software-as-a-Service đến Service-as-Software

Nếu đẩy ý tưởng này thêm một bước nữa, SaaS có thể thay đổi cả thứ mà nó bán.

SaaS truyền thống bán:

"Bạn có một phần mềm để xử lý invoice."

Service-as-Software có thể hướng tới:

"Hãy giao việc xử lý invoice cho tôi."

Ví dụ:

"Xử lý invoice tháng này cho khách hàng A"

Agent có thể:

Find customer
     ↓
Read orders
     ↓
Calculate amount
     ↓
Calculate tax
     ↓
Generate invoice
     ↓
Send invoice
     ↓
Update accounting system
     ↓
Report result

Người dùng không quan tâm nhiều đến việc agent đã click vào màn hình nào.

Họ quan tâm:

Invoice đã được xử lý chưa?

Đây là một thay đổi về value proposition.

SaaS trước đây bán tool.

Mô hình mới có xu hướng bán outcome.

---

Nhưng agent không tự nhiên thay thế SaaS

Đây là chỗ cần cẩn thận.

Có một cách nhìn hơi quá đơn giản:

"AI agent mạnh lên → SaaS sẽ biến mất."

Tôi không nghĩ vậy.

Một agent vẫn cần dữ liệu và hệ thống để làm việc.

Ví dụ agent muốn tạo invoice thì đâu đó vẫn phải tồn tại:

Customer
Invoice
Payment
Order
Permission
Audit log
Transaction

Đó chính là phần system of record.

AI có thể quyết định:

"Tạo invoice cho customer A."

Nhưng hệ thống backend vẫn phải đảm bảo:

• customer nào;
• invoice ID nào;
• số tiền bao nhiêu;
• quyền của agent có được tạo invoice hay không;
• transaction có thành công không;
• audit log ở đâu;
• rollback thế nào.

Vì vậy, SaaS có thể không biến mất.

Nó có thể dịch chuyển vai trò.

Từ:

UI
 ↓
Business workflow
 ↓
Database

sang:

             Agents
                ↓
        API / Business Logic
                ↓
          SaaS Core
                ↓
        System of Record

UI chỉ còn là một trong những cách truy cập hệ thống.

---

API sẽ trở nên quan trọng hơn UI

Nếu điều này xảy ra, một SaaS có UX rất đẹp nhưng API tệ sẽ gặp vấn đề.

Agent không cần nhìn thấy một button đẹp.

Agent cần khả năng:

createTicket()
updateTicket()
searchCustomer()
generateInvoice()
deployApplication()
getDeploymentStatus()

Vì vậy giá trị của SaaS sẽ ngày càng nằm ở:

Data + API + Business Rules + Permissions + Events + AI capability

Thay vì chỉ:

UI + features.

Đây cũng là lý do một hệ thống được thiết kế với API rõ ràng, permission tốt và domain model sạch có lợi thế lớn khi bước sang AI/agent.

---

Một vấn đề khác sẽ xuất hiện: quyền hạn

Khi con người tạo ticket:

User
 ↓
Click Create
 ↓
Server validates permission
 ↓
Create ticket

Rất dễ hình dung ai đang làm gì.

Nhưng nếu:

User
 ↓
Agent
 ↓
Tool
 ↓
API
 ↓
Database

thì câu hỏi trở nên khó hơn:

Agent được phép làm đến đâu?

Ví dụ:

Agent:
✓ Read Jira
✓ Create ticket
✓ Update ticket
✓ Read GitHub
✓ Create PR
✗ Merge production branch
✗ Deploy production

Những ranh giới này sẽ trở thành một phần quan trọng của architecture.

Đặc biệt với những thao tác có hậu quả lớn, mô hình hợp lý thường không phải:

AI tự quyết định tất cả.

Mà là:

Agent
  ↓
Prepare action
  ↓
Human approval
  ↓
Execute

Human-in-the-loop vì vậy không chỉ là một UX feature.

Nó có thể trở thành một security boundary.

---

SaaS cũng có thể thay đổi cách tính tiền

SaaS truyền thống rất dễ hiểu:

$20/user/month

Nhưng nếu một agent có thể thay con người thực hiện hàng nghìn thao tác thì "số user" không còn phản ánh đầy đủ giá trị.

Có thể xuất hiện nhiều mô hình hơn:

Subscription
     +
Usage
     +
Outcome

Ví dụ:

$100/month
+
AI usage
+
$X / successfully processed transaction

Hoặc sản phẩm có thể tính tiền theo workflow.

Ví dụ thay vì:

$30/user/month

có thể tiến tới:

$0.5 cho mỗi invoice được xử lý thành công.

Đây không phải kết luận rằng pricing theo outcome chắc chắn sẽ thắng.

Nó chỉ cho thấy một điều:

Khi software bắt đầu trực tiếp tạo ra kết quả, cách đo giá trị của software cũng thay đổi.

---

Vậy SaaS truyền thống có bị AI nuốt mất?

Một phần có thể.

Đặc biệt là những SaaS chủ yếu cung cấp:

• CRUD;
• dashboard;
• workflow đơn giản;
• form;
• data transformation;
• automation cơ bản.

Nếu một agent có thể truy cập dữ liệu và API trực tiếp, một số UI/workflow có thể trở thành abstraction không còn cần thiết.

Nhưng những hệ thống có:

• dữ liệu độc quyền;
• domain logic phức tạp;
• compliance;
• permission;
• transaction;
• audit;
• ecosystem;
• network effect;

thì khó bị thay thế chỉ bằng một agent.

Vì agent cần một nguồn dữ liệu đáng tin cậy và một hệ thống có contract rõ ràng để hành động.

---

Điều này có ý nghĩa gì với Frontend Developer?

Đây là phần tôi nghĩ đáng quan tâm nhất nếu bạn đang làm frontend.

Không cần vội kết luận:

"AI sẽ lấy mất việc frontend."

Thay vào đó, nên nhìn sự thay đổi ở interaction model.

Frontend truyền thống:

Page
 ↓
Component
 ↓
Form
 ↓
API
 ↓
Result

AI-native frontend có thể trở thành:

Intent
 ↓
Agent
 ↓
Streaming state
 ↓
Tool execution
 ↓
Result
 ↓
Human approval
 ↓
UI / Visualization

Những thứ như:

• streaming;
• optimistic UI;
• async state;
• agent status;
• tool execution;
• approval flow;
• retry;
• cancellation;
• rollback;
• generated UI;
• permission;
• observability;

sẽ trở nên đáng quan tâm hơn.

Ví dụ thay vì chỉ hiển thị:

Loading...

một agent UI có thể cần thể hiện:

Analyzing request       ✓
Searching Jira          ✓
Checking GitHub         ✓
Creating PR             ●
Waiting for approval    ○

Đây là một loại UX khác hẳn loading spinner truyền thống.

---

Nhưng không phải project nào cũng cần Agent

Đây là điểm tôi sẽ giữ khá rõ.

Nếu workflow chỉ là:

User
 ↓
Fill form
 ↓
Save

thì đừng thêm agent chỉ vì sản phẩm đang có AI.

Agent kéo theo rất nhiều thứ:

• context management;
• permission;
• failure handling;
• observability;
• evaluation;
• cost;
• security;
• unpredictable behavior;
• human approval;
• debugging.

Một CRUD đơn giản đôi khi vẫn là giải pháp tốt nhất.

Ví dụ:

"Tạo một user."

Không nhất thiết phải cần:

User
 ↓
AI Agent
 ↓
Understand intent
 ↓
Call tool
 ↓
Create user

Một form với validation có thể tốt hơn rất nhiều.

AI/Agent đáng cân nhắc khi workflow có tính mở, nhiều bước, nhiều hệ thống và khó biểu diễn bằng một tập UI action cố định.

Đó mới là nơi abstraction này bắt đầu có giá trị.

---

Tôi nghĩ SaaS tương lai sẽ không có một hình dạng duy nhất

Có lẽ chúng ta sẽ không đi từ:

SaaS → Agent SaaS

theo một đường thẳng.

Thực tế có thể giống:

                    SaaS
                     │
          ┌──────────┼──────────┐
          ↓          ↓          ↓
       Human UI   AI Copilot   Agent
          │          │          │
          └──────────┼──────────┘
                     ↓
               SaaS Core/API
                     ↓
              System of Record

Một sản phẩm tốt có thể cho phép cả ba.

Người dùng muốn tự làm → có UI.

Người dùng muốn được hỗ trợ → có Copilot.

Người dùng muốn giao việc → có Agent.

Đây có lẽ là hướng thực tế hơn việc cố biến mọi phần mềm thành chatbot.

---

Một cách nhìn khác về tương lai của SaaS

Nếu phải rút gọn toàn bộ câu chuyện thành một thay đổi, tôi sẽ nhìn như thế này:

SaaS 1.0

"Đây là công cụ.
Hãy sử dụng nó."


AI SaaS

"Đây là công cụ.
Tôi có thể giúp bạn sử dụng nó."


Agentic SaaS

"Đây là mục tiêu.
Tôi có thể thực hiện workflow cho bạn."


Service-as-Software

"Đây là kết quả bạn cần.
Software sẽ xử lý phần còn lại."

Và từ góc độ software engineering, điều đáng học không phải chỉ là cách gọi LLM hay tạo một chatbot.

Thứ đáng quan tâm hơn là cách xây một hệ thống mà AI có thể hành động một cách an toàn.

Nó kéo theo những bài toán rất quen thuộc với software engineer:

API design.

Permission.

State management.

Transactions.

Observability.

Error handling.

Security.

Auditability.

Human approval.

AI chỉ làm những bài toán đó trở nên khó hơn và quan trọng hơn.

Vì vậy, nếu SaaS đang đi từ software that helps people work sang software that can do the work, thì engineering fundamentals không biến mất.

Ngược lại.

Chúng trở thành nền móng để agent có thể làm việc mà chúng ta dám tin tưởng.