GSD là gì? Framework AI coding tối ưu cho MVP linh hoạt

GSD là gì? Toàn cảnh framework AI coding tối ưu cho dự án thử nghiệm (2026)

TL;DR

• GSD là framework AI coding tối ưu cho dự án thử nghiệm, yêu cầu hay thay đổi, cần MVP rất nhanh.
• GSD dùng kiến trúc sub-agent song song và kiểm chứng nhiều tầng để hạn chế mất/ô nhiễm ngữ cảnh khi dự án lớn dần.
• So với Bmad và SuperPowers, GSD giảm tối đa phần “lên kế hoạch trước”, ưu tiên thử nghiệm và điều chỉnh linh hoạt.
• Khi kết hợp Claude Code (1M token context), GSD giúp vừa tận dụng context lớn vừa giữ cấu trúc tài liệu rõ ràng.
• GSD không phải lựa chọn tốt cho app quá đơn giản; nó mạnh nhất với app nhiều tính năng, yêu cầu phức tạp.

---

Bối cảnh GSD: là framework AI coding tối ưu cho dự án yêu cầu linh hoạt và nhiều thử nghiệm

GSD (Get Stuff Done) là một framework AI coding được thiết kế riêng cho những dự án mà yêu cầu còn linh hoạt và cần rất nhiều thử nghiệm trong quá trình phát triển. Nó hướng tới môi trường phát triển dựa trên AI agent, nơi sản phẩm có thể thay đổi liên tục khi hiểu hơn về người dùng và bài toán.

Trong vài năm gần đây, số lượng AI coding framework bùng nổ mạnh. Framework nào cũng tự nhận là “cách tốt nhất để xây agent.” Nhưng có một điểm mà nhiều người bỏ qua: không có “cách tốt nhất” chung cho mọi dự án. Chỉ có framework phù hợp nhất với loại dự án cụ thể.

Tôi từng thử Bmad, SuperPowers và một số framework khác. Nhận xét thật lòng: mỗi cái chỉ thật sự tỏa sáng trong bối cảnh mà nó được thiết kế cho. GSD gây chú ý không phải vì nó “mới”, mà vì nó lấp vào khoảng trống mà các framework kia chưa giải quyết được, đặc biệt khi kết hợp với Claude Code trong các dự án lớn, đa tính năng.

“Không có viên đạn bạc. Trước khi chọn framework, phải hiểu rõ bản chất dự án của mình là gì.”

---

Triết lý GSD: là framework ưu tiên “làm được thứ chạy được” cho dự án chưa rõ hoàn toàn yêu cầu

Triết lý GSD tập trung vào một việc: làm cho chạy được thật nhanh, trong bối cảnh chưa thể biết hết mọi chi tiết từ đầu. Framework này phù hợp nhất với những dự án mà bạn biết mình muốn giải quyết vấn đề gì, nhưng không thể mô tả chính xác toàn bộ UX, luồng, hay ràng buộc kỹ thuật ngay từ bước một.

GSD không dành cho kiểu “chúng ta chưa biết gì, cứ làm đại.” Nó dành cho tình huống: biết bài toán, nhưng mỗi bước đều phải thử nghiệm để tìm lời giải tốt nhất. Đây là lý do GSD đặc biệt mạnh trong giai đoạn xây MVP (Minimum Viable Product) với tốc độ cao.

Tên gọi “Get Stuff Done” phản ánh trực tiếp triết lý này. GSD vẫn hỏi các câu hỏi phạm vi ban đầu, nhưng khác với Bmad ở chỗ nó không trói bạn vào một bản kế hoạch cố định. Kế hoạch của GSD mang tính “từng bước”, để những phần phía sau không bị khóa cứng quá sớm.

Ví dụ trong thực tế là On-screen Interview Assistant — công cụ hỗ trợ phỏng vấn hiển thị trên màn hình. Đây là dạng sản phẩm mà UX rất khó hình dung trước khi thử dùng thật. Cách “ẩn mình” khi chia sẻ màn hình để không bị các nền tảng phát hiện cũng không thể đoán trước bằng lý thuyết.

Trên thực tế, những dạng “công cụ lạ” ít tiền lệ trên thị trường luôn đòi hỏi nhiều vòng thử rồi sai. GSD tỏa sáng trong chính kiểu bài toán đó: không ép bạn “phải biết hết ngay từ đầu”, mà giúp bạn thử nghiệm có cấu trúc cho đến khi tìm được hướng đúng.

---

So sánh GSD với Bmad và SuperPowers: là bộ ba framework phục vụ ba kiểu dự án khác nhau

So sánh GSD, Bmad và SuperPowers là cách nhanh nhất để hiểu “nên dùng GSD khi nào.” Mỗi framework được sinh ra cho một kiểu dự án khác nhau, đặc biệt về mức độ chắc chắn của yêu cầu và rủi ro khi sai sót.

Bmad: là framework lên kế hoạch chi tiết trước, phù hợp dự án yêu cầu đã rất rõ

Bmad là framework phát triển theo từng bước với tài liệu cực kỳ chi tiết trước khi code. Nó phát huy sức mạnh khi bạn đã biết rõ mình sẽ xây gì và cấu trúc sản phẩm ít thay đổi trong suốt quá trình.

Bmad có cả “bộ phận” tương tự research, business analyst, design thinking được mô hình hóa trong prompt. Bạn có thể đưa vào đủ loại góc nhìn (kinh doanh, thiết kế, kỹ thuật) để mổ xẻ sản phẩm trước khi động đến dòng code nào. Loại dự án hợp nhất với Bmad gồm CRM tùy chỉnh cho doanh nghiệp, nền tảng nội bộ có quy trình chặt chẽ, hay hệ thống mà yêu cầu đã rõ và ít thay đổi.

Điểm mạnh lớn của Bmad: “khung” prompt rất chặt, agent khó thoát khỏi phạm vi được thiết kế, nên độ ổn định cao khi yêu cầu không đổi.

Tuy nhiên, khi yêu cầu buộc phải thay đổi, Bmad bắt đầu lộ nhược điểm. Khi sửa yêu cầu, hệ thống dễ trở nên “lung lay” vì quá nhiều thứ đã được khóa vào tài liệu ban đầu. Việc tài liệu hóa mọi thứ trước khi làm cũng tốn rất nhiều thời gian, nhất là với dự án mang tính khám phá.

Theo trải nghiệm của tôi, nếu bạn biết 90% sản phẩm ngay từ đầu, Bmad là “vũ khí hạng nặng” rất hữu dụng. Nhưng nếu bạn mới chỉ biết 50–60%, nó có thể trở thành gánh nặng.

SuperPowers: là framework dựa trên TDD, hợp với hệ thống có rủi ro sai sót rất cao

SuperPowers dựa trên TDD (Test-Driven Development) — viết test trước, rồi mới code. Triết lý cốt lõi là: bạn đã biết rất rõ mình sẽ xây cái gì, và sai một chút ở edge case cũng có thể gây thiệt hại lớn.

Nó phù hợp khi bạn xây nền tảng AI agent tự động thao tác với hệ thống thật thay mặt người dùng, hoặc khi sai sót có thể gây mất tiền, lộ dữ liệu nhạy cảm, hay phá vỡ quy trình quan trọng. Ở đây, test được viết trước nên kế hoạch khó thay đổi nhiều về sau. Điều này tốt cho độ an toàn, nhưng kém linh hoạt khi muốn thử nghiệm.

Điểm thú vị là GSD và SuperPowers không loại trừ nhau. Chiến lược kết hợp rất thực tế: dùng GSD để nhanh chóng dựng V1, tìm ra hướng đúng, khóa lại những tính năng cốt lõi. Sau đó dùng SuperPowers để tăng độ bao phủ kiểm thử và siết chất lượng cho giai đoạn ổn định.

GSD: là lựa chọn tối ưu khi yêu cầu còn dao động và cần nhiều thử nghiệm

Trong bộ ba, Bmad chắc chắn và chặt nhưng nặng về tài liệu trước. SuperPowers an toàn và ưu tiên test, phù hợp hệ thống rủi ro cao. GSD linh hoạt, ưu tiên thử nghiệm và điều chỉnh.

Nếu bạn đang làm một sản phẩm mà sau vài tuần nói chuyện với người dùng thì roadmap có thể đổi khá nhiều, GSD gần như là lựa chọn tự nhiên nhất.

---

Kiến trúc kỹ thuật GSD: là mô hình sub-agent song song và tài liệu XML để bảo vệ ngữ cảnh

Kiến trúc kỹ thuật GSD là hạ tầng giúp nó giữ được độ tập trung của agent trong các dự án lớn, dài hơi. Ba trụ cột chính là sub-agent tách biệt, prompt XML, và quản lý ngữ cảnh có chủ đích.

Sub-agent song song: là cách GSD tránh “ô nhiễm ngữ cảnh”

Sub-agent trong GSD là những agent con đảm nhiệm từng phần việc riêng, chạy như các quy trình độc lập song song với agent chính. Mục tiêu là giữ context window của agent chính sạch, chỉ chứa những gì thật sự quan trọng, và tránh “context rot” — hiện tượng ngữ cảnh bị loãng, nhiễm quá nhiều thông tin phụ khi làm việc lâu.

Trong các dự án phức tạp, agent rất dễ “quên” mục tiêu ban đầu nếu ngữ cảnh cứ được nhồi thêm vô hạn. GSD giải quyết điều này ở cấp kiến trúc, không chỉ ở prompt.

Kết quả thử nghiệm cho thấy điều này rất thực tế. Tôi đã thử cách “tất cả trong một agent” ở nhiều dự án, và gần như luôn kết thúc bằng tình trạng agent bắt đầu đưa ra quyết định mơ hồ sau vài chục lượt trao đổi. Mô hình sub-agent tách riêng là một bước tiến quan trọng để giải quyết vấn đề này.

Cấu trúc XML: là định dạng chỉ dẫn giúp Claude hiểu và tuân thủ tốt hơn

Không giống đa số framework dùng Markdown cho prompt, GSD dùng XML để cấu trúc toàn bộ chỉ dẫn. Lý do khá thực dụng: dòng Claude (Opus, Sonnet) hiểu cấu trúc XML tốt và tuân thủ chỉ dẫn dạng có cấu trúc tốt hơn. Các phần “role”, “task”, “rules”, “tools” được đánh dấu rõ, nên agent ít bị nhầm lẫn hơn.

Khi cài đặt GSD, nếu dùng trong Claude Code thì framework được đặt dạng “hook” lệnh agent bên trong thư mục Claude. Nếu không, nó nằm trong thư mục agents ở root dự án. Cách đóng gói này cho phép bạn đổi model hoặc môi trường mà không phải viết lại toàn bộ logic điều phối.

Quản lý ngữ cảnh: là chiến lược cố ý rút gọn tài liệu lõi, dựa vào tài liệu theo giai đoạn

GSD áp dụng chiến lược khá cụ thể cho ngữ cảnh. Tài liệu lõi (project.md) trong thư mục planning luôn được giữ ngắn và tập trung: chỉ chứa mô tả ngắn, phạm vi, phần ngoài phạm vi, ràng buộc, và các quyết định quan trọng. Mọi tiến trình, lịch sử, chi tiết được trải ra trong các tài liệu theo giai đoạn và trong Git.

Trước mỗi lần commit Git, GSD chạy một loạt script kiểm tra và chỉ commit khi đạt chuẩn. Trong thử nghiệm, toàn bộ một vòng lặp phát triển tiêu tốn khoảng 138.000 token, trong khi Claude Opus cho phép tới 1.000.000 token. Tức là ngay cả với cách tiếp cận chia nhỏ và nhiều tầng kiểm tra, GSD vẫn không “đốt” context quá mức cần thiết.

---

Quy trình làm việc thực tế GSD: là chuỗi bước từ khởi tạo, nghiên cứu song song đến các “wave” thực thi

Quy trình GSD là điểm khiến tôi thấy framework này khác hẳn khi trải nghiệm. Nó vừa có cấu trúc rõ ràng, vừa không khóa chặt bạn vào một kế hoạch duy nhất từ đầu.

Giai đoạn khởi tạo: là bước thiết lập dự án, thu thập thông tin và hiểu bài toán

Quy trình bắt đầu bằng lệnh New Project. Agent khảo sát codebase hiện tại, hỏi bạn có muốn mapping codebase hay bỏ qua nếu đã có mã. Sau đó, GSD đặt một loạt câu hỏi về ý tưởng app, người dùng mục tiêu, tính năng cốt lõi và phạm vi dự án.

So với SuperPowers, nội dung hỏi ở đây ít nhắm vào “edge case sẽ làm hỏng hệ thống ở đâu”, mà thiên về hiểu rõ mình sẽ xây cái gì ở mức V1.

Giai đoạn nghiên cứu song song: là bước dùng nhiều sub-agent để khám phá bối cảnh

Khi đủ thông tin, GSD chuyển sang giai đoạn research chạy song song. Nhiều sub-agent cùng lúc nghiên cứu các khía cạnh khác nhau của app, tất cả chạy nền mà không làm “ngợp” bạn bằng quá nhiều tương tác.

Khi research xong, một Research Synthesizer agent nén và tổng hợp kết quả, đồng thời đánh dấu các vấn đề tiềm ẩn. Điểm đáng chú ý là những tác vụ nặng mới dùng model mạnh như Opus, còn tác vụ nhẹ như tổng hợp chỉ dùng Sonnet để tiết kiệm chi phí.

Khi đội nhóm áp dụng chiến lược “chọn model theo trọng lượng tác vụ”, chi phí AI giảm đáng kể mà hiệu quả không thay đổi. GSD coi đây là một phần mặc định trong kiến trúc, không phải thứ bạn phải tự nghĩ ra sau.

Giai đoạn yêu cầu & roadmap: là bước chắt lọc MVP và chia nhỏ thành các wave

Trong giai đoạn Requirements, GSD tập trung đặt câu hỏi để bóc tách đúng mức MVP thực sự cần gì cho V1, loại bỏ những thứ “nên có” nhưng không bắt buộc cho lần ra mắt đầu.

Khi bạn chấp nhận tập tính năng MVP này, GSD tạo ra một cấu trúc roadmap. Thời điểm bạn ấn nút “đồng ý” chính là khi dự án được coi là đã khởi tạo xong. Giai đoạn lập kế hoạch có hai loại agent tách biệt: Planning Agent thiết kế kế hoạch chi tiết, còn Validation Agent liên tục rà soát và trả về cảnh báo.

Đây là cơ chế “adversarial review” — hai agent với vai trò khác nhau tự động tranh luận và kiểm tra lẫn nhau, không cần bạn phải micromanage từng bước.

Kế hoạch cuối cùng được chia thành nhiều wave độc lập ở mức độ nhiệm vụ. Các nhiệm vụ đủ độc lập sẽ được sub-agent xử lý song song để tăng tốc độ.

Giai đoạn thực thi: là quá trình mỗi wave được triển khai và kiểm chứng từng bước

Mỗi wave có một agent triển khai chính, đi theo đúng kế hoạch đã được thông qua. Khi hoàn tất, agent chạy các kiểm thử Playwright phù hợp để tạo checkpoint kỹ thuật, rồi tóm tắt kết quả theo dạng dễ cho con người rà soát.

Wave đầu tiên tạo ra một phiên bản app dạng placeholder — mọi thành phần đã có “khung” nhưng nhiều chức năng còn là giả lập. Các vòng lặp sau dần thay placeholder bằng tính năng thực hoạt động đầy đủ. Ở cuối mỗi vòng, validation agent kiểm tra lại xem kết quả còn bám sát mục tiêu ban đầu không.

Đây là cách kết hợp tốt giữa tốc độ (ra được bản chạy được rất sớm) và kiểm soát (mỗi bước đều có checkpoint kỹ thuật và checkpoint mục tiêu).

---

Hạn chế của GSD và vai trò của Context7 MCP: là lớp bảo vệ nghiên cứu tài liệu chính xác hơn

GSD không hoàn hảo. Có một điểm yếu quan trọng trong giai đoạn research: cách tham chiếu tài liệu chính thức.

Thay vì kết nối trực tiếp tới tài liệu chính thức hay một nguồn kiểm soát được, GSD trong thử nghiệm dùng web search bình thường, thậm chí thêm từ khóa “2025” vào truy vấn để tìm thông tin “mới nhất.” Cách làm này dễ dẫn đến việc dùng tài liệu không chính xác hoặc bị ảnh hưởng bởi nội dung “SEO tốt nhưng không chuẩn.”

Giải pháp được khuyến nghị là tích hợp Context7 MCP — một MCP server cho phép truy xuất tài liệu chính thức (ví dụ documentation của thư viện, framework) theo thời gian thực. Khi kết nối GSD với Context7, lớp research sạch hơn, dựa trên nguồn có kiểm soát, và ít lệ thuộc vào search ngẫu nhiên trên web.

Điều này đặc biệt quan trọng với framework cập nhật nhanh như Next.js hay React. Một thay đổi nhỏ trong version mới có thể làm hỏng cả app nếu agent vẫn dựa vào tài liệu cũ.

Bên cạnh đó, GSD không phù hợp cho mọi dự án. Với một app đơn giản như landing page, form cơ bản hay một tích hợp dịch vụ nhẹ, chỉ cần một agent Claude là đủ.

GSD nên được xem như “khung quản lý dự án AI” cho các app nhiều tính năng, nhiều module liên quan, nơi bạn muốn có kế hoạch đủ bài bản nhưng vẫn linh hoạt.

Nếu dự án chỉ tốn vài file code, việc dựng cả GSD sẽ tốn thời gian hơn là lợi ích nó mang lại. Nhưng nếu bạn xây một SaaS nhiều module cho thị trường Việt Nam — kết nối Shopee, Tiki, Zalo OA cùng lúc — GSD bắt đầu cho thấy giá trị rõ rệt.

---

Hướng dẫn chọn framework: là bản đồ ra quyết định giữa GSD, Bmad, SuperPowers và custom framework

Lựa chọn framework đúng có thể quyết định 50% thành bại của dự án AI agent. Trục quyết định dựa trên hai yếu tố: độ chắc chắn của yêu cầu và mức độ cần thử nghiệm.

Khi nào nên dùng Bmad, GSD, SuperPowers?

Bmad phù hợp khi yêu cầu gần như chắc chắn, cấu trúc hệ thống khó thay đổi, và cần tài liệu hóa kỹ càng từ đầu. Ví dụ: CRM tùy chỉnh cho doanh nghiệp lớn tại Việt Nam, nền tảng quản lý nội bộ có quy trình cố định.

GSD phù hợp khi yêu cầu còn dao động, cần thử nghiệm nhiều ở từng bước, và cần MVP chạy được nhanh để test với người dùng thật.

SuperPowers phù hợp khi edge case bị bỏ sót sẽ gây hậu quả nặng (mất tiền, lỗi giao dịch, lộ dữ liệu), và khi hệ thống là nền tảng cốt lõi chứ không phải một tính năng phụ.

Ranh giới này thực tế hơn lý thuyết. Tích hợp Stripe vào một app Next.js nhỏ có thể không cần SuperPowers. Nhưng nếu bạn xây nền tảng AI tự động điều phối thanh toán cho nhiều bên, SuperPowers trở nên rất cần thiết.

Chiến lược kết hợp và khả năng tự xây framework riêng

Các framework này không loại trừ nhau. Một chiến lược thực tế: dùng GSD để xây nhanh bản V1 giàu tính thử nghiệm, khi tính năng ổn định thì đưa SuperPowers vào để nâng mức đảm bảo chất lượng, rồi với các module ít thay đổi về sau thì chuyển sang Bmad.

Nếu không framework nào đáp ứng đủ, tự xây custom framework cũng là lựa chọn hợp lý. Nhưng điều kiện là phải hiểu rất rõ rằng framework tốt là framework được thiết kế cho đúng loại dự án. Không hiểu điều này, custom framework rất dễ trở thành một phiên bản Bmad hoặc GSD tệ hơn.

Tôi thường khuyên các nhóm ở Việt Nam bắt đầu bằng hai câu hỏi đơn giản: yêu cầu có chắc hay không, và nếu sai thì hậu quả lớn đến mức nào? Trả lời hai câu này sẽ tự dẫn tới framework phù hợp.

---

Claude mới và GSD: là chiến lược phát triển trong kỷ nguyên 1M token context

Claude Opus 4.6 với 1.000.000 token context window là một bước nhảy lớn cho phát triển dựa trên AI agent. Nhiều kỹ thuật nén ngữ cảnh tinh vi từng rất quan trọng nay không còn “sống còn” như trước.

Một vòng lặp GSD sử dụng khoảng 138.000 token, tương đương khoảng 14% context của Opus. Với con số này, áp lực tối ưu context giảm đi rất nhiều. Nhưng chiến lược tài liệu theo giai đoạn của GSD vẫn cực kỳ giá trị vì hai lý do thực tế.

Thứ nhất, không phải môi trường nào cũng có 1M token — nhiều agent phụ vẫn chỉ có 200k hoặc thấp hơn. Thứ hai, kể cả khi context lớn, “đổ hết mọi thứ vào” vẫn khiến agent khó tập trung vào phần quan trọng.

GSD giải quyết vấn đề bằng cấu trúc: mỗi giai đoạn có tài liệu rõ ràng, nên kể cả khi phải “reset” context, agent vẫn biết phải bắt đầu lại từ đâu.

Chiến lược chọn model theo tác vụ (Opus cho việc phức tạp, Sonnet cho việc nhẹ) còn giúp tối ưu chi phí đáng kể. Với các dự án kéo dài nhiều vòng lặp, chênh lệch giữa “dùng toàn Opus” và “trộn Opus/Sonnet hợp lý” là rất lớn.

Khi dùng Claude Code kết hợp framework có kiến trúc rõ như GSD, cảm giác gần giống làm việc với một team dev thật có tech lead, QA, BA — chứ không chỉ là “một con chatbot thông minh viết code.” Sự bổ trợ giữa model mạnh và framework có cấu trúc tạo ra khác biệt rất lớn so với việc chỉ có một trong hai.

---

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

Q: Khi nào nên chọn GSD thay vì Bmad hoặc SuperPowers?

A: GSD phù hợp khi yêu cầu dự án còn nhiều điểm chưa rõ, cần thử nghiệm liên tục và cần ra MVP nhanh. Nếu yêu cầu đã chặt chẽ và ít thay đổi, Bmad tốt hơn. Nếu rủi ro sai sót rất lớn, nhất là về edge case, SuperPowers là lựa chọn ưu tiên.

Q: GSD có phù hợp cho các ứng dụng web đơn giản không?

A: Không hẳn. Với những app đơn giản, bạn thường chỉ cần một agent Claude hoặc một workflow nhẹ. GSD được thiết kế cho hệ thống nhiều tính năng, nhiều module, nơi cần mức độ tổ chức và kiểm chứng cao hơn nhưng vẫn giữ được tính linh hoạt.

Q: Lợi ích lớn nhất của kiến trúc sub-agent trong GSD là gì?

A: Lợi ích lớn nhất là bảo vệ ngữ cảnh của agent chính khỏi bị “ô nhiễm” và mất tập trung khi dự án phức tạp dần lên. Bằng cách tách các tác vụ ra cho sub-agent xử lý song song, GSD giúp agent chính luôn bám sát mục tiêu và không bị “đuối” trong biển thông tin phụ.

Q: Tại sao cần kết nối GSD với Context7 MCP?

A: Vì lớp research mặc định của GSD vẫn dựa nhiều vào web search chung, dễ gặp thông tin không chính xác. Kết nối với Context7 MCP cho phép GSD tham chiếu trực tiếp tài liệu chính thức — đặc biệt quan trọng với framework cập nhật nhanh như Next.js hay React.

Q: GSD có còn cần thiết trong thời đại 1M token context của Claude Opus 4.6 không?

A: Có. Dù context lớn giảm bớt áp lực nén ngữ cảnh, GSD vẫn mang lại giá trị qua cấu trúc tài liệu theo giai đoạn, cơ chế kiểm chứng nhiều tầng và kiến trúc sub-agent. Những yếu tố này giúp quá trình phát triển ổn định, có thể kiểm soát và dễ khởi động lại ở bất kỳ giai đoạn nào.

---

Kết luận

GSD không tự nhận là “framework AI coding tốt nhất.” Nó là framework đúng cho những dự án cần thử nghiệm nhiều, yêu cầu còn di động, nhưng vẫn cần một bộ khung đủ bài bản để không rơi vào hỗn loạn.

Những điểm đáng nhớ nhất: GSD ưu tiên “làm được thứ chạy được” hơn là cố dự đoán mọi chi tiết từ đầu. Kiến trúc sub-agent tách biệt và tài liệu XML giúp bảo vệ ngữ cảnh và tăng độ tuân thủ của agent. Khi đi cùng Claude Code với 1M token context, GSD tạo ra tổ hợp rất mạnh cho các app lớn, đa tính năng. Tích hợp Context7 MCP giúp bịt bớt lỗ hổng ở lớp research, nhất là với công nghệ cập nhật liên tục.

Trong vài năm tới, khi AI agent tham gia ngày càng sâu vào quy trình phát triển phần mềm, câu hỏi sẽ không còn là “dùng AI hay không” mà là “dùng AI trong kiến trúc nào để vẫn giữ được kiểm soát.” Ở câu hỏi đó, GSD là một câu trả lời đáng cân nhắc nghiêm túc.

---

Tham khảo thêm:

• Claude Models & API: https://docs.anthropic.com
• Model Context Protocol (MCP): https://modelcontextprotocol.io
• Playwright Testing: https://playwright.dev
• Khái niệm MVP (Minimum Viable Product): https://www.productplan.com/glossary/minimum-viable-product
• Giới thiệu Test-Driven Development (TDD): https://martinfowler.com/bliki/TestDrivenDevelopment.html