- ตั้งแต่ NoCode ไปจนถึง AI เทคโนโลยีที่อ้างว่าจะมาแทนนักพัฒนาเกิดขึ้นซ้ำแล้วซ้ำเล่า แต่ในความเป็นจริงคือ บทบาทเปลี่ยนรูปไปตามการเปลี่ยนแปลงของเทคโนโลยี
- NoCode ไม่ได้ทำให้นักพัฒนาหายไป แต่กลับทำให้เกิด ผู้เชี่ยวชาญ NoCode และผู้เชี่ยวชาญด้านการบูรณาการระบบ ขณะที่คลาวด์ก็สร้างสายงานระดับสูงอย่าง วิศวกร DevOps ขึ้นมา
- ปัจจุบันเครื่องมือพัฒนา AI ก็กำลังเดินตามเส้นทางเดียวกัน และแม้จะเข้าสู่ยุคที่ AI เขียนโค้ดได้ ความสามารถในการ ออกแบบสถาปัตยกรรมระบบ ก็ยังคงเป็นแกนหลัก
- AI ทำงานด้านการเพิ่มประสิทธิภาพเฉพาะจุดได้ดี แต่ยังอ่อนด้านการออกแบบทั้งระบบ และ ความเร็วในการสร้างที่สูงอาจทำให้ความผิดพลาดเชิงโครงสร้างถูกตรึงไว้ได้อย่างรวดเร็ว
- การแทนที่นักพัฒนาในท้ายที่สุดจึงเป็นเพียง วิวัฒนาการและการยกระดับตามการเปลี่ยนแปลงของเทคโนโลยีสแต็ก ไม่ใช่การหายไปของบทบาทโดยสิ้นเชิง
From NoCode to AI-Assisted
- ทุก ๆ ไม่กี่ปี จะมี เทคโนโลยีใหม่ที่อ้างว่าจะมาแทนนักพัฒนาซอฟต์แวร์ ปรากฏขึ้น
- พาดหัวทำนองเดียวกันอย่าง “จุดจบของการเขียนโค้ด”, “จากนี้ใคร ๆ ก็สร้างแอปได้”, “แม้แต่เด็กก็เขียนโค้ดได้” ถูกผลิตซ้ำพร้อม ความคาดหวังที่เกินจริง
- ผู้บริหารและที่ปรึกษาต่างจับตากระแสนี้ และเห็นการโยกย้ายของงบประมาณตามมา
- แต่ในความเป็นจริง สิ่งที่เกิดขึ้นไม่เคยเป็น “การแทนที่” หากเป็น “การเปลี่ยนรูป”
- มีทั้ง บทบาทใหม่ และ วิชาชีพเฉพาะทางที่ยกระดับขึ้น เกิดขึ้นเพื่อรับมือกับเทคโนโลยีที่ซับซ้อนขึ้น และมีแนวโน้มว่า ระดับค่าจ้างก็สูงขึ้น ซ้ำแล้วซ้ำเล่า
- NoCode สร้าง ความคาดหวังว่าสามารถสร้างแอปได้โดยไม่ต้องมีผู้เชี่ยวชาญ แต่สุดท้ายก็ยังมี ปัญหาซับซ้อนอย่างการทำ data modeling, การบูรณาการระบบ, การบำรุงรักษา ซึ่งนำไปสู่การเกิดขึ้นของ สายงานใหม่ เพื่อแก้ปัญหาเหล่านี้
- คลาวด์ทำให้หลายคนเชื่อว่าสามารถดำเนินงานได้โดยไม่ต้องมีผู้ดูแลระบบ แต่ในความจริงกลับต้องการ ความเชี่ยวชาญระดับสูงแบบวิศวกร DevOps และค่าตอบแทนก็สูงขึ้น
- AI ก็เช่นกัน แม้จะดูเหมือนว่า “AI จะเขียนโค้ดแทนได้” แต่ในทางปฏิบัติ ความสำคัญของ นักพัฒนาที่มีทักษะในการจัดการและ orchestrate AI กลับยิ่งเพิ่มขึ้น
ม้าหมุนแห่งคำสัญญาเรื่องการแทนที่ที่วนไม่รู้จบ (The Endless Carousel of Replacement Promises)
การปฏิวัติ NoCode/LowCode
- นวัตกรรม NoCode/LowCode ปรากฏขึ้นพร้อมคำสัญญาว่าทุกคนจะสร้างแอปได้ด้วยอินเทอร์เฟซที่ใช้งานง่าย
- แต่ในภาคสนามจริงกลับเกิด ปัญหาใหม่ เช่น การออกแบบ data model, การบูรณาการกับระบบและฐานข้อมูลเดิม, การจัดการกรณียกเว้น, และการบำรุงรักษา
- ด้วยเหตุนี้ จึงต้องการไม่ใช่นักพัฒนาแบบทั่วไป แต่เป็น ผู้เชี่ยวชาญ NoCode ที่เข้าใจทั้งความรู้เชิงโดเมนและข้อจำกัดทางเทคนิคพร้อมกัน
- คนกลุ่มนี้ได้รับ เงินเดือนสูงกว่า นักพัฒนาแบบเดิม
การปฏิวัติคลาวด์
- ครั้งหนึ่งมีความคาดหวังสูงว่าเมื่อย้ายขึ้นคลาวด์แล้วจะไม่ต้องมีผู้ดูแลระบบอีกต่อไป
- แต่ในความเป็นจริง ความเชี่ยวชาญด้านการจัดการคลาวด์ และ ความซับซ้อน กลับเพิ่มขึ้น
- ผู้ดูแลระบบแบบเดิมเปลี่ยนบทบาทเป็น วิศวกร DevOps ที่ได้รับค่าตอบแทนสูงขึ้น และระดับงานก็ยกระดับไปสู่ การทำ infrastructure automation, deployment pipeline, และการจัดการระบบกระจาย
- งานไม่ได้หายไป แต่พัฒนาไปเป็นรูปแบบงานใหม่
- แม้แต่การเปลี่ยนไปสู่ microservices ก็เพิ่มความซับซ้อน และท้ายที่สุดก็ยืนยันว่า บทบาทของผู้เชี่ยวชาญที่ดูแลระบบในระดับรากฐาน ยังคงสำคัญ
กระแสการพัฒนาแบบออฟชอร์ (Offshore)
- แม้จะเกิดความเชื่อว่าสามารถลดต้นทุนได้ผ่านการจ้างงานจากต่างประเทศ แต่ก็เกิดปัญหาจาก การสื่อสาร คุณภาพที่ลดลง และการขาดความเข้าใจโดเมน
- สุดท้ายกลยุทธ์จึงเปลี่ยนไปสู่ โครงสร้างทีมแบบกระจาย การกำหนด ownership ให้ชัดเจน และสถาปัตยกรรมที่แข็งแรง ส่งผลให้ต้นทุนรวมสูงกว่าที่คาดไว้ในตอนแรก
การปฏิวัติผู้ช่วยเขียนโค้ดด้วย AI
- ตอนนี้คำสัญญาที่เป็นประเด็นร้อนคือ AI จะสร้างโค้ดให้อัตโนมัติ
- ในความเป็นจริงช่วงแรก โค้ดที่ AI สร้างขึ้นมักแฝง ข้อผิดพลาดที่ละเอียดอ่อนและปัญหาความสอดคล้อง
- วิศวกรอาวุโสต้องใช้เวลามากในการตรวจทานและแก้ไขผลลัพธ์จาก AI และยิ่งเป็นนักพัฒนาที่มีประสบการณ์มากก็ยิ่งสร้างมูลค่าได้มากกว่าเดิม
- ระบบที่สร้างขึ้นโดยพึ่งพา AI เป็นหลักเพียงอย่างเดียว มัก ขาดสถาปัตยกรรมที่เป็นระบบ
- กล่าวคือ เทคโนโลยีไม่ได้มาแทนผู้เชี่ยวชาญ แต่ยกระดับความเชี่ยวชาญของพวกเขาไปสู่ชั้นนามธรรมที่สูงขึ้น
เหตุใดรอบนี้จึงพิเศษ
- แก่นสำคัญที่ผู้คนมักมองข้ามคือ โค้ดไม่ใช่สินทรัพย์ แต่เป็นหนี้สิน
- ยิ่งสร้างโค้ดได้เร็วและง่ายเท่าไร ภาระด้านการบำรุงรักษา ความปลอดภัย และการรีแฟกเตอร์ ก็ยิ่งมากขึ้นเท่านั้น
- AI อาจ เพิ่มประสิทธิภาพในระดับฟังก์ชัน ได้ แต่ยัง ขาดความสามารถในการออกแบบทั้งระบบ
- ยิ่งความเร็วในการพัฒนาสูงขึ้น ก็ยิ่งมี ความเสี่ยงที่ความผิดพลาดเชิงโครงสร้างจะถูกตรึงไว้รวดเร็วขึ้น
- ท้ายที่สุดแล้ว แม้ในยุค AI สินทรัพย์ที่แท้จริงก็คือความสามารถในการออกแบบสถาปัตยกรรมระบบ และนี่คือสิ่งที่ควรถูก เสริมพลัง ไม่ใช่ถูกแทนที่
- คำกล่าวที่ว่า "AI จะมาแทนนักพัฒนา" เกิดจากความเข้าใจผิดพื้นฐานดังต่อไปนี้
- ความจริงที่ว่า โค้ดไม่ใช่สินทรัพย์ แต่เป็นหนี้สิน
- โค้ดต้องการ การบำรุงรักษา การตรวจสอบ การจัดการความปลอดภัย และการเปลี่ยนทดแทน อย่างต่อเนื่อง และยิ่งมีจำนวนบรรทัดมาก หนี้สินก็ยิ่งเพิ่มขึ้น
- การที่ AI สร้างโค้ดได้เร็ว หมายถึงเพียงการสร้างหนี้สินได้เร็วขึ้นเท่านั้น
- กล่าวอีกอย่างคือ AI ทำ local optimization ได้ดีในระดับฟังก์ชันหรือฟีเจอร์ย่อย แต่ยังอ่อนด้าน การออกแบบเชิงภาพรวมและการตัดสินใจด้านสถาปัตยกรรม
- ยิ่งความเร็วในการลงมือพัฒนาสูงขึ้น ความเสี่ยงที่การออกแบบที่ผิดจะ 'แข็งตัว' ไปทั่วทั้งระบบ ก็ยิ่งมากขึ้น
- สำหรับการทำเว็บหรือไซต์ระยะสั้นแบบครั้งเดียวอาจไม่ใช่ปัญหา แต่สำหรับระบบที่ต้องเติบโตระยะยาว นี่คือจุดที่อันตรายอย่างยิ่ง
- รูปแบบของนวัตกรรมเทคโนโลยียังคงเหมือนเดิมไม่เปลี่ยน
- ผู้ดูแลระบบกลายเป็นวิศวกร DevOps และนักพัฒนาแบ็กเอนด์กลายเป็นสถาปนิกคลาวด์
- แต่ AI เร่งทุกอย่างให้เร็วขึ้น ทักษะที่ทำให้รอดและเติบโตต่อไปได้ไม่ใช่การเขียนโค้ด
- แต่มันคือ การออกแบบระบบ (Architecting systems). นั่นคือสิ่งเดียวที่ AI ยังทำไม่ได้
19 ความคิดเห็น
ผมเป็นคนทำงานค่อนข้างอนุรักษ์นิยม เลยยังไม่เคยนำเครื่องมือ AI มาใช้กับงานสำคัญจริงจัง มีแค่เปลี่ยนจากการค้นหาใน Google หรือ Stack Overflow ไปถาม Gemini หรือ ChatGPT แทนประมาณนั้น? ก็ใช้อยู่เหมือนกัน...
เวลาขอให้ AI สร้างอะไรสักอย่าง ผมคิดว่าถ้าใช้แบบให้มันทำในระดับฟังก์ชัน เช่น ขอให้สร้างฟังก์ชันที่รับอินพุตแบบนี้แล้วคืนค่าแบบนั้น แล้วเราค่อยเขียนลอจิกสำหรับตรวจสอบเองว่าค่าที่รีเทิร์นจากฟังก์ชันที่ AI สร้างมาถูกต้องไหม แบบนี้ก็น่าจะโอเคนะครับ
ผมค่อนข้างสงสัยกับคำถามที่ว่า เราจะจัดระเบียบบริบททั้งหมดให้อยู่ในรูปแบบที่ AI เข้าใจได้ดีจริง ๆ หรือไม่ มนุษย์ไม่ได้มีแค่บริบทที่จำเป็นอย่างผิวเผินต่อการพัฒนาในตอนนี้เท่านั้น แต่ยังมีบริบทแฝงอยู่ด้วย และเราก็พัฒนาโดยคำนึงถึงส่วนเหล่านั้นไปพร้อมกัน ซึ่งผมยังไม่คิดว่ามนุษย์จะสามารถเขียนบริบทเหล่านี้ออกมาเป็นถ้อยคำที่ผ่านการขัดเกลาอย่างดีได้ นี่อาจไม่ใช่ปัญหาของ AI แต่เป็นข้อจำกัดของมนุษย์มากกว่า โดยเฉพาะอย่างยิ่ง ผมยังคิดว่าทักษะการเขียนของผู้คนในปัจจุบันก็ไม่ได้ดีนักด้วย
สิ่งที่น่ากลัวไม่ใช่ตอนนี้ในขณะนี้ แต่ดูเหมือนว่าจะเป็นแนวโน้มมากกว่าครับ..
ตอนนี้แตกต่างไปโดยสิ้นเชิง
อนาคตที่ทุกอาชีพจะถูกแทนที่กำลังอยู่ตรงหน้า และนักพัฒนาก็เป็นเพียงหนึ่งในนั้น
เรื่องแบบนี้ไม่เคยเป็นกระแสเลยแม้แต่ครั้งเดียว
คงไม่มีการเปลี่ยนแปลงไหนที่เหมือนเดิมทุกอย่างแบบเป๊ะ ๆ หรอกครับ。
แต่นี่คือการเปลี่ยนแปลงที่หลายอาชีพเคยผ่านมาก่อนแล้วตั้งแต่ยุคสมัยใหม่เมื่อนานมาแล้ว ตัวอย่างเช่น ศิลปินได้รับผลกระทบจากการมาถึงของการถ่ายภาพ และช่างฝีมือได้รับผลกระทบจากโรงงานอัตโนมัติ การเขียนโค้ดก็ดูไม่ได้แตกต่างกันนัก
ผมคาดว่าเมื่อการสร้างนวัตกรรมกลายเป็นเรื่องปกติ ในท้ายที่สุดเราจะต้องการวิศวกรมากกว่าตอนนี้เสียอีก เพราะมาตรฐานความคาดหวังของผู้ใช้จะสูงขึ้น และเราจะต้องสร้างสิ่งที่ใหญ่และซับซ้อนกว่าเดิม ราวกับที่สมมติฐานราชินีแดงพูดไว้
แน่นอนว่ามีความเป็นไปได้สูงที่ประเภทของงานจะเปลี่ยนไป หรืองานบางอย่างจะหายไป เหมือนกับที่ช่างเรียงพิมพ์ค่อย ๆ หายไปโดยไม่รู้ตัว ในบริบทนั้น การออกแบบระบบก็คงจะเป็นอุปลักษณ์หรือตัวอย่างของการยกระดับนามธรรมที่สูงขึ้น
ผมคิดว่ามันเป็นเพราะทุกคนอยากหาสิ่งอื่นมาแทนนักพัฒนา
ดูเหมือนว่าจะมีคนจำนวนไม่น้อยที่คิดว่านักพัฒนาไม่ค่อยได้ทำอะไรแต่กลับได้เงินเยอะ
ผมคิดว่าไม่ว่าจะถูกแทนที่จริงหรือไม่ เหตุผลที่เนื้อหาแบบนั้นยังถูกพูดถึงซ้ำ ๆ ก็เพราะมันเร้าอารมณ์
ส่วนใหญ่แล้วพาดหัวที่ฟันธงแรง ๆ แบบนั้น ดูไม่น่าจะเป็นผลลัพธ์จากการคิดอย่างลึกซึ้งตั้งแต่แรก ว่าความเป็นจริงคืออะไร หรือจะนิยามคำว่า "การถูกแทนที่" ได้อย่างไร
งานที่ผ่านการคิดมาอย่างจริงจังกลับจะพูดถึงมากกว่าว่า ตอนนี้ AI หรือเครื่องมืออื่น ๆ ทำอะไรได้ถึงไหนแล้ว และกำลังพัฒนาไปทางไหน แต่คนทั่วไปก็คงไม่คลิกพาดหัวจืด ๆ แบบนั้นหรอก
พาดหัวกระตุ้นอารมณ์มีเยอะจริง ๆ..
"ซักเคอร์เบิร์กที่ปลดพนักงาน 10% ทุกปี: 'ปีหน้า AI จะแทนที่นักพัฒนาครึ่งหนึ่ง' [Silicon Valley View ของ Yoon Min-hyuk]" https://m.sedaily.com/NewsView/2GRQ1RKIYC
"'สิ่งที่ AI ทำได้ดีที่สุดคือการเขียนโค้ด'… เป้าหมายอันดับแรกของการปรับโครงสร้างที่ MS คือ 'นักพัฒนา'" https://n.news.naver.com/mnews/article/009/0005494133
"'แบบนี้คงถึงขั้นตกงาน' ความกังวลกำลังกลายเป็น 'ความจริง' หรือ?... วงการกำลังหวั่นวิตก" https://econmingle.com/economy/…
"[Yumi's Pick] 'เราไม่รับนักพัฒนา SW หน้าใหม่'… บริษัทที่ได้ลิ้มรส 'AI coding' เริ่ม 'เพิ่มประสิทธิภาพองค์กร'" https://v.daum.net/v/20250522162617091
"'AI ทำได้หมดทั้งการวิเคราะห์ ออกแบบ และเขียนโค้ด'… LG CNS ใช้ 'AI programmer' แทนนักพัฒนา" https://zdnet.co.kr/view/?no=20250528092405
ผมคิดว่าควรมองว่ามันกำลังถูกแทนที่ไปทีละน้อย
เป็นความจริงที่จำนวนคนที่ต้อง投入เพื่อให้ได้ผลงานจากงานเดียวกันกำลังลดลง
แม้แต่ในเรื่อง "การออกแบบระบบ" ถ้างานที่เคยใช้คน 10 คนทำ สามารถแก้ได้ด้วยคน 8 คน + การซัพพอร์ตจาก AI
ก็เท่ากับว่ามีคน 2 คนถูกแทนที่ไปแล้วครับ
ในแง่ของการออกแบบระบบ
อาจเป็นเพราะมักใส่เข้าไปในพรอมป์โดยไม่ได้พิจารณากันตามปกติหรือเปล่า
ดูเหมือนว่าปัญหาคือการตามเก็บงานจาก vibe coding มักเอาไม่ค่อยอยู่
ผมเห็นด้วยจากประสบการณ์ส่วนตัว AI ก็เป็นเครื่องมือในท้ายที่สุด ดังนั้นตั้งแต่ 1 ถึง 99 มันทั้งเร็วและดีมากจริง ๆ แต่ก็ให้ความรู้สึกเหมือนขาดอีก 1 ที่เหลืออยู่เสมอ
เห็นด้วยครับ/ค่ะ แต่ผม/ดิฉันคิดว่าหัวใจสำคัญน่าจะไม่ใช่ "การออกแบบระบบ" มากกว่า "การแก้ปัญหาที่ซับซ้อนผ่านการออกแบบระบบ"
ผม/ดิฉันเชื่อว่างานที่ง่ายจะยิ่งง่ายขึ้น และงานที่ยากก็จะยิ่งยากขึ้นเรื่อย ๆ
ฮ่า ฮ่า
ความคิดเห็นจาก Hacker News
จากประสบการณ์ล่าสุดที่ไปรับงานฟรีแลนซ์แก้งานประเภท "marketing landing page ใช้ครั้งเดียว" ลูกค้าที่ชอบควบคุมทุกอย่างมักจะเพิ่มข้อกำหนดประหลาดที่ AI จัดการไม่ได้อยู่เสมอ สุดท้ายก็กลายเป็นว่าต้องให้คนมาเก็บกู้ปัญหาอยู่ดี ไม่ว่า AI จะฉลาดขึ้นแค่ไหน ปัญหาซอฟต์แวร์จำนวนมากก็ไม่ใช่ปัญหาทางเทคนิค แต่เป็นปัญหาที่มนุษย์สร้าง “ความซับซ้อนที่ไม่จำเป็น” ขึ้นมาเอง สุดท้ายอาวุธที่ใหญ่ที่สุดของนักพัฒนาคือคำว่า “ไม่” แต่ก็มีความกังวลว่าถ้าให้ AI แข่งกันเอง มันอาจจะมีสักตัวที่ตอบ “ได้” แบบมนุษย์เสมอ
ซอฟต์แวร์อาจพัฒนาให้สมบูรณ์แบบได้ แต่ถ้าตัว requirement เองไม่สะท้อนความเป็นจริงทางเทคนิค สุดท้ายก็มีแต่ความสับสน นี่คือแนวคิดคลาสสิกเรื่อง “requirement bug” ทุกวันนี้ AI เองก็พอรับมือข้อจำกัดเชิงรูปแบบหรือการรองรับได้แล้ว เช่น gif ไม่รองรับ transparency แต่คำขอเพี้ยน ๆ อย่าง “ช่วยทำโลโก้ให้เป็นสี่เหลี่ยมจัตุรัสที่ทุกจุดอยู่ห่างจากจุดศูนย์กลางเท่ากัน” มนุษย์ก็คงยังเขียนออกมาเรื่อย ๆ มีการแซว typo ของ jpg เป็นมุกด้วย
ระหว่างคำว่า “ไม่” กับ “ได้” ยังมีเฉดสีเทาอีก 50 แบบในความหมายว่า “สิ่งนี้มันใช่หรือเปล่า” มีคนเคยบอกว่าอยากได้เว็บเพจที่ “ดาวน์โหลดฐานข้อมูลได้” แต่จริง ๆ แค่หมายถึง export csv ง่าย ๆ จึงสะท้อนว่าการตีความตามบริบทสำคัญมาก และก็มองว่าชวนสงสัยว่า chatgpt จะจับ nuance แบบนี้ได้ดีแค่ไหน
การ “ปฏิเสธ” คือส่วนที่ยากและหนักที่สุดของงานนักพัฒนา หลายนักพัฒนาเองก็ไม่ได้ชอบบทบาทนี้ หรือมองว่าไม่ใช่งานของตัวเอง แต่ความสำเร็จจริงของโปรเจกต์กลับถูกกำหนดด้วยการสื่อสารแบบ ‘คนกับคน’ กับผู้มีส่วนได้ส่วนเสีย มากกว่าจะเป็นเทคโนโลยี จึงเชื่อว่าจะยังต้องมีคนที่เป็น ‘นักพัฒนาที่ทำหน้าที่ PM ไปด้วยในทางปฏิบัติ’ อยู่เสมอ
ทั้งหมดนี้คือสิ่งที่หนังสือชื่อ ‘Peopleware’ พูดไว้ได้ดีมาก จึงชอบประโยคอวยพรที่ว่า “ขอให้ทุกปัญหาของคุณเป็นปัญหาทางเทคนิค” เพราะในโลกจริง ปัญหาที่แก้ด้วยโค้ดนั้นแทบไม่เคยยากมากนัก ยกเว้น edge case บางส่วน
มีความเห็นว่านี่เป็นประเด็นที่ดี และ AI อาจจะเก่งขึ้นเรื่อย ๆ ในการประเมินระดับความซับซ้อนและเตือนล่วงหน้า โดยยกตัวอย่างว่าในหมากรุก AI แสดงความสามารถด้านการประเมินและการตัดสินใจเหนือมนุษย์ไปไกลแล้ว ซึ่ง AI ในที่นี้ไม่ได้จำกัดแค่ LLM แต่ก็ยอมรับว่าความก้าวหน้าในกลุ่มนั้นมีจริง
ไม่เห็นด้วยกับคำกล่าวในบทความที่ว่า “AI ออกแบบระบบเชิงสถาปัตยกรรมไม่ได้” เพราะจริง ๆ แล้ว AI กำลังเก่งขึ้นในด้านนี้อย่างต่อเนื่อง และยังมีปรากฏการณ์เลื่อนเสาประเด็นด้วยการเปลี่ยนนิยามของเงื่อนไขที่จำเป็นไปเรื่อย ๆ อย่างไรก็ตาม AI ยังไม่สามารถตัดสินแทนได้ว่าตัวเองควรต้องการอะไร หรือควรตัดสินแรงจูงใจของผู้ใช้แทนหรือไม่ (แม้จะช่วยเสนอไอเดียได้) ต่อไปสังคมก็ยังต้องมีใครสักคนที่ลงมือและต้องการแก้ปัญหาจริง ๆ บทบาทของนักพัฒนาอาจเปลี่ยน แต่การแก้ปัญหายังคงเป็นหน้าที่ของมนุษย์
มีคนบอกว่าความหมายของคำว่า “นักพัฒนา” กำลังเปลี่ยน แต่ก็มีมุมมองว่าที่จริงแก่นแท้ไม่เคยเปลี่ยนเลย การเขียนโปรแกรมคือการแปลง requirement ที่คลุมเครือให้เป็นโค้ดที่ชัดเจน วิธีการอาจเปลี่ยนจาก machine code และ punch card ไปเป็น framework, GUI หรือเครื่องมือแบบภาพ แต่เหตุผลที่การเขียนโค้ดยังมีประสิทธิภาพที่สุดก็เพราะความชัดเจนและการสื่อสารที่ตรงไปตรงมา LLM เก่งกับการทำตามสิ่งที่มีอยู่แล้ว แต่ถ้าให้ทำงานที่ใหม่จริง ๆ หรืออธิบายผ่านภาษาธรรมชาติทั้งหมดกลับชวนอึดอัดไม่น้อย ตลาดตอนนี้อยู่ในภาวะ hype สูงสุด แต่สุดท้ายก็เป็นรูปแบบเดิมที่เทคโนโลยีใหม่แต่ละครั้งเข้ามาเปลี่ยนบางส่วน
มีการสังเกตว่าหลายบริษัทเริ่มลดการรับ junior เพราะ AI แล้ว ถ้า AI ทำได้ทุกอย่างยกเว้น architecting สุดท้ายโครงสร้างก็จะต้องการวิศวกรจำนวนน้อยลงอยู่ดี
มีความเห็นยืนยันว่า AI ยังทำ architecture ไม่ได้ และชี้ว่า architecting กับ planning คนละเรื่องกัน planning คือความสามารถในการจัดสรรข้อจำกัด วิธีแก้ ทรัพยากร และการคาดการณ์ ซึ่ง AI ยังห่างไกลจากระดับที่ทำได้อย่างมีประสิทธิภาพ ส่วน architecting ที่แท้จริงคือการออกแบบเชิงร่วมมือและแข่งขันระหว่างหลายชั้น หาก AI พลาดในชั้นใดชั้นหนึ่ง ระบบทั้งหมดก็อาจเสียรูปได้ และระบบแบบนี้มีแต่มนุษย์เท่านั้นที่ออกแบบและกำกับดูแลได้อย่างปลอดภัย
มีความเห็นว่าถ้ามีข้อมูลบริบทมากพอ AI ก็เข้าใจสิ่งที่ต้องการได้ค่อนข้างดี ซึ่งโยงไปถึงคำเตือนเรื่องการละเมิดความเป็นส่วนตัวด้วย ถ้าองค์กรถือครองระบบที่แข็งแรงและเทคโนโลยีที่รับรู้บริบทได้ดีพอ สิ่งที่น่ากลัวกว่าคือ AI อาจคาดเดาความต้องการหรือการกระทำถัดไปของคุณได้ “มากพอ”
มีคนพูดตรง ๆ ว่า AI ยังไม่ได้ทำ architecting แต่แค่ทำ simulation และหลายครั้งแม้แต่การเขียนโค้ดก็ยังทำได้ไม่ดี
มีข้อโต้แย้งว่าการตั้งสมมติฐานว่าธุรกิจให้ความสำคัญกับคุณภาพนั้นผิดตั้งแต่ต้น บริษัทสนใจแค่ความสามารถในการทำกำไร และจะให้คุณภาพสูงก็ต่อเมื่อลูกค้าต้องการเท่านั้น พูดตรง ๆ ลูกค้าเองก็มักชอบของที่คุ้มค่าที่สุดมากกว่าคุณภาพ จึงซื้อเครื่องมือที่ถูกที่สุดใน Amazon แล้วผลิตโค้ดแนว (vibe code) ที่หละหลวมคล้าย ๆ กันออกมาซ้ำ ๆ สุดท้ายกลุ่มที่ให้ความสำคัญกับคุณภาพจริง ๆ มีแค่วิศวกร ดังนั้นคำทำนายอนาคตที่ให้ความสำคัญกับคุณภาพจากมุมมองวิศวกรอาจมองข้ามไปได้เลย
มีความเห็นว่าคุณภาพสามารถเป็นจุดสร้างความแตกต่างได้ ยกตัวอย่างตอน iPhone เปิดตัว แม้จะมีคู่แข่งมากมายที่ใส่ฟีเจอร์มาเยอะกว่า แต่เมื่อ UI ลื่นไหลและประณีตกว่า ก็ครองตลาดได้ในที่สุด
มีการแนะนำบริษัทที่ชอบที่สุดในด้านการยึดคุณภาพคือ Fractal Audio บริษัทขนาดเล็กที่ทำ hardware modeler สำหรับกีตาร์ (ตัวจำลองแอมป์และ pedal board) มีอัปเดตเชิงนวัตกรรมต่อเนื่อง และ CEO ก็หมกมุ่นกับประสิทธิภาพของ analog modeling คุณภาพดีกว่าบริษัทใหญ่หลายรายอย่างชัดเจน วางตำแหน่งด้วยการขายตรงและอัปเดตอัลกอริทึมฟรี โดยไม่พึ่ง commission, subscription หรือการตลาดผ่านคนดัง เป็นตัวอย่างมีชีวิตว่าคุณภาพสามารถยึดส่วนแบ่งตลาดได้ และไม่ใช่ทุกธุรกิจที่จะลงแข่งแบบ ‘ถูกที่สุด คุณภาพต่ำที่สุด’ เสมอไป
มีคนโต้กลับมุมมองที่ว่าลูกค้าไม่สนใจคุณภาพว่า ถ้าคุณภาพไม่มีความหมายจริง สตาร์ตอัปทั้งหมดก็ควรสร้างแต่ของถูกและไม่สมบูรณ์ แล้วก็ควรประสบความสำเร็จและทำรายได้มหาศาลกันหมดแล้ว
มีการไล่รายชื่อว่าซอฟต์แวร์ที่ประสบความสำเร็จจริงส่วนใหญ่นั้นมีคุณภาพสูงมาก ไม่ว่าจะเป็น Google, iPhone, Stripe, Notion สินค้าที่อยู่รอดในตลาดระยะยาวไม่ได้ช้าหรือเต็มไปด้วยบั๊ก ตรงกันข้าม คุณภาพต่างหากที่เป็นปัจจัยความสำเร็จ และก็ตั้งคำถามว่าทำไมจึงไม่ค่อยได้ยินตัวอย่างที่สวนทางกัน
มีความกังวลว่าคุณภาพอาจค่อย ๆ เลือนหายเพราะการทำให้ทุกอย่างกลายเป็นชิ้นส่วนย่อย subscription และต้องเชื่อมต่ออินเทอร์เน็ตตลอด แต่สุดท้ายอนาคตอาจมาถึงจุดที่ทุกอย่างพังลงเร็วมาก เช่น อุปกรณ์กลายเป็นก้อนอิฐ เว็บไซต์ง่าย ๆ ยังใช้เวลาโหลด 12 วินาที โครงสร้างพื้นฐานสังคมและระบบภาครัฐใช้งบหลายพันล้านแต่ยังไม่เสถียร และการสนทนาในชีวิตประจำวันกลายเป็นการคุยกับ LLM ทั้งหมด
มีการย้อนมองว่าแนวปฏิวัติองค์กรแบบ UML ในอดีตที่ให้ “architect ทำสเปก แล้วนักพัฒนาเติมช่องว่าง” กลับสร้างระบบที่ซับซ้อนเกินจำเป็นและสูญเสียความคล่องตัว ส่วน “Agile” ที่ตามมาก็ถูกเข้าใจผิดจนกลายเป็นวัฒนธรรมการ micromanage นักพัฒนา ไม่ไว้ใจ และไม่สร้างสรรค์ สุดท้ายทีมที่ประสบความสำเร็จจริงกลับมีลักษณะร่วมคือ ไม่ว่าจะแชร์เครื่องมือหรือ process แบบไหน คนที่ไม่ใช่นักพัฒนากลับสนใจงานของนักพัฒนาอย่างจริงจังและช่วยกันแก้ปัญหา ขณะที่ความพยายามลดความซับซ้อนมักล้มเหลวเสมอ
ต่อคำกล่าวที่ว่า “architecting คือทักษะที่มีคุณค่าที่สุด แต่ AI แทนไม่ได้” มีคนแย้งว่าในทางปฏิบัติ ถ้าขอให้ AI ออกแบบ system architecture อย่างชัดเจน มันมักให้ผลลัพธ์ดีกว่านักออกแบบในโลกจริงอย่างน้อย 30% ที่เคยพบมาเสียอีก เพียงแต่ผู้ใช้ AI ส่วนใหญ่ไม่ค่อยขอมันแบบนั้น
ปัจจุบัน LLM ถูกฝึกจากคำตอบระดับกลาง ๆ แบบ best practice เป็นหลัก จึงโดยธรรมชาติแล้วมักให้ผลที่ดีกว่านักออกแบบมนุษย์ราวหนึ่งในสามด้วยซ้ำ ในแง่การออกแบบที่พึ่ง common sense และปลอดภัย แต่ในโดเมนใหม่จริง ๆ ที่ไม่มีในข้อมูลฝึก หรือในอุตสาหกรรมที่ต้องการสมรรถนะสูงมาก มนุษย์ที่คิดจาก first principles ยังจำเป็นกว่า และถ้าให้ LLM ออกแบบ DB kernel ก็คงได้งานระดับพื้นฐานมากกว่านวัตกรรม
มีคำวิจารณ์ว่าตัวบทความเองเขียนในสไตล์เฉพาะแบบ ChatGPT เช่น ประโยคสั้น การซ้ำคำ การเล่นสำนวนอย่าง “ไม่ใช่ X แต่เป็น X+1”, “ไม่ใช่ X แต่เป็นตรงข้ามของ X” ที่ใช้มากเกินไป และยังแปลกใจที่บทความลักษณะนี้ได้อัปโหวตเยอะใน HN
มีการตีความว่าผู้เขียนอาจกำลังคิดแบบ wishful thinking จากความเชื่อหรือความมั่นใจเกินไปว่าทักษะของตัวเอง (architecting) เป็นสิ่งถาวรและแทนไม่ได้ ถ้าเจ้าตัวเก่งด้านอื่นมากกว่า ก็คงเชื่อว่าสิ่งนั้นแทนไม่ได้แทน
มีการสรุปว่าแก่นของการเป็น architect คือความสามารถในการเข้าใจ requirement และ constraint อย่างแม่นยำแล้วสะท้อนลงในระบบ กล่าวอีกแบบคือ ต้องเขียน prompt ให้ดี อ่านคำตอบให้เป็น และกล้าโต้แย้งหนัก ๆ เมื่อจำเป็น
มีความเห็นว่า ‘architect’ จำนวนมากที่เจอในโลกจริงกลับมีความสามารถเชิงปฏิบัติไม่พอ เช่น คิดว่าแค่ใช้เครื่องมือวาดไดอะแกรมหรือ Excel ได้ก็พอ ทั้งที่ไม่มีความเชี่ยวชาญด้าน IT infrastructure จริง ภายนอกดูคล้าย manager แต่ในความจริงมีเพียงส่วนน้อยที่ทำงานแก่นแท้ของบทบาทนี้ได้
มีความเห็นว่าบริษัทที่พึ่ง AI “มากเกินไป” กลับเพิ่มความเสี่ยงที่จะโดนคลื่นนวัตกรรมซัดล้ม ในยุค AI แก่นสำคัญไม่ใช่ productivity ของการผลิตโค้ด แต่คือการควบคุมคุณภาพของโค้ด ทว่าตลาดกลับโฟกัสหนักเกินไปที่การสร้างโค้ดอัตโนมัติ มีการอ้างคำพูดของ Satya Nadella ที่ว่า “30% ของโค้ด Microsoft ถูกเขียนด้วย AI” และยังยกแนวโน้มที่ Github มีเหตุการณ์ขัดข้องมากกว่า 20 ครั้งต่อเดือนเป็นค่าเฉลี่ยจริง (ลิงก์อ้างอิง: githubstatus.com/history) จึงคาดว่าบริษัทที่ไล่ตามประสิทธิภาพอย่างเดียวจะต้องมารับภาระจากคุณภาพที่ตกลงในภายหลัง โดยเฉพาะบริษัทขนาดเล็กและกลางที่ไม่ใช่ยักษ์ใหญ่ระดับ MS มีความเสี่ยงจะพังได้ง่ายกว่า
มีความเห็นโต้แย้งว่าบริษัทที่เมิน AI ต่างหากที่จะลำบาก
มีการยกบทความสนับสนุนมุมมองว่า “บริษัทที่ใช้ AI มากเกินไปจะต้องแบกต้นทุนระยะยาวมหาศาล” (AI: Accelerated Incompetence)
เห็นด้วย 100% กับประโยคที่ว่า “โค้ดไม่ใช่สินทรัพย์ แต่เป็นหนี้สิน” เป้าหมายคือทำให้บรรลุวัตถุประสงค์ด้วยโค้ดให้น้อยที่สุด แต่ AI กลับทำให้การผลิตโค้ดง่ายเกินไป จนเสี่ยงทำให้ code debt พอกพูนหนักกว่าเดิม
มีการแชร์ลิงก์วิกิเรื่อง productivity paradox ในความก้าวหน้าทางเทคโนโลยี ซึ่งหมายถึงปรากฏการณ์ที่ productivity เพิ่มขึ้น แต่ประสิทธิภาพจริงถูกหักล้างด้วยความซับซ้อนของระบบที่เพิ่มขึ้น (Productivity paradox)
มีการเปรียบว่ายุค AI สร้างโค้ดในปัจจุบันคล้ายกับยุคที่คนทำเว็บไซต์ด้วย MS FrontPage ซึ่ง html เต็มไปด้วยโค้ดไร้ประโยชน์ถึง 90% เป็น ‘ยุคแห่ง cruft’
มีความคิดกลับด้านว่า ถ้าในอนาคตโค้ดแทนกันได้ง่ายจริง มุมมองที่ว่าโค้ดคือหนี้สินอาจหมดความหมายไปหรือไม่ เพราะเวลาเจอ error โปรแกรมเมอร์ก็อาจแค่บอก AI ให้เขียนใหม่ ทำให้ภาระลดลง
อีกคนบอกว่าตนเองมองโค้ดเป็นทั้งงานสร้างสรรค์และการแสดงออกทางศิลปะ และเคยมีประสบการณ์ที่มองโค้ดซึ่งอ่านง่ายและสวยงามแล้วรู้สึกถึงความงามได้ทันที
มีการแชร์ลิงก์เพื่อเตือนว่า ตั้งแต่ช่วงเปิดตัว FORTRAN แรก ๆ ในปี 1954 ก็มีสโลแกนประมาณว่า “Fortran จะทำให้การเขียนโค้ดและการดีบักหมดไป” แล้ว (BackusEtAl-Preliminary Report)
มีความเห็นว่าข้อสมมติฐานที่อยู่ใต้การถกเถียงทั้งหมดนี้คือความคาดหวังว่าความก้าวหน้าทางเทคนิคจะชนเพดานในไม่ช้า แต่ถ้าสมมติฐานนั้นผิด ก็ไม่มีอะไรห้ามว่าในวันหนึ่ง AI จะเข้าใจและออกแบบธุรกิจแบบองค์รวมได้ จากการมองเห็นทั้ง infrastructure, log, การเงิน และเอกสารทั้งหมด โมเดล AI ยังขยายตัวต่อ ความสามารถก็ดีขึ้นและถูกลงเรื่อย ๆ จึงมีน้ำหนักไปทางที่ว่าในที่สุดมันอาจไปถึงแก่นของการทดแทนได้จริง
มีมุมมองว่าการปลดนักพัฒนาไม่ได้เกิดจากความก้าวหน้าทางเทคโนโลยี แต่เป็นผลตามมาจากความไม่แน่นอน และการอ้างเทคโนโลยีหรือ AI ก็เป็นเพียงคำแก้ตัวภายหลัง ยกตัวอย่างว่าเมื่อ 5 ปีก่อน บริษัทจำนวนมากยังยอมเพิ่มจำนวนวิศวกรซอฟต์แวร์แม้ต้นทุนสูง เพื่อหวังขยาย productivity ดังนั้นจึงมองว่าต้นทุนไม่ใช่ต้นเหตุที่แท้จริง
กำลังมองหาคนช่วยตรวจงาน vibe coding ด้วย AI ให้หน่อย ทำไว้หมดแล้วแต่มี error ช่วยแก้นิดเดียวพอ คำขอจ้างงานลักษณะนี้มีออกมาแล้ว ซึ่งจริง ๆ สร้างใหม่ยังจะเร็วกว่า
เรื่องนี้ผมก็เคยเจอมากับตัวเหมือนกัน น่ากลัวสุดๆ...
ไม่รู้ว่าเป็นเพราะพวกเขาไม่รู้จริง ๆ หรือแค่ไม่ใส่ใจกันแน่ แต่ไม่ว่าจะยังไงก็ดูเหมือนจะมีคนแบบนั้นเยอะพอสมควร...
เรื่องการแปลก็เหมือนกัน... AI พอจะใช้งานได้ไหม? ได้อยู่ แต่ดูเหมือนว่าจะทำให้หลายคนลำบากเหมือนกัน...
พอมองผ่าน ๆ มันก็ดูเข้าท่า แต่ในมุมของคนที่ต้องมาแก้ งานกลับยิ่งเพิ่มขึ้นอีก T_T
ขนลุกเลย 5555