แนวคิด Value Over Replacement ใช้วัดคุณค่าวิศวกรจากส่วนต่างของผลงานเมื่อเทียบกับคนที่จะมาทำงานแทน แต่ตอนนี้เกณฑ์เปรียบเทียบกำลังเปลี่ยนไป แนวคิดนี้เสนอไว้ตั้งแต่ปี 2025 ว่าเวลาวัดคุณค่าของวิศวกร อย่าดูแค่ว่าโปรเจกต์นั้นทำเงินให้บริษัทได้เท่าไร แต่ให้ดูว่าเราทำงานได้ดีกว่าวิศวกรทั่วไปในตำแหน่งเดียวกันมากแค่ไหน

ล่าสุด Sean Goedecke เจ้าของบทความต้นทางและผู้เสนอกรอบคิดนี้ บอกว่าสิ่งที่เรานำมาใช้เปรียบเทียบเปลี่ยนไปแล้ว ตอนนี้เราไม่ได้เทียบกับเพื่อนร่วมตำแหน่งอีกต่อไป แต่กำลังเทียบกับโมเดล AI อย่าง GPT-5.6-Sol หรือ Claude Opus 5

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

ปฏิเสธว่าโมเดลเขียนโค้ดไม่ได้ ไม่ได้ช่วยให้เราปลอดภัยขึ้น

บทความต้นทางปัดคำปลอบใจ 2 แบบทิ้งไปตั้งแต่ต้น: แบบแรกคือ "โมเดลพวกนี้เขียนโค้ดไม่ได้จริงหรอก ทั้งหมดเป็นแค่เรื่องการตลาด" แบบที่สองคือ "โค้ดที่ AI เขียนมีแต่ปัญหา เดี๋ยวปีหน้าบริษัทที่ใช้ก็พังกันหมด"

เขาบอกตรงๆ ว่า พอถึงปี 2027 เราจะไม่มีทางพบว่ากระแส AI จบลงจนทุกคนต้องกลับมานั่งพิมพ์โค้ดเองเหมือนเดิม

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

หนีไปทำงานที่ยากขึ้น ก็ไม่ใช่ทางรอดระยะยาว

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

หลักฐานที่เขายกมาคือ งานวิจัยของห้องแล็บ AI อย่าง Anthropic ที่โมเดลสามารถช่วยหาขอบล่างที่ดีกว่าเดิมของโจทย์คณิตศาสตร์ระดับโลกอย่าง Riemann hypothesis ถ้าโมเดลไปถึงระดับนั้นได้ การเขียนโปรแกรมควบคุมอย่างไดรเวอร์ หรือชุดคำสั่งกราฟิกอย่าง GPU shader ก็คงทำได้ตามมาในเวลาไม่นาน ความยากทางเทคนิคจึงช่วยยื้อเวลาได้แค่ชั่วคราว ไม่ได้ทำให้เรามีที่ยืนถาวร

สิ่งที่เขาเสนอให้มองแทน คือการเน้นไปที่งานอีก 2 ประเภท นั่นคือ งานที่โมเดลแทบไม่เก่งขึ้นเลยตลอดหลายปีที่ผ่านมา และงานที่โดยธรรมชาติแล้วพัฒนาให้เก่งขึ้นได้ยาก ตัวอย่างที่ชัดเจนที่สุดของงาน 2 ข้อนี้คือ ความคุ้นเคยกับ codebase ในระดับลึก และ การสื่อสารเชิงเทคนิค

โมเดลไม่ได้พลาดเพราะไม่ฉลาด แต่พลาดเพราะไม่รู้จักระบบของเรา

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

1. ผิดพลาดเพราะไม่รู้บริบท: เช่น เขียน logic ขึ้นมาใหม่ทั้งที่ในโปรเจกต์มีโมดูลที่ทำเรื่องนั้นอยู่แล้ว แก้โค้ดผิดระบบเพราะไม่รู้ว่าทีมจัดการเรื่องนี้ไว้ที่ไหน หรือเขียนโค้ดด้วยสไตล์ที่ไม่ตรงกับมาตรฐานที่ทีมใช้กันมาตลอด

2. ผิดพลาดเพราะระแวงเกินไป: AI มักจะเขียนโค้ดดักความเสี่ยงมากเกินความจำเป็น เช่น เช็กค่าเดิมซ้ำซ้อนถึง 3 ชั้น ทั้งที่ในทางปฏิบัติ ค่านั้นตั้งจากไฟล์ตั้งค่าครั้งเดียวแล้วแทบไม่เคยอัปเดตอีกเลย มองว่าความล่าช้าเพียง 10 มิลลิวินาทีเป็นเรื่องที่รับไม่ได้ จนออกแบบระบบซับซ้อนมาคอยอัปเดตข้อมูลให้สดตลอดเวลา หรือใส่โค้ดดักจับข้อผิดพลาดวุ่นวายให้กับเครื่องมือ command-line ที่ความจริงถ้าเจอปัญหาก็ควรปล่อยให้โปรแกรมหยุดทำงานไปเลย ทีมจะได้รู้ตัวทันที

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

ข้อจำกัดนี้เกิดจากลักษณะการทำงานของ agent เอง ทางแก้ที่เขามองว่าพอจะเป็นไปได้ คือทำให้โมเดลเรียนรู้ต่อเนื่องจากงานที่ทำได้ หรือขยาย context window ซึ่งเป็นหน่วยความจำที่โมเดลอ่านข้อมูลได้พร้อมกันให้ใหญ่ขึ้นมากๆ ตราบใดที่ยังไม่มีใครทำสองอย่างนั้นสำเร็จ โมเดลก็จะยังคงผิดพลาดในลักษณะเดิมต่อไป

ส่วนที่ยากกว่าคือการกล้าคัดค้าน AI

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

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

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

โมเดลเขียนโค้ดเก่งขึ้น แต่เขียนอธิบายแย่ลง

ช่องว่างที่สองฟังดูขัดความรู้สึกกว่าเดิม คือโมเดลรุ่นใหม่ๆ เขียนโค้ดเก่งขึ้นเรื่อยๆ แต่กลับเขียนอธิบายให้คนเข้าใจได้แย่ลง ในยุค GPT-3.5 และ GPT-4 ภาษายังเป็นธรรมชาติเหมือนคนเขียน แต่พอมาถึง GPT-4o สำนวนประดิษฐ์กลวงๆ ที่เรียกกันว่า slop ก็เริ่มชัดเจนขึ้น ส่วนโมเดลรุ่นใหม่ของ Anthropic ก็พูดภาษาที่มีคนตั้งชื่อให้ว่า Claudish ซึ่งเป็นสำนวนที่ทั้งประดิษฐ์คำเกินพอดี และตัดทอนคำจนห้วนสั้นอยู่ในประโยคเดียวกัน

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

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

Claudish อาจเกิดจากการถ่ายทอดกระบวนการคิดของโมเดลแบบตรงตัว

เขาเสนอคำอธิบายที่น่าสนใจว่า ถ้าเราเข้าไปดู reasoning token ซึ่งเป็นข้อความในกระบวนการคิดที่โมเดลใช้คุยกับตัวเองก่อนตอบ จะเห็นว่ามันเลือกใช้คำแปลกๆ และละโครงสร้างทางไวยากรณ์จนประโยคห้วน ดังตัวอย่างที่หลุดออกมาจากหน้าเว็บของโมเดล:

RESOLUTION: charge the current-leg's OWN saved-prefix occupancy EAGERLY: when leg i saves e1..et: ALSO commit their occupancy AT LEG i

พอเอาข้อความนี้มาเรียบเรียงใหม่ให้เป็นภาษาอังกฤษที่ถูกหลักไวยากรณ์ จะได้ประมาณนี้:

Charge the current-leg's saved-prefix occupancy on a clean, eager path: when leg i saves e1..et, commit the occupancy at leg i.

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

นี่คือเหตุผลที่ การสื่อสารเชิงเทคนิค อาจเป็นทักษะที่อยู่ได้นานกว่าที่คิด เหมือนในนิยายไซไฟเรื่อง Blindsight ของ Peter Watts ที่โลกเต็มไปด้วยมนุษย์ที่ผ่านการดัดแปลงสมองจนฉลาดล้ำ โดยมีตัวเอกทำอาชีพ Synthesist ทำหน้าที่เป็นตัวกลางคอยแปลสิ่งที่พวกอัจฉริยะคิดผ่านคำย่อและท่าทาง ให้คนธรรมดาทั่วไปเข้าใจได้ ต่อให้เรามีระบบหรือเครื่องมือที่ฉลาดแค่ไหน เราก็ยังต้องการคนที่เข้าใจบริบทและสามารถแปลความคิดเหล่านั้นออกมาให้คนอื่นเข้าใจได้อยู่ดี

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

อย่าเป็นแค่ meat proxy

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

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

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

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

ที่มา: บทความ You have to beat the models at something จาก seangoedecke.com