Khi agent viết phần lớn mã: nút cổ chai dịch từ viết sang xác minh
Ảnh: Amit Merchant

Khi agent viết phần lớn mã: nút cổ chai dịch từ viết sang xác minh

Từ đầu 2026, thông lượng nhánh tính năng tăng vọt còn nhánh chính thì đứng yên. Vì sao mã do agent sinh khó review hơn mã người viết, quy trình spec-driven và hộp cát đang hình thành ra sao, và đơn vị chi phí phần mềm đã đổi thành gì.

Cập nhật: tháng 8/2026.

Nửa đầu 2026, bảng số liệu của các đội phần mềm bắt đầu nói một chuyện kỳ lạ: số nhánh tính năng hoàn thành tăng vọt, còn số thay đổi thật sự vào được nhánh chính thì đứng yên, thậm chí tụt. Số liệu 2026 của CircleCI cho thấy thông lượng nhánh tính năng tăng khoảng 59% so với năm trước, trong khi thông lượng nhánh chính của đội trung vị lại giảm. Báo cáo benchmark 2026 của LinearB thì đo được thời gian một pull request do agent tạo phải nằm chờ trước khi có người ngó tới dài hơn nhiều lần so với PR người tự viết.

Nhìn từ xa thì tưởng đội ngũ đang chậm đi. Nhìn kỹ thì ngược lại: khâu gõ ra mã đã nhanh tới mức không còn là chỗ hẹp nữa, và toàn bộ áp lực dồn sang khâu mà con người vẫn phải gánh — xác minh. Cái mới ở đây không phải “AI biết viết mã”; chuyện đó cũ rồi. Cái mới là hệ quả dây chuyền: khi chi phí sinh ra mã tiến dần về 0, mọi quy ước trong quy trình vốn ngầm dựa trên giả định “viết mã là phần đắt nhất” đều gãy cùng lúc.

Nút cổ chai không biến mất, nó chỉ dịch chỗ

Một dây chuyền chỉ chảy nhanh bằng khâu hẹp nhất của nó. Suốt hai mươi năm, khâu hẹp trong làm phần mềm là biến ý định thành mã chạy được, nên mọi thứ đều tối ưu cho khâu đó: IDE thông minh hơn, framework sẵn hơn, sprint chia theo “bao nhiêu điểm story”. Từ 2026, khâu đó rộng ra gần như vô hạn — một kỹ sư cho ba bốn agent chạy song song trên bốn nhánh, mỗi nhánh ra một diff hoàn chỉnh trong vài chục phút. Nhưng khâu kế tiếp, đọc diff đó và tin được rằng nó đúng, vẫn chạy đúng tốc độ sinh học của một bộ não người.

Dây chuyền không đổi, chỉ chỗ thắt là đổi: khi agent viết mã, năng lực xác minh của con người trở thành trần sản lượng của cả đội.
Dây chuyền không đổi, chỉ chỗ thắt là đổi: khi agent viết mã, năng lực xác minh của con người trở thành trần sản lượng của cả đội.

Triệu chứng dễ thấy nhất là hai con số đi ngược nhau trong cùng một báo cáo: thời gian review trung vị kéo dài ra nhiều lần, đồng thời tỉ lệ PR được merge mà không có ai review cũng tăng. Đó không phải mâu thuẫn mà là hai cách phản ứng trước cùng một sức ép. Đội giữ kỷ luật thì hàng đợi review phình ra; đội chịu không nổi thì mở van, và mã chưa ai đọc chảy thẳng vào nhánh chính.

Vì sao mã do agent viết lại khó review hơn mã người viết

Trực giác thông thường là: mã là mã, ai viết cũng vậy. Sai. Có mấy khác biệt về cơ chế làm việc review đắt hơn hẳn.

  • Mất dấu vết quyết định. Khi đồng nghiệp viết một hàm, họ mang theo chuỗi lựa chọn: đã thử cách nào, bỏ cách nào, vì sao — và review là hỏi vào chuỗi đó. Diff của agent tới tay bạn ở trạng thái hoàn chỉnh, không kèm hành trình; người review phải dựng lại ý định từ ticket và từ chính đoạn mã, tức làm phần khó nhất của thiết kế nhưng làm ngược và làm sau.
  • Mã sai trông giống mã đúng. Lỗi của người lộ ra ở bề mặt: đặt tên lệch, cấu trúc lủng củng, thiếu nhánh xử lý — đúng những tín hiệu người review học cách bắt bằng mắt. Mã do mô hình sinh thì trơn tru, đặt tên hợp lý, docstring đầy đủ, trông chuẩn ngay cả khi ngữ nghĩa sai. Nó vô hiệu hoá đúng bộ cảm biến mà kỹ sư đã luyện cả sự nghiệp.
  • Che lỗi thay vì xử lý lỗi. Các phân tích kho mã trong 2026 chỉ ra xu hướng “error masking” tăng mạnh: agent hay bọc một khối try rộng và nuốt ngoại lệ để bài kiểm thử chạy qua. Về sau không ai biết đoạn bắt lỗi nào có chủ đích, đoạn nào chỉ để làm dịu CI.
  • Ít tái dùng, hay viết lại. Cũng các phân tích đó cho thấy mức “gọi sang hàm có sẵn” trong commit mới giảm rõ rệt: agent thường sinh một bản sao cục bộ thay vì đi tìm thứ đã có. Từng diff thì gọn, nhưng kho mã phình lên với nhiều bản gần giống nhau — thứ nợ chỉ hiện hoá lúc phải sửa một lỗi ở cả sáu chỗ.
  • Diff quá to. Vì rẻ, agent hay làm nhiều hơn mức được yêu cầu: dọn định dạng, đổi tên biến, thêm test cho chỗ không liên quan. Người review đối diện với 900 dòng mà phần cần suy nghĩ chỉ có 40.

Cộng lại: đơn giá review một dòng mã do agent sinh cao hơn một dòng do người sinh, trong khi số dòng cần review thì tăng vài lần. Đó là công thức của một hàng đợi vỡ.

Quy trình mới: spec thành nguồn sự thật, mã thành sản phẩm phái sinh

Phản ứng đang hình thành rõ nhất trong 2026 là spec-driven development. Ý tưởng gốc không mới, nhưng lý do nó sống dậy thì mới: agent viết mã rất giỏi và đoán ý định rất tệ. Nếu ý định chỉ tồn tại trong một cuộc trò chuyện — trôi mất sau khi đóng cửa sổ chat — thì mỗi lần chạy lại là một lần đoán lại.

Nên các đội đảo ngược thứ tự: đặc tả là tài sản được lưu, được review, được đánh phiên bản; là thứ sinh ra từ đặc tả và có thể vứt đi sinh lại. Trong 2026 hầu hết bộ công cụ lập trình có AI lớn đều đã ra phiên bản riêng của ý tưởng này — GitHub Spec Kit, AWS Kiro, các cơ chế tương đương trong Claude Code và Cursor, cùng một loạt dự án mở như OpenSpec. Chi tiết khác nhau, khung thì giống: yêu cầu → thiết kế → kế hoạch → thực thi, mỗi bước có văn bản để soi.

Điều đáng nói không phải định dạng file, mà là chỗ nào công sức con người được đặt vào. Một spec tốt cho agent không phải bản mô tả văn xuôi; nó chứa những thứ máy kiểm được:

  • Bất biến: điều gì phải luôn đúng sau thay đổi (số dư không âm, mỗi đơn hàng đúng một bản ghi thanh toán).
  • Tiêu chí chấp nhận dịch thẳng được thành test, không phải “phải nhanh và ổn định”.
  • Non-goal: chỗ nào cấm đụng. Đây là phần hay bị bỏ nhất và cứu được nhiều nhất — không nói ra thì agent sẽ “tiện tay” refactor cả module cạnh bên.
  • Kích thước thay đổi: một ý định một thay đổi. Diff nhỏ không phải sở thích thẩm mỹ, nó là điều kiện để review còn khả thi.

Nói cách khác, kỹ sư chuyển từ “viết lời giải” sang “viết định nghĩa của lời giải đúng” — phần luôn khó hơn, chỉ bị che đi bấy lâu vì phần kia tốn thời gian hơn.

Chạy agent như chạy mã của người lạ

Nhánh thay đổi thứ hai đến từ phía bảo mật. Một agent viết mã không chỉ sinh ra văn bản: nó chạy lệnh, cài phụ thuộc, gọi API, đọc file. Về mô hình mối đe doạ, nó là mã không tin cậy chạy với quyền của bạn, cộng thêm một đặc tính mà tiến trình thường không có — nó đọc dữ liệu bên ngoài (issue, trang web, README của gói) rồi để dữ liệu đó ảnh hưởng tới hành động tiếp theo. Đó chính là bề mặt của prompt injection gián tiếp.

Nên trong 2026, mặc định công nghiệp đã dịch từ “chạy agent trên máy dev” sang môi trường dùng một lần, cách ly bằng phần cứng: microVM kiểu Firecracker hoặc lớp cách ly nhân kiểu gVisor, mỗi tác vụ một máy, xong thì huỷ. Kèm theo là kỷ luật quyền hạn nay thành bắt buộc: chỉ mount thư mục thật sự cần, khoá ngắn hạn thay cho API key vĩnh viễn, dữ liệu là bản sao đã che, và mọi kết nối ra ngoài phải khai báo trước.

Ba lớp cổng thay cho niềm tin: hợp đồng ý định trước khi chạy, hộp cát và quyền tối thiểu trong lúc chạy, bằng chứng kiểm được sau khi chạy.
Ba lớp cổng thay cho niềm tin: hợp đồng ý định trước khi chạy, hộp cát và quyền tối thiểu trong lúc chạy, bằng chứng kiểm được sau khi chạy.

Lớp cổng thứ ba nằm ở CI, và đây là chỗ nhiều đội vẫn còn chủ quan. Bộ kiểm thử truyền thống được thiết kế để bắt lỗi của người — nên nó kiểm vài ví dụ tiêu biểu. Agent thì rất giỏi làm cho những ví dụ đó xanh mà không cần hiểu bài toán. Muốn CI còn giá trị làm bằng chứng, nó phải sinh ra thứ khó giả:

  • Kiểm thử tính chất và fuzz: khẳng định một luật đúng với mọi đầu vào sinh ngẫu nhiên, thay vì với ba ca đã biết.
  • Mutation testing: cố tình làm hỏng mã rồi xem bộ test có kêu không — nó đo chất lượng của test, thứ giờ cũng phần lớn do agent viết.
  • Build tất định và khoá phụ thuộc theo hash: agent tự thêm gói là chuyện thường ngày; không khoá thì bề mặt chuỗi cung ứng nở ra sau mỗi lần chạy.
  • Ghi xuất xứ: agent nào, mô hình nào, theo spec nào, trong hộp cát nào. Khi có sự cố sáu tháng sau, đây là thứ duy nhất trả lời được “chỗ này ai quyết”.

Góc kinh tế: đơn vị chi phí đã đổi

Đơn vị tính chi phí phần mềm xưa nay ngầm là một dòng mã được viết ra, vì đó là chỗ tiền lương thật sự chảy vào. Từ 2026, chi phí sinh ra một dòng rơi xuống mức tính bằng cent, còn chi phí để một dòng được xác minh và chịu trách nhiệm thì không giảm — nó còn tăng, vì mã khó review hơn. Đơn vị chi phí thật vì thế đã dịch sang một thay đổi đã xác minh và đưa vào chạy thật. Hệ quả rất cụ thể:

  • Tiết kiệm ở khâu viết dễ bị nuốt trọn ở khâu sau. Nếu kỹ sư cấp cao — người đắt nhất trong đội — dành phần lớn ngày để đọc và sửa mã agent, thì chi phí chỉ chuyển chỗ chứ không mất đi. Vài đội đã đo được đúng nghịch lý này: throughput trên biểu đồ đẹp lên trong khi số giờ dành cho rework và sự cố cũng tăng.
  • Nợ kỹ thuật đổi hình dạng. Nợ kiểu cũ là mã xấu ai cũng thấy. Nợ kiểu mới là mã trông đẹp mà không ai thật sự hiểu, lặp lại ở nhiều chỗ, có bắt lỗi vô nghĩa rải rác. Nó không gây khó chịu ngay, nên không được ưu tiên trả — và vì thế đắt hơn.
  • Thị trường lao động lệch về phía kinh nghiệm. Việc mà kỹ sư mới vào nghề từng làm để học — sửa lỗi nhỏ, viết CRUD, gắn vài API — chính là việc agent làm rẻ nhất, nên nhu cầu dồn sang các vai đòi phán đoán. Đây là một vấn đề liên thời gian: cắt tầng dưới hôm nay là cắt nguồn cung tầng trên của 2032, trong khi cái lợi thì thấy ngay quý này. Ai cũng nhìn ra, nhưng động cơ của từng công ty riêng lẻ vẫn là cắt.
  • Trách nhiệm không có chỗ trốn. Không nhà cung cấp nào bảo hành đầu ra của mô hình. Về pháp lý và vận hành, người bấm nút merge là người chịu — một quy trình không sinh ra bằng chứng kiểm được thì đang chuyển rủi ro cho chính đội mình mà không ghi vào sổ.

Nghề lập trình thật sự đổi thành gì

Không phải “kỹ sư biến mất”, cũng không phải “kỹ sư chỉ còn ngồi duyệt”. Cái đổi là tỷ trọng: bốn việc trước đây chiếm phần nhỏ trong ngày nay nở thành phần chính — đặc tả (biến yêu cầu mơ hồ thành bất biến kiểm được), xác minh (dựng bộ kiểm thử đủ mạnh để cái xanh của CI có ý nghĩa), kiến trúc và ranh giới (agent làm tốt trong phạm vi hẹp và rõ, nên hợp đồng sạch giữa các module lên giá), và vận hành khi hỏng (đọc log, dựng lại chuỗi nhân quả, quyết định rollback — phần agent yếu nhất). Nghịch lý dễ chịu: đây vốn luôn là phần “kỹ thuật” thật sự của kỹ thuật phần mềm, chỉ bị lấn át bấy lâu bởi công việc thủ công của việc gõ ra mã.

Dự đoán

  • Chỉ số đội nhóm được viết lại quanh khâu xác minh. Thông lượng nhánh tính năng mất giá trị làm thước đo; thứ được nhìn sẽ là thời gian từ spec tới thay đổi đã xác minh chạy thật, tỉ lệ rework của PR do agent tạo, và tỉ lệ merge không qua review.
  • Review tách làm hai lớp. Thay đổi ít rủi ro đi qua cổng tự động (test tính chất, mutation, phân tích tĩnh, agent review độc lập); mắt người dồn vào vùng rủi ro cao: bảo mật, tiền, di trú dữ liệu, hợp đồng giữa các module. “Merge trước, review sau” phổ biến ở nơi rollback rẻ và tê liệt ở nơi không có.
  • Hộp cát thành hạ tầng mặc định. Chạy agent thẳng trên máy dev với quyền đầy đủ sẽ bị nhìn như chạy binary lạ bằng quyền root — vẫn có người làm, nhưng đã ra khỏi vùng chấp nhận được.
  • Một đợt sự cố bảo trì đang tới. Mã sinh ồ ạt trong 2025–2026 sẽ tới tuổi phải sửa vào 2027–2028, ở những kho không ai còn giữ ý định gốc. Đội lưu spec và xuất xứ sẽ trả giá thấp hơn hẳn đội chỉ lưu mã.
  • Sức ép quay lại phía tuyển dụng. Sau vài quý thấy chi phí xác minh không giảm, một số công ty sẽ tuyển lại tầng dưới — với mô tả công việc khác: vào nghề bằng đọc, kiểm thử và vận hành, không phải bằng những dòng mã đầu tiên.

Tóm lại: 2026 không phải năm phần mềm được viết bởi máy. Nó là năm ngành phần mềm phát hiện ra viết chưa bao giờ là phần đắt nhất — chỉ là phần dễ thấy nhất. Khi phần đó rẻ đi, thứ còn lại lộ ra: một hệ thống chỉ đáng tin bằng lượng bằng chứng ta có về nó.

Chia sẻ

Thảo luận