- Thomas Dohmke ซีอีโอของ GitHub เน้นย้ำว่า แม้ เครื่องมือ AI จะแพร่หลายมากขึ้น แต่ ทักษะการเขียนโค้ดด้วยตนเอง ก็ยังคงมีความสำคัญ
- เขาระบุว่า ต่อให้ AI จะสร้างโค้ดได้ แต่ นักพัฒนายังต้องแก้ไขและตรวจทานด้วยตนเอง จึงจะทำงานได้อย่างมีประสิทธิภาพ
- หาก พึ่งพาแต่ระบบอัตโนมัติ อาจก่อให้เกิด ความไม่มีประสิทธิภาพ และเสี่ยงต่อการลดทอนผลิตภาพ อีกทั้งการใช้โค้ดจาก AI มากเกินไปแบบ "Vibe coding" ยังเพิ่ม ความเสี่ยงด้านคุณภาพและความปลอดภัย
- บทความอธิบายโดยอ้างอิงแนวโน้มและกรณีศึกษาในอุตสาหกรรมว่า แนวทางแบบไฮบริดระหว่าง AI กับนักพัฒนามนุษย์ มีประสิทธิภาพมากที่สุด
- บทบาทของนักพัฒนาไม่ได้หายไป แต่กำลังพัฒนาไปสู่การ ทำงานร่วมกับ AI พร้อมใช้ความสามารถด้านการแก้ปัญหาเชิงกลยุทธ์และการออกแบบ มากขึ้น
CEO ของ GitHub เน้นย้ำความสำคัญของการเขียนโค้ดด้วยตนเองในยุค AI
Thomas Dohmke ซีอีโอของ GitHub เน้นย้ำถึงความสำคัญของการรักษา ทักษะการเขียนโค้ดด้วยตนเอง แม้การใช้เครื่องมือ AI ในงานพัฒนาซอฟต์แวร์จะกำลังแพร่หลายมากขึ้น
- ในรายการ “The MAD Podcast with Matt Turck” เขาอธิบายว่า นักพัฒนาต้องมี ความสามารถในการแก้ไขโค้ดที่ AI สร้างขึ้นด้วยตนเอง เพื่อป้องกัน การลดลงของผลิตภาพ
- สำหรับเวิร์กโฟลว์ที่มีประสิทธิภาพ แนวทางคือ ให้เครื่องมือ AI สร้างโค้ดและส่ง Pull Request จากนั้นนักพัฒนาใช้ทักษะของตนแก้ไขได้ทันที
- มีการกล่าวถึงความเสี่ยงด้านความไม่มีประสิทธิภาพว่า หากพึ่งพาเพียง เอเจนต์อัตโนมัติ อาจเสีย เวลาโดยไม่จำเป็น ไปกับการอธิบายการแก้ไขง่าย ๆ ด้วยภาษาธรรมชาติ
- Dohmke ชี้ว่า “การพยายามอธิบายด้วยภาษาธรรมชาติในสิ่งที่คุณทำได้อยู่แล้วโดยตรงด้วยภาษาการเขียนโปรแกรม เป็นทางเลือกที่ไม่มีประสิทธิภาพที่สุด”
- คำว่า “vibe coding” ที่ Andrej Karpathy ผู้ร่วมก่อตั้ง OpenAI กล่าวถึง หมายถึง การพึ่งพาโค้ดที่ AI สร้างมากเกินไป ซึ่ง Dohmke ก็เตือนให้ระวังเช่นกัน
อินไซต์และแนวโน้มในอุตสาหกรรม
1. คำตอบที่เหมาะสมที่สุดของ AI coding คือกลยุทธ์แบบไฮบริด
- มุมมองของ Dohmke สอดคล้องกับ ฉันทามติของอุตสาหกรรม ที่มองว่า การผสานระบบอัตโนมัติของ AI เข้ากับทักษะการเขียนโปรแกรมของมนุษย์ คือแนวทางที่เหมาะสมที่สุด
- จากงานวิจัยของ Deloitte นักพัฒนาใช้เครื่องมือ AI เป็นหลักเพื่อเขียนโค้ดแบบ boilerplate แต่ยังคง การตรวจทานขั้นสุดท้ายโดยมนุษย์ เอาไว้ ซึ่งช่วยเพิ่มผลิตภาพได้ 10~20 นาที
- เนื่องจาก ราวครึ่งหนึ่งของโค้ดที่ AI สร้างมีข้อผิดพลาดบางส่วน กลยุทธ์แบบ “เชื่อใจได้แต่ต้องตรวจสอบ” จึงกำลังกลายเป็นมาตรฐานของอุตสาหกรรม
- Google มี โค้ดมากกว่า 25% ทั้งหมดที่สร้างโดย AI แต่จากประสบการณ์ก็ยังพบว่า กระบวนการรีวิวและปรับปรุงอย่างจริงจังโดยนักพัฒนามนุษย์ ยังคงจำเป็น
- แนวทางที่สมดุล เช่นนี้สะท้อนว่า อุตสาหกรรมกำลังเติบโตสู่ทิศทางที่ตระหนักถึงข้อจำกัดของ AI และใช้ความเชี่ยวชาญของนักพัฒนาเพื่อ เสริมพลัง ไม่ใช่แทนที่
2. บทบาทของนักพัฒนากำลังเปลี่ยน ไม่ได้หายไป
- แทนที่ AI จะทำให้อาชีพโปรแกรมเมอร์หายไป บทบาทของนักพัฒนากำลังเปลี่ยนจากโค้ดเดอร์ล้วน ไปเป็นผู้จัดการกระบวนการพัฒนาที่อาศัย AI
- ผู้เชี่ยวชาญคาดว่า สายงานพัฒนาจะถูกแยกออกเป็น วิศวกรผลิตภัณฑ์ที่ใช้ AI และ สถาปนิกที่รับประกันคุณภาพ/ความปลอดภัยของระบบขั้นสูง
- การเปลี่ยนแปลงนี้หมายถึงความจำเป็นของทักษะใหม่ เช่น วิธีใช้ AI อย่างมีประสิทธิภาพ, ความสามารถในการแก้ปัญหาเชิงกลยุทธ์ และ ความสามารถด้านการออกแบบระดับสูง
- เมื่อประกอบกับ ภาวะขาดแคลนวิศวกรซอฟต์แวร์ และผลที่พิสูจน์แล้วว่า เครื่องมือ AI ช่วยสนับสนุนนักพัฒนารุ่นจูเนียร์ได้ จึงยังเปิด โอกาสการเติบโตใหม่ให้กับนักพัฒนาที่มีประสบการณ์
- สิ่งนี้บ่งชี้ว่า เช่นเดียวกับยุคที่เครื่องมือพัฒนาและเทคโนโลยี abstraction เกิดขึ้นในอดีต ความคิดสร้างสรรค์ของมนุษย์ก็ยังคงจำเป็น
3. ภาวะกลืนไม่เข้าคายไม่ออกระหว่างผลิตภาพกับคุณภาพของ “Vibe coding”
- ปรากฏการณ์ “Vibe coding” เป็นเทรนด์ที่เผยให้เห็นทั้ง ข้อได้เปรียบด้านผลิตภาพ และ ข้อจำกัดด้านคุณภาพ/ความปลอดภัย ของโค้ดที่สร้างโดย AI
- เครื่องมือ AI ช่วยสนับสนุน การทำต้นแบบอย่างรวดเร็วและการพัฒนาแบบวนซ้ำ แต่ก็ทำให้ความกังวลเรื่อง คุณภาพโค้ดที่ลดลงและความเสี่ยงด้านความปลอดภัย เพิ่มขึ้นด้วย
- ในกรณีใช้งานจริงก็มีการเกิด ช่องโหว่ด้านความปลอดภัย จาก การนำโค้ด AI มาใช้โดยไม่ตรวจสอบ
- โดยเฉพาะใน สตาร์ตอัปที่ก่อตั้งโดยผู้ประกอบการที่ไม่ได้จบสายเทคนิค การใช้โค้ด AI มากเกินไปอาจสะสมเป็น หนี้ทางเทคนิค และนำไปสู่ การฉุดรั้งการเติบโตในระยะยาว
- จากประสบการณ์ของบริษัทไอทีขนาดใหญ่ การสร้างสมดุลระหว่างระบบอัตโนมัติกับการควบคุมคุณภาพอย่างเข้มงวด คือหัวใจของการนำ AI มาใช้ และ บทเรียนนี้ก็สำคัญต่อสตาร์ตอัปเช่นกัน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมสงสัยมากว่าทำไมคนถึงเลิกพูดถึง ความซับซ้อนโดยเนื้อแท้ ของระบบกันไปแล้ว
ใน No Silver Bullet ของ Fred Brooks มีการชี้ว่าความยากที่แท้จริงของวิศวกรรมซอฟต์แวร์มาจากการทำความเข้าใจ ทำให้ชัดเจน และสร้างแบบจำลองของพื้นที่ปัญหาหลัก ส่วน ความซับซ้อนโดยบังเอิญ อย่างข้อจำกัดของเครื่องมือนั้นเป็นเรื่องรอง
ช่วงนี้มีคนพูดกันมากว่า AI agent จะสร้างทั้ง codebase จาก prompt ภาษาธรรมชาติแทนวิศวกรได้ แต่สมมติฐานนี้เป็นความเข้าใจผิดว่าปัญหาเรื่อง specification ถูกแก้ไปแล้ว ทั้งที่ในความเป็นจริง การเปลี่ยนไอเดียที่คลุมเครือให้กลายเป็นระบบที่ละเอียดและแข็งแรงยังคงเป็นบทบาทหลักของวิศวกร
ถ้ามีใครให้รายละเอียด specification และทำงานวนกับ AI เพื่อสร้างซอฟต์แวร์ เท่ากับว่ากำลังใช้ AI เพื่อลดความซับซ้อนโดยบังเอิญ ซึ่งคล้ายกับตอนที่นักพัฒนาย้ายจาก assembly ไปใช้ภาษาระดับสูง มันไม่ได้มาแทนวิศวกร แต่แค่เพิ่ม productivity เท่านั้น ทั้งยังช่วยลดต้นทุนของงานซ้ำๆ และเปิดโอกาสให้ขยายผลกระทบได้กว้างขึ้น
ถ้า agent สร้างผลิตภัณฑ์ได้จากแค่ prompt ก็เป็นเพราะมีใครบางคนกำหนดระบบไว้อย่างชัดเจนแล้ว และถ้าใช้ AI เพื่อก็อปปี้ผลิตภัณฑ์ที่มีอยู่ ก็ไม่ใช่การแก้ปัญหาทางเทคนิค แต่เป็นการแข่งขันด้านการกระจายสินค้าหรือต้นทุน ซึ่งไม่ใช่ นวัตกรรมทางวิศวกรรม แต่เป็นนวัตกรรมทางธุรกิจ
เลยสงสัยว่าผมกำลังพลาดอะไรไปรึเปล่า
ประเด็นหลักคือเหตุใดงานด้าน specification ถึงถูกละเลยมาตั้งนานก่อน AI จะมาเสียอีก
ผู้มีส่วนได้ส่วนเสีย (ลูกค้า ผู้จัดการ) สมัยก่อนก็สั่งให้เขียนโค้ดแบบคร่าวๆ จากความรู้สึกอยู่แล้ว อธิบายลวกๆ แล้วหวังว่าจะมีใครสักคนเสก solution ที่ตรงใจออกมาได้ ไม่มีใครรู้จริงหรอกว่ามันทำงานครบหรือไม่ ส่วนใหญ่ก็แค่ดูเหมือนใช้ได้ระดับหนึ่งแล้วก็ปล่อยผ่าน
ในหลายกรณี โปรแกรมเมอร์เป็นคนทำให้ชัดขึ้นเองจาก ความรู้โดเมน (เช่น รู้โดยสัญชาตญาณว่าหน้า form submit ที่ถูกต้องควรหน้าตาอย่างไร)
ตอนนี้แค่เปลี่ยนอีกฝ่ายเป็น AI แทน ก็ต้องรอดูว่าวิธีแบบนี้จะทำซ้ำได้เหมือนเดิมหรือไม่
การแยก ความซับซ้อนโดยเนื้อแท้/โดยบังเอิญ เป็น insight ที่สำคัญมากในการคิดว่า AI จะรับงานพัฒนาซอฟต์แวร์ได้ไกลแค่ไหน
นักพัฒนาหลายคนอาจอธิบายเป็นคำพูดไม่ได้ว่าทำไมตัวเองจะไม่ถูก AI แทนที่ แต่โดยสัญชาตญาณแล้วสิ่งที่รู้สึกก็คือประเด็นนี้
จริงๆ ผมเองก็เคยลองให้ agent อย่าง Claude แก้ปัญหาใน codebase ขนาดใหญ่และซับซ้อนมากที่พันกับ business logic ภายนอก แต่ AI ไม่เข้าใจ business requirement หรือบริบทได้แบบจับสัญชาตญาณ จึงเปลี่ยนโค้ดเชิงธุรกิจไม่ได้ ทำได้แค่ช่วยกับการเปลี่ยนโค้ดง่ายๆ ที่มี context แคบๆ กล่าวคือจัดการได้แค่ ความซับซ้อนโดยบังเอิญ และยังมีข้อจำกัดในการแปลง requirement จริงให้เป็นระบบ ซึ่งเป็นบทบาทแท้จริงของนักพัฒนา
อีกอย่าง ในความเป็นจริง ปัญหาที่นักพัฒนาหลายคนกำลังแก้อยู่อาจไม่ใช่ปัญหาเชิงเทคนิค แต่เป็น ปัญหาด้านการกระจาย/ตลาด การใช้ AI มาแทน junior ยังดูน่ากังวล ประเด็นใหญ่สุดคือ AI ยัง แก้ไขตัวเอง ไม่ได้ ถึงอย่างนั้น ธุรกิจที่ขับเคลื่อนด้วย AI เพื่อกดต้นทุนของธุรกิจเดิมก็จะยังเกิดขึ้นต่อไป ส่วนการเปลี่ยนแปลงนั้นจะดีหรือร้าย ก็ไม่มีความหมายอะไรนักสำหรับคนที่ถูกเบียดตกงาน
มีคำตอบสำหรับคำถามว่า “ผมกำลังพลาดอะไรอยู่ไหม?”
คือมี นักพัฒนาจำนวนมากที่ใช้ซอฟต์แวร์ไม่เป็นจริงๆ และคนเหล่านี้จะถูกแทนที่ด้วย AI ได้ง่าย
ในงานเก่าผมทำ JavaScript และคนที่ทำอะไรน่าทึ่งได้จริงๆ มีแต่พวกที่เขียนโค้ดเป็นงานอดิเรกมานานแล้ว ในบริษัท คนส่วนใหญ่แม้แต่แสดงข้อความบนจอก็ยังลำบาก นี่ไม่ได้พูดเล่น
หลายคนพยายามลุย framework ใหญ่ๆ แต่สุดท้ายก็ทำได้แค่ ก็อปแปะ จนพอให้มันรันได้ อ้างว่าแก้ปัญหาความซับซ้อนระดับสูง ทั้งที่แทบทั้งหมดเป็นงานไม่จำเป็นหรือโชว์โค้ด
พวกเขาแทบไม่มีความสามารถในการสร้างแอปต้นฉบับ เขียนเอกสาร หรือวัด usability จริง
แล้วจะแก้ยังไง? ต้องมี มาตรฐานสูง แบบสอบใบอนุญาตวิชาชีพทนาย ถ้าไม่ผ่านเกณฑ์ก็ควรคัดออกอย่างเด็ดขาด และรับเป็นแค่ junior หรือ apprentice เพื่อให้รุ่นของนักพัฒนาเติบโตอย่างถูกทาง
คำตอบง่ายๆ ของ “สิ่งที่กำลังมองข้าม” คือ ไม่มีใครในวงการอ่าน "No Silver Bullet"
คนที่เขียนเรื่อง technical debt หรือ system architecture ไม่ใช่ผู้ตัดสินใจที่มีอำนาจชี้เป็นชี้ตายทีม/ธุรกิจจริงๆ และหนังสือพวกนั้นก็เป็นแค่อ่านเสริมหรือไม่อ่านก็ได้สำหรับวิศวกร
คนที่นำกระแสเรื่อง AI มาแทนการเขียนโค้ด มักแยกไม่ออกระหว่างการทำ MVP กับการขยาย codebase ตลอด 10 ปีพร้อมปรับปรุง legacy
ยกตัวอย่าง ผู้จัดการคนหนึ่งเคยเสนอไอเดียผิดพลาดตามสูตรว่าในหนึ่งวันให้แบ่งเวลา 33% ไป 3 โปรเจ็กต์เท่าๆ กัน การจัดสรรคนและโครงสร้างเวลาควรเป็นทักษะของผู้จัดการ แต่สุดท้ายคนที่ต้องมาจัดการให้ใช้ได้จริงก็คือวิศวกร
ตอนนี้ผู้จัดการแบบนั้นกำลังเสนอว่า “ให้ AI จัดการ technical debt/การทดสอบทั้งหมดสิ” แล้วพอมันไม่ได้ผล คนที่ต้องอธิบายก็ยังเป็นวิศวกร
เรื่องความซับซ้อนจริงๆ แล้วก็เป็นแค่การวนกลับมาของ ปัญหาการบริหารที่ล้มเหลว เท่านั้น วิศวกรอาวุโสส่วนใหญ่ไม่เชื่ออยู่แล้วว่างานของตัวเองจะถูกแทนที่ด้วย prompt ง่ายๆ
ประเด็นที่เราควรคุยกันจริงๆ คือ “software engineering มีปัญหาด้านการจัดการรุนแรง และ AI ทำให้มันเด่นชัดขึ้น”
คนที่ไม่ใช่นักพัฒนาหรือแม้แต่นักเรียนจำนวนมาก รู้สึกว่าการพัฒนาซอฟต์แวร์ต้องเรียนรู้การใช้เครื่องมือที่ซับซ้อน จึงถูกดึงดูดด้วยคำสัญญาว่า “ถ้าทำ specification ได้ดีก็ใครๆ ก็สร้างซอฟต์แวร์ได้” (โดยจงใจไม่พูดว่าความสามารถในการทำ specification เองก็ยากมากและต้องมีเทคโนโลยีสนับสนุน)
สมัย no-code ก็เป็นแบบนี้ และในทางปฏิบัติ เครื่องมือ no-code ก็มีข้อจำกัด ยิ่งทรงพลังเท่าไร ก็ยิ่งซับซ้อนและต้องเรียนรู้อย่างเชี่ยวชาญมากขึ้น
แนวคิดที่ว่า LLM จะมาแทน SWE ก็เป็นเวอร์ชันของแนวคิดเดียวกัน คือ “แทนที่จะเรียนรู้ระบบ ก็ใช้ prompt ภาษาธรรมชาติแล้วให้โมเดลไปใช้เครื่องมือแทน”
ถ้ามองแบบนี้ สิ่งที่ตอนนี้เรียกว่า vibe coding ก็คือจุดสุดยอดของเป้าหมายนี้เอง (แม้จะมีจุดอ่อนจริงอย่างเรื่องการบำรุงรักษา)
ในมุมมองผม เหตุผลหนึ่งที่ผู้จัดการอยากกำจัด SWE คือพวกเขาสื่อสารกับ SWE ไม่รู้เรื่อง
พอมี LLM ก็เลยมองว่าสามารถคุยกับเครื่องได้โดยไม่ต้องผ่าน “พวกเนิร์ด (นักพัฒนา)” และนั่นคือทางแก้ปัญหา
ภาษาการเขียนโปรแกรมเป็นสื่อที่เหมาะกับ specification ที่แม่นยำ ของโปรแกรมที่ต้องการ ภาษาธรรมชาติไม่มีทางชัดเจนได้ถึงระดับนั้น
ดังนั้นการรีวิวและแก้ไขผลลัพธ์ที่ AI สร้างขึ้นจึงเป็นเรื่องธรรมดา และบางครั้งการแก้เองก็ง่ายกว่าการอธิบายสิ่งที่ต้องเปลี่ยนเสียอีก
ผมสงสัยว่างานวิจัยอิสระที่พบว่า Copilot เพิ่ม อัตราความผิดพลาด อาจเป็นเหตุผลตามธรรมชาติที่ทำให้คนระมัดระวังมากขึ้นหรือไม่
คนขาย AI มักอ้างว่าผู้เขียนที่เป็นมนุษย์จะไม่จำเป็นอีกต่อไปในไม่ช้า
Transformer ใช้ได้กับหลายอย่าง เช่น automated testing, การขยาย specification, การเร่งเริ่มโปรเจ็กต์ใหม่, การสำรวจ API ที่ไม่รู้จัก, การขึ้นฟีเจอร์เริ่มต้น, code review และอื่นๆ
ต่อให้ยอมรับว่าโค้ดคือสื่อที่ถูกต้องสำหรับ specification แต่ Transformer ก็ทำหน้าที่เป็นอินเทอร์เฟซอัตโนมัติระหว่างภาษาธรรมชาติกับสื่อนั้น (โค้ด)
ช่วงหลัง Transformer ไม่มีปัญหาเรื่องการสร้างโค้ด เพราะมีองค์ความรู้มหาศาล
เช่นเดียวกับที่มนุษย์แสวงหา automation ในการเขียนโปรแกรม Transformer คือก้าวกระโดดครั้งใหญ่
ในอนาคต ณ จุดใดจุดหนึ่ง การที่ AI มาแทนโปรแกรมเมอร์อาจกลายเป็นจริงได้ (เหมือนที่ เครื่องทอผ้าอัตโนมัติ, แท่นพิมพ์ และเครื่องคำนวณอิเล็กทรอนิกส์เคยแทนงานมนุษย์)
แต่อาจไม่ใช่ตอนนี้ หรือแม้แต่ใน 10 ปีข้างหน้า และยังมีโจทย์เรื่อง hallucination, accuracy, การทำเป็นเครื่องมือ, การสร้างโครงสร้างพื้นฐาน ฯลฯ ที่ต้องแก้
การจะยังมีงานโปรแกรมมิงหรือไม่ อาจขึ้นอยู่กับโดเมน ทักษะ และความคาดหวังด้านค่าตอบแทน
สิ่งสำคัญคือต้องรับ AI tool อย่างจริงจังและปรับตัว ไม่อย่างนั้นก็เสี่ยงจะตามไม่ทันการเปลี่ยนแปลงเหมือนยุคเริ่มต้นของ personal computing หรืออินเทอร์เน็ต
ผมมองว่า ความสร้างสรรค์หลอกๆ ของ AI มีขีดจำกัด
ถ้าผลลัพธ์จากการฝึก LLM ทั้งหมดถูกวนกลับมาเป็นอินพุตของ LLM ต่อไปเรื่อยๆ ขอบเขตของไอเดียใหม่จะไม่ขยายออกไปเลย
แต่มนุษย์ยังแสดงความคิดสร้างสรรค์ที่ก้าวข้ามขอบเขตนั้นอยู่เสมอ
อนาคต LLM อาจทะลุกำแพงนี้ได้ แต่ตอนนี้มันก็ยังไม่ต่างจาก ‘ลิงพิมพ์ดีด’ มากนัก
จากประสบการณ์ของผม LLM มีประสิทธิภาพที่สุดเมื่อใช้เป็น scaffolding (เครื่องมือช่วยตั้งต้น)
ผมเทสิ่งที่อยากทำเป็นเหมือนการ dump ความคิดออกไป แล้วขอให้มันสร้าง model กับ controller พื้นฐานที่ต้องใช้ให้
จากนั้นผมก็เหลือแค่โฟกัสกับ view และ business logic จริงๆ ทำให้แบ่งงานกันชัดเจน
เท่าที่ทราบ ตอนที่ภาษาระดับสูงเพิ่งเกิดใหม่ๆ ในช่วงแรกมาก ก็เคยมีคำวิจารณ์คล้ายกับที่ตอนนี้วิจารณ์ LLM หรือการเขียนโค้ดด้วยภาษาธรรมชาติ เช่น “ควบคุมหน่วยความจำโดยตรงยาก เลยขาดความแม่นยำ”
ปัญหาไม่ใช่ว่าภาษาธรรมชาติ ไม่มีทางมีความแม่นยำได้ แต่คือคนส่วนใหญ่ไม่ได้อธิบาย requirement อย่างแม่นยำ และแม้จะรู้ชัดว่าตัวเองต้องการอะไร ก็ยังอธิบายสิ่งที่คอมพิวเตอร์ต้องทำจริงๆ ไม่ได้ดีพอ
ผลก็คือวิศวกรต้องเดาเยอะมากเวลาแปล requirement ทางธุรกิจ หรือไม่ก็ LLM ต้องมารับบทนั้นทั้งที่เข้าใจบริบทได้น้อยกว่าเดิมอีก
วิธีใช้ AI ที่ดีที่สุดคือใช้เพื่อไม่ให้ผมสะดุดกับ API ที่ไม่เคยเห็น หรือฟีเจอร์ที่น่ารำคาญจนไม่อยากทำ และช่วยให้ยังคงอยู่ใน flow state ได้
AI สามารถนำ pattern ร่วม ไปใช้กับโค้ดทั้งชุดได้อย่างรวดเร็วและมีประสิทธิภาพ แต่โดยแก่นแล้วมัน "ไม่รู้ด้วยตัวเองว่ากำลังทำอะไรอยู่"
ขอแชร์ประสบการณ์ล่าสุด ผมเคยให้ LLM refactor โค้ดที่เกี่ยวกับการคำนวณขนาด popup และการกำหนดตำแหน่ง
ที่หนึ่งเขียนด้วย
ifอีกที่เขียนด้วยswitchแต่ LLM ไม่ตอบสนองอย่างยืดหยุ่นเลยต่อความจริงที่ว่าสองแบบนี้ต่างกัน ต่อให้อธิบายชัดเจน มันก็จะบังคับให้ทั้งสองที่เป็น if หรือ switch แบบเดียวกันหมดLLM มีแนวโน้มจะคง pattern ของ token ก่อนหน้าไว้เรื่อยๆ
กรณีนี้ยังไม่ใช่ปัญหาใหญ่มาก แต่ถ้าซับซ้อนขึ้นอีกนิด มันจะละเลยรายละเอียดแล้วสร้างโค้ดที่ดูเหมือนใช่แค่ผิวเผิน
แต่ถ้า แยกงานเป็นชิ้นเล็กๆ แล้วสั่งให้ชัด LLM จะมีประสิทธิภาพมาก เช่น คำสั่งว่า “เก็บขนาดใน m_StateStorage แล้วค่อยนำไปใช้ในขั้น render” แบบนี้มันทำได้ง่าย
โดยเฉพาะถ้าใช้ร่วมกับโมเดลอย่าง Cerebras ที่จัดการ โค้ดขนาดหลายกิโลไบต์ ได้เร็ว มันเร็วกว่าการที่ผมจะพิมพ์ความคิดเป็นโค้ดจริงเองมาก
สิ่งที่เราวิจารณ์กันทุกวันนี้จริงๆ คือข้อจำกัดด้านประสิทธิภาพของ โมเดล Transformer ในปัจจุบัน
วงการนี้เปลี่ยนเร็วมากจนข้อจำกัดของวันนี้อาจหมดความหมายในอีกหนึ่งเดือนก็ได้
คำว่า “LLM” เองก็เป็นคำที่คลุมเครือถ้าพูดให้เคร่งครัด โมเดล Transformer รุ่นใหม่เป็น multimodal จัดการข้อมูลได้หลายรูปแบบ ไม่ใช่แค่ข้อความ
เพราะฉะนั้นถ้าจะวิจารณ์ ก็ควรชี้ให้ชัดว่าเป็นโมเดล/เครื่องมือ/พาราไดม์แบบไหน จึงจะถกกันได้อย่างมีประสิทธิภาพ
เรื่อง “ขาดแคลนวิศวกรซอฟต์แวร์” และผลวิจัยที่ว่า “AI ช่วย junior developer ได้เป็นพิเศษ”
ในไทม์ไลน์โลกที่ผมอยู่ ตลาดงานสายเทค แย่มาก และ AI กลับยิ่งทำให้ junior เสียเปรียบ เพราะไปแย่งประสบการณ์ในจุดที่พวกเขาควรได้เติบโต
เมื่อเร็วๆ นี้ผมมีประสบการณ์ตลกๆ กับ Claude ใน Zed พอสั่งว่า “ช่วยแก้ error ที่บรรทัด 71 หน่อย” มันดันไปเปลี่ยน formatting ไร้สาระที่บรรทัด 91
ให้ความรู้สึกเหมือนเล่นเกมโทรศัพท์เสียกับ LLM
การแก้แบบง่ายๆ แค่นี้ทำเองยังเร็วกว่า และประสบการณ์นี้ก็ย้ำความรู้สึกอีกครั้งว่า “LLM ไม่ได้คิดจริงๆ”
LLM แย่มากเรื่องการรับรู้ เลขบรรทัด
ประสบการณ์แบบนี้ให้บทเรียนว่า “LLM นับเลขบรรทัดไม่ได้”
คราวหน้าถ้าสั่งว่า “ช่วยแก้ error ในฟังก์ชัน XYZ” หรือแปะบรรทัดนั้นไปตรงๆ น่าจะดีกว่า
และแน่นอนว่า LLM ไม่ได้คิด มันเป็นแค่ สมการ ขนาดมหึมาเท่านั้น
ดูเหมือนในเธรดนี้จะมีคนจำนวนมากที่เพิ่งลองเขียนโค้ดกับ AI เป็นครั้งแรก
อาจเป็นความผิดพลาดของ operator ก็ได้
คุณต้องให้ context ที่เหมาะสมกับ LLM เลขบรรทัดไม่ใช่ context ที่ดี
สำหรับผม บทบาทของ software engineer คือการแปลง requirement ให้เป็นซอฟต์แวร์
ซอฟต์แวร์ไม่ได้มีแค่โค้ด และ requirement ก็ไม่ได้ถูกส่งมาเป็นเพียงภาษาธรรมชาติอย่างเดียว
ณ ตอนนี้ ต่อให้ทำงานร่วมกับ AI ผมก็ยังไม่เร็วกว่า AI เองนัก (ยกเว้นงานง่ายหรือซอฟต์แวร์ขนาดเล็ก)
ปัจจุบัน AI ในสายตาผมอยู่ระดับ junior/mid-level developer
ช่วง 2 ปีที่ผ่านมา AI ไม่ได้ดีขึ้นแบบก้าวกระโดดในระดับที่ผมรู้สึกได้
requirement ส่วนใหญ่ไม่ได้ถูกทำเอกสารไว้อย่างชัดเจน
แทบไม่มีใครรู้ด้วยซ้ำว่า business logic คืออะไร
เพราะแบบนั้น software engineer จึงต้องเดินไปถามเองบ่อยมาก
ยังต้องอาศัย ประสบการณ์และสัญชาตญาณ เพื่อคิดเรื่อง ทิศทางการเติบโตของซอฟต์แวร์ และจะออกแบบอย่างไรให้รองรับการขยายตัวนั้นได้
ผมนึกไม่ออกเลยว่า LLM จะมาทำหน้าที่นี้ได้แม้เพียงบางส่วน
ผมไม่เคยเห็นโปรเจ็กต์ซอฟต์แวร์ที่มี requirement ชัดเจนเลยสักครั้ง
ครึ่งหนึ่งของโปรเจ็กต์คือ ‘การหาว่าจริงๆ แล้วต้องการอะไรกันแน่’
LLM ยังไปไม่ถึงแม้แต่ ระดับ junior
ถ้า AI ที่มีอยู่ตอนนี้เทียบได้กับ mid-level developer ที่บริษัทคุณ นั่นคือ ปัญหาด้านการจ้างคน ของบริษัทคุณแล้ว
ข้อดีใหญ่ที่สุดอย่างหนึ่งของคอมพิวเตอร์คือ automation ที่เชื่อถือได้และทำซ้ำได้
ภาษารูปแบบ อย่างภาษาการเขียนโปรแกรม สามารถสื่อความต้องการด้าน automation ได้อย่างชัดเจนโดยไม่กำกวม
ภาษาธรรมชาติไม่ได้มีความแม่นยำขนาดนั้น
แหล่งอ้างอิงที่เป็นความจริงแท้จริงของโปรแกรมก็คือ โค้ด ในที่สุด
หากมนุษย์ต้องการควบคุมการทำงานของโปรแกรมอย่างแม่นยำ ความสามารถในการ เข้าใจและแก้ไขโค้ด คือสิ่งสำคัญที่สุด
คำว่า “manual” มีนัยเชิงลบอยู่
สิ่งที่บทความนั้นน่าจะตั้งใจสื่อคือ “การเขียนโค้ดโดยมนุษย์ยังคงเป็นแกนหลัก”
ผมไม่แน่ใจว่า GitHub CEO ใช้คำว่า "manual" จริงหรือไม่ น่าจะดีถ้ามีแหล่งข่าวที่เลือกคำได้เป็นกลางหรือแม่นยำกว่านี้
การลดคุณค่าการเขียนโค้ดโดยมนุษย์ว่าเป็น “manual” ไม่ใช่เรื่องที่เหมาะสม นักพัฒนามนุษย์เองก็ใช้ ชุดเครื่องมือ automation อีกมากมายนอกเหนือจาก AI
อาจให้ความรู้สึกแย่พอๆ กับคำว่า “การคิดแบบ manual”
เพิ่งรู้เหมือนกันว่า “manual” มีความหมายเชิงลบ
สมัยนี้คนต่อต้านงาน manual กันขนาดนั้นเลยหรือ
สงสัยว่าความต่างระหว่าง “manual coding” กับ “human coding” คืออะไร
“ถ้าพึ่งพา AI agent อย่างเดียวอาจไม่มีประสิทธิภาพ”
เช่น หลายครั้งการแก้โค้ดตรงๆ เร็วกว่าการอธิบายการเปลี่ยนแปลงง่ายๆ ด้วยภาษาธรรมชาติยาวๆ
ดังนั้น การโต้ตอบกับ AI agent อย่างกระตือรือร้น น่าจะเป็น workflow ที่เหมาะที่สุด
หลายครั้งพอเริ่มคิดการเปลี่ยนแปลงเป็นภาษาธรรมชาติ ก่อนจะพิมพ์ออกไป ผมก็นึกวิธีแก้ตรงๆ ที่ต้องการได้ในหัวแล้ว
ยิ่งเป็น การเปลี่ยนที่มี context เยอะ ก็ยิ่งเหมือนผมจะแก้เองได้เร็วกว่า agent
อยากรู้ว่าระดับการโต้ตอบเชิงรุกแบบไหนถึงจะพอดี
ผมเพิ่งเข้าร่วม startup ด้าน agent tooling และภายในเราคุยกันเรื่องนี้เยอะมาก
ผมคิดว่าการให้ feedback กับ agent ต่อเนื่องแบบ “พูดตรงๆ เลยนะ คุณทำอันนี้ไม่เก่ง!” นั้นโอเค แต่บางเรื่องก็น่าเหนื่อย
อยากรู้ว่าคุณคิดเห็นอย่างไร หรือมีจินตนาการ/feedback เพิ่มเติมต่อ workflow แบบนี้ไหม
AI ยังไปไม่ถึงระดับที่คาดหวัง
ตัวอย่างเช่น ผมมักเจอปัญหากับ reference หรือ specification ที่ผิดอยู่บ่อยๆ ซึ่งน่าจะเพราะ AI ถูกฝึกด้วย ข้อมูลเก่า และขาดความสามารถอัปเดตแบบเรียลไทม์
LLM และโซลูชัน GI ที่มีอยู่ตอนนี้พยายามแก้ทุกขั้นตอน (n-step) ในครั้งเดียว จนกลับทำให้ประโยชน์ใช้งานลดลง
ถ้ามันช่วยจัดการได้ดีแค่ขั้นที่ 1 ถึงขั้นที่ i จากมุมมองมนุษย์ก็น่าจะช่วยได้มากกว่า
ผมยังไม่เคยเห็นโซลูชัน AI แบบ modular อย่างสมบูรณ์ ที่ผมต้องการ (เช่น สะท้อนสไตล์ github ของผม และอ้างอิงแค่ resource a, b, c เพื่อแก้ปัญหา x)
และผมหวังว่าจะได้เห็น coding AI ที่ สำรวจปัญหาแบบเป็นลำดับ พร้อมถามคำถามเพิ่มและคุยตอบโต้เป็นระยะๆ
รู้สึกว่าการที่ CEO คนหนึ่งออกมาพูดเรื่อง AI กับการเขียนโค้ดในทิศทางที่ค่อนข้างต่างออกไปนั้นน่าสนใจ
โดยปกติ CEO หรือนักลงทุนมักทำนายบทบาทนักพัฒนาที่ลดลงด้วยคำพูดอย่าง “มากกว่า 30% ของโค้ดทั้งหมดถูกเขียนโดย AI” แต่ในความเป็นจริง มันก็แค่เครื่องมือที่ช่วยให้นักพัฒนาคนเดิมเขียนโค้ดได้เร็วขึ้น
และยังย้ำด้วยว่าการเขียนโค้ดเองนั้นเป็นเพียงส่วนหนึ่งของงานพัฒนาซอฟต์แวร์ทั้งหมด