BMAD-METHOD

30 Best Claude Plugins on GitHub (Sorted by Your Job) 30 Claude plugins with 3.9 million GitHub stars between them, sorted into 5 rows so you only need yours: coding, research, saving tokens, design, and writing + video. Don't add all 30. Pick the row that fits your week, add one plugin, and open its repo first to check what it can touch on your machine. 💬 Comment ANYLANCER and I'll send you all 30 links, or grab them here: 1) You write code • Superpowers: obra/superpowers • Matt Pocock's Skills: mattpocock/skills • ECC: affaan-m/ECC • Karpathy Skills: multica-ai/andrej-karpathy-skills • Ponytail: DietrichGebert/ponytail • Agent Skills: addyosmani/agent-skills 2) You research big things • Graphify: Graphify-Labs/graphify • Agent Reach: Panniantong/Agent-Reach • Understand Anything: Egonex-AI/Understand-Anything • Last 30 Days: mvanhorn/last30days-skill • Career Ops: career-ops-hq/career-ops • REA: morluto/rea 3) Huge projects, few tokens • gstack: garrytan/gstack • Caveman: JuliusBrussee/caveman • Claude-Mem: thedotmack/claude-mem • Headroom: headroomlabs-ai/headroom • GSD: gsd-build/get-shit-done • BMAD Method: bmad-code-org/BMAD-METHOD 4) Design & visuals • UI UX Pro Max: nextlevelbuilder/ui-ux-pro-max-skill • Taste: Leonxlnx/taste-skill • Archify: tt-a1i/archify • Impeccable: pbakaus/impeccable • PPT Master: hugohe3/ppt-master • Diagram Design: cathrynlavery/diagram-design 5) Writing & video • Anthropic Skills: anthropics/skills • OpenMontage: calesthio/OpenMontage • HyperFrames: heygen-com/hyperframes • Humanizer: blader/humanizer • I Have ADHD: ayghri/i-have-adhd • Marketing Skills: coreyhaines31/marketingskills Built a skill people would pay for? Sell it on Anylancer: anylancer.com Which row are you? 👇 Star counts from GitHub on Oct 29, 2026. This video was made with HyperFrames. #ClaudeCode #AIAgents #GitHub #Shorts

lets try bmad-code-org/bmad-method to make my vibe coding more efficient 😁 t.co

N-Zik: an open-source YouTube Music client for Android offline downloads, advanced lyrics, 30+ languages Hi everyone, I'd like to share N-Zik, an open-source (GPLv3) YouTube Music client for Android. It started as a fork of Kreate and grew into a community project, with performance improvements, UI/UX refinement, bug fixes, and new features built with long-term support in mind. What it does - Streams from YouTube Music premium quality unlocks automatically if you connect a YouTube Music Premium account - Offline: smart auto-caching + real downloads (individual tracks or whole playlists), with a dedicated download quality setting - Advanced lyrics: fetch, word-by-word sync, edit, and translate in real time - Song recognition (Shazam-like) and voice search - Available in 30+ languages via community translation (Crowdin) - Listening stats + a "Rewind" feature with yearly/monthly recaps - Listen Together: live listening sessions with friends (N-Zik is an officially supported MetroServer host) - Desktop companion app (Windows/Linux) to control your library and playback from your PC (very very early stage not mean for use rn) - Home-screen widgets, Android Auto/TV (still need improvements)/tablet support, Discord Rich Presence, last.fm scrobbling - Multi-profile, automatic settings + database backup, parental controls, hidden songs Where to get it - GitHub (all builds: 64/32-bit, FOSS, and minified builds for low-end devices): github.com/N-Zik-Group/N-Zik/releases - F-Droid (FOSS build): f-droid.org - Official website: n-zik.vercel.app - Discord: discord.gg Honest notes - N-Zik may not be as stable as the original Kreate yet. If you need a more mature option, Metrolist, VIVI Music, or RiPlay are solid alternatives. - It's a side project that grew bigger than expected. I use generative AI to assist with the code (structured with the BMAD Method), but everything gets reviewed and tested before it's pushed not shipping blind. - The project has no affiliation with YouTube or Google LLC. - i'm currently restructured release, new build aren't out yet still finishing other issue If you try it, I'd love to hear what works and what doesn't feedback and issues are very welcome on GitHub.

Superpowers, BMAD, Spec Kitty: framework จัดทีม agent ใช้จริงหนักแค่ไหน? โดย Nokka (นก-กา) | ตอนที่ 4 ของซีรีส์เปรียบเทียบเครื่องมือ SDD | ตรวจข้อมูล 24 ต.ค. 2026 บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา) !ภาพเปิด: ทีมช่างฝีมือยืนล้อมโต๊ะไม้ยาว แต่ละคนถือเครื่องมือคนละอย่าง framework ต่างจากเครื่องมือสองตอนก่อนอย่างไร ตอนที่ 2 คือเครื่องมือที่ให้โครงเอกสารและคำสั่ง ส่วนตอนที่ 3 คือผลิตภัณฑ์ที่ขายประสบการณ์สำเร็จรูป ตอนนี้คือของกลางทาง คือ ชุดวิธีทำงานที่ติดตั้งเป็นสกิลให้ agent แล้วบังคับให้มันทำงานเป็นขั้นตอน คล้ายมีหัวหน้าทีมคอยสั่ง ความต่างที่สำคัญคือมันไม่ได้ให้แค่แม่แบบ spec แต่กำหนดว่าใครทำอะไร เมื่อไร และรีวิวกันแบบไหน ผลคือถ้าทีมคุณยังไม่มีกระบวนการ framework จะกลายเป็นกระบวนการแทนคุณ ซึ่งดีหรือไม่ดีขึ้นกับขนาดงาน Superpowers: วิธีทำงานทั้งชุดในรูปสกิล Superpowers เป็นโครงการที่โตที่สุดในกลุ่มนี้ 304,296 ดาว ใบอนุญาต MIT และ push ล่าสุด 23 ต.ค. 2026 [1] แนวคิดคือแทนที่จะให้ agent ลงมือเขียนโค้ดทันที มันจะถามกลับก่อนว่าคุณกำลังทำอะไรจริง ๆ แล้วค่อย ๆ สกัดข้อกำหนดออกมาเป็นท่อนสั้นพอให้อ่านไหว [2] จากนั้นจึงสร้างแผนงานที่ละเอียดพอให้วิศวกรจูเนียร์ที่ไม่มีบริบทของโปรเจกต์ทำตามได้ และแบ่งงานให้ subagent ทำงานแบบเขียนเทสต์ก่อน แล้วมีคนรีวิว [2] จุดที่ผมประทับใจคือมันรองรับ host เยอะมาก ตั้งแต่ Claude Code, Codex, Cursor, Gemini CLI ไปจนถึง Hermes Agent และ Kimi Code [2] สิ่งที่ต้องแลกมา - ต้องตอบคำถามเยอะในตอนเริ่ม ซึ่งช้าสำหรับงานเล็ก - มี issue ค้างราว 354 รายการ [1] แปลว่าชุมชนใหญ่จนคำขอฟีเจอร์ วิ่งเร็วกว่าคนดูแล - ถ้าทีมมีกระบวนการอยู่แล้ว การเอา framework เข้ามาทับจะทำให้เกิดสองระบบที่ขัดกัน BMAD: องค์กรจำลองในกล่อง BMAD Method หรือชื่อเต็มคือ BMad Method วางตัวเป็นวิธีทำ agile ที่ขับด้วย AI โดยแบ่งงานเป็นวงจร Clarify, Plan, Build and verify แล้วย้อนกลับมา Learn and adjust [3] จุดขายคือมันปรับขนาดตามงาน งานเล็กเข้า Build ตรง ๆ งานใหญ่ได้ความลึกตามที่ต้องการ และมีบทบาทสมมติอย่างนักวิเคราะห์ผลิตภัณฑ์ สถาปนิก และผู้ตรวจสอบคุณภาพ เวอร์ชันที่หน้า repo ระบุคือ v6.12 เป็นรุ่นเสถียร ส่วน v7 อยู่ระหว่างพรีวิวและประกาศกรอบเวลาไว้ว่าประมาณ 16 ต.ค. 2026 [3] ซึ่ง ณ วันที่ผมเขียน บล็อกนั้นยังไม่ปรากฏรุ่น v7 ในหน้า release จึงควรถือว่ายังไม่พร้อมใช้ เรื่องใบอนุญาตที่ต้องระวัง README ของ BMAD ติดป้ายว่า MIT แต่ GitHub API รายงานใบอนุญาตเป็น NOASSERTION [1] ซึ่งหมายถึงระบบตรวจไม่พบไฟล์ใบอนุญาตที่ตรงมาตรฐาน ผมเปิดไฟล์ LICENSE ใน repo แล้วพบว่าข้อความข้างในเป็น MIT License ของ BMad Code, LLC [3] แปลว่า NOASSERTION น่าจะมาจากระบบตรวจที่ไม่รู้จักรูปแบบไฟล์ ไม่ใช่การละเมิดสัญญาอนุญาต ถึงอย่างนั้นถ้าจะใช้ในองค์กร ก็ควรให้ฝ่ายกฎหมายเปิดอ่านเองอีกรอบ เพราะความรับผิดชอบอยู่ที่ผู้นำไปใช้ ไม่ใช่ที่ป้ายบนหน้า repo ใครเหมาะ ทีมที่มีคนอยากได้บทบาทชัดเจน และยอมให้ framework กำหนดลำดับงาน ข้อควรระวัง - ต้องติดตั้ง uv และสคริปต์ Python เพิ่ม [3] - บทบาทสมมติหลายบททำให้มีเอกสารหลายชั้น ซึ่งทีมเล็กอาจรู้สึกหนักเกินงาน - การอยู่ในช่วงเปลี่ยนรุ่นใหญ่ ทำให้เอกสารสองชุดปนกันได้ง่าย Spec Kitty: โรงงานที่มีประตูอนุมัติ Spec Kitty นิยามตัวเองว่าเป็น CLI สำหรับสร้างโรงงานซอฟต์แวร์ คือมีลำดับ spec, plan, tasks, next, review, accept, merge และเก็บสถานะทั้งหมดไว้ใน repo [4] จุดเด่นคือ worktree แยกต่อหนึ่งงาน ทำให้ agent หลายตัวทำงานขนานได้โดยไม่ชนกันใน branch เดียว และมีประตูอนุมัติให้คนตัดสินก่อน merge [4] รองรับ agent หลายค่าย ทั้ง Claude Code, Codex, Cursor, Gemini, GitHub Copilot, Windsurf และ OpenCode [4] ตัวเลขที่ต้องอ่านให้ดี 1,700 ดาว และมี issue เปิดค้าง 1,030 รายการ [1] ซึ่งเป็นอัตราส่วนที่สูงมาก ตัวเลขนี้ไม่ได้แปลว่าเครื่องมือไม่ดี แต่มันบอกว่าคำถามและข้อบกพร่องเข้ามาเร็วกว่ากำลังคนดูแล และรุ่น 4.0 ยังเป็น release candidate [4] ถ้าทีมคุณไม่มีคนรับผิดชอบเรื่องเครื่องมือโดยเฉพาะ การเจอ issue ที่ยังไม่มีคำตอบจะเป็นประสบการณ์ปกติ ไม่ใช่ข้อยกเว้น กรณีศึกษาที่ควรจำ: ดาวหกหมื่นกับ repo ที่ถูกเก็บเข้ากรุ ในตอนที่ 2 ผมพูดถึง get-shit-done ซึ่งมี 64,236 ดาวแต่ถูก archive ไปแล้ว [1] ผมยกมาซ้ำเพราะมันเป็นภาพที่คนทำ SDD ควรเห็นบ่อย ๆ คือเครื่องมือที่ดูยิ่งใหญ่ที่สุดอาจหยุดพัฒนาไปแล้ว โดยที่บทความและวิดีโอเก่ายังแนะนำอยู่ ก่อนติดตั้งอะไรทุกครั้ง ให้เปิดหน้านั้นดูสามอย่าง คือ archived หรือไม่ push ล่าสุดเมื่อไร และ issue ค้างเท่าไร [1] เทียบกับเกณฑ์หกข้อจากตอนที่ 1 - จุดเริ่มที่ถนัด: Superpowers ถนัดงานใหม่ที่ยังไม่มีข้อกำหนด · BMAD ครอบทั้งงานเล็กและใหญ่ · Spec Kitty ถนัดงานที่ต้องรันขนานหลายชิ้น - สิ่งที่ถูกบังคับใช้จริง: ทั้งสามบังคับผ่านสกิลและประตูอนุมัติ แต่ Spec Kitty บังคับถึงระดับ merge - การเชื่อมกับ agent: Superpowers กว้างที่สุด · BMAD และ Spec Kitty รองรับหลายตัวแต่เน้น Claude Code - ร่องรอยตรวจสอบ: Spec Kitty เก็บสถานะครบที่สุด เพราะออกแบบมาเพื่อ audit - ภาระที่เพิ่มให้ทีม: สูงทั้งสามตัว บทความนี้จึงไม่แนะนำให้เริ่มจากที่นี่ถ้าทีมยังไม่เคยเขียน spec - สุขภาพของโครงการ: Superpowers แข็งแรงที่สุด · BMAD กำลังเปลี่ยนรุ่นใหญ่ · Spec Kitty มี issue ค้างมาก ลำดับที่ผมแนะนำให้ลอง สำหรับทีมที่ยังไม่เคยทำ SDD ผมไม่แนะนำให้เริ่มจาก framework เพราะคุณจะสับสนว่าปัญหาอยู่ที่กระบวนการหรือที่เครื่องมือ ลำดับที่ผมคิดว่าได้ผลกว่าคือ เขียน spec ด้วยเครื่องมือเบาจากตอนที่ 2 สองถึงสามสัปดาห์ แล้วค่อยถามว่าอะไรที่ยังเจ็บ - ถ้าเจ็บที่ agent ไม่ทำตามแผน → framework ช่วยได้ - ถ้าเจ็บที่งานขนานชนกัน → Spec Kitty หรือ Conductor - ถ้าเจ็บที่ข้อกำหนดไม่ชัด → ปัญหาอยู่ที่การเขียน ไม่ใช่เครื่องมือ คำถามที่ควรถามก่อนเลือก framework 1. ทีมมีคนรับผิดชอบดูแลเครื่องมือนี้หรือยัง 2. งานส่วนใหญ่เป็นงานเดี่ยวหรือขนานกันหลายสาย 3. ถ้า framework กำหนดบทบาทของทีมใหม่ คุณยอมเปลี่ยนวิธีทำงานหรือไม่ ถ้าข้อสามตอบว่าไม่ คุ้มกว่าที่จะหยิบแค่บางสกิลมาใช้ ไม่ต้องยกทั้งชุด ภาพที่ผมเห็นในหัว ยกตัวอย่างให้เห็นภาพ คือทีมช่างห้าคนที่ทำงานในโรงงานเดียวกัน ถ้าไม่มีใครกำหนดว่าใครทำอะไร ทั้งห้าคนจะหยิบเครื่องมือเดียวกันพร้อมกัน และชนกันที่โต๊ะตัวเดียว framework คือคนที่กำหนดว่าใครยืนตรงไหนและส่งงานต่อให้ใคร แต่ถ้าโรงงานของคุณมีงานชิ้นเดียว การจ้างคนมาคุมห้าคนจะกลายเป็นต้นทุนที่ไม่ได้ช่วยอะไร เหมือนซื้อระบบจัดการคลังสินค้าสำหรับของสามชิ้น ตอนต่อไป ตอนที่ 5 คือตอนที่ผมรวบทุกอย่างมาเป็นแผนตัดสินใจ พร้อม checklist สองสัปดาห์และกับดักที่ทำให้โครงการ SDD ล้ม ซึ่งเป็นส่วนที่ผมคิดว่ามีค่าที่สุดในซีรีส์นี้ REF [1] GitHub REST API, ข้อมูล repository ของ obra/superpowers, bmad-code-org/BMAD-METHOD, spec-kitty/spec-kitty, gsd-build/get-shit-done, สืบค้น 24 ต.ค. 2026 (ดาว ใบอนุญาต วันที่ push และจำนวน issue). api.github.com [2] obra, "Superpowers README", สืบค้น 24 ต.ค. 2026 (วิธีทำงาน ตั้งแต่ถามความต้องการจนถึง subagent และรายชื่อ host ที่รองรับ). obra/superpowers [3] bmad-code-org, "BMAD-METHOD README", สืบค้น 24 ต.ค. 2026 (วงจร Clarify, Plan, Build, Learn · v6.12 · v7 preview · ต้องใช้ uv). bmad-code-org/BMAD-METHOD [4] spec-kitty, "Spec Kitty README", สืบค้น 24 ต.ค. 2026 (ลำดับ spec ถึง merge · worktree แยกต่องาน · รายชื่อ agent ที่รองรับ · สถานะ 4.0 RC). spec-kitty/spec-kitty

ต้นทุน ความเสี่ยง และคนที่ต้องเซ็นรับ: สแตกไหนเหมาะกับทีมขนาดไหน? โดย Nokka (นก-กา) | ตอนที่ 7 จาก 7 ของชุด "สร้างซอฟต์แวร์ด้วย AI" | ตรวจสอบข้อมูล ณ 23 ต.ค. 2026 บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา) หกตอนที่ผ่านมาพูดถึงเครื่องมือและวิธีต่อมันเข้าด้วยกัน บทนี้จะพูดถึงปัจจัยที่ตัดสินว่าจะใช้ต่อได้หรือไม่ คือเงิน ความเสี่ยง และคนที่รับผิดชอบ ผมจะไม่ให้ตัวเลขค่าถูก ๆ ต่อโทเคน เพราะราคาเปลี่ยนทุกเดือนและแต่ละผู้ให้บริการคิดไม่เหมือนกัน บทนี้จึงให้วิธีคำนวณและจุดที่ต้องตั้งเพดาน ซึ่งใช้ได้ไม่ว่าราคาจะเปลี่ยนไปแค่ไหน ต้นทุนจริงของ agent หนึ่งงาน อยู่ที่จำนวนรอบ ไม่ใช่ราคาต่อโทเคน วิธีวัดที่ผมแนะนำ ทุกครั้งที่ agent วนอีกรอบ มันส่งบริบทที่โตขึ้นเข้า LLM ใหม่ทั้งก้อน งานหนึ่งงานที่มีการอ่านไฟล์สิบไฟล์และรันเทสต์ห้ารอบ อาจใช้โทเคนมากกว่าการแชตถามตอบปกติหลายสิบเท่า ตัวคูณที่แท้จริงคือจำนวนรอบ คูณด้วยขนาดบริบทที่โตขึ้นในแต่ละรอบ วิธีที่ผมใช้คือบันทึกสามค่าต่อ task ได้แก่ จำนวนรอบ โทเคนขาเข้า และโทเคนขาออก เมื่อมีข้อมูลสามค่านี้สิบงาน คุณจะรู้ว่าทีมคุณใช้งบต่อ task ประมาณเท่าไร และควรตั้งเพดานไว้ที่เท่าไร ถ้าไม่วัดเลย บิลจะโตแบบอธิบายไม่ได้ และไม่มีใครรู้ว่าต้นเหตุอยู่ที่งานไหน ตัวอย่างรูปแบบบันทึกที่ผมใช้ (สมมติขึ้นเพื่อให้เห็นภาพ) task: fix-issue-142 rounds: 7 input_tokens: 412000 output_tokens: 18000 estimated_cost: คำนวณจากราคาต่อโทเคนของผู้ให้บริการ ณ วันนั้น outcome: tests passed บรรทัดสุดท้ายสำคัญไม่แพ้ตัวเลข เพราะงานที่แพงแต่ไม่ผ่านจะทำให้ค่าเฉลี่ยต่อ task ที่สำเร็จสูงกว่าที่เห็น ความเสี่ยงที่หนึ่ง คือ prompt injection ผ่าน issue และ pull request ช่องทางที่พบบ่อยในทีมจริง ถ้า agent อ่าน issue หรือคอมเมนต์บน PR ได้ คนนอกสามารถเขียนข้อความที่สั่งให้ agent ทำสิ่งอื่นได้ OWASP จัดเรื่องนี้เป็นความเสี่ยงอันดับหนึ่งของระบบที่ใช้ LLM คือ LLM01 Prompt Injection [1] ในทางปฏิบัติ ช่องทางที่พบบ่อยคือ - issue ที่มีข้อความซ่อนคำสั่ง เช่น บอกให้อ่านไฟล์ secrets แล้วใส่ในคอมเมนต์ - ชื่อไฟล์หรือข้อความในโค้ดที่ agent อ่านเข้าไป แล้วตีความเป็นคำสั่ง - ผลลัพธ์จากเครื่องมือภายนอก เช่น หน้าเว็บที่ agent เปิดอ่าน วิธีลดความเสี่ยงที่ได้ผลจริงคือ จำกัดสิทธิ์ของ token ให้แคบ ประกาศ permissions: ให้ชัด และห้าม agent อ่านค่าความลับ [2] อีกข้อที่สำคัญคือ action ที่รันจาก pull request ของคนนอกได้สิทธิ์แบบอ่านอย่างเดียวเป็นค่าเริ่มต้น ซึ่งช่วยได้มาก แต่เจ้าของ repo เปลี่ยนค่านี้ได้ด้วยตัวเลือกที่อนุญาตให้ workflow จาก fork รันด้วยสิทธิ์เขียน และเอกสารความปลอดภัยของ GitHub ไม่ได้รับรองว่าปลอดภัยในทุกกรณี [2][8] ความเสี่ยงที่สอง คือสัญญาอนุญาต เครื่องมือในซีรี่ส์นี้มีสัญญาอนุญาตหลายแบบ และบางแบบมีผลกับวิธีที่คุณใช้ในบริษัท - Qodo Cover เป็น AGPL-3.0 ซึ่งเป็นสัญญาแบบ copyleft ที่เข้มกว่า GPL และมีผลเมื่อให้บริการผ่านเครือข่าย [3][4] - Actions ส่วนใหญ่ที่ผมใช้เป็น MIT แต่ gitleaks-action มีสถานะ NOASSERTION ต้องเปิดไฟล์เอง [7] - BMAD ระบุ MIT ใน README แต่ GitHub จัดสถานะ NOASSERTION เช่นกัน [6] หลักที่ผมใช้คือ ถ้าเป็นเครื่องมือที่รันในเครื่องและไม่ได้ให้บริการต่อ ความเสี่ยงด้านสัญญาจะต่ำ แต่ถ้าคุณจะเอาไปประกอบเป็นบริการให้ลูกค้า ต้องให้ฝ่ายกฎหมายอ่านก่อนทุกครั้ง ความเสี่ยงที่สาม คือความรับผิดชอบเมื่อ agent ทำพัง คำถามนี้ไม่มีคำตอบทางเทคนิค แต่ต้องตอบให้ได้ก่อนใช้กับระบบจริง ถ้า agent ลบข้อมูลหรือใส่บั๊กที่ทำให้ลูกค้าเสียหาย ผู้รับผิดชอบคือคนที่อนุมัติให้ใช้ ไม่ใช่โมเดล นี่คือเหตุผลที่ผมยืนยันเรื่อง branch protection และการบังคับให้มีคนอนุมัติในตอนที่ 6 ไปป์ไลน์ที่ดีทำให้ความผิดพลาดถูกจับเร็ว แต่ไม่ได้ทำให้ใครพ้นความรับผิดชอบ สแตกสำหรับทีมคนเดียว ถ้าคุณทำงานคนเดียวและต้องการเริ่มแบบควบคุมได้ - agent ในเครื่องหนึ่งตัว ที่คุณดูอยู่ตลอด เช่น Claude Code หรือ Codex - git และ GitHub สำหรับเก็บประวัติ - pytest หรือ vitest พร้อม coverage ขั้นต่ำใน CI - ไม่ต้องมี Docker และไม่ต้องมี orchestrator ตั้งแต่ต้น จุดที่ต้องระวังคืออย่าให้ agent merge เอง เพราะไม่มีคนที่สองช่วยจับ สแตกสำหรับทีม 3 ถึง 5 คน - spec-kit สำหรับแปลง issue เป็น spec และ task [5] - agent หนึ่งตัวเป็นผู้เขียนหลัก และใช้ตัวเดียวกันรีวิวงานคนอื่น ไม่ใช่รีวิวงานตัวเอง - CI ที่มี lint, typecheck, test, coverage gate และ secret scan - mutation testing เฉพาะไฟล์ที่ถูกแก้ - คนอนุมัติอย่างน้อยหนึ่งคนที่ไม่ใช่คนเขียน PR สแตกนี้เพิ่มงานด้านกระบวนการชัดเจน แต่ลดโอกาสที่งานจะไปค้างเพราะไม่มีใครรู้ว่าใครทำอะไร สแตกสำหรับทีมที่ต้องผ่านการตรวจสอบ - แยกสภาพแวดล้อมสำหรับ agent ออกจากเครื่องที่เข้าถึงข้อมูลจริง - เก็บ log ของทุก task ทั้งคำสั่งและผลลัพธ์ - จำกัดสิทธิ์ของ token ตามหลัก least privilege และไม่ให้ agent เห็นค่าความลับ - กำหนดเพดานค่าใช้จ่ายต่อวันและต่อทีม - ตรวจสัญญาอนุญาตของทุกเครื่องมือก่อนใช้งานในผลิตภัณฑ์ สแตกนี้หนักกว่าเดิมมาก แต่เป็นราคาที่ต้องจ่ายถ้าคุณต้องอธิบายให้ผู้ตรวจสอบฟังว่าทำไมระบบถึงทำแบบนั้น สิ่งที่ผมไม่ได้ทดลอง ผมไม่ได้รันไปป์ไลน์เต็มรูปแบบบน GitHub Actions และไม่ได้ทดลอง agent ในสภาพแวดล้อมแยกที่ได้มาตรฐานองค์กร จึงยังไม่มีตัวเลข token หรือค่าใช้จ่ายจริงจากทีมของผมเองมาเล่า บทนี้จึงอ้างจากเอกสาร OWASP เอกสาร GitHub และสถานะสัญญาอนุญาตที่เปิดตรวจจริง ไม่ใช่จากการวัดผลในทีมของผม ถ้าคุณต้องการตัวเลขต้นทุนจริง ผมแนะนำให้วัดจากงานสิบงานแรกของทีมคุณเอง แล้วค่อยตั้งเพดานจากตัวเลขนั้น เช็กลิสต์ก่อนอนุมัติให้ใช้ในทีม 1. วัดโทเคนต่อ task ได้แล้วหรือยัง 2. มีเพดานค่าใช้จ่ายรายวันหรือยัง 3. agent อ่าน issue จากคนนอกได้หรือไม่ และมีมาตรการอะไร 4. token ที่ใช้มีสิทธิ์แคบที่สุดหรือยัง 5. สัญญาอนุญาตของทุกเครื่องมือผ่านฝ่ายกฎหมายหรือยัง 6. ใครเซ็นรับเมื่อระบบพัง ถ้าตอบข้อ 6 ไม่ได้ ยังไม่ควรใช้กับระบบที่มีผู้ใช้จริง บทเรียนที่ผมอยากฝากไว้ เครื่องมือในซีรี่ส์นี้เปลี่ยนได้ตลอด แต่หลักที่ใช้ตัดสินใจไม่เปลี่ยน วัดก่อนตั้งเพดาน จำกัดสิทธิ์ก่อนให้อำนาจ และกำหนดคนรับผิดชอบก่อนให้ระบบทำงานอัตโนมัติทุกอย่าง ถ้าคุณกำลังวางแผนใช้ agent กับทีมจริง เล่าให้ผมฟังได้ว่าทีมขนาดไหนและมีข้อจำกัดอะไรบ้าง ผมช่วยดูสแตกให้ได้ ซีรี่ส์นี้จบที่ตอนนี้ แต่เรื่องนี้ยังเดินต่อทุกเดือน เพราะเครื่องมือที่ผมเขียนว่ายังเดินอยู่ วันหนึ่งอาจหยุดเหมือน Qodo Cover [1] OWASP GenAI Security Project, "LLM01: Prompt Injection", สืบค้น 23 ต.ค. 2026. genai.owasp.org [2] GitHub Docs, "Secure use reference", สืบค้น 23 ต.ค. 2026 (แนวปฏิบัติด้านความปลอดภัยของ GitHub Actions และการจำกัดสิทธิ์ของ GITHUB_TOKEN). docs.github.com [3] Open Source Initiative, "AGPL-3.0 license", สืบค้น 23 ต.ค. 2026 (ลักษณะ copyleft และเงื่อนไขเมื่อให้บริการผ่านเครือข่าย). opensource.org [4] GitHub, "qodo-ai/qodo-cover" README, สืบค้น 23 ต.ค. 2026 (AGPL-3.0 · ประกาศหยุดดูแล 15 มิ.ย. 2025). qodo-ai/qodo-cover [5] GitHub, "github/spec-kit" README, สืบค้น 23 ต.ค. 2026 (MIT · 142,492 ดาว · คำสั่ง speckit-specify ถึง speckit-implement). github/spec-kit [6] GitHub, "bmad-code-org/BMAD-METHOD" README และหน้าสัญญาอนุญาต, สืบค้น 23 ต.ค. 2026 (README ระบุ MIT แต่ GitHub จัดสถานะ NOASSERTION). bmad-code-org/BMAD-METHOD [7] GitHub, "gitleaks/gitleaks-action", สืบค้น 23 ต.ค. 2026 (666 ดาว · สถานะสัญญาอนุญาต NOASSERTION · รีลีสล่าสุด v3.0.0). gitleaks/gitleaks-action [8] GitHub Docs, "Managing GitHub Actions settings for a repository", สืบค้น 23 ต.ค. 2026 (ตัวเลือกการรัน workflow จาก fork pull request และข้อยกเว้นเรื่องสิทธิ์เขียน). docs.github.com

ทีม multi-agent AI เขียนซอฟต์แวร์ได้จริงไหม: BMAD, ChatDev และ MetaGPT หลังเปิด repo ตรวจเอง โดย Nokka (นก-กา) | ตอนที่ 3 จาก 7 ของชุด "สร้างซอฟต์แวร์ด้วย AI" | ตรวจสอบข้อมูล ณ 23 ต.ค. 2026 บทความนี้เขียนด้วย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา) คำถามที่คนถามมากแต่คำตอบมักลอย ในกลุ่มคนที่เริ่มใช้ AI เขียนโค้ด มีคำถามหนึ่งที่ถูกถามซ้ำบ่อยที่สุด ถ้า agent ตัวเดียวเก่งได้ขนาดนี้ ทำไมไม่จัดทีม agent หลายตัว แบ่งเป็นนักวิเคราะห์ สถาปนิก นักเขียนโค้ด และผู้ตรวจสอบ แล้วให้คุยกันเอง แนวคิดนี้มีชื่อว่า multi-agent software development และมีโปรเจกต์ชื่อดังอยู่สามตัวที่คนพูดถึงบ่อย ผมเปิด repo ทั้งสามตัวดูวันนี้ แล้วจะเล่าว่าอะไรคือของจริง อะไรคือการสาธิต และอะไรคือโปรเจกต์ที่ควรปล่อยผ่าน สรุปสั้น - BMAD Method คือตัวที่ยังพัฒนาอยู่จริงและวางโครงกระบวนการได้ละเอียดที่สุด 54,458 ดาว และมีรุ่นเสถียร v6.12 กับ v7 ที่ยังพรีวิว - ChatDev แยกเป็นสองรุ่นชัดเจน คือ 1.0 ที่เป็นงานวิจัยจำลองบริษัทซอฟต์แวร์ และ 2.0 หรือ DevAll ที่เป็นแพลตฟอร์ม multi-agent แบบ zero-code - MetaGPT มี 70,973 ดาว แต่ commit ล่าสุดคือ 21 ม.ค. 2026 ห่างมาเก้าเดือนแล้ว - ผมไม่พบว่าตัวไหนเขียนเทสต์เก่งกว่าตัวอื่นอย่างมีนัยสำคัญ สิ่งที่ทั้งสามทำคือแบ่งบทบาทให้คนละส่วนของงาน - ตัวชี้ขาดว่าทีม agent ใช้ได้จริงหรือไม่ ไม่ใช่จำนวน agent แต่เป็นคุณภาพของข้อกำหนดที่ป้อนให้มัน BMAD: ทีมที่ถูกออกแบบมาให้ถามกลับ BMAD Method มี 54,458 ดาว และอัปเดตล่าสุด 20 ต.ค. 2026 [1] จุดที่ผมคิดว่ามันต่างจากตัวอื่นคือปรัชญาที่ระบุไว้ใน README ตรง ๆ ว่า agent เก่งเรื่องลงมือ แต่ชอบเปลี่ยนสมมติฐานที่ไม่มีใครพูดออกมาให้กลายเป็นโค้ด [1] BMAD จึงออกแบบมาให้ agent และ workflow ทำให้การตัดสินใจสำคัญถูกพูดออกมาชัด ๆ และเก็บไว้เป็นบริบทของงานที่ตามมา ในทางปฏิบัติคุณจะเจอ agent หลายบทบาท เช่น analyst, product manager, architect, dev และ QA ที่ส่งงานต่อกันเป็นช่วง [6] เรื่องเวอร์ชันที่ต้องรู้ก่อนติดตั้ง: README ระบุว่ามีสองสาย คือ v6.12 ที่เป็นรุ่นเสถียรและถูกตรึงไว้แก้แค่บั๊ก กับ v7 ที่ยังเป็น preview alpha และไฟล์อาจเปลี่ยนบ่อย [1] ถ้าคุณจะใช้กับงานจริง ให้เลือก v6.12 และอ่าน changelog ก่อนขยับ เรื่องสัญญาอนุญาต: README ติดแบดจ์ MIT แต่หน้า repo บน GitHub ยังจัดสถานะเป็น NOASSERTION [1] ความต่างนี้ไม่ได้แปลว่ามีปัญหา แต่แปลว่าฝ่ายไอทีควรเปิดไฟล์ LICENSE ใน repo อ่านเองก่อนอนุมัติใช้ในองค์กร ChatDev 2.0: จากงานวิจัยสู่แพลตฟอร์ม ChatDev มี 34,573 ดาว สัญญาอนุญาต Apache-2.0 และอัปเดตล่าสุด 16 ต.ค. 2026 [2] รุ่น 2.0 เปิดตัวเมื่อ 7 ม.ค. 2026 ภายใต้ชื่อ DevAll และวางตัวเป็นแพลตฟอร์ม multi-agent แบบ zero-code สำหรับ "developing everything" [2] README แยกคำอธิบายของสองรุ่นไว้ชัดเจน รุ่น 1.0 (Legacy) คือบริษัทซอฟต์แวร์จำลองที่มี agent หลายบทบาทประชุมกันในห้องเฉพาะทาง ครอบ designing, coding, testing และ documenting ส่วนรุ่น 2.0 (DevAll) อธิบายว่าผู้ใช้กำหนด agent, workflow และ task เอง และรองรับงานอย่าง data visualization, 3D generation และ deep research [2] คำว่า testing อยู่ในคำอธิบายของรุ่น 1.0 ไม่ใช่รุ่น 2.0 ซึ่งเป็นจุดที่ผมต้องแก้ความเข้าใจของตัวเอง แต่เมื่อเปิดดูโครงสร้างจริง ผลที่ได้คือสภาพแวดล้อมสำหรับสร้างแอปตัวอย่างที่รันได้ ไม่ใช่ระบบที่จะรับโปรเจกต์บริษัทคุณแล้วส่งงานพร้อมเทสต์ครบในคืนเดียว ผมมองว่ามันมีค่าในฐานะแม่แบบแนวคิด มากกว่าฐานรากของไปป์ไลน์จริง MetaGPT: ดาวเยอะ แต่หยุดเดิน MetaGPT มี 70,973 ดาว สัญญาอนุญาต MIT [3] ตัวเลขนี้ทำให้หลายคนเข้าใจว่ามันคือตัวเลือกอันดับหนึ่ง แต่ commit ล่าสุดคือ 21 ม.ค. 2026 ซึ่งห่างจากวันที่ผมตรวจมาเก้าเดือนกว่าแล้ว โปรเจกต์ที่ไม่มี commit มาเก้าเดือนไม่ใช่โปรเจกต์ที่ตายแน่นอน เพราะบางทีม stable พอแล้วและไม่ต้องแก้ แต่ในสายเครื่องมือที่พึ่ง API ของโมเดลซึ่งเปลี่ยนทุกไม่กี่เดือน การหยุดนานขนาดนี้หมายความว่าคุณจะต้องแก้โค้ดเองเมื่อ API เปลี่ยน ถ้าคุณจะใช้ ควรเผื่อแรงไว้สำหรับงานซ่อมบำรุง ไม่ใช่แค่ติดตั้ง ทีม agent เก่งกว่าตัวเดียวตรงไหน จากที่อ่านทั้งสามตัว ผมสรุปได้สามข้อที่ทีม agent ทำได้ดีกว่า หนึ่ง การแยกบทบาททำให้ข้อกำหนดถูกตรวจหลายรอบ analyst เขียน PM ท้วง architect ประเมิน ก่อนถึงมือคนเขียนโค้ด สอง งานที่ต้องใช้มุมมองต่างกันได้ประโยชน์จริง เช่นการออกแบบฐานข้อมูลที่ต้องคิดทั้งเรื่องประสิทธิภาพและความถูกต้อง สาม ข้อผิดพลาดถูกจับเร็วขึ้นในขั้นเอกสาร ซึ่งถูกกว่าการจับตอนโค้ดเสร็จมาก แต่มีข้อเสียที่สำคัญไม่แพ้กัน ค่าใช้จ่ายเพิ่มตามจำนวน agent เพราะแต่ละบทบาทคือการเรียกโมเดลหนึ่งครั้งขึ้นไป ความล่าช้าเพิ่มขึ้น เพราะต้องรอให้ agent คุยกันจบก่อนได้ผลลัพธ์ และปัญหาที่ผมเจอบ่อยที่สุดคือ agent เห็นด้วยกันเองตลอด ซึ่งทำให้การตรวจสอบกลายเป็นพิธีกรรม ถ้าจะเลือกใช้จริง เลือกตามงานที่คุณมี ถ้าคุณต้องการโครงกระบวนการที่ละเอียดและยังมีคนคุมอยู่ BMAD เป็นตัวเลือกที่ตรงที่สุด และควรเริ่มที่ v6.12 ถ้าคุณอยากเห็นภาพว่าทีม agent ทำงานร่วมกันหน้าตาเป็นอย่างไร ChatDev 2.0 เหมาะกับการทดลองและเรียนรู้ ถ้าคุณกำลังมองหาฐานรากของระบบจริง MetaGPT ยังใช้ได้ แต่ต้องยอมรับว่าคุณจะต้องดูแลโค้ดเองในอีกไม่กี่เดือน และถ้าคุณต้องการแค่ให้ AI เขียนโค้ดเป็นชิ้น ๆ อย่างมีวินัย ผมคิดว่า agent ตัวเดียวที่มีสเปกดี ๆ ให้ผลคุ้มกว่าทีม agent ที่ขาดข้อกำหนด BMAD มีอะไรให้ใช้จริงนอกจากตัว core นอกจากตัว core ที่ติดตั้งผ่าน npm แล้ว README ยังลิงก์ไปยังส่วนเสริมหลายตัว [1] ตัวที่เกี่ยวกับหัวข้อของเราที่สุดคือ BMad Test Architect ซึ่งเป็น add-on ด้านการทดสอบสำหรับองค์กร แยกเป็น repo ต่างหาก [4] การที่ทีมแยกเรื่องเทสต์ออกมาเป็นผลิตภัณฑ์อีกชั้น ผมอ่านว่า พวกเขาเห็นว่าการทดสอบเป็นงานที่ต้องออกแบบ ไม่ใช่ผลพลอยได้จากการเขียนโค้ด README ยังลิงก์ไปยัง repo ชื่อ BMad Loop แต่ผมไม่ได้เปิดอ่านรายละเอียดของมันในรอบนี้ จึงไม่สรุปว่ามันทำอะไร [1] ในมุมมองของผม BMAD ไม่ได้ขายความอัตโนมัติเต็มรูปแบบ แต่ขายการทำให้การตัดสินใจถูกจดไว้ ในทางปฏิบัติ นั่นหมายความว่าคุณยังต้องนั่งอ่าน brief กับ spec ที่ agent เขียน และตัดสินใจในจุดที่มันถามกลับ ถ้าคุณกำลังหาเครื่องมือที่จะทำงานแทนคุณโดยไม่ต้องอ่านอะไรเลย BMAD จะทำให้คุณผิดหวัง แต่ถ้าคุณเคยเจอปัญหา agent เขียนโค้ดจากสมมติฐานที่ไม่มีใครเคยพูดออกมา BMAD ถูกออกแบบมาเพื่อปัญหานั้นโดยตรง ChatDev 2.0 ต่างจากงานวิจัยรุ่นแรกตรงไหน รุ่นแรกของ ChatDev เป็นงานวิจัยที่จำลองบริษัทซอฟต์แวร์ขนาดเล็ก โดยมี agent หลายบทบาทคุยกันผ่านบทสนทนา [7] รุ่น 2.0 เปลี่ยนรูปเป็นแพลตฟอร์มที่ผู้ใช้กำหนด agent, workflow และ task เองได้ โดยไม่ต้องเขียนโค้ดตั้งค่าแพลตฟอร์ม [2] ชื่อ DevAll สื่อเจตนาว่าอยากให้มันสร้าง "อะไรก็ได้" ไม่จำกัดแค่เว็บแอป ข้อดีของแนวนี้คือคนที่ไม่ได้เขียนโปรแกรมก็ลองได้ และเห็นภาพว่าทีม agent คุยกันอย่างไร ข้อจำกัดที่ผมเห็นคือเมื่อมันเน้นการสร้างแอปตัวอย่างที่รันได้ มันจึงเก่งกับงานขนาดเล็กที่มีบริบทครบในตัว งานจริงของบริษัทมักมีข้อจำกัดที่ไม่ได้อยู่ในคำสั่ง เช่น ต้องใช้ฐานข้อมูลเดิม ต้องผ่านระบบสิทธิ์ที่มีอยู่ และต้องไม่ทำให้ระบบเก่าพัง ข้อจำกัดพวกนี้จะไม่ปรากฏในผลลัพธ์ของเครื่องมือที่สร้างแอปใหม่จากศูนย์ MetaGPT ยังน่าสนใจตรงไหน MetaGPT วางตำแหน่งเป็น framework หลาย agent ที่จำลองขั้นตอนการทำงานแบบบริษัทซอฟต์แวร์ มีการแบ่งบทบาทและส่งงานต่อกันเป็นเอกสาร [3] งานวิจัยต้นทางอธิบายแนวทางนี้ว่า meta programming สำหรับ framework ที่ agent หลายตัวร่วมมือกัน [5] แนวคิดนี้มีค่ามาก ในมุมมองของผม เพราะเป็นหนึ่งในต้นแบบที่โปรเจกต์รุ่นหลังหยิบไปต่อยอด แต่สถานะการพัฒนาเป็นเรื่องที่ต้องชั่งน้ำหนัก commit ล่าสุด 21 ม.ค. 2026 แปลว่าโค้ดไม่ได้แตะมาเก้าเดือนกว่า ในช่วงที่ API ของโมเดลเปลี่ยนไปหลายรอบ ผมจึงคาดว่า คุณจะต้องมีคนดูแลโค้ดเอง ถ้าคุณจะใช้ ผมคิดว่า ควรเตรียมคนที่อ่านโค้ดภาษา Python ของโปรเจกต์ได้ และเผื่องบเวลาสำหรับการอัปเดตความเข้ากันได้ไว้ด้วย หน้าตาของการเรียกใช้งานจริง เพื่อให้เห็นภาพ ผมเขียนตัวอย่างสมมติขึ้นเองด้านล่างนี้ ไม่ได้คัดลอกจากโปรเจกต์ใด เป็นเพียงโครงที่สะท้อนวิธีทำงานของทีม agent step 1: analyst LLM อ่าน requirement แล้วเขียน brief step 2: architect LLM อ่าน brief แล้วเขียนแผน step 3: dev LLM อ่านแผนแล้วเขียนโค้ด step 4: qa LLM รันเทสต์และเขียนรายงาน step 5: ถ้าไม่ผ่าน กลับไป step 3 พร้อมบริบทที่โตขึ้น ทุกบรรทัดคือการเรียก LLM หนึ่งครั้งขึ้นไป และบริบทที่ส่งไปจะโตขึ้นเรื่อย ๆ ตามจำนวนไฟล์ที่ระบบอ่านเข้ามา นี่คือเหตุผลทางเทคนิคว่าทำไมค่าใช้จ่ายของทีม agent จึงโตเร็วกว่าจำนวน agent ค่าใช้จ่ายที่คนมักลืมคิด ทุกครั้งที่ agent หนึ่งตัวส่งงานให้อีกตัว เกิดจากการเรียก LLM อีกครั้งด้วยบริบทที่โตขึ้น ถ้าทีมคุณมีห้าบทบาทและแต่ละบทบาทคุยกันสองรอบ งานชิ้นเดียวอาจกลายเป็นการเรียก LLM สิบครั้งขึ้นไป นี่คือเหตุผลที่ทีม agent หลายตัวมีค่าใช้จ่ายต่อ task สูงกว่า agent เดี่ยวมาก ไม่ใช่เพราะฉลาดกว่า แต่เพราะพูดมากกว่า ความเร็วก็เช่นกัน ผู้ใช้จะรู้สึกว่าระบบ "คิดนาน" เพราะต้องรอให้ทุกบทบาทคุยกันจบ ทางบรรเทาที่ผมคิดว่าได้ผลคือกำหนดเพดานจำนวนรอบ และให้ agent หยุดเมื่อได้ข้อสรุปที่วัดได้ ไม่ใช่เมื่อทุกคนเห็นด้วย เช็กลิสต์ก่อนเลือกใช้ทีม agent 1. งานที่คุณจะให้ทำ มีข้อจำกัดที่เขียนออกมาได้ครบหรือยัง 2. คุณมีคนที่จะอ่านผลลัพธ์และตัดสินใจหรือไม่ 3. งบต่อ task สูงสุดที่รับได้คือเท่าไร 4. คุณต้องการเอกสารประกอบหรือต้องการแค่โค้ดที่รันได้ 5. โปรเจกต์ยังมี commit ในหกเดือนล่าสุดหรือไม่ ถ้าตอบข้อ 1 กับข้อ 2 ไม่ได้ ทีม agent จะทำให้คุณเสียเวลาและเงินมากกว่าที่คิด บทเรียนที่ผมอยากฝากไว้ คำว่า multi-agent ฟังดูเหมือนความก้าวหน้า แต่ตัวที่ทำให้ผลลัพธ์ดีขึ้นจริงคือข้อกำหนดที่ชัดและการตรวจรับที่มีคนรับผิดชอบ ทีม agent ที่ไม่มีสเปกก็คือคนสิบคนที่เดาพร้อมกัน บทถัดไปผมจะลงไปดูชั้นที่ลงมือจริง คือ OpenHands, SWE-agent และ Aider ว่าตัวไหนรันคำสั่งได้จริงแค่ไหน และอะไรคือราคาที่ต้องจ่ายเมื่อปล่อยให้มันทำงานเอง ถ้าคุณอยากลองด้วยตัวเอง เริ่มจาก agent เดี่ยวหนึ่งตัวแล้ววัดจำนวน token ที่ใช้ต่องานก่อน แล้วค่อยขยับไปทีม agent หากคุณกำลังเลือกว่าจะเริ่มจากทีม agent หรือ agent เดี่ยว เล่าให้ผมฟังได้ว่าทีมคุณมีคนรีวิวกี่คน และงานส่วนใหญ่เป็นงานใหม่หรือแก้ของเดิม เพราะสองคำตอบนี้เปลี่ยนคำแนะนำทั้งหมด แหล่งอ้างอิง [1] GitHub, "bmad-code-org/BMAD-METHOD" README, สืบค้น 23 ต.ค. 2026 (54,458 ดาว · อัปเดต 20 ต.ค. 2026 · แบดจ์ MIT แต่ GitHub จัดเป็น NOASSERTION · v6.12 เสถียรและ v7 preview alpha · add-on BMad Test Architect และ BMad Loop · ถ้อยเรื่อง agent เปลี่ยนสมมติฐานเป็นโค้ด). bmad-code-org/BMAD-METHOD [2] GitHub, "OpenBMB/ChatDev" README, สืบค้น 23 ต.ค. 2026 (Apache-2.0 · 34,573 ดาว · อัปเดต 16 ต.ค. 2026 · แยกคำอธิบาย 1.0 Legacy ซึ่งครอบ designing/coding/testing/documenting กับ 2.0 DevAll ที่เป็น zero-code multi-agent platform รองรับ data visualization, 3D generation และ deep research · ประกาศ 7 ม.ค. 2026). OpenBMB/ChatDev [3] GitHub, "FoundationAgents/MetaGPT", สืบค้น 23 ต.ค. 2026 (MIT · 70,973 ดาว · commit ล่าสุด 21 ม.ค. 2026). FoundationAgents/MetaGPT [4] GitHub, "bmad-code-org/bmad-method-test-architecture-enterprise", สืบค้น 23 ต.ค. 2026 (ที่อยู่ของ add-on ด้านเทสต์ที่ README ของ BMAD ลิงก์ไป). bmad-code-org/bmad-method-test-architecture-enterprise [5] arXiv, "MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework" (arXiv:2308.00352, 2023), สืบค้น 23 ต.ค. 2026. arxiv.org [6] GitHub, "bmad-code-org/BMAD-METHOD: docs/reference/skills-and-agents.md", สืบค้น 23 ต.ค. 2026 (รายการ skill และ agent ที่ตัวติดตั้งสร้าง รวมบทบาท analyst, product manager, architect, dev และ QA). github.com/bmad-code-org/BMAD-METHOD/blob/main/do… [7] arXiv, "ChatDev: Communicative Agents for Software Development" (arXiv:2307.07924, 2023), สืบค้น 23 ต.ค. 2026. arxiv.org

Breakthrough Method for Agile AI Driven Development

Le vrai problème du vibe coding, ce n'est pas le code, c'est la mémoire _BMad, Superpower, OpenSpec : trois reboots d'un même projet en Spec-Driven Development_ Un peu de contexte : lead tech fullstack depuis plus de 20 ans, j'avais déjà le site vitrine de Black Speech Production pour mon association d'organisation de concerts à Nantes, mais qui avait surtout besoin d'une grosse mise à jour, fonctionnelle et technique. Ce site était statique, la contribution manuelle est lourde. Résultat : plusieurs années sans la moindre évolution. Autant repartir d'une page blanche, et en profiter pour tester l'IA sur ce chantier. C'est donc un projet perso, c'est-à-dire pas de deadline, des sessions de travail espacées et irrégulières. Sur cette refonte, j'ai exploré le vibe coding, puis testé trois outils de Spec-Driven Development. Voici mon retour d'expérience. Le vibe coding : on avance, mais on ne construit rien Premier reboot vers mai 2025 avec Junie, pour les améliorations fonctionnelles et techniques du site web. En Next.js, avec un design system via Storybook, deux technos que je connaissais déjà. Je suis parti avec mon idée en tête, sans plan écrit. Le code avançait bien, mais lentement, pour des raisons qui tenaient autant à moi qu'à l'outil : les plans générés par Junie pour chaque tâche étaient solides, l'intégration à l'IDE aussi. La génération des stories Storybook, elle, s'en sortait très bien. Le design system n'était pas vraiment utile à ce stade : une seule IHM était en cible pour le moment. Mon mode opératoire n'aidait pas non plus : j'ouvrais le code, je regardais ce qui manquait, puis je demandais à Junie de traiter ce manque, un point à la fois. J'avais aussi anticipé plein de besoins d'évolutions, ce qui a alourdi la quantité de travail à réaliser, incompatible avec le temps que je pouvais apporter au projet, et je n'étais pas focus sur un MVP. Résultat : je n'ai jamais fini, avec une grosse coupure entre deux sessions jusqu'à fin 2025, et perte complète de l'état d'avancement à la reprise. Le vrai problème n'était pourtant ni la vitesse ni la qualité du code : c'était l'absence de fil conducteur entre deux sessions espacées, et l'absence de priorisation des tâches restantes. Rien qui capture ce qui avait été décidé, rien à relire pour reprendre le contexte, rien pour savoir par quoi continuer. C'est cette absence de mémoire écrite, associée à cette coupure de plusieurs mois, qui a fini par me convaincre qu'il fallait autre chose. J'ai tenté de construire mon propre workflow sous Junie pour résoudre ce problème : une bonne intuition, mais trop chronophage à mettre en place par rapport à ma disponibilité sur ce projet. Ma veille techno et des échanges avec des collègues m'ont fait découvrir que d'autres avaient déjà formalisé cette même idée : le Spec-Driven Development (SDD), une méthode qui s'ajoute par-dessus un agent de code IA comme Junie ou Claude Code. Pas un agent en soi donc, mais du contexte et des instructions _pour_ un agent. J'avais envie de la tester, et de rebooter le projet une nouvelle fois. BMad : puissant pour brainstormer, mais à cadrer sérieusement Deuxième reboot, en février 2026, cette fois avec BMad (Breakthrough Method for Agile AI-Driven Development, open source, plus de 52 000 étoiles GitHub), mon premier outil de SDD, utilisé par-dessus Junie. L'outil organise 21 agents spécialisés répartis en rôles agiles (product owner, architecte, développeur, testeur) sur quatre phases : analyse (brainstorming, recherche), planning (PRD, specs techniques), solutioning (architecture) puis implémentation, avec un découpage façon Scrum en « story files » et sprints qui isolent le contexte de chaque tâche. La phase de brainstorming est solide, même utilisée en solo avec l'équipe d'agents de BMad. Sur ce site web, c'était aussi l'occasion de découvrir une nouvelle techno : je suis parti sur du Rust. Autre point fort : la sauvegarde des tâches à faire dans les story files rend la reprise du travail beaucoup plus simple. Exactement ce qui manquait en vibe coding pur : pas de plan d'action global pour le projet, juste des plans éphémères par tâche. Le côté multi-agents est aussi un vrai plus : avoir plusieurs rôles spécialisés en parallèle donne plusieurs points de vue sur le même problème, chacun challenge les autres. Le découpage façon Scrum en story files et sprints est bien pensé, mais lourd à porter pour un développeur solo. Le brainstorming, par nature, pousse à anticiper plein de choses et à se projeter dans un futur lointain : je n'avais pas ce temps-là à donner au projet. Sur ce projet précis, il est monté trop haut : d'un site web, le brainstorming a fini par dessiner une suite entière d'applications. Trop ambitieux, alors que seul le site web était ma vraie priorité. Deux frictions supplémentaires : - Consommation de tokens élevée : le brainstorming en profondeur a un coût. - Du drift : ajuster la spec ou la solution hors du cadre prévu (la review de fin de sprint) au lieu de passer par elle. bmad-help aide à savoir où reprendre, mais pousse à avancer dans le plan existant, pas à ajuster la spec ou le plan d'action : ce qui évite le drift, c'est de faire remonter chaque ajustement via cette review, portée par les retours de démo. Encore faut-il, en amont, que la spec soit bien rédigée et stable : BMad pousse dans cette direction, mais ce n'était pas mon cas, le périmètre était trop vaste suite au brainstorming. Ce mode opératoire ne me convenait pas en solo dev. La dérive du brainstorming n'a pas été inutile : elle m'a aidé à mieux cerner mon besoin réel. Mais c'est bien cette dérive, en plus de la consommation de tokens, qui m'a poussé à rebooter à nouveau plutôt que de m'acharner sur BMad. BMad reste, pour moi, l'outil à sortir pour cadrer une idée floue. Pas pour driver l'exécution au quotidien sur un scope instable ou en solo. Superpower : rapide sur un POC, mais le drift devient irrécupérable Troisième reboot, en mai 2026 après une nouvelle pause, avec Superpower cette fois, créé par Jesse Vincent (obra), devenu le plugin le plus étoilé de l'écosystème Claude Code avec plus de 280 000 étoiles GitHub. Sa version du SDD tient en trois documents dans l'ordre : la spec dit quoi construire, le plan dit dans quel ordre, le code suit le plan, avec du TDD red-green-refactor (tests d'abord, code ensuite, refactor une fois que ça passe) et une phase de brainstorming en amont, plus simple que celle de BMad et bien adaptée à un petit projet comme le mien, donc moins gourmande en tokens. Nouvelle techno, une fois de plus : je suis parti sur Astro. La motivation du redémarrage était justement de réduire le scope à la seule chose qui comptait : le site web. Et ça s'est vu : pas de dérive côté scope cette fois, et c'est rapide, idéal pour sortir une petite application. Il y a aussi eu un passage par Claude Code sur cette phase, en complément de Superpower. Point positif à garder : les propositions de design accompagnées d'une démo HTML étaient un vrai plus, ça donnait quelque chose de concret à valider avant de coder. Deux frictions, cette fois côté durée de vie du projet : - Le drift post-POC : contrairement à BMad, celui-là devient vite compliqué à rattraper une fois les ajustements accumulés. Un effet yo-yo s'installe, des allers-retours entre spec et code qui ne se stabilisent jamais. - Des specs difficiles à ajuster une fois posées : plus compliqué qu'avec BMad. C'est ce qui a motivé le passage à OpenSpec. OpenSpec : pas de reboot, juste un switch, et le drift s'arrête En juin 2026, pour OpenSpec (Fission-AI, open source, plus de 67 000 étoiles GitHub), pas de nouveau reboot : un simple switch d'outil sur le projet existant. Le repo y est structuré en deux espaces : openspec/specs/, la source de vérité du comportement actuel, et openspec/changes/, où toute évolution significative doit d'abord passer par une proposition de changement (proposal, design, tasks) validée _avant_ que quoi que ce soit ne soit codé. C'est exactement ce qui a fermé la boucle que BMad et Superpower laissaient ouverte : cette validation en amont, plus la traçabilité de l'archive, mettent fin au drift. Autre point fort : une fois le projet initialisé, il ne reste que trois commandes à connaître. propose crée la proposition de changement. apply lance l'implémentation, guidée par cette proposition. archive merge ensuite la proposition dans la spec globale et archive le changement, pour la traçabilité. À la bascule, le code et les specs laissés par Superpower ont servi de base pour repartir avec OpenSpec. J'ai ensuite ajouté des fonctionnalités sans repartir de zéro, y compris pour des changements de plus grande ampleur. L'approche changement + rétro spec fonctionne bien pour mon contexte projet. Je la trouve même plus adaptée à un mode kanban, itératif, qu'à un enchaînement séquentiel classique de phases. La contrepartie : proposal, design et tasks se valident souvent d'un bloc, avec moins d'humain dans la boucle sur la production de ces trois fichiers qu'entre les phases bien séparées de BMad ou Superpower, et une réflexion en amont plus légère. On a moins la main, mais sur des petits changements, ajuster les trois fichiers reste rapide. Ça compense largement le manque de recul par rapport à un vrai temps de recadrage phase par phase. Ce que je retiens Le fil rouge de ces trois outils, c'est la mémoire : capturer ce qui a été décidé et pourquoi, pour ne pas repartir de zéro à chaque session. C'est exactement ce qui manquait en vibe coding, et que les trois SDD testés résolvent chacun à leur manière, avec plus ou moins de rigueur. Ça a aussi un impact sur la gestion de projet au sens large : ces specs et ces plans d'actions vivent dans le repo, alors qu'on gère souvent ce suivi ailleurs, hors du dépôt git. Le SDD change la donne par rapport au vibe coding, quelque soit l'outil retenu au final : le vrai saut est de sortir du mode « on avance sans rien capturer ». Mais les trois outils ne jouent pas le même rôle : - BMad pour brainstormer un scope flou, seul ou en équipe. - Superpower pour sortir un POC vite. - OpenSpec pour tout ce qui doit durer sans repartir en drift. C'est celui que je recommande par défaut aujourd'hui. | | BMad | Superpower | OpenSpec | |---|---|---|---| | Cas d'usage idéal | Cadrer un scope flou, en groupe | Sortir un POC vite | Faire durer un projet sans drift | | Méthode de travail | Scrum (story files, sprints) | Cycle en V (spec verrouillée avant le code) | Kanban (proposition par proposition, itératif) | | Terrain de jeu | Greenfield, scope encore flou | Greenfield, POC rapide | Brownfield, projet qui évolue dans la durée | | Gestion du drift | Rattrapable, demande de reprendre la main régulièrement | Devient vite irrécupérable après le POC | Stoppé par la validation en amont et le merge dans la spec à l'archivage | | Coût en tokens | Élevé (brainstorming en profondeur) | Modéré | Faible, changement par changement | | Vitesse | Lente au démarrage, phase d'analyse longue | Très rapide | Rapide, et régulière dans la durée | | Étoiles GitHub | Plus de 52 000 | Plus de 280 000 | Plus de 67 000 | Un bémol méthodologique : chaque reboot changeait aussi de stack technique (Next.js/Storybook, puis Rust, puis Astro), sauf le passage de Superpower à OpenSpec qui a gardé le même code. La comparaison n'est donc pas un test en environnement parfaitement contrôlé : une partie de la lourdeur ressentie sous BMad tient peut-être aussi à l'apprentissage de Rust, à mon scope ambitieux et à mon organisation, pas seulement à l'outil. La vraie bonne pratique, commune aux trois, c'est de relire ce que produit l'agent à chaque étape, pas de tout valider en bloc à la fin. Ce qui change d'un outil à l'autre, c'est à quel point cette relecture est imposée plutôt que laissée à ma discipline. Sur ce spectre, BMad est le plus permissif : rien n'oblige à y revenir, tout repose sur moi. Superpower muscle le début, spec et plan, puis relâche la garde une fois le code lancé. OpenSpec est le seul des trois à en faire une étape obligatoire, à chaque changement, du premier jour à aujourd'hui. Un autre avantage commun aux trois, bien que ce soit une pratique manuelle de mon côté et non une fonctionnalité imposée par l'outil : la séparation entre planification et implémentation permet de choisir un modèle LLM à forte réflexion pour établir la liste des actions, puis de basculer sur un modèle plus direct, donc plus rapide et moins coûteux, pour l'implémentation. Ce type d'outils évolue vite, ça vaut le coup de continuer à explorer et tester au fil des sorties. Je suis justement en train de tester ECC (Everything Claude Code, plus de 247 000 étoiles GitHub), un système d'optimisation pour agents IA (skills, mémoire, sécurité), la suite logique de cette série. Et les réflexions issues du brainstorming BMad ne sont pas perdues pour autant : le site web est en production sur blackspeech.net, mais l'idée d'en faire une suite d'applications reste valable, pour une prochaine fois. Ce projet m'a aussi permis d'explorer de nouvelles technos et concepts au passage : Rust, Astro, RTK, Scaleway, Netlify, GEO (Generative Engine Optimization, le référencement pensé pour les moteurs IA), entre autres. Cette version 2 a mis du temps à sortir, entre les pauses qui se sont enchaînées avant d'y arriver, mais le résultat dépasse les attentes que j'avais au lancement du projet. En complément, ces trois outils, je les ai aussi testés sur d'autres projets. BMad, pour du brainstorming, une fiche produit et un cadrage de solution. Superpower, avec le même retour : bon pour un POC ou un besoin bien délimité, pas pour du long cours. OpenSpec, je l'ai adopté sur deux projets différents, celui-ci et un autre. Sources : - BMad-Method - Superpower - OpenSpec - ECC

BMad Method GitHub Overview: Persistent Context for AI Software Development bmad-method by bmad-code-org: bmad-code-org/bmad-method BMad Method is an open-source orchestration layer for AI-assisted software development. This overview explains how it carries planning and architecture decisions in local files so work can retain context beyond a transient chat session. It covers the v7 preview-alpha direction, the Node.js and Python runtime split, Python 3.11 and uv requirements, layered TOML configuration, Party Mode's analyst, product manager, and architect planning flow, and the build and validation path. It also examines the tradeoffs: alpha volatility, setup and Windows path issues, and the security implications of parent-directory traversal. The focus is what the repository is designed to do and where its operational boundaries are—not a successful installation or a hands-on benchmark. TimeStamps: 0:00 Why transient AI chats lose project context 0:29 BMad's file-backed orchestration and v7 alpha status 1:00 Runtime requirements and layered configuration 1:56 Party Mode turns vague ideas into requirements 2:28 Locking decisions before the build phase 3:02 Scaling validation and preserving an audit trail 3:44 Alpha volatility and setup glitches 4:11 Windows path parsing and module-linking failures 4:29 Parent-directory traversal as a security risk 4:55 Isolation, credential hygiene, and alpha-stage tradeoffs 🧠 Persistent context turns transient AI sessions into file-backed project history 🧩 Multi-agent planning converts vague ideas into requirements and architecture ⚙️ Build and validation flow scales with change size ⚠️ Alpha volatility and path traversal create operational tradeoffs BMad Method is best understood as a file-backed coordination layer for AI coding tools: useful when requirements, architecture, and audit trails matter, but demanding careful runtime setup and workspace isolation. The v7 preview alpha is a tradeoff between structured context, multi-agent planning, and fast-moving operational risk. #BMadMethod #AICoding #SoftwareArchitecture [de-DE] YNAS ynp_ba1336ee91450004 Cinematic Privater automatisierter Staging-Upload. Paketidentität: ynp_ba1336ee91450004; Ausgabe: cinematic. [es-US] YNAS ynp_ba1336ee91450004 cinemático Carga de entorno de prueba de automatización privada. Identidad del paquete: ynp_ba1336ee91450004; salida: cinemática. [fr-FR] YNAS ynp_ba1336ee91450004 cinématique Téléchargement de l'environnement de test d'automatisation privé. Identifiant du package : ynp_ba1336ee91450004 ; sortie : cinématique. [hi] YNAS ynp_ba1336ee91450004 सिनेमैटिक निजी स्वचालन स्टेजिंग अपलोड। पैकेज पहचान: ynp_ba1336ee91450004; आउटपुट: सिनेमाई। [id] Sinematik YNAS ynp_ba1336ee91450004 Unggahan staging otomatisasi pribadi. Identitas paket: ynp_ba1336ee91450004; output: sinematik. [it] YNAS ynp_ba1336ee91450004 cinematic Caricamento di automazione privata. Identità del pacchetto: ynp_ba1336ee91450004; output: cinematografico. [pt-BR] YNAS ynp_ba1336ee91450004 cinemático Upload de teste de automação privada. Identificação do pacote: ynp_ba1336ee91450004; saída: cinemática.

BMAD-METHOD: Breakthrough Method for Agile Ai Driven Development (54k stars) What it does All text below is quoted directly from the project README. >Breakthrough Method for Agile Ai Driven Development Why BMad?: - Right-sized process: Go directly to implementation for clear changes or add deeper planning for larger initiatives. - New or existing code: Start from nothing, or establish verified context on a codebase you inherited and work from what is actually there. - Durable context: Carry product and technical decisions forward instead of re-explaining them in every chat. - Specialized perspectives: Bring in product, architecture, UX, development, and testing expertise when it helps. - Guided collaboration: Use structured workflows and multiple-agent discussions without handing over judgment. - One delivery path: Move from early thinking through reviewed implementation, correction, and learning. >npx bmad-method install Repository bmad-code-org/BMAD-METHOD Repository stats |Metric|Value| |:-|:-| |Stars|54,269| |Forks|6,098| |Last release|v6.12.4 (2026-10-14)| |Languages|Python 76.1%, HTML 14.2%, JavaScript 7%| |Contributors|166| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|cursoragent: 1, Copilot: 3, claude: 297| |AI co-authored commits|Claude: 301, Cursor: 1, Copilot: 3| Main contributor |Field|Value| |:-|:-| |Name|Alex Verkhovsky| |GitHub|@alexeyv| |Commits to this repo|620 (top contributor)| |Company / Location|Calgary, AB| |Followers|152| |Public repos|7| |On GitHub since|2008-08-11| ------------------------------------------------------------------------------------------------ Discover the best GitHub repos without the endless scrolling. Get top repos organized by category (AI, DevOps, Databases & more), plus key takeaways from developers' most useful comments - all in one free, twice-weekly newsletter. 👉 Get the best repos & community insights - Free