TL;DR
· Tháng 6 năm 2026, nhiều nhà thực hành lập trình AI gần như đồng thời đề xuất Loop Engineering, Stripe đã sử dụng Minions để hợp nhất hơn 1300 PR do AI tạo ra mỗi tuần.
· Phương pháp này không còn phụ thuộc vào việc con người đưa ra từng gợi ý tuần tự, mà để hệ thống tự động phát hiện nhiệm vụ, bàn giao, xác minh, lưu trạng thái và chuyển sang vòng tiếp theo.
· Độ tin cậy vẫn phụ thuộc vào bộ đánh giá độc lập, cổng chặn cứng và kiểm tra thủ công, nợ xác minh và suy giảm khả năng hiểu có thể khuếch đại ngược rủi ro.

Gần đây, một kỹ sư của Anthropic đã công bố tài liệu dài 11 trang về "Kỹ thuật vòng lặp cho hệ thống tác nhân", đặt Loop Engineering sau Prompt Engineering, Context Engineering và Harness Engineering, coi đây là phương pháp then chốt để lập trình AI bước vào giai đoạn tiếp theo.

Tài liệu này thu hút sự chú ý vì nó chạm đúng vào bước ngoặt của các cuộc thảo luận về lập trình AI vào tháng 6 năm 2026. Addy Osmani, Boris Cherny và Peter Steinberger gần như trong cùng một tuần đã gọi giai đoạn mới của lập trình AI là Loop Engineering, và pipeline Minions của Stripe đã sử dụng ý tưởng tương tự để hợp nhất hơn 1300 Pull Request do AI tạo ra mỗi tuần.

Con số này quan trọng không phải vì AI viết thêm được vài dòng code, mà vì trọng tâm của phát triển phần mềm đang chuyển từ "con người bảo mô hình viết gì" sang "con người thiết kế một hệ thống có thể tự xếp hàng, nhận nhiệm vụ, viết code, kiểm tra kết quả, lưu trạng thái và tiếp tục chạy".

Trong năm qua, các câu chuyện về công cụ lập trình AI chủ yếu xoay quanh năng lực mô hình: tự động hoàn thành code chính xác hơn, cửa sổ ngữ cảnh dài hơn, tác nhân có thể hoàn thành các tác vụ phức tạp hơn trong một lần. Nhưng Loop Engineering thảo luận về một điều khác: khi việc tạo code ngày càng rẻ, thứ mà kỹ sư thực sự cần thiết kế trở thành một vòng lặp bền vững. Máy móc có thể liên tục tạo ra các giải pháp ứng viên, con người phải quyết định kết quả nào đáng tin cậy, kết quả nào phải chặn lại, chi phí dài hạn nào đang bị ẩn giấu.

Gần đây, một kỹ sư của Anthropic đã công bố tài liệu dài 11 trang về "Kỹ thuật vòng lặp cho hệ thống tác nhân", đặt Loop Engineering sau Prompt Engineering, Context Engineering và Harness Engineering, coi đây là phương pháp then chốt để lập trình AI bước vào giai đoạn tiếp theo. Bài viết này lấy tài liệu đó làm điểm cắt, kết hợp các cuộc thảo luận công khai của Boris Cherny, Addy Osmani và những người khác, cùng với trường hợp Stripe Minions hợp nhất hơn 1300 PR do AI tạo ra mỗi tuần, để giải thích Loop Engineering thực sự là gì, tại sao đột nhiên được thảo luận rộng rãi trên mạng, và điều nó thực sự thay đổi không phải là viết code, mà là xác minh, lập lịch và phán đoán trong phát triển phần mềm.

Lập trình AI từ "một lần gợi ý" đến "vòng lặp liên tục"

Loop Engineering được đặt sau Prompt Engineering, Context Engineering và Harness Engineering, là lớp thứ tư của stack kỹ thuật AI.

Prompt Engineering giải quyết vấn đề "làm thế nào để hỏi"; Context Engineering giải quyết "cho mô hình xem cái gì"; Harness Engineering giải quyết "làm thế nào để kết nối một lần chạy mô hình với công cụ, kiểm thử và quy trình làm việc". Loop Engineering tiến thêm một bước: hệ thống không chỉ thực hiện một nhiệm vụ duy nhất, mà có thể khởi động lại vào thời gian cố định hoặc dưới các điều kiện kích hoạt, sử dụng kết quả của lần trước làm đầu vào cho vòng tiếp theo.

Một vòng lặp hoàn chỉnh thường bao gồm năm hành động.

Bước đầu tiên là phát hiện công việc, ví dụ quét các lỗi CI, Issue đang mở, commit code hoặc tác vụ đang chờ xử lý; bước thứ hai là bàn giao nhiệm vụ, tổ chức nhiệm vụ thành ngữ cảnh mà mô hình có thể xử lý; bước thứ ba là xác minh độc lập, kiểm tra xem code do mô hình tạo ra có thực sự chạy được, có vượt qua kiểm thử, có gây ra tác dụng phụ không; bước thứ tư là lưu trữ kết quả, ghi trạng thái, đánh giá và các việc chưa hoàn thành vào file hoặc hệ thống; bước thứ năm là lập lịch vòng lặp, để vòng tiếp theo chạy vào thời điểm thích hợp.

Điều quan trọng nhất ở đây không phải là "tạo sinh", mà là "xác minh". Nếu một vòng lặp chỉ liên tục để mô hình viết code, rồi lại để chính mô hình đó tự khen kết quả của mình, nó rất dễ trở thành "vòng lặp gật đầu": mỗi vòng có vẻ tiến triển, nhưng thực tế chỉ đóng gói lỗi một cách hoàn chỉnh hơn.

Vòng lặp triage buổi sáng của Osmani là một ví dụ cá nhân: hệ thống tự động đọc các lỗi CI của ngày hôm trước, Issue đang mở và các commit gần đây, tạo file trạng thái, chuyển các vấn đề không thể xử lý vào hộp thư đến của con người. Giá trị của nó không phải là thay kỹ sư đưa ra mọi quyết định, mà là hoàn thành sàng lọc ban đầu trước khi kỹ sư thức dậy, dành sự chú ý cho những phần thực sự cần phán đoán.

1300 PR của Stripe: độ tin cậy đến từ ràng buộc, không phải mô hình

Pipeline Minions của Stripe là trường hợp doanh nghiệp ấn tượng nhất trong cuộc thảo luận này: mỗi tuần hợp nhất hơn 1300 Pull Request do AI tạo ra, và code không được viết từng dòng bởi con người.

Nhưng điều này không có nghĩa Stripe giao hệ thống sản xuất cho một mô hình lớn tự do sáng tạo. Ngược lại, chìa khóa của Minions nằm ở quy trình được kiểm soát chặt chẽ: bộ điều phối xác định trước lắp ráp ngữ cảnh, trích xuất thông tin nhiệm vụ từ Jira, tìm kiếm code và các công cụ nội bộ; LLM chịu trách nhiệm tạo code; sau đó thông qua linter được mã hóa cứng, các cổng chặn commit và cuối cùng là kiểm tra thủ công để quyết định có thể hợp nhất hay không.

Nói cách khác, độ tin cậy không đến từ "mô hình đột nhiên đủ thông minh", mà từ một chuỗi các ràng buộc. Mô hình chịu trách nhiệm đề xuất các thay đổi ứng viên, hệ thống chịu trách nhiệm giới hạn những gì nó có thể động vào, những kiểm tra nào nó phải vượt qua, con người chịu trách nhiệm phán đoán cuối cùng xem có đưa vào nhánh chính hay không.

Đây cũng là sự khác biệt giữa Loop Engineering và các script lập trình AI thông thường. Script thông thường thường tập trung vào "để mô hình hoàn thành nhiệm vụ"; hệ thống vòng lặp phải xem xét nhiệm vụ đến từ đâu, xử lý thế nào khi thất bại, lưu trạng thái ra sao, kiểm soát ngân sách thế nào, ai ngăn lỗi xâm nhập vào môi trường sản xuất.

Nếu không có các ràng buộc này, 1300 PR mỗi tuần không phải là bước nhảy vọt về hiệu quả, mà có thể là cỗ máy tạo ra nợ kỹ thuật.

Bộ tạo sinh và bộ đánh giá phải được tách rời

Một thiết kế cốt lõi của Loop Engineering là tách bộ tạo sinh và bộ đánh giá.

Bộ tạo sinh chịu trách nhiệm viết code, sửa file, gửi kết quả ứng viên. Bộ đánh giá chịu trách nhiệm tìm lỗi, và tốt nhất là mặc định cho rằng code có vấn đề. Hai bộ này không thể được hoàn thành bởi cùng một "tác nhân lạc quan", vì mô hình khi tự đánh giá thường có xu hướng công nhận đầu ra của chính nó, đặc biệt khi mô tả nhiệm vụ mơ hồ, phạm vi kiểm thử không đầy đủ hoặc ngữ cảnh không hoàn chỉnh.

Bộ đánh giá độc lập có thể đơn giản hơn, hoài nghi hơn và dễ dàng tinh chỉnh hơn. Nó không cần giải quyết vấn đề một cách sáng tạo, chỉ cần xác minh trang có thể mở được không, kiểm thử có vượt qua không, điều kiện biên có bị phá vỡ không, code có tuân thủ các quy tắc đã định không. Một số thực hành cho phép bộ đánh giá nhấp vào trang thực tế thông qua công cụ tự động hóa trình duyệt, thay vì chỉ đọc code rồi đưa ra đánh giá.

Điều này giải thích tại sao "xác minh" là khâu khó nhất trong vòng lặp năm bước. Tạo code ngày càng rẻ, nhưng chứng minh một đoạn code thực sự đúng vẫn còn đắt. Đặc biệt trong các codebase lớn, lỗi không nhất thiết lộ ra ngay lập tức, và kiểm thử không nhất thiết bao phủ tất cả các đường dẫn kinh doanh thực tế. Vòng lặp chạy càng nhanh, các giả định chưa được xác minh tích lũy càng nhanh.

Chi phí tiềm ẩn sẽ củng cố lẫn nhau

Rủi ro của Loop Engineering không nằm ở việc nó có thể viết sai code, mà ở việc nó có thể khiến nhóm khó nhận ra rằng họ đã mất khả năng hiểu.

Loại chi phí thứ nhất là nợ xác minh. Các lỗi không được kiểm thử bao phủ sẽ tích lũy liên tục trong vòng lặp, cho đến khi bùng phát tập trung vào một lần hợp nhất hoặc triển khai. Loại thứ hai là suy giảm khả năng hiểu. Codebase tiếp tục phình to, nhưng kỹ sư không tự mình trải qua các quyết định thiết kế quan trọng, bản đồ tinh thần chỉ còn lại phiên bản cũ. Loại thứ ba là đầu hàng nhận thức. Con người bắt đầu mặc nhiên chấp nhận đầu ra của máy, chỉ phê duyệt hình thức. Loại thứ tư là bùng nổ tiêu thụ token. Thử lại, tác nhân phụ, ngữ cảnh dài và xác minh nhiều vòng có thể khiến hóa đơn tăng nhanh.

Bốn loại chi phí này sẽ nuôi dưỡng lẫn nhau: kiểm thử không đủ dẫn đến nợ xác minh, nợ xác minh tăng khiến kỹ sư càng không muốn hiểu sâu, hiểu biết giảm làm cho kiểm tra thủ công trở thành con dấu cao su, kiểm tra con dấu cao su lại thúc đẩy nhiều lần thử tự động hơn và chi phí cao hơn.

Do đó, cùng một bộ thành phần vòng lặp, trong tay các kỹ sư khác nhau có thể tạo ra kết quả hoàn toàn trái ngược. Người có khả năng phán đoán mạnh mẽ, ranh giới rõ ràng có thể sử dụng vòng lặp để khuếch đại sự hiểu biết của mình về hệ thống, coi máy móc như lớp thực thi không biết mệt mỏi; người có khả năng phán đoán yếu hoặc quá phụ thuộc vào tự động hóa có thể sau vài tháng trở thành "người gác cổng" cho hệ thống của chính mình, chỉ biết phê duyệt hoặc từ chối, nhưng không thể giải thích tại sao hệ thống lại chạy như vậy.

Code trở nên rẻ hơn, điều đắt đỏ là phán đoán

Loop Engineering đẩy một xu hướng dài hạn đến vị trí rõ ràng hơn: code, kế hoạch, PR và phân rã nhiệm vụ đang trở nên gần như miễn phí, nhưng "điều gì thực sự đúng" không trở nên rẻ hơn.

Đối với doanh nghiệp, điều này có nghĩa là trọng tâm đầu tư cho lập trình AI có thể chuyển từ mua các mô hình mạnh hơn sang thiết kế các quy trình ổn định hơn: ranh giới nhiệm vụ, lắp ráp ngữ cảnh, đánh giá độc lập, lưu trạng thái, giới hạn ngân sách, điểm kiểm tra thủ công và cách dừng vòng lặp khi có bất thường. Năng lực mô hình vẫn quan trọng, nhưng nó chỉ là một phần của hệ thống.

Đối với kỹ sư, vai trò cũng đang thay đổi. Công việc cốt lõi trước đây là viết code, bây giờ ngày càng chuyển thành xem xét các câu trả lời ứng viên do máy tạo ra: nó có đáp ứng yêu cầu không, có phá vỡ kiến trúc không, có chỉ trông hợp lý không, có đẩy độ phức tạp cho những người bảo trì tương lai không.

Điều này không có nghĩa lập trình viên đã bị thay thế. Ngược lại, Loop Engineering giống như một bộ khuếch đại phán đoán. Nó có thể giúp một kỹ sư tạo ra lượng thay đổi mà trước đây một nhóm nhỏ mới có thể hoàn thành, và cũng có thể khuếch đại sự lười biếng, mù quáng tin tưởng và thiếu xác minh thành các sự cố sản xuất.

Sự phân nhánh thực sự nằm ở việc con người có còn giữ đủ khả năng phán đoán và quyền phủ quyết mạnh mẽ hay không. AI có thể liên tục gửi PR, nhưng có được hợp nhất không, có nên triển khai không, về lâu dài có kéo sụt hệ thống không, vẫn phụ thuộc vào con người.

Nhấp để tìm hiểu các vị trí tuyển dụng của BlockBeats

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Telegram nhóm đăng ký: https://t.me/theblockbeats

Telegram nhóm giao lưu: https://t.me/BlockBeats_App

Twitter tài khoản chính thức: https://twitter.com/BlockBeatsAsia