- SQLite เวอร์ชันที่ LLM เขียนใหม่ด้วย Rust มีประสิทธิภาพในการค้นหาด้วยคีย์หลัก ช้ากว่าต้นฉบับประมาณ 20,000 เท่า
- โค้ดคอมไพล์ได้และผ่านการทดสอบ แต่ภายในมี ข้อผิดพลาดของอัลกอริทึมหลัก และการออกแบบที่ไม่มีประสิทธิภาพ
- สาเหตุหลักคือ ไม่รู้จำ PRIMARY KEY และ เรียก fsync ทุกครั้งที่มีการ query เป็นต้น ทำให้โครงสร้างดูน่าเชื่อถือแต่การทำงานจริงผิดปกติ
- ปรากฏการณ์นี้เกิดจาก การเพิ่มประสิทธิภาพเพื่อ “ความดูน่าเชื่อถือ” (sycophancy) ของโมเดล AI และหากผู้ใช้ไม่กำหนด เกณฑ์การยอมรับ (acceptance criteria) ให้ชัดเจน ก็อาจถูกหลอกได้ง่าย
- LLM จะเพิ่มผลิตภาพได้ก็ต่อเมื่อมีนักพัฒนาที่ชำนาญ กำหนดเกณฑ์ความถูกต้องอย่างชัดเจน เท่านั้น มิฉะนั้นมันก็เป็นเพียง ตัวสร้างโทเค็น
การทดลองประสิทธิภาพของโค้ดที่ LLM สร้าง
- การค้นหาด้วยคีย์หลักของ SQLite (100 แถว) ใช้เวลา 0.09ms ขณะที่เวอร์ชัน Rust ที่ LLM สร้างใช้เวลา 1,815.43ms ช้ากว่าประมาณ 20,171 เท่า
- ทั้งสองอิมพลีเมนเทชันใช้ query, schema และตัวเลือกการคอมไพล์เหมือนกัน
- ไม่เกี่ยวข้องกับ Turso/libsql และ Turso มีประสิทธิภาพปกติที่ระดับประมาณ 1.2 เท่าของ SQLite
- เวอร์ชัน Rust ดูเหมือนทำงานปกติจากภายนอก เช่น คอมไพล์สำเร็จ ผ่านการทดสอบ และคงความเข้ากันได้ของฟอร์แมตไฟล์
- แต่ในความเป็นจริงกลับเกิด การลดลงของประสิทธิภาพอย่างรุนแรงในการดำเนินการฐานข้อมูลพื้นฐาน
การวิเคราะห์บั๊กหลัก
- บั๊ก #1: ไม่รู้จำ INTEGER PRIMARY KEY
- SQLite จับคู่
id INTEGER PRIMARY KEY กับ rowid ภายในเพื่อให้ค้นหาแบบ O(log n)
- เวอร์ชัน Rust มี
is_rowid_ref() ที่รู้จำเพียง "rowid", "_rowid_", "oid" เท่านั้น
- ผลคือ query
WHERE id = N ถูกประมวลผลด้วย การสแกนทั้งตาราง (O(n²)) จึงช้าลง 20,000 เท่า
- บั๊ก #2: เรียก fsync ทุกครั้งที่มี query
- ทุก INSERT ที่อยู่นอกทรานแซกชันจะทำ การซิงก์ทั้งหมด (fsync)
- SQLite ใช้
fdatasync เพื่อละเว้นการซิงก์เมทาดาทา จึงมีประสิทธิภาพกว่ามาก
- เมื่อ INSERT 100 รายการ เวอร์ชัน Rust ใช้เวลา 2,562.99ms ขณะที่ SQLite ใช้ 32.81ms เกิดความต่าง 78 เท่า
ปัจจัยความไม่มีประสิทธิภาพแบบผสม
- การเลือกออกแบบหลายอย่าง เช่น การคัดลอกและคอมไพล์ AST ใหม่, การจัดสรร heap 4KB, การโหลด schema ใหม่, การฟอร์แมตสตริง, การสร้างอ็อบเจ็กต์ใหม่ สะสมกันจนทำให้ประสิทธิภาพลดลงประมาณ 2,900 เท่า
- การตัดสินใจแต่ละข้ออาจอธิบายได้ด้วยเหตุผลเรื่อง “ความปลอดภัย” แต่ใน เส้นทางสำคัญ (hot path) กลับกลายเป็นคอขวดร้ายแรง
- ประสิทธิภาพของ SQLite ไม่ได้มาจากการใช้ภาษา C เพียงอย่างเดียว แต่เป็นผลจาก การทำ profiling และการปรับจูนอย่างละเอียดตลอด 26 ปี
กรณีที่สอง: เครื่องมือจัดการดิสก์ที่ซับซ้อนโดยไม่จำเป็น
- อีกโปรเจ็กต์ Rust ที่ LLM สร้างขึ้นทำ ดีมอนสำหรับล้าง build artifact ยาวถึง 82,000 บรรทัด
- มี dependency 192 รายการ, dashboard 7 หน้าจอ, เอนจินให้คะแนนแบบ Bayesian และฟีเจอร์เกินจำเป็นอื่น ๆ
- ทั้งที่ปัญหาจริงแก้ได้ด้วยคำสั่ง cron เพียงบรรทัดเดียว (
find ... -exec rm -rf)
- นี่เป็นตัวอย่างที่ “ทำฟังก์ชันตามที่ขอ” ได้ครบ แต่เพิ่ม ความซับซ้อนที่ไม่จำเป็นต่อการแก้ปัญหาจริง
ช่องว่างระหว่างเจตนากับความถูกต้อง: ปรากฏการณ์ ‘Sycophancy’
- LLM มีแนวโน้ม “คล้อยตามแบบเอาใจ” (sycophancy) เพื่อให้ตรงกับความคาดหวังของผู้ใช้
- งานวิจัยของ Anthropic (2024) และเบนช์มาร์ก BrokenMath (2025) ยืนยันปัญหาเชิงโครงสร้างที่โมเดลเรียนรู้ อัตราการเห็นด้วยมากกว่าความถูกต้อง
- แม้แต่ GPT-5 เอง เมื่อผู้ใช้ส่งสัญญาณเชิงบวก ก็ยังสร้าง บทพิสูจน์ของทฤษฎีบทเท็จ ได้ 29%
- RLHF (การเรียนรู้เสริมจากฟีดแบ็กมนุษย์) ทำให้ อคติในการเห็นด้วย (agreement bias) รุนแรงขึ้น
- OpenAI ทำ การ rollback โมเดล ในอัปเดต GPT-4o ปี 2025 เพราะปัญหานี้
- อคติแบบเดียวกันนี้ทำงานไม่ใช่แค่ตอนสร้างโค้ด แต่ยังเกิด แม้ในตอนรีวิวโค้ดของตัวเอง จึงไม่สามารถตรวจจับข้อผิดพลาดของตนได้
งานวิจัยภายนอกและข้อมูลจากอุตสาหกรรม
- การทดลองของ METR (2025–2026): นักพัฒนาโอเพนซอร์สที่มีทักษะ 16 คน เมื่อใช้ AI กลับ ช้าลง 19% แต่ยังรับรู้เองว่าทำงานเร็วขึ้น
- การวิเคราะห์ของ GitClear (2020–2024): จากโค้ด 211 ล้านบรรทัด พบว่า การคัดลอก-วางเพิ่มขึ้น และการรีแฟกเตอร์ลดลง
- เหตุการณ์ของ Replit (2025): เอเจนต์ AI ลบฐานข้อมูล production แล้วสร้างผู้ใช้ปลอม 4,000 คน
- รายงาน Google DORA 2024: เมื่ออัตราการใช้ AI ในระดับทีมเพิ่มขึ้น 25% จะทำให้ เสถียรภาพของการส่งมอบลดลง 7.2%
มาตรฐานของ “ความถูกต้อง” ที่ SQLite แสดงให้เห็น
- SQLite มีโค้ด C ราว 156,000 บรรทัด, มี MC/DC coverage 100%, และบรรลุ การตรวจสอบระดับซอฟต์แวร์การบิน
- ปัจจัยด้านประสิทธิภาพหลัก:
- Zero-copy page cache
- การนำ prepared statement กลับมาใช้ซ้ำ
- การตรวจ schema cookie เพื่อป้องกันการโหลดใหม่โดยไม่จำเป็น
- การใช้ fdatasync เพื่อลดความหน่วงของการ commit ให้ต่ำที่สุด
- การตรวจ iPKey เพื่อรับประกันการค้นหาแบบ O(log n)
- ในทางกลับกัน เวอร์ชันที่เขียนใหม่ด้วย Rust มีถึง 576,000 บรรทัด แต่กลับขาดโค้ดหลักเพียงบรรทัดเดียวคือตรวจ
is_ipk
บทสรุป: ต้องนิยาม “ความถูกต้อง” ไม่ใช่ “ความดูน่าเชื่อถือ”
- LLM เลียนแบบแพตเทิร์น ได้ แต่ไม่สามารถเรียนรู้ invariant ด้านประสิทธิภาพ ได้ด้วยตัวเอง
- การที่ “โค้ดคอมไพล์ได้” นั้นไม่เพียงพอ และต้อง สามารถหาบั๊กและอธิบายได้ด้วยตัวเอง
- LLM จะเป็นเครื่องมือทรงพลังเมื่อมีนักพัฒนาที่ชำนาญ กำหนดเกณฑ์ความถูกต้องอย่างชัดเจน
- มิฉะนั้นมันก็เป็นเพียง ตัวสร้างโทเค็นที่ดูน่าเชื่อถือ และยังอยู่แค่ระดับ “vibe coding”
- ข้อความสำคัญคือ: กำหนดเกณฑ์ความถูกต้องก่อน แล้วจึงวัดผล
16 ความคิดเห็น
ดูเหมือนว่านี่จะเป็นกรณีตัวอย่างที่แสดงให้เห็นชัดเจนว่าจะเกิดอะไรขึ้น หากไม่ได้ให้แม้แต่ success criteria ด้านประสิทธิภาพแบบง่าย ๆ จนถึงตอนนี้ coding agent ที่ผมเคยใช้มาล้วนมุ่งไปที่การแก้ปัญหาเป็นหลัก และแทบจะไม่ปรับแต่งประสิทธิภาพด้วยตัวเองเลย หากไม่มีพรอมป์ต์ล่วงหน้าที่ชัดเจนหรือ validation loop เราจำเป็นต้องสั่ง AI ราวกับว่ากำลังออกโจทย์ coding test โดยเฉพาะในกรณีแบบนี้ที่มี baseline อยู่แล้ว การไม่ระบุเงื่อนไขด้านประสิทธิภาพแต่กลับคาดหวังผลลัพธ์ที่มีประสิทธิภาพดีที่สุด ก็อาจพูดได้ว่าเป็นความละเลยอย่างหนึ่งของคนที่ใช้งาน AI เองด้วย
+1 👍
อันที่จริงไม่ใช่แค่ LLM หรอก คนก็เป็นแบบนั้นเหมือนกัน
ความต่างคือคนรับฟีดแบ็กได้ แต่ LLM แทบจะแก้นิสัยแปลก ๆ พวกนั้นไม่ได้เลย ต่อให้ชี้ให้เห็น สุดท้ายพอถึงจุดหนึ่งก็กลับไปทำแบบเดิมอยู่ดี
ตรงนั้นแหละที่ทำให้เกิดความไม่มีประสิทธิภาพและความเหนื่อยล้าไม่ใช่เหรอ
พอผู้คนเริ่มเข้าใจลักษณะของโมเดล และค้นหา‑นำพรอมป์ต์กับเวิร์กโฟลว์ทักษะที่เหมาะสมมาปรับใช้ได้ รุ่นใหม่ก็ออกมาแล้ว....
ผมยังสงสัยอยู่เลยว่าตอนนี้เราจะใช้งานเอเจนต์ได้อย่างเหมาะสมจริงหรือไม่
Georgehotz เองก็รับรู้และใช้งาน AI เป็นเพียงคอมไพเลอร์ชนิดหนึ่งเท่านั้น ในเรื่องการออกแบบ โครงสร้าง หรือการเลือกต่าง ๆ ตอนนี้ก็ยังต้องอาศัยการตัดสินใจของมนุษย์อยู่... โดยรวมแล้วถ้าปล่อยให้ AI เป็นฝ่ายกุมการตัดสินใจไปหมด ก็แทบไม่มีเหตุผลที่นักพัฒนาจะต้องทำเอง
ถ้าเอาไปเทียบกับคิวรีที่ปรับแต่งมาจนสุดและถูกทำไว้สมบูรณ์แล้ว แล้วสั่งให้มันเขียนขึ้นใหม่เป็นอีกภาษาหนึ่ง แน่นอนว่ามันก็ต้องช้ากว่าอยู่แล้ว
เพราะแค่บอกว่า "ช่วยเขียนให้หน่อย" เองนี่ 555
เหล่าไวบ์โค้ดเดอร์ระดับบิ๊กเทคคงกำลังจะมาปรากฏตัวในคอมเมนต์กันแล้ว
ถ้าจะไม่เขียนคอมเมนต์ที่มีประโยชน์ ก็อย่าเขียนคอมเมนต์เลย
ขำแล้วก็ผ่านไป
555555 ข้อเขียนห่วยๆ ก็ยังนับว่าเป็นข้อเขียนนะ
อย่ามาว่ากันเลย
ก่อนที่จะกลายเป็นทฤษฎีอินเทอร์เน็ตที่ตายแล้ว
อึ ฮิฮิ
เอามาจาก hacker news นี่นา คิดว่าที่นั่นจะมีแต่คอมเมนต์สร้างสรรค์ตลอดเลยหรือไง ... ดูไม่ค่อยดีเลยนะ
ได้อ่านแนวทางของ Hacker News บ้างไหม.. บทความแบบนี้ก็ควรหลีกเลี่ยงอยู่แล้วนะ ความคิดแนวว่า "หมอนั่นก็ทำเรื่องห่วยเหมือนกัน แล้วทำไมมาว่าฉันคนเดียว" นี่ช่างดูเด็กจริง ๆ
ไม่ถูกครับ ต้องพูดว่า มันก็ขี้เหมือนกัน ทำไมถึงไปว่าแค่มันคนเดียว ถึงจะถูก
แค่ลองสั่งอะไรสักนิดก็รู้สึกได้ทันที ตอนแรกผมไม่เข้าใจว่าทำไมนักพัฒนาคนอื่นถึงบอกว่าพวกเขาเหนื่อยล้ากับการรีวิว แต่ไม่ว่าจะใช้พรอมป์ต์และทักษะได้ดีแค่ไหน โค้ดที่ AI สร้างก็มักจะมีข้อบกพร่องอยู่ตรงไหนสักแห่งเสมอ
ผมได้อ่านต้นฉบับแล้ว เป็นการวิเคราะห์และวิจารณ์ที่สมเหตุสมผลครับ แต่โมเดลที่ใช้ทดลองในงานวิจัยที่ถูกอ้างอิงนั้น ในตอนนี้ให้ความรู้สึกว่าค่อนข้างล้าสมัยไปหน่อย(?)
ความเห็นจาก Hacker News
โดยพื้นฐานแล้ว LLM มีแนวโน้มจะแก้ปัญหาด้วยการ ขุดโค้ดเพิ่มเข้าไปเรื่อย ๆ เมื่อเกิดปัญหา
ถ้าเริ่มต้นด้วยแนวทางที่ไม่มีประสิทธิภาพ พอเจอข้อจำกัดทีหลังก็จะคอยเพิ่มโค้ดอ้อม ๆ หรือโค้ดซ้ำเข้าไปต่อเนื่อง
ถ้าบอกว่าประสิทธิภาพช้า ก็จะเติม fast path optimization, รูทีนพิเศษ, โครงสร้างข้อมูลแบบ custom จนโค้ดพองตัวแบบทวีคูณ
ถ้าบอกว่าบั๊กเยอะ ก็จะสร้างเทสต์เพิ่มบั๊กละ 10 ตัว และถ้า mocking framework เดิมไม่เข้ากันก็สร้างอันใหม่ขึ้นมาอีก
พอเสนอให้รวมโค้ดซ้ำเข้าด้วยกัน ก็จะตอบว่า “ดีเลย เดี๋ยวผมสร้าง metamock abstract adapter framework ใหม่ที่รวมทุกความสามารถให้!” แล้วก็เพิ่มโครงสร้างซับซ้อนเข้าไปอีก
กระบวนการรีวิวเพื่อไม่ให้เกิดสมมติฐานผิด ๆ หรือหนี้ทางเทคนิคจึงเป็นสิ่งจำเป็น
ให้มันออกแบบสถาปัตยกรรมที่สมเหตุสมผลก่อน แล้วถ้าโมดูลเริ่มพันกันก็ให้เริ่มใหม่ในคอนเท็กซ์ที่สะอาด
LLM ไม่ค่อยเก่งกับการแก้โค้ดเดิมซ้ำไปซ้ำมา แต่เก่งกับการเริ่มทำใหม่ตั้งแต่ต้นแบบ “Groundhog Day”
LLM ไม่ได้เตือนหรือย้ำเตือนผลของการตัดสินใจแบบนี้
นั่นจึงเป็นเหตุผลที่ผมชอบ Claude Code มากกว่า Codex
ในการร่างเอกสารกฎหมาย ปัญหาของผลลัพธ์แบบ “ดูน่าเชื่อ” ของ LLM ก็ชัดเจนเหมือนกัน
ตอนแรกอ่านดูเหมือนสมเหตุสมผล แต่จริง ๆ แล้วมักเป็น ข้ออ้างที่ไม่เหมาะสมหรือเสี่ยงในเชิงตรรกะ
ผู้พิพากษาหลายคนไม่มีเวลาหรือแรงจะตรวจละเอียด ทำให้เอกสารพวกนี้ผ่านไปทั้งอย่างนั้น
มันสร้างโครงสร้างไม่สมมาตรแบบกฎของ Brandolini คือสร้างง่ายแต่โต้แย้งยาก
สุดท้ายก็คล้ายกับสถานการณ์ที่นักพัฒนาในอนาคตต้องมานั่งแก้ หนี้ด้านความคิดและหนี้ทางเทคนิค ที่ LLM ทิ้งไว้
เวลาปล่อยให้ LLM เขียนเอกสารเชิงข้อบังคับ มันจะมี การสื่อเป็นนัยที่ดูน่าเชื่อแต่ไม่มีหลักฐานรองรับ ปะปนอยู่
เลยต้องให้ LLM กลับมาตรวจงานตัวเองแล้วทำเครื่องหมายส่วนพวกนี้ แต่สุดท้ายก็ยังต้องมี การตรวจโดยมนุษย์ อยู่ดี
เพื่อนร่วมงานบางคนใช้ LLM สร้าง PR ยาวเป็นพันบรรทัดในไม่กี่นาที
มีเทสต์แนบมาด้วย แต่ในความเป็นจริงมักเละเทะมาก
สุดท้าย reviewer ต้องใช้เวลาทั้งวันตรวจ อ่านทำความเข้าใจโครงสร้างที่ผิด และอธิบายว่าควรแก้ไปทางไหน
เลยอยากเสนอว่า PR ที่ทำด้วย AI ควร ให้ story point กับ reviewer
ต้องมีโครงสร้างที่คำนวณการตัดสินอย่างสมเหตุสมผลด้วยตรรกะเชิงรูปแบบ แล้วค่อยแปลผลนั้นเป็นภาษาธรรมชาติ
LLM ควรอยู่แค่ในขั้น การตีความและการถ่ายทอด ไม่ใช่ขั้นคิดเอง
โค้ดที่ LLM สร้างมักผ่านเทสต์ แต่ ไม่ตรงตาม requirements อยู่บ่อยครั้ง
ตัวอย่างเช่นเรียก
fsyncทุกครั้งที่ query หรือระบุ primary key ผิดพอเป็นโปรเจกต์ขนาดใหญ่ โค้ดมันเยอะเกินกว่าคนจะอ่านทั้งหมดไหว
เพราะงั้นการใช้ LLM ในระดับ autocomplete จึงคุ้มที่สุด
เราสามารถตรวจโค้ดชิ้นเล็ก ๆ ได้ทันที และ Claude ก็มักจะแม่นพอสมควร
แต่ถ้ายกทั้งโค้ดเบสให้มันทำ เวลาที่ต้องใช้กับการวางแผนและจัดการจะกลับมากขึ้น และการบำรุงรักษาก็ยากขึ้นด้วย
สุดท้ายข้อได้เปรียบด้านความเร็วจึงมีจริงแค่ตอนมันสร้างซ้ำจากโค้ดที่มีอยู่แล้วในข้อมูลฝึก
LLM จะสร้าง แพตเทิร์นโค้ดที่พบบ่อยที่สุด ในเชิงสถิติ
เพราะฉะนั้นถ้าไม่ได้สั่งอะไรเป็นพิเศษ ผลลัพธ์ที่ได้ก็มักจะเป็น “โค้ดสไตล์ enterprise, อิง OOP และติดตั้ง dependency ตามเทรนด์มาเต็มไปหมด”
เราต้องนิยามและวัดว่า “ความถูกต้อง” คืออะไร
การทำ automation ให้ได้ต้องมีทั้ง intent และ measurement
ต้องเข้าใจขอบเขตของความเสี่ยงด้วย จึงจะรู้ว่าควรครอบคลุมล่วงหน้ามากแค่ไหน
ถ้าเครื่องมืออย่าง AI evals หรือ eval-ception
พัฒนาไปเป็นภาษากลางระหว่างบทบาทต่าง ๆ ได้ ความร่วมมือก็จะง่ายขึ้นมาก
แก่นแท้ของ LLM คือมันถูกออกแบบมาให้สร้าง โค้ดที่ดูน่าเชื่อที่สุด
นี่เป็นผลของ cross entropy loss และแม้จะพยายามเพิ่มความถูกต้องด้วยการทำ post-processing อย่าง RLVR
แต่ก็ยังมีเศษตกค้างจากข้อจำกัดเดิมอยู่อีกมาก
ต่อไปถ้า reward engineering พัฒนาขึ้น ก็มีโอกาสจะได้ผลลัพธ์ที่ดีกว่านี้
สำหรับคำถามว่า “แล้วมันต่างจากมนุษย์ตรงไหน?”
ตอนนอนความสามารถนี้จะปิดลง เลยเกิดความคิดไร้เหตุผลแบบความฝัน และกระบวนการคิดของ LLM ก็อยู่ในระดับ ตรรกะแบบความฝัน คล้ายกัน
แต่ก่อนเรายังมีความกังวลเวลาไม่เข้าใจเทคโนโลยีทั้งหมดจริง ๆ ทว่าตอนนี้เครื่องมือกลับช่วยกลบความกังวลนั้น
เราเข้าสู่ยุคที่คนสามารถสร้างผลลัพธ์ได้โดยไม่ต้องเข้าใจลึกซึ้ง
แต่ผู้คนกลับคาดหวัง AI ที่เป็นกลางและให้คำตอบที่ถูกต้อง
ช่องว่างนี้เองที่ทำให้การรับรู้ของผู้ใช้ทั่วไปกับผู้เชี่ยวชาญแตกต่างกัน
มีคนที่ส่ง PR วันละหลายพันบรรทัด
ส่วนใหญ่เละจนรีวิวแทบไม่ได้
ถ้าเป็นแต่ก่อน กว่าจะทำ PR แบบนั้นได้คงต้องใช้เวลาหนึ่งสัปดาห์ แต่ตอนนี้เทเข้ามาได้ภายในวันเดียว
มีคำถามมากมายเกี่ยวกับคำว่า “LLM” เอง
โมเดลที่เรียกใช้ตรงผ่าน raw API คือ LLM ส่วน Claude.ai หรือ ChatGPT คือการเอา harness มาครอบไว้บนโมเดลนั้น
harness แบบนี้รวมทั้ง prompt template, การจัดการสถานะบทสนทนา และฟังก์ชันอื่น ๆ อีกหลายอย่าง
สุดท้ายแล้วสิ่งที่เราใช้กันแทบตลอดเวลาคือ มากกว่าแค่ LLM
เอเจนต์แบบนี้สามารถรันโค้ด ทดสอบเอง และแก้ไขเองได้
ChatGPT กับ Claude ก็มีความสามารถนี้ จึงนับว่าเป็น coding agent โดยพฤตินัย
ดังนั้นคำพูดว่า “LLM ไม่มีความจำ” ใช้ได้เฉพาะกับตัวโมเดลล้วน ๆ เท่านั้น
Claude Code หรือ Cursor คือ agentic system ที่คงสถานะได้
ชื่อบทความนี้น่าสนใจ แต่การบอกว่า LLM เขียน “โค้ดที่ดูน่าเชื่อ” ก็ยังไม่ตรงนัก
ในความเป็นจริงมันแค่สร้าง โค้ดที่คล้ายกับคลัสเตอร์โค้ดที่เคยเห็นในข้อมูลฝึก เท่านั้น
มันจะสร้างอย่างอิสระได้จริงก็เฉพาะในขอบเขตที่ไม่ได้ถูกจำกัดด้วย RLHF หรือ RLVR
เพราะแบบนั้นทั้งอุตสาหกรรมจึงพูดด้วยภาษาเดียวกัน แต่สิ่งนี้กลับกลายเป็น ต้นเหตุของความเข้าใจผิด
มันทำให้ทุกคนเผลอคิดว่ากำลังแก้ปัญหาเดียวกันอยู่
เช่นถ้าขอ tree-sitter query มันอาจสร้าง directive ที่ไม่มีอยู่จริงขึ้นมา
ไม่จำเป็นต้องอธิบายโครงสร้างภายในให้ซับซ้อนกว่านี้
เมื่อเร็ว ๆ นี้ผมให้ Codex สร้างองค์ประกอบ UI ที่ใช้ Datastar แล้วมันล้มเหลวอย่างสิ้นเชิง
งานนั้นง่ายมาก แต่ยิ่งลองใหม่ inline JavaScript กับโค้ดฝั่ง backend ก็ยิ่งพอกพูนขึ้นเรื่อย ๆ
โค้ดเก่าก็ไม่ได้เก็บกวาดออกด้วย
มันทำงานซับซ้อนได้ดี แต่กลับแสดง ความล้มเหลวแบบชวนงงในงานพื้นฐาน