ทำให้ Claude Code กลายเป็นคู่หูด้านการออกแบบที่ดีที่สุด
(betweentheprompts.com)- ตอนเริ่มใช้ Claude Code ครั้งแรก ผู้เขียนเข้าหาด้วยวิธี สั่งผ่านพรอมป์ตและแก้ไขวนซ้ำ แบบง่าย ๆ แต่เมื่อเป็นงานซับซ้อนก็พบปัญหาเรื่อง การพึ่งพาประวัติการสนทนาและข้อจำกัดของคอนเท็กซ์
- เพื่อแก้ปัญหานี้ จึงให้เขา เขียนเอกสารแผน (plan document) ก่อนลงมือพัฒนาฟีเจอร์ และใช้เอกสารนี้เป็น แหล่งความจริงหนึ่งเดียว (SSOT) ของเซสชันใหม่
- เอกสารแผนประกอบด้วยการสรุปความต้องการใหม่ คำอธิบายรายละเอียดการพัฒนา คำสั่งสำหรับตรวจสอบคุณภาพโค้ด ฯลฯ และยังถูกอัปเดตต่อเนื่องเป็น เอกสารมีชีวิต (living document) แม้ระหว่างการพัฒนาด้วย
- วิธีนี้ช่วยแก้ปัญหา การสูญเสียบริบท และแม้จะเริ่มเซสชันใหม่ก็สามารถทำงานต่อในโปรเจ็กต์ได้ด้วยเอกสารเพียงฉบับเดียว
- ผลลัพธ์คือ AI ไม่ได้เป็นแค่เครื่องมือสำหรับลงมือทำ แต่ทำหน้าที่เป็น คู่หูด้านการออกแบบเชิงร่วมมือ ที่กระตุ้นให้นักพัฒนาคิดและบันทึกงานออกแบบได้ลึกขึ้น
มุมมองต่อปัญหา: ข้อจำกัดของวิธีสนทนาแบบตรงไปตรงมา
- เมื่อต้องทำงานกับ Claude Code แบบโต้ตอบกัน แม้จะเหมาะกับงานง่าย ๆ แต่เมื่อขนาดและความซับซ้อนของงานเพิ่มขึ้น ก็เกิด ข้อจำกัดสำคัญ หลายอย่าง
- บทสนทนากลายเป็นแหล่งความจริงเพียงหนึ่งเดียว ทำให้ข้อความใหม่สามารถเขียนทับคำสั่งก่อนหน้าได้ง่าย และยากจะรู้ได้ชัดว่าเกิดขึ้นตอนไหน
- เนื่องจาก AI มี ข้อจำกัดด้านขนาดคอนเท็กซ์ เมื่อบทสนทนายาวขึ้น ข้อมูลก่อนหน้าก็อาจหล่นหายไปได้
- แม้ Claude Code จะมีฟังก์ชันบีบอัดบทสนทนา แต่ก็ยังไม่สามารถแก้ข้อจำกัดนี้ได้ทั้งหมด
ทดลองใช้แนวทางที่ยึดเอกสารแผนเป็นศูนย์กลาง
- เพื่อแก้ปัญหาเหล่านี้ จึงลองใช้ แนวทางที่อิงเอกสารแผน
- ตอนเริ่มต้น จะอธิบายให้ Claude Code ฟังอย่างละเอียดที่สุดเท่าที่ทำได้เกี่ยวกับฟีเจอร์ที่จะพัฒนา หรือบั๊กที่ต้องแก้
- มีการอ้างถึงไฟล์ซอร์สที่มีอยู่แล้วหรือเอกสารแผนที่เคยเขียนไว้ก่อนหน้าเพื่อใช้เป็นข้อมูลอ้างอิงด้วย
- หลีกเลี่ยงการสั่งรายละเอียดการพัฒนาแบบเจาะจงเกินไป เพื่อเปิดโอกาสให้ AI ทำหน้าที่ เสนอแนวทางการออกแบบ
- เมื่อได้เอกสารแผนที่น่าพอใจเพียงพอแล้ว ก็ล้างประวัติการสนทนาและเริ่มใหม่โดยใช้แผนนั้นเป็นบริบทเพียงอย่างเดียว
- ในแผนจะมีสรุปฟังก์ชัน แผนการพัฒนา โค้ดและรหัสเทียม รวมถึงคำสั่งสำหรับ type/lint/test
กระบวนการออกแบบแบบร่วมมือ
- หากไม่ชอบแบบที่ AI เสนอ ก็จะให้ฟีดแบ็กอย่างเฉพาะเจาะจงเพื่อชี้นำไปสู่ แนวทางที่ปรับแก้แล้ว
- ระหว่างการพูดคุย บางครั้งก็พบว่าข้อเสนอแรกของ AI เหมาะสมกว่า และมีประสิทธิภาพกว่าการเขียนโค้ดโดยอาศัยการออกแบบของตัวเองล้วน ๆ
- บทสนทนาที่เป็นระบบให้ประสบการณ์คล้ายกับการคุยแผนกับเพื่อนร่วมทีมนักพัฒนา
- AI อาจไม่ได้เสนอแนวทางที่ต่างออกไปโดยสิ้นเชิงด้วยตัวเองเสมอไป แต่ถ้าถาม ก็สามารถเสนอทางเลือกอื่นได้เช่นกัน
วิธีทำงานแบบเอกสารมีชีวิต (Living Document)
- เอกสารแผนไม่ได้เขียนครั้งเดียวแล้วจบ แต่ถูก อัปเดตอย่างต่อเนื่องแม้ระหว่างการพัฒนาฟีเจอร์
- การเปลี่ยนแปลงที่พบระหว่างการพัฒนา การตรวจ type การ lint หรือการทดสอบ จะถูกสะท้อนกลับเข้าไปแบบเรียลไทม์
- สร้างนิสัยให้ตรวจสอบสถานะล่าสุดของแผนทุกครั้งที่คอมมิตโค้ด
- เมื่อแผนถูกดูแลให้ทันสมัยอยู่เสมอ แม้จะเปิดบทสนทนาเซสชันใหม่ ก็เพียงแนบแผนก็สามารถทำงานต่อได้โดยไม่สูญเสียบริบท
การรีวิวโค้ดและการเปลี่ยนแปลงของนิสัยการพัฒนา
- หลังเริ่มลงมือพัฒนาแล้ว จะคอยตรวจสอบการเปลี่ยนแปลงเป็นระยะ และหากพอใจกับผลลัพธ์ก็อาจเชื่อถือการทำงานของ AI มากขึ้น
- ตอนรีวิวโค้ดขั้นสุดท้าย เอกสารแผนที่อัปเดตแล้วช่วยให้เข้าใจ เหตุผลเบื้องหลังการตัดสินใจทางเทคนิค ได้ดี
- การวางแผนอย่างรอบคอบและบันทึกเป็นเอกสารล่วงหน้าทำให้ได้ประสบการณ์เติบโตเป็น นักพัฒนาที่ดีกว่าเดิม
- เพราะต้องอธิบายให้ AI เข้าใจ จึงช่วยให้ผู้พัฒนาจัดระเบียบกระบวนการตัดสินใจของตนเองได้ชัดเจนขึ้น
จากความวุ่นวายสู่ความเป็นระบบ
- วิธีนี้ทำให้เอกสารแผนกลายเป็น แหล่งความจริงเพียงหนึ่งเดียว ช่วยแก้ปัญหาการสูญเสียบริบท และส่งเสริมการคิดเชิงสถาปัตยกรรม
- เอกสารแผนมีทั้งสเปกและบันทึกการพัฒนา โดยไม่ได้บันทึกแค่ว่า “ทำอะไร” แต่รวมถึง “ทำไม” และ “อย่างไร” ด้วย
- ผลลัพธ์สุดท้ายคือกระบวนการพัฒนาที่มีการวางแผน มีเอกสารรองรับอย่างดี และเชื่อถือได้สูง
- AI จึงไม่ได้เป็นเพียงผู้ลงมือพัฒนา แต่กลายเป็น คู่หูด้านการออกแบบเชิงร่วมมือ อย่างแท้จริง
2 ความคิดเห็น
ดูเหมือนว่าสัดส่วนของบทบาท PM และสถาปนิกในเวิร์กโฟลว์ของนักพัฒนาจะเพิ่มมากขึ้น
ความคิดเห็นจาก Hacker News
ตลอด 2 สัปดาห์ที่ผ่านมา ผมทุ่มสุดตัวทุกเย็นเพื่อสร้าง "พรอมป์ต์ที่สมบูรณ์แบบ" ที่จะใช้
claude codeทำโปรเจกต์ให้เสร็จได้ในครั้งเดียว สุดท้ายก็ออกแบบให้CLAUDE.mdอ้างอิงไฟล์ Markdown อีก 8 ไฟล์ที่ต่างกัน ซึ่งครอบคลุมสถาปัตยกรรมโปรเจกต์ สเปกของโมเดล ลำดับการบิลด์ เลเยอร์ของการทดสอบ สถานการณ์ใช้งาน ฯลฯ โปรเจกต์นี้ใช้สำหรับ model-based governance ของ Databricks Unity Catalog ผมมีประสบการณ์ด้านนี้มาก แต่รู้สึกว่าเครื่องมือเดิมยังยืดหยุ่นไม่พอ สุดท้ายก็ให้ซับเอเจนต์ 3 ตัวช่วยทำงานกับเอกสารวางแผนจริง ได้แก่ ผู้เชี่ยวชาญ Databricks ผู้เชี่ยวชาญ Pydantic และผู้เชี่ยวชาญด้านพรอมป์ต์ ผลคือคุณภาพของไฟล์ Markdown ดีขึ้นมากในหลายจุด ตั้งแต่ปัญหาเวอร์ชัน Pydantic รุ่นเก่า ไปจนถึงความเข้าใจผิดของผมเกี่ยวกับ Unity Catalog เมื่อวานลองรันจริงแล้ว นอกจากที่ผมต้องกดอนุมัติการใช้เครื่องมืออยู่ไม่กี่ครั้ง ภายใน 2 ชั่วโมงก็ได้เครื่องมือส่วนใหญ่และชุดทดสอบเกือบครบ วิธีนี้ต่างจากเมื่อก่อนมากจนรู้สึกทึ่ง และผมรู้สึกว่ามีอนาคตจริง ๆ กับการเขียนเอกสารเชิงเทคนิคอย่างรอบคอบแล้วทำให้ทุกคนมองไปในทิศทางเดียวกัน ผมยังคิดว่าผลิตภาพดีกว่าการลงไปไล่เขียนโค้ดเองด้วย เพียงแต่ตอนทำโค้ดผมโฟกัสได้ลึกกว่า แต่พอต้องจัดการเอกสาร Markdown หลายไฟล์ สมาธิกลับหลุดง่ายกว่า เป็นยุคที่น่าสนใจมากจริง ๆรู้สึกได้ว่ากำลังมีรูปแบบใหม่ที่ทำให้ต้องออกแบบระบบล่วงหน้าแบบเดียวกับ Test-Driven Development เมื่อก่อนเรามักค่อย ๆ วาดภาพระบบไปพร้อมกับการเขียนโค้ด แต่การพัฒนาแบบใช้ AI ครั้งนี้กลับบังคับให้ต้องออกแบบและแม็ปขอบเขตไว้ก่อน แล้วโค้ดจริงก็กลายเป็นงาน boilerplate ที่แค่ทำตามแบบออกแบบ AI เก่งกับงาน boilerplate แบบนี้มาก
ผมก็เจอเหมือนกันว่า productive ขึ้น แต่สมาธิกระจัดกระจายมากขึ้น มันแปลกแต่ตอนนี้ก็ได้ผล ระยะยาวคงต้องหาวิธีแก้ ตอนนี้วิธีที่เข้ากับผมที่สุดคือให้หลายเอเจนต์ทำงานคนละ task อยู่ตามหลาย repository ของโปรเจกต์ แล้วผมก็คอยอนุมัติงานไปเรื่อย ๆ ให้ความรู้สึกเหมือนเป็น project manager ที่นำทีมขนาดใหญ่ เป็นยุคที่น่าสนใจจริง ๆ
เป็นวิธีที่สดใหม่มาก อยากรู้ว่า framework ที่ใช้รันเอเจนต์ในการทดลองจริงคืออะไร
ช่วงนี้ผมก็อัดเสียงรายละเอียดของโปรดักต์ เส้นทางผู้ใช้ ฯลฯ แล้วใช้สิ่งนั้นเริ่มกระบวนการทำ technical documentation มี
CLAUDE.mdแบบขั้นต่ำ ใช้ Github workflow สำหรับการพัฒนาซอฟต์แวร์ แต่การทำ CI workflow ที่ดีนั้นยาก playbook ของผมคือ https://nocodo.com/playbook/ผมไม่ค่อยอินกับคำกล่าวที่ว่า “ถ้าวางแผนก่อน ผลลัพธ์จะดีขึ้น” สำหรับผม ไม่ว่าจะเป็นฟีเจอร์ใหญ่หรือโปรเจกต์ใหญ่ ผมก็คิดโครงสร้าง เหตุผล และวิธีทำไว้ก่อนเสมออยู่แล้ว ไม่ว่าจะในหัว บนกระดาษ ใน Confluence หรือบนไวท์บอร์ด 80% ของ software engineering คือกระบวนการคิดและตัดสินใจว่าจะทำอะไร ทำไม และทำอย่างไร อีก 20% สุดท้ายเท่านั้นที่เป็นการเขียนโค้ดจริง มันก็เป็นแบบนี้มาตลอด และผมยังไม่แน่ใจว่า AI จำเป็นจริงไหมสำหรับการวางแผนหรือการกำหนดเป้าหมายที่ดี
ในทีมใหญ่หรือสภาพแวดล้อมที่มีวัฒนธรรมองค์กรชัดเจน อาจจะเป็นแบบนั้น แต่การพัฒนาจำนวนมากก็ยังเน้นโปรเจกต์เดี่ยว ทีมเล็ก side project, POC เร็ว ๆ หรือเครื่องมืออัตโนมัติใช้ครั้งเดียว งานประเภทนี้มักไม่ได้เริ่มจากเอกสาร/สเปก/การทดสอบตั้งแต่ต้น แต่เดินหน้าโดยผสมการเขียนโค้ดเข้ากับการคิดและการลงมือทำไปพร้อมกัน TDD เหมาะกับบางที่ แต่หลายกรณีก็ไม่จำเป็นนัก แต่หลังจากมี AI coding agent เข้ามา ขั้นตอนการนิยามไอเดียให้ชัดแล้วจัดเป็นสเปกกลับสำคัญขึ้นมาก การถ่ายทอดทุกอย่างที่อยู่ในหัวออกมาเป็นคำพูดกลายเป็นเรื่องจำเป็นมากขึ้น ทุกวันนี้ภาษาโปรแกรมที่ฮอตที่สุดคือภาษาอังกฤษ
ผมเป็นสายที่ผสมการพัฒนาเข้ากับการออกแบบ เริ่มเขียนโค้ดก่อนแล้วค่อย ๆ ขัดเกลาและพัฒนาต่อ สำหรับกรณีส่วนใหญ่ วิธีแก้แบบคร่าว ๆ มันค่อนข้างชัดอยู่แล้ว เลยรู้สึกว่าไม่จำเป็นต้องเสียเวลาวางแผนลึกมาก
เมื่อก่อน prompt engineering เคยเป็นเรื่องล้อเล่น แต่ตอนนี้สัมผัสได้จริงแล้ว บางครั้งผมใช้เวลา 10~20 นาทีไปกับพรอมป์ต์ที่เขียนอย่างละเอียดและการวางแผนตั้งต้น เพื่อใช้ cloud code อย่างเป็นระบบ ผมก็เหมือน OP คือเก็บแผนไว้เป็นไฟล์แล้วเอาไปรันใน context ใหม่ สิ่งที่อยากได้มากคือ CLI ดี ๆ (ตอนนี้ใช้ charm กับ cc อยู่) ถ้าแยกโมเดลสำหรับ implementation, planning และ sub-agent แต่ละตัวได้จะดีมาก โครงสร้างที่ให้โมเดลโลคัลทำ implementation แล้วใช้โมเดลคลาวด์ทำ planning หรือสลับกันตามต้องการเพื่อประหยัดเงิน Charm เป็นตัวที่ผมใช้แล้วรู้สึกว่าทำเรื่องสลับไปมาระหว่าง context โดยไม่สูญเสียบริบทได้ดีที่สุดเท่าที่เคยลองมา ความสามารถเรื่อง parallel sub-agent ก็เป็นหนึ่งในฟีเจอร์ที่ดีที่สุดของ claudecode เช่นกัน (ผมลอง CCR แล้ว แต่ไปได้ไม่เกินโมเดลพื้นฐานเลยค่อนข้างผิดหวัง)
ที่ prompt engineering กลายเป็นประเด็นตอนนี้ ส่วนหนึ่งเพราะกระแส hot take บน Twitter หรือการผลิตคอนเทนต์ แต่จริง ๆ แล้ว prompt engineering สำคัญมาตั้งนานแล้ว GIGO ("Garbage In, Garbage Out") เป็นความจริงของทุกโปรเจกต์ machine learning เพราะงั้นผมถึงคอยแนะนำเพื่อนร่วมงานหรือเพื่อน ๆ ว่า “ต้องลองใช้เอง” สิ่งที่ทำไม่ได้เมื่อ 6 เดือนก่อน ตอนนี้อาจทำได้แล้ว ต้องจับมันใช้งานจริงถึงจะรู้ว่าอะไรเปลี่ยนไป อะไรทำได้บ้าง ผมคิดว่ากรณีสำเร็จจริง บล็อก gist หรือตัวอย่างต่าง ๆ มีค่ามากกว่าความเห็นเชิงลบมาก ไม่ใช่แค่เอาไว้คำนวณง่าย ๆ หรือจับคำสะกดผิด แต่มันต้องช่วยปรับปรุงและสนับสนุน workflow ของผมได้ Prompt engineering ก็เหมือนกับการฝึกให้เก่ง Google เมื่อ 10~15 ปีก่อน คือคอยเรียนรู้การเปลี่ยนแปลงใหม่ ๆ และรูปแบบที่ได้ผลอยู่เสมอ
ถ้าจะทำงานร่วมกับ AI ให้ดี prompt engineering คือหัวใจจริง ๆ
โปรเจกต์ที่ผมใช้ AI เป็นโปรเจกต์ที่มีเอกสารและการทดสอบดีที่สุดเท่าที่เคยทำมา เพราะการดึงประสิทธิภาพจาก LLM ต้องมี context เอกสารเลยดีขึ้น และเพราะต้นทุนการสร้างเทสต์ลดลง เทสต์ก็มีมากขึ้นด้วย ตรงกันข้ามกับคำทำนายที่ว่าคุณภาพโค้ดจะตก ผมกลับคิดว่ามันจะดีขึ้น
พูดตามตรง คำว่า "prompt engineering" ก็คือการออกแบบสถาปัตยกรรมผ่านสื่อชนิดใหม่ สมัยก่อนทักษะอย่าง "การออกแบบไดอะแกรม" เคยได้รับความสำคัญ ทุกวันนี้มันก็เป็นการทำ architecture ในรูปแบบใหม่เท่านั้นเอง
ผมเพิ่งลองใช้ Claude Code ไปไม่นาน และกำลังจะลอง workflow ที่มีคนแนะนำ ดูเป็นวิธีที่ค่อนข้างดี แต่ค่าใช้จ่ายของ CC แพงกว่าที่คิด รีแฟกเตอร์ง่าย ๆ ใช้งาน 5 นาที บวกรีวิว 15 นาที ก็เสียไป 4 ดอลลาร์แล้ว ถ้าผมทำเองคงเสร็จใน 15~20 นาที อยากรู้ว่าปกติคนอื่นใช้ CC ต่อหนึ่งฟีเจอร์เสียกันประมาณเท่าไร ไม่มีใครพูดเรื่องราคาเลย
ถ้าสมัครสมาชิกจะเป็น flat charge $20~$200 พร้อมลิมิตการใช้โทเคนรายวัน/รายสัปดาห์ https://support.anthropic.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
ทิศทางที่นักลงทุน AI อยากเห็นคือโครงสร้างที่ AI เข้ามาแทนแรงงานด้วยมาร์จิน 15% จะมีวันที่งบ AI ต่อหัวเท่ากับนักพัฒนา 1 คน เช่น นักพัฒนาระดับ senior เงินเดือน 100,000 ดอลลาร์ ถูกแทนที่ด้วยงบ AI 100,000 ดอลลาร์ งบ AI จะถูกดึงออกมาจากค่าใช้จ่ายด้านการพัฒนา เงินเดือน senior อาจลดลง และขนาดทีมพัฒนาอาจหดตัวอย่างรวดเร็ว ตอนนี้ยังอยู่ในช่วง 'ยึดพื้นที่' ที่ VC ออกเงินอุดหนุนเต็มที่ แต่ถ้าดูบรรยากาศ VC บน Twitter ก็เหมือนช่วงนี้ใกล้จะจบแล้ว การระดมเพิ่มอีกหลายรอบแบบเผาเงิน 500 ล้านดอลลาร์ใน 9 เดือนก็คงไปต่อได้จำกัด
ตั้งแต่ย้ายบางส่วนจาก Cursor มาใช้ Claude Code ค่าใช้จ่ายเพิ่มขึ้นมาก ที่บริษัทใช้เป็นหลักเลยคุยกับหัวหน้าไม่ยาก แต่กับ side project ก็ยังลังเล ไม่อยากจ่าย 20 ดอลลาร์ทุกครั้งแค่เพื่อ bootstrap แอปเล่น ๆ
สมัครได้โดยเลือกสองโมเดลคือ Sonnet (20 ยูโร/เดือน) และ Opus (100 ยูโร/เดือน) ผมเริ่มจาก Sonnet แล้วค่อยย้ายไป Opus Sonnet ก็ใช้งานได้ดีพอสมควร ภายในโควตาโทเคน ตอนนี้ยังเพียงพอกับงานของผม แต่อนาคตก็ยังไม่แน่ใจ
คุณบอกว่า "ถ้าผมทำเองก็ 15~20 นาที" แต่ลองคิดดูว่า 15~20 นาทีนั้นเอาไปทำอย่างอื่นได้ไหม
วิธีใช้ Visual Studio Code/ChatGPT5 preview ของผมก็คล้ายกับ workflow นี้ {น่าจะยังจ่ายผ่าน Github Copilot subscription อยู่ แต่ช่วงนี้ไม่ค่อยแน่ใจแล้ว} ผมรู้สึกว่า LLM แบบ non-agent ทำให้โค้ดพังเร็วมาก พอใช้ agent mode วิธีสร้างโค้ดเปลี่ยนไปชัดเจน ผมไม่ใช่นักพัฒนา Python แต่ก็ประทับใจกับการที่ LLM สร้างโค้ดก้อนใหม่ให้ได้จริง ๆ หลังจากทำเสร็จ ผมตั้งใจจะเอาไปให้ LLM ตัวเล็กบน BitGrid ช่วยอ่าน แล้วค่อยทำความเข้าใจโค้ดทั้งหมดทีหลัง วิธีของผมคือทำขั้นสำรวจเล็ก ๆ ซ้ำไปเรื่อย ๆ แล้วแก้เฉพาะบางส่วนเพื่อคุมดีไซน์รวมให้ยังเป็นแบบที่ผมต้องการ มันทำให้ผมมั่นใจในอนาคตที่ LLM จะเป็น programming partner อยากรู้ว่ามีใครใช้งาน Visual Studio Code/ChatGPT5 แบบนี้อีกไหม
น่าสนใจดีที่การพยายาม optimize เครื่องมือ AI กลับทำให้นักพัฒนาค้นพบคุณค่าของ 'การสื่อสารที่ดี' และ 'การตั้งความคาดหวัง' อีกครั้ง ภาพจำของนักพัฒนา 10x แบบคนแปลกแยกหรืออัจฉริยะเพี้ยน ๆ คงถึงเวลาต้องทบทวนแล้ว
ผมมีประสบการณ์คล้ายกันใน Replit พอแอปเริ่มใหญ่ขึ้น ถ้าเอกสารการออกแบบไม่ได้เป็นทั้ง task และ source of truth ระบบจะพังเร็วมาก OpenAI มีปัญหาที่แชตช้าและค้างง่าย เลยพบว่าการทำเอกสารแยกแล้ว import เข้าแชตใหม่ช่วยได้มาก ในระดับมนุษย์เอง ผมก็รู้สึกว่าเราควรทำแบบนั้นเหมือนกัน การทบทวนตัวเอง จัดทำเอกสาร และบันทึก ‘memory’ ลงในเอกสารออกแบบ จะช่วยให้ทั้งเราและ LLM ทำงานได้อิสระขึ้น
ผมเองก็เพิ่งค้นพบ workflow นี้เมื่อไม่นานและประหลาดใจมาก เรื่องสำคัญคือให้ข้อกำหนดกับ claude แบบน้อยที่สุด แล้วปล่อยให้ plan mode ทำงานได้เต็มที่ ถ้าเป็นรายงานตัวชี้วัดการขาย แค่บอกว่า "Ultrathink relevant sales metrics" ก็พอ มันจะเสนอเมตริกต่าง ๆ มาให้ แล้วช่วยจัดอันดับเพื่อคัดเลือกได้ ผมสร้าง directory แยกสำหรับแต่ละฟีเจอร์ใหม่ แล้วให้มันเขียนแผนของฟีเจอร์นั้นลงไฟล์ จากนั้นก็สั่งเป็นขั้น ๆ ตั้งแต่แผนการ implement, data query ที่ต้องใช้, implementation จริง, test, เอกสารสำหรับผู้ใช้ แล้วค่อยส่งต่อไป QA เมื่อก่อนการสร้างฟีเจอร์พยากรณ์ยอดขายหนึ่งอย่างต้องใช้ทั้งทีมใหญ่และเวลามาก แต่ claude ทำเป็น Docker container ให้ได้ในครึ่งวัน การเปลี่ยนแปลงนี้กำลังเปลี่ยนมุมมองของผมต่อซอฟต์แวร์ เมื่อก่อนบริษัทต่าง ๆ ไม่เคยยอมปล่อยซอร์สโค้ดออกนอกองค์กรเพราะ NDA, IP ฯลฯ แต่ตอนนี้แม้แต่ระบบ ERP ซับซ้อนที่ใช้เวลาพัฒนา 20 ปี claude ก็ยังรีอิมพลีเมนต์ใหม่ได้เร็ว พร้อมเอกสารและเทสต์ด้วย ในโลกจริงมันยังไม่สมบูรณ์แบบนัก แต่ความเร็วในการคืบหน้าเร็วมากจริง ๆ
ถ้าอยากดึงฟีเจอร์ดี ๆ จาก Claude Code การเขียนแผนให้ดีก่อนคือหัวใจสำคัญ ช่วงนี้ผมใช้ GPT-5 High ใน Cursor ทำแผนก่อน แล้วค่อยเอาเข้า Claude Code เพื่อ implement ถ้าให้มันเขียนเอกสารล่วงหน้าว่าจะต้องแก้ตรงไหนใน codebase จะได้ผลดีขึ้นอีกประมาณ 15~20% ถ้าโมเดลวางแผนช่วยเขียนเอกสารเรื่องวิธีการทำงาน สถาปัตยกรรม และแพตเทิร์น รวมถึงแทรกการออกแบบฟีเจอร์เข้าไปด้วย ผลลัพธ์จะยิ่งดีขึ้น สุดท้าย การรีวิวและแก้เอกสารกับแผนด้วยตัวเองก็ช่วยได้มากเช่นกัน
อยากรู้ว่ามีใครค้นพบวิธีที่ดีในการผสานงานออกแบบฟรอนต์เอนด์เข้ากับกระบวนการแบบนี้อย่างแนบเนียนหรือยัง ส่วนใหญ่ที่เห็นจะจบแค่การพูดถึงเฟรมเวิร์กฟรอนต์เอนด์ หรือไม่ก็ระดับรูปภาพจาก figma ซึ่งยังไม่ให้ความรู้สึกว่าเป็นโซลูชันด้านดีไซน์แบบบูรณาการจริง ๆ