ตัวเลขที่เจ้าของไม่ได้ตั้งเป้า

ประโยคแรกที่เจอตอนค้นชื่อเธอคือ “SpaceXAI engineer Lauren Tan: 99% of people are using GrokBot wrong.” (วิศวกร SpaceXAI Lauren Tan: คน 99% ใช้ GrokBot ผิดวิธี) อยู่ใต้ชื่อบัญชีที่ไม่ใช่ของเธอ เลื่อนลงไปอีกสองโพสต์ ประโยคแบบเดียวกันมาพร้อมตัวเลขคนละชุด โพสต์หนึ่งบอกว่าเธอคุม agent “15+” ตัว มี Chief of Staff หนึ่ง manager สาม worker สิบเอ็ด อีกโพสต์บอก “20+” อีกโพสต์เล่าว่าเพื่อนสมัครงานมาร้อยห้าสิบที่ แล้วได้ข้อเสนอเจ็ดแสนห้าหมื่นดอลลาร์ พร้อมแนบวิดีโอที่อ้างว่าเป็นคอร์สของเธอ

ฉันเปิดสัมภาษณ์ที่ยาวที่สุดที่หาฟังได้ เป็นไลฟ์หนึ่งชั่วโมงห้านาทีที่ Matt Pocock คุยกับเธอเมื่อ 2 ตุลาคม แล้วไล่หาเลข 99 ไม่เจอ ตัวเลขที่เจอคือ “more than 10 chiefs of staff” (chief of staff มากกว่าสิบตัว) ซึ่งเธอใช้เล่าว่ามี agent ตัวคุมงานสิบกว่าตัว แยกกันดูแลคนละเรื่อง ตัวหนึ่งไล่ performance ของแอป ตัวหนึ่งแก้บั๊กที่ผู้ใช้แจ้ง ผังองค์กรสามชั้นแบบที่โพสต์วาดให้ไม่มีอยู่ในคำตอบของเธอ

ตัวเลขที่ทำให้ชื่อ Lauren Tan วิ่งไปทั่ว feed คือจำนวน PR ที่ขึ้น production ในเดือนเดียว talk ที่เธอโพสต์บน X เมื่อ 21 กันยายนชื่อ how i shipped 2,500 PRs last month to production (เดือนที่แล้วส่ง PR 2,500 ใบขึ้น production ได้อย่างไร) คนสัมภาษณ์บอกว่ายอดดูราวสามล้าน ไล่เก็บจากบทความและโพสต์ที่พูดถึงเธอตลอดเดือนเดียวกัน ตัวเลขนี้มีหลายร่าง 1,000 ต่อเดือน, 2,000, 2,462, 2,500 แล้วกลายเป็น “5,000+ ในหกเดือน” ไม่มีร่างไหนแนบรายการ PR ให้นับ ดูจากความเร็วที่มันโต ตัวเลขนี้ขยันกว่า agent ของเธอเสียอีก

ตัวเธออยู่ในวงการนี้มานานก่อนตัวเลขนั้น ก่อนหน้านี้อยู่ทีม React ที่ Meta ราวหกปี เป็นหนึ่งในคนทำ React Compiler เครื่องมือที่ทำ memoization ให้อัตโนมัติ ออกเวอร์ชัน 1.0 เมื่อ 7 ตุลาคม 2025 ก่อนนั้นเป็น engineering manager ที่ Netflix เดือนมีนาคม 2026 ย้ายไป Cursor แล้วตามไปอยู่ SpaceXAI หลัง SpaceX ซื้อ Cursor ตอนนี้ดูแล Grok Bot ชื่อ poteto ที่ใช้บน GitHub มาจากมันฝรั่ง เธอบอกในสัมภาษณ์ว่าชอบทำอาหาร อุปมาที่เธอใช้ตลอดชั่วโมงจึงเป็นครัวระดับ Michelin แทนคำว่า software factory

ในสัมภาษณ์ เรื่องของเธอเริ่มจากความรำคาญ ต้นเมษายน หลังเข้า Cursor ได้ไม่นาน เธอถูกขอให้ช่วยแก้ agents window ที่หน่วง งานคือนั่งดู flame graph กับ heap snapshot ทีละอัน แล้วคอยส่งผลจาก DevTools ไปให้ agent อ่าน

I was the meat proxy between my agent and Chrome DevTools.
ตัวฉันเองกลายเป็นคนกลางเลือดเนื้อ คอยส่งของไปมาระหว่าง agent กับ Chrome DevTools

ทางออกที่เธอสร้างคือ verification skill ชุดคำสั่งที่ให้ agent เปิดแอปเอง คลิกเอง เก็บ trace เอง เธอเรียกมันว่าการให้ agent มี “hands and eyes” (มือและตา) และพูดตรง ๆ ว่าถ้าจะมี skill ได้แค่ตัวเดียว ตัวนี้สำคัญที่สุด

พอ Matt ถามว่าเธอชิมจานทั้ง 2,500 ใบที่ออกจากครัวไหม เธอตอบว่าไม่ แล้วเทียบกับหัวหน้าควบคุมคุณภาพในโรงงานที่สุ่มดูทุกวัน ถ้า agent หลายตัวพลาดแบบเดียวกัน เธอไม่แก้ที่ agent ตัวนั้น เธอแก้ที่ครัว ก่อนหน้านั้นเธอพูดประโยคหนึ่งที่ฉันไม่เจอในโพสต์ไหนเลย

The 2,500 PRs, they're not obviously like 2,500 features… a lot of the work actually is spent on gardening.
PR 2,500 ใบนั้น เห็นชัดว่าไม่ใช่ฟีเจอร์ 2,500 อย่าง… งานส่วนใหญ่จริง ๆ หมดไปกับการทำสวน

gardening ในความหมายของเธอคืองานถอนของที่ไม่ควรงอก ตัวอย่างที่เธอยกคือ agent ตัวหนึ่งที่ตั้งไว้ไล่หา pattern อันตรายของ React ใน codebase มันจดลงเอกสารไว้ก่อน ยังไม่แก้ ทุกสองสามวันเธอเปิดอ่านแล้วค่อยตัดสินว่าจะถอนอะไร งานแบบนี้นับเป็น PR ได้ทุกใบ แต่ไม่มีใบไหนเป็นปุ่มใหม่ให้ผู้ใช้กด ตามสรุป talk ที่ redreamality เขียนไว้ เธอบอกด้วยว่าไม่เคยตั้งเป้าตัวเลขนี้

จุดที่ฉันคิดว่าเด่นจริงอยู่ตรงนี้ เธอเล่าว่า Grok Bot เวอร์ชันแรก ๆ ประกอบด้วย god file แปดไฟล์ ไฟล์ละอย่างต่ำหนึ่งหมื่นบรรทัด agent ที่เข้ามาแก้ก็ต่อท้ายไฟล์เดิมไปเรื่อย ๆ ทางที่เธอเลือกคือสร้าง framework ภายในชื่อ Dune ที่บังคับให้ทุกฟีเจอร์มี directory ของตัวเอง แล้วผูก lint rule เข้มจน “there's really only one way to do something” (ทำอะไรก็มีอยู่ทางเดียวจริง ๆ) ทุกครั้งที่เห็น agent พลาดแบบเดิมซ้ำ เธอถามตัวเองว่าจะเปลี่ยนมันเป็น lint rule ได้ไหม มันเด่นเพราะย้ายกฎออกจากความจำของ agent ไปไว้ใน build กฎในเอกสาร agent อ่านแล้วข้ามได้ build ที่ fail ข้ามไม่ได้

เธอพูดเองว่ามันยาก “it's very hard to get to this point” (กว่าจะมาถึงจุดนี้ยากมาก) แล้วต่อด้วย “I don't want to sell this as… something that you can just do easily” (ไม่อยากขายว่ามันเป็นของที่ใครก็ทำได้ง่าย ๆ) วงจร verify ตอนเปิด full autopilot เธอบอกว่า “quite token intensive” (กิน token ค่อนข้างหนัก) คืนแรกที่ปล่อยให้ agent merge โค้ดเองตอนเธอหลับ เธอบอกว่ากลัว

สิ่งที่หาไม่เจอทั้งในสัมภาษณ์และในโพสต์ที่แชร์ต่อกันคือตัวเลขอีกฝั่งของบัญชี ใน 2,500 ใบ ถูก revert กี่ใบ ใช้ token ไปเท่าไร กี่ใบที่ไม่มีคนอ่านก่อน merge เธอเล่าว่าตอนเช้าจะไล่ดู commit history แล้ว revert หรือแก้ แต่ไม่ได้บอกว่าเช้าหนึ่งเจอกี่ใบ อีกเรื่องที่ไม่มีใครถามคือ Grok Bot กับ Cursor Cloud Agents เป็นสินค้าของบริษัทที่เธอทำงานให้ pstack ปลั๊กอินที่รวมวิธีทำงานของเธอก็อยู่ใน marketplace ของ Cursor ตัวเลข PR จึงทำหน้าที่เป็น demo ของสินค้าไปพร้อมกัน

ตัวเลขจากคนนอกที่มีให้เทียบชี้ไปคนละทาง การทดลองของ METR เมื่อกรกฎาคม 2025 ให้ developer สิบหกคนทำงานจริง 246 ชิ้น ฝั่งที่ใช้ AI ใช้เวลานานขึ้น 19% รายงานของ Faros AI ปีนี้ เก็บจาก developer สองหมื่นสองพันคน พบ incident ต่อ PR เพิ่มขึ้น 242.7% ส่วนงานวิจัยบน arXiv ที่นับ PR จาก agent สามหมื่นเจ็ดพันกว่าใบ พบว่า PR ของ Codex ถูก revert น้อยกว่าของคน ไม่มีชุดไหนวัดตัวเธอ สามชุดนี้บอกได้แค่ว่าจำนวน PR อย่างเดียวไม่พอให้ตัดสินอะไร

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

I think it's a great question that I don't really have the answer to.
เป็นคำถามที่ดีมาก และเป็นคำถามที่ฉันเองก็ยังไม่มีคำตอบจริง ๆ

ฉันไม่เจอโพสต์ไหนหยิบประโยคนี้ไปใช้ ถ้าคุณเคยแชร์ตัวเลข 2,500 คุณเคยได้ยินประโยคนี้ไหม