Quay lại danh sách
2026-05-22 · 38 phút đọc

Khi sản xuất phần mềm không còn là sản xuất code

Bài trước nói về số phận của lập trình viên. Bài này đi xa hơn một bước: nếu viết code chỉ là một mắt xích nhỏ trong chuỗi sản xuất phần mềm, thì cả chuỗi sẽ biến đổi thế nào khi AI nuốt dần từng mắt xích? Và cái gọi là 'công ty phần mềm' còn nghĩa lý gì?

TuanTác giả @tuan

Mở đầu

Bài trước dừng ở câu hỏi về lập trình viên. Nhưng lập trình viên chỉ là một trong nhiều vai trò tạo ra phần mềm. Trong một sản phẩm phần mềm bình thường, số người không viết code thường nhiều hơn số người viết code: quản lý sản phẩm (product manager), thiết kế (designer), kiểm thử chất lượng (QA), vận hành hạ tầng (DevOps), kỹ sư độ tin cậy (SRE), phân tích nghiệp vụ (business analyst), viết tài liệu kỹ thuật, hỗ trợ kỹ thuật, tư vấn giải pháp bán hàng, chăm sóc thành công khách hàng (customer success). Mỗi vai trò là một mắt xích trong chuỗi giá trị. Mỗi mắt xích là một giả định về phân công lao động — giả định rằng có những việc phải tách rời và giao cho con người khác nhau vì không ai làm tốt cả.

Khi AI giỏi dần ở từng mắt xích, các giả định phân công này sụp đổ — không đồng đều, không cùng tốc độ, nhưng đều sụp đổ. Và khi chuỗi tan rã, "công ty phần mềm" như một thực thể tổ chức cũng phải tái cấu trúc lại từ đầu.

Bài này đi theo bốn bước: phá vỡ giả định "sản xuất phần mềm = viết code", truy ngược lại sản xuất phần mềm thật sự là gì, xem chuỗi giá trị đó tan rã ra sao, và phác hoạ trạng thái mới có thể trông thế nào.

Giọng bài giữ như bài trước: suy luận đến tận cùng, không lạc quan rập khuôn, không bi quan rập khuôn. Và cuối bài có ghi chú "có thể sai ở đâu", như mọi suy luận đi xa khỏi dữ liệu hiện có.


Phần 1: Sản xuất phần mềm là gì, thật sự?

Câu hỏi nghe ngây thơ. Nhưng đa số người trong ngành chưa bao giờ trả lời tử tế. Khi hỏi "công ty bạn làm gì", câu trả lời thường là "chúng tôi xây phần mềm X". Đây là mô tả đầu ra, không phải mô tả quá trình.

Đi từ nguyên lý gốc (first principles), sản xuất phần mềm là chuỗi chuyển hoá thông tin, không phải chuỗi chuyển hoá vật chất. Chuỗi này có khoảng năm tầng:

flowchart TD
    U[Nhu cầu mơ hồ<br/>của người dùng] --> T1
    T1[Tầng 1 — Hiểu vấn đề<br/><i>BA, PM, founder</i>] -->|Mô tả vấn đề| T2
    T2[Tầng 2 — Thiết kế giải pháp<br/><i>UX, kiến trúc sư, tech lead</i>] -->|Kiến trúc, API, mô hình dữ liệu| T3
    T3[Tầng 3 — Hiện thực hoá<br/><i>Lập trình viên</i>] -->|Mã nguồn, bản dựng| T4
    T4[Tầng 4 — Đưa vào vận hành<br/><i>DevOps, SRE</i>] -->|Dịch vụ chạy 24/7| T5
    T5[Tầng 5 — Đóng vòng phản hồi<br/><i>Hỗ trợ, CS, sales</i>] -.->|Hành vi thật + phản hồi| T1
    T5 --> R[Giá trị tới<br/>người dùng]

Tầng 1 — Hiểu vấn đề. Khách hàng/người dùng có một nhu cầu mơ hồ. Ai đó phải biến nhu cầu mơ hồ thành mô tả vấn đề rõ ràng. Đây là việc phân tích nghiệp vụ, quản lý sản phẩm, founder, đôi khi designer làm. Đầu vào là ngôn ngữ tự nhiên, ngữ cảnh ngành, quan sát hành vi. Đầu ra là một mô tả vấn đề có thể đem giải.

Tầng 2 — Thiết kế giải pháp. Mô tả vấn đề biến thành mô tả giải pháp. Đây là việc thiết kế trải nghiệm người dùng (UX designer), kiến trúc sư phần mềm (software architect), tech lead làm. Đầu vào là vấn đề. Đầu ra là kiến trúc, luồng người dùng, mô hình dữ liệu, hợp đồng giao tiếp (API contract) — những thứ chưa phải code nhưng đã đủ cụ thể để code được.

Tầng 3 — Hiện thực hoá. Mô tả giải pháp biến thành code chạy được. Đây là việc lập trình viên làm. Bài trước nói chính về tầng này. Đầu ra là mã nguồn, bản dựng (build), thành phẩm triển khai được (deployment artefact).

Tầng 4 — Đưa vào vận hành. Code biến thành dịch vụ chạy 24/7 dưới tải thật. Đây là việc DevOps, SRE, kỹ sư hạ tầng làm. Đầu vào là thành phẩm và yêu cầu phi chức năng (độ sẵn sàng, độ trễ, chi phí). Đầu ra là hệ thống vận hành, được giám sát, có thể phục hồi.

Tầng 5 — Đóng vòng phản hồi. Người dùng dùng phần mềm, gặp vấn đề, đưa ra yêu cầu mới. Đây là việc hỗ trợ, chăm sóc thành công khách hàng, tư vấn giải pháp bán hàng, đôi khi cả sản phẩm làm. Đầu vào là hành vi thật và phản hồi. Đầu ra là input cho tầng 1 vòng sau.

Chuỗi năm tầng này tồn tại vì không một người nào đủ năng lực để làm tốt cả năm. Một người không thể vừa hiểu sâu lĩnh vực khách hàng, vừa thiết kế hệ thống phân tán, vừa code tốt, vừa vận hành ổn định, vừa giao tiếp với người dùng cuối. Phân công lao động là hệ quả của giới hạn năng lực con người.

Đây là điểm mấu chốt: chuỗi giá trị phần mềm hiện tại không phải là cấu trúc tự nhiên. Nó là kết quả của việc con người có giới hạn nhận thức. Khi giới hạn đó được giảm bởi AI — không phải một người siêu việt, mà một người bình thường được AI khuếch đại — chuỗi không còn lý do tồn tại theo hình dạng cũ.


Phần 2: Từng tầng tan rã thế nào

Đi qua từng tầng, suy luận đến tận cùng. Trước khi vào chi tiết, đây là thứ tự và mức độ tan rã dự đoán:

flowchart LR
    subgraph S1[Tan rã nhanh nhất]
        direction TB
        A[Tầng 3<br/>Hiện thực hoá]
        B[Tầng 4<br/>Vận hành]
    end
    subgraph S2[Tan rã trung hạn]
        direction TB
        C[Tầng 2<br/>Thiết kế giải pháp]
    end
    subgraph S3[Biến đổi nhưng không biến mất]
        direction TB
        D[Tầng 1<br/>Hiểu vấn đề]
        E[Tầng 5<br/>Đóng vòng phản hồi]
    end
    S1 ==> S2 ==> S3

Tầng 3 — hiện thực hoá — tan rã nhanh nhất. Bài trước đã phân tích kỹ. Đây là tầng AI làm tốt nhất hiện tại vì đầu vào (mô tả giải pháp) và đầu ra (code) đều là văn bản có cấu trúc, có lượng dữ liệu huấn luyện khổng lồ, và có vòng phản hồi nhanh (chạy/lỗi/sửa). Đây là lý do "lập trình viên" thành chủ đề nóng — nhưng cũng là lý do nó là tầng không thú vị nhất để phân tích sâu thêm.

Tầng 4 — vận hành — tan rã chậm hơn nhưng triệt để hơn. Vận hành hệ thống phân tán quy mô lớn từng là pháo đài của senior — kiến thức ngầm, kinh nghiệm sự cố, trực giác về nơi hệ thống dễ vỡ. AI hiện đã tốt ở phân tích nhật ký (log), đề xuất gỡ lỗi, thậm chí tự sửa cấu hình. Đáng nói hơn: AI có lợi thế cấu trúc ở đây mà con người không có — AI có thể đọc đồng thời triệu dòng log, tương quan tín hiệu xuyên dịch vụ, ghi nhớ mọi sự cố từng xảy ra trong tổ chức. Một SRE giỏi không cạnh tranh nổi về băng thông xử lý thông tin. Tầng này sẽ trở thành "AI vận hành, con người phê duyệt thay đổi rủi ro cao" — và sau đó, "AI vận hành, con người chỉ thấy báo cáo".

Tầng 2 — thiết kế giải pháp — đây là vùng tranh chấp thật sự. Thiết kế đòi hỏi giữ đồng thời nhiều ràng buộc, phán đoán thẩm mỹ, dự đoán hệ quả dài hạn. AI hiện tại làm được phần đề xuất phương án nhưng yếu ở phần đánh giá thoả hiệp giữa các phương án trong ngữ cảnh cụ thể. Nhưng "yếu" ở đây là tương đối — yếu hơn một kiến trúc sư senior xuất sắc, nhưng đã ngang ngửa một kiến trúc sư trung bình. Khi senior nghỉ hưu mà không có lớp kế cận (vì cơ chế đào tạo dựa trên việc làm tầng 3 đã biến mất, xem Phần 5 dưới), AI sẽ tự động chiếm chỗ này không phải vì AI giỏi lên, mà vì con người yếu đi.

Tầng 1 — hiểu vấn đề — bền nhất, nhưng không phải vì lý do người ta nghĩ. Nhiều bài viết nói "hiểu vấn đề" bền vì AI không tiếp xúc trực tiếp với khách hàng. Lý do này yếu — AI hoàn toàn có thể phỏng vấn khách hàng qua giọng nói, phân tích cuộc gọi, tổng hợp hành vi. Lý do thật sự khiến tầng này bền là trách nhiệm pháp lý và niềm tin. Khách hàng doanh nghiệp không ký hợp đồng triệu đô với AI. Họ ký với một người mà họ tin tưởng, một người chịu trách nhiệm nếu mọi thứ sai. Tầng 1 bền vì nó gắn với cơ chế xã hội (hợp đồng, trách nhiệm, danh tiếng), không phải vì AI dở. Nhưng số người cần ở tầng 1 ít hơn nhiều so với hiện tại — một người ở tầng 1 hôm nay làm việc với 5-10 kỹ sư phía sau; trong tương lai có thể làm việc với 50-100 tác tử AI (AI agent).

Tầng 5 — đóng vòng phản hồi — biến đổi triệt để nhất. Tầng này hiện tại được làm bởi hỗ trợ, chăm sóc thành công khách hàng — vai trò thường bị xem nhẹ. Trong thế giới mới, đây là tầng AI làm tốt hơn con người ở mọi mặt: trả lời tức thì, không cảm xúc, nhớ mọi tương tác trước đó, đa ngôn ngữ. Nhưng đồng thời, đây là tầng tạo ra dữ liệu huấn luyện quý nhất cho mọi tầng còn lại.

Ở đây cần tách rõ hai loại dữ liệu — vì chúng có giá trị rất khác nhau và quyết định ai thật sự có lợi thế. Dữ liệu hành vi (click, session, thời gian dừng trang) decay nhanh, dễ thu thập, các nền tảng siêu quy mô sẽ biến nó thành hàng hoá phổ thông trong vài năm tới — không phải pháo đài. Dữ liệu nghiệp vụ chuyên ngành (luồng phê duyệt tín dụng của một ngân hàng cụ thể, dòng chuyền sản xuất của một nhà máy cụ thể, quy trình xử lý đơn của một sàn cụ thể) là loại khác — bền lâu, không AI nào tự sinh ra được vì nó chỉ tồn tại trong vận hành thực. Công ty kiểm soát loại dữ liệu thứ hai có lợi thế cấu trúc dài hạn; công ty chỉ có loại thứ nhất sẽ bị nuốt bởi các nền tảng lớn hơn.

Tổng hợp lại: chuỗi năm tầng không tan rã đều. Tầng 3 và 4 tan rã trước, tầng 2 tan rã sau đó, tầng 1 và 5 biến đổi nhưng không biến mất. Hậu quả là trọng tâm giá trị dịch chuyển khỏi hiện thực hoá về phía hiểu vấn đề và đóng vòng phản hồi. Đây là điểm mà nhiều người trong ngành đang đoán đúng nhưng nói chưa đủ — chưa nói đến hệ quả tổ chức của nó.


Phần 3: Tầng bị thiếu — ai setup và vận hành đống AI này?

Phần trên nói "AI làm tầng 3", "AI vận hành tầng 4" như thể AI tự xuất hiện, tự cấu hình, tự chạy. Thực ra không. Có một tầng mới xuất hiện mà mô hình năm tầng cũ bỏ sót — tạm gọi là tầng 0, hay tầng hạ tầng AI.

Tầng 0 là những người làm công việc sau:

  • Chọn mô hình nào cho việc nào, fine-tune ra sao
  • Viết prompt, vòng lặp tác tử (agent loop), bộ điều phối (orchestration)
  • Cài đặt MCP (Model Context Protocol), tích hợp công cụ, kết nối AI với codebase và hạ tầng nội bộ
  • Giám sát chất lượng đầu ra, can thiệp khi AI lệch
  • Xây hệ thống đánh giá (evaluation), kiểm tra hồi quy (regression test)
  • Quản lý chi phí suy luận (inference), chọn mô hình nào cho việc nào
  • Viết rào chắn (guardrail), đảm bảo AI không phá hệ thống vận hành
  • Cập nhật khi có mô hình mới (mỗi 3-6 tháng)

Đây không phải nghề mới hoàn toàn. Nó là hợp nhất của vài nghề cũ: DevOps + kỹ sư học máy (ML engineer) + kỹ sư nền tảng (platform engineer) + một chút tư duy sản phẩm. Người làm được phải hiểu cả hạ tầng (để vận hành), cả mô hình (để chọn và đánh giá), cả vấn đề kinh doanh (để biết AI phải làm gì). Đây là vai trò "chữ T rất sâu, rất rộng" — hiếm và đắt.

Tầng 0 ngồi ngang tất cả tầng còn lại, không ở trong chuỗi:

flowchart TD
    T0[Tầng 0 — Hạ tầng AI<br/><i>AI platform engineer / AI orchestrator</i>]
    T0 -.cung cấp AI cho.-> T2
    T0 -.cung cấp AI cho.-> T3
    T0 -.cung cấp AI cho.-> T4
    T0 -.cung cấp AI cho.-> T5

    T1[Tầng 1<br/>Hiểu vấn đề] --> T2[Tầng 2<br/>Thiết kế]
    T2 --> T3[Tầng 3<br/>Hiện thực hoá]
    T3 --> T4[Tầng 4<br/>Vận hành]
    T4 --> T5[Tầng 5<br/>Phản hồi]
    T5 -.-> T1

Một chú thích quan trọng: "tầng 0" không phải một nghề duy nhất. Thực tế đang phân hoá thành ba hướng chuyên môn rõ rệt — chọn và đánh giá mô hình (model & eval ops), tích hợp và công cụ (integration & MCP), kiểm soát chi phí và rào chắn (cost & guardrails). Một người có thể giỏi cả ba lúc khởi đầu; ở quy mô lớn, ba hướng tách thành ba nhóm nhỏ làm việc cùng nhau.

Có năm điều đáng nói về tầng này, suy luận đến tận cùng:

Một, đây là vai trò có đòn bẩy cao nhất trong tổ chức mới. Một người setup tốt hệ thống AI có thể nhân năng suất của 50 người khác. Một người setup tệ có thể làm cả tổ chức chậm hơn so với không dùng AI — vì AI sai ngầm, tốn tiền suy luận, và tạo nợ kỹ thuật (technical debt) nhanh hơn con người gỡ ra. Khoảng cách giữa "tốt" và "tệ" ở vai trò này lớn hơn bất kỳ vai trò kỹ thuật nào hiện tại.

Hai, đây có thể là pháo đài bền nhất cho con người ở tầng kỹ thuật — bền hơn cả "hệ thống quan trọng" mà phần dưới sẽ nói. Vì AI không thể tự setup AI một cách đáng tin cậy ở mức tổ chức — đó là bài toán có quá nhiều ngữ cảnh ngầm (nguồn dữ liệu nội bộ, ràng buộc tuân thủ, văn hoá đội ngũ, lịch sử hệ thống) mà không trích xuất được thành mô tả chính thức để AI đọc. Ít nhất trong 10-15 năm tới.

Ba, vai trò này tạo bất cân xứng quyền lực mới trong tổ chức. Người setup AI biết rõ AI làm được gì và không làm được gì — biết rõ hơn cả CTO hay CEO, vì họ là người duy nhất chạm vào cấu hình thật. Điều này có hai mặt. Mặt tích cực: họ là người tin cậy nhất để tư vấn chiến lược AI. Mặt tiêu cực: họ có thể "biểu diễn" năng suất bằng cách giấu chi phí, hoặc "biểu diễn" giới hạn để giữ vị thế. Tổ chức truyền thống chưa có cơ chế xử lý động lực chính trị mới này — vì chưa từng có ai giữ chìa khoá của một nguồn lực có đòn bẩy mạnh đến vậy.

Bốn, vai trò này tự nó cũng đang được AI nuốt dần. Có những startup đang xây "tác tử AI để setup tác tử AI" — vòng đệ quy đáng nghi ngờ nhưng không vô lý. Nếu thành công, đây là điểm tới hạn ở quy mô nhỏ: AI tự tổ chức việc làm phần mềm. Lúc đó, vai trò "người setup AI" co lại còn vài chục người trên toàn thế giới, làm ở các phòng lab nền tảng. Đây là cách tầng 0 có thể tự tan rã — nhưng chậm hơn các tầng khác, có lẽ từ 10 năm trở lên.

Năm, tầng 0 là nơi đối thủ mới của công ty bạn hình thành trước khi bạn nhận ra. Nếu khách hàng bạn thuê được một người tầng 0 giỏi, họ có thể tự xây được phần mềm thay bạn. Cơ chế của Dịch chuyển 3 ("công ty trong ngành X tự xây") trong phần sau chính là bởi vì tầng 0 đã tồn tại. Không có tầng 0, câu chuyện "tự xây" vẫn chỉ là lý thuyết.


Phần 4: Hệ quả tổ chức — công ty phần mềm biến đổi ra sao

Khi chuỗi giá trị thay đổi, hình dạng công ty phải thay đổi theo. Bốn dịch chuyển có khả năng cao nhất:

Dịch chuyển 1 — Quy mô tối ưu giảm mạnh. Công ty phần mềm hiện tại có 50, 500, 5000 kỹ sư vì phân công lao động ở tầng 3 đòi hỏi nhiều người. Khi tầng 3 cần một-phần-mười số người, công ty 500 kỹ sư hoặc co lại còn 50, hoặc làm gấp mười sản phẩm. Phần lớn sẽ làm gấp mười sản phẩm — vì đó là cách tự nhiên hơn về mặt tổ chức (không phải sa thải, mà mở rộng phạm vi). Hậu quả: công ty trung bình làm nhiều việc hơn, ranh giới sản phẩm mờ đi, "công ty làm một thứ" trở thành hiếm.

Dịch chuyển 2 — Lợi thế quy mô về phần mềm thuần biến mất, lợi thế phân phối nổi lên. Lợi thế của công ty lớn so với startup hiện nay phần lớn dựa trên: nhiều kỹ sư hơn, hạ tầng tốt hơn, công cụ nội bộ tinh vi hơn. AI làm phẳng cả ba điều này. Một startup 5 người với AI có thể tạo ra sản phẩm có chất lượng kỹ thuật ngang công ty 500 người. Lợi thế của công ty lớn dịch chuyển sang ba thứ khác: kênh phân phối, dữ liệu, quan hệ. Trong ba thứ này, kênh phân phối là pháo đài bền nhất — vì nó là trận địa con người, không phải kỹ thuật. AI không làm phẳng được quan hệ với purchasing director của một tập đoàn, không thay được mạng lưới đối tác tích hợp được xây mười năm, không tạo ra được niềm tin của khách hàng đã mua bốn lần trước. Đây là lý do các "ông lớn" hiện tại không sụp đổ ngay dù bị ăn từ dưới lên về mặt kỹ thuật. Và đây cũng là lý do startup giỏi kỹ thuật mà không có kênh thường thất bại — họ thắng ở tầng dễ làm phẳng nhất.

Dịch chuyển 3 — Ranh giới giữa "công ty phần mềm" và "công ty trong ngành X" tan dần. Khi tạo phần mềm rẻ hơn 10-100 lần, mọi công ty trong mọi ngành đều có thể tự xây phần mềm — với điều kiện họ thuê được vài người tầng 0 giỏi. Nhưng "tự xây" cũng có giới hạn: những hệ thống có ràng buộc pháp lý mạnh, switching cost cực cao, hoặc vendor lock-in lâu năm vẫn ít có khả năng tự xây thay thế. Ngân hàng sẽ không tự xây core banking (Temenos, Finastra giữ vị trí này, NHNN không khuyến khích thay đổi), nhưng họ sẽ tự xây pipeline KYC/onboarding, fraud detection, ops tooling, hệ thống phân tích nội bộ — những thứ trước đây mua của các vendor tích hợp lớn. Công ty sản xuất sẽ không tự xây ERP cốt lõi nhưng sẽ tự xây MES tuỳ chỉnh, hệ thống chất lượng, dashboard vận hành. "Nhà cung cấp phần mềm" như một loại hình kinh doanh độc lập thu hẹp lại — chỉ còn ở các lĩnh vực có yêu cầu rất chuyên hoặc rào cản pháp lý cao. Ở giữa — cái mà ta gọi là "SaaS doanh nghiệp" — bị ép từ hai phía: ép từ trên (các nền tảng siêu quy mô nuốt dần các lớp nền tảng) và ép từ dưới (khách hàng tự xây cái họ cần). Đây là xu hướng đã bắt đầu, AI chỉ tăng tốc.

Dịch chuyển 4 — Mô hình kinh doanh "bán quyền sử dụng phần mềm" suy yếu, mô hình "bán kết quả" lên ngôi. Khi phần mềm tự nó trở thành hàng hoá phổ thông (commodity), khách hàng không trả tiền cho phần mềm — họ trả tiền cho kết quả mà phần mềm mang lại. Đây là chuyển dịch từ "bán công cụ" sang "bán dịch vụ có công cụ phía sau". Salesforce bán quyền sử dụng; thế hệ tiếp theo bán "kết quả bán hàng được tăng X%". Đo lường khó hơn, nhưng giá trị thu được trên mỗi khách hàng cao hơn — và quan trọng nhất, biến phần mềm thành thứ không thể thuần thay thế bằng một AI tự xây. Đây có thể là pháo đài cuối của các công ty phần mềm hiện tại.

Bốn dịch chuyển này không xảy ra cùng tốc độ. Dịch chuyển 1 và 2 đang diễn ra, có thể quan sát được trong các đợt sa thải và cắt giảm gần đây. Dịch chuyển 3 đang ở giai đoạn đầu — đa số công ty truyền thống vẫn mua phần mềm từ nhà cung cấp, nhưng tỷ lệ "tự xây" đang tăng. Dịch chuyển 4 mới đang nhen nhóm trong các tác tử AI theo lĩnh vực dọc — và sẽ tăng tốc khi mô hình bán quyền sử dụng trở nên khó bảo vệ.


Phần 5: Hai vòng lặp ác trong hệ thống

Có hai vòng lặp ác (vicious loop) trong quá trình này, đáng được gọi tên rõ. Đây là sơ đồ chuyển động của chúng — chú ý cách hai vòng nuôi lẫn nhau ở chính giữa:

flowchart TB
    subgraph L1[Vòng lặp 1 — Mất cơ chế đào tạo]
        direction LR
        A1[AI viết code<br/>thay junior] --> A2[Tầng 3 ít<br/>vị trí junior]
        A2 --> A3[Không có lớp<br/>kế cận tầng 2]
        A3 --> A4[Senior cũ<br/>nghỉ hưu]
        A4 --> A5[Phán đoán kiến trúc<br/>chuyển cho AI]
        A5 --> A1
    end

    subgraph L2[Vòng lặp 2 — Mất đa dạng phán đoán]
        direction LR
        B1[Thế hệ mới<br/>học từ AI] --> B2[Phán đoán hội tụ<br/>về thẩm mỹ AI]
        B2 --> B3[Không ai dám<br/>cãi AI]
        B3 --> B4[Mất động lực<br/>rèn năng lực độc lập]
        B4 --> B1
    end

    A5 -.củng cố.-> B1
    B3 -.củng cố.-> A1

Vòng lặp 1 — Mất cơ chế đào tạo lớp kế cận. Senior ở tầng 2 hôm nay được tạo ra từ junior ở tầng 3 hôm qua. Một kiến trúc sư xuất sắc không sinh ra như kiến trúc sư — họ là kỹ sư đã viết code mười năm, đã gặp đủ loại sai lầm, đã hiểu vì sao một quyết định kiến trúc dẫn đến đau khổ ba năm sau. Khi tầng 3 không còn vị trí cho junior, không có cách nào tạo ra senior tầng 2. Trong 5-10 năm, lớp senior hiện tại nghỉ hưu mà không có lớp thay thế. Tầng 2 không tan rã vì AI giỏi hơn — nó tan rã vì con người mất khả năng giỏi ở đó.

Đây là kiểu sụp đổ chậm và không thể đảo ngược trong khoảng thời gian thực tế. Ngành y, ngành luật, ngành kỹ thuật xây dựng đã quan sát phiên bản nhẹ của vấn đề này. Trong ngành phần mềm, vì tốc độ thay đổi nhanh hơn, vòng lặp ác này sẽ diễn ra rõ rệt hơn.

Vòng lặp 2 — Mất đa dạng phán đoán (luận điểm yếu hơn vòng lặp 1, cần đọc kèm phản chứng). Mỗi thế hệ kỹ sư hôm nay học từ nhiều nguồn khác nhau: trường lớp, sách, người dẫn dắt (mentor), dự án thực tế. Đa dạng nguồn tạo ra đa dạng phán đoán — đa dạng phán đoán là vốn quan trọng cho ngành sáng tạo. Thế hệ tiếp theo học chủ yếu từ AI.

Ở đây có một phản chứng đáng nhắc: ngắn hạn, các phòng lab nền tảng (Anthropic, OpenAI, xAI, Mistral, Google) đang phân hoá thẩm mỹ chứ không hội tụ — Claude code style khác hẳn ChatGPT, khác hẳn Cursor, khác hẳn Copilot. Người dùng nhiều mô hình có thể vẫn duy trì đa dạng phán đoán. Luận điểm "hội tụ" chỉ thành lập khi: (a) thị trường mô hình co lại còn 2-3 người chơi, (b) các mô hình copy lẫn nhau qua synthetic data, hoặc (c) một thế hệ kỹ sư lớn lên chỉ dùng một mô hình duy nhất từ đầu. Cả ba điều kiện này khả thi nhưng chưa chắc — và nếu không xảy ra, vòng lặp 2 chỉ là cảnh báo lý thuyết chứ không phải dự đoán.

Giả sử ba điều kiện đó thành lập: phán đoán của thế hệ tiếp theo sẽ hội tụ về một thẩm mỹ chung — thẩm mỹ của AI. Hệ quả: tổ chức tương lai sẽ có vẻ đa dạng (nhiều người, nhiều quốc gia, nhiều xuất thân) nhưng tư duy thì đồng nhất. Đa dạng bề mặt, đơn điệu chiều sâu. Đây là loại đồng nhất nguy hiểm vì nó vô hình — không ai cảm thấy thiếu, không ai biết có gì để thiếu.

Hai vòng lặp này tương tác với nhau. Mất cơ chế đào tạo dẫn đến phụ thuộc AI nhiều hơn, dẫn đến mất đa dạng phán đoán (nếu giả định trên đúng), dẫn đến không có ai dám nghi ngờ AI, dẫn đến không có động lực rèn năng lực độc lập. Vòng lặp tự củng cố — với điều kiện vòng lặp 2 thật sự xảy ra.


Phần 6: Trạng thái mới có thể trông thế nào

Suy luận đến tận cùng, trạng thái cân bằng mới (nếu có) có thể có các đặc điểm sau:

Đặc điểm 1 — Ba loại công ty phần mềm tách biệt rõ, không chỉ hai. Mô tả phổ biến hiện nay nói có hai cực: xưởng nhỏ và nền tảng siêu quy mô. Đúng nhưng chưa đủ. Có một loại thứ ba đang định hình.

Loại một — xưởng nhỏ (5-50 người): mỗi người có phạm vi rất rộng nhờ AI khuếch đại. Đây là dạng "studio" — gần với cách công ty quảng cáo hoặc kiến trúc hoạt động hơn là dạng công ty phần mềm hiện tại.

Loại hai — nền tảng siêu quy mô (vài tỷ đô doanh thu trở lên): sở hữu hạ tầng AI nền tảng, mô hình, GPU, kênh phân phối toàn cầu.

Loại ba — vertical integrator (đường thứ ba): công ty kết hợp phần cứng + phần mềm + dịch vụ trong một ngành cụ thể. Khác xưởng vì có vốn vật chất (nhà máy, thiết bị, kho bãi, mạng lưới triển khai). Khác nền tảng siêu quy mô vì hẹp về ngành, sâu về domain. Ví dụ: công ty làm kiosk bán lẻ tự sản xuất phần cứng + viết phần mềm + triển khai dịch vụ tại điểm; công ty smart manufacturing tích hợp PLC + MES + AI ops trong nhà máy của một ngành nhất định. Loại này có rào cản kép — kỹ thuật và vốn vật chất — nên không bị startup AI thuần phần mềm tấn công, nhưng cũng không bị nền tảng siêu quy mô nuốt vì nền tảng không xuống tầng vật chất.

Lớp giữa — công ty phần mềm 100-5000 người không có cả vốn vật chất lẫn quy mô siêu lớn — bị bóp lại. Tổ chức ở giữa hoặc co lại thành xưởng, hoặc bị sáp nhập vào nền tảng siêu quy mô, hoặc tiến hoá thành vertical integrator (nếu có thể đi xuống tầng vật chất), hoặc chuyển nghề (sang loại công ty "ngành + tech" — xem đặc điểm 2).

Đặc điểm 2 — Công ty không phải phần mềm hấp thụ phần lớn người làm phần mềm hiện tại. Đây là điểm dễ bỏ sót. Khi việc tạo phần mềm rẻ đi, các công ty trong ngành khác (sản xuất, bán lẻ, y tế, tài chính, hậu cần) sẽ thuê nhiều người làm phần mềm hơn — nhưng dưới một danh nghĩa khác. Họ không gọi mình là "kỹ sư phần mềm" mà là "kỹ sư vận hành sản xuất", "chuyên gia tự động hoá tài chính", "kỹ sư hệ thống chăm sóc bệnh nhân". Tay nghề phần mềm trở thành kỹ năng nền, không phải bản dạng nghề nghiệp. Tương tự cách "biết Excel" hôm nay là kỹ năng nền chứ không phải nghề.

Đặc điểm 3 — Phần mềm trở thành cơ sở hạ tầng vô hình. Hôm nay người dùng cuối biết họ đang dùng "phần mềm" — họ mở Microsoft Word, họ vào Salesforce, họ tải ứng dụng. Trong trạng thái mới, phần mềm là lớp vô hình giữa người dùng và kết quả họ muốn. Họ nói với AI "tôi muốn báo cáo doanh thu quý này theo vùng" — AI tạo ra phần mềm vừa-đủ để trả lời, dùng một lần, rồi vứt đi. Khái niệm "ứng dụng" như một thành phẩm bền vững có thể không còn cần thiết. Đây là viễn cảnh xa hơn 5-10 năm — nhưng nếu nó đúng, toàn bộ mô hình kinh doanh phần mềm hiện tại (sản phẩm, quyền sử dụng, đăng ký) đều bị phá vỡ.

Đặc điểm 4 — Hai pháo đài cuối cho con người ở tầng kỹ thuật: tầng 0 và lớp hệ thống quan trọng. Tầng 0 (hạ tầng AI) bền vì AI chưa tự setup AI được ở mức tổ chức — đây là vai trò có đòn bẩy cao, số vị trí nhiều hơn lớp hệ thống quan trọng, và đang tăng nhu cầu nhanh. Lớp hệ thống quan trọng (phần mềm điều khiển nhà máy hạt nhân, máy bay, thiết bị y tế cấy ghép, hạ tầng điện) bền vì trách nhiệm pháp lý và hậu quả vật lý cao đến mức không xã hội nào chấp nhận AI làm chủ — nhưng số vị trí rất nhỏ và ngưỡng vào rất cao. Tầng 0 là con đường khả thi cho nhiều người; lớp hệ thống quan trọng chỉ cho một số ít. Nhưng cả hai đều có khả năng tự tan rã dài hạn — tầng 0 bởi AI tự setup AI, lớp hệ thống quan trọng bởi thay đổi luật và chấp nhận xã hội.

Đây là kịch bản trung tâm. Có nhiều kịch bản khác. Quan trọng là không lẫn lộn "trạng thái trung gian hiện tại" với "trạng thái cân bằng dài hạn". Đa số người trong ngành hôm nay đang lập kế hoạch sự nghiệp dựa trên trạng thái trung gian — như thể nó bền vững. Nó không bền vững.


Phần 7: Hệ quả với người ra quyết định

Bài trước viết cho junior và senior cá nhân. Bài này viết cho người ra quyết định — founder, CTO, trưởng bộ phận kỹ thuật, người quản lý đơn vị kinh doanh.

Đối với founder/CEO công ty phần mềm hiện tại: Câu hỏi quan trọng nhất không phải "làm sao dùng AI để tăng năng suất" — đa số đối thủ cũng đang làm điều đó, không tạo lợi thế bền vững. Câu hỏi quan trọng hơn: mô hình kinh doanh của bạn còn ý nghĩa gì khi tạo phần mềm rẻ 10 lần? Nếu câu trả lời là "vẫn vậy, chỉ là biên lợi nhuận cao hơn", có lẽ bạn chưa nghĩ đủ sâu. Đối thủ mới có thể không phải công ty khác trong ngành bạn — mà là công ty trong ngành của khách hàng bạn, tự xây cái họ từng mua của bạn.

Đối với CTO/trưởng bộ phận kỹ thuật: Đầu tư vào cái gì còn giá trị 5-10 năm nữa? Không phải khung phần mềm (framework), không phải công cụ. Đáng đầu tư nhất là: hệ thống tri thức nội bộ (kiến thức ngầm được viết ra), kho dữ liệu nghiệp vụ chuyên ngành (không phải dữ liệu hành vi — xem Phần 2), khả năng tích hợp với hệ thống ngành cụ thể (rào cản lĩnh vực), và quan trọng nhất — năng lực tầng 0 nội bộ. Không thuê ngoài tầng 0; không giao cho vendor. Đây là tài sản không bị AI làm phẳng. Quy mô đội ngũ — đặc biệt ở tầng 3 — sẽ phải giảm. Đối mặt thật với điều này càng sớm càng tốt, vì lựa chọn của bạn không phải "có giảm hay không" mà là "giảm chủ động và tái đầu tư, hay bị thị trường ép giảm bị động".

Đối với người quản lý đơn vị kinh doanh trong công ty không-phải-phần-mềm: Câu hỏi của bạn là ngược lại. Bạn đang mua phần mềm gì mà thực ra có thể tự làm với 3-5 người nội bộ + AI? Đây không phải câu hỏi "làm thế nào để tiết kiệm chi phí" — mà là câu hỏi chiến lược về việc kiểm soát những gì cốt lõi với hoạt động kinh doanh của bạn. Phần mềm là nơi mô hình kinh doanh của bạn được mã hoá. Để người khác viết nó là để người khác hiểu công ty bạn rõ hơn chính bạn. Câu hỏi đi kèm: bạn có người tầng 0 chưa, nếu chưa thì bỏ bao nhiêu tiền cũng không "tự xây" được. Và biết phân biệt cái gì nên tự xây (KYC, ops tooling, dashboard nội bộ) với cái gì không nên đụng (core banking, ERP cốt lõi, hệ thống có vendor lock-in pháp lý).

Ba góc nhìn này không tương thích lẫn nhau. Founder phần mềm thấy mối đe doạ là khách hàng tự xây. Khách hàng thấy cơ hội là kiểm soát ngược lại lớp công nghệ. Đây là cuộc chiến phân phối lại giá trị trong chuỗi giá trị — và mỗi bên đều có lập luận hợp lý từ vị trí của mình. Người nào nhận ra điều này sớm và hành động sớm sẽ có lợi thế.


Phần 8: Riêng với Việt Nam

Mọi phần trên viết chung cho ngành phần mềm toàn cầu. Nhưng Việt Nam ở một vị thế đặc biệt trong câu chuyện này — đáng dành riêng vài đoạn vì những gì bài này dự đoán sẽ va vào VN sớm và mạnh hơn nhiều thị trường khác.

Ngành gia công CNTT là nhóm tan rã đầu tiên ở quy mô lớn. FPT Software, NashTech, KMS, TMA, Bagel và hàng trăm công ty gia công nhỏ hơn — phần lớn doanh thu đến từ tầng 3 thuần (viết code theo đặc tả của khách nước ngoài), với một phần tầng 4 (DevOps, vận hành cho khách). Đây chính xác là hai tầng tan rã nhanh nhất theo phân tích Phần 2. Lợi thế cạnh tranh hiện tại — chi phí kỹ sư thấp hơn 1/3 đến 1/5 so với Mỹ/châu Âu — sẽ biến mất khi AI làm tầng 3 với chi phí gần bằng không và 24/7. Không phải vì kỹ sư Việt yếu, mà vì cả ngành gia công đang đứng trên tầng dễ tan rã nhất của chuỗi.

Đây không phải dự đoán xa — các công ty gia công lớn ở Ấn Độ (TCS, Infosys, Wipro) đã sa thải hàng chục nghìn người trong 18 tháng qua, và Ấn Độ thường đi trước Việt Nam 3-5 năm trong xu hướng này. Câu hỏi không phải "có xảy ra ở VN không" mà là "khi nào, và ai chuẩn bị từ bây giờ".

Hai con đường thoát cho ngành gia công VN. Một, đi lên chuỗi giá trị — chuyển từ "viết code theo đặc tả" sang "thiết kế giải pháp" (tầng 2) hoặc "hiểu vấn đề khách hàng" (tầng 1). Đây là con đường khó: đòi hỏi đầu tư đào tạo nhiều năm, văn hoá tổ chức khác hẳn, và phải vượt rào cản ngôn ngữ/văn hoá để làm việc sâu với khách. Hai, đi xuống tầng vật chất — trở thành vertical integrator (Đặc điểm 1 ở Phần 6) trong các ngành mà VN có vốn vật chất sẵn: sản xuất, logistics, bán lẻ, nông nghiệp. Con đường này khả thi hơn vì khai thác được nền sản xuất nội địa, nhưng đòi hỏi chuyển mô hình kinh doanh triệt để, không phải nâng cấp tăng dần.

Công ty không chọn được con đường nào sẽ co lại — không phải sụp đổ ngay, nhưng từng bước mất khách, mất biên lợi nhuận, mất nhân tài giỏi, đến khi còn lại một vỏ.

Tầng 0 ở VN còn nguyên cơ hội. Đây là tin tốt. Tầng 0 (hạ tầng AI) hiện tại ở VN có rất ít người làm thật sự — vài chục đến vài trăm người trên cả nước có năng lực tự setup hệ thống AI cho tổ chức quy mô lớn. Trong khi nhu cầu đang tăng theo cấp số nhân: các ngân hàng (Techcombank, MBBank, TPBank, VPBank đều đang xây đội AI nội bộ), các tập đoàn (Masan, Vingroup, FPT, Viettel), các startup. Người làm được tầng 0 ở VN trong 3-5 năm tới sẽ ở vị trí thương lượng cực mạnh — đòn bẩy cao như đã nói ở Phần 3, cộng với độ khan hiếm của thị trường VN.

Khuyến nghị cụ thể cho cá nhân: nếu bạn là kỹ sư trẻ ở VN, đầu tư vào tầng 0 có khả năng cao là quyết định nghề nghiệp tốt nhất trong 5 năm tới — hơn cả việc cố giỏi hơn AI ở tầng 3. Nếu bạn là CTO hoặc head of engineering, xây nhóm tầng 0 nội bộ là việc cấp bách nhất trong roadmap năm 2026, không phải năm 2027.

Vai trò đặc biệt của các tập đoàn đa ngành VN. Masan, Vingroup, Hoà Phát, THACO, Viettel — các tập đoàn vừa có vốn vật chất (nhà máy, bán lẻ, viễn thông) vừa có nguồn lực tài chính lớn vừa kiểm soát dữ liệu nghiệp vụ chuyên ngành (loại dữ liệu bền — xem Phần 2). Đây chính là cấu hình thuận lợi nhất để trở thành vertical integrator (Đặc điểm 1, loại ba). Trong khi các công ty phần mềm thuần ở VN (kể cả lớn như FPT) đang ở vị thế khó, các tập đoàn truyền thống — vốn không tự nhận là "công ty công nghệ" — lại đang ở vị thế thuận lợi nhất. Bài học chiến lược: trong làn sóng AI, công ty có vốn vật chất + dữ liệu nghiệp vụ + người tầng 0 sẽ thắng công ty có nhiều kỹ sư phần mềm thuần.

Một cảnh báo cuối. VN có truyền thống đào tạo kỹ sư phần mềm qua các trường đại học kỹ thuật — Bách Khoa, ĐHQG, FPT University. Hiện tại, đa số chương trình vẫn đào tạo để làm tầng 3. Trong 5 năm tới, các sinh viên ra trường với kỹ năng tầng 3 thuần sẽ vào thị trường mà tầng 3 đã không còn cần nhiều người. Đây là vấn đề hệ thống không cá nhân nào tự giải quyết được — nhưng nó là rủi ro thật cho cả một thế hệ kỹ sư trẻ đang học bây giờ.


Kết: Bốn câu hỏi khác

Tiếp tục cấu trúc của bài trước — bốn câu hỏi không cần trả lời ai cả, chỉ cần trả lời cho chính mình:

Một, công ty bạn đang ở mắt xích nào trong chuỗi giá trị phần mềm, và mắt xích đó có còn không? Đây là câu hỏi về vị trí cấu trúc, không phải câu hỏi về chiến thuật. Một công ty làm gia công CNTT (IT outsourcing) thuần tầng 3 có vị trí khác hẳn một công ty làm sản phẩm theo lĩnh vực dọc sâu trong một ngành. Câu trả lời không có giá trị nếu nó né tránh sự thật.

Hai, nếu phần mềm trở thành hàng hoá phổ thông, bạn bán cái gì? Không phải câu trả lời mặc định ("dịch vụ", "kinh nghiệm"). Câu trả lời cụ thể: bạn bán cái gì mà AI + 5 kỹ sư khác không bán được? Nếu câu trả lời mơ hồ, có lẽ bạn chưa có gì cụ thể — và đó là cảnh báo, không phải lý do để bào chữa.

Ba, ai trong tổ chức của bạn đang làm tầng 0, và bạn có biết họ đang làm gì không? Đây là câu hỏi nhiều tổ chức không trả lời được. Có người đang setup AI cho công ty bạn — có thể chính thức, có thể tự phát. Nếu bạn là founder/CTO mà không biết người đó là ai, không biết họ đang chọn mô hình nào, không biết chi phí suy luận mỗi tháng, không biết AI đang được cấp quyền truy cập vào những hệ thống nào — thì thực ra người đó đang điều hành công ty bạn nhiều hơn bạn nghĩ. Tầng 0 vô hình là rủi ro quản trị mới chưa có tên.

Bốn, bạn đang xây tổ chức cho trạng thái nào — hôm nay, ba năm nữa, hay mười năm nữa? Đa số tổ chức được thiết kế cho trạng thái hôm nay, với một chút thích nghi cho ba năm. Mười năm nữa hầu như không ai nghĩ đến. Nhưng quyết định bạn ra hôm nay — về cấu trúc đội ngũ, về văn hoá, về đầu tư công nghệ — sẽ định hình tổ chức đó trông thế nào mười năm nữa. Không có lựa chọn không quyết định; không hành động cũng là một loại quyết định.


Ghi chú: Bài này có thể sai ở đâu

Cũng như bài trước, có những chỗ đáng nghi ngờ:

Một, suy luận về chuỗi giá trị có thể quá gọn. Mô hình năm tầng (cộng tầng 0) là một lát cắt — thực tế phức tạp hơn, với nhiều vòng phản hồi xuyên tầng. Tốc độ tan rã của từng tầng phụ thuộc vào nhiều yếu tố không phải kỹ thuật (luật, văn hoá ngành, vòng đời sản phẩm) mà bài này chưa nói đủ. Có thể tầng 2 bền hơn tôi nghĩ, hoặc tầng 4 tan rã nhanh hơn tôi nghĩ. Có thể tầng 0 bị AI nuốt nhanh hơn tôi dự đoán nếu các hệ "tác tử setup tác tử" tiến xa hơn dự kiến.

Hai, "công ty không phải phần mềm tự xây" có thể bị phóng đại. Lịch sử cho thấy đa số công ty truyền thống thử tự xây phần mềm đều thất bại — vì văn hoá tổ chức, vì cơ chế ra quyết định, vì thiếu tài năng (đặc biệt là tài năng tầng 0). AI có thể giảm rào cản kỹ thuật, nhưng không tự động giải quyết rào cản tổ chức. Có thể "nhà cung cấp phần mềm" bền hơn dự đoán vì khách hàng vẫn không muốn tự làm, dù về mặt kỹ thuật họ có thể.

Ba, câu hỏi về cầu chưa được trả lời. Bài này giả định tổng thị trường phần mềm giữ nguyên, chỉ tái phân phối giá trị giữa các bên. Nhưng có hai khả năng đối lập, đều hợp lý. Một (Jevons paradox): khi phần mềm rẻ 10 lần, nhu cầu có thể tăng 100 lần — vì những bài toán trước đây không đáng giải bằng phần mềm giờ đáng giải, và tổng thị trường nở ra. Hai (commoditization triệt để): khi phần mềm trở thành hàng hoá phổ thông, giá trị bị nuốt về phía hạ tầng AI và khách hàng cuối, lớp giữa teo lại. Câu trả lời quyết định toàn bộ chiến lược của founder — và bài này không cố trả lời, chỉ đặt ra để bạn suy nghĩ.

Bốn, có thể có một dạng giá trị mới chưa lường được. Mọi suy luận trên đều giả định khuôn khổ tư duy "chuỗi giá trị" còn nguyên hình. Lịch sử công nghệ cho thấy chuyển dịch lớn thường kèm theo dạng giá trị mới mà người đương thời không thấy được — internet không chỉ là "bưu điện nhanh hơn", điện thoại thông minh không chỉ là "điện thoại có web". Có thể AI tạo ra một loại giá trị mà cả người viết bài và người đọc bài đều chưa hình dung ra. Nếu vậy, toàn bộ phân tích này lỗi thời từ khi viết.

Đọc bài này như một kịch bản đáng nghĩ tới, không phải dự báo chắc chắn — giống như bài trước.