BMAD Method: Chuẩn hóa kỷ luật Agile cho AI Agent trong hệ thống Legacy Brownfield

Khi các công cụ AI hỗ trợ lập trình bước sang thế hệ thứ ba (Gen 3) với những cái tên như Claude Code, Cursor Agent hay Devin, mô hình tương tác giữa kỹ sư và mô hình ngôn ngữ lớn (LLM) đã thay đổi hoàn toàn.

Thay vì dừng lại ở việc gợi ý một dòng code (Gen 1 - Autocomplete) hoặc trả lời thắc mắc trong cửa sổ chat bên cạnh IDE (Gen 2 - Chatbot), các Agent thế hệ mới có quyền đọc toàn bộ codebase, tự động tạo mới và sửa đổi nhiều file mã nguồn, chạy terminal command và lặp lại vòng lặp kiểm thử cho tới khi bài toán hoàn thành.

Thế nhưng, chính quyền năng này mở ra một rủi ro kỹ thuật mới: một sai lệch trong quá trình hiểu yêu cầu giờ đây không chỉ là một dòng code gợi ý sai, mà có thể biến thành một Pull Request (PR) 400 dòng đi sai hoàn toàn định hướng kiến trúc. Năng lực tạo code của AI đã vượt qua khả năng mô tả yêu cầu của con người. Điểm nghẽn (bottleneck) lớn nhất trong phát triển phần mềm hiện đại đã dịch chuyển từ khâu viết mã sang khâu định nghĩa specification có cấu trúc.

Báo cáo kỹ thuật này phân tích toàn diện BMAD Method (Breakthrough Method for Agile AI-Driven Development) — một framework mã nguồn mở chuyển hóa mô hình Agile thành hệ thống Agent chuyên trách — đồng thời chia sẻ kinh nghiệm may đo (tailoring) phương pháp này vào một hệ thống legacy brownfield thực tế.

Ba thế hệ công cụ AI cho lập trình

Để hiểu rõ lý do cần đến một framework quản trị như BMAD, cần nhìn lại tiến trình phát triển của các công cụ AI hỗ trợ kỹ sư:

Ở Gen 3, vấn đề không còn là mô hình AI có biết viết mã hay không, mà là làm thế nào để giữ Agent hoạt động trong ranh giới an toàn. Các phương pháp tiếp cận hiện đại như BMAD, Spec Kit, OpenSpec hay Kiro đều chia sẻ chung một triết lý: chuẩn hóa yêu cầu thành specification có cấu trúc chặt chẽ trước khi bàn giao cho Agent thực thi.

BMAD Method là gì?

BMAD (Breakthrough Method for Agile AI-Driven Development) là framework mã nguồn mở theo giấy phép MIT do cộng đồng bmad-code-org khởi xướng. Về bản chất, BMAD ánh xạ các vai trò và nghi thức trong một đội ngũ Agile truyền thống thành một dàn AI Agent chuyên trách, trong đó mỗi Agent sở hữu persona, nhiệm vụ, template tài liệu và checklist phản biện riêng biệt.

Phương pháp này tạo ra hai bước đột phá then chốt:

• Agentic Planning: Thay vì để một prompt duy nhất giải quyết toàn bộ tính năng, các Agent như Analyst, Product Manager (PM) và Architect cùng tương tác để hoàn thiện tài liệu Product Requirements Document (PRD) và Architecture Document trước khi bất kỳ dòng code nào được sinh ra. Cơ chế này loại bỏ các giả định ngầm và phát hiện lỗ hổng nghiệp vụ ngay từ khâu thiết kế.
• Context Engineering trong khâu Dev: Scrum Master phân rã PRD và tài liệu kiến trúc thành các file Story độc lập (self-contained). Mỗi Story file chỉ nạp đúng và đủ ngữ cảnh cần thiết cho Dev Agent, triệt tiêu hoàn toàn nhiễu ngữ cảnh (competing noise) và hiện tượng hallucination.

BMAD có ba đặc tính kỹ thuật quan trọng:

• Độc lập với mô hình (Model-agnostic): Agent thực chất là các file Markdown định nghĩa persona, quy trình và checklist, không phụ thuộc vào một nhà cung cấp LLM cụ thể.
• Không vendor lock-in: Có thể vận hành linh hoạt trên Claude Code, Cursor, Windsurf, GitHub Copilot CLI hoặc các custom runner.
• Quản lý tập trung trên Git: Toàn bộ brief, PRD, architecture shard và story file đều được lưu trong Git repository, cho phép review, theo dõi diff và trace ngược nguồn gốc khi phát sinh lỗi.

Ba nguyên lý nền tảng của BMAD

Mọi quy trình trong BMAD đều vận hành dựa trên ba nguyên lý cốt lõi:

1. Phân cấp tài liệu nghiêm ngặt

Quy trình tài liệu đi tuần tự qua sáu tầng: Brief -> PRD -> Architecture -> Epic -> Story -> Code. Mỗi tầng đóng vai trò là đầu vào trực tiếp cho tầng kế tiếp, tuyệt đối không nhảy cóc. Khi mã nguồn xuất hiện lỗi logic, kỹ sư có thể dễ dàng truy vết ngược lại xem lỗi bắt nguồn từ tầng Story, Architecture hay PRD.

2. Chuyên biệt hóa Agent (Agent Specialization)

Một mô hình ngôn ngữ cố gắng làm mọi việc cùng lúc (“biết tuốt”) thường cho ra kết quả ở mức trung bình. BMAD chia nhỏ trách nhiệm:

• Product Manager tập trung trả lời câu hỏi: Làm cái gì (What) và vì sao cần làm (Why)?
• Architect chịu trách nhiệm trả lời: Triển khai bằng cách nào (How), cấu trúc dữ liệu ra sao, giới hạn kỹ thuật là gì?
• Dev Agent chỉ tập trung thực hiện đúng nội dung được giao trong phạm vi file cho phép.
• Mỗi Agent đi kèm một checklist chuyên biệt, buộc mô hình phải chủ động đặt câu hỏi phản biện về các trường hợp biên (edge cases) mà một prompt tự do thường bỏ quên.

3. Human-in-the-loop tại các Decision Gate

BMAD không loại bỏ con người để vận hành tự động hoàn toàn. Trái lại, framework thiết lập ba chốt chặn phê duyệt bắt buộc:

• Chốt chặn 1: Kỹ sư duyệt nội dung PRD trước khi chuyển sang thiết kế kiến trúc.
• Chốt chặn 2: Kỹ sư duyệt tài liệu Architecture trước khi phân rã task.
• Chốt chặn 3: Kỹ sư review mã nguồn và duyệt merge Pull Request.

Ở các tác vụ nhỏ, BMAD tạo ra chi phí quy trình (overhead) cao hơn so với việc viết prompt tự do (vibe coding). Tuy nhiên, trên các tác vụ quy mô lớn hoặc dự án có nhiều người cùng tham gia, chi phí viết specification được khấu hao nhanh chóng nhờ khả năng tái sử dụng ngữ cảnh và giảm thiểu số lần phải sửa lại mã từ đầu.

Đội hình Agent: Phân định trách nhiệm và dữ liệu đầu ra

Trong một chu trình phát triển đầy đủ, BMAD điều phối 9 vai trò Agent chính:

Ngoài việc chạy tuần tự, BMAD hỗ trợ chế độ Party Mode: nhiều Agent cùng tham gia một phiên thảo luận do BMad Master điều phối. Chế độ này hữu ích khi cần cân nhắc các đánh đổi kiến trúc phức tạp (architectural trade-offs), nhưng tiêu tốn lượng token lớn nên chỉ được khuyến nghị sử dụng khi thật sự cần thiết.

Giải phẫu một Agent: Cấu trúc file cấu hình

Mỗi Agent trong BMAD thực chất là một file văn bản định dạng YAML hoặc Markdown, không phải một phần mềm biên dịch phức tạp.

Ví dụ cấu hình của Agent Architect (PhucNH):

agent:
  name: PhucNH (Architect)
  persona: 15 năm kinh nghiệm kiến trúc hệ thống microservice, ưu tiên giải pháp tối giản, luôn hỏi rõ ràng trước khi đưa ra giả định kỹ thuật
  commands:
    - create-architecture
    - review-design
    - shard-document
  dependencies:
    templates:
      - templates/architecture-tmpl.md
    checklists:
      - checklists/architect-checklist.md
    data:
      - conventions/tech-preferences.md

Thiết kế này mang lại bốn lợi thế kỹ thuật:

• Persona định hình tư duy: Nguyên tắc “luôn hỏi rõ trước khi giả định” triệt tiêu nguy cơ mô hình tự ý suy diễn nghiệp vụ khi gặp điểm chưa rõ ràng.
• Checklist đảm bảo tính toàn diện: Bắt buộc Agent duyệt qua các tiêu chí về concurrency, transaction rollback, caching strategy và bảo mật trước khi kết luận bản thiết kế.
• Template chuẩn hóa định dạng: Tạo ra sự đồng nhất về mặt tài liệu giữa các module và các thành viên trong dự án, giúp tốc độ review của kỹ sư nhanh hơn.
• Dependencies giới hạn không gian ngữ cảnh: Khi khởi chạy Agent, công cụ chỉ nạp đúng các template và checklist được khai báo, không nạp bừa bãi toàn bộ repository vào context window.

Bốn Phase triển khai và Điều chỉnh liều lượng quy trình (Scale Levels)

Quy trình phát triển trong BMAD được tổ chức thành bốn giai đoạn:

1. Analysis (Tùy chọn): Dùng khi bài toán còn ở dạng ý tưởng sơ khai. Analyst nghiên cứu bối cảnh, đối thủ và viết Project Brief. Có thể bỏ qua giai đoạn này nếu nghiệp vụ đã được định nghĩa rõ ràng.
2. Planning (Bắt buộc): Product Manager tổng hợp yêu cầu thành PRD với mục tiêu, số liệu đo lường thành công, Functional Requirements (FR), Non-Functional Requirements (NFR), luồng ngoại lệ (exception flows) và danh mục loại trừ (Out of Scope).
3. Solutioning: Architect phân tích hiện trạng hệ thống, đưa ra giải pháp kỹ thuật, chia nhỏ tài liệu kiến trúc thành các mảnh (sharding) và cùng Product Owner phân rã thành các Epic.
4. Implementation: Vận hành theo vòng lặp Story khép kín: Scrum Master viết Story -> Kỹ sư duyệt -> Dev Agent triển khai theo hướng test-first -> Quality gate tự động -> Review đa lớp -> Hoàn thành (Done).

Sai lầm phổ biến nhất của các đội ngũ khi tiếp cận BMAD là áp dụng cứng nhắc toàn bộ 4 phase và đủ 9 Agent cho mọi tác vụ. Điều này khiến thời gian viết tài liệu lấn át thời gian phát triển thực tế, khiến đội ngũ kiệt sức sau 2–3 tuần.

BMAD giải quyết vấn đề này bằng hệ thống phân cấp quy mô từ Level 0 đến Level 4. Căn cứ để chọn cấp độ quy trình là phạm vi ảnh hưởng (blast radius) và hệ thống kiểm thử sẵn có (safety net), không phụ thuộc vào số dòng code. Một thay đổi chỉ vỏn vẹn 5 dòng code nhưng nằm trong module xử lý thanh toán tài chính vẫn bắt buộc áp dụng tối thiểu Level 2.

Kỹ thuật Context Engineering: “Ít mà đúng thắng nhiều mà loãng”

Một ngộ nhận tai hại khi làm việc với LLM hiện đại là cho rằng khi cửa sổ ngữ cảnh đạt 200.000 hoặc 1.000.000 token thì có thể nhồi toàn bộ repository vào prompt.

Thực tế kỹ thuật chứng minh điều ngược lại qua ba vấn đề:

• Hiện tượng Lost in the middle (Liu et al., 2023): Thông tin nằm ở khoảng giữa một đoạn ngữ cảnh quá dài thường bị mô hình suy giảm khả năng chú ý nghiêm trọng.
• Nhiễu cạnh tranh ngữ cảnh (Competing noise): Những đoạn mã không liên quan khiến Agent bắt chước sai mẫu thiết kế hoặc gọi nhầm các hàm không tương thích.
• Chi phí và độ trễ tăng vọt: Chi phí token và thời gian phản hồi tăng tỷ lệ thuận với độ dài context, nhưng chất lượng kết quả đầu ra lại giảm dần.

BMAD áp dụng nguyên tắc Just-in-time Context qua mô hình phân tầng ba lớp:

Giải phẫu Story file: Bảy thành phần bắt buộc

Story file là đơn vị bàn giao quan trọng nhất trong BMAD. Một Story file chuẩn mực phải đảm bảo tính tự điều hướng (self-contained) để Dev Agent có thể đọc hiểu và thực thi mà không cần hỏi thêm hay đọc lan man ra ngoài codebase.

Bảy thành phần bắt buộc trong cấu trúc một Story file bao gồm:

# Story-104: Tích hợp Rate Limiter cho Endpoint Tìm kiếm Việc làm

## 1. Objective
Ngăn chặn hành vi cào dữ liệu tự động tần suất cao trên endpoint `/api/v1/jobs/search/`,
đảm bảo tính ổn định của hệ thống tìm kiếm cho người dùng thật.

## 2. Acceptance Criteria (AC)
- AC-1: Chặn mọi IP vượt quá 60 requests/phút, trả về mã lỗi HTTP 429 Too Many Requests (kèm payload JSON `{"error": "rate_limit_exceeded"}`).
- AC-2: Response header phải chứa `X-RateLimit-Limit`, `X-RateLimit-Remaining`, và `Retry-After`.
- AC-3: Bỏ qua kiểm tra rate limit đối với các request nội bộ có header `X-Internal-Secret` hợp lệ.

## 3. Architecture Context
- Sử dụng kết nối Redis qua `django_redis.get_redis_connection("default")`.
- Thuật toán áp dụng: Token Bucket (tham khảo file `docs/architecture/rate-limiter.md`).

## 4. File Scope
- Được phép sửa đổi / tạo mới:
  + `jobs/middleware/rate_limit.py`
  + `jobs/tests/test_rate_limit_middleware.py`
- Nghiêm cấm chạm vào:
  + `config/settings/base.py` (Khai báo `MIDDLEWARE` do Subleader cấu hình thủ công)
  + `jobs/services/redis_client.py` (Chỉ dùng interface có sẵn, không sửa core)

## 5. Technical Constraints
- Triển khai middleware theo chuẩn Django callable tương thích Django 4.2+.
- Không cài thêm thư viện bên ngoài; chỉ dùng client `django-redis` và Lua script có sẵn.
- Xử lý Redis connection failure theo cơ chế fail-open: nếu Redis sập (ném ngoại lệ `ConnectionError`), request vẫn được đi tiếp và ghi log warning qua module `logging`.

## 6. Test Specification
- Mapping AC-1: `test_rate_limit_returns_429_when_threshold_exceeded()`
- Mapping AC-2: `test_rate_limit_headers_present_in_response()`
- Mapping AC-3: `test_internal_secret_bypasses_rate_limit()`
- Edge case: `test_fail_open_when_redis_connection_fails()`

## 7. Definition of Done (DoD)
- [ ] Toàn bộ 4 test case trong Test Specification đều pass khi chạy `pytest` hoặc `python manage.py test`.
- [ ] Chạy linter đạt chuẩn ruff/flake8, kiểm tra kiểu dữ liệu với `mypy --strict` không phát sinh lỗi.
- [ ] Không có file nào nằm ngoài danh sách File Scope bị thay đổi.

Trong bảy thành phần trên, có hai thành phần đặc biệt then chốt nhưng thường bị xem nhẹ:

• Phạm vi file (File Scope - mục 4): Cần chỉ định rõ ràng file nào được sửa và file nào nghiêm cấm chạm vào. Nếu thiếu ràng buộc này, Agent có xu hướng “tiện tay” refactor các file xung quanh, đổi chữ ký hàm của các module liên quan, khiến một PR từ 40 dòng phình to lên 300 dòng không thể review nổi.
• Ánh xạ tiêu chí kiểm thử (Test Specification - mục 6): Từng Acceptance Criteria phải có test case đối ứng trực tiếp. Nếu không có mục này, Agent sẽ chỉ viết test cho những trường hợp dễ (happy path) nhằm tăng độ bao phủ (coverage) ảo mà bỏ qua toàn bộ rủi ro nghiệp vụ.

Bài toán Greenfield và Brownfield

Tiếp cận dự án mới (Greenfield) và hệ thống hiện hữu (Brownfield) đòi hỏi hai chiến lược hoàn toàn khác nhau:

Với các hệ thống legacy brownfield, BMAD đề xuất ba quy tắc kỹ thuật bất biến:

• Wiki trước, code sau: Ưu tiên để Agent đọc các tài liệu tổng quan đã chắt lọc. Việc thả Agent tự do quét hàng trăm ngàn dòng mã nguồn legacy vừa gây lãng phí token vừa khiến mô hình học theo các đoạn mã xấu (code smells) trong quá khứ.
• Ngưỡng tự tin (Confidence Threshold): Khi Agent chưa đạt độ chắc chắn tối thiểu (ví dụ < 0.7) về luồng hoạt động của một module phức tạp, quy trình bắt buộc Agent dừng lại và đọc trực tiếp mã nguồn của riêng module đó thay vì tự suy đoán.
• Ghim phiên bản mã nguồn (Version Pinning): Mọi tài liệu kiến trúc trích xuất ra phải ghi rõ commit hash cụ thể của Git repository tại thời điểm phân tích.

Kiểm thử dựa trên rủi ro (Risk-Driven Testing)

Trong mô hình BMAD, vai trò của Test Architect là thiết lập ma trận rủi ro (Xác suất xảy ra × Mức độ tác động) để phân bổ tỷ trọng giữa Unit Test, Integration Test và End-to-End (E2E) Test cho từng Acceptance Criteria.

Một nguyên tắc kiểm thử tối quan trọng khi làm việc với AI: Test phải được sinh ra độc lập từ Acceptance Criteria trong Story, tuyệt đối không sinh test từ đoạn mã AI vừa viết xong.

LLM rất giỏi viết test cho đoạn mã có sẵn, nhưng đó là một cái bẫy kỹ thuật: bộ test đó chỉ khẳng định lại hành vi hiện tại của đoạn code (bao gồm cả các lỗi logic ngầm mà AI vừa tạo ra). Chỉ khi test case được hình thành độc lập dựa trên tiêu chí nghiệm thu ban đầu, hệ thống kiểm thử mới phát hiện được sai lệch logic giữa yêu cầu và mã triển khai.

Hệ thống quản trị chất lượng được bảo vệ bởi bốn chốt chặn tự động:

Tốc độ sinh mã của AI chỉ an toàn khi ba chốt chặn đầu tiên đã được tự động hóa hoàn toàn trong CI/CD pipeline. Nếu thiếu nền tảng kiểm thử tự động, việc tăng tốc độ tạo mã thực chất chỉ là dời rủi ro và tích lũy nợ kỹ thuật (technical debt) về giai đoạn sau.

Nhìn nhận khách quan: BMAD không làm được gì?

Dù sở hữu cấu trúc quản trị chặt chẽ, BMAD không phải giải pháp toàn năng. Cần nhìn nhận rõ các giới hạn kỹ thuật và phê bình thực tế:

• Không thể biến mô hình AI yếu thành mô hình giỏi: BMAD chỉ cung cấp cấu trúc ngữ cảnh và quy trình kiểm soát; năng lực suy luận logic vẫn phụ thuộc vào năng lực của LLM nền tảng.
• Không thay thế được tri thức nghiệp vụ (Domain Knowledge) của kỹ sư: Khi gặp bài toán nghiệp vụ đặc thù chưa từng xuất hiện trên internet, Agent không thể tự suy luận đúng nếu kỹ sư không cung cấp dữ liệu nền tảng.
• Chi phí thời gian ban đầu không giảm: Kỹ sư phải dành nhiều thời gian hơn cho việc đọc spec, soát checklist và review tài liệu thiết kế.
• Overhead cao đối với task nhỏ: Việc áp dụng quy trình đầy đủ cho các lỗi nhỏ sẽ làm chậm tiến độ đáng kể.
• Tốn chi phí token khi vận hành Multi-Agent: Các phiên đối thoại nhiều bên tiêu tốn lượng token gấp 3–5 lần so với phiên làm việc đơn lẻ.
• Nguy cơ biến tướng thành quy trình Waterfall trá hình AI: Nếu đội ngũ sa đà vào việc viết tài liệu hoàn hảo trước khi kiểm chứng thực tế, quy trình sẽ đánh mất hoàn toàn tính linh hoạt của Agile.

Giá trị cốt lõi của BMAD nằm ở kỷ luật công nghệ (engineering discipline) mà nó yêu cầu, chứ không nằm ở việc sở hữu một bộ công cụ phức tạp.

Đối chiếu Landscape: Vibe Coding đến BMAD

Để lựa chọn công cụ phù hợp cho từng giai đoạn dự án, có thể tham khảo bảng so sánh các trường phái tiếp cận:

Chiến lược kết hợp hiệu quả nhất trong thực tế là mô hình xếp tầng: Sử dụng Rules file làm nền tảng kiểm soát chung, áp dụng Story file cho từng task cụ thể, và kích hoạt các quy trình BMAD cấp cao khi đối mặt với các module có mức rủi ro lớn.

Kinh nghiệm thực tế: Chiến lược may đo BMAD cho hệ thống Legacy

Trong các hệ thống phần mềm doanh nghiệp lâu năm, đội ngũ kỹ thuật thường đối mặt với các đặc thù kỹ thuật rõ rệt:

• Hệ thống Brownfield điển hình: Codebase có lịch sử phát triển nhiều năm, độ bao phủ kiểm thử tự động ban đầu rất thấp (test coverage dưới 2%).
• Mô hình phối hợp phân tán: Kho lưu trữ mã nguồn chính (core codebase) do đối tác hoặc trụ sở chính quản lý, trong khi đội ngũ kỹ thuật phụ trách phát triển tính năng mới và viết kiểm thử tự động (autotest) trên một repository riêng, không trực tiếp nắm giữ product backlog toàn cục.
• Cơ cấu nhân sự phân vai rõ ràng: Đội ngũ vận hành theo các vai trò tách bạch: Bridge Software Engineer (BrSE), Subleader, Developer và Tester.

Khi đối chiếu giữa các giải pháp:

Chiến lược may đo (Tailoring): Chỉ kích hoạt đúng thành phần cần thiết

Nhận thức rõ nguy cơ quá tải quy trình nếu áp dụng nguyên bản toàn bộ framework, đội ngũ kỹ thuật đã thực hiện may đo BMAD v6.12.4 (gồm module core và bmm) vào repository autotest theo nguyên tắc: Chỉ lấy phần cốt lõi phục vụ trực tiếp bài toán của team.

Đội ngũ kỹ thuật tận dụng tối đa hai vũ khí đắt giá nhất của BMAD:

1. Architecture Spine sinh trực tiếp từ codebase: Thay vì cố gắng viết một bản kiến trúc lý thuyết dài hàng trăm trang, framework hỗ trợ quét mã nguồn thực tế để sinh ra “xương sống kiến trúc” (as-is architecture map). Đây chính là tấm bản đồ dẫn đường giúp Dev Agent không bị lạc trong hệ thống legacy.
2. Khái niệm Phân vai (Roles): Gắn kết từng Agent kỹ thuật số với vai trò của kỹ sư thật trong pipeline. BrSE kiểm soát AC, Subleader kiểm soát thiết kế chi tiết và File Scope, Developer điều hướng Agent trong phiên làm việc, Tester đánh giá ma trận rủi ro.

Kết quả: Quy trình phát triển giữ nguyên được tốc độ linh hoạt vốn có, trong khi tỷ lệ mã nguồn bị lệch chuẩn hoặc tự ý sửa đổi ngoài phạm vi giảm rõ rệt.

Bài học đúc kết (Key Takeaways)

Qua quá trình nghiên cứu và thực nghiệm triển khai BMAD Method vào dự án thực tế, có bốn bài học cốt lõi mà các đội ngũ kỹ thuật có thể tham khảo:

• Định nghĩa yêu cầu là điểm nghẽn mới của thời đại AI Agent: Khi AI có thể tạo hàng trăm dòng mã trong vài chục giây, năng lực kỹ thuật quan trọng nhất của kỹ sư không còn là tốc độ gõ code mà là khả năng phân tích ranh giới bài toán và thiết lập tiêu chí nghiệm thu rõ ràng.
• File Scope và Test Specification là hai rào chắn an toàn then chốt: Một Story file tốt bắt buộc phải chỉ định danh sách file cấm sửa đổi để ngăn ngừa hiện tượng lan rộng phạm vi ngoài tầm kiểm soát, đồng thời ánh xạ trực tiếp từng tiêu chí nghiệm thu sang các test case cụ thể để tránh độ bao phủ ảo.
• Context Engineering: Chất lượng vượt trội số lượng: Đừng lạm dụng cửa sổ ngữ cảnh khổng lồ của mô hình. Hãy chia nhỏ tài liệu thành các shard theo domain và áp dụng nguyên tắc Single-Story Session để giữ cho không gian suy luận của Agent luôn tập trung và chính xác.
• May đo theo bối cảnh thực tế thay vì ôm đồm trọn gói: Giá trị lớn nhất của các framework mã nguồn mở như BMAD nằm ở các mẫu hình thiết kế (design patterns) và kỷ luật tài liệu. Hãy mạnh dạn cắt bỏ những nghi thức không phù hợp với cấu trúc phân vai và hiện trạng của dự án.