Claude Code ใช้งานได้ง่ายทันทีกับโปรเจกต์ขนาดเล็กหรือการสร้าง prototype จากศูนย์ที่ยังไม่มีกฎเกณฑ์ซับซ้อน แต่งานซอฟต์แวร์ระดับองค์กรที่มีวิศวกรนับพันคนแชร์ monorepo เดียวกัน มี convention สะสมมานานหลายปี มี CI/CD pipeline ซับซ้อน และมี stakeholder หลายฝ่ายที่ต้องเข้าใจภาพตรงกัน บริบทเหล่านี้ทำให้ Claude แบบเดิมๆ ไม่เพียงพอ

ในงาน Code with Claude ของ Anthropic, Daisy Holman วิศวกรประจำทีม Claude Code (และอดีตประธานคณะกรรมการมาตรฐาน C++) ขึ้นบรรยายในหัวข้อ "Beyond the basics with Claude Code" เพื่อตอบคำถามสำคัญ: หากต้องการให้ AI agent ทำงานเคียงบ่าเคียงไหล่กับวิศวกรซอฟต์แวร์มืออาชีพ เราต้องออกแบบ agentic harness อย่างไร และข้อจำกัดทางวิศวกรรมแบบไหนที่ใช้ตัดสินใจเลือก abstraction ที่เหมาะสม

ดูคลิปต้นฉบับ Beyond the basics with Claude Code บนช่อง YouTube ของ Claude

1. ทำไม Claude แบบ Out-of-the-Box จึงไม่พอสำหรับงาน Software Engineering จริง

Daisy แยกความแตกต่างระหว่างสองคำอย่างชัดเจน:

• Agentic Programming คือการสั่งให้ agent เขียนโค้ดจบเป็นไฟล์ๆ หรือทำ demo เล็กๆ
• Agentic Software Engineering คือการทำงานใน codebase ขนาดใหญ่ที่มีข้อตกลงร่วมของทีม มี technical debt ที่ต้องระวัง และต้องคำนึงถึงผลกระทบต่อระบบโดยรวม

Claude ในสภาพตั้งต้นจะมองเห็นเพียง repository กับ shell จึงทำงานได้ดีกับโปรเจกต์เดี่ยว แต่ในการทำงานจริง บริบทสำคัญส่วนใหญ่ไม่ได้อยู่ใน source code แต่อยู่ใน design docs, เธรด Slack, บันทึกการประชุม, รันบุ๊ก และแดชบอร์ดของระบบ production ถ้า agent เข้าไม่ถึงข้อมูลเหล่านี้ การตัดสินใจก็จะไม่สอดคล้องกับแนวทางของทีม

หัวใจสำคัญจึงอยู่ที่การปรับแต่ง agentic harness ให้ agent มีข้อมูลและเครื่องมือเท่าเทียมกับวิศวกรในทีม โดย Daisy เสนอกรอบคิด 3 เสาหลัก ได้แก่ Access (การเข้าถึง), Knowledge (ความรู้เฉพาะทาง) และ Tooling (เครื่องมือ)

2. เสาหลัก 3 ต้นของ Agentic Harness: Access, Knowledge, Tooling

2.1 Access: ตอบคำถามว่า "ทำไม" ถึงตัดสินใจแบบนั้น (Why)

Access คือการเปิดทางให้ Claude เข้าถึงพื้นที่ที่ทีมใช้ตัดสินใจจริง เวลาที่ Claude เลือกแนวทางผิด มักเกิดจากการที่ Claude ขาดบริบทที่อยู่ในหัวของนักพัฒนา หาก Claude ได้เห็นเธรดการถกเถียงเรื่อง architecture ใน Slack, ได้อ่าน design doc ที่แจกแจง trade-off หรือเห็น error log ตอนระบบล่ม โอกาสที่จะตัดสินใจได้ตรงใจทีมจะเพิ่มขึ้นทันที

Daisy ยกตัวอย่างงานที่ควรยกให้ agent จัดการ:

• CI/CD Failure การแก้งานที่ build ไม่ผ่านเป็นงานที่ agent ทำได้รวดเร็วและแม่นยำ
• Production Dashboard การดึงและวิเคราะห์ข้อมูลปริมาณมากขณะระบบเกิดปัญหา
• Meeting Notes บันทึกการประชุมที่แปลงเป็นข้อความ แล้วให้ Claude หาประเด็นย่อยเพื่อเปิด Pull Request (PR) แก้ไขจุดเล็กๆ ซึ่งทีมของ Daisy ได้เฉลี่ย 2 ถึง 3 PR ต่อหนึ่งการประชุมโดยไม่ต้องสั่งงานรายตัว

2.2 Knowledge: ตอบคำถามว่า "อะไร" คือบริบทของ Codebase (What)

Knowledge ครอบคลุมกฎเกณฑ์ภายในทีม, internal API, ศัพท์เฉพาะ และความเปลี่ยนแปลงล่าสุดของระบบ ซึ่งข้อมูลเหล่านี้ไม่มีอยู่ใน training data ของโมเดล

Daisy ชี้ว่าการนำโมเดลไป fine-tune เพื่อให้เข้าใจ codebase นั้นไม่ตอบโจทย์ ด้วยเหตุผล 2 ประการ:

1. งานวิจัยชี้ว่าการ fine-tune ข้อมูลเฉพาะทางมักเพิ่มอัตราการตอบข้อมูลเท็จ (hallucination)
2. โมเดล frontier มีการอัปเดตเร็วมาก การลงทุน fine-tune จึงไม่คุ้มค่าทางเศรษฐศาสตร์

ทางออกที่มีประสิทธิภาพคือ In-Context Learning (ICL) ซึ่งทำได้ผ่านไฟล์ CLAUDE.md, skills และ prompts เพื่อป้อนความรู้เข้าสู่ context window ของโมเดลเฉพาะช่วงเวลาที่ต้องใช้ แทนที่จะพยายามยัดความรู้เข้าไปใน weights ของโมเดล

2.3 Tooling: ตอบคำถามว่า "อย่างไร" ในการลงมือทำ (How)

เมื่อนักพัฒนายังต้องการ syntax highlighting, LSP และระบบ autocomplete สำหรับช่วยพิมพ์โค้ด Claude ที่ต้องแก้ไขโค้ดแบบตรงตัวทุกตัวอักษรก็ต้องการเครื่องมือช่วยตรวจทานในระดับเดียวกัน

Daisy เปรียบเทียบ Claude ในสภาพเริ่มต้นเหมือนคนที่ต้องเขียนโค้ดด้วย editor โบราณอย่าง ed ที่ไม่มีเครื่องมือแจ้งเตือนใดๆ สิ่งที่โมเดลต้องการคือระบบเตือนแบบ "เส้นหยักสีแดง" (red squiggly) ที่คอยสะกิดเตือนเบาๆ โดยไม่ขัดจังหวะการทำงาน

Daisy แนะนำให้ใช้ post-tool-use hook มาทำหน้าที่เป็น red squiggly ตัวอย่างเช่น เมื่อ Claude พยายามแก้ไขไฟล์ที่ถูกสร้างอัตโนมัติ (generated file) hook จะแทรกข้อความเตือนว่าไฟล์นี้เป็น generated file และไม่ควร commit แทนที่จะสั่งบล็อกการแก้ไขอย่างเด็ดขาด เพราะบางครั้ง agent อาจมีเหตุผลจำเป็นในการแก้เพื่อทดสอบระบบชั่วคราว

หลักการสำคัญคือการเลือกสร้าง tool ที่เสริมพลังตามความฉลาดของโมเดลที่เพิ่มขึ้น แทนที่จะสร้าง tool เพื่อชดเชยจุดอ่อนชั่วคราวของโมเดลรุ่นเก่า

3. Context Window: ข้อจำกัดทางวิศวกรรมที่แท้จริง

Daisy เน้นย้ำว่า context window ของโมเดลชั้นนำไม่ได้ขยายตัวอย่างก้าวกระโดดในช่วงที่ผ่านมา และเราไม่สามารถแก้ปัญหานี้ได้ด้วยการอัด compute เพิ่มเพียงอย่างเดียว นักพัฒนาจึงควรมอง context window เป็นทรัพยากรจำกัดที่ต้องใช้อย่างคุ้มค่าที่สุด

Daisy เปรียบเทียบว่าการใส่ข้อมูลทุกอย่างเข้า context window เหมือนกับการพยายามรัน npm บนบอร์ด Arduino หน่วยความจำที่มีจำกัดบังคับให้เราต้องเลือกเฉพาะสิ่งที่จำเป็นอย่างยิ่งยวดตามหลักการ "Don't pay for what you don't use"

นอกจากนี้ ระบบยังมีกลไก KV Cache เข้ามาเกี่ยวข้อง ทุกครั้งที่ token ช่วงต้นของ context มีการเปลี่ยนแปลง ระบบจะต้องคำนวณ token ทั้งหมดหลังจากนั้นใหม่ ซึ่งมีค่าใช้จ่ายสูงกว่าการอ่านจากแคชเดิมถึง 10 เท่า สถาปัตยกรรมที่ดีจึงต้องวางข้อมูลที่คงที่ (เช่น คำนิยามของ tool และ system prompt) ไว้ที่ช่วงต้นของ context และวางข้อมูลที่เปลี่ยนแปลงบ่อยไว้ที่ส่วนท้าย

4. เปรียบเทียบ 4 รูปแบบ Plug-in Primitives ในแง่ Context Scaling

Daisy ตั้งคำถามสำคัญว่า หากเรามีปลั๊กอินถึง 100,000 ตัวใน monorepo แต่ละ abstraction จะรับมืออย่างไร:

4.1 MCP (Model Context Protocol)

• ตำแหน่ง Context: นิยามของทุก tool (ชื่อ, คำอธิบาย, schema) ต้องอยู่ใน system prompt ตลอดเวลา
• พฤติกรรมการ Scale: Scale ได้จำกัด หากมีหลายสิบ server รวมกันหลายร้อย tool ขนาดของ schema จะกินพื้นที่ context window ไปมหาศาลตั้งแต่ยังไม่เริ่มทำงาน
• ความเหมาะสม: เหมาะกับการเชื่อมต่อภายนอกที่ผู้ใช้ไม่มีสิทธิ์เข้าถึง shell โดยตรง (เช่น Slack, Email, Ticket system) แต่สำหรับระบบภายใน การใช้ CLI command ตรงๆ ผ่าน skill จะประหยัดกว่า

4.2 Skills

• ตำแหน่ง Context: เก็บเฉพาะ description สั้นๆ ไว้ใน system prompt แล้วโหลดเนื้อหาเต็มเข้ามาเมื่อถูกเรียกใช้ (Progressive Disclosure)
• พฤติกรรมการ Scale: ดีกว่า MCP เพราะจ่าย token เฉพาะตอนใช้งานจริง แต่ description ของทุก skill ยังกินพื้นที่ใน system prompt อยู่
• ความเหมาะสม: เหมาะกับคู่มือ workflow, convention ภายในทีม และ guideline เฉพาะทาง

4.3 Hooks

• ตำแหน่ง Context: ทำงานอยู่นอก context window ทั้งหมด โดยถูกทริกเกอร์จาก event ภายใน agentic loop
• พฤติกรรมการ Scale: เป็น Zero-overhead Abstraction อย่างแท้จริง ต่อให้มี hook 100,000 ตัวในเครื่อง หากไม่มี event ที่ตรงเงื่อนไข ก็จะไม่เสีย token ใน context เลยแม้แต่น้อย
• ความเหมาะสม: เหมาะสำหรับทำ linting, type-checking, sanity check และระบบแจ้งเตือนแบบ red squiggly

4.4 Sub-agents

• ตำแหน่ง Context: ทำงานแยก context window อิสระจาก main agent
• พฤติกรรมการ Scale: เหมาะกับการทำงานแบบคู่ขนาน (parallelism) หรืองานสำรวจที่ต้องอ่านไฟล์จำนวนมากเพื่อสรุปผลสั้นๆ ส่งกลับมา โดยไม่ทำให้ main context บวม
• ความเหมาะสม: เหมาะสำหรับงานค้นคว้า, งานรีวิวโค้ดเชิงลึก และงานที่แยกส่วนชัดเจน

5. รูปแบบการทำงานจริงของทีม Anthropic: Asynchrony และ Parallelism

Daisy เล่าถึงสไตล์การทำงานภายในของทีม Claude Code ที่เปลี่ยนจากการนั่งรอหน้าจอ มาเป็นการสั่งงานแบบ asynchronous และรันหลาย agent พร้อมกัน:

Git Worktrees แยกโฟลเดอร์สำหรับ Agent อายุยาว

ทีมใช้ git worktree เพื่อแยก repo ออกเป็นหลายโฟลเดอร์บนเครื่องเดียว ทำให้ Claude Code แต่ละตัวทำงานบน branch ของตนเองได้อย่างอิสระ ไม่ชนกัน ช่วยลดเวลาติดตั้ง dependency ซ้ำซ้อน และยังใช้เทคนิคตั้งชื่อพร้อมเปลี่ยนสีของ session เพื่อช่วยให้สลับบริบทการทำงานได้ง่ายขึ้น

send_message: ให้ Claude สื่อสารกันเอง

ระบบเปิดให้ Claude instance หนึ่งส่งข้อความสอบถามบริบทหรือผลลัพธ์จาก Claude อีกตัวหนึ่งได้โดยตรง ขยายขอบเขตการเข้าถึงข้อมูลระหว่าง agent ในทีม

/loop: สั่งรันคำสั่งตามรอบเวลา

คำสั่ง /loop ช่วยรัน prompt ซ้ำๆ ตามเวลาที่กำหนด เช่น ให้คอยเช็กผลการรัน CI ทุก 10 นาที หากพบข้อผิดพลาดก็สั่งแก้และ push ใหม่จนกว่า build จะผ่าน ช่วยให้นักพัฒนาปล่อยงานทิ้งไว้ข้ามคืนได้

Auto Permissions Mode: ปลอดภัยสำหรับงานข้ามคืน

โหมดนี้ใช้ classifier agent ร่วมกับ adversarial agent คอยตรวจสอบความปลอดภัยของคำสั่งก่อนอนุมัติ ทำให้ agent ทำงานต่อเนื่องได้โดยไม่ต้องหยุดรอการกดยืนยันจากมนุษย์ในทุกขั้นตอน

Claude Agents View และ Remote Control

หน้าจอสำหรับมอนิเตอร์สถานะของ agent ทุกตัวพร้อมกัน และฟีเจอร์ Remote Control ที่ช่วยให้ตรวจเช็กความคืบหน้าของงานผ่านสมาร์ตโฟนได้จากทุกที่

6. สรุป 3 บทเรียนสำคัญ

1. Give it access: เปิดทางให้ agent เข้าถึงพื้นที่ที่มีบริบทการตัดสินใจของทีม ไม่ว่าจะเป็นเอกสารการออกแบบ, เธรดการสนทนา หรือแดชบอร์ด เพื่อให้ agent ทำงานเป็นเพื่อนร่วมทีมได้อย่างแท้จริง
2. Mind the box: ตระหนักอยู่เสมอว่า context window มีจำกัด ต้องเลือกใส่เฉพาะข้อมูลที่จำเป็นและมีโครงสร้างชัดเจน
3. Pick abstractions that scale: เลือกใช้ abstraction ให้เหมาะกับขนาดของงาน โดยมองหาเครื่องมือที่มี overhead ต่ำอย่าง Hooks สำหรับงานตรวจสอบ และใช้ Skills หรือ Sub-agents สำหรับงานที่ต้องการความยืดหยุ่น

ที่มา: Beyond the basics with Claude Code (Daisy Holman, Claude, Anthropic official)