17 คะแนน โดย GN⁺ 2026-02-09 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังการนำ AI มาใช้ แม้ว่า ผลิตภาพจะสูงขึ้น แต่ความเหนื่อยล้ากลับรุนแรงขึ้น ซึ่งกำลังแพร่กระจายในหมู่วิศวกร
  • ความเร็วในการทำงานเพิ่มขึ้น แต่ ปริมาณงานและความคาดหวังก็เพิ่มตามไปด้วย ทำให้ภาระด้าน การประสานงานและการตรวจทาน ของมนุษย์หนักขึ้น
  • กระบวนการตรวจทานและตัดสินโค้ดจาก AI ที่เกิดซ้ำ ๆ ทำให้ ความเหนื่อยล้าจากการตัดสินใจและการใช้พลังการรับรู้ สะสม
  • การต้องไล่ตามเทคโนโลยีใหม่อย่างต่อเนื่อง, ความเหนื่อยจากการเปลี่ยนเครื่องมือ, และ ผลลัพธ์จาก AI ที่ไม่เป็นแบบกำหนดแน่นอน กระตุ้นความกังวลและภาวะหมดไฟ
  • เพื่อให้การใช้ AI ยั่งยืน จำเป็นต้องมี การตั้งขอบเขต การบริหารเวลา และการผ่อนคลายความเป็นเพอร์เฟ็กชันนิสต์

ความย้อนแย้งระหว่างผลิตภาพกับความเหนื่อยล้าจาก AI

  • AI ช่วยลดเวลาของงานแต่ละชิ้น แต่ ปริมาณงานรวมและความคาดหวังกลับเพิ่มขึ้นพร้อมกัน
    • จากเดิมที่ใช้เวลาหนึ่งวันกับงานเดียว กลายเป็นต้องจัดการหลายปัญหาพร้อมกัน ทำให้ ต้นทุนของการสลับบริบท สูงขึ้น
  • ต้นทุนการผลิตลดลง แต่ต้นทุนการประสานงาน การตรวจทาน และการตัดสินใจเพิ่มขึ้น และภาระนี้ถูกผลักไปให้มนุษย์ทั้งหมด
  • แม้ AI จะสร้างโค้ดได้รวดเร็ว แต่ ความเหนื่อยล้าทางการรับรู้ของมนุษย์ กลับเพิ่มขึ้น

การเปลี่ยนจากผู้สร้างเป็นผู้ตรวจทาน

  • หลังการนำ AI มาใช้ บทบาทของวิศวกรเปลี่ยนจาก ผู้สร้างเป็นผู้ประเมิน
    • การพิมพ์พรอมป์ต์ การตรวจผลลัพธ์ และการตัดสินความถูกต้องกับความปลอดภัย กลายเป็นงานประเมินแบบซ้ำ ๆ ที่เป็นแกนหลัก
  • งานเชิงสร้างสรรค์ทำให้เกิดภาวะจดจ่อ แต่การประเมินทำให้เกิดความเหนื่อยล้า
  • เพราะโค้ดจาก AI ยังขาดความน่าเชื่อถือ จึงมี ภาระที่ต้องตรวจทุกบรรทัด มากขึ้น
  • ด้วยเหตุนี้ ความสำคัญของ ระบบความปลอดภัยและการจัดการสิทธิ์ จึงเพิ่มขึ้น และจำเป็นต้องมุ่งไปในทิศทางที่ลดภาระทางการรับรู้ของมนุษย์

ปัญหาความไม่เป็นแบบกำหนดแน่นอน

  • AI เป็น ระบบที่ไม่เป็นแบบกำหนดแน่นอน ซึ่งอาจให้ผลลัพธ์ต่างกันแม้ใช้อินพุตเดียวกัน และขัดกับวิธีคิดของวิศวกร
  • พรอมป์ต์เดียวกันอาจให้ผลต่างกัน ทำให้เกิด ความไม่เสถียรที่ดีบักไม่ได้
  • เพื่อบรรเทาปัญหานี้ จึงได้พัฒนา เครื่องมือกลั่นบริบทแบบกำหนดได้ Distill เพื่อทำให้อินพุตมีความสม่ำเสมอ
  • วิศวกรบางส่วนมองผลลัพธ์จาก AI เป็น “ร่างที่ยังไม่สมบูรณ์” และรับมือด้วยการเผื่อเวลาแก้ไขไว้ในงบประมาณ

FOMO (ความกลัวว่าจะพลาด) และความเหนื่อยจากเครื่องมือ

  • ในช่วงไม่กี่เดือนที่ผ่านมา มี AI agent, framework และ SDK จำนวนมากเกิดขึ้นอย่างรวดเร็ว
  • ความพยายามที่จะตามเครื่องมือใหม่ให้ทัน ทำให้เกิด วงจรอุบาทว์ของการเรียนรู้และการเปลี่ยนเครื่องมืออย่างต่อเนื่อง
  • เกิดทั้ง ความรู้ที่หายไปอย่างรวดเร็วและงานที่ซ้ำซ้อน และในบางกรณี คนที่รอดูสถานการณ์กลับมีประสิทธิภาพมากกว่าผู้ที่รีบใช้งานตั้งแต่ต้น
  • ผู้เขียนเลือกแนวทางที่ไม่สั่นไหวตามการเปลี่ยนเครื่องมือ โดยโฟกัสที่ ชั้นโครงสร้างพื้นฐาน (สิทธิ์, บริบท, ความปลอดภัย)

กับดักของ “ขอพรอมป์ต์อีกแค่อีกครั้งเดียว”

  • เมื่อผลลัพธ์จาก AI ไม่สมบูรณ์ จึงเกิดภาวะ วนซ้ำกับการปรับพรอมป์ต์
  • การลองซ้ำหลายครั้งดูเหมือนมีประสิทธิผล แต่จริง ๆ แล้ว กลับเสียเวลาไปกับการปรับพรอมป์ต์มากกว่าการแก้ปัญหาจริง
  • จึงใช้ “กฎ 3 ครั้ง” เพื่อรักษาประสิทธิภาพ: หากลองสามครั้งแล้วยังใช้ประโยชน์ได้ไม่เกิน 70% ก็จะลงมือเขียนเอง

การปะทะกันระหว่างความเป็นเพอร์เฟ็กชันนิสต์กับผลลัพธ์เชิงความน่าจะเป็น

  • ผลลัพธ์จาก AI มักอยู่ในระดับ “เกือบถูก” เสมอ ซึ่งสร้างความเครียดอย่างมากให้กับวิศวกรที่มีแนวโน้มเป็นเพอร์เฟ็กชันนิสต์
  • การแก้ไขจุกจิกซ้ำไปมา นำไปสู่ ความเหนื่อยล้าทางอารมณ์และการเสียเวลา
  • การมองผลลัพธ์จาก AI เป็น “ร่าง” และนำมาปรับต่ออย่างรวดเร็ว เป็นท่าทีที่มีประสิทธิภาพกว่า

การอ่อนลงของความสามารถในการคิด

  • ผลจากการพึ่งพา AI ทำให้เกิด การถดถอยของความสามารถในการแก้ปัญหาและการออกแบบ
  • นิสัยที่ไม่คิดด้วยตนเองนำไปสู่ การฝ่อลงของ “กล้ามเนื้อการคิด”
  • เพื่อป้องกันสิ่งนี้ จึงฝึก คิดและออกแบบโดยไม่ใช้ AI เป็นเวลาช่วงหนึ่งในทุกวัน

กับดักของการเปรียบเทียบ

  • บนโซเชียลมีเดีย มักมีเพียง กรณีที่ใช้ AI แล้วได้ผลลัพธ์อย่างรวดเร็ว ถูกแชร์ออกมา ทำให้ความล้มเหลวหรือความเหนื่อยล้าของแต่ละคนไม่ปรากฏ
  • ผลลัพธ์จาก AI มีความสามารถในการทำซ้ำต่ำ จึงทำให้ การเปรียบเทียบกันนั้นแทบไม่มีความหมาย
  • ทางที่เหมาะสมคือ ลดการเสพข้อมูล และโฟกัสกับ แหล่งข้อมูลที่เชื่อถือได้ซึ่งเน้นการสร้างและการปฏิบัติจริง

กลยุทธ์การใช้ AI อย่างยั่งยืน

  • จำกัด ระยะเวลาของเซสชัน AI เพื่อป้องกันการวนซ้ำมากเกินไป
  • แยกเวลาคิดออกจากเวลาใช้ AI เพื่อรักษาสมดุลทางการรับรู้
  • ยอมรับความสมบูรณ์ระดับ 70% เพื่อลดความเป็นเพอร์เฟ็กชันนิสต์
  • ชะลอจังหวะการรับเทคโนโลยีใหม่ และเลือกใช้เครื่องมือที่ผ่านการพิสูจน์แล้วเป็นหลัก
  • บันทึก log ประสิทธิภาพของ AI เพื่อเข้าใจประโยชน์จริงและข้อจำกัด
  • ลดขอบเขตการตรวจทาน และโฟกัสเฉพาะพื้นที่สำคัญ

ความยั่งยืนและภาวะหมดไฟ

  • AI ลบข้อจำกัดด้านความเร็วในการทำงาน ออกไป จึงเร่งให้เกิดการทำงานหนักเกินไป
  • เมื่อมนุษย์ เกินขีดจำกัดทางการรับรู้ ก็จะเกิดภาวะหมดไฟ และสิ่งนี้กำลังขยายจากปัญหาระดับบุคคลไปเป็น ปัญหาเชิงระบบ
  • แกนสำคัญของการฟื้นตัวไม่ใช่ปริมาณการใช้ AI แต่คือ การออกแบบวิธีใช้งานใหม่
  • ท่ามกลางความเหนื่อยล้า ก็ยังเกิดเครื่องมือแก้ปัญหาจริงอย่าง Distill·agentic-authz·AgentTrace ขึ้นมา

ศักยภาพที่แท้จริง: ความสามารถในการรู้ว่าเมื่อไรควรหยุด

  • ความสามารถสำคัญในยุค AI คือ วิจารณญาณที่จะรู้ว่าเมื่อไรควรหยุด
  • ต้องรู้ว่าเมื่อไรควรหยุดที่ผลลัพธ์ซึ่งดีพอแล้ว และเมื่อไรควรเขียนเองหรือพักผ่อน
  • การปกป้องสมองของมนุษย์ในฐานะ ทรัพยากรที่มีจำกัด คือวิศวกรรมที่แท้จริง
  • AI ทรงพลัง แต่ก็เป็น เครื่องมือที่สิ้นเปลืองพลังทางการรับรู้มากที่สุด และการใช้อย่างชาญฉลาดคือหัวใจของความยั่งยืน
  • ผลลัพธ์ที่ยั่งยืน คือคุณค่าที่แท้จริง และเป็นเป้าหมายสูงสุดของการใช้ AI

5 ความคิดเห็น

 
fantajeon 2026-02-09

ยิ่งนานวันก็ยิ่งไม่แน่ใจว่าสำนวนนี้แม่นยำไหม แต่รู้สึกว่านักพัฒนากำลังค่อย ๆ กลายเป็น “tech leader” มากขึ้น

ถ้า AI เข้ามาเอางาน “เขียนโค้ด” ไป สิ่งที่เหลืออยู่สุดท้ายก็คือ

  • การแก้ปัญหา (ความเครียด)
  • การตรวจทานผลลัพธ์ (ความเครียด)
  • ความรับผิดชอบ (ความเครียด)

เท่านั้น

พูดอีกแบบก็คือ นักพัฒนาไม่ได้เป็น “ผู้ผลิต” อีกต่อไป แต่บทบาทกำลังเปลี่ยนไปเป็น

  • “ผู้มีอำนาจตัดสินใจ”
  • “ผู้ตรวจทาน”
  • “ผู้รับผิดชอบ”

แทน

พอเป็นแบบนี้ ก็เลยเกิดความเหนื่อยล้าจากการทำงานแบบที่ไม่เคยมีมาก่อน และทำให้ต้องถามตัวเองว่าสุดท้ายแล้วทิศทางนี้สอดคล้องกับความถนัดในอาชีพนักพัฒนาที่ฉันมองหาอยู่จริงหรือไม่

 
roxie 2026-02-24

บรรทัดสุดท้ายกินใจดีนะครับ/ค่ะ เหมือนว่านี่ไม่ใช่สิ่งที่ผม/ฉันอยากทำมาตั้งแต่แรก

 
dolsangodkimchi 2026-02-26

ตอนเด็ก ๆ ผมเคยอยู่ชมรมวงดนตรี แล้วก็มีเพื่อนคนหนึ่งที่พยายามโน้มน้าวทุกคนว่าในนั้นเราควรแต่งเพลงของตัวเองกัน เขาบอกว่าแทนที่จะขัดเกลาทักษะการเล่น เราควรคิดก่อนว่าอยากร้องเรื่องอะไร แน่นอนว่าที่ผมจำได้คือเสียงของพวกที่อยากตั้งวงด้วยการเล่นเพลงดัง ๆ ตามต้นฉบับนั้นมีมากกว่า
แต่ช่วงนี้ผมนึกถึงเพื่อนคนนั้นบ่อยมาก
มันเป็นคำถามที่ผมมัวแต่ยุ่งกับการใช้ชีวิตจนเลี่ยงไม่เผชิญมันมาตลอด แต่ด้วยการพัฒนาของ AI หลังจากที่ผมยึดอาชีพนักพัฒนาแล้ว ตกลงผมชอบการเขียนโค้ดจริง ๆ หรือผมชอบการสร้างคุณค่า และใช้การเขียนโค้ดเป็นเพียงเครื่องมือสำหรับสิ่งนั้น
ถ้าที่ผ่านมาคนสองประเภทนี้ยังปะปนกันอยู่ ต่อจากนี้คงอีกไม่นานจะถึงช่วงเวลาที่ผมต้องทำให้ชัดว่าตัวเองเป็นฝ่ายไหนกันแน่

 
pencil6962 2026-02-26

ความรับผิดชอบในการสร้างโปรแกรมที่ทำงานได้ดีตามความต้องการของลูกค้าและเป็นโปรแกรมที่ไม่เสียยังคงเป็นของนักพัฒนาอยู่ ดังนั้นคุณไม่จำเป็นต้องเลิกลงมือเขียนโค้ด ผมคิดว่า AI แค่ช่วยพิมพ์ให้เท่านั้น แต่แก่นแท้ยังเหมือนเดิม

 
GN⁺ 2026-02-09
ความเห็นจาก Hacker News
  • สำหรับฉัน ความเหนื่อยมันต่างออกไปนิดหน่อย ปัญหาคือการต้อง หยุดรอทุกครั้งที่ LLM สร้างผลลัพธ์ ระหว่างทำงานหรือรีวิวโค้ด
    ระยะเวลาที่ต้องรอนั้นคาดเดาไม่ได้ เลยไม่แน่ใจว่าควรรอต่อหรือเริ่มทำอย่างอื่นดี สุดท้ายก็เลยไปทำอย่างอื่นเพื่อฆ่าเวลา
    ท้ายที่สุดก็ เข้าโหมดลื่นไหล (flow) ไม่ได้ และเหนื่อยจากการต้องคอยเฝ้าว่างานเบื้องหลังจะเสร็จเมื่อไร
    แทนที่จะรู้สึกว่าผลิตภาพสูงขึ้น กลับรู้สึกเหมือนเป็นพี่เลี้ยงขี้เกียจที่คอยกันเด็กไม่ให้เจ็บตัว

    • อาจเป็นคำแนะนำที่ไม่ค่อยรับผิดชอบนัก แต่ทุกครั้งที่ฉันส่งคำขอยาว ๆ ให้ Claude Code ฉันก็ พักหายใจแล้วไปเล่นเกม
      ขอแนะนำเกมโอเพนซอร์สที่เริ่มเล่นสั้น ๆ แล้วหยุดได้อย่าง Endless Sky
      เมื่อก่อนฉันเริ่มรู้สึกว่าการเขียนโปรแกรมไม่สนุกแล้ว แต่ด้วย Claude Code ฉันกลับมารู้สึกสนุกอีกครั้ง ไม่เหมือนเดิมซะทีเดียว แต่ก็สนุกพอสำหรับช่วงชีวิตตอนนี้
    • ความเหนื่อยแบบนี้ไม่ใช่เรื่องใหม่ แค่พอมี เครื่องมือเขียนโค้ด AI แบบเอเจนต์ เข้ามา ความล้าจากการสลับบริบทก็เพิ่มขึ้นเป็น 10 เท่า
      อย่างที่ฉันเขียนไว้ใน บทความเรื่อง review fatigue มันส่งผลไม่ใช่แค่กับนักพัฒนา แต่กับทั้งองค์กรด้วย
      พอเวิร์กโฟลว์ AI มุ่งเน้นการรีดผลิตภาพสูงสุด สุดท้ายก็กลายเป็นการเผาผลาญมนุษย์
      ทางแก้ก็เป็นแบบคลาสสิก — พักบ่อย ๆ และให้นักพัฒนามนุษย์ได้ลงมือเขียนโค้ดเองบ้าง อย่างน้อยเล็กน้อย วิธีนี้ช่วยให้ช้าลงแต่ยังรักษา ความลื่นไหลและการฟื้นตัว ได้
    • สิ่งที่สำคัญกว่าผลิตภาพคือ ความลื่นไหล (flow) ต่างหาก กาแฟสักแก้ว หูฟังตัดเสียงรบกวน และช่วงโฟกัส 2 ชั่วโมง คือช่วงเวลาที่น่ารักที่สุดของการเขียนโปรแกรม
    • ช่วงนี้ฉันเรียกมันว่า “Claude Code routine ออกกำลังกาย
      ระหว่างที่ LLM ทำงาน ฉันจะสควอต วิดพื้น หรือเดินยืดเส้นยืดสายรอบบ้าน มันสนุกกว่านั่งหน้าคีย์บอร์ดทั้งวันมาก
      การขยับร่างกายช่วยจัดระเบียบความคิดได้ดีขึ้น แต่ถึงอย่างนั้น ความเหนื่อยล้าทางใจ ก็ยังอยู่
    • เมื่อก่อนฉันเคยจมกับงานได้เป็นชั่วโมง แต่ตอนนี้โดนขัดจังหวะตลอด
      ระหว่างส่งพรอมป์ต์แล้วรอ ฉันก็เผลอไปท่องเว็บ ถ้าไม่ใช้แอป SelfControl มาบล็อกไว้ก็แทบทนไม่ไหว
      แม้ LLM จะช่วยเพิ่มผลิตภาพ แต่พอจบวันกลับเหนื่อยกว่าเดิมมาก และยังรู้สึกผิดด้วย
  • ไอเดียของบทความดีนะ แต่พออ่านไปแล้วกลับรู้สึก เหนื่อยเหมือนอ่านอะไรที่ AI เขียน
    เรื่องที่จบได้ในหนึ่งสองประโยคกลับยืดยาวเกินไป และมีตัวอย่างที่ไม่จำเป็นเยอะ
    ข้ออ้างว่า “หน้าแรกของ HN กำลังสับสนวุ่นวาย” ก็ไม่จริง บทความที่ยกมาพูดถึงยังได้ไม่ถึง 5 upvote ด้วยซ้ำ และคุณภาพหน้าแรกของ HN ก็ยังโอเคอยู่
    อีกอย่าง ข้ออ้างว่า “ไม่มีใครพูดถึงเรื่องนี้” ก็ไม่จริง การพูดคุยเรื่อง AI fatigue มีมานานแล้ว

    • ฉันเห็นด้วยกับคำว่า “หน้าแรก HN ยังปกติดี” แต่สิ่งที่แปลกจริง ๆ คือประโยคแบบนี้
      “ขอบคุณ OpenClaw, ขอบคุณ AGI—สำหรับฉันมันมาถึงแล้ว”
      “ถ้าวันนี้คุณยังไม่ได้ใช้โทเค็นอย่างน้อย $1,000 ต่อวิศวกรมนุษย์หนึ่งคน โรงงานซอฟต์แวร์ของคุณก็ยังมีที่ให้ปรับปรุง”
      “โค้ดไม่ควรให้มนุษย์รีวิว”
      “C เคยทำอะไรกับแอสเซมบลี Java เคยทำอะไรกับ C ตอนนี้ LLM ก็กำลังทำแบบนั้นกับทุกภาษา”
      ประโยคเหล่านี้ยกมาจากโพสต์ที่ขึ้นหน้าแรกจริง ๆ
    • ฉันเห็นประโยค “You’re not imagining it.” แล้วก็สะดุดทันที เพราะมันรู้สึกแบบนั้นจริง ๆ
    • ผู้เขียนน่าจะสั่ง LLM ประมาณว่า “ฉันเหนื่อย ช่วยดูเซสชันล่าสุดแล้วเขียนเป็นบล็อกอธิบายเหตุผลให้หน่อย”
      หรือไม่ก็อ่านบทความ AI มากเกินไปจน สไตล์การเขียนเองกลายเป็นเหมือน AI ไปแล้ว
    • หรือบางทีเขาอาจเป็นคนที่แค่ชอบเขียนก็ได้
      ฉันเองก็เพิ่งเริ่มเขียนบล็อกไม่นานนี้ แล้วพบว่า การเขียนเชิงเล่าเรื่อง สนุกกว่าที่คิด
      แต่ละคนก็มีสไตล์ต่างกันไป ไม่ใช่ปัญหาอะไร
    • เห็นด้วยกับคำว่า “เหนื่อยแบบงานเขียนที่เหมือน AI เขียน”
      เนื้อหานี้ย่อได้ไม่กี่ย่อหน้า แต่มีคำขยายที่ไม่จำเป็นเยอะเกินไป
      ต่อไปเราอาจได้เห็น “ฉลากผู้ผลิตที่เป็นมนุษย์” ติดอยู่กับคอนเทนต์ด้วยก็ได้ — เช่น “ผลิตโดยฟรีแลนซ์” หรือ “ผลิตโดยคนชานเมือง” อะไรทำนองนั้น
  • เห็นด้วยกับคำว่า “พอปล่อยงานได้เร็วขึ้น ความคาดหวังก็สูงขึ้น”
    นี่เป็นปัญหาเก่าแล้ว Helen Keller ก็เคยพูดอะไรคล้าย ๆ กันไว้ตั้งแต่เกือบ 100 ปีก่อน
    ใน บทความของ The Atlantic มีใจความประมาณว่า “เอาเครื่องทุ่นแรงมาใช้เพื่อประหยัดแรงงานจริง ๆ กันเถอะ”

  • ในหนึ่งวันฉันขยับหลายโปรเจกต์ได้ก็จริง แต่ก็ หมดแรงไปเลย
    หลายคนถึงกับนอนไม่หลับเพราะถูกล่อด้วยความคิดว่า “ขอส่งพรอมป์ต์อีกแค่ครั้งเดียว”
    จังหวะการทำงานที่ยั่งยืน ซึ่งสั่งสมมานานพังไปแล้ว และคงต้องใช้เวลาสักพักกว่าจะหาสมดุลใหม่เจอ

    • เมื่อก่อนพอเริ่มไอเดียอะไร ฉันจะรู้ได้เร็วว่ามันไม่มีคุณค่าหรือไม่น่าจะเวิร์ก
      แต่ตอนนี้ช่วงแรกมันไปได้ดีมากจนทำต่อเรื่อย ๆ แล้วค่อยมาเจอ จุดที่ตันแบบกะทันหัน
    • ฉันก็เป็นฟรีแลนซ์เหมือนกัน และด้วย AI ฉันทำระบบออก invoice เสร็จในวันเดียว
      แต่ฉันหยุดไม่ได้ เลยขยายต่อไปถึงบัญชี ภาษี CRM คลังสินค้า และการจัดการโปรเจกต์
      สุดท้ายก็เผลอสร้าง SaaS ที่ไม่มีความจำเป็น ขึ้นมา ตอนนี้เลยกำลังคิดว่าจะปล่อยเป็นโอเพนซอร์สดีไหม
    • ความคิดแบบ “ขอทำให้สมบูรณ์อีกนิดเดียว” กินเวลาทั้งหมดไป
      แต่ตอนนี้อย่างน้อยก็ ตามดู agent session ต่อจากเบราว์เซอร์มือถือได้แล้ว เลยนอนดูบนเตียงได้ด้วย (พูดเล่นครึ่งหนึ่งจริงครึ่งหนึ่ง)
    • AI ลดแรงเสียดทานของการเขียนโค้ดลงไปมาก
      ตอนนี้คอขวดที่แท้จริงไม่ใช่การเขียนโค้ด แต่คือ การเก็บ requirement และการตัดสินใจ
    • ถ้าผลิตภาพเพิ่มขึ้น 10 เท่าขนาดนั้น แล้ว เวลา休息ก็น่าจะเพิ่มเป็นสองเท่าด้วยไม่ใช่เหรอ?
      ไม่เข้าใจเลยว่าทำไมถึงยังต้องทำงานต่อกันอีก
  • ผมเป็นคนเขียนบทความเอง ไม่ได้ตั้งใจเขียนต้าน AI แต่พูดถึง ต้นทุนทางการรับรู้
    ยิ่งงานเร็วขึ้น งานก็ยิ่งมากขึ้น และการต้องคอยตรวจผลลัพธ์จาก AI ก็สะสมเป็น ความล้าจากการตัดสินใจ
    ระบบนิเวศของเครื่องมือก็เปลี่ยนทุกสัปดาห์ ผมแค่แชร์วิธีที่ช่วยได้จริง และอยากรู้ว่าคนอื่นกำลังชนกำแพงคล้าย ๆ กันหรือเปล่า

    • อยากรู้ว่าทำไมถึง ใช้ LLM มาปรับประโยค ในบล็อกและโพสต์นี้
      มันทำให้ความรู้สึกเหนื่อยจากการคุยกับสิ่งที่ไม่ใช่มนุษย์หนักขึ้นไปอีก
    • ภาพในบทความทำให้นึกถึง ภาพกรณีภาพผิดพลาดจาก AI ที่เป็นประเด็น
    • เป็นบทความที่ดีนะ ฉันเองก็เคยรู้สึก กดดันว่าต้องทำอะไรได้มากขึ้นเพราะ AI
      แต่พอตั้งความคาดหวังให้สมจริง และพยายามไม่หวั่นไหวไปกับ “โพสต์เวทมนตร์จาก AI” ทั้งหลาย ความกังวลก็ลดลง
    • น่าขำตรงที่ บทความเรื่อง AI fatigue ดันดูเหมือนถูกสร้างด้วย AI ซะเอง
  • เทคโนโลยีไม่เคยมีไว้ทำให้แรงงานสบายขึ้น
    มันมีเป้าหมายเพื่อเพิ่ม ผลิตภาพและความสามารถในการแข่งขัน มาโดยตลอด
    จากม้าสู่รถยนต์ จากโทรศัพท์สู่สมาร์ตโฟน แต่เวลาว่างของเราไม่ได้เพิ่มขึ้นเลย เราแค่กลายเป็นมนุษย์ที่ เคลื่อนที่ได้มากขึ้นและเชื่อมต่อมากขึ้น เท่านั้น

    • แต่การใช้ประสิทธิภาพนั้นเป็นเรื่องของการเลือก
      ถ้ายอมรับคุณภาพชีวิตแบบดั้งเดิมได้ ก็สามารถ ทำงานให้น้อยลงและยังใช้ชีวิตได้สบาย
  • ช่วงนี้ที่ฉันรู้สึกคือ ความล้าของการทำงานบริหารจัดการความคิด (executive functioning fatigue)
    เวลาทำงานร่วมกับ AI เราต้องตัดสินใจระดับสูงอยู่ตลอด มากกว่าจะเป็นแค่การลงมือทำ
    แทบไม่มีช่วงพักเลย เหมือนสมองส่วนหน้าถูกใช้งานหนักเกินไป
    ถ้าสภาพนี้ดำเนินต่อไปเรื่อย ๆ บางที ความสามารถด้าน executive function ของมนุษย์อาจแข็งแรงขึ้นก็ได้

  • ไม่คิดเลยว่าการดูแลทีมวิศวกรอัจฉริยะสิบคนแต่ไม่นิ่งเอาเสียเลย จะ บั่นทอนพลังได้ขนาดนี้

    • แบบนั้นคงไม่ใช่ ‘การบริหาร’ แต่ควรเรียกว่า micro-managing มากกว่า
  • ผมคิดว่าสาเหตุของ AI fatigue คือ สมดุลของสามช่วงในการเขียนโปรแกรมพังไปแล้ว
    ปกติทั้งสามช่วงคือ แก้ปัญหา → เขียนโค้ด → ตรวจผลลัพธ์ และมันเคยสมดุลกัน
    การเขียนโค้ดแม้จะซ้ำ ๆ แต่ก็เป็น กระบวนการที่คล้ายสมาธิและให้ความมั่นคง ส่วนการแก้ปัญหานั้นใช้พลังสูง และการตรวจผลลัพธ์คือรางวัลโดพามีน
    แต่เมื่อ LLM มารับช่วงการเขียนโค้ดไป เราเลยเหลือแค่ ขั้นแก้ปัญหาและรีวิวที่เครียดสูง
    ช่วงกันชนระหว่างสองอย่างนั้นหายไป เลยยิ่งเหนื่อยกว่าเดิมมาก
    เหตุผลที่หลายคนคิดถึงการเขียนโค้ดแบบเดิม ก็เพราะการสูญเสีย กระแสลื่นไหลเชิงสมาธิ นี่เอง
    ผมเองก็ชอบทำ pair programming กับ AI โดยพิมพ์โค้ดเองไปด้วย รู้สึกว่าวิธีนี้ยั่งยืนกว่าในระยะยาว
    แต่ความยั่วยวนของ ผลิตภาพจากการจัดการหลายเอเจนต์พร้อมกัน ก็แรงมากจริง ๆ

  • ส่วนที่ว่า “กำลังต่อสู้กับระบบที่ไม่เป็น deterministic” นั้นโดนใจมาก
    โดยธรรมชาติแล้ว LLM ต้องการ การแทรกแซงจากมนุษย์อย่างต่อเนื่อง เว้นแต่บริษัทจะพร้อมรับผิดชอบผลลัพธ์ของมันทั้งหมด

    • แต่การ โยนความรับผิดให้ ‘เครื่องโง่ ๆ’ นั้นเป็นไปไม่ได้
      จะลดแรงดันไฟฟ้าเพื่อลงโทษมันก็ไม่ได้ และมันก็ฟังไม่สมเหตุสมผลพอ ๆ กับการเอาผิดลูกเต๋า
    • ยิ่งไปกว่านั้น นักพัฒนามนุษย์เองก็ไม่ได้ เป็น deterministic อย่างสมบูรณ์ เช่นกัน ฉันไม่เคยเจอใครแบบนั้นเลย