สอนให้ AI คิดเหมือนวิศวกรอาวุโส

• วิธีการให้เครื่องมือเขียนโค้ดด้วย AI วางแผนก่อนลงมือเขียนโค้ด เพื่อป้องกันการ implement ผิดพลาดและเพิ่มความเร็วในการพัฒนา
• ใช้ 8 กลยุทธ์การวางแผน ตามระดับความยาก โดยแต่ละกลยุทธ์มีโครงสร้างให้เอเจนต์เฉพาะทางทำการวิจัยแบบขนาน ก่อนที่นักพัฒนาจะใช้วิจารณญาณและตัดสินใจ
• แต่ละกลยุทธ์ครอบคลุมการจำลองบั๊ก การค้นหา best practices การวิเคราะห์ codebase เดิม การสืบค้นประวัติ git ฯลฯ และ ความชอบกับแพตเทิร์นที่เอเจนต์เรียนรู้จะถูกสะสมโดยอัตโนมัติ
• สามารถติดตั้งระบบที่เปิดเป็นโอเพนซอร์สนี้บน Claude Code หรือเริ่มจากฟีเจอร์เดียวก่อน แล้วค่อย ๆ สอนวิธีคิดของนักพัฒนาให้ AI เรียนรู้

---

แนวทางการพัฒนาแบบให้ AI วางแผนเป็นศูนย์กลาง

• แนะนำแนวทางที่ให้ AI จัดทำแผนก่อนเขียนโค้ด
  • วิธีนี้ให้ผลทั้ง เร่งความเร็วในการทำฟีเจอร์และลดข้อผิดพลาด ได้ดีกว่าการให้เขียนโค้ดอย่างเดียว
• ยกตัวอย่างกระบวนการพัฒนาฟีเจอร์ “email bankruptcy” ของแอปจัดการอีเมล Cora
  • ตอนทำฟีเจอร์สำหรับจัดระเบียบอีเมล 53,000 ฉบับโดยไม่ทำอีเมลสำคัญสูญหาย AI research agent ได้วิเคราะห์ล่วงหน้า
  • พบปัญหา ข้อจำกัด 2,000 รายการของ Gmail, system timeout, และเวลารอของผู้ใช้ ตั้งแต่ต้น จึงหลีกเลี่ยงการ implement ผิดทางได้

8 กลยุทธ์การวางแผน

กลยุทธ์ 1: จำลองบั๊กและจัดทำเอกสาร

• เป้าหมาย: จำลองบั๊กก่อนแก้ และสร้างคู่มือแบบเป็นขั้นตอน
• ช่วงที่ใช้: Fidelity 1~2 โดยเฉพาะตอนแก้บั๊ก
• หลังปล่อยฟีเจอร์ email bankruptcy ไม่นาน พบปัญหาที่ผู้ใช้ 19 คนติดอยู่ในสถานะที่งานล้มเหลว
  • จากการไล่ดู log ของ AppSignal เพื่อวินิจฉัย พบว่า production กำลังเพิกเฉยต่อ error เรื่อง rate limit ของ Gmail
  • เมื่อ batch ใด batch หนึ่งล้มเหลว งานทั้งหมดจะหยุด แต่ไม่มีการแจ้งผู้ใช้ ทำให้ผู้ใช้เห็นแค่ spinner โหลดไม่สิ้นสุด
• ระหว่างการจำลองปัญหา พบว่าจำเป็นต้องมี การประมวลผลแบบ batch และความสามารถในการ resume งาน ยืนยันว่าการ retry อย่างเดียวไม่พอ
• ผลทบต้น: เพิ่มรายการตรวจในเช็กลิสต์ของเอเจนต์ @kieran-rails-reviewer ว่า “เมื่อมี background job ที่เรียก external API มีการจัดการ rate limit หรือไม่, มี retry หรือไม่, และมี partial state ค้างหรือไม่”

กลยุทธ์ 2: สำรวจ best practices

• เป้าหมาย: ค้นหากรณีแก้ปัญหาคล้ายกันจากบนเว็บ
• ช่วงที่ใช้: ทุกระดับความยาก โดยเฉพาะแพตเทิร์นที่ไม่คุ้นเคย
• ตอนอัปเกรด gem ที่ตามหลังอยู่ 2 เวอร์ชัน เอเจนต์ค้นหา “เส้นทางการอัปเกรดจากเวอร์ชัน X ไป Y”, “breaking changes ระหว่างเวอร์ชัน”, “ปัญหา migration ที่พบบ่อย”
  • พบทั้งคู่มืออัปเกรดทางการ และบล็อกโพสต์ 3 ชิ้นจากวิศวกรที่เคยอัปเกรดแบบเดียวกัน
  • การค้นคว้า 3 นาทีช่วยเลี่ยงการ debug แบบลองผิดลองถูกที่อาจกินเวลาหลายชั่วโมง
• ใช้ได้แม้กับ การตัดสินใจที่ไม่ใช่เชิงเทคนิค: เช่น “best practices ของ pricing tier สำหรับ SaaS”, “copy สำหรับเพิ่ม conversion ใน email drip campaign”, “กลยุทธ์ retry ของ background job”
• ผลทบต้น: เมื่อพบแพตเทิร์นที่มีประโยชน์ จะบันทึกลงไฟล์ `docs/*.md` โดยอัตโนมัติ เพื่อให้ครั้งถัดไปตรวจดูก่อนค้นเว็บ

กลยุทธ์ 3: สำรวจ codebase

• เป้าหมาย: ค้นหาแพตเทิร์นคล้ายกันจากโค้ดที่มีอยู่
• ช่วงที่ใช้: ทุกงานที่อาจซ้ำกับฟีเจอร์เดิม
• ก่อนเพิ่ม event tracking ให้ฟีเจอร์ใหม่ เอเจนต์ค้นหาใน codebase ว่า “ตอนนี้จัดการ event tracking กันอย่างไร?”, “แพตเทิร์นของการเรียก analytics เป็นแบบไหน?”, “ส่ง event กันที่ตรงไหน?”
  • พบ ระบบ tracking เดิมที่มีทั้ง helper method พร้อมใช้ (ซึ่งผู้เขียนเองก็ลืมไปแล้ว)
  • ถ้า AI ไม่อ้างอิง codebase ก็มีแนวโน้มจะพยายามสร้างใหม่ตั้งแต่ต้น
• แทนที่จะสร้างระบบ tracking ใหม่ จึงขยายจากแพตเทิร์นเดิม ช่วย เลี่ยงการสร้างระบบที่สองซึ่งไม่เข้ากัน
• ผลทบต้น: สร้างเอเจนต์ “@event-tracking-expert” เพื่อให้รันอัตโนมัติทุกครั้งที่วางแผนฟีเจอร์ที่ต้องมี tracking

กลยุทธ์ 4: สำรวจซอร์สโค้ดของไลบรารี

• เป้าหมาย: อ่านซอร์สโค้ดของ package และ gem ที่ติดตั้งอยู่โดยตรง
• ช่วงที่ใช้: เมื่อต้องใช้ไลบรารีที่เปลี่ยนเร็วหรือมีเอกสารไม่เพียงพอ
• gem อย่าง RubyLLM มีการเพิ่มโมเดล พารามิเตอร์ และฟีเจอร์ใหม่อย่างต่อเนื่อง แต่ เอกสารตามไม่ทัน
  • เอเจนต์วิเคราะห์ซอร์สโค้ด RubyLLM: “มีตัวเลือกโมเดลอะไรใช้ได้บ้าง?”, “ส่งพารามิเตอร์อะไรได้บ้าง?”, “ฟีเจอร์ล่าสุดที่ยังไม่ถูกบันทึกในเอกสารมีอะไรบ้าง?”
  • ได้คำตอบว่า “เวอร์ชัน 1.9 เพิ่มการรองรับ streaming แต่ยังไม่ถูกบันทึกในเอกสาร” พร้อมชื่อพารามิเตอร์และตัวอย่างการใช้งานจาก test suite
• ผลทบต้น: ทุกครั้งที่อัปเดต dependency ความรู้ก็อัปเดตตามอัตโนมัติ ไม่ต้องทำงานด้วยข้อมูลเก่า

กลยุทธ์ 5: ศึกษา git history

• เป้าหมาย: วิเคราะห์ commit history เพื่อเข้าใจเจตนาของการตัดสินใจในอดีต
• ช่วงที่ใช้: ตอน refactor, รับช่วงงานต่อ, หรือเมื่อจำเป็นต้องเข้าใจว่า “ทำไม”
• เมื่อพบว่ายังใช้ EmailClassifier เวอร์ชันเก่าอยู่ จึงค้น git history ก่อนอัปเกรดว่า “ทำไมยังใช้ v1 อยู่?”, “เคยพยายามอัปเกรดเป็น v2 หรือยัง?”
  • พบ PR ของเพื่อนร่วมทีมเมื่อ 3 เดือนก่อน ที่อัปเกรดเป็น v2 แล้วเกิดปัญหาให้อีเมล inbox ไปอยู่ archive และอีเมล archive กลับไปอยู่ inbox
  • ในบทสนทนาของ PR มีบันทึกไว้อย่างละเอียดว่าจงใจ rollback เพราะเหตุใด
• ผลทบต้น: institutional memory ถูกเก็บและค้นหาได้ ทำให้สมาชิกใหม่ของทีมรับช่วงตรรกะของการตัดสินใจเดิมได้

กลยุทธ์ 6: ทำ prototype เพื่อทำให้ requirements ชัดเจน

• เป้าหมาย: ทำ prototype อย่างรวดเร็วในสภาพแวดล้อมแยกต่างหาก เพื่อทำให้ requirements ชัดเจน
• ช่วงที่ใช้: Fidelity 3, เมื่อ UX ยังไม่แน่นอน, หรืองานเชิงสำรวจ
• ตอนออกแบบอินเทอร์เฟซ Email Brief ใหม่ ได้สร้าง prototype layout ที่ต่างกัน 5 แบบ ใน Claude โดยใช้เวลาราว 5 นาทีต่อแบบ
  • สามารถกดใช้งานเองเพื่อหาจุดที่ไม่สะดวก และนำเวอร์ชันที่ดีที่สุดไปให้ผู้ใช้บางส่วนลอง
  • ฟีดแบ็กจากผู้ใช้รายหนึ่ง: “layout ดูเยอะจนล้น และไม่รู้ว่าจะ archive อีเมลอย่างไร”
• insight นี้จึงถูกสะท้อนเข้าไปใน requirements ของแผนจริง: “ต้องวางปุ่ม archive ไว้มุมซ้ายบน—เพราะ muscle memory ของผู้ใช้คาดหวังตำแหน่งนั้นจาก Gmail”
• ผลทบต้น: การทำ prototype เปลี่ยนความไม่แน่นอนให้เป็นสเปกที่เป็นรูปธรรม และบันทึกปฏิกิริยาของผู้ใช้ไว้

กลยุทธ์ 7: สังเคราะห์พร้อมตัวเลือก

• เป้าหมาย: รวมงานวิจัยทั้งหมดเป็นแผนเดียวที่มี trade-off ครบถ้วน
• ช่วงที่ใช้: หลังจบขั้นวิจัย ก่อนเริ่ม implement
• หลังรันกลยุทธ์ 1~6 แล้ว เอเจนต์จะสรุปว่า “จากงานวิจัยนี้ เสนอ 3 วิธีในการแก้ปัญหา พร้อมความซับซ้อนในการ implement, ผลต่อประสิทธิภาพ, ภาระการดูแลรักษา, และแพตเทิร์นเดิมที่สอดคล้องกันของแต่ละวิธี”
• ตัวอย่างการซิงก์ Gmail inbox:
  • ตัวเลือก A—ใช้ระบบซิงก์เดิม: implement ได้เร็ว แต่เกิดโค้ดซ้ำและแยก concerns ได้ไม่ดี
  • ตัวเลือก B—ซิงก์แบบ real-time: สถาปัตยกรรมสะอาด แต่ช้าและอาจมีปัญหาเรื่องความน่าเชื่อถือ
  • ตัวเลือก C—สร้างระบบ mirror caching: เป็นคำตอบระยะยาวที่ดีที่สุด แยกส่วนได้สะอาดที่สุด แต่มีงานเริ่มต้นมากที่สุด
• เมื่อเทียบกันครบแล้ว ก็สามารถเลือกอย่างมีข้อมูลได้ภายใน 30 วินาที
• ผลทบต้น: การเลือกสะท้อนความชอบ เช่น หากระบุว่า “ให้ความสำคัญกับ compatibility ก่อน” ระบบก็จะให้น้ำหนักกับ compatibility มากขึ้นในการตัดสินใจลักษณะคล้ายกันครั้งต่อไป

กลยุทธ์ 8: รีวิวโดย style agent

• เป้าหมาย: ส่งแผนที่เสร็จแล้วให้ reviewer เฉพาะทางที่ใช้ตรวจความชอบของนักพัฒนา
• ช่วงที่ใช้: ขั้นสุดท้ายของแผน ก่อน implement
• มีรีวิวเอเจนต์ 3 ตัวที่รันอัตโนมัติ:
  • เอเจนต์เพื่อการทำให้ง่ายลง: ปักธง overengineering เช่น “ฟีเจอร์นี้จำเป็นต้องมี 3 ตารางฐานข้อมูลจริงหรือ? ใช้ 1 ตารางที่มี type field แทนได้ไหม?”
  • เอเจนต์ด้านความปลอดภัย: ตรวจช่องโหว่ทั่วไป เช่น “แผนนี้เปิดให้ user input เข้า database query โดยตรง—ต้องเพิ่ม input sanitization”
  • Kieran style agent: บังคับใช้ความชอบส่วนบุคคล เช่น “กำลังใช้ join ที่ซับซ้อน แต่ Kieran ชอบ query ที่เรียบง่ายกว่า ลองพิจารณา denormalization”
• ผลทบต้น: เอเจนต์จะสะสมรสนิยมของนักพัฒนาไปเรื่อย ๆ เมื่อเวลาผ่านไป เช่น หากระบุว่า “ไม่ชอบแบบนี้” หรือ “จับประเด็นได้ดี” ระบบก็จะเรียนรู้

เริ่มต้นใช้งาน

วิธีที่ลองได้ตั้งแต่วันนี้

• มีการเปิดซอร์สระบบวางแผนไว้ที่ Every’s Github Marketplace
• เมื่อติดตั้งใน Claude Code จะสามารถใช้ slash command /plan และ research agent ได้ทันที
• ใช้ปลั๊กอินได้ทั้งใน Claude Code หรือ Droid

วิธีเริ่มแบบง่าย

• เลือกฟีเจอร์ Fidelity 2 ที่กำลังสร้างอยู่สักหนึ่งอย่างในสัปดาห์นี้: งานที่กินหลายไฟล์และมีขอบเขตชัด เช่น เพิ่ม view ใหม่, ทำระบบ feedback, หรือ refactor คอมโพเนนต์
• ก่อนสั่ง Claude Code หรือ Cursor ให้ build ให้ ทำ การค้นคว้า 15~20 นาที:
  1. best practices: คนอื่นแก้ปัญหานี้อย่างไร? ค้นบล็อกโพสต์, Stack Overflow, เอกสารบนเว็บ
  2. แพตเทิร์นของตัวเอง: ปกติคุณแก้อย่างไร? ค้นหาฟีเจอร์คล้ายกันจาก codebase เดิม
  3. ความสามารถของไลบรารี: เครื่องมือที่ใช้อยู่รองรับอะไรจริงบ้าง? ใช้ AI อ่านเอกสารหรือซอร์สโค้ด
• ให้ AI สังเคราะห์งานวิจัยออกมาเป็นแผนที่มีหัวข้อต่อไปนี้:
  1. ปัญหาที่ต้องแก้ (ประโยคเดียวที่ชัดเจน)
  2. แนวทางแก้ 2~3 แบบ (พร้อมข้อดีข้อเสียอย่างตรงไปตรงมาของแต่ละแบบ)
  3. แพตเทิร์นในโค้ดเดิมที่ต้องสอดคล้องกัน
  4. edge cases หรือประเด็นด้านความปลอดภัย
• ทบทวนแผนและสังเกตปฏิกิริยาของตัวเอง: หากคิดว่า “ซับซ้อนเกินไป” หรือ “มีวิธีที่ดีกว่านี้อยู่แล้ว” อย่าแก้เฉพาะตัวแผน แต่ให้ จับเหตุผลว่าคิดแบบนั้นเพราะอะไร แล้วบันทึกไว้
• ปล่อยฟีเจอร์ตามแผน, เปรียบเทียบ implementation สุดท้ายกับแผนเดิม อะไรที่ต่างออกไป? เพราะอะไร? อะไรจะทำให้แผนดีขึ้นได้?
• ใช้เวลา 10 นาทีทำให้สิ่งที่เรียนรู้กลายเป็นกฎชัดเจนหนึ่งข้อ: เพิ่มลงในไฟล์ CLAUDE.md เช่น “เมื่อทำงานประเภท X ให้จำไว้ว่าต้องตรวจ Y” หรือ “เพราะเหตุผล C จึงชอบแนวทาง A มากกว่า B”
• เมื่อมีการสะสมการเรียนรู้แล้ว ให้ สร้าง research agent หรือคำสั่งเฉพาะทาง เช่น “Event Tracking Expert” (รู้แพตเทิร์นของคุณ), “Security Checker” (ปักธงความผิดพลาดทั่วไป)
• ทำซ้ำอีกครั้งในสัปดาห์หน้า อ้างอิงโน้ตเดิม ตรวจดูว่าแผนครั้งที่สองดีกว่าครั้งแรกหรือไม่ และ ภายในไม่กี่เดือนก็จะได้ระบบที่เข้าใจวิธีคิดของนักพัฒนา