เลิกจ่ายราคา Frontier ให้งานระดับ Executor

ทีมส่วนใหญ่ที่เริ่มใช้ AI coding agent มักพลาดเรื่องเดียวกัน คือมองว่า "เลือกโมเดล" เป็นการตัดสินใจครั้งเดียวจบ — เลือกตัวที่ฉลาดที่สุด โยนงานทุกอย่างให้มัน แล้วก็นั่งดูบิล token พุ่ง

แบบนั้นไม่ใช่ architecture ครับ มันคือการจ้าง principal engineer มาทั้งทีม แล้วให้คนเงินเดือนแพงสุดนั่งแก้ changelog

ผมลองผิดลองถูกกับ agentic workflow มาพักใหญ่ จนตอนนี้ลงตัวที่โครงสร้างหนึ่งซึ่งใครเคยทำทีม software จริง ๆ จะคุ้นทันที — มันคือ org chart ดี ๆ นี่เอง แค่เปลี่ยน headcount เป็น model tier

ราคาต่อ token ไม่ใช่ต้นทุนจริง

เวลาเถียงกันเรื่องราคาโมเดล คนมักจบที่ rate card — ตัวนี้ถูกกว่าต่อ 1M token ก็แปลว่าถูกกว่า ซึ่งเป็นสมการที่ผิดครับ

ต้นทุนจริง = ราคาต่อ token × จำนวน token ที่เผาจริงกว่างานจะเสร็จ

โมเดลที่ถูกกว่าแต่ชอบ over-engineer ทำเกินสั่ง หรือต้องสั่ง rework บ่อย ๆ สุดท้ายอาจแพงกว่าโมเดลที่ราคาสูงแต่ทำถูกตั้งแต่รอบแรก เพราะ token ที่เผาไปกับงานที่โดนทิ้ง มันคือต้นทุนที่ rate card ไม่เค

ห

ไผยโชว์ให้เห็น

และของที่แพงที่สุดในระบบไม่ใช่ token ด้วยซ้ำ — คือเวลาของเราที่ต้องนั่งไล่ review งานที่เละ

พอมองแบบนี้ คำถามจะเปลี่ยนจาก "โมเดลไหนเก่งสุด" เป็น "โมเดลไหนเหมาะกับตำแหน่งไหน"

โครงสร้าง 3 ชั้น

แผนภาพโครงสร้าง AI orchestration 3 ชั้น: คนอนุมัติ, frontier วิเคราะห์, executor ลงมือ

จ่ายแพงเฉพาะจุดที่ต้องใช้ judgment ที่เหลือจ่ายราคา executor — และไม่มีงานไหนหลุดลงไปก่อน thesis จะถูก commit

ชั้นที่ 1 — คน (Approver) ผมไม่ได้เขียนโค้ดเอง และช่วงหลังแทบไม่ได้ร่างแผนเองด้วยซ้ำ หน้าที่ผมคือตั้งโจทย์ เคาะ trade-off และอนุมัติ เหตุผลง่ายมาก: attention ของคนคือทรัพยากรที่แพงและหายากที่สุดในระบบ ก็ควรใช้มันกับการตัดสินใจเท่านั้น ไม่ใช่ลงมือ

ชั้นที่ 2 — Frontier model (Analyst) ตัวนี้ไม่ใช่เลขาพิมพ์งาน แต่เป็นคู่ซ้อมเถียงครับ หน้าที่มันคือแย้งผม — โยน trade-off ที่ผมมองข้าม แตกงาน เสนอแผน แล้วเราตีกันไปมาจนแผนนิ่ง ค่อย commit thesis ซึ่งเป็นด่านแข็ง: แผนที่ยังไม่ commit ห้ามมีการ execute เด็ดขาด

เหมือน architect คุยกับ tech lead น่ะครับ — คุณค่าไม่ได้อยู่ที่ tech lead พิมพ์เร็ว แต่อยู่ที่คุณภาพของการเถียงกันก่อนใครจะพิมพ์อะไร

ชั้นที่ 3 — โมเดลราคาประหยัด (Executor) พอ thesis นิ่งแล้ว งานถึงกระจายลง subagent ที่เป็นโมเดลถูกลง งาน execution ส่วนใหญ่ — CRUD, refactor ตาม pattern, implement ตาม spec ที่ปิดแล้ว — มันเป็นงาน bounded ครับ ฉลาดเกิน threshold ไปคุณภาพไม่ได้เพิ่ม เพิ่มแค่บิล

มีโบนัสอีกอย่าง: executor ที่ "เชื่อฟังมาก ๆ" คือสิ่งที่เราต้องการพอดีในชั้นนี้ นิสัยที่น่าหงุดหงิดตอนเป็น agent หลัก — ทำตามสั่งเป๊ะไม่คิดเพิ่ม — กลายเป็นจุดแข็งทันทีเมื่อการคิดถูกทำเสร็จไปแล้วข้างบน

กับดักที่ไม่มีใครคิดราคา: เชื่อฟังแบบเงียบ ๆ

กลยุทธ์ "ใช้ executor ถูก ๆ" มีหลุมอยู่หลุมหนึ่งครับ โมเดลที่ต่ำกว่าระดับหนึ่ง มันไม่ใช่แค่ทัก spec ที่ผิดไม่เป็น — มันจะทำตาม spec ที่ผิดอย่างเนี้ยบและมั่นใจมาก บั๊กเลยไม่โผล่ตอน generate ที่แก้ถูก แต่ไปโผล่ตอน integration ที่แก้แพง แล้วสุดท้ายก็ย้อนกลับมากองบนโต๊ะคนอนุมัติอยู่ดี

เพราะงั้นชั้น executor จะเลือกจากราคาอย่างเดียวไม่ได้ ทุกตัวต้อง "เก่งพอที่จะยกมือ" ในโดเมนที่มันรู้จัก

ด่านทดสอบ: แอบปล่อยช่องโหว่ให้ทัก

ก่อนโมเดลไหนจะเข้า pool executor ของผม มันต้องผ่านการทดสอบที่ benchmark ทั่วไปไม่วัด: มันยกมือเป็นไหม

แผนภาพ Planted-Flaw Capability Gate: ทดสอบว่าโมเดล executor ทักช่องโหว่ใน spec ได้หรือไม่

ยื่น spec ที่แอบฝังช่องโหว่ไว้หนึ่งจุดในโดเมนที่มันควรรู้ — โมเดลที่ execute spec ผิดได้อย่างสมบูรณ์แบบ อันตรายกว่าโมเดลที่พังเสียงดังอีก

วิธีง่ายมากครับ เอา spec สมจริงในโดเมนที่โมเดลควรถนัด ฝังช่องโหว่ไว้จุดเดียว — contract ที่ไม่ match กัน, edge case ที่หาย, constraint ที่ขัดกันเอง — แล้วยื่นให้เหมือนเป็นงานจริง

ทักได้ → ผ่าน มันมี domain grounding พอจะเป็น safety net ไม่ใช่แค่เครื่องพิมพ์โค้ด เงียบแล้วทำตาม → ตก ต่อให้ต่อ token ถูกแค่ไหน integration risk ก็ทำให้มันแพงเกินไป

จริง ๆ กับคนเราก็ทำแบบนี้โดยธรรมชาตินะครับ ก่อน delegate งานสำคัญให้ใคร เรายังต้องสำรวจความเข้าใจเขาก่อนเลย กับโมเดลที่กำลังจะไว้ใจให้เขียนโค้ดเข้า production ก็ไม่ควรหย่อนกว่านั้น

แล้วบิล token เปลี่ยนไปยังไง

Token ราคา frontier ถูกใช้เฉพาะช่วงที่ leverage สูงสุด — ตอนเถียง trade-off กับแตกงาน — ซึ่งเป็นสัดส่วนน้อยมากของ volume ทั้งหมด ส่วน token ก้อนใหญ่เผาที่ราคา executor และ rework ลดลงเพราะ spec ถูก challenge สองรอบก่อนถึงมือคนทำ: รอบแรกโดย frontier รอบสองโดย executor ที่ผ่านด่านยกมือมาแล้ว

Metric ที่ผม track จริง ๆ เลยไม่ใช่ token ต่องาน แต่คือ rework rate — เปอร์เซ็นต์งาน executor ที่ถูกตีกลับ นี่แหละ SLA ตัวจริงของ subagent ราคาต่อ token ถูกแต่ rework สูง คือส่วนลดที่เราจ่ายซ้ำสองรอบครับ

ปิดท้าย

เรื่องทั้งหมดนี้จริง ๆ ไม่เกี่ยวกับ AI เลย มันคือวินัยเดิมของ solution architecture มาตลอด: จับทรัพยากรให้ตรงกับความรับผิดชอบ, กั้น execution ไว้หลังการตัดสินใจที่ commit แล้ว, และวัดผลลัพธ์ไม่ใช่วัด input — โมเดลจะเปลี่ยนไปเรื่อย ๆ แต่ org chart นี้จะอยู่ครับ