ฉันขอระบายอะไรหน่อย ก่อนสัมภาษณ์ที่ @cursor_ai ฉันไม่เคยใช้ Cursor จริงจังมาก่อนเลย
ที่ Meta, Claude Code กำลังมาแรงมาก ฉันถึงขนาดจ่ายเงิน $200 ต่อเดือนเพื่อใช้โปรเจกต์ส่วนตัว ฉันชอบความเรียบง่ายของมัน และรู้สึกว่าทำงานได้มีประสิทธิภาพเร็วมาก จุดที่ติดขัดสำหรับฉันคือการพัฒนาทักษะของตัวเองที่ทำให้ cc กลายเป็นอะไรก็ได้ที่ฉันต้องการ ฉันถึงขนาดเริ่มสร้างเครื่องมือ orchestrator ของตัวเองขึ้นมาบนนั้น
ระหว่างสัมภาษณ์ที่ออฟฟิศ ฉันใช้ Cursor ตลอด 2 วัน เพื่อสร้างโปรเจกต์สัมภาษณ์ ตอนนั้นยังไม่ถึง Cursor 3 เลยใช้ Editor Window ฉันใช้ vscode มาหลายปีจนคีย์ลัดส่วนใหญ่ยังอยู่ในความทรงจำ การกลับมาใช้ IDE ก็เลยไม่ยากเกินไป แต่ก็ต้องยอมรับว่าชั่วโมงแรกๆ ฉันคิดถึง cli มาก การต้องคลิกอะไรต่างๆ รู้สึกดึกดำบรรพ์มาก แต่ก็มีบางอย่างที่โดดเด่นจริงๆ
อย่างแรก โมเดลที่ฉันเคยใช้ตอนนั้น - Opus และ Codex - รู้สึกฉลาดกว่าในทางใดทางหนึ่ง และการสลับโมเดลได้ทันทีแล้วใช้ทั้งสองตัวพร้อมกันในส่วนต่างๆ ของโปรเจกต์ (Opus สำหรับ frontend, Codex สำหรับระบบ) มันเจ๋งมาก ก่อนสัมภาษณ์ ฉันก็พูดถึง adversarial review แบบหลายโมเดลอยู่แล้ว การทำแบบนี้ได้ใน UI โดยตรงเลยรู้สึกเป็นธรรมชาติมาก ยิ่งไปกว่านั้นคือการสร้าง subagent ของโมเดลต่างๆ ได้ เพื่อให้ได้สิ่งที่ดีที่สุดจากทั้งสองโลกในบทสนทนาเดียว
อย่างที่สอง การ compact รวดเร็วมาก ในฐานะผู้ใช้ cc ฉันเคยชินกับการ compact ที่ใช้เวลาหลายนาที เลยต้องคอยระวัง context และ plan usage ตลอดเวลา ดังนั้นฉันถึงตกใจมากที่ Cursor ทำได้เร็วขนาดนั้น จนแทบไม่ต้องดูว่าใช้ context ไปเท่าไหร่ มันทำงานได้ดี ในขณะที่ cc ฉันรู้สึกว่าโมเดลกลายเป็นโง่ลงมากหลังจาก compact
และอย่างที่สามที่สังเกตคือ GUI มีข้อดีเหนือ TUI มากแค่ไหน การเปิดแอปของคุณในเบราว์เซอร์ของ Cursor โดยตรงแล้วปรับดีไซน์ด้วย Design Mode รู้สึกเป็นธรรมชาติ และทำให้ฉันคิดว่า UI ที่ออกแบบมาเฉพาะทางจะทำให้การเขียนโค้ดแบบ agentic มีประสิทธิภาพมากขึ้นแค่ไหน
สร้าง Cursor ด้วย Cursor
ตั้งแต่เริ่มงานปลายเดือนมีนาคม ฉันทำงานหลักๆ บน Agent Window ของ Cursor 3 และใช้มันเป็นเครื่องมือหลักทุกวัน แม้ฉันยังคิดว่า cc เป็นผลิตภัณฑ์ที่ดีและมีทีมงานที่ยอดเยี่ยม แต่ฉันสังเกตว่าความเรียบง่ายของมันมักทำให้คนอยากสร้าง abstraction ของตัวเองขึ้นมาห่อหุ้มมัน ในงานก่อนหน้านี้ รู้สึกเหมือนมีเครื่องมือ orchestrator ภายในตัวใหม่ที่สร้างบน cc ประกาศออกมาทุกสัปดาห์
@bcherny พูดถึงแนวคิด "latent demand" นี้บ่อยๆ:
"มีแนวคิดเก่าแก่ในเรื่องผลิตภัณฑ์ที่เรียกว่า latent demand... คุณสร้างผลิตภัณฑ์ในแบบที่สามารถ hack ได้ แบบที่เปิดกว้างพอให้คนใช้มันในทางอื่นๆ จากนั้นคุณดูว่าคนใช้มันในทางไหน แล้วคุณก็สร้างเพื่อสิ่งนั้น"
นี่คือสิ่งที่เกิดขึ้น! ผู้คนที่มุ่งไปที่เครื่องมือ orchestration เผยให้เห็น latent demand ว่าการใช้ cli ทำให้คุณซึ่งเป็นมนุษย์เป็น orchestrator
แต่ทุก workflow ของ agent ที่ฉันเคยใช้เน้นผิดจุด การรัน CLI หลายตัวใน GUI พลาดประเด็นไปโดยสิ้นเชิง แนวทางที่ฉันสนใจคือการสร้างความไว้วางใจใน agent
ในฐานะอดีต engineering manager ฉันรู้ได้เร็วว่าการจัดการ agent คล้ายกับการสร้างทีมวิศวกรมนุษย์ พนักงานใหม่ต้องได้รับการ onboarding เพื่อให้เข้าใจ codebase และวิธีการทำงาน พวกเขามาพร้อมทักษะที่เรียนรู้จากประสบการณ์ที่ผ่านมา เช่น การ debug การเขียนโค้ดและ test ที่มีคุณภาพสูง และการสื่อสาร
Agent ก็เหมือนพนักงานใหม่ที่อยู่ในสภาวะความจำเสื่อมและโง่เขลาตลอดเวลา พวกเขาจำสิ่งที่คุณบอกไม่ได้ และไม่เคยเรียนรู้อะไรใหม่ๆ แต่เราสามารถติดตั้งกฎ ทักษะ เครื่องมือ และความจำระยะยาวให้พวกเขาได้ ซึ่งพอจะเทียบเคียงได้ พวกเขามีความสามารถแต่โง่ และสอนได้ดีมาก และฉันมองเห็น failure mode ของพวกเขาเป็นโอกาสที่จะสอนทุกอย่างที่ฉันรู้เกี่ยวกับการทำวิศวกรรมที่ลึกซึ้งและเข้มงวด
เพราะเมื่อไม่มีความเข้มงวด agent จะทำทุกอย่างเพื่อเขียนโค้ดที่คุณขออย่างประจบประแจง และมันสามารถเขียนได้มากมายมหาศาล การทำ parallelization แบบไร้เดียงสาแค่ทำให้มันเขียนขยะได้เร็วขึ้น
ถ้าอยากไปเร็ว ต้องลงลึกก่อน
ฉันคิดว่าการ orchestrate agent สามารถทำได้อย่างมีประสิทธิภาพ แต่เราต้องลงลึกก่อน
ฉันเปิด source pstack ซึ่งเป็นชุดทักษะและหลักการวิศวกรรมส่วนตัวที่ฉันใช้ทุกวันเพื่อสร้าง @cursor_ai ฉันเริ่มพัฒนา iteration แรกๆ ของทักษะเหล่านี้ในโปรเจกต์ส่วนตัว และปรับปรุงมันเรื่อยมา
ดาวน์โหลดได้ที่นี่: https://cursor.com/marketplace/cursor/pstack
ทักษะเหล่านี้กลายเป็นหนึ่งในทักษะที่ทีม Cursor ใช้มากที่สุด ฉันเลยตื่นเต้นที่จะแบ่งปันให้ทุกคน
pstack สอน agent ให้เข้มงวดมากขึ้นโดยใช้หลายโมเดล ฉันนำ failure mode ทั้งหมดที่สังเกตเห็นมาเปลี่ยนเป็นทักษะ หัวใจของปลั๊กอินคือ /poteto-mode ซึ่งเป็นทักษะระดับสูงที่ให้ playbook ที่ถูกต้องแก่ agent สำหรับงานที่ได้รับ เป้าหมายไม่ใช่ LOC สูงสุด แต่ตรงกันข้าม: ผลกระทบสูงสุดด้วยโค้ดน้อยที่สุด
ความเข้มงวดถูกนำมาใช้โดยการเข้าถึงปัญหาแบบเดียวกับวิศวกรที่มีประสบการณ์ ตัวอย่างเช่น วิธีที่ดีในการ debug คือการค้นหาแบบ binary search ในพื้นที่ปัญหา คุณเริ่มต้นด้วยสมมติฐานบางอย่างเกี่ยวกับสิ่งที่อาจเกิดขึ้น จากนั้นพยายามตัดทิ้งอย่างเป็นระบบจนกว่าจะเข้าใกล้สาเหตุที่แท้จริง ถ้าทำให้เกิดซ้ำได้ยาก คุณอาจลองทำให้บั๊กเกิดขึ้นโดยการจำลอง หรือลองเพิ่ม instrumentation หรือ console logging เพื่อตรวจสอบสถานะโปรแกรมขณะทำงาน
ขั้นตอนเหล่านี้เป็น playbook ที่ agent สามารถใช้เพื่อ debug ปัญหาอย่างละเอียดแทนการเดา ซึ่งพวกเขาชอบทำถ้าคุณปล่อยให้ทำ pstack มาพร้อมกับทักษะและ playbook มากมายที่ช่วยให้คุณเข้าถึงวิศวกรรมซอฟต์แวร์ด้วยความเข้มงวดระดับนี้ ปัจจุบันฉันมี playbook สำหรับ:
- การสร้างทักษะและการประเมินผล
- การทำงานอัตโนมัติ
- การแก้ไขบั๊กและการตรวจสอบรันไทม์
- การพัฒนาฟีเจอร์
- การตรวจสอบความเท่าเทียมทางภาพและการสร้างต้นแบบ
- และอื่นๆ
เมื่อใดก็ตามที่คุณต้องการความเข้มงวด ให้ขึ้นต้น prompt ด้วย /poteto-mode ตัวอย่างเช่น:
คุณยังสามารถเรียกใช้ทักษะอื่นๆ ตามต้องการ:
- /how: คุณต้องการคำอธิบายว่าระบบย่อยทำงานอย่างไร
- /why: คุณต้องการรู้ว่าทำไมบางสิ่งถึงถูกสร้างแบบนี้ ใช้ MCP ที่มีอยู่เพื่อสอบถามแต่ละหมวดหมู่หลักฐานแบบขนาน (source control, issue tracker, เอกสารระยะยาว, แชทเรียลไทม์, infra observability, error tracking, analytics warehouse)
- /architect: คุณกำลังจะเขียนโค้ดที่ข้ามขอบเขตฟังก์ชัน และต้องการให้ type และ data structure ถูกกำหนดก่อน
- /arena: คุณต้องการให้ N ความพยายามแบบขนานในสิ่งเดียวกัน จากนั้นเลือกส่วนที่ดีที่สุดของแต่ละอัน
- /interrogate: คุณต้องการให้โมเดลต่างๆ ตรวจสอบบางสิ่งแบบ adversarial
- /tdd: คุณกำลังแก้ไขบั๊ก เขียน test ที่ล้มเหลวก่อน จากนั้นจึงแก้ไข
- /unslop: คุณกำลังทำความสะอาดงานเขียน AI ทุกประเภท ทำให้พวกเขาพูดอย่างตรงไปตรงมา
- /reflect: คุณต้องการปรับปรุงทักษะอย่างต่อเนื่องหลังจากการสนทนายาว
- /figure-it-out: กำลังทำอะไรที่ผิดปกติ? ออกแบบ playbook ที่เข้มงวดและตรวจสอบได้สำหรับงานนั้น
- /show-me-your-work: คุณต้องการร่องรอยการตัดสินใจที่ตรวจสอบได้ บันทึกการตัดสินใจลงใน tsv ที่คุณ commit ได้
และสุดท้าย คุณสามารถสร้างทักษะโหมดของคุณเองด้วย /automate-me มันขุด transcript ล่าสุดของคุณ ร่างทักษะ your-mode จากวิธีที่คุณทำงาน และส่งผ่าน pstack ด้านล่าง
pstack ทำงานกับเครื่องมือเขียนโค้ดแบบ agentic ใดๆ แต่ทำงานได้ดีเป็นพิเศษในเครื่องมือหลายโมเดลอย่าง Cursor ทักษะหลายอย่างใช้ workflow หลายโมเดลเพื่อใช้ประโยชน์จากจุดแข็งและจุดอ่อนเฉพาะของแต่ละโมเดล มันคือ agent orchestration แต่ใช้แบบ depth first แทนที่จะเป็น breadth first
คอขวดของ agent คือการตรวจสอบ Agent สามารถเขียนโค้ดจำนวนมากได้อย่างรวดเร็ว การทำให้แน่ใจว่าทั้งหมดถูกต้องนั้นยากมาก เมื่อคุณไปถึงจุดนั้น การทำ agent parallelism ที่แท้จริง เหมือนใน dark factory สำหรับซอฟต์แวร์ อาจเป็นไปได้
แต่ก่อนอื่น เราต้องลงลึกและเข้มงวด ฉันคิดว่าเราจะไปถึงจุดนั้นได้ด้วยการเพิ่มความไว้วางใจ
ลองใช้ pstack และบอกฉันว่าคุณคิดอย่างไร
เซนและศิลปะการบำรุงรักษาซอฟต์แวร์
ทักษะเหล่านี้ช่วยให้ฉันเคลื่อนไหวด้วยความมั่นใจมากขึ้นเมื่อเขียนโค้ด แต่การบำรุงรักษาโค้ดตอนนี้เป็นฝันร้ายเพราะ agent เขียนโค้ดทั้งหมด บั๊ก ปัญหาประสิทธิภาพ และคำขอฟีเจอร์ยังคงใช้เวลาในการจัดการ และตอนนี้มีโค้ดมากขึ้นมาก!
ฉันใช้ Cursor automations อย่างหนักที่ Cursor พวกมันคือ cloud agent ที่สามารถกำหนดเวลาหรือรันตามเหตุการณ์ เช่น ข้อความใหม่ใน Slack channel ตัวอย่างหนึ่งคือบอท Benny ของฉัน ฉันให้ทักษะเดียวกับที่ฉันมีใน pstack แก่เขา
Benny ยังคงเป็นงานที่กำลังดำเนินการ แต่วิสัยทัศน์ของฉันคือการทำให้กระบวนการบำรุงรักษาซอฟต์แวร์เป็นอัตโนมัติมากที่สุด แนวคิดคือ: ถ้าตอนนี้เรามีความมั่นใจที่จะ "one shot" ปัญหาส่วนใหญ่ด้วย pstack โดยมีความแน่นอนในระดับดีว่า PR มีคุณภาพสูง แน่นอนว่าเราสามารถทำให้ feedback เป็นอัตโนมัติได้เช่นกัน
โรงงานนี้เริ่มต้นด้วยการ triage: รวบรวมข้อมูลจากพนักงานเกี่ยวกับรายงานบั๊ก เรา dogfood Cursor มาก ดังนั้นเราจึงได้รับ feedback มากมายจากพนักงานเกี่ยวกับ release candidate Benny เข้าใจไฟล์รูปภาพและวิดีโอที่แนบมา สำรวจ codebase โดยใช้ทักษะ pstack และพูดคุยกับผู้รายงานเพื่อขอข้อมูลเกี่ยวกับขั้นตอนการทำซ้ำถ้าไม่ชัดเจน
นี่เป็นส่วนสำคัญของกระบวนการรายงานบั๊ก หากไม่มีขั้นตอนการทำซ้ำที่ชัดเจนและความเข้าใจในสิ่งที่เสียหาย agent สามารถเดาวิธีแก้ไขได้เท่านั้น เราต้องให้ความเข้าใจที่ชัดเจนแก่พวกเขาว่ามันเสียตรงไหนและอย่างไร
เมื่อ triage เสร็จแล้ว Benny สร้าง ticket พร้อมสิ่งที่ค้นพบจากการดูโค้ด git history สำหรับ regression ล่าสุด Slack สำหรับข้อความอื่นๆ เกี่ยวกับบั๊กเดียวกัน และแม้แต่ Notion สำหรับการตัดสินใจด้านดีไซน์และผลิตภัณฑ์ว่าฟีเจอร์ควรทำงานอย่างไร: มันเป็นบั๊ก หรือถูกออกแบบให้ทำงานแบบนี้?
หลังจาก ticket ถูกยื่น บอท Benny ตัวอื่นรับมันต่อโดยใช้ทักษะอื่นที่ฉันสร้างชื่อ /orchestrate
ก่อนอื่น เขาพยายามทำซ้ำปัญหาผ่านการใช้คอมพิวเตอร์ Cursor Cloud Agents สามารถรัน Cursor เองในคลาวด์ ซึ่งพวกมันโต้ตอบกับเดสก์ท็อป คลิกสิ่งต่างๆ และส่งคีย์บอร์ด input ภายในใช้ทักษะเพิ่มเติมที่ฉันสร้างเพื่อควบคุมผลิตภัณฑ์ของเราโดยทางโปรแกรมโดยใช้โปรโตคอลเช่น CDP หรือเทียบเท่า
สิ่งนี้ช่วยให้เราสามารถแสดงว่ารายงานบั๊กสามารถทำซ้ำได้หรือไม่ ถ้ามันทำซ้ำบั๊กได้อย่างสม่ำเสมอ เขาจะพยายามแก้ไข ถ้าเป็นปัญหา perf Benny สามารถทำ CPU trace และ heap snapshot ก่อนและหลัง Subplanner สร้าง worker เพิ่มเพื่อตรวจสอบการแก้ไขโดยใช้ทักษะ pstack และตรวจสอบงานกับ ticket ว่ามันถูกแก้ไขหรือไม่
Worker เพิ่มเติมถูกสร้างขึ้นในการรันนี้เพื่อถ่ายวิดีโอก่อนและหลัง และสุดท้าย worker เปิด PR เพื่อตรวจสอบพร้อมวิดีโอในคำอธิบาย
ทั้งหมดนี้ยังคงเป็นงานที่กำลังดำเนินการและมีอีกมากที่ต้องทำ แต่ฉันตื่นเต้นที่จะมีทีม agent ที่ช่วยฉันแก้ไขบั๊กด้วยความมั่นใจในขณะที่ฉันนอนหลับหรือทำอย่างอื่น การทำให้ code review ปรับขนาดได้เป็นอีกพื้นที่ใหญ่ และฉันคิดว่า Cursor จะมีฟีเจอร์ใหม่ๆ ที่เจ๋งเพื่อช่วย
แต่กุญแจสำคัญในการสร้าง software factory ของคุณเองคือความไว้วางใจ เว้นแต่คุณจะไว้วางใจ agent ให้เป็นเจ้าของปัญหาตั้งแต่ต้นจนจบ รวมถึงการตรวจสอบ คุณจะไม่สามารถทำให้กระบวนการของคุณเป็นอัตโนมัติได้ เมื่อคุณเพิ่มความไว้วางใจโดยใช้ปลั๊กอินอย่าง pstack ที่ให้ความลึกทางวิศวกรรมแก่ agent ของคุณมากขึ้น คุณสามารถเริ่มจัดการกับปัญหาที่ท้าทายมากขึ้น การพยายาม parallelize agent ที่คุณยังไม่ไว้วางใจเป็นการสิ้นเปลือง token อย่างมหาศาลและเพิ่มขยะใน codebase ของคุณ
ขอบคุณที่อ่าน!
