8 cấp độ của kỹ thuật xây dựng tác nhân thông minh

Tác giả: Bassim Eledath

Dịch: Bảo Ngọc

Khả năng lập trình của AI đang vượt xa khả năng chúng ta kiểm soát nó. Đó là lý do tại sao tất cả những nỗ lực cố gắng đạt điểm cao trong SWE-bench của mọi người lại không đồng bộ với các chỉ số năng suất thực sự mà các lãnh đạo kỹ thuật quan tâm. Nhóm của Anthropic đã ra mắt Cowork trong vòng 10 ngày, trong khi một nhóm khác sử dụng cùng mô hình đó nhưng không thể tạo ra một POC (bằng chứng khái niệm) nào — sự khác biệt nằm ở chỗ một nhóm đã thu hẹp khoảng cách giữa năng lực và thực hành, còn nhóm kia thì chưa.

Khoảng cách này sẽ không biến mất trong một đêm, mà sẽ dần thu hẹp theo từng cấp độ. Tổng cộng có 8 cấp độ. Phần lớn những người đọc bài viết này có thể đã vượt qua vài cấp đầu tiên, còn bạn thì háo hức muốn đạt được cấp tiếp theo — vì mỗi cấp tăng đều mang lại bước nhảy lớn về năng suất, và mỗi lần nâng cao khả năng của mô hình sẽ càng làm tăng lợi ích này hơn nữa.

Một lý do khác bạn nên quan tâm là hiệu ứng hợp tác nhóm. Sản lượng của bạn còn phụ thuộc nhiều hơn bạn nghĩ vào cấp độ của các đồng đội. Giả sử bạn là người cấp 7, khi ngủ đêm, các AI trong nền sẽ giúp bạn đề xuất vài PR. Nhưng nếu kho mã của bạn cần một đồng nghiệp phê duyệt để hợp nhất, và người đó vẫn đang ở cấp 2, vẫn thủ công xem xét PR, thì năng suất của bạn sẽ bị giới hạn. Vì vậy, giúp đồng đội nâng cấp cũng có lợi cho chính bạn.

Thông qua việc trao đổi với nhiều nhóm và cá nhân về thực hành sử dụng AI hỗ trợ lập trình, dưới đây là con đường tiến cấp độ mà tôi quan sát được (thứ tự không hoàn toàn tuyệt đối):

8 cấp độ của kỹ thuật AI

Cấp 1 và 2: Hoàn thiện Tab và IDE tích hợp AI

Hai cấp này tôi sẽ đề cập nhanh, chủ yếu để ghi lại đầy đủ. Bạn có thể bỏ qua hoặc đọc lướt.

Hoàn thiện Tab là bước khởi đầu của mọi thứ. GitHub Copilot đã mở màn cho phong trào này — nhấn Tab để tự động hoàn thiện mã. Nhiều người có thể đã quên giai đoạn này, những người mới bắt đầu còn có thể bỏ qua luôn. Nó phù hợp hơn với các lập trình viên có kinh nghiệm, họ có thể xây dựng khung mã trước, rồi để AI điền các chi tiết sau.

Các IDE chuyên dụng như Cursor đã thay đổi cục diện, kết nối chat và kho mã, giúp chỉnh sửa qua nhiều tệp dễ dàng hơn nhiều. Nhưng giới hạn vẫn nằm ở ngữ cảnh. Mô hình chỉ có thể giúp xử lý những gì nó nhìn thấy, và điều điên rồ là hoặc là nó không thấy đúng ngữ cảnh, hoặc là nó thấy quá nhiều ngữ cảnh không liên quan.

Hầu hết người ở cấp này cũng đang thử các chế độ lập trình của AI đã chọn: biến ý tưởng sơ bộ thành kế hoạch từng bước có cấu trúc gửi cho LLM, lặp lại quá trình này rồi kích hoạt thực thi. Ở giai đoạn này, hiệu quả khá tốt, cũng là cách giữ kiểm soát hợp lý. Tuy nhiên, các cấp cao hơn sẽ cho thấy rằng phụ thuộc quá nhiều vào chế độ kế hoạch sẽ ngày càng ít đi.

Cấp 3: Kỹ thuật ngữ cảnh (Context Engineering)

Bây giờ mới vào phần thú vị. Kỹ thuật ngữ cảnh (Context Engineering) là từ khóa của năm 2025, vì mô hình cuối cùng đã có thể đáng tin cậy theo dõi một số lượng chỉ thị hợp lý, kết hợp với ngữ cảnh phù hợp. Ngữ cảnh ồn ào hoặc không đủ đều tệ như nhau, vì vậy công việc cốt lõi là tăng mật độ thông tin của mỗi token. “Mỗi token phải chiến đấu cho vị trí của nó trong prompt” — đó là chân lý lúc đó.

Thông tin giống nhau, ít token hơn — mật độ thông tin mới là vua (nguồn: humanlayer/12-factor-agents)

Trong thực tế, kỹ thuật ngữ cảnh bao gồm nhiều mặt hơn mọi người nhận thức. Nó bao gồm prompt hệ thống và các file quy tắc (.cursorrules, CLAUDE.md). Nó bao gồm cách bạn mô tả công cụ, vì mô hình đọc các mô tả này để quyết định gọi công cụ nào. Nó còn bao gồm quản lý lịch sử hội thoại, tránh các AI chạy dài bị lạc hướng sau vòng thứ mười. Nó cũng bao gồm quyết định công cụ nào sẽ được mở ra mỗi vòng, vì quá nhiều lựa chọn sẽ làm mô hình bối rối — giống như con người.

Ngày nay, bạn ít nghe nói về kỹ thuật ngữ cảnh nữa. Trọng tâm đã chuyển sang các mô hình có thể chịu đựng ngữ cảnh ồn ào hơn, có thể suy luận trong các tình huống hỗn loạn hơn (cửa sổ ngữ cảnh lớn hơn cũng giúp ích). Nhưng việc tiêu thụ ngữ cảnh vẫn rất quan trọng. Trong một số tình huống sau, nó vẫn là điểm nghẽn:

Mô hình nhỏ nhạy cảm hơn với ngữ cảnh. Ứng dụng thoại thường dùng mô hình nhỏ hơn, và kích thước ngữ cảnh cũng liên quan đến độ trễ của token đầu tiên, ảnh hưởng đến tốc độ phản hồi.

Token tiêu hao nhiều. Các giao thức ngữ cảnh mô hình (Model Context Protocol - MCP) như Playwright và đầu vào hình ảnh sẽ nhanh chóng tiêu hao token, khiến bạn sớm rơi vào trạng thái “hợp thoại nén” trong Claude Code hơn dự kiến.

Các AI tích hợp hàng chục công cụ, tiêu tốn token để phân tích định nghĩa công cụ còn nhiều hơn cả làm việc thực tế.

Điều quan trọng hơn là: kỹ thuật ngữ cảnh không biến mất, chỉ đang tiến hóa. Trọng tâm đã chuyển từ việc lọc ngữ cảnh xấu sang đảm bảo ngữ cảnh đúng xuất hiện đúng lúc. Chính sự chuyển đổi này đã mở đường cho cấp 4.

Cấp 4: Kỹ thuật ghép (Compounding Engineering)

Kỹ thuật ngữ cảnh chỉ cải thiện cho lần hội thoại hiện tại. Kỹ thuật ghép (Compounding Engineering, do Kieran Klaassen đề xuất) cải thiện cho các lần hội thoại sau này. Triết lý này là bước ngoặt đối với tôi và nhiều người khác — giúp chúng tôi nhận ra rằng “lập trình theo cảm tính” không chỉ đơn thuần là làm nguyên mẫu.

Đây là vòng lặp “lập kế hoạch, phân công, đánh giá, tích lũy”. Bạn lập kế hoạch nhiệm vụ, cung cấp đủ ngữ cảnh cho LLM để thành công. Bạn giao nhiệm vụ. Bạn đánh giá kết quả. Và bước quan trọng — bạn tích lũy kinh nghiệm: cái gì hiệu quả, cái gì sai, lần tới nên làm theo mô hình nào.

Vòng lặp tích lũy: lập kế hoạch, phân công, đánh giá, tích lũy — mỗi vòng đều làm cho vòng tiếp theo tốt hơn

Điều kỳ diệu nằm ở bước “tích lũy”. LLM là không trạng thái. Nếu hôm qua nó tái tạo một phụ thuộc mà bạn đã rõ ràng loại bỏ, ngày hôm sau nó vẫn sẽ làm như vậy — trừ khi bạn bảo nó đừng. Phương pháp phổ biến nhất là cập nhật file quy tắc CLAUDE.md (hoặc tương đương), ghi lại bài học kinh nghiệm vào mọi hội thoại tương lai. Nhưng cần lưu ý: sự thúc ép đưa mọi thứ vào file quy tắc có thể phản tác dụng (quá nhiều chỉ thị thì chẳng khác gì không có chỉ thị). Cách tốt hơn là tạo ra môi trường để LLM tự phát hiện ngữ cảnh hữu ích dễ dàng — ví dụ như duy trì thư mục docs/ luôn cập nhật (chi tiết sẽ trình bày ở cấp 7).

Những người thực hành kỹ thuật ghép thường rất nhạy cảm với ngữ cảnh cung cấp cho LLM. Khi LLM mắc lỗi, phản ứng tự nhiên của họ là nghĩ xem có thiếu gì trong ngữ cảnh chứ không đổ lỗi cho mô hình. Chính trực giác này đã làm cho các cấp 5 đến 8 trở nên khả thi.

Cấp 5: MCP và kỹ năng

Cấp 3 và 4 giải quyết vấn đề ngữ cảnh. Cấp 5 giải quyết vấn đề năng lực. MCP và kỹ năng tùy chỉnh giúp LLM của bạn truy cập vào cơ sở dữ liệu, API, pipeline CI, hệ thống thiết kế, cùng các công cụ như Playwright để kiểm thử trình duyệt, Slack để thông báo. Mô hình không còn chỉ suy nghĩ về kho mã của bạn nữa — giờ đây nó có thể thao tác trực tiếp.

Có nhiều tài liệu chất lượng về MCP và kỹ năng rồi, tôi không cần nhắc lại chúng là gì. Nhưng ví dụ tôi dùng chúng: nhóm của tôi chia sẻ một kỹ năng xem xét PR, cùng nhau cải tiến (hiện vẫn đang phát triển), nó sẽ dựa vào tính chất của PR để kích hoạt các AI con phù hợp. Một AI kiểm tra an toàn tích hợp với cơ sở dữ liệu, một AI phân tích độ phức tạp để đánh dấu dư thừa hoặc quá mức, AI khác kiểm tra độ lành mạnh của prompt để đảm bảo tuân thủ chuẩn mực của nhóm. Nó còn chạy linter và Ruff.

Tại sao lại đầu tư nhiều vào kỹ năng xem xét? Bởi khi AI bắt đầu tạo ra hàng loạt PR, việc kiểm tra thủ công trở thành điểm nghẽn chứ không còn là rào cản chất lượng nữa. Latent Space đưa ra luận điểm thuyết phục: các quy trình kiểm tra mã truyền thống đã chết. Thay vào đó là kiểm tra tự động, nhất quán, dựa trên kỹ năng.

Về MCP, tôi dùng Braintrust MCP để LLM có thể truy vấn nhật ký đánh giá và tự sửa đổi. Tôi dùng DeepWiki MCP để AI có thể truy cập tài liệu của bất kỳ kho mã nguồn mở nào mà không cần phải đưa thủ công tài liệu vào ngữ cảnh.

Khi nhiều người trong nhóm bắt đầu tự viết các kỹ năng cùng loại, thì đáng để hợp nhất thành một registry chung. Block (gửi lời chia buồn) có bài viết rất hay: họ xây dựng một thị trường kỹ năng nội bộ, có hơn 100 kỹ năng, và thiết kế các gói kỹ năng phù hợp cho từng vai trò, nhóm. Kỹ năng và mã đều được đối xử như nhau: pull request, xem xét, lịch sử phiên bản.

Một xu hướng đáng chú ý nữa là: LLM ngày càng sử dụng nhiều công cụ CLI thay vì MCP (và dường như mỗi công ty đều sắp ra mắt riêng của mình: CLI Google Workspace, Braintrust cũng sắp ra). Lý do là hiệu quả token. Máy chủ MCP mỗi vòng đều đưa toàn bộ định nghĩa công cụ vào ngữ cảnh, dù AI có dùng hay không. Trong khi đó, CLI: AI chạy lệnh cụ thể, chỉ phần liên quan mới vào ngữ cảnh. Tôi thường dùng agent-browser thay vì Playwright MCP, chính vì lý do này.

Trước khi tiếp tục, hãy tạm dừng. Từ cấp 3 đến 5 là nền tảng cho mọi thứ tiếp theo. LLM có khả năng xuất sắc trong một số việc, lại kém trong việc khác, bạn cần phát triển trực giác về các giới hạn này, rồi mới có thể xây dựng thêm tự động hóa. Nếu ngữ cảnh của bạn ồn ào, prompt không đầy đủ hoặc không chính xác, mô tả công cụ mơ hồ, thì từ cấp 6 đến 8 sẽ chỉ làm các vấn đề đó trầm trọng hơn.

Cấp 6: Kỹ thuật Harness (Harness Engineering)

Chuyến bay thật sự bắt đầu cất cánh.

Kỹ thuật ngữ cảnh tập trung vào những gì mô hình nhìn thấy. Còn Harness Engineering (Kỹ thuật khai thác hệ thống) tập trung vào xây dựng toàn bộ môi trường — công cụ, hạ tầng và vòng phản hồi — để AI có thể hoạt động đáng tin cậy mà không cần can thiệp của bạn. Không chỉ cung cấp cho AI một trình chỉnh sửa, mà còn là một vòng phản hồi hoàn chỉnh.

Hệ thống công cụ Codex của OpenAI — một hệ thống quan sát toàn diện cho phép AI truy vấn, liên kết và suy luận về chính kết quả của mình (nguồn: OpenAI)

Nhóm Codex của OpenAI đã tích hợp Chrome DevTools, các công cụ quan sát và điều hướng trình duyệt vào runtime của AI, cho phép nó chụp màn hình, điều khiển UI, truy vấn nhật ký, xác nhận các sửa chữa của chính nó. Chỉ cần một prompt, AI có thể tái tạo lỗi, ghi video, thực hiện sửa chữa. Sau đó, nó kiểm tra bằng cách thao tác ứng dụng, gửi PR, phản hồi phản hồi của reviewer, hợp nhất — chỉ báo cho con người khi cần đánh giá. AI không chỉ viết mã, nó còn thấy được kết quả của mã, rồi tự cải tiến — giống như con người.

Nhóm của tôi làm về các AI chẩn đoán sự cố kỹ thuật qua thoại và chat, vì vậy tôi đã tạo ra một công cụ CLI gọi là converse, cho phép bất kỳ LLM nào cũng có thể trò chuyện với backend của chúng tôi, thực hiện các vòng hội thoại liên tục. Sau khi chỉnh sửa mã, LLM dùng converse để thử nghiệm trong hệ thống trực tuyến, rồi lặp lại. Đôi khi, vòng tự cải tiến này chạy liên tục vài giờ. Khi kết quả có thể xác minh, điều này đặc biệt mạnh mẽ: hội thoại phải theo quy trình này, hoặc trong các trường hợp đặc biệt, gọi các công cụ phù hợp (ví dụ như chuyển sang nhân viên hỗ trợ).

Điều cốt lõi hỗ trợ tất cả là cơ chế backpressure — cơ chế phản hồi tự động (hệ thống kiểu, kiểm thử, linter, hook pre-commit), giúp AI phát hiện và sửa lỗi mà không cần con người can thiệp. Nếu bạn muốn AI tự chủ, phải có backpressure, nếu không, bạn sẽ có một cỗ máy sản xuất rác. Điều này cũng mở rộng sang lĩnh vực an ninh. CTO của Vercel chỉ ra rằng, AI, mã do nó sinh ra và khóa API của bạn nên nằm trong các vùng tin cậy khác nhau, vì một cuộc tấn công tiêm lệnh trong nhật ký có thể khiến AI đánh cắp thông tin xác thực của bạn — nếu tất cả chia sẻ cùng một ngữ cảnh an toàn, thì nguy cơ này rất cao. Giới hạn an toàn chính là backpressure: chúng giới hạn AI làm gì khi mất kiểm soát, chứ không chỉ là những gì nó nên làm.

Hai nguyên tắc giúp làm rõ ý tưởng này:

Thiết kế cho năng suất chứ không phải hoàn hảo. Khi yêu cầu mọi lần gửi đều phải hoàn hảo, AI sẽ lặp đi lặp lại cùng một lỗi, che phủ lẫn nhau các sửa chữa. Cách tốt hơn là chấp nhận lỗi nhỏ không gây trở ngại, rồi làm kiểm tra cuối cùng trước khi phát hành. Chúng ta cũng làm như vậy với đồng nghiệp con người.

Ưu tiên hạn chế hơn chỉ thị. Các prompt từng bước (“làm A trước, rồi B, rồi C”) đang trở nên lỗi thời. Theo kinh nghiệm của tôi, định nghĩa rõ ràng các giới hạn hiệu quả hơn nhiều so với liệt kê chi tiết, vì AI sẽ chăm chăm vào danh sách đó, bỏ qua mọi thứ ngoài đó. Prompt tốt hơn là “Đây là kết quả tôi muốn, cứ làm liên tục cho đến khi vượt qua tất cả các bài kiểm tra này.”

Phần còn lại của kỹ thuật Harness là đảm bảo AI có thể tự do di chuyển trong kho mã mà không cần bạn hướng dẫn. Cách của OpenAI là giữ file AGENTS.md trong khoảng 100 dòng, làm mục lục liên kết đến các tài liệu cấu trúc khác, và đưa tính thời hạn của tài liệu vào quy trình CI, chứ không dựa vào các cập nhật tạm thời dễ lỗi thời.

Khi bạn đã xây dựng tất cả những điều này, một câu hỏi tự nhiên sẽ xuất hiện: nếu AI có thể tự xác nhận kết quả, tự di chuyển trong kho mã, và tự sửa lỗi mà không cần bạn, thì tại sao bạn còn phải ngồi đó?

Xin nhắc lại, đối với những người còn ở các cấp đầu, nội dung tiếp theo có thể nghe có vẻ viễn tưởng (nhưng không sao, cứ lưu lại, rồi xem lại sau).

Cấp 7: AI nền tảng (Background AI)

Chỉ trích: chế độ lập kế hoạch đang dần biến mất.

Người sáng lập Claude Code, Boris Cherny, hiện vẫn bắt đầu khoảng 80% nhiệm vụ theo chế độ lập kế hoạch. Nhưng theo từng thế hệ mô hình mới ra đời, tỷ lệ thành công sau lập kế hoạch một lần ngày càng tăng. Tôi nghĩ chúng ta đang tiến gần đến một điểm tới hạn: chế độ lập kế hoạch như một bước can thiệp nhân tạo độc lập sẽ dần biến mất. Không phải vì nó không quan trọng, mà vì mô hình đã đủ thông minh để tự lập kế hoạch. Nhưng điều kiện tiên quyết là bạn đã làm tốt các cấp 3 đến 6. Nếu ngữ cảnh của bạn sạch sẽ, các giới hạn rõ ràng, mô tả công cụ đầy đủ, vòng phản hồi khép kín, thì mô hình có thể tự lập kế hoạch đáng tin cậy mà không cần bạn kiểm tra. Nếu không, bạn vẫn phải theo sát kế hoạch.

Nói rõ hơn, lập kế hoạch như một thực hành chung sẽ không biến mất, chỉ thay đổi hình thái. Đối với người mới, chế độ lập kế hoạch vẫn là cách tiếp cận đúng (như đã đề cập ở cấp 1 và 2). Nhưng đối với các nhiệm vụ phức tạp cấp 7, “lập kế hoạch” không còn đơn thuần là viết một dàn ý từng bước nữa, mà là khám phá: dò tìm trong kho mã, thử nghiệm nguyên mẫu trong worktree, xác định phạm vi giải pháp. Và ngày càng nhiều, chính là các AI nền tảng sẽ giúp bạn thực hiện những khám phá này.

Điều này rất quan trọng vì chính nó mở khóa AI nền tảng. Nếu một AI có thể tạo ra kế hoạch đáng tin cậy và thực thi mà không cần bạn ký xác nhận, nó có thể chạy bất cứ khi nào bạn bận việc khác. Đây là bước chuyển đổi then chốt — từ “tôi mở nhiều tab cùng lúc” sang “có công việc tiến triển mà không cần tôi”.

Vòng Ralph là cách phổ biến để bắt đầu: một vòng lặp AI tự chủ, chạy lặp đi lặp lại CLI lập trình cho đến khi hoàn thành tất cả các mục trong PRD (bản yêu cầu sản phẩm), mỗi lần đều khởi động một instance mới với ngữ cảnh hoàn toàn mới. Theo kinh nghiệm của tôi, để chạy vòng Ralph tốt không dễ, bất kỳ mô tả không đầy đủ hoặc không chính xác nào trong PRD cuối cùng cũng sẽ phản tác dụng. Nó hơi quá “bỏ đi rồi không quản lý nữa”.

Bạn có thể chạy nhiều vòng Ralph cùng lúc, nhưng càng nhiều AI khởi động, bạn sẽ thấy thời gian dành cho gì? Phối hợp chúng, sắp xếp thứ tự công việc, kiểm tra đầu ra, thúc đẩy tiến độ. Bạn không còn viết mã nữa — bạn trở thành một quản lý trung tầng. Bạn cần một hệ thống điều phối AI để xử lý lịch trình, để tập trung vào ý định chứ không phải hậu cần.

Dispatch chạy song song 3 mô hình, khởi động 5 worker — hội thoại của bạn gọn nhẹ, AI làm việc

Gần đây tôi thường dùng công cụ Dispatch, là một kỹ năng Claude Code tôi tự xây, biến hội thoại của bạn thành trung tâm chỉ huy. Bạn giữ trong một hội thoại sạch, worker thực hiện công việc nặng trong các ngữ cảnh cách ly. Bộ điều phối chịu trách nhiệm lập kế hoạch, phân công và theo dõi, còn cửa sổ hội thoại chính của bạn dành để điều phối. Khi worker gặp vấn đề, nó sẽ đưa ra câu hỏi rõ ràng chứ không im lặng thất vọng.

Dispatch chạy tại chỗ, rất phù hợp cho các dự án phát triển nhanh, nơi bạn muốn phản hồi nhanh, dễ gỡ lỗi, không cần hạ tầng phức tạp. Inspect của Ramp là giải pháp bổ sung, dành cho các công việc dài hạn, tự chủ hơn: mỗi hội thoại AI đều chạy trong một VM sandbox trên đám mây, có môi trường phát triển đầy đủ. Một PM phát hiện lỗi UI, báo trong Slack, Inspect sẽ tiếp nhận và xử lý khi bạn tắt máy. Chi phí là phức tạp về vận hành (hạ tầng, snapshot, bảo mật), nhưng bạn có được quy mô và khả năng tái tạo mà AI nền tảng tại chỗ không thể sánh bằng. Tôi khuyên dùng cả hai (AI nền tảng tại chỗ và đám mây).

Trong cấp này, còn có một mô hình cực kỳ mạnh mẽ: dùng các mô hình khác nhau để làm các nhiệm vụ khác nhau. Đội ngũ kỹ thuật tốt nhất không phải là một nhóm các bản sao. Các thành viên có cách suy nghĩ khác nhau, nền tảng đào tạo khác nhau, điểm mạnh khác nhau. Tương tự, các mô hình LLM cũng đã qua huấn luyện hậu kỳ khác nhau, mang đặc điểm tính cách rõ rệt. Tôi thường phân Opus cho các nhiệm vụ thực thi, Gemini cho nghiên cứu khám phá, Codex cho kiểm duyệt, và tổng hợp kết quả tốt hơn nhiều so với làm việc riêng lẻ từng mô hình. Có thể xem như trí tuệ tập thể, nhưng ứng dụng vào mã nguồn.

Điều cực kỳ quan trọng là phải tách biệt người thực thi và người đánh giá. Tôi đã mắc sai lầm nhiều lần vì cùng một instance mô hình vừa làm, vừa tự đánh giá kết quả của chính nó, dẫn đến thành kiến. Nó sẽ bỏ qua vấn đề, báo rằng mọi thứ đã xong — trong khi thực tế chưa hẳn vậy. Không phải vì ác ý, mà vì lý do giống như bạn tự chấm bài thi của chính mình. Hãy để một instance khác hoặc một mô hình khác với prompt đánh giá riêng làm việc này. Chỉ số tín hiệu của bạn sẽ tăng đáng kể.

AI nền tảng còn mở ra cánh cửa cho tích hợp CI và AI. Khi AI có thể vận hành mà không cần người giám sát, bạn có thể kích hoạt chúng từ hạ tầng hiện có. Một robot tài liệu tự động cập nhật tài liệu sau mỗi lần hợp nhất, gửi PR cập nhật CLAUDE.md (chúng tôi đang dùng, tiết kiệm rất nhiều thời gian). Một robot kiểm tra an ninh quét PR và gửi sửa. Một robot quản lý phụ thuộc không chỉ đánh dấu vấn đề mà còn nâng cấp gói và chạy bộ kiểm thử. Ngữ cảnh tốt, quy tắc tích lũy liên tục, công cụ mạnh mẽ, vòng phản hồi tự động — tất cả đều vận hành tự chủ.

Cấp 8: Đội ngũ AI tự chủ

Chưa ai thực sự làm chủ cấp này, dù có một số đang hướng tới. Đây là biên giới hiện tại.

Trong cấp 7, bạn có một hệ thống điều phối LLM phân phối nhiệm vụ theo mô hình trung tâm phân tán tới các AI làm việc. Cấp 8 loại bỏ hoàn toàn giới hạn này. Các AI tự phối hợp trực tiếp — nhận nhiệm vụ, chia sẻ phát hiện, đánh dấu phụ thuộc, giải quyết xung đột — mà không cần qua một người điều phối trung tâm.

Chức năng Agent Teams của Claude Code là một ví dụ sớm: nhiều instance làm việc song song trên cùng một kho mã, đồng đội chạy trong các ngữ cảnh riêng, liên lạc trực tiếp với nhau. Anthropic đã dùng 16 AI song song để xây dựng một trình biên dịch Linux từ con số không. Cursor đã vận hành hàng trăm AI liên tục trong nhiều tuần, xây dựng trình duyệt từ con số không và chuyển kho mã từ Solid sang React.

Nhưng nhìn kỹ sẽ thấy vấn đề. Khi không có cấu trúc phân cấp, các AI trở nên e dè, quanh quẩn không tiến bộ. Anthropic phải liên tục phá vỡ các chức năng cũ để thêm pipeline CI chống lỗi hồi quy. Tất cả các nhóm thử nghiệm cấp này đều nói một điều: phối hợp đa AI là một bài toán rất khó, chưa ai tìm ra giải pháp tối ưu.

Thành thật mà nói, tôi không nghĩ mô hình đã đủ sẵn sàng cho mức độ tự chủ này của hầu hết nhiệm vụ. Dù chúng đủ thông minh, đối với các dự án lớn như biên dịch hoặc xây trình duyệt, chúng vẫn quá chậm, tiêu tốn token quá nhiều, về mặt kinh tế thì chưa khả thi (ấn tượng, nhưng còn xa mới trưởng thành). Đối với công việc hàng ngày của phần lớn chúng ta, cấp 7 mới là đòn bẩy thực sự. Tôi không ngạc nhiên nếu cấp 8 cuối cùng trở thành xu hướng chính, nhưng hiện tại tôi tập trung vào cấp 7 (trừ khi bạn là Cursor — vì đột phá chính là công việc của bạn).

Cấp ? (chưa đặt tên)

Vấn đề tất yếu của “tiếp theo là gì”.

Khi bạn đã thành thạo trong việc điều phối đội ngũ AI mà không gặp nhiều trở ngại, giao diện tương tác sẽ không còn giới hạn ở dạng văn bản nữa. Giao tiếp qua giọng nói (có thể là suy nghĩ qua suy nghĩ?) và tương tác với các AI lập trình — dạng hội thoại của Claude Code, chứ không chỉ là chuyển giọng thành văn bản — là bước tiếp theo tự nhiên. Nhìn vào ứng dụng của bạn, mô tả rõ ràng từng thay đổi rồi xem chúng diễn ra trước mắt.

Có một nhóm đang theo đuổi việc tạo ra các lần sinh ra hoàn hảo một lần: nói ra điều bạn muốn, AI sẽ hoàn thiện một cách hoàn hảo ngay lần đầu. Vấn đề là giả định này là chúng ta biết chính xác mình muốn gì. Nhưng thực tế, chúng ta không biết. Chúng ta luôn không biết. Phát triển phần mềm luôn là quá trình lặp đi lặp lại, và tôi nghĩ nó sẽ luôn như vậy. Chỉ là nó sẽ trở nên dễ dàng hơn nhiều, vượt xa việc giao tiếp thuần túy qua văn bản, và nhanh hơn nhiều.

Vậy bạn đang ở cấp nào? Bạn làm gì để tiến tới cấp tiếp theo?