งานวิจัยใหม่เกี่ยวกับ GitHub Copilot พบว่าเกิด ‘แรงกดดันขาลงต่อคุณภาพโค้ด’
(visualstudiomagazine.com)- เอกสารไวต์เปเปอร์ Coding on Copilot ของ GitClear วิเคราะห์จากข้อมูลการเปลี่ยนแปลงโค้ดว่า โค้ดที่มี AI ช่วยเขียนอาจเพิ่มประสิทธิภาพการทำงาน แต่ก็อาจสร้างภาระต่อคุณภาพและความสามารถในการบำรุงรักษาได้หรือไม่
- Code churn ซึ่งคือโค้ดที่ถูกย้อนกลับหรือแก้ไขภายใน 2 สัปดาห์หลังเขียน คาดว่าจะเพิ่มเป็นสองเท่าในปี 2024 เมื่อเทียบกับค่าฐานก่อนยุค AI ในปี 2021
- หลังการแพร่หลายของ Copilot สัดส่วนของ โค้ดที่เพิ่มเข้าไป และ โค้ดที่คัดลอก/วาง เพิ่มขึ้น ขณะที่โค้ดที่ถูกย้ายลดลง ซึ่งชี้ให้เห็นถึงการอ่อนตัวลงของการรีแฟกเตอร์และการนำกลับมาใช้ซ้ำ
- งานวิจัยของ GitHub ในปี 2022 ระบุว่าผู้ใช้ Copilot ทำงานเสร็จ เร็วขึ้น 55% แต่ GitClear มุ่งเน้นที่ต้นทุนการบำรุงรักษาระยะยาวมากกว่าประสิทธิภาพการทำงาน
- การวิเคราะห์โค้ดที่ถูกเปลี่ยนแปลงจำนวน 153 ล้านบรรทัด ซึ่งเขียนขึ้นระหว่างเดือนมกราคม 2020 ถึงธันวาคม 2023 แสดงให้เห็นว่าผู้นำด้านเทคนิคควรประเมินผลของการนำ AI มาใช้ด้วยตัวชี้วัดคุณภาพโค้ด
ลักษณะของโค้ดที่มี AI ช่วยเขียนตามมุมมองของไวต์เปเปอร์ GitClear
- ไวต์เปเปอร์ Coding on Copilot ศึกษาว่าโค้ดที่มี AI ช่วยเขียนมีความแตกต่างด้าน คุณภาพ และ ความสามารถในการบำรุงรักษา อย่างไรเมื่อเทียบกับโค้ดที่มนุษย์น่าจะเขียนเอง
- คำถามหลักคือ โค้ดที่มี AI ช่วยเขียนนั้นใกล้เคียงกับผลงานของนักพัฒนาระดับซีเนียร์ที่ผ่านการขัดเกลาอย่างรอบคอบ หรือใกล้เคียงกับงานที่ขาดความต่อเนื่องของผู้รับจ้างระยะสั้นมากกว่ากัน
- GitClear เป็นบริษัทที่ขาย เครื่องมือรีวิวโค้ด บนคลาวด์ และงานวิจัยครั้งนี้มุ่งดูว่าองค์ประกอบของการเปลี่ยนแปลงโค้ดเปลี่ยนไปอย่างไรหลังมีการใช้ AI
สัญญาณเชิงลบที่ปรากฏในด้านการบำรุงรักษา
- GitClear พบแนวโน้มที่น่ากังวลในด้านความสามารถในการบำรุงรักษา
- Code churn คือสัดส่วนของบรรทัดโค้ดที่ถูกย้อนกลับหรืออัปเดตภายใน 2 สัปดาห์หลังเขียน
- สัดส่วนนี้คาดว่าจะเพิ่มเป็นสองเท่าในปี 2024 เมื่อเทียบกับค่าฐานก่อนยุค AI ในปี 2021
- สัดส่วนของ โค้ดที่เพิ่มเข้าไป และ โค้ดที่คัดลอก/วาง เพิ่มขึ้นเมื่อเทียบกับโค้ดที่ถูกแก้ไข ลบ หรือย้าย
- จากการเปลี่ยนแปลงเหล่านี้ จึงมีการประเมินว่าโค้ดที่สร้างโดย AI คล้ายกับผลงานของผู้มีส่วนร่วมแบบผ่านไปผ่านมา ที่มักละเมิดหลักการ DRY ของรีโพซิทอรีที่ตนเข้ามาแก้ไข
การเปลี่ยนแปลง 3 อย่างที่เชื่อมโยงกับการแพร่หลายของ Copilot
- GitClear ระบุว่า churn, โค้ดที่ถูกย้าย, และ โค้ดที่คัดลอก/วาง คือการเปลี่ยนแปลงสำคัญหลังการนำ Copilot มาใช้
-
churn ที่เพิ่มขึ้น
- มองว่า “การใช้ Copilot” มีความสัมพันธ์อย่างมากกับการ push โค้ดที่ผิดพลาด เข้ารีโพซิทอรี
- เชื่อมโยงกับแนวโน้มที่โค้ดซึ่งมี AI ช่วยเขียนถูกเพิ่มเข้ามาอย่างรวดเร็ว แล้วถูกย้อนกลับหรือแก้ไขภายในเวลาอันสั้น
-
โค้ดที่ถูกย้ายลดลง
- การลดลงของโค้ดที่ถูกย้ายบ่งชี้ถึงการลดลงของ การรีแฟกเตอร์ และ การนำกลับมาใช้ซ้ำ
- เมื่อดูร่วมกับการเพิ่มขึ้นของโค้ดคัดลอก/วาง จึงตีความได้ว่าการทำงานของ AI assistant ในปัจจุบันยังไม่ได้ส่งเสริมการใช้โค้ดซ้ำอย่างเพียงพอ
- แทนที่จะสร้างโค้ดแบบ DRY ผ่านการรีแฟกเตอร์ กลับมอบสิ่งล่อใจให้ทำซ้ำโค้ดเดิมได้ด้วยการกดปุ่มเพียงครั้งเดียว
-
โค้ดคัดลอก/วางที่เพิ่มขึ้น
- โค้ดที่คัดลอก/วาง ถูกประเมินว่าเป็นปัจจัยที่สร้างภาระหนักต่อการบำรุงรักษาระยะยาว
- เมื่อมีการทำซ้ำเป็นบรรทัดโค้ด ไม่ใช่แค่คีย์เวิร์ด ก็อาจตีความได้ว่าไม่มีเวลาประเมิน implementation เดิมอย่างเพียงพอ
- หากเพิ่มโค้ดซ้ำเข้าไปแทนการนำโค้ดเดิมกลับมาใช้ ผู้ดูแลในภายหลังจะต้องมารวมเส้นทางโค้ดแบบขนานที่ทำหน้าที่ซ้ำกัน
เทียบกับงานวิจัยด้านประสิทธิภาพการทำงาน
- งานวิจัยของ GitHub ในปี 2022 ระบุว่านักพัฒนาที่ใช้ Copilot ทำงานเสร็จ เร็วขึ้น 55% เมื่อเทียบกับนักพัฒนาที่ไม่ใช้
- งานวิจัยชิ้นเดียวกันยังวัดผลเชิงบวกต่อความพึงพอใจของนักพัฒนาและการรักษาพลังงานทางจิตใจ นอกเหนือจากประสิทธิภาพการทำงาน
- ตรงกันข้ามกับผลด้านประสิทธิภาพดังกล่าว ไวต์เปเปอร์ของ GitClear มุ่งวิเคราะห์การเปลี่ยนแปลงขององค์ประกอบการเปลี่ยนแปลงโค้ดและความสามารถในการบำรุงรักษาเมื่อมีการใช้ AI
การประเมินที่แตกต่างกันจากงานวิจัยที่เกี่ยวข้อง
- Exploring the Verifiability of Code Generated by GitHub Copilot: พบหลักฐานที่สอดคล้องกับฉันทามติในวรรณกรรมเดิมว่า Copilot เป็นเครื่องมือที่ทรงพลัง แต่ไม่ควรปล่อยให้ “ขับเครื่องบิน” ตามลำพัง
- Assessing the Quality of GitHub Copilot's Code Generation: จากการวิเคราะห์เชิงประจักษ์ Copilot เป็นเครื่องมือที่มีอนาคต แต่ยังต้องมีการประเมินที่ครอบคลุมมากขึ้นในอนาคต
- Sea Change in Software Development: Economic and Productivity Analysis of the AI-Powered Developer Lifecycle: เมื่อทักษะในการ prompt generative AI เพิ่มขึ้น ก็เกิดความเชื่อมโยงเฉพาะตัวระหว่างมนุษย์กับ AI ที่ยากจะแยกออกจากกัน
- The Impact of AI on Developer Productivity: Evidence from GitHub Copilot: ผลกระทบที่แตกต่างกันซึ่งสังเกตได้ แสดงให้เห็นว่า AI pair programmer อาจช่วยให้ผู้คนเปลี่ยนเข้าสู่อาชีพการพัฒนาซอฟต์แวร์ได้
- Study of software developers' experience using the Github Copilot Tool in the software development process: ความเห็นของนักพัฒนาแบ่งออกเป็นหลายทาง และแม้ทัศนคติโดยรวมจะค่อนข้างบวก แต่ความตั้งใจใช้งานจริงไม่สูงนัก และมีความกังวลด้านความปลอดภัย
ขอบเขตการวิเคราะห์และคำถามที่ยังเหลืออยู่
- GitClear รวบรวมและวิเคราะห์โค้ดที่ถูกเปลี่ยนแปลงจำนวน 153 ล้านบรรทัด ซึ่งเขียนขึ้นระหว่างเดือนมกราคม 2020 ถึงธันวาคม 2023
- พร้อมกันนั้นยังชี้ว่า เรากำลังก้าวเข้าสู่ยุคที่มีการเพิ่มบรรทัดโค้ดเร็วกว่าเวลาใด ๆ เนื่องจากความนิยมของ AI ที่พุ่งสูงขึ้น
- คำถามของปี 2024 จึงอาจไม่ใช่ว่า Copilot จะเปลี่ยนความหมายของการเป็นนักพัฒนาอย่างไร แต่เป็นว่าใครจะเป็นผู้รับหน้าที่เก็บกวาดงานที่ตามมาหลังจากนั้น
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
ใช้อยู่ 2 เดือนแล้วก็ยกเลิกสมาชิกไป ต้นทุนทางใจจากการต้องตามแก้ความผิดพลาดของ โค้ดอ้วกแตก ที่มันถาโถมมาเยอะเกินไป และกับงานที่ไม่ใช่งานจุกจิกหรืองานเกี่ยวกับ SQL ต่อให้ใส่สคีมาทั้งหมดให้ก่อนก็แทบไม่มีประโยชน์
เพราะผมรู้อยู่แล้วว่าอยากเขียนอะไร การเขียนเองเลยเหนื่อยน้อยกว่ามาก และการแก้ความผิดพลาดของตัวเองก็ง่ายกว่าการแก้ความผิดพลาดของบอต ผมห่วงพวกระดับจูเนียร์ที่จะต้องจมอยู่ใต้กองขยะนี่
ผมใช้ ChatGPT แทน Copilot แล้วก็ทึ่งว่ามันทำอะไรได้เยอะมาก แต่ก็ยังเรียกว่าเป็น “โค้ดที่ดี” ได้ไม่เต็มปาก ถึงจะอ่าน JavaScript ได้ แต่ 14 ปีหลังมานี้ผมเชี่ยวชาญ iOS เลยไม่ค่อยรู้แนวปฏิบัติที่ดีฝั่งเบราว์เซอร์นัก ก็เลยใช้มันอยู่ ซึ่งแม้จะได้โค้ดที่โดยรวมทำงานได้ แต่ก็ยังเห็นตัวเลือกที่ไม่ดีหรือจุดแปลก ๆ อยู่
ตอนนี้ผมคิดว่าท่าทีที่ถูกคืออย่าไปสุดโต่งแบบ “มันจบแล้ว” หรือ “มันไม่มีอะไรเลย” กับ AI ฝั่งหลังน่าจะต้องใช้คำเปรียบเทียบประมาณว่า “เหมือนหมาที่เล่นกล juggling, ยื่นภาษี, แล้วก็อบเค้กได้ แต่แทนที่จะทึ่งว่ามันทำได้ คุณกลับบ่นว่ามันทำลูกบอลตก คิดเลขผิด แล้วสูตรก็ไม่ค่อยดี”
Copilot มีประโยชน์ที่สุดในฐานะ เครื่องมือ autocomplete ที่ช่วยลดการพิมพ์เวลาคุณเขียนโค้ดที่คาดเดาได้จากบริบท เช่น เขียน enum class ในหน้าต่างหนึ่ง แล้วให้มัน autocomplete ส่วนที่ถูกใช้งานในอีกหน้าต่างจากบริบท หรือเวลาคุณเขียนชุด unit test มันช่วยสร้างโครงของ test case ถัดไปให้ได้ด้วยการกด Tab ครั้งเดียว
โดยเฉพาะในภาษากลุ่ม dynamic นั้น Copilot ช่วยเสริม IntelliSense ได้ค่อนข้างดี
เมื่อไม่กี่เดือนก่อนผมเคยเขียนถึงแนวโน้มที่อุตสาหกรรมนักพากย์คงเลี่ยงไม่พ้นการถูกโมเดลแปลงข้อความเป็นเสียงแย่งงาน โดยยกตัวอย่างงานเรียงพิมพ์ เข้าเล่ม และเรียงโน้ตเพลงไว้ด้วย: https://news.ycombinator.com/item?id=38491203
แต่ถ้าตัวงานพัฒนาเองถูกทำให้กลวงแบบนี้ ผมก็ไม่แน่ใจว่าปลายทางจะเป็นยังไง เพราะคนที่ขับเคลื่อนการแทนที่ในอดีตก็คือนักพัฒนาเอง รูปแบบหนึ่งของความเสื่อมถอยและการพังทลายทางสังคมก็ดูไม่ใช่เรื่องเหลือเชื่อไปเสียทีเดียว
“พาร์ส JSON นี้แล้วเอาฟิลด์ที่เกี่ยวข้องไปใส่ในตำแหน่งที่ถูกต้องของฐานข้อมูล” เป็นกรณีใช้งานที่ยอดเยี่ยมมากสำหรับการเขียน SQL ด้วย Copilot คุณอาจใช้ ORM plugin หรือ middleware ก็ได้ แต่สำหรับ MVP หรือ mockup นั่นเป็นการ optimize ล่วงหน้ามากเกินไป
ตรงกันข้าม ChatGPT API ผมใช้บ่อยและค่อนข้างสะดวกมาก ตอนเขียน SQL update ที่กระทบข้อมูลหลายล้านแถว ผมให้มันช่วยเปลี่ยนให้แบ่งเป็น batch และพิมพ์สถานะ log หลังแต่ละ batch ส่วนตอนเจอ 401 ตอนเข้าถึง nuget feed ของ Azure DevOps มันไม่เพียงบอกสาเหตุ แต่ยังให้ yaml ที่ใช้แก้มาเลย
ทั้งสองอย่างเป็นเรื่องที่ถ้าศึกษาอีกนิดก็ทำเองได้ แต่การไม่ต้องเสียเวลาไปค้นนี่แหละที่ดีมาก
GPT-4 ทำให้ประสิทธิภาพการทำงานของผมดีขึ้นมาก ผมทำ PHP CRUD app ง่าย ๆ เป็นหลักเพื่อแก้ปัญหางานประจำวัน และไม่ได้ใช้ framework หรือโครงสร้างแบบ MVC ดังนั้นโค้ดที่ GPT-4 สร้างจากคำสั่งที่ชัดเจนจึงเข้าใจง่ายและมักใช้ได้เลย
ปกติผมจะขอให้มันแก้โค้ดสัก 25 บรรทัดให้ตรงกับฟังก์ชันรายงานบางอย่าง เช่น บอกว่าในหน้านี้ให้จัดกลุ่มตาม X และรวมค่า Y มันก็ตอบได้ตรงมาก พอทำ QA และทดสอบแบบเร็ว ๆ ก็จบ และสำหรับงานที่ความซับซ้อนต่ำกับคำสั่งชัดเจน มันมีผลระดับเปลี่ยนเกมเลย
กระบวนการนี้คล้ายกับเวลาซีเนียร์โปรแกรมเมอร์แยกงานออกเป็นองค์ประกอบพื้นฐานแล้วมอบหมายให้จูเนียร์ทำ ซึ่งในที่นี้ GPT-4 ทำหน้าที่เป็นจูเนียร์โปรแกรมเมอร์ราคา 20 ดอลลาร์ต่อเดือน และช่วยประหยัดเวลาให้ผมจนยอมจ่ายเอง
แต่ก็เหมือนตอนเด็ก ๆ ที่ถามว่ามีเครื่องคิดเลขแล้วจะเรียนคณิตไปทำไม ตอนนี้ผมเข้าใจแล้วว่าทำไมยังต้องเรียนพื้นฐาน ถ้าไม่รู้พื้นฐานก็ใช้งานมันอย่างมีประสิทธิภาพไม่ได้ ถ้า GPT-4 มีอยู่ตอนผมกำลังเรียน PHP ผมคงไม่เข้าใจพื้นฐานได้เท่าตอนนี้ ผมได้ประโยชน์จากการที่เรียนมาก่อนที่เครื่องมือพวกนี้จะมี
เรื่องคุณภาพโค้ดก็ไม่ได้รู้สึกว่าแย่ลงเป็นพิเศษ ตรงกันข้าม บางครั้งมันยังให้ผลลัพธ์ที่ขัดเกลากว่าด้วยซ้ำ
คำวิจารณ์จำนวนมากผมมองว่ายังเร็วเกินไป และมันใกล้เคียงกับการก้าวไปข้างหน้าแบบกระท่อนกระแท่นที่ยังต้องการโครงสร้างรองรับเพิ่ม ผมอดสงสัยไม่ได้ว่าการผสาน linter ที่ช่วยไม่ให้มันสร้างผลลัพธ์ที่คอมไพล์ไม่ได้อยู่ไหน หรือความสามารถในการหาและแก้ข้อผิดพลาดระดับง่ายแบบอัตโนมัติอยู่ไหน
ยังเปิดกว้างอยู่ว่าการทดสอบในสภาพแวดล้อมการพัฒนาแบบ generative AI ควรมีหน้าตาอย่างไรและควรเปลี่ยนไปอย่างไร บางทีอาจมีวิธีที่ดีกว่าแนวทางเชิงกระบวนการอย่าง TDD หรือ BDD ซึ่งช่วยเพิ่มประโยชน์สูงสุดและลดต้นทุนได้
ช่วง 1-2 ปีที่ผ่านมาเป็นช่วงที่การเปลี่ยนแปลงทางเทคโนโลยีครั้งใหญ่ถูกโยนเข้าไปใน workflow เดิม ๆ แบบตรง ๆ ผลลัพธ์ของเครื่องมือใด ๆ ก็ตามล้วนเกิดจากความสามารถของเครื่องมือนั้นรวมกับประสบการณ์ของคนใช้
วงการยังต้องสั่งสมประสบการณ์และภูมิปัญญาในการผสาน generative AI เข้ากับการพัฒนาอีกมาก กว่าจะพอมองเห็นมูลค่าสุทธิที่แท้จริงได้ ผมคิดว่ายังต้องใช้อีกอย่างน้อย 2-3 ปี ไม่ใช่เพราะเทคโนโลยีต้องปรับตัว แต่เพราะคนต้องใช้เวลาในการปรับตัว
ผมเห็นทีมวัยยี่สิบสร้าง full-stack spaghetti กองมหึมาทับลงบน CRUD framework พื้นฐานที่ผมทำไว้แล้ว ถ้าคุณสร้าง “MMO framework” ได้ใน 60 วินาที แรงจูงใจที่จะลองทำแอป TODO ตั้งแต่ศูนย์ก็จะลดลง
มันคล้ายกับตอน 12 ปีก่อนที่ผมใช้ Firebase ก่อนจะเรียนพื้นฐานเชิง relational และต้องใช้เวลาหลายปีกว่าจะไปถึงพื้นฐานนั้น
แม้มองอนาคตได้ไม่แม่นยำนัก แต่เชื่อว่าวิธีที่เรารับรู้คุณภาพจะเปลี่ยนไป
มีบรรยากาศเหมือนเทคโนโลยีจะเป็นผู้กอบกู้ปัญหาสำคัญในทุกด้านรอบตัวเรา ไม่ว่าจะเป็นรถยนต์ไฟฟ้า การแพทย์ IT หรือการเงิน ขณะเดียวกันก็ยิ่งชัดขึ้นว่าเทคโนโลยีถูกใช้เป็นหลักเพื่อขยายตลาด รัฐบาล และรัฐชาติ และทำงานด้วยการวางอีกชั้นหนึ่งทับลงบน abstraction ที่รั่วอยู่แล้ว ดูเหมือนกำลังละลายแค่อาการ มากกว่าจะแก้ปัญหา
คุณภาพมีความช้าเป็นส่วนหนึ่งอยู่ในนั้น การรักษาแค่อาการก็มีขีดจำกัด และการที่มนุษย์คอยซ้อน abstraction เพิ่มเข้าไปเรื่อย ๆ ก็รับมือกับความท้าทายไม่ไหว จึงมองว่าความช้านั้นจะยิ่งจำเป็น
แนวคิดที่ว่าต้องเร็วขึ้นอีกเป็นความคิดที่ผิด เชื่อว่าหากไม่เข้าใจพื้นฐานของความท้าทายในฐานะมนุษย์ แล้วพยายามแก้เพื่อผลประโยชน์ผิวเผิน คุณภาพก็จะไม่เกิดขึ้น
LLM เป็นหายนะต่อสายงานของเรา เพราะมันเอาใจความผิดพลาดของมนุษย์ทั่วไปที่อยากไปถึงเป้าหมายโดยไม่ทำงานจริง งานจริงคือการนำสมมติฐานเรื่องความถูกต้องมาใช้ พร้อมกับเข้าใจว่าตัวเองกำลังพยายามแก้อะไรกันแน่
โชคดีที่ไม่ใช่ทุกคนจะมุ่งไปให้เร็วขึ้น ยังมีบางคนที่กลับไปเรียนรู้พื้นฐานใหม่ ใช้การตัดสินใจอย่างรอบคอบ และลับคมความคิดกับเครื่องมือเพื่อสร้างคุณภาพที่อยู่ได้นาน
ประสบการณ์ของผมกลับเกือบตรงกันข้าม แทนที่งานไล่ดู API หรือไลบรารีที่รกจะมาขัดขวางส่วนที่ยาก LLM กลับทำให้เห็นอย่างเจ็บแสบชัดเจนว่าความคิดของผมยังไม่แน่นตรงไหนในงานที่มีความหมาย
จะทำอะไรกับ LLM ได้ก็ต้องเขียน และจะเขียนก็ต้องคิด การค่อย ๆ เรียบเรียงสิ่งที่ผมอยากทำเป็นประโยคอย่างระมัดระวัง ถูก LLM จี้ถาม แล้วพบช่องโหว่ในความคิดระหว่างทาง รวมถึงได้กลับมาดูประวัติแชตที่ผ่านการทำให้ชัดขึ้นแล้วในภายหลัง นี่มักเป็นส่วนที่มีประโยชน์ที่สุด
โดยเฉพาะช่วงต้นของการขึ้นรูปแอป มันมีประโยชน์มากในการตามรอยสิ่งที่ตอนนั้นคิดว่าต้องทำ และกลับมาทบทวนภายหลังว่ายังใช่อยู่หรือไม่
พวกเขาไปฟังนักดนตรีอาชีพเล่นในคลับ แล้วกลับบ้านมาพยายามเลียนแบบ แต่สุดท้ายก็กลายเป็นก้อนความสับสนที่ไม่มีพื้นฐาน เขาเน้นว่าควรพอใจกับการทำสิ่งง่าย ๆ และค่อย ๆ สร้างพื้นฐานที่แข็งแรงขึ้นทีละน้อย
ข้อสังเกตนี้แทบจะใช้กับการใช้โค้ดที่ AI สร้างขึ้นได้ตรงตัว
เฟอร์นิเจอร์ IKEA เป็นตัวอย่างที่ดี ถ้าคุณทำเฟอร์นิเจอร์เอง ความรู้สึกเวลาอยู่ใกล้มันจะดีกว่าของที่เหมือนกระดาษลังจาก IKEA มาก แต่ในหัวของผู้คนดูเหมือนต้นทุน ความเร็ว และความสะดวกจะสำคัญที่สุด
โมเดล AI พรากประสบการณ์ที่ติดตัวมาโดยธรรมชาตินั้นไป แล้วให้แค่ครีมหน้าสุดของผลลัพธ์สุดท้าย มันคล้ายกับการดูหนังโป๊แทนการมีความสัมพันธ์จริงจนถึงจุดสุดยอด
ถ้าใช้อย่างฉลาด เครื่องมือสาย Copilot ก็มีประโยชน์ มันจัดการงาน boilerplate และส่วนที่น่าเบื่อ เพื่อให้คนไปโฟกัสกับการคิดหนัก ๆ ได้
ยิ่งไปกว่านั้น มันยังอยู่ในช่วงเริ่มต้น ยังเร็วเกินไปที่จะตัดสิน และก็ดูไม่เหมือนว่าจะหายไปไหน
วิธีวิจัยดูเหมือนตีความการเปลี่ยนแปลงเป็นสมมติฐาน โดยเปรียบเทียบกิจกรรมคอมมิตในปี 2023 กับปีก่อนหน้า ทั้งที่ไม่รู้เลยว่าในนั้นมีส่วนที่ Copilot เกี่ยวข้องอยู่เท่าไร เป็นแนวทางที่ค่อนข้างสั่นคลอน
อีกทั้งยังระบุว่า “การคาดการณ์ปี 2024 ใช้ OpenAI gpt-4-1106-preview Assistant รัน quadratic regression กับข้อมูลเดิม” ก็เลยสงสัยว่าแทนที่จะใช้เครื่องมือ regression ง่าย ๆ อย่าง sklearn, R หรือ Excel เขาเอาข้อมูล 4 จุดไปให้ GPT ทำ regression หรือเปล่า ต่อให้ทำถูกต้อง เมื่อมีข้อมูลแค่ 4 จุดและยังต้องคำนึงถึงข้อกังวลแรกด้วย ความน่าเชื่อถือก็ยังอ่อนอยู่ดี
คำว่า quadratic regression ฟังดูน่าเชื่อ แต่ถ้ามีข้อมูลแค่สองจุด มันแทบไม่ต่างจาก “ลากเส้นต่อออกไปตรง ๆ” ดังนั้นการคาดการณ์ปี 2024 จึงแทบไม่มีความหมายในเชิงสาระเลย
ฉันเป็นผู้เขียนงานวิจัยต้นฉบับเอง รู้สึกยินดีที่เห็นหลายคนกังวลเรื่อง คุณภาพโค้ด ในระยะยาว สิ่งที่เราเห็นในปี 2023 คือ churned code และโค้ดซ้ำหรือโค้ดคัดลอกแปะเพิ่มขึ้น ขณะที่ moved code ลดลง ซึ่งมากกว่าที่เราคาดไว้เสียอีก
หวังว่าทีมพัฒนาและผู้สร้าง AI Assistant จะนำตัวชี้วัดและแรงจูงใจที่ส่งเสริมการนำโค้ดที่มีอยู่กลับมาใช้ มากกว่าการเพิ่มโค้ดใหม่เข้าไป โดยเฉพาะทีมที่อยู่ภายใต้ผู้จัดการที่เชื่อว่าควรใส่ LoC ลงในการประเมินผลงานถือว่าน่าเป็นห่วง ตามงานวิจัยของ GitHub มีอยู่ราวหนึ่งในสาม และเครื่องมือช่วยเขียนโค้ดรุ่นปัจจุบันทำให้การกด Tab แล้วคอมมิตเพื่อหว่านหนี้ทางเทคนิคในอนาคตเป็นเรื่องง่ายเกินไป อย่างที่ Adam Tornhill กล่าวไว้บน Twitter ว่า “ความท้าทายหลักของการเขียนโปรแกรมแบบมี AI ช่วย คือมันทำให้การผลิตโค้ดจำนวนมากที่จริง ๆ แล้วไม่ควรเขียนตั้งแต่แรก กลายเป็นเรื่องง่ายเกินไป”
อย่างไรก็ดี นัยสำคัญของงานวิจัยปัจจุบันยังมีข้อจำกัดตรงที่ไม่ได้วัดโค้ดที่ AI เขียนโดยตรง เราเพียงวาดความสัมพันธ์ระหว่างคุณภาพโค้ดกับการแพร่หลายของ AI Assistant ตลอด 4 ปีที่ผ่านมาเท่านั้น คงจะดีหาก GitHub หรือบริษัท AI Assistant อื่น ๆ ร่วมมือในงานวิจัยต่อเนื่อง เพื่อให้สามารถวัดความแตกต่างด้านคุณภาพระหว่าง “โค้ดที่ AI เสนอทั้งหมด”, “โค้ดที่มนุษย์แก้จากข้อเสนอของ AI” และ “โค้ดที่เขียนขึ้นตั้งแต่ต้น” ได้โดยตรง
ในงานวิจัยถัดไป ฉันก็อยากวัดโดยตรงด้วยว่าความถี่ของบั๊กเปลี่ยนไปอย่างไรตามการใช้ AI หากมีไอเดียอื่นที่ควรวัดก็อยากให้ช่วยเสนอมา ฉันตั้งใจจะออกงานวิจัยใหม่ประมาณทุก ๆ 2 เดือน
การนำโค้ดกลับมาใช้ อาจทรงพลังได้ภายในโค้ดเบสเดียวกัน แต่ฉันก็เคยเห็นว่าพอข้ามโค้ดเบสแล้วมันสร้างความสับสนได้เหมือนกัน มันอาจมีประโยชน์ หรืออาจไม่เหมาะสมและทำให้สับสนก็ได้ และผลลัพธ์ส่วนใหญ่ขึ้นอยู่กับวิจารณญาณ
ฉันคิดว่าควรประเมินนักพัฒนาจากผลลัพธ์ของซอฟต์แวร์มากกว่า เช่น ผลกระทบต่อองค์กรเทียบกับทรัพยากรที่ใช้ หรือข้อผิดพลาดของบริการที่ไม่ได้มีสาเหตุมาจากบริการพึ่งพาหรือโครงสร้างพื้นฐาน
โปรแกรมเมอร์ยุคใหม่ไม่ได้เป็นคนที่รับผิดชอบแค่โค้ด แต่เป็นส่วนผสมโดยเจตนาของวิศวกรคุณภาพ/ผู้ทดสอบ ผู้จัดการผลิตภัณฑ์เชิงเทคนิค ผู้จัดการโครงการ โปรแกรมเมอร์ วิศวกรประสิทธิภาพ และวิศวกรโครงสร้างพื้นฐาน ฉันไม่ได้จะลดทอนคุณค่าของงานวิจัย แค่ดีใจที่มีคนใส่ใจเรื่องคุณภาพโค้ดอย่างจริงจัง และคิดว่าเราควรคิดเรื่องวิธีประเมินกันใหม่
ก็สงสัยเหมือนกันว่าได้ควบคุมคำอธิบายที่เป็นไปได้อื่น ๆ เช่น เศรษฐศาสตร์ด้านเทคโนโลยีที่เปลี่ยนไปหรือไม่
บทความนี้ทำเบนช์มาร์กประสิทธิภาพของ LLM ยอดนิยมกับงานรีแฟกเตอร์ริงโค้ดจริง และระบุว่า AI ให้รีแฟกเตอร์ริงที่ถูกต้องในเชิงฟังก์ชันได้เพียง 37% ของกรณีเท่านั้น
การเขียนโค้ดโดยมี AI ช่วยนั้นมีประโยชน์จริง แต่เราควรให้มนุษย์ที่มีทักษะอยู่ในวงจรต่อไป และตั้งความคาดหวังที่สมจริงให้พ้นจากคำโฆษณาเกินจริงทางการตลาด
เวิร์กโฟลว์การทำงานของฉันปกติคือไล่อ่านเอกสาร สร้างต้นแบบ ขัดเกลาโค้ดเล็กน้อย เพิ่มการทดสอบ ย้ายสิ่งต่าง ๆ ทำให้พัง กลับมาทำใหม่ ศึกษาเอกสาร แล้วรีแฟกเตอร์อีก จนในที่สุดถึงจะเข้าใจปัญหามากพอที่จะทิ้งโค้ดไป 80% แล้วสร้างใหม่อย่างถูกต้อง
ถ้า Copilot ให้โค้ดที่ใช้งานได้พอสมควรในขั้นต้นแบบจนฉันแค่เดินหน้าต่อไป มันก็ทำให้ฉันไม่ได้เข้าใจลึกพอที่จะวางโครงสร้างทั้งหมดให้ถูกต้อง มันช่วยให้ข้ามเวิร์กโฟลว์ไป 90% แต่ก็ต้องจ่ายราคา แน่นอนว่าในช่วงท้ายของการพัฒนา Copilot อาจมีประโยชน์มาก
ถ้าผลวิจัยนี้ถูกต้อง ฉันก็ไม่แปลกใจ โค้ดแย่มาจากความเข้าใจที่ไม่เพียงพอ และ Copilot ก็ไม่มีทางมีความเข้าใจมากกว่าที่ฉันป้อนให้ มันอาจเขียนโค้ดได้ดีกว่าโปรแกรมเมอร์ทั่วไป แต่ผลลัพธ์ก็ไม่มีทางดีกว่าอินพุตได้ ฉันไม่เข้าใจว่าทำไมผู้คนถึงทุ่มเทกับ “prompt engineering” กันมาก แต่กลับแปลกใจที่ “พรอมป์ต์” แย่ ๆ ของ VSCode ให้ผลลัพธ์แย่ ๆ
จากประสบการณ์ของฉัน Copilot ยอดเยี่ยมมากสำหรับช่วยให้เริ่มต้นได้ โค้ดที่ได้บางครั้งก็ดี บางครั้งก็ธรรมดา หรือบางครั้งก็พังแบบใช้ไม่ได้เลย
ถึงอย่างนั้นมันก็มีคุณค่าเพราะช่วยให้เริ่มคิดได้ ก่อนจะใช้มัน ฉันเสียเวลาไปมากกว่านี้เยอะ อาจเป็นเพราะวงจรสมองของฉันแปลกก็ได้
ผมยังเป็นจูเนียร์และติดตั้ง Codeium ไว้ใน VSCode แต่ส่วนใหญ่แล้วมันทำให้เสียสมาธิมาก ไม่ค่อยเข้าใจว่าทำไมคนจำนวนมากถึงใช้เครื่องมือช่วยแบบนี้
อย่าง Phind มีประโยชน์นะ เวลาเกิดอะไรขึ้นแล้วผมไม่เข้าใจ มันช่วยให้ผมเข้าใจปัญหาได้สัก 60% เหมือนช่วยหาบั๊กเล็ก ๆ ที่ผมมองข้ามไปเพราะเหนื่อยหรือเพราะโง่เอง
ส่วน Codeium อาจมีประโยชน์ตอนปั๊ม boilerplate ของเฟรมเวิร์ก แต่จากประสบการณ์เล็ก ๆ กับ scraper, data pipeline แบบง่าย ๆ และโปรเจ็กต์เล็กที่ใช้ JS+HTML/CSS ล้วน ๆ การต้องคอยไล่ดูข้อเสนอของมันน่าหงุดหงิดมาก โดยเฉพาะเพราะบ่อยครั้งมันใช้ไม่ได้จริง และมักเป็นเหตุผลง่าย ๆ อย่างขาดอาร์กิวเมนต์ไปตัวหนึ่ง สุดท้ายก็ต้องเสียเวลาไปกับการดีบักอยู่ดี
อีกอย่าง ใน JavaScript มีสไตล์ที่นิยมต่อ method กับ anonymous function เป็นโซ่ยาวเหมือนเดซี่เชนไม่รู้จบ ซึ่งผมรับไม่ค่อยไหว ผมชอบแยกบรรทัด ตั้งชื่อให้ฟังก์ชันและตัวแปรมากกว่า ข้อเสนอของโค้ดก็มักตามสไตล์นั้น ซึ่งก็คงเพราะข้อมูลฝึกเป็นแบบนั้น Codeium บอกว่าเรียนรู้สิ่งนี้ได้ และบางครั้งมันก็ทำได้จริง
สิ่งที่ผมห่วงที่สุดคือ ถ้าผมที่ยังเป็นจูเนียร์ยกโค้ดให้เครื่องมือช่วยพวกนี้ทำ แล้วผมจะเรียนรู้ยังไง การให้บริบทกับคำถามแก่ Phind นั้นช่วยให้เรียนรู้ได้ หรืออย่างน้อยก็ชี้ทางให้ไปค้นต่อบนอินเทอร์เน็ตเองได้ แต่แค่กด Tab แล้วจะเรียนรู้อะไรได้ยังไง ผมนึกไม่ออก
ไม่กี่วันก่อนผมเพิ่งตระหนักว่าหลายคน รวมถึงนักพัฒนาด้วย ใช้ LLM ไม่ใช่เป็นเครื่องมือเพื่อทำให้ตัวเองดีขึ้น แต่เป็น สิ่งทดแทนความพยายาม ฟังดูน่ากลัว ไม่ใช่แค่เพราะบริษัทอาจเอาไปใช้แทนคน แต่ยังน่ากลัวในแง่การสำรวจตัวเองด้วย
การเขียนโค้ดไม่ใช่ความหลงใหลของชีวิตผม แต่ผมก็ชอบมัน เพราะมันทำให้สิ่งต่าง ๆ เกิดขึ้นได้และทำให้รับมือกับความซับซ้อนได้ ถ้าคุณไม่เข้าใจว่าเกิดอะไรขึ้น คุณก็สร้างอะไรไม่ได้ และก็จะไม่รู้ด้วยว่าความซับซ้อนจะย้อนมากลืนคุณเมื่อไร
ทำแบบนี้ต่อไปแหละ ถ้าไม่เปลี่ยน คุณจะไปได้ไกลแน่ ๆ คุณอยู่บนเส้นทางที่ถูกต้องแล้ว
ประเด็นสำคัญคือ ตลอดอาชีพผมเขียนสเปก API ด้วยมือมาเยอะมาก จึง 1) เห็นปัญหาได้ทันที และ 2) แก้ได้เองโดยไม่ต้องพึ่งอะไรเพิ่ม การแก้โมเดลด้วยมือเร็วกว่าไปนั่งขัดเกลาพรอมป์ต์เสียอีก
ในเรื่องที่เรารู้ดีอยู่แล้ว มันน่าทึ่งที่เห็นงานซึ่งปกติอาจกินเวลาทั้งเช้าเสร็จได้ใน 30 วินาที แต่ผมจะไม่สั่ง AI ให้ทำสิ่งที่ผมทำไม่เป็น ผมกลับคุยกับ AI เรื่อง trade-off, ประเด็นด้านความปลอดภัยที่อาจเกิดขึ้น และเรื่องทำนองนั้นเกี่ยวกับงานที่กำลังทำมากกว่า
มันเหมือนวิศวกรจูเนียร์ที่มีปริญญาเอกในภาษาที่ผมใช้อยู่ มันไม่ได้เข้าใจหลายอย่าง แต่สิ่งที่มันเข้าใจดูเหมือนจะเข้าใจลึกมาก
นักพัฒนาบางคน โดยเฉพาะสาย JS ชอบการ chaining ทั้งที่มันแทบไม่มีประโยชน์อะไรเลยนอกจากทำให้ทุกอย่างอยู่ในบรรทัดเดียว ซึ่งนั่นไม่ใช่ข้อดีอะไร ทำแบบที่คุณทำต่อไป และอย่าให้สำนวนงี่เง่านี้เข้ามาฝังหัวคุณก็พอ
ช่วงเวลาที่เทคโนโลยีนี้น่าทึ่งที่สุดคือเวลาที่มันปรับให้เข้ากับสไตล์และความชอบของผมได้ มันตั้งชื่อแบบที่ผมต้องการ และใช้เมธอดที่ผมเพิ่งเขียนไปอย่างถูกต้องแทนที่จะสร้างซ้ำแบบมั่ว ๆ
ผมไม่ได้ใช้มันมากนักในโปรเจ็กต์ว่างเปล่าหรือโปรเจ็กต์เล็ก ๆ แต่ถ้ามันไม่ได้โน้มเอียงอย่างแรงตามสิ่งที่ผมใช้อยู่แล้วจากบริบทรอบข้าง มันก็คงให้ความรู้สึกไม่เข้าที่เข้าทางกว่านี้มาก
การใช้งานหลักของเครื่องมือช่วย AI สำหรับผมคือการเขียนเทสต์ และการทำการเปลี่ยนแปลงซ้ำ ๆ แบบ “คล้ายอันนี้แต่ต่างออกไปนิดหน่อย” ให้เร็วขึ้น ใน IntelliJ + GitHub ถ้ามีงานที่ต้องให้พารามิเตอร์ใหม่สะท้อนไปหลายเมธอดและหลายไฟล์ แค่พิมพ์สองสามรูปแบบแรกเอง หลังจากนั้นก็มักจัดการต่อได้ด้วย enter + tab บริบทจะเติมที่เหลือให้เอง
ส่วน Codeium บน VSCode นั้น ทั้งตัว AI เองก็ดูไม่ค่อยพอ และปลั๊กอินก็ดูเหมือนเขียนมาแบบที่คีย์เสนอคำแนะนำกับคีย์ยอมรับคำแนะนำชอบขัดกันบ่อย แม้ยังช่วยเรื่องงานซ้ำ ๆ ได้อยู่ แต่ในแง่การเสนอวิธีไปให้ถึงเป้าหมาย มันช่วยได้น้อยกว่า
ผมลองให้ ChatGPT สร้าง Yourls clone ที่ทำบน Django/Python โดยสั่งไว้ชัดเจนว่าต้องรองรับ short URL แบบกำหนดเองและติดตามทราฟฟิกด้วย แต่มันกลับไม่ได้คำนึงถึงเรื่องนั้นอย่างเหมาะสมใน logic หรือ data model ถ้าจะให้แก้ทีหลังก็ต้องยัดคำสั่งที่เฉพาะเจาะจงเข้าไปอีก
เครื่องมือ AI ก็เหมือนนักพัฒนาจูเนียร์ที่มาทำงานให้คุณ เพียงแต่มันเร็วกว่าเยอะ
ถ้าคุณไม่รู้ว่าตัวเองกำลังทำอะไรอยู่ มันก็แค่เร่งความเร็วในการทำพลาดเท่านั้น
ไม่นานมานี้ผมต้องใส่คำนำหน้าชื่อตารางให้กับ column alias ในคำสั่ง SELECT แต่ไม่มีฟังก์ชันแบบนั้น ก็เลยส่ง schema definition กับ query ให้ ChatGPT แล้วให้มันเขียนรายการเลือกคอลัมน์ยาว ๆ ราว 40 คอลัมน์ให้
ผมหาวิธีที่ดีสำหรับทำงานแบบนี้อัตโนมัติข้ามหลาย RDBMS ไม่เจอ แม้จะทำด้วย regex หรือการจัดการข้อความแบบอื่นก็ได้ แต่การแค่อธิบายปัญหาแล้วได้ผลลัพธ์ตามที่ต้องการกลับเรียบง่ายจนน่าพอใจ
นอกนั้นผมก็ใช้ LLM เหมือน autocomplete มันยังช่วยให้ตั้งชื่อฟังก์ชันได้ดีด้วย เพราะบ่อยครั้งแค่ข้อมูลระดับนั้น LLM ก็ให้จุดเริ่มต้นที่สมเหตุสมผลได้แล้ว โดยเฉพาะเวลาทำงานกับ API หรือภาษาที่ผมยังใช้ไม่มาก และเวลาปัญหาที่เจอเป็นอะไรที่มีคนแก้มาแล้วหลายพันครั้ง StackOverflow เลยแทบไม่ได้ใช้แล้ว
เพราะงั้นผมเลยซื้อ Copilot และใช้ ChatGPT บ่อยมาก LLM เป็นหนึ่งในสิ่งที่ผมชอบที่สุดเมื่อใช้คู่กับ autocomplete ดี ๆ แบบ IntelliSense, การสร้างโค้ดจาก OpenAPI หรือ EF/JPA, การทำ migration/สร้างตารางฐานข้อมูลจาก ER model, container, และ IDE ฉลาด ๆ อย่าง JetBrains
บริษัทต่าง ๆ คงอยากได้โค้ดมากขึ้นและเร็วขึ้น และผมคิดว่าในวังวนแบบนั้น คนที่รู้จริงว่าตัวเองกำลังทำอะไรอยู่จะยิ่งมีน้อยลง
เอกสารฉบับเต็มอยู่ที่นี่: https://gitclear-public.s3.us-west-2.amazonaws.com/Coding-on...
ก่อนที่เครื่องมือช่วยเหลือ “AI” จะออกสู่ตลาด ก็มีแรงต้านต่อ โค้ดแบบ DRY อยู่แล้ว และน่าเสียดายที่มันเป็นกระแสที่ขยายตัวขึ้นตอนใช้ Twitter ในช่วงปี 2019~2022
นักพัฒนารุ่นใหม่บางคนมีทัศนคติต่อโค้ดที่ต่างจากสิ่งที่ผมเรียนมาอย่างมาก พวกเขาดูจะดูแคลน Gang of Four และ design patterns อย่างหนัก ทั้งที่ไม่รู้ด้วยซ้ำว่าเฟรมเวิร์กที่ตัวเองชอบก็เต็มไปด้วยแพตเทิร์นเหล่านั้น พวกเขาพูดประชดหลักการอย่าง DRY โดยเฉพาะ SOLID
บนที่อย่าง Twitter ยิ่งพูดประชดและโจมตีฝั่งตรงข้ามมากเท่าไร การมีส่วนร่วมก็ยิ่งเพิ่มขึ้น เป็นกระแสที่ค่อนข้างน่ากังวล
ผมเองก็รู้สึกดูแคลนอย่างมากกับสิ่งที่เกิดขึ้นใน codebase ขององค์กร การซ้อนชั้นความอ้อมผ่านคลาสต่าง ๆ ไม่ใช่เรื่องโอเค ไม่ว่าเหล่ากูรู SOLID จะพูดว่าอย่างไร best practices, DRY, SOLID มักถูกใช้เป็นแค่ข้ออ้าง
ผมทนไม่ได้กับการเอารายการหลักการแบบตามอำเภอใจที่มาจากแนวคิดเชิงวัตถุสไตล์ Java มาปฏิบัติเหมือนเป็นสัจธรรมของการทำแบบจำลองซอฟต์แวร์ ผมเบื่อเต็มทีแล้วกับการถกเถียงครั้งที่ล้านว่า SOLID ควรถูกเข้าใจอย่างไร
คนไม่ได้ทะเลาะกันเรื่อง CAP theorem แบบนั้น เพราะมันไม่ใช่การจับแนวคิดตามอำเภอใจมามัดรวมให้เป็นตัวย่อเท่ ๆ
DRY ก็ถูกใช้เกินเลยได้ และสิ่งที่คนต่อต้านจริง ๆ คือท่าทีที่ปฏิบัติต่อมันราวกับสมบูรณ์แบบ
ยกตัวอย่างเช่น หลักสำคัญของ DRY ไม่ใช่การไม่ทำโค้ดซ้ำ แต่คือการไม่ทำไอเดียซ้ำ สำหรับแนวคิดใด ๆ ในระบบ ตามอุดมคติแล้วควรมีแหล่งความจริงเพียงแห่งเดียว และเวลาจัดการกับแนวคิดนั้น ก็ควรมีเพียงที่เดียวที่ต้องทำความเข้าใจหรือแก้ไข
เพราะฉะนั้น การคัดลอกแล้ววางโค้ดจำนวนไม่น้อยแทนการทำ abstraction ที่มีความหมายจึงมักเป็นเรื่องไม่ดี ในขณะเดียวกัน มันยังเป็นคำเตือนด้วยว่าเมื่อใดก็ตามที่คุณทำไอเดียซ้ำ คุณกำลังก่อหนี้ถาวรที่ต้องคอยซิงก์การแสดงออกหลายแบบให้ตรงกัน เรื่องนี้ใช้ได้กับทั้ง DB migration ที่นิยาม schema กับ ORM class ที่แยกต่างหาก, backend API กับ frontend client, ค่าฟอร์มของ retained mode UI กับสถานะภายใน, และ data model invariants ที่ถูกแสดงอยู่ทั้งใน type และ unit test
คนที่คัดค้านการฝืนรวมสิ่งที่เป็นคนละไอเดียเข้าด้วยกันเพียงเพราะบังเอิญมี implementation คล้ายกันนั้นไม่ได้ผิด เพราะมันจะกลายเป็นความเสี่ยงด้านการบำรุงรักษาในภายหลัง เพียงแต่สิ่งที่พวกเขาโจมตีเป็นหุ่นฟางที่ไม่ใช่ประเด็นดั้งเดิมของ DRY
ตอนนี้ปัญหาคือ นักพัฒนารุ่นใหม่จะได้เรียนรู้หลักการเหล่านี้อย่างถูกต้องจากที่ไหนและเมื่อไร บางคนมีพื้นฐานจากการเรียนสายนี้มา แต่ไม่ใช่ทุกคน และหลักสูตร CS เชิงวิชาการก็ไม่จำเป็นต้องสอนทักษะการพัฒนาซอฟต์แวร์เชิงปฏิบัติมากนัก
ตอนที่ผมเริ่มต้น เหล่าซีเนียร์ยังฝึกสอนจูเนียร์กันแบบจริงจังและลงลึก แต่ตอนนี้ดูเหมือนสิ่งนั้นจะลดลงมากในวัฒนธรรมการย้ายงานบ่อยและบรรยากาศที่ไม่อยากรับจูเนียร์มาเป็นการลงทุนระยะยาว แม้คอร์สทางการจะราคาแพงสำหรับคนทั่วไป แต่แทบไม่มีต้นทุนเลยเมื่อเทียบในระดับบริษัท ทว่าในความเป็นจริง บริษัทที่ส่งนักพัฒนาใหม่ไปเรียนกลับมีน้อยมาก
มีหนังสือที่ควรอ่านอยู่เหมือนกัน แต่ก็ไม่แน่ใจว่าคนอายุยี่สิบในปี 2024 จะเต็มใจหยิบรูปแบบเก่า ๆ ที่เป็นหมึกพิมพ์บนเยื่อไม้ที่ตัดมาอ่านหรือเปล่า ทุกวันนี้นักพัฒนาที่กำลังเติบโตน่าจะเรียนรู้แนวคิดเหล่านี้จากบล็อกและ YouTube เป็นจำนวนมาก ซึ่งก็มีทั้งแหล่งข้อมูลชั้นเยี่ยม แต่ปัญหาคือคุณต้องคุ้ยหามันจากกองขยะที่ทั้งเข้าใจไม่ถูกต้องหรือแพ็กเกจมาอย่างน่าสงสัยอยู่เสมอ
ดังนั้น เมื่อมีเครื่องมือมหัศจรรย์ที่สร้างโค้ด 12 บรรทัดที่พอใช้งานได้แบบลวก ๆ ภายในชั่วพริบตาปรากฏขึ้น ก็ไม่น่าแปลกใจที่นักพัฒนารุ่นใหม่จะคิดว่าโค้ดนั้นยอดเยี่ยม ทั้งที่แทบไม่รู้ปัญหาเชิงลึกของมันเลย จะโทษว่าเป็นความผิดของใครคนเดียวก็คงยาก แต่มันเป็นปัญหาที่ชัดเจน และคงดีถ้าเรารู้ว่าควรทำอย่างไร