นักพัฒนาที่เริ่มใช้ GitHub Copilot, ChatGPT หรือ Cursor มักจะบรรยายถึง "ช่วงฮันนีมูน" ที่เหมือนกัน งานที่เคยใช้เวลาสองชั่วโมง ตอนนี้เหลือเพียงยี่สิบนาที โค้ดพื้นฐาน (Boilerplate) หายวับไปเพียงแค่กดปุ่ม Tab แต่ไม่นานนัก ข้อร้องเรียนที่เงียบเชียบกว่าก็เริ่มปรากฏขึ้นในฟอรัมและช่อง Slack นั่นคือ "ความเหนื่อยล้า" เครื่องมือเป็นคนเขียนโค้ด แต่บางอย่างในกระบวนการนั้นกลับสูบพลังคุณไป ปัญหามันไม่ใช่ที่ตัวโค้ด แต่มันคือการ "บริโภค" โค้ดเหล่านั้นต่างหาก
คอขวดที่ไม่มีใครเตรียมใจรับมือ
เป็นเวลาหลายทศวรรษที่ข้อจำกัดในวิศวกรรมซอฟต์แวร์คือความเร็วในการพิมพ์ ไม่ว่าคุณจะคิดเร็วแค่ไหน นิ้วมือและความรู้ด้านไวยากรณ์ (syntax) ของคุณคือเพดานที่กั้นไว้ ผู้ช่วย AI ได้ทำลายเพดานนั้นลง พวกมันสามารถสร้างโค้ดหลายร้อยบรรทัดในหลายๆ ไฟล์ได้ก่อนที่คุณจะอ่านบล็อกแรกจบด้วยซ้ำ ความเร็วระดับนี้ฟังดูเหมือนอิสระ แต่มันกลับสร้างการจราจรที่ติดขัดอย่างไม่คาดคิด ทันใดนั้น ส่วนที่ช้าที่สุดในกระบวนการก็คือความสามารถของคุณในการอ่าน ทำความเข้าใจ และตรวจสอบสิ่งที่เพิ่งปรากฏบนหน้าจอ คุณได้กลายเป็นผู้ตรวจสอบโค้ด (code reviewer) เต็มเวลาให้กับโปรเจกต์ของตัวเอง เพียงแต่ผู้เขียนคืออัลกอริทึมที่ไม่เคยหลับและไม่เคยเหนื่อย
การสลับบทบาทของแรงงานนี้เปลี่ยนลักษณะของการเขียนโค้ด แทนที่จะสลับไปมาระหว่างการสร้างสรรค์และการตรวจสอบเบื้องต้น คุณกลับต้องติดอยู่ในโหมดการตรวจสอบ (validation) ที่ยาวนาน และการตรวจสอบนั้นไม่ใช่การอ่านแบบผ่านๆ แต่มันคือการวิเคราะห์เชิงรุกที่เต็มไปด้วยความระแวง ทุกชื่อตัวแปร ทุกเงื่อนไขขอบเขต (boundary condition) และทุกคำสั่ง import จำเป็นต้องผ่านตัวกรองทางความคิด เพราะ AI ไม่มีส่วนได้ส่วนเสีย (skin in the game) มันจะไม่ถูกตามตัวตอนตี 3 เมื่อระบบบน production เกิดล่ม
ทำไมสมองของคุณถึงถึงจุดตัน
ความเหนื่อยล้านี้ไม่ใช่ความขี้เกียจ แต่มันคือการปะทะกันที่คาดการณ์ได้ระหว่างผลลัพธ์ที่หลั่งไหลมาอย่างมหาศาลกับขีดความสามารถที่จำกัดของมนุษย์
ภาระจากปริมาณที่มากเกินไป (Volume overload). คำแนะนำจาก AI ทั่วไปอาจรวมถึง React component ทั้งชุด, ตรรกะการจัดสไตล์ (styling logic), ฟังก์ชันยูทิลิตี้ และ unit tests ทั้งหมดนี้มาในคราวเดียว หน่วยความจำขณะทำงาน (working memory) ของคุณสามารถรับข้อมูลได้จำกัด เมื่อหน้าจอเต็มไปด้วยบรรทัดใหม่นับสิบๆ บรรทัด สมองของคุณต้องเลือกระหว่างการบีบอัดพวกมันให้เป็นรูปแบบนามธรรม หรือไม่ก็ต้องสแกนพวกมันทีละบรรทัด ซึ่งทั้งสองกลยุทธ์ล้วนใช้พลังงานสมาธิทั้งสิ้น หลังจากตรวจสอบบล็อกเหล่านี้ไปหลายชุด อาการล้าทางจิตใจที่เทียบได้กับอาการปวดกล้ามเนื้อก็จะตามมา คุณกำลังอ่านอยู่ แต่คุณไม่ได้ทำความเข้าใจมันอย่างแท้จริงอีกต่อไป
ช่องว่างแห่งความไว้วางใจ (The trust gap). โค้ดที่สร้างโดย AI ดูมีความน่าเชื่อถือ การย่อหน้า (indentation) นั้นสมบูรณ์แบบ ชื่อตัวแปรดูสมเหตุสมผล แม้แต่คอมเมนต์ก็ปรากฏในตำแหน่งที่ถูกต้อง แต่ความน่าเชื่อถือไม่ได้หมายถึงความถูกต้องเสมอไป โค้ดอาจใช้ API ที่ล้าสมัย (deprecated), พลาดกรณีขอบเขต (edge case) ที่เกี่ยวข้องกับค่า null หรือนำช่องโหว่ SQL injection ที่แนบเนียนเข้ามา เพราะคุณรู้ว่าสิ่งนี้เกิดขึ้นได้ คุณจึงไม่สามารถอ่านผ่านๆ ได้ คุณต้องตรวจสอบทุกคำสั่ง return และทุกเงื่อนไขทางตรรกะด้วยความระมัดระวังเหมือนการตรวจสอบความปลอดภัย (security audit) การตรวจสอบในระดับนั้นที่ต้องทำต่อเนื่องหลายชั่วโมงนั้นใช้พลังงานสมองสูงมาก มันคือเหตุผลเดียวกับที่เจ้าหน้าที่ตรวจความปลอดภัยในสนามบินต้องทำงานเป็นกะสั้นๆ เพราะความตื่นตัวที่ต่อเนื่องนั้นเสื่อมถอยลงอย่างรวดเร็ว
ความไม่สอดคล้องของเวิร์กโฟลว์ (Workflow mismatch). สภาพแวดล้อมการพัฒนาและกระบวนการทำงานของทีมส่วนใหญ่ยังคงตั้งอยู่บนจังหวะการ "เขียนแล้วทดสอบ" ของมนุษย์ ฐานโค้ด (codebase) เติบโตในจังหวะของมนุษย์ และการรีวิวโค้ดก็เกิดขึ้นเป็นรอบๆ ตามกำหนดการ เมื่อ AI ถูกแทรกเข้ามาในกระบวนการนั้น กระแสการทำงาน (flow) ก็จะขาดตอน คุณสร้างโค้ดยี่สิบบรรทัด หยุดเพื่อตรวจสอบ ขอให้แก้ไข ตรวจสอบอีกครั้ง ย้ายไปฟังก์ชันถัดไป และสูญเสียความเชื่อมโยงกับสถาปัตยกรรมในภาพรวม การสลับบริบท (context switching) ไปมาระหว่างการสร้างสรรค์และการตรวจสอบอย่างระแวงสร้างแรงเสียดทาน IDE ของคุณถูกออกแบบมาเพื่อ "ผู้เขียน" ไม่ใช่ "บรรณาธิการ" ที่ต้องทำงานภายใต้เส้นตายที่ต่อเนื่อง
วงจรแห่งความเหนื่อยล้า
ปัจจัยเหล่านี้หล่อเลี้ยงวงจรที่แย่ลงเรื่อยๆ เมื่อเวลาผ่านไปในแต่ละวัน
ผู้ช่วย AI พ่นการทำงานของฟีเจอร์ออกมาในไม่กี่วินาที จากนั้นคุณต้องใช้เวลาสิบห้านาทีในการไล่ดูการ import, ตรวจสอบความเข้ากันได้ของ type และจำลองกรณีขอบเขตในใจ เมื่อถึงรอบที่สามหรือสี่ สมาธิของคุณจะเริ่มลดลง คุณเริ่มยอมรับโค้ดส่วนที่ "ดูเหมือนจะถูกเป็นส่วนใหญ่" ข้อผิดพลาดจึงหลุดรอดไป เพื่อเป็นการชดเชย คุณจึงต้องทำงานช้าลง ซึ่งเป็นการทำลายความเร็วที่คุณได้รับมาตั้งแต่แรก คุณจบวันด้วยโค้ดดิบๆ ที่มากกว่าปกติ แต่กลับมีความมั่นใจในโค้ดนั้นน้อยลง และมีอาการปวดหัวที่บ่งบอกว่าคุณทำงานหนักขึ้น ไม่ใช่ทำงานได้ฉลาดขึ้น
เมื่อความเร็วกลายเป็นอันตราย
หากรูปแบบนี้กลายเป็นกิจวัตร ความเสียหายจะขยายวงกว้างไปไกลกว่าแค่ช่วงบ่ายที่แย่ๆ
ภาวะหมดไฟ (Burnout) จะมาถึงอย่างเงียบเชียบ มันแสดงออกมาในรูปแบบของความรู้สึกหดหู่เมื่อต้องเปิดโปรเจกต์ หรือการไม่สามารถจ้องมองบล็อกโค้ดที่มีสีสันสวยงามได้อีกต่อไปโดยไม่รู้สึกหงุดหงิด เมื่อเครื่องมือหลักที่ควรจะช่วยคุณ กลายเป็นแหล่งกำเนิดหลักของความเหนื่อยล้า ความรู้สึกขุ่นเคืองก็จะตามมา
Then there is skill atrophy. The muscle of translating intent into syntax weakens when you stop doing it. You might still architect systems well, but the granular fluency — knowing why a certain loop structure feels off, or recalling how a specific library behaves under load — fades when an autocomplete layer handles the details. Over time, you risk becoming a passive curator rather than an active engineer.
The most immediate danger, however, is sloppy deployment. Under pressure to maintain velocity, and exhausted by hours of reading machine output, developers sometimes deploy code they have not fully validated.