- ตลอดกว่า 50 ปีที่ผ่านมา มีความพยายามซ้ำแล้วซ้ำเล่าในการ ทำให้การพัฒนาซอฟต์แวร์ง่ายขึ้นเพื่อลดการพึ่งพานักพัฒนา
- รูปแบบเดิมดำเนินต่อเนื่องตั้งแต่ COBOL ในทศวรรษ 1960 ไปจนถึง CASE tools, Visual Basic, low-code·no-code และล่าสุด AI code assistants
- เทคโนโลยีแต่ละอย่างช่วยเพิ่มผลิตภาพ แต่ กระบวนการคิดเพื่อรับมือกับความซับซ้อน ยังเป็นหน้าที่ของมนุษย์
- AI ช่วยขยายขีดความสามารถของนักพัฒนา แต่ไม่ได้แทนที่ ความเข้าใจปัญหาทางธุรกิจและวิจารณญาณ
- ความพยายามที่เกิดซ้ำนี้เผยให้เห็นว่า สิ่งสำคัญไม่ใช่ ข้อจำกัดของเครื่องมือ แต่คือความซับซ้อนของปัญหา และท้ายที่สุดหัวใจสำคัญคือ การลงทุนกับความสามารถในการคิดของมนุษย์
จุดเริ่มต้นของรูปแบบที่เกิดซ้ำ
- ทุก ๆ 10 ปี มักมีคำสัญญาว่า “คราวนี้การพัฒนาจะง่ายขึ้น” ปรากฏขึ้น
- หลังโครงการ Apollo ในปี 1969 ซอฟต์แวร์ได้ก้าวขึ้นมาเป็นเทคโนโลยีหลัก
- แต่ก็เห็นชัดว่าการพัฒนายังคงต้องใช้ ความรู้เฉพาะทาง สมาธิ และเวลา
- นับจากนั้น ความฝันอย่างต่อเนื่องเรื่อง “ทำให้การพัฒนาง่ายขึ้นเพื่อลดจำนวนคน” ก็เริ่มต้นขึ้น
COBOL: ความเชื่อว่าฝ่ายธุรกิจจะเขียนโค้ดได้ด้วยตนเอง
- ตามชื่อ Common Business-Oriented Language, COBOL ถูกออกแบบมาเพื่อให้ ผู้รับผิดชอบงานธุรกิจสามารถเขียนโค้ดในลักษณะคล้ายประโยคภาษาอังกฤษ ได้
- แต่ในความเป็นจริง ความซับซ้อนของตรรกะ โครงสร้างข้อมูล และการออกแบบระบบ ยังคงอยู่ ทำให้ท้ายที่สุดเกิด กลุ่มนักพัฒนา COBOL เฉพาะทาง ขึ้นมาใหม่
- วิสัยทัศน์แบบ “ใคร ๆ ก็เขียนโค้ดได้” จึงไม่เกิดขึ้นจริง
ทศวรรษ 1980: คำสัญญาของ CASE tools เรื่องการสร้างอัตโนมัติ
- เครื่องมือ CASE (Computer-Aided Software Engineering) ปรากฏตัวพร้อมคำสัญญาว่าจะ สร้างโค้ดอัตโนมัติจากไดอะแกรม
- องค์กรต่าง ๆ ลงทุนครั้งใหญ่โดยคาดหวังว่าผลิตภาพจะเพิ่มขึ้น 10 เท่า
- แต่โค้ดที่สร้างขึ้นกลับล้มเหลวจาก ปัญหาด้านประสิทธิภาพ การบำรุงรักษาที่ยาก และความไม่สอดคล้องของโมเดล
- เพราะยังคงต้อง เข้าใจความซับซ้อนเชิงตรรกะ ปัญหาจึงไม่ได้รับการแก้ไข
ทศวรรษ 1990: แนวทางของ Visual Basic และ Delphi
- การสร้าง UI ทำได้ง่ายขึ้นด้วยวิธี drag-and-drop ทำให้อุปสรรคในการเริ่มพัฒนาลดลง
- แม้จะสร้างแอปพลิเคชันแบบง่ายได้ แต่ระบบที่ซับซ้อนซึ่งต้องการ การเชื่อมต่อ ความปลอดภัย ประสิทธิภาพ และการบำรุงรักษา ก็ยังต้องอาศัยนักพัฒนาที่มีทักษะ
- ผลลัพธ์คือ ความต้องการนักพัฒนาไม่ได้ลดลง กลับเพิ่มขึ้นด้วยซ้ำ
ตั้งแต่ทศวรรษ 2000 เป็นต้นมา: เว็บเฟรมเวิร์ก, low-code, no-code
- Ruby on Rails ชูแนวคิด “convention over configuration” ขณะที่ แพลตฟอร์ม low-code·no-code ชูแนวคิด “การพัฒนาโดยไม่ต้องเขียนโค้ด”
- แม้จะช่วยเพิ่มความเร็วและขยายการมีส่วนร่วมได้ในบางด้าน แต่ ความจำเป็นของนักพัฒนาเฉพาะทางยังคงเพิ่มขึ้นอย่างต่อเนื่อง
- คำถามที่วนกลับมาซ้ำ ๆ คือ “ทำไมรูปแบบนี้ยังเกิดขึ้นต่อไป?”
ธรรมชาติของความซับซ้อน
- ซอฟต์แวร์อาจดูเหมือนเรียบง่ายในภาพรวม แต่ในความเป็นจริง ความซับซ้อนจะระเบิดขึ้นที่ รายละเอียดสถานการณ์และการจัดการข้อยกเว้น
- ตัวอย่าง: ความขัดแย้งในการจองสต็อก, การชำระเงินล้มเหลว, บริการอีเมลหยุดทำงาน
- การตัดสินใจในรายละเอียดเหล่านี้เองคือ แก่นแท้ของการพัฒนา และไม่มีเครื่องมือใดลบสิ่งนี้ออกไปได้
บทใหม่ในยุค AI
- AI code assistants สามารถสร้างโค้ดจากภาษาธรรมชาติ รวมถึงอธิบาย ดีบัก และเสนอแนวทางปรับปรุงได้
- นี่คือ ความก้าวหน้าที่จับต้องได้ แต่บทบาทอย่าง การกำหนดปัญหา ความปลอดภัย การเชื่อมต่อ และการตัดสินใจด้านการบำรุงรักษา ก็ยังเป็นของมนุษย์
- AI ช่วย เพิ่มผลิตภาพของนักพัฒนา แต่ไม่สามารถแทนที่ วิจารณญาณและความเข้าใจบริบท ได้
ศักยภาพด้านการพัฒนาที่ยังขาดแคลน
- แม้เทคโนโลยีจะก้าวหน้าอย่างมาก แต่ ความต้องการซอฟต์แวร์ยังสูงกว่าอุปทาน
- องค์กรต่าง ๆ จึงมองหา “วิธีสร้างให้เร็วขึ้นและได้มากขึ้น” พร้อมฝากความหวังไว้กับ เครื่องมือทำให้การพัฒนาง่ายขึ้น
- แต่คอขวดที่แท้จริงไม่ใช่ ความเร็วในการพิมพ์หรือไวยากรณ์ หากเป็น ความสามารถในการคิดรับมือความซับซ้อน
คำถามที่ผู้นำควรถาม
- ไม่ใช่ “เครื่องมือนี้จะมาแทนนักพัฒนาหรือไม่?” แต่คือ
- “มันช่วยแก้ปัญหาที่ซับซ้อนได้หรือไม่?”
- “มันช่วยลดงานซ้ำ ๆ เพื่อให้โฟกัสกับปัญหาเชิงสร้างสรรค์ได้หรือไม่?”
- “จำเป็นต้องเรียนรู้ทักษะใหม่หรือไม่?”
- คำถามเหล่านี้ทำให้เห็นทั้ง ข้อจำกัดของเครื่องมือและความหลีกเลี่ยงไม่ได้ของการคิดแบบมนุษย์
บทเรียนจาก 50 ปี: ปัญหาไม่ใช่เรื่องเชิงกลไก แต่เป็นเรื่องทางปัญญา
- COBOL ทำให้ไวยากรณ์ง่ายขึ้น, CASE ลดการพิมพ์, และ AI สร้างฟังก์ชันทั้งชุดได้ แต่ ความยากที่เป็นแก่นแท้ยังคงอยู่
- การพัฒนาซอฟต์แวร์คือ ‘การทำให้ความคิดเป็นรูปธรรม’ และสิ่งนี้ไม่อาจแทนที่ได้ด้วยเครื่องมือ
- เช่นเดียวกับการออกแบบสถาปัตยกรรมหรือการวินิจฉัยทางการแพทย์ กระบวนการคิดเองต่างหากคือคุณค่าหลัก
ทิศทางต่อจากนี้
- จะยังมีเครื่องมือใหม่ ๆ ปรากฏขึ้นต่อไป แต่สิ่งสำคัญที่สุดคือ การลงทุนกับพลังการคิดของมนุษย์
- ควรทดลองใช้ AI·low-code·เฟรมเวิร์กใหม่ ไปพร้อมกัน แต่ต้องยึด ความสามารถในการเข้าใจความซับซ้อน ให้เป็นขีดความสามารถหลักขององค์กร
- เช่นเดียวกับโครงการ Apollo ความแม่นยำของการคิด ไม่ใช่เครื่องมือ คือปัจจัยชี้ขาดความสำเร็จ
เหตุผลที่ความฝันนี้ยังคงดำเนินต่อไป
- “ความฝันที่จะมาแทนนักพัฒนา” ไม่ใช่ความล้มเหลว แต่เป็น ความมองโลกในแง่ดีที่กระตุ้นนวัตกรรมของเครื่องมือ
- ความพยายามแต่ละครั้งแม้จะล้มเหลวในการแทนที่อย่างสมบูรณ์ แต่ก็ได้สร้าง เครื่องมือที่มีประโยชน์สำหรับคนรุ่นต่อมา
- COBOL ช่วยขยายการพัฒนาระบบธุรกิจ
- CASE ช่วยผลักดันการพัฒนา visual modeling
- Visual Basic ช่วยขยายการเข้าถึงการพัฒนา
- AI ช่วยเร่งการเปลี่ยนแปลงวิธีพัฒนา
- ท้ายที่สุด ข้อจำกัดไม่ได้อยู่ที่ เครื่องมือ แต่คือความซับซ้อนของปัญหาที่เราพยายามแก้
- ไม่จำเป็นต้องปฏิเสธเครื่องมือใหม่ แต่ควรตระหนักถึง ความคาดหวังที่สมจริงและความสำคัญของวิจารณญาณมนุษย์
5 ความคิดเห็น
ความเห็นจาก Hacker News
เมื่อมองดู คลื่นแห่งนวัตกรรม AI ครั้งนี้ ก็ทำให้ตระหนักได้ว่าหลายส่วนของการเขียนโค้ดไม่ได้เป็นความซับซ้อนโดยเนื้อแท้ แต่เป็น ความซับซ้อนเชิงบังเอิญ
สำหรับมนุษย์ งานเชิงแนวคิดกำลังกลายเป็นงานเชิงกระบวนการสำหรับ AI
ตัวอย่างเช่น เมื่อก่อนการจะเขียน
public static void main(String[] args)ใน Java ต้องเรียนรู้หลายแนวคิด แต่สำหรับ AI แค่ให้พรอมป์ต์ว่า “เขียนเมธอดเริ่มต้นของคลาส” ก็แทบจะสร้างโค้ดนั้นออกมาได้อย่างแน่นอนงานเชิงกระบวนการที่ยากสำหรับมนุษย์กลับง่ายสำหรับ AI ขณะที่สังคมถูกจัดโครงสร้างอยู่บนแรงงานเชิงกระบวนการแบบนี้ ดังนั้นเมื่อการเปลี่ยนแปลงแพร่ขยายออกไป บางคนก็จะก้าวขึ้นไป และบางคนก็จะต้องเจ็บปวด
คำกล่าวที่ว่า “No-code จะมาแทนที่นักพัฒนา” ถูกพูดซ้ำมาเรื่อย ๆ แต่ในความเป็นจริงกลับสร้างงานนักพัฒนาเพิ่มขึ้นมาตลอด
ตั้งแต่ COBOL, VB, Squarespace จนถึง AI ตอนนี้ — เมื่อเครื่องมือทำให้กำแพงการเริ่มต้นต่ำลง ผู้คนก็อยากสร้างอะไรบางอย่างมากขึ้น และสุดท้ายพอชนข้อจำกัด ก็ยังต้องการนักพัฒนาตัวจริงอยู่ดี
งานซ้ำ ๆ ง่าย ๆ อาจหายไป แต่ การนิยามว่าจะสร้างอะไรและการดีบัก ก็ยังคงอยู่
ถ้า AI สามารถเขียนโค้ดโปรเจกต์ที่ซับซ้อนได้ด้วยตัวเอง มนุษย์ก็อาจไม่ต้องใส่ใจรายละเอียดมากนัก และความต้องการนักพัฒนาอาจลดลง
ในอดีตเราเคยมีเทรนด์ใหญ่ระดับอินเทอร์เน็ต คลาวด์ โมบาย และแมชชีนเลิร์นนิง แต่ก็ไม่แน่ใจว่าในอนาคตจะยังมี ‘ปัญหาใหญ่’ แบบนั้นเกิดขึ้นต่อเนื่องหรือไม่
ตลอด 20 ปีที่ผ่านมา ในงานดูแลระบบก็เห็นรูปแบบเดียวกันนี้มาตลอด
คำสัญญาว่า “การยกระดับ abstraction จะทำให้งานของผู้เชี่ยวชาญเป็นประชาธิปไตยมากขึ้น” ถูกพูดซ้ำแล้วซ้ำเล่า แต่ในความเป็นจริงกลับเกิด การประดิษฐ์ซ้ำที่มีต้นทุนสูง
เครื่องมืออย่าง Kubernetes อ้างว่าซ่อนความซับซ้อนไว้ได้ แต่สุดท้ายเหล่านักพัฒนาก็กำลังเรียนรู้ปัญหาเดิมซ้ำอีกครั้งด้วยวิธีที่แพงกว่า โดยไม่รู้แม้แต่แนวคิดพื้นฐาน
Excel เป็นตัวอย่างชัดเจน — มันสร้างข้อผิดพลาดเลวร้ายมหาศาล แต่ก็ประสบความสำเร็จเพราะ การเข้าถึงง่าย
ท้ายที่สุด เราต่างก็ต้องการ “การเข้าถึงง่ายแบบ Excel และความน่าเชื่อถือแบบวิศวกรรม” พร้อมกัน แต่เราไม่มีทางได้ทั้งสองอย่าง
ความจริงคือเมื่อขนาดองค์กรโตขึ้น ความซับซ้อนของงาน ก็ขยับสูงขึ้นตาม
เหตุผลที่รูปแบบนี้เกิดซ้ำ ก็เพราะ แรงจูงใจของตลาด
บริษัทต่าง ๆ ต้องทำให้ AI ดูเหมือนเป็นยาวิเศษสารพัดอย่างเพื่อให้ราคาหุ้นขึ้น จึงกลายเป็นโครงสร้างที่ขาย ความเชื่อ มากกว่าประสิทธิภาพจริง
สุดท้ายเมื่อความจริงเปิดเผย ตลาดก็จะสับสนวุ่นวาย
ที่จริงแล้วจำนวนผู้พัฒนาสามารถลดลงได้
ถ้าบริษัท คัดสรรการจ้างงานและลงทุนด้านการฝึกอบรม มากกว่านี้
แต่ความจริงกลับตรงกันข้าม และเว็บเฟรมเวิร์กก็ถูกสร้างขึ้นเพื่อ ลดต้นทุนการฝึกอบรมและขยายพูลแรงงาน มากกว่าจะเพิ่มผลิตภาพ
ผู้จัดการระดับกลางและผู้บริหารมองฝ่ายเทคโนโลยีเป็นเพียง ศูนย์ต้นทุน
จึงเอ่ยถึง AI ในข่าวประชาสัมพันธ์ทุกชิ้นพร้อมประกาศลดต้นทุนแรงงาน
ในความเป็นจริง ต้นทุนที่ลดลงไม่ได้มาจาก AI แต่เกิดจาก การแทนที่ด้วยแรงงานออฟชอร์
ส่วนทีมออนไซต์ที่เหลืออยู่ก็ต้องแบกรับงานมากขึ้นและเพิ่มผลิตภาพไปพร้อมกัน
สาเหตุไม่ใช่การลดต้นทุนแรงงาน แต่เป็น การหดตัวของการลงทุน โดยรวม
สุดท้าย AI กำลังดูดซับเงินทุนไปกับการลงทุนในดาต้าเซ็นเตอร์ และทำให้งานลดลง
จุดประสงค์ของ AI ไม่ใช่การแทนที่นักพัฒนา แต่คือ การยกระดับ abstraction เพื่อให้รับมือกับปัญหาที่ซับซ้อนยิ่งขึ้นได้
ตั้งแต่ยุคแรกของการโปรแกรมด้วยการเดินสายคอมพิวเตอร์ ไปสู่อะเซมบลี, C, Python และเฟรมเวิร์ก นักพัฒนาจึงค่อย ๆ ขยับไปจัดการปัญหาในระดับที่สูงขึ้นเรื่อย ๆ
อย่างไรก็ตาม ขั้นตอนก่อนหน้านี้ทั้งหมดล้วนเป็น การแปลงที่เป็นเชิงกำหนดและตรวจสอบได้ แต่ Generative AI นั้นไม่เป็นเชิงกำหนด ซึ่งเป็นจุดที่ต่างออกไป
สำหรับเรื่องที่เกี่ยวข้อง ลองดู The Story of Mel
LLM ไม่เหมือนคอมไพเลอร์ตรงที่เราไม่สามารถเห็น token, AST, IR ฯลฯ ได้ จึงมีความทึบแสง
ระบบไม่เป็นเชิงกำหนดที่อิงภาษาธรรมชาตินั้นต่างจาก abstraction รุ่นก่อน ๆ
ดังนั้นการเปรียบเทียบว่า “เหมือนการเปลี่ยนจากอะเซมบลีไป C” จึงไม่ค่อยเหมาะนัก
อย่างที่ Dijkstra กล่าวไว้ วิทยาศาสตร์ถูกเกลียดเพราะมันยาก และนักวิทยาศาสตร์ผู้ครอบครองพลังนั้นก็ถูกเกลียดเช่นกัน
ลิงก์ต้นฉบับ EWD1041
ในทางกลับกัน นักพัฒนาเองก็ฝันจะ ทำงานของสายอาชีพที่ไม่ใช่นักพัฒนาให้เป็นอัตโนมัติ มาตลอด
AI ก็เป็นเวอร์ชันล่าสุดของความฝันนั้น
ช่วงต้นยุค 2000 ในมหาวิทยาลัย Rational Rose UML เป็นวิชาบังคับ
ตอนนั้น CEO ของสตาร์ทอัปรายหนึ่งพูดว่า “จากนี้ไปแค่วาดไดอะแกรม โค้ดก็จะถูกสร้างอัตโนมัติแล้ว จึงไม่จำเป็นต้องมีนักพัฒนา”
แต่สุดท้ายคำพยากรณ์นั้นก็ไม่เคยเป็นจริง
เครื่องจักรสร้างโค้ดสำหรับเครื่องจักร
ปราสาททรายที่มนุษย์สร้างขึ้นบนภาษาระดับเครื่องจักร สุดท้ายก็มีชะตาต้องพังทลายลง
...จะพูดแบบนั้นก็ได้เหมือนกันนะ 555