Matt Pocock ครูสอน TypeScript และผู้ก่อตั้ง aihero.dev มีมุมมองที่น่าสนใจและสวนทางกับกระแสหลัก เขามองว่าคนที่รีดพลังจาก AI ได้คุ้มค่าที่สุดไม่ใช่คนที่คอยวิ่งไล่ตามโมเดลตัวใหม่ล่าสุดทุกสัปดาห์ แต่คือคนที่วางสถาปัตยกรรมระบบได้ขาดมาตั้งแต่แรก เพราะผลลัพธ์ของ AI จะดีได้แค่ไหนขึ้นอยู่กับว่าคนคุมเกมแตกโจทย์ วางโครงสร้าง และตรวจงานเป็นไหม เขาสรุปไว้สั้นๆ ว่า "ฝีมือของเราคือเพดานของสิ่งที่ AI ทำได้" ถ้าคนสั่งยังมีพื้นฐานไม่แน่น AI ก็พาโปรเจกต์ไปได้ไม่ไกลกว่านั้น

แนวคิดนี้กลับทิศสิ่งที่คนส่วนใหญ่กำลังโฟกัส หลายคนมัวแต่รอคอยว่าโมเดลรุ่นต่อไปจะเก่งขึ้นกี่เปอร์เซ็นต์ ทั้งที่ในความเป็นจริง คุณภาพของ codebase และทักษะการซอยงานต่างหากที่เป็นตัวชี้ขาดว่างานจะออกมาเวิร์กหรือพัง บทความนี้สรุปวิธีคิดและเวิร์กโฟลว์จริงของ Matt Pocock เพื่อให้เรานำไปปรับใช้กับการเขียนโค้ดร่วมกับ AI agent ได้ทันที

งานที่ AI ทำแทนได้ กับงานที่ยังต้องเป็นเรา

วิธีคิดนี้ต่อยอดมาจากหนังสือ A Philosophy of Software Design ของ John Ousterhout ซึ่งแบ่งการเขียนโปรแกรมออกเป็นสองมิติหลัก มิติแรกคือ tactical หรือการลงมือพิมพ์โค้ดแก้โจทย์เฉพาะหน้าให้ฟีเจอร์ทำงานได้ มิติที่สองคือ strategic ซึ่งเน้นการออกแบบสถาปัตยกรรม วางอินเทอร์เฟซระหว่างแต่ละโมดูล แบ่งงานใหญ่ให้เป็นชิ้นย่อยที่ชัดเจน และดูแลให้ระบบขยายหรือแก้ต่อได้ง่ายในระยะยาว

ทุกวันนี้ AI กลืนงานฝั่ง tactical ไปเกือบหมดแล้ว การนั่งไล่เขียนโค้ดทีละบรรทัดเพื่อให้ฟังก์ชันทำงานได้กลายเป็นเรื่องที่ส่งต่อให้ AI ทำแทนได้เกือบ 100% คุณค่าที่เหลืออยู่ของคนจึงอยู่ที่งาน strategic แทบทั้งหมด Matt Pocock จึงแนะนำให้เราเลิกมองตัวเองเป็นแค่ "คนพิมพ์โค้ด" แล้วยกระดับมาเป็น "ผู้วางสถาปัตยกรรม" โดยมอง AI เป็นเหมือนทีมช่างฝีมือดี เรามีหน้าที่วางพิมพ์เขียวและตัดแบ่งโจทย์ ส่วน AI มีหน้าที่ลงมือก่อสร้าง

นี่คือเหตุผลที่วิศวกรระดับ senior มักใช้ AI แล้วได้ผลผลิตเพิ่มขึ้นมหาศาล Matt Pocock ประเมินจากการแลกเปลี่ยนกับ CTO หลายคนว่า senior อาจรีดผลงานจาก AI ได้เพิ่มขึ้นถึง 10 เท่า ในขณะที่มือใหม่อาจได้ประโยชน์น้อยกว่านั้นมาก ไม่ใช่เพราะ senior พิมพ์พรอมต์เก่งกว่า แต่เป็นเพราะเขารู้วิธีแบ่งงาน รู้ว่าโครงสร้างแบบไหนดี และมองทะลุตั้งแต่เห็นโค้ดแวบแรกว่าท่าที่ AI เสนอมาจะสร้าง technical debt หรือปัญหาในอนาคตหรือไม่

รถแข่งไม่ได้มีแค่เครื่องยนต์

ถ้าโมเดลไม่ใช่ทุกอย่าง แล้วอะไรคือตัวตัดสินผลงาน Matt Pocock เปรียบเทียบกับรถแข่ง Formula 1 ว่าคนทั่วไปมักจ้องแต่เครื่องยนต์ (ซึ่งก็คือตัวโมเดล AI) ทั้งที่จริงแล้ว แอโรไดนามิก ตัวถัง และระบบควบคุมรอบคันก็สำคัญไม่แพ้กัน ในโลกของการเขียนโค้ด องค์ประกอบรอบข้างเหล่านี้คือสิ่งที่เขาเรียกว่า harness ตั้งแต่ prompt, skills ที่เตรียมไว้, เครื่องมือเชื่อมต่อ ไปจนถึงความสะอาดของ codebase เอง เขาให้น้ำหนักระหว่างตัวโมเดลกับ harness พอๆ กันแบบ 50:50

มุมมองนี้ต่างจากแนวคิด The Bitter Lesson ในแวดวง machine learning ที่เชื่อว่าในระยะยาวพลังการประมวลผลดิบของฮาร์ดแวร์และโมเดลจะเอาชนะการปรับแต่งเฉพาะทางเสมอ Matt Pocock เข้าใจข้อโต้แย้งนี้ดี แต่เขาเลือกที่จะพัฒนา harness ควบคู่ไปด้วย เพราะ harness คือสิ่งที่เราลงมือควบคุมและสร้างความได้เปรียบได้ทันทีในวันนี้ โดยไม่ต้องรอโมเดลรุ่นถัดไป

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

Matt Pocock ยังเสนอมุมมองใหม่เคียงคู่กับ DX (Developer Experience หรือความสะดวกของนักพัฒนา) นั่นคือ AX (Agent Experience) ซึ่งหมายถึงทุกอย่างที่ช่วยให้ AI agent ทำงานกับโค้ดของเราได้ราบรื่นที่สุด ทั้ง skills ที่เป็นระเบียบ harness ที่รัดกุม และสถาปัตยกรรมที่ไม่ซับซ้อนเกินจำเป็น ข่าวดีคือสิ่งที่ทำให้คนทำงานง่าย มักช่วยให้ AI ทำงานง่ายขึ้นด้วยเช่นกัน การปรับปรุง codebase จึงให้ผลลัพธ์คุ้มค่าสองต่อเสมอ

ดัน Output ให้พุ่งด้วยการทำงานแบบ AFK

จุดที่พลิกปริมาณงานได้มากที่สุดคือการปล่อยให้ AI ทำงานในตอนที่เราไม่ได้นั่งเฝ้าหน้าจอ หรือ AFK (Away From Keyboard) แทนที่จะนั่งแชตกับ AI ทีละข้อความแล้วคอยตรวจคำตอบแบบเรียลไทม์ Matt Pocock เลือกซอยงานที่มีขอบเขตชัดเจนออกเป็นชิ้นๆ แล้วสั่งให้ agent หลายตัวแยกย้ายกันไปทำในเบื้องหลังพร้อมกัน ในเวิร์กโฟลว์นี้ คนทำงานทำหน้าที่เป็นผู้จัดการคนเดียวที่คุม agent หลายตัวทำงานคู่ขนาน

หลายคนมักติดภาพคำว่า "agentic loop" เป็นลูปวิเศษตัวเดียวที่วนคิดและลงมือทำทุกอย่างเองตั้งแต่ต้นจนจบ แต่ Matt Pocock มองว่าภาพที่ตรงกับการทำงานจริงมากกว่าคือ คิวงาน (Queue) งานทั้งหมดจะถูกจัดเป็นคิวสิ่งที่ต้องทำ จากนั้นมี agent หลายตัวคอยหยิบงานออกจากคิวไปประมวลผลพร้อมๆ กัน เหมือนทีมพัฒนาซอฟต์แวร์จริงที่แต่ละคนหยิบงานของตัวเองไปทำคู่ขนานกัน

เวิร์กโฟลว์จริงของเขาใช้ GitHub Issues เป็นคิวกลาง แล้วเดินงานตามลำดับนี้

1. มีบั๊กหรือฟีเจอร์ใหม่เข้ามาเป็น GitHub Issue หนึ่งใบ
2. คนติดป้ายกำกับ "explore" ให้ issue นั้น
3. AFK agent หยิบไปสำรวจว่าโค้ดส่วนไหนต้องแก้ มีผลกระทบอะไรบ้าง แล้วสรุปข้อมูลกลับมาเป็นระเบียบ
4. คนอ่านผลการสำรวจ ถ้าแนวทางถูกต้องก็ติดป้าย "agent implement"
5. Agent ลงมือเขียนโค้ดจริงผ่าน GitHub Actions แล้วเปิด Pull Request (PR) ขึ้นมาอัตโนมัติ
6. คนเข้ามาตรวจรีวิว PR แล้วกด merge เข้าโปรเจกต์

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

เครื่องมือที่ทำให้การรันแบบ AFK ปลอดภัยคือ Sand Castle ซึ่งเป็นระบบที่ Matt Pocock พัฒนาขึ้นมาเพื่อรัน Claude Code ให้อยู่ใน sandbox แยกขาดอย่าง Docker หรือ Podman รันได้ทั้งบนเครื่องส่วนตัวหรือคลาวด์ เหตุผลที่ต้องมี sandbox นั้นชัดเจนมาก เพราะ agent ที่ทำงานโดยไม่มีขอบเขตจำกัดอาจเผลอลบไฟล์สำคัญหรือส่งข้อมูลลับในเครื่องออกไปข้างนอก การตีกรอบให้อยู่ใน sandbox จึงเป็นเงื่อนไขแรกสุดก่อนจะปล่อยให้ AI ทำงานลำพัง

Skills คือ Harness ที่เราปรับแต่งได้เอง

ส่วนที่เรานำไปปรับใช้ได้ทันทีคือ skills หรือชุดคำสั่งและความสามารถเฉพาะทางที่เราติดตั้งให้ AI Matt Pocock แบ่ง skills ออกเป็นสองประเภท

• procedure คือสกิลที่คนเป็นคนสั่งเรียกใช้เอง เหมาะกับงานที่เราต้องการควบคุมขั้นตอนและจังหวะเวลาอย่างเคร่งครัด
• ability คือสกิลที่โมเดลตัดสินใจเรียกใช้เองได้ตามสถานการณ์ ข้อควรระวังคือคำอธิบายของ ability จะกิน context window ของ AI ตลอดเวลา ยิ่งใส่เยอะ context ยิ่งเต็มเร็ว

ข้อแนะนำในการเลือกใช้คือ ถ้าอยากคุมทิศทางให้แม่นยำและประหยัด context ให้เน้นใช้ procedure เป็นหลัก เก็บ ability ไว้เฉพาะฟังก์ชันที่จำเป็นต้องให้ AI ตัดสินใจเองจริงๆ และหากมีสกิลไหนที่ไม่ต้องการให้ระบบโหลดคำอธิบายมาเปลือง context ตลอดเวลา ก็สามารถปิดการประกาศตัวอัตโนมัติได้ เช่น สกิล engineering zoom out ที่เขาตั้งค่าให้เรียกเฉพาะตอนจำเป็น

วิธีเริ่มต้นสร้าง harness ที่เขาแนะนำคือ ล้างกระดานให้เหลือศูนย์ก่อนเสมอ

1. ลบ skills, plugin, MCP server, ไฟล์ CLAUDE.md และ agents.md ออกทั้งหมด เพื่อให้เหลือแค่ตัว agent เปล่าๆ
2. ลองสั่งงานดูเพื่อทำความเข้าใจว่าตัวโมเดลเพียวๆ มีความสามารถและข้อจำกัดตรงไหนบ้าง
3. ทยอยใส่ของกลับเข้ามาทีละชิ้น โดยเริ่มจาก skills แบบ procedure ที่เราเข้าใจการทำงานอย่างถ่องแท้

การเริ่มจากศูนย์ช่วยให้เรารู้ชัดเจนว่าเครื่องมือแต่ละชิ้นช่วยแก้ปัญหาจริง หรือแค่เข้ามาทำให้ context รก เมื่อเข้าใจระบบแล้วค่อยหยิบ skills สำเร็จรูปมาปรับแต่ง เช่น ชุด skills ของ Matt Pocock ที่เปิดให้ใช้งานบน GitHub โดยติดตั้งผ่านคำสั่ง npx skills latest add matt-skills ซึ่งรองรับทั้ง Claude Code และ Codex

ตัวอย่างสกิลที่น่าสนใจคือ teach ซึ่งออกแบบมาเพื่อสอนเขียนโปรแกรมอย่างต่อเนื่องและจดจำพัฒนาการของผู้เรียน เมื่อเรียกใช้ สกิลจะถามสามคำถามเพื่อตั้งหลัก ได้แก่ เป้าหมายของเราคืออะไร กำลังทำโปรเจกต์ไหน และนิยามคำว่า "ทำซอฟต์แวร์ให้ดีขึ้น" สำหรับเราคืออะไร จากนั้นจะบันทึกเป้าหมายลงไฟล์ mission.md และสร้างบทเรียนในรูปแบบไฟล์ HTML พร้อมแบบฝึกหัด คำถามทบทวน และลิงก์อ่านต่อ เมื่อกลับมาเรียนใหม่อีกครั้ง ระบบจะดึงความคืบหน้าเดิมมาสอนต่อได้ทันที

ต้นทุนที่ต้องจ่าย และสิ่งที่ AI ยังทำแทนไม่ได้

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

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

บทเรียนสำคัญจาก Matt Pocock คือสิ่งที่กำหนดผลงานของเราไม่ใช่โมเดลรุ่นใหม่ล่าสุด แต่คือรากฐานทางวิศวกรรมซอฟต์แวร์ที่มีมานาน ทั้งการออกแบบระบบที่ดี การแบ่งขอบเขตงานให้ชัดเจน และการดูแลรักษาโค้ดให้แก้ได้ง่าย ยิ่ง AI ฉลาดและทำงานได้เร็วขึ้นเท่าไร ทักษะทางสถาปัตยกรรมของคนสั่งก็ยิ่งเป็นตัวกำหนดว่าผลงานจะไปได้ไกลแค่ไหน

---

ที่มา: คลิป Matt Pocock's Agentic Engineering Workflow (just copy him) จากช่อง David Ondrej