ลูปที่กำลังจะมาถึง
(lucumr.pocoo.org)- ลูประดับฮาร์เนส ที่คิวงานและฮาร์เนสจัดการการวนซ้ำนอกตัว coding agent กำลังก้าวขึ้นมาเป็นแพตเทิร์นศูนย์กลางใหม่ของงาน agent engineering
- ยิ่งปล่อยให้โมเดลทำงานอัตโนมัติได้นานเท่าไร ก็ยิ่งเติม การป้องกันเฉพาะจุด และ fallback ได้ง่ายกว่า invariant ที่แข็งแรง ทำให้ความเข้าใจในการออกแบบและการควบคุมในโค้ดที่ต้องดูแลระยะยาวอาจสั่นคลอน
- ในทางกลับกัน ในงานอย่างการพอร์ตโค้ด การทดลองด้านประสิทธิภาพ การสแกนความปลอดภัย และงานวิจัย ซึ่งตรวจสอบผลลัพธ์หรือทิ้งผลลัพธ์ได้ง่าย การวนซ้ำเชิงกลไก ทำงานได้ดีอย่างชัดเจนแล้ว
- เมื่อทั้งผู้โจมตีและผู้รายงานใช้ลูป หมายความว่าผู้ดูแลก็ถูกกดดันให้ใช้เครื่องจักรกับการ triage การทำซ้ำปัญหา และการตอบสนองเช่นกัน โดยกรณีของ curl แสดงให้เห็นภาระที่รายงานซึ่งสร้างโดย AI ก่อขึ้น
- โจทย์ต่อจากนี้ไม่ใช่ว่าจะใช้ลูปหรือไม่ แต่คือจะรักษา การตัดสินใจของมนุษย์ กฎวิศวกรรม การกำกับดูแลอย่างรับผิดชอบ และสถาปัตยกรรมที่เข้าใจได้ไว้ภายในลูปอย่างไร
ลูปที่หมุนนอกตัว coding agent
- ภายใน coding agent เองมี agent loop อยู่แล้ว ซึ่งโมเดลจะเรียกใช้เครื่องมือ สะท้อนผลลัพธ์ อ่านและแก้ไขไฟล์ รันทดสอบ แล้วจึงตอบกลับ
- แพตเทิร์นที่โดดเด่นขึ้นมาใหม่คือลูปภายนอกนั้น หรือ ลูประดับฮาร์เนส
- งานถูกใส่เข้าไปในคิว
- เครื่องหยิบงานขึ้นมาลองทำ
- เมื่อหยุดแล้ว ฮาร์เนสจะตัดสินว่างานเสร็จจริงหรือไม่
- ถ้ายังไม่เสร็จ ก็อาจอัดข้อความเข้าไปในเซสชันเดิม เริ่มเซสชันใหม่ด้วยบริบทที่แก้ไขแล้ว หรือส่งต่องานไปยังเครื่องอื่น
- ลูปภายนอกนี้ทำให้งานยังคงมีชีวิตต่อไปได้แม้พ้นจุดที่โดยปกติโมเดลจะบอกว่า “เสร็จแล้ว”
- ตัวลูปเองไม่ใช่เรื่องใหม่ แต่ช่วงหลังเริ่มถูกพูดถึงบ่อยขึ้นทั้งในงาน agent engineering และบทสนทนาบน Twitter
- บน Pi ก็เริ่มเห็นโฟลว์ลักษณะนี้บางส่วนเช่นกัน และเพราะ Pi เป็นฮาร์เนส จึงอยู่ตรงศูนย์กลางของการทดลองแบบนี้
ความอึดอัดเมื่อใช้กับโค้ดที่ต้องดูแลระยะยาว
- กับโค้ดที่ใส่ใจอย่างลึกซึ้ง วิธีนี้ยังไม่ค่อยเข้าที่นัก
- แก่นของเรื่องคือ รสนิยมและการควบคุม
- เราอยากเข้าใจโค้ดที่ตัวเองนำขึ้นใช้งาน
- ในสถานการณ์กดดันหรือเวลาคุยกับคนอื่น เราควรอธิบายการทำงานของระบบได้โดยไม่ต้องให้เครื่องเป็นฝ่ายอธิบายก่อน
- ณ ตอนนี้ ความเข้าใจโค้ดยังคงสำคัญอยู่มาก
- โค้ดที่สร้างขึ้นแบบปล่อยมือ โดยเฉพาะโค้ดที่ออกมาจากลูป มักมีปัญหาซ้ำ ๆ
- ป้องกันตัวมากเกินไป
- ซับซ้อนเกินไป
- ติดอยู่กับการให้เหตุผลเฉพาะจุด
- หลีกเลี่ยง invariant ที่แข็งแรง
- แทนที่จะทำให้สถานะที่ผิดเป็นไปไม่ได้ กลับเติม fallback เข้าไป
- สร้างโค้ดซ้ำซ้อนและ abstraction ที่ไม่ดี แล้วใช้กลไกเพิ่มขึ้นเพื่อกลบการออกแบบที่ไม่ชัดเจน
- ชุดอย่าง Claude Code กับ Fable สามารถทำงานกับปัญหาเดียวต่อเนื่องเกิน 30 นาทีได้ ทำให้ human in the loop ลดลงกว่าก่อน
- คุณภาพโค้ดจากแนวทางฮาร์เนสแบบปล่อยมือในตอนนี้ให้ความรู้สึกว่าแย่กว่าช่วงฤดูใบไม้ร่วงปีที่แล้วเสียอีก และอย่างน้อยในมุมรสนิยมแบบนี้ก็แทบไม่เห็นการพัฒนา
ลูปขยายพฤติกรรมของโมเดลให้แรงขึ้น
- เมื่อโมเดลเห็นความล้มเหลวเฉพาะจุด ก็มักจะเติมการป้องกันเฉพาะจุดเข้าไป
- Andrej Karpathy เคยกล่าวไว้ว่าโมเดล “กลัว exception แบบรุนแรงมาก”
- ในระบบที่มี invariant สำคัญ โดยเฉพาะฟอร์แมตข้อมูลถาวรหรือโครงสร้างพื้นฐานหลัก วิธี “รองรับทุก malformed case” อาจไม่ใช่การแก้ไขที่ถูกต้อง
- ทางที่ดีกว่าคือทำให้ malformed case ถูกแสดงออกมาไม่ได้ หรือเขียนมันไม่ได้ตั้งแต่ต้น
- ต่อให้มีการบังคับทิศทางด้วยมือมากพอ LLM ก็ยังสร้างโค้ดแบบนี้ได้ไม่เป็นธรรมชาติ และอาจพยายามจัดการแม้แต่ข้อผิดพลาดที่ถูกทำให้เป็นไปไม่ได้แล้ว
- เมื่อนำนิสัยนี้ไปไว้หลังลูป ปัญหาจะถูก ขยาย
- แต่ละรอบจะเติมการป้องกันเล็ก ๆ เพิ่มอีกหนึ่งชั้น
- ระบบดูเหมือนแข็งแรงขึ้น แต่กลับเข้าใจยากขึ้นเรื่อย ๆ
- ยิ่งปล่อยมือมาก แนวโน้มนี้ก็ยิ่งแรงขึ้น
- หากให้เครื่องมือแบบนี้กับคนจูเนียร์โดยไม่มีแนวทางชัดเจน ก็อาจทำให้พวกเขาเรียนรู้แนวปฏิบัติที่ไม่ดีได้
- และถ้าถามเหตุผล พวกเขาก็อาจปกป้องการตัดสินใจของตัวเองได้อย่างฟังดูน่าเชื่อถือ
พื้นที่ที่ลูปเข้ากันได้ดี
- แพตเทิร์นแบบลูปทำงานได้ดีมากอยู่แล้วในบางพื้นที่
- การพอร์ตโค้ด เป็นตัวอย่างชัดเจน
- มีกรณีการพอร์ตอัตโนมัติขนาดใหญ่ เช่น การย้ายบางส่วนของ Bun จาก Zig ไปเป็น Rust
- และยังถูกใช้พอร์ต MiniJinja ไปยัง Go ได้สำเร็จด้วย
- มันยังเหมาะกับการสำรวจด้านประสิทธิภาพ
- เครื่องลองทำการทดลอง
- รัน benchmark
- ทิ้งผลล้มเหลว
- แล้วสำรวจต่อไป
- มันยังเข้ากับการสแกนความปลอดภัยและงานวิจัยแทบทุกชนิดอย่างเป็นธรรมชาติ
- สามารถให้มันสำรวจพื้นที่ปัญหาที่ซับซ้อนแล้วรายงานผลกลับมาได้
- ไม่จำเป็นต้อง commit โค้ดที่จะต้องคงอยู่ระยะยาวเสมอไป
- จุดร่วมของกรณีที่สำเร็จคือผลลัพธ์ไม่จำเป็นต้องถูกดูแลระยะยาว หรือเป็นการแปลงโค้ดเดิม หรือใกล้เคียงกับ proof of concept, ไอเดีย, การค้นพบ, หรือการแปลงเชิงกลไก
- สิ่งที่ฮาร์เนสต้องการไม่ใช่สัญญาณที่เป็นอัตวิสัยล้วนหรือเป็นไบนารีล้วน แต่เป็น สัญญาณ ที่มีประโยชน์พอจะผลักรอบถัดไปต่อได้
- กรณีสำเร็จหลายแบบใช้ LLM ตัวอื่นเป็น judge หรือ orchestrator
- การแปลเชิงกลไกอาจตรวจสอบด้วย test case แบบไบนารี หรือจะให้ LLM ตัดสินก็ได้
- Claude Code กำลังเก่งขึ้นเรื่อย ๆ ในการสร้างและรัน workflow การทดลองทั้งชุด
- แม้โค้ดที่สร้างจะเลอะเทอะ ปัญหานั้นก็ใกล้เคียงกับปัญหาของตัวโมเดลมากกว่าความสามารถในการตัดสินของฮาร์เนส
การเปลี่ยนไปสู่การมองซอฟต์แวร์เหมือนสิ่งมีชีวิตมากกว่าเครื่องจักร
- การเขียนโค้ดที่จะต้องอยู่ยาวด้วยวิธีลูปแบบเดียวกันนี้ยังไม่ค่อยสบายใจนัก
- อุดมคติเดิมใกล้เคียงกับการเข้าใจซอฟต์แวร์ในฐานะ เครื่องจักรที่กำหนดแน่นอน
- เมื่อแกะออกทีละชั้น เราควรเข้าใจได้ลึกขึ้น
- เครื่องที่ถูกสังเกตว่าไม่เป็นดีเทอร์มินิสติกไม่ได้ถือว่าเหมาะที่สุดนัก
- สถาปัตยกรรมควรเดินหน้าไปสู่ความเป็นดีเทอร์มินิสติกที่มากขึ้น
- และการทำให้นักวิศวกรใหม่สามารถสำรวจ codebase ที่ซับซ้อนได้ ก็ถือเป็นการออกแบบที่ดี
- ในระบบที่ออกแบบดี จะมีวิศวกรที่รู้ว่า invariant อยู่ตรงไหน ส่วนไหนเป็น load-bearing และการเปลี่ยนแบบใดปลอดภัย
- ซอฟต์แวร์ขนาดใหญ่ทุกวันนี้ก็ไม่ได้อยู่ครบในหัวคนอยู่แล้ว และระบบกระจายก็มีมุมที่ต้องวินิจฉัยเหมือนแพทย์ดูอาการ ตั้งสมมติฐาน แล้วสั่งตรวจเพิ่ม
- LLM ผลักแนวโน้มนี้ให้เร็วขึ้นอีก
- เมื่อเกิดปัญหาใน production เครื่องจะอ่าน log
- เสนอ root cause
- ส่ง patch ขึ้นมา
- แล้วเครื่องอีกตัวก็รีวิว และบางครั้งก็รวมเข้า main โดยไม่มีมนุษย์กำกับ
- วิธีนี้ทรงพลังและน่าดึงดูดมาก แต่คนอาจไม่เข้าใจระบบทั้งหมดแบบเดิมอีกต่อไป
- เราอาจจัดการ เฝ้าดู และทำให้มันเสถียรได้ แต่ไม่ได้แปลว่าเข้าใจมันจริง ๆ
- ไม่ใช่ว่าโค้ดทุกบรรทัดต้องมาจากมนุษย์ และในอดีตก็อาจมีการเขียนโค้ดที่แย่กว่านี้ด้วยซ้ำ
แรงกดดันที่ถอนตัวออกได้ยาก
- ในอนาคตที่เครื่องเป็นตัวขับเคลื่อนอย่างเต็มที่ การ opt out อาจทำได้ยาก
- ด้านความปลอดภัยเป็นตัวอย่างที่ชัดที่สุด
- ต่อให้เราไม่ได้ใช้ลูปสร้างซอฟต์แวร์ของตัวเอง คนอื่นก็อาจเอาลูปมาหมุนใส่ซอฟต์แวร์นั้น
- ผู้โจมตีจะเดินเครื่องต่อเนื่อง
- ต่อให้ไม่ใช่ผู้โจมตี นักวิจัยด้านความปลอดภัยก็ทำงานอัตโนมัติได้เช่นกัน
- ผลที่ตามมาคือทั้งปัญหาจริงและสัญญาณรบกวนจะไหลเข้ามาพร้อมกัน
- summer of bliss ของ Daniel Stenberg ที่เกี่ยวกับ curl แสดงให้เห็นแรงกดดันที่ผู้ดูแลต้องเจออยู่แล้ว
- ดูเหมือนว่า AI จะยังไม่ได้มีบทบาทใหญ่ในงานพัฒนาหลักของ curl
- แต่ถึงอย่างนั้น ผู้ดูแลก็ยังถูกถาโถมด้วยรายงานจำนวนมาก ซึ่งส่วนใหญ่เป็นรายงานที่สร้างโดย AI
- เมื่อทั้งผู้โจมตีและผู้รายงานหมุนลูป ฝ่ายป้องกันก็ต้องไล่ตาม
- ไม่จำเป็นต้องเป็นเพื่อเขียน patch เองโดยตรงเสมอไป
- แต่อาจต้องใช้เครื่องเพราะแรงกดดันจากการ triage การทำซ้ำปัญหา และการตอบสนอง
- แรงกดดันด้านการแข่งขันก็คล้ายกัน
- บางทีมอาจสร้างสิ่งต่าง ๆ ได้มากกว่าอีกทีมเพียงเพราะความเร็วล้วน ๆ
- หากกลุ่มเล็ก ๆ ประสานเครื่องได้ดี โครงการก็อาจเร็วขึ้นอย่างฉับพลัน
- สตาร์ตอัปบางแห่งอาจทำงานที่เมื่อก่อนต้องใช้ 50 คนได้ด้วยคนเพียง 5 คน
- และใครบางคนก็อาจหมุนลูปใส่ผลิตภัณฑ์ของเราแล้วสั่งให้ “ทำให้เป็นอีกแบบหนึ่ง” ได้
- ไม่ใช่ซอฟต์แวร์ทุกประเภทจะได้รับผลกระทบเท่ากัน
- บางพื้นที่ลงโทษความหยาบและต้องการความน่าเชื่อถือกับความรับผิดชอบ
- แต่ซอฟต์แวร์จำนวนมากให้ความสำคัญกับความเร็ว การทดลองอย่างรวดเร็ว และการครอบคลุมที่กว้างมาก
การพึ่งพาแบบใหม่ที่ลูปสร้างขึ้น
- เครื่องมือที่ลูปสร้างขึ้นอาจไม่ใช่แค่ต้นทุนครั้งเดียว แต่สร้าง การพึ่งพาทางการรับรู้ อย่างต่อเนื่อง
- การพัฒนาซอฟต์แวร์ในอดีตพึ่งพาเครื่องมือที่มีต้นทุนอย่างคอมไพเลอร์ แต่เครื่องมือทุกวันนี้ใกล้เคียงกับระบบที่ต้องเข้าถึงอยู่ตลอดเวลา
- หาก codebase ถูกสร้างด้วยลูป ถูกรีวิวด้วยลูป ถูกแพตช์ด้วยลูป และถูกดูแลด้วยลูป ก็จะเกิดปัญหาเมื่อการเข้าถึงระบบระดับเดียวกันนั้นสะดุดลง
- การจำกัดทางการค้าอาจทำให้เข้าถึงโมเดลที่ทรงพลังที่สุดไม่ได้อีก
- ค่าใช้จ่ายอาจสูงจนรับไม่ไหว
- ทีมอาจสูญเสียความสามารถสุดท้ายในการเข้าใจโค้ดโดยไม่มีเครื่องช่วย
- อาจเกิด codebase ที่ไม่ใช่แค่บำรุงรักษายากสำหรับมนุษย์ แต่ตั้งสมมติฐานไว้เลยว่าการมีส่วนร่วมของเครื่องเป็นส่วนหนึ่งของโมเดลการดูแลรักษา
- ตอนนี้เริ่มเห็นการเปลี่ยนแปลงบางอย่างแล้ว
- คนจำนวนมากขึ้น merge โค้ดที่อธิบายได้ไม่หมดจริง ๆ
- มีการเสริมหรือเขียนใหม่ issue report และการคุยในแชตด้วยบริบทที่เครื่องจัดให้
- พึ่งพาเครื่องในการสรุปและจัดบริบท
- และเห็นคนสื่อสารผ่าน LLM บ่อยขึ้น
- จะบอกว่าสิ่งนี้ผิดเสมอไปก็คงไม่ได้ แต่ก็เป็นการเปลี่ยนแปลงใหญ่จากวิธีเดิม
ฮาร์เนสและเครื่องมือที่ยังต้องมีต่อจากนี้
- แค่ประสานลูปให้มากขึ้นยังไม่พอ
- ต่อให้มองเห็นการเปลี่ยนแปลง การ orchestration และเอเจนต์ได้ดีขึ้น ก็ไม่ได้แปลว่าความเข้าใจจะกลับคืนมาเอง
- ทิศทางที่ต้องการน่าจะมีอยู่สองแบบ
- ดึงมนุษย์กลับเข้าไปในลูปอย่างจริงจังอีกครั้ง และหาวิธีทำให้การเปลี่ยนแปลงจากลูปยังอ่านเข้าใจได้ในระยะยาว
- หรือหาวิธีประกอบระบบที่ซับซ้อนขึ้นเรื่อย ๆ ให้ดีขึ้น
- มุมมองต่อ Pi เองก็กำลังเปลี่ยน
- Pi ระมัดระวัง และความระมัดระวังนั้นเป็นสิ่งที่ดี
- เราไม่ได้อยากได้อนาคตที่ทุกปฏิสัมพันธ์กลายเป็นการเปลี่ยนแปลงจากฝูงเครื่องที่ตามแทบไม่ทัน
- เราก็ไม่อยากให้ Pi กลายเป็นความโกลาหลที่บำรุงรักษาไม่ได้เพียงเพื่อเอาชนะการแข่งขันของซอฟต์แวร์ที่เขียนตัวเอง
- และไม่อยากให้ Pi สนับสนุนวิศวกรรมลักษณะนี้ด้วย
- ถึงอย่างนั้น Pi ก็เป็นฮาร์เนส และฮาร์เนสก็อยู่ตรงศูนย์กลางของการทดลองแบบใหม่
- คิวงานสำหรับ coding, agent orchestration, subagent และ durable session จะยิ่งสำคัญขึ้นเรื่อย ๆ
- แม้แต่คนที่ไม่ยอมรับลูปแบบไม่ลืมหูลืมตา ก็ควรเริ่มทดลอง
- เพราะต้องทำความเข้าใจว่าจะทำให้อนาคตนี้ ยังอยู่ในขอบเขตและรับมือได้ อย่างไร
ปัญหาของการควบคุมลูป
- เมื่อยอมรับลูประดับฮาร์เนสแล้ว ฮาร์เนสจะเป็นฝ่ายตัดสินว่างานจบเมื่อไร
- ใน agent loop โมเดลจะพูดว่า “done” ในที่สุด แล้วมนุษย์ค่อยรีวิว
- และก่อนหน้านั้นโดยทั่วไปมนุษย์ก็มักคอยบังคับทิศทางอยู่ระหว่างทาง
- มนุษย์มีส่วนร่วม และได้เรียนรู้ไปพร้อมกัน
- แต่ในลูปที่ฮาร์เนสดำเนินการ บทบาทของมนุษย์กลับพร่าเลือน
- แม้แต่สัญญาณ “done” ก็เริ่มไร้ความหมาย และกลายเป็นเพียงข้อความให้เครื่องอื่นเอาไปตัดสินต่อ
- บทบาทของมนุษย์อาจกลายเป็นแค่ผู้ส่งสารมากขึ้น
- ตอนนี้โค้ดจำนวนมากที่ถูกสร้างด้วยวิธีแบบนี้ยังไม่ใช่สิ่งที่ชอบ และการปฏิสัมพันธ์กับซอฟต์แวร์ที่สร้างด้วยความช่วยเหลือของ AI ก็ไม่ได้สนุกนัก
- ลูปนั้นทรงพลัง แต่ก็ค่อย ๆ ถอนความรับผิดชอบออกไป และอย่างน้อยในตอนนี้ยังมีด้านที่ผลักให้คนยอมจำนนต่อเครื่อง
- ถึงอย่างนั้น อนาคตของลูปก็ดูเหมือนกำลังมาถึง
- มีตัวอย่างอยู่แล้วของทีมเล็กมากที่สร้างสิ่งต่าง ๆ ด้วยความเร็วที่ดูเหมือนเป็นไปไม่ได้
- codebase กำลังเปลี่ยนไปเป็นสิ่งมีชีวิตที่กำกวมและสับสนมากขึ้น
- codebase แบบนั้นทั้งมีประโยชน์และเลอะเทอะไปพร้อมกัน
- คำถามต่อจากนี้จึงไม่ใช่ “จะหมุนลูปไหม” แต่ใกล้เคียงกับเรื่องต่อไปนี้มากกว่า
- จะไม่ละทิ้งการตัดสินใจภายในลูปได้อย่างไร
- จะรักษากฎวิศวกรรมที่ดีไว้ได้อย่างไร
- จะทำให้มนุษย์ที่มีความรับผิดชอบยังคงกำกับดูแลต่อไปได้อย่างไร
- จะต้องคิดสถาปัตยกรรมโค้ดใหม่อย่างไรเพื่อให้ยังมีสติอยู่ได้
1 ความคิดเห็น
ความเห็นจาก Hacker News
ลูปจะทำงานได้เมื่อเราใช้เวลามากพอในการทำความเข้าใจสิ่งที่ต้องการล่วงหน้าอย่างถี่ถ้วน เงื่อนไขตั้งต้นคือ ความชัดเจน และต้องอยู่ในระดับที่เขียนสเปกอย่างรอบคอบพอจะส่งต่อให้เพื่อนร่วมงานระดับจูเนียร์ได้
โดยปกติแล้วกว่าจะเข้าใจถึงจุดนั้นได้ก็มักต้องผ่านเวอร์ชันพัง ๆ หยาบ ๆ สัก 5~6 รอบก่อน การลองผิดลองถูก 5~6 รอบนี้เร่งไม่ได้ และเทคโนโลยีเอเจนต์แบบไหนก็ช่วยให้หลีกเลี่ยงเวลาที่สมองมนุษย์ต้องใช้คิดไม่ได้ ดังนั้นเวลาส่วนใหญ่จึงหมดไปกับการสลับไปมาระหว่าง “ฉันยังไม่รู้ว่าตัวเองต้องการอะไร ต้องอ่าน เขียน และลองแก้โค้ดดูก่อน” กับ “ตอนนี้น่าจะผ่านเวลามามากพอจนเริ่มรู้แล้วว่าต้องการอะไร” มันหลอกตัวเองได้ง่ายมาก แต่จะใช้ลูปได้ก็ต่อเมื่อรู้จริง ๆ แล้วว่าอยากได้อะไร หลายคนคิดว่าสามารถใช้เอเจนต์ลัดขั้นนี้ได้ แต่ ความเข้าใจและความชัดเจน เป็นสิ่งที่แกล้งทำแทนกันไม่ได้ และคนที่ข้ามขั้นนี้จะเห็นได้ชัดจนน่าเจ็บปวด
ผมไม่ต้องนั่งคิดอยู่นานว่าต้องการอะไร แค่อยากให้มันทำสิ่งนั้น ผลลัพธ์ยังปน ๆ กันอยู่ และยังไม่ไว้ใจพอจะให้ดูแลโค้ดเบสที่ละเอียดอ่อน แต่กับเกมที่กำลังทำอยู่ เวลาที่ใช้ไปกับการตรวจสอบลดลงเหลือ 1/5 ของเดิม ซึ่งก็ไม่ได้เป็นเรื่องดีเสมอไป มีโอกาสสูงว่าผมกำลังพลาดไอเดียดี ๆ เพราะใช้เวลาน้อยลง แต่ก่อนพรอมป์ต์มักกลายเป็น
#now-do-this,#now-review-thatแบบกลไก และค้างอยู่ที่ข้อเสนอถูกต้อง 90% ตอนนี้มันจะเตือนโดยอัตโนมัติว่า “ทำเรื่องยากก่อน แล้วค่อยจัดระเบียบ/รีแฟกเตอร์ระหว่างทาง” และหลังผลลัพธ์รอบแรกก็จะเตือนให้ “ย้อนกลับมาทบทวนงาน” เพื่อให้มันระบายปัญหาที่เหลือออกมา จากนั้นก็เอาสิ่งนั้นใส่ในพรอมป์ต์สร้างไกด์แล้วกระจายเป็นงานใหม่ได้เลยการวนซ้ำเร็วขึ้นก็จริง แต่แรงที่ต้องใช้เพื่อผ่านเวอร์ชันหยาบ ๆ เหล่านั้นแทบจะเท่าเดิม เพราะผมยังต้องเข้าใจว่าไอเดีย หลักการ หรือดีไซน์แบบไหนเหมาะกับคำตอบ และต้องลองอะไรต่อ รวมทั้งปรับ mental model ของตัวเองอยู่ดี สุดท้ายมันให้ความรู้สึกเหมือนใช้แรงทางความคิดมากขึ้นในเวลาที่สั้นลง และประหยัดได้เพียงนิดหน่อยในส่วนของการเขียนโค้ด ถ้าชำนาญแล้ว การพิมพ์โค้ดเองแต่แรกก็ไม่ใช่สัดส่วนใหญ่ของงานอยู่แล้ว ทั้งที่ดูเหมือนแค่เขียนพรอมป์ต์แล้วอ่านโค้ด แต่ก็เหนื่อยพอ ๆ กัน หรือบางทีก็เหนื่อยกว่าเพราะรอบการวนซ้ำถูกบีบให้สั้นลง
ตอนนี้เจอเรื่องแบบนี้ทุกวัน และทั้งท้อแท้ทั้งกังวล ผมคิดว่าสาเหตุที่เรากำลัง merge โค้ดที่อธิบายไม่ได้อย่างสมบูรณ์มากขึ้น เป็นเพราะ mental model ที่เมื่อก่อนสร้างขึ้นจากการเขียนโค้ดและการวางแผนทางเทคนิคแบบร่วมมือกัน ตอนนี้กลับไปพึ่งการรีวิวโค้ดแทน
การรีวิวโค้ดไม่เหมาะกับเป้าหมายนี้ แต่ผมคิดว่าน่าจะปรับสมดุลระหว่างแรงเสียดทานกับความเข้าใจให้ดีขึ้นได้ ถ้าเอาแบบฝึกหัดที่มีโครงสร้างจากศาสตร์การศึกษามาพ่วงกับการรีวิวโค้ด ตอนนี้กำลังหาคนช่วยทดสอบแบบฝึกเหล่านี้อยู่
UI ของ PR ใน GitHub ที่อ่อนมากก็ไม่ช่วยอะไรด้วย เครื่องมือสำหรับสำรวจบริเวณรอบ ๆ ของโค้ดเบสที่ไม่ได้เปลี่ยนโดยตรงแต่ได้รับผลกระทบ เพื่อหาปัญหาและเน้นให้เห็น ยังมีจำกัด
ประเด็นในต้นฉบับที่ว่าควรเลือกระบบที่ทำให้เงื่อนไขขอบเขตที่ผิดพลาด “เป็นไปไม่ได้” แทนการรับมือด้วยเส้นทางสำรอง เป็นเรื่องสำคัญมาก วิธีแบบเส้นทางสำรองทำให้ต้องไปสร้างเส้นทางสำรองบนเส้นทางสำรองอีกที และแต่ละเส้นทางก็เพิ่มปริมาณโค้ดแบบยกกำลัง พร้อมสร้างปัญหาใหม่อย่างน่าประหลาดใจอยู่เสมอ ถึงขั้นแทบเรียกได้ว่าเป็น “กฎทั่วไปของการออกแบบระบบ” เส้นทางสำรองช่วยลดความเสี่ยงที่จะล้มเหลว แต่ถ้าความล้มเหลวเกิดขึ้นจริง มันจะทำให้สถานการณ์ซับซ้อนและเป็นอันตรายยิ่งกว่าเดิม ในฐานะวิศวกรซอฟต์แวร์ ผมชอบสภาพแวดล้อมการเขียนโค้ดใหม่ที่ AI สร้างขึ้นนะ เพราะบิ๊กเทคได้สร้างงานไร้ขีดจำกัดให้ผม มนุษย์นักพัฒนากลายเป็นองค์ประกอบหลักของการรันโค้ด และต้องคอยเฝ้าไว้ตลอดเพื่อจัดการข้อยกเว้นยาก ๆ ที่แทบไม่มีที่สิ้นสุดซึ่งยังไม่ได้รับการจัดการและจะต้องเกิดขึ้นเป็นครั้งคราว ตอนนี้วิศวกรซอฟต์แวร์เลยคล้าย เจ้าหน้าที่รักษาความปลอดภัย มากกว่าคนใช้แรงงาน คือส่วนใหญ่ก็นั่งโต๊ะจิบกาแฟ แล้วค่อยเข้าแทรกแซงเมื่อมีปัญหาเกิดขึ้นนาน ๆ ที
นี่ต่อเนื่องจากที่ผมพูดมาหลายเดือนแล้ว LLM เก่งมากเรื่อง ทำงานให้เสร็จ แต่ไม่เก่งเรื่องสุนทรียะและรสนิยม
งานมีอยู่สองประเภท แบบแรกคืองานที่ขับเคลื่อนด้วยเป้าหมาย มีเป้าหมายให้บรรลุ และวิธีไปถึงเป้าหมายนั้นไม่สำคัญมากนัก ความปลอดภัยเป็นตัวอย่างที่ชัดเจน ถ้าจะ exploit ระบบ คุณแทบไม่สนว่า exploit จะสวยงามไหม แค่อยากเข้าถึงแผนนิวเคลียร์ลับสุดยอดก็พอ งานวิจัยก็คล้ายกัน เพราะโค้ด “ระดับงานวิจัย” มีชื่อเสียงว่าเละเทะมาตั้งแต่ก่อนยุค AI แล้ว อีกแบบหนึ่งคือ งานที่ขับเคลื่อนด้วยรสนิยม เวลาจะเพิ่มฟีเจอร์ในโค้ดเบสขนาดใหญ่ เราอาจคิดว่าเป้าหมายคือการเพิ่มฟีเจอร์นั้น แต่จริง ๆ แล้วมักไม่ใช่ สิ่งที่สำคัญกว่าฟีเจอร์เฉพาะนั้นมากคือการทำให้โค้ดเบสยังรองรับการเปลี่ยนแปลงในอนาคตได้ดี และสิ่งนี้ต้องอาศัยรสนิยม ความสามารถในการบำรุงรักษาและคุณภาพโค้ดไม่ใช่คำพ้องความหมายกัน โดยคุณภาพโค้ดเป็นเพียงวิธีการ ส่วนเป้าหมายจริงคือความสามารถในการบำรุงรักษา
ปัญหาที่ LLM พยายามจัดการแม้แต่กรณีที่ผิดโดยธรรมชาติก็เป็นสิ่งที่ถกเถียงกันมาใน PR review จำนวนมาก โดยเฉพาะเมื่อเขียนไปแล้ว จะอธิบายให้เชื่อได้ยากมากว่าการทำ null check มากเกินไปนั้นเป็นโทษ
ถ้าไม่มีการทำโมเดลลิงที่ดีกว่านี้ และไม่มีภาษาที่ยอมให้ใช้ union type ก็ยังไม่เจอข้อโต้แย้งที่ใช้ได้ทั่วไปกับ “shotgun parsing” แบบนี้ บางทีมันอาจไม่ใช่ปัญหาใหญ่จริง ๆ ก็ได้ แต่เวลาอ่านและรีแฟกเตอร์โค้ดเบสจริง ๆ การต้องคอยจัดการเช็กที่ไม่จำเป็นแบบนี้น่าหงุดหงิดเสมอ พอมันถูกใส่เข้าไปแล้ว บางครั้งก็แทบลบออกอย่างปลอดภัยไม่ได้เลย ถ้ายังไม่ได้เพิ่ม logging หรือทำการตรวจสอบในวงกว้างก่อน
นี่ก็คือแก่นของคำพูดที่ว่า ทำให้สถานะที่ไม่พึงประสงค์ “ไม่สามารถแสดงออกมาได้”
ถึงตอนนี้จะยังไม่มีอะไรส่งค่าติดลบเข้าไปในฟังก์ชันนี้ แต่ในอนาคตการเปลี่ยนโค้ดจะทำลายสมมติฐานนั้นได้ยากแค่ไหน? ฉันคิดมาตลอดว่าการแสดงข้อผิดพลาดให้ชัดเจนคือสิ่งที่ดีที่สุด คนที่ไม่คุ้นกับโค้ดก็จะรู้ได้ว่ามีสมมติฐานอะไรเกี่ยวกับช่วงค่าที่ใช้ได้ของอินพุต และไม่ต้องคอยพิจารณาค่าผิดปกติที่เป็นไปไม่ได้
คอขวดของฉันอยู่ที่ spec ส่วน agent loop ตอนนี้กลายเป็นปัญหาที่สำคัญน้อยลงแล้วสำหรับฉัน
ถ้าฉันตั้งเป้าให้ได้ความเข้าใจที่ชัดเจนเกี่ยวกับสิ่งที่อยากสร้าง แล้วส่งต่อเป็นเป้าหมายให้เขียนสเปกที่นำไปปฏิบัติได้ใน planning mode ของ Claude Code พอเอเจนต์เริ่มลงมือทำ implementation ก็มักได้ผลลัพธ์ที่ดีมากเป็นส่วนใหญ่ แต่กลยุทธ์ที่ได้ผลนี้ก็โยนภาระการเขียนสเปกกลับมาที่ฉันอย่างมาก เอเจนต์จัดการแต่ละสเปกได้ดีเยี่ยมเป็นส่วนใหญ่ และงานต่อเนื่องจาก code review ก็มักใช้แค่ 2–3 รอบ แต่ไม่นานก็จะกลับมาถึงจุดที่ต้องมีสเปกอีก ถึงเอเจนต์จะทำงานที่ฉันปล่อยไว้ตอนไม่อยู่เสร็จแล้ว และสามารถเริ่มสเปกเดิมที่ไม่มีความขัดแย้งเพราะไฟล์ไม่ทับกันได้ มันก็ไม่รู้ว่าตัวเองสร้าง branch ใหม่แล้วเริ่มต่อได้ ก่อนนอนฉันมักบอกว่า “ทำงาน X ให้เสร็จและ push แล้วค่อยเริ่มงาน Y” แต่เกินกว่านั้นมักไปได้ไม่ดี บ่อยครั้งพอมันเริ่ม Y ก็เกิดคำถามขึ้น แล้วเอเจนต์ก็หยุดค้างไปตลอดเวลาที่เหลือ ปัญหาสุดท้ายคือเรื่อง dependency ที่ประกอบกับทั้งหมดนี้ ตัวอย่างเช่น วันนี้ฉันเขียน background job worker และแน่นอนว่า jobs ของงานถัด ๆ ไปก็ต้องใช้ระบบนั้น เรื่องแบบนี้เกิดขึ้นค่อนข้างบ่อย และเพื่อสะท้อนรายละเอียดที่ตัดสินใจระหว่าง implementation ตัวสเปกเองก็ต้องอัปเดตหลัง implement เสร็จเช่นกัน ถึงอย่างนั้นตอนนี้ก็ใกล้ถึงจุดที่ต้องมี outer loop แล้ว จุดคอขวดแทบทั้งหมดอยู่ที่การเขียนสเปกและ PR review ในจุดที่คอขวดนั้นไม่สำคัญ ฉันอยากให้เอเจนต์เดินหน้าต่อไปเรื่อย ๆ อีกอย่าง ฉันเชื่ออย่างมากว่าเราควรเริ่มใช้เครื่องมือที่ถึงจะไม่ดีสำหรับเรา แต่ดีกว่าสำหรับ LLM เช่น Rust ที่ compiler เข้มงวดเกินไปจนทำให้ฉันรำคาญ แต่กลับยอดเยี่ยมสำหรับ LLM
ตอนนี้การสร้างถูกทำให้เป็นอัตโนมัติมากขึ้นแล้ว spec กับ system design จึงอาจกลับมามีบทบาทนำที่สำคัญอีกครั้ง วิศวกรรมและคุณภาพอาจกำลังจะกลับมา
AI เก่งมากในการสร้างวิธีแก้ที่ใช้ได้จริงในเชิงเทคนิคและพอใช้ได้ แต่ค่อนข้างอ่อนในการมีวิสัยทัศน์ที่ดีต่อวิธีแก้ มันยังมีประโยชน์มากในการช่วยถกไอเดียและสำรวจเพื่อเพิ่มความเข้าใจ แต่การเขียนสเปกที่ดีให้ LLM เอาไป implement ต่อ ก็ไม่ได้ง่ายกว่าการเขียนโค้ดเองมากนัก
https://www.aihero.dev/skills-handoff
/handoffคือสกิลใหม่ที่ฉันชอบที่สุดตอนนี้https://www.youtube.com/watch?v=dtAJ2dOd3ko
จะมีเอเจนต์หรือไม่มี จะเป็นบัตรเจาะรูหรือ interpreter สุดท้ายการเขียนโปรแกรมก็คือการเขียนโปรแกรม
กลิ่นโค้ดที่ใหญ่ที่สุดของ LLM คือมันพยายาม “จัดการทุกกรณีที่ผิดพลาด” และตอนนี้ถึงขั้นพยายามจัดการข้อผิดพลาดที่เป็นไปไม่ได้ด้วย ไม่รู้เหมือนกันว่าทำไมถึงหมกมุ่นกับเรื่องนี้นัก
ใน Python มักเห็นบ่อยในรูปแบบอย่างการใส่เช็ก
hasattrให้กับชนิดข้อมูลที่นิยามไว้แล้วว่ามีแอตทริบิวต์นั้นอยู่ ใน codebase ที่ตรวจชนิดแบบครบถ้วนแล้ว ทำไมถึงทำแบบนี้กันนะ? สงสัยว่าเป็นเพราะ pretraining หรือ reinforcement learning ถ้าเป็นอย่างหลัง ก็อยากให้ห้องแล็บทั้งหลายช่วยแก้ทีบน HN มีการพูดเรื่องนี้เยอะ แต่ไม่ว่าจะเป็นโอเพนซอร์สหรือที่ทำงาน เวลาเห็น codebase ที่ไม่ใช่ผมเขียนแล้วทำเรื่องนี้ได้ดีจริง ๆ ก็ยังประหลาดใจอยู่เสมอ โปรแกรมเมอร์ส่วนใหญ่ไม่ได้คิดแบบทำให้ข้อผิดพลาดเกิดขึ้นไม่ได้แล้วให้ข้อมูลสะท้อนความจริงนั้น แต่จะคิดแบบคอยเก็บเศษชิ้นส่วนมาแก้ตรงจุดที่ข้อความ error โผล่ออกมาแทน ที่บอกว่า “ส่วนใหญ่” ก็เพราะผมมองว่า AI ปัจจุบันเองก็มีปัญหาในวิธีคิดแบบนี้เหมือนกัน การจะให้ AI เข้าใจ codebase ในระดับสุดท้ายแบบที่มนุษย์เข้าใจ คือเข้าใจการไหลของการรับประกันต่าง ๆ แบบภาพรวมทั้งระบบ ตอนนี้ยังยากมาก ในระดับโค้ดดิบ การรับประกันพวกนี้มักกระจายอยู่ในโค้ดจำนวนมากจน context window แตกได้ง่าย ต่อให้พยายามสรุปเป็นไฟล์แบบ memory ก็ยังมีปัญหา การที่มีข้อความเขียนเรื่องการรับประกันไว้ ไม่ได้แปลว่า AI จะดึงข้อมูลที่ถูกต้องออกมาได้ และมนุษย์เองถ้าอ่านแต่โค้ดก็เหมือนกัน ผมจะไม่บอกว่าการให้ AI มีความเข้าใจแบบนี้เป็นเรื่อง “เป็นไปไม่ได้” แต่ถึงจะทำให้มันเข้าใจได้ วิธีทำงานของ AI ก็มักสวนทางกับความเข้าใจนั้นอยู่บ่อย ๆ ทางแก้ของผมส่วนใหญ่คือเลิกหวังให้ AI เข้าใจเรื่องนี้โดยตรง แทนที่จะทำแบบนั้นก็เอาวิธีแก้ปัญหามาทำเป็นพรอมป์ตอย่างที่คนทั่วไปทำ และถ้าอยากทำให้สถานะที่ผิดพลาดที่ไม่ดีเป็นสิ่งที่แสดงออกมาไม่ได้ ก็ให้ AI ทำขั้นตอน refactoring ที่จำเป็นทีละขั้น ถ้าเล็กมากก็ทำเอง เวลาสั่งให้มันค่อย ๆ ทำโค้ดที่เต็มไปด้วย map/dictionary, array, string และ integer ให้มีการกำหนดชนิดอย่างเข้มงวดขึ้น มันกลับทำได้ค่อนข้างดี ไม่ว่าจะเขียนละเอียดแค่ไหน ผมแทบไม่เคยได้ดีไซน์ที่ดีจากพรอมป์ตเดียว การแยกเป็นสองงานคนละชิ้นดูจะเข้ากว่ามาก และต้องคอยระวังความต่างของชนิดข้อมูลให้ดี AI ชอบแอบยัดเมธอดอย่าง
.JustSetItAndIgnoreAllThePreAndPostConditions(string)เข้ามา เหมือนกับว่าในข้อมูลฝึกมีตัวอย่างเยอะของ “ชนิดข้อมูลที่จัดโครงสร้างมาดีเพื่อทำให้สถานะข้อผิดพลาดแสดงออกมาไม่ได้ แต่ต่อมามีคนดูแลเข้ามาแล้วเพิ่มเมธอดJustEffingDoItที่พังทุกอย่าง” หนึ่งในวิธีป้องกันที่ดีที่สุดคือแยกชนิดข้อมูลพวกนี้ไว้ในไฟล์ของตัวเอง จะได้ไล่ดูเมธอดที่ถูกเพิ่มเข้ามาทั้งหมดได้ง่าย และถ้ามีอะไรแบบนั้นก็จับได้ทันที ผมเคยเขียนคำเตือนในเอกสารไว้เยอะมากว่าอย่าทำ พร้อมอธิบาย precondition/postcondition ที่ต้องรักษาไว้ แต่ผลแทบไม่ต่างกันgetattrกับทุก dataclass เป็นทางเลือกที่ประหลาดจริง ๆโค้ดคือส่วนหนึ่งของความเข้าใจร่วมที่ถูกแบ่งปันและสั่งสมเกี่ยวกับระบบสารสนเทศ
ถ้าลูปพวกนี้กำลังทำให้พวกเราทุกคนยังเคลื่อนไหวอยู่ท่ามกลางคลื่นซอฟต์แวร์ที่ถาโถมมาไม่หยุด สุดท้ายแล้วในการออกแบบระบบสารสนเทศเชิงตรรกะระดับสูงที่สุด ทุกอย่างก็จะกลายเป็นเรื่องของการใช้วิจารณญาณของมนุษย์และการถ่วงดุลกับความต้องการทางธุรกิจ เพื่อให้เข้ากับบริษัทหรือช่องตลาดเฉพาะทาง โปรแกรมเมอร์ทุกคนคงต้องกลายเป็นทั้งนักวิเคราะห์ธุรกิจ นักวิจัยตลาด และนักธุรกิจด้วย ยกเว้นในช่องเฉพาะบางแบบที่เครื่องมือ AI “กระท่อนกระแท่น” เข้าไปทำได้ไม่ดี หรือเมื่อยุค AI token ที่มีเงินอุดหนุนจบลงจนลูปทั้งหมดนี้แพงเกินไป มันให้ความรู้สึกเหมือนการหวนกลับมาของ expert systems และเครื่อง Symbolics Lisp ชั่วขณะหนึ่ง สิ่งที่เราเคยเผชิญคือ ตัวโค้ดเองไม่ได้เป็นข้อจำกัดว่าอะไรทำไม่ได้ แต่โครงสร้างองค์กรของบริษัทจะถูกถ่ายทอดลงมาในซอฟต์แวร์ในที่สุด ดังนั้นถ้าเปลี่ยนโครงสร้างองค์กรไม่ได้ ความยืดหยุ่นของซอฟต์แวร์ก็มีขีดจำกัดเช่นกัน data flow, ความรู้โดเมน, domain modeling และ ubiquitous language อาจกลายเป็น ภาษาเหนือระดับ ที่เรากำหนดคุณภาพ ฟังก์ชัน มาตรฐานแบบ non-functional และธรรมเนียมปฏิบัติกันได้ เราต้องทำให้ “clanker ที่วิ่งวนลูป” พวกนี้ทำตามสัญญาด้านข้อมูล พฤติกรรม และประสิทธิภาพให้ครบก่อนที่มันจะบอกว่า “เสร็จแล้ว” ตอนนี้คำว่า “เสร็จแล้ว” ไม่ได้หมายถึงแค่โค้ดที่คอมไพล์ได้ สร้างบิลด์ได้ ดีพลอยได้ หรือแม้แต่ขึ้น production ได้แล้วเท่านั้น มันต้องเป็นโค้ดที่ตอบโจทย์ทั้งผู้ใช้ ผู้ปฏิบัติการระบบ และผู้ดูแลรักษาด้วย เพราะงั้นภาษาที่ใช้จึงอาจทำให้พวกเราทุกคนเข้าใกล้บทบาทนักวิเคราะห์ธุรกิจและสถาปนิกซอฟต์แวร์มากกว่าคนที่แค่รู้ไวยากรณ์ภาษา นี่จะเป็นการล้างแค้นของ UML และการกลับมาของการออกแบบเชิงประกาศ/เชิงตรรกะ/BDD หรือเปล่า?
ตรวจคำสะกดด้วย gemma4-12b แต่ไม่ได้ให้มันเปลี่ยนสารที่ต้องการสื่อ
ผมคิดอยู่เรื่อย ๆ ว่าตั้งแต่เมื่อไหร่ผมจะไม่จำเป็นต้องถูกยัดเข้าไปอยู่ในลูปอีกต่อไปแล้ว ในฐานะนักพัฒนา ผมชอบมากกับการขัดเกลาโครงสร้างโค้ด ทำให้มันชัดเจนขึ้น คิด abstraction ที่ดี และแยกมันออกเป็นโมดูล
ผมสนุกกับมัน แต่ก็เข้าใจเหมือนกันว่า ณ จุดหนึ่ง ตัวผมเองกลายเป็นคอขวด ถ้าจุดประสงค์ของซอฟต์แวร์คือการสร้างประโยชน์ให้ผู้คน เราควรยังใส่ใจอยู่ไหมว่าโค้ดหน้าตาเป็นอย่างไร? ตอนนี้ผมคิดว่าคำตอบคือ “ใช่” แต่ในอีก 3 ปีล่ะ? อีก 10 ปีล่ะ?
ถ้าบางอย่างต้องใช้การตัดสินใจมาก และเป็น “โค้ดที่ฉันใส่ใจอย่างลึกซึ้ง” ก็ยากจะเห็นด้วยกับแนวทางที่พูดถึงตรงนี้ ไม่ควรพยายามมอบหมายการตัดสินใจที่เราใส่ใจมาก
ฉันชอบการแยกระหว่าง agent loop กับ harness loop แต่ควรมอบหมายเฉพาะสิ่งที่สามารถระบุสเปกได้อย่างแม่นยำล่วงหน้าเท่านั้น สำหรับฉัน ส่วนใหญ่จะเป็นงานที่ทำซ้ำได้ เช่น “ดูว่า X ทำอย่างไร แล้วทำแบบนั้นกับ Y ด้วย” ซึ่งโดยเนื้อแท้แล้วเป็นงานที่คาดเดาได้ ถ้าพอเอาการตัดสินใจของฉันออกไปแล้ว สุดท้ายมันจะเป็นสิ่งที่ฉันต้องบอกว่า “ไม่” ก็ต้องถอยลงมาอยู่ที่การทำงานร่วมกันภายใน agent loop ตามที่ Armin พูดถึง ซึ่งก็โอเคมาก ทั้งเร็วและปลอดภัย แม้ก่อนจะมีผู้ช่วยเขียนโค้ด AI บางครั้งก็มีวิศวกรที่มีประสิทธิภาพสูงมากเข้ามาอยู่ในทีม เพื่อนร่วมงานจะอิจฉาแล้วพูดว่า “ที่พวกคุณทำทั้งหมดนั้นได้ก็เพราะทีมมี X อยู่ไม่ใช่เหรอ!” แต่พวกเขาไม่เคยเจอกับคำสาปของการมีคนแบบนั้นอยู่ข้างตัว ถ้าไม่ได้ aligned กันอย่างสมบูรณ์ คนเหล่านั้นจะพุ่งไปผิดทิศทางด้วยความเร็วมหาศาล
ไม่รู้ว่านี่จริง ๆ หมายถึงอะไร มันก็แค่บทความยืดยาวที่เอาแนวคิดนามธรรมมาวางเรียงกัน เหมือนออกแบบมาเพื่อบอกเป็นนัยว่ามีภาพใหญ่กว่านั้น แต่สุดท้ายก็คือเรื่องให้ AI เขียนโค้ดให้
ต่อไปมันจะเป็นแบบนี้เหรอ? ที่จริงแล้วเราไม่ได้กำลังเป็นผู้นำทางความคิด แต่กำลังกลายเป็นครูเทียม ๆ ที่พยายามต้อนฝูงคนโง่ AI ให้ไปทางคำตอบ ขณะเดียวกันก็ต้องทำให้บทบาทนี้ดูคลุมเครือราวกับเป็นผู้นำทางความคิดต่อไป โดยไม่ให้คนจับได้ว่านี่ทั้งหมดคือ tech posturing?
ผู้เขียนอาจขัดเกลาให้กระชับกว่านี้ได้ แต่ที่ผู้อ่านไม่เข้าใจเนื้อหาในระดับปัจจุบัน ไม่ได้แปลว่ามีการทำให้มันดูลึกลับอะไร
ฉันเห็นสิ่งที่ต้นฉบับพูดถึงนี้ตรงเป๊ะทั้งในงานและโปรเจกต์ส่วนตัว และมันน่ากลัวที่บางคนมองว่านี่เป็นแค่ “บทความยืดยาวที่เรียงแนวคิดนามธรรม” มันทำให้รู้สึกว่าคนส่วนใหญ่ไม่รู้เลยว่าตอนนี้กำลังเกิดอะไรขึ้น
ในวงการ AI อายุของเทคนิคล้ำสมัยล่าสุดมีแค่ประมาณ 2 สัปดาห์ ฉันยังตาม Ralph Wiggum loop ไม่ทันเลย ตอนนี้เลยรู้สึกว่าดีแล้วที่ไม่ได้พยายามตาม
https://news.ycombinator.com/item?id=46682325