วิเคราะห์ความเหนื่อยล้าจาก 'vibe coding' ของนักพัฒนาที่เกิดจากความเร็วของ AI ซึ่งเร็วกว่าการคิด
(tabulamag.com)ประเด็นสำคัญ:
- การใช้เครื่องมือ AI (Claude Code, Cursor) ช่วยเพิ่มความเร็วในการพัฒนา แต่จังหวะการทำงานที่เร็วเกินไปกลับเกินขีดจำกัดการประมวลผลของสมองและก่อให้เกิดความเหนื่อยล้า
- การสลับบริบทบ่อยครั้ง ภาวะโดพามีนมากเกินไป และการเปลี่ยนบทบาทไปเป็นผู้จัดการ ล้วนเพิ่มภาระทางการรับรู้
- เกิดปรากฏการณ์ 'เวลาแบบเครื่องจักร' ที่มนุษย์ถูก AI ลากไปตามความเร็ว จนทำให้ความจำเป็นในการควบคุมจังหวะการทำงานด้วยตนเองชัดเจนขึ้น
บทนำ
- ประโยชน์และผลข้างเคียงของเครื่องมือ AI: นักพัฒนาที่มีประสบการณ์ 40 ปี ใช้ Claude Code และ Cursor เพื่อพัฒนาแพ็กเกจแมเนเจอร์ (Marvai) และพบว่าผลิตภาพเพิ่มขึ้น แต่ในขณะเดียวกันก็รู้สึกเหนื่อยล้าอย่างที่ไม่เคยเป็นมาก่อน
- การตั้งคำถามต่อปัญหา: แม้ความเร็วในการพัฒนาฟีเจอร์และแก้บั๊กจะเพิ่มขึ้น แต่สมองกลับตามความเร็วของ AI ไม่ทัน จนเกิดอาการหมดแรงแม้ทำงานในช่วงเวลาสั้น ๆ (ประมาณ 1 ชั่วโมง)
เนื้อหา
1. ภาระทางการรับรู้ที่พุ่งสูงขึ้นและแรงกดดันของ 'เวลาแบบเครื่องจักร'
- การประยุกต์ใช้ทฤษฎีภาระทางการรับรู้: ตามทฤษฎี Team Topologies ความรับผิดชอบที่มากเกินไปและการสลับหัวข้อไปมาจะเพิ่มภาระทางการรับรู้ การเขียนโค้ดด้วย AI ผลักภาระนี้จนเกือบถึงขีดจำกัด
- จังหวะที่เครื่องจักรเป็นผู้กำหนด: คล้ายกับความเครียดที่แรงงานในโรงงานสมัยก่อนต้องทำงานให้ทันความเร็วของเครื่องจักร นักพัฒนากำลังเผชิญปรากฏการณ์ที่ต้องวิ่งตามความเร็วการเขียนโค้ดอันรวดเร็วที่ AI เป็นผู้กำหนด ('เวลาแบบเครื่องจักร')
- การหายไปของกระบวนการคิด: การเขียนโค้ดแบบเดิมมีจังหวะการทำงานที่สอดคล้องกับความเร็วในการคิด ทำให้สมองมีเวลาประมวลผล (Baking time) แต่การเขียนโค้ดด้วย AI สามารถจัดการสถาปัตยกรรมที่ซับซ้อนและกระบวนการตัดสินใจได้แทบจะทันที จนรบกวนการซิงก์ของสมอง
2. การอยู่ร่วมกันของโดพามีนที่มากเกินไปและฮอร์โมนความเครียด
- วงจรโดพามีนที่เร่งขึ้น: วงจรรางวัลของโดพามีนที่ต่อเนื่องจาก 'เขียนโค้ด-เกิดข้อผิดพลาด-แก้ไข-สำเร็จ' ถูกเร่งให้เร็วขึ้นอย่างมากด้วย AI
- ภาวะหมดไฟทางอารมณ์: การหลั่งโดพามีนบ่อยครั้งควบคู่กับฮอร์โมนความเครียดจากจังหวะความเร็ว ทำให้แทนที่จะรู้สึกสนุกกับการเขียนโค้ด กลับเกิดความเหนื่อยล้าและความรู้สึกถูกถาโถม
3. ต้นทุนของการสลับบริบท (Context Switching) ที่เพิ่มขึ้น
- โอเวอร์โหลดของแคชในสมอง: การสลับบริบทเป็นงานที่ใช้พลังงานสูง เพราะต้องล้างและเติมแคชของสมองใหม่
- การสลับบริบทระดับย่อย (Micro-Context Switching): AI อาจแก้หลายโมดูลพร้อมกัน หรือแม้แต่ในการใช้ฟังก์ชันเติมข้อความอัตโนมัติแบบง่าย (
Tabkey) ก็ยังบังคับให้เกิดการสลับย่อยอย่างถี่จาก 'โหมดเขียน' ไปเป็น 'โหมดตรวจทาน' ทำให้พลังงานสมองลดลงอย่างรวดเร็ว
4. การเปลี่ยนแปลงเชิงแก่นของบทบาทนักพัฒนา
- จากผู้เขียนสู่ผู้จัดการ: บทบาทเปลี่ยนจากการนำความต้องการมาแปลงเป็นโค้ด ไปสู่การเป็น 'หัวหน้าทีม' หรือ 'ผู้ประสานงาน' ที่ต้องจัดการและตรวจทานผลลัพธ์ของ AI ซึ่งเปรียบเสมือน 'เพื่อนร่วมทีมที่ทำงานเร็วมาก'
- ความไม่สมมาตรของความรับผิดชอบ: ในขณะที่ AI สามารถปล่อยงานออกมาได้เทียบเท่าคน 5 คน นักพัฒนายังคงต้องรับผิดชอบขั้นสุดท้ายต่อคุณภาพของโค้ด จึงทำให้ภาระด้านการจัดการเพิ่มขึ้น
บทสรุป
ข้อเสนอเพื่อการเขียนโค้ดด้วย AI อย่างยั่งยืน
- การกำหนดจังหวะอย่างตั้งใจ (Pacing): นักพัฒนาต้องเป็นฝ่ายควบคุมจังหวะการทำงานเอง ไม่ปล่อยให้ถูกความเร็วของ AI พัดพาไป
- การนำวิธีทบทวนแบบใหม่มาใช้: จำเป็นต้องมีรูทีนการทำงานแบบใหม่ เช่น การทบทวนประจำวัน (Retrospective) เพื่อให้ AI กับสมองซิงก์กัน
- การเปลี่ยนมุมมองต่อบทบาท: ควรลดการไมโครแมเนจเอาต์พุตของ AI และปรับสไตล์การทำงานไปสู่การเชื่อใจ AI มากขึ้น
- มุมมองต่ออนาคต: อนาคตของการเขียนโค้ดอาจไม่ใช่การเพิ่มความเร็วอย่างไม่มีเงื่อนไข แต่เป็น 'ความช้าด้วยความตั้งใจ' และการกำหนดขอบเขตใหม่โดยคำนึงถึงขีดจำกัดทางการรับรู้ของมนุษย์
14 ความคิดเห็น
ผมก็มีประสบการณ์คล้ายกัน เลยทำแบบนี้ครับ
ยกตัวอย่างเช่น ถ้าจะรีแฟกเตอร์
'สั่งให้วิเคราะห์โค้ดเดิมแล้วเสนอทางเลือก'
'สั่งให้สรุปอธิบายความแตกต่างระหว่างทางเลือกกับโค้ดเดิม รวมถึงข้อดีข้อเสีย'
'สั่งให้เสนอวิธีตรวจสอบว่าทางเลือกนั้นดีกว่าจริงหรือไม่'
'ตรวจสอบทางเลือกด้วยตัวเองโดยตรง'
'สั่งให้นำทางเลือกไปใช้ พร้อมเขียนเอกสารและทดสอบ'
ปัญหาคือ การใช้โทเคนเยอะเกินไป ทำให้มีค่าใช้จ่ายสูงมาก...
แม้แต่งานจิปาถะง่าย ๆ ผมก็ยังรู้สึกสบายใจกว่าถ้าได้ทำเป็นแมโครขึ้นมาเสียเอง...
ระหว่างคนด้วยกันก็เป็นแบบนั้นเหมือนกัน
ปัญหาแบบนี้ก็เกิดขึ้นบ่อยระหว่างคนด้วยกันเช่นกัน
ถ้าคนที่คิดช้าเป็นผู้จัดการ
ก็จะพูดว่า
“งานมันเร็วเกินไปจนเหนื่อย เลยทำงานด้วยกันยาก”
แต่ถ้าคนนั้นเป็นลูกน้อง
ก็จะพูดว่า
“จับใจความที่พูดได้ไม่ค่อยดี เลยทำงานด้วยกันยาก”
สุดท้ายแล้ว ถ้าจะทำงานร่วมกันได้ ทั้งสองฝ่ายก็ต้องเข้าขากันได้.
ความทรมานที่ถูกพรากการเขียนโค้ดไป เหลือเพียงต้องทำแค่โค้ดรีวิวและทดสอบ...
ยกเว้นโปรเจ็กต์ส่วนตัว ผมใช้ vibe coding แบบจำกัดครับ โดยใช้แค่การทำไอเดียด้วย Cursor autocomplete กับการเขียนโค้ดซ้ำตามแพตเทิร์นเดิมประมาณนั้นเท่านั้น การพยายามแก้ทุกอย่างด้วย vibe coding ในโปรเจ็กต์ระยะยาว ผมมองว่าเป็นการกระทำที่ขาดความรับผิดชอบในฐานะนักพัฒนา
ดูเหมือนว่าคนที่เข้าใจโค้ดของผลลัพธ์ที่สร้างขึ้นและคอยตรวจสอบ/รีวิว จะรู้สึกเหนื่อยล้ามากกว่าคนที่แค่เขียนพรอมป์ต์แล้วรับผลลัพธ์อย่างเดียว
ในต้นฉบับก็ระบุไว้แบบนั้นเช่นกัน
ผมคิดแค่ว่า "ดีจังที่ด้วย AI แล้วงานที่ผมต้องทำลดลง" เลยไม่เคยรู้สึกเหนื่อยล้าแบบนี้เลยครับ ผมใช้ zed + claude ซึ่งบางครั้งระหว่างทางบริบทก็เปลี่ยนไปทำให้มันทำงานแปลก ๆ บ้าง แต่พอถึงตอนนั้นผมก็ย้อนโค้ดใน git แล้วบอกให้มัน "สรุปสิ่งข้างต้นแล้วเขียนใหม่อีกครั้ง" มันกลับจัดให้ได้สะอาดกว่าเดิมอีกนะครับ ไม่ใช่ว่าเราไม่ได้พิมพ์โค้ดด้วยมือตรง ๆ หรอก แค่กระบวนการเปลี่ยนความคิดในหัวให้เป็นโค้ดมันเปลี่ยนไปเท่านั้นไม่ใช่เหรอ? บางทีตอนพิมพ์พรอมต์ก็ยิ่งช่วยให้ความคิดเป็นระเบียบขึ้นด้วยครับ
กระบวนการสร้างด้วยโค้ดกลายเป็นกล่องดำไปแล้ว เลยไม่จำเป็นต้องมีเวลาเพื่อซิงก์โค้ดกับสิ่งที่คิดไว้ในหัวหรือครับ?
การเขียนโค้ดแบบเดิมรับประกันได้ว่าโค้ดกับสิ่งที่คิดไว้ในหัวตรงกัน แต่การโค้ดผ่าน LLM มันไม่ได้รับประกันแบบนั้นนี่ครับ
ในหัวมีแค่ตรรกะ แล้วก็แค่ตรวจว่าโค้ดที่ AI เขียนออกมาถูกต้องไหม ไม่จำเป็นต้องประกอบโค้ดในหัวเองแล้วไม่ใช่เหรอ? แค่คิดว่าจะส่งข้อมูลที่แม่นยำแค่ไหนให้ในพรอมป์ต์ก็พอ กลับยิ่งทำให้งานเสร็จเร็วขึ้นมากเลยครับ
น่าจะขึ้นอยู่กับว่าเราพรอมป์ได้ละเอียดแค่ไหนด้วยนะครับ ถ้าส่งให้ LLM ในระดับ pseudocode ก็พอเข้าใจประเด็นที่คุณพูดแล้วครับ
เมื่อก่อนแม้จะเขียนโค้ดทั้งวัน พอเลิกงานก็ยังรู้สึกอิ่มเอมกับงานที่ทำ แต่เดี๋ยวนี้งานเกือบทั้งวันถูกจัดการผ่านการสนทนา และหลายวันก็แทบไม่ได้เขียนโค้ดด้วยมือตัวเองแม้แต่บรรทัดเดียว แต่กลับหมดไฟเสียแล้ว.. เห็นด้วยอย่างยิ่งครับ
ผมก็เหนื่อยล้าเพิ่มขึ้นด้วยเหตุผลนี้พอดีเลยครับ ผมพอคาดไว้แล้วว่าจะเป็นแบบนั้น เลยโอเคกับความเหนื่อยล้าเองอยู่ แต่ยิ่งไปกว่านั้นคือ จากภายนอกพอมองเข้ามา มันไม่มีช่วงเวลาที่นั่งรัวคีย์บอร์ดตอนเขียนโค้ด เลยดูเหมือนว่าทำงานแบบชิลมาก ถ้าผมบอกว่าเดี๋ยวนี้เหนื่อยกว่าเมื่อก่อน เขาก็ดูจะไม่ค่อยเข้าใจเท่าไร....
อา เหมือนมีคนมาอธิบายแทนได้อย่างชัดเจนเลยว่าทำไมผมถึงรู้สึกเหนื่อยล้า
1. "ความเร็วช่วยเติมพลัง" (ฝ่ายมองบวก)
2. "ข้อถกเถียงเรื่องนิยามของ vibe coding" (ความสับสนของคำศัพท์)
3. "ความเร็วที่ไร้การตรวจสอบคือหนี้เทคนิค" (ฝ่ายระมัดระวัง)
4. "ความเหนื่อยล้าจากการสลับบริบท" (ฝ่ายเห็นด้วย)
5. "ความสนุกของการเขียนโค้ดที่หายไป" (โดพามีนไม่พอ)
6. "เป็นพิษสำหรับมือใหม่ แต่เป็นยาสำหรับผู้ชำนาญ" (ความต่างตามระดับทักษะ)
7. "ถูกบังคับให้เปลี่ยนบทบาทเป็นผู้จัดการ" (การเปลี่ยนบทบาท)
8. "การขาดความเข้าใจ business logic" (การชี้ข้อจำกัด)
9. "การหายไปของการพักและช่องว่างให้หายใจ" (เวลาของเครื่องจักร)
10. "ปัญหาชั่วคราวของเครื่องมือ" (มุมมองอนาคต)