AI viết code, kỹ sư làm gì trong nhà máy phần mềm (software factory)?

Khi Trí tuệ nhân tạo (AI) tự động hóa việc viết mã nguồn, phán đoán của con người không hề mất đi mà dịch chuyển từ việc gõ dòng lệnh sang thiết kế bộ khung kiểm chuẩn (harness), xác định ý đồ hệ thống và chịu trách nhiệm nghiệm thu.

Trong nhà máy phần mềm, AI sản xuất các sản phẩm trung gian như mã nguồn hay bài test. Kỹ sư chịu trách nhiệm thiết lập thanh chất lượng, bảo tồn mô hình tư duy kiến trúc và quyết định thời điểm mã nguồn đủ an toàn để đưa lên môi trường thực tế.

Sự dịch chuyển này đòi hỏi bạn phải nâng cao gu kỹ thuật và kỷ luật thẩm định, thay vì phó mặc hệ thống cho các mô hình ngôn ngữ tự vận hành mà thiếu sự kiểm soát.

Phán đoán của con người dịch chuyển lên thượng nguồn trong nhà máy phần mềm

Nhà máy phần mềm là gì và khi nào bạn thực sự cần đến nó?

Nhà máy phần mềm (software factory) là một vòng lặp tự động hóa khép kín, lặp lại liên tục quanh các công việc phát triển hệ thống. Hệ thống này vận hành theo cơ chế kích hoạt bằng sự kiện (event-driven) trong các môi trường đám mây cô lập, xử lý các tác vụ từ khi tiếp nhận issue cho đến khi sẵn sàng tạo Pull Request mà không bắt quy trình phải dừng lại chờ thao tác thủ công.

Quy trình nhà máy phần mềm đám mây và cơ chế khóa trạng thái triage

Luồng vận hành chuẩn trong một nhà máy phần mềm đám mây thường được tổ chức qua các agent chuyên biệt:

Triage Agent: Tiếp nhận sự kiện từ issue tracker (GitHub, Linear), phân loại tác vụ và gán nhãn trạng thái (ready-to-implement, ready-to-spec, needs-info, hoặc wait-to-implement).
Spec Agent: Tự động soạn thảo bản mô tả yêu cầu kỹ thuật nếu tác vụ rơi vào nhãn ready-to-spec.
Implementation Agent: Tiến hành viết mã nguồn dựa trên spec hoặc thực thi trực tiếp các tác vụ ready-to-implement.
Code Review / Verification Agent: Chạy phân tích tĩnh, thực thi bài test tự động hoặc kiểm thử giao diện qua công cụ tự động hóa.
Human Review: Kỹ sư kiểm tra bằng chứng nghiệm thu và ra quyết định phê duyệt.
CI/CD: Tích hợp và triển khai mã nguồn lên môi trường mục tiêu.

Về mặt kiến trúc hệ thống, các nhãn trạng thái của Triage Agent không đơn thuần để quản lý danh sách việc, mà chính là cơ chế khóa đồng thời (concurrency locks) và chuyển giao trạng thái (state handoffs) giữa các cụm agent đám mây phân tán. Khi hàng chục phiên agent chạy song song, cơ chế khóa này ngăn chặn tình trạng nhiều agent cùng tranh chấp một tác vụ, đồng thời phân luồng công việc để tránh làm quá tải các kỹ sư đóng vai trò kiểm duyệt cuối cùng.

Bạn chưa cần dựng nhà máy phần mềm nếu chỉ dùng các công cụ lập trình AI cá nhân (như Claude Code hay Codex CLI) trong từng phiên làm việc đơn lẻ. Bạn chỉ thực sự cần đến nhà máy phần mềm khi phải quản lý một hàng đợi công việc lớn, cần chạy song song nhiều luồng xử lý độc lập và đòi hỏi cơ chế phân luồng, khóa tác vụ tự động để cỗ máy không bị đình trệ vì chờ review thủ công.

Phán đoán dịch chuyển đi đâu: Phân tách vòng lặp "Why" và "How"

Để xác định vị trí của kỹ sư trong mô hình mới, cần phân tách quá trình phát triển phần mềm thành hai vòng lặp cốt lõi:

Vòng lặp "Why" (Lý do): Chuyển hóa ý tưởng thành mục tiêu sản phẩm, xác định giá trị cho người dùng cuối và đưa ra các quyết định đánh đổi về mặt kinh doanh. Vòng lặp này hoàn toàn do con người nắm giữ vì AI không thể tự định hình nguyện vọng và ngữ cảnh của con người.
Vòng lặp "How" (Cách thức): Sản xuất và biến đổi các sản phẩm trung gian như mã nguồn, bài test, cấu hình hạ tầng và tài liệu kỹ thuật. Vòng lặp này đang được chuyển giao cho các agent AI thực thi tự động.

Phân tách vòng lặp Why do con người định hình và vòng lặp How do AI thực thi

Khi công việc trong vòng lặp "How" do máy móc đảm nhận, vị trí của con người đối với luồng vận hành thay đổi qua ba trạng thái:

Trong vòng lặp (In the loop): Con người đứng gác từng dòng code do AI sinh ra. Cách làm này tạo ra nút thắt cổ chai nghiêm trọng vì tốc độ sinh code của AI vượt xa khả năng đọc hiểu thủ công của con người.
Ngoài vòng lặp (Off the loop / Vibe coding): Bỏ mặc agent tự do xả mã nguồn vào hệ thống mà không có sự kiểm soát, dẫn đến sự tích tụ của code rác và nguy cơ sụp đổ kiến trúc.
Trên vòng lặp (On the loop): Con người đứng ở vị trí điều khiển hệ thống, tập trung thiết kế, duy trì và tinh chỉnh bộ khung kiểm soát để định hướng agent ngay từ đầu.

Đứng "On the loop" cũng là tiền đề để kích hoạt bánh đà agentic (agentic flywheel). Thay vì kỹ sư phải sửa từng lỗi nhỏ do agent tạo ra, hệ thống sẽ thu thập dữ liệu đo đạc từ pipeline, bài test và môi trường runtime để phản hồi ngược lại bộ khung kiểm chuẩn. Từ đó, chính các agent sẽ đưa ra đề xuất tự nâng cấp bộ khung điều khiển của mình, giúp hệ thống liên tục tiến hóa dưới sự giám sát của con người.

Thực tế kinh tế do Kent Beck chỉ ra phản ánh chính xác sự chuyển dịch này: 90% kỹ năng mang tính cơ học (gõ cú pháp, biến đổi chuỗi, viết code mẫu) đã giảm giá trị kinh tế về 0. Tuy nhiên, 10% kỹ năng còn lại (bao gồm đặt câu hỏi đúng, sở hữu gu kỹ thuật, thiết kế kiến trúc hệ thống và đánh giá rủi ro) được gia tăng đòn bẩy giá trị lên 1.000 lần.

Mã hóa gu kỹ thuật vào bộ khung kiểm chuẩn (harness) tất định

Khung kiểm chuẩn (harness) là toàn bộ môi trường và cơ chế kiểm soát được xây dựng xung quanh mô hình AI (Agent = Model + Harness). Nhiệm vụ của harness là định hướng hành vi ban đầu và tạo ra mạng lưới kiểm soát tất định giúp agent tự sửa lỗi trước khi kết quả được chuyển đến con người.

Ma trận khung kiểm chuẩn harness giữa tính toán tất định CPU và suy luận GPU

Trục phân loại hệ thống kiểm soát bao gồm:

Chỉ dẫn trước (Feedforward): Bao gồm hướng dẫn kiến trúc (AGENTS.md, Skills), quy tắc lập trình, hoặc các công cụ tự động biến đổi code. Dạng suy luận (inferential) dựa trên GPU cung cấp ngữ cảnh rộng nhưng phi tất định; dạng tính toán (computational) dựa trên CPU (như AST transformers) mang tính tất định tuyệt đối.
Phản hồi sau (Feedback): Giúp agent tự sửa lỗi khi phát hiện sai lệch. Dạng tính toán (computational) chạy trên CPU với tốc độ mili-giây (linters, type checkers, bài kiểm thử cấu trúc) cung cấp tín hiệu phản hồi tin cậy; dạng suy luận (inferential) chạy trên GPU (AI code review, LLM-as-a-judge) hỗ trợ thẩm định ngữ nghĩa nhưng chịu khoảng bù suy luận và độ biến động cao hơn.

Birgitta Böckeler phân chia khung kiểm chuẩn thành ba hạng mục điều chỉnh:

Bộ kiểm chuẩn khả năng bảo trì (Maintainability Harness): Kiểm soát chất lượng nội bộ, độ phức tạp cyclomatic, trùng lặp mã nguồn và tuân thủ chuẩn mực viết code thông qua các công cụ phân tích tĩnh.
Bộ kiểm chuẩn độ phù hợp kiến trúc (Architecture Fitness Harness): Đảm bảo hệ thống tuân thủ các đặc tính kiến trúc (Fitness Functions), ranh giới module, tiêu chuẩn ghi log và chỉ số hiệu năng.
Bộ kiểm chuẩn hành vi (Behaviour Harness): Kiểm soát tính đúng đắn về mặt chức năng của ứng dụng. Đây chính là vấn đề phức tạp nhất hiện nay, bởi nếu chỉ dựa vào việc kiểm tra các bài unit test do AI tự viết, hệ thống rất dễ rơi vào trạng thái an toàn giả tạo.

Dưới góc độ không gian trạng thái, mô hình ngôn ngữ lớn (LLM) có năng lực tạo ra sự biến thiên vô hạn. Theo Định luật Ashby về sự đa dạng cần thiết (Ashby's Law of Requisite Variety), một bộ điều chỉnh chỉ có thể kiểm soát hệ thống nếu nó có độ phức tạp tương đương không gian trạng thái của hệ thống đó. Việc bắt buộc áp dụng các khuôn mẫu kiến trúc định sẵn (harness templates) chính là chiến lược giảm thiểu sự đa dạng, thu hẹp không gian biến thiên mà LLM có thể sinh ra để các công cụ tất định trên CPU giữ trọn quyền kiểm soát.

Nợ thấu hiểu: Cạm bẫy khi bài test xanh nhưng nhận thức cạn kiệt

Nợ thấu hiểu (comprehension debt) là khoảng cách ngày càng rộng giữa khối lượng mã nguồn tồn tại trong hệ thống và lượng code thực sự được con người hiểu rõ. Khác với nợ kỹ thuật (technical debt) vốn bộc lộ qua sự đình trệ vận hành, nợ thấu hiểu tạo ra sự tự tin giả tạo: các chỉ số CI/CD xanh mướt, nhưng mô hình nhận thức của đội ngũ kỹ sư về lý do tồn tại của các quyết định thiết kế đã bị rỗng ruột.

Nợ thấu hiểu và sự bất đối xứng giữa tốc độ sinh mã nguồn AI và khả năng thẩm định

Sự tích tụ này bắt nguồn từ bất đối xứng về tốc độ (speed asymmetry). Trước đây, một kỹ sư senior kiểm tra code nhanh hơn tốc độ viết của một junior. Sự xuất hiện của AI đảo ngược hoàn toàn thế cờ: một junior dùng AI có thể xả ra khối lượng code vượt xa khả năng thẩm định nghiêm túc của một senior. Cổng kiểm soát chất lượng bị biến thành cuộc khủng hoảng về bất đối xứng lưu lượng kiểm thử.

Thực trạng này bị che khuất bởi khoảng trống đo lường (measurement gap). Các thước đo hiệu suất phổ biến như DORA, throughput hay test coverage vẫn đẹp đẽ vì chúng chỉ đo đạc tốc độ hợp nhất mã nguồn chứ không đo đạc mô hình tâm trí của kỹ sư đối với hệ thống.

Nghiên cứu thực nghiệm của Anthropic trên 52 kỹ sư phần mềm cho thấy rõ sự suy giảm nhận thức này:

Nhóm giao phó thụ động cho AI bị sụt giảm 17% điểm số trong bài kiểm tra nhận thức (đạt 50% so với 67% của nhóm đối chứng).
Mức độ suy giảm kỹ năng nặng nề nhất diễn ra ở khả năng gỡ lỗi (debugging) và đọc hiểu mã nguồn.

Đáng chú ý, mức độ thấu hiểu phụ thuộc hoàn toàn vào chế độ sử dụng: lập trình viên sử dụng AI theo dạng giao phó thụ động đạt dưới 40% điểm thấu hiểu, trong khi nhóm sử dụng AI để truy vấn khái niệm, tức liên tục hỏi về các phương án đánh đổi và cấu trúc kiến trúc, đạt trên 65%.

Bên cạnh đó, bài test màu xanh không đồng nghĩa với logic đúng. Khi gặp lỗi, agent có thể tự sửa đổi hàng loạt test case hoặc thay đổi logic kiểm thử để khớp với đoạn code sai của nó. Nếu kỹ sư không duy trì nhận thức sâu sắc về hệ thống, những sai lệch này sẽ lọt qua các cổng tự động mà không bị phát hiện.

Kỷ luật thẩm định: Vì sao giao nộp code không kiểm chứng là thiếu trách nhiệm

Máy tính không chịu trách nhiệm pháp lý hay vận hành; trách nhiệm đó thuộc về con người. Như Simon Willison đã nhấn mạnh, nhiệm vụ của kỹ sư không phải là xả ra hàng nghìn dòng code, mà là giao nộp mã nguồn đã được chứng minh là hoạt động đúng. Việc quẳng hàng loạt pull request chưa kiểm chứng cho đồng nghiệp thẩm định là sự thoái thác trách nhiệm nghề nghiệp.

Kỷ luật thẩm định hai bước với bằng chứng thực tế và bài test hồi quy

Để chứng minh một thay đổi là an toàn, kỹ sư phải hoàn thành hai bước thẩm định bắt buộc:

Kiểm thử thủ công (Manual testing): Tự mình kích hoạt hệ thống và chứng kiến thay đổi hoạt động đúng thực tế. Kết quả kiểm thử phải được đóng gói thành bằng chứng hiển nhiên (như đoạn lệnh terminal kèm log output, hoặc video/ảnh chụp màn hình giao diện) đính kèm vào Pull Request.
Kiểm thử tự động (Automated testing): Đóng gói mã nguồn cùng bài test tự động tương ứng. Bài test phải bị hỏng ngay lập tức nếu đảo ngược (revert) đoạn code xử lý chính.

Đối với các agent tự động, bạn phải tích hợp công cụ (LSPs, CLI runners, headless browsers) để bắt buộc agent tự thực thi và trưng ra bằng chứng nghiệm thu trước khi tạo PR. Agent phải tự chạy lệnh CLI, chụp ảnh màn hình UI để chứng minh tính đúng đắn trước khi yêu cầu con người phê duyệt.

Giữ quyền sở hữu: 10% phán đoán định đoạt toàn bộ nhà máy phần mềm

Tỷ lệ mã nguồn gõ thủ công bằng tay có thể giảm về 0, nhưng quyền sở hữu (ownership) và gu kỹ thuật (taste) tuyệt đối không thể chuyển giao. Kỹ sư vẫn là người giữ quyền định đoạt: chọn đúng bài toán, thiết lập cấu trúc kiến trúc, đặt ra thanh chất lượng cho bộ kiểm chuẩn và quyết định khi nào bằng chứng chứng minh đã đủ an toàn để đưa code lên production.

Sự thành bại của một nhà máy phần mềm không nằm ở việc nó loại bỏ được bao nhiêu phần trăm sự hiện diện của con người, mà nằm ở việc nó đặt phán đoán của con người vào đúng vị trí có đòn bẩy giá trị cao nhất.