ทำไม AI เขียนโค้ดแล้วเราไม่กล้าใช้? วิธีสร้างความเชื่อใจแบบ Lauren Tan แห่ง Cursor

โดย Nokka (นก-กา) | นักเขียนอิสระสาย AI | ตรวจสอบข้อมูล ณ 19 ต.ค. 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

มีประโยคหนึ่งในบทสนทนาที่ผมฟังแล้วต้องหยุด

"ผมตื่นขึ้นมาแล้วมี PR ยี่สิบอันถูกรวมเข้าสาขาหลักไปแล้ว"

คนพูดคือวิศวกรที่ทำงานให้บริษัท AI แห่งหนึ่ง และเธอบอกต่อว่าตอนนี้ เอเจนต์ของเธอรวม PR ให้เองอัตโนมัติ ส่วนเธอแค่ตื่นมาอ่านทีหลังว่ามันไปทำอะไรไว้

ประโยคนี้ฟังดูเหมือนคนที่ปล่อยโค้ดขยะขึ้นระบบจริง และเธอรู้ตัวดี เพราะประโยคถัดมาคือ "ฟังดูน่ากลัวนะ แต่ผมสัญญาว่าผมไม่ได้เป็นศิลปินทำสลอป"

ผมเลยอยากรู้ว่าก่อนจะไปถึงจุดที่กล้านอนหลับได้ เธอทำอะไร

บทความนี้สรุปจากบทสนทนายาว 58 นาที ที่ช่อง Keepintrust เผยแพร่เมื่อ 5 กันยายน 2026 มีคนดูประมาณ 66,000 ครั้ง [1] เนื้อหาทั้งบทมาจากแหล่งนี้ เว้นแต่จะมีป้ายอ้างอิงอื่นกำกับไว้ ผู้ให้สัมภาษณ์คือ Lauren Tan หรือที่วงการรู้จักในชื่อ poteto บน X (Twitter)

เธอเป็นใคร

เธอเล่าประวัติตัวเองในนาทีแรกว่าเคยอยู่ที่ Meta ทีม React โดยทำงานกับ React Compiler และยังอยู่ในทีม core ถึงทุกวันนี้

ก่อนหน้านั้นอยู่ที่ Netflix ทั้งในตำแหน่ง tech lead และเปลี่ยนไปเป็น engineering manager ประมาณสองปี

ตอนให้สัมภาษณ์เธออยู่ที่ Cursor มาได้ประมาณห้าเดือน [1]

ผมเปิด README ของปลั๊กอินที่เธอเขียนเพื่อยืนยันตัวตนอีกชั้น เธอเขียนแนะนำตัวไว้เองว่าเคยทำงานกับโค้ดหลายล้านบรรทัดที่ Meta, Netflix และ Cursor และยังช่วยสร้างและดูแล React Compiler อยู่ [3] ส่วนชื่อและสังกัด Meta ยืนยันได้จากรายชื่อผู้พูดงาน React Conf [6]

ประวัตินี้สำคัญเพราะมันคือที่มาของข้อสังเกตที่เธอใช้ตลอดบทสนทนา

การจัดการคน กับการจัดการเอเจนต์ เป็นเรื่องเดียวกัน

ประเด็นหลักของเธอคือ ความเชื่อใจ

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

ผลคือคุณได้งานช้าลง และทีมก็ไม่โต

เธอวาดกราฟเส้นหนึ่งขึ้นมา และบอกเองว่ามันไม่เป็นวิทยาศาสตร์สักเท่าไร แต่เป็นกราฟที่อธิบายเส้นทางการใช้เอเจนต์ของเธอ

แกนหนึ่งคือความเชื่อใจ อีกแกนคือจำนวนงานที่ทำได้

ช่วงแรกอยู่ที่มุมล่างซ้าย คือเปิดเอเจนต์ทีละตัว แล้วนั่งดูทุก output ตัวเองเป็นคนป้อน prompt ตลอดเวลา และไม่มีทางทำอะไรขนานได้เลย

เธอพูดประโยคที่ตรงมากว่า ถ้าคุณไม่เชื่อใจเอเจนต์แม้แต่ตัวเดียว คุณจะสร้างเอเจนต์ร้อยตัวไม่ได้

จากนั้นเส้นกราฟก็ไล่ขึ้นมา จนถึงจุดที่เธอบอกว่าเธอปล่อยให้เอเจนต์รวม PR ให้เอง

ตัวเลขที่ทำให้ผมต้องอ่านซ้ำ

เธอให้ตัวเลขไว้สามชุด

เดือนก่อนเธอส่ง PR ไป หนึ่งพันอัน

เดือนที่บันทึกบทสนทนา ผ่านไปแค่สิบสองวัน เธอบอกว่าอยู่ที่เกือบ แปดร้อยอัน

วันที่ผมยืนยันได้คือวันเผยแพร่ 5 กันยายน 2026 ส่วนวันที่บันทึกจริงผมยืนยันไม่ได้ คำพูดของเธอชี้ว่าบทสนทนาเกิดในวันที่ 12 ของเดือนหนึ่ง ซึ่งต้องเป็นเดือนก่อนหน้าวันเผยแพร่

และการรีแฟกเตอร์ Grok Bot แอปใหม่ที่เพิ่งเปิดตัว ใช้ไปมากกว่า หกร้อย PR

ผมต้องบอกตรง ๆ ว่าตัวเลขพวกนี้ผมตรวจสอบเองไม่ได้ เพราะเป็น repo ภายในบริษัท

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

เธอพูดเองว่า "ผมแน่ใจว่าหลายคนจะสงสัยว่าโค้ดพวกนี้ดีจริงแค่ไหน ซึ่งเป็นคำถามที่แฟร์มาก"

คำตอบของเธอคือประโยคที่ผมว่าคือหัวใจของทั้งบทสนทนา

ทักษะที่สำคัญที่สุดในการทำงานกับเอเจนต์ คือการตรวจสอบ

การตรวจสอบ หมายถึงอะไรกันแน่

คำว่า verification ในที่นี้เธอไม่ได้หมายถึงการอ่านโค้ดแล้วพยักหน้า

เธอหมายถึง ให้เอเจนต์รันโค้ดจริงได้ เก็บ trace ของ CPU ได้ เก็บ heap snapshot ได้ เปิด simulator ของ iOS ได้

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

เธอเล่าเคสจริงที่เกิดขึ้นกับตัวเองตอนเข้าทำงานใหม่ ๆ

เธอถูกย้ายจากทีม cloud agents มาช่วยงานหน้าต่างเอเจนต์ของ Cursor ซึ่งเป็นแอปพลิเคชัน React และมีกำหนดเปิดตัวในอีกหนึ่งสัปดาห์

เธอเปิด Chrome DevTools จับ trace เอง แล้วนั่งอ่าน flame graph ทั้งที่เพิ่งเข้าทีมได้สัปดาห์แรก

แล้วเธอก็ส่ง trace ให้เอเจนต์ดู เอเจนต์ก็ตอบว่า "อืม น่าจะอันนี้นะ" อย่างมั่นใจ

พอลองแก้ตามนั้น ปรากฏว่าไม่ใช่

ทำแบบนี้ซ้ำไปเรื่อย ๆ และมันช้ามาก เพราะ เธอคือคนที่ต้องเป็นตัวตรวจสอบเอง

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

ทางออกของเธอคือสร้างสิ่งที่เธอเรียกว่า control-glass ซึ่งเป็นสกิลที่สอนเอเจนต์ให้บังคับแอปผ่าน Chrome DevTools Protocol, จับ trace และสั่งงาน simulator ได้ด้วยตัวเอง

ผลคือลูปปิดที่ตัวเอเจนต์ ไม่ใช่ที่ตัวเธอ [1]

ปัญหาที่ผมไม่เคยเห็นใครพูดถึง

การให้เอเจนต์รันแอปได้ เป็นเพียงครึ่งเดียวของเรื่อง

เธอเล่าว่าหลังจากสร้าง control-glass เสร็จ เอเจนต์รันหน้าต่างเอเจนต์ได้แล้ว จับ trace ได้แล้ว แต่มีปัญหาใหม่ที่คาดไม่ถึง

มันไม่รู้ว่ากำลังดูอะไรอยู่

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

เธอบรรยายว่ามันเอาแต่ตะลีตะลานงมทางไปเรื่อย ๆ และสกิลที่สร้างมาก็แทบไม่มีประโยชน์

ทางแก้ของเธอเรียบง่ายมากจนน่าตกใจ เธอทำไฟล์ที่เรียกว่า feature map [1]

มันคือแผนที่ที่สอนเอเจนต์ว่าฟีเจอร์ทุกอย่างของคุณเข้าถึงได้อย่างไร ตั้งแต่แถบด้านซ้ายมีอะไรบ้าง แต่ละฟีเจอร์ย่อยอยู่ตรงไหน คีย์ลัดคืออะไร ไปจนถึง attribute ของ DOM ที่ต้องใช้เลือก element ผ่าน CDP

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

เธอเล่าต่อว่าที่ Cursor มีช่อง Slack ที่คนส่งฟีดแบ็กเข้ามาเยอะมาก และคุณภาพรายงานต่ำมาก บางทียอดฮิตคือส่งภาพหน้าจอมาแล้วพิมพ์ว่า "???" สามตัว

ถ้าไม่มีแผนที่ เอเจนต์ก็ทำอะไรไม่ได้ แต่ถ้ามี มันแปลงคำถามที่กำกวมที่สุดให้เป็นการกระทำได้

เธอบอกว่าปลั๊กอินของเธอมีสกิลที่ช่วยสร้างแผนที่นี้ให้เอง โดยไล่สำรวจโค้ดแล้วประกอบเป็นแผนที่ตั้งต้น และมีอีกสกิลไว้ดูแลให้มันไม่ล้าสมัย [2]

eval คือ unit test ของสกิล

จุดที่ผมว่าฉลาดที่สุดในบทสนทนาคือวิธีที่เธอทำให้แน่ใจว่าสกิลที่เขียนนั้นทำงานจริง

เธอเรียกมันว่า eval และให้นิยามสั้น ๆ ว่า มันคือ unit test สำหรับเอเจนต์

ไม่มีเฟรมเวิร์กพิเศษ ไม่ต้องมีอะไรมาก เธอใช้เอเจนต์ตัวหลักเป็นผู้วางเกณฑ์ว่าสกิลนี้ควรทำอะไร แล้วมันก็แตกเอเจนต์ลูกออกมาหลายตัวให้ไปลองทำตามเกณฑ์

ตรงนี้มีรายละเอียดที่ผมชอบมาก [1]

เธอตั้งชื่อโฟลเดอร์ของเอเจนต์ลูกแต่ละตัวให้ไม่สื่อว่า กำลังถูกวัด

เหตุผลคือเอเจนต์จับได้ว่าตัวเองอยู่ในสถานการณ์สอบ และเมื่อมันรู้ มันจะเปลี่ยนพฤติกรรม

ผมอ่านตรงนี้แล้วนึกถึงปัญหาที่เจอในงานวิจัยทั้งหลาย ถ้าคนถูกจับตามอง เขาก็ทำตัวต่างออกไป เอเจนต์ก็เหมือนกัน

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

ผลลัพธ์ที่ได้คือคะแนน ซึ่งเอาไปใช้ไต่ระดับต่อได้ เธอบอกว่าใช้คำสั่ง /loop ใน Cursor สั่งให้วนแก้ไปเรื่อย ๆ จนกว่าคะแนนจะเต็มสิบ

ผมมองว่านี่คือการเปลี่ยนงานเขียน prompt จากงานฝีมือเป็นงานที่มีตัวเลขรองรับ [1]

แต่การดูแลสกิลก็ยังยากอยู่ดี

เธอไม่ได้ขายฝันว่าทุกอย่างจะง่าย

เธอบอกตรง ๆ ว่าการดูแลสกิลต้องใช้ รสนิยมและการสังเกต สูงมาก

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

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

เพราะความล้มเหลวมักซ่อนอยู่ในนั้น

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

นี่คือความต่างระหว่าง "เอเจนต์ตอบผิด" กับ "เอเจนต์ไม่ได้ทำงานที่เราคิดว่ามันทำ" [1] อย่างหลังอันตรายกว่ามาก เพราะมันดูเหมือนทำงาน

สกิลที่เธอสร้างจากเคสนี้คือการสอนให้มันค้นหาโค้ดจริงและใช้ sub-agent ช่วย มากกว่าจะเดา

เชฟหัวครัว ไม่ใช่คนหั่นผัก

มีภาพเปรียบเทียบหนึ่งที่เธอใช้อธิบายบทบาทใหม่ของวิศวกร

เธอบอกว่าเวลามีเอเจนต์ช่วยทำงาน เราไม่ได้เป็นคนลงมือทำทุกอย่างอีกต่อไป แต่เป็นเหมือน เชฟหัวครัว

คุณไม่ได้หั่นผักเองแล้ว คุณมีทีมพ่อครัว มีสถานีต่าง ๆ หน้าที่ของคุณคือ ออกแบบครัว

คือจัดสภาพแวดล้อมให้ถูก กำหนดว่าอะไรอยู่ตรงไหน ใครรับผิดชอบสถานีไหน

ผมว่าภาพนี้ตรงกับความจริงมากกว่าคำว่า "คนคุมเอเจนต์" เพราะมันบอกชัดว่าคุณออกแบบได้แค่ สภาพแวดล้อม ไม่ใช่ตัวงาน

และมันอธิบายด้วยว่าทำไมเธอจึงใช้เวลากับการสร้างสกิลมากกว่าการเขียนโค้ดเอง

ทำไม lint อย่างเดียวเอาไม่อยู่

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

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

เธอเรียกหลักการของกรอบที่เธอสร้างว่า Dune ซึ่งเป็นกรอบที่ใช้รีแฟกเตอร์ Grok Bot และอธิบายสั้น ๆ ว่าเป็นทำนองเดียวกับ Next.js แต่สำหรับแอป Electron และออกแบบมาให้เอเจนต์เขียนโดยเฉพาะ

ใน Dune มีคำนามชัดเจน เช่น feature, entry point และ transcript card [1] ทุกอย่างมีวิธีสร้างที่ถูกเพียงวิธีเดียว

ชั้นถัดมาคือ CI และการวิเคราะห์เชิงสถิต ซึ่งทำให้ CI แดงได้จริง เช่นการตรวจ dependency graph ว่าโค้ดจากโฟลเดอร์ main ถูก import เข้าโฟลเดอร์ renderer หรือเปล่า

เรื่องนี้ฟังดูจุกจิก แต่เธออธิบายว่ามันคือปัญหาที่เจอจริงในแอป Electron ถ้าโค้ดที่กิน CPU หลุดเข้าไปอยู่ใน renderer thread ที่ต้องวาดภาพทุก 16 มิลลิวินาที ภาพก็จะกระตุก

ชั้นที่อ่อนที่สุดคือ rules, skills และบอทตรวจโค้ด เธอบอกตรง ๆ ว่าเอเจนต์ยังลืมได้ ยังทำไม่สม่ำเสมอ

และประโยคที่ผมว่าตรงที่สุดคือ ถ้าคุณมีแค่ rules, skills, บอทตรวจโค้ด และ style guide ไม่ช้าก็เร็วโค้ดเบสของคุณจะกลายเป็นขยะ

สองอย่างที่เธอห้ามเด็ดขาด

มีรายการที่เธอแบนในโปรเจกต์ของเธอ และสองอันแรกน่าสนใจมาก

อย่างแรก เธอแบน useEffect ซึ่งเป็น hook ที่คนเขียน React รู้กันว่ามีโอกาสพลาดสูง

อย่างที่สอง เธอแบนคอมเมนต์ในโค้ด [1]

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

ตัวอย่างที่เธอยกมาคือคอมเมนต์ที่เขียนว่า "Lauren said you should never do this"

เธอบอกว่าเธอไม่ได้หมายถึงกฎถาวรที่ใช้ได้ทั้งระบบ ตอนนั้นเธอแค่หมายความว่า PR อันนั้นห่วยและควรแก้

นี่คือหลักฐานที่ดีมากว่าปัญหาของเอเจนต์ไม่ใช่เรื่องความฉลาด แต่มันคือการเหมารวมบริบทเฉพาะกิจให้กลายเป็นกฎถาวร

และทางแก้ที่เธอเลือกก็สอดคล้องกัน คือถ้าไม่มีที่ให้เขียนคอมเมนต์ ปัญหานี้ก็ไม่มีที่เกิดขึ้น

กับดักที่ผมว่าควรระวังที่สุด

เธอมีประโยคหนึ่งที่ผมคิดว่าคนเป็นหัวหน้าทีมควรติดไว้ข้างจอ

ถ้าคุณกำลังบังคับกฎอะไรก็ตามด้วยการที่ต้องมีคนมาอ่านโค้ดแล้วบอกว่า "ห้ามทำแบบนี้" ทุกครั้งที่คุณต้องทำแบบนั้น ให้ถือว่านั่นคือสัญญาณว่ามีอะไรผิด

เธอเรียกสภาวะนี้ว่า code review land และบอกว่ามันเป็นที่ที่แย่ที่สุด

วิธีแก้คือทุกครั้งที่คุณต้องคอมเมนต์อะไรใน PR [1] ให้ถามตัวเองว่า ทำไมเรื่องนี้ไม่เป็นกฎที่เครื่องบังคับได้ ทำไมไม่เป็น lint หรือ CI failure หรือจะกำจัดปัญหานี้ให้หมดไปเลยได้ไหม

ผมชอบมากเพราะมันพลิกวิธีคิดของคนรีวิวโค้ด จากคนที่ต้องจำกฎ ไปเป็นคนที่ออกแบบกฎ

ตัวเลขที่ผมว่าต้องอ่านให้ครบ

เธอเล่าว่า PR ของเธอมีขนาดตั้งแต่ห้าสิบบรรทัดถึงหนึ่งพันบรรทัด [1] ไม่มีเพดานตายตัว แต่เธอให้เอเจนต์แบ่งงานเป็นหลาย PR

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

ส่วนเรื่องค่าใช้จ่าย มีคนถามตรง ๆ ว่าแบบนี้คนที่มีโควตาโทเคนปกติจะทำได้หรือ

คำตอบของเธอซื่อสัตย์ที่สุดในบทสนทนาทั้งหมด

เธอบอกว่า "ผมทำงานอยู่ที่ AI lab ที่มีโทเคนไม่จำกัด ผมจึงบอกไม่ได้ว่าทุกคนควรทำแบบเดียวกับผม" [1]

เธอมองว่ามันเป็นเรื่องของผลตอบแทนจากการลงทุน คือจ่ายโทเคนก้อนใหญ่ช่วงแรกเพื่อรีแฟกเตอร์และวางข้อจำกัด แล้วหลังจากนั้นเอเจนต์ที่ฉลาดน้อยกว่าก็ทำงานได้ดี

และเธอเปรียบเทียบกับอีกทางเลือกหนึ่ง คือจ้างคนมาทำ ซึ่งมีต้นทุนและมีค่าใช้จ่ายแอบแฝงที่เธอประสบมาก่อนตอนเป็นผู้จัดการ

ผมว่าการที่เธอพูดประโยคนี้เองทำให้บทสนทนาทั้ง 58 นาทีมีน้ำหนักขึ้นมาก เพราะมันกันไม่ให้คนฟังเอาไปใช้แบบผิดบริบท

และมีคำสารภาพอีกช่วงที่ผมคิดว่าสำคัญกว่าตัวเลขทั้งหมด ในนาทีที่ 41 เธอบอกว่ามันคือการต่อสู้ที่ไม่จบ เพราะมี PR ไหลเข้าและถูกรวมตลอดเวลา และแต่ละอันทำให้ประสิทธิภาพ ความเสถียร หรือความน่าเชื่อถือถอยหลังได้

เธอยอมรับด้วยว่าแอปหน้าต่างเอเจนต์ยังไม่ได้ใช้สถาปัตยกรรมแบบ Dune และมันถอยหลังบ่อยมาก เพราะการแยก process ระหว่างกันยังทำได้แย่

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

pstack คืออะไร และควรเริ่มตรงไหน

ปลั๊กอินที่เธอสร้างชื่อ pstack ติดตั้งด้วยคำสั่งเดียว

/add-plugin pstack

จากนั้นรัน /setup-pstack เพื่อเลือกโมเดลที่ต้องการ แล้วใช้ /poteto-mode ทุกครั้งที่ทำงานที่ต้องใช้ความรัดกุม

ตัว /poteto-mode มี playbook อยู่ยี่สิบสามชุด [3] และมันจะเลือกใช้เองตามลักษณะงาน

ตัวอย่างคำสั่งที่เธอใส่ไว้ใน README และผมว่าสื่อพลังของมันได้ดีที่สุดคือ

/poteto-mode i'm going to bed. land the stack even if ci flakes. i want everything merged by morning.

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

อีกอย่างที่ผมว่าแปลกดีคือมันแบ่งงานตามจุดแข็งของโมเดล งานโค้ดที่ลงมือได้เลยอย่างการเพิ่มฟีเจอร์ รีแฟกเตอร์ แก้บั๊ก ปรับประสิทธิภาพ และไต่ระดับคะแนน จะไปทาง grok ส่วนงานที่ยากที่สุด งานเขียน และงานที่ต้องใช้ดุลยพินิจ จะไปทาง opus 5.5 โดยแผงเริ่มต้นมีสองตัวคือ opus 5.5 กับ grok

README ของเธอยังเขียนประโยคที่ผมชอบมากอีกประโยค [3]

"ถ้าอยากไปเร็ว ให้ลงลึกก่อน" และ "ปริมาณงานที่ไม่มาพร้อมคุณภาพ ไม่ใช่เป้าหมายที่ผมอยากได้"

เหมาะกับใคร

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

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

เหมาะ ถ้าคุณเป็นหัวหน้าทีมและกำลังคิดว่าจะทำให้ทั้งทีมได้ประโยชน์ ไม่ใช่แค่ตัวเอง

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

ยังไม่เหมาะ ถ้าคุณมีโควตาโทเคนจำกัดมาก เพราะเธอเองยอมรับว่าจุดที่เธออยู่ต้องแลกด้วยโทเคนจำนวนมาก

สิ่งที่ผมยืนยันได้ และยืนยันไม่ได้

ยืนยันได้

• วิดีโอเผยแพร่ 5 กันยายน 2026 ความยาว 58 นาที 31 วินาที [1]
• Lauren Tan คือ poteto และเคยอยู่ทีม React ที่ Meta ก่อนย้ายมา Cursor ข้อนี้ยืนยันได้จาก README ของปลั๊กอินที่เธอเขียนเอง [3][5]
• pstack มีอยู่จริงใน repo ทางการ cursor/plugins และมี playbook ยี่สิบสามชุดตามที่ README ระบุ [2][3]
• คำสั่งติดตั้ง /add-plugin pstack และสองขั้นตอน setup ตรงกับ README [3]
• Grok Bot เป็นผลิตภัณฑ์จริงของ Cursor และเอกสารระบุว่าให้ Bot ประจำตัวสำหรับงานค้นคว้า ปฏิบัติการ เอกสาร การท่องเว็บ และระบบอัตโนมัติ [4]

ยืนยันไม่ได้

• ตัวเลขหนึ่งพัน PR ต่อเดือน และแปดร้อย PR ในสิบสองวัน เพราะเป็น repo ภายใน
• ว่าโค้ดที่เอเจนต์รวมให้เองมีคุณภาพแค่ไหน เพราะไม่มีตัวเลขผลวัดเผยแพร่
• ว่าแนวทางนี้ได้ผลกับทีมทั่วไป ไม่ใช่เฉพาะคนที่ทำงานในบริษัท AI ที่มีโทเคนไม่จำกัด

คำถามที่ผมว่าควรถามก่อนทำตาม

ไม่ใช่ "ผมควรสร้างสกิลไหม" แต่เป็น "ตอนนี้ผมเป็นคอขวดอยู่ตรงไหน"

ถ้าคำตอบคือต้องตรวจทุกอย่างด้วยตัวเองเพราะเอเจนต์รันแอปไม่ได้ คำตอบคือสร้างสกิลตรวจสอบก่อน

ถ้าคำตอบคือเอเจนต์รันได้แต่ไม่รู้จะไปทางไหน คำตอบคือทำแผนที่ฟีเจอร์

ถ้าคำตอบคือเอเจนต์ทำได้แต่บางทีลืมกติกา คำตอบคือย้ายกติกาจากหัวคุณไปที่ CI

และถ้าคำตอบคือยังไม่รู้ ให้เริ่มจากการเปิดดู tool call ของเอเจนต์สักหนึ่งงาน แล้วอ่านว่ามันทำอะไรจริง ๆ

นั่นคือจุดที่บทสนทนานี้เริ่มต้น

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

[1] Keepintrust, "หยุดเขียนโค้ดเอง! วิธีเทรน AI Agent ทำงานแบบวิศวกรระดับโลก โดย Lauren Tan (Cursor, Grokbot)", YouTube, 5 ก.ย. 2026, ความยาว 58:31. https://www.youtube.com/watch?v=Yx_CBWkRAWY
[2] Lauren Tan (poteto), "pstack", cursor/plugins, GitHub, เข้าถึง 19 ต.ค. 2026. https://github.com/cursor/plugins
[3] pstack README, GitHub, เข้าถึง 19 ต.ค. 2026. https://raw.githubusercontent.com/cursor/plugins/main/pstack/README.md
[4] Cursor, "Grok Bot for Teams and Enterprise", Cursor Docs, เข้าถึง 19 ต.ค. 2026. https://cursor.com/docs/grok-bot/teams
[5] Lauren Tan (@poteto), X (Twitter), เข้าถึง 19 ต.ค. 2026. https://x.com/poteto
[6] React Conf, "Lauren Tan", React Conf 2021 Speaker Profile. https://conf.reactjs.org/speakers/lauren