ประสบการณ์ใช้งาน Claude Code 6 สัปดาห์
(blog.puzzmo.com)- หลังนำ Claude Code มาใช้ วิธีการเขียนและบำรุงรักษาโค้ดขนาดใหญ่ก็เปลี่ยนไปอย่างมาก จนเปรียบได้กับ “ช่วงเริ่มต้นของการนำการถ่ายภาพมาใช้ในโลกการเขียนโค้ด” ทำให้ พัฒนาได้รวดเร็วและแสดงออกได้อย่างอิสระ
- งานที่ทำซ้ำและเคยถูกมองว่าเป็น ‘หนี้ทางเทคนิค’ (เช่น migration, การเปลี่ยน framework) สามารถ ทำควบคู่กันได้อย่างรวดเร็วแม้ทำคนเดียว และแทบไม่เป็นภาระแม้ทำไปพร้อมกับงานหลัก
- เกิดรูปแบบการพัฒนาเชิงทดลองแบบ “ลองใช้ก่อนแล้วค่อยตัดสินทีหลัง” โดยสามารถ สร้างและลบ test/abstraction/โค้ดทดลองได้อย่างง่ายดาย จนได้ทั้ง productivity และ insight ในการพัฒนา
- การทำเกมต้นแบบ การทำงานร่วมกัน และการ deploy แบบทดลอง เร็วขึ้นมาก—นักออกแบบเกมสามารถเปลี่ยนไอเดียเป็นสิ่งที่รันได้จริงภายในไม่กี่ชั่วโมงโดยไม่ต้องเขียนโค้ดเอง
- ในสภาพแวดล้อมที่เหมาะกับ Claude Code เช่น monorepo, tech stack ที่ชัดเจน, codebase ที่ทันสมัย ความเร็วและความยืดหยุ่นของงานพัฒนาจริงเพิ่มขึ้นอย่างมาก
บทนำ: สิ่งที่เปลี่ยนไปหลังนำ Claude Code มาใช้
- ตลอด 6 สัปดาห์ที่ผ่านมาในการใช้งาน Claude Code รู้สึกได้ถึง การเปลี่ยนแปลงสำคัญ ในวิธีการเขียนและดูแลโค้ด
- รู้สึกเหมือนได้ "อิสระในการแสดงออก" เพราะไม่จำเป็นต้องเขียนโค้ดทุกบรรทัดด้วยตัวเอง
- เมื่อใช้ Claude Code เราสามารถวางโครงสร้างทั้งหมดได้ในครั้งเดียว แล้วใช้ความสามารถในการรีวิวและแก้ไขเพื่อสร้างผลลัพธ์สุดท้าย
- เหมือนกับตอนที่การถ่ายภาพถือกำเนิดขึ้นและเสน่ห์ของการวาดภาพด้วยมือลดลง ตอนนี้กระบวนการป้อนคำสั่งและการผลิตในงานโปรแกรมมิงก็กำลังเปลี่ยนไปอย่างมาก
- แม้การเปลี่ยนแปลงนี้อาจทำให้รู้สึกไม่สบายใจ แต่การมาของเครื่องมือที่อิง LLM กำลังก่อให้เกิด การเปลี่ยนกระบวนทัศน์ ต่อการเขียนโปรแกรม
1. วิธีที่ Claude Code เปลี่ยนการเขียนและบำรุงรักษาโค้ด
- งานอย่าง migration, refactoring, การลดหนี้ทางเทคนิค ที่ในอดีตใช้เวลาหลายสัปดาห์ถึงหลายเดือน หลังนำ Claude Code มาใช้ก็สามารถทำควบคู่กันและเสร็จได้ทั้งหมดภายใน 6 สัปดาห์
- ตัวอย่าง: การแปลง React Native components หลายร้อยตัวไปเป็น React, การเปลี่ยนระบบ RedwoodJS, migration จาก Jest → Vitest, server-side rendering, refactoring design system, อัปเกรด Node 22 เป็นต้น
- side project/backlog ที่เดิมต้อง “แยกเวลามาทำต่างหาก” สามารถ ทำควบคู่กับงานหลักในเวลาว่างได้ โดยแทบไม่เพิ่มภาระงาน
- สูตรเดิมที่ว่า “หนี้ทางเทคนิคต้องหาเวลาในแผนงานก่อนแล้วค่อยทุ่มทรัพยากรจำนวนมาก” ถูกทำลายลง และเกิดความ เริ่มทันที→เดินหน้าต่อ→จบได้เลยแบบฉับไว
2. วัฒนธรรมการพัฒนาเชิงทดลองแบบ “ลองใช้ก่อนแล้วค่อยตัดสิน”
- เมื่อมีไอเดียก็ลองทำกับ Claude Code ก่อน และเรียนรู้ผ่านการสร้างและลบสิ่งอย่าง test code แบบอัตโนมัติซ้ำไปมาในช่วงต้น
- แม้ยังไม่มี test strategy ฝั่ง frontend ก็สามารถ ให้ Claude Code สร้าง/ลบการทดสอบได้หลายรูปแบบแบบสด ๆ ในแต่ละ PR เพื่อสะสมประสบการณ์และช่วยตัดสินทิศทางโดยรวม
- การพิจารณาเรื่องไอเดียหรือ abstraction ก็ตรวจสอบและสำรวจได้อย่างรวดเร็วด้วยวิธี “ลองทำจริง→ล้มเหลวก็ไม่เป็นภาระ”
- ต้นทุนของความล้มเหลวลดลงอย่างมาก ทำให้ วงจรทดลอง-เรียนรู้-ตัดสินใจเร็วขึ้นอย่างชัดเจน
3. การเปลี่ยนแปลงของการพัฒนาแบบขนานและการทำงานร่วมกัน
- ใช้ git clone/VSCode profile สองชุด เพื่อทำงานแยกกันในแต่ละ clone (เช่น อันหนึ่งใช้ทำ PR อีกอันใช้ทำงานทดลอง)
- ระหว่างที่ Claude Code กำลังทำงาน ก็ไปทำงานแบบขนานในอีก clone ได้ หรือแยกให้ชัดด้วย theme/port ที่ต่างกันในแต่ละ clone
- เขียน Pull Request แบบขนาน พร้อมหลีกเลี่ยงการชนกันของพอร์ต dev server และเพิ่มประสิทธิภาพการทำงาน
4. ปฏิวัติกระบวนการพัฒนาเกมต้นแบบ/งานทดลอง
- เดิมกระบวนการ สร้างเกมต้นแบบ→ปล่อยใช้งานภายใน→รับ feedback→เปิดสาธารณะ/ทิ้ง ใช้เวลาหลายสัปดาห์ถึงหลายเดือน แต่หลังนำ Claude Code มาใช้ แม้แต่นักออกแบบก็สามารถเขียนโค้ดและ deploy ขึ้นเว็บไซต์ได้เองภายในไม่กี่ชั่วโมง
- ตั้งแต่ไอเดีย→ลงมือทำ→รับ feedback จากทีม→ยุติการทดลอง/ย้ายไป production (เขียนใหม่) ทำให้ รอบการ deploy สั้นลงอย่างมาก
- อย่างไรก็ตาม ก็มีโจทย์ด้านการปฏิบัติการใหม่ ๆ ตามมา เช่น การดูแลเกมชั่วคราวและเกณฑ์ในการทำให้เป็นทางการหรือยกเลิก
5. การใช้ Claude Code ในการเขียนโค้ดและการทำงานร่วมกันประจำวัน
- ระหว่าง weekly triage สามารถ ใช้ Claude Code GitHub action เพื่อสร้าง PR/ทำการทดลองแบบทันที และนำประเด็นเล็ก ๆ ไปใช้ได้ทันที
- สมาชิกทีมที่มีทั้งมุมมองด้านผลิตภัณฑ์และเทคนิค พร้อมความเป็นเจ้าของงาน จะใช้ Claude Code ได้อย่างมีประสิทธิภาพที่สุด หรือก็คือ ‘full-breadth developer’
- "Full-breadth developers" : ช่วยให้นักพัฒนาคนหนึ่งสามารถนำทั้ง workflow ของงานได้อย่างอิสระ
- เมื่อมนุษย์ยังคงรับบทรีวิวโค้ด ให้บริบท รวมถึงแก้ไขและตัดสินใจ ก็จะช่วยเพิ่มทั้ง productivity และความคิดสร้างสรรค์ของทีมโดยรวม
6. สภาพแวดล้อมของ codebase ที่เหมาะกับ Claude Code
- monorepo: เมื่อโค้ดทั้งหมด/DB schema/API/logic หน้าจออยู่ในที่เดียว Claude Code จะเหมาะมากกับการทำความเข้าใจบริบทและงานอัตโนมัติ
- ใช้ tech stack ที่เป็นมาตรฐาน (React, Relay, GraphQL, TypeScript, StyleX, Bootstrap ฯลฯ) ทำให้ LLM เข้าใจและทำงานอัตโนมัติได้ง่าย
- การทำ codebase ให้ทันสมัยและลด legacy ให้น้อยที่สุด ช่วยเพิ่มประสิทธิภาพของการใช้ LLM ได้สูงสุด
7. ข้อจำกัดของ Claude Code และความเปลี่ยนแปลงที่สัมผัสได้จริง
- แม้การเปลี่ยนแปลงเชิงปริมาณอย่างจำนวน PR/commit จะไม่ได้มากนัก แต่ ความเร็ว ความยืดหยุ่น และ productivity ที่สัมผัสได้ในการทำงานดีขึ้นมาก
- Claude Code ทำหน้าที่เสมือน pair programmer ระดับ ‘junior ที่มีประสบการณ์มากกว่า’ — หากวิศวกรดูแลคุณภาพโค้ด ตรรกะ และบริบท ก็จะกลายเป็นพาร์ตเนอร์ที่ยอดเยี่ยม
- มอบ ประสบการณ์การทำงานที่ต่างออกไปในเชิงคุณภาพ ทั้งในงานซ้ำ ๆ การลดหนี้ทางเทคนิค และการผลักดัน side project อย่างรวดเร็ว
8. กลยุทธ์ ‘การทำแบบขนาน’ ที่แนะนำสำหรับ junior/ผู้เรียน
- ไม่จำเป็นต้อง หมกมุ่นมากเกินไปกับเทรนด์ล่าสุด ของ ecosystem LLM
- สำหรับนักพัฒนามือใหม่ แนะนำให้ เขียนโค้ดด้วยตัวเองก่อน แล้วค่อย ให้ Claude Code ทำโจทย์เดียวกัน เพื่อใช้ในการ เปรียบเทียบและเรียนรู้
- สามารถอ้างอิงแนวทางของ Claude Code เพื่อเรียนรู้ abstraction และรูปแบบการทำงานจริงได้อย่างรวดเร็ว
- ใช้ LLM เป็นทั้ง 'คู่แข่ง+เมนเทอร์' เพื่อ พัฒนาทักษะการทำงานจริงและความเข้าใจ ecosystem สมัยใหม่ไปพร้อมกัน
- Claude Code เหมือนโทรศัพท์มือถือ ไม่จำเป็นต้องเปิดไว้ตลอดเวลา
- สิ่งสำคัญคือการเป็นฝ่ายควบคุมและใช้งานมันอย่างมีประสิทธิภาพ
9. การเพิ่มขึ้นอย่างก้าวกระโดดของ side project และการทดลองระยะสั้น
- งานอย่าง การทดลองเล็ก ๆ การพัฒนาเครื่องมือ หรือการปรับปรุงบล็อก ที่เดิมยากจะลองทำเพราะข้อจำกัดด้านเวลาและพลังงาน กลายเป็นสิ่งที่ทำได้ภายในไม่กี่ชั่วโมงด้วย Claude Code
- ไอเดีย→ลงมือทำทันที→ล้มเหลวก็ไม่เป็นภาระ — ทำการทดลองเชิงสร้างสรรค์/โปรเจกต์ส่วนตัวควบคู่กับ production ได้ง่าย
10. ตัวอย่างจริงของบทสนทนาและการรีวิวโค้ดกับ Claude Code
- มีตัวอย่างจริงของกระบวนการ ระบุความต้องการ-สร้างโค้ด-รัน-แก้ไข-รีวิว สำหรับสิ่งอย่างสคริปต์จัดการ DB, puzzle REPL, layout PDF ของ crossword
- LLM อาจเกิดข้อผิดพลาดได้ (การให้เหตุผลผิด การพูดเกินจริง hardcoding ฯลฯ) — วิศวกรต้องรับผิดชอบการตรวจสอบเชิงตรรกะและคุณภาพ จึงจะได้คุณค่าที่แท้จริง
11. ตำแหน่งของ Claude Code ในงานวิศวกรรมและบทสรุป
- Claude Code มีความสามารถโดดเด่นในการรับ บริบทที่กว้าง เช่น reference code, screenshot และคำอธิบายเพิ่มเติม
- Claude Code คือ โปรแกรมเมอร์ผู้ช่วยระดับ 'post-junior (สูงกว่า junior ที่ชำนาญ)' — ด้วยความอดทนไม่จำกัดและความเร็วสูง จึงมีประสิทธิภาพมากในฐานะพาร์ตเนอร์การทำงานจริง
- การออกแบบ คุณภาพ และการควบคุมขั้นสุดท้ายยังเป็นหน้าที่ของวิศวกรมนุษย์ ส่วน Claude Code ช่วยขยายขอบเขตและความเร็วของการ implementation การทดลอง และระบบอัตโนมัติอย่างมาก
- ทำให้เกิด สภาพแวดล้อมการพัฒนาที่หลุดพ้นจากข้อจำกัดที่ต้องเขียนโค้ดทีละบรรทัดด้วยตัวเอง และสามารถโฟกัสกับการออกแบบ การดูแลคุณภาพ และนวัตกรรมได้มากขึ้น
7 ความคิดเห็น
ผมเองก็ใช้งาน Claude Code ด้วยความพึงพอใจมากเช่นกัน
ตอนนี้ก็น่าจะใช้มาได้ราว ๆ 6 สัปดาห์แล้วครับ
เนื้อหาส่วนใหญ่รู้สึกเห็นด้วยมากครับ
https://jeho.page/essay/2025/07/15/claude-code.html
ความเห็นจาก Hacker News
หลังจากได้ลองใช้ Claude Code ราว 2 สัปดาห์ ผลคือมันน่าทึ่งมาก ทั้งที่ปกติผมค่อนข้างสงสัยเรื่อง AI สำหรับเขียนโค้ด การจะใช้ให้คล่องต้องผ่านช่วงเรียนรู้พอสมควร และจำเป็นต้องให้บริบทที่เหมาะสมพร้อมทั้งแบ่งงานให้ดี แน่นอนว่าต้องมีทักษะการเขียนโปรแกรม และถ้าโยนเรื่องที่ตัวเองไม่รู้ทั้งหมดให้ AI จัดการ ปัญหาต้องเกิดแน่ ๆ ด้วยประสบการณ์กว่า 25 ปี ผมมั่นใจว่าต่อให้ Claude Code สร้างอะไรออกมา ผมก็รีวิวและแก้ให้ถูกได้ถ้ามันผิด เมื่อราว 10~15 ปีก่อนผมเคยฝันถึงอะไรทำนอง neural interface ที่ทำให้ไม่ต้องเขียนโค้ดเอง และ Claude Code ก็ให้ความรู้สึกว่าไปได้ใกล้เคียงสิ่งนั้นพอสมควร บางครั้งผมติดลิมิตการใช้งานรายวันเลยลองใช้ Gemini CLI 2.5 pro model แทนเป็นหลัก แต่เทียบกับ Claude Code ไม่ได้เลย Gemini อืดและน่าอึดอัดเกินกว่าจะใช้ได้ สมัยก่อนผมนึกไม่ออกเลยว่าจะจ่ายเกิน 100 ดอลลาร์ต่อเดือนกับเครื่องมือพัฒนา ตอนนี้กำลังคิดจริงจังว่าจะอัปเกรดเป็น Max plan
ถ้าเป็นสถานการณ์ที่นักพัฒนาอาวุโสสามารถคอยให้คำแนะนำและกำกับนักพัฒนารุ่นจูเนียร์ได้ ผมคิดว่าเครื่องมือนี้เหมาะมาก จากที่ฟังนักพัฒนาอาวุโสรอบตัว หลายคนบ่นว่าพวกจูเนียร์กลับใช้ LLM สร้างโค้ดที่ยิ่งแปลก ช้า ไม่ปลอดภัย หรือเละเทะกว่าเดิม แล้วก็เปิด PR ทั้งที่ยังไม่เข้าใจโค้ด สิ่งที่มีประโยชน์กับผมที่สุดคือการสร้าง boilerplate (แค่อธิบายก็ให้มันร่าง class design ได้), แปลง JSON เป็น class หรือฟอร์แมตอื่น และคำถามอย่าง “โค้ดนี้มีปัญหาอะไร? ถ้าเป็นวิศวกรระดับ Staff จะเปลี่ยนยังไง?” มันช่วยหาบั๊กในโค้ดที่ผมพิมพ์เองล่วงหน้าได้จริงด้วย Claude Code
เรื่องที่น่าสนใจคือคนที่สงสัยใน “vibe coding” มักมีความคาดหวังต่ำมากก่อนจะได้ลองใช้เครื่องมือจริง หลายคนคิดว่าโค้ดที่ LLM สร้างต้องเป็นขยะ และเอาตัวอย่างสุดโต่งมาเหมาว่าเป็นค่าเฉลี่ย แต่พอได้ลองเองก็มักตกใจกับตัวเองว่ามันดีกว่าที่คิด แน่นอนว่าเราคงใช้ Claude Code ปั้น SaaS มูลค่า 1 พันล้านดอลลาร์ด้วยทีม 10 คนไม่ได้ทันที แต่ก็ยังมีคนอีกมากที่ประเมินพลังที่แท้จริงของเครื่องมือนี้ต่ำเกินไป
ถ้าพูดให้เคร่งครัด จริง ๆ แล้วคุณไม่ได้กำลังทำ vibe coding แต่ใกล้เคียงกับ software engineering ที่ใช้ AI มากกว่า vibe coding หมายถึงการเอาโค้ดที่ AI สร้างมาใช้ตรง ๆ โดยไม่เข้าใจแล้วเดินหน้าต่ออย่างเดียว ความหมายของคำนี้แต่ละคนก็ต่างกันไป ดังนั้นไม่ควรเชื่อคำว่า vibe coding มากเกินไป
แค่ไม่กี่เดือนก่อนผมยังไม่เคยจ่ายค่าสมัครบริการไหนเกิน 20 ดอลลาร์ แต่ตอนนี้ผมจ่าย Max 20 plan เดือนละ 200 ดอลลาร์อยู่ ผมเป็นนักพัฒนาชาวสโลวักที่อาศัยในสหรัฐฯ และมีประสบการณ์ 20 ปี ดังนั้นผมเองก็ยังแปลกใจ ผมลองเครื่องมืออื่นมาด้วย แต่ไม่ค่อยมีอันไหนที่ทำให้รู้สึกถึง productivity และ efficiency แบบตรงไปตรงมาได้ขนาดนี้ Claude Code มันคนละระดับจริง ๆ แน่นอนว่าต้องคอยกำกับรายละเอียดอยู่เรื่อย ๆ แต่วิธีของผมคือใช้ Plan Mode วาง requirement กับแผนการแก้โค้ดให้ละเอียดก่อน พอเห็นด้วย 100% ค่อยให้มันลงมือ แล้วค่อยทำ code review กับผลลัพธ์ที่ได้ (compiler error, unit test, lint issue ให้ AI แก้เอง) ให้ความรู้สึกเหมือนมีวิศวกรจูเนียร์ที่แปลก ๆ นิดหน่อยแต่มีความรู้มากและเร็วมากอยู่ข้างตัว ทิศทางของการพัฒนาซอฟต์แวร์กำลังไปทางนี้ชัดเจน และนี่คืออนาคต
ช่วงหลังผมรู้สึกว่า Claude model ไม่น่าเชื่อถือเท่าไรเวลาเขียน/แก้ SQL เช่น มันเขียนเงื่อนไขได้ดี แต่ไม่ใส่วงเล็บครอบ AND/OR ทำให้ Gemini pro ตรวจเจอเป็นบั๊กได้ถูกต้อง
เห็นด้วยอย่างมากว่า Claude Code นำหน้าคู่แข่งทุกตัวอย่างชัดเจน ตั้งแต่ปี 2023 ผมทำ cli tool สำหรับ AI code generation เองมาเรื่อย ๆ และเรียกได้ว่าแทบลองตัวเลือกหลัก ๆ มาหมดแล้ว ผมรู้สึกร่วมกับหลายวิธีที่ผู้เขียนใช้มาก:
ในข้อที่สอง (เริ่มจากสเปกที่ดี) อยากรู้ว่าคุณจัดสเปกอย่างไรในทางปฏิบัติ เช่น แยกเป็นเอกสาร Markdown ไหม และต้องละเอียดแค่ไหน อีกอย่างผมเห็นด้วยกับคำแนะนำที่ว่า “ดูแลเทสต์ตั้งแต่ต้น” แต่ในทางปฏิบัติพอ Claude มี test hooking แล้ว มันกลับข้ามขั้นตอนสร้างเทสต์ก่อน แล้ววนอยู่กับการแก้โค้ดโดยไม่ตรวจบั๊กหรือสมมติฐาน ผมเลยเคยทำ flag สำหรับเปิดปิดพฤติกรรมเกี่ยวกับเทสต์
monorepo อาจช่วยประหยัดเวลาให้คุณ แต่ก็ทำให้ tool call กับการใช้ token ของ Claude เพิ่มขึ้นมาก ผมคิดว่าแนวทางแบบ Aider ที่เลือกส่งเฉพาะไฟล์จำเป็นให้ AI น่าจะดีกว่า ผมไม่ค่อยเข้าใจว่าทำไม Claude ถึงนิยมมาก Aider ดีกว่าแทบทุกด้าน และยังต่อกับ LLM ได้หลากหลายกว่า
ถ้าจะใช้ CC ให้ดี โครงสร้างโปรเจกต์ต้องจัดมาดีพอสมควร ในโปรเจกต์ Django ที่มีทั้งเทสต์ type และเอกสารครบ CC จัดการได้ดีแทบทุกอย่าง แต่ก็ยังต้องมีการชี้ทางเป็นระยะ ๆ ช่วงหลังผมยังทำ side project ที่รัน CC แบบออฟไลน์บน local model ด้วย เวอร์ชันแรกทำได้ดีด้วยความช่วยเหลือจาก ChatGPT แต่พอเปลี่ยนมาใช้ CC กลับพบว่า CC วนอยู่กับประเด็นสำคัญและเลี่ยงข้อผิดพลาดไปเรื่อย ๆ แทนที่จะ refactor โค้ดเดิมหรือแก้บั๊ก มันชอบสร้างไฟล์/สคริปต์ใหม่เพิ่มขึ้นเรื่อย ๆ
อยากรู้ว่าคุณเอาเอกสารภายนอกมาจัดฟอร์แมตไว้ในโปรเจกต์โดยตรงไหม โปรเจกต์ส่วนใหญ่มีเอกสารอยู่แค่บนเว็บไซต์ เลยสงสัยว่าคุณยอมเสียเวลาทำเป็นไฟล์ Markdown ที่เรียบร้อยแยกไว้หรือเปล่า
พลังที่แท้จริงของ Claude Code คือมันไม่ได้หยุดอยู่แค่การเขียนโค้ด แต่ควบคุมคอมพิวเตอร์ทั้งเครื่องได้ ถ้ามี CLI tool อยู่ Claude ก็ใช้มันได้ และต่อให้ไม่มี บางครั้งแค่ถาม Claude ก็ทำให้ทึ่งได้เหมือนกัน เช่น ผมให้มันช่วยงานจุกจิกอย่าง crop/resize ภาพ, ดึง mp3 จากวิดีโอ YouTube, ลบช่วงไม่มีเสียงออกจากไฟล์เสียง เป็นต้น มันประหยัดเวลาให้ผมมหาศาลจนจำไม่ได้แล้วว่าเมื่อก่อนทำงานกันยังไง คิดว่าคงกลับไปทำแบบเดิมไม่ได้อีกแล้ว
แทนที่จะต่อ Claude เข้ากับคอมพิวเตอร์จริงของตัวเอง ควรให้มันใช้คอมพิวเตอร์แยกต่างหากจะดีกว่า (และไม่ควรเป็นเครื่องหลักของตัวเอง) สำหรับผมคือใช้ IDE ที่รันบน cloud VM แล้วเชื่อม Claude เข้ากับตรงนั้น จากนั้นเข้าผ่านเบราว์เซอร์ (https://brilliant.mplode.dev) ผมคิดว่านี่คือ UX ที่ใกล้เคียงกับการใช้งาน agent ที่เหมาะที่สุด ไม่ต้องเตรียม terminal หรือ ssh แค่ล็อกอินก็พอ และ instance ก็ถูกสร้าง/พักอัตโนมัติ สรุปคือ Claude + Linux instance ส่วนตัว + IDE ถูกเปิดขึ้นมาผ่านลิงก์ได้ทันที ต่อไปผมวางแผนจะให้เปิด instance ได้หลายตัวตามต้องการ และควบคุมสิทธิ์, filesystem, สิทธิ์ของ container (JWT ฯลฯ) ได้ละเอียดขึ้น ถ้าเกิดปัญหาหรือมีอะไรต้องรีวิว ก็เข้า IDE ไปจัดการได้ทันที ไม่จำเป็นต้องมี UI แยกด้วยซ้ำ จะดูผ่านหลาย panel ใน IDE หรือเปิด web app จากใน container โดยตรงก็ได้ ผมไม่เคยตื่นเต้นกับความก้าวหน้าทางเทคโนโลยีเท่าตอนนี้มาก่อน
ถึงทุกอย่างจะดูดี แต่ถ้าดูเฉพาะผลลัพธ์ด้านโค้ดจริง ๆ ข้อมูลก่อนและหลังแทบไม่ต่างกัน ต่อให้ทำงานด้วย Claude จำนวน commit, PR, หรือบรรทัดโค้ดก็ไม่ได้ต่างจากเดิมมาก นั่นคือ AI coding ให้ความรู้สึกว่า “productive ขึ้น” และ “ดีจังที่มีอะไรสักอย่างทำแทนเรา” แต่ในความเป็นจริงยังต้องรีวิว แก้ และ re-prompt จำนวนมาก สุดท้ายปริมาณผลลัพธ์รวมก็คล้ายเดิม และเมื่อเรายกส่วนที่ยากให้ AI ทำ ความสามารถในการออกแบบและคิดเองก็จะค่อย ๆ อ่อนลง พอลองใช้แต่ Claude หรือ LLM อื่น ๆ สักเดือน แล้วกลับมาทำแอปเล็ก ๆ ด้วยตัวเอง จะรู้สึกว่าทั้งโค้ดและการออกแบบโครงสร้างโดยรวมยากขึ้น ผลระยะยาวอาจทำให้ codebase ค่อย ๆ เสื่อมสภาพและกลายเป็นผลลบได้ด้วยซ้ำ (อย่างน้อยก็สำหรับ LLM รุ่นปัจจุบัน)
เมื่อก่อนผมต้องไล่ประกอบคำสั่ง ImageMagick (
mogrify) แบบดั้งเดิมทีละอย่างเอง การมีเครื่องมือ AI มาช่วยทำให้ประหยัดเวลาแบบบ้าคลั่งผมเคยให้ Claude ช่วยวิเคราะห์สาเหตุที่ Linux PC ล่มบ่อย ๆ มันดึง log จาก
journalctlแล้วช่วยหาต้นตอได้จริง เลยเป็นประสบการณ์ที่ช่วยแก้ปัญหาได้โดยตรงมากอีกตัวอย่างหนึ่งคือการสร้าง static site ง่ายขึ้นมาก จะเขียนบทความด้วยไวยากรณ์อะไรก็ได้ แล้วสั่ง Claude Code ว่าให้แปลงโพสต์นี้เป็นฟอร์แมตสำหรับบล็อก มันก็จัดการให้เอง เช่น แค่เขียนว่า “ใส่รูป image.jpeg ให้ด้วย” มันก็ทำให้ทันที ไม่ต้องยึดกับ Markdown หรือฟอร์แมตของ Hugo ก็สะดวกดี
ในฐานะคนที่ใช้ Claude code วันละ 12~16 ชั่วโมง ผมพบเคล็ดลับดังนี้:
ข้อ 5 นอกจาก docker แล้ว ถ้าเชื่อมกับ playwright MCP server ก็ทำให้มันตรวจทั้ง UI และ request ได้ทันทีเช่นกัน 6. เริ่มจาก plan mode แล้วให้มันวนปรับแผนจนกว่าจะพอใจ 7. ใช้ slash command (
/คำสั่ง) อย่างจริงจัง เพื่อปรับปรุงอย่างต่อเนื่องผ่าน mini prompt ให้บริบทเพิ่ม และสั่งใช้เครื่องมือภายนอกอย่างghได้ด้วย ส่วน compacting ไม่ควรรอให้เหลือ 0% แล้วค่อยทำ ควรทำระหว่างทางในจังหวะที่เหมาะสม สำหรับข้อ 1 (แนะนำ sonnet) บางคนอาจไม่เห็นด้วยปกติผมพยายามเลี่ยง docker แต่สนใจมากกับทิปข้อ 5 (ให้ Claude ทำ docker orchestration) อยากรู้ว่าคุณใช้รูปแบบ prompt แบบไหน
ผมเคยใช้วิธีทำไฟล์
plan.mdที่ละเอียดมากก่อน (เช่น การเชื่อมระหว่างระบบและสถาปัตยกรรมทั้งหมด) แล้วปล่อยรันข้ามคืนด้วยเครื่องมืออย่าง claude-loop(https://github.com/DeprecatedLuke/claude-loop) จากนั้นตอนเช้ามาค่อย patch ด้วยมือ วิธีนี้ก็ได้ผลดีเหมือนกันอยากรู้ว่าคุณใช้ Claude Code วันละ 16 ชั่วโมงได้อย่างไร
บางครั้ง Claude ชอบไปยุ่งใน container มากเกินไป ทั้งที่ผมแค่อยากให้มันเข้าใจโค้ด แต่มันกลับพยายามรันโค้ดภายใน container หลายรูปแบบจนทำให้ทุกอย่างแปลกไป เคยมีช่วงหนึ่งมันเอาไฟล์ไป pipe ผ่านคำสั่ง cli แล้วก็ไม่ได้เกิดอะไรขึ้นเลย เป็นตัวอย่างของนิสัยที่พยายาม “รันอะไรสักอย่าง” แบบหมกมุ่นเกินเหตุ
ผมไม่รู้ว่า Claude Code ดีแค่ไหนจริง ๆ (เพราะยังไม่เคยใช้เอง) แต่มีประเด็นที่ทำให้ลังเลอยู่ ผมอยาก refactor gdscript (สาย Python) ที่ทั้งช้าและรก ให้เป็น C# ในโปรเจกต์ส่วนตัว เพื่อให้สะอาดและเร็วขึ้น งานนี้เป็นความท้าทายใหม่สำหรับผมและมีคุณค่าด้านการเรียนรู้ ถ้าใช้ Claude ก็เหมือนกำลังแย่งโอกาสในการเรียนรู้ที่มีค่าจากตัวเองไป (ซึ่งอาจช่วยการเติบโตระยะยาวได้) แต่ถ้าไม่ใช้ ก็เหมือนต้องเอาเวลาอันมีค่าไปทุ่มกับงานน่าเบื่อที่ในอนาคตยังไงก็คงถูกทำให้อัตโนมัติอยู่ดี เลยติดอยู่ในภาวะกลืนไม่เข้าคายไม่ออกซ้ำ ๆ
จากประสบการณ์พัฒนา 35 ปี ผมใช้วิธีมอบงานให้ AI เฉพาะตอนที่ผมทำเองได้แต่ไม่อยากทำ (น่าเบื่อหรือซ้ำซาก) ไม่ว่าจะเป็น LLM ตัวไหนก็ตาม เช่น การแก้ Open API 3.0 schema ถ้าผมทำเองก็ไม่ได้เรียนรู้อะไรใหม่เลย เลยให้ Claude ทำ รวมถึงการสร้าง example code ก็ให้ AI จัดการ ส่วนสิ่งที่เป็นจุดเรียนรู้ใหม่จริง ๆ ผมจะสรุปเป็น flashcard ในแอปอย่าง Anki SRS หรือเขียนไว้ในบล็อก TIL หรือไม่ก็ลงมือทำตัวอย่างเดิมซ้ำหลายรอบเพื่อให้กลายเป็นประสบการณ์ สิ่งสำคัญคือความรู้ใหม่ต้องถูกเชื่อมเข้ากับสมองอย่างน้อย 2 ครั้งขึ้นไปถึงจะเรียนได้ผล เหมือนเวลาเรียนคำศัพท์ใหม่ เราเอาไปใช้ใน 3 ประโยคต่างกัน
ถ้าคุณไม่รีวิวโค้ดที่สร้างขึ้นเองโดยตรง (คือยังไม่รู้ C# ดีพอ) codebase จะพังอย่างรวดเร็ว LLM coding มีแนวโน้มให้ความผิดพลาดสะสม จึงจำเป็นต้องปรับปรุงอย่างจริงจัง ไม่งั้นจะกลายเป็นกองขยะที่ดูแลต่อไม่ได้ เพื่อนรอบตัวผมบอกว่าทำให้ AI สร้างเทสต์ให้เพียงพอจะช่วยเจอปัญหาได้ตั้งแต่ต้น แต่ผมเองยังไปไม่ถึงจุดนั้น เพราะโค้ดของผมออกแนว logic มากกว่า algorithm เลยเขียนเทสต์ลำบากพอควร
ในฐานะนักพัฒนามืออาชีพมา 16 ปี ผมรู้สึกว่า Claude Code ช่วยให้เรื่องที่เคยชนกำแพงและต้องนั่งกุมขมับ แก้ได้ง่ายขึ้นมาก เวลาเรียนอะไรใหม่ให้เร็ว เครื่องมือ AI (โดยเฉพาะโหมดถามตอบอย่าง "ask") มีประสิทธิภาพสูง ผมใช้ทั้งอุปมา กรณีตัวอย่าง และเทคนิคช่วยจำอย่างเต็มที่ ถ้าเป้าหมายคือการเรียนให้ลึกแบบค่อยเป็นค่อยไป วิธีดั้งเดิมที่ช้ากว่ายังดีกว่า แต่ถ้าเป้าหมายคือเรียนให้เร็ว การใช้ AI ก็ไม่ใช่ทางเลือกที่แย่ ถ้าอยากได้ผลลัพธ์จริง ๆ การเขียนสเปกให้ดีและมีเทสต์เพียงพอก็สำคัญ สุดท้ายไม่ว่าจะใช้วิธีไหน ผมคิดว่าการสร้างอะไรออกมาอย่างต่อเนื่องต่างหากที่มีความหมาย
เมื่อก่อนเคยมีกระแสบล็อกแนว “ลองสร้าง x library ของตัวเองดู” กระบวนการลงมือสร้างอะไรเองนี่แหละที่ทำให้เราเรียนรู้ได้มากที่สุด เช่น ถ้าอยากเข้าใจ client-side router ก็ลองเขียน router เอง ในยุค LLM อะไรก็อาจถูกแทนที่ด้วยโค้ดจาก library ได้ แต่ถ้าผมอยากเรียน C# ให้จริง การ port เองน่าจะดีที่สุด ถ้าต้องการแค่ผลลัพธ์และอยากโฟกัสกับเรื่องอื่น จะให้ Claude ทำก็ได้ การเรียนรู้ต้องมีช่วงที่เจ็บปวดเสมอ ถ้ามันง่ายเกินไป ก็อาจแปลว่าเราไม่ได้เรียนรู้อะไรเลย
ก่อนยุค AI การคัดลอกวางคือกระแสหลัก เพื่อนหลายคนที่หยิบโค้ดจาก Stackoverflow มาใช้โดยไม่เข้าใจเหตุผล สุดท้ายก็ไม่ได้เรียนรู้อะไรอยู่ดี ผมคิดว่าให้ AI ช่วยอธิบายแนวคิดหรือให้คำแนะนำไม่ใช่ปัญหา แต่ถ้าให้มันเขียนทุกอย่างแทนทั้งหมด ก็ชัดเจนว่าไม่ได้เรียนรู้อะไร อย่างไรก็ตาม การปกป้องเวลาของตัวเองในฐานะนักพัฒนาก็เป็นเรื่องฉลาด เพราะยังมีสิ่งที่ต้องเรียนอีกมาก ถ้าเป้าหมายคือการพัฒนาเกม การ port GDscript อาจไม่ใช่ประสบการณ์จำเป็นที่สุดก็ได้ แม้แน่นอนว่ามันมีส่วนที่ให้เรียนรู้อยู่จริง
จากประสบการณ์เขียนโค้ดด้วย Claude Code ราว 3 สัปดาห์ ผมเป็นนักพัฒนา 10 ปีที่ทำงานสาย Python ML/data engineering เป็นหลัก เหตุผลมีหลายอย่าง:
การลดความเจ็บปวดตอนเริ่มต้นนี่สำคัญมากจริง ๆ แต่ก่อนมีหลายอย่างที่คิดว่า “ถ้ามีเวลาคงอยากทำ” แต่ตอนนี้ใช้แค่ไม่กี่ prompt ก็ลงมือได้เลย จริง ๆ ผมเคยอยากทำเกม NYT Connections บน terminal แล้วมันก็เสร็จใน 3 prompt (https://github.com/jleclanche/connections-tui)
ข้อ 4 น่าประทับใจมาก เมื่อก่อนการปล่อยเทสต์หรือหนี้เทคนิคค้างไว้เป็นเรื่องปกติ แต่ตอนนี้แค่บอกว่า “ควรมี test suite” มันก็สร้างอะไรที่ค่อนข้างดีให้ได้อัตโนมัติ ต่อให้ไม่สมบูรณ์แบบ อย่างน้อยงานระดับกลาง ๆ ก็ถูกจัดการได้แน่นอน
ในฐานะคนส่วนน้อยที่ยังอยากลองทำ agentic coding ต่อไปด้วยความอยากรู้ ผมพยายามหาคำอธิบายว่าทำไมประสบการณ์ของผมถึงต่างจากกระแสหลัก คิดว่าประโยคนี้น่าจะอธิบายได้ตรงที่สุด:
ผมยังสงสัยว่าโลกที่ผู้คนยังวาดภาพและยอมจ่ายเงินซื้อภาพนั้นยังอยู่จริงแค่ไหน งานหัตถกรรมจำนวนมากก็ถูกเบียดด้วยสายการผลิตแบบโมดูลาร์และการผลิตจำนวนมากไปแล้ว ตอนนี้ดูเหมือนคุณค่าจะไม่ได้อยู่ที่ตัวสินค้าเพียงอย่างเดียว แต่เป็นประสบการณ์ร่วมทางจินตนาการระหว่างผู้ผลิตกับผู้บริโภคมากกว่า ไม่ใช่แค่สั่งของจาก Amazon แต่เป็นการเสพความสัมพันธ์กับช่างฝีมือและเรื่องเล่าของกระบวนการสร้างสรรค์ ผมคิดว่าในอนาคตการเขียนโค้ดก็น่าจะต้องไปในทางนี้ถ้าจะอยู่รอด
ผมเข้าใจมุมนี้มาก ผมยอมรับประโยชน์ของ agent coding สำหรับงานเล็ก ๆ, bug fix, หรือทำร่างแรก แต่ไม่เข้าใจว่าทำไมถึงมีการถกเถียงกันแรงเรื่องจะเชียร์หรือคัดค้าน interface ต่าง ๆ ที่ห่อหุ้มโมเดลอยู่แค่ไม่กี่ตัว ส่วนผลกระทบต่อ junior dev ผมยังคิดไม่ตก ถ้า AI ช่วยทำ code review อัตโนมัติได้ด้วย ชีวิตผมน่าจะมีความสุขขึ้นอีกมาก
ผมไม่คิดว่าอุปมานั้นใช้ได้ทั้งหมด ในเชิงประวัติศาสตร์ painting เคยเป็นวิธีเดียวในการจำลองโลกจริง แต่ศิลปะไม่ใช่แค่การลอกเลียน มันคือการตีความของผู้สร้าง นั่นจึงเป็นเหตุผลที่คนยังวาดภาพอยู่ ถ้ามองว่าการเขียนโค้ดเป็นศิลปะ ก็ยังทำต่อไปได้ แต่หลายคนมีเป้าหมายคือการพัฒนาผลิตภัณฑ์ และตัวผลิตภัณฑ์เองต่างหากที่เป็นงานศิลปะ ถ้า AI พาไปถึงเป้าหมายนั้นได้เร็วขึ้น ก็เป็นธรรมดาที่การเลือก AI จะดีกว่า ในอีกด้านหนึ่ง ผมก็คิดถึงยุค “code monkey” (เขียนโค้ดล้วน ๆ) เหมือนกัน ดูเหมือนเรากำลังไปสู่โลกที่ทุกคนต้องเป็นเหมือน lead developer คอยกำหนดทิศทาง, รีวิวโค้ด, และตัดสินใจทางเทคนิค การต้องจับงานเขียนโค้ดจริงให้น้อยลงในงานประจำก็มีส่วนที่น่าเสียดาย
อุปมาที่เหมาะกว่าน่าจะเป็นการเปลี่ยนจาก hand-tool ไปสู่ power tool มากกว่า อุปมาแบบ painting-vs-photography ดูเหมือนขยายความเกินไป เพราะมันไม่ใช่การเกิดขึ้นของสื่อใหม่ในระดับนั้น agent coding ยังไม่ได้ปฏิวัติถึงขนาดนั้น
ผมพยายามใช้ Claude Code ให้เยอะขึ้น แต่รู้สึกว่ามันช้าเกินไปและมักหลุดประเด็นอยู่เสมอ จนน่าหงุดหงิด ในงานส่วนใหญ่ผมไม่รู้สึกว่ามันช่วยประหยัดพลังงานทางจิตใจได้จริง แม้บางงานจะมีประโยชน์ แต่ก็มักถูกหักหลังในจังหวะสำคัญจนไม่อยากใช้บ่อย ๆ เช่น ผมเคยให้มันช่วยแปลง
.zshrcเป็น nushell มันงมอยู่ 30 นาทีแต่ก็ยังรันไม่ได้ ทั้งที่ถ้าผมเปิดเอกสารทางการเองใช้เวลาไม่ถึง 10 นาที ประสบการณ์น่าผิดหวังแบบนี้ทำให้ไม่ค่อยอยากกลับไปใช้ Claude อีกประสบการณ์นี้คล้ายของผมเลย ผมพยายามให้มันช่วยเขียนเทสต์ แต่สุดท้ายก็ต้องเขียนใหม่เองเกือบทุกครั้ง เรื่องดีบักก็ไม่เคยเห็นผลลัพธ์ที่ชัดเจน มันพอใช้ได้กับงานง่าย ๆ อย่างแปลงสคริปต์ (เช่น parse output ของคำสั่ง) หรือ scaffold โปรเจกต์ใหม่เท่านั้น (แต่เราทำเรื่องแบบนี้บ่อยแค่ไหนกัน) สำหรับการ port โค้ดง่าย ๆ มันพอได้ แต่ประสบการณ์ล้มเหลวมีมากกว่ามาก
อยากถามว่าเคยลองใช้ context7 MCP ไหม พวก LLM มักอ่อนกับภาษาไม่ค่อยนิยมและโดเมนที่ไม่คุ้นเคย วิธีแบบ context7 ที่ดึง reference จาก source ล่าสุดมาให้โดยตรงดูจะได้ผลดีกว่า
เพราะ RSI และ carpal tunnel syndrome ผมเคยเขียนโค้ดได้น้อยลง แต่ด้วย Claude ตอนนี้ผมกลับมาเขียนโปรแกรมได้อีก (ความเจ็บปวดลดลงเหลือประมาณหนึ่งในสิบ) เดิมทีผมแทบอยากปฏิเสธเทคโนโลยีนี้ แต่ถ้าจะรักษาอาชีพไว้ ตอนนี้มันกลายเป็นสิ่งจำเป็นแล้ว
ผมได้ยินเรื่องแบบนี้จากหลายคนมาก สำหรับคนที่มี RSI เครื่องมืออย่าง Claude คือ game changer ของจริง เพราะมันช่วยงานซ้ำ ๆ ที่หนักและน่าเบื่ออย่าง boilerplate ได้ง่ายขึ้นมาก เมื่อก่อนแค่เห็นโค้ดซ้ำ ๆ ก็ปวดทั้งข้อมือและสภาพจิตใจ แต่ตอนนี้แทบไม่ต้องกังวล และกลับไปโฟกัสกับปัญหาเชิงนามธรรมหรือปัญหาใหม่ ๆ ได้ ทำให้การเขียนโปรแกรมสนุกขึ้นอีกครั้ง หลายคนกังวลว่า “เครื่องมือแบบนี้อาจทำให้อาชีพจบลง” แต่ผมกลับเชื่อว่ามันจะช่วยรักษาอาชีพผมไว้ต่างหาก
หลังจากเริ่มใช้ Claude อาการปวด RSI ของผมแทบหายไปเลย โดยเฉพาะเพราะมันแทนที่งานซ้ำ ๆ ได้ด้วยคำสั่งและประโยคที่แม่นยำมาก ผมยังได้ยินกรณีใช้ร่วมกับ voice recognition เยอะขึ้น และมันเหมือนกำลังเปิดประตูด้าน accessibility ด้วย
ผมคิดว่าถ้าใช้ Claude Code ผ่านเสียงได้โดยตรงน่าจะช่วยมากขึ้นอีก บน MacOS มีตัวเลือก TTS/ASR ฟรี และยังต่อ voice engine อื่นแบบ BYOK ได้ด้วย (https://github.com/robdmac/talkito)
ถ้ามีแอป STT/รู้จำเสียงที่แม่นยำและสะดวกพอ การอธิบายบริบทละเอียดให้ Claude Code ผ่านเสียงก็มีประสิทธิภาพดี จากที่ลองแอป speech recognition มาหลายตัว ตัวที่เหมาะกับผมที่สุดคือ Wispr Flow เพราะมีทั้งโหมด hands-free ผ่านคีย์ลัด และให้ทั้งความแม่นยำกับความเร็ว เพียงแต่ผมก็หวังว่าจะรองรับ local app ด้วย
อยากรู้ว่าคุณใช้การป้อนข้อความด้วยเสียงอยู่หรือเปล่า
ในมุมมองด้านการบำรุงรักษา ผมเห็นด้วยกับผู้เขียนมาก เมื่อก่อนงานอย่างการ refactor หรือ TODO/ticket สำหรับเตือนความจำมักถูกทิ้งไว้ก่อน แต่ด้วย Claude ตอนนี้ผมลงมือทำทันทีได้เลย ช่วยลดภาระงานซ้ำ ๆ ไปมาก และยังลองไอเดีย refactor ได้รวดเร็ว ถ้าไม่ชอบก็ทิ้งได้ง่าย พลังงานเริ่มต้นสำหรับงานแนวนี้ลดลงอย่างชัดเจน ผมยังเห็นด้วยว่า ถ้าปล่อย AI agent ทำงานแบบขนาน/ออฟไลน์อย่างไร้การควบคุม อาจนำไปสู่ burnout และคุณภาพโค้ดที่ลดลงได้ จึงควรอยู่ในโหมด human supervision เสมอ นอกจากนี้ผมยังเขียนสรุปเพิ่มเติมไว้ที่ https://www.modulecollective.com/posts/agent-assisted-coding...
ความรู้สึกของผมก็เหมือนกับผู้เขียนต้นฉบับเลยครับ 555
จ่าย $200 แล้วแก้ปัญหายากระดับ 4 ปีได้ภายในแค่ชั่วโมงเดียว
ถ้าผมทำเองคนเดียว... หรือใช้ Cursor ก็คงไม่มีทางแก้ได้จริง ๆ
พอจะอธิบายความแตกต่างตอนใช้ Claude Code กับตอนใช้ Cursor + Claude LLM ได้ไหมครับ?
ตอนนี้ผมใช้ Cursor อยู่ แต่กำลังลังเลว่าจะย้ายไปใช้ Claude Code ดีไหม
หมายถึง API key ของ Claude LLM ใช่ไหมครับ?
หรือหมายถึงโมเดล Agent ที่อยู่ใต้หน้าต่างแชตกันแน่?
ผมก็เคยใช้ Cursor แล้วพอใจมากเหมือนกัน แต่ติดลิมิตการใช้งานบ่อย เลยใช้แพ็กเกจ $60 ไปพลางก็ยังคอยกังวลว่าจะติดลิมิตอีกหรือเปล่า
เพราะงั้นเลยต้องสลับไปใช้ gemini cli ด้วย ทำให้เครียดพอสมควรครับ
Cursor + Claude 4 sonnet ก็ดีมากพออยู่แล้ว แต่พอผ่านไปวันหนึ่งก็ติดลิมิต และพอติดลิมิตแล้วใช้ต่อไม่ได้ทั้งเดือน อันนี้เป็นปัญหาใหญ่ที่สุดสำหรับผม
ส่วน Cursor + Claude 4 opus นี่ไม่กล้าลองใช้เลยครับ
สุดท้าย Claude Code ก็เป็น CLI-based อยู่แล้ว และไม่ค่อยขึ้นกับลักษณะเฉพาะของ IDE เลยตัดสินใจลองใช้ดูครับ
ตอนแรกใช้แพ็ก $20 แต่เจ้าตัวนี้ก็ไม่มี opus เหมือนกัน
พอเริ่มจะติดลิมิต ผมเลยตัดสินใจจ่าย $200 โดยคิดว่าเอาแค่ลองใช้สักเดือน แล้วพอได้ใช้จริง
เหมือนเปิดโลกใหม่เลยครับ opus ... คนละระดับจริง ๆ...
ตอนนี้ใช้แพ็ก $200 มาได้ 4 วันแล้ว และกำลังเคลียร์โจทย์ยาก ๆ ที่ค้างไว้ออกได้หมดเลย ฮ่าๆ
ดูเหมือนจะแก้ไขโพสต์ไม่ได้เลยนะ
เหมือนจะไม่ใช่หนึ่งเดือน แต่เป็นหนึ่งวันมากกว่านะครับ ตลอดทั้งเดือนเลยคอยกังวลอยู่ตลอด
แล้วก็ทะเลาะกับ Cursor มาเยอะพอสมควร แต่
กับ Claude Code ไม่ค่อยได้ทะเลาะกันเท่าไหร่ครับ
โอ้ ขอบคุณมากสำหรับคำตอบที่ละเอียดมากครับ
ผมเองก็ติดลิมิตเลยไม่มีทางเลือก ต้องใช้ Cursor ในโหมด Auto อยู่เหมือนกัน แต่คงต้องย้ายตามไปแล้วล่ะครับ