แถลงการณ์ Weft

ตัวเลขเดียว: ห้า

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

เราตั้งขีดจำกัดให้เล็กโดยตั้งใจ ในสูตรคิวของ Kingman เวลารอเพิ่มขึ้นตาม ρ/(1−ρ): ผู้ review ที่ไม่ว่าง 95% ของเวลาจะทำให้งานรอนานกว่าผู้ที่ไม่ว่างแค่ครึ่งหนึ่งของเวลาถึง 19 เท่า เมื่อความแปรปรวนเท่ากัน เช่นเดียวกับเป้าหมายของ Google SRE ที่ให้งานจุกจิกซ้ำซาก (toil) กินเวลาวิศวกรไม่เกิน 50% ห้าคือตัวเลขที่คุณอาจทำเกินได้ — และมองเห็นได้ว่าคุณทำเกินไปแล้ว^7,8

หลักการเจ็ดข้อ

1. 01งานไม่ได้ขาดแคลนอีกต่อไป การตัดสินใจของคุณต่างหากที่ขาดแคลน

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

2. 02“เสร็จ” ทุกครั้งต้องบอกว่าอ้างอิงจากอะไร

   รายงานของ agent เป็นเพียงคำขอให้รับรอง ไม่ใช่หลักฐาน ในโดเมน τ²-bench แบบควบคุมฝ่ายเดียว ความสำเร็จปลอม — agent บอกว่าเสร็จ แต่สภาพแวดล้อมบอกว่าไม่ — คิดเป็น 45–48% ของความล้มเหลว และไม่มี LLM judge ตัวใดที่อ่าน trace ของ agent แล้วได้คะแนน AUROC เกิน 0.65 ขณะที่การโยนเหรียญยังได้ 0.5 ดังนั้น “เสร็จ” ที่หนักแน่นที่สุดคือการอ่านจากโลกภายนอก: หน้าเว็บที่ตอบสนอง ไฟล์ที่ hash ตรงกัน ออบเจ็กต์ที่มีอยู่จริง งานที่ไม่ต้องการอะไรจากคุณอาจปิดได้ด้วยคำพูดของ agent — และจะแสดงตามนั้นตรง ๆ ไม่ใช่แสดงว่าตรวจสอบแล้ว⁴

3. 03ใครทำงาน คนนั้นไม่ได้เป็นผู้อนุมัติงาน

   ยืนยันแล้วกับยอมรับแล้วเป็นสองสถานะที่ต่างกัน เซิร์ฟเวอร์ที่อ่านโลกภายนอกซ้ำ การตรวจสอบแบบ deterministic หรือคน สามารถทำเครื่องหมายว่างานยืนยันแล้วได้ แต่ agent ที่ทำงานนั้นทำไม่ได้ การยอมรับคือลายเซ็นที่สองซึ่งแยกต่างหาก สำหรับอะไรก็ตามที่ย้อนกลับไม่ได้ — เงิน การเผยแพร่ ข้อความถึงลูกค้า หรือเรื่องใดที่เกี่ยวกับกฎหมาย — Weft จะขอให้ agent หยุดและรอคุณ และเมื่อตั้งจุดหยุดนั้นแล้ว ไม่มี agent ใดยกเลิกได้หรือย้ายงานไปที่ Done ได้

4. 04ทุกงานมีเจ้าของที่เป็นคนเพียงหนึ่งคน

   คุณให้ agent รับผิดชอบไม่ได้ ทำได้แค่มอบหมายงานให้มัน ดังนั้นงานหนึ่งจึงมีเจ้าของเพียงคนเดียวซึ่งเป็นคน และมีผู้รับมอบหมายที่ระบุชื่อชัดเจน: ไม่ใช่ “AI” แต่เป็น Claude Code, Cursor, ChatGPT หรือ Codex ให้มีผู้รับมอบหมายไม่มาก คำแนะนำของ Anthropic เองสำหรับทีม agent คือเริ่มที่สามถึงห้าตัว เพราะ “three focused teammates often outperform five scattered ones” (เพื่อนร่วมทีมที่โฟกัสสามคนมักทำได้ดีกว่าห้าคนที่กระจัดกระจาย)⁵

5. 05เมื่อถึงขีดจำกัด ให้ชี้ทาง — และอย่าปลอมการตัดสินใจเด็ดขาด

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

6. 06ไม่มีอะไรถูกยกยอดไปอย่างเงียบ ๆ

   สัปดาห์คือหน่วยของการวางแผน: เมื่อเทียบกับวันธรรมดา ผู้คนมีแนวโน้มจะตั้งใจมุ่งสู่เป้าหมายมากขึ้น 62.9% ในวันเริ่มต้นสัปดาห์ และมากขึ้น 23.6% ในวันเริ่มต้นเดือน สัปดาห์จึงจบลงด้วยการตัดสินใจกับงานที่ยังไม่เสร็จทุกชิ้น — ทำต่อพร้อมขั้นตอนถัดไปที่ชัดเจน แบ่งย่อย ส่งกลับ หรือยกเลิก — ไม่ใช่ด้วยการย้ายไปสัปดาห์หน้าอย่างเงียบ ๆ⁶

7. 07การตัดสินใจอยู่ได้นานกว่า session

   ไม่มี AI client ไหนส่งต่อความจำของตัวเองให้ผู้อื่น และนั่นก็ถูกต้องแล้ว ดังนั้นสิ่งที่อยู่รอดหลังจบ session คือสิ่งที่ถูกบันทึกไว้ภายนอก: ไม่ใช่แฟ้มประวัติของคุณ แต่เป็นประวัติของงาน — งานจบลงอย่างไร ตัดสินใจอะไรไป และเพราะอะไร ความจำก็ต้องรู้จักลืมด้วย: บันทึกที่ล้าสมัยจะไม่ถูกส่งให้ agent อีก

ลองนำบอร์ดของคุณมาวัดดู

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

✓ ใช้งานได้แล้ววันนี้ · — บางส่วน หรือยังไม่เปิดใช้ · ✗ ไม่มี

เรานับอะไร และไม่นับอะไร

Velocity, story point, burndown, อัตราการใช้ทรัพยากร, จำนวนงานที่สร้าง และจำนวนครั้งที่เรียกใช้ AI ไม่มีอยู่ในผลิตภัณฑ์นี้ สิ่งเหล่านี้วัดทรัพยากรที่ไม่ขาดแคลนอีกต่อไป และให้รางวัลกับความวุ่นวายที่ไร้ความหมาย

ความรู้สึกว่าเร็วขึ้นก็ไม่ใช่การวัดผลเช่นกัน ในการศึกษาของ METR กับนักพัฒนาโอเพนซอร์สที่มีประสบการณ์ซึ่งใช้เครื่องมือช่วงต้นปี 2025 พวกเขาเชื่อว่า AI ทำให้ตัวเองเร็วขึ้น 20% แต่เมื่อวัดจริง พวกเขาช้าลง 19%⁹

สิ่งที่ควรนับมีสี่อย่าง: รายการที่เก่าที่สุดรอคุณมานานแค่ไหน เวลาตั้งแต่ “agent พร้อมแล้ว” จนถึง “คุณตัดสินใจแล้ว” สัดส่วนงานที่ได้รับการยอมรับตั้งแต่ครั้งแรก แยกตามผู้ลงมือทำแต่ละราย และจำนวนนาทีที่คุณใช้ความสนใจต่อผลลัพธ์ที่ได้รับการยอมรับหนึ่งชิ้น ตัวสุดท้ายคือบททดสอบที่ตรงไปตรงมาเพียงหนึ่งเดียวว่า AI คุ้มค่าจริงหรือไม่ Weft บันทึกข้อมูลที่แต่ละตัวชี้วัดต้องใช้ — ใครทำงานแต่ละชิ้น งานพร้อมเมื่อไร และคุณตัดสินใจอะไร — และแสดงให้เห็นว่ามีงานรอคุณอยู่เท่าไร

จุดที่วิธีนี้ใช้ไม่ได้

งานบางอย่างไม่มีการตรวจสอบที่รันได้ จดหมายถึงนักลงทุนหรือ positioning statement ไม่สามารถให้เซิร์ฟเวอร์ยืนยันได้ และในกรณีนั้น วิธีนี้ก็ยอมถอยกลับไปเป็นบอร์ดธรรมดาอย่างตรงไปตรงมา โดยมีผู้ review หนึ่งคนและงานแบบนั้นทีละหนึ่งชิ้น เฟรมเวิร์กที่สัญญาเกินกว่าที่ตรวจสอบได้ จะพังลงตรงจุดที่มีคนพึ่งพามันพอดี

ยังไม่มีงานวิจัยที่ผ่าน peer review เกี่ยวกับขีดจำกัดที่เหมาะสมเมื่อ agent เป็นผู้ทำงาน ห้าคือค่าเริ่มต้นของเรา ไม่ใช่ข้อค้นพบ เราเริ่มที่สามและเพิ่มขึ้นหลังจากใช้งานจริงในช่วงสัปดาห์แรก ๆ: หนึ่งในสามของการปฏิเสธเกิดขึ้นตอนที่มีงานรออยู่เพียงสามหรือสี่รายการ และเคลียร์ได้หมดในการนั่งทำครั้งเดียว การ review ก็อาจมีต้นทุนต่ำลงด้วย: GDPval เองระบุว่าเวลา review ลดลงเมื่อผู้เชี่ยวชาญคุ้นเคยกับงาน หากวันหนึ่งการตรวจสอบกลายเป็นเรื่องถูกและเชื่อถือได้ ขีดจำกัดก็ควรเพิ่มขึ้น — นั่นคือเหตุผลที่ทุกเกณฑ์ในที่นี้เป็นค่าเริ่มต้นที่เราคาดว่าจะปรับแก้ ไม่ใช่ความเชื่อ³

แหล่งอ้างอิง

1. 2026 Software Engineering Benchmarks Report — LinearB, 2026
2. The Acceleration Whiplash — Faros AI, 12 April 2026
3. GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks — OpenAI, arXiv:2510.04374, 5 October 2025
4. From Confident Closing to Silent Failure — arXiv:2606.09863, 1 June 2026
5. Orchestrate teams of Claude Code sessions — Choose an appropriate team size — Anthropic, retrieved 22 October 2026
6. The Fresh Start Effect: Temporal Landmarks Motivate Aspirational Behavior — Dai, Milkman, Riis — Management Science 60(10), 2014
7. The single server queue in heavy traffic — J. F. C. Kingman — Proceedings of the Cambridge Philosophical Society, 1961
8. Site Reliability Engineering, Chapter 5: Eliminating Toil — Google, 2016
9. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR, 10 July 2025