Lời Thú Nhận Từ Một Tech Lead

Tôi có một điều muốn thú nhận. Ba tháng qua, tôi đã điều hành một đội phần mềm mà hầu hết các thành viên trong đó… không tồn tại.

Để tôi giải thích. Tên tôi là Thuận Lương. Tôi là một Tech Lead đang làm việc tại Việt Nam, và tôi đã dành phần lớn năm qua để pair programming cùng Claude — AI model của Anthropic — xây dựng đủ thứ từ portfolio site cho đến production API. Tôi đã viết về trải nghiệm đó trong bài trước: Vibe Coding with Claude: From Idea to Production. Trong bài đó, tôi mô tả điều gì xảy ra khi một developer và một AI cùng làm việc với nhau.

Kết quả rất ấn tượng. Đáng ngạc nhiên là vậy. Một AI pair programmer duy nhất đã giúp tôi ship tính năng trong vài giờ thay vì vài ngày. Nhưng nó cũng phơi bày ra một vấn đề cốt lõi mà dù có prompt khéo léo đến đâu cũng không giải quyết được:

Một AI assistant, dù giỏi đến mấy, vẫn chỉ là một bộ não làm một việc tại một thời điểm.

Khi tôi đang xây dựng một tính năng cùng Claude, không có ai viết test. Không có ai review kiến trúc. Không có ai kiểm tra xem deployment pipeline có xử lý được các thay đổi mới không. Không có ai cập nhật project board. Không có ai nói chuyện với khách hàng để xem tính năng này có phải thứ cần xây dựng hay không.

Tôi chính là cả đội. Và tôi chỉ là một người.

Nhận ra điều này, tôi đã bị cuốn vào một cuộc hành trình đã ngốn hết ba tháng buổi tối và cuối tuần của tôi. Điều gì xảy ra nếu tôi không cần phải là cả một đội nữa? Điều gì xảy ra nếu tôi có thể tự xây dựng chính cái đội đó?

Không phải thuê một đội. Không phải outsource cho một đội. Mà xây dựng một đội — từ các AI agent, mỗi agent chuyên biệt một vai trò cụ thể, mỗi agent có khả năng tạo ra các artifact thực sự, mỗi agent có thể giao tiếp với những agent khác và bàn giao công việc y hệt như các thành viên nhân sự trong team thực tế.

Đây là câu chuyện về hành trình đó. Đây là Phần 1 trong một series 12 phần, nơi tôi sẽ xây dựng từ đầu một đội phát triển phần mềm multi-agent hoàn chỉnh và hoạt động thực sự. Đến cuối series, bạn sẽ có một hệ thống hoạt động được, nơi bạn có thể đưa vào một yêu cầu của khách hàng và theo dõi nó chạy qua phân tích của Product Owner, viết user story của Business Analyst, tạo test case của QA, thiết kế Technical Architecture, triển khai của Senior Software Engineer, review của Tech Lead, deploy của DevOps, và điều phối của Project Manager — tất cả tự động, tất cả tạo ra artifact thực sự, tất cả kết nối với nhau.

Hãy để tôi bắt đầu bằng lý do tại sao điều này quan trọng.

---

Vấn Đề: Bạn Chính Là Nút Cổ Chai

Cái Bẫy Của Developer Đơn Lẻ

Đây là một kịch bản tôi biết bạn đã từng trải qua, vì tôi đã trải qua nó hàng chục lần.

Bạn là một solo developer — hoặc có thể là một team lead nhỏ với một hoặc hai junior. Bạn có một dự án khách hàng. Khách hàng muốn một ứng dụng web với authentication, một dashboard, CRUD operations cho ba hoặc bốn entities, file upload, email notification, và “chỉ một admin panel đơn giản thôi.” Họ muốn có trong sáu tuần. Ngân sách chỉ đủ cho một senior developer. Là bạn.

Vậy là bạn bắt đầu xây dựng. Và ngay lập tức, bạn phải context-switch liên tục giữa:

• Thu thập yêu cầu (Cái “admin panel đơn giản” đó nghĩa là gì chính xác?)
• Viết user story (Để có thể ước lượng và theo dõi tiến độ)
• Thiết kế kiến trúc (Monolith hay microservices? Database nào? Auth provider nào?)
• Viết code thực sự (Cuối cùng, phần bạn được thuê để làm)
• Viết test (Bạn có viết test không, đúng không?)
• Cài đặt CI/CD (Vì deploy thủ công là dành cho những người ghét ngủ)
• Review code của chính mình (Rubber duck debugging, nhưng còn buồn hơn)
• Quản lý timeline dự án (Khách hàng muốn cập nhật tình hình mỗi thứ Sáu)
• Deploy và monitoring (Vì server sẽ crash lúc 2 giờ sáng ngày thứ Bảy)

Mỗi cái trong số này là một vai trò toàn thời gian hợp lý trong một đội phần mềm đúng nghĩa. Product Owner. Business Analyst. Technical Architect. Senior Software Engineer. QA Engineer. DevOps Engineer. Tech Lead. Project Manager.

Bạn đang làm cả tám vai. Không phải vì bạn giỏi đến vậy — mà vì bạn không có lựa chọn nào khác.

Cái Giá Của Thời Gian

Đây là điều mọi người thường hiểu nhầm về nút cổ chai của solo developer: đây không phải là vấn đề về kỹ năng. Đây là vấn đề về thời gian và context-switching.

Tôi có thể viết code tốt. Tôi có thể viết test tạm được. Tôi có thể cài đặt một CI/CD pipeline. Tôi có thể quản lý một project board. Tôi thậm chí có thể làm business analysis ở mức chấp nhận được nếu bạn cho tôi đủ caffeine.

Nhưng tôi không thể làm tất cả những thứ này cùng một lúc. Và mỗi lần tôi chuyển từ việc này sang việc khác, tôi phải trả một cái giá. Các nghiên cứu về context-switching cho thấy trung bình cần 23 phút để tập trung hoàn toàn trở lại vào một tác vụ sau khi bị gián đoạn. Khi bạn đang đóng tám vai, bạn liên tục tự làm gián đoạn chính mình.

Hãy để tôi đặt con số vào đây. Đây là tuần điển hình của tôi trong một dự án solo:

Thứ Hai:    4 giờ coding, 2 giờ làm rõ yêu cầu, 1 giờ quản lý dự án
Thứ Ba:     5 giờ coding, 1 giờ debug CI/CD, 1 giờ code review (code của chính mình)
Thứ Tư:     3 giờ coding, 2 giờ viết test, 1 giờ quyết định kiến trúc, 1 giờ gọi khách hàng
Thứ Năm:    4 giờ coding, 1 giờ vấn đề deployment, 1 giờ viết documentation
Thứ Sáu:    2 giờ coding, 2 giờ báo cáo tình trạng dự án, 1 giờ sprint planning, 1 giờ testing

Trong một tuần làm việc 35 giờ, tôi chỉ thực sự viết code khoảng 18 giờ. Phần còn lại là overhead — overhead cần thiết, nhưng vẫn là overhead. Và 18 giờ coding đó bị phân mảnh ra suốt năm ngày, không bao giờ quá năm giờ liên tục, liên tục bị gián đoạn bởi việc chuyển đổi vai.

Một developer chuyên tâm trong một đội thực sự, được hỗ trợ bởi PO, BA, QA, DevOps và PM? Họ code 28-30 giờ mỗi tuần, trong các khối tập trung, với yêu cầu rõ ràng được giao đến tận tay, test được viết bởi người khác, deployment được xử lý bởi người khác, và báo cáo dự án được làm bởi người khác.

Developer đó ship nhiều hơn tôi khoảng 60%. Không phải vì họ giỏi hơn. Mà vì họ không phải đóng tám vai.

Giải Pháp Đội Nhóm (Và Tại Sao Nó Không Scale Xuống Được)

Giải pháp hiển nhiên là: thuê một đội. Và với các công ty có ngân sách, đó chính xác là câu trả lời đúng. Một đội phần mềm hoạt động tốt với vai trò rõ ràng, giao tiếp tốt, và quy trình được thiết lập sẽ vượt trội hơn bất kỳ solo developer nào gấp nhiều lần.

Nhưng đội nhóm cũng đi kèm với những chi phí riêng:

Chi phí tài chính. Một đội phần mềm tối thiểu — một PO, một developer, một QA, một DevOps bán thời gian — tốn 15.000-30.000 USD/tháng ở Đông Nam Á, còn nhiều hơn ở các thị trường phương Tây. Với một freelancer hay agency nhỏ, con số đó thường vượt quá toàn bộ ngân sách của dự án.

Chi phí phối hợp. Mỗi người bạn thêm vào đội sẽ tăng thêm các kênh giao tiếp. Hai người có một kênh. Ba người có ba kênh. Năm người có mười kênh. Tám người có hai mươi tám kênh. Đây là định luật Brooks trong thực tế: thêm người vào một dự án phần mềm đã trễ hạn sẽ làm nó trễ hơn. Ngay cả trong một đội được quản lý tốt, việc phối hợp ngốn mất 20-30% tổng năng lực.

Chi phí làm quen. Thành viên mới cần hiểu codebase, kiến trúc, domain nghiệp vụ, và các quy ước của đội. Việc này mất nhiều tuần, đôi khi nhiều tháng. Khi họ đã productive, dự án có thể đã đi được nửa đường.

Chi phí về sự sẵn sàng. Người ta đổ bệnh. Người ta nghỉ phép. Người ta nghỉ việc. Người ta có những tuần không tốt. Một đội toàn người thật vốn có năng lực biến động.

Với những dự án lớn, được tài trợ tốt, tất cả những chi phí này đều đáng trả. Nhưng với phần lớn công việc phần mềm — các dự án freelance, các MVP, các công cụ nội bộ, các side project, công việc của agency nhỏ — một đội đầy đủ là không khả thi.

Điều này tạo ra cái tôi gọi là khoảng cách đội nhóm: khoảng không gian giữa những gì một solo developer có thể tạo ra và những gì một đội phối hợp có thể tạo ra, nơi dự án cần đầu ra ở cấp độ đội nhưng chỉ có ngân sách của một solo developer.

Điều Đã Thay Đổi: AI Đã Đủ Tốt

Hai năm trước, khoảng cách đội nhóm chưa có giải pháp. Bạn hoặc trả tiền cho người thật, hoặc tự làm tất cả.

Rồi các large language model trở nên giỏi. Không chỉ là “demo ấn tượng” — mà là thực sự, thực tế giỏi trong công việc tri thức chuyên môn.

Khi tôi xây dựng portfolio site với Claude như một pair programmer, tôi có một AI giúp tôi một việc tại một lúc. Giống như có một junior developer rất nhanh, rất am hiểu mà không bao giờ mệt mỏi. Chỉ điều đó thôi đã là bước ngoặt — tôi ship tính năng nhanh hơn 2-3 lần so với làm một mình.

Nhưng cái nhận thức thực sự đến khi tôi chú ý đến cách tôi đang sử dụng Claude. Tôi không chỉ yêu cầu nó viết code. Tôi đang yêu cầu nó đóng các vai khác nhau vào các thời điểm khác nhau:

• “Hãy đóng vai product owner. Nhìn vào feature request này và cho tôi biết nó có hợp lý không.”
• “Hãy đóng vai QA engineer. Tôi đang thiếu những edge case nào trong hàm này?”
• “Hãy đóng vai DevOps engineer. Viết cho tôi một GitHub Actions workflow cho dự án này.”
• “Hãy đóng vai tech lead. Review PR này và cho tôi biết bạn sẽ thay đổi gì.”

Và nó giỏi ở tất cả các vai đó. Không hoàn hảo. Không tốt bằng một senior specialist cho từng vai. Nhưng đủ tốt để bắt những thứ tôi đang bỏ sót, đủ tốt để tạo ra các artifact tôi có thể sử dụng, đủ tốt để thực sự có ích.

Đó là lúc ý tưởng trở nên rõ ràng: nếu một AI có thể đóng tất cả các vai này theo trình tự (khi tôi tự prompt thủ công), thì điều gì xảy ra nếu tôi xây dựng một hệ thống mà nhiều AI agent đóng các vai này đồng thời, tự động, với các handoff và quality gate đúng đắn?

Điều gì xảy ra nếu tôi có thể xây dựng cả cái đội?

---

Đội Phần Mềm Agentic Là Gì?

Không Phải Chatbot. Là Agent.

Hãy để tôi nói rõ về thuật ngữ, bởi vì không gian AI đang chìm trong các buzzword và tôi không muốn góp thêm vào sự hỗn loạn đó.

Một chatbot là hệ thống chờ input của bạn, tạo ra response, rồi lại chờ thêm input. Nó phản ứng thụ động. Nó không tự hành động. Nó không tạo ra artifact. Nó không có bộ nhớ về những gì nó đang làm hôm qua. ChatGPT ở dạng cơ bản là một chatbot — một chatbot có năng lực phi thường, nhưng vẫn là chatbot.

Một agent thì khác hoàn toàn. Một agent:

1. Có vai trò và mục tiêu được xác định rõ. Nó biết mình chịu trách nhiệm về điều gì.
2. Có thể hành động tự chủ. Nó không chờ con người prompt ở mọi bước.
3. Tạo ra artifact. Không chỉ là các text response — mà là file thực sự, tài liệu, code, test case, cấu hình.
4. Có bộ nhớ. Nó nhớ các quyết định trong quá khứ, công việc đã làm, và bối cảnh của dự án.
5. Có thể giao tiếp với các agent khác. Nó có thể gửi và nhận các message có cấu trúc.
6. Có quyền hạn và ràng buộc. Nó biết mình được và không được phép làm gì.
7. Có thể sử dụng tool. Nó có thể đọc file, viết file, tìm kiếm internet, chạy lệnh, truy cập database.

Một đội phần mềm agentic là một tập hợp các agent, mỗi agent đại diện cho một vai trò trong đội phát triển phần mềm, và họ cùng nhau làm việc qua các workflow được định nghĩa để biến yêu cầu thành phần mềm hoạt động được.

Đây là sự phân biệt quan trọng. Khi tôi pair-program với Claude, tôi là người điều phối. Tôi quyết định làm gì tiếp theo, tôi chuyển đổi giữa các vai, tôi quản lý workflow. Trong một đội agentic, các agent tự điều phối lẫn nhau. PM Agent điều phối workflow. PO Agent quyết định khi nào yêu cầu đủ rõ để chuyển sang BA. QC Agent quyết định khi nào độ phủ test là đủ. TL Agent quyết định khi nào chất lượng code vượt qua review.

Tôi trở thành khách hàng. Tôi mô tả những gì tôi muốn, và đội xây dựng nó.

Nhận Thức Quan Trọng: Chuyên Môn Hóa Làm AI Tốt Hơn

Đây là điều không hiển nhiên cho đến khi bạn thử: một AI assistant đa năng cố gắng làm mọi thứ kém hơn đáng kể so với một agent chuyên biệt làm tốt một việc.

Khi tôi hỏi Claude “viết cho tôi một user story cho tính năng đăng nhập,” nó tạo ra một user story tạm được. Nhưng khi tôi đưa cho một agent một system prompt chi tiết nói rằng “Bạn là một Business Analyst với 10 năm kinh nghiệm. Bạn viết user story theo định dạng Given/When/Then. Bạn luôn bao gồm acceptance criteria. Bạn xem xét các edge case. Bạn ước lượng theo story point sử dụng thang Fibonacci. Bạn không bao giờ giả định chi tiết triển khai kỹ thuật — bạn tập trung vào giá trị nghiệp vụ” — kết quả đầu ra tốt hơn đáng kể.

Tại sao? Bởi vì các ràng buộc giúp tập trung sự chú ý của model. Thay vì cố gắng là tất cả mọi thứ, nó kênh khả năng của mình vào một vai được định nghĩa hẹp và rõ ràng. Đây là lý do tương tự mà một senior QA engineer viết test case tốt hơn một senior full-stack developer — không phải vì họ thông minh hơn, mà vì họ tập trung hơn.

Đây là nhận thức quan trọng giúp các đội agentic trở thành khả thi: chuyên môn hóa qua system prompt và ràng buộc giúp LLM có năng lực đáng kể hơn ở các vai riêng lẻ so với khi chúng đóng vai trò trợ lý chung.

LLM Ngày Nay Có Thể Và Không Thể Làm Gì

Tôi muốn thành thật về các giới hạn, bởi vì không có gì giết chết một dự án nhanh hơn là kỳ vọng không thực tế.

Những gì LLM có thể làm đủ tốt cho các vai agent (hiện tại, tháng 4 năm 2026):

• Hiểu và cấu trúc các yêu cầu ngôn ngữ tự nhiên
• Viết user story và acceptance criteria
• Tạo test case và phân tích edge case
• Tạo ra các tài liệu thiết kế kiến trúc
• Viết code trong hầu hết các ngôn ngữ và framework phổ biến
• Review code và xác định vấn đề
• Tạo cấu hình CI/CD
• Viết báo cáo trạng thái dự án và tóm tắt
• Giao tiếp theo định dạng có cấu trúc (JSON, YAML, v.v.)

Những gì LLM vẫn còn gặp khó khăn:

• Thiết kế thuật toán thực sự mới lạ (chúng có thể triển khai các thuật toán đã biết, nhưng phát minh ra thuật toán mới thì không chắc chắn)
• Hiểu các codebase legacy phức tạp mà không có context đầy đủ
• Đưa ra các phán quyết đòi hỏi chuyên môn sâu về domain nghiệp vụ
• Lý luận trạng thái kéo dài (chúng rất tốt trong một cuộc hội thoại, kém tin cậy hơn qua nhiều phiên làm việc rời rạc)
• Biết khi nào chúng đang sai (việc hiệu chuẩn độ tin cậy vẫn còn kém)

Điều này có nghĩa gì với đội agent của chúng ta:

Các agent sẽ thực sự hữu ích cho phần lớn công việc phát triển phần mềm tiêu chuẩn. Chúng sẽ gặp khó khăn với những vấn đề hoàn toàn mới lạ, các hệ thống legacy nặng về edge case, và các quyết định đòi hỏi bối cảnh nghiệp vụ sâu. Hệ thống cần có sự giám sát của con người — không phải ở mọi bước, mà tại các điểm quyết định quan trọng. Chúng ta sẽ xây dựng sự giám sát đó vào pipeline dưới dạng quality gate.

---

Ánh Xạ Các Vai Thực Tế Vào Agent

Hãy để tôi đi qua từng vai trong một đội phần mềm tiêu chuẩn và giải thích cách nó ánh xạ sang một AI agent — agent đó làm gì, tạo ra artifact nào, và nó phù hợp ở đâu trong pipeline.

PO Agent (Product Owner)

Một PO người thật làm gì: Một Product Owner là cầu nối giữa business và đội phát triển. Họ thu thập yêu cầu từ các stakeholder, ưu tiên các tính năng, xác định tầm nhìn sản phẩm, và đưa ra quyết định về những gì được xây dựng và theo thứ tự nào.

PO Agent làm gì:

PO Agent nhận đầu vào thô từ khách hàng — có thể là bất cứ thứ gì từ một tài liệu yêu cầu chi tiết đến một tin nhắn Slack mơ hồ kiểu “chúng tôi cần một cái dashboard gì đó” — và biến đổi nó thành các product brief có cấu trúc.

Cụ thể, PO Agent:

• Phân tích các yêu cầu đến về tính đầy đủ và rõ ràng
• Xác định các điểm mơ hồ và tạo ra các câu hỏi làm rõ
• Đánh giá khả năng thi hành ở cấp cao (điều này có thực tế về mặt kỹ thuật không?)
• Cấu trúc yêu cầu thành một product brief với mục tiêu, phạm vi, và tiêu chí thành công rõ ràng
• Ưu tiên các tính năng sử dụng framework như MoSCoW (Must have, Should have, Could have, Won’t have)
• Phân tách các yêu cầu lớn thành các epic

Artifact được tạo ra:

• Tài liệu Product Brief
• Ma trận ưu tiên tính năng
• Các câu hỏi làm rõ (gửi lại cho khách hàng hoặc cho PM Agent)
• Phân tách epic

Ví dụ về tương tác:

CLIENT INPUT: "We need a customer portal where clients can
view their invoices, download PDFs, and pay online."

PO AGENT OUTPUT:
{
  "product_brief": {
    "title": "Customer Invoice Portal",
    "goal": "Enable self-service invoice management for clients",
    "scope": {
      "must_have": [
        "Invoice listing with filters (date, status, amount)",
        "PDF download for individual invoices",
        "Online payment integration"
      ],
      "should_have": [
        "Bulk PDF download",
        "Payment history view",
        "Email notifications for new invoices"
      ],
      "could_have": [
        "Invoice dispute/query feature",
        "Auto-payment setup"
      ],
      "wont_have_v1": [
        "Invoice generation (admin-side only for v1)",
        "Multi-currency support"
      ]
    },
    "clarifying_questions": [
      "What payment providers should be supported?",
      "Is there an existing authentication system to integrate with?",
      "What is the expected number of concurrent users?"
    ],
    "success_criteria": [
      "Clients can view all their invoices within 2 seconds",
      "PDF downloads complete within 5 seconds",
      "Payment flow completes in under 3 clicks"
    ]
  }
}

BA Agent (Business Analyst)

Một BA người thật làm gì: Một Business Analyst lấy các yêu cầu ở cấp sản phẩm và dịch chúng thành các đặc tả chi tiết, sẵn sàng để phát triển. Họ viết user story, định nghĩa acceptance criteria, tạo process flow, và ước lượng công sức.

BA Agent làm gì:

BA Agent nhận product brief từ PO Agent và tạo ra các user story chi tiết với acceptance criteria, ước lượng, và ánh xạ phụ thuộc.

Cụ thể, BA Agent:

• Phân tách epic thành user story theo định dạng “Là [vai trò], tôi muốn [tính năng], để [lợi ích]”
• Viết acceptance criteria chi tiết theo định dạng Given/When/Then
• Xác định các phụ thuộc giữa các story
• Ước lượng công sức theo story point (thang Fibonacci)
• Tạo mô tả process flow
• Gắn cờ các rủi ro kỹ thuật tiềm ẩn hoặc edge case

Artifact được tạo ra:

• User story với acceptance criteria
• Ước lượng story point
• Bản đồ phụ thuộc
• Tài liệu process flow

Ví dụ đầu ra:

user_story:
  id: "US-001"
  epic: "Customer Invoice Portal"
  title: "View Invoice List"
  story: >
    As a registered client, I want to see a list of all my
    invoices so that I can quickly find and manage my payments.
  acceptance_criteria:
    - given: "I am logged in as a client"
      when: "I navigate to the Invoices page"
      then: "I see a paginated list of my invoices sorted by date (newest first)"
    - given: "I am on the Invoices page"
      when: "I apply a date range filter"
      then: "only invoices within that date range are displayed"
    - given: "I am on the Invoices page"
      when: "I apply a status filter (paid, pending, overdue)"
      then: "only invoices with that status are displayed"
    - given: "I have no invoices"
      when: "I navigate to the Invoices page"
      then: "I see a friendly empty state message"
  story_points: 5
  dependencies: ["US-000 (Authentication)"]
  risks:
    - "Pagination performance with large invoice volumes (>10k)"
    - "Date range filter needs timezone handling"
  notes: >
    Invoice data comes from external ERP system. Need to
    confirm API availability and rate limits with TA agent.

QC Agent (Quality Control)

Một QC người thật làm gì: Một QC hay QA Engineer thiết kế chiến lược test, viết test case, xác định edge case, thực hiện kiểm thử, và đảm bảo những gì được deliver thực sự hoạt động đúng như đặc tả.

QC Agent làm gì:

QC Agent nhận user story và acceptance criteria từ BA Agent và tạo ra các test case toàn diện, bao gồm các edge case mà BA có thể đã bỏ sót. Nó cũng review code đã hoàn thành và chạy test suite.

Cụ thể, QC Agent:

• Tạo test case từ acceptance criteria
• Xác định edge case và điều kiện biên
• Viết các negative test scenario (những gì KHÔNG nên xảy ra)
• Định nghĩa các yêu cầu dữ liệu test
• Review các thay đổi code đối chiếu với test case
• Tạo báo cáo độ phủ test
• Tạo ghi chú refinement khi yêu cầu còn mơ hồ

Artifact được tạo ra:

• Tài liệu test case
• Phân tích edge case
• Đặc tả dữ liệu test
• Yêu cầu refinement (gửi lại cho BA Agent)
• Báo cáo thực thi test

Agent này rất quan trọng. Theo kinh nghiệm của tôi, QC Agent bắt được nhiều vấn đề hơn bất kỳ agent nào khác, vì nó được thiết kế đặc biệt để suy nghĩ đối nghịch — để hỏi “điều gì có thể đi sai?” thay vì “làm thế nào để tôi làm cho cái này hoạt động?”

TA/TL Agent (Technical Architect / Tech Lead)

Một TA/TL người thật làm gì: Một Technical Architect thiết kế cấu trúc của hệ thống — database schema, API contract, ranh giới service, lựa chọn công nghệ, và các pattern. Một Tech Lead đảm bảo chất lượng code, tính nhất quán, và khả năng bảo trì thông qua code review và hướng dẫn kỹ thuật.

Chúng ta kết hợp hai vai này thành một agent vì với AI, các kỹ năng chồng lấp nhau nhiều: cả hai đều đòi hỏi kiến thức kỹ thuật sâu và khả năng đưa ra quyết định thiết kế.

TA/TL Agent làm gì:

TA/TL Agent nhận user story (từ BA) và test case (từ QC) và tạo ra các tài liệu thiết kế kỹ thuật mà SSE Agent sẽ triển khai. Sau khi triển khai, nó review code.

Cụ thể, TA/TL Agent:

• Tạo tài liệu thiết kế kỹ thuật sử dụng nguyên tắc Domain-Driven Design (DDD)
• Định nghĩa database schema, API contract, và data model
• Đưa ra quyết định về công nghệ và framework
• Thiết kế workflow phát triển (chiến lược branching, CI trigger, v.v.)
• Tạo các architecture decision record (ADR)
• Review code được tạo bởi SSE Agent
• Phê duyệt hoặc từ chối với phản hồi chi tiết

Artifact được tạo ra:

• Tài liệu Thiết kế Kỹ thuật
• Định nghĩa database schema
• Đặc tả API contract (OpenAPI/Swagger)
• Architecture Decision Record
• Phản hồi code review

Vòng lặp review là điều cốt yếu ở đây. Khi TA/TL Agent từ chối code từ SSE Agent, nó cung cấp phản hồi cụ thể. SSE Agent sửa lại và gửi lại. Vòng lặp này tiếp tục cho đến khi code vượt qua review. Điều này bắt chước quy trình pull request review trong các đội thực — và nó thực sự cải thiện chất lượng code, vì agent đang review có các ưu tiên khác (khả năng bảo trì, tính nhất quán, bảo mật) so với agent đang triển khai (chức năng, tính đúng đắn).

SSE Agent (Senior Software Engineer)

Một SSE người thật làm gì: Một Senior Software Engineer viết code thực sự. Họ triển khai tính năng, viết unit test, debug vấn đề, và lặp lại cho đến khi code hoạt động và vượt qua review.

SSE Agent làm gì:

SSE Agent là con ngựa kéo xe của hệ thống. Nó nhận tài liệu thiết kế kỹ thuật từ TA/TL Agent và triển khai chúng thành code hoạt động được kèm test.

Cụ thể, SSE Agent:

• Đọc tài liệu thiết kế kỹ thuật và hiểu các yêu cầu triển khai
• Viết production code tuân theo kiến trúc và pattern được chỉ định
• Viết unit test và integration test
• Chạy test và lặp lại cho đến khi tất cả vượt qua
• Sửa các vấn đề được xác định trong code review
• Tuân theo coding standard và quy ước được định nghĩa bởi TA/TL Agent

Artifact được tạo ra:

• File source code
• Unit test
• Integration test
• Ghi chú triển khai

Vòng lặp iteration: SSE Agent không chỉ viết code một lần. Nó theo một cách tiếp cận test-driven:

1. Đọc design doc và test case
2. Viết code
3. Chạy test
4. Nếu test thất bại, phân tích lỗi và sửa
5. Lặp lại bước 3-4 cho đến khi tất cả test vượt qua
6. Gửi để TL review
7. Nếu review từ chối, đọc phản hồi và sửa lại
8. Lặp lại bước 3-7 cho đến khi được phê duyệt

Đây là agent hưởng lợi nhiều nhất từ năng lực LLM hiện tại. Việc tạo code là một trong những use case mạnh nhất của các model như Claude, và đầu vào có cấu trúc (design doc rõ ràng, test case cụ thể) làm cho đầu ra đáng tin cậy hơn đáng kể so với việc tạo code ad-hoc.

DevOps Agent

Một DevOps engineer người thật làm gì: Một DevOps Engineer xây dựng và duy trì hạ tầng — CI/CD pipeline, containerization, tự động hóa deployment, monitoring, và quản lý môi trường.

DevOps Agent làm gì:

DevOps Agent nhận code đã được phê duyệt từ bước TL review và xử lý mọi thứ cần thiết để deploy nó.

Cụ thể, DevOps Agent:

• Tạo Dockerfile và cấu hình docker-compose
• Tạo định nghĩa CI/CD pipeline (GitHub Actions, GitLab CI, v.v.)
• Cấu hình biến môi trường và quản lý secret
• Thiết lập deployment script cho các platform khác nhau
• Tạo infrastructure-as-code (Terraform, CloudFormation) khi cần
• Giám sát trạng thái deployment và báo cáo vấn đề

Artifact được tạo ra:

• Dockerfile
• Cấu hình CI/CD pipeline
• Deployment script
• Định nghĩa hạ tầng
• Template cấu hình môi trường

PM/SM Agent (Project Manager / Scrum Master)

Một PM/SM người thật làm gì: Một Project Manager hay Scrum Master điều phối toàn bộ đội. Họ theo dõi tiến độ, xác định blocker, tạo điều kiện giao tiếp, tổ chức các buổi ceremony, và đảm bảo dự án đi đúng hướng.

PM/SM Agent làm gì:

PM/SM Agent là người điều phối của toàn bộ hệ thống. Nó không tạo ra product artifact — nó tạo ra process artifact và điều phối workflow.

Cụ thể, PM/SM Agent:

• Nhận yêu cầu khách hàng ban đầu và chuyển đến PO Agent
• Theo dõi trạng thái của mọi tác vụ qua pipeline
• Phát hiện blocker (một agent đang chờ đầu vào chưa đến)
• Tạo báo cáo trạng thái hàng ngày/sprint
• Điều phối handoff giữa các agent
• Leo thang các vấn đề yêu cầu sự can thiệp của con người
• Duy trì project board (trạng thái tác vụ, phân công, timeline)

Artifact được tạo ra:

• Kế hoạch sprint/iteration
• Báo cáo trạng thái
• Cảnh báo blocker
• Tin nhắn handoff giữa các agent
• Cập nhật timeline dự án

Đây là agent phức tạp nhất để xây dựng, vì nó cần hiểu trạng thái của toàn bộ hệ thống, không chỉ tác vụ của chính nó. Chúng ta sẽ dành nhiều thời gian đáng kể cho agent này ở các phần sau của series.

---

Thuộc Tính Và Năng Lực Của Agent

Mỗi agent trong hệ thống của chúng ta được định nghĩa bởi một tập hợp các thuộc tính nhất quán. Đây không chỉ là để cho ngăn nắp — đây là yếu tố thiết yếu để hệ thống hoạt động. Mỗi agent cần biết nó có thể làm gì, không thể làm gì, có thể nói chuyện với ai, và chịu trách nhiệm về những artifact nào.

Đây là schema chính thức cho mọi agent trong hệ thống:

from pydantic import BaseModel, Field
from typing import List, Optional
from enum import Enum

class Permission(str, Enum):
    READ_ARTIFACTS = "read_artifacts"
    WRITE_ARTIFACTS = "write_artifacts"
    WRITE_CODE = "write_code"
    RUN_COMMANDS = "run_commands"
    SEND_MESSAGES = "send_messages"
    APPROVE_ARTIFACTS = "approve_artifacts"
    REJECT_ARTIFACTS = "reject_artifacts"
    ACCESS_INTERNET = "access_internet"
    MODIFY_PIPELINE = "modify_pipeline"

class LearningSource(BaseModel):
    source_type: str  # "internet", "task_history", "agent_feedback", "human_override"
    description: str
    requires_approval: bool = False

class CommunicationChannel(BaseModel):
    target_agent: str
    message_types: List[str]
    direction: str  # "send", "receive", "bidirectional"

class AgentConfig(BaseModel):
    """Configuration schema for every agent in the system."""

    # Identity
    name: str = Field(description="Unique agent identifier")
    role: str = Field(description="Human-readable role title")
    description: str = Field(description="What this agent does")

    # Capabilities
    responsibilities: List[str] = Field(
        description="Specific tasks this agent performs"
    )
    skills: List[str] = Field(
        description="Domain skills this agent possesses"
    )

    # Constraints
    permissions: List[Permission] = Field(
        description="What this agent is allowed to do"
    )
    denied_permissions: List[Permission] = Field(
        default_factory=list,
        description="Explicitly denied actions"
    )

    # Learning
    learning_sources: List[LearningSource] = Field(
        default_factory=list,
        description="How this agent improves over time"
    )

    # Communication
    communication_channels: List[CommunicationChannel] = Field(
        description="Who this agent talks to and how"
    )

    # Behavior
    system_prompt: str = Field(
        description="The detailed system prompt for the LLM"
    )
    temperature: float = Field(
        default=0.3,
        description="LLM temperature (lower = more deterministic)"
    )
    max_retries: int = Field(
        default=3,
        description="Max attempts before escalating to PM"
    )

Có một vài điều cần lưu ý về schema này:

Quyền hạn là tường minh. Mỗi agent có danh sách rõ ràng về những gì nó có thể và không thể làm. BA Agent không thể viết code. SSE Agent không thể sửa đổi deployment pipeline. QC Agent không thể phê duyệt kết quả test của chính mình. Các ràng buộc này ngăn các agent giẫm lên chân nhau và đảm bảo phân tách các mối quan tâm.

Việc học là đa nguồn nhưng có kiểm soát. Các agent có thể học từ bốn nguồn:

1. Internet — tìm kiếm các best practice, tài liệu, ví dụ
2. Task history — các tác vụ trước được lưu trong vector database (ChromaDB), để agent có thể tham chiếu cách nó xử lý công việc tương tự trước đây
3. Agent feedback — khi agent khác cung cấp phản hồi (ví dụ: TL từ chối code kèm comment), agent nhận học từ phản hồi đó
4. Human override — một người có thể sửa đầu ra của agent, và sự sửa chữa đó có mức ưu tiên cao nhất

Điều quan trọng ở đây là requires_approval. Một số nguồn học yêu cầu sự phê duyệt của con người trước khi agent tích hợp chúng. Điều này ngăn các agent học các pattern xấu từ nhau trong một vòng lặp không được giám sát.

Giao tiếp có cấu trúc. Các agent không gửi tin nhắn free-text cho nhau. Chúng gửi các tin nhắn có kiểu — user_stories, test_cases, code_review_feedback, status_update — với các schema được định nghĩa. Điều này làm cho hệ thống có thể dự đoán và debug được. Khi có gì đó sai, bạn có thể nhìn vào message log và thấy chính xác những gì đã được gửi, bởi ai, và khi nào.

Tại Sao Quyền Hạn Quan Trọng: Một Câu Chuyện Cảnh Báo

Hãy để tôi kể cho bạn tại sao tôi đã thêm các quyền hạn bị từ chối tường minh sau khi học theo cách khó khăn.

Trong một prototype ban đầu, tôi đã cấp cho tất cả các agent quyền hạn rộng — đọc bất cứ thứ gì, viết bất cứ thứ gì, gửi bất cứ thứ gì. BA Agent, khi gặp một yêu cầu mơ hồ, đã quyết định rằng cách hành động hiệu quả nhất là tự viết code dựa trên đánh đoán tốt nhất của nó, bỏ qua hoàn toàn các agent TA/TL và SSE, và gửi thẳng đến DevOps để deploy.

Về mặt kỹ thuật, nó đã giải quyết vấn đề. Về mặt thực tế, nó đã deploy code chưa được test, chưa được review và không khớp với yêu cầu vì “đánh đoán tốt nhất” của BA là sai. BA Agent không cố gắng gây hại — nó đang cố gắng hiệu quả. Nhưng hiệu quả không có ràng buộc là hỗn loạn.

Bây giờ, mỗi agent có các quyền hạn bị từ chối tường minh. BA Agent có WRITE_CODE trong danh sách bị từ chối. Nó thực sự không thể viết code, ngay cả khi lý luận của nó bảo rằng điều đó sẽ nhanh hơn. Đây là tương đương AI của việc phân tách quyền hạn trong bảo mật — và nó quan trọng không kém.

---

Tầm Nhìn: Từ Ý Tưởng Đến Production

Hãy để tôi vẽ ra bức tranh toàn cảnh. Đây là những gì xảy ra khi một khách hàng gửi một feature request vào đội agent của chúng ta.

Pipeline Từng Bước

Bước 1: Yêu Cầu Khách Hàng Đến

Khách hàng gửi một feature request. Đây có thể là một tài liệu chính thức, một email, một tin nhắn chat, hay thậm chí là một bản ghi âm. PM Agent nhận và chuyển nó đến PO Agent.

Bước 2: PO Agent Phân Tích Và Cấu Trúc

PO Agent đọc yêu cầu thô, xác định những gì đang được yêu cầu, kiểm tra tính khả thi ở cấp cao, và tạo ra một product brief có cấu trúc. Nếu yêu cầu còn mơ hồ, PO Agent tạo ra các câu hỏi làm rõ gửi lại cho khách hàng (thông qua PM Agent).

Quality gate: Product brief phải vượt qua kiểm tra tính đầy đủ của PM Agent trước khi tiến tiếp.

Bước 3: BA Agent Tạo Story

BA Agent lấy product brief và phân tách thành các user story với acceptance criteria, ước lượng, và bản đồ phụ thuộc. Mỗi story là một đơn vị công việc rời rạc, có thể triển khai được.

Quality gate: Story phải có acceptance criteria và ước lượng trước khi tiến tiếp.

Bước 4: QC Và TA Làm Việc Song Song

Đây là lúc pipeline trở nên thú vị. Hai agent làm việc đồng thời:

• QC Agent lấy các user story và tạo test case, edge case, và negative scenario. Nó hỏi “làm thế nào chúng ta biết cái này hoạt động?” và “điều gì có thể đi sai?”
• TA/TL Agent lấy các user story và tạo tài liệu thiết kế kỹ thuật — database schema, API contract, kiến trúc pattern, coding standard.

Hai agent này làm việc độc lập nhưng đầu ra của chúng hội tụ tại bước tiếp theo. Tính song song này là một trong những lợi thế lớn nhất của đội agent so với solo developer — bạn đơn giản là không thể vừa viết test case vừa thiết kế kiến trúc cùng một lúc.

Bước 5: SSE Agent Triển Khai

SSE Agent nhận cả test case (từ QC) và thiết kế kỹ thuật (từ TA/TL). Nó có mọi thứ cần thiết: phải xây dựng gì, xây dựng như thế nào, và cách xác minh nó hoạt động. Nó viết code, viết test, chạy test, và lặp lại cho đến khi mọi thứ đều pass.

Bước 6: TL Code Review (Quality Gate)

Đây là quality gate quan trọng nhất trong pipeline. TA/TL Agent (lúc này trong vai TL) review code được tạo bởi SSE Agent. Nó kiểm tra:

• Tuân thủ thiết kế kỹ thuật
• Chất lượng code và khả năng bảo trì
• Vấn đề bảo mật
• Lo ngại về hiệu suất
• Độ phủ test

Nếu review thất bại, SSE Agent nhận phản hồi chi tiết và sửa lại. Vòng lặp này tiếp tục cho đến khi code vượt qua review. Trong thực tế, tôi đã thấy điều này trung bình mất 1-3 vòng lặp — tương tự như các pull request review thực tế.

Bước 7: DevOps Agent Deploy

Khi code vượt qua TL review, DevOps Agent tiếp quản. Nó tạo hoặc cập nhật cấu hình Docker, CI/CD pipeline, và deployment script. Nó xử lý quá trình build, test (lại, trong CI), và deploy.

Bước 8: Production

Tính năng đã live. PM Agent cập nhật project board, đánh dấu tác vụ là hoàn thành, và tạo ra một bản cập nhật trạng thái.

Những Artifact Chạy Qua Pipeline

Hãy để tôi nói cụ thể về từng handoff trông như thế nào:

Client → PO:     Raw requirement (text)
PO → BA:         Product Brief (JSON)
BA → QC:         User Stories + Acceptance Criteria (JSON)
BA → TA/TL:      User Stories + Acceptance Criteria (JSON)
QC → SSE:        Test Cases + Edge Cases (JSON)
TA/TL → SSE:     Technical Design Document (JSON + diagrams)
SSE → TL:        Source Code + Tests (files)
TL → SSE:        Review Feedback (JSON) [if rejected]
TL → DevOps:     Approved Code (files) [if approved]
DevOps → Prod:   Deployment artifacts (Docker, CI/CD configs)
PM → All:        Status updates, blocker alerts (JSON)

Mọi artifact đều có cấu trúc, được version, và được lưu trữ. Không có gì bị mất. Không có gì mơ hồ. Và vì mỗi agent tạo ra typed output, hệ thống có thể debug được — khi có gì đó sai, bạn có thể truy vết chính xác nơi và tại sao.

---

Giao Tiếp Giữa Agent: Ai Nói Chuyện Với Ai

Không phải mọi agent đều nói chuyện với mọi agent khác. Mạng giao tiếp được cố ý ràng buộc để ngăn hỗn loạn và đảm bảo thông tin chảy theo hướng đúng.

Quy Tắc Giao Tiếp

Mạng giao tiếp tuân theo các nguyên tắc sau:

1. Thông tin mặc định chảy xuôi chiều. PO gửi đến BA. BA gửi đến QC và TA. QC và TA gửi đến SSE. SSE gửi đến DevOps. Đây là happy path.

2. Phản hồi chảy ngược chiều. Khi TL từ chối code, phản hồi chảy từ TA/TL trở lại SSE. Khi QC Agent tìm thấy sự mơ hồ trong story, nó gửi yêu cầu làm rõ trở lại BA. Khi BA tìm thấy khoảng trống trong product brief, nó gửi câu hỏi trở lại PO.

3. PM thấy mọi thứ. Mọi tin nhắn giữa các agent cũng hiển thị cho PM Agent. Đây không phải để kiểm soát — mà là để phối hợp. PM cần biết trạng thái của toàn bộ hệ thống để phát hiện blocker và tạo báo cáo trạng thái chính xác.

4. Các agent không thể bỏ qua pipeline. SSE Agent không thể nói chuyện trực tiếp với PO Agent. DevOps Agent không thể nói chuyện với BA Agent. Điều này ngăn các đường tắt có thể làm ảnh hưởng đến chất lượng. Nếu SSE Agent có câu hỏi về yêu cầu, nó đi qua TA/TL Agent hoặc PM Agent.

5. Tất cả giao tiếp đều được log. Mọi tin nhắn được lưu trữ với người gửi, người nhận, timestamp, loại tin nhắn, và nội dung. Điều này tạo ra một audit trail đầy đủ của mọi quyết định được đưa ra trong hệ thống.

Đây là tin nhắn điển hình trong hệ thống trông như thế nào:

{
  "message_id": "msg-2026-04-19-001",
  "from_agent": "ba_agent",
  "to_agent": "qc_agent",
  "message_type": "user_stories",
  "timestamp": "2026-04-19T10:30:00Z",
  "payload": {
    "epic_id": "EP-001",
    "stories": [
      {
        "id": "US-001",
        "title": "View Invoice List",
        "story": "As a registered client...",
        "acceptance_criteria": ["..."],
        "story_points": 5
      }
    ]
  },
  "metadata": {
    "pipeline_run_id": "run-42",
    "iteration": 1,
    "previous_message_id": null
  }
}

---

Series Này Sẽ Xây Dựng Gì

Đây là Phần 1 của một series 12 phần. Đến cuối series, bạn sẽ có một đội phần mềm multi-agent hoàn toàn hoạt động có thể nhận yêu cầu khách hàng và tạo ra code đã được deploy. Đây là lộ trình:

Lộ Trình Series

Phần 1 (bài này): Tại Sao Mô Phỏng Một Đội Phần Mềm Với AI Agent? Tầm nhìn, vấn đề, các vai, pipeline. Bạn đang ở đây.

Phần 2: Thiết Lập Nền Tảng — LangGraph, State, và Kiến Trúc Agent Chúng ta thiết lập dự án, định nghĩa state graph, và xây dựng hạ tầng mà tất cả các agent sẽ chạy trên đó. Giới thiệu tech stack: LangGraph để điều phối, Pydantic cho data model, ChromaDB cho bộ nhớ.

Phần 3: Xây Dựng PO Agent — Từ Yêu Cầu Thô Đến Brief Có Cấu Trúc Agent đầu tiên. Chúng ta xây dựng Product Owner lấy đầu vào lộn xộn từ khách hàng và tạo ra product brief gọn gàng với các ưu tiên, phạm vi, và câu hỏi làm rõ.

Phần 4: Xây Dựng BA Agent — User Story, Tiêu Chí, Và Ước Lượng Agent thứ hai. Chúng ta xây dựng Business Analyst biến product brief thành các user story sẵn sàng phát triển với acceptance criteria Given/When/Then.

Phần 5: Xây Dựng QC Agent — Test Case, Edge Case, Và Chất Lượng Agent đối nghịch. Chúng ta xây dựng QC Agent suy nghĩ về mọi thứ có thể đi sai và tạo ra các test case toàn diện.

Phần 6: Xây Dựng TA/TL Agent — Kiến Trúc, DDD, Và Thiết Kế Kỹ Thuật Người kiến trúc. Chúng ta xây dựng agent thiết kế giải pháp kỹ thuật sử dụng Domain-Driven Design, định nghĩa schema, API, và coding standard.

Phần 7: Xây Dựng SSE Agent — Tạo Code Với Test-Driven Iteration Con ngựa kéo xe. Chúng ta xây dựng agent viết code, chạy test, và lặp lại cho đến khi mọi thứ đều pass. Bao gồm vòng lặp test-driven và tự sửa lỗi.

Phần 8: Xây Dựng DevOps Agent — Docker, CI/CD, Và Deployment Người deploy. Chúng ta xây dựng agent nhận code đã được phê duyệt và khiến nó chạy được trong production với containerization và pipeline đúng đắn.

Phần 9: Xây Dựng PM/SM Agent — Điều Phối, Blocker, Và Báo Cáo Người phối hợp. Chúng ta xây dựng agent phức tạp nhất — agent quản lý toàn bộ pipeline, phát hiện blocker, và giữ mọi thứ chuyển động.

Phần 10: Bộ Nhớ Và Học Tập Của Agent — ChromaDB, RAG, Và Cải Tiến Chúng ta thêm bộ nhớ dài hạn cho các agent sử dụng vector database. Các agent học từ các tác vụ trước, từ phản hồi của nhau, và từ các sửa chữa của con người.

Phần 11: Vòng Lặp Review — Quality Gate, Phê Duyệt, Và Từ Chối Chúng ta xây dựng vòng lặp code review, vòng lặp story review, và tất cả các quality gate khiến hệ thống đáng tin cậy. Đây là nơi phép màu xảy ra.

Phần 12: Gộp Tất Cả Lại — Demo End-to-End Và Dashboard Streamlit Chúng ta kết nối mọi thứ, xây dựng dashboard Streamlit để monitoring, và chạy một demo end-to-end hoàn chỉnh từ yêu cầu khách hàng đến tính năng đã được deploy.

Tech Stack

Đây là những gì chúng ta sẽ sử dụng:

orchestration:
  framework: LangGraph
  language: Python 3.11+
  why: "Graph-based agent workflows with built-in state management"

data_models:
  library: Pydantic v2
  why: "Type-safe data validation for all agent messages and artifacts"

memory:
  vector_db: ChromaDB
  why: "Local vector database for agent memory and RAG"

llm:
  provider: Anthropic (Claude)
  model: claude-opus-4-6
  fallback: claude-sonnet-4-20250514
  why: "Best-in-class code generation and reasoning"

ui:
  framework: Streamlit
  why: "Rapid dashboard development for monitoring agent activity"

storage:
  artifacts: Local filesystem (JSON/YAML)
  logs: SQLite
  why: "Simple, portable, no infrastructure dependencies"

containerization:
  runtime: Docker + docker-compose
  why: "Consistent environments, easy deployment"

Tại sao LangGraph? Vì nó cho chúng ta các workflow dựa trên graph với state management tích hợp, conditional routing, và hỗ trợ cycle (cho các vòng lặp review). Nó được xây dựng đặc biệt cho hệ thống multi-agent, và nó xử lý sự phức tạp của “QC và TA chạy song song, rồi cả hai đều feed vào SSE” một cách thanh lịch.

Tại sao Pydantic? Vì mọi tin nhắn giữa các agent cần một schema chặt chẽ. Pydantic cho chúng ta runtime validation, serialization, và thông báo lỗi rõ ràng khi một agent tạo ra output không đúng định dạng.

Tại sao ChromaDB? Vì các agent cần bộ nhớ. Khi BA Agent viết user story thứ 100, nó nên có thể tham chiếu các pattern từ 99 cái trước. ChromaDB cho chúng ta tìm kiếm vector nhẹ nhàng, cục bộ mà không cần phải khởi động một service riêng biệt.

Bạn Sẽ Có Gì Khi Kết Thúc

Sau khi theo dõi cả 12 phần, bạn sẽ có:

1. Một hệ thống multi-agent hoạt động với 8 agent chuyên biệt
2. Một pipeline hoàn chỉnh từ yêu cầu khách hàng đến code đã được deploy
3. Quality gate với các vòng lặp review tự động
4. Bộ nhớ agent với việc học từ các tác vụ và phản hồi trước
5. Một dashboard monitoring hiển thị hoạt động agent, trạng thái tác vụ, và tình trạng pipeline
6. Một codebase bạn có thể fork, tùy chỉnh, và mở rộng cho dự án của riêng mình

Tổng codebase sẽ có khoảng 5.000-8.000 dòng Python. Mỗi phần thêm 400-800 dòng, xây dựng dần dần trên các phần trước.

---

Lời Tuyên Bố Thành Thật

Tôi muốn kết thúc bằng sự thành thật, vì tôi nghĩ đó là điều quan trọng nhất tôi có thể cung cấp.

Hệ thống này sẽ không thay thế một đội phần mềm người thật. Không phải hôm nay, có lẽ không phải năm tới, có thể sẽ không phải trong một thời gian dài. Đây là những gì nó sẽ không làm được:

• Nó sẽ không xử lý tốt các vấn đề thực sự mới lạ. Nếu khách hàng muốn thứ gì đó chưa từng được xây dựng trước — thực sự mới lạ, không chỉ là “mới với dự án này” — các agent sẽ gặp khó khăn. Chúng được huấn luyện trên các pattern hiện có và hoạt động tốt nhất khi áp dụng các pattern đã biết vào bối cảnh mới.

• Nó sẽ không bắt được mọi bug. QC Agent khá tốt, nhưng nó không phải là một senior QA engineer với 15 năm kinh nghiệm và trực giác về nơi bug ẩn náu. Nó sẽ bỏ sót những thứ. Bạn vẫn sẽ cần kiểm thử bằng người thật cho các hệ thống quan trọng.

• Nó sẽ không đưa ra quyết định kiến trúc hoàn hảo. TA/TL Agent sẽ tạo ra kiến trúc hợp lý, nhưng nó sẽ không có trực giác đến từ việc đã duy trì một hệ thống trong ba năm và biết phần nào dễ vỡ.

• Nó sẽ không quản lý các stakeholder người thật. Nếu khách hàng khó tính, thay đổi yêu cầu liên tục, hoặc giao tiếp kém, các agent không thể điều hướng điều đó. PO Agent có thể đặt câu hỏi làm rõ, nhưng nó không thể đọc được những gì ẩn đằng sau một email thụ động gây hấn.

Đây là những gì nó sẽ làm:

• Nó sẽ xử lý 70-80% công việc phát triển phần mềm tiêu chuẩn. Những phần tẻ nhạt, lặp lại, được hiểu rõ mà ngốn hầu hết thời gian của bạn — viết user story, tạo test case, triển khai CRUD operation, cài đặt CI/CD, tạo báo cáo trạng thái.

• Nó sẽ giải phóng bạn để tập trung vào 20-30% đòi hỏi phán quyết của con người. Giải quyết vấn đề sáng tạo, quản lý stakeholder, trực giác kiến trúc, những cảm giác “cái này có gì đó sai” đến từ kinh nghiệm.

• Nó sẽ chạy 24/7. Trong khi bạn ngủ, các agent có thể đang xử lý yêu cầu sprint tiếp theo, tạo test case, hoặc lặp lại trên phản hồi code review.

• Nó sẽ nhất quán. Không giống con người, các agent không có ngày tồi. Chúng không quên các quy ước. Chúng không bỏ qua các bước vì mệt mỏi hay chán nản.

• Nó sẽ có thể kiểm tra được. Mọi quyết định, mọi artifact, mọi tin nhắn đều được log và có thể truy vết. Khi có gì đó sai, bạn có thể thấy chính xác những gì đã xảy ra.

Mục tiêu không phải là thay thế developer. Mục tiêu là cho các solo developer và đội nhỏ năng lực đầu ra của một đội lớn hơn nhiều, trong khi vẫn giữ con người trong vòng lặp cho những quyết định quan trọng.

Đó là những gì chúng ta đang xây dựng. Hãy bắt đầu thôi.

---

Tiếp Theo

Trong Phần 2, chúng ta sẽ thiết lập dự án, cài đặt LangGraph và các dependency, định nghĩa state graph, và xây dựng nền tảng mà tất cả các agent sẽ chạy trên đó. Chúng ta sẽ viết vài trăm dòng code đầu tiên và thấy agent đầu tiên của chúng ta ra đời.

Theo dõi series để được thông báo khi Phần 2 ra mắt. Và nếu bạn có câu hỏi, suy nghĩ, hoặc kinh nghiệm của riêng bạn với các hệ thống multi-agent — tôi thực sự muốn được nghe từ bạn.

Tương lai của phát triển phần mềm không phải là AI thay thế developer. Mà là developer với đội AI, xây dựng nhanh hơn, xây dựng tốt hơn, xây dựng những thứ họ không thể xây dựng một mình.

Hãy xây dựng đội thôi.

---

Thuận Lương là một Tech Lead đang làm việc tại Việt Nam, người xây dựng ứng dụng web và thỉnh thoảng nói chuyện với robot về code. Series này ghi lại nỗ lực của anh ấy để tự động hóa mọi thứ ngoại trừ những lần nghỉ uống cà phê. Theo dõi series Vibe Coding: Building an AI Software Team để xem tất cả 12 phần.