ในงาน Anthropic Code with Claude Conference ที่ผ่านมา Dan Carey ผู้รับหน้าที่ Product Manager ของ Anthropic Labs ขึ้นมาเล่าเบื้องหลังการสร้าง Claude Design ตั้งแต่วันแรกที่เป็นแค่ไอเดีย จนปล่อย Research Preview ให้คนทั่วไปได้ลองใช้ภายในเวลาเพียง 10 สัปดาห์ โดยใช้ทีมงานหลักเพียง 3 คนตลอดช่วงพัฒนา (ก่อนขยายเป็น 5 คนช่วงสัปดาห์สุดท้ายก่อนเปิดตัว)

ตัวเลขนี้ไม่ใช่แค่เรื่องของการทำตัวเลขให้ดูว้าว แต่เป็นภาพสะท้อนวิธีคิดและวัฒนธรรมการทำงานของ Anthropic Labs ที่ใช้สร้างเครื่องมืออย่าง Claude Code, Model Context Protocol (MCP), Skills, Claude in Chrome และ hands-free audio

Dan เล่าว่าเบื้องหลังความเร็วระดับนี้ คือการรันลูป "ship-watch-learn" ซ้ำๆ ถึง 50 ถึง 100 รอบในเวลาไม่ถึงสามเดือน โดยไม่มี PRD ขนาดยาว ไม่มี vision doc ลอยๆ ไม่มีการจัดประชุม alignment ยืดเยื้อ และไม่มีแผนอัตรากำลังคนล่วงหน้า จุดเริ่มต้นทั้งหมดมาจากโปรโตไทป์ตัวเดียวที่ Nate ดีไซเนอร์ในทีม แฮกขึ้นมาในวันหยุดสุดสัปดาห์โดยเอา Agent SDK มาครอบด้วย IDE wrapper แบบบางๆ

1. จุดเริ่มต้น: เมื่อ Claude Code ย้ายคอขวดจาก Engineer ไปหา Designer และ PM

Dan ชี้ให้เห็นว่า Claude Design ไม่ได้เกิดจากการนั่งวาดวิสัยทัศน์ 5 ปี แต่เกิดจากผลพลอยได้ของ Claude Code โดยตรง เมื่อเครื่องมือ AI coding ช่วยให้ทีมวิศวกรเขียนโค้ดได้เร็วขึ้นจนย่นระยะเวลาส่งมอบฟีเจอร์จาก 6 เดือนเหลือ 1 เดือน จาก 1 สัปดาห์เหลือแค่ 1 วัน คอขวดของกระบวนการพัฒนาซอฟต์แวร์จึงไม่ได้อยู่ที่ "การ build ฟีเจอร์" อีกต่อไป แต่ย้ายมาอยู่ที่ "การค้นหาว่าอะไรคือสิ่งที่ควรสร้างตั้งแต่แรก" ซึ่งเป็นงานฝั่ง Product Designer และ PM โดยตรง

เมื่อเจอปัญหานี้ ทางเลือกมี 2 ทาง:

1. ข้ามขั้นตอน discovery แล้วรีบตัดสินใจ ซึ่งเสี่ยงมากที่จะสร้างของผิดทิศทางได้เร็วกว่าเดิม
2. หาวิธีให้ Designer และ PM เร่งวงรอบการทดลองของตัวเองให้ทันสปีดของ Engineer

ทีม Anthropic Labs เลือกทางที่สอง Nate ซึ่งเคยเป็นดีไซเนอร์ของ Claude Code มาก่อน จึงหยิบ Agent SDK ผสมกับ skill ของ Claude Code มาประกอบเป็นโปรโตไทป์หยาบๆ ภายในวันหยุดสุดสัปดาห์ แล้วอัดคลิป screen recording โพสต์ลง Slack ของบริษัท เพื่อให้เพื่อนร่วมทีมเข้ามาลองเล่นและคอมเมนต์ได้ทันที

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

2. โยน PRD ทิ้ง แล้วสื่อสารด้วย Prototype

ทีม Anthropic Labs พบว่าเอกสาร PRD (Product Requirement Document) แบบดั้งเดิมมีปัญหาเชิงโครงสร้าง เพราะคนสองคนที่อ่านเอกสารฉบับเดียวกัน มักจะจินตนาการภาพผลิตภัณฑ์ออกมาคนละแบบ และบ่อยครั้งก็ไม่ตรงกับสิ่งที่คนเขียนคิดไว้แต่แรก PRD จึงเป็นสิ่งที่คลุมเครือโดยธรรมชาติ ในขณะที่โปรโตไทป์เป็นสื่อที่จับต้องได้ คลิกเล่นได้จริง และทำให้ทุกคนในทีมเห็นภาพเดียวกันทันที

Dan อธิบายว่ากระบวนการขึ้นโปรโตไทป์ของทีมสั้นลงเหลือเพียงไม่กี่นาที โดยเริ่มจากการนั่งคุยกับเพื่อนร่วมทีมหนึ่งคน บันทึกเสียง แล้วแปลงเป็นข้อความ transcript ทีมจะไม่เสียเวลาคุยเรื่องตำแหน่งปุ่มหรือหน้าตา UI ล่วงหน้า แต่จะคุยว่าปัญหาคืออะไร ทางออกที่ดีควรมีหน้าตาอย่างไร และทำไมถึงต้องแก้ปัญหานี้ จากนั้นป้อน transcript ให้ Claude Design สร้างตัวเลือกโปรโตไทป์ออกมา 3 รูปแบบ กระบวนการนี้เข้ามาแทนที่การเขียน PRD ของ Dan อย่างสิ้นเชิง แม้ว่าเขาจะเขียนเอกสาร PRD มาเกือบ 20 ปีก็ตาม

นอกจากนี้ ทีมยังมีวัฒนธรรมที่เรียกว่า "pitch-off" ซึ่งเป็นการรวมตัวกันเพื่อชวนเพื่อนร่วมงานมาช่วยทำ bet ของตัวเอง ในการ pitch ครั้งแรกด้วย Claude Design เกือบ 100% ของไอเดียในห้องถูกเปลี่ยนเป็นโปรโตไทป์หรือสไลด์ที่รันสดๆ ได้ในครึ่งหลังของเซสชัน

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

3. ทีม 3 คน กับบทบาทที่หลอมรวมเข้าหากัน

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

เมื่อเจอสัญญาณที่เข้าเป้า ทีมจะขยายกำลังคนเป็น 3 คน ซึ่งเป็นขนาดทีมที่กระชับและมีภาระเรื่อง coordination ต่ำที่สุด หากโปรเจกต์พิสูจน์ตัวเองได้แล้ว จึงค่อยขยายเป็น 5 คนก่อนเปิดตัวจริง

สิ่งที่ทำให้ทีม 3 คนขับเคลื่อนงานใหญ่ได้ คือการที่เส้นแบ่งบทบาทแบบเดิมละลายเข้าหากัน:

• Engineer ออกไปพูดคุยเก็บ requirement จากผู้ใช้โดยตรง
• PM เขียนโค้ดและปรับแก้โปรโตไทป์เอง
• Designer วิเคราะห์ข้อมูล data analytics ด้วยตัวเอง

ทุกคนยังคงความเชี่ยวชาญหลักของตนไว้ แต่สามารถหยิบจับงานข้ามสายได้ทันที สมาชิกคนใดคนหนึ่งสามารถคุยกับผู้ใช้ 10 คน ออกแบบทางออก ขึ้นโค้ด และอ่าน feedback ได้จบในตัวโดยไม่ต้องรอตั้งการประชุม alignment ใหญ่โต หากจำเป็นต้องปรึกษากัน ก็แค่หันไปคุยกับคนที่นั่งข้างๆ

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

4. วงจรการทำงาน 4 ขั้น: คุยกับผู้ใช้ ออกแบบ ส่งมอบ และอ่านฟีดแบ็ก

วงจรการทำงานของทีม Anthropic Labs สรุปได้เป็น 4 ขั้นตอนที่เรียบง่าย: Talk to users → Design features → Ship code → Read feedback แล้ววนซ้ำในความถี่ระดับวัน สิ่งสำคัญคือความเร็วและวินัยในการตั้งคำถามอยู่เสมอว่า "ขั้นตอนนี้เรายังทำเองอยู่ทำไม ในเมื่อ Claude ช่วยทำได้?"

คุยกับผู้ใช้ทุกวัน (Talk to users)

ทีมเปิดช่องทาง Slack ร่วมกับผู้ใช้ทุกคนและทดลองใช้กันเองภายในอย่างหนัก (dog-fooding) จากนั้นดึง Claude เข้ามาช่วยอ่านบทสนทนาและจับกลุ่มประเด็นร่วม ทีมไม่ได้ให้ AI มาคุยแทนคน แต่ให้ AI ช่วยวิเคราะห์ข้อความดิบปริมาณมากให้เห็นภาพรวมได้ทันที

ออกแบบฟีเจอร์ด้วยเครื่องมือของตัวเอง (Design features)

ในช่วงแรกที่ยังไม่มี Claude Design ทีมใช้ Claude Code ขึ้นโปรโตไทป์แล้วแชร์ผ่านคลิปวิดีโอ พอระบบเริ่มเข้าที่ ทีมก็ใช้ Claude Design มาช่วยออกแบบ Claude Design เอง ฟีเจอร์หลักอย่างโหมด multiplayer และการส่งงานต่อให้ Claude Code ล้วนเกิดจากการแก้ความยุ่งยากในวงรอบการทำงานของทีมเองทั้งสิ้น

ส่งมอบโค้ดโดยลดรอยต่อระหว่างเครื่องมือ (Ship code)

ก่อนจะมีระบบ handoff ระหว่าง Claude Design กับ Claude Code ทีมต้อง export ไฟล์แล้วนำเข้าพร้อมพิมพ์ context ซ้ำใหม่ทุกรอบ ทีมจึงสร้างระบบส่งต่อโค้ดขึ้นมาแก้ปัญหาของตัวเอง ซึ่งกลายเป็นฟีเจอร์ที่ผู้ใช้ภายนอกเรียกร้องเข้ามามากที่สุดเป็นอันดับสอง

อ่านฟีดแบ็กด้วยระบบจับกลุ่มอัตโนมัติ (Read feedback)

เมื่อมีผู้ใช้มากขึ้น ฟีดแบ็กก็หลั่งไหลเข้ามาจนอ่านไม่ทัน ทีมจึงใช้เวลาช่วงบ่ายวันเดียวสร้าง feedback clustering tool ขึ้นมา โดยให้ Claude ช่วยอ่านฟีดแบ็กทั้งหมด จับคู่กับระบบมอนิเตอร์และ error trace เพื่อวิเคราะห์หาบั๊กและเสนอแนวทางแก้ไข ให้ทีมกดปุ่มอนุมัติเข้ากระบวนการพัฒนาต่อได้ทันที

5. รู้ว่าผิดทางให้รีบถอย: บทเรียนจากฟีเจอร์ Advanced Controls

ความเร็วในการทำงานไม่ได้การันตีว่าจะตัดสินใจถูกเสมอไป Dan เล่าถึงฟีเจอร์ advanced controls ที่ทีมสร้างขึ้นเพื่อให้ผู้ใช้ปรับแต่งหน้าจอได้ละเอียดถึงระดับพิกเซล ในช่วงแรกทีมได้เสียงตอบรับเชิงบวกจากกลุ่ม power user ที่ใช้งานหนัก แต่เมื่อตรวจดูข้อมูลการใช้งานจริง กลับพบว่าผู้ใช้ส่วนใหญ่สับสนและรู้สึกว่าทำให้เครื่องมือซับซ้อนเกินไป

ทีมจึงตัดสินใจถอดฟีเจอร์นี้ออกทั้งหมดภายในเวลา 1 สัปดาห์ Dan ชี้ว่าหากทำงานในรอบรายไตรมาส การเดินผิดทางครั้งนี้อาจผลาญเวลาไปทั้งไตรมาส แต่ด้วยรอบการทำงานที่สั้น ทำให้ทีมรู้ตัวและแก้ไขได้ทันที

บทเรียนสำคัญคือ:

1. เครื่องมือที่ดีควรช่วยยกระดับงานของคนส่วนใหญ่ ไม่ใช่สร้างความซับซ้อนเพื่อ power user เพียงกลุ่มเดียว
2. ควรเปิดให้ระบบต่อเชื่อมกับภายนอกได้ง่าย เช่น การเปิดให้ export เป็น HTML/CSS/JavaScript หรือเชื่อมต่อผ่าน MCP เพื่อให้ผู้ใช้ที่มีความต้องการเฉพาะทางนำไปจัดการต่อเองได้

6. โฟกัสกับสิ่งที่ "เกือบจะเวิร์ก"

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

สิ่งที่ทีมมองหาในช่วงเริ่มต้นไม่ใช่ผลิตภัณฑ์ที่ไร้ที่ติ แต่เป็นสัญญาณความมหัศจรรย์เล็กๆ (hint of magic) ที่บอกว่าทิศทางของผลิตภัณฑ์มาถูกทางแล้ว

7. 62 รายการปรับปรุงในสุดสัปดาห์แรกหลังเปิดตัว

เพื่อสะท้อนให้เห็นถึงสปีดในการปรับปรุง หลังจากการเปิดตัว Claude Design ในวันศุกร์ ทีมได้ส่งมอบการปรับปรุงเพิ่มอีกถึง 62 รายการก่อนถึงเช้าวันจันทร์ ครอบคลุมทั้งการประหยัด token, การจัดการรูปภาพ, การสำรวจ codebase และการเร่งความเร็วในการ export สิ่งนี้ไม่ใช่การโหมทำงานข้ามคืน แต่เป็นจังหวะการทำงานที่ฝึกฝนมาตลอด 10 สัปดาห์

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

8. 3 สิ่งที่เริ่มทดลองทำได้ตั้งแต่วันพรุ่งนี้

Dan สรุปคำแนะนำ 3 ข้อที่ทีมพัฒนาสามารถหยิบไปเริ่มใช้ได้ทันที:

1. หยุดเขียน PRD ขนาดยาว: หันมาคุยเรื่องปัญหากับเงื่อนไขของทางออกที่ดี บันทึกเสียงแล้วให้ AI ช่วยขึ้นตัวเลือกโปรโตไทป์ 3 แบบแทน
2. สร้าง internal tool ง่ายๆ ในบ่ายเดียว: อย่ามัวแต่รอซอฟต์แวร์สำเร็จรูป ลองหยิบโจทย์ติดขัดในทีมมาให้ AI ช่วยเขียนสคริปต์แก้ปัญหาเฉพาะหน้าขึ้นมาใช้ก่อน
3. หยิบฟีเจอร์จริงจากผู้ใช้มาส่งมอบใน 24 ชั่วโมง: ลองเลือก request ของผู้ใช้ที่ไม่ใช่งานแก้เล็กๆ มาทำและส่งให้ผู้ใช้ลองภายในหนึ่งวัน เพื่อตรวจดูว่ากระบวนการทำงานของทีมติดขัดตรงขั้นตอนไหนบ้าง ไม่ว่าจะเป็นเรื่อง pipeline การ deploy หรือการ review โค้ด

บทสรุป

เบื้องหลังการสร้าง Claude Design ใน 10 สัปดาห์ของ Anthropic Labs สะท้อนให้เห็นว่า เมื่อ AI ช่วยลดเวลาในการเขียนโค้ดลงแล้ว ความได้เปรียบจะตกอยู่กับทีมที่ทดลองได้เร็วที่สุด การเปลี่ยนจากการเขียนเอกสารมาเป็นการสร้างโปรโตไทป์ การลดเส้นแบ่งบทบาทในทีม และการรักษาจังหวะการส่งมอบงานในระดับรายวัน คือแบบแผนการทำงานที่ทุกทีมสามารถนำไปปรับใช้ได้จริง

ที่มา: Designing with Claude: From prompt to production, Anthropic Code with Claude Conference โดย Dan Carey, Product Manager, Anthropic Labs