- เป็นแนวทางการพัฒนาซอฟต์แวร์แบบ ทบต้น ที่ทุกหน่วยงานวิศวกรรมทำให้งานถัดไปง่ายขึ้น โดยมีแกนหลักเป็น ลูป 4 ขั้นตอน (วางแผน → ลงมือทำ → รีวิว → ทำให้เกิดการทบต้น) ที่ทำให้การทำงานร่วมกับ AI agent เป็นระบบ
- ในลูปแบบวนซ้ำนี้ เวลาของวิศวกรควรถูกจัดสรรเป็น 80% สำหรับการวางแผนและการรีวิว และ 20% สำหรับการลงมือทำและการทำให้เกิดการทบต้น
- แจกจ่ายในรูปแบบ ปลั๊กอิน ที่รวม 26 เอเจนต์เฉพาะทาง, 23 workflow command และ 13 skill โดยสามารถติดตั้งบน Claude Code, OpenCode และ Codex ได้
- เสนอให้ละทิ้งความเชื่อเดิมของการพัฒนาซอฟต์แวร์ 8 ข้อ (เช่น โค้ดต้องเขียนด้วยมือ, ทุกบรรทัดต้องรีวิวด้วยตนเอง ฯลฯ) ในฐานะ ความเชื่อที่ต้องปล่อยทิ้ง และนำหลักการใหม่ที่เข้ารหัสรสนิยมไว้ในระบบมาใช้
- แบ่งระดับการนำ AI มาใช้ของนักพัฒนาออกเป็น ระดับ 0 (พัฒนาแบบแมนนวล) ถึงระดับ 5 (รันบนคลาวด์แบบขนาน) พร้อม เฟรมเวิร์กแบบครอบคลุม ที่อธิบายวิธีอัปเลเวลในแต่ละขั้น และขยายไปถึงการทำงานร่วมกันในทีม การออกแบบ รีเสิร์ช และการตลาด
ปรัชญาหลัก
- หลักการสำคัญ คือ แต่ละหน่วยงานวิศวกรรมต้องทำให้งานถัดไปง่ายขึ้น
- โค้ดเบสแบบดั้งเดิมจะเพิ่มความซับซ้อนทุกครั้งที่เพิ่มฟีเจอร์ จนผ่านไป 10 ปี คนพัฒนาต้องใช้เวลากับการต่อสู้กับระบบมากขึ้น
- ใน Compound Engineering ฟีเจอร์ใหม่จะ สอนความสามารถใหม่ให้ระบบ การแก้บั๊กจะลบหมวดหมู่ของบั๊กในอนาคตทั้งชุด และแพตเทิร์นจะถูกเปลี่ยนเป็นเครื่องมือ ทำให้โค้ดเบสเข้าใจ แก้ไข และเชื่อถือได้ง่ายขึ้นเมื่อเวลาผ่านไป
ลูปหลัก: Plan → Work → Review → Compound
- ทีม Every ดำเนินการ 5 ผลิตภัณฑ์ (Cora, Monologue, Sparkle, Spiral, Every.to) โดย ใช้ทีมวิศวกรรมแบบคนเดียวเป็นหลัก และสิ่งที่ทำให้เป็นไปได้ก็คือลูป 4 ขั้นตอนนี้
- 3 ขั้นแรก (วางแผน ลงมือทำ รีวิว) เป็นเรื่องทั่วไป แต่จุดต่างสำคัญคือ ขั้นที่ 4 Compound ซึ่งเป็นจุดที่ผลประโยชน์แบบทบต้นสะสมขึ้น
- ไม่ว่าจะเป็นการแก้บั๊ก 5 นาทีหรือการพัฒนาฟีเจอร์ที่ใช้เวลาหลายวัน ก็ใช้ลูปเดียวกัน เพียงแค่ปรับเวลาที่ใช้ในแต่ละขั้น
-
ขั้นที่ 1: Plan (วางแผน)
- ทำความเข้าใจ requirement: ต้องสร้างอะไร ทำไมต้องสร้าง และมีข้อจำกัดอะไรบ้าง
- สำรวจโค้ดเบส: วิเคราะห์วิธีทำงานของฟีเจอร์ที่คล้ายกันและแพตเทิร์นที่มีอยู่
- สำรวจภายนอก: ตรวจสอบเอกสารของเฟรมเวิร์กและ best practice ในอุตสาหกรรม
- ออกแบบโซลูชัน: กำหนดแนวทางและไฟล์ที่จะเปลี่ยนแปลง
- ตรวจสอบแผน: ยืนยันความครบถ้วนและความสอดคล้องของแผนทั้งหมด
-
ขั้นที่ 2: Work (ลงมือทำ)
- ตั้งค่าสภาพแวดล้อมแบบแยก: แยกงานด้วย Git worktree (สำเนาแยกของ repository) หรือ branch
- ดำเนินการตามแผน: ให้เอเจนต์ลงมือ implement ทีละขั้น
- รันการตรวจสอบ: หลังการเปลี่ยนแปลงแต่ละครั้งให้รัน test, linting (ตรวจโค้ดอัตโนมัติ) และ type check
- ติดตามความคืบหน้า และปรับแผนเมื่อเกิดปัญหา
- ถ้าเชื่อถือแผนได้ ก็ไม่จำเป็นต้องคอยเฝ้าโค้ดทุกบรรทัด
-
ขั้นที่ 3: Review (รีวิว)
- หลายเอเจนต์ตรวจโค้ดแบบขนาน
- จัดลำดับสิ่งที่พบเป็น P1 (ต้องแก้), P2 (แนะนำให้แก้), P3 (ข้อปรับปรุง)
- เอเจนต์แก้ปัญหาตาม feedback จากการรีวิว และตรวจสอบผลการแก้อีกครั้ง
- บันทึกแพตเทิร์น: จดว่ามีอะไรผิดพลาดเพื่อป้องกันการเกิดซ้ำ
-
ขั้นที่ 4: Compound (ทำให้เกิดการทบต้น) — ขั้นที่สำคัญที่สุด
- การพัฒนาแบบดั้งเดิมมักจบที่ขั้นที่ 3 แต่ในขั้น Compound จะมีการสะสมของการปรับปรุงระบบ
- หาก 3 ขั้นแรกสร้างฟีเจอร์ ขั้นที่ 4 จะสร้าง ระบบที่ทำให้สร้างฟีเจอร์ได้ดีขึ้น
- งานที่ต้องทำ:
- จับสิ่งที่ได้ผล สิ่งที่ไม่ได้ผล และ insight ที่นำกลับมาใช้ซ้ำได้
- เพิ่ม metadata, tag และ category ด้วย YAML frontmatter เพื่อให้ค้นหาได้
- เพิ่มแพตเทิร์นใหม่ลงใน CLAUDE.md และสร้างเอเจนต์ใหม่เมื่อจำเป็น
- ตรวจสอบว่า "ครั้งหน้า ระบบจะจับปัญหานี้ได้อัตโนมัติหรือไม่?"
องค์ประกอบของปลั๊กอิน
- เอเจนต์เฉพาะทาง 26 ตัว: สำหรับรีวิว (14 ตัว), รีเสิร์ช, ดีไซน์, เวิร์กโฟลว์, เอกสาร และงานเฉพาะด้านอื่น ๆ
- 23 workflow command: ลูปหลัก + ยูทิลิตี
- 13 skill: มอบความเชี่ยวชาญเชิงโดเมน เช่น agent-native architecture และ style guide
- ติดตั้งได้บน Claude Code, OpenCode (experimental) และ Codex (experimental) แบบ zero-config
-
โครงสร้างไฟล์
- CLAUDE.md: ไฟล์ที่สำคัญที่สุดซึ่งเอเจนต์จะอ่านทุกครั้งเมื่อเริ่ม session ใช้เก็บ preference, pattern และบริบทของโปรเจกต์
- docs/solutions/: ปัญหาที่แก้แล้วจะถูกสะสมเป็นเอกสารที่ค้นหาได้ เพื่อสร้าง องค์ความรู้ขององค์กร (institutional knowledge)
- docs/brainstorms/: เก็บผลลัพธ์จากคำสั่ง brainstorm
- docs/plans/: เก็บผลลัพธ์จากคำสั่ง plan
- todos/: ติดตามรายการงานตามลำดับความสำคัญและสถานะ
คำสั่งหลัก
-
/workflows:brainstorm
- คำสั่งที่ใช้เมื่อยังไม่ชัดเจนว่าจะสร้างอะไร
- หลังทำ repo research แบบเบื้องต้น จะ ถามทีละข้อเพื่อทำให้ชัดเจนขึ้น เกี่ยวกับเป้าหมาย ผู้ใช้ ข้อจำกัด และ edge case
- AI จะเสนอแนวทาง และผลลัพธ์จะถูกเก็บใน
docs/brainstorms/ เพื่อส่งต่อไปยัง /workflows:plan
-
/workflows:plan
- อธิบายสิ่งที่ต้องการ แล้วระบบจะคืนแผนการ implement
- รัน 3 เอเจนต์รีเสิร์ชแบบขนาน: repo-research-analyst (แพตเทิร์นในโค้ดเบส), framework-docs-researcher (เอกสาร), best-practices-researcher (มาตรฐานอุตสาหกรรม)
- เอเจนต์ spec-flow-analyzer จะวิเคราะห์ user flow และ edge case
- เมื่อเปิดโหมด
ultrathink จะรัน /deepen-plan อัตโนมัติ เพื่อเปิดใช้ เอเจนต์รีเสิร์ชแบบขนานมากกว่า 40 ตัว
-
/workflows:work
- ขั้นที่เอเจนต์เขียนโค้ดจริง
- มี 4 เฟส: quick start (สร้าง Git worktree และตั้งค่า branch) → execute (implement งานตาม task พร้อมติดตามความคืบหน้า) → quality check (เลือกเปิด เอเจนต์รีวิวมากกว่า 5 ตัว ได้) → ship it (รัน linting, สร้าง PR)
-
/workflows:review
- รีวิว PR แบบ พร้อมกันและขนานโดยเอเจนต์เฉพาะทางมากกว่า 14 ตัว
- รวมถึง security (security-sentinel), performance (performance-oracle), architecture (architecture-strategist), data integrity (data-integrity-guardian), code quality (code-simplicity-reviewer), reviewer ตามเฟรมเวิร์ก (DHH-rails, Kieran-rails/python/typescript), deployment verification, frontend race condition และ agent-native reviewer
- เอาต์พุตจะเป็นรายการลำดับความสำคัญเดียวที่จัดประเภทเป็น P1 (critical), P2 (สำคัญ), P3 (เล็กน้อย)
- สามารถแก้สิ่งที่พบโดยอัตโนมัติด้วยคำสั่ง
/resolve_pr_parallel (ให้ P1 มาก่อน และแต่ละการแก้จะรันแบบแยก)
- สามารถกรองสิ่งที่พบทีละรายการด้วยคำสั่ง
/triage โดยเลือกอนุมัติ/ข้าม/ปรับแต่ง
-
/workflows:compound
- บันทึกปัญหาที่แก้แล้วไว้เป็นเอกสารสำหรับอ้างอิงในอนาคต
- รัน 6 sub-agent แบบขนาน: context analyzer, solution extractor, related docs finder, prevention strategist, category classifier, documentation writer
- สร้าง Markdown ที่ค้นหาได้ พร้อม YAML frontmatter
-
/lfg
- เมื่ออธิบายฟีเจอร์แล้ว เอเจนต์จะทำตั้งแต่วางแผน implement ไปจนถึงรีวิว และ ส่ง PR ที่พร้อม merge
- เชื่อมทั้งพายป์ไลน์ของ plan → deepen-plan → work → review → resolve findings → browser tests → feature video → compound
- หลังแผนได้รับอนุมัติ ระบบจะหยุดชั่วคราวก่อน แล้วจึงรันต่อแบบอัตโนมัติ โดยใช้ เอเจนต์มากกว่า 50 ตัว ตลอดทุกขั้นตอน
ความเชื่อ 8 ข้อที่ต้องทิ้ง
-
"โค้ดต้องเขียนด้วยมือ"
- ความต้องการที่แท้จริงคือการเขียนโค้ดที่ดี ดูแลรักษาได้ และแก้ปัญหาที่ถูกต้อง โดย ไม่สำคัญว่าใครเป็นคนพิมพ์
-
"ทุกบรรทัดต้องรีวิวด้วยมือ"
- การรีวิวทีละบรรทัดด้วยมือเป็นเพียงหนึ่งในวิธีประกันคุณภาพ และ ระบบอัตโนมัติที่จับปัญหาเดียวกันได้ ก็ใช้ได้เช่นกัน
- ถ้าเชื่อถือผลลัพธ์ไม่ได้ ก็ไม่ควรชดเชยด้วยการลงมือทำเอง แต่ต้อง แก้ระบบ
-
"โซลูชันต้องมาจากวิศวกร"
- AI สามารถค้นหาแนวทาง วิเคราะห์ trade-off และแนะนำตัวเลือกได้ ดังนั้นบทบาทของวิศวกรคือการ เติมรสนิยม (taste) — ตัดสินว่าโซลูชันแบบไหนเหมาะกับ codebase นี้ ทีมนี้ และบริบทนี้
-
"โค้ดคือผลลัพธ์หลัก"
- ระบบ ที่ผลิตโค้ดมีคุณค่ามากกว่าโค้ดแต่ละชิ้น
- สิ่งสำคัญกว่าการนำไปใช้ที่ยอดเยี่ยมเพียงครั้งเดียว คือ กระบวนการที่ผลิต implementation ที่ดีได้อย่างสม่ำเสมอ
-
"การเขียนโค้ดคือหน้าที่หลัก"
- งานของนักพัฒนาคือ ส่งมอบคุณค่า (ship value) และโค้ดเป็นเพียงหนึ่งในอินพุต
- การวางแผน การรีวิว และการสอนระบบ ล้วนถือเป็นงาน
-
"ครั้งแรกต้องออกมาดี"
- อัตราของเสีย ของครั้งแรกอยู่ที่ 95% และครั้งที่สองก็ยัง 50%
- นี่ไม่ใช่ความล้มเหลวแต่เป็นกระบวนการ และควร โฟกัสที่การวนซ้ำอย่างรวดเร็ว เพื่อให้ครั้งที่สามเสร็จเร็วกว่าครั้งแรก
-
"โค้ดคือการแสดงออกถึงตัวตน"
- โค้ดเป็นของทีม ของผลิตภัณฑ์ และของผู้ใช้ และถ้า ไม่มองโค้ดเป็นการแสดงออกถึงตัวเอง ก็จะรับฟีดแบ็ก รีแฟกเตอร์ และถกเถียงเรื่องคุณภาพได้ง่ายขึ้น
-
"ยิ่งพิมพ์มากก็ยิ่งเรียนรู้มาก"
- ปัจจุบัน ความเข้าใจสำคัญกว่าความจำของกล้ามเนื้อ
- นักพัฒนาที่รีวิว implementation จาก AI 10 แบบจะ เข้าใจแพตเทิร์นได้มากกว่า นักพัฒนาที่พิมพ์เอง 2 แบบ
ความท้าทายทางจิตวิทยาในช่วงเปลี่ยนผ่าน
- พอพิมพ์น้อยลงก็รู้สึกเหมือนทำน้อยลง: แต่ในความเป็นจริง การสั่งงานเอเจนต์ต้องใช้การคิดมากกว่าการลงมือ implement
- ความกังวลต่อการทำงานแบบอัตโนมัติ: นี่ไม่ใช่การปล่อยการควบคุม แต่เป็นการ เข้ารหัสการควบคุม ลงในข้อจำกัด กฎ และกระบวนการรีวิว
- คำถามว่า "นี่ฉันเป็นคนสร้างจริงหรือ?": การวางแผน การรีวิว และการทำให้มั่นใจในมาตรฐานคุณภาพก็คืองานนั้นเอง ส่วน AI ทำหน้าที่แค่เขียน
ความเชื่อที่ควรยึดถือ
-
ดึงรสนิยมออกมาใส่ในระบบ
- รสนิยมของนักพัฒนา เช่น กฎการตั้งชื่อ แพตเทิร์นการจัดการ error และแนวทางการทดสอบ มักไม่ได้ถูกเขียนเป็นเอกสารและอยู่แค่ในหัวของวิศวกรอาวุโส
- ควรบันทึกความชอบเหล่านี้ไว้ใน CLAUDE.md หรือ AGENTS.md และสร้างเอเจนต์กับสกิลเฉพาะทางสำหรับรีวิว ทดสอบ และ deploy เพื่อให้ AI ผลิตโค้ดที่พร้อมให้อนุมัติได้ด้วยตัวเอง
-
กฎ 50/50
- จัดสรรเวลา engineering 50% ให้พัฒนาฟีเจอร์ และ 50% ให้ปรับปรุงระบบ
- เดิมทีมักเป็น 90% ฟีเจอร์ / 10% อย่างอื่น แต่การสร้างรีวิวเอเจนต์ การทำเอกสารแพตเทิร์น และการสร้างตัวสร้างเทสต์ คือการลงทุนที่ทำให้ ฟีเจอร์ในอนาคตง่ายขึ้น
- การลงทุน 1 ชั่วโมงกับรีวิวเอเจนต์ อาจ ประหยัดเวลารีวิว 10 ชั่วโมง ตลอด 1 ปี
-
เชื่อมั่นในกระบวนการและสร้างตาข่ายนิรภัย
- หากต้องการขยายการใช้ AI ช่วยงาน จะไม่สามารถให้มนุษย์รีวิวทุกบรรทัดได้ ดังนั้นหัวใจสำคัญคือการสร้าง guardrail อย่างการทดสอบ การรีวิวอัตโนมัติ และการมอนิเตอร์
- ถ้ายังเชื่อถือผลลัพธ์ไม่ได้ ก็อย่าถอยกลับไปใช้การรีวิวด้วยมือ แต่ให้ เพิ่มระบบที่ทำให้ขั้นตอนนั้นน่าเชื่อถือได้
-
จัดสภาพแวดล้อมให้เป็น agent-native
- สิ่งที่นักพัฒนาเห็นหรือทำได้ เอเจนต์ก็ควรทำได้เช่นกัน: รันเทสต์ ดู production log ดีบักจากสกรีนช็อต สร้าง PR เป็นต้น
- งานใดก็ตามที่ไม่ยอมให้เอเจนต์ทำ ก็จะต้อง ทำด้วยมือตนเองโดยตรง
-
ใช้ประโยชน์จากการทำงานแบบขนาน
- คอขวดในอดีตคือความสนใจของมนุษย์ที่ทำได้ทีละงาน แต่คอขวดใหม่คือ compute (จำนวนเอเจนต์ที่รันพร้อมกันได้)
- ให้หลายเอเจนต์ทำหลายฟีเจอร์พร้อมกัน และทำรีวิว ทดสอบ และจัดทำเอกสารแบบขนาน
-
แผนคือโค้ดรูปแบบใหม่
- เอกสารแผนงาน คือผลลัพธ์ที่สำคัญที่สุดในตอนนี้
- แทนที่จะเขียนโค้ดก่อนแล้วค่อยทำเอกสารภายหลัง หากเขียนแผนก่อน ก็จะใช้เป็น source of truth ให้เอเจนต์สร้างโค้ด ทดสอบ และตรวจสอบได้
- การแก้ไอเดียบนกระดาษมีต้นทุนต่ำกว่าการแก้ในโค้ด
-
สรุปหลักการสำคัญ
- ทุกหน่วยงานควรทำให้งานถัดไปง่ายขึ้น
- ควร ฝังรสนิยมไว้ในระบบ ไม่ใช่ไว้ในรีวิว
- อย่าทำเองโดยตรง แต่ให้ สอนระบบ
- อย่าสร้างแค่กระบวนการรีวิว แต่ให้ สร้างตาข่ายนิรภัย
- จัดโครงสร้างสภาพแวดล้อมให้เป็น agent-native
- ใช้แนวคิดแบบดอกเบี้ยทบต้นกับทุกสิ่ง
- ยอมรับความไม่สบายใจของการมอบหมายงาน และเลือก ผลลัพธ์ที่ยังไม่สมบูรณ์แต่ขยายได้ ดีกว่าผลลัพธ์ที่สมบูรณ์แบบแต่ขยายไม่ได้
- เขียนโค้ดให้น้อยลงและส่งมอบคุณค่าให้มากขึ้น
- หลักการเหล่านี้ขยายไปได้ไกลกว่า engineering ไปสู่ design, research, writing และ ทุกสาขาที่ได้ประโยชน์จากการเข้ารหัสรสนิยมและบริบท
ขั้นการเติบโตของนักพัฒนา (บันได 5 ขั้น)
-
Stage 0: การพัฒนาแบบแมนนวล
- เขียนโค้ดทีละบรรทัดโดยไม่มี AI ค้นคว้าจากเอกสารและ Stack Overflow ดีบักด้วยคำสั่ง print
- วิธีนี้สร้างซอฟต์แวร์ที่ดีมาได้หลายสิบปี แต่ ในปี 2025 มันไม่เร็วพอแล้ว
-
Stage 1: ความช่วยเหลือแบบแชต
- ถาม ChatGPT, Claude, Cursor เป็นต้น เพื่อรับโค้ดสไนเป็ต แล้วคัดลอกวางส่วนที่ใช้ประโยชน์ได้
- AI ช่วยเร่งการรีเสิร์ชและการสร้าง boilerplate แต่ก็ยัง รีวิวทุกบรรทัดด้วยตัวเองและคงการควบคุมเต็มรูปแบบ
-
Stage 2: เครื่องมือ agentic + รีวิวทีละบรรทัด
- เครื่องมือ agentic อย่าง Claude Code, Cursor Composer และ Copilot Chat สามารถอ่านไฟล์และ แก้ไขใน codebase ได้โดยตรง
- มนุษย์ทำหน้าที่เป็น gatekeeper ที่คอยอนุมัติ/ปฏิเสธทุกสิ่งที่เอเจนต์เสนอ
- นักพัฒนาส่วนใหญ่ ติดอยู่ ในขั้นนี้ จึงยังไม่ได้ประโยชน์เต็มที่จากการมอบหมายงานให้ AI
-
Stage 3: วางแผนก่อน รีวิวระดับ PR
- นี่คือขั้นที่ทุกอย่างเปลี่ยนไป: ร่วมเขียน แผนอย่างละเอียด กับ AI ซึ่งครอบคลุมข้อกำหนด แนวทาง และ edge case
- เมื่อวางแผนเสร็จ AI จะ implement โดยไม่ต้องกำกับ และรีวิวผลลัพธ์ในรูปแบบ PR
- Compound Engineering เริ่มต้นที่จุดนี้ — การวางแผน การ implement และการรีวิวในแต่ละรอบจะสอนระบบ ทำให้รอบถัดไปเร็วขึ้นและง่ายขึ้น
-
Stage 4: ไอเดีย → PR (เครื่องเดียว)
- เมื่อให้ไอเดีย เอเจนต์จะจัดการทั้งหมดตั้งแต่รีเสิร์ช codebase วางแผน implement ทดสอบ รีวิวตัวเอง แก้ปัญหา และสร้าง PR
- การมีส่วนร่วมของมนุษย์ลดเหลือ เสนอไอเดีย รีวิว PR และ merge 3 ขั้นตอน
- แต่ยังคงรันได้ทีละงานบนคอมพิวเตอร์เครื่องเดียว
-
Stage 5: รันบนคลาวด์แบบขนาน (หลายอุปกรณ์)
- ย้ายการรันขึ้นคลาวด์เพื่อให้ ประมวลผลแบบขนาน
- ใช้เอเจนต์ 3 ตัวกับ 3 ฟีเจอร์พร้อมกัน แล้วค่อยรีวิวเมื่อ PR เสร็จ
- เอเจนต์ยังสามารถติดตามฟีดแบ็กและเสนอการแก้ไขเชิงรุกได้เอง
- บทบาทจึงเปลี่ยนจากผู้ลงมือทำรายคน ไปเป็น ผู้บัญชาการกองเรือเอเจนต์
คู่มือเลเวลอัป
-
0 → 1: เริ่มทำงานร่วมกัน
- เลือกเครื่องมือสักหนึ่งตัว (เช่น Cursor with Opus 4.5 หรือ Claude Code) และใช้งานทุกวัน
- ก่อนเริ่มเขียนโค้ด ให้ AI อธิบายโค้ดเดิมเพื่อยืนยันความเข้าใจ
- มอบหมายงานจาก boilerplate ก่อน เช่น เทสต์ ไฟล์ตั้งค่า ฟังก์ชันที่ทำซ้ำ
- รีวิวทุกบรรทัดเพื่อเรียนรู้
- งานแบบทบต้น: บันทึกพรอมป์ต์ที่ได้ผลดีอย่างต่อเนื่อง
-
1 → 2: อนุญาตการเข้าถึงของเอเจนต์
- สลับไปใช้โหมด agentic เพื่อให้เอเจนต์มีสิทธิ์เข้าถึงระบบไฟล์
- เริ่มจาก การเปลี่ยนแปลงวงแคบแบบไฟล์เดียว·เป้าหมายเดียว เช่น “เพิ่มเทสต์ให้ฟังก์ชันนี้”
- อนุมัติ/ปฏิเสธแต่ละแอ็กชันเพื่อสร้างสัญชาตญาณเรื่องความไว้วางใจ
- รีวิว diff เพื่อ โฟกัสเฉพาะส่วนที่เปลี่ยน
- งานแบบทบต้น: สร้างไฟล์ CLAUDE.md และเพิ่มโน้ตเมื่อเอเจนต์ทำพลาด
-
2 → 3: เชื่อถือแผน (จุดเปลี่ยนสำคัญ)
- เขียน แผนที่ชัดเจน สำหรับข้อกำหนด แนวทาง และ edge case
- อนุญาตให้ AI อ่าน codebase หาแพตเทิร์น และเสนอแนวทาง
- หลังเขียนแผนแล้ว ให้เอเจนต์ลงมือพัฒนาและ ปล่อยให้ทำจนเสร็จ
- รีวิวใน ระดับ PR แทนที่จะดูทีละขั้นหรือทีละบรรทัด
- งานแบบทบต้น: หลังการพัฒนาแต่ละครั้ง ให้บันทึกสิ่งที่แผนพลาดไป
-
3 → 4: บอกผลลัพธ์ ไม่ใช่วิธีสั่งทำ
- ระบุผลลัพธ์ (outcome) เช่น “เพิ่มการแจ้งเตือนทางอีเมลเมื่อมีคอมเมนต์ใหม่” แล้วให้เอเจนต์ตัดสินใจวิธีพัฒนา
- เพราะเอเจนต์รู้จัก codebase และทำรีเสิร์ชได้ การวางแผนจึงเป็นความรับผิดชอบของเอเจนต์ด้วย
- รีวิวแนวทางก่อนลงมือพัฒนา เพื่อกันทิศทางที่ผิดตั้งแต่เนิ่น ๆ
- งานแบบทบต้น: สร้างคลังคำสั่งแบบยึดผลลัพธ์ที่ใช้งานได้ดี
-
4 → 5: ทำทุกอย่างให้ขนานกัน
- ย้ายการรันไปยังคลาวด์เพื่อ ปลดคอขวดของเครื่องโลคัล
- มอบหมาย 3 ฟีเจอร์ให้ 3 เอเจนต์ทำพร้อมกัน
- จัดไอเดีย บั๊ก และสิ่งปรับปรุงเป็น คิว เพื่อให้เอเจนต์หยิบทำตามลำดับ
- เปิดให้เอเจนต์ติดตามฟีดแบ็กผู้ใช้และ เสนอฟีเจอร์เชิงรุก ได้เอง
- งานแบบทบต้น: แยกและบันทึกว่างานใดทำแบบขนานได้ และงานใดเป็นแบบลำดับโดยธรรมชาติ
3 คำถามก่อนอนุมัติผลลัพธ์จาก AI
- “การตัดสินใจที่ยากที่สุดตรงนี้คืออะไร?” — กระตุ้นให้ AI เปิดเผยส่วนที่ซับซ้อนและจุดที่ต้องใช้วิจารณญาณ
- “มีทางเลือกอะไรที่คุณปฏิเสธไป และเพราะอะไร?” — ตรวจดูตัวเลือกที่ถูกพิจารณาเพื่อจับการตัดสินใจที่ผิด
- “ส่วนไหนที่คุณมั่นใจน้อยที่สุด?” — ทำให้ LLM ยอมรับจุดอ่อนของตัวเอง แต่จะตอบได้ก็ต่อเมื่อ ถามตรง ๆ เท่านั้น
สถาปัตยกรรมแบบ Agent Native
- หัวใจสำคัญคือการมอบ ความสามารถระดับเดียวกับนักพัฒนา ให้กับเอเจนต์
- ถ้าเอเจนต์รันเทสต์ไม่ได้ คุณต้องไปรันเอง และถ้าดูล็อกไม่ได้ คุณต้องไปดีบักเอง ดังนั้น ทุกความสามารถที่ไม่อนุญาตจะกลายเป็นงานแมนนวล
-
เช็กลิสต์ Agent Native
- สภาพแวดล้อมการพัฒนา: รันแอปโลคัล, รันเทสต์สวีต, รัน linter·type checker, DB migration, seed ข้อมูลสำหรับพัฒนา
- งาน Git: สร้าง branch, commit, push ไป remote, สร้าง PR, อ่านคอมเมนต์ใน PR
- การดีบัก: ดูล็อก local/production (อ่านอย่างเดียว), ถ่ายภาพหน้าจอ UI, ตรวจ network request, เข้าถึงระบบติดตามข้อผิดพลาด (เช่น Sentry)
-
การนำ Agent Native มาใช้แบบค่อยเป็นค่อยไป
- Level 1 (การพัฒนาพื้นฐาน): เข้าถึงไฟล์, รันเทสต์, Git commit — ใช้ Compound Engineering ขั้นพื้นฐานได้
- Level 2 (โลคัลครบชุด): เข้าถึงเบราว์เซอร์, ล็อกโลคัล, การสร้าง PR — ทำ Stage 3~4 ได้
- Level 3 (การมองเห็น production): ล็อก production (อ่านอย่างเดียว), error tracking, monitoring dashboard — ทำดีบักเชิงรุกโดยเอเจนต์ได้
- Level 4 (เชื่อมต่อครบวงจร): ระบบ ticket, ความสามารถในการ deploy, การเชื่อมต่อบริการภายนอก — ทำ Stage 5 ได้
-
แนวคิดแบบ Agent Native
- ตอนสร้างฟีเจอร์: “เอเจนต์จะโต้ตอบกับสิ่งนี้อย่างไร?”
- ตอนดีบัก: “เอเจนต์ต้องมองเห็นอะไรได้บ้าง?”
- ตอนเขียนเอกสาร: “เอเจนต์เข้าใจสิ่งนี้ได้หรือไม่?”
Skip Permissions
- แฟล็ก
--dangerously-skip-permissions ของ Claude Code ใช้ ปิดการขอสิทธิ์ ที่จะถามทุกครั้งก่อนทำแต่ละแอ็กชัน
- ชื่อที่ฟังดูน่ากลัวถูกตั้งใจไว้เพื่อให้ผู้ใช้คิดให้รอบคอบก่อนใช้งาน
-
ควรใช้เมื่อไร
- แนะนำให้ใช้: เมื่อมีระบบแผนและรีวิวที่ดี, เมื่อต้องทำงานในสภาพแวดล้อม sandbox, เมื่อต้องการความเร็ว
- ไม่ควรใช้: ระหว่างกำลังเรียนรู้ (การขอสิทธิ์ช่วยให้เข้าใจมากขึ้น), เมื่อต้องทำงานกับโค้ด production, เมื่อยังไม่มีระบบ rollback
-
กลไกความปลอดภัยเมื่อข้ามการขอสิทธิ์
- Git คือเครือข่ายนิรภัย: งานของเอเจนต์จะถูกบันทึกใน Git และกู้คืนได้ด้วย
git reset --hard HEAD~1
- เทสต์ช่วยจับความผิดพลาด: รันเทสต์ก่อน merge
- รีวิวก่อน merge: ข้ามสิทธิ์ระหว่างการพัฒนาได้ แต่ต้องรีวิวขั้นสุดท้ายเสมอ
- แยกความเสี่ยงด้วย Worktree: งานเสี่ยงให้ทดลองในไดเรกทอรีที่แยกออกมา
-
การคำนวณด้านผลิตภาพ
- ถ้าไม่ข้ามสิทธิ์ จะมีพรอมป์ต์ขึ้นประมาณทุก 30 วินาที และการต้องพิมพ์ “y” ทุกครั้งจะทำให้เสียสมาธิ
- ถ้าข้ามสิทธิ์ จะ รักษาสภาวะ flow ได้ ทำให้วนรอบได้เร็วขึ้น 5~10 เท่า และประหยัดเวลากว่าความเสี่ยงจากการ rollback เป็นครั้งคราวอย่างมาก
เวิร์กโฟลว์ด้านดีไซน์
-
แนวทาง Baby App
- สร้าง โปรเจกต์ใช้ครั้งเดียว (baby app) ที่ทดลองซ้ำได้อย่างอิสระ โดยไม่ต้องกังวลเรื่องเทสต์ สถาปัตยกรรม หรือ breaking change
- เมื่อได้ดีไซน์ที่พอใจแล้ว ให้ดึงสี ระยะห่าง ตัวอักษร และแพตเทิร์นของคอมโพเนนต์ออกมาเพื่อ ย้ายกลับไปยังโปรเจกต์หลัก
-
ลูปสำรวจ UX
- สร้างหลายเวอร์ชัน ทำ click-through และ แชร์ functional prototype ให้ผู้ใช้ เพื่อเก็บฟีดแบ็ก
- ต่างจาก mockup ใน Figma เพราะสามารถคลิกใช้งานได้จริง
- โปรโตไทป์มีไว้เพื่อการเรียนรู้ และหลังจากนั้นจะ สร้างใหม่ตั้งแต่ต้นด้วยแผนที่เหมาะสม
-
การทำงานร่วมกับดีไซเนอร์: Compound flow
- โฟลว์แบบดั้งเดิม: mockup ของดีไซเนอร์ → นักพัฒนาตีความ → วนแก้ไขซ้ำ
- Compound flow: mockup จาก Figma ของดีไซเนอร์ → ส่งลิงก์ Figma ไปที่
/plan → AI พัฒนา → เอเจนต์ figma-design-sync ตรวจว่า การพัฒนาตรงกับ mockup หรือไม่ → ดีไซเนอร์รีวิว เวอร์ชันจริงแบบ live แทนการดูภาพหน้าจอ
-
การเข้ารหัสรสนิยมด้านดีไซน์
- ทำงานร่วมกับดีไซเนอร์ในบางฟีเจอร์ แล้วบันทึกแพตเทิร์นที่ค้นพบ (สีที่ชอบ, เลย์เอาต์ฟอร์ม ฯลฯ) ลงใน ไฟล์สกิล
- ทำให้ AI สามารถสร้างดีไซน์ที่ตรงกับรสนิยมของดีไซเนอร์ได้แม้ไม่มีดีไซเนอร์อยู่ด้วย
-
ดีไซน์เอเจนต์
- design-iterator: วิเคราะห์ภาพหน้าจอของดีไซน์ปัจจุบันและปรับปรุงซ้ำ ๆ เพื่อขัดเกลาอย่างค่อยเป็นค่อยไป
- figma-design-sync: ดึงดีไซน์จาก Figma มาเทียบกับการพัฒนา และ แก้ความต่างโดยอัตโนมัติ
- design-implementation-reviewer: ตรวจว่า การพัฒนาตรงกับสเปกใน Figma หรือไม่ เพื่อจับบั๊กด้านภาพก่อนถึงมือผู้ใช้
Vibe Coding
- แนวทางสำหรับคนที่ต้องการ แค่ผลลัพธ์ ไม่ได้ต้องการตัวโค้ดเอง: เช่น product manager, ดีไซเนอร์, โปรเจกต์ส่วนตัว
- ข้ามขั้นบันไดแล้ว ไป Stage 4 ตรง ๆ: อธิบายสิ่งที่ต้องการ → เอเจนต์จัดการทั้งแผน โค้ด เทสต์ รีวิว และ PR
- เหมาะกับกรณี: โปรเจกต์ส่วนตัว, โปรโตไทป์, การทดลอง, การสำรวจว่า “ทำแบบนี้ได้ไหม?”, เครื่องมือภายใน, การสำรวจ UX
- ไม่เหมาะกับกรณี: ระบบ production ที่มีผู้ใช้, โค้ดที่คนอื่นต้องดูแลต่อ, แอปที่อ่อนไหวด้านความปลอดภัย, ระบบที่วิกฤตด้านประสิทธิภาพ
-
พาราด็อกซ์ของ Vibe Coding
- Vibe Coding อาจช่วย พัฒนาความสามารถในการวางแผน ได้ด้วยซ้ำ
- เมื่อยังไม่รู้ว่าจะสร้างอะไร ให้ทำโปรโตไทป์เพื่อเก็บฟีดแบ็กจากผู้ใช้ แล้ว ลบทั้งหมดทิ้งและเริ่มใหม่ด้วยแผนที่เหมาะสม
- การแบ่งสัดส่วนที่ดีที่สุดคือ: ค้นพบด้วย vibe coding, สร้างด้วยสเปก — สำหรับการพัฒนาขั้นสุดท้าย สเปกชนะเสมอ
การทำงานร่วมกันของทีม
-
ไดนามิกทีมแบบใหม่
- แบบดั้งเดิม: คน A เขียนโค้ด → คน B รีวิว → ถกกันในคอมเมนต์ PR → อนุมัติแล้วจึง merge
- Compound: คน A สร้างแผน → AI ลงมือทำ → เอเจนต์ AI รีวิว → คน B รีวิวการรีวิวของ AI → มนุษย์อนุมัติแล้วจึง merge
-
มาตรฐานทีม
- การอนุมัติแผน: ความเงียบไม่ถือว่าอนุมัติ ดังนั้นก่อนลงมือทำต้องมี การ sign-off อย่างชัดเจน
- ความเป็นเจ้าของ PR: ไม่ว่าใครจะเป็นผู้เขียนโค้ด คนที่เริ่มงานคือเจ้าของ PR และต้องรับผิดชอบต่อคุณภาพของแผน การรีวิว การแก้ไข และผลกระทบหลัง merge
- จุดโฟกัสของการรีวิวโดยมนุษย์: ใน PR ที่เอเจนต์รีวิวของ AI วิเคราะห์ไปแล้ว มนุษย์จะไม่เน้น syntax error, ความปลอดภัย, ประสิทธิภาพ หรือสไตล์ แต่จะ รีวิวโดยยึด intent เป็นหลัก — "ตรงกับที่ตกลงกันไว้ไหม?", "แนวทางนี้สมเหตุสมผลไหม?", "มีปัญหาใน business logic หรือไม่?"
-
รูปแบบการสื่อสาร
- ยึด asynchronous เป็นค่าเริ่มต้น: การสร้างแผน รีวิว และอนุมัติแผน ไม่จำเป็นต้องประชุม เช่น "ฉันทำเอกสารแผนไว้แล้ว ฝากคอมเมนต์ภายในวันนี้"
- การส่งต่องานที่ชัดเจน: ต้องมีสถานะ สิ่งที่ทำเสร็จแล้ว งานที่เหลือ บริบท และวิธีทำต่อ
-
รูปแบบการขยายสเกล
- ความเป็นเจ้าของที่ชัดเจน + อัปเดตแบบ asynchronous: แต่ละฟีเจอร์หลักมีเจ้าของหนึ่งคนที่ดูแลแผน การติดตาม การรีวิว การ merge และการอัปเดตให้ทีม
- Feature flag + PR ขนาดเล็ก: ยิ่งทุกคน deploy ได้เร็วเท่าไร ความขัดแย้งตอน merge ก็ยิ่งมากขึ้น จึงควร deploy เป็นหน่วยเล็ก ๆ merge เข้า main บ่อย ๆ และ แก้ conflict ทันทีที่เกิด
- เอกสาร Compound = tribal knowledge ที่ถูกเติมเต็ม: แทนที่จะบอกว่า "ไปถาม Sarah เธอรู้เรื่อง auth ดี" ก็ให้ Sarah รัน
/compound เพื่อจัดทำเอกสารโซลูชัน แล้ว ทุกคนก็สามารถค้นหาเจอได้
การวิจัยผู้ใช้
-
ช่องว่างระหว่างรีเสิร์ชกับการพัฒนา
- แบบดั้งเดิม: นักวิจัยสัมภาษณ์ → เขียนรายงาน → ถูกทิ้งไว้ใน Google Drive → นักพัฒนาไม่ได้อ่านรายงาน → ฟีเจอร์ไม่สะท้อนความต้องการของผู้ใช้
- Compound: งานวิจัยสร้าง insight ที่มีโครงสร้าง → insight ถูกใช้เป็น บริบทของแผน → AI อ้างอิง insight ระหว่างวางแผน → ข้อมูลการใช้งานช่วยยืนยัน insight → insight สะสมทบต้นอย่างต่อเนื่อง
-
การทำให้รีเสิร์ชมีโครงสร้าง
- แปลงโน้ตสัมภาษณ์ดิบให้เป็น Markdown แบบมีโครงสร้าง เพื่อให้ AI นำไปใช้ได้ โดยมีข้อมูลผู้เข้าร่วม insight หลัก คำพูดอ้างอิง นัยสำคัญ และระดับความเชื่อมั่น (ผู้เข้าร่วม n/5 คน)
-
เอกสารเพอร์โซนา
- สร้าง เอกสารเพอร์โซนา ที่มีเป้าหมาย ความไม่พอใจ และคำพูดอ้างอิง เพื่อให้ AI ใช้อ้างอิงได้
-
การวางแผนบนฐานรีเสิร์ช
- เมื่อรัน
/workflows:plan ให้ใส่บริบทจากรีเสิร์ชด้วย (ผลสัมภาษณ์ รูปแบบของเพอร์โซนา pain point ปัจจุบัน) เพื่อให้ insight จากรีเสิร์ชเชื่อมไปสู่ฟีเจอร์ได้โดยตรง
การดึงแพตเทิร์นจากข้อมูล
- วิธีที่ผู้ใช้ใช้ผลิตภัณฑ์คือ เบาะแสที่บอกว่าควรสร้างอะไร
-
ประเภทแพตเทิร์นที่ควรจับตา
- แพตเทิร์นการใช้งานเกินคาด: ฟีเจอร์ที่ถูกใช้มากกว่าที่คาดไว้มาก การกลับเข้าหน้าเดิมซ้ำ ๆ
- แพตเทิร์นความยากลำบาก: ใช้เวลาอยู่บนหน้าที่ควรเรียบง่ายนานผิดปกติ พยายามทำ action เดิมซ้ำ ๆ วนลูป error → retry → error
- แพตเทิร์นการอ้อมไปทำอย่างอื่น: export ข้อมูลจากที่หนึ่งแล้ว import เข้าอีกที่หนึ่ง คัดลอก-วางข้ามหลายหน้าจอ หรือ เปิดหลายแท็บพร้อมกัน เพื่อเปรียบเทียบ
- แพตเทิร์นการหลุดออกจาก flow: หลุดออกจาก flow หรือเริ่มใช้งานฟีเจอร์แล้วไม่ทำจนเสร็จ
-
จากแพตเทิร์นสู่ฟีเจอร์
- ผู้ใช้คัดลอก-วางข้อมูลระหว่างตารางสัปดาห์ละ 50 ครั้ง → ทำเป็นฟีเจอร์ ปุ่ม "ซิงก์ไปยังตาราง B"
- ผู้ใช้สร้างโปรเจกต์ "เทมเพลต" แล้วคัดลอกซ้ำ → ทำเป็นฟีเจอร์ รองรับเทมเพลตแบบ first-class
การเขียนคำโฆษณา
-
ใส่ copy เข้าไปในแผน
- ทีมส่วนใหญ่ปฏิบัติต่อ copy ว่าเป็น สิ่งรองลงมา ที่ค่อยเติมหลังสร้างฟีเจอร์เสร็จ แต่ copy คือส่วนหนึ่งของประสบการณ์ผู้ใช้
- หากใส่ copy ที่ผู้ใช้มองเห็น เช่น หัวข้ออีเมล ข้อความสำเร็จ ข้อความผิดพลาด ตั้งแต่ขั้นวางแผน AI ก็จะมี copy พร้อมใช้อยู่แล้วตอนลงมือทำ
-
เข้ารหัสโทนเสียง
- เขียนหลักการ (พูดให้เหมือนมนุษย์ ข้อความ error ต้องช่วยผู้ใช้ ประโยคสั้น ใช้คำชัดเจน) และ คำที่ควรหลีกเลี่ยง (Invalid → ใช้งานไม่ได้, Error → อธิบายว่าเกิดอะไรขึ้น เป็นต้น) ไว้ในไฟล์สกิล
-
รีวิว copy
- เพิ่มการรีวิว copy เข้าไปในกระบวนการ
/workflows:review: มีเอเจนต์ copy-reviewer ตรวจ 4 เกณฑ์คือ ความชัดเจน ความเป็นประโยชน์ โทน และความสม่ำเสมอ
การตลาดผลิตภัณฑ์
-
โฟลว์แบบ Compound
- วิศวกรสร้างแผนที่มี value proposition ของผลิตภัณฑ์ → AI สร้างฟีเจอร์ → AI สร้าง release note จากแผน → สร้าง โพสต์โซเชียลจาก release note → ใช้ Playwright จับภาพหน้าจออัตโนมัติ → วิศวกรรีวิวแล้วปล่อยทุกอย่างพร้อมกัน
- ทุกอย่างไหลอยู่ในที่เดียว จึงไม่ต้อง handoff และไม่มีช่องโหว่
-
การสร้าง release note
- AI มีทั้งแผน การเปลี่ยนแปลงโค้ด และการทดสอบ จึงสามารถ รู้ได้อย่างแม่นยำว่าสร้างอะไรไปบ้าง
- ให้เรียงลำดับโดยเน้นประโยชน์ต่อผู้ใช้ก่อน ใส่ตัวอย่างที่เฉพาะเจาะจง 1 ตัวอย่าง กล่าวถึง breaking change และยาวไม่เกิน 200 คำ
-
การสร้าง changelog
- ใช้คำสั่ง
/changelog เพื่อตรวจ merge ล่าสุดบน main แล้วอ่านแต่ละแผน/PR เพื่อ สร้าง changelog ที่น่าสนใจ
-
ภาพหน้าจออัตโนมัติ
- ใช้ Playwright จับภาพหน้าจอสำหรับงานการตลาดโดยอัตโนมัติ ไม่ต้องขอภาพจากทีมวิศวกรรม และ แก้ปัญหาภาพหน้าจอเก่าไม่อัปเดต
ยังไม่มีความคิดเห็น