กราฟ contribution บน GitHub ของผมในปี 2025 ดูเหมือนเป็นของนักพัฒนาสองคนที่ต่างกันโดยสิ้นเชิง ครึ่งปีแรกแทบว่างเปล่า ส่วนครึ่งปีหลังมี มากกว่า 4,000 commits
ผมไม่ได้มีเวลาว่างเพิ่มขึ้นอย่างกะทันหัน ผมยังทำงาน full-time ควบคู่กับ side project เหมือนเดิม สิ่งที่เปลี่ยนคือ friction ระหว่างไอเดียกับเวอร์ชันที่ใช้งานได้จริง เพราะผมเริ่มใช้ AI coding tools อย่างจริงจังมากขึ้น
แต่ตัวเลขนี้ต้องตีความอย่างระมัดระวัง จำนวน commits ไม่ใช่ตัวชี้วัด productivity ในตัวมันเอง 4,000 commits ไม่ได้แปลว่าผมสร้างการปรับปรุงที่มีความหมาย 4,000 อย่าง และไม่ได้พิสูจน์ว่า code มีคุณภาพสูง สิ่งที่กราฟแสดงได้จริงคือรูปแบบการทำงานของผมเปลี่ยนไป ผม build, iterate และพาสิ่งที่ทำไปถึงเวอร์ชันที่ใช้งานได้อย่างสม่ำเสมอกว่าเดิมมาก
คอขวดจริงคือพลังที่ต้องใช้เพื่อเริ่ม experiment
ใน side project ผมเจอปัญหาเดิมซ้ำ ๆ: useful version แรกมักอยู่หลังงาน routine จำนวนมาก ทั้ง routing, validation, scripts, tests, configuration และ cleanup ซึ่งอาจกิน momentum ก่อนจะรู้ด้วยซ้ำว่า idea นั้นคุ้มค่าหรือไม่
เมื่อก่อนผมมักเลื่อน experiment ถ้า first working version ดูเหมือนต้องใช้ setup หลายคืน AI coding tools ไม่ได้ทำให้งานเหล่านั้นหายไป แต่ลด cost ของ first pass และช่วยให้ไปถึง testable version ได้เร็วขึ้น
ดังนั้นประโยชน์ใหญ่สุดไม่ใช่พิมพ์เร็วขึ้น แต่คือ activation energy ที่ต่ำลง: idea มากขึ้นไปถึงจุดที่ผมเก็บ evidence จริงได้
workflow Node.js ของผมเปลี่ยนอย่างไร
ผมไม่ได้แทน development process ด้วย chat window ใน side project Node.js ผมใช้ DeepSeek เป็น second pair of hands สำหรับ task ที่ scope ชัดเจน เช่นร่าง implementation แรก อ่าน code ที่ไม่คุ้น เสนอ tests วิเคราะห์ stack trace แบ่ง refactor ใหญ่เป็นขั้นเล็ก และ review deployment assumptions
- Scaffolding: สร้าง first version ที่น่าเบื่อของ handler, validation, script หรือ test
- Code reading: trace request หรือ value ก่อน edit
- Refactoring: แบ่ง change เชิงกลเป็น diff เล็กที่ review ง่าย
- Debugging: สร้างหลาย hypothesis จาก logs
- Verification: หา edge case และ regression หลัง happy path ใช้งานได้
ยิ่ง input, output, constraint และ convention เดิมชัดเจน ผลลัพธ์ยิ่ง verify ง่าย task ที่ vague มักให้ abstraction ที่ดูสมเหตุสมผลแต่ผิด
ผมจึงมอง AI output เป็น candidate patch ไม่ใช่ final answer Type checking, tests, build และ real flow คือ evidence; คำอธิบายที่มั่นใจไม่ใช่
DeepSeek ช่วยมากที่สุดตรงไหน — และตรงไหนไม่ช่วย
DeepSeek มีประโยชน์เพราะผมใช้ซ้ำกับ concrete programming tasks ได้ง่าย ขอ first pass ตัดส่วนที่ไม่ดี ส่ง real error กลับไป ลด scope และ iterate ได้เร็ว
ผมไม่เรียกสิ่งนี้ว่า benchmark เพราะไม่ได้ทำ controlled study เทียบกับทุก model และ model lineup เปลี่ยนเร็ว สิ่งที่พูดได้อย่างรับผิดชอบคือ DeepSeek เข้ากับ workflow ของผมได้ดีพอจนผมใช้ AI assistance บ่อยขึ้นมาก
มันทำได้ดีที่สุดเมื่อ feedback ราคาถูก เช่นมี function, tests และ error จริง และอ่อนลงเมื่อ task ต้องอาศัย product context ที่ไม่ได้เขียนไว้หรือ architecture trade-off ที่ละเอียด ในกรณีนั้นคำตอบที่ลื่นไหลอาจทำให้ assumption ที่ผิดดูเหมือนเสร็จแล้ว
AI เปลี่ยนต้นทุนของการทดลอง
การเปลี่ยนแปลงที่ใหญ่ที่สุดไม่ใช่ “AI เขียน code ได้ ดังนั้น development จึงอัตโนมัติ” แต่คือชิ้นส่วนเล็ก ๆ หลายอย่างมีต้นทุนต่ำพอที่จะลองทำ feature ของ side project ที่เมื่อก่อนดูเหมือนต้อง setup มากเกินไป สามารถกลายเป็น prototype ได้ในช่วงที่ผมยังสนใจไอเดียนั้นอยู่
ความแตกต่างนี้สำคัญ AI ลดต้นทุนในการไปถึงเวอร์ชันที่ทดสอบได้ แต่ไม่ได้ทำให้ architecture, product judgment, deployment หรือ correctness หายไป generated implementation ยังผิดได้ successful build ยัง fail ตอน runtime ได้ และ prototype ที่ deploy แล้วก็ยังอาจเป็น product ที่ไม่ดี
ประโยชน์ที่ชัดที่สุดสำหรับผมคือ momentum เมื่อเห็นทั้งระบบทำงานแล้ว ผมมีแรงที่จะปรับปรุงมันต่อมากขึ้นมาก
benchmark ที่แข็งแรงกว่าต้องมีอะไร
ถ้าจะทำ benchmark ที่ reproduce ได้ ผมจะบันทึก exact model versions, fixed programming tasks, repository snapshots, prompts, raw outputs, elapsed time, accepted/rejected patches, review time, test results และ rework
ผมจะวัดมากกว่า commits ด้วย เช่นเวลาจาก idea ถึง verified version, defects, rollbacks และงานที่ต้องเขียนใหม่ หากไม่มี context เหล่านี้ 4,000 commits เป็นหลักฐานของ activity และ behavior change ไม่ใช่ proof ของ software quality
สิ่งที่เปลี่ยนสำหรับผม
ปี 2025 เป็นปีที่ผมหยุดมอง side project ทุกชิ้นว่าเป็นภูเขา setup ที่ต้องปีนด้วยมือทั้งหมด AI ทำให้เวอร์ชันแรกที่ใช้งานได้มีต้นทุนต่ำพอที่ผมจะไปถึงจุดที่ product decision สำคัญจริง ๆ ได้บ่อยขึ้น
นี่คือเหตุผลที่ครึ่งปีหลังของกราฟ GitHub ดูแตกต่างมาก ไม่ใช่เพราะ AI เพิ่มชั่วโมงให้หนึ่งวัน และไม่ใช่เพราะ code ทุกบรรทัดที่ generate ออกมาดี แต่มันลด friction ที่เคยทำให้ไอเดียเก่าตายก่อนจะกลายเป็นของจริง
ในปี 2026 ผมสนใจด้านที่ไม่หวือหวาของสมการมากกว่า: refine workflow, วัด quality อย่างจริงจังขึ้น และทำให้แน่ใจว่า development ที่เร็วขึ้นสร้าง software ที่ดีขึ้น ไม่ใช่แค่ commits ที่มากขึ้น