Claude Code คือเครื่องมือ AI ที่ทำงานผ่านหน้าจอพิมพ์คำสั่งของเครื่องเราและแก้ไฟล์ในโปรเจกต์ได้จริง แต่เริ่มจากศูนย์ใหม่ทุกครั้งที่เรากด Enter

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

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

และนี่คือจุดที่เปลี่ยนวิธีทำงานของเราได้จริง เพราะถ้าทุกเทิร์นต้องประกอบขึ้นใหม่ ทุกอย่างที่เราตั้งค่าไว้ก็ไม่ใช่การสอนให้มันจำ แต่เป็นการออกแบบว่าอะไรจะไปอยู่ในบริบทของเทิร์นถัดไป สิ่งเหล่านี้มีทั้งไฟล์ CLAUDE.md ที่บอกกติกาของโปรเจกต์ กฎ permissions ที่กำหนดว่าอะไรทำได้หรือทำไม่ได้ skills ที่เก็บขั้นตอนงานไว้ให้มันหยิบไปใช้ และ workflow ที่วางลำดับงานทั้งชุดไว้ล่วงหน้า บทบาทของเราจึงเปลี่ยนจากการพิมพ์โค้ด มาเป็นการจัดเตรียมบริบทให้ครบและตรวจผลลัพธ์ให้เป็น

โมเดลเริ่มจากศูนย์ทุกครั้ง ส่วน harness ทำหน้าที่ป้อนบริบทใหม่

Lydia Hallie จากทีมผู้พัฒนา Claude Code ที่ Anthropic อธิบายเรื่องนี้ไว้ชัดที่สุดในคลาส Claude Code ที่ Frontend Masters เปิดสอนฟรีว่า โมเดลเป็น stateless ไม่มีความจำระหว่างการเรียกแต่ละครั้ง และไม่มีแม้แต่ความจำภายในเซสชันเดียวกัน ทุกครั้งที่เรียก มันเริ่มจากศูนย์ โดย harness มีหน้าที่ป้อนข้อมูลทุกอย่างที่โมเดลต้องรู้

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

พอมองแบบนี้ คำถามสำคัญก็เปลี่ยนไปทันที จากเดิมที่ถามว่าจะทำยังไงให้ Claude จำได้ กลายเป็นว่าจะทำยังไงให้ข้อมูลที่มันอ่านในแต่ละรอบครบและถูกต้อง เราเป็นคนตอบคำถามใหม่นี้ได้ทั้งหมด และคำถามนี้คือหลักสำคัญในการทำความเข้าใจทุกฟีเจอร์ในบทความ ใครยังไม่คุ้นกับเครื่องมือนี้ อ่าน Claude Code คืออะไร เข้าใจ pattern หลักของ CLI coding agent ควบคู่กันได้

เปิดดูข้างในก้อน prompt ที่ส่งไปทุกเทิร์น

ทันทีที่เรากด Enter Claude Code จะรวบรวมคำสั่งและบริบททั้งหมดที่โมเดลต้องอ่านไว้ใน prompt เดียว แล้วส่งผ่าน Messages API ซึ่งเป็นช่องทางเรียกใช้โมเดลของ Anthropic คำขอนี้อยู่ในรูปแบบ JSON ซึ่งเป็นรูปแบบข้อมูลที่โปรแกรมใช้สื่อสารกัน แต่โมเดลไม่ได้อ่าน JSON โดยตรง เพราะฝั่ง API จะแปลงข้อมูลเป็น token หรือหน่วยข้อความย่อยให้โมเดลอ่าน prompt ที่ส่งไปมีสี่ส่วนหลัก

tool schemas คือคำอธิบายเครื่องมือทุกตัวที่ Claude Code ลงมือทำแทนเราได้ ทั้งชื่อ คำอธิบาย และรูปแบบข้อมูลที่ต้องส่งเข้าไป เช่น bash · edit · read · agent · web fetch จุดที่คนมักเข้าใจผิดคือโมเดลรันเครื่องมือพวกนี้เองไม่ได้ มันทำได้แค่ส่งสัญญาณออกมาว่าอยากให้ harness รันตัวไหนให้

system prompt คือคำสั่งตั้งต้นที่ Anthropic กำหนดมาใน Claude Code บอกว่ามันเป็นใคร ใช้น้ำเสียงแบบไหน ใช้หลักการเขียนโค้ดแบบใด และต้องบังคับใช้กฎความปลอดภัยข้อไหนบ้าง ส่วนนี้เราไม่ได้เขียนเอง

environment คือสภาพแวดล้อมของเซสชันที่ Claude Code บันทึกไว้ตอนเปิดโปรแกรม ทั้งระบบปฏิบัติการ shell หรือโปรแกรมที่คอยรับคำสั่งที่เราพิมพ์ โมเดลที่กำลังรันอยู่ และ git branch หรือชุดโค้ดที่แยกออกมาสำหรับแก้ไข

messages array คือส่วนที่มาจากเราจริงๆ ข้างในมีข้อความทั้งหมดที่เราพิมพ์ เนื้อหาไฟล์ CLAUDE.md ซึ่งจะแนบไปกับข้อความแรกของเซสชันถ้าโปรเจกต์นี้มีไฟล์ดังกล่าว และรายชื่อ skills ทั้งหมดของโปรเจกต์ ก่อนปิดท้ายด้วยประโยคที่เราเพิ่งพิมพ์

รายชื่อ skills ตรงนี้มีรายละเอียดที่สำคัญมาก คือมันส่งไปแค่ชื่อกับคำอธิบายสั้นๆ ไม่ได้ส่งเนื้อในทั้งไฟล์ วิธีนี้เรียกว่า progressive disclosure หรือการทยอยเปิดเผยเท่าที่จำเป็น โมเดลจะเห็นแค่ว่ามีทักษะอะไรให้หยิบใช้ได้บ้าง แล้วค่อยเปิดอ่านเนื้อในตอนที่ตัดสินใจใช้จริง ผลคือเรามี skill เยอะแค่ไหนก็ได้ โดยไม่ต้องส่งไฟล์ทั้งหมดไปทุกรอบ

ทุกอย่างที่เราตั้งค่าไว้ คือการออกแบบว่าอะไรจะไปอยู่ในบริบทของเทิร์นถัดไป

วงจร tool call ที่ทำให้ Claude Code ทำงานต่อเนื่องเองได้

โมเดลอ่าน prompt ทั้งก้อน แล้วคิดจากข้อมูลที่มีอยู่ตรงหน้า ถ้ายังขาดข้อมูลบางอย่าง เช่น ยังไม่เคยเห็นไฟล์ที่เราพูดถึง มันจะส่งข้อความที่มี tool call ออกมาเพื่อขอใช้เครื่องมือ read อ่านไฟล์นั้น

จากนั้น harness จะเรียกเครื่องมือไปอ่านไฟล์จริงในเครื่อง แล้วนำผลลัพธ์มาต่อท้าย messages array พร้อมกับข้อความ tool call เมื่อครู่ ก่อนประกอบ prompt ทั้งหมดขึ้นใหม่และส่งให้โมเดลอ่านอีกรอบตั้งแต่ต้น วงจรนี้ทำซ้ำไปเรื่อยๆ จนกว่างานจะจบ นี่คือ agentic loop ที่ทำให้ AI agent ทำงานยาวๆ เองได้ ใครอยากเห็นวงจรนี้แบบเจาะลึก มีบทความ Agent loop คือวงจร reason → act → observe แยกไว้อีกที

ผลจากวงจรนี้มีสองอย่างที่ควรจำให้ขึ้นใจ อย่างแรกคือทุกสิ่งที่เราใส่ไว้จะส่งไปพร้อมกับทุกเทิร์น ไม่ใช่แค่รอบแรก CLAUDE.md ที่ยาวเกินจำเป็นจึงกินที่ในทุกรอบ อย่างที่สองคือ plan mode จะจำกัดสิทธิ์ของวงจรนี้ไว้ โดยบอกกลายๆ ว่ายังห้ามแตะโค้ด ต้องวางแผนก่อน แล้วจึงอนุญาตให้รัน tool call จริง

allow · ask · deny กฎที่เราเขียนไว้ใน settings.json

ไฟล์ .claude/settings.json คือที่ที่เรากำหนดว่าเครื่องมือแต่ละแบบจะรันได้เลย ต้องถามก่อน หรือห้ามรันเด็ดขาด สามระดับนี้เลือกใช้ต่างกันชัดเจน

• allow สำหรับงานที่ทำซ้ำวันละหลายสิบครั้งและย้อนกลับได้ เช่น npm run ที่สั่งรันคำสั่งประจำของโปรเจกต์ หรือ git commit ที่บันทึกการแก้โค้ดไว้ในเครื่องตัวเอง
• ask สำหรับงานที่อันตรายเป็นบางกรณี เช่น rm ที่ลบไฟล์ทิ้ง เหตุผลที่ไม่ตั้งเป็น deny ไปเลยก็เพราะจะเหลือไฟล์ค้างที่ควรลบไปนานแล้ว
• deny สำหรับงานที่พลาดแล้วกู้คืนยาก เช่น git push ที่ส่งโค้ดขึ้นเซิร์ฟเวอร์กลาง กฎข้อนี้แปลตรงตัวว่าห้ามแตะโค้ดฝั่งเซิร์ฟเวอร์เด็ดขาด

ใครไม่อยากแก้ไฟล์ JSON ด้วยมือ มีคำสั่ง /permissions ให้เพิ่มหรือดูกฎที่มีอยู่ได้ แต่ก็ยังต้องรู้ชื่อเครื่องมือกับรูปแบบการเขียนกฎอยู่ดี

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

กฎ deny หยุดโมเดลได้จริง ไม่ว่าจะรันด้วยโมเดลไหน

เดโมที่ชัดที่สุดในคลาสคือการตั้งกฎ deny ห้ามแก้ไฟล์ package.json แล้วสั่งให้ Claude เปลี่ยนเลขเวอร์ชันในไฟล์นั้นเป็น 2.1 งานง่ายแบบนี้ตั้งใจใช้ Haiku ซึ่งเป็นโมเดลตัวเล็กที่สุด แต่ Claude ก็ตอบว่าทำไม่ได้

จุดสำคัญไม่ได้อยู่ที่โมเดลตัวเล็กเชื่อฟังง่ายกว่า แต่อยู่ที่กฎนั้นไม่ได้อยู่ในตัวโมเดลตั้งแต่แรก มันอยู่ใน harness ซึ่งเป็นตัวรันเครื่องมือให้ โมเดลจะอยากแก้ไฟล์แค่ไหนก็ได้ แต่ตัวที่ลงมือรันคำสั่งจริงคือ harness และมันไม่ยอมรัน กฎ deny จึงมีผลเด็ดขาดเท่ากันหมด ไม่ว่าเบื้องหลังจะเป็น Haiku · Sonnet หรือ Opus

ข้อจำกัดที่ต้องพูดให้ครบคือ deny คุ้มครองเฉพาะสิ่งที่ตรงกับรูปแบบที่เราเขียนไว้ คำสั่งอันตรายที่มาในรูปแบบอื่นยังหลุดได้ กฎพวกนี้จึงช่วยลดความเสี่ยง แต่ป้องกันไม่ได้ทุกอย่าง

/fewer-permission-prompts ให้ Claude เสนอกฎจากพฤติกรรมจริง

ปัญหาของ permissions คือแทบไม่มีใครนั่งเขียนกฎล่วงหน้าตั้งแต่วันแรก คนส่วนใหญ่กดอนุญาตไปเรื่อยๆ จนถึงวันที่ทนไม่ไหว คำสั่ง /fewer-permission-prompts เกิดมาแก้ตรงจุดนี้พอดี

มันย้อนอ่านบันทึกเซสชันที่ผ่านมา หาว่าเรากดอนุญาตเครื่องมือตัวไหนซ้ำๆ แล้วเสนอกฎที่ควรเพิ่มเข้าไปใน settings ให้เอง ในเดโมมันเสนอกฎให้ MCP server ของ Linear ซึ่งเป็นตัวเชื่อมเครื่องมือติดตามงานของทีมเข้ากับ Claude รวมถึงคำสั่งตรวจชนิดข้อมูลที่ใช้อยู่เป็นประจำ โดยไม่มีใครสั่งให้ทำ

สิ่งที่ทำให้มันน่าไว้ใจคือมันเลือกไม่เสนอบางอย่าง แล้วบอกเหตุผลบนจอด้วยว่าทำไม เช่น ตัวนี้ Claude อนุญาตให้อัตโนมัติอยู่แล้ว ไม่ต้องเพิ่มกฎ หลักที่มันยึดคือถ้าไม่มั่นใจ ก็ไม่ต้องเพิ่มกฎนั้น ดีกว่าใส่ไว้ก่อนแล้วมาเสียใจทีหลัง

Skills คือไฟล์ markdown ที่เก็บขั้นตอนซ้ำๆ ไว้แทนเรา

skill คือไฟล์ SKILL.md ที่เขียนด้วย markdown หรือข้อความธรรมดาที่จัดหัวข้อได้ ข้างในเก็บขั้นตอนการทำงานเรื่องใดเรื่องหนึ่งเอาไว้ ลองนึกถึงสิ่งที่ต้องอธิบายให้ Claude ฟังใหม่ทุกครั้ง เช่น ขั้นตอน deploy หรือการส่งงานขึ้นระบบจริงของทีม วิธีต่อ API ตัวหนึ่ง หรือลูปถามตอบที่ใช้ประจำ เมื่อเขียนลงไฟล์ครั้งเดียวแล้วผูกไว้กับโปรเจกต์ Claude Code ก็หยิบไปใช้ได้เอง เรื่องนี้เคยอธิบายไว้แล้วใน Claude Code Skills สอน Claude ให้จำวิธีทำงานของทีมไว้ครั้งเดียว

ตัวช่วยที่มีมาให้ในตัวคือ skill-creator เพียงบอกสั้นๆ ว่าอยากได้ skill ที่ทำอะไร มันก็ร่างโครงไฟล์ให้ ในคลาส Lydia Hallie สาธิตด้วยการสร้าง skill สำหรับรีวิวโค้ดแบบง่ายๆ ขึ้นมาสดๆ

ส่วนหัวของไฟล์ยังตั้งค่าเพิ่มได้อีกหลายอย่างที่คนมองข้าม

• model: บังคับให้ skill นี้รันด้วยโมเดลที่เรากำหนด เช่น ให้ใช้ Sonnet ตลอด แม้เซสชันหลักจะรันบน Opus อยู่
• disable-model-invocation: true ล็อกให้เรียกใช้ได้เฉพาะตอนที่เราพิมพ์คำสั่งเองเท่านั้น โมเดลจะหยิบไปใช้เองไม่ได้
• user-invocable: false ทำงานตรงกันข้าม คือให้โมเดลเรียกได้ฝ่ายเดียว เราพิมพ์เรียกเองไม่ได้
• $ARGUMENTS รับค่าที่ส่งเข้ามาตอนเรียกใช้ เช่น เรียก skill deploy ว่า deploy staging แล้ว skill จะนำค่า staging ไปใช้ในขั้นตอนต่างๆ ภายใน

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

auto mode ทางสายกลางระหว่างถามทุกอย่างกับไม่ถามเลย

โหมดที่ถามก่อนทุกการกระทำฟังดูปลอดภัยที่สุด แต่ในทางปฏิบัติกลับใช้ไม่ได้จริง เพราะพอโดนถามเป็นร้อยครั้ง คนก็เลิกอ่านแล้วกดผ่านรวด อาการนี้มีชื่อเรียกว่า permission fatigue หรือความล้าจากการอนุญาต และมันอันตรายพอๆ กับการไม่ถามเลย เพราะสุดท้ายไม่มีใครตรวจอะไรจริงๆ

อีกทางเลือกที่มีมาก่อนคือปิดการถามทั้งหมด ซึ่งเร็วจริง แต่ถ้าวันหนึ่งมันลบไฟล์สำคัญของโปรเจกต์ทิ้ง ก็ไม่มีปุ่มย้อนกลับให้กด

auto mode อยู่กึ่งกลางระหว่าง deny list กับ allow list ทุกครั้งที่มี tool call ระบบจะเรียกตัวคัดกรองอีกตัวมาตรวจว่าอันตรายไหม ถ้าอันตรายก็เด้งมาถามเรา แต่ถ้าเป็นงานปกติอย่างอ่านหรือแก้ไฟล์ก็ปล่อยผ่าน เปิดใช้ด้วยการตั้งตัวแปรสภาพแวดล้อม CLAUDE_CODE_ENABLE_AUTO_MODE แล้วเปิด Claude ใหม่ จากนั้นสลับโหมดไปมาด้วย shift+tab ได้เลย

ข้อดีที่ Lydia Hallie ยกให้เป็นเรื่องที่นักพัฒนามองข้ามมากที่สุด คือมันทนต่อ prompt injection ได้ดีกว่า ซึ่งก็คือกรณีที่ข้อความแปลกปลอมแอบสั่งให้ Claude ทิ้งคำสั่งเดิมแล้วทำตามคำสั่งใหม่ ตัวคัดกรองจะจับเนื้อหาแบบนั้นได้ และมันยังดูบริบทเป็นด้วย เช่น คำสั่งลบทั้งโฟลเดอร์จะไม่นับว่าอันตราย ถ้าเราเป็นคนขอให้ลบโฟลเดอร์นั้นเองกับมือ

สามขั้นตอนแรกที่ลงมือได้วันนี้

แนวคิดที่อธิบายมานำไปใช้จริงได้ภายในสิบนาที ถ้าเริ่มจากสามขั้นนี้ตามลำดับ

1. เปิด /permissions แล้วใส่กฎสามข้อแรก ให้ npm run เป็น allow ให้ rm เป็น ask และให้ git push เป็น deny เท่านี้ก็ลดคำถามที่น่ารำคาญที่สุด พร้อมล็อกคำสั่งที่หากพลาดแล้วจะสร้างความเสียหายหนัก
2. ใช้งานตามปกติสองสามวัน แล้วพิมพ์ /fewer-permission-prompts ปล่อยให้มันอ่านประวัติการใช้ของเราเอง แล้วเสนอว่ากฎไหนควรเพิ่ม เราแค่ดูแล้วรับเฉพาะข้อที่เห็นด้วย
3. หยิบขั้นตอนที่ต้องอธิบายซ้ำทุกอาทิตย์มาหนึ่งอย่าง เช่น ขั้นตอนส่งงานขึ้นระบบที่ต้องรันเทสต์ก่อนแล้วค่อยรวมไฟล์ แล้วสั่ง skill-creator ให้ร่างเป็น SKILL.md ครั้งต่อไปเรียกด้วย deploy staging แล้วไม่ต้องอธิบายอะไรอีก

dynamic workflow ไฟล์ JavaScript ที่คุมทีม subagent

subagent คือ Claude Code อีกตัวที่แยกบริบทของตัวเองออกไป เหมาะกับงานเดี่ยวๆ ที่โฟกัสเรื่องเดียว ปัญหาคือถ้าปล่อยให้ Claude Code เรียก subagent เพิ่มเองตามใจชอบ ผลลัพธ์จะเดาไม่ได้ บางครั้งเรียกมาสี่ตัว บางครั้งไม่เรียกเลย อีกครั้งเรียกมาสิบตัว งานเดิมแท้ๆ แต่วิธีทำไม่เคยเหมือนเดิม

dynamic workflow แก้ปัญหานี้ด้วยการสร้างไฟล์ที่เราตรวจสอบได้ เราเพียงบอกเป็นภาษาคนตรงๆ ว่าให้ใช้ dynamic workflow กับงานนี้ แล้ว Claude Code จะเขียนไฟล์โปรแกรมภาษา JavaScript ขึ้นมาจริงๆ หนึ่งไฟล์ เพื่อกำหนดว่าจะใช้ subagent กี่ตัว ตัวไหนทำอะไร และเรียงลำดับยังไง เมื่อการควบคุมงานอยู่ในไฟล์ที่อ่านและแก้ได้ ความไม่แน่นอนก็หายไป

โครงของมันคือทำทีละเฟสตามลำดับ แต่ agent ที่สร้างงานอยู่ในเฟสเดียวกันทำงานพร้อมกันได้ ในเดโม Lydia Hallie สั่งรื้อเกมขึ้นมาใหม่ด้วย subagent ฝั่งสร้างสี่ตัวที่ทำงานพร้อมกัน คือทำระบบเกม ทำหน้าจอ ทำเสียง และทำด่านกับระบบสั่น จากนั้นค่อยทำเฟสรวมงาน เฟสรีวิว และเฟสตรวจสอบไล่ไปตามลำดับ ถ้าปล่อยให้ subagent ตัวเดียวไล่ทำสี่งานนี้ทีละชิ้น เวลาก็ยืดออกไปตามจำนวนงาน แต่พอสี่ตัวลงมือพร้อมกัน งานทั้งสี่ชิ้นจบในเวลาใกล้เคียงกับงานชิ้นเดียว นี่คือเหตุผลที่ workflow แบบนี้เหมาะกับงานใหญ่ที่กินเวลาหลายชั่วโมงหรือหลายวัน

เมื่อพอใจกับ workflow แล้ว กด s เพื่อบันทึกและตั้งชื่อไว้ ครั้งต่อไปมันจะกลายเป็นคำสั่งลัดที่เรียกซ้ำได้ทันที และเพราะมันเป็นแค่ไฟล์ JavaScript เราจึงเข้าไปเปลี่ยนโมเดลของ subagent แต่ละตัวในไฟล์ได้เอง อยากให้ตัวไหนใช้ Opus หรือตัวไหนใช้โมเดลที่เบากว่า ก็แก้บรรทัดนั้น ทุกครั้งที่เรียกคำสั่งนั้นอีก มันจะใช้ subagent ชุดเดิมและลำดับเดิมทุกประการ

intent-driven development บอกว่าอยากได้อะไร ไม่ใช่บอกวิธีทำ

แนวคิดนี้เห็นภาพชัดมากในรายการ The Agent Factory ของ Google Cloud Tech ตอนที่ YK Sugi เจ้าของช่อง CS Dojo สั่งสร้างเกมหนังสติ๊กสามมิติขึ้นมาสดๆ ด้วยเสียงพูด เขาเรียกวิธีทำงานแบบนี้ว่า intent-driven development หรือการทำงานที่ยึดเจตนาเป็นตัวตั้ง หัวใจของมันไม่ได้อยู่ที่ prompt วิเศษ แต่อยู่ที่การรู้ว่าตัวเองต้องการอะไรกันแน่ แล้วพูดออกมาให้ครบ

เขาพูดสเปกทั้งก้อนใส่ไมค์รวดเดียว หนังสติ๊กอยู่กับที่ กล้องไม่ขยับ ลากลูกบอลเพื่อกำหนดทิศซ้ายขวาบนล่าง กดค้างนานแค่ไหนคือกำหนดความลึก ยิ่งดึงไกลยิ่งยิงแรงตอนปล่อย ทำเป็นหน้าเว็บล้วนๆ จะหยิบชุดโค้ดสำเร็จรูปตัวไหนมาใช้ก็ได้ เหตุผลที่ใช้เสียงแทนการพิมพ์ก็ตรงไปตรงมา คือมันเร็วกว่ามาก และพูดผิดพูดใหม่ก็ไม่เป็นไร ตราบใดที่สื่อความต้องการออกไปได้ครบ

จังหวะที่น่าเรียนรู้ที่สุดคือลำดับของคำถาม เขาถามกว้างก่อนเสมอ ทั้งเรื่องโครงสร้างของโปรเจกต์ และชุดโค้ดสำเร็จรูปที่ควรหยิบมาใช้ ตอน Claude เสนอทางเลือกไลบรารีฟิสิกส์ หรือชุดโค้ดที่จำลองแรงและการชนให้ เขาปัดตัวเลือกที่ต้องเขียนฟิสิกส์เองทิ้ง แล้วเลือกคู่ที่ชื่อ Three.js กับ Rapier ซึ่งเป็นชุดโค้ดสำเร็จรูปฝั่งภาพสามมิติและฟิสิกส์ ด้วยเหตุผลของตัวเอง จากนั้นค่อยไล่เจาะรายละเอียดทีละชั้น

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

วางแผนด้วยภาพก่อน แล้วค่อยปล่อยให้ Claude ลงมือ

ครึ่งหลังของเดโมคือการอัปเกรดเกมตัวเดิมให้เป็นเกมที่เล่นได้จริง และจุดเริ่มไม่ใช่การพิมพ์สั่ง แต่เป็นการวางแผนด้วยภาพใน Claude Design เครื่องมือตัวใหม่ที่ยังอยู่ในขั้นทดลองและเปิดให้ใช้งานแล้ว อธิบายง่ายๆ ว่าเหมือน Claude Code แต่ทำงานฝั่งออกแบบ

สิ่งที่ได้ออกมาคือ wireframe หรือโครงหน้าจอแบบร่างที่เขียนเป็นไฟล์ HTML หรือไฟล์หน้าเว็บธรรมดา ข้างในมีครบตั้งแต่ลำดับการเล่น เมนูหลัก หน้าเลือกด่าน ลูปการเล่น หลอดเลือด ระบบเล็งและออกแรง ระบบสั่น คะแนน ไปจนถึงหลายด่าน ไฟล์นี้ส่งออกไปเข้าเครื่องมือออกแบบเจ้าอื่นก็ได้ แต่ Lydia Hallie เลือกเก็บไว้เป็น HTML แล้วแก้ไขข้อความในนั้นด้วยตัวเองก่อน จากนั้นส่งไฟล์เดียวนั้นให้ Claude ใช้เป็นสเปก พร้อมประโยคสั้นๆ ว่าอ่านไฟล์ออกแบบนี้ แล้วใช้ dynamic workflow รื้อเกมขึ้นมาใหม่ให้ตรงกับมัน

ผลที่ได้คือเกมหลายด่านที่มีเสียงประกอบ และหน้าตาตรงกับ wireframe แทบทุกจุด บทเรียนอยู่ตรงนี้ ภาพร่างที่แก้ได้คือสเปกที่ตรวจง่ายกว่าคำอธิบายยาวๆ เพราะมองปราดเดียวก็รู้ว่าตรงหรือไม่ตรง ขณะที่ย่อหน้าบรรยายสิบบรรทัดต้องอ่านทีละคำถึงจะจับผิดได้

90% ของงานอยู่ที่การตรวจ

ตอนเขียนโค้ดเอง การตรวจงานเกิดขึ้นระหว่างพิมพ์ไปแล้วราว 90% เพราะเราคิดไปตรวจไปโดยไม่รู้ตัว พอเปลี่ยนมาใช้ Claude Code สัดส่วนนี้กลับด้าน คือเราใช้เวลาและแรงราว 90% ไปกับการตรวจสิ่งที่มันเขียนมา เหลืออีกราว 10% เป็นการลงมือแก้เอง คนส่วนใหญ่ยังไม่ปรับวิธีคิดตาม ยังคงใช้ Claude Code แบบเดียวกับตอนเขียนโค้ดเอง แล้วก็ตรวจงานเท่าเดิม

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

ความเข้มงวดของการตรวจควรขึ้นอยู่กับความเสี่ยงของงาน เกมที่ทำเล่นสนุกส่วนตัวไม่ต้องรีวิวโค้ดก็ได้ แต่โค้ดทั้งโปรเจกต์ที่ขึ้นระบบจริงควรมีขั้นตอนแบบในเดโม คือ commit ลงเครื่อง แล้ว push ขึ้น branch ใหม่แทนที่จะ push เข้า branch หลักอย่าง main โดยตรง จากนั้นเปิด draft PR หรือคำขอรวมโค้ดแบบร่างบน GitHub ที่เก็บโค้ดของทีมเอาไว้ ด้วย GitHub CLI ซึ่งสั่งงาน GitHub ได้จากหน้าจอคำสั่งเลย แล้วให้คนหรือ AI อีกตัวรีวิวก่อนรวมเข้าจริง

ประโยคที่ควรจำที่สุดมาจาก YK Sugi คือเราเป็นคนรับผิดชอบผลลัพธ์ ต่อให้มันสร้างโค้ดมาแสนบรรทัด เราก็ไม่จำเป็นต้อง commit ทั้งแสนบรรทัด ข้อสังเกตนี้ตรงกับทิปข้อ 38 ใน Claude Code Tips คลังทิปของเขาเอง ที่ว่าโมเดลสร้างโค้ดมักเขียนเกินความจำเป็น ทางแก้ไม่ใช่การจ้ำจี้จ้ำไชทุกบรรทัด แต่คือการคุมสามอย่างให้อยู่ ทั้งคุณภาพของโค้ด ความถูกต้องของผลลัพธ์ และที่สำคัญที่สุดคือสิ่งที่เรายอมให้รวมอยู่ในโค้ดจริง

งานของวิศวกรเปลี่ยนจากการเขียนโค้ดเป็นการกำกับภาพรวม

สิ่งที่เปลี่ยนไปไม่ใช่ว่าความรู้ทางเทคนิคหมดความหมาย แต่เรานำความรู้นั้นไปใช้กับงานอีกแบบ ทุกวันนี้วิศวกรเขียนโค้ดด้วยภาษาระดับสูงอย่าง TypeScript หรือ JavaScript โดยไม่ต้องสนใจภาษาเครื่องที่โค้ดจะแปลงไปเป็นในตอนท้ายอยู่แล้ว ตอนนี้งานกำลังเปลี่ยนไปในทำนองเดียวกัน จากการเขียนโค้ดทีละบรรทัด มาเป็นการสั่งงานและตรวจงาน

งานจริงที่เหลืออยู่คือการออกแบบสถาปัตยกรรม การเข้าใจว่าทำไมฟีเจอร์นี้ต้องมีอยู่ และการสร้างสภาพแวดล้อมที่ดีให้ Claude ทำงาน ไม่ว่าจะเป็นไฟล์ CLAUDE.md ที่บอกธรรมเนียมของโปรเจกต์ หรือกฎ permissions ที่กันคำสั่งเสี่ยงเอาไว้ ทั้งหมดนี้ยังต้องอาศัยความรู้ลึกเหมือนเดิม บวกกับรสนิยมที่ดีและความกล้าตัดสินใจ

พูดอีกแบบคือวิศวกรกำลังรับบทเป็นเจ้าของงานมากขึ้น เป็นคนที่รู้ว่าอะไรควรมีอยู่ในระบบและอะไรไม่ควรมี ซึ่งเป็นทักษะที่ AI ยังทำแทนไม่ได้ และจะพัฒนาขึ้นทุกครั้งที่เราตั้งใจรีวิวงาน

Claude Code ไม่ได้มีไว้เขียนโค้ดอย่างเดียว

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

ตัวอย่างที่เห็นภาพที่สุดเกิดขึ้นตอน YK Sugi กำลังซื้ออสังหาริมทรัพย์ แทนที่จะนั่งหาข้อมูลนายหน้าทีละเจ้า เขาให้ Claude Code รวบรวมรายชื่อนายหน้าพร้อมอีเมลไว้ในชุดข้อมูลที่คั่นแต่ละรายการด้วยจุลภาค จากนั้นให้ส่งอีเมลหานายหน้าทั้งหมดเอง เขาประเมินว่าวิธีนี้ประหยัดเงินไปราว 10,000 ดอลลาร์

ฝั่ง Anthropic เองก็เห็นสัญญาณนี้ตั้งแต่ปลายปีก่อน ตอนพบว่าทีมที่ไม่ใช่วิศวกรอย่างการตลาดและทีมข้อมูลก็ใช้ Claude Code ทำงานกันอยู่แล้ว จึงทำแอปบนเดสก์ท็อปชื่อ Cowork ขึ้นมาภายในเวลาราวหนึ่งสัปดาห์ ข้างในยังใช้ Claude Code ทำงานอยู่เบื้องหลังเหมือนเดิม แต่เปลี่ยนตัวเชื่อมต่อและ system prompt ให้เข้ากับงานที่ไม่ใช่โค้ด อย่างอีเมล ปฏิทิน หรือการจองตั๋วเครื่องบิน หลักการเลือกใช้ก็ง่าย งานสายเทคนิคใช้ Claude Code ส่วนงานที่ไม่ใช่เทคนิค Cowork ทำได้ดีกว่า

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

ความจำของ Claude Code จึงอยู่ในไฟล์ที่เราเขียนไว้ให้มันอ่านใหม่ทุกเทิร์น และไฟล์เหล่านั้นจะดีขึ้นก็ต่อเมื่อเราตั้งใจดูแล

---

ที่มา:

• คลิป Intent-driven development with Claude Code & Fable 5 จากช่อง The Agent Factory (Google Cloud Tech)
• คลิป Claude Code — Lydia Hallie (Anthropic) จากช่อง Frontend Masters