Skip to content
Claude Code เกิดจาก Dogfood ไม่ใช่ Roadmap: Gate ก่อนสร้าง AI Agent ให้ทีมใช้จริง
หลายทีมเริ่มปี 2026 ด้วยประโยคคล้ายกัน: “เราน่าจะมี AI Agent ของบริษัท”
ฟังดูถูกทางครับ แต่คำถามที่สำคัญกว่าคือ agent ตัวนั้นควรเกิดจากอะไร
เกิดจาก roadmap ที่ผู้บริหารอยากมี
หรือเกิดจาก workflow จริงที่ทีมใช้แล้วพิสูจน์ได้ว่ากลับไปทำแบบเดิมยากขึ้น
บทความ official ของ Anthropic เรื่อง The Making of Claude Code ทำให้เห็นเส้นทางที่น่าสนใจมาก เพราะ Claude Code ไม่ได้เริ่มจากการประกาศว่า “เราจะสร้าง coding agent เบอร์หนึ่ง” แล้วค่อยหาผู้ใช้ แต่มันค่อย ๆ โตจากเครื่องมือที่คนในบริษัทใช้เอง เห็น pain จริง แก้ feedback เร็ว และขยับจาก assistant ไปเป็น agent เมื่อความไว้ใจเริ่มเกิดขึ้นจริง
นี่คือบทเรียนที่ทีมไทยเอาไปใช้ได้ทันที ไม่ว่าจะกำลังทำ agent สำหรับ sales ops, data ops, content ops, dev ops หรือ back office automation
1) เกิดอะไรขึ้น
Anthropic เล่าว่า product coding แรก ๆ ของบริษัทเคยเป็น VS Code extension ที่ให้ข้อเสนอหลายทางต่อหนึ่ง prompt ก่อนที่ชิ้นส่วนสำคัญของ agentic coding จะเริ่มชัดขึ้น เช่น bash tool, search, internal CLI ที่ชื่อ clide, และต่อมาคือ Labs team ที่ตั้งขึ้นในมกราคม 2024 เพื่อผลักงาน agentic coding โดยตรง
จุดที่ควรสนใจคือเส้นทางนี้ไม่ได้เป็นเส้นตรงแบบ product launch ทั่วไป
มันมีของที่ยังไม่พร้อม มี internal tool ที่คนบางกลุ่มชอบมาก มีคนใช้จริงส่ง feedback หนัก มี core features หลายอย่างที่ถูกเร่งใน sprint สั้น ๆ และมีระบบ auto-update กับ user metrics ที่ทำให้ทีมแก้ปัญหาให้ผู้ใช้ได้เร็ว
ถ้าแปลเป็นภาษาคนทำงาน: Claude Code โตจาก loop ของ “ใช้เอง, เจ็บเอง, แก้เอง, วัดเอง” ก่อนจะกลายเป็น product ที่คนข้างนอกใช้
2) ทำไมมันสำคัญกว่าที่เห็น
เวลาคุยเรื่อง AI Agent หลายทีมมักเริ่มที่ model, tool, framework หรือ vendor
แต่เรื่องนี้ชี้อีกมุมหนึ่ง: agent ที่ดีต้องมี สนามใช้งานจริง ก่อน
ถ้าทีมเราไม่มีงานจริงให้ agent ลอง ไม่มีคนใช้ที่พร้อมบอกว่าอะไรพัง ไม่มี telemetry หรือ proof ว่าใช้แล้ว workflow ดีขึ้น เราจะได้แค่ demo ที่ดูฉลาด แต่ไม่กลายเป็นระบบทำงาน
Claude Code น่าสนใจเพราะ signal สำคัญไม่ได้มีแค่ “มันเขียนโค้ดได้” แต่มีสัญญาณ operator หลายชั้น:
- มี internal users ที่ใช้กับงานจริง
- feedback กลับไปถึงทีมทำ product เร็ว
- ทีมสามารถ ship fix และ feature ได้ไว
- usage เพิ่มขึ้นตามความไว้ใจ ไม่ใช่ตามคำสั่ง
- ขอบเขตของ assistant ค่อย ๆ เปลี่ยนเป็น agent เมื่อคนเริ่มยอมให้มัน take action มากขึ้น
นี่คือความต่างระหว่าง “มี AI tool” กับ “มี AI operating loop”
3) Operator Lesson: ธุรกิจควรเปลี่ยนวิธีทำงานอะไร
ถ้าคุณกำลังจะสร้าง AI Agent ภายในองค์กร อย่าเริ่มจากการถามว่า “จะเปิดให้ใครใช้บ้าง”
ให้เริ่มจากการหา dogfood lane เล็ก ๆ ก่อน
เลือกทีมที่ pain ชัด มีงานซ้ำพอประมาณ มีคนพร้อมให้ feedback และมีขอบเขตความเสี่ยงที่ควบคุมได้ เช่น สรุป lead, ตรวจ report, สร้าง draft email, triage ticket, อ่าน log, ตรวจ PR, หรือจัด queue content
จากนั้นให้วัด 3 อย่าง:
- Usage proof: คนกลับมาใช้ซ้ำเองหรือไม่
- Workflow proof: งานจริงเร็วขึ้น ชัดขึ้น หรือมี error น้อยลงไหม
- Trust proof: คนยอมให้ agent ทำ action มากขึ้นเพราะเห็นหลักฐาน ไม่ใช่เพราะโดนบังคับ
ถ้าไม่มี 3 proof นี้ อย่าเพิ่ง scale
เพราะการ scale agent ที่ยังไม่มี trust loop จะสร้างภาระ follow-up มากกว่า productivity
Operator Kit: Agent Dogfood Gate Checklist
ใช้ checklist นี้ก่อนเปิด internal AI agent จากทีมทดลองไปสู่ทีมกว้างขึ้น
- Real work gate: agent ถูกใช้กับงานจริงอย่างน้อย 5 รอบหรือยัง ไม่ใช่แค่ demo script
- Repeat use gate: มีผู้ใช้กลับมาใช้ซ้ำเองอย่างน้อย 2 คนหรือ 2 workflow โดยไม่ได้ถูกบังคับหรือยัง
- Feedback speed gate: feedback สำคัญถูกแปลงเป็น fix, prompt rule, tool change หรือ SOP update ภายในรอบงานถัดไปหรือยัง
- Boundary gate: agent รู้ชัดไหมว่าอ่านอะไรได้ แก้อะไรได้ ต้องขออนุมัติก่อน action ไหน และห้ามแตะอะไร
- Proof gate: ทุก run มีหลักฐานงาน เช่น diff, source URL, log, screenshot, queue state หรือ QA result ที่คนตรวจย้อนหลังได้หรือยัง
- Trust gate: ถ้าจะเปิด auto-accept หรือ unattended mode มี rule ว่างานแบบไหนทำได้เอง และงานแบบไหนต้องหยุดถามคนหรือยัง
- Scale gate: ถ้าผู้ใช้เพิ่ม 10 เท่า ทีมยังรับ feedback, incident, cost, permission และ training ได้หรือไม่
ถ้า checklist นี้ผ่านไม่ครบ ให้จัด agent เป็น internal pilot ต่อไป ไม่ใช่ production coworker
5) Data-Espresso จะเอาไปใช้ยังไง
สำหรับ Data-Espresso บทเรียนนี้ตรงกับวิธีทำงานของ operating system มากกว่าการซื้อ tool ใหม่
ทุก agent ที่จะเข้า workflow จริงควรมี control plane เล็ก ๆ:
- issue หรือ ticket ที่บอกเป้าหมายชัด
- source proof ก่อนเขียนหรือแก้
- output artifact ที่ตรวจได้
- QA gate ก่อนส่งต่อ
- approval boundary ก่อน publish, send, deploy หรือเปลี่ยน production
พูดง่าย ๆ คือ agent ไม่ควรถูกวัดจากคำตอบที่ดูดีใน chat แต่ควรถูกวัดจากงานที่จบพร้อมหลักฐาน
และถ้าทีมยังไม่มีวิธีรับ feedback กลับเข้า agent loop ก็ยังไม่ควรเรียกมันว่า autonomous เต็มตัว
สรุป
Claude Code เป็นสัญญาณที่ดีว่าตลาดกำลังขยับจาก coding assistant ไปสู่ coding agent จริง
แต่บทเรียนที่สำคัญกว่าคือ วิธีที่ agent กลายเป็นของจริงไม่ได้เริ่มจากคำประกาศ มันเริ่มจากการใช้งานในสนามจริงจนเกิด trust
สำหรับทีมไทยที่กำลังทำ AI Agent ของตัวเอง คำถามแรกจึงไม่ใช่ “ใช้ model ไหน”
คำถามแรกคือ “เรามี dogfood gate ที่พิสูจน์ว่า agent นี้ควรได้สิทธิ์มากขึ้นหรือยัง”