"ตอนนี้ผมแทบไม่ code แล้ว" — เมื่อ bot ทำ PR เอง
"ตอนนี้ผมแทบไม่ code แล้ว PR หลายอัน bot มันทำเอง ผมแค่ review แล้วก็กด"
นี่คือคำพูดของคนที่ดูแล product ที่มีคนใช้ 20,000 กว่าธุรกิจ ไม่ใช่คนที่เพิ่งหัด vibe code เล่นๆ
— คุณปั่น (Wasin Watthanasrisong) ผู้ก่อตั้งและ CTO ของ Paypers
อยู่สาย infra/blockchain มา 6-7 ปี ตั้งแต่ Thoughtworks ไปจนเป็น product manager ที่ Initia blockchain ของเกาหลี
ผมไปฟัง "ใช้ Claude Code ยังไง ให้ปังแบบ Paypers" ที่เขาขึ้นพูดในงาน Claude Code Bangkok Meetup มา เป็น session ที่หาฟังยากเพราะเป็นการเปิดหลังบ้านจริงๆ ว่า startup ที่ขึ้น production มีคนใช้จริงเขาเอา Claude Code ไปวางในงานยังไง
เหมาะมากสำหรับคนที่เลย stage เล่น Claude Code คนเดียวแล้ว อยากเอาไปใช้กับทีม กับงานจริง เลยอยากมาแชร์ให้ฟังครับ
1. Paypers เกิดจาก pain ตัวเอง
คุณปั่นกับพี่พลอยเคยเปิดบริษัทกันทั้งคู่ แล้วเกลียดการทำบัญชีค่าใช้จ่ายทุกเดือน เขาบอกว่า existing solution อย่าง FlowAccount หรือ Peak มันบังคับให้เราต้องรู้ก่อนว่าจะทำอะไร ต้องกรอก field ไหน เขาเลยทำให้มันง่ายลงเหลือแค่ส่งใบเสร็จเข้า LINE จาก 3 ชั่วโมงเหลือ 3 นาที ตอนนี้มี business ใช้ 20,000 กว่า process ค่าใช้จ่ายไปเกือบ 300,000 รายการภายในประมาณ 4 เดือน
2. ทำไมเลือก Claude Code
ตอนเริ่มโปรเจกต์เขาลองทั้ง Gemini ทั้ง Codex ช่วงที่ Claude 4 กับ 4.5 ออก แต่สรุปว่า Claude Code เข้ามือที่สุด รู้สึกว่ามันฉลาดที่สุด ณ ตอนนั้น เลยใช้ dev เป็นหลัก
3. มี stack ในใจอยู่ก่อนแล้ว
เขาไม่ได้ให้ AI research stack ให้ เพราะทำ side project มาเยอะ มี stack ที่เข้ามืออยู่แล้ว (Vercel, Supabase, เขียน infra ด้วย Terraform) จุดสำคัญคือเขาเลือก stack ที่ตัวเอง review โค้ดได้โดยไม่ต้องไปเรียนรู้อะไรใหม่
4. ของที่ยากที่สุดในการทำ product ไม่ใช่การ build feature เร็ว
เขาบอกว่าทุกคนเห็นในเน็ตว่าออกแอปได้เร็วมาก แต่ความจริงคือพอขึ้น production มีคนใช้ 200 คนแล้ว feature ต่อไปต้องคิดเสมอว่าจะ tie in กับของเดิมยังไง ของที่ขึ้นไปแล้วต่อให้มีคนใช้แค่ 5% ก็ตัดทิ้งไม่ได้ เพราะถ้าเขา unsubscribe เราก็รู้สึกแย่ ความยากคือการตัดสินใจว่า "อะไรไม่ทำ"
5. AI ยังตัดสินใจเรื่อง product ให้ไม่ค่อยได้
เขาใช้ AI ปรึกษาเรื่อง market size หรืออะไรที่ logical ได้ แต่พอเป็นเรื่องทิศทาง product เขาบอกตรงๆ ว่าข้อมูลในอินเทอร์เน็ตมันผิดเยอะกว่าถูก คนส่วนน้อยเท่านั้นที่มองเห็นปัญหาได้ ถ้าเรา prompt แบบ simple ยังไงก็ได้คำตอบไม่ดี สุดท้ายการตัดสินใจว่าทำไม่ทำมาจากการคุยกับลูกค้ามากกว่า
6. ไม่ทำ feedback form เพราะอยากโต้กับลูกค้า
เวลาลูกค้าขอ feature เขาให้ขอผ่าน LINE ไม่ทำเป็นฟอร์มให้กรอกแล้ว submit จบ เพราะเขาอยากถามต่อ ขอเบอร์ ไปคุยเพิ่ม เพื่อให้ได้ core insight ว่าทำไมถึงต้องการ แล้วเอา insight ของลูกค้าแต่ละกลุ่ม (ร้านชำ ปั๊มน้ำมัน) มา rank กันในทีมว่าอันไหน pain หนักสุดของกลุ่มที่ focus
7. write plan skill ที่ spawn agent มา review ตัวเอง
เขาเขียน skill สำหรับ plan เอง พอ plan เสร็จมันจะ spawn agent อีก 1-2 ตัวมา review plan นั้นว่ามี gap ตรงไหน critical ตรงไหน แล้วค่อยมาบอกทีหลังว่า fix อะไรไป เขาบอกว่ามันดีกว่า plan ปกติที่ทำรอบเดียวไม่มีใคร review
8. plan เป็น HTML ไม่ใช่ Markdown
อันนี้น่าสนใจมาก เขาให้ plan ออกมาเป็น HTML แบ่งสอง section ส่วนบนสำหรับคนอ่าน (ตัวเขาเอง) ส่วนล่างเป็น implementation plan ปกติ เขา focus 90% ที่ส่วนบน สั่งให้มันทำ diagram ของปัจจุบันกับของใหม่วาง side-by-side ให้เห็นเลยว่าก่อนทำเป็นยังไง หลังทำเป็นยังไง เพราะ MD ยาวๆ อ่านแล้วตาลาย แล้วหลุดเองโดยไม่รู้ตัว เขาบอกว่า prompt ที่ใช้คือ always create diagram (ไอเดียนี้เขาเห็นจากโพสต์ของ Thariq สมาชิกทีม Claude Code ใน X)
9. optimize ความเร็วด้วย parallel
ตอน implement มันจะคิดก่อนว่า plan นี้ทำ parallel ได้แค่ไหน ถ้าจะแก้ 10 ไฟล์ ทำพร้อมกันได้กี่ไฟล์ที่ไม่ทับกัน แล้วมี reviewer ตัวพ่อคอย aggregate กับ test ให้ผ่าน พอผ่านก็รัน reviewer กับ simplifier (/simplify ของ Claude Code) พร้อมกัน
10. bug fixer ที่ตื่นมาทำงานเองทุกชั่วโมง
เขาทำ bug fixer เป็น routine รันบน cloud ตื่นมาทุกชั่วโมง ไปดูใน Linear ว่ามี task ไหนติด bug แล้วทำเฉพาะที่ไม่ complex ไม่มี decision ไม่แตะ database (ไม่มี schema change) เขาเลือกใช้ routine ไม่ใช่ loop เพราะ loop ไม่เคลียร์ context และไม่อยู่ตลอดไป
11. ทั้งทีมต่อ database production แบบ read-only
แทนที่ dev จะโดนถามกระจายว่าวันนี้ยอดเท่าไร conversion เท่าไร เขาให้ทุกคนในทีมต่อ MCP เข้า database production แบบ read only แล้วถามใน Claude เอาเองได้เลย คนที่ไม่ใช่ dev ก็ใช้ได้
12. skill สำคัญกว่าที่คิด ไม่ใช่แค่เร็วขึ้น แต่ประหยัด token
เขาย้ำว่าอยากให้ทุกคนในทีมเขียน skill เพราะนอกจากทำงานเร็วขึ้น มันประหยัด token ด้วย เพราะเราบอกมันชัดเจนว่าต้องทำอะไรยังไง เช่น skill export LINE broadcast ที่พิมพ์ภาษาคนว่าอยากได้ user กลุ่มไหน มันก็ gen SQL query filter ข้อมูล export เป็น CSV พร้อมส่ง เพราะในskill เขาใส่ schema database ไว้ให้แล้ว
13. หา engineer แบบไหนในยุคนี้
พอ Claude เขียนโค้ดให้เยอะ เขาบอกว่าอยากได้คนที่หาปัญหาเก่งและไม่ท้อที่จะแก้ ไม่ใช่ engineer ที่รอรับ requirement มาแล้วทำตาม card อย่างเดียว เพราะคนแบบหลัง eventually น่าจะหายไป
14. vibe coding ขึ้น production ไม่ได้
ทั้งคุณจุ้นทั้งคุณปั่นเห็นตรงกันว่า vibe coding ยังขึ้น production ไม่ได้ มันเก่งเรื่อง validate idea ให้คนที่ไม่ใช่ dev ลองได้ทันที แต่สิ่งที่ delay การทำงานจริงไม่ใช่ feature ทำยาก มันคือการ make sure ว่า feature ใหม่ไม่ไป break คนที่ใช้อยู่เป็นพันเป็นหมื่นคน แล้ว vibe code ยิ่งสร้าง bug ใหม่เข้าไปเรื่อยๆ
15. คำแนะนำคนเริ่ม Claude Code
เขาบอกให้ศึกษา Claude Code แบบหมดไส้หมดพุงว่ามันทำอะไรได้บ้าง ทั้ง routine skill connector แล้วดูว่า anatomy ของมัน compatible กับปัญหาที่เราจะแก้ไหม จะได้ไม่เผลอ bake เครื่องมือใหม่ๆ เข้าไปทุก process ทั้งที่ของเดิมมันทำได้อยู่แล้ว และเขาแนะนำให้ลองไปอ่าน cc-prompt ที่มีคน reverse engineering ดูว่า Claude ส่ง prompt กับ tools อะไรบ้าง จะช่วยให้เราเขียน skill เขียน prompt ได้ดีขึ้น
สิ่งที่ผมชอบที่สุดในคลิปนี้คือเขาไม่ได้ขายฝันว่า AI ทำได้ทุกอย่าง เขาพูดชัดว่า Claude ไม่ได้เป็นภาพใหญ่ของ product มันแค่มาช่วยให้ productive ขึ้น ส่วนที่ตัดสินว่า product จะรอดหรือไม่ ยังต้องใช้ human touch กับ critical thinking อยู่ดี
ใครทำงานสาย dev หรือกำลังเอา AI ไปใช้กับทีม ไปฟังเต็มๆ ได้เลยครับ
https://www.youtube.com/watch?v=WR_L0l-GKcY
อยากใช้ AI กับงานจริงเป็นระบบ?
เรียน Claude Method — วิธีคิดและลงมือใช้ Claude/AI กับงานจริง ตั้งแต่วันแรก
📍 โพสต้นฉบับบน Facebook: AI กับ Peesamac