หลังจากเขียนโค้ดด้วย LLM มาหลายเดือน ผมตัดสินใจกลับมาใช้สมองของตัวเองอีกครั้ง
(albertofortin.com)- ใช้ LLM ประสิทธิภาพสูง เพื่อสร้างอินฟราสตรักเจอร์ แต่พบ ปัญหาใหญ่ ด้านคุณภาพโค้ดและความสามารถในการดูแลรักษา
- เพราะ ความไร้ประสิทธิภาพของ AI และผลลัพธ์ที่ไม่สม่ำเสมอ จึงรู้สึกถึงความจำเป็นที่จะต้องเข้าใจโค้ดเอง ค้นคว้าเอง และพัฒนาทักษะของตัวเอง
- เป้าหมายที่ต้องการ ปิดโปรเจ็กต์ให้เร็ว กลับนำไปสู่ความสับสนของโครงสร้างโค้ด การทำซ้ำ และความไม่สอดคล้องกัน
- ตอนนี้จึงจำกัดการใช้ AI ไว้แค่งานช่วยเหลือ เช่น งานซ้ำ ๆ หรือการแปลงโค้ด
- เนื่องจากการใช้ AI อาจนำไปสู่ การถดถอยของสัญชาตญาณด้านการเขียนโค้ดและความสามารถในการแก้ปัญหา จึงให้ความสำคัญกับการใช้สมองอย่างจริงจังเป็นอันดับแรก
บทนำ: ความพยายามสร้างอินฟราสตรักเจอร์ด้วย LLM
- อินฟราสตรักเจอร์เดิมแบบ PHP+MySQL มาถึงขีดจำกัด จึงตระหนักถึงความจำเป็นของ อินฟราสตรักเจอร์ใหม่
- เลือกใช้ Go และ Clickhouse และเดินหน้าวางแผนกับออกแบบอินฟราสตรักเจอร์ร่วมกับ AI
- สอบถาม LLM อย่าง Claude เกี่ยวกับ best practices และสถาปัตยกรรม เพื่อวางแผนอย่างละเอียด
- ตั้งเป้าพัฒนาฟีเจอร์ให้เสร็จและปล่อยใช้งานอย่างรวดเร็ว จึงเดินหน้าเขียนโค้ดโดยเน้น ความเร็วเป็นหลัก
กระบวนการพัฒนาและการเกิดปัญหา
- ใช้ เครื่องมืออย่าง Cursor ให้ AI เขียนโค้ด ขณะที่ผู้เขียนเน้นงานด้านการ build และทดสอบ
- แม้ codebase จะยังไม่เป็นระเบียบ ก็ยังให้ความสำคัญกับการส่งมอบข้อมูลที่ต้องใช้ก่อน
- แม้จะพัฒนาได้รวดเร็ว แต่เมื่อเวลาผ่านไปกลับมี ปัญหาใหม่เกิดขึ้นอย่างต่อเนื่อง
- ด้วยประสบการณ์ที่ยังน้อยกับ Go และ Clickhouse จึงเจอความยากลำบาก และข้อเสนอแก้ไขจาก AI ก็ทำให้เกิดปัญหาต่อเนื่องเป็นลูกโซ่
ปัญหาคุณภาพโค้ดและการตระหนักถึงข้อจำกัด
- จัดเวลาเพื่อทำ code review ตรวจดูโค้ดทั้งหมดที่สร้างขึ้นอย่างละเอียด
- ไฟล์ที่ทำหน้าที่เดียวกันกลับ ไม่สอดคล้องกันทั้งชื่อ พารามิเตอร์ และโครงสร้าง รวมถึงมีความซ้ำซ้อนและความสับสนจำนวนมาก
- ตัวอย่าง:
WebAPIproviderและwebApiหมายถึงพารามิเตอร์เดียวกัน แต่กลับแยกกันอยู่ - มีกรณีที่เมธอดเดียวกันถูกนิยามซ้ำในหลายไฟล์
- วิธีเข้าถึงไฟล์ตั้งค่าไม่มีความสม่ำเสมอ
- ตัวอย่าง:
- ผลลัพธ์ที่ได้เหมือนกับมีนักพัฒนาระดับจูเนียร์หลายคน ทำงานพร้อมกันโดยไม่สื่อสารกัน
ข้อจำกัดของการป้อนบริบทให้ LLM และการเปลี่ยนกลยุทธ์
- แม้จะ ให้ข้อมูลบริบทอย่างเพียงพอ และใช้ LLM ที่มี context window ขนาดใหญ่อย่าง Gemini ก็ยัง ปรับปรุงความสม่ำเสมอได้ไม่ดีพอ
- ตระหนักถึงความจำเป็นในการเรียนรู้ด้วยตนเองเกี่ยวกับอินฟราสตรักเจอร์และภาษา รวมถึง ศึกษาจากเอกสารและวิดีโอเพิ่มเติม
- เพื่อให้เขียนโค้ดแบบ clean และจัดระเบียบได้ดีขึ้น จึง เปลี่ยนทิศทาง จากการพัฒนาแบบ AI นำ ไปสู่การออกแบบโค้ดด้วยตัวเอง
การเปลี่ยนวิธีใช้ AI เป็นตัวช่วย
- มุ่งเน้นที่ ความเข้าใจและการดูแลโค้ดโดยตรง ผ่านการ refactor และจัดระเบียบโค้ดซ้ำ ๆ ด้วยตัวเอง
- จำกัดบทบาทของ AI ไว้ที่งานซ้ำ ๆ แบบง่าย เช่น การเปลี่ยนโค้ดอัตโนมัติ การเปลี่ยนพารามิเตอร์ครั้งเดียวหลายจุด และ การแปลงโค้ด
- ส่วนการวางแผนฟีเจอร์ใหม่หรือการเขียนโค้ดร่างแรก จะ คิดเองก่อนแล้วค่อยให้ LLM ตรวจสอบหรือช่วยเสริม
- วาง AI ไว้ในบทบาทของ “ผู้ช่วย” และให้ นักพัฒนาเป็นผู้ตัดสินใจ เรื่องแผนและโครงสร้างเอง
ความกังวลเรื่องการถดถอยของความคิดและท่าทีที่เปลี่ยนไป
- เมื่อมี AI อยู่ตลอด ก็เริ่มตระหนักว่าตัวเอง ใช้สมองน้อยลง และพึ่งพา AI ในการวางแผนหรือกระบวนการคิดมากขึ้น
- พยายามฟื้นฟูทักษะนักพัฒนาและความสามารถในการแก้ปัญหาผ่าน ปากกาและกระดาษ การออกแบบด้วยตัวเอง และการเขียนโค้ดด้วยตัวเอง
- ตระหนักถึงความเสี่ยงที่ AI อาจทำให้ สัญชาตญาณด้านการเขียนโค้ดถดถอย
ความกังวลต่อคนที่ไม่ใช่นักพัฒนาและ ‘Vibe Coding’
- หากคนที่ไม่ใช่นักพัฒนาใช้แค่ LLM ในการพัฒนา ปัญหา โค้ดซับซ้อน สับสน และการวนซ้ำของข้อผิดพลาด จะยิ่งรุนแรงขึ้น
- เมื่อเทียบกับเครื่องมือ no-code การพัฒนาแบบอาศัย AI อาจทำให้เข้าใจโครงสร้างได้ยากยิ่งกว่า
- กล่าวถึง ความยากและความเสี่ยงเชิงรากฐาน จากกำแพงโค้ดที่ไม่อาจทำความเข้าใจได้ และวงจรข้อผิดพลาด-แก้ไข-กลับมาเกิดซ้ำที่ดำเนินต่อเนื่อง
มุมมองต่อความจริงของการใช้ AI และบรรยากาศในคอมมูนิตี้
- แสดงความสับสนต่อการโหมโฆษณาเกี่ยวกับ AI เชิงพาณิชย์ benchmark อินฟลูเอนเซอร์ และบริษัท AI รวมถึง ความไม่ตรงกันของประสิทธิภาพจริง
- ในโมเดลและพรอมป์เดียวกันก็ยังได้ผลลัพธ์ที่ แตกต่างกันอย่างสิ้นเชิง
- แม้แต่ LLM รุ่นล่าสุดประสิทธิภาพสูงก็ยัง ไม่สามารถจัดการงานซับซ้อนจริงได้อย่างสมบูรณ์ เช่น query ของ Clickhouse กับข้อมูลหลายร้อยล้านแถว
- เมื่อถูกบังคับให้ใช้ การตั้งค่าที่ซับซ้อนและ workflow ที่ไม่มีประสิทธิภาพ สิ่งนั้นเองอาจเป็น ‘การเสียเวลา’
- แม้ AI จะดูน่าทึ่ง แต่ในตอนนี้ก็ยังเป็นเพียง เครื่องมือที่ดีแต่ยังไม่ยอดเยี่ยม เท่านั้น
บทสรุป
- ยังคงมี ความคาดหวังและความสนใจอย่างมาก ต่อเทคโนโลยีใหม่และ AI
- แต่ในเวลานี้ กลยุทธ์ที่ชาญฉลาดคือ เข้าใจบทบาทและข้อจำกัดของมันอย่างถูกต้อง แล้วใช้ AI แบบจำกัดในฐานะเครื่องมือช่วยหรือเครื่องมือเพื่อการเรียนรู้
- พร้อมเตือนถึง การเสื่อมถอยของทักษะนักพัฒนา จากการใช้ AI และหันกลับมาให้ความสำคัญกับการคิดและการวางแผนด้วยตนเอง
- การพัฒนาที่พึ่ง AI ทั้งหมดโดย ไม่เข้าใจหลักการทำงานและโครงสร้างของโค้ด มีโอกาสล้มเหลวสูง
2 ความคิดเห็น
ความคิดเห็นบน Hacker News
ฉันไม่ค่อยเข้าใจแนวคิดแบบ "ทุ่มสุดตัว" กับ LLM เท่าไร ฉันทำงานเป็นนักพัฒนา iOS และก็ยังทำงานตามปกติ ทุกวันนี้ใช้ LLM แค่ช่วยทำพวกวิวชั่วคราวที่อิงจากดีไซน์ให้เสร็จเร็วขึ้น เป็นหน้าจอประกอบอย่างฟีเจอร์ใหม่หรือคำแนะนำการติดตั้งวิดเจ็ต ไม่ใช่แกนหลักของแอป ของที่เมื่อก่อนใช้เวลา 30–60 นาทีตามความซับซ้อน ตอนนี้เสร็จได้ใน 5 นาที ฉันไม่ชอบงานเว็บ แต่ LLM ค่อนข้างใช้ได้กับเรื่องแบบนั้น งานเปลี่ยนแปลงใหญ่ ๆ ก็ใช้ LLM แล้วตรวจเองก่อน commit ลง git แต่ถ้าปล่อยให้ LLM พาไปโดยไม่คุม flow ให้ดี บางทีก็พังอยู่หลายชั่วโมงแล้วต้องกลับไปเริ่มใหม่ตั้งแต่ต้น ฉันคิดว่าสิ่งสำคัญคือการใช้อย่างสมดุล
ความมีประโยชน์ของเครื่องมือขึ้นอยู่กับคนและปัญหา ตัวอย่างเช่น ถ้าเป็นนักพัฒนา Python ที่มีประสบการณ์ 10 ปี ทำงานกับ legacy code ขนาดใหญ่ใน IDE ที่จูนมาอย่างดี และเน้นความเสถียร เครื่องมืออย่าง LLM หรือ Cursor อาจกลายเป็นตัวรบกวนได้ ในทางกลับกัน ถ้าเป็นนักพัฒนา JS ปีแรก ๆ (React, Nextjs ฯลฯ) ที่ทำ prototype ของไอเดียใหม่บ่อย ๆ ไม่ได้มีความชอบ IDE เป็นพิเศษ และเปิดรับการทดลอง LLM กับ Cursor จะช่วยเพิ่มศักยภาพได้อย่างเห็นผลทันที
ฉันก็ทำหลายด้านเหมือนกัน (iOS, เว็บดีเวลอปเมนต์ ฯลฯ) และผลลัพธ์ของ LLM ต่างกันมากระหว่างสองฝั่ง บ่อยครั้งโค้ดที่ LLM สร้างมายังคอมไพล์ไม่ผ่านด้วยซ้ำ เคยถึงขั้นแนะนำ API ที่ไม่มีอยู่จริงด้วย แต่ถ้าเป็นแอป Nextjs กลับทำได้ดีในรอบเดียว สุดท้ายก็มาจากความต่างของข้อมูลที่ LLM ใช้ฝึกนั่นแหละ
การประเมินความสามารถของ LLM สูงเกินจริงเป็นเรื่องธรรมชาติ ฉันเองก็ใช้มาค่อนข้างนานในฐานะตัวแทน Stack Overflow และไว้ขอ code snippet สั้น ๆ จากนั้นก็ค่อย ๆ โยนความรับผิดชอบให้มากขึ้น จนเจอปัญหาและตระหนักถึงขีดจำกัด สุดท้ายเลยกลับมาใช้ LLM ในบทบาทช่วยคิดไอเดียกับให้คำแนะนำมากกว่า ฉันคิดว่าหลายคนก็ผ่านกระบวนการคล้าย ๆ กัน
ฉันก็รู้สึกคล้ายกัน ไม่ได้ศรัทธา LLM แบบสุดทาง แต่ใช้แค่กับงานซ้ำ ๆ น่าเบื่อ (ฟังก์ชันเล็ก ๆ, การ implement interface, การทำเอกสารอัตโนมัติ ฯลฯ) วิธีนี้ช่วยประหยัดเวลาไปมากและเพิ่มประสิทธิภาพการทำงานด้วย
สำหรับงานพัฒนา iOS ประสิทธิภาพของ LLM ยังขึ้น ๆ ลง ๆ สาเหตุหนึ่งคือ Swift กับ SwiftUI เปลี่ยนเร็วเกินไป และเอกสารทางการก็ไม่ค่อยดี มันมีประโยชน์กับการสร้างวิวง่าย ๆ แต่พอเป็น async processing หรือ business logic ซับซ้อนก็พังง่าย ถึงอย่างนั้นก็ยังช่วยชี้ทิศทางได้ เพียงแต่ก็เสี่ยงจะหลงไปกับผลลัพธ์ผิด ๆ ได้มากเหมือนกัน
คนที่เชียร์ LLM มักมองข้ามความจริงที่ว่าคอขวดส่วนใหญ่ไม่ได้อยู่ที่การสร้างโค้ด การเขียนโค้ดให้เร็วขึ้นไม่ได้เปลี่ยนความจริงที่ว่าเรายังต้องใช้เวลาอีกมากกว่าเดิมเป็นเท่าตัวกับ code review, การทดสอบ, และการทำความเข้าใจ codebase ถ้าจะดูแลรักษาในระยะยาวจริง ๆ (แก้บั๊ก, refactor ฯลฯ) ก็หลีกเลี่ยงขั้นตอนเหล่านี้ไม่ได้
การอ่านโค้ดยากกว่าการเขียนมาก ดังนั้นในความเป็นจริงฉันใช้เวลากับการทำความเข้าใจโค้ดมากกว่า แต่ฉันเคยเจอ CEO คนหนึ่งที่อ้างทำนองว่า ถ้าให้ข้อมูลบริบทกับเครื่องมือ นักพัฒนาก็ไม่จำเป็นต้องอ่านโค้ดอีกต่อไป เป็นตรรกะประมาณว่า AI จะเปลี่ยนแก่นแท้ของงานวิศวกรรมไปเลย พูดตรง ๆ ว่าฉันงงพอสมควร
ฉันรู้สึกว่า LLM ค่อนข้างมีประโยชน์เวลาให้มันอธิบายโค้ดของฉันกลับมาอีกที
ทุกครั้งที่มีคนชมเครื่องมือ editor แบบสร้างโค้ดอัตโนมัติ ฉันก็มักจะนึกแบบเดียวกัน
ตามความเป็นจริง นักพัฒนาส่วนใหญ่ก็ไม่ได้สนใจ implementation ภายในของ dependency library มากนัก ขอแค่มันทำงานตาม interface ก็พอ แน่นอนว่าการดึงโค้ดที่ LLM สร้างมากับการนำ npm package หรือ rust crate มาใช้นั้นต่างกันมาก ฉันก็รู้ปัญหาของมัน แต่ก็มีเหตุผลที่แนวปฏิบัตินี้แพร่หลาย
ฉันก็คิดคล้ายกัน ช่วงนี้ฉันใช้ LLM เป็นหลักในการเรียนรู้เทคโนโลยีใหม่ หรือสร้าง client code สำหรับ standard API (โดยเฉพาะ boto3) ฉันยังลองใช้ Windsurf ให้ช่วยแก้ไฟล์ docker compose ด้วย แต่ผิดหวังเพราะมันทำงานไม่ได้จริง มันอาจช่วยทำ prototype ได้ แต่ก็ไม่ใช่ทั้งหมด ฉันคิดว่า LLM เปลี่ยนเกมในฝั่ง devops ไปแล้ว (ตอนนี้รายละเอียด API สำคัญน้อยลง) แต่การตัดสินใจสำคัญ ๆ ฉันยังต้องเป็นคนทำเอง เช่น นิยาม interface เอง แล้วให้ LLM ไป implement ต่อ ฉันไม่คิดว่านี่ใช่ "vibe coding"
ฉันเคยเจอบั๊กใหญ่หลุดออกมาตอน code review จนประสิทธิภาพที่ได้จากการใช้ Cursor หายวับไปทันที ตอนนี้เลยกลับไปใช้ VSCode และใช้ Copilot แบบจำกัดเฉพาะเวลาที่ขออะไรเจาะจงเท่านั้น ฟีเจอร์ tab completion ของ Cursor ตอนแรกให้ความรู้สึกเหมือนเวทมนตร์ แต่ไม่นานผลนั้นก็จางหาย
สิ่งที่ตลกที่สุดคือการเห็น Cursor พยายามใส่โค้ดที่เพื่อนร่วมทีมเพิ่งลบไปกลับเข้ามาอีกครั้งด้วย tab completion โดยอัตโนมัติ
ฉันสงสัยว่าคุณตั้งข้อจำกัดอะไรไว้ให้ agent สร้างโค้ดบ้างไหม (เช่น หลักการ SOLID, lint, coverage 100%, เอกสารออกแบบที่ชัดเจน ฯลฯ)
ฉันอินกับความเห็นนี้เหมือนกัน ฉันใช้ LLM เยอะมาก แต่ตั้งกฎไว้สองข้อ ข้อแรกคือปัญหาที่ต้องคิดลึก ๆ จะไม่ยกให้ LLM เด็ดขาด (งานออกแบบซับซ้อนต้องแก้เองเท่านั้น) ข้อสองคือโค้ดที่ LLM สร้างมาจะต้องถูกรีวิวและแก้แบบละเอียดทีละบรรทัด โดยปกติโค้ดของ LLM มักเยิ่นเย้อหรือระวังตัวเกินไป ต่อให้แก้ด้วย prompt ยังไง สุดท้ายความรับผิดชอบในการดูแลรักษาในอนาคตก็ยังเป็นของฉัน ถ้าทำเฉย ๆ กับผลลัพธ์ของการสร้างโค้ด มันจะทิ้งความรู้สึกไม่สบายใจไว้ ถ้าใช้ในแบบของฉัน ฉันก็ยังใช้ LLM ได้มากและพัฒนาได้เร็วขึ้นอยู่
ฉันมอบงานวิเคราะห์เชิงลึกให้ AI เลย จุดประสงค์คือให้มันช่วยทำแผนปฏิบัติการที่ชัดเจน (ขั้นตอน implementation ละเอียด ๆ, เกณฑ์การตรวจสอบ ฯลฯ) และเขียนรายงานที่ทำซ้ำได้ การวางแผนกับการตรวจสอบยังต้องทำซ้ำหลายรอบอยู่ แต่ด้วยความช่วยเหลือของ AI มันจบได้เร็วขึ้นมาก บางครั้งก็จบในรอบเดียวตามแผนได้เลย พอมีแผนละเอียดและเอกสารที่ดี ความสม่ำเสมอก็เกิดขึ้นและทำให้รู้สึกพอใจมาก
ถ้าต้องตรวจโค้ดที่ LLM สร้างมาอย่างละเอียดทีละบรรทัดจริง ๆ ก็อดสงสัยไม่ได้ว่ามันประหยัดเวลาได้จริงหรือเปล่า
บางบริษัทบังคับให้วิศวกรซอฟต์แวร์ใช้ LLM (มีการนับสถิติการใช้ Copilot/Cursor) และมีโอกาสสูงที่สถิติเหล่านี้จะถูกใช้เป็นตัวชี้วัดสำหรับการปลดคน ฉันลองใช้แบบถูกบังคับอยู่หนึ่งเดือนแล้วรู้สึกว่าความสามารถของตัวเองเสื่อมลงเร็วมาก มันช่วยงานง่าย ๆ ได้ แต่ถ้าพึ่ง LLM มากเกินไปแม้แต่ในเรื่องการคิด ก็จะติดลูปได้ง่าย ผลิตภาพไม่ได้เพิ่มขึ้น แถมปริมาณงานในสปรินต์กลับเพิ่มขึ้นอีก ในบริษัทมีบรรยากาศเชื่อ LLM แบบเกือบเป็นศาสนา ประเด็นด้านความปลอดภัยก็ร้ายแรงมากเช่นกัน ตอนนี้มีสัญญาณหลายอย่างว่ากำลังอยู่ที่จุดสูงสุดของ hype cycle ฉันคิดว่าถ้าบริษัท AI ไม่ได้ไปสร้างโรงไฟฟ้านิวเคลียร์กันจริง ๆ ค่าใช้จ่ายในการคงโมเดล AI ขนาดใหญ่แบบปัจจุบันจะมหาศาลจนอยู่ไม่ไหว สุดท้ายสิ่งที่น่าจะเหลือรอดก็อาจมีแค่ turbo autocomplete เท่านั้น ตัวโมเดล transformer เองก็มีข้อจำกัดชัดเจน และอาจลงเอยเหมือน neural network ยุค 80s คือเหลืออยู่เฉพาะงานเฉพาะทางแล้วก็หายไป ก่อนจะกลับมาอีกครั้งในอีก 30 ปี สุดท้ายก็จะเห็นเองว่าใครบ้างที่ว่ายน้ำอยู่โดยไม่มีอะไรปิดบัง
เพื่อป้องกันเรื่องนี้ ฉันตั้งกฎส่วนตัวว่าอย่างน้อยสัปดาห์ละครั้งจะปิด Copilot แล้วทำงานไปเลย เรียกว่า 'no Copilot Fridays'
ฉันเองก็ใช้ Cursor แค่ระดับ autocomplete กับ code snippet สั้น ๆ เท่านั้น แต่ถึงอย่างนั้นก็ยังรู้สึกได้ว่าทักษะตัวเองลดลง สุดท้ายก็ได้ตระหนักถึงธรรมชาติของสมองว่า "ไม่ใช้ก็ลืม"
ฉันก็เห็นปัญหาแบบเดียวกัน ตอนนี้ฉันใช้ LLM 90% กับโปรเจกต์เล่น ๆ มันเร็วกว่าการเขียนเอง 10 เท่า แต่คุณภาพการออกแบบตกลงและมีความรู้สึกแปลก ๆ ฉันเชื่อว่าโค้ดที่ LLM นำทางคืออนาคต แต่ถ้าคุมไม่ดีจะกลายเป็นความโกลาหล ฉันลองเปลี่ยน prompt เพื่อชักนำให้มันปรับปรุง architecture ซ้ำ ๆ ด้วย แต่ผลลัพธ์ก็ยังไม่นิ่ง บางทีคำตอบอาจอยู่ที่ prompt engineering ที่ดีกว่านี้ หรือไม่ก็การเขียนเอกสาร design กับ guideline ให้ชัดเจนขึ้น ถ้าประสิทธิภาพเครื่องมือดีขึ้นอีก 10 เท่าและ latency ลดลง ประสบการณ์ใช้งานคงต่างออกไปมาก
หวังว่ายุคที่ "ดีขึ้น 10 เท่า" แบบนั้นจะมาถึงเร็ว ๆ แต่ปัญหาตอนนี้คือบรรยากาศโฆษณาชวนเชื่อเหมือนกับว่าเรามาถึงจุดนั้นแล้ว หลายคนเลยเริ่มคิดว่า "หรือเราใช้มันไม่เป็นเอง" แต่ฉันคิดว่าเครื่องมือยังไปไม่ถึงระดับนั้นจริง ๆ
ถ้ากำหนด class กับ method เองไว้ก่อน แล้วให้ LLM ทำแค่ implementation จะดีมาก สำหรับส่วนที่ซับซ้อนก็ใส่โน้ตไว้ใน body ของ method ว่าควรทำไปในทิศทางไหน แบบนี้ภาพใหญ่ยังอยู่ในการควบคุมของเรา แล้วให้ LLM สร้างแค่โค้ดเฉพาะจุด LLM ให้ความรู้สึกเหมือนนักพัฒนาจูเนียร์ที่ขยันช่วยเกินไป และเพราะต้นทุนการสร้างโค้ดตอนนี้ถูกมาก เราจึงทิ้งแล้วทำใหม่ได้เต็มที่ ในกรณีของฉัน ฉันทิ้งและเขียนโค้ดประมวลผล dataset ใหม่หมดหลายรอบด้วยความช่วยเหลือจาก LLM จนสุดท้ายได้ผลลัพธ์และประสิทธิภาพที่ต้องการ ถ้าเป็นงานที่คนอื่นเขียนให้ ฉันคงยอมแพ้ไปแล้ว
เครื่องมือแบบนี้โดดเด่นมากในช่วงต้นแบบของโปรเจกต์ greenfield แต่พอเข้าใกล้การ deploy จริง ผลคูณ 10 เท่านั้นก็จะค่อย ๆ หายไป ถ้าไม่ดูแล architecture อย่างระมัดระวัง สุดท้ายก็มีแต่งานเพิ่ม
สำหรับ codebase ซับซ้อน ตอนนี้มันใช้งานได้แค่ประมาณ advanced voice-to-text input เท่านั้น (และถ้าไม่ได้ใช้เสียง จริง ๆ เขียนมือเองยังเร็วกว่า)
เห็นด้วยว่าต้องบันทึก architecture และ guideline ไว้อย่างชัดเจน ยิ่งกำหนดเงื่อนไขและพฤติกรรมไว้อย่าง explicit มากเท่าไร ก็ยิ่งได้ผลดีมากขึ้นเท่านั้น
ใจความของบทความคลาสสิกเก่าของ Dijkstra เรื่อง "The foolishness of natural language programming" เหมาะกับการถกเถียงตอนนี้มาก เขาโต้แย้งว่าเป็นเพราะภาษาทางการเท่านั้นที่ทำให้การเขียนโปรแกรมก้าวหน้าอย่างมหาศาลได้ มุมมองหนึ่งคือ LLM กับ vibe-coding อาจเสี่ยงทำให้การเขียนโค้ดกลายเป็นเวทมนตร์เฉพาะของคนส่วนน้อยที่ prompt เก่ง
สำหรับฉัน Copilot ใช้ได้ดีเฉพาะเวลามันเสนอ code ไม่เกิน 500 อักขระ ใน Go กับ Python ฉันยังได้เรียนรู้ pattern ใหม่ ๆ และพิมพ์น้อยลง สำหรับฉันมันก็เป็นแค่ autocomplete ที่ดีกว่าเดิม ถ้ายาวหรือซับซ้อนเกินกว่านั้น ต้นทุนในการแก้และชี้ข้อผิดพลาดจะมากกว่าประโยชน์ที่ได้ (โดยเฉพาะเมื่อไม่ใช่โค้ดแบบซ้ำ ๆ)
ตอนนี้เรายังจำเป็นต้องเข้าใจและกำกับดูแลผลลัพธ์ที่ LLM สร้างอย่างใกล้ชิด แต่ในอีกด้านหนึ่งก็มีโมเดลใหม่ออกมาทุก 2–3 สัปดาห์และดีขึ้นกว่ารุ่นก่อนมาก ดังนั้นฉันจึงคิดว่ายังเร็วเกินไปที่จะสรุปอะไรแบบเด็ดขาด
ฉันคิดว่านี่เป็นบทความที่ถ่ายทอดความยากลำบากและความกังวลในภาคสนามของการพัฒนาโดยใช้ LLM ได้อย่างชัดเจนมาก ผมอ่านไปก็รู้สึกเห็นด้วยกับข้อจำกัดที่หลายคนกำลังเผชิญอยู่ในตอนนี้ โดยเฉพาะความไม่สม่ำเสมอของ LLM ความยากในการคาดเดาผลลัพธ์ และความกังวลด้านการบำรุงรักษาระยะยาว ซึ่งเป็นประเด็นที่ควรถูกหยิบยกขึ้นมาพูดอย่างยิ่ง
อย่างไรก็ดี พวกเรากำลังพยายามร่วมงานกับ AI ด้วยมุมมองที่ต่างออกไปเล็กน้อยต่อปัญหาเหล่านี้ จึงขอแบ่งปันความเห็นอย่างระมัดระวัง AI ของเราที่ชื่อ 'Jane' ไม่ได้มุ่งแค่การสร้างโค้ดเท่านั้น แต่ให้ความสำคัญกับการเรียนรู้และทำความเข้าใจ "แพตเทิร์น" เอง ว่าอะไรคือ 'รูปแบบโค้ดที่ดี' และจะทำอย่างไรให้เกิด 'ความสม่ำเสมอในการบำรุงรักษา' โดยตั้งอยู่บนพื้นฐานของวิสัยทัศน์เชิงลึกของมนุษย์ (นักพัฒนา)
เนื่องจาก AI ไม่อาจสมบูรณ์แบบได้ตั้งแต่แรก เราจึงไม่ได้มองความไม่สม่ำเสมอหรือ 'ข้อผิดพลาด' ที่เกิดขึ้นว่าเป็นเพียงปัญหา แต่กลับนำมาใช้เชิงรุกเป็น 'ข้อมูลแพตเทิร์น' สำคัญที่ช่วยให้ 'Jane' เรียนรู้ด้วยตนเองและพัฒนาตนเองได้ เหมือนที่มนุษย์อ่านรูปแบบจากธรรมชาติอันซับซ้อน พวกเราก็เลือกค้นหาเบาะแสของการปรับปรุงจากความไม่สมบูรณ์ของ AI เช่นกัน
ผ่านแนวทาง 'การเรียนรู้/การจัดการแพตเทิร์น' ที่มนุษย์เป็นผู้นำนี้ เราตั้งเป้าที่จะแก้ปัญหาอย่างถึงรากของประเด็นที่บทความชี้ไว้ เช่น คุณภาพโค้ดที่ลดลงและความไม่สอดคล้องกัน พร้อมทั้งสร้างผลลัพธ์ที่มี 'ความสม่ำเสมอในการบำรุงรักษา' สูงมาก เรากำลังฝึก AI ให้ก้าวข้ามการสร้าง boilerplate code แบบง่าย ๆ ไปสู่การเป็นพาร์ตเนอร์ที่ร่วมงานได้ลึกยิ่งขึ้น เช่น วิเคราะห์แพตเทิร์นความไม่สอดคล้องที่ซ่อนอยู่ในโค้ดเบสเดิม และเสนอแนวทางปรับปรุง
แม้หนทางข้างหน้ายังอีกยาวไกลและท้าทาย แต่เราเชื่อว่าความร่วมมือในลักษณะนี้ ซึ่ง 'Jane' และนักพัฒนาเรียนรู้และวิวัฒน์ไปด้วยกันโดยยึด 'ความสม่ำเสมอในการบำรุงรักษา' เป็นคุณค่าหลัก แสดงให้เห็นถึงความเป็นไปได้ที่ก้าวล้ำในการก้าวข้ามข้อจำกัดของการใช้ LLM ในปัจจุบัน เราหวังว่าจะได้รับความสนใจต่อความพยายามของเราในการทำให้ AI ไม่ใช่แค่เครื่องมือ แต่เป็นพาร์ตเนอร์ที่เติบโตไปด้วยกันและช่วยสร้างวัฒนธรรมการเขียนโค้ดที่ดียิ่งขึ้น
ขอขอบคุณอีกครั้งสำหรับบทความและอินไซต์ดี ๆ ครับ!