Claude Code ไม่ใช่เครื่องมือ แต่มันคือโลกทัศน์หนึ่ง — ถอดรหัสปรัชญาผลิตภัณฑ์ 7 ข้อจากบทสัมภาษณ์ของ Cat Wu

แนะนำให้เพื่อน ๆ ที่ทำผลิตภัณฑ์หาเวลาดูบทสัมภาษณ์ของ Cat Wu ผู้ดูแลผลิตภัณฑ์ Claude Code ทั้งสองตอนนี้ — ตอนหนึ่งเป็นสัมภาษณ์เดี่ยวใน Lenny's Podcast อีกตอนหนึ่งเป็นรายการ Every.to 《AI & I》 ที่เธอพูดคุยร่วมกับ Boris Cherny รวมสองตอนยาวกว่าสามชั่วโมง ความหนาแน่นของข้อมูลมากจนผมฟังซ้ำสองรอบ

หลายคนพูดถึงสองตอนนี้โดยโฟกัสที่ Anthropic ย่นระยะเวลาพัฒนาฟีเจอร์จาก 6 เดือนเหลือแค่ 1 สัปดาห์ หรือแม้แต่ 1 วัน เรื่องความเร็วบ้าบอนี้จริง ๆ แต่สิ่งที่ผมสะเทือนใจที่สุดไม่ใช่ความเร็ว

สิ่งที่ปลุกความคิดผมจริง ๆ คือ โลกทัศน์ทั้งชุดที่ซ่อนอยู่ในตัวผลิตภัณฑ์ Claude Code มันแยกได้เป็น 7 ข้อ แต่ละข้อถ้าแยกออกมาดูจะรู้สึกสวนทางกับสามัญสำนึก แต่เมื่อประกอบรวมกัน มันคือหน้าตาที่ผลิตภัณฑ์ AI-first ควรจะเป็น ทีนี้มาไล่เรียงทีละข้อ

1

Plan Mode ไม่ใช่ฟีเจอร์ แต่มันคือโลกทัศน์

Boris Cherny พูดประโยคที่หนักแน่นมากในรายการว่า

"เปลี่ยนไปใช้ plan mode ให้ Claude แสดงขั้นตอนที่จะทำออกมาทีละขั้นก่อน ตรงกันเรื่องแนวทางก่อนจะลงมือเขียนจริง — อัตราสำเร็จของงานที่ซับซ้อนสามารถเพิ่มขึ้นเป็นสองเท่าหรือสามเท่า"

สองเท่าหรือสามเท่า ตัวเลขนี้ตอนผมได้ยินครั้งแรกทำให้สะดุดทีเดียว

ในทางปฏิบัติก็แค่กด Shift+Tab สองครั้ง ในรายการยังพูดถึงว่า ตอนที่ Boris ทำฟีเจอร์ที่มีความยากด้วยตัวเอง เขาก็เปลี่ยนไปใช้ plan mode ก่อน จัดแนวแผนให้ตรงกันแล้วค่อยเขียนโค้ด ยังไม่ทันเขียนแม้แต่บรรทัดเดียว

คำถามคือ ทำไมสวิตช์เล็ก ๆ ที่ดูเหมือนตัวเลือก UI ถึงดึงอัตราสำเร็จขึ้นสูงขนาดนี้?

เพราะเบื้องหลังมันคือการตั้งต้นในระดับผลิตภัณฑ์ — ยอมรับว่าโมเดลสร้างภาพหลอนได้ ดังนั้นต้องเอาเจตนามาวางไว้บนโต๊ะให้ชัดก่อน Plan Mode ไม่ได้มีไว้ให้คุณดู แต่มันมีไว้ให้โมเดล — มันบังคับให้โมเดลคิดก่อน แล้วลงมือทำทีหลัง

หลายคนเข้าใจว่า Plan Mode คือ "ให้ผู้ใช้ตรวจแผนของ AI" แต่ที่จริงแล้วคำอธิบายที่แม่นยำกว่าคือ "อย่าให้ AI ข้ามขั้นตอนการคิดเด็ดขาด"

การทำให้ "การคิดให้เห็นเป็นรูปธรรม" กลายเป็นกลไกระดับผลิตภัณฑ์ นี่แหละคือโลกทัศน์

2

รื้อนั่งร้านตามขีดความสามารถของโมเดล แทนที่จะกองฟีเจอร์เพิ่ม

Cat Wu ใน Lenny's พูดถึงแนวคิดที่ละเอียดอ่อนคำหนึ่ง เรียกว่า AGI-pilled — พูดง่าย ๆ คือ "ระดับที่เราเดิมพันว่า AGI จะมา" เธอบอกว่าการบาลานซ์ระดับ AGI-pilled ให้พอดีเป็นหนึ่งในเรื่องที่ยากที่สุดในผลิตภัณฑ์

ถ้าเชื่อ AGI มากเกินไป จะสร้างวิสัยทัศน์ผลิตภัณฑ์ที่หลุดโลก ถ้าเชื่อน้อยเกินไป ก็จะเปลืองศักยภาพของโมเดล ทุกครั้งที่มีโมเดลใหม่ จุดสมดุลนี้ต้องปรับเทียบใหม่หมด

ปรัชญาของเธอกับ Boris คือ "ตัดฟีเจอร์ออกให้พอ ๆ กับที่สร้าง" การถอดฟีเจอร์หนึ่งออก (unship) ไม่ใช่เพราะมันล้มเหลว แต่เพราะเจอเส้นทางที่เรียบง่ายและตรงไปตรงมากว่า

ตัวอย่างชัดที่สุดคือ todo list ในยุคแรก โมเดลยังไม่สามารถเช็กรายการที่เสร็จแล้วได้อย่างน่าเชื่อถือ ทีมต้องเพิ่ม system reminder เตือนทุก ๆ สองสามข้อความ พอโมเดลรุ่นใหม่ออกมา "นั่งร้านช่วยเตือน" พวกนี้ก็กลายเป็นของเหลือใช้ ถอดทิ้งทันที

Cat ยังมีการทดสอบมาตรฐานตัวหนึ่ง — ให้ Claude Code เพิ่มฟีเจอร์ตารางให้ Excalidraw Opus 4 เมื่อเดือนมิถุนายน 2025 ทำได้บ้างเป็นครั้งคราว ไม่ถึงหนึ่งปีถัดมา Opus 4.6 ในเดือนเมษายน 2026 กลับทำสำเร็จในการรันครั้งเดียว และโชว์ live demo ต่อหน้าวิศวกรหลายพันคนได้

ช่วงเวลาแค่หนึ่งปี จาก "สำเร็จบ้างเป็นครั้งคราว" มาเป็น "สำเร็จในการรันครั้งเดียว" จังหวะการรื้อนั่งร้านขึ้นอยู่กับขีดความสามารถของโมเดลล้วน ๆ

คนอื่นวิ่งไล่ตามฟีเจอร์ พวกเขาวิ่งไล่ตามโมเดล — โมเดลเก่งขึ้นทีละนิ้ว นั่งร้านก็ถูกรื้อออกทีละนิ้ว

3

Swiss Cheese Model ป้องกันหลายชั้น ไม่ใช่ vibe coding

ข้างใน Anthropic เรียกกลไกชุดนี้ว่า Swiss Cheese Model — ซ้อนกันหลายชั้น แต่ละชั้นมีรู แต่พอทับรวมกันแล้วรูหายไป

เมื่อนำมาใช้ใน Claude Code Boris อธิบายในรายการถึงห้าขั้นตอนการทำงานของ PR หนึ่งตัว

Claude รันเทสต์เอง, ถ้าขาดเทสต์ก็เขียนเอง, รัน linter ที่ตัวเองสร้างขึ้น, ทำหน้าที่เป็น reviewer อัตโนมัติตรวจทานตัวเองอีกรอบ สุดท้ายปิดท้ายด้วยคนตรวจอีกครั้ง

สังเกตว่าสี่ชั้นแรกเป็นสิ่งที่ Claude Code ตั้งขึ้นมาให้ตัวเอง มันไม่เชื่อว่าชั้นไหนจะไม่พลาดเดี่ยว ๆ ดังนั้นก่อนจะถึงมือคนในชั้นที่ห้า มันจัดการด้วยตัวเองถึงสี่รอบ

ในมุมมองของ Boris vibe coding วิธีการเขียนแบบ "รู้สึกว่ามันน่าจะเวิร์ค" เหมาะกับโค้ดใช้แล้วทิ้งหรือ prototype แต่ไม่เหมาะกับระบบระดับ production เหตุผลง่ายนิดเดียว — ด้านตรงข้ามของระบบ production ไม่ใช่โมเดลไม่เก่งพอ แต่มันคือเหตุการณ์ที่ผลลัพธ์ผิดพลาดจะต้องเกิดแน่ ๆ

นี่คือจุดที่คมที่สุดของแนวคิด Swiss Cheese: ผลิตภัณฑ์ AI ระดับอุตสาหกรรมจริง ไม่ได้พนันว่าโมเดลจะไม่พลาด แต่ตั้งสมมติฐานว่ามันจะต้องพลาด แล้วใช้โครงสร้างมารองรับ

4

Antfooding — ทุก 5 นาทีมี feedback หนึ่งชิ้น

วิศวกรใน Anthropic มีฉายาภายในว่า ants (มด) ดังนั้นพวกเขาเลยเรียกวงจรการใช้งานภายในตัวเองว่า Antfooding — รูปแบบวิวัฒนาการของ dogfooding

Cat พูดในรายการประโยคที่ฟังดูบ้ามากว่า

"ช่องทางฟีดแบ็กของเรา ทุก ๆ 5 นาทีจะมีข้อความใหม่เด้งขึ้นมา"

5 นาทีต่อ 1 ข้อความ ไม่ว่าจะเป็นคนชอบฟีเจอร์นี้จริง ๆ มีบั๊ก จะ unship หรือไม่ — ทุก 5 นาทีได้สัญญาณมาหนึ่งครั้ง

วิศวกรหลายร้อยคนในออฟฟิศใช้ Claude Code ทุกวัน Cat เดินรอบออฟฟิศก็เห็นฟีดแบ็กสด ๆ ภาพนี้สำคัญมาก — กลุ่มผู้ใช้กลุ่มแรกของ Claude Code คือกลุ่มคนที่เรื่องมากที่สุดในโลก เขียนโค้ดเก่งที่สุด และฟาดเละได้หนักที่สุด

ออกเวอร์ชัน → ใช้ภายในแบบ dogfooding → รับฟีดแบ็กทุกไม่กี่นาที → ปรับแต่ง → ออกเวอร์ชันอีกครั้ง วงจรนี้สั้นแค่ไหน? เมื่อก่อนหนึ่งฟีเจอร์จากเริ่มคิดถึงขึ้นไลฟ์ใช้เวลา 6 เดือน (วางแผน + ปรับแนวข้ามทีม + เขียน PRD) ตอนนี้จังหวะโดยรวมภายใน Anthropic บีบลงเหลือ ship ได้ภายใน 24 ชั่วโมง — สังเกตว่านี่คือจังหวะการ iteration ของทั้งทีม ไม่ได้หมายความว่าฟีเจอร์เดิมจาก 6 เดือนเหลือ 24 ชั่วโมง

ไม่มีผู้ใช้คนไหนเรื่องมากเท่าวิศวกรที่ติดขัดเพราะ Claude Code อีกแล้ว dogfooding ของผลิตภัณฑ์ทั่วไปคือ "เราใช้เองด้วย" ส่วน Antfooding คือ "เราใช้หนักกว่าทุกคนบนโลก"

5

ให้ Subagent จับผิดกันเอง แทนที่จะตัดสินด้วยไม้ตายเดียว

ส่วนนี้อาจเป็นช่วงที่พลิกความเข้าใจของผมมากที่สุดในทั้งบทสัมภาษณ์

Boris อธิบายวิธีที่เขารันคำสั่ง code review ของตัวเขาว่า

เริ่มต้นแบบขนานด้วย subagent หลาย ๆ ตัว — ตัวหนึ่งเช็คสไตล์โค้ด ตัวหนึ่งไล่ดู git history ว่าก่อนหน้านี้ทำยังไง ตัวหนึ่งหาบั๊กที่เห็นชัด รอบแรกจับได้ทั้งปัญหาจริงและ false alarm ผมก็เลยเปิด subagent อีก 5 ตัว เพื่อรับหน้าที่จับผิดสิ่งที่พวกก่อนหน้านี้เจอ ผลลัพธ์คือเจอปัญหาจริงทั้งหมด และ false positive ถูกกำจัดหมด

อ่านถึงตรงนี้ผมอึ้งไปชั่วขณะ ปกติเวลาผมทำผลิตภัณฑ์ Agent สัญชาตญาณแรกคือ "เปลี่ยนเป็นโมเดลที่เก่งขึ้น" — เมื่อคุณภาพมีปัญหา ความคิดแรกคือโมเดลไม่ดีพอ ไม่เคยคิดถึงเส้นทางนี้: ให้ Agent N ตัวจับผิดกันเอง คุณภาพไม่ได้ขึ้นอยู่กับฝีมือของโมเดล แต่อยู่ที่การปะทะกันระหว่างโมเดล

คนส่วนใหญ่ทำผลิตภัณฑ์ Agent ด้วยแนวคิด "ใช้โมเดลที่เก่งที่สุดตัวเดียวจัดการทุกอย่าง" แต่ Claude Code กลับกัน — ใช้หลาย ๆ โมเดลตีกันเอง รอบแรก subagent ตรวจทาน รอบสอง subagent เอาหน้าที่จับผิดรอบแรกโดยเฉพาะ

Cat เองก็ใช้คอนฟิกคล้ายกัน — มี planner subagent หนึ่งตัว code review subagent หนึ่งตัว ตอนทำงานแบบ real-time ก็ใช้ subagent ใน CI ก็ใช้ slash command สิ่งที่ทำคือเรื่องเดียวกัน

ต้นทุนมีจริง การทำงานที่เน้น subagent มากทำให้กิน token เป็น 2 ถึง 5 เท่าของการรัน single agent เมื่อเทียบกับข้อมูลสาธารณะของอุตสาหกรรม องค์กรที่ deploy เฉลี่ยใช้ประมาณ $150-$250 ต่อคนพัฒนาต่อเดือน แต่ใน Anthropic เคยมีเคสสุดโต่งที่ผู้ใช้คนเดียวเบิร์น token มูลค่า 1.5 แสนดอลลาร์สหรัฐในหนึ่งเดือน — แม้จะเป็นเคสเดี่ยว แต่ก็บอกได้ว่าขีดบนของวิธีการนี้มันน่ากลัวแค่ไหน

แต่ความเห็นของ Boris แข็งมาก: การให้ subagent จับผิดกันเอง กลับให้ผลลัพธ์ที่สะอาดกว่า การปะทะกันคือแหล่งกำเนิดของคุณภาพ

แทนที่จะเชื่อว่า AI จะตอบถูกในครั้งเดียว ให้ AI ตีหน้ากันเองดีกว่า

6

Stop Hook เขียนนิยามของคำว่า "เสร็จ" ใหม่

บทก่อนพูดถึงการไม่เชื่อใจการตัดสินจุดเดียว บทนี้ก้าวต่อไปอีกขั้น — กระทั่งเรื่องที่ "โมเดลบอกว่าทำเสร็จแล้ว" ก็ไม่ควรเชื่อ

ทางออกของ Boris คือ Stop Hook

"คุณสามารถปล่อยให้โมเดลทำงานต่อเนื่องไปเรื่อย ๆ จนกว่ามันจะเสร็จจริง ๆ ได้"

วิธีทำคือติด stop hook เข้ากับชุดテスト (test suite) — ถ้าテストไม่ผ่านก็โยน error กลับให้ Claude แก้ แล้วรันใหม่อีกรอบ จนกว่าテストจะผ่านทั้งหมดถึงจะถือว่าเสร็จ "ฉันทำเสร็จแล้ว" ไม่นับว่าเสร็จ "テストผ่านแล้ว" ต่างหากที่แปลว่าเสร็จ

Boris เน้นเป็นพิเศษในรายการว่า การให้ Claude มีวงจรที่ตรวจสอบตัวเองได้ คือ สิ่งสำคัญที่สุดอย่างหนึ่ง ที่ทำให้ได้ผลลัพธ์ดีจาก Claude Code — พอมีวงจรนี้ คุณภาพสุดท้ายจะดีขึ้น 2 ถึง 3 เท่า

ตัวเขาเองยังรัน PostToolUse hook เพื่อจัดฟอร์แมตโค้ดอัตโนมัติ — ปกติ Claude มักฟอร์แมตไม่มีปัญหา hook นี้จะมาแก้ส่วนที่เหลืออีก 10% ป้องกันไม่ให้ CI ล่ม

เมื่อเอามองซ้อนกันสองชั้น Stop Hook กำลังทำบางอย่างที่ลงลึกถึงราก — มันกำลังนิยามคำว่า "เสร็จ" ขึ้นมาใหม่ ในยุค AI ผลลัพธ์เท่านั้นที่ซื่อสัตย์แค่หนึ่งเดียว การ "เสร็จ" ที่โมเดลประกาศเองไม่นับ ของที่รันผ่านเท่านั้นที่นับ

7

จาก typing ไปสู่ deciding — สิ่งที่หายากที่สุดคือวิจารณญาณ

บทสุดท้าย Cat พูดใน Lenny's ประโยคหนึ่งที่ผมหยิบมาโพสต์ในกรุ๊ปให้คนดูซ้ำแล้วซ้ำเล่า

"โค้ดถูกลงเรื่อย ๆ สิ่งที่มีค่ามากกว่ากลายเป็น 'การตัดสินใจว่าควรเขียนอะไร' — และการรู้ว่าสิ่งหนึ่งทำยากแค่ไหน ช่วยให้คุณตัดสินใจเรื่องความสำคัญได้"

เธอพูดต่อไปอีกว่า ทุกบทบาทกำลังหลอมรวมกัน — PM ทำงานแบบวิศวกร วิศวกรทำงานแบบ PM นักออกแบบทำงานแบบ PM แทบทุกคนในทีมของเธอที่เป็น PM เคยเป็นวิศวกร หรือไม่ก็ยื่น PR ด้วยตัวเอง นักออกแบบทั้งหมดก็จบสาย front-end วิศวกร

มุมมองของ Boris ยิ่งเข้มข้นขึ้นไปอีก ในมุมเขา วิศวกรซอฟต์แวร์เป็นเหมือนนักคัดลอกคัมภีร์ AI เป็นเหมือนแท่นพิมพ์ — โค้ดไม่ใช่ของหายากอีกต่อไป

ถ้าเอา 6 ข้อก่อนหน้านี้มาย้อนมองในบทนี้ จะพบว่ามันคือเรื่องเดียวกันทั้งหมด —

Plan Mode ทำให้คุณต้องแสดงวิจารณญาณออกมาให้เห็น; การรื้อนั่งร้านทำให้คุณปรับวิจารณญาณตามขีดความสามารถของโมเดล; Swiss Cheese ทำให้คุณไม่ต้องตัดสินว่า "โมเดลจะพลาดไหม"; Antfooding ทำให้วิจารณญาณของคุณสัมผัสกับฟีดแบ็กจริงให้เร็วที่สุด; Subagent จับผิดกัน ทำหน้าที่ตัดสินแทนวิจารณญาณของคุณที่มีต่อวิจารณญาณของโมเดล; Stop Hook แทนที่คุณในการตัดสินว่า "เสร็จ" จริงหรือไม่

ปรัชญาผลิตภัณฑ์ทั้งหมดนี้ ทำงานเพื่อเป้าหมายเดียวกัน — ปลดปล่อยคนออกจาก typing และให้โฟกัสกับ deciding

Claude Code ไม่ได้มาแทนที่วิศวกร แต่มันดึงวิศวกรให้ลุกขึ้นจากที่นั่งของคนพิมพ์ดีด

---

เมื่อร้อยเรียงแนวคิด 7 ข้อนี้เข้าด้วยกัน มันคือโลกทัศน์ของผลิตภัณฑ์ Claude Code —

ยอมรับว่า AI ไม่น่าเชื่อถือ จึงสร้างการป้องกันหลายชั้น ไม่เชื่อการตัดสินจุดเดียว จึงให้มันจับผิดกันเอง ไม่สนว่าโมเดลจะประกาศตัวเองว่า "เสร็จ" สนแต่ผลลัพธ์ที่รันผ่าน ปลดปล่อยคนจากที่นั่งของคนพิมพ์ดีด ให้ทุ่มเทอยู่กับการตัดสินใจ

หลังอ่านจบ ความรู้สึกใหญ่ที่สุดไม่ใช่ความทึ่ง แต่คือคำว่า ลงมือเปลี่ยนเองด้วยความตื่นตัว

ผลิตภัณฑ์ที่เราใช้อยู่ทุกวันนี้ กำลังทำงานภายใต้โลกทัศน์ชุดนี้ — มันสมมติฐานว่าผิดพลาดต้องเกิด, จัดระบบให้เกิดการปะทะกัน, นิยามคำว่า "เสร็จ" เสียใหม่, ผลักคนไปยืนอยู่ในตำแหน่งของคนตัดสิน แล้ววิธีที่เราทำผลิตภัณฑ์ ทำทีม ทำงานตรงหน้าในแต่ละวัน สมควรจะตามทันด้วยหรือไม่? การประสานงานในทีมต้องเปลี่ยน, เครื่องมือต้องเปลี่ยน, นิสัยการทำงานต้องเปลี่ยน, กระทั่ง "อะไรถึงเรียกว่าทำงานหนึ่งเสร็จแล้ว" ก็ต้องถูกนิยามใหม่

ถ้าไม่ลงมือเปลี่ยนด้วยตัวเอง ก็จะถูกโลกทัศน์นี้ผลักให้เดินไปอยู่ดี

แนะนำให้คุณไปฟังบทสัมภาษณ์ทั้งสองตอนนี้ดูด้วยตัวเอง มีประโยชน์กว่าที่ผมพ่นยืดยาวอีกมาก

ระหว่างที่คุณใช้ Claude Code ดีไซน์ไหนที่พลิกความเข้าใจของคุณมากที่สุด? คอมเมนต์คุยกันได้ครับ