Vibe coding và Tính bất biến của hệ thống

Vibe coding và Tính bất biến của hệ thống - Thiết lập chốt chặn logic khi làm việc cùng AI

Ở bài trước về Vibe Coding, mình đã chia sẻ khoảng cách lớn giữa ứng dụng demo cá nhân và hệ thống Production của doanh nghiệp. AI có thể tạo giao diện mượt, sinh code chạy được sau vài chục phút. Nhưng khi đưa vào vận hành thực tế, hệ thống rất dễ gặp lỗi nghiêm trọng, sai lệch dữ liệu hoặc xung đột logic.

Bản chất vấn đề: Nôm na thì AI rất giỏi tạo luồng xử lý trôi chảy ở bề mặt, nhưng không tự ý thức được các ràng buộc sống còn của hệ thống — tức Tính bất biến (System Invariants).

Nếu BA, Product hay Developer không nắm chắc tính bất biến, bạn dễ bị đánh lừa bởi bản đặc tả hoặc đoạn code trông rất hợp lý nhưng đang âm thầm phá vỡ tính toàn vẹn dữ liệu.

---

1. Tính bất biến của hệ thống là gì?

Về cơ bản thì:

Tính bất biến (System Invariant) là những điều kiện logic hoặc ràng buộc dữ liệu bắt buộc phải luôn luôn đúng tại mọi thời điểm, trong mọi trạng thái của hệ thống, bất kể có bao nhiêu người dùng thao tác hay có bao nhiêu lỗi mạng xảy ra.

Quy trình nghiệp vụ có thể thay đổi theo thị trường, nhưng tính bất biến bên trong hệ thống là nguyên tắc không bao giờ được vi phạm.

Trong thực tế, có 4 nhóm tính bất biến kinh điển cần lưu ý:

1. Tính bất biến về kế toán và dòng tiền (Conservation of Value)Tổng phát sinh Nợ luôn bằng Tổng phát sinh Có tại mọi thời điểm. Không có đồng tiền nào tự sinh ra hay biến mất khỏi hệ thống.

Một công thức thanh toán cơ bản phải luôn được bảo toàn, ví dụ như: Tổng tiền thanh toán = Tiền hàng - Giảm giá + Phí vận chuyển + Thuế

Nếu có luồng xử lý làm lệch công thức dù chỉ 1 đồng, hệ thống đã lỗi toàn vẹn tài chính.

2. Tính bất biến về số lượng và kho vận (Non-Negativity)Số lượng tồn kho khả dụng (Available Quantity) và tồn kho thực tế (Physical Quantity) trong cơ sở dữ liệu không bao giờ được phép là số âm.

Hàng hóa ngoài đời là hữu hạn. Nếu số lượng khách đặt vượt quá tồn kho khả dụng, hệ thống phải chặn lại và thông báo ngay cho người dùng.

Để giải quyết bài toán này trong lúc khách nhập thông tin thanh toán, hệ thống chuẩn mực thường áp dụng cơ chế tạm giữ tồn kho (Inventory Reservation): tạm khóa giữ số hàng đó trong thời gian giới hạn (ví dụ: 10 phút). Nếu hết thời gian mà khách không thanh toán, số hàng này lập tức được nhả ngược lại kho.

Khi hai người cùng bấm mua sản phẩm cuối cùng tại một thời điểm, hệ thống chỉ được phép cho một người giữ hàng thành công.

Lưu ý về Backorder / Pre-order: Một số hệ thống lớn (như Amazon, Apple) vẫn cho phép khách đặt hàng khi kho đã hết hàng (Backorder/Pre-order) để tự kích hoạt lệnh nhập hàng từ nhà cung cấp và xếp chỗ ưu tiên cho khách. Tuy nhiên, tính bất biến vẫn được bảo toàn: hệ thống phân định rạch ròi giữa tồn kho vật lý sẵn có và số lượng đặt trước, tuyệt đối không ghi nhận âm kho ảo để đánh lừa quy trình vận hành.

3. Tính bất biến về vòng đời trạng thái (Acyclic State Progression)Vòng đời của một đối tượng nghiệp vụ (Đơn hàng, Hóa đơn, Yêu cầu hỗ trợ) bản chất là "con đường một chiều không quay đầu" (Directed Acyclic Graph - DAG).

Một đơn hàng khi đã chuyển sang trạng thái ĐÃ HỦY hoặc HOÀN TẤT thì không được phép quay ngược lại trạng thái ĐANG XỬ LÝ. Mọi thay đổi sau đó đều phải xử lý bằng một nghiệp vụ mới (tạo đơn mới, tạo phiếu hoàn tiền), thay vì sửa đè lên trạng thái cũ.

Lưu ý: Nếu BA hoặc đội ngũ thiết kế nghiệp vụ cố tình tạo bước "quay xe" — cho phép mở lại đơn đã hủy để xử lý tiếp thay vì tạo đơn mới — toàn bộ chuỗi nghiệp vụ phía sau sẽ có thể bị phá vỡ: hàng hóa nhả về kho có thể đã bị bán cho khách khác, tiền đã hoàn không thể tự thu hồi, và báo cáo kế toán lịch sử lập tức bị sai lệch số liệu.

4. Tính bất biến về quan hệ dữ liệu (Referential Integrity)Chi tiết đơn hàng (OrderItem) không thể tồn tại độc lập ngoài đơn hàng cha (Order). Giao dịch trừ tiền bắt buộc phải gắn với tài khoản người dùng xác định.

Nếu xóa đơn cha mà dữ liệu con vẫn sót lại, bạn đã tạo ra dữ liệu mồ côi (orphaned data), làm sai lệch toàn bộ báo cáo doanh thu và tồn kho.

---

2. Case study thực tế: AI đã vi phạm tính bất biến như thế nào?

Hãy xem một ví dụ thực tế: Yêu cầu AI xây dựng tài liệu đặc tả kỹ thuật hoàn chỉnh cho tính năng "Cập nhật địa chỉ giao hàng sau khi đặt hàng thành công".

• Prompt:
  Google Drive PreviewG-DRIVE
• Kết quả:
  Google Docs DocumentG-DOC

Kết quả AI tạo ra là tài liệu dài hơn 500 dòng rất chỉn chu:

• Khung quản lý thực thi với 5W1H và Tiêu chí hoàn thành (DoD).
• Ma trận phân cấp trạng thái đơn hàng (Order State Eligibility Matrix).
• Sơ đồ hoạt động (Activity Diagram bằng Mermaid) chi tiết từng nhánh.
• Lược đồ cơ sở dữ liệu (ERD) với bảng lưu vết (order_address_change_log) và bảng điều chỉnh cước (shipping_fee_adjustment).
• Bộ 3 RESTful API contracts chuẩn hóa từ Request/Response JSON đến mã lỗi HTTP.
• Tầng kỹ thuật nâng cao: Khóa phân tán Redis (SET NX EX 10), Khóa lạc quan SQL (WHERE version = :expectedVersion), và Message Broker Kafka (order.shipping_address.updated).

Trông thì có vẻ như rất ổn, nhưng tài liệu này vẫn còn các lỗ hổng về tính bất biến như:

1. Khóa tạm thời hết hạn trước khi khách thanh toán xong

• Thiết kế của AI: Khi địa chỉ mới làm tăng cước vận chuyển đối với đơn thanh toán trực tuyến, hệ thống mở cửa sổ thanh toán phụ thu kéo dài 15 phút. Tuy nhiên, ở tầng kiến trúc phân tán, AI lại cấu hình Redis Lock bảo vệ đơn hàng với thời gian sống (TTL) vỏn vẹn 10 giây (SET lock:order:{orderId} <request_id> NX EX 10).

• Hệ quả thực tế: Khách hàng mất 1–2 phút mở app ngân hàng quét mã QR. Sau 10 giây, Redis Lock tự giải phóng. Ngay lúc đó, nhân viên kho quét mã đơn hàng sang đóng gói (PACKING).

  2 phút sau, webhook từ cổng thanh toán báo thành công, hệ thống gọi API cập nhật nhưng bị Database từ chối vì đơn đã sang đóng gói. Khách bị trừ tiền phụ thu nhưng đơn vẫn giao về địa chỉ cũ. Phát sinh giao dịch mồ côi (Orphaned Surcharge) mà không có cơ chế hoàn tiền tự động.

2. Vi phạm tính bất biến bảo toàn tồn kho khi tái điều phối kho

• Thiết kế của AI: Khi địa chỉ mới yêu cầu chuyển kho xuất hàng (Warehouse Re-allocation), AI thiết kế luồng tuần tự: (1) Kiểm tra tồn kho tại Kho mới -> (2) Xác nhận đủ hàng -> (3) Hủy lệnh phân bổ tại Kho cũ và cấp phát tại Kho mới.

• Hệ quả thực tế: Đây là lỗi kiểm tra trước khi thực thi thiếu tính nguyên tử (Check-Then-Act without Atomic Reservation).

  Giả sử Kho mới chỉ còn đúng 1 sản phẩm. Ngay khi hệ thống vừa hủy giữ hàng ở Kho cũ, một khách hàng khác trên sàn bấm mua và chiếm giữ sản phẩm tại Kho mới.

  Khi hệ thống gửi lệnh cấp phát sang Kho mới thì bị từ chối vì hết hàng. Đơn hàng mất quyền giữ hàng ở cả 2 kho, rơi vào tình trạng thiếu hàng (Stock Outage) không thể xuất xưởng.

3. Biến dạng tính bất biến hạch toán tài chính, Voucher và Thuế GTGT

• Thiết kế của AI: AI tính chênh lệch chi phí bằng phép trừ số học đơn giản: fee_difference = new_shipping_fee - old_shipping_fee.

• Hệ quả thực tế: Bỏ qua cấu trúc trợ giá trong thương mại điện tử. Đơn hàng gốc có thể áp mã freeship do sàn tài trợ. Khi đổi địa chỉ làm đổi đơn vị vận chuyển (3PL mới không áp dụng trợ giá), khoản tiền này bị hủy hay ai bù lỗ?

  Đồng thời, cước vận chuyển chịu thuế GTGT. Với đơn hàng doanh nghiệp đã xuất hóa đơn điện tử (E-Invoice), đổi cước làm biến động tổng tiền bắt buộc phải kích hoạt quy trình phát hành Hóa đơn điều chỉnh theo luật thuế. CSDL do AI vẽ ra không hề có trường dữ liệu nào ghi nhận thuế hay hóa đơn.

4. Lỗi Dual-Write và thiếu Transactional Outbox

• Thiết kế của AI: Giao dịch CSDL cập nhật địa chỉ -> Giải phóng Redis Lock -> Bắn sự kiện lên Kafka topic order.shipping_address.updated để báo cho WMS và đơn vị vận chuyển (3PL).

• Hệ quả thực tế: Lỗi phân tán kinh điển (Dual-Write Problem). Nếu CSDL lưu thành công địa chỉ mới, nhưng tiến trình mạng gặp sự cố (Kafka broker timeout hoặc crash container), message không bao giờ được gửi đi.

  CSDL lưu địa chỉ mới (Hà Nội), nhưng kho và vận chuyển vẫn in nhãn dán giao về địa chỉ cũ (Đà Nẵng). Để bảo toàn tính nhất quán dữ liệu, bắt buộc phải dùng Transactional Outbox: ghi sự kiện vào cùng Database Transaction với đơn hàng trước khi đẩy sang Kafka.

5. Ảo tưởng tính lũy nghiệm (Idempotency Illusion)

• Thiết kế của AI: Đưa tham số idempotency_key vào Request payload của API để tạo vẻ ngoài chuẩn Enterprise.

• Hệ quả thực tế: Trong Data Schema, cả 3 bảng liên quan (orders, order_address_change_log, shipping_fee_adjustment) không lưu cột này và không có ràng buộc duy nhất (UNIQUE INDEX).

  Khi mạng giật lag khiến người dùng bấm gửi liên tiếp 2 lần, hoặc hệ thống mạng retry, không có chốt chặn nào ở tầng cơ sở dữ liệu ngăn việc nhân đôi các bản ghi điều chỉnh cước.

Bài học rút ra: Cần lưu ý rằng trong ví dụ trên, AI nhận yêu cầu trong một hội thoại thiếu ngữ cảnh dự án và các dữ liệu đầu vào liên quan, chỉ có đúng một câu lệnh ngắn nên việc viết thiếu sót các trường hợp nghiệp vụ là điều đương nhiên. Tuy nhiên, điều này không phủ nhận một thực tế: AI có thể bắt chước cú pháp tài liệu rất thành thạo và vẽ sơ đồ thuyết phục, nhưng lại thiếu tư duy về ranh giới trạng thái (Boundary States), tính đồng thời (Concurrency) và tính toán phân tán (Distributed Invariants). Nếu con người không chủ động đặt ra chốt chặn, hệ thống sẽ rất dễ gặp sự cố khi đưa vào vận hành thực tế.

---

3. Thiết lập Guardrails khi làm việc cùng AI

Để làm chủ quá trình cộng tác với AI và không bị đánh lừa bởi kết quả bề mặt, bạn nên áp dụng quy trình 3 bước sau:

1. Khi viết prompt: Định nghĩa trước các yêu cầu bất biến (Requirements & Invariants)Trước khi mở IDE hay yêu cầu AI thiết kế tính năng, bạn phải tự trả lời: Điều gì tuyệt đối không được phép sai trong bài toán này?

Hãy viết ra 3 đến 5 mệnh đề logic bắt buộc, ví dụ:

• "Tồn kho khả dụng không bao giờ được nhỏ hơn 0."
• "Địa chỉ giao hàng chỉ được phép sửa khi đơn hàng ở trạng thái CHỜ XỬ LÝ."
• "Mọi thay đổi làm biến động phí vận chuyển phải phát sinh giao dịch thu thêm hoặc hoàn tiền trước khi cập nhật đơn."

Về bản chất, tính bất biến chính là "Requirement" cốt lõi. Khi đưa các yêu cầu này vào context cho AI ngay từ đầu, kết quả sinh ra sẽ chặt chẽ hơn. Requirement đầu vào càng đầy đủ, logic hệ thống do AI xây dựng càng an toàn, hạn chế tối đa lỗ hổng phát sinh.

2. Chuẩn bị và định nghĩa State Transition (Bao quát cả góc nhìn BA lẫn Dev)Khi nhận bản đặc tả hoặc mã nguồn do AI sinh ra, cần rà soát lại toàn bộ vòng đời trạng thái của đối tượng.

Cần phân biệt rõ hai tầng trạng thái:

• State Transition của BA: Tập trung vào chu trình nghiệp vụ (Business Lifecycle) từ góc nhìn người dùng và vận hành (MỚI TẠO -> ĐÃ THANH TOÁN -> ĐANG ĐÓNG GÓI -> GIAO THÀNH CÔNG / ĐÃ HỦY). Trạng thái chuyển đổi khi có sự kiện nghiệp vụ hợp lệ.
• State Machine của Dev: Đi sâu vào mô hình kỹ thuật thực thi của hệ thống, quản lý cả trạng thái trung gian, điều kiện bảo vệ (Guard Conditions), và xử lý bất thường kỹ thuật (thao tác đồng thời từ 2 thiết bị, mất mạng, cổng thanh toán phản hồi chậm, Timeout, Idempotency và Rollback).

Khi làm việc với AI, thiếu sót phổ biến của BA là chỉ vẽ State Transition ở luồng lý tưởng (Happy Path). AI cũng sẽ chỉ sinh ra tài liệu hoặc mã nguồn cho luồng màu hồng đó. Khi đưa vào thực tế, hệ thống sụp đổ vì thiếu các chốt chặn của State Machine.

Vì vậy, hãy chủ động quét mọi điểm chuyển trạng thái bằng các câu hỏi rà soát:

• "Nếu thao tác này xảy ra đồng thời từ 2 thiết bị cùng một giây thì sao?"
• "Nếu đang xử lý chuyển trạng thái mà mất kết nối mạng thì hệ thống ghi nhận trạng thái nào?"
• "Có trường hợp nào khiến các mệnh đề bất biến ở Bước 1 bị sai lệch không?"

3. Thiết lập chốt chặn thực thi (Cho cả Non-tech User và Developer)

Tùy vào vai trò trong dự án, giải pháp thiết lập chốt chặn được triển khai ở hai cấp độ:

Dành cho Non-tech User:Bạn không trực tiếp can thiệp mã nguồn hay cơ sở dữ liệu, nhưng hoàn toàn có thể thiết lập guardrails qua tài liệu đặc tả và tiêu chí nghiệm thu:

• Đặc tả Business Rules có điều kiện phủ định: Viết quy tắc nghiệp vụ theo cú pháp chuẩn: NẾU [Điều kiện], HỆ THỐNG [Hành động] - TUYỆT ĐỐI KHÔNG [Hành động cấm]. Tránh các mô tả mơ hồ như "hệ thống xử lý linh hoạt".
• Bắt AI sinh Ma trận ngoại lệ (Failure & Edge Cases Matrix): Khi yêu cầu AI thiết kế luồng, thêm prompt bắt buộc: "Liệt kê toàn bộ các trường hợp thất bại, thao tác đồng thời (Concurrency) và sự cố mạng có thể xảy ra, cùng hành vi tương ứng của hệ thống". Lấy danh sách này làm Tiêu chí nghiệm thu (Acceptance Criteria - DoD).
• Dùng bộ câu hỏi thực tế để kiểm tra giải pháp của AI hoặc nghiệm thu với đội ngũ kỹ thuật:
  • "Nếu 2 người cùng bấm mua món hàng cuối cùng thì ai được, ai mất?"
  • "Nếu khách thanh toán bị lag mạng thì tiền có bị trừ mà đơn bị treo không?"
  • "Nếu đơn hàng đã chuyển sang khâu đóng gói thì quyền sửa trên app đã bị khóa cứng chưa?"

Dành cho Developer / Solution Architect:Ở tầng kỹ thuật, bạn có thể tham khảo việc chuyển hóa các tính bất biến thành những ràng buộc cứng trong Database Schema và kiến trúc hệ thống, ví dụ như:

• Dùng CHECK (quantity >= 0) để database tự động từ chối nếu có lệnh làm âm kho.
• Dùng FOREIGN KEY ... ON DELETE RESTRICT để ngăn việc xóa dữ liệu cha làm mồ côi dữ liệu con.
• Dùng UNIQUE (order_id, idempotency_key) để chống trùng lặp giao dịch khi người dùng bấm nút nhiều lần.
• Đóng gói các thao tác cập nhật liên quan trong cùng Database Transaction với mức độ cô lập phù hợp, kết hợp mô hình Transactional Outbox khi đồng bộ sang hệ thống ngoại vi (WMS, 3PL).

---

4. Lời kết

Sự khác biệt khi làm phần mềm giữa một người có tư duy hệ thống, tuân thủ các quy tắc và một người chỉ gõ câu lệnh rồi quan tâm tới kết quả bề mặt nằm ở chính năng lực kiểm chứng tính bất biến.

Người có tư duy hệ thống sẽ luôn nhận diện những điều kiện cốt lõi không được phép sai, chủ động thiết lập chốt chặn để bảo vệ dữ liệu, và chịu trách nhiệm đến cùng về giải pháp khi đưa vào thực tế. Ngược lại, việc chỉ nhìn vào giao diện mượt mà hay tài liệu bóng bẩy của AI rất dễ tạo ra ảo tưởng về một sản phẩm hoàn thiện.

AI là công cụ đắc lực giúp tăng tốc công việc. Nhưng chính tư duy phản biện, sự thấu hiểu kiến trúc và kỷ luật kỹ thuật của bạn mới là yếu tố quyết định hệ thống có vận hành an toàn và bền vững hay không.

Hy vọng góc nhìn và case study thực tế này sẽ giúp bạn thiết lập được những guardrails vững chắc khi làm việc cùng AI.