🎞️ Videos → ใช้ Claude Code ยังไง ให้ปังแบบ Paypers

แนะนำตัว: จากสาย Consult สู่การทำ Startup เป็นของตัวเอง0:00

ก็ จริงๆงานแรกแบบ full-time น่าจะเป็น Thoughtworks

ซึ่งก็เจอพี่จุ้น เจอหลายๆคน แล้วก็ตอนนั้นทำ software consultant เนาะ ก็ไปหาลูกค้าที่เป็นแบงก์ หรือว่าลูกค้า Thoughtworks ต่างๆ ก็จะลงพื้นที่ ไปคุยกับลูกค้าจริงๆ แล้วก็ gather requirement ขึ้นมาทำ แล้วก็ต่อไปก็จะเข้าสู่โลก blockchain เลยนะครับ ก็คือผมอยู่ blockchain น่าจะแบบ 6-7 ปี ส่วนใหญ่จะเป็น lead ด้าน infrastructure ซะมากกว่า ก็คือพวกแบบ Google Cloud, ทำ architecture เขียน Terraform อะไรประมาณนั้น ก็เป็น founding member ของ crypto payment gateway อันหนึ่ง แล้วก็เป็น infra lead ของ

เขาเรียกว่าเป็น explorer ใครเคยใช้ blockchain อาจจะเคยแบบเข้า Etherscan อะไรพวกนี้ จะเป็น block explorer ของ Cosmos นะครับ แล้วก็สุดท้ายคือเป็น integration lead แล้วก็ product manager ที่ Initia Initia ก็คือเป็น blockchain ของเกาหลี อ่า แปลว่าประสบการณ์ blockchain ก็ค่อนข้างเยอะ แล้วก็ส่วนใหญ่จะเป็นแนว infra, back-end เออ infra แล้วก็ product ชอบ 2 ซีก

จุดเริ่มต้น Paypers: ลดเวลาทำบัญชีค่าใช้จ่ายบริษัทที่น่าปวดหัว1:16

โอเค ถ้างั้นเดี๋ยวเรามาเข้าส่วนของ Paypers ปัจจุบัน

อ่า ได้ โอเค เกริ่นก่อน ผมรู้สึกว่าผมไม่ค่อยเก่ง การใช้ Claude Code มาก ไม่แน่ใจว่าใครเป็น dev บ้างครับ ใครเป็น dev โอเค ใครแบบไม่ใช่ dev บ้าง ทำทำอะไรครับพี่ system โอเค เออ ผมก็ใช้ Claude Code มาน่าจะเท่าๆกับทุกคนเนาะ อาจจะไม่ได้แบบ focus ที่ optimize อะไรมาก แต่คิดว่าน่าจะเป็น real use case ที่น่าจะแชร์ได้ ครับ ก็ Paypers อันนี้เปิดมาต้นปี

ก็ประมาณกลางๆ หรือปลายๆ เดือน Jan นะครับ ตอนนี้ก็เราทำให้การจัดการเรื่องค่าใช้จ่าย ของบริษัททำได้ง่ายแบบไม่ต้องคิดมาก คือผมรู้สึกว่า ผมเองก็เคยเปิดบริษัทใช่ไหม แล้วรู้สึกว่าการทำบัญชีค่าใช้จ่ายทุกเดือน มันค่อนข้างปวดหัว แล้วผมรู้สึกว่า existing solution เนี่ย ผมต้องเข้าใจว่าผมจะทำอะไร เช่น ผมเข้า FlowAccount ผมเข้า Peak ผมเข้าอะไรก็แล้วแต่ ผมต้องรู้ว่าผมกำลังจะทำอะไร ผมต้องกรอก field ไหนบ้าง ผมรู้สึกว่าอะไรพวกนี้มันน่าจะง่ายได้

ก็เลยเริ่มทำกับพี่พลอย นะครับ เป็นทำให้การกรอกค่าใช้จ่าย

พวกนี้ไม่ต้องคิดเยอะนะครับ ประมาณนั้นก็คือ 3 ชั่วโมงเหลือได้ใน 3 นาทีนะครับ ก็ตอนนี้มี business อยู่ 20,000 กว่า แล้วก็ process ค่าใช้จ่ายไปแล้วเกือบ 300,000 ละนะครับ อันนี้ภายในกี่ ภายในกี่เดือน ก็

เกือบ 4 เดือนครับ เพียงแค่ 4 เดือนนะครับ โอเค ทีนี้คำถามแรกเลยก็คือ เมื่อกี้ เหมือนเป็นมาจาก pain point ตัวเอง ใช่ pain point พี่พลอย และ pain point ผม ที่เรามีบริษัททั้งคู่ แล้วก็รู้สึกไม่ชอบการทำบัญชี อะไรพวกนี้ครับ โอเค

ใช้ Tech Stack ที่ถนัดเพื่อประหยัดเวลาตอนทำ Code Review3:05

แล้วเริ่ม เริ่มเข้าไปที่ Claude Code ดีกว่า

เราได้ใช้ Claude Code ในการแบบ ตั้งแต่ศูนย์เลยปะจากโปรเจกต์นี้ มีการ setup อะไรยังไงบ้าง ตอนนั้นน่าจะลองหลายอัน เพราะว่าผมก็ไม่ได้ มันน่าจะตอนที่แบบ Claude 4 ออก หรือ 4.5 ออก แถวๆ เนี้ย เออ เราก็ลอง Gemini เราก็ลอง Codex เออ แต่ตอนนั้นรู้สึกว่า Claude เข้ามือที่สุดละกัน Claude Code มันออกมาแล้ว เออ ผมรู้สึกว่ามันฉลาดที่สุด ณ ตอนนั้น เออ ก็เลยใช้ Claude Code ในการ dev ซะส่วนใหญ่ ใช่ครับ แล้วตัวตอนที่เราเริ่มโปรเจกต์ เอาช่วงเริ่มโปรเจกต์ก่อนละกันนะครับ เราคุยกับมัน คือเรามี stack อยู่ในใจอยู่แล้วไหม

หรือว่าเราเริ่ม research กับตัว Claude Code ก่อน

อะไรพวกนี้ มี stack ในใจ เพราะว่าผมเป็นคนที่อาจจะทำโปรเจกต์ส่วนตัว มี side project ก็ทำเยอะ แล้วเรามันมี stack ที่เข้ามืออยู่แล้ว อ๋อ โอเค แปลว่าเรามี... ใช้แบบ Vercel, Supabase แล้วก็เขียน infra ทุกอย่างด้วย Terraform อะไรพวกเนี้ย มันอยาก optimize ให้เราสามารถรีวิวโค้ดได้ โดยที่ไม่ต้องไปเรียนรู้อะไรใหม่ๆ ขนาดนั้น โอเค แปลว่าเรามี stack อยู่ในใจแล้ว ใช่ เราแค่เหมือนกับบอกให้ Claude มัน

หมายถึงว่าเราบอก Claude ให้มันจัดการ เขียนโค้ดยังไงดีกว่า เอาอย่างนี้ ตอนช่วงแรกๆ ที่แบบเริ่ม

AI ช่วยประเมินขนาดตลาดได้ แต่ยังตัดสินใจทิศทางของ Product ไม่ดีพอ4:36

ช่วงแรกผมว่าไม่ได้ complicated นะ ก็คือ complicated ตรง requirement มากกว่า ว่าเราจะเอาอะไร ไม่เอาอะไร เพราะว่าผมว่าในอินเทอร์เน็ตตอนนี้ ทุกคนเห็นการออกแอปมันออกมาเร็วมาก ถูกไหม แต่ว่าความเป็นจริงคือ สมมติถ้าเราขึ้น production แล้ว แล้วมีลูกค้าใช้ 200 คนแล้ว แล้วเราจะทำ feature ต่อไป มันต้องคิดถึงเสมอว่า เอ้ย มันจะ ต้อง tie in กับของที่มีอยู่แล้วยังไงบ้าง ถ้าไม่ tie in มันจะรู้สึกว่าเป็น product ที่ไม่ complete หรือเปล่า ของที่ขึ้นไปแล้วบางที สมมติว่ามีคนแค่ 5% ใช้

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

คือในส่วนนี้มันเป็นเรื่องของการตัดสินใจใช่ไหม แต่เรามีได้คุยกับ AI ไหม หรือว่าส่วนใหญ่มันมาจากฝั่ง product ว่าอะไรที่ควรทำ หรืออะไรที่ไม่ควรทำ มีปรึกษา มันปรึกษา AI เนี่ย น่าจะเป็นปรึกษาเรื่อง market size อะไรพวกนี้มากกว่า อะไรที่มันค่อนข้าง logical ว่า อันนี้ น่าทำไหม pain มันใหญ่พอหรือเปล่า ตลาดมันสามารถไปถึงแบบ ร้อยล้านพันล้านได้ไหม แต่ว่าผมว่าถ้า feature ไหนที่

อาจจะถามว่า เอ้ย คู่แข่งทำอะไรได้บ้างแล้ว มี แต่สุดท้ายแล้วเราจะมองเห็นภาพ ของ product เราแบบไหน ผมว่าตอนนี้มันยังไม่ค่อยตอบโจทย์ โอเค ก็คือ แปลว่า Claude Code หรือ AI จะ ยังไม่ work ในมุมที่เป็นการ ช่วยตัดสินใจเรื่องของ product หรือผมอาจจะ prompt ไม่ดีก็ได้นะ แต่ผมรู้สึกว่าข้อมูลในอินเทอร์เน็ตมัน ผิดเยอะกว่าถูก หมายถึงว่า ถ้าเรายอมรับว่าคน

ผิดมากกว่าคนถูก แปลว่าเราถาม Claude แบบ simple ยังไงก็ได้คำตอบที่ไม่ดี คนส่วนน้อยมันถูก คนส่วนน้อยมันสามารถมองเห็นปัญหาได้ ฉะนั้นเรารู้สึกว่า อาจจะต้อง prompt แบบค่อนข้างฉลาดมาก แล้วก็คุยกับมันเยอะมาก กว่าจะออกมาเป็นแบบ ควรทำไม่ควรทำ ส่วนใหญ่จะแบบมาจากคุยกับลูกค้ามากกว่าครับ ถ้าอะไรตัดสินใจว่า ทำไม่ทำ ผมว่าคือลูกค้ามากกว่า

โอเคครับ

พูดคุยหา Core Insight จากลูกค้า ดีกว่าการใช้แบบฟอร์มรับ Feedback7:03

อันนี้เป็นแบบว่า intro ช่วงแรกนะครับ เดี๋ยวเราไปลงลึกในส่วน Claude Code ละกัน ว่าใช้ยังไง อยากให้ปั่นเล่าหน่อยว่า ถ้าเป็น routine เอาช่วง recently ที่ผ่านมาก็ได้ routine ของการ develop feature อะไรสักอย่างหนึ่ง routine ของเราเป็นยังไง โอเค

ตอนนี้ พอเรา launch มาในระดับหนึ่ง มีลูกค้าเข้ามาเยอะ เราจะเริ่มมี คือเราจะมีสองช่องนะ เป็น Paypers ธรรมดา เป็น LINE chatbot ที่เขาใช้งานอยู่ตลอดเวลา คุยกับน้องเรื่องแบบค่าใช้จ่ายตัวเอง แบบ เดือนนี้ค่าใช้จ่ายหมดไหนเยอะสุด เดือนที่แล้วเป็นยังไงอะไรอย่างนี้ หรือส่งใบเสร็จ อีกอันหนึ่งจะเป็น LINE support ซึ่งอันนี้คนเท่านั้นนะ ในการคุยด้วย ฉะนั้นเราก็จะไว้ตอบลูกค้า

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

คือสุดท้ายแล้วเราอยากได้ core insight ว่าทำไมถึงต้องการ ฉะนั้นเราไม่อยากจบแค่แบบเป็น feedback form ก็จะประมาณนั้น แล้วพอเรามี core insight ค่อนข้างเยอะ ว่า ลูกค้าประเภทนี้ที่เขาทำร้านชำ ลูกค้าประเภทนี้ที่เขาทำแบบปั๊มน้ำมัน แต่ละคนอยากต้องการสิ่งไหนเพราะอะไร แล้วเข้ามา rank กันในทีมนี่แหละว่า เออ อันนี้ pain หนัก ของคนกลุ่มนี้ที่เรา focus นะ ฉะนั้น ทำอันนี้ก่อน อันนี้ที่ก็มีคนเรียกร้องมาเหมือนกัน ฉะนั้นเราพักไว้ก่อน ประมาณนี้ แล้วทีนี้พอมันเข้าไปใน พี่เดาว่า มันน่าจะต้องเข้าไปใน board สัก board หนึ่ง ที่เราเอาไว้จัดการเรื่องของ task management อะไรพวกนี้ใช่ไหม แล้วตอนที่ dev

แบบ feature development อย่างนี้ เรามีการใช้ Claude Code แบบยังไงบ้าง เรามี workflow อะไรไหม หรือว่ามี ticket มา ก็เปิด session ใหม่ แล้วก็ค่อยๆ คุยกับมันไป อะไรประมาณนี้

คือ เดี๋ยวนะ สมมติ

ก็ Linear เหรอ ก็ จริง ๆ อ่ะ ผมว่ามันเพิ่งเริ่ม มันเพิ่งเริ่มละเอียดขึ้น แต่ก่อนมีผมกับพี่พลอย 2 คน แล้วเราก็จะเขียนกันแบบ requirement ค่อนข้างที่จะไม่ชัด เออ อืม แต่ว่าตอนนี้มันค่อนข้างชัดเจนขึ้น และหลาย ๆ อย่าง บางที เอ่อ PR หลาย ๆ อัน bot มันทำเลยด้วยซ้ำ ผมไม่ได้แตะเลย ผม review แล้วก็กด อืม แต่ว่า อย่างเช่น

จดรายละเอียดแจ้ง Bug ให้ชัดเจน และใช้ Superset เป็น Terminal ช่วยอ่าน PR9:45

อันนี้คือ Linear ป่ะ ใช่ อันนี้คือ Linear อะไรดี อย่างอันนี้เป็นอันหนึ่งที่ อาจจะไม่ได้ละเอียดมาก แต่ว่านี้เป็น bug ใช่ไหม ซึ่งอันนี้ bug ที่

น้องในทีมเป็นคนเขียน แต่ว่าอันนี้

ผมไม่ได้ทำเอง เออ โทษที ๆ ไอ้ description อะไรพวกนี้ ณ ตอนนี้ ยังเป็นคนเขียนอยู่ป่ะ แล้วแต่อัน แล้วแต่ แล้วแต่อัน ใช่ ถ้าเป็น bug เนี่ย เราจะพยายามเขียนเองทั้งหมด เพราะว่า อยากเขียน reproduction step ให้ clear อืม แล้วบางทีเนี่ย เราอยากเขียนเป็นใน bug ดูว่า ใครเจอ ลูกค้า ลูกค้าคนไหนใน LINE เจอ คือถ้าเราใส่ลูกค้าคนไหนใน LINE ชื่อเข้าไปอ่ะ ตอน bot มัน ทำงานอ่ะครับ มันจะ query database ได้ว่า ลูกค้าที่มี LINE ID นี้ คือใคร แล้วเข้าไปดูได้ว่าแบบ เอ้ย receipt นี้ หน้าตาเป็นยังไงจริงๆ อืม แล้วเราก็จะแก้ อืม โอเค ประมาณนั้น แต่ว่า สมมติว่า เป็นอันนี้ เราก็ ผม ส่วนใหญ่ผมก็ก๊อป ก๊อป ก๊อปอันนี้มา ใช่ไหม อืม แล้วผมก็ใช้ Superset ไม่แน่ใจว่า มีใครใช้ Superset มั้ย อันนี้คือ Superset คืออะไร ไม่รู้ โอเค อันนี้คือคล้าย ๆ

พวก Warp พวก iTerm เนี่ย มันก็จะเป็นแบบ terminal ใช่ไหม ที่ run server จริงๆ ก็ run console session ในนี้ได้ อืม แต่ผมรู้สึกว่า Superset อ่ะ มันคือเหมือน terminal ที่สร้างมาเพื่อการแบบ

vibe code นิดหนึ่ง อ่า แต่ว่า มันก็ยังเห็นเนี่ย ไฟล์ทั้งหมดอยู่ดี เห็น change ทั้งหมดอยู่ดี พอผมเปิดขึ้น PR ปุ๊บ ก็เห็นว่า อันนี้ อันนี้ไม่ใช่ PR เนาะ แต่ว่า สมมติว่า เป็น PR แล้วมันมี run check อะไรอย่างนี้ มันก็จะขึ้นเลย อ๋อ อันนี้ อันนี้เสียเงินไหมครับ อะไรนะฮะ เสียเงินหรือเปล่า Superset ไม่เสีย แนว Conductor ป่ะ เคยได้ยิน แนว Conductor แนว Conductor

แต่ว่า Conductor อ่ะ มัน มัน worktree only อันนี้ผมสามารถทำใน

ทำใน main repo ได้ ถ้าผมจำไม่ผิดนะ Conductor มันรู้สึกว่า worktree only เท่านั้น อ่า ๆ เออ ก็

โอเค ลอง ลอง ไป เก็บไว้ได้นะครับ Superset Superset กับ Conductor อ่ะ มี 2 ค่ายให้เลือก

เรียก อันนี้ ก็เป็น อันหนึ่งที่ดีนะครับ

สร้าง Agent ไว้ดับเบิลเช็กรีวิวแผนงานและปิดช่องโหว่ก่อนลงมือเขียนโค้ดจริง12:01

ที่โชว์ขึ้นมา เพราะว่า สำหรับคน ที่ dev เริ่ม เริ่มจะต้องมี session เยอะขึ้น อะไรอย่างนี้ เราก็ จะเริ่ม มองหา เครื่องมือ ที่มันมาช่วย ให้เรา เห็นภาพ ได้ กว้างขึ้น

สลับ นู่นนี่นั่น อะไรอย่างนี้ ปกติ ที่ผม ทำก็คือ สมมติว่า ผมจะอ่าน Linear ก่อน ว่า Linear เนี่ย ครบไหม ขาดอะไรไหม zoom นิดหนึ่ง ได้ไหม zoom อ๋อ ได้ๆ ซึ่ง ผมปิด อันอื่น ก่อนนะ

เห็นไหมครับ โอเค ดีขึ้นครับ ก็ ถ้า Linear card มันค่อนข้าง clear ผมอ่านแล้ว ผมรู้สึกว่า ไม่ติด อะไรเลย ผมก็ จะใช้ write plan Linear นี่คือ เราก็ ต้องต่อ MCP อะไรพวกนี้ ปะ ถูกๆ ก็จะ อันนี้เป็น skill ที่ผม เขียนเอง สำหรับการ plan มีความลับ ปะ มีความลับ ปะ ไม่ๆ ไม่ลับ ไม่ลับ โอเค

ก็คือ มันก็ จะอ่าน ก่อนใช่ไหมครับ แล้วมันก็ จะ ทำความเข้าใจ แล้วก็ plan ออกมา ที่เหมือน plan ปกติ แต่ทีนี้ สิ่งที่มันต่าง 2 อย่างหลักๆ อันแรก ก็คือ plan เสร็จ เนี่ย จะ spawn agent อีกตัว สองตัว เพื่อมา review plan นี้ ว่า เจอ gap ตรงไหน หรือเปล่า มันจะ เข้าไปอ่าน Linear task แล้วก็ อ่าน plan ว่า จะแก้ อะไรบ้าง แล้วก็ find gaps

gaps ที่เป็น critical important fix เลย แล้วมา บอกผม ทีหลัง ว่ามัน fix อะไร เราก็ จะได้ plan ที่รู้สึกว่า ส่วนตัว นะ ผมรู้สึกว่า มันดีกว่า ผมทำ plan ปกติ ถ้า plan ปกติ มันรอบเดียว ไม่มีใคร review agent ไม่ได้ review เพิ่ม อะไรอย่างนี้ แต่อันนี้ คือมัน review อีกสองตัว แล้วผม ได้ plan ที่ โอเค อาจจะ มั่นใจ ระดับหนึ่ง แล้ว สิ่งที่มัน จะ gen ก็คือ จะเป็น HTML ตอนนี้ มีใคร plan ออกมาเป็น MD หรือ HTML ไหม

MD HTML มีไหมครับ

สั่ง AI ให้ออกแบบ Plan เป็น HTML Interactive เห็นภาพชัดเจนกว่า Markdown13:58

โอเค เพราะว่า ช่วงวันสองวันก่อน เพิ่งมี Twitter ว่า เฮ้ย คุณลองใช้ HTML สิ ซึ่ง ผมรู้สึกว่า ผมชอบมาก

สำหรับโพสต์อันนั้นนะครับ ลอง search x.com แล้วก็ คนโพสต์ชื่อ Thariq เป็น member ใน Claude Code นะครับ Thariq t h a r i q

เขาเขียนเป็นเหมือนเป็นโพสต์ไว้ใน Twitter

ซึ่งเวลาผมให้มันเขียน plan เนี่ย ผมจะแบ่งเป็นสอง section section สำหรับ human read ก็คือผม read ผมอ่าน กับ section อีกอันหนึ่งคือ เป็น plan ปกติที่ปกติ Claude ทำ ก็คือให้เป็นข้างหลัง implementation plan ใช่ไหม ซึ่งผมอะ จะ focus ประมาณ 90% กับข้างบน ให้มันทำ diagram เยอะๆ แบบบอกว่า เขียน diagram ของที่เป็นปัจจุบันให้หน่อย เขียน diagram ของอันใหม่ให้หน่อย แล้วก็ side-by-side ให้หน่อย ว่า ตอนนี้มันเป็นอย่างนี้แล้ว สิ่งที่เกิดขึ้นคืออะไร แล้วอันที่หลังจากทำเสร็จ มันควรจะหน้าตาเป็นยังไง

ซึ่งผมว่าอันนี้ช่วยผมมากๆ ในฐานะ reviewer ว่า ผมกำลังให้มันรันในสิ่งที่ผมต้องการ impact ที่เกิดขึ้นคืออะไร ด้านต่างๆ อะไรอย่างนี้ แล้วก็อันนี้ก็ skim skim ดูว่ามันมีอะไรที่แบบ off เกินไปไหม แต่ส่วนใหญ่ก็จะไม่ ถ้าเกิดข้างบนมันถูก สำหรับผมนะ ประมาณนั้น แล้วผมก็จะต่อด้วย implementation plan

อันนี้เดี๋ยวต้องไป เดี๋ยวต้องไปลอง gen เป็น HTML บ้าง

สั่งกระจายงานทำพร้อมกันแบบ Parallel และใช้คำสั่ง simplify เคลียร์โค้ดให้สะอาด15:43

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

แล้วมันก็อันนี้ คือพอเป็น HTML อะ มันสามารถที่จะใส่ลูกเล่นอะไรแบบนี้ได้ แบบเห็น สมมติว่าเป็นทำ front-end อย่างนี้ ก็เห็นจริงๆ ว่ามันจะเกิดอะไรขึ้น แล้วก็ลองกด สมมติว่าทำแบบ select

drop-down ก็เห็นเลยว่ามันจะหน้าตาเป็นยังไง ไม่ใช่ว่าแค่แบบ เป็น MD อะ เออประมาณนี้ อันนี้ อันนี้มี secret อะไร ที่อยู่ในตัว write plan เมื่อกี้ปะ เพื่อให้มัน gen HTML หรือว่าเป็นแค่ prompt ง่ายๆ ว่าแบบ make it interactive in HTML อะไรประมาณนี้ ผมใช้คำว่า ผมใช้คำว่า always create diagram

สำหรับปัจจุบันและสิ่งที่ propose อืม เออ ฉะนั้นมันจะออกมาตลอดเวลา ยกเว้นว่าแบบ มันคงหาทาง gen ไม่ได้จริงๆ อะ อืม somehow แต่ว่าส่วนใหญ่มันจะออก ใช่ครับ นี่ประมาณนี้ อ่า โอเคครับ แล้วก็ step ต่อไปก็คือพอได้ plan มาปุ๊บ review เสร็จปุ๊บ อืม ก็ไปเข้า implementation เลยปะ implementation plan ใช่ อันนี้ ซึ่งอันนี้ก็จะทำตามที่ plan ที่เขียน ใช่ไหม แล้วก็ ทำเสร็จก็จะมี เอ้ย แล้วก็ตอน ตอนมันทำอะ มันจะคิดก่อนว่า

plan นี้ ทำ parallel ได้แค่ไหน เพราะว่าผมอยาก optimize เพื่อความเร็วเหมือนกัน ฉะนั้นถ้ามันสามารถ มันกำลังจะแก้ 10 files จะให้แบบ ทำ parallel สูงสุดได้กี่ file ที่ไม่ทับกัน อืม เออ ฉะนั้นมันก็จะ parallelize ตรง implementation แล้วก็ตัว reviewer ที่เป็นตัวพ่อ ก็ aggregate แล้วก็ลอง test ให้ผ่าน test ผ่านปุ๊บ รัน

reviewer กับ simplifier พร้อมกัน ฉะนั้นตัวหนึ่งก็จะ focus refactoring อีกตัวหนึ่ง review code file gaps เหมือนเดิม simplifier นี่ใช้ built-in เลยไหม ใช่ /simplify อะ อันนี้ อันนี้เป็นอันหนึ่งที่ผมก็ใช้บ่อยนะ จะมี /simplify ของ Claude Code นะครับ ซึ่งมันก็จะ make in ไปใน implementation track อยู่แล้ว อืม โอเค งั้นผมไม่ต้อง ผมไม่ต้องทำอะไรเพิ่ม โอเค เอิ่ม โอเค ผมว่าอันนี้ทุกคนน่าจะอยากรู้ว่า

เคล็ดลับ: การเขียน Skill สำหรับ Prompt ควรมีความยาวไม่เกิน 1,500 Tokens18:21

ประมาณ ช่วยประมาณ size ของ skill ที่เราเขียนเมื่อกี้อะ อยู่ที่ประมาณ สักกี่บรรทัด หรือประมาณกี่ tokens อะไรประมาณนี้ เออ อันนี้น่าจะ น่าจะต้องแบบ น่าจะต้องลองลอง ถาม ถาม Claude ดูอะ โอเค ได้ แต่ก็ แต่ก็ น่าจะไม่ได้ยาวอะไรมากครับ อืม ตาม ตามที่เล่าให้ฟังเมื่อกี้แหละว่า process เป็นยังไง อะไรอย่างนี้ ใช่ โอเค โอเค

แต่มันจะมีอันหนึ่งที่ผมทำให้ทีมใช้ ก็คือ อันนี้ส่วนตัวละกัน ส่วนตัวคือ ผมอะ เวลาใช้ สร้าง skill ใช่ไหม ผมก็จะใช้ skill-creator ในการสร้าง แต่นี้ ส่วนใหญ่เวลา skill ที่มันออกมา มันจะค่อนข้างยาว นะครับ แต่ว่า เท่าที่ผมไป research เนี่ย เขาก็แนะนำว่า skill ที่มันโอเค อยู่ที่ประมาณ 1,500 tokens นะ ที่มันจะไม่ ไม่ ไม่สั้นเกินไป ไม่ยาวเกินไป เออ เออ จน จนตอนนี้ ผมรู้สึกแล้วว่า โอเค ภาษาอังกฤษแม่งโคตรสำคัญ นะครับ อืม อืม

โอเค อันนี้ อันนี้แชร์ได้นิดหนึ่งก็คือ

แชร์ Repo ให้คนในทีมใช้ MCP ดึงข้อมูล GCP Log นำไปวิเคราะห์หาปัญหาด้วยตัวเอง19:24

จริงๆ เพิ่งทำให้ทีมใช้เลย ก็คือ อยากให้ทีมทุกคนอะ ไม่ว่าจะเป็น dev หรือไม่ dev นะ

โคลน โคลน GitHub ของ Paypers ลงไป แล้วก็ work บนนั้น โอเค เข้าใจ เพราะว่าจริงๆ ผมมี MCP หลายตัวที่ถ้าเขา สั่ง Claude ขึ้นมาใน ใน repo ตัวนี้ปุ๊บอะ มัน มันต่อกับ Google Cloud logging ได้เลย หรือ GCP ได้เลย อะไรอย่างนี้ ฉะนั้น สามารถ สามารถแบบ query log ตรงนี้ได้เลยว่า อะไรดีอะ How many 403s we got in the last day?

สมมติอย่างนี้ มันก็จะแบบ ไป query GCP ดูว่ามี 403 กี่อัน แล้วก็ report ให้ผมดูว่า โอเค อะไรเป็นยังไง อืม อยากรู้ว่า bug นี้ที่เกิดขึ้น จริงหรือเปล่า

มีใน log หรือเปล่า อะไรอย่างนี้ มันก็จะ เข้าไปดูได้ เออ อะไรประมาณนี้ ซึ่งผมก็เลยสร้าง cheat sheet ขึ้นมาว่า เฮ้ย มี skill ไหนบ้างนะที่เอาไปใช้ได้ เออ อันนี้อาจจะผสมว่าเป็น dev ด้วย หรือไม่ dev ก็ใช้ จริงๆ อันนี้จะอยู่ในหัวข้อต่อไปที่จะคุย แต่ว่าสปอยล์มาแล้วก็ไม่เป็นไร เอิ่ม โอเค เดี๋ยวกลับมาที่เรื่องทีม

เทคนิคลดการสิ้นเปลือง Context ด้วยการพิมพ์ Prompt สไตล์ Caveman และใช้ RTK20:39

เพราะว่าเป็นอีกมุมหนึ่งที่พี่รู้สึกว่า น่าสนใจเหมือนกัน เออ ขอกลับมาที่ไอ้ตัว Claude Code เมื่อกี้แป๊บนึง เรื่องเดี๋ยวนี้เรายังมีปัญหาเรื่อง manage context อยู่หรือเปล่า แบบ หรือเรามีเรียกว่า tips อะไรในการจัดการ context ไหม หรือว่าส่วนใหญ่ก็คือแค่นี้ สองสามอันแล้วก็เวิร์กละ ไปโฟกัสที่ skill มากกว่า คือผมว่าตอนเคลียร์กับ /compact ทุกคนคงรู้อยู่แล้ว ทุกคนคงใช้แล้วละ ใช่ไหม เออ แต่ที่ผมทำเพิ่มขึ้นมาก็น่าจะมีสามตัว ก็คือ caveman ทุกคนน่าจะใช้อยู่หรือเปล่า เออ แต่ถ้าสมมติใครไม่ใช้ caveman คือทำให้สิ่งที่พ่นเข้าพ่นออกมันสั้นลง แล้วผมชอบมาก เพราะว่าเวลาอ่านแล้วมัน concise แทนที่จะบอกว่าแบบ ตอนนี้ของนี้เป็นอย่างนี้ และกำลังจะเปลี่ยนเป็นอะไร แบบ ตอนนี้อย่างนี้ ใหม่แบบนี้ อะไรอย่างนี้ เออ แล้วมันทำให้ context มันสั้นลง แล้วเราอ่านเข้าใจง่ายขึ้นด้วย หนึ่ง สองคือ RTK ทุกคนเคยรู้จัก RTK ไหม

โอเค RTK เนี่ย มันคือ เดี๋ยวเปิด...

เวิร์กจริงเหรอ RTK พี่ลองใช้ละ ผม...

รู้สึกว่ามัน หมายถึงว่ารู้สึกไหม อะไรนะครับ รู้สึกว่ามันเวิร์กไหม จากตอนแรก เวิร์กที่พี่หมายถึงคือ context ลดลงอย่างนี้เหรอ ไม่ คือตอนนี้พี่ไม่สน context ละ เพราะว่าพี่มี 1 million tokens 1M ละ ใช่ไหม

แต่พี่ยังฟีลไม่ได้ว่ามันดีขึ้นจริงหรือเปล่า ส่วนอันหนึ่งที่พี่รู้สึกว่าตอนแรกที่ใช้นะ RTK ที่มันจะเวิร์กคือ เวลามันรัน test แล้วมี test fail มันเคลมว่าจะเอาแค่ fail ส่งให้ AI ใช่ไหม แล้วก็จะได้ fix เร็วขึ้นอะไรพวกนี้ ใช่ แต่พี่ไม่รู้ว่ามันเวิร์กจริงหรือเปล่า หมายถึงว่าแบบไม่ได้เข้าไปดูลึกๆ ว่ามัน มันใช่แบบที่มันเคลมหรือเปล่า อืม เออ แต่ส่วนตัวเรา ต้องยอมรับว่ายังไม่ได้ dig deep เหมือนกัน แต่คือใช้แล้วไม่มีปัญหา อืม แล้วไปใช้ command ของมันน่ะ ที่แบบว่า verify ว่า

คุณลด token ไปแล้วกี่อันน่ะ แล้วมันขึ้นว่า 90% ผมไม่รู้ว่าจริงไม่จริง แต่เอาเป็นว่า ผมไม่มีเวลาไปนั่งดูว่าจริงไม่จริง เห็นบอกว่าลดก็ลดละกันครับ โอเค เข้าใจ พี่ก็เจออย่างนั้นเหมือนกัน แต่ก็รู้สึกว่าแบบ too good to be true หรือเปล่าวะ โอเค มี มีอะไรแชร์ไหมครับ

RTK อาจจะเฉยๆ กับฝั่ง dev ครับ แต่ฝั่ง system ผมพบว่า RTK เนี่ย ลดได้จริง เยอะมาก มากๆ เพราะว่าคำสั่งที่มันใช้ ส่วนมากจะเป็นคำสั่งตระกูลฝั่ง system ต่อให้เป็น git เป็นอะไรพวกนั้นก็เหอะ เพราะเราเขียนแบบ เค้าเรียกว่าไรนะ infra as a code อะไรอย่างนี้ พวกนั้นมันก็จะมาช่วยเช็ก ช่วยลดพวกนี้ได้อีกเยอะจริงๆ ครับ แล้วก็ไม่นับว่า debug ของพวก server ลดแบบมหาศาลมากๆ โดยเฉพาะ log server ครับ

แต่ว่ามันไม่มี มันไม่ได้มี trade-off ใช่ไหมครับ หมายถึงว่าเราเคยเจอไหม trade-off โอเค ถ้ายังไม่รู้สึก ถ้าอย่างนั้นก็ ลองดูครับทุกคน RTK

แปลง Codebase เป็นลักษณะ Graph ช่วยทุ่นเวลาที่ AI ต้องใช้สแกนค้นหาฟังก์ชัน24:05

อีกอันหนึ่งผมจำ แนวๆ ที่ทำให้ codebase เราเป็น graph อะไรอย่างนี้ปะ ใช่ๆ แต่ผม จำชื่อที่ผมใช้ไม่ได้ละ เดี๋ยวเช็กก่อนนะ อืม คุ้นๆ อยู่เหมือนกัน แต่ว่ายังไม่มีเวลาไปเล่น เพราะว่าไอ้พวกนี้ครับ สิ่งที่ผมกลัวอย่างเดียวคือ เวลาเอาอะไรมา install ปุ๊บเนี่ย เราจะต้องเห็นความแตกต่างด้วย

ไม่ใช่ว่าอะไรเขาบอกว่าดีก็ลง ลงแม่งทุกอย่าง จนสุดท้ายแบบ มันดีหรือไม่ดี หรือว่าอะไรกันแน่ อันนี้คือสิ่งที่ผมรู้สึกว่าอาจจะต้องระวัง เวลาใช้เครื่องมือของคนอื่นต่างๆ จริงครับ ไม่งั้นเดี๋ยวของเรามันจะเพี้ยน ใช่ อันนี้ก็เป็นอีกอันหนึ่งที่ใช้ แล้วก็ใส่ไปใน prompt ทุกอันว่า เวลาจะค้นหา function ที่มีอยู่แล้ว ใน codebase ให้เรียกอันนี้ แทนที่จะไปอ่านเอง คือมันเป็น skill มันเป็นตัวที่แบบต้องพร้อมนิดหนึ่งอ่ะ ไม่งั้น default มันจะไม่

ซึ่งมันทำให้แบบ แทนที่จะต้องไปอ่านโค้ด หลายบรรทัดว่า ไอ้สิ่งนี้มี ไม่มี มันดูง่ายๆ เลยว่ามีหรือไม่มี โอเค ประมาณนั้น ลองไปดู โอเคครับ

ตั้งกฎใน CLAUDE.md สำหรับแบ่งแยกหมวดหมู่และจ่ายงานให้ Agent เฉพาะทาง25:21

แล้วก็มีอีกคำถามหนึ่งเกี่ยวกับตัว CLAUDE.md เรา

เอาแบบสั้นๆ ละกันนะ CLAUDE.md ว่าเรา ณ ตอนนี้เรา manage ยังไง แบบ มัน fix อยู่กับที่ไหม หรือว่าเรามีการเพิ่มมันไปเรื่อยๆ ในกรณีที่เราแบบอาจจะเจอเคสอะไรเพิ่มขึ้นมา ผมมีแบบ 200 บรรทัดเนี่ย ถือว่าเยอะนะ 200 บรรทัดก็ไม่ ไม่มาก

แต่คือมันคือ CLAUDE.md link ไปที่ agent เนาะ แล้ว agent เนี่ย แต่ละอันเนี่ย ก็คือจะมีอันนี้อยู่ หมายถึงว่า front-end ไปอ่านไฟล์นี้ API ไปอ่านไฟล์นี้ ผมว่าอันนี้ช่วยเยอะ เพราะว่ามันไม่จำเป็นต้องอ่าน claude แบบ ไม่จำเป็นต้องอ่านทุกอันนี้ตลอด ฉะนั้นจะใช้อะไรก็ reference ไปหาอันนั้น แล้วค่อยโหลดเข้ามา อันนี้น่าจะเป็นตัวช่วยที่ทำให้แบบ manage context ได้ดีขึ้น แล้วส่วนใหญ่ ส่วนใหญ่ มันไม่ค่อย add ในไฟล์ CLAUDE.md หรอก ก็คือจะค่อนข้างไปเพิ่มตรงนี้มากกว่า อันนี้แนะนำว่าให้เอาไปใส่ใน rules

มัน build-in เลย แบบ `.claude/rules`

มัน build-in เลย มันเรียกเอง ไม่ต้องบอกมัน เดี๋ยวมันหาเอง อันนี้ก็เผื่อใครเอาไปลองนะครับ

โอเค

เมื่อกี้เราก็คุยไปแล้วเนาะว่า skill เมื่อกี้ปั่นก็โชว์ให้ดู เรื่องของการ ทั้ง feature dev ทั้ง bug fix ใช่ป่ะ flow เมื่อกี้ ไอ้ตัว skill ที่เป็น

รันคำสั่ง Routine สร้างบอทกวาดอ่าน Linear คอยตามแก้ Bug ง่ายๆ โดยอัตโนมัติ27:01

writing plan แล้วก็ implement plan อ๋อ ไม่ bug fix เนี่ย จริงๆ เรามี 2 อย่าง ก็คือ มีตัวที่เป็น bug fixer ไอ้เนี่ย จะทำเฉพาะอันที่มันไม่ complex เท่านั้น ไม่ complex คืออะไร คือ ปกติเวลาเรา run เรา run Claude อย่างนี้ครับ ถ้ามันเป็น plan ยากๆ มันจะถามเราถูกไหมว่า เฮ้ย พี่จะทำอย่างนี้หรือเปล่า ให้เลือก choice ถ้าเกิดว่ามี choice decline ทิ้ง อันนี้จะเป็น bug fixer ที่ run ทุกชั่วโมงนะ มันจะตื่นมาทุกชั่วโมง ดูว่าใน Linear task เนี่ย มี task อะไรที่ติดคำว่า bug อันนี้คือใช้ loop ป่ะ หรือว่าใช้ schedule ของ ของไอ้ตัว app?

ใช้ routine ครับ อ๋อ ใช้ routine โอเค ใช่ เพราะว่า loop มันไม่เคลียร์ context อ่ะ ถูกป่ะ ไม่รู้เหมือนกัน loop มันไม่เคลียร์ context แต่ loop มันไม่ มันไม่อยู่ตลอดไป ณ ตอนนี้ เออ ไม่อยู่ตลอดไป และไม่เคลียร์ context ด้วย เออ แต่โอเคเข้าใจได้ ผมใช้ routine ซะส่วนใหญ่ แต่ อ๋อ routine run local ใช่ไหม

หรือว่า routine run บน cloud? ไอ้ bug fixer run บน cloud แต่ว่ามันจะมีหลายตัวที่ run local ของผม ใช่ๆ โอเค อ่ะนี่ bug fixer หยิบเฉพาะการ์ดที่ bug fixer ไม่ต้อง ไม่ต้องมี decision แล้วก็ไม่แตะ database ก็คือไม่มี schema change อันนี้คือ rule ของผม ซึ่ง bug พวกนี้ คนเขียนถูกป่ะ เป็นแบบคนเปิด ขึ้นมา คนไปเปิดใน Linear

ใน Linear ก็คือเปิดแบบนี้ ก็คือว่าเขียนไปแหละ แล้วก็ "@linear create task" มันก็จะไปเปิดใน Linear ให้ โอเค อันนี้คือก็ของปั่นเขาใช้ Slack ในการ ในการคุยงานเนาะ ใช่ไหมครับ แล้วก็ integrate พวก Linear app ใช่ป่ะ ใช่ครับ เอา Claude มาใส่ในนี้ด้วยป่ะ เอา Claude มาใส่ใน มีครับๆ แต่ว่าไม่ค่อยมีใครใช้ มันก็เป็น token ผม อือ

อีกอันนึงก็คือเป็น validate bug

บอทผู้ช่วยกรองบั๊กปลอม, ตรวจแจ้งเตือน Sentry และสกัดรายงานลูกค้าที่ยกเลิกใช้งาน (Churn)29:12

อันนี้คือสมมติว่าทีม product ไม่แน่ใจว่า ใช่เปล่าวะ นี่คือ user ผิด หรือ user งง หรือเป็น bug จริงๆ ก็จะ tag tag ผม แล้วบอกว่า validate หน่อย แล้วก็จะใส่ ซึ่งอันนี้ bot ผมก็จะเป็นคนจัดการ แล้วก็บอกว่าไม่ใช่ bug โว้ย ใช่ไหม ถ้ามันไม่ใช่ bug ถ้ามันใช่ก็จะใช่ อันนี้ก็ไม่ใช่แล้ว อ๋อ ใช่ ลูกค้าหาเจอแล้ว ไม่เสียเวลาผมไปนั่งแบบ แม่งคนนี้ยังไงวะ อะไรอย่างนี้ อ๋อ โอเค คือส่วนใหญ่ผมน่าจะใช้มันในการ เอาสิ่งที่ไม่จำเป็นออกจากหัวผมมากกว่า อ่าฮะ ผมจะได้ยัง focus ในสิ่งที่มันต้อง focus อะไรอย่างนี้ อ่าฮะ ก็พยายามทำพวกนี้ขึ้นมา ยกตัวอย่างอีกอันนึงก็คือ

น่าจะเป็น อ๋อ แล้วก็น่าจะคล้าย bug fixer อีกอันนึงก็คือเป็น มันจะอ่าน Sentry ทุกวัน ว่า 24 ชั่วโมงที่ผ่านมา มี alert อะไรใน Sentry อะไรที่มันรู้สึกมั่นใจในการแก้ เปิด PR แก้ โอเค แล้วก็ สมมติ Stripe อย่างนี้ ทุกวัน มันจะมีช่วงก่อนที่แบบลูกค้าเรายังไม่เยอะเนาะ

พี่พลอย พี่พลอยจะแบบ วันนี้ลูกค้า churn อีกแล้ว ลูกค้าแบบ หนีออกจาก หนีไปจากเรา churn แต่เขาอยากโทรไปหาลูกค้าว่า เฮ้ย หนีทำไม ใช่ไหม ฉะนั้นผมก็จะมี เพราะพี่พลอยจะถามผมว่า ขอเบอร์ลูกค้าคนนี้หน่อย วิเคราะห์ให้หน่อยว่าลูกค้าคนนี้ทำไม churn ก็เลยทำ daily churn report ขึ้นมา มันก็จะบอกว่า โอเค มีกี่ลูกค้าที่ churn เขาเป็นแบบสอง active นะ วันนี้ แล้ว มีคุณอะไรบ้าง เขาใช้ package อะไรอยู่ อันนี้กดไปที่ Stripe ของเขาได้เลยนะ เบอร์โทรอะไรอย่างนี้ จะได้

จะได้ไม่ต้องมาถาม โอเค นึกออก

ก็ อันนี้เป็นอันนึงที่ผมรู้สึกว่า อยากจะ ให้ทุกคนเห็นเวลามาคุยกับคนที่เขาทำเป็น product จริงๆ เราจะเห็นว่าหลายๆ อย่างมัน มันต้องเกิดขึ้นจาก สิ่งที่เขาเจอเนาะ มันไม่ใช่ว่า คือ Claude มันคงไม่ได้ ไม่ได้เป็นส่วนเรียกว่าภาพ ใหญ่ของ product ที่เราทำ แต่มันมาส่วนมาช่วยมากกว่าเนาะ ใช่ๆ เท่าที่เราทำ

มันทำให้ productive มากขึ้น productive มากขึ้น โอเค

ทีนี้เดี๋ยว กลับไปที่เรื่องทีม collaboration เมื่อกี้นิดนึง collaboration อันไหนนะ อันไหนนะครับ ตอนแรกที่เรา spoil มาแล้วอ่ะ ที่ทำ ที่ให้คนในทีมสามารถ cheat sheet เออ pull ลงไป pull repo ลงไปป่ะ อ๋อ ที่ โอเค เออ ตอนนี้น่าจะยังไม่มีใคร clone นะ แต่ว่า

แต่ว่า ก็จะเป็นแบบโอเค เราอยากให้ทุกคนมี sense ของการใช้ GitHub เพราะว่าจะได้ทำนู่นทำนี่ได้ แล้วเราจะได้ฝัง skill ไว้ในที่เดียว ก็คือใน repo ผม ทุกคนก็แชร์ skill กัน ซึ่งก็แล้วก็เขียน cheat sheet ขึ้นมาเพื่อว่า ใช้ยังไง set up ยังไง ก่อนจะไปตรงนั้นถามนิด นึงว่าในทีมของเราอ่ะ

ทีม Business ใช้งาน AI ดึงข้อมูล Insight จาก Database จริงได้เองผ่านสิทธิ์แบบ Read-Only32:31

เรื่องของการใช้ AI เรา อยู่ใน level ไหน แบบทุกคนใช้เลยไหม หรือว่ากำลัง adopt อยู่ หรืออะไรอย่างนี้ ทุกคนน่าจะใช้นะครับ แต่ว่า ใช้ใน ใช้ถึงขนาดไหน อันนี้น่าจะแล้วแต่คน แต่ dev น่าจะใช้กันหนัก จริงจริงตอนนี้คือ product team ทุกคน น่าจะใช้กันเยอะมาก เพราะว่าผมให้ทุกคนต่อ

MCP ที่เข้า database ของ production แบบ read only นะ แบบ read only เพราะว่าไม่งั้นน่ะ ถาม dev กันกระจายเลยว่าแบบ อะไรยังไง แบบอยากรู้ว่าวันนี้ยอดเท่าไร conversion วันนี้เท่าไร อะไรพวกนี้ ตอนนี้คือเขาถามใน Claude ที่ต่อกับ database production อะไรอย่างนี้ แล้วก็ ได้คำตอบที่ต้องการ

ซึ่งก็น่าจะใช้ตรงนี้กันเยอะ analyze ข้อมูลที่เรามีอยู่ครับ แล้วเรา ต้อง train ไหม

หรือว่าเราแค่สร้างเครื่องมือแล้ว คนในทีมเขาแบบ โจ้เองเลย

นึกออกไหม หมายถึงว่าต้อง train ว่า ถ้าอยาก คุณอยากรู้อันนี้ ถามสไตล์นี้ อะไรอย่างนี้

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

ใช่ไหม ซึ่งตอนนี้คือเนี่ย มี skill นู่นนี่เยอะแยะ ที่เราก็เขียนมาแหละ ว่าอะไรทำอะไรได้บ้าง อันหนึ่งใช่ไหม export LINE broadcast อย่างนี้ ก็คือ เวลาเรา broadcast ใน LINE เราสามารถ target broadcast ได้ อยาก target ไปแค่กลุ่ม segment นี้ user ID set นี้ ใช่ไหม แต่ว่าประเด็นคือ เราจะรู้ได้ไงว่า ใครเข้าข่ายบ้าง

พอด้วย Claude กับ MCP มัน enable สิ่งนี้แล้ว ก็คือ /line /export-line-broadcast พิมพ์เลยว่าแบบ user ที่เพิ่งเข้ามาวันนี้และยังไม่ convert

ซึ่งใน skill นี้ผมจะเขียนว่า schema database ผมแบบนี้ ถ้าจะถาม user ที่ table นี้ บลาๆๆ ไป แล้วมันก็ทำความ optimize ในการ ในการทำ query SQL query ออกมา แล้วมันก็จะไป filter ข้อมูล export เป็น CSV แล้วก็พร้อมใช้งานเลย พร้อมส่งให้ LINE เพื่อแบบ broadcast ประมาณนี้ อะไรแบบนี้มัน มันเพิ่ม speed ในการทำงานและ token มันก็ utilize ได้ดีด้วย เพราะว่าเราบอกว่าทำยังไง

product team cheat sheet ให้ เรียกว่าให้ทุกคนเข้ามาถึงตรงนี้ แล้วก็อยากจะได้อะไรก็คือ อาจจะ copy ไปใช้ หรือพิมพ์ / skill ที่เขากำลังต้องการ พิมพ์ skill เลย เพราะว่า อยู่ใน repo อยู่ใน repo โอเค

คุณสมบัติ Engineer ในยุค AI: สายตาไวในการมองหาปัญหาและไม่ยอมแพ้ในการหาทางแก้35:39

มีคำถามหนึ่ง อยากจะ

น่าจะมีประโยชน์นะครับ คือตอนนี้ปั่นมีทีมมีกี่คนนะ

เยอะมาก หกคนครับ หกคน โอเค หกคนรวมผมเป็นเจ็ด แต่ว่ามีน้อง intern อะไรพวกนี้ อยากถามในฐานะ CTO ที่ต้อง ตอนนี้เราเริ่มขยับต้องมาดูภาพรวมใช่ปะ แบบไม่ได้ไม่ต้องเขียนโค้ดอะไรขนาดนั้น ถ้าเราต้องขยายทีม tech คือตอนนี้เรามองหาคนแบบไหน ในโลกของที่เป็นเทรนด์ที่เป็น AI แล้วด้วย context ที่ product ที่เราทำอยู่ คือเรามองหาคนแบบประมาณไหนอยู่ โอเค

ผมว่าพอ Claude มันเขียนโค้ดให้เราเยอะอะ

ผมรู้สึกว่าผมอยากได้คนที่หาปัญหาเก่ง

แล้วก็ไม่ท้อที่จะหาทางแก้ปัญหา

รู้สึกว่า engineer แต่ก่อนมันคือแบบ ได้ requirement มาว่านี่คือปัญหาแล้วแก้ ใช่ไหม ผมรู้สึกว่าตอนนี้มันคือหาปัญหา แล้วก็ พยายามหาเวลาแก้มัน ใช่ๆ เพราะว่า engineer สามารถที่จะเห็นปัญหา และทำได้เลยโดยไม่ต้องถามใคร ไอ้พวกแบบเมื่อกี้ที่ทำมาทั้งหมด ว่าแบบบอท auto-fixer อะไรพวกนี้ ผมรู้สึกว่าเฮ้ย มันเป็นสิ่งที่เราเจอทุกวัน เราเจอปัญหา แล้วเราแบบ กลับบ้านตอนนี้ทำได้เลย แล้วก็แยก worktree ทำเอา เพราะว่าเราทุกคนก็น่าจะใช้ worktree เนาะ ผมสามารถมีแบบสามอันทำพร้อมกันได้ ผมเจอปัญหาใหม่ ผมแบบ control N แล้วผมบอกมันว่าผมจะทำอะไร

ก็เลยรู้สึกว่า engineer ที่ถ้าเราจะรับ engineer ขอคนที่แบบชอบมองหาปัญหา

แล้วก็ไม่ท้อที่จะแก้มัน โอเค น่าจะเป็น feature หลัก

โอเคครับ อันนี้ในส่วนของทีมนะครับ

แนวทาง Vibe Coding เหมาะสำหรับงานทดสอบ Prototype แต่ยังไม่พร้อมสำหรับฝั่ง Production37:36

collaboration ส่วนต่อไปเป็นส่วนที่แบบ

อยากฟังความเห็นของปั่นนะครับ จะเป็นแบบภาพรวมซะส่วนใหญ่

คือตอนนี้ในออนไลน์มันก็จะมีเรื่อง vibe coding ใช่ปะ อยากฟังความเห็นปั่นนิดหนึ่งว่า ในมุมของเราอะ เราคิดว่า vibe coding มันคืออะไรประมาณไหน แล้วก็เราคิดว่ามัน work กับ production จริงไหม vibe coding พี่จุ้นคิดยังไงอะ อ้าว ซวยละกู

ส่วนตัวพี่ไม่คิดว่า vibe coding มันจะขึ้น production ได้ production นะ production แล้วไม่คิดว่า vibe coding มันจะสามารถไปต่อใน production ได้ เอาอย่างนี้

โอเค สั้นๆ เห็นด้วยๆ ผมรู้สึกว่ามันเป็น ตัวช่วย validate idea ที่ดีมาก

แล้วทีมคนอื่นที่ไม่ใช่ dev ก็สามารถ ทำได้เลย validate ได้ทันที แต่ก่อนมันอาจจะพยายามใช้ prototype tool ต่างๆ ที่ interaction มันอาจจะ limited แบบลูกค้าเลื่อนไม่ได้หรือว่าอะไรพวกนี้ แต่ว่าพอ vibe code แล้วมันแบบ animation ได้เต็มที่เลย ก็รู้สึกว่าได้ตรงนั้น แต่ว่าพอขึ้น production แล้ว มันคนละเรื่องกัน เพราะว่า อย่างที่ผมบอก ผมรู้สึกว่าสิ่งที่ delay

สิ่งที่ delay การทำของอะ ไม่ใช่ว่า feature มันทำยาก

แต่มันคือต้อง make sure ว่า feature นี้ ไม่ได้ break คนที่กำลังใช้งานอยู่ แบบเป็นพันเป็นหมื่นคนอะ รู้สึกว่าตรงนี้มันเป็น process ที่ค่อนข้างยากละกัน แล้ว vibe code ก็ยิ่งจะสร้าง bug ใหม่ เข้าไปเรื่อยๆ

ถูกต้อง เห็นด้วยเลยครับ ในฐานะทำ production เหมือนกัน

เมื่อ AI เริ่มรับหน้าที่เขียนโค้ด Engineer ยิ่งต้องเร่งพัฒนาฝีมือด้าน Critical Thinking39:28

อีกคำถามหนึ่งคือ ตอนนี้มันมีเหมือนกับ

ไอเดียว่า เฮ้ย AI มันทำได้ขนาดนี้ มันจะมาแทน software engineer หรือเปล่า แล้วพวกเราจะ

ตายห่ากันหมดเลยหรือเปล่า

สำหรับปั่นมองไว้ยังไง

coding ไม่เหลืออยู่แล้วอะ ผมรู้สึกว่าผมก็แทบไม่ code แล้วอะ ฉะนั้นผมก็เลยรู้สึกว่ายังไง coding ก็ไม่เหลือ แต่ว่า

logical skill ที่เรามี แบบที่เราเรียนวิศวะกันมาหรือแบบ อะไรพวกเนี้ย ผมว่ามันคือ critical thinking แล้วในโลกที่ข้อมูลเยอะ แล้วข้อมูลที่ผิดมากกว่าข้อมูลที่ถูกอะ critical thinking ยังสำคัญที่สุดอยู่ ในมุมผมนะ เราจะทำอะไร เราจะไม่ทำอะไร อันนี้น่าทำ อันนี้ไม่น่าทำ อันนี้มี loophole ไหม อันนี้ไม่มี loophole อะ รู้สึกว่ายังไงเราก็ต้องถาม AI กลับอยู่ดี อันนี้ไม่ว่าจะเป็น product หรือ engineering นะ สมมติมันให้ข้อมูลเรามา เราต้องคิดทุกอย่างว่า ที่มันพูดมา มันจริงไม่จริงอะ แล้วรู้สึกว่า skill เนี้ย ถ้า engineer มี และ

ไม่... เค้าเรียกว่าไรอะ ไม่ท้อละกัน ไม่ท้อในการแบบ รู้สึกว่าปัญหานี้แก้ยาก หรือไม่อยากสร้างปัญหาใหม่เงี้ย ผมว่า software engineer คนนั้นอะ รอด แต่ถ้าจะเป็น engineer ที่รอรับงานอย่างเดียวเลย บอกว่าทำ card เนี้ย แล้วทำ แค่ทำแค่นั้นน่ะ ผมรู้สึกว่ายังไง eventually น่าจะหายอยู่ละ เพราะผมรู้สึกว่า vibe coding อะ เดี๋ยวมันจะขึ้น production ได้ ผมรู้สึกว่ามันจะขึ้น production ได้ แต่ แต่ app เนี้ยควรจะขึ้นไหมอะ อีกเรื่องหนึ่ง แบบควรจะมี feature อะไรบ้าง เพื่อ serve user คนไหน ประมาณนั้น ส่วนนั้นมันต้องแบบ มันยังต้อง human touch อยู่

มันต้อง critical thinking เยอะมากละกัน แล้วก็ exploration ด้วยว่าแบบ เราจะกำลัง serve ใคร แล้วเราก็ไม่ serve ใคร เรา serve คนนี้เพราะอะไร อะไรพวกเนี้ย โอเค แล้วก็ สุดท้ายดีไหม

สุดท้ายไปก่อนก็ได้ จริงๆ เวลาเหลืออีก เผื่อ เผื่อมีคนสงสัย มีคำถามนะครับ คำถามสุดท้ายสำหรับของผมก็คือ

ข้อแนะนำคนเริ่มใช้งาน: ลุยทำความเข้าใจ Anatomy การวางระบบภายในเครื่องมือของ Claude Code41:47

แนะนำคนที่เพิ่งเริ่ม Claude Code ละกัน ว่า เค้าควรจะเหมือน focus ยังไง focus ตรงไหน

หรือเรามีคำแนะนำอะไรไหม สำหรับ developer ที่กำลังแบบ จะลองใช้ Claude Code อะไรเงี้ย เพื่อให้เค้าแบบไปได้ถูกทาง

หรือไม่มี ลองเลย ลองเลย

ไปให้ถูก

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

มันจะเป็นประมาณไหน โอเค

ปกติที่ผมใช้ในการ tackle ปัญหาซักอย่างหนึ่งนะ

ก็คือ อยากรู้แบบหมดไส้หมดพุงเลยว่า มันทำอะไรได้บ้าง ผมรู้สึกว่าอาจจะเพราะทำ infra และทำ product มาด้วยมั้ง เราเหมือนจะพยายามอยากรู้ว่า ปัญหาเนี้ยแก้ด้วยอะไร แล้วมันเหมาะสมที่สุด อือหึ ฉะนั้น สมมติว่าผมจะใช้ Claude Code อย่างเงี้ย ก็อาจจะดูว่า Claude มีอะไรบ้าง แบบมี routine มี skill, connector, cowork นู่นนี่นั่น แล้ว anatomy ของมันอะ

มัน compatible กับปัญหาที่ผมกำลังจะแก้หรือเปล่า อืม เออ ฉะนั้นก็ลองศึกษาดูว่า Claude Code ทำอะไรได้บ้าง โอเค แบบหมดไส้หมดพุง เพราะว่างั้นอะ ผมรู้สึกว่า สมมติ OpenClaw ออกมา เราก็อาจจะ

ถ้าเราคิดน้อยอะ เราก็อาจจะพยายาม bake มันไปเลย ในกับทุก process ของเรา แต่จริงๆ มันอาจจะมี option อื่น ใช่ไหม อือหึ ตอนนี้ Claude มันก็ทำได้เยอะแล้ว แล้วก็อาจจะทำให้หลายๆ อย่างมันง่ายขึ้น โดยที่เรายังไม่ได้ invest ไปกับสิ่งที่เราอาจจะ อืม มันใหม่และยังไม่รู้จักอะไรอย่างเงี้ย อืม ประมาณนั้น โอเค อันนี้พี่ก็เห็นด้วย เพราะว่า เวลาพี่มีงาน พี่ก็จะพูดทุกครั้งว่าพยายาม เข้าไปเข้าใจไอ้ตัว Claude Code นะครับ ซึ่ง

ศึกษาระบบหลังบ้านผ่าน cc-changelog ช่วยให้เลือกทูลเขียนคำสั่ง Prompt ได้ถูกต้องยิ่งขึ้น44:01

ปั่นช่วยเปิด browser ให้หน่อย มีอันหนึ่งที่แนะนำชื่อ cc-changelog มันเป็น

เป็น GitHub อันหนึ่งที่ เค้า reverse engineering

เพื่อที่จะดูว่า Claude มันส่งอะไร บ้างเวลาเราคุยกับ Claude อันไหนนะ cc cc-changelog

ไม่ใช่ มันต้องเขียนว่า cc-changelog อืม ผมน่าจะกดถูกนะ ทำไมไม่มีวะ

ลอง cc-changelog github ได้ไหม

ไม่ใช่ ทำไมไม่มี

ลองๆ มอง มอ มอ มอ

น่าจะ น่าจะ mackgreg อันแรก mackgreg/claude-code ใช่ปะ

คล้ายๆ cc-prompt นี่แหละครับ น่าจะใช่ พี่ไม่รู้ว่ามันเปลี่ยนไปขนาดไหนแล้ว แต่ว่ามันจะ ลองๆ กด cc-prompt.md ก็ได้ นี่ อัปเดต อัปเดต prompt to version เดี๋ยว อันนี้ไป อันนี้ไปเสิร์ชเหรอ No, no, no. กลับไปอันเมื่อกี้ นี่ ตรงไฟล์ อ๋อ โอเค

อันเนี้ย จะเป็นเหมือนกับว่า Claude Code มันทำงานยังไงครับ แล้วมันก็จะมีเครื่องมือบอกหมดเลยว่า ในตัวมันเองมี tools อะไรบ้าง คือผมเอาไว้เช็ค เพื่อที่จะดูว่า เราจะ improve prompt เราให้มันดียังไง อย่างเช่น พอมีเครื่องมืออย่างเช่น มี cron ใช่ไหมครับ มันจะมี cron job อยู่ ถ้าเราพิมพ์แบบ ให้ เข้าใกล้เครื่องมือมันมากที่สุดอะ มันก็จะใช้เครื่องมือ tools ที่มันมีอยู่อะ ได้เร็วขึ้น อะไรประมาณนี้ ซึ่ง อันนี้เป็นอันหนึ่งที่แนะนำว่า ให้ลองไปอ่านดูว่ามันทำอะไรบ้าง แล้วก็ ข้อดีคือ มันจะช่วยให้เราเขียน skill หรือเขียน prompt อะไรอย่างเงี้ย ได้ดีขึ้นด้วย เหมือนกับเรามาดู cheat sheet แล้วอะ

ก็อันนี้แนะนำลองไปอ่านๆ ดู

โอเคครับ มีใครมีคำถามอะไรไหมครับ

Q&A: ระบุโครงสร้าง Schema ของ Database ให้ชัดเจนเสมอ หากต้องการให้ AI ขุดหา Insight ได้แม่นยำ46:14

อยากจะถามปั่นไหม เกี่ยวกับ project หรือว่าเกี่ยวกับ Claude Code ที่เขาใช้ เป็นโอกาสเดียวที่จะได้

พอดีเห็นตัว plan นะครับ ที่เป็น HTML อันนี้ก็เพิ่งเห็นแล้วก็ โห visualize ดีมาก แล้วก็ สงสัยอย่างหนึ่งครับ ตอนที่เรา review plan สมมติเรา review แล้ว เราจะ refine เราทำยังไงครับ หมายถึงว่า เราแก้ตัวไฟล์ HTML ตรงๆ แล้ว ให้ตัว Claude มาอ่าน หรือว่าเรา prompt กลับกับ Claude ไปเลย? แก้ prompt พร้อมกับ Claude ไปเลยครับ อ๋อ พร้อมกับ Claude ไปเลยนะครับ จริงๆ เดี๋ยว ผมมีหลายคำถามมากเลยครับ จริงๆ สนใจอีกอันหนึ่งครับ ที่ต่อ MCP เข้ากับ database แล้วก็

ที่มี query ถามว่า พวก ขอพวก insight อะไรพวกนี้ครับ ไม่แน่ใจว่า ตัว result ที่ได้ครับ มัน impact เยอะขนาดไหน แบบ result มัน ดี ดีไหมครับ แบบในมุมพี่

สำหรับเรา มันช่วยเราเยอะมาก ผมรู้สึกว่ามันช่วยผมเยอะมาก เพราะว่า ผมค่อนข้างเขียนชัดเจน เวลาผม prompt มันน่ะ สมมติจะคุยกับ database นะครับ ผมก็ พอพอเป็น dev แล้วเราขึ้น schema เองอะ เราก็รู้ว่า ต้องใช้ keyword อะไร แบบเรารู้ table name อยู่แล้วอะไรเงี้ย ฉะนั้นมัน มันไม่เคยทำงานพลาดละกัน แต่ว่าถ้าเกิดว่า เขียนกว้างๆ แล้วแบบใน skill ไม่ได้ใส่ schema ให้มันไปอะ แบบ มันก็อาจจะอ่านผิด เข้าใจผิดว่า table นี้ มี data ประมาณนี้ อะไรอย่างเงี้ย แต่ว่าถ้า ถ้าให้ schema มัน ผม ยังไม่เคยเจอที่มันแบบ ผิดแบบมหันต์ อะไรขนาดนั้น แต่หมายถึงว่าก็สุดท้าย ก็อยู่ที่มุมมองเราด้วยว่าเราจะอยากจะดูอะไร ก็หมายถึงว่าไอเดียในการดูแบบ insight แบบบางที ผม ถ้าสมมติว่าผมไม่มี skill แบบการ analysis เลย ก็อาจจะ prompt ไปแค่ว่า อยากรู้ข้อมูลจังเลย ข้อมูลนี้บอกอะไรเราบ้าง ใช่ ก็จะไม่ค่อยดี เพราะมันก็จะไม่รู้ว่า มันจะต้องทำอะไร สุดท้ายก็จะเป็น skill ของเราด้วย ที่จะตั้งคำถามอะไรกับมันใช่ไหมครับ ใช่ มันเหมือนสั่งงาน สั่งงานเพื่อนๆ หรือสั่งงานคนอื่นแหละครับ หมายถึงว่าถ้า ถ้าไม่เคลียร์ มันก็จะแบบ เอ้ย ทำผิดแน่นอน

ครับ ขอบคุณครับ

Q&A: Devin เครื่องมือช่วยสแกนตรวจ PR ให้ถูกต้องระดับความละเอียดสูง แลกมาด้วยต้นทุนราคาแพง48:39

และก็อีกอันหนึ่งที่ อันนี้ น้องในทีมแนะนำมา แล้วก็ ตอนแรกใช้แบบ ใช้จนติด แต่ว่า ใช้จนติด ติดลิมิต ติดลิมิตอะ เออ แล้วก็แบบ ไม่จ่ายต่อเพราะว่า มันค่อนข้างแพงมาก คือ Devin review เนี่ย คิดอยู่ทุกวันว่าจะกลับมาใช้ไหม แต่ตอนนั้นน่ะเราใช้ฟรี แอบ review อะไร PR คือ ผมเคยใช้ Claude review PR ผมรู้สึกว่า มัน find gap ได้ไม่ค่อยละเอียดเท่าไหร่ คือมัน มัน find gap ได้ระดับหนึ่ง แต่ว่า พอผมใช้ Devin review น่ะ ผมรู้สึกว่ามัน มัน review แบบ

ละเอียดมาก แล้วผมรู้สึกว่า เจอสิ่งที่ valid บ่อย อืม อืม Devin Devin ใช่ไหม เออ Devin review คือผมไม่ได้ใช้ feature อื่นเลยนะ ผมใช้อย่างเดียว ก็คือเปิด PR มา มันก็จะอ่าน ทีนี้ ตอนเนี้ย 1 PR ผมอ่ะ 3 ดอล

1 PR 100 บาท ก็เลยคิดอยู่ว่าจะ จะกลับมาเปิดไหม จริงๆ มันก็สามารถ filter ได้แหละว่า PR แบบไหนจะให้อ่าน แต่ว่า คิดอยู่ครับ ขอแบบ PR ที่ แต่ถ้า ถ้า ใครยังไม่เคยใช้ แล้วมัน ผมไม่แน่ใจว่ายังมี free trial แบบใช้ review ได้ไหมนะ แต่ลอง ลองไปกดใช้ดู ผมรู้สึกค่อนข้างประทับใจ แต่ถ้าใช้แล้วติด ติดใจ แต่ต้องโดนค่าใช้จ่ายขนาดนี้ ก็

เออ สำหรับคนเงินเหลือ อ่า โอเค หรือถ้า ถ้าบริษัทจ่ายก็จบ ครับ เพราะว่า วันนี้ มีคุยกับคนหนึ่ง ใช้ Claude Code บริษัทจ่าย ได้ อะไรวะ ได้ เออ

งบคนละ 2,000 เหรียญต่อเดือน ไม่รู้ใช้ไร โอ้โห โอ้โห อยู่ข้างหลัง นั่งอยู่ข้างหลังนั่น

โอ้โห เออ

เอ้า มี มีอีกอันหนึ่ง CodeRabbit CodeRabbit เออ อันนี้ เห็นเหมือนกันครับ แต่ผมยังไม่เคยลองนะ แต่ชื่อ CodeRabbit เห็น open source หลาย repo ใช้ เอ่อ แล้วก็ ล่าสุดที่ผมเห็นก็คือ โปรเจกต์ชื่อ Bun Bun เขาใช้ CodeRabbit กับ Claude เอ่อ fix bug หรือ implement feature ให้ แล้วประเด็นคือ สิ่งที่มันว้าวคือ เอ่อ Claude implement CodeRabbit review แล้ว Claude ก็มาตอบ CodeRabbit อีกทีหนึ่ง แล้วมันก็คุยกันเองไปเรื่อยๆ จน มัน มัน align กันน่ะ แบบเห็นด้วยกันแล้วก็จบ เออ แล้ว แล้ว maintainer ก็มา merge PR อะไรประมาณนี้ ซึ่ง ไม่รู้เหมือนกันว่ามัน มันจะเวิร์กไหม หมายถึงว่า เออ ในในส่วนคนที่ เป็น มุมของ maintainer คือผมก็ทำ open source เหมือนกัน เอ่อ แต่ผมยัง คุยกับคนในทีมละ ยังรู้สึกว่ามัน กูยังไม่อยากไปถึงจุดนั้น ที่แบบ กูไม่รู้ว่าอะไร merge เข้าไปอ่ะ แต่มันผ่าน อะไรเงี้ย นึกออกไหม เออ ก็ อันนี้แล้วแต่คน เออ งั้นใช้ Bun ก็ เข้าไปดูด้วยละกันนะ อะไรมันเข้าไปบ้าง อ่ะ โอเค ถ้าไม่มี มีคำถามอีกไหมครับ

Q&A: หากผูกเข้ากับ VS Code ระบบ Claude Code จะสามารถตรวจสอบดึงโชว์ Error LSP มาให้จัดการได้ทันที51:43

สุดท้ายละ

โอเคครับ

สวัสดีครับ (สวัสดีครับ) ผมมีคำถามอยากจะสอบถามนิดหนึ่ง เมื่อกี้เห็นโชว์เกี่ยวกับ code review graph ซึ่งโดย nature เวลาเราไม่ได้ใช้ AI ทำงานเนี่ย เราจะ rely บน LSP คู่กับ editor สมัยที่เราไม่มี AI ผมอยากจะ พอดีผมทำ personal project ที่เหมือนจะทำเป็นคล้ายๆ กับ เอา LSP มา integrate เพื่อให้มันใช้ hot ตลอดเวลา เลยอยากจะถามว่า ไอเดียถ้าเกิด ในมุมมองของคุณเนี่ย ถ้าเกิดเราแทนที่จะใช้ตัว code review graph แล้วมา โดย nature มันจะ cold start ใช่ไหมครับ (ครับ) ถ้าเกิดเรามาคล้ายๆ กับ adapt ให้มันมาใช้ LSP ของภาษาต่างๆ อ่ะ

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

ตั้งแต่แบบเขียนโค้ดด้วย Claude แล้วผม review plan มันอย่างเดียว เออ ฉะนั้นไม่แน่ใจเรื่อง anatomy ข้างใน พี่ พี่ไท พอจะมีแบบ (เราจะเอา LSP) ใช่ ว่าแบบ (อ๋อ) เออ Claude Code นะครับ

ถ้าเกิดเชื่อมกับ VS Code เนี่ย มันจะ มันจะเชื่อมกับ LSP อยู่แล้ว แปลว่าถ้าเราเปิด Claude Code ใน VS Code เนี่ย แล้วมันแก้ไฟล์อะไร แล้วมันมีขีดเส้นใต้แดงอะไรต่างๆ ตัว ตัว Claude Code เนี่ย มันจะดึงพวก (ดึง error มาแก้) ไม่ต้องใช้สกิล เพราะว่า Claude Code เขา

implement มาให้แล้วอ่ะครับผม เท่าที่ นี่ ครับผม

ครับ ขอบคุณครับ (ขอบคุณครับ)