- การแพร่หลายของ เครื่องมือ AI ทำให้การเขียนโค้ดง่ายขึ้น แต่ ความเข้มข้นและความซับซ้อนของงานวิศวกรซอฟต์แวร์ กลับเพิ่มขึ้น
- เมื่อ AI ช่วยเพิ่มผลิตภาพ ความคาดหวังขององค์กรและเส้นฐานของปริมาณงานก็สูงขึ้น วิศวกรจึงถูกกดดันให้ทำงานได้มากขึ้นและเร็วขึ้น
- เมื่ออัตลักษณ์ที่ยึดโยงกับการเขียนโค้ดเป็นศูนย์กลางอ่อนลง วิศวกรจึงต้องรับภาระ งานที่ไม่ใช่งานพัฒนา เช่น รีวิว ออกแบบ และคิดเชิงผลิตภัณฑ์ เพิ่มเติม
- การตรวจทานและดีบักโค้ดที่ AI สร้างขึ้นใช้เวลามากขึ้น ทำให้ ภาระด้านการควบคุมคุณภาพและภาระทางความคิด เพิ่มขึ้น
- เพื่อสร้างวัฒนธรรมวิศวกรรมที่ยั่งยืน จำเป็นต้องมี ความเข้าอกเข้าใจจากผู้นำ การกำหนดขอบเขตบทบาท การพัฒนาจูเนียร์ และตัวชี้วัดการประเมินแบบใหม่
การเลื่อนของเส้นฐานและภาระที่มองไม่เห็น
- หลังนำ AI มาใช้ ผลผลิตที่คาดหวังจากวิศวกรเพิ่มขึ้นอย่างรวดเร็ว และมีการคาดหวังงานมากขึ้นแม้ไม่มีคำสั่งอย่างชัดเจน
- ตามงานวิจัยของ Harvard Business Review พนักงานที่ใช้ AI ไม่ได้เลิกงานเร็วขึ้น แต่กลับ ทำงานได้มากขึ้น
- 83% ตอบว่า AI ทำให้ปริมาณงานเพิ่มขึ้น และ อัตรา burnout ของผู้ปฏิบัติงานมากกว่า 60% ขณะที่ผู้บริหารอยู่ที่ 38% ซึ่งสะท้อนช่องว่างที่ชัดเจน
- ขณะที่ฝ่ายผู้นำมองว่า “AI ทำให้งานง่ายขึ้น” วิศวกรหน้างานกลับรับรู้ถึงความซับซ้อนและความเหนื่อยล้า
- ในอีกการสำรวจหนึ่งที่มีผู้ตอบมากกว่า 600 คน ก็พบว่า 2 ใน 3 ประสบภาวะ burnout และ 43% ตอบว่าผู้นำไม่เข้าใจความเป็นจริง
วิกฤตอัตลักษณ์ของวิศวกร
- วิศวกรจำนวนมากเคยได้รับความพึงพอใจในอาชีพจาก การลงมือเขียนโค้ดด้วยตนเองในฐานะงานสร้างสรรค์
- แต่หลัง AI เข้ามา มีข้อความโดยนัยแพร่หลายว่า “อย่าเขียนโค้ดเอง ให้ไปจัดการมันแทน”
- AI เข้ามาทำส่วนของการลงมือสร้าง ขณะที่วิศวกรเปลี่ยนไปเป็น ผู้กำกับดูแลและผู้รีวิว
- นี่ไม่ใช่แค่การเปลี่ยนแปลงธรรมดา แต่เป็น การเปลี่ยนผ่านระดับรากฐานของอัตลักษณ์ทางวิชาชีพ ซึ่งทำให้ความภาคภูมิใจของผู้มีทักษะลดลง
- ดังคำว่า “จากผู้สร้างกลายเป็นผู้ตรวจ” แม้ปริมาณงานเพิ่มขึ้น แต่ ความเป็นช่างฝีมือและความรู้สึกจดจ่อมีส่วนร่วมนั้นลดลง
การขยายบทบาทและ scope creep
- เมื่อ AI ทำให้การลงมือพัฒนาเร็วขึ้น คอขวดจึงย้ายไปอยู่ที่ งานรายรอบ เช่น ข้อกำหนด สถาปัตยกรรม การทดสอบ และการ deploy
- องค์กรจึงกระจายงานเหล่านี้มายังวิศวกร ทำให้ต้องรับผิดชอบถึง การวางแผนผลิตภัณฑ์ การประเมินความเสี่ยง และการบริหารงานปฏิบัติการ
- งานวิจัยของ Harvard Business Review ยังชี้ว่า ขอบเขตบทบาทเริ่มพร่าเลือน และงานของ PM นักวิจัย และวิศวกรเริ่มทับซ้อนกัน
- งานด้านวิศวกรรม 45% ต้องการทักษะข้ามสายงาน แต่ ค่าตอบแทนหรืออำนาจตัดสินใจไม่ได้เพิ่มตาม
- ผลลัพธ์คือ ขอบเขตงานกว้างขึ้นแต่ความลึกตื้นลง และ burnout ก็ยิ่งเร่งตัว
ความย้อนแย้งของการกำกับดูแล: ความยากของการรีวิวโค้ดจาก AI
- เกิด ความย้อนแย้งที่การตรวจโค้ดที่ AI สร้างยากกว่าการเขียนเอง
- ผู้เขียนย่อมรู้บริบทของสิ่งที่ตนสร้าง แต่โค้ดจาก AI มี ที่มาของการตัดสินใจที่ไม่ชัดเจน จึงเพิ่มภาระในการรีวิว
- จากการสำรวจของ Harness 67% ระบุว่าเวลาในการดีบักเพิ่มขึ้น และ 68% ระบุว่าเวลาในการรีวิวเพิ่มขึ้น
- ฝ่ายบริหารคาดหวังความเร็วที่สูงขึ้น แต่ในความเป็นจริง ภาระด้านการประกันคุณภาพและการทำความเข้าใจบริบท กลับสูงขึ้น
- คอขวดของการผลิตจึงย้ายจากขั้นการเขียน ไปสู่ ขั้นการทำความเข้าใจ ซึ่งไม่สามารถแก้ได้ด้วยระบบอัตโนมัติ
กับดักของการเร่งความเร็วและความยั่งยืน
- เมื่อ AI เพิ่มความเร็ว ก็เกิด ลูปเสริมแรงตัวเองที่ทำให้ปริมาณงานเพิ่มขึ้นโดยธรรมชาติ
- งานวิจัยของ Harvard เรียกสิ่งนี้ว่า “workload creep” ซึ่งทำให้ภาระงานสะสมโดยที่คนไม่ทันรู้ตัว
- ในอดีต ความเร็วในการคิดและพิมพ์ของมนุษย์เป็นข้อจำกัดตามธรรมชาติ แต่ AI ได้ลบข้อจำกัดนั้นออกไป
- ผลคือ ตัวชี้วัดด้านผลิตภาพสูงขึ้น แต่คุณภาพลดลง พร้อมกับหนี้ทางเทคนิคและความเหนื่อยล้าที่สะสม
- ภายนอกอาจดูเหมือนผลิตภาพดีขึ้น แต่ ภายในกลับเกิดการหมดไฟและคุณภาพที่ถดถอย
การขาดช่วงของการเรียนรู้สำหรับวิศวกรจูเนียร์
- เมื่อ AI เข้ามาแทนงานง่าย ๆ โอกาสฝึกปฏิบัติของวิศวกรระดับต้นก็ลดลงอย่างมาก
- ในช่วง 2023~2024 การรับสมัครระดับต้นของบริษัทยักษ์ใหญ่ด้านเทคโนโลยี ลดลง 25% และรายงานของ HackerRank ก็ยืนยันว่า การจ้างงานเน้นผู้มีประสบการณ์
- เมื่อโจทย์ง่าย ๆ สำหรับการเรียนรู้หายไป เส้นทางการสร้างบุคลากรซีเนียร์ในอนาคตก็เสี่ยงพังทลาย
- ดังคำเตือนที่ว่า “คุณไม่สามารถกำกับดูแลระบบที่ไม่เคยสร้างด้วยตัวเองได้” ปัญหา การขาดตอนของทักษะพื้นฐาน จึงถูกมองว่าเป็นความเสี่ยงระยะยาว
สิ่งที่ผู้นำต้องทำ
- การ เข้าอกเข้าใจและยอมรับอย่างชัดเจน ถึงความยากของการเปลี่ยนแปลง คือจุดเริ่มต้นของการรักษาความไว้วางใจ
- จัดให้มี การ reskill ที่เป็นรูปธรรม: การออกแบบระบบ ความปลอดภัย การคิดเชิงผลิตภัณฑ์ การประเมินโค้ดจาก AI และทักษะขั้นสูงอื่น ๆ
- ต้อง กำหนดขอบเขตบทบาทให้ชัดและปรับค่าตอบแทนให้เหมาะสม เพื่อป้องกันการขยายงานแบบไร้ขีดจำกัด
- นิยามตัวชี้วัดผลงานใหม่: ให้ความสำคัญกับคุณภาพ ความเสถียร และสุขภาวะของทีม มากกว่าความเร็วหรือจำนวนบรรทัดโค้ด
- การคงการจ้างงานจูเนียร์ไว้ เป็นเงื่อนไขจำเป็นต่อการรักษาระบบนิเวศบุคลากรในระยะยาว
กลยุทธ์ที่วิศวกรแต่ละคนทำได้
- รักษาทักษะพื้นฐานทางเทคนิค: ความเข้าใจด้านสถาปัตยกรรม การดีบัก ประสิทธิภาพ และความปลอดภัย ยิ่งสำคัญมากขึ้นกว่าเดิม
- ระวังกับดักของการเร่งความเร็ว: อย่าไล่ตามความเร็วสูงสุดที่ AI ทำได้โดยไม่มีเงื่อนไข แต่ควรรักษาจังหวะการทำงานที่ยั่งยืน
- ยอมรับบางบทบาทที่ขยายออกมาและตนเองสนใจ แล้วใช้เป็นโอกาสในการเติบโตทางอาชีพ
- แบ่งปันเรื่อง burnout และความรู้สึกโดดเดี่ยว เพื่อขยายการรับรู้ความจริงผ่านการพูดคุยกับเพื่อนร่วมงาน
- การเปลี่ยนแปลงทางเทคโนโลยีเกิดขึ้นซ้ำมาโดยตลอด และ AI ก็ไม่อาจแทนที่ความต้องการบุคลากรเทคนิคที่มีรากฐานแข็งแรงได้
ความย้อนแย้งที่เรากำลังเผชิญ
- ความจริงที่ว่า AI ทำให้การเขียนโค้ดง่ายขึ้น แต่การทำวิศวกรรมกลับยากขึ้น นั้นเกิดขึ้นพร้อมกันได้
- เมื่อความคาดหวังสูงขึ้น บทบาทขยายขึ้น และการสนับสนุนไม่เพียงพอ ก็จะนำไปสู่วัฒนธรรมที่ ไม่ยั่งยืน
- หากไม่ยอมรับความย้อนแย้งนี้ ก็จะไม่สามารถรักษา ความไว้วางใจและการคงอยู่ของบุคลากร ได้
- เราไม่ควรลืมหลักการที่ว่า คน ไม่ใช่เครื่องมือ คือผู้สร้างผลิตภัณฑ์ และข้อสรุปคือ
ความสามารถในการแข่งขันที่แท้จริงในยุค AI มาจากองค์กรที่เข้าใจและปกป้องขีดจำกัดของมนุษย์
2 ความคิดเห็น
> หนี้ทางความคิด: เมื่อความเร็วแซงหน้าความเข้าใจ
ความคิดเห็นจาก Hacker News
บทความนี้ดูเหมือนจะเป็นงานที่ สร้างโดย AI บางส่วน หรืออย่างน้อยก็ถูกแก้ไขหนักมากด้วย LLM
โครงสร้างประโยคแบบ “It’s not X, it’s Y” ถูกใช้ซ้ำ ๆ และก็น่าสงสัยที่บล็อกซึ่งแทบไม่มีความเคลื่อนไหวระหว่างปี 2015~2025 จู่ ๆ ก็เริ่มปล่อยบทความจำนวนมากแบบผิดปกติ
สไตล์การเขียนแบบนี้ทำให้คนจำนวนมากเอียน แต่ดูเหมือนจะไม่สำคัญสำหรับ คนที่หวังจะประสบความสำเร็จ ในอุตสาหกรรมนี้
จังหวะและสำนวนที่ซ้ำ ๆ ดูเป็นงานจาก LLM แบบชัดเจน ขาดอารมณ์แบบมนุษย์และเนื้อหาก็กลวง
ถึงเวลาที่ต้องเห็นคุณค่าของ ชุมชนเล็ก ๆ ที่มีคุณภาพสูง ซึ่ง AI ยังแทรกซึมเข้าไปไม่มาก
ประโยคอย่าง “The job changed. The expectations changed. And nobody sent a memo.” ให้ความรู้สึกแบบ AI เขียนชัดมาก
ปัญหาหนึ่งที่เจอจริงคือ การ deploy ด้วย AI แบบพลาดหนัก คนประเภท ‘Vibe Coders’ ต้องการเมนเทอร์สาย IT/Dev
ตัวอย่างเช่น มีศัลยแพทย์คนหนึ่งสร้างเว็บแอปสำหรับบันทึกการผ่าตัดด้วย Claude แล้วกังวลเรื่องความปลอดภัยจึงขอให้ผมช่วยตรวจ
ตัวโค้ดกับฐานข้อมูลโอเค แต่เขา zip ทั้งโปรเจกต์แล้วอัปขึ้นไปไว้ที่ web root โดยตรง และ ไม่มีไฟล์ index
เลยกลายเป็นว่าใครก็โหลดไฟล์สำรองได้ ซึ่งข้างในมีทั้ง DB, API key, AWS key และความลับทุกอย่าง
เขาไม่รู้ด้วยซ้ำว่าไฟล์ index มีไว้ทำไม สุดท้ายก็บอกว่าจะไปถาม Claude เรื่องวิธีทำให้ปลอดภัย
อีกไม่กี่เดือน script kiddies ก็คงใช้กันในวงกว้าง และอาจมีใครเอาไปทำ swatting จนมีคนบาดเจ็บหรือตายได้
ตอนนั้นคงน่าสนใจว่าประเด็นความรับผิดชอบจะถูกถกกันอย่างไร
ผมไม่เข้าพวกกับประโยคที่ว่า “วิศวกรส่วนใหญ่ชอบเขียนโค้ด”
ผมสนใจ การออกแบบและสร้างบางสิ่ง มากกว่าการนั่งเขียนโค้ด
สุดท้ายแล้วการเห็นด้วยหรือไม่กับ AI ก็เหมือนจะขึ้นอยู่กับว่า “คุณชอบการเขียนโค้ด” หรือ “คุณชอบสร้างผลิตภัณฑ์ให้โลก” มากกว่ากัน
แต่ AI ยังไปไม่ถึงจุดนั้น โค้ดจำนวนมากยังคอมไพล์ไม่ผ่าน และถ้ามันยังทำงานไม่ถูกต้อง การ optimize ก็ไม่มีความหมาย
หลายคอมเมนต์วิจารณ์ว่าบทความนี้เหมือน AI เขียน แต่ในมุมของผมที่เขียนโปรแกรมมากว่า 30 ปีและนำทีมมา 20 ปี ผมรู้สึกถึง อินไซต์ที่ลึกซึ้ง
ไม่ว่าใครจะเป็นคนเขียน ผมคิดว่าเนื้อหามีคุณค่า เลยแปลกใจที่มันถูก flagged
ตัวอย่างเช่น ประโยคอย่าง “สิ่งที่ผมได้เรียนรู้จากการบริหารทีมฟินเทค” ถ้าไม่ได้มาจากประสบการณ์จริงก็หมดความหมาย
แต่ถ้าเป็นประสบการณ์จริงที่เอา AI มาช่วยขัดเกลา ก็ไม่มีปัญหาอะไรเลย
วลีเชย ๆ อย่าง “AI เป็นสิ่งที่หลีกเลี่ยงไม่ได้” ไม่มี ปัญญา เหลืออยู่อีกแล้ว
ในยุค AI วิธีคิดแบบวิศวกรรม เปลี่ยนไป
เดิมทีเป็นการคิดเชิงลึกแบบแนวดิ่งที่เจาะลงไปในปัญหา แต่ตอนนี้ต้องใช้ การคิดเชิงแนวนอนและเชิงเมตา มากขึ้น
ตัวอย่างเช่น ตอนแรกผมกำลังอ่านเอกสารเพื่อปรับสภาพแวดล้อมของ Claude ให้เหมาะสม แต่พอให้บริบทของโปรเจกต์กับ Claude แล้วขอให้มัน optimize ให้
มันกลับเสนอและสร้างปลั๊กอินกับเอเจนต์ที่จำเป็นให้อัตโนมัติ
สุดท้ายสิ่งสำคัญไม่ใช่รายละเอียดการ implement แต่คือ ความสามารถในการกำหนดโครงสร้างของโปรเจกต์
แก่นของบทความนั้นถูกต้อง ระบบอัตโนมัติทำให้งานง่าย ๆ หายไปและบังคับให้เรา โฟกัสกับปัญหาที่ยากกว่าเดิม
ถ้ายกตัวอย่างเครื่องคิดเลข นักบัญชีที่เคยเก่งเรื่องการบวกเลข ตอนนี้ต้องไปจัดการกับปัญหาระดับที่สูงขึ้น
แต่สำหรับมือใหม่ การที่งานเขียนโค้ดหายไปอาจเป็นฝันร้ายก็ได้
ถ้าเทียบกับวงการวรรณกรรม AI ไม่ได้ช่วยสร้าง Terry Pratchett คนใหม่ให้เร็วขึ้น แต่มันทำให้เขาถูกกลบหายไป
ถ้าคุณแยกไม่ออกว่าโพสต์บล็อกไหนเขียนโดย AI คุณก็คงแยก โค้ดแย่ ๆ ไม่ออกเหมือนกัน
ผมแยกไม่ค่อยออกว่าบทความไหนเขียนโดย LLM หรือไม่ แต่ช่วงนี้เวลาอ่านอะไรแล้วรู้สึก เหนื่อยล้า มาก
คำมันเยอะเกินไป และสำหรับคนที่มีแนวโน้ม ADHD จะอ่านยากเป็นพิเศษ
บทความนี้ตาม ประวัติใน Pangram ถูกเขียนโดย AI 100%
ยังมี งานวิจัยที่ชี้ว่าการใช้ LLM ไม่ได้นำไปสู่ผลิตภาพที่สูงขึ้น
บทความประเภทนี้มักตั้งต้นจากสมมติฐานว่าประสิทธิผลนั้นมีอยู่จริง แต่ในโลกจริงความคาดหวังของผู้บริหารกับสภาพหน้างานไม่เหมือนกัน
หากมองจากมุมของวิศวกร ช่องว่างนั้นชัดเจนมาก