ข้อคิดเกี่ยวกับอนาคตของการพัฒนาซอฟต์แวร์

xguru · 2024-03-25T10:31:01+09:00

โมเดลภาษาขนาดใหญ่ (LLMs) สามารถสร้างภาพ ข้อความ และโค้ดได้ จึงสร้างแรงสั่นสะเทือนครั้งใหญ่ในงานสร้างสรรค์ ในช่วงแรกมักมีผลลัพธ์ชวนขำอยู่มาก เช่น วาดมือคนผิดรูป หรือบอกข้อเท็จจริงผิด ๆ แต่ก็ค่อย ๆ ดีขึ้นเรื่อย ๆ ก่อนที่โมเดลเหล่านี้จะปรากฏขึ้น เหตุผลหลักที่ใช้คัดค้านระบบอัตโนมัติคือเครื่องจักรไม่สามารถคิดอย่างสร้างสรรค์ได้ แต่ตอนนี้ข้อโต้แย้งนั้นเริ่มอ่อนแรงลงเรื่อย ๆ แล้วจากนี้เราควรไปทางไหน? กรอบคิด: ระดับความสามารถในการพัฒนาซอฟต์แวร์ การพัฒนาซอฟต์แวร์ไม่ได้มีแค่การเขียนโค้ดเท่านั้น ภาพจำของโปรแกรมเมอร์คือคนนั่งพิมพ์โค้ดอย่างขะมักเขม้นอยู่หน้าคอมพิวเตอร์ในห้องมืด แต่ในความเป็นจริง พวกเขาใช้เวลากับงานอื่นมากกว่าการเขียนโค้ด เก็บความต้องการจากผู้ใช้ฝั่งธุรกิจ กลั่นกรองความต้องการให้อยู่ในรูปแบบที่สามารถโมเดลเป็นโค้ดได้ ทำภาพและวางแผนโซลูชันร่วมกับเพื่อนร่วมทีม เช่น ดีไซเนอร์และผู้จัดการผลิตภัณฑ์ ออกแบบและขัดเกลางานเชิงเทคนิคร่วมกับนักพัฒนาคนอื่น ตั้งค่าโครงสร้างพื้นฐาน การคอนฟิก โค้ด boilerplate ฯลฯ เขียนโค้ดจริง ดีบัก ทำความเข้าใจโค้ดของคนอื่น เขียนเอกสาร ฯลฯ ดีพลอยขึ้นโปรดักชัน รับมือกับปัญหาในโปรดักชัน และงานอื่น ๆ อีกมาก คำพูดที่ว่า “AI จะมาแทนนักพัฒนา” หมายความว่า AI ต้องเก่งในทุกงานที่กล่าวมาข้างต้น แต่ถ้าดูจากรายการนี้ บางงานอาจถูกทำให้อัตโนมัติได้ในอนาคต ทว่าหลายงานยังดูเหมือนเป็นสิ่งที่ยังทำให้อัตโนมัติไม่ได้ในตอนนี้ การจัดระดับระบบอัตโนมัติของรถยนต์ขับเคลื่อนอัตโนมัติ วงการรถยนต์ไร้คนขับได้พัฒนาวิธีจัดระดับของระบบอัตโนมัติขึ้นมา การจัดระดับนี้ช่วยอธิบายได้อย่างชัดเจนว่าเทคโนโลยีปัจจุบันทำอะไรได้ และหลีกเลี่ยงการมองแบบขาวกับดำ หากนำแนวคิดนี้มาใช้กับการพัฒนาซอฟต์แวร์ด้วย AI ระดับต่ำสุดคือสิ่งที่เราเคยมีมาก่อน นั่นคือขั้นที่ AI ไม่ได้เข้ามาเกี่ยวข้องกับงาน แน่นอนว่าเรามีระบบอัตโนมัติแบบอื่นอยู่แล้ว เช่น compiler หรือ build process แต่สิ่งเหล่านี้ไม่ใช่ AI เป็นระบบอัตโนมัติแบบกำหนดแน่นอนที่มนุษย์เขียนขึ้น ระดับถัดมาคือสิ่งที่เรามีอยู่ตอนนี้ นักพัฒนาใช้ ChatGPT หรือ GitHub Copilot เพื่อช่วยงาน นักพัฒนาใช้มันในการเขียนเทสต์ เขียนโค้ดสำเร็จรูป รีแฟกเตอร์ และทำความเข้าใจโค้ด/ข้อผิดพลาด เราสามารถคุยกับมันเหมือนคุยกับเพื่อนร่วมงานนักพัฒนาผ่านแชตเพื่อถามคำถามและขอความช่วยเหลือได้ แต่เพราะมันไม่มีสิทธิ์เข้าถึงคอมพิวเตอร์ จึงยังไม่สามารถสร้างไฟล์ รันคำสั่ง build หรือดีพลอยขึ้นโปรดักชันได้ ระดับสูงสุดคือการมอบหมายบางส่วนหรือทั้งหมดของโปรเจกต์ให้ “AI coder” AI coder รับ requirement เขียนโค้ด แก้ข้อผิดพลาด และดีพลอยผลิตภัณฑ์สุดท้ายขึ้นโปรดักชัน เดิมทีคิดว่าคงต้องใช้เวลาอีกหลายเดือนกว่าสิ่งนี้จะเกิดขึ้น แต่ตอนนี้เดโมของ Devin พิสูจน์ให้เห็นแล้วว่า แม้ตอนนี้จะยังทำได้แค่งานพัฒนาที่ไม่ซับซ้อน แต่ก็มีโอกาสพัฒนาไปได้อีกในอนาคต Devin, วิศวกรซอฟต์แวร์ AI คนแรก นอกจากความสามารถของโมเดล AI แล้ว ยังต้องคิดด้วยว่าโซลูชันนั้นแม่นยำแค่ไหน โมเดลเหล่านี้มักมีแนวโน้มจะ hallucinate หรือจำเป็นต้องป้อน prompt ในรูปแบบเฉพาะเพื่อให้ได้สิ่งที่ต้องการ สิ่งนี้ทำให้เกิดแรงเสียดทานในการนำไปใช้ และทำให้คนส่วนใหญ่เลิกใช้ผู้ช่วย AI ตั้งแต่จุดนี้ แต่เรื่องนี้ก็กำลังดีขึ้นเช่นกัน และในโมเดลรุ่นใหม่ก็ไม่จำเป็นต้องใช้ prompt engineering มากเท่าเดิมแล้ว อีกทั้งโมเดลควรสามารถท่องเว็บเพื่อ “เรียนรู้” ได้ แทนที่จะพึ่งพาแต่ข้อมูลฝึกเพียงอย่างเดียว เรื่องนี้สำคัญมากเมื่อมีไลบรารีและภาษาโปรแกรมเวอร์ชันใหม่ออกมาอย่างต่อเนื่อง กรอบคิด: การพัฒนาซอฟต์แวร์แบบเอาต์ซอร์ซ เมื่อสร้างขีดความสามารถขึ้นมาได้แล้ว คำถามคือสิ่งนี้จะส่งผลอย่างไรต่อโครงสร้างทีมและองค์กร? บริษัททำการพัฒนาซอฟต์แวร์ได้หลายรูปแบบ: ทำเองทั้งหมดภายในองค์กร ทำเองเป็นหลักภายในองค์กร โดยมี vendor เพียงไม่กี่ราย ทำเองในองค์กรเพียงเล็กน้อย โดยมี vendor หลายราย ใช้ vendor ทั้งหมด เราอาจมอง AI coder เป็น vendor/consultant ด้านซอฟต์แวร์ที่ถูกเอาต์ซอร์ซมาก็ได้ สิ่งสำคัญคือทีมภายในบริษัทต้องคอยกำกับดูแลงานของ vendor ปัญหานี้อาจแก้ด้วยสัญญาได้ แต่โดยทั่วไปสัญญามักใช้ได้กับผู้ให้บริการหรือโปรเจกต์เฉพาะ และไม่สามารถบังคับเป้าหมายระยะยาวได้ด้วยวิธีนี้ การมีทีมภายในขนาดเล็กที่สามารถชี้นำ vendor ได้จึงเป็นเรื่องที่ดี ในทำนองเดียวกัน แม้จะสามารถเช่า AI coder ได้เหมือนเช่า EC2 instance การมีทีมภายในที่ประกอบด้วยนักพัฒนาซอฟต์แวร์คอยกำกับงานก็ยังเป็นประโยชน์ กรอบคิด: การพัฒนาซอฟต์แวร์คือการทำแบบจำลองความซับซ้อน เมื่อต้องพูดถึงการแก้ปัญหาทางธุรกิจ เราอาจยก Excel มาเป็นตัวอย่างได้ Excel มีอุปสรรคในการเริ่มต้นต่ำมาก จึงสามารถใช้จัดระเบียบข้อมูล ทำการวิเคราะห์ข้อมูล หรือทำบางกระบวนการให้เป็นอัตโนมัติได้ แต่ไม่เหมาะกับเวิร์กโฟลว์ทางธุรกิจที่ซับซ้อน เพราะไม่มีความสามารถอย่างการควบคุมสิทธิ์การเข้าถึงแบบละเอียด การเชื่อมต่อกับระบบที่ไม่รองรับ การทดสอบได้ การนำกลับมาใช้ซ้ำ หรือประเด็นเรื่องการผูกติดกับผู้ให้บริการ โซลูชัน “low-code” อย่าง Power Automate ก็เช่นเดียวกัน “ผู้ใช้ฝั่งธุรกิจจะสามารถใช้ AI coder เพื่อสร้างเวิร์กโฟลว์ที่ซับซ้อนเหล่านี้ได้โดยไม่ต้องพึ่งนักพัฒนาซอฟต์แวร์หรือไม่?” ถ้าคิดดูให้ดี Excel และเครื่องมือ low-code มีมาหลายสิบปีแล้ว แล้วทำไมอาชีพนักพัฒนาซอฟต์แวร์จึงยังคงอยู่? เพราะเรามักคิดว่าการพัฒนาซอฟต์แวร์คือแค่การเขียนโค้ด ปัญหาที่ซับซ้อนต้องการคนที่สามารถจัดการความซับซ้อนนั้นได้อย่างมีประสิทธิภาพ และแปลงปัญหาทางธุรกิจให้เป็นโมเดลดิจิทัลในโดเมนจริง พูดอีกแบบคือ ต่อให้คุณสร้างเพิงไม้จากวิดีโอสอนใน YouTube ได้โดยไม่ต้องมีวิศวกรโยธาช่วย ก็ไม่ได้แปลว่าคุณจะสร้างอาคาร 10 ชั้นได้แบบเดียวกันหรือควรทำเช่นนั้น หากเรียนรู้วิธีทำสิ่งนี้อย่างถูกต้องไปเรื่อย ๆ คุณก็อาจค่อย ๆ กลายเป็นวิศวกรโยธาได้ เพียงแต่คำถามคือคุณจะลงทุนเวลาเพื่อเรียนรู้ให้ถูกต้อง หรือจะจ้างวิศวกรที่มีทักษะอยู่แล้ว ดังนั้น ไม่ว่าจะใช้ Excel หรือ AI coder รุ่นล่าสุด ถ้าคุณกำลังทำแบบจำลองตรรกะที่ซับซ้อนอยู่ ผมก็ยังมองว่าคุณคือนักพัฒนาซอฟต์แวร์ ต่างกันเพียงแค่เครื่องมือที่ใช้แสดงความต้องการทางธุรกิจ เช่น สูตรในสเปรดชีต โค้ด หรือ prompt กรอบคิด: ขนาดของพาย ความกังวลส่วนใหญ่เกี่ยวกับเรื่องนี้ตั้งอยู่บนสมมติฐานว่าขนาดของตลาดการพัฒนาซอฟต์แวร์จะคงเดิม กล่าวคือ AI coder จะค่อย ๆ แย่ง “ส่วนแบ่งตลาด” มาจากมนุษย์ แต่เพราะตลาดของ “การแก้ปัญหาทางธุรกิจ” มีขนาดใหญ่กว่าตลาดการพัฒนาซอฟต์แวร์มาก การพัฒนาซอฟต์แวร์จึงไม่น่าจะหายไปในเร็ว ๆ นี้ กรอบคิด: การนิยามตรรกะทางธุรกิจอย่างเป็นทางการ ตรรกะทางธุรกิจต้องถูกนิยามในรูปแบบที่ชัดเจนและเป็นทางการเสมอ ด้วยเหตุนี้ ภาษาโปรแกรมจึงใช้คำภาษาอังกฤษอย่าง if, switch เป็นต้น แต่ก็กำหนดความหมายของคำเหล่านั้นไว้อย่างเข้มงวดมาก และถ้าใช้คำผิดก็จะไม่ทำงาน ลองคิดดูแล้วสูตร Excel หรือ flow แบบ low-code ก็ไม่ต่างกัน ในอนาคต แม้ AI coder จะสามารถสร้างผลิตภัณฑ์ซอฟต์แวร์จากคำสั่งที่ให้มาเป็นภาษาอังกฤษเชิงสนทนาได้ ผมก็คิดว่านิยามอย่างเป็นทางการพื้นฐานของตรรกะทางธุรกิจที่ถูกสร้างขึ้นในฝั่ง backend ก็ยังคงมีอยู่ มันอาจมีหน้าตาแตกต่างจากภาษาและเฟรมเวิร์กที่เราใช้กันในปัจจุบันมาก แต่การนิยามตรรกะทางธุรกิจอย่างเป็นทางการนั้นฟังดูคล้าย “โค้ด” มากอยู่ดี จนกว่า AI coder จะสามารถสร้างตรรกะทางธุรกิจเหล่านี้จากภาษาอังกฤษเชิงสนทนาได้อย่างเป็นระบบแบบกำหนดแน่นอน ก็ยังจำเป็นต้องมีคนที่เข้าใจโค้ดที่ถูกสร้างขึ้นในฝั่ง backend และปรับแก้ได้เมื่อจำเป็น ซึ่งก็คือนักพัฒนาซอฟต์แวร์ บทสรุป ลักษณะของงานจะเปลี่ยนไป และเครื่องมือที่เราใช้ก็จะต่างจากทุกวันนี้มาก แต่ผมคิดว่าในอนาคตอันใกล้ ตลาดสำหรับนักพัฒนาซอฟต์แวร์ก็จะยังคงมีอยู่

(sheshbabu.com)

39 คะแนน โดย xguru 2024-03-25 | 7 ความคิดเห็น | แชร์ทาง WhatsApp

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

กรอบคิด: ระดับความสามารถในการพัฒนาซอฟต์แวร์

การพัฒนาซอฟต์แวร์ไม่ได้มีแค่การเขียนโค้ดเท่านั้น
ภาพจำของโปรแกรมเมอร์คือคนนั่งพิมพ์โค้ดอย่างขะมักเขม้นอยู่หน้าคอมพิวเตอร์ในห้องมืด แต่ในความเป็นจริง พวกเขาใช้เวลากับงานอื่นมากกว่าการเขียนโค้ด
- เก็บความต้องการจากผู้ใช้ฝั่งธุรกิจ
- กลั่นกรองความต้องการให้อยู่ในรูปแบบที่สามารถโมเดลเป็นโค้ดได้
- ทำภาพและวางแผนโซลูชันร่วมกับเพื่อนร่วมทีม เช่น ดีไซเนอร์และผู้จัดการผลิตภัณฑ์
- ออกแบบและขัดเกลางานเชิงเทคนิคร่วมกับนักพัฒนาคนอื่น
- ตั้งค่าโครงสร้างพื้นฐาน การคอนฟิก โค้ด boilerplate ฯลฯ
- เขียนโค้ดจริง
- ดีบัก ทำความเข้าใจโค้ดของคนอื่น เขียนเอกสาร ฯลฯ
- ดีพลอยขึ้นโปรดักชัน
- รับมือกับปัญหาในโปรดักชัน
- และงานอื่น ๆ อีกมาก
คำพูดที่ว่า “AI จะมาแทนนักพัฒนา” หมายความว่า AI ต้องเก่งในทุกงานที่กล่าวมาข้างต้น
แต่ถ้าดูจากรายการนี้ บางงานอาจถูกทำให้อัตโนมัติได้ในอนาคต ทว่าหลายงานยังดูเหมือนเป็นสิ่งที่ยังทำให้อัตโนมัติไม่ได้ในตอนนี้

การจัดระดับระบบอัตโนมัติของรถยนต์ขับเคลื่อนอัตโนมัติ

วงการรถยนต์ไร้คนขับได้พัฒนาวิธีจัดระดับของระบบอัตโนมัติขึ้นมา
การจัดระดับนี้ช่วยอธิบายได้อย่างชัดเจนว่าเทคโนโลยีปัจจุบันทำอะไรได้ และหลีกเลี่ยงการมองแบบขาวกับดำ
หากนำแนวคิดนี้มาใช้กับการพัฒนาซอฟต์แวร์ด้วย AI
- ระดับต่ำสุดคือสิ่งที่เราเคยมีมาก่อน นั่นคือขั้นที่ AI ไม่ได้เข้ามาเกี่ยวข้องกับงาน แน่นอนว่าเรามีระบบอัตโนมัติแบบอื่นอยู่แล้ว เช่น compiler หรือ build process แต่สิ่งเหล่านี้ไม่ใช่ AI เป็นระบบอัตโนมัติแบบกำหนดแน่นอนที่มนุษย์เขียนขึ้น
- ระดับถัดมาคือสิ่งที่เรามีอยู่ตอนนี้
  - นักพัฒนาใช้ ChatGPT หรือ GitHub Copilot เพื่อช่วยงาน
  - นักพัฒนาใช้มันในการเขียนเทสต์ เขียนโค้ดสำเร็จรูป รีแฟกเตอร์ และทำความเข้าใจโค้ด/ข้อผิดพลาด
  - เราสามารถคุยกับมันเหมือนคุยกับเพื่อนร่วมงานนักพัฒนาผ่านแชตเพื่อถามคำถามและขอความช่วยเหลือได้ แต่เพราะมันไม่มีสิทธิ์เข้าถึงคอมพิวเตอร์ จึงยังไม่สามารถสร้างไฟล์ รันคำสั่ง build หรือดีพลอยขึ้นโปรดักชันได้
- ระดับสูงสุดคือการมอบหมายบางส่วนหรือทั้งหมดของโปรเจกต์ให้ “AI coder”
  - AI coder รับ requirement เขียนโค้ด แก้ข้อผิดพลาด และดีพลอยผลิตภัณฑ์สุดท้ายขึ้นโปรดักชัน
  - เดิมทีคิดว่าคงต้องใช้เวลาอีกหลายเดือนกว่าสิ่งนี้จะเกิดขึ้น แต่ตอนนี้เดโมของ Devin พิสูจน์ให้เห็นแล้วว่า แม้ตอนนี้จะยังทำได้แค่งานพัฒนาที่ไม่ซับซ้อน แต่ก็มีโอกาสพัฒนาไปได้อีกในอนาคต Devin, วิศวกรซอฟต์แวร์ AI คนแรก
นอกจากความสามารถของโมเดล AI แล้ว ยังต้องคิดด้วยว่าโซลูชันนั้นแม่นยำแค่ไหน
- โมเดลเหล่านี้มักมีแนวโน้มจะ hallucinate หรือจำเป็นต้องป้อน prompt ในรูปแบบเฉพาะเพื่อให้ได้สิ่งที่ต้องการ
- สิ่งนี้ทำให้เกิดแรงเสียดทานในการนำไปใช้ และทำให้คนส่วนใหญ่เลิกใช้ผู้ช่วย AI ตั้งแต่จุดนี้
- แต่เรื่องนี้ก็กำลังดีขึ้นเช่นกัน และในโมเดลรุ่นใหม่ก็ไม่จำเป็นต้องใช้ prompt engineering มากเท่าเดิมแล้ว
อีกทั้งโมเดลควรสามารถท่องเว็บเพื่อ “เรียนรู้” ได้ แทนที่จะพึ่งพาแต่ข้อมูลฝึกเพียงอย่างเดียว
- เรื่องนี้สำคัญมากเมื่อมีไลบรารีและภาษาโปรแกรมเวอร์ชันใหม่ออกมาอย่างต่อเนื่อง

กรอบคิด: การพัฒนาซอฟต์แวร์แบบเอาต์ซอร์ซ

เมื่อสร้างขีดความสามารถขึ้นมาได้แล้ว คำถามคือสิ่งนี้จะส่งผลอย่างไรต่อโครงสร้างทีมและองค์กร? บริษัททำการพัฒนาซอฟต์แวร์ได้หลายรูปแบบ:
- ทำเองทั้งหมดภายในองค์กร
- ทำเองเป็นหลักภายในองค์กร โดยมี vendor เพียงไม่กี่ราย
- ทำเองในองค์กรเพียงเล็กน้อย โดยมี vendor หลายราย
- ใช้ vendor ทั้งหมด
เราอาจมอง AI coder เป็น vendor/consultant ด้านซอฟต์แวร์ที่ถูกเอาต์ซอร์ซมาก็ได้
สิ่งสำคัญคือทีมภายในบริษัทต้องคอยกำกับดูแลงานของ vendor
- ปัญหานี้อาจแก้ด้วยสัญญาได้ แต่โดยทั่วไปสัญญามักใช้ได้กับผู้ให้บริการหรือโปรเจกต์เฉพาะ และไม่สามารถบังคับเป้าหมายระยะยาวได้ด้วยวิธีนี้
- การมีทีมภายในขนาดเล็กที่สามารถชี้นำ vendor ได้จึงเป็นเรื่องที่ดี
- ในทำนองเดียวกัน แม้จะสามารถเช่า AI coder ได้เหมือนเช่า EC2 instance การมีทีมภายในที่ประกอบด้วยนักพัฒนาซอฟต์แวร์คอยกำกับงานก็ยังเป็นประโยชน์

กรอบคิด: การพัฒนาซอฟต์แวร์คือการทำแบบจำลองความซับซ้อน

เมื่อต้องพูดถึงการแก้ปัญหาทางธุรกิจ เราอาจยก Excel มาเป็นตัวอย่างได้
Excel มีอุปสรรคในการเริ่มต้นต่ำมาก จึงสามารถใช้จัดระเบียบข้อมูล ทำการวิเคราะห์ข้อมูล หรือทำบางกระบวนการให้เป็นอัตโนมัติได้
แต่ไม่เหมาะกับเวิร์กโฟลว์ทางธุรกิจที่ซับซ้อน เพราะไม่มีความสามารถอย่างการควบคุมสิทธิ์การเข้าถึงแบบละเอียด การเชื่อมต่อกับระบบที่ไม่รองรับ การทดสอบได้ การนำกลับมาใช้ซ้ำ หรือประเด็นเรื่องการผูกติดกับผู้ให้บริการ
โซลูชัน “low-code” อย่าง Power Automate ก็เช่นเดียวกัน
“ผู้ใช้ฝั่งธุรกิจจะสามารถใช้ AI coder เพื่อสร้างเวิร์กโฟลว์ที่ซับซ้อนเหล่านี้ได้โดยไม่ต้องพึ่งนักพัฒนาซอฟต์แวร์หรือไม่?”
ถ้าคิดดูให้ดี Excel และเครื่องมือ low-code มีมาหลายสิบปีแล้ว แล้วทำไมอาชีพนักพัฒนาซอฟต์แวร์จึงยังคงอยู่?
เพราะเรามักคิดว่าการพัฒนาซอฟต์แวร์คือแค่การเขียนโค้ด
ปัญหาที่ซับซ้อนต้องการคนที่สามารถจัดการความซับซ้อนนั้นได้อย่างมีประสิทธิภาพ และแปลงปัญหาทางธุรกิจให้เป็นโมเดลดิจิทัลในโดเมนจริง
พูดอีกแบบคือ ต่อให้คุณสร้างเพิงไม้จากวิดีโอสอนใน YouTube ได้โดยไม่ต้องมีวิศวกรโยธาช่วย ก็ไม่ได้แปลว่าคุณจะสร้างอาคาร 10 ชั้นได้แบบเดียวกันหรือควรทำเช่นนั้น
- หากเรียนรู้วิธีทำสิ่งนี้อย่างถูกต้องไปเรื่อย ๆ คุณก็อาจค่อย ๆ กลายเป็นวิศวกรโยธาได้
- เพียงแต่คำถามคือคุณจะลงทุนเวลาเพื่อเรียนรู้ให้ถูกต้อง หรือจะจ้างวิศวกรที่มีทักษะอยู่แล้ว
ดังนั้น ไม่ว่าจะใช้ Excel หรือ AI coder รุ่นล่าสุด ถ้าคุณกำลังทำแบบจำลองตรรกะที่ซับซ้อนอยู่ ผมก็ยังมองว่าคุณคือนักพัฒนาซอฟต์แวร์
ต่างกันเพียงแค่เครื่องมือที่ใช้แสดงความต้องการทางธุรกิจ เช่น สูตรในสเปรดชีต โค้ด หรือ prompt

กรอบคิด: ขนาดของพาย

ความกังวลส่วนใหญ่เกี่ยวกับเรื่องนี้ตั้งอยู่บนสมมติฐานว่าขนาดของตลาดการพัฒนาซอฟต์แวร์จะคงเดิม กล่าวคือ AI coder จะค่อย ๆ แย่ง “ส่วนแบ่งตลาด” มาจากมนุษย์
แต่เพราะตลาดของ “การแก้ปัญหาทางธุรกิจ” มีขนาดใหญ่กว่าตลาดการพัฒนาซอฟต์แวร์มาก การพัฒนาซอฟต์แวร์จึงไม่น่าจะหายไปในเร็ว ๆ นี้

กรอบคิด: การนิยามตรรกะทางธุรกิจอย่างเป็นทางการ

ตรรกะทางธุรกิจต้องถูกนิยามในรูปแบบที่ชัดเจนและเป็นทางการเสมอ
ด้วยเหตุนี้ ภาษาโปรแกรมจึงใช้คำภาษาอังกฤษอย่าง if, switch เป็นต้น แต่ก็กำหนดความหมายของคำเหล่านั้นไว้อย่างเข้มงวดมาก และถ้าใช้คำผิดก็จะไม่ทำงาน ลองคิดดูแล้วสูตร Excel หรือ flow แบบ low-code ก็ไม่ต่างกัน
ในอนาคต แม้ AI coder จะสามารถสร้างผลิตภัณฑ์ซอฟต์แวร์จากคำสั่งที่ให้มาเป็นภาษาอังกฤษเชิงสนทนาได้ ผมก็คิดว่านิยามอย่างเป็นทางการพื้นฐานของตรรกะทางธุรกิจที่ถูกสร้างขึ้นในฝั่ง backend ก็ยังคงมีอยู่
มันอาจมีหน้าตาแตกต่างจากภาษาและเฟรมเวิร์กที่เราใช้กันในปัจจุบันมาก แต่การนิยามตรรกะทางธุรกิจอย่างเป็นทางการนั้นฟังดูคล้าย “โค้ด” มากอยู่ดี
จนกว่า AI coder จะสามารถสร้างตรรกะทางธุรกิจเหล่านี้จากภาษาอังกฤษเชิงสนทนาได้อย่างเป็นระบบแบบกำหนดแน่นอน ก็ยังจำเป็นต้องมีคนที่เข้าใจโค้ดที่ถูกสร้างขึ้นในฝั่ง backend และปรับแก้ได้เมื่อจำเป็น ซึ่งก็คือนักพัฒนาซอฟต์แวร์

บทสรุป

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

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

xguru 2024-03-31

Devin, วิศวกรซอฟต์แวร์ AI คนแรก
OpenDevin - อิมพลีเมนเทชันโอเพนซอร์สของ Devin วิศวกรซอฟต์แวร์ AI

dhlee0305 2024-03-25

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

edunga1 2024-03-25

เหมือนกับเนื้อหาและโพสต์ https://th.news.hada.io/topic?id=13557
ตอนนี้สัดส่วนงานของนักพัฒนาจะต้องลดลงอย่างชัดเจน และคงจะยิ่งเร่งตัวขึ้นใช่ไหม?

ahwjdekf 2024-03-25

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

colus001 2024-03-25

ผมคิดว่าโค้ดมีไว้เพื่อมนุษย์ และการที่เครื่องจักรเขียนโค้ดก็หมายความว่ามนุษย์ยังคงจำเป็นอยู่ ดังนั้นจึงไม่น่าใช่ทิศทางการพัฒนาในอนาคตอันไกลนัก ผมมองว่าน่าจะพัฒนาไปในรูปแบบที่เราโยนคำถามที่ต้องการเข้าไปในกล่องดำบางอย่าง คล้ายกับ backend-GPT ที่เคยทดลองในช่วงแรก (https://github.com/RootbeerComputer/backend-GPT) ให้มันเข้าถึง DB เพื่อประมวลผลข้อมูล และมีมนุษย์เข้าไปมีส่วนร่วมบางส่วนกับประสบการณ์ก่อนและหลังจากนั้น

kaistj 2024-03-25

ดูเหมือนว่าในบรรดาประเด็นที่ผู้คนพูดถึงกันมากเกี่ยวกับ ChatGPT และ Copilot จะมีการกล่าวถึงเรื่อง prompt engineering อยู่บ่อย ๆ ผมคิดว่าองค์ประกอบสำคัญอีกอย่างคือ เราจะถ่ายทอดและสื่อสารกับ AI coder อย่างมีประสิทธิภาพได้อย่างไร โดยอาศัยกระบวนการที่พวกเรามักใช้กันในการเขียนโปรแกรม เช่น การประชุม การสื่อสารกันด้วยคำพูดอย่างรวดเร็ว แล้วก็สรุปและตรวจสอบความเข้าใจ ^^.

vbmania 2024-03-25

> คำพูดที่ว่า “AI จะเข้ามาแทนที่นักพัฒนา” หมายความว่า AI ต้องเชี่ยวชาญกับงานทั้งหมดข้างต้น

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