ทิปใช้ Coding Agent จาก Thorsten Ball: โมเดลที่ดีที่สุด สั่งที่ผลลัพธ์ และอย่าให้ agent ทำงานในที่มืด

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

ช่วงนี้ใน X มีหัวข้อที่ขึ้น trending เรื่องทิปการใช้ coding agent ของ Thorsten Ball ซึ่งทำ Amp และเขียน newsletter ชื่อ Register Spill ผมเลยตามไปอ่านต้นฉบับ ไม่ใช่แค่โพสต์สรุป เพราะโพสต์สรุปหลายอันที่ผมเจอเล่าไม่ตรงกันในรายละเอียด

โพสต์นี้อยู่ในซีรีส์ Critical Thinking ครับ ต่อจากเรื่อง Cursor Agent SDK ที่พูดถึงการดูแล agent แบบดูแลโค้ด คราวนี้ถอยกลับมาที่เรื่องพื้นฐานกว่านั้น คือคนที่สั่งงาน agent ทุกวันควรทำงานกับมันยังไง

จุดยืนของผมสั้น ๆ คือ ทิปทั้งสามข้อไม่ได้เป็นเรื่องเทคนิค prompt แต่เป็นเรื่องที่ PM กับ PO รู้กันมานานแล้ว คือจ้างคนเก่ง บอกเป้าหมายให้ชัด และอย่าเชื่อคำว่า "เสร็จแล้ว" โดยไม่มีหลักฐาน

ต้นฉบับคืออะไร และผมอ่านจากไหน

ต้นฉบับคือ X article ชื่อ "How I work with Agents" ของ Thorsten Ball ซึ่งเขาระบุว่าเป็นวิธีทำงาน ณ เดือนตุลาคม 2026 ตัวหน้า X ผมเปิดอ่านผ่านเครื่องมือไม่ได้ เลยอ่านผ่านฉบับที่มีคนเก็บไว้บน GitHub ซึ่งมีข้อความภาษาอังกฤษต้นฉบับสลับกับคำแปลภาษาจีน ใครจะอ้างถ้อยคำเป๊ะ ๆ แนะนำให้เปิดต้นฉบับบน X เทียบอีกทีครับ

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

1. ใช้โมเดลที่ดีที่สุดที่มี

หัวข้อแรกของเขาคือ "Use the latest and greatest models." ตรง ๆ แบบนั้นเลยครับ เหตุผลที่เขาให้ ผมสรุปเป็นคำของผมเองได้ว่า ถ้าโมเดลผิดสักสิบเปอร์เซ็นต์ของงาน ปัญหาไม่ได้อยู่ที่สิบเปอร์เซ็นต์นั้น แต่อยู่ที่เราไม่รู้ล่วงหน้าว่างานไหนคือสิบเปอร์เซ็นต์ที่ผิด สุดท้ายก็ต้องลองซ้ำหลายรอบและตรวจทุกอย่าง เขาเลยมองว่าการใช้โมเดลที่รองลงมามีแนวโน้มจะเสียเวลามากกว่าที่ประหยัดได้

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

แต่มีสองเรื่องที่ผมจะไม่ข้ามไปครับ

• "ดีที่สุด" เปลี่ยนเร็วมาก อย่าเอาชื่อโมเดลจากโพสต์ไหน (รวมถึงโพสต์นี้) ไปตั้งเป็นมาตรฐานทีม ให้ตั้งเป็นหลักการว่า "งานที่ตรวจยากใช้รุ่นท็อปเสมอ" แล้วทบทวนเป็นระยะ
• ผมไม่มีตัวเลขค่าใช้จ่ายมาให้ ต้นฉบับไม่ได้ให้ตัวเลขเรื่องนี้ และค่าใช้จ่ายของแต่ละทีมขึ้นกับปริมาณงานจริง ถ้าทีมไหนงบจำกัด ผมว่าวิธีที่สมเหตุสมผลคือลองวัดเองสักสองสามสัปดาห์ ว่ารุ่นท็อปกับรุ่นรองต่างกันแค่ไหนทั้งในเรื่องค่าใช้จ่ายและจำนวนรอบที่ต้องสั่งใหม่ ไม่ใช่เดา

2. สั่งที่ "อะไร" ไม่ใช่ "ยังไง"

หัวข้อที่สามคือ "Prompt the What, not the How." ใจความคือให้บอกว่าอยากได้อะไร ไม่ใช่บอกว่าเราจะทำมันยังไง ตัวอย่างในต้นฉบับมีทั้งการบอกว่าสุดท้ายระบบควรทำงานแบบไหน และการตั้งเป้าที่มีจุดหยุดชัดเจน เช่น "Do not stop until it's 2x faster."

ตัวอย่างหลังนี่แหละที่ผมว่าสำคัญครับ เพราะมันมีครบสามอย่างในประโยคเดียว คือ เป้าหมาย (เร็วขึ้น) ตัวเลขที่วัดได้ (2 เท่า) และเงื่อนไขว่าเมื่อไหร่ถือว่าเสร็จ

สำหรับคนที่เป็น PO นี่คือเรื่องเดียวกับการเขียน acceptance criteria ที่ผมเคยเขียนไว้ในยุค agent = คุณต้องเขียน AC เหมือน PO ต้นฉบับไม่ได้ใช้คำว่า "definition of done" นะครับ ส่วนนี้เป็นการตีความของผมเอง แต่ผมว่ามันคือแก่นเดียวกัน

ลองเทียบให้เห็นภาพครับ สมมติว่าหน้ารายงานในระบบหลังบ้านโหลดช้า

แบบสั่ง "ยังไง"

เปิด ReportService แล้วเพิ่ม cache ให้ฟังก์ชัน getMonthlySummary ใช้ Redis TTL 5 นาที แล้วแก้ controller ให้เรียกตัวใหม่

แบบสั่ง "อะไร"

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

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

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

3. อย่าให้ agent ทำงานในที่มืด

หัวข้อที่ผมชอบที่สุดคือข้อสี่ "Make the whole SDLC legible to the agent." ซึ่งมีประโยคที่คนแชร์กันเยอะว่า "If the agent can't see something, it makes it up." คือถ้า agent มองไม่เห็นอะไร มันจะเติมช่องว่างนั้นเอง เขาจึงอยากให้ agent เห็นสิ่งที่คนเห็น ตั้งแต่รันของที่มันสร้างแบบ end-to-end อ่าน log ไปจนถึงงาน deploy

ตรงนี้ผมอยากชี้ให้ชัดครับ เพราะเวลาคนพูดว่า "visibility" ในเรื่องนี้ มันมีสองทิศทางที่มักถูกพูดรวมกัน

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

แต่ต้องระวังเรื่องสิทธิ์ด้วยครับ การให้ agent อ่าน log production หรือ deploy เองได้ คือการให้สิทธิ์จริงกับระบบจริง สำหรับทีม junior ผมจะเริ่มจากสิทธิ์อ่านใน environment ที่ไม่ใช่ production ก่อน และไม่ให้สิทธิ์เขียนกับอะไรที่ย้อนกลับไม่ได้ ใครสนใจมุมนี้ ผมเขียนไว้ในบทความ OWASP สำหรับ agentic app

ทิศทางที่สอง: เราเห็นว่า agent ทำอะไร ข้อนี้ต้นฉบับพูดผ่านหัวข้อที่เก้า "Ask for irrefutable proof." คือขอหลักฐานที่ปฏิเสธไม่ได้ เช่น walkthrough แบบ end-to-end วิดีโอเดโม หรือตัวเลขก่อนและหลัง เขายังแนะนำให้เขียนลงใน AGENTS.md ไว้ด้วยว่าอะไรบ้างที่ "ไม่นับเป็นหลักฐาน"

ผมว่าข้อนี้คือของจริงสำหรับคนที่ไม่มีเวลานั่งเฝ้าครับ เราไม่จำเป็นต้องดูทุกขั้นตอนที่ agent ทำ แต่ต้องมีหลักฐานตอนจบที่เช็คได้ในไม่กี่นาที คำว่า "เสร็จแล้วครับ เทสต์ผ่านหมด" ไม่ใช่หลักฐาน แต่ "นี่คือ output ของเทสต์ที่รัน นี่คือตัวเลข benchmark ก่อนและหลัง และนี่คือสิ่งที่ยังไม่ได้ทดสอบ" คือหลักฐาน เรื่องนี้ต่อเนื่องกับนิสัยการ verify ที่ผมเขียนไว้ก่อนหน้า

ข้ออื่นที่น่าสังเกต แต่ผมยังไม่รีบเอามาใช้

ใน 15 ข้อมีอีกหลายข้อที่น่าสนใจ เช่น "Don't wait for your agents. Let them wait on you." ที่บอกให้ทำงานแบบ async มอบงานก้อนใหญ่ขึ้นแทนการคุยตอบกลับไปมา และ "Review only code with high blast radius." ที่เขาบอกว่ารีวิวเฉพาะไฟล์ที่เป็นแกนกลางไม่กี่ไฟล์กับ database migration

ข้อ async ผมว่าเอามาใช้ได้เลยครับ แต่ข้อรีวิวผมจะระวังมาก บริบทของเขาคือคนที่มีประสบการณ์สูงและรู้ว่าไฟล์ไหนอันตราย ทีม junior ยังแยกไม่ออกว่าอะไรคือ high blast radius ถ้าเอาไปใช้ตรง ๆ ก็เท่ากับเลิกรีวิวโดยไม่รู้ว่ากำลังเสี่ยงอะไร สำหรับทีมผม ข้อนี้ต้องเริ่มจากการตกลงกันให้ได้ก่อนว่าไฟล์ไหนบ้างที่ต้องรีวิวเสมอ แล้วเขียนเป็นลิสต์ไว้

เทมเพลต prompt แบบ outcome-focused

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

เป้าหมาย:
[ผลลัพธ์ที่ต้องการ ในมุมผู้ใช้หรือธุรกิจ ไม่ใช่วิธีทำ]

เสร็จเมื่อ:
- [เงื่อนไขที่วัดได้ เช่น ตัวเลข เทสต์ที่ต้องผ่าน พฤติกรรมที่ต้องเห็น]
- [เงื่อนไขหยุด: ถ้าทำไม่ได้ ให้หยุดและรายงานว่าติดตรงไหน]

ห้ามเปลี่ยน:
- [API, schema, ไฟล์ หรือพฤติกรรมที่ต้องคงเดิม]

สิ่งที่คุณเข้าถึงได้:
- [คำสั่งรันเทสต์ วิธีเปิดแอป log ที่อ่านได้ ข้อมูลตัวอย่าง]

หลักฐานที่ต้องส่งกลับมา:
- [output ของเทสต์จริง ตัวเลขก่อน/หลัง ภาพหน้าจอ หรือขั้นตอนทดสอบซ้ำ]
- [สิ่งที่ยังไม่ได้ทดสอบหรือไม่แน่ใจ]

และ checklist สั้น ๆ ที่ผมจะใช้เช็คก่อนส่งงานให้ agent

• งานนี้ตรวจยาก หรือผิดแล้วแพงไหม ถ้าใช่ ใช้โมเดลรุ่นท็อป
• prompt บอก "อะไร" และ "เสร็จเมื่อไหร่" โดยไม่ล็อก "ยังไง" ไว้เกินจำเป็น
• มีเงื่อนไขหยุด ไม่ใช่ปล่อยให้ agent ลองไปเรื่อย ๆ
• เขียนชัดว่าอะไรห้ามแตะ
• agent รันเทสต์ เปิดแอป หรืออ่าน error ที่เกี่ยวข้องเองได้
• สิทธิ์ที่ให้ไม่เกินที่งานนี้ต้องใช้
• รู้ล่วงหน้าว่าจะขอหลักฐานอะไร และอะไรที่ไม่นับเป็นหลักฐาน

ถ้าผมจะเริ่มใช้กับทีม

ส่วนนี้คือแผนที่ผมคิดไว้นะครับ ไม่ใช่สิ่งที่ทำเสร็จแล้ว

ถ้าทีมผมจะลอง ผมจะไม่เริ่มจากการสอนเทคนิค prompt แต่จะเริ่มจากการให้แต่ละทีมเอางานที่เคยสั่ง agent ไปแล้วมาเขียนใหม่ตามเทมเพลตด้านบน แล้วดูว่าช่องไหนที่เขียนไม่ออก ผมเดาว่าช่องที่เขียนยากที่สุดจะเป็น "เสร็จเมื่อ" กับ "หลักฐานที่ต้องส่งกลับมา" และถ้าเป็นอย่างนั้นจริง ปัญหาก็ไม่ได้อยู่ที่ agent แต่อยู่ที่เรายังไม่รู้ชัดว่าอยากได้อะไร

ต่อมาคือการใส่ข้อตกลงเรื่องหลักฐานลงใน AGENTS.md ของแต่ละโปรเจกต์ เพื่อให้ทุกคนที่สั่งงาน agent ได้มาตรฐานเดียวกัน ไม่ต้องพึ่งว่าใครเขียน prompt เก่งกว่ากัน

ท้ายที่สุด

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

ซึ่งสำหรับ PM กับ PO นี่ไม่ใช่ทักษะใหม่เลยครับ มันคือสิ่งที่เราทำกับคนในทีมอยู่แล้ว แค่ agent ทำให้ผลของการสั่งงานแบบคลุมเครือย้อนกลับมาหาเราเร็วกว่าเดิม

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