Sloptember ชั่วนิรันดร์
(geohot.github.io)- AI agent ไม่ได้ทำการเขียนโปรแกรมจริง ๆ แต่เลียนแบบการกระจายของงานเขียนโปรแกรม และผลลัพธ์ที่พังจะยิ่งดูออกได้ยากขึ้นเรื่อย ๆ
- ผู้เขียนเคยใช้มันเขียนบางส่วนของ tinygrad และรีเวิร์ส ชิป USB <-> PCIe แต่ก็ยังอดสงสัยไม่ได้ว่าถ้าทำเองอาจจะดีกว่าและเร็วกว่า
- agent ช่วยให้ช่วงเริ่มต้นคืบหน้าเร็ว แต่พอถึงช่วงเก็บงานกลับทำให้ต้องหวังกับการลองซ้ำเหมือน คันโยกสล็อตแมชชีน และไปไม่ถึงเส้นชัย
- องค์กรขนาดใหญ่ อาจได้รับความเสียหายด้านคุณภาพมากกว่าคนเก่งเดี่ยวหรือทีมเล็ก เพราะวงจรป้อนกลับช้าและมีผลผลิตเพิ่ม 10 เท่าโดยไม่ตรวจทานตัวเอง
- AI มีประโยชน์กับการค้นหาและการทำต้นแบบอย่างรวดเร็ว แต่ยังยากจะเรียกว่าเป็น วิศวกรซอฟต์แวร์ จริง ๆ และสิ่งสำคัญคือการรู้ว่าเมื่อไรไม่ควรใช้มัน
คำวิจารณ์หลักต่อ AI agent
- กระแสการนำ AI agent มาใช้กับการพัฒนาซอฟต์แวร์อาจเป็นความผิดพลาดที่ costly มาก และ agent ก็ใกล้เคียงกับโมเดลสถิติที่ซับซ้อนซึ่งเลียนแบบการกระจายของการเขียนโปรแกรม มากกว่าจะเป็นการเขียนโปรแกรมจริง
- ผลลัพธ์ที่ได้เสียหายอยู่ แต่เสียหายในแบบที่ตรวจจับได้ยากขึ้นเรื่อย ๆ และยิ่งโมเดลสถิติมีความแม่นยำขึ้น ปัญหาแบบนี้ก็ยิ่งสังเกตได้ยาก
- ตลอด 6 เดือนที่ผ่านมา ผู้เขียนใช้ agent เขียน tinygrad บางส่วน และรีเวิร์ส ชิป USB <-> PCIe แต่ก็ยังสงสัยว่าถ้าทำเองอาจจะได้ผลดีกว่าและเร็วกว่านี้
- agent เร่งความคืบหน้าในช่วงแรก แต่ในช่วงท้ายกลับทำให้ต้องคอยดึง คันโยกสล็อตแมชชีน ซ้ำ ๆ หวังว่าผลลัพธ์จะดีขึ้น และสุดท้ายก็ไปไม่ถึงปลายทาง
- ผู้เขียนลองมาหลายโมเดล หลาย harness และหลาย prompt แล้ว ดังนั้นคำโต้แย้งว่า “ใช้ผิดวิธี” จึงฟังไม่ค่อยขึ้น และคล้ายกับการบอกว่าถ้าลงเดิมพันกับสล็อตแมชชีนด้วยวิธีเฉพาะก็จะชนะ
- ตัว AI เองยังมีประโยชน์ และสำหรับการค้นหาหลายแบบมันทำงานได้เหมือน Google ที่ดีกว่า อีกทั้งยังเร็วมากสำหรับการทำต้นแบบอย่างรวดเร็วเมื่อไม่ได้กังวลเรื่องความสมบูรณ์
- แต่ถ้าจะมองว่าเป็น วิศวกรซอฟต์แวร์ ก็คงยังไม่ใช่ และยังไม่ใกล้เคียงมาตรฐานของบริษัทไหนเลยที่ผู้เขียนเคยร่วมงานด้วย โดยหัวใจสำคัญคือการรู้ว่าเมื่อไรควรใช้และเมื่อไรไม่ควรใช้
ผลกระทบต่อองค์กรและคุณภาพ
- AFL พบ bug ได้มากกว่า LLM แต่ไม่มีใครกลัวว่าจะเสียสถานะในฐานะนักพัฒนา และหมากรุกกับ Go ก็ยิ่งได้รับความนิยมมากขึ้นหลังยุค AI ดังนั้นการวิจารณ์ AI จึงยากจะอธิบายว่าเป็นแค่ความกังวลเรื่องสถานะเท่านั้น
- อนาคตที่มีผู้ช่วยหุ่นยนต์ที่เชื่อถือได้มาช่วยจัดระเบียบโค้ดนั้นน่าคาดหวัง แต่ก็ดูเหมือนว่า ความกลัวการสูญเสีย กำลังถูกใช้เพื่อขาย agent ในแบบที่ทำให้บริษัทใหญ่ ๆ ขยับตัว
- เมื่อเทียบกับคนเก่งเดี่ยวหรือองค์กรเล็กแล้ว องค์กรขนาดใหญ่ มีโอกาสได้รับผลเสียจาก agent มากกว่า
- คนที่มีผลงานสูงสามารถแก้ข้อผิดพลาดได้ มักดูออกเมื่อผลลัพธ์นั้นหละหลวม และยังคงอ่านและทำความเข้าใจแต่ละบรรทัดอย่างระมัดระวัง เว้นแต่จะเป็นขอบเขตที่จำกัดมาก
- องค์กรขนาดใหญ่มีวงจรป้อนกลับที่ช้าและการจัดแนวที่อ่อนกว่า ดังนั้นเมื่อคนผลงานต่ำใช้ agent เพื่อสร้างผลผลิตเพิ่ม 10 เท่าโดยไม่ตรวจทานตัวเอง คุณภาพเฉลี่ยของผลลัพธ์อาจลดลง
- agent จะสร้างโค้ด แอป และฟีเจอร์ได้มากกว่าเดิม แต่ยุคนี้อาจกลายเป็นยุคที่มี ผลลัพธ์หละหลวม กองพะเนิน มากกว่าจะมีผลงานคุณภาพสูงที่เป็นอัญมณี
- เรื่องที่ว่า Apple กำลังกดดันให้วิศวกรทุกคนใช้ AI ควรถูกมองผ่านคำถามที่เป็นรูปธรรม เช่น “ในอีก 2 ปีข้างหน้า macOS จะดีขึ้นหรือแย่ลง” มากกว่าความคาดหวังเชิงนามธรรม
- ผู้คนมักตั้งสมมติฐานโดยนัยว่าผู้สร้างผลงานได้ผ่านสภาวะจิตใจและกระบวนการแบบมนุษย์มา แต่กับผลลัพธ์จาก AI สมมติฐานนี้ไม่จริงอีกต่อไป
- องค์ประกอบอย่างไวยากรณ์และรูปประโยค ซึ่งในอดีตเคยใช้เป็นตัวชี้วัดคุณภาพทางอ้อม กลับมีประโยชน์น้อยลงเมื่อเจอกับผลลัพธ์จาก AI และความต่างจะปรากฏชัดเมื่อมีปฏิสัมพันธ์แบบมนุษย์หรือสร้างบางอย่างต่อยอดจากมัน
- สำหรับ LLM ผู้เขียนเริ่มใกล้เคียงกับจุดยืนฝั่ง LeCun/Marcus มากขึ้น และนำไปสู่ข้อสรุปว่าโมเดลแบบนี้ไม่สามารถเขียนโปรแกรมได้ และ กระบวนการ ต่างหากที่สำคัญ
- deep learning อาจยังเป็นคำตอบได้อยู่ แต่สำหรับ agent เขียนโปรแกรมจริง ๆ สิ่งที่ต้องการไม่ใช่ RLVR แบบคอมเมนต์ทิ้ง failing test แล้วบอกว่าทุก test ผ่าน แต่คือ world model
- แก่นสำคัญของยุคนี้อาจอยู่ที่ว่า ท่ามกลางกระแสตื่นตัวเกินจริงต่อ AI ใครจะสามารถยืนระยะได้โดยไม่ทำร้ายตัวเอง
1 ความคิดเห็น
ความเห็นจาก Hacker News
ปัญหาใหญ่ของวาทกรรมตอนนี้คือมันเป็น การมองแบบขาวดำ มากเกินไป ถ้าสงสัย LLM ก็จะถูกมองว่าเป็นลัดไดต์ แต่ถ้าเชื่อก็เป็นพวก “ai pilled”
ในกรณีส่วนใหญ่ LLM พาคุณไปได้ราว 80~95% และบางครั้งก็ทำได้น้อยกว่านั้นหรือดีกว่านั้น บางทีก็พาไปผิดทางแบบสิ้นเชิง
แต่ทุกคนกลับเถียงกันแค่ว่า LLM จะกลายเป็นวิศวกรซอฟต์แวร์ที่สมบูรณ์แบบได้เองลำพังในตู้เสื้อผ้าหรือไม่ แล้วใช้เรื่องนั้นไปปฏิเสธความเป็นไปได้มหาศาลในสถานการณ์อื่น ๆ ด้วย
ถ้าลองคิดดูว่าแค่อินเทอร์เน็ตอย่างเดียวก็ทำให้องค์กรส่วนใหญ่มีประสิทธิภาพมากขึ้นจากตอนนี้ได้แค่ไหน จะเห็นว่าบริษัทจริง ๆ จำนวนมากยังทำสิ่งที่เป็นไปได้ได้ไม่ถึงเสี้ยวเดียว LLM ก็ถูกมองได้ในมุมเดียวกัน
ความผิดไม่ได้อยู่ที่โมเดลภาษา แต่อยู่ที่ตัวเราเอง
เดิมทีลัดไดต์คือคนที่ออกมาประท้วงเครื่องจักรที่ใช้ผลิตสินค้าคุณภาพต่ำแบบ “ฉ้อฉลและหลอกลวง” เลี่ยงมาตรฐานแรงงาน และแย่งอาชีพของช่างฝีมือผู้มีทักษะ
ฉันไม่ได้ใช้เอเจนต์ แต่สร้างซอฟต์แวร์เป็นรายฟังก์ชันผ่านแชตอินเทอร์เฟซธรรมดาและบทสนทนาต่อเนื่อง เวิร์กโฟลว์ที่ได้ค่อนข้างเป็นแบบ “ไคมีรา” และได้ประโยชน์อย่างมากจากประสบการณ์และความเชี่ยวชาญของฉัน LLM แค่ช่วยทำให้กระบวนการลื่นขึ้นเท่านั้น
สำหรับฉันมันใช้ได้ผลดี และไม่อยากกลับไปทำแบบเดิมแล้ว
คนที่ถูกเรียกว่า “ลัดไดต์” ในวาทกรรมปัจจุบัน ส่วนใหญ่แค่เป็นคนที่กล้าตั้งข้อสงสัยกับกระแสโหม “AI” เท่านั้น และโดยมากคนเหล่านี้ก็ไม่ใช่นักเคลื่อนไหวด้วย
สำหรับระดับความสามารถของ AI ตอนนี้ ผมพบว่าการมองมันว่าเป็น การค้นหา ที่ดีมากซึ่งทำงานอยู่บนองค์ความรู้เดิมนั้นมีประโยชน์ เหมือนขั้นถัดไปของความสามารถในการค้นหาที่ต่อเนื่องมาจากหนังสืออ้างอิง, Stack Overflow และ GitHub
โปรแกรมเมอร์เป็นอาชีพที่ต้องนำเทคนิคเดิมกลับมาใช้และคิดขึ้นใหม่ซ้ำบ่อยกว่างานไหน ๆ ที่ผมนึกออก จึงเข้ากับเครื่องมือที่ค้นหาองค์ความรู้เดิมได้ดีมากอยู่แล้ว และการที่ AI สามารถปรับองค์ความรู้นั้นให้เข้ากับกรณีใช้งานเฉพาะได้ก็ยิ่งทำให้มันทรงพลังขึ้น
แต่ก็เหมือนกับที่การเอาโค้ดจาก Stack Overflow มาปะติดปะต่อกันไม่ได้ทำให้โปรเจ็กต์ประสบความสำเร็จมากนัก AI ในตอนนี้ก็ยังสร้างทั้งโปรเจ็กต์ให้ดีจริง ๆ ไม่ได้
ถ้าเป็นโค้ดเบสเลกาซีเก่า ๆ ที่ไม่ค่อยถูกใช้งานนัก ก็อาจให้ AI agent อ่านโค้ดเพื่อถามอะไรอย่าง “แอปพลิเคชัน X ทำ Y อย่างไร” ได้ แต่ผมคงไม่ปล่อยให้มันสร้างฟีเจอร์แบบรัว ๆ หรือรับผิดชอบรีแฟกเตอร์
เพราะถ้าทำแบบนั้นคอมมิตจะเยอะเกินไปและทำให้ทีมพัฒนาสับสน มีโอกาสสูงที่จะได้ผลลัพธ์ที่เละยิ่งกว่ากองปัญหาที่เดิมก็รับมืออยู่แล้ว ช่วงนี้ผมค่อนข้างผิดหวังกับ AI และคำอธิบายนี้ก็สรุปประสบการณ์ของผมได้ดีมาก
งานที่ยากที่สุดในวิศวกรรมซอฟต์แวร์คือการแก้ ปัญหาที่ถูกต้อง ผมคิดว่าความสามารถในการระบุว่าควรแก้ปัญหาอะไรนี่แหละที่ทำให้วิศวกรอาวุโสระดับบนแตกต่างออกไป
ถ้าจะพูดให้เรียบง่าย ที่นี่ก็คือปัญหาที่เมื่อแก้แล้วจะเพิ่มคุณค่าให้ผลิตภัณฑ์ได้มากที่สุดเมื่อเทียบกับความซับซ้อนและต้นทุนแฝงที่ตามมา
นานมาแล้วผมเคยทำงานกับเว็บโปรดักต์ตัวหนึ่ง เดิมทีนักออกแบบจูเนียร์คิดว่าคงดีถ้าสามารถจัดการแบ็กเอนด์ของมันด้วยเครื่องมือ LDAP ได้ เลยทำให้สคีมาฐานข้อมูลและโครงสร้างของโปรดักต์เลียนแบบ OpenLDAP และใช้คีย์ CN แบบผสม ทั้งโค้ดเบสจึงต้องจัดการกับโครงสร้างนี้ทุกครั้งที่อ่านหรือเขียน DB ตอนออกแบบสคีมาฐานข้อมูล ความเข้ากันได้กับ LDAP ไม่ใช่ปัญหาที่ถูกต้องที่ควรแก้
ซอฟต์แวร์ที่แก้ปัญหาถูกต้องอาจระบุได้ยาก เพราะโดยมากวิธีทำงานของมันดูเป็นเรื่องธรรมดาเสียจนแทบไม่เห็นว่าจริง ๆ แล้วเราอาจเลือกการออกแบบแบบอื่นได้
เมื่อเวลาผ่านไป สิ่งที่มักช่วยจำกัดรัศมีการระเบิดของการออกแบบที่แก้ปัญหาผิด ก็คือแรงเสียดทานที่การออกแบบนั้นสร้างขึ้น การพัฒนาจะช้าลง และการพัฒนาที่ไปแก้ปัญหาผิดเพิ่มก็จะช้าลงด้วย เป็นกลไกจำกัดตัวเอง
นี่แหละคือสิ่งที่ผมกังวลอย่างมากกับ LLM coding agent มันไปกลบแรงเสียดทานนั้น ไม่ได้แก้ไขมัน แต่แค่เลื่อนต้นทุนออกไปข้างหน้า
ผลคือจะได้โค้ดเบสที่ความซับซ้อนโตได้แบบไร้ขีดจำกัดเมื่อเทียบกับคุณค่าที่มันส่งมอบ และไม่มีอะไรคอยควบคุม
พวกจูเนียร์ก็จะไม่ได้ผ่านวงจรป้อนกลับที่ช่วยสร้างสัญชาตญาณและรสนิยมทางวิศวกรรม ว่าปัญหาไหนกันแน่ที่ควรแก้ภายใต้การออกแบบแบบหนึ่ง ๆ
ในระดับทั้งวงการ เราอาจถึงขั้นลืมไปเลยว่าครั้งหนึ่งเคยมีแนวคิดเรื่องการแก้ปัญหาที่ถูกต้องอยู่
ไม่รู้เหมือนกันว่าควรทำอย่างไร หรือผมควรวางแผนเกษียณก่อนกำหนดเสียเลย
ตอนนี้มีคนซื้อ เปปไทด์จากตลาดสีเทา แล้วฉีดสารที่ติดป้ายว่า “ไม่ใช่สำหรับการบริโภคของมนุษย์” เข้าร่างกาย โดยเชื่อแค่เกร็ดเล่าต่อ ๆ กันกับความรู้สึกล้วน ๆ เพื่อให้ผิวใสขึ้นและเพิ่มมวลกล้ามเนื้อ
พวกเขากลายเป็นซอมบี้กันหมดแบบฉับพลันหรือเปล่า? ก็ไม่ใช่ แล้วพวกเขารู้จริงไหมว่าอีกไม่กี่ปีร่างกายจะเป็นอย่างไร? ก็ไม่รู้อีกนั่นแหละ มันอาจจบแบบหายนะได้ไหม? ก็อาจได้
เวลานึกถึงช่วงราว 6 เดือนหลังมานี้ที่ทั้งวงการหันไปใช้ AI อย่างหนักหน่วงให้เป็นตัวสร้างโค้ดหลัก อุปมานี้ก็ผุดขึ้นมา AI คือเปปไทด์ และ codebase คือร่างกาย แทบไม่มีใครรู้ตามตัวอักษรเลยว่าวิธีนี้จะดูแลรักษาได้แค่ไหน เพราะเวลายังผ่านไปไม่มากพอที่จะรู้
มันอาจโอเคก็ได้ หรืออาจกลายเป็นความเละเทะเต็มรูปแบบก็ได้ ทั้งทีมวิศวกรรมอาจปล่อยมือจากพวงมาลัยแล้วหลับไป คิดไปเองว่าตัวเองเข้าใจสิ่งที่กำลังสร้างทั้งที่จริงไม่เข้าใจเลย แล้วพอถึงจุดที่ LLM รับไม่ไหวอีกต่อไป ก็อาจไม่เหลือกำลังจะซ่อมหรือดูแลรักษาแล้วด้วยซ้ำ
https://www.bbc.co.uk/news/articles/cdr268m5pxro
สำหรับ codebase ส่วนตัวของฉัน ถ้าไม่ใช่กรณีที่ไม่ได้สนใจเรื่องการดูแลรักษาหรืออายุการใช้งานจริง ๆ ฉันก็เลิกทำแบบนั้นแล้ว
ตอนนี้ฉันอยู่ฝั่ง “ไม่ได้เขียนโค้ดเองมาสักพักแล้ว” อยากเห็นตัวอย่างที่ปัญหาหนักพอจะทำให้กลับไปเขียนโค้ดด้วยมือ
ปัญหาหลักของฉันคือคุณภาพมันแกว่งไปมาตามแต่ละ model release และโดยเฉพาะในเครื่องมือบรรทัดคำสั่ง มันชอบยัด API หรือเอกสารเก่า ๆ เข้ามา
ฉันพอเข้าใจว่าทำไมโมเดลถึงลำบากกับ monorepo ล้านบรรทัดที่มีขยะสะสมมา 10 ปี แต่กับ codebase ใหม่ ฉันยังนึกไม่ค่อยออกว่าทำไมมันต้องทรมานขนาดนั้น
การเขียนโค้ดไม่ได้ยากขนาดนั้น จนบ่อยครั้งแค่ลงมือเขียนโค้ดเองยังง่ายกว่าการอ่านเขียนภาษาอังกฤษเสียอีก แต่ฉันใช้แต่ Haskell เลยอาจมีอคติอยู่บ้าง
ความเสี่ยงอย่างหนึ่งของการบริหารงานวิศวกรรมคือ มันอาจทำให้คุณกลายเป็นคนที่ทำงานนั้นเองไม่ได้อีกต่อไป
แต่มันสำคัญจริงไหม?
ถึงอย่างนั้นฉันก็ยังมองโลกในแง่ดีกว่าคนเขียนอยู่นิดหน่อย รู้สึกว่ายังพอจัดการกระบวนการเพื่อไม่ให้เรื่องนั้นเกิดขึ้นได้
สภาพแวดล้อมการรันแบบ agent เพิ่งมีมาแค่ปีกว่า ๆ และเพิ่งเชื่อถือได้พอสมควรจริง ๆ แค่ราวครึ่งปี แต่ความเหนื่อยล้าก็มาแรงแล้ว ฉันว่ามันสะท้อน ความ耗พลังทางจิตใจของการเขียนโปรแกรมแบบมี AI ช่วย ได้ดีกว่าคำถามว่า LLM เขียนโปรแกรมได้จริงไหม
ถ้าจะตามให้ทันว่า agent กำลังทำอะไรกับ codebase คุณต้องตัดสินใจถี่ขึ้นมาก และต้องอ่านโค้ดกับข้อความอธิบายมหาศาลระดับดาราศาสตร์
ความเหนื่อยล้าส่วนบุคคลและทางจิตใจ รวมถึงอารมณ์ด้านลบนี้ กำลังถูกโยงอย่างคลาดเคลื่อนไปเป็นมุมมองเชิงลบต่อศักยภาพการพัฒนาของเทคโนโลยีเอง
ถ้าคนที่ใช้มันอย่างถูกต้องต่างก็หงุดหงิดหมด ส่วนคนที่ชอบมันกลับกองสุมของผสมมั่วที่บำรุงรักษาไม่ได้เป็นภูเขา เราก็คงโยนมันลงถังขยะของประวัติศาสตร์ในไม่ช้า
มีหลายอย่างที่ “มีศักยภาพ” แต่สุดท้ายก็ไม่กลายเป็นอะไรเลย
ฉันคงยังใช้ LLM ต่อไป แต่ในความเห็นฉัน ประโยชน์ใช้สอยของ การเขียนโค้ดแบบ agentic ได้ผ่านจุดสูงสุดไปแล้ว
ส่วนหนึ่งของงานของฉันคือหาวิธีทำให้โมเดลพวกนี้มีประสิทธิผลในองค์กรใหญ่ที่ฉันทำงานอยู่ มันใกล้เคียงกับการปามะเขือเทศใส่กำแพง และในระดับหนึ่งก็เห็นปัญหาเหมือนที่เขาพูด คือดูเหมือนเอาต์พุตจะมีข้อจำกัดบางอย่างโดยเฉพาะ
แต่ขณะเดียวกัน ในบทความของเขาก็ไม่มีทั้ง ชิ้นส่วนโค้ด หรือสิ่งที่จับต้องได้ใด ๆ ให้ยึดว่า “โมเดลทำพังตรงนี้ และจริง ๆ ควรทำแบบนี้” วิธีวิจารณ์แบบนี้ดูเหมือนเป็นแพตเทิร์นที่วนซ้ำในโพสต์แนว “LLM ใช้ไม่ได้เลย” ตามบล็อกและ Twitter
โมเดลเหล่านี้เก่งกว่าการทำ autocomplete อย่างชัดเจน และแม้แต่ในงานพัฒนาประจำวันของฉันเอง มันก็สร้างส่วนใหญ่ของ codebase ที่ดูเหมือนงานของวิศวกรระดับจูเนียร์หรือมิดเลเวลได้
ถ้าไม่มีใครยกตัวอย่างอย่างเป็นรูปธรรมเลยว่ามันพลาดตรงไหนบ้าง แล้วเราจะประเมินความสามารถที่แท้จริงของมันได้อย่างไร?
มันแทบจะสร้างโค้ดที่รันได้เสมอ และโดยมากก็ทำสิ่งที่ขอจริง ๆ แต่จะผิดไปนิด ๆ ในแบบที่น่าหงุดหงิดมากจนอยากปาเก้าอี้ แถมมันยังไม่มีรสนิยมพอจะสังเกตได้ด้วยซ้ำว่าอะไรผิดและผิดอย่างไร
แบบนี้จะยกตัวอย่างเฉพาะก็ไม่ได้ จะไม่ยกตัวอย่างเฉพาะก็ไม่ได้ งั้นเกมก็คือจบแล้ว
ฉันรู้ว่ากำลังก่อความผิดพลาดแบบเหมารวมจากกลุ่มอยู่ แต่ถึงอย่างนั้นก็ยังอยากพูดแบบนี้
น่าจะมีข้อมูลแบบนั้นอยู่แน่ ๆ ถ้าใครมีคอนเทนต์ที่ยกตัวอย่างดี ๆ ก็อยากให้ช่วยชี้เป้า
ฉันไม่สงสัยเลยว่า coder ระดับบนไม่กี่เปอร์เซ็นต์เขียนได้ดีกว่า Claude หรือ Codex มาก แต่ก็สงสัยว่ามันด้อยกว่านักพัฒนาธรรมดา ๆ ระดับเฉลี่ยอยู่แค่ไหน
ฉันเดาว่าโมเดลจะยังดีขึ้นเรื่อย ๆ
ตอนเริ่มทำ agentic coding เมื่อ 1~2 ปีก่อน ฉันเคยมั่นใจว่ามันมีประโยชน์แค่ระดับ autocomplete เท่านั้น แต่เมื่อต้นปีนี้มีบางอย่างเกิดขึ้น และโมเดลก็ไปถึง ระดับความสามารถใหม่
ตอนนี้คนที่ฉันรู้จักทำ agentic coding กันหมดแล้ว และมันน่าทึ่งจริง ๆ ฉันคิดว่าควรดันมันไปให้สุดเท่าที่ทำได้ รู้สึกเหมือนการเร่งความเร็วของมนุษยชาติมาอยู่ตรงหน้าแล้ว
ตลอด 2 ปีที่ผ่านมา มีการประกาศศูนย์ข้อมูลใหม่รวมราว 6GW แต่ที่เปิดใช้งานจริงและเริ่มให้บริการมีไม่ถึง 1GW กำหนดส่งมอบของที่เหลือก็เลื่อนออกไปเรื่อย ๆ
แถมศูนย์ข้อมูลยังพูดเหมือนว่าชิปข้างในจะใช้อยู่ได้ถึง 6 ปี ทั้งที่ก็เริ่มเห็นแล้วว่านั่นก็ไม่น่าจะไหว
เลิกพูดอะไรอย่าง “การเร่งความเร็วของมนุษยชาติ” ได้แล้ว ไม่มีใครกำลังใช้ LLM เพื่อแก้มะเร็ง การเปลี่ยนแปลงสภาพภูมิอากาศ ความเหลื่อมล้ำ หรือปัญหาความจริงที่สำคัญอื่น ๆ
ถ้าเทคโนโลยีนี้ดีพอจะเพิ่มผลิตภาพให้คุณได้ ก็เพราะคุณไม่ได้กำลังทำงานใหม่ งานล้ำสมัย หรืองานเชิงนวัตกรรมอะไรอยู่ เหตุผลเดียวที่ LLM ทำงานของคุณได้ ก็เพราะโค้ดแบบนั้นถูกเขียนขึ้นตามตัวอักษรมาแล้วมากพอจนไปอยู่ในข้อมูลฝึก
ลองให้ LLM เขียน C++26, HDL หรือสแต็กเฉพาะทางมาก ๆ ดู แล้วจะได้กลับมามองความจริง
ไม่ใช่ว่า AFL หาช่องโหว่ได้มากกว่า LLM แต่เป็น AFL กับคนทำงานที่ชำนาญต่างหากที่หาช่องโหว่เจอ
AFL ทำให้เกิดบั๊กขึ้นมา และหลายตัวหรืออาจจะส่วนใหญ่ก็เอาไป exploit ไม่ได้ มนุษย์ และตอนนี้รวมถึงเอเจนต์ ต้องเป็นคนคัดกรองและประเมินมัน
ยิ่งไปกว่านั้น งานนั้นเกิดขึ้นกับคลังซอฟต์แวร์ที่ไม่ปลอดภัยด้านหน่วยความจำจากยุคก่อน AFL ช่วงรุ่งเรืองของ AFL คือเมื่อ 10 ปีก่อน และตอนนี้เป้าหมายทุกอย่างก็ยากขึ้นกว่าเดิมแล้ว
เพื่อเพิ่มบริบท ผู้เขียนคือ George “geohot” Hotz เขามีประวัติการทำ exploit มายาวนาน และสิ่งที่น่าจะเป็นที่รู้จักที่สุดก็คือการสร้าง comma.ai สำหรับรถยนต์ไร้คนขับแบบเกือบจะเหมือน vibe coding ด้วยงบจำกัด ตั้งแต่ก่อนที่ AI vibe coding จริง ๆ จะเกิดขึ้นนานมากแล้ว
https://en.wikipedia.org/wiki/George_Hotz