Tại sao các doanh nghiệp lớn đang quay lại với code sau một thời gian dài say mê với automation nền tảng low-code?

Nhìn vào bức tranh chuyển đổi số năm 2025, có một nghịch lý đang âm thầm diễn ra trong các phòng kỹ thuật của những tập đoàn hàng đầu. Sau gần một thập kỷ rót hàng triệu đô la vào các nền tảng kéo thả, các giám đốc công nghệ bắt đầu lặng lẽ phê duyệt ngân sách cho những đội phát triển phần mềm truyền thống. Họ thuê lại các kỹ sư Java, C# và React. Họ mở lại những repository từng bị coi là di sản lỗi thời. Đây không phải là một cuộc chiến tôn giáo giữa trường phái “code” và “no-code”. Đây là một bài toán kinh tế lạnh lùng mà ở đó, chi phí ẩn của sự tiện lợi đã vượt qua ngưỡng chịu đựng của hệ thống.

Cái bẫy ngọt ngào của sự đơn giản hoá

Khi một nền tảng low-code hứa hẹn giúp nhân viên nghiệp vụ tạo ra ứng dụng mà không cần viết một dòng lệnh nào, nó đánh trúng vào mong muốn nguyên thủy nhất của nhà quản lý: giảm sự phụ thuộc vào bộ phận IT vốn luôn bị coi là nút thắt cổ chai. Cơ chế vận hành của những nền tảng này thực chất là một mạng lưới các hàm đã được đóng gói sẵn. Mỗi lần bạn kéo một nút “Gửi email” hoặc “Tạo bản ghi”, bạn không đang lập trình, mà đang kích hoạt một chuỗi lệnh XML hoặc JSON đã được viết cứng bởi nhà cung cấp.

Vấn đề nằm ở chỗ, các hàm đóng gói ấy được thiết kế để phục vụ số đông. Chúng giống như những viên gạch Lego tiêu chuẩn. Khi bạn cần xây một ngôi nhà có hình dạng thông thường, mọi thứ rất nhanh. Nhưng khi nghiệp vụ của tập đoàn bắt đầu cần một bức tường cong 15 độ, lập tức bạn phải đẽo gọt, chắp vá và cuối cùng là đập vỡ cả viên gạch nguyên bản để nhồi vào đó một đoạn code tuỳ chỉnh.

Key Takeaway: Low-code không xoá bỏ code. Nó chỉ cất code vào một chiếc hộp đen mà bạn không có chìa khoá. Khi hộp đen vỡ, bạn còn tệ hơn lúc ban đầu vì thậm chí không hiểu được cấu trúc bên trong.

Ba vết nứt không thể hàn gắn

Sự thất bại của một dự án automation quy mô lớn hiếm khi nằm ở giao diện hay tính năng. Nó nằm ở ba cơ chế lõi mà các nền tảng low-code xử lý một cách thô sơ bậc nhất.

Vòng đời của một khối dữ liệu

Trong môi trường doanh nghiệp, dữ liệu không đứng yên. Nó biến đổi qua hàng chục hệ thống trung gian. Khi một hợp đồng được ký trên DocuSign, nó cần được xé nhỏ thành các bản ghi kế toán, cập nhật vào CRM, kích hoạt quy trình nhân sự và đồng bộ với kho dữ liệu. Các nền tảng low-code xử lý việc này thông qua các connector API tĩnh. Mỗi connector là một đường ống cứng, đúc sẵn.

Sai lầm chết người xảy ra khi định dạng đầu ra của CRM thay đổi một trường dữ liệu, dù chỉ là từ CustomerName thành FullName. Trong kiến trúc code truyền thống, bạn chỉ cần sửa một dòng mapping. Trong low-code, nếu nền tảng không hỗ trợ xử lý lỗi ở tầng thấp đó, toàn bộ flow tự động sẽ im lặng sụp đổ, tạo ra những dòng dữ liệu ma không ai phát hiện cho đến cuối kỳ đối soát tài chính.

Logic điều kiện và nghịch lý độ phức tạp

Các quy trình nghiệp vụ không vận hành theo kiểu “nếu đúng thì đi tiếp, nếu sai thì dừng”. Chúng vận hành theo kiểu “nếu đúng và là quý 3 và khách hàng VIP và tỷ giá lớn hơn 25k thì phê duyệt, còn không thì chuyển sang luồng kiểm tra thủ công nhưng phải gửi cảnh báo cho giám đốc vùng”.

Khi biểu diễn logic này trên giao diện kéo thả, bạn sẽ có một mớ hỗn độn các mũi tên, hình thoi và hộp điều kiện đan xen như một đĩa spaghetti. Nghiên cứu về tâm lý học nhận thức chỉ ra rằng bộ não con người xử lý logic phân nhánh tuần tự qua văn bản (code) tốt hơn rất nhiều so với xử lý trực quan không gian hai chiều phức tạp. Đến một ngưỡng độ phức tạp nhất định, việc đọc một đoạn switch-case 50 dòng còn trực quan hơn một canvas chứa 50 khối hình.

Chi phí biên của việc mở rộng

Đây là yếu tố quan trọng nhất mà các doanh nghiệp thường bỏ qua trong bài toán TCO ban đầu. Với code native, chi phí biên cho người dùng thứ 1.000.001 gần như bằng 0. Hạ tầng máy chủ tăng thêm vài đô la, còn codebase vẫn thế. Với phần lớn các nền tảng low-code, bạn trả tiền theo đầu người dùng cuối, theo lượt chạy automation hoặc theo dung lượng dữ liệu xử lý. Khi doanh nghiệp lớn mở rộng quy mô từ 100 lên 10.000 nhân viên, chi phí không tăng tuyến tính mà tăng theo cấp số nhân, trong khi hiệu năng lại đi xuống vì kiến trúc đa tầng phình to.

Mô phỏng tình huống: Hệ thống quản lý đơn hàng tại Demeter Corp

Bối cảnh

Demeter Corp, một chuỗi cung ứng nông sản quy mô vừa, quyết định số hoá quy trình xử lý đơn hàng tươi sống của mình vào năm 2023. Họ chọn một nền tảng low-code hàng đầu để xây dựng hệ thống Order Management System vì cam kết “ra mắt trong 3 tháng, không cần viết code”.

Quy trình ban đầu rất đơn giản: Đơn hàng từ sàn thương mại điện tử -> Phân loại dựa trên khu vực giao hàng -> Điều phối tới kho lạnh tương ứng -> Xuất hoá đơn tự động.

Chất xúc tác cho sự sụp đổ

Vào quý 2 năm 2025, Demeter áp dụng chính sách mới: Nếu nhiệt độ ngoài trời khu vực giao hàng vượt quá 38°C, đơn hàng phải được tự động cộng thêm phí bảo quản lạnh cao cấp, sử dụng xe đông lạnh thay vì xe mát, và thời gian giao hàng bị rút ngắn 30% để tránh hư hỏng.

Trên nền tảng low-code, việc này yêu cầu:

1. Gọi tới API thời tiết bên thứ ba theo thời gian thực (tốn thêm license connector).

2. Tạo một bảng điều kiện phức tạp với 3 biến động: nhiệt độ, độ ẩm, loại sản phẩm.

3. Ghi đè logic điều phối kho mặc định để chọn xe đông lạnh.

Đội ngũ vận hành mất 4 tuần loay hoay với giao diện kéo thả nhưng luôn gặp lỗi “Race Condition”: Khi nhiệt độ biến động ngay tại ngưỡng 38°C trong lúc máy chủ xử lý, đơn hàng có thể bị tính phí hai lần hoặc không bị tính phí.

Giải pháp “quay về nguyên liệu thô”

Cuối năm 2025, CTO của Demeter hạ lệnh gỡ bỏ module này khỏi nền tảng low-code. Họ viết lại toàn bộ luồng xử lý bằng Python với một vòng lặp sự kiện bất đồng bộ (asyncio). Toàn bộ logic khó nhằn trên được xử lý bằng một hàm Python thuần tuý dài chưa đến 100 dòng, container hoá bằng Docker và triển khai trên Kubernetes cluster nội bộ.

Kết quả: Tốc độ xử lý tăng gấp 4 lần, loại bỏ hoàn toàn lỗi Race Condition nhờ cơ chế idempotency key trong code. Họ vẫn giữ lại nền tảng low-code để dựng các dashboard báo cáo cho quản lý, nhưng toàn bộ phần lõi nghiệp vụ logic đã được “hồi hương” về code.

Kiến trúc composite: Mô hình vận hành cho doanh nghiệp lớn

Từ bài học trên, bản chất hạ tầng số của một tập đoàn không phải là sự lựa chọn nhị phân giữa code và low-code. Nó là một kiến trúc phân lớp theo dòng chảy dữ liệu.

Hãy nhìn thẳng vào cách một bit dữ liệu di chuyển trong doanh nghiệp. Nó trải qua ba giai đoạn: Tiếp nhận, Biến đổi và Phân phối.

Việc sử dụng low-code ở giai đoạn Tiếp nhận là hợp lý, nơi bạn cần kết nối nhanh với các API bên thứ ba có giao thức chuẩn. Việc sử dụng low-code ở Phân phối cũng có thể chấp nhận được, nếu bạn cần nhân viên nghiệp vụ tự thiết kế giao diện xem báo cáo.

Nhưng giai đoạn Biến đổi – nơi logic cốt lõi của doanh nghiệp vận hành, nơi tiền được tạo ra hoặc mất đi – nó đòi hỏi sự chính xác tuyệt đối và khả năng kiểm soát đến từng bit. Dữ liệu ở giai đoạn này phải được biến đổi bởi các thuật toán mà bạn có thể “chạm” tới tận cùng logic toán học của nó, thứ mà những hộp đen low-code không thể cung cấp.

Code, ở dạng nguyên thủy nhất, là tập hợp các chỉ thị logic mà CPU thực thi trực tiếp mà không có lớp phiên dịch trung gian nào có thể tự ý diễn giải lại. Đó là sự khác biệt căn bản.

Chiến lược thực thi: Định vị ranh giới sống còn

Việc quay lại với code không đồng nghĩa với việc sa thải toàn bộ nhóm vận hành low-code và mở một cuộc “thập tự chinh” công nghệ. Đó là một sai lầm chiến lược. Cách tiếp cận thực dụng nằm ở việc vẽ lại ranh giới dựa trên tính chất của entropy trong hệ thống.

Hệ thống bất biến và khả biến

Trong mọi doanh nghiệp, có những quy trình có độ entropy thấp – chúng gần như không thay đổi theo thời gian. Ví dụ: Quy trình xin nghỉ phép, quy trình tạo mã nhân viên, quy trình gửi thông báo nội bộ. Đây là vùng đất an toàn cho low-code. Sự tiện lợi là tối đa, rủi ro sai hng thấp.

Ngược lại, các quy trình có entropy cao – thay đổi liên tục theo thị trường, theo khuyến mãi, theo quy định thuế khoá – phải được ánh xạ sang code native bằng bất kỳ giá nào. Logic tính giá động dịp Black Friday, thuật toán phân bổ hàng tồn kho khi đứt chuỗi cung ứng, hay bộ quy tắc phát hiện gian lận đều thuộc nhóm này. Chúng là trái tim cạnh tranh của doanh nghiệp. Đặt trái tim vào một cỗ máy mà bạn không nắm được sơ đồ mạch là một canh bạc có tỷ lệ thua cao.

Điểm cần lưu ý khi chuyển đổi ngược

Khi kéo một ứng dụng từ nền tảng low-code về code, doanh nghiệp thường mắc kẹt ở dữ liệu. Các nền tảng low-code thường lưu trữ dữ liệu trong các cơ sở dữ liệu độc quyền, khiến việc xuất dữ liệu ra ngoài trở thành một cơn ác mộng về tính toàn vẹn. Bắt buộc phải có một giai đoạn “bảo trì kép” (vừa chạy hệ cũ, vừa chạy hệ mới) cho đến khi dữ liệu được so sánh khớp từng bản ghi một.

So sánh năng lực nền tảng trong môi trường doanh nghiệp

Không phải mọi nền tảng low-code đều giống nhau. Sự khác biệt nằm ở mức độ cho phép can thiệp vào tầng thấp.

Đặc tính kỹ thuật	Low-Code thuần tuý (Doanh nghiệp)	Low-Code lai (Có code-first backing)	Mô hình Code Native (Microservices)
Cơ chế xử lý lỗi	Hộp thoại mặc định của nền tảng	Tùy chỉnh được một phần qua webhook	Toàn quyền kiểm soát Exception Handling
Tốc độ xử lý dữ liệu lớn	Giới hạn bởi API Gateway của nhà cung cấp	Phụ thuộc vào kiến trúc backend tự dựng	Tuyến tính với tài nguyên phần cứng được cấp
Quản lý phiên bản (Versioning)	Gần như không tồn tại, rollback thủ công	Git-based, nhưng UI binding có thể gãy	Toàn bộ quy trình CI/CD chuẩn DevOps
Chi phí biên (10K users)	Rất cao, tính theo block hoặc seat	Vừa phải, trả phí nền tảng + hạ tầng	Thấp, chủ yếu là chi phí vận hành máy chủ
Tính di động (Vendor Lock-in)	Gần như tuyệt đối	Một phần, logic nằm ngoài nền tảng	Hoàn toàn linh hoạt, chạy được trên mọi cloud

Thẻ điểm đánh giá mức độ sẵn sàng cho việc hồi quy về code

Trước khi quyết định viết lại bất c thứ gì, doanh nghiệp cần chấm điểm mức độ phù hợp của hệ thống hiện tại. Dưới đây là thẻ điểm tự đánh giá dành cho bài toán quản lý đơn hàng phức tạp (tương tự case study trên).

Tiêu chí	Điểm	Ghi chú thực tiễn
Độ phức tạp của luật nghiệp vụ (1-10)	9	Quá nhiều biến động về nhiệt độ, thời gian và chi phí. Vượt khả năng cấu hình kéo thả.
Tần suất thay đổi logic cốt lõi	8	Chính sách vận hành thay đổi theo mùa vụ. Code dễ sửa và test hơn canvas có mũi tên rối.
Khả năng kiểm soát lỗi dữ liệu	7	Dữ liệu đơn hàng là cốt lõi tài chính. Sai một ly là lỗ nghiệp vụ, cần cơ chế idempotency cứng.
Mức độ phụ thuộc vào nhà cung cấp	10	Hiện tại đang bị lock-in hoàn toàn, không thể thương lượng giá khi scale. Cần giải phóng.
Năng lực đội ngũ kỹ thuật nội bộ	6	Đội ngũ có thể viết Python tốt nhưng chưa quen với quy trình DevOps. Cần thời gian ramp-up.

Tổng điểm trung bình: 8.0 / 10 (Mức Khá, xu hướng thiên về nhu cầu chuyển đổi cấp thiết).

Với điểm số này, quyết định của Demeter Corp là hoàn toàn có cơ sở. Họ không phải là những kẻ cuồng tín công nghệ. Họ là những nhà quản trị rủi ro giỏi. Năng lực đội ngũ (6 điểm) là rủi ro duy nhất, nhưng hoàn toàn có thể giải quyết bằng việc thuê thêm 1 senior developer hoặc đào tạo nội bộ, đổi lại việc loại bỏ hoàn toàn rủi ro “khóa chặt nhà cung cấp” (10 điểm) và kiểm soát được logic biến động cao.

Những tín hiệu từ đường chân trời 2026

Việc các doanh nghiệp lớn quay lại với code không phải là dấu chấm hết cho ngành công nghiệp low-code. Ngành này vẫn sẽ phát triển rực rỡ, đặc biệt ở phân khúc doanh nghiệp vừa và nhỏ, hoặc các phòng ban không trọng yếu. Nhưng ở phân khúc cao nhất của thị trường – nơi dữ liệu được tính bằng petabyte và logic nghiệp vụ thay đổi từng phút – sẽ có một sự phân định quyền lực rõ ràng.

Thế hệ kiến trúc sư phần mềm năm 2026 đang nâng cấp khái niệm automation lên một tầm cao mới. Họ không còn hỏi “Làm sao để chạy cái này mà không cần code?”, mà họ hỏi “Làm sao để code trở thành tấm khiên chắn cuối cùng, bảo vệ dữ liệu khỏi sự hỗn loạn của các quy trình tự động?”.

Các nền tảng mới sẽ buộc phải lộ diện phần lõi của chúng. Xu hướng “Headless Automation” – nơi nền tảng chỉ cung cấp API mạnh mẽ, còn giao diện kéo thả chỉ là một optional client – sẽ lên ngôi. Điều này cho phép doanh nghiệp giữ được tốc độ của low-code ở lớp bề mặt, nhưng vẫn nắm chắc phần xương sống code bên dưới. Cuộc chơi không còn là “low-code giết chết code”, mà là “code thuần hoá low-code để phục vụ mình”.

Sự trưng thành của một tổ chức công nghệ được đo bằng khả năng phân biệt giữa việc muốn một thứ hoạt động ngay bây giờ, và việc muốn nó tiếp tục hoạt động không lỗi trong một môi trường mà mọi tham số có thể bị đảo lộn vào ngày mai. Đó không phải là cuộc chiến giữa hai công cụ. Đó là cuộc chiến giữa sự tiện lợi ngắn hạn và khả năng sinh tồn dài hạn, và các doanh nghiệp lớn đang tỉnh giấc, chọn đứng về phía sự sống còn.