What is Claude Code

คุณกำลังนั่งอยู่ในโปรเจกต์ shop-api และเจอ bug: `GET /orders/:id` คืน `200` พร้อม body ว่างเปล่าเมื่อไม่พบ order ในฐานข้อมูล คุณเปิดหน้าต่างแชทของโมเดลภาษา แล้วพิมพ์ว่า "ช่วยแก้ bug นี้ให้หน่อย" จากนั้นก็ได้โค้ดที่ดูสมเหตุสมผลกลับมา: ``` if (!order) { return res.status(404).json({ error: "not found" }); } ``` โค้ดนี้ถูกต้องในเชิงไวยากรณ์ และอ่านแล้วก็ดูเหมือนจะแก้ปัญหาได้ แต่โมเดลไม่เคยเห็นไฟล์จริงของ shop-api เลย: มันไม่รู้ว่า route ถูกประกาศที่ไหน, handler เรียกฐานข้อมูลผ่านอะไร, โปรเจกต์ใช้ test runner ตัวไหน และจะรู้ได้อย่างไรว่าการแก้นี้ทำให้เทสต์ที่ล้มอยู่กลับมาเขียว คำถามที่บทนี้จะตอบจึงไม่ใช่ "โมเดลเก่งแค่ไหน" แต่คือ "อะไรทำให้ข้อความของโมเดลกลายเป็นการเปลี่ยนแปลงจริงในโปรเจกต์"

เมื่อคุณรัน Claude Code ในโฟลเดอร์ shop-api สิ่งที่เกิดขึ้นต่างออกไปอย่างมีนัยสำคัญ: มันอ่านไฟล์จริงในโปรเจกต์ดังกล่าว หา handler ของ `GET /orders/:id` เจอ แก้ ณ จุดที่เป็นสาเหตุจริง แล้วรัน `pnpm test` เพื่อยืนยันด้วยผลลัพธ์จริงก่อนสรุป ความต่างนี้ไม่ได้มาจาก "โมเดลฉลาดขึ้น" แต่มาจากชั้นที่ห่อโมเดลไว้ ซึ่งบทนี้จะอธิบายกลไกก่อน แล้วจึงเรียกชื่อมันอย่างแม่นยำ

โมเดลภาษาทำได้อย่างเดียว: รับข้อความที่อยู่ในสายตาของมัน แล้วทำนายข้อความถัดไป มันไม่มีมือไว้แก้ไฟล์ ไม่มีตาไว้รันคำสั่ง และไม่มีความจำข้าม session ที่ติดตัวมา ถ้าอยากให้งานในโปรเจกต์เกิดขึ้นจริง ต้องมีชั้นหนึ่งที่ทำสี่อย่างนี้แทนโมเดล: - **ให้เครื่องมือ** — อ่านไฟล์ แก้ไฟล์ รันคำสั่ง แล้วส่งผลลัพธ์กลับ - **ประกอบ context** — เลือกว่าอะไรจะอยู่ในสายตาของโมเดลในแต่ละรอบ - **ตรวจสิทธิ์** — ตัดสินว่าการกระทำใดต้องขออนุญาตก่อน - **ป้อนผลกลับ** — เอา output จริงของเครื่องมือกลับเข้าไปให้โมเดลตัดสินใจรอบถัดไป ชั้นนี้คือ **agentic harness** และ Claude Code คือ harness นี้พร้อมโมเดล Claude อยู่ข้างใน

ใน shop-api ลูปการทำงานจริงมีลำดับดังนี้: 1. **รับโจทย์** — คุณพิมพ์เป้าหมายลงใน session เช่น "แก้ bug ที่ `GET /orders/:id`" 2. **gather** — harness ประกอบ context จากคำสั่งของคุณ + ไฟล์ instruction ของโปรเจกต์ (ถ้ามี) + ประวัติการสนทนา + ผลลัพธ์จากเครื่องมือรอบก่อน ๆ 3. **act** — โมเดลขอเรียกเครื่องมือตามแผนของมัน เช่น อ่าน `src/routes/orders.ts`, แก้ไข, หรือรัน `pnpm test` 4. **ตรวจสิทธิ์** — harness เทียบคำขอกับ permission rule ก่อนที่การกระทำจะเกิดขึ้นจริง 5. **verify** — harness รันเครื่องมือ เก็บ output จริง และป้อนกลับเป็น context ของรอบถัดไป 6. **วนซ้ำหรือจบ** — โมเดลตัดสินจากผลจริงว่าควรแก้ต่อหรือสรุปงาน

จุดสำคัญของกลไกนี้คือ context ถูกประกอบขึ้นใหม่ทุกครั้งที่เริ่ม session ไม่มีอะไรถูกจำไว้ข้างในตัวโมเดลระหว่าง session นอกเหนือจากสิ่งที่ถูกเขียนลงไฟล์ที่ harness โหลดให้ สิ่งที่คุณเคยบอกใน session ก่อนจึงไม่ตามมาโดยอัตโนมัติ นี่คือเหตุผลเชิงกลไกที่ความรู้ถาวรของโปรเจกต์ต้องอยู่ในไฟล์ ไม่ใช่ในแชท

ลองเทียบสิ่งที่เกิดขึ้นกับโจทย์ bug เดียวกันในสองรูปแบบ เพื่อให้เห็นว่าความต่างอยู่ที่ชั้นใด

• โมเดลทำหน้าที่ให้เหตุผลจาก context ส่วน harness เป็นชั้นที่ให้เครื่องมือ ประกอบ context ตรวจสิทธิ์ และป้อนผลจริงกลับ
• Claude Code ทำงานเป็นลูป gather → act → verify โดยมี permission check คั่นก่อนการกระทำทุกครั้ง
• context ถูกประกอบใหม่ทุก session สิ่งที่จำถาวรจึงต้องอยู่ในไฟล์ที่ harness โหลดให้
• ก้าวต่อไป: บทถัดไปคือ Model vs harness ซึ่งจะแยกสองชั้นนี้ออกจากกันด้วยตัวอย่างที่คมขึ้น และเป็นพื้นฐานให้ทุกบทหลังจากนี้