51 คะแนน โดย bboydart91 2026-02-19 | 14 ความคิดเห็น | แชร์ทาง WhatsApp

สรุปประเด็นสำคัญ

  • ภายใน 3 ปีหลังการมาของ ChatGPT หนึ่งวันทำงานของนักพัฒนากำลังย้ายจาก "การเขียนโค้ด" ไปเป็น "การตรวจทานผลลัพธ์จาก AI"
  • บทบาทของนักพัฒนาไม่ได้หายไป แต่ใกล้เคียงกับการย้ายจุดศูนย์ถ่วงจากผู้เขียนโค้ดไปเป็นผู้รีวิวและผู้อนุมัติ
  • AI ไม่ใช่นิติบุคคลทางกฎหมายและไม่สามารถรับผิดชอบได้ อีกทั้งกฎระเบียบอย่าง EU AI Act ก็กำลังเข้มงวดขึ้นในทิศทางที่ให้ความรับผิดตกอยู่กับมนุษย์
  • ความสามารถหลักที่ต้องการในยุค AI ไม่ใช่ทักษะการเขียนพรอมป์ต์ แต่คือการคาดการณ์ต้นทุนการเปลี่ยนแปลงระยะยาว การตัดสินใจเรื่อง abstraction และการถ่ายทอดความรู้โดยนัยออกมาเป็นภาษา ซึ่งโดยแก่นแล้วก็คือสิ่งเดียวกับที่นักพัฒนาที่ดีต้องมีอยู่แล้วในปัจจุบัน
  • หากอธิบายด้วยแนวคิด accidental complexity vs essential complexity ของ Fred Brooks สิ่งที่ AI แก้ได้มีเพียง accidental complexity เท่านั้น ส่วน essential complexity ของโดเมนยังคงต้องอาศัยการตัดสินใจของมนุษย์
  • อายุการใช้งานของความชำนาญด้านเครื่องมือ (เช่น prompt engineering) ผูกอยู่กับรอบการเปลี่ยนเครื่องมือ แต่ความสามารถในการตัดสินใจด้านการออกแบบและการถ่ายทอดความรู้โดยนัยจะยังใช้ได้ตราบเท่าที่ essential complexity ของซอฟต์แวร์ยังคงมีอยู่

สรุปแบบละเอียด

3 ปีหลัง ChatGPT

  • ตอนที่ ChatGPT ปรากฏตัวช่วงปลายปี 2022 ไม่มีใครคาดว่ามันจะพัฒนาเร็วขนาดนี้
  • คำจำกัดความเดิมของนักพัฒนาคือคนที่ทำครบทั้ง "วิเคราะห์ความต้องการจากภาษาธรรมชาติ → ออกแบบ → ลงมือพัฒนาเอง"
  • ปัจจุบัน เวลาส่วนใหญ่ในหนึ่งวันกลายเป็นการ "ส่งต่อบริบทให้ AI → อ่านโค้ดที่สร้างขึ้น แก้ไข และขอใหม่"
  • ตอนนี้ AI coding agent ก้าวพ้นระดับผู้ช่วยธรรมดาไปแล้ว และในระดับฟังก์ชันหรือโมดูลก็ยากจะแยกจากโค้ดที่มนุษย์เขียน

จากผู้เขียนไปเป็นผู้มีอำนาจตัดสินใจ

  • กิจกรรมการผลิตโค้ดกำลังย้ายจาก "การเขียนโค้ดเอง" ไปเป็น "การตัดสินใจเกี่ยวกับโค้ด"
  • คำว่า "การตัดสินใจ" ไม่ได้หมายถึงแค่ตรวจว่าเอาต์พุตจาก AI ตรงตามเจตนาหรือไม่ แต่หมายถึงการตรวจสอบว่าเจตนาทางธุรกิจถูกแปลเป็นการนำไปใช้ทางเทคนิคอย่างถูกต้องหรือไม่
  • คำถามสำคัญคือ "ถ้าโค้ดที่ AI เขียนทำให้เกิดบั๊กในระบบชำระเงิน ใครต้องรับผิดชอบ?"
  • เนื่องจาก AI ไม่ใช่นิติบุคคลทางกฎหมาย ผู้รับผิดชอบจึงคือนักพัฒนาและองค์กรที่รีวิวและอนุมัติโค้ดนั้น
  • EU AI Act ที่มีผลบังคับใช้ในปี 2024 กำหนดให้ระบบ AI ในพื้นที่เสี่ยงสูง เช่น การแพทย์ การเงิน และโครงสร้างพื้นฐาน ต้องมีการกำกับดูแลโดยมนุษย์
  • ความรับผิดชอบต่ออุบัติเหตุของรถยนต์ไร้คนขับตกอยู่กับผู้ผลิตและผู้ขับขี่, AI ทางการแพทย์ที่ผ่านการอนุมัติจาก FDA ก็ยังให้แพทย์เป็นผู้ตัดสินใจสุดท้าย, และกรณี Flash Crash ปี 2010 ก็มีผู้ดำเนินการอัลกอริทึมเป็นเป้าของการกำกับดูแล
  • ยิ่งระบบอัตโนมัติซับซ้อนขึ้น โครงสร้างความรับผิดไม่ได้พร่าเลือนลง แต่กลับยิ่งชัดเจนว่าตกอยู่ฝั่งมนุษย์

ความสามารถที่นักพัฒนาต้องมีในยุค AI

① ความสามารถในการคาดการณ์ต้นทุนการเปลี่ยนแปลงระยะยาว

  • AI ถูกปรับให้เหมาะกับการสร้าง "โค้ดที่ใช้งานได้" (โดยจำลองแพตเทิร์นที่พบบ่อยที่สุดจากข้อมูลฝึก)
  • โค้ดที่ใช้ได้ในตอนนี้ กับโค้ดที่ยังดูแลรักษาง่ายในอีก 6 เดือนข้างหน้า เป็นเรื่องที่ใช้เกณฑ์คนละชุดโดยสิ้นเชิง
  • ต้นทุนของการออกแบบที่แย่ไม่ได้เกิดขึ้นตอนเขียนโค้ด แต่เกิดตอนที่ต้องแก้ไขเปลี่ยนแปลง
  • บน LinkedIn มีโพสต์เพิ่มขึ้นเรื่อยๆ เช่น "ทำด้วย AI แต่ดูแลต่อยากเลยต้องจ้างนักพัฒนา" หรือ "ต่อยอดฟีเจอร์ไม่ได้จนต้องพับโปรเจกต์"

② ความสามารถในการประเมินโค้ดจากหลายมุม

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

③ ความสามารถด้าน abstraction

  • AI เองก็สามารถนิยามอินเทอร์เฟซ แยกคลาส และแยกโมดูลได้ และในเชิงรูปแบบก็ทำได้ดี
  • ความต่างที่ชี้ขาดคือ abstraction ของ AI ตั้งอยู่บนค่าเฉลี่ยเชิงสถิติ ส่วน abstraction ของนักพัฒนาที่ชำนาญคือการตัดสินใจเรื่อง trade-off ภายใต้ทรัพยากรที่จำกัดและอนาคตที่ไม่แน่นอน
  • จุดอันตรายของโค้ดที่ AI สร้างคือมันดูดีจากภายนอก — ไฟล์ถูกแยกอย่างเหมาะสม การตั้งชื่อเป็นไปตามธรรมเนียม และแพตเทิร์นก็คุ้นตา
  • ปัญหาจะโผล่มาเมื่อถึงเวลาต้องเปลี่ยนแปลง: "แค่อยากเพิ่มช่องทางชำระเงินอีกแบบเดียว แต่เพิ่งมารู้ว่าต้องแก้พร้อมกันหลายจุดในโครงสร้างที่ดูสะอาดนั้น"
  • ตัวอย่างฝั่งฟรอนต์เอนด์: AI อาจยัดทั้ง data fetching, state management และ UI rendering ไว้ในคอมโพเนนต์ยักษ์ตัวเดียว หรือในทางกลับกัน อาจสร้าง custom hook 3 ตัวพร้อม context provider สำหรับกราฟง่ายๆ แค่อันเดียว

④ ความสามารถในการทำให้ความรู้โดยนัยชัดเจนเป็นคำพูดได้

  • หากจะสั่ง AI ได้อย่างแม่นยำ ต้องสามารถเปลี่ยนสัญชาตญาณแบบ "มันดูแปลกๆ" ให้เป็นภาษาที่ชัดเจน เช่น "ฟังก์ชันนี้มีหน้าที่อยู่สองอย่าง"
  • สิ่งสำคัญไม่ใช่เทคนิคพรอมป์ต์เชิงรูปแบบอย่าง few-shot หรือ chain-of-thought แต่เป็นความสามารถในการนิยามให้ชัดว่าจะสร้างอะไร และตัดสินได้ว่าบริบทไหนสำคัญจนต้องส่งต่อ
  • อายุของความชำนาญด้านเครื่องมือ: ผูกกับรอบการเปลี่ยนเครื่องมือ (jQuery → React, Webpack → Vite)
  • อายุของความสามารถในการตัดสินใจด้านการออกแบบและการถ่ายทอดความรู้โดยนัย: ใช้ได้ตราบเท่าที่ essential complexity ของซอฟต์แวร์ยังคงมีอยู่

ความจำเป็นของการออกแบบการฝึกฝนอย่างตั้งใจ

  • แม้จะบอกว่า "ให้โฟกัสกับสิ่งที่เครื่องมือทำแทนไม่ได้" แต่สถานการณ์กลับยิ่งขัดแย้ง เพราะโอกาสในการฝึกสิ่งเหล่านั้นกลับลดลง

① สองจุดที่ไม่ควรยกให้ AI: การออกแบบและการรีวิว

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

② เวลาที่ตั้งใจลงมือเขียนเอง

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

③ ฝึกอธิบาย "ทำไม" ออกมาเป็นภาษา

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

สุดท้ายแล้ว แก่นของเรื่องไม่ได้เปลี่ยนไป

  • Fred Brooks (1986): accidental complexity (ข้อจำกัดของเครื่องมือ) vs essential complexity (สิ่งที่ฝังอยู่ในตัวปัญหาเอง)
  • สิ่งที่ AI แก้ได้คือ accidental complexity — boilerplate, แพตเทิร์นซ้ำๆ, ข้อผิดพลาดทางไวยากรณ์
  • essential complexity (ความกำกวมของข้อกำหนดทางธุรกิจ, การหาสมดุลระหว่างเป้าหมายการออกแบบที่ขัดกัน, ความไม่แน่นอนของการเปลี่ยนแปลงในอนาคต) จะไม่หายไปแม้ AI จะพัฒนาไปมากกว่านี้
  • ตราบใดที่มนุษย์ยังคงเป็นผู้ตัดสินใจและผู้รับผิดชอบ แก่นของความสามารถที่จำเป็นต่อการตัดสินใจก็จะไม่เปลี่ยน
  • ยิ่งการผลิตโค้ดเป็นอัตโนมัติมากเท่าไร น้ำหนักของวิจารณญาณในการตรวจสอบผลผลิตก็จะยิ่งเด่นชัดขึ้นเท่านั้น

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

 
bboydart91 2026-02-19

ขอบคุณสำหรับความคิดเห็นดี ๆ ทุกท่านครับ!

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

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

 
moregeek 2026-02-19

เห็นด้วยเช่นกันครับ อ่านได้ดีมากครับ

 
apkas 2026-02-19

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

 
mhj5730 2026-02-19

ในมุมของคนที่ใช้ AI ในงานจริง คำว่า การพัฒนาโดย AI -> การกำกับดูแลผลลัพธ์จาก AI นั้นโดนใจมากจริงๆ
และ AI ก็กำลังช่วยได้มากในการคลี่คลายความซับซ้อนที่เป็นแก่นแท้ด้วยเช่นกัน [ตรวจสอบความขัดแย้งระหว่างวิเคราะห์ความต้องการ, ตรวจสอบความซ้ำซ้อน, ตั้งคำถามถึงคุณค่าที่เป็นแก่นแท้]

 
cocofather 2026-02-19

ควรมีคนที่ศรัทธา AI แบบสุดโต่งเพิ่มขึ้นอีก

 
moregeek 2026-02-20

เหตุผลคืออะไรครับ?

 
armila 2026-02-19

นี่ก็น่าจะเป็นเพียงช่วงเปลี่ยนผ่านเหมือนกันนะ
เพราะแม้แต่ในบรรดาผู้จัดการทีมฟุตบอลชื่อดัง ก็มีหลายคนที่ไม่ได้มาจากการเป็นนักเตะมาก่อน

 
moregeek 2026-02-19

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

 
tested 2026-02-20

แต่พอพูดถึงฟุตบอล ก็ทำให้นึกถึงชุง มง-กยูขึ้นมาเลยครับ

 
tested 2026-02-20

เพราะพวกเขามีคุณสมบัติมากพอที่จะเป็นโค้ชฟุตบอลได้แม้จะไม่ใช่อดีตนักกีฬาอาชีพ และคนที่สามารถรับผิดชอบต่อผลการแข่งขันได้ก็ควรเป็นคนคุมทีม

 
chshin84 2026-02-20

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

 
dohyun682 2026-02-19

ฉันก็เห็นด้วยครับ
ช่วงนี้พอดูแนวทางแบบ Harness หรือ Loop แล้ว เหมือนคนแค่ให้สเปก ส่วนรีวิวหรือแม้แต่ QA ก็ไปในทิศทางที่ให้ AI จัดการกันเองแล้ว

 
gcback 2026-02-19

เห็นด้วยครับ

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

ไม่ว่าจะเป็นคนหรือ AI นี่คือเกมที่ฝ่ายซึ่งมีความผิดพลาดน้อยกว่าในเชิงสถิติเป็นผู้ชนะ

 
github88 2026-02-19

ทำให้การกำกับดูแลเป็นประชาธิปไตยงั้นเหรอ? 555 ก็เพราะมีคุณสมบัติถึงได้เป็นผู้กำกับ ไม่ใช่ว่าไม่มีคุณสมบัติแล้วยังจะมาเป็นผู้กำกับได้