ชุมชนนักพัฒนากำลังทดลองใช้เฟรมเวิร์กที่มีโครงสร้างเพื่อทำให้ Claude AI มีประสิทธิภาพมากขึ้นในงานเขียนโค้ด อย่างไรก็ตาม ผู้ใช้งานรุ่นแรกพบว่าระบบเหล่านี้อาจไม่ได้ให้ผลลัพธ์ที่ดีขึ้นตามที่สัญญาไว้ ทำให้เกิดการถกเถียงเกี่ยวกับว่าโมเดล AI ปัจจุบันพร้อมสำหรับแนวทางที่มีโครงสร้างเช่นนี้หรือไม่
Context Poisoning กลายเป็นปัญหาหลัก
นักพัฒนาหลายคนตั้งคำถามว่าการเพิ่มโครงสร้างเฟรมเวิร์กที่ซับซ้อนช่วยหรือเป็นอุปสรรคต่อประสิทธิภาพของ Claude ปัญหาหลักดูเหมือนจะเป็น context poisoning - เมื่อข้อมูลที่เกี่ยวข้องกับเฟรมเวิร์กมากเกินไปแย่งพื้นที่จากรายละเอียดงานจริงที่ Claude ต้องการเพื่อให้เข้าใจงาน
นักพัฒนาบางคนรายงานว่าการกำหนด MCP (Model Context Protocol) endpoint เพียงอย่างเดียวสามารถใช้พื้นที่ context ประมาณ 20,000 tokens ทำให้เหลือพื้นที่น้อยลงสำหรับโค้ดและข้อกำหนดเฉพาะที่ Claude ต้องการเพื่อเข้าใจงานจริง
MCP (Model Context Protocol): ระบบที่เชื่อมต่อ Claude กับเครื่องมือภายนอกเช่นฐานข้อมูล เบราว์เซอร์ และ test runners
ข้อกังวลเกี่ยวกับการใช้งาน Context:
- คำจำกัดความของ MCP endpoint: ประมาณ 20,000 tokens
- Framework overhead ลดพื้นที่สำหรับข้อมูลงานจริง
- ภาษาที่ไม่ค่อยได้รับความนิยม ( Ada , Elixir ) แสดงผลลัพธ์ที่ไม่ดี
- ความลำเอียงของ Python / JavaScript ในข้อมูลการฝึกส่งผลต่อภาษาอื่น ๆ
ผลลัพธ์ในโลกจริงแสดงความสำเร็จที่จำกัด
นักพัฒนาที่ทดสอบเฟรมเวิร์กเหล่านี้ในสภาพแวดล้อมการผลิตรายงานผลลัพธ์ที่หลากหลาย แม้ว่าบางคนจะเห็นการปรับปรุงในโปรเจกต์ greenfield (โค้ดเบสใหม่) แต่ผลลัพธ์กลับไม่น่าเชื่อถือเมื่อทำงานกับซอฟต์แวร์องค์กรที่มีอยู่หรือภาษาโปรแกรมที่ไม่ค่อยได้รับความนิยม
นักพัฒนาคนหนึ่งที่ทำงานกับโค้ดเบส Elixir ขนาดใหญ่สังเกตว่า Claude ทำงานได้ดีกว่ามากในฟีเจอร์ใหม่เมื่อเปรียบเทียบกับงาน refactoring ที่ซับซ้อน อย่างไรก็ตาม พวกเขาพบความสำเร็จโดยการสร้างเอกสารทางเทคนิคที่ละเอียดและใช้ code review agents เฉพาะทางเพื่อรักษามาตรฐานคุณภาพ
ปัญหา language bias มีความโดดเด่นเป็นพิเศษ นักพัฒนาที่ทำงานกับภาษาเช่น Ada, Elixir หรือเทคโนโลยีอื่นๆ ที่ไม่ค่อยพบเห็นรายงานว่า Claude มักจะสร้าง syntax ที่ถูกต้องแต่พลาดข้อกำหนดจริงโดยสิ้นเชิงหรือทำตามรูปแบบที่ไม่ถูกต้อง
รายงานประสบการณ์ของนักพัฒนา:
- ผลลัพธ์ที่ดีกว่าในโปรเจกต์ greenfield เมื่อเทียบกับโปรเจกต์ brownfield
- โค้ดเบสขององค์กร (500K+ SLOC) แสดงผลสำเร็จแบบผสมผสาน
- แผนราคาคงที่ (แผน Max $200 USD) ช่วยควบคุมต้นทุนการประมวลผล
- ยังคงต้องมีการติดตามอย่างใกล้ชิด - AI ทำงานเป็น "นักศึกษาฝึกงานที่ฉลาด" มากกว่านักพัฒนาที่ทำงานอัตโนมัติ
ความซับซ้อนของเฟรมเวิร์ก เทียบกับ แนวทางที่เรียบง่าย
ภูมิทัศน์ปัจจุบันประกอบด้วยเฟรมเวิร์ก open-source หลายสิบตัวที่มีชื่อเช่น BMAD-METHOD, Agent OS และ Symphony แต่ละตัวสัญญาว่าจะแก้ไขการประสานงานระหว่าง AI agents หลายตัว จัดการ context ได้ดีขึ้น หรือให้ structured workflows
อย่างไรก็ตาม นักพัฒนาที่มีประสบการณ์บางคนโต้แย้งเพื่อแนวทางที่เรียบง่ายกว่า แทนที่จะเป็นระบบ multi-agent ที่ซับซ้อน พวกเขาแนะนำให้มุ่งเน้นไปที่ context ที่แม่นยำและน้อยที่สุดที่จัดการกับงานโดยตรง
ผมจะโต้แย้งว่าเราต้องการ context poisoning น้อยลงด้วยข้อมูลที่ไร้ประโยชน์ ให้ข้อมูลที่แม่นยำที่สุดแก่โมเดลสำหรับงานจริงที่ต้องทำและพัฒนาต่อยอดจากนั้น
Greenfield projects: โปรเจกต์พัฒนาซอฟต์แวร์ที่เริ่มต้นจากศูนย์โดยไม่มีข้อจำกัดจากโค้ดที่มีอยู่
หมวดหมู่เฟรมเวิร์กหลัก:
- การจัดการงาน: แบ็คล็อก Markdown , ข้อกำหนดข้อความที่มีโครงสร้าง, ตั๋ว GitHub Issues / Jira
- การประสานงานเอเจนต์: การจำลองบทบาท (PM, สถาปนิก, นักพัฒนา, ผู้ทดสอบ), การทำงานแบบขนานของ swarm , สิ่งประดิษฐ์ดั้งเดิมของ repo
- การจัดการเซสชัน: การจัดระเบียบ Terminal , worktrees แบบขนาน, คอนเทนเนอร์ที่แยกออกจากกัน
- การรวมเครื่องมือ: เซิร์ฟเวอร์ MCP , สคริปต์เชลล์แบบกำหนดเอง, ตัวเข้าถึงฐานข้อมูล, hooks การทดสอบ
คำถามเรื่องความเป็นอิสระยังคงไม่ได้รับคำตอบ
ความท้าทายสำคัญคือการกำหนดระดับความเป็นอิสระที่เหมาะสมสำหรับผู้ช่วยเขียนโค้ด AI นักพัฒนาส่วนใหญ่ยังคงพบว่าตัวเองต้องติดตามงานของ Claude อย่างใกล้ชิดและแทรกแซงบ่อยครั้งเมื่อมันหลงทาง สิ่งนี้แสดงให้เห็นว่าโมเดลปัจจุบันทำงานได้ดีกว่าในฐานะนักศึกษาฝึกงานที่ฉลาดมากกว่าสมาชิกทีมที่เป็นอิสระ
เฟรมเวิร์กพยายามจัดการเรื่องนี้โดยเพิ่มโครงสร้าง บทบาท และขั้นตอนการตรวจสอบมากขึ้น แต่ความซับซ้อนเพิ่มเติมนี้อาจทำงานขัดกับการฝึกอบรมของโมเดลมากกว่าที่จะทำงานร่วมกัน
มองไปข้างหน้า
การถกเถียงสะท้อนคำถามที่กว้างขึ้นเกี่ยวกับเครื่องมือพัฒนา AI: เราควรสร้างระบบที่ซับซ้อนรอบข้อจำกัดของ AI ปัจจุบัน หรือมุ่งเน้นไปที่แนวทางที่เรียบง่ายกว่าที่ทำงานกับวิธีที่โมเดลเหล่านี้ทำงานจริงๆ
เมื่อโมเดลใหม่กว่าเช่น Claude 4 แสดงการปรับปรุง นักพัฒนาบางคนรายงานผลลัพธ์ที่ดีขึ้นกับเฟรมเวิร์กเดียวกัน สิ่งนี้แสดงให้เห็นว่าปัญหาอาจเป็นเรื่องของความสามารถของโมเดลมากกว่าการออกแบบเฟรมเวิร์กเพียงอย่างเดียว
ฉันทามติของชุมชนดูเหมือนจะเกิดขึ้นรอบจุดกึ่งกลาง - ใช้โครงสร้างบางอย่างเพื่อแนะนำพฤติกรรม AI ในขณะที่หลีกเลี่ยงความซับซ้อนมากเกินไปที่ทำให้ context window รกรุงรัง แนวทางที่ประสบความสำเร็จมากที่สุดดูเหมือนจะรวมการกำหนดงานที่ชัดเจนกับ guardrails ที่น้อยแต่มีประสิทธิภาพ
อ้างอิง: Claude Code Framework Wars