timeline เต็มไปด้วย plugin ใหม่ เราประเมินก่อนลง แล้วไม่ลงสักตัว

อาทิตย์ที่ผ่านมา timeline ของเรามีแต่ชื่อเดียว: Ponytail plugin ที่ทำให้ agent เขียนโค้ดสั้นลงเหมือน senior dev ขี้เกียจ คนแชร์ตัวเลขสวย ๆ กันเต็มไปหมด ดังพร้อมกันก็ Headroom เครื่องบีบ context ที่ดาวขึ้นหลายหมื่นในไม่กี่สัปดาห์ เราเกือบกด /plugin install ทั้งสองตัว แต่หยุดไว้ก่อน แล้วถามคำถามเดียว: "ของมันดัง" กับ "ของมันเหมาะกับเรา" เป็นคนละเรื่องกันรึเปล่า

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

ช่วงที่ 1ดัง ไม่ใช่สัญญาณให้ลง

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

กระแสเป็นสัญญาณว่า "มาประเมินสิ" ไม่ใช่ "ลงเลย" ความต่างนี้เล็กแต่ราคาแพง เพราะ tool ทุกตัวที่ลงไปไม่ได้ฟรี มันกินพื้นที่ในหัว กินงบ context กินเวลา debug เวลาอะไรพัง

ช่วงที่ 2เกณฑ์ รัศมีความเสียหาย คูณ ความเจ็บที่วัดได้

เราไม่ตัดสิน tool จากว่า feature เจ๋งแค่ไหน แต่ดูจากสองแกน: หนึ่ง รัศมีความเสียหาย ถ้ามันพัง มันลามแค่ไหน สอง ความเจ็บที่วัดได้ ตอนนี้มีปัญหาที่ tool นี้แก้จริง ๆ และวัดเป็นตัวเลขได้ไหม

วาง tool ลงบนสองแกนนี้ คำตอบก็มักโผล่มาเอง:

• รัศมีศูนย์ (ฟรี ไม่แตะระบบเดิม) ลองได้เลย ไม่มีอะไรต้องเสีย
• รัศมีแคบ (เสียบเป็น library เฉพาะจุดที่เราคุมโค้ดเอง) ทำเป็นการทดลอง เปิดก็ต่อเมื่อมีความเจ็บจริง
• รัศมีเต็มระบบ (ไปนั่งคั่นทางที่ทุกอย่างวิ่งผ่าน) ตีกลับ ความเสี่ยงไม่คุ้ม

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

ช่วงที่ 3เช็คเงื่อนไขที่ตัดจบ ก่อนจะลงแรงวัด

เทสต์ Headroom สอนเราเรื่องที่มีค่าสุด Headroom บีบ token ก่อนส่งเข้าโมเดล เพื่อประหยัดค่า API เราตั้งใจจะวัด before/after ของจริงในงานที่ context ก้อนโต แต่ก่อนจะวัด ก็ถามคำถามเดียวที่ตัดจบทั้งแผน:

งานที่จะเอา Headroom ไปลง จ่ายค่าโมเดลแบบจ่ายตามจำนวน token หรือจ่ายแบบเหมาราย subscription

คำตอบคือ subscription ทุกงาน agent ที่เรารันอยู่เรียกโมเดลผ่านวิธีที่นับเป็นโควต้าเหมา ไม่ใช่บิลต่อ token แปลว่าไม่มีบิลต่อ token ให้บีบตั้งแต่แรก เราเลยตัดแผนวัดทั้งกองทิ้งด้วยคำถามเดียว ที่ใช้เวลาเช็คไม่ถึงนาที

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

ช่วงที่ 4สองตัวอย่างจริง และของที่เรามีอยู่แล้ว

Ponytail ตกที่แกนซ้ำซ้อนกับค่านิยม เครื่องมือลดความบวมของโค้ด เรามีอยู่แล้วในชุดเดิม อยากให้คุณเห็นว่ามีอะไรบ้าง เผื่อคุณก็มีเหมือนกัน:

• /simplify ของ Claude Code รีวิว diff แล้วลงมือตัดให้เลย ไม่ใช่แค่ชี้
• /code-review ครอบทั้งความบวมและบั๊กในคำสั่งเดียว เป็น superset ของ /simplify
• caveman บีบคำพูดของ agent ให้สั้น คนละแกนกับการบีบโค้ด ใช้คู่กันได้ไม่ทับ

ส่วนที่ Ponytail เพิ่มเข้ามา คือชี้รายการให้ไปตัดเอง ก็ทับกับ /simplify ที่เรามี แถมตัวที่เรามีลงมือแก้ให้เลยด้วยซ้ำ บวกกับมันสวนนิสัยสร้างเผื่อของเรา แล้วยัง inject กฎเข้ามาทุกเทิร์น กินงบ context ตลอด ส่วนตัวเลขเขียนโค้ดน้อยลง 80-94% นั่นเป็นเบนช์มาร์กของ Ponytail เอง ไม่ใช่ของเรา และต่อให้จริง มันก็ไม่ตอบโจทย์ที่เรายังไม่เจ็บ คำตัดสิน: ข้าม แต่ข้ามไม่ได้แปลว่าตลอดไป วันที่ Ponytail ลงมือตัดให้เองแทนที่จะส่งรายการมาให้ไปตัด แล้วเลิก inject กฎทุกเทิร์น ก็ค่อยกลับมาดูใหม่ ตอนนี้ของที่มีอยู่ก็ครอบแกนนี้แล้ว

Headroom ตกที่ killer-condition ในฐานะของลงทั้งระบบ แต่มันไม่ใช่ของแย่ ถ้าวันหนึ่งมีงานที่จ่ายต่อ token จริง เราจะกลับมาลองมันแบบ library เฉพาะจุด วัด before/after ในที่เดียว ไม่ใช่เอา proxy ไปคั่นทางทั้งระบบ คำตัดสิน: ยังไม่ใช่ตอนนี้ แต่จดเงื่อนไขปลุกไว้แล้ว

ทั้งสองคำตัดสินมาจากเกณฑ์เดียวกัน ไม่ใช่อารมณ์ตามกระแส

เกณฑ์ที่เอาไปใช้ได้เลย เวลามี tool ใหม่มาแรง

1. ถามก่อน "ดัง" หรือ "เหมาะกับเรา"
2. วางบนสองแกน รัศมีความเสียหาย คูณ ความเจ็บที่วัดได้จริง
3. หาเงื่อนไขที่ตัดจบ แล้วเช็คมันก่อนลงแรง
4. เช็คว่าชุดเครื่องมือที่มีอยู่แล้วครอบแกนนั้นไหม ก่อนจะเพิ่มตัวใหม่
5. จดไว้ว่าอะไรจะพลิก "no" นี้ เป็นเงื่อนไขหรือวันที่ก็ได้ "no" ที่ไม่มีสายชนวนจะค่อย ๆ แข็งเป็น veto ทั้งที่เครื่องมือดีขึ้นทุกอาทิตย์

ผ่านครบค่อยลง ไม่ผ่านก็ยังมีของเดิมที่ทำงานอยู่ กระแสจะมาเรื่อย ๆ เกณฑ์ของคุณต่างหากที่ควรอยู่กับที่

เริ่มตรงไหน ครั้งหน้าที่นิ้วจะกดติดตั้ง หยุดถามข้อ 1 ก่อนข้อเดียวพอ