เวิร์กโฟลว์ใช้ AI เขียนโค้ดของ Matt Pocock · คนที่ได้ 10 เท่าจาก AI ไม่ใช่คนที่ไล่ตามโมเดลใหม่

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 ทำแทนได้ ส่วนที่เหลือเป็นคุณค่าของคนคืองาน strategic ทั้งหมด นั่นแปลว่าวิธีมองตัวเองที่ Matt Pocock เสนอคือ เลิกมองตัวเองเป็นคนเขียนโค้ด แล้วมองตัวเองเป็นคนวางสถาปัตยกรรม โดยมี AI เหมือนทีมช่างคอยรับงานไปทำ เราออกแบบและตัดโจทย์ ส่วน AI ลงมือ

AI เก่งขึ้นแค่ไหนไม่สำคัญเท่ากับว่าคนสั่งวางโจทย์และตรวจงานเป็นหรือเปล่า

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

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

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

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

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

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

ของจริงที่ทำให้ output พุ่งคือ AFK ไม่ใช่ลูป

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

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

เวิร์กโฟลว์จริงของเขาวางบน GitHub Issues ซึ่งเป็นระบบเปิดใบงานในที่เก็บโค้ดบน GitHub โดยใช้มันเป็นคิวงาน แล้วเดินเป็นขั้นแบบนี้

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

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

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

skills คือ harness ที่เราปรับเองได้

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

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

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

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

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

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

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

ราคาของวิธีนี้ และสิ่งที่ AI ยังแทนไม่ได้

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

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

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

---

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