Agentic Coding là gì?

Bạn gõ một prompt, đọc câu trả lời, sao chép những phần hay vào trình soạn thảo, sửa lại những chỗ mô hình làm sai rồi tự mình chạy kiểm thử. Vòng lặp đó giúp bạn viết code nhanh hơn. Nhưng nó không thay đổi việc ai là người làm. Bạn vẫn là người ôm trọn công việc trong đầu và đẩy nó tiến lên qua từng lần dán.

Lập trình agentic là điểm mà điều đó thay đổi. Thay vì ra prompt để lấy một câu trả lời rồi dán vào, bạn giao một đơn vị công việc và nhận về kết quả đã được nghiên cứu, thực thi, kiểm thử và báo cáo sẵn. Công việc của lập trình viên chuyển từ gõ từng dòng code sang định hướng, cấp quyền và chấp nhận hay từ chối những gì được trả về. Hướng dẫn này định nghĩa lập trình agentic cho các đội dev đang làm việc, dẫn bạn đi qua thang trưởng thành từ trợ lý chat đến Crew được điều phối, và vạch ra ranh giới mà sự chuyển dịch này phụ thuộc vào: con người ở lại ở đâu.

Chúng tôi sẽ dùng Sharkly làm quy trình tham chiếu xuyên suốt bài viết, bởi phần khó của lập trình agentic không nằm ở việc Agent viết code. Mà nằm ở việc điều phối nhiều lượt chạy, giữ ngữ cảnh ở một nơi chia sẻ chung, và quyết định cái gì thực sự được phát hành. Sharkly là nền tảng chỉ huy và quản lý Agent tất-cả-trong-một: nó bổ sung lớp task, Computer, ngữ cảnh, kiểm soát và review dùng chung quanh những công cụ lập trình mà nhóm bạn đang dùng. Chính lớp đó biến “một agent viết ra vài dòng code” thành lập trình agentic mà cả nhóm có thể tin tưởng.

TL;DR: lập trình agentic là gì?

Lập trình agentic là một quy trình phát triển phần mềm trong đó bạn giao một đơn vị công việc đã được giới hạn phạm vi cho một Agent lập trình AI; Agent này nghiên cứu codebase, thực hiện thay đổi, chạy kiểm thử và báo cáo lại kèm bằng chứng, thay vì chỉ trả lời một prompt đơn lẻ. Nhà phát triển chuyển từ người viết sang người chỉ đạo: bạn định hướng, cấp quyền và chấp nhận kết quả. Quá trình này trưởng thành qua bốn giai đoạn: từ trợ lý chat tự động hoàn thành code, đến một Agent làm việc, đến nhiều Agent chạy song song, rồi đến một Crew được điều phối bởi một Agent trưởng nhóm.

Rào cản của lối prompt rồi dán

Lập trình AI dựa trên chat đã chạm trần mà hầu hết các nhóm đều cảm nhận được nhưng ít khi gọi tên. Bạn chỉ có thể hỏi một câu tại một thời điểm. Mọi câu trả lời đều đổ về tay bạn, nơi bạn phải đọc, đánh giá, ghép nó vào code thật và chạy các bước kiểm tra. Mô hình gõ code; còn bạn làm phần suy nghĩ, tích hợp và xác minh. Nhân lên trong cả một sprint, trợ lý này rất nhanh ở bước nhỏ và vô dụng ở bước lớn.

Nỗi đau này lộ ra ở ba chỗ dễ đoán. Thứ nhất, ngữ cảnh nằm trong đầu bạn và trong lịch sử chat riêng tư, nên đồng đội không thể thấy vì sao agent đưa ra lựa chọn đó hay nó đã thử những gì. Thứ hai, năng suất bị chặn ở mức chú ý của một người: năm terminal mở cùng lúc, năm phiên agent làm dở dang, và không có bản ghi chung nào cho biết phiên nào thực sự xong. Thứ ba, không có gì chịu trách nhiệm. Lý luận của agent, diff của nó và kết quả kiểm thử nằm rải rác trong một cửa sổ chat mà không ai xem lại trước khi code được merge.

Lập trình agentic giải quyết cả ba vấn đề bằng cách thay đổi đơn vị tương tác. Bạn ngừng trao đổi tin nhắn và bắt đầu giao việc. Và một khi công việc là đơn vị, nó cần một nơi để tồn tại, một người chịu trách nhiệm, và một cổng kiểm soát trước khi phát hành. Đó mới chính là quy trình mà bài viết này thực sự bàn tới, và cũng là lý do một định nghĩa dừng ở mức “agent tự viết code” là chưa chạm đúng vấn đề của các nhóm. Nếu bạn muốn tìm hiểu khía cạnh điều phối của cùng câu chuyện này, bài hướng dẫn về điều phối AI agent là bài trụ cột song hành với bài này.

Một định nghĩa thực tế về lập trình agentic

Đây là phiên bản một câu đáng để trích dẫn: lập trình agentic là một quy trình phát triển trong đó một người giao một Task đã được giới hạn phạm vi cho một Agent lập trình AI; Agent này nghiên cứu, thực thi, kiểm thử và báo cáo kết quả, còn người đó vẫn giữ vai trò định hướng, cấp quyền và nghiệm thu cuối cùng.

Hai nửa của câu đó chứa trọn ý tưởng. Phần của Agent là một vòng lặp các động từ: nghiên cứu codebase và yêu cầu, thực thi thay đổi, chạy kiểm thử và build, rồi báo cáo lại bằng một bản tóm tắt cùng bằng chứng có thể kiểm tra được. Phần của con người là một vòng lặp ngắn hơn: định hướng, cấp quyền, chấp nhận hoặc từ chối. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, cấp quyền và chấp nhận kết quả. Tự động hóa dừng lại ở đúng chỗ cần đến phán đoán của nhóm.

Cũng nên nói rõ lập trình agentic không phải là gì. Nó không phải việc mô hình thay thế lập trình viên, và cũng không phải kiểu “để AI chạy không giám sát rồi cầu may”. Một Agent lập trình không có người đặt phạm vi và nghiệm thu kết quả thì không phải lập trình agentic; đó là một quy trình vô chủ. Sự chuyển dịch này không nhằm loại bỏ con người. Nó nhằm đưa con người từ giữa từng thao tác gõ phím ra hai đầu mấu chốt: xây cái gì và liệu nó đã đủ tốt để phát hành chưa.

Sự khác biệt đó cũng tách lập trình agentic khỏi “vibe coding”, nơi bạn chấp nhận code do máy sinh ra mà không đọc. Vibe coding loại bỏ con người ở đầu nghiệm thu. Lập trình agentic giữ lại đầu đó và tự động hóa phần ở giữa. Một bên là đường tắt; bên kia là quy trình bạn có thể vận hành cả một nhóm dựa trên nó.

Thang trưởng thành: bốn giai đoạn của lập trình agentic

Các nhóm không nhảy thẳng tới các Agent tự chủ. Họ leo từng bậc. Gọi tên từng bậc giúp thấy rõ nhóm bạn đang ở đâu và bước tiếp theo một cách trung thực là gì.

Giai đoạn 1: trợ lý chat

Mô hình hoàn thành dòng code, trả lời câu hỏi và phác thảo hàm ngay trong trình soạn thảo của bạn. Bạn điều khiển từng bước. Không có Task lâu dài, không có người sở hữu, không có báo cáo; giá trị nằm ở việc gõ nhanh hơn và tra cứu nhanh. Đây là nơi hầu hết lập trình viên bắt đầu, và với một sửa lỗi một dòng thì nó vẫn là công cụ phù hợp. Dùng Agent ở đây là thừa sức.

Giai đoạn 2: một Agent đơn lẻ

Bạn giao một Task đã giới hạn phạm vi cho một Agent và để nó chạy trọn vòng lặp: đọc các file liên quan, thực hiện thay đổi, chạy các bước kiểm tra, rồi quay lại với một diff và một bản tóm tắt. Agent làm việc dựa trên trạng thái hiện tại của code, chứ không từ một prompt trống. Đây là bậc thực sự đầu tiên của lập trình agentic, vì lần đầu tiên đơn vị công việc là công việc chứ không phải tin nhắn. Một điểm khởi đầu tốt là một thay đổi nhỏ, ít rủi ro; bài hướng dẫn của chúng tôi về cách giao task đầu tiên cho một Agent lập trình AI bàn đúng bậc này.

Giai đoạn 3: nhiều Agent chạy song song

Giờ bạn chạy nhiều Agent cùng lúc, mỗi Agent một Task riêng, mỗi Agent trong một worktree tách biệt để chúng không đụng nhau. Việc frontend, một endpoint backend, một bản sửa lỗi và một loạt test coverage đều có thể tiến triển đồng thời. Năng suất không còn bị giới hạn bởi sự chú ý của một người. Cái khó nằm ở điều phối: năm Agent trong năm terminal thì nhanh hơn nhưng cũng hỗn loạn, trừ khi có thứ gì đó giữ mục tiêu, diff và kết quả ở cùng một chỗ. Đây là bậc mà các nhóm vượt qua tmux và các script tùy hứng; xem cách chạy nhiều Agent Claude Code song song để biết phần cơ chế.

Giai đoạn 4: Crew được điều phối

Ở bậc cao nhất, một Agent trưởng nhóm diễn giải một mục tiêu lớn hơn, chia nó thành các Task, huy động các Agent thành viên khác và trả kết quả tổng hợp của họ về một Task duy nhất. Crew là một nhóm gồm Người và Agent có thể tái sử dụng, được điều phối bởi một Agent trưởng nhóm. Bạn không còn giao từng thay đổi riêng lẻ nữa; bạn giao cả kết quả đầu ra. Điều này rất mạnh, và cũng chính ở bậc này mà cám dỗ bỏ qua bước nghiệm thu của con người là lớn nhất, nên cổng nghiệm thu ở đây lại càng quan trọng.

Dùng một Agent đơn lẻ khi công việc nhỏ và đã rõ ràng. Dùng Crew khi trưởng nhóm cần diễn giải mục tiêu, huy động các Agent thành viên khác và gom kết quả của họ về một Task. Leo lên một bậc quá sớm, khi chưa có đủ khả năng quan sát để review việc các Agent đã làm, là cách phổ biến nhất khiến các nhóm bị “bỏng”.

Vòng lặp của Agent: nghiên cứu, thực thi, kiểm thử, báo cáo

Vòng lặp động từ này đáng để ta dừng lại kỹ, vì nó là thứ phân biệt một Agent với một công cụ tự động hoàn thành code hào nhoáng.

Nghiên cứu. Trước khi chạm vào code, một Agent đủ năng lực sẽ đọc ngữ cảnh sản phẩm, codebase, các Task liên quan trong quá khứ và các quy tắc của nhóm, rồi hoàn thiện phạm vi cùng tiêu chí nghiệm thu. Đây là bước mà chat bỏ qua hoàn toàn. Một prompt bắt đầu từ con số không; một Agent bắt đầu từ repository của bạn ở đúng trạng thái hiện tại.

Thực thi. Agent thực hiện thay đổi trong một worktree tách biệt, nhờ đó một lượt chạy dở dang không bao giờ làm bẩn nhánh chính hay công việc của Agent khác. Git worktree chính là cơ chế nhàm chán nhưng đã được chứng minh nằm bên dưới; chúng cho phép nhiều nhánh cùng tồn tại như những thư mục làm việc riêng biệt.

Kiểm thử. Agent chạy typecheck, bộ test và build, rồi đính kèm kết quả. Đây là khác biệt giữa “đây là vài dòng code” và “thay đổi này đã pass”. Một báo cáo không có bằng chứng chỉ là một lời tuyên bố suông.

Báo cáo. Quá trình thực thi, các điểm tắc nghẽn, kết quả và thảo luận tiếp theo đều quay về dòng thời gian của Task, chứ không phải một terminal riêng tư. Bản tóm tắt thay đổi, kết quả xác minh và các giới hạn đã biết nằm ở một nơi mà người review có thể đọc. Công việc luôn quay về Task.

Động từ cuối cùng đó là trung tâm thầm lặng của toàn bộ quy trình. Khi kết quả quay về một Task chung thay vì biến mất trong cửa sổ chat, lập trình agentic không còn là một mẹo làm việc cá nhân mà trở thành thứ cả nhóm có thể nhìn thấy, review và tin tưởng.

Con người ở lại ở đâu: thỏa thuận nghiệm thu

Câu quan trọng nhất trong lập trình agentic nói về những phần bạn không tự động hóa. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, cấp quyền và chấp nhận kết quả. Hãy để việc nghiệm thu cuối cùng và quyết định phát hành cho con người.

Chia nhỏ điều đó thành ba chỗ con người ở lại:

• Định hướng. Một người mô tả nhu cầu và đặt ra mục tiêu. Agent có thể định hình phạm vi và viết tiêu chí nghiệm thu, nhưng ý định ban đầu xuất phát từ bạn. Định hướng rác sẽ tạo ra những dòng code đầy tự tin, được kiểm thử kỹ lưỡng, nhưng giải sai bài toán.
• Quyền hạn. Agent hành động trong giới hạn bạn cấp: được chạm vào những repository nào, chạy trên Computer nào, có được mở pull request hay phải dừng trước bước merge. Quyền hạn là thứ được nêu rõ, không phải mặc định.
• Nghiệm thu. Một người review bản tóm tắt thay đổi cùng bằng chứng, rồi chấp nhận, yêu cầu chỉnh sửa, hoặc quyết định bước merge và phát hành. Cổng này không bao giờ chuyển sang máy, dù Agent có giỏi đến đâu.

Đây là thỏa thuận khiến lập trình agentic đủ an toàn để vận hành ở quy mô nhóm. Tự động hóa dừng lại ở đúng chỗ cần đến phán đoán của nhóm và trả về một sản phẩm bàn giao với ngữ cảnh đầy đủ cùng bằng chứng có thể kiểm tra. Lưu ý rằng thỏa thuận này không hề làm chậm các Agent giỏi. Nó cho đầu ra của họ một nơi để được đánh giá. Một Agent tạo ra diff sạch, test xanh và bản tóm tắt rõ ràng sẽ khiến việc nghiệm thu diễn ra nhanh chóng. Cổng kiểm soát không phải là lực cản; nó là điểm mà niềm tin được tạo dựng hoặc từ chối dựa trên bằng chứng.

Lập trình agentic như một quy trình làm việc nhóm với Sharkly

Mọi điều ở trên đều vận hành được với một lập trình viên và một Agent. Nó sẽ sụp đổ với một nhóm, trừ khi công việc, ngữ cảnh và việc review nằm ở một nơi chia sẻ chung. Khoảng trống đó chính là thứ Sharkly lấp đầy.

Sharkly không thay thế Claude Code, Codex hay các công cụ thực thi khác. Nó bổ sung lớp task, Computer, ngữ cảnh, kiểm soát và review dùng chung quanh những công cụ mà nhóm bạn đã dùng. Claude Code, Codex và các công cụ tương tự đảm nhiệm việc thực thi. Sharkly quản lý việc giao việc ở cấp nhóm, các Computer được kết nối, ngữ cảnh Task, tiến độ, điểm tắc nghẽn, kết quả và hoạt động review của con người xuyên suốt các công cụ đó. Bạn giữ nguyên các gói đăng ký mô hình và API key mà nhóm đã cấu hình; Sharkly làm cho các lượt chạy trở nên có thể giao việc và truy vết được.

Đây là cách thang bốn bậc ánh xạ vào sản phẩm:

• Task là đơn vị công việc chính trong Sharkly, và là nơi lưu giữ yêu cầu, diff của Agent, kết quả kiểm thử và phần review. Đây chính là bản ghi chung mà chat chưa bao giờ có.
• Agent định nghĩa cách xử lý công việc; Computer cung cấp máy chủ và tài nguyên cục bộ; Runtime thực hiện phiên agent thực tế; còn Task vẫn là bản ghi chung cho cả nhóm. Mỗi vai trò có một nhiệm vụ.
• Chạy nhiều Agent song song là an toàn vì mỗi Agent làm việc trong một worktree tách biệt trên một Computer được kết nối, nên các lượt chạy đồng thời không giẫm lên nhau.
• Crew đảm nhiệm bậc được điều phối: một nhóm gồm Người và Agent có thể tái sử dụng, được điều phối bởi một Agent trưởng nhóm, với kết quả tổng hợp được trả về một Task duy nhất.

Quy trình phát triển sản phẩm chính thức được đọc như bốn giai đoạn phản chiếu chính xác vòng lặp của agent và thỏa thuận nghiệm thu: một người mô tả nhu cầu và một Agent nghiên cứu rồi tạo ra các Task có thể thực thi; các Agent nhận những Task sẵn sàng và phát triển song song; Agent chạy typecheck, test và build, đính kèm bằng chứng, rồi một người chấp nhận hoặc yêu cầu chỉnh sửa; cả nhóm theo dõi tình trạng hoàn thành, quyền sở hữu, các phụ thuộc và điểm tắc nghẽn trong kế hoạch chung. Đòn bẩy của cả nhóm không đến từ việc mở thêm nhiều cửa sổ chat AI. Nó đến từ việc chia sẻ vai trò, quy tắc, ngữ cảnh và quy trình để một thiết lập tốt trở thành năng lực phát triển mà cả nhóm tái sử dụng được.

Lợi ích thực tế là một hệ thống nơi ngữ cảnh, tiến độ, điểm tắc nghẽn, kết quả và hoạt động review của con người luôn hiển thị — hãy yêu cầu và giao cho nó một Task ít rủi ro.

Những sai lầm thường gặp khi áp dụng lập trình agentic

Một vài kiểu thất bại cứ lặp đi lặp lại. Tránh được chúng thì quá trình khởi động sẽ suôn sẻ hơn nhiều.

1. Leo lên Crew trước khi có thể review nổi một Agent. Nếu bạn không thể nhìn rõ và nghiệm thu sạch sẽ công việc của một Agent, thì năm Agent sẽ nhấn chìm bạn. Hãy thành thạo Giai đoạn 2 trước Giai đoạn 4.
2. Giao việc với định hướng mơ hồ. “Cải thiện luồng thanh toán” không phải là một Task. Hãy giới hạn phạm vi, hoặc để Agent phác thảo phạm vi và tiêu chí nghiệm thu rồi xác nhận trước khi nó chạy.
3. Bỏ qua cổng nghiệm thu vì áp lực deadline. Khoảnh khắc bạn merge đầu ra của agent mà không đọc chỉ vì test đã pass, bạn đã đánh đổi lập trình agentic lấy vibe coding. Test pass là điều kiện cần, chứ chưa đủ.
4. Chạy nhiều Agent song song mà không tách biệt. Các Agent đồng thời dùng chung một thư mục làm việc sẽ làm hỏng thay đổi của nhau. Worktree tách biệt cho từng Agent không phải là tùy chọn ở Giai đoạn 3.
5. Để ngữ cảnh sống trong các cuộc chat riêng tư. Nếu lý do đằng sau một thay đổi không nằm trong Task, người tiếp theo không thể review hay phát triển tiếp dựa trên nó. Hãy giữ bản ghi ở dạng chia sẻ chung.

Lập trình agentic so với các thuật ngữ liên quan

Từ vựng quanh lĩnh vực này khá nhiễu loạn. Đây là cách lập trình agentic đứng cạnh những thuật ngữ mà nó hay bị nhầm với.

Lập trình agentic là quy trình. Điều phối là thứ bạn cần khi đã có nhiều hơn một Agent vận hành quy trình đó. Chúng là hai trụ cột của cùng một hệ thống, nên các nhóm áp dụng cái này thường sẽ muốn cái kia ngay sau đó.

Các tình huống thực tế

Endpoint backend gấp vì deadline. Một lập trình viên mô tả một endpoint mới, các đầu vào và tiêu chí nghiệm thu của nó thành một Task. Một Agent nghiên cứu các mẫu route hiện có, viết handler cùng test trong một worktree tách biệt, chạy bộ test và trả về một diff với các bước kiểm tra xanh. Lập trình viên review rồi merge. Thời gian làm việc trực tiếp: một tin nhắn mô tả phạm vi và một lần review.

Chiến dịch dập bug song song. Một tech lead tạo sáu Task sửa bug không liên quan trước giờ standup. Sáu Agent nhận chúng, mỗi Agent trên worktree và Computer riêng. Đến giữa buổi sáng, các Task đã mang sáu diff kèm bằng chứng kiểm thử, sẵn sàng để review. Sự chú ý của một người không còn giới hạn năng suất của sáu bản sửa lỗi nữa.

Cùng làm việc với một Crew. Một mục tiêu lớn hơn, ví dụ một trang cài đặt gồm phần backend, frontend và migration, sẽ được giao cho một Crew. Agent trưởng nhóm chia nó thành các Task, huy động các Agent thành viên và trả kết quả tổng hợp về một Task để có một quyết định nghiệm thu duy nhất. Người quản lý nhìn thấy quyền sở hữu, các phụ thuộc và điểm tắc nghẽn trong Sprint chung suốt quá trình.

Kết luận

Lập trình agentic không phải là một công cụ tự động hoàn thành code thông minh hơn. Đó là sự thay đổi đơn vị công việc, từ prompt bạn dán sang Task bạn giao, cùng một thay đổi tương ứng trong vai trò của bạn, từ người viết sang người chỉ đạo. Định nghĩa đáng nhớ là một định nghĩa đơn giản:

• Agent nghiên cứu, thực thi, kiểm thử và báo cáo; con người định hướng, cấp quyền và nghiệm thu.
• Nó trưởng thành qua bốn bậc: trợ lý chat, một Agent, nhiều Agent song song, Crew được điều phối.
• Cổng nghiệm thu không bao giờ chuyển sang máy, dù Agent có năng lực đến đâu.
• Công việc song song cần sự tách biệt; công việc nhóm cần một Task chung để kết quả quay về.
• Phần khó là điều phối và review, và đó chính là lớp mà Sharkly bổ sung quanh những công cụ lập trình bạn đang dùng.

Hãy bắt đầu ở bậc thấp nhất còn hữu ích. Tải Sharkly, kết nối một Computer, tạo một Agent và giao cho nó một việc nhỏ nhặt, tẻ nhạt. Tự bạn nghiệm thu kết quả. Chính vòng lặp đó, chỉ cần chạy một lần, sẽ dạy bạn nhiều về lập trình agentic hơn mọi định nghĩa, kể cả định nghĩa này.

Câu hỏi thường gặp

Nói một cách đơn giản thì lập trình agentic là gì? Đó là cách xây dựng phần mềm trong đó bạn giao một phần công việc đã giới hạn phạm vi cho một Agent lập trình AI; Agent này nghiên cứu codebase của bạn, thực hiện thay đổi, chạy kiểm thử và báo cáo lại kèm bằng chứng, thay vì trao đổi từng tin nhắn một trong khung chat. Bạn vẫn là người quyết định xây cái gì và liệu kết quả đã đủ tốt để phát hành chưa.

Lập trình agentic khác gì so với dùng ChatGPT hay Copilot để viết code? Trợ lý chat và công cụ tự động hoàn thành code trả lời một prompt rồi giao kết quả lại cho bạn để tích hợp và xác minh. Một Agent đảm nhận cả một Task xuyên suốt từ nghiên cứu, thực thi, kiểm thử đến báo cáo kết quả. Đơn vị thay đổi từ một tin nhắn thành một phần công việc, và Agent bắt đầu từ repository thực tế của bạn chứ không phải từ một ô trống.

Lập trình agentic có giống vibe coding không? Không. Vibe coding nghĩa là chấp nhận code do máy sinh ra mà không đọc, tức là loại con người khỏi bước nghiệm thu. Lập trình agentic giữ chắc bước nghiệm thu ở con người và chỉ tự động hóa phần ở giữa: nghiên cứu, thực thi và kiểm thử. Một bên là đường tắt; bên kia là quy trình có thể review.

Lập trình agentic có thay thế lập trình viên không? Không. Nó đưa lập trình viên từ việc gõ từng dòng code sang định hướng, cấp quyền và nghiệm thu kết quả. Agent nghiên cứu, thực thi, kiểm thử và báo cáo; con người quyết định xây cái gì và liệu nó có được phát hành. Việc nghiệm thu cuối cùng và phát hành vẫn thuộc về con người.

Tôi cần những công cụ gì để bắt đầu lập trình agentic? Một công cụ lập trình AI có thể chạy task (Claude Code, Codex và những công cụ tương tự), cùng một lớp để giao việc, giữ ngữ cảnh chung và review kết quả trong cả nhóm. Sharkly chính là lớp đó; nó chạy bên trên các công cụ thực thi và gói đăng ký bạn đã có. Xem Sharkly là gì để có cái nhìn tổng quan.

Làm sao để các nhóm chạy nhiều Agent lập trình cùng lúc mà không hỗn loạn? Mỗi Agent làm việc trên Task riêng của nó trong một worktree tách biệt, và mọi kết quả đều quay về một Task chung nơi con người có thể review. Sự kết hợp đó — tách biệt khi thực thi cộng với một bản ghi chung để review — là thứ giữ cho các lượt chạy song song không đụng nhau. Bài hướng dẫn của chúng tôi về chạy nhiều Agent Claude Code song song sẽ trình bày phần thiết lập.

Con người ở lại ở đâu trong một quy trình lập trình agentic? Ở ba điểm: định hướng (xây cái gì), quyền hạn (Agent được phép chạm vào cái gì) và nghiệm thu (kết quả có được phát hành hay không). Mọi thứ ở giữa những điểm đó đều có thể tự động hóa; ba điểm đó vẫn thuộc về con người.