บทสนทนาว่าด้วยการเปลี่ยนแปลงเชิงแก่นของบทบาทนักพัฒนาระดับซีเนียร์ในยุค AI ซึ่ง Addy Osmani ผู้อำนวยการฝ่าย AI ของ Google Cloud และอดีตผู้นำฝ่ายวิศวกรรม Chrome เปิดเผยไว้ในการสัมภาษณ์ที่งานประชุม JS Nation US ปี 2026 (นิวยอร์ก) Osmani เป็นผู้เขียนหนังสือเทคนิค 14–15 เล่ม เช่น Learning JavaScript Design Patterns, Leading Effective Engineering Teams และยังชี้ข้อจำกัดเชิงปฏิบัติของการเขียนโค้ดด้วย AI มาอย่างต่อเนื่องผ่านบรรยายปี 2025 เรื่อง "The AI-Native Software Engineer" และซีรีส์ "70% problem", "80% problem" บน Substack บทสัมภาษณ์ครั้งนี้จึงเป็นส่วนต่อเนื่องที่อธิบายอย่างรอบด้านถึงปรากฏการณ์ที่วิศวกรระดับซีเนียร์กำลังเปลี่ยนจากผู้เขียนโค้ดไปเป็นผู้แก้ไขโค้ด (Editor)
ภูมิทัศน์หลังผ่านยุค AI coding มา 1 ปี
- นักพัฒนา 90% ใช้ AI ในการเขียนโค้ด แต่ความเชื่อมั่นกลับมีแนวโน้มลดลง
- มีประสิทธิภาพกับโปรเจกต์ใหม่หรือต้นแบบ (MVP) แต่ใน codebase ขนาดใหญ่หรือสภาพแวดล้อมระดับองค์กร ช่องว่างยังชัดเจน
- ขนาดของ PR (pull request) เพิ่มขึ้นมาก และมักพบว่า AI ไปแตะไฟล์เกินความจำเป็น หรือไม่รีใช้ utility function เดิมแล้วเขียนใหม่
- ปรากฏการณ์ที่ Osmani เคยเรียกว่า "70% problem" ในบทความก่อนหน้ายังใช้ได้อยู่ AI พาไปได้ถึง 70% แต่คุณภาพ ความสอดคล้อง และ last mile ที่เหลืออีก 30% ยังเป็นหน้าที่ของมนุษย์
Vibe Coding vs AI-assisted engineering
- Vibe Coding คือแนวทางอิสระที่ใช้สำรวจความเป็นไปได้ของไอเดียอย่างรวดเร็ว และไม่ได้ใส่ใจกับ code review มากนัก
- AI-assisted engineering คือการใช้ AI เป็นเครื่องมือโดยยังรักษาหลักวิศวกรรมแบบดั้งเดิมไว้ ทั้งด้านสถาปัตยกรรม ความปลอดภัย ประสิทธิภาพ และคุณภาพ
- สำหรับ production code วิธีหลังเป็นสิ่งจำเป็น และในจุดนี้ "context engineering" (เทคนิคการให้บริบทอย่างเข้มข้นแก่โมเดล เช่น เอกสาร ตัวอย่าง ประวัติการสนทนา โครงสร้าง codebase ฯลฯ) เป็นตัวกำหนดคุณภาพของผลลัพธ์
บทบาทใหม่ของวิศวกรซีเนียร์: code editor
- บทบาทหลักของนักพัฒนากำลังย้ายจากผู้เขียนโค้ดไปเป็นผู้ประเมินและแก้ไขโค้ด นี่คือความหมายของคำว่า "highly-paid Code Editors" ตามที่พาดหัวสื่อไว้
- code review กำลังกลายเป็นสนามหลักของการสอนนักพัฒนาจูเนียร์ และการคิดเชิงวิพากษ์เพื่อถามว่า "ทำไม AI ถึงเลือกแนวทางนี้" สำคัญกว่าที่เคย
- งานวิจัยชิ้นหนึ่งระบุว่าวิศวกรใช้เวลามากในการดีบักโค้ดจาก AI ที่ "ดูเหมือนถูก แต่จริงๆ ผิด" และ Osmani เคยขยายแนวคิดนี้ต่อในบทความถัดไปด้วยคำว่า "comprehension debt"
การใช้งาน background agent ในภาคปฏิบัติ
- Osmani เล่าว่าเวลาระหว่างเดินเล่น เขาจะมอบหมายงาน 3–4 อย่างให้เอเจนต์ผ่านแอป GitHub แล้วได้ PR กลับมาเมื่อเดินกลับถึงบ้าน คำพูดที่น่าสนใจคือ "ผมไม่ได้ต้องการ issue แต่ต้องการ PR"
- เขาจำกัดการใช้งานไว้กับโปรเจกต์ขนาดเล็กถึงกลาง และยังไม่แนะนำสำหรับองค์กรขนาดใหญ่
- เขาใช้อุปมาเปรียบเทียบว่ากำลังเปลี่ยนจากขั้น "conductor" ที่ใช้เอเจนต์ตัวเดียว ไปสู่ขั้น "orchestrator" ที่จัดการหลายเอเจนต์พร้อมกัน
Chrome DevTools MCP และ Figma MCP
- Chrome DevTools MCP (Model Context Protocol) ที่เปิดตัวช่วงปลายปี 2025 ช่วยมอบ "ดวงตา" ให้ coding agent ทำให้เอเจนต์ตรวจดูผลการเรนเดอร์จริง และใช้ข้อมูลจาก console log กับ network ได้
- เมื่อใช้ร่วมกับ Figma MCP ก็สามารถทำเวิร์กโฟลว์ที่นำไฟล์ดีไซน์ไปลงมือทำ แล้วตรวจสอบหน้าจอจริงได้ แต่ยังไปไม่ถึงระดับที่รีใช้ UI component library เดิมแบบอัตโนมัติ
อนาคตของ Browser AI และปัญหาเรื่องความไว้วางใจ
- ขั้นต่อไปคือการทำให้เส้นทางการใช้งานของผู้ใช้เป็นอัตโนมัติด้วยบริบทมหาศาลที่เบราว์เซอร์มีอยู่แล้ว (ข้อมูลล็อกอิน ปฏิทิน ประวัติการค้นหา ฯลฯ) แต่หัวใจสำคัญคือการออกแบบความไว้วางใจให้ยังมีการยืนยันจากมนุษย์ในจุดที่เกี่ยวข้องกับการชำระเงินหรือข้อมูลส่วนบุคคล
- Osmani เน้นว่า "ไม่ใช่การอัตโนมัติ 100% แต่ต้องหยุดให้แน่ใจในจุดที่ผู้ใช้อาจเลิกคิ้วสงสัย"
คำแนะนำสำหรับนักพัฒนาจูเนียร์
- หากสามารถสร้างความเชี่ยวชาญเชิงลึกในพื้นที่ที่ AI ยังแก้ไม่ได้ ก็อาจกลายเป็นโอกาสในการสร้างความแตกต่าง
- ต่อมุมมองสุดโต่งที่ว่า programming language หรือ stack จะหมดความหมาย Osmani โต้ว่า "การเข้าใจพื้นฐานและ fundamentals ยังคงเป็น superpower"
ประเด็นชวนคิด
- ข้อความหลักของบทสนทนานี้ชัดเจนมาก ในยุคที่ AI เขียนโค้ดแทนได้ มูลค่าของวิศวกรซีเนียร์ไม่ได้อยู่ที่ความเร็วในการพิมพ์โค้ด แต่อยู่ที่ความสามารถในการอ่าน ตัดสิน และใส่บริบทให้โค้ด คำว่า "บรรณาธิการโค้ดค่าตัวสูง" ที่ฟังดูยั่วยุจึงไม่ได้เป็นคำดูแคลน แต่สะท้อนอย่างย้อนแย้งว่านี่คือความสามารถแกนหลักที่ยุคนี้ต้องการ
- เช่นเดียวกับที่ Osmani ขยับตัวเลขจาก 70% ไปเป็น 80% ความสมบูรณ์ของเอเจนต์ดีขึ้นอย่างชัดเจน แต่ต้นทุนในการจัดการ "comprehension debt" เพื่อปิดช่องว่างอีก 20–30% ยังไม่ลดลง และการลดช่องว่างนี้จะยังเป็นโจทย์ร่วมของทั้งเครื่องมือและวิศวกรต่อไป
1 ความคิดเห็น
โปรแกรมเมอร์ระดับซีเนียร์ดูจะเป็นโมเดลด้านการออกแบบที่เหนือกว่า opus นะ 555