- สรุปประสบการณ์ตลอด 6 สัปดาห์ที่จำนวนคอมมิตเพิ่มขึ้นอย่างรวดเร็ว ผ่านการ ปรับปรุงโครงสร้างพื้นฐานการพัฒนา เช่น การทำงานอัตโนมัติสำหรับงานซ้ำๆ ของ AI agent, การกำจัดเวลารอบิลด์, และการสร้างระบบ worktree แบบขนาน
- ใช้สกิล
/git-pr ทำให้กระบวนการสร้าง PR เป็นอัตโนมัติ จึงลด ต้นทุนจากการสลับคอนเท็กซ์ และให้ agent เขียนคำอธิบาย PR ที่ละเอียดกว่าเดิมได้เอง
- เปลี่ยนเครื่องมือบิลด์เป็น SWC ทำให้การรีสตาร์ตเซิร์ฟเวอร์สั้นลงเหลือไม่ถึง 1 วินาที จึงได้สภาพแวดล้อมการพัฒนาที่โฟลว์ไม่สะดุด
- ใช้ ฟีเจอร์พรีวิว ของ Claude Code ให้ agent ตรวจสอบ UI ด้วยตัวเอง จึงแก้คอขวดที่เดิมนักพัฒนาต้องคอยตรวจทุกการเปลี่ยนแปลงด้วยตัวเอง
- เมื่อค่อยๆ กำจัดแต่ละจุดเสียดทานออกไป ก็จะเห็นคอขวดถัดไปโผล่ขึ้นมาตามลำดับ ซึ่งตรงกับแพตเทิร์นของ Theory of Constraints
- ตอนนี้จึงโฟกัสที่ การสร้างโครงสร้างพื้นฐานให้ agent ทำงานได้มีประสิทธิภาพ และเพิ่มความเร็วของลูป มากกว่าการลงมือพัฒนาฟีเจอร์เอง
ทำงานซ้ำๆ ให้เป็นอัตโนมัติ
- ช่วงแรกยัง ทำทุกอย่างด้วยมือ ตั้งแต่ stage การเปลี่ยนแปลง, เขียนข้อความ commit, เขียนคำอธิบาย PR, push ไปจนถึงสร้าง GitHub PR
- จุดเปลี่ยนแรกคือการตระหนักว่างานนี้เป็นงานซ้ำๆ (grunt work) และบทบาทของตัวเองก็เปลี่ยนจาก ผู้ลงมือ implement ไปเป็น ผู้จัดการที่คอยดูแล agent
- จึงเขียนสกิล Claude Code ตัวแรกคือ
/git-pr เพื่อทำให้ทั้งกระบวนการสร้าง PR เป็นอัตโนมัติ
- เพราะ agent อ่าน diff ทั้งหมดและสรุปการเปลี่ยนแปลงได้ถูกต้อง จึงทำให้ คำอธิบาย PR ละเอียดกว่า ที่เคยเขียนเอง
- ในโค้ดเบสมีการระบุใน
CLAUDE.md ว่าใช้ Graphite แต่ส่วนตัวชอบ plain git มากกว่า จึงใช้ /git-pr ในการทำงาน
- ประโยชน์ที่ใหญ่กว่าการประหยัดเวลา คือการลด ภาระทางความคิด: การสลับคอนเท็กซ์เล็กๆ จาก “โหมดคิดเขียนโค้ด → โหมดคิดอธิบายโค้ด” ทุกครั้งที่เขียน PR หายไป
กำจัดเวลารอ
- เพื่อดู local preview ต้องคอยออกจากงานที่กำลังทำอยู่ ปิด dev server แล้วรีสตาร์ตบน branch ใหม่ ซ้ำแล้วซ้ำอีก
- การบิลด์เซิร์ฟเวอร์ใช้เวลาราว 1 นาที ซึ่งนานพอจะทำลายสมาธิ แต่ก็สั้นเกินกว่าจะไปทำอย่างอื่นอย่างจริงจัง
- จึงเปลี่ยนระบบบิลด์เป็น SWC ทำให้การรีสตาร์ตเซิร์ฟเวอร์สั้นลงเหลือ ไม่ถึง 1 วินาที
- พอบันทึกไฟล์ เซิร์ฟเวอร์ก็พร้อมอยู่แล้วทันที จึงแทบไม่มีช่องว่างให้สมาธิหลุด
- เปรียบได้กับความต่างระหว่าง “บทสนทนาที่มีช่วงเงียบกระอักกระอ่วน” กับ “บทสนทนาที่ลื่นไหลเป็นธรรมชาติ”
ให้ agent ตรวจสอบ UI เอง
- ก่อนหน้านี้ต้องเปิด local preview เพื่อตรวจทุกการเปลี่ยนแปลงของ UI ด้วยตัวเอง จึงทำให้ นักพัฒนาเป็นคอขวดของทุกฟีเจอร์
- หลังจาก Chrome extension แครชอยู่เรื่อยๆ จึงย้ายมาใช้ ฟีเจอร์พรีวิว ของ Claude Code
- agent สามารถตั้งค่าพรีวิวและคงข้อมูลของเซสชันไว้ได้ พร้อมทั้ง เห็นเองโดยตรงว่า UI หน้าตาเป็นอย่างไรจริงๆ
- เมื่อนำเข้ามาอยู่ใน workflow แล้ว จะถือว่า agent “เสร็จงาน” ได้ก็ต่อเมื่อมันตรวจ UI ด้วยตัวเองแล้วเท่านั้น
- ทำให้มอบหมายงานตรวจสอบได้ และเราเข้าไปมีส่วนร่วมเฉพาะตอนรีวิวสุดท้าย ขณะที่ agent ก็ทำงานต่อได้อย่างอิสระนานขึ้น
- ผลลัพธ์ที่สำคัญกว่าที่คาดไว้มากคือ agent จับความผิดพลาดของตัวเองได้
ระบบ worktree แบบขนาน
- เมื่อมีทั้งรีบิลด์ที่รวดเร็วและพรีวิวอัตโนมัติแล้ว จุดเสียดทานถัดไปที่ชัดขึ้นคือ ยังทำงานได้สะดวกทีละงานเดียว
- หากต้องรีวิว PR ของ agent ตัวอื่นหรือของเพื่อนร่วมทีม ก็ต้อง checkout จาก main ไปยัง PR branch แล้วรีบิลด์กับรันทดสอบ แต่จะชนกับการเปลี่ยนแปลงที่ยังไม่ได้ commit
- ต้องทำ stash → checkout → rebuild → test → switch back → pop stash หรือไม่ก็สร้าง worktree ด้วยมือแล้วเจอปัญหา port ชนกัน
- แอปต้องใช้พอร์ตแยกระหว่าง frontend กับ backend และทุก worktree ก็ แชร์ environment variable ชุดเดียวกัน จึงพยายาม bind ไปที่พอร์ตเดียวกัน
- เพื่อแก้ปัญหานี้ จึงสร้างระบบที่ตอนสร้าง worktree จะ จัดสรรช่วงพอร์ตเฉพาะให้แต่ละเซิร์ฟเวอร์โดยอัตโนมัติ
- ทำให้เปิดพรีวิวพร้อมกันได้ถึง 10 ตัว
- จากเดิมที่แค่มี 2 branch แบบขนานก็ล้นมือแล้ว กลายเป็นสามารถ ดูแล 5 worktree พร้อมกัน ได้
- รัน agent หลายตัวใน worktree แยกกัน ให้แต่ละตัวสร้างฟีเจอร์คนละอย่าง และ ปล่อยให้ทำงานเองจนกว่าจะตรวจ UI ของตัวเองเสร็จ
- เข้าไปมีส่วนร่วมลึกในช่วงวางแผน แล้ว ไม่ต้องแทรกแซงอีกจนกว่าจะถึงเวลาทำ code review
- การรีวิวก็ลื่นไหลขึ้นมาก: ไม่ต้องตั้งค่า ไม่ต้องรีบิลด์ ไม่ต้องแก้พอร์ตชน แค่ อ่าน ตรวจ และ merge
แก่นสำคัญไม่ใช่ AI แต่เป็นโครงสร้างพื้นฐาน
- บทบาทเปลี่ยนไป: แทนที่จะใช้เวลาแก้ปัญหาซับซ้อนด้วยตัวเองและทำ UI ให้สมบูรณ์ กลับรู้สึกสนุกกว่ากับการ สร้างโครงสร้างพื้นฐานที่ทำให้ agent ทำงานได้ดีขึ้น
- คล้ายกับการกลายเป็นผู้จัดการของทีมขนาด 10 คน มากกว่าจะเป็นนักพัฒนาเดี่ยว
- แม้จะเป็นงานระบบหลังบ้านที่ไม่หวือหวา แต่สิ่งนี้เองที่ตัดสินว่าเราจะ อยู่ในภาวะลื่นไหลต่อเนื่อง หรือมัวแต่สู้กับสภาพแวดล้อม
- ที่ Tano งานที่ให้แรงทดสูงสุดไม่ใช่การพัฒนาฟีเจอร์ แต่คือ การสร้างโครงสร้างพื้นฐานที่เปลี่ยนกระแสของคอมมิตให้กลายเป็นสายน้ำเชี่ยว
ลูป: การประยุกต์ใช้ Theory of Constraints
- แต่ละขั้นตอนช่วยกำจัดจุดเสียดทานคนละแบบ:
/git-pr: กำจัด จุดเสียดทานด้านการจัดรูปแบบ ในการเปลี่ยนโค้ดให้กลายเป็น PR- SWC: กำจัด จุดเสียดทานจากการรอคอย ระหว่างแก้ไขแล้วต้องรอดูผล
- ฟีเจอร์พรีวิว: กำจัด จุดเสียดทานด้านการตรวจสอบ การเปลี่ยนแปลง
- ระบบ worktree: กำจัด จุดเสียดทานจากการสลับคอนเท็กซ์ ระหว่างหลายสายงาน
- ทุกครั้งที่กำจัดอย่างหนึ่งออกไป คอขวดถัดไปก็จะปรากฏขึ้นทันที ซึ่งเป็นแพตเทิร์นแบบคลาสสิกของ Theory of Constraints
- ธรรมชาติของงานจึงเปลี่ยนไป จากการ “ใช้เครื่องมือเพื่อเขียนโค้ด” เป็นลูปฟีดแบ็กที่กระชับของ เริ่มงาน → ให้ agent เขียนโค้ด → ตรวจพรีวิว → อ่าน diff → ให้ฟีดแบ็กหรือ merge → ไปงานถัดไป
- ถ้าลูปเร็วพอ ก็จะไม่มีช่องให้สมาธิรั่วไหล และ การเพิ่มความเร็วเองก็กลายเป็นเกมหนึ่ง
- สุดท้าย เป้าหมายของการพัฒนาไม่ได้อยู่ที่การสร้างฟีเจอร์อีกต่อไป แต่ย้ายไปอยู่ที่ว่า จะเพิ่มความเร็วของลูปได้อีกแค่ไหน
- เป็นช่วงที่ ความเร็วกลายเป็นความสนุกของการทำวิศวกรรม
2 ความคิดเห็น
ในมุมของคนรีวิว พอเห็น PR Description ที่เครื่องเขียนแล้ว ประสบการณ์ก็ไม่ได้ดีเท่าไหร่นักเหมือนกันนะครับ/ค่ะ แม้ก็แอบคิดว่าถ้าจูนพรอมป์ต์ให้ดีพออาจจะช่วยได้ก็ได้ก็ตาม..
ความคิดเห็นจาก Hacker News
ให้ความรู้สึกเหมือนยุค 90 ที่ตัวชี้วัด “จำนวนบรรทัดโค้ดต่อสัปดาห์” กลับมาอีกครั้ง
การที่ “ทำ PR ได้มากขึ้น” ไม่ได้เป็นหลักฐานว่า AI ทำงานได้ดี แค่หมายความว่ามีการ merge มากขึ้นเท่านั้น
การตัดสินผลงานจากปริมาณผลผลิตโดยไม่คำนึงถึงคุณภาพโค้ด บั๊ก และภาระในการดูแลรักษา ก็ไม่ต่างจากตัวชี้วัดแย่ ๆ ที่ผู้จัดการสมัยก่อนชอบยัดเยียด
ท้ายที่สุดแล้ว ดูเหมือนว่าเราไม่ได้ต่อต้านตัวชี้วัดที่แย่ แต่เราไม่ชอบ การถูกวัดผล เองมากกว่า
เป้าหมายที่แท้จริงคือทำให้โค้ดเรียบง่ายและสร้างผลลัพธ์ที่มีอิมแพ็กต์
ตอนนี้กำลังทดลองรันหลายเอเจนต์พร้อมกัน ให้ลอง implementation คนละแบบ แล้วค่อยรวมไอเดียที่ดีที่สุดเข้าด้วยกัน
อีกอย่างคือรวบรวมเอกสารกับ requirement มาให้เอเจนต์ช่วยตอบคำถาม และทำ feedback จาก code review ให้เป็น checklist แบบทั่วไปเพื่อนำไปใช้กับรอบรีวิวถัดไป
การทำงานจนป่วยไม่ใช่เรื่องน่าภูมิใจ แต่มันเป็นสัญญาณว่าระบบมีปัญหา
ตัวอย่างเช่น โมเดล COCOMO ก็ได้รับความเชื่อถือถึงขั้นถูกใช้ในศาลเพื่อประเมินมูลค่าระบบ
นักพัฒนาส่วนใหญ่ไม่อยากให้ตัวเองถูกแปลงเป็นตัวเลข
แต่คนที่สนับสนุน AI มองว่าถ้าจะพิสูจน์การพัฒนาให้ดีขึ้น ก็จำเป็นต้องมีการวัดผล
คิดว่าควรใช้ LLM ในทางที่ ช่วยลดภาระทางความคิด
มนุษย์ไม่เก่งเรื่อง multitasking และ LLM ก็ไม่ได้ช่วยแก้จุดนั้น
ฉันไม่ได้ใช้ Claude ให้ลงมือ implement แทน แต่ใช้แบบ ให้มันคอยนำทางขั้นตอนการ implement
แบบนี้ทำให้เข้าใจกระบวนการทั้งหมด พร้อมมองเห็นทั้งรายละเอียดและภาพรวมไปพร้อมกัน
แค่มอบหมายส่วนที่ซ้ำ ๆ และเป็นงานเชิงกลให้ Claude ทำก็พอ
โยนคำถามให้ LLM เข้าใจปัญหา เขียนโค้ดแกนหลักเอง แล้วค่อยให้มันช่วยวางแผน implementation ส่วนที่เหลือ
LLM เก่งเรื่องอ่านโค้ด อธิบาย และงานง่าย ๆ ส่วนฉันโฟกัสกับการเลือกทิศทางการแก้ปัญหา
ตอนนี้กำลังทดลอง prompt อย่าง “ช่วยทำรายการ assumption” หรือ “ระบุการตัดสินใจที่อยู่นอกแผน” เพื่อไล่ตามส่วนที่ LLM ตัดสินใจแทนฉัน
ถ้าเข้าใจลักษณะของ Claude ก็จะตรวจสอบได้มีประสิทธิภาพขึ้น และยิ่งมีประสบการณ์มากขึ้นก็ยิ่งควบคุมคุณภาพได้ง่ายขึ้น
ถ้ารันหลายเอเจนต์เพื่อสร้างฟีเจอร์ใหญ่ ๆ สุดท้ายจะเจอปัญหา เวลารีวิวพุ่งสูงมาก
เพราะการอ่านโค้ดของคนอื่น (หรือ AI) ยากกว่าการเขียนเอง
อาจใช้ test automation มาช่วยครอบคลุมได้ แต่ก็ยังยากจะเชื่อถือได้เต็มร้อย
ต้องกำหนดขอบเขต แผนการทดสอบ และแผนเอกสารให้ชัดเจน แล้วใช้ code review bot (Sourcery, CodeRabbit, Codescene) ร่วมกับ กฎ linting ที่เข้มงวด
ใช้ทั้ง BDD, property testing, e2e test, code audit ไปจนถึง mutation/fuzzing test
ข้อดีของ agent coding คือมันช่วยให้มีเวลาไปลงกับการควบคุมคุณภาพพวกนี้มากขึ้น
กำลังลองแนวทางแบบ 100 PRs a day เพื่อทำ progressive deployment
ถ้าแบ่งงานให้เล็กลงและเชื่อถือการทดสอบได้ การรีวิวโค้ดจาก AI ก็จะเบาลง
ฉันจะดู test case ให้ละเอียดขึ้น แล้วรีบจบ code review ให้ไว
แม้จะไม่ได้รันหลายเอเจนต์แบบขนาน แต่ productivity ก็เพิ่มขึ้นชัดเจนเพราะ AI
ถ้ากระบวนการเขียน PR ถูกทำให้เป็นอัตโนมัติอย่างเดียว ก็จะเสีย โอกาสในการตรวจสอบตัวเอง ไป
ฉันมักเจอความแปลกในโค้ดของตัวเองตอนเขียนคำอธิบาย PR
ช่วงที่ต้องอธิบายเป็นภาษาอังกฤษนั่นแหละคือ sanity check ครั้งสุดท้าย
ระบบ worktree ทำให้สลับบริบทได้ง่ายขึ้น แต่ในขณะเดียวกันก็เพิ่ม ความเหนื่อยล้าทางจิตใจ
ถ้าแบ่งเป็นชิ้นเล็ก ๆ และทำให้รอบรีวิวสั้นลง ก็จะควบคุมคุณภาพได้ง่าย
แค่ชอบที่กลับมาวันถัดไปแล้ว งานยังเดินหน้าอยู่ โดยไม่ต้องให้จังหวะการทำงานของฉันสะดุด
ยังสงสัยกับสมมติฐานที่ว่า Claude เขียนโค้ดได้ดีจนเกือบเสร็จสมบูรณ์
ในความเป็นจริงมันต้องอาศัย feedback และการแก้ไขหลายรอบ และถ้าจัดการหลายงานพร้อมกันแบบขนานก็ยิ่งไม่มีประสิทธิภาพ
Claude Code เป็น เครื่องมือเพื่อการเรียนรู้ที่ปฏิวัติวงการ แต่คุณภาพของการสร้างโค้ดยังขึ้น ๆ ลง ๆ
ตอนเรียน Flutter/Dart ฉันใช้ Claude ถามเรื่องแนวคิดต่าง ๆ จนทำแอปได้ในหนึ่งสัปดาห์โดยไม่ต้องพึ่งหนังสือ
มันให้ความรู้สึกเหมือน สารานุกรมแบบโต้ตอบได้
คำถามอย่าง “วิธีทำ X ในภาษานี้แบบที่ idiomatic คืออะไร?” มักได้คำตอบที่มีประโยชน์ทันที
แต่มันไม่ใช่สิ่งที่จะมาเปลี่ยนโลก เป็นแค่ เครื่องมือที่ดีมาก เท่านั้น
แต่การตลาดที่เกินจริงกำลังส่งผลเสียต่อเศรษฐกิจโดยรวม
ยังน่ากังวลด้วยว่าภาพลวงตาเรื่อง AI แย่งงานกำลังทำให้คนรุ่นใหม่บางส่วนล้มเลิกเส้นทางอาชีพไปเลย
มีคนพูดว่า “หลังเปลี่ยน build ไปใช้ SWC เวลารีสตาร์ตเซิร์ฟเวอร์ลดลงเหลือน้อยกว่า 1 วินาที”
SWC คือ Speedy Web Compiler เป็นเครื่องมือสำหรับ transpile ให้เร็วโดยไม่ทำ type checking
เอกสาร NestJS ก็อธิบายเรื่องเดียวกัน
การใช้ LLM ไม่ได้เป็นเรื่องที่ควรเอามา อวดว่าผลิตภาพเพิ่มขึ้นแบบระเบิด
ถ้าทุกคนใช้เครื่องมือเดียวกัน เส้นฐานก็แค่สูงขึ้น
อีกอย่าง ถ้าโค้ดจำนวนมากที่ AI สร้างไม่ได้รับการรีวิวอย่างเหมาะสม คุณภาพระยะยาวก็ยังไม่แน่นอน
แม้ LLM จะช่วยเพิ่ม productivity ได้ แต่การวัดด้วย กราฟจำนวน commit ก็ไม่มีความหมาย
มันโง่พอ ๆ กับการใช้ LOC ตัดสินคุณภาพ
ฉันยังเขียนโค้ดเองเพื่อให้เข้าใจมัน และ Claude ก็ช่วยมากในฐานะ คู่หูสำหรับแตกงานและรีวิว
ความสามารถในการแทนที่โค้ดซับซ้อนด้วย abstraction ที่เรียบง่ายต่างหาก คือ productivity ที่แท้จริง