ประสิทธิภาพอันเกินคาดของลูปเอเจนต์ LLM และการใช้เครื่องมือ

• เน้นให้เห็นถึงการติดตั้งใช้งานที่เรียบง่ายของ โครงสร้างลูปที่ผสาน LLM กับการใช้เครื่องมือ ผ่านประสบการณ์พัฒนา Sketch ผู้ช่วยเขียนโปรแกรมด้วย AI
• ด้วยโค้ดลูปเพียง 9 บรรทัด โมเดล LLM รุ่นใหม่อย่าง Claude 3.7 Sonnet ก็สามารถแก้ปัญหาจริงได้อย่างรวดเร็ว
• แม้จะมีเพียงเครื่องมืออเนกประสงค์อย่าง bash ตัวเดียว ก็ยังช่วยทำงานซ้ำๆ และงานที่จุกจิกของนักพัฒนาให้เป็นอัตโนมัติได้ในระดับมาก
• นอกจากการแก้ปัญหาแล้ว ยังสามารถเชื่อมต่อเครื่องมือเพิ่มเติมเพื่อยกระดับคุณภาพและความเร็วในการทำซ้ำของ การแก้ไขข้อความหรืองานเฉพาะทาง
• มีแนวโน้มที่จะเห็น ลูปเอเจนต์ LLM แบบปรับแต่งเฉพาะ ถูกนำมาใช้กับงานอัตโนมัติในชีวิตประจำวันของนักพัฒนามากขึ้นเรื่อยๆ

---

บทนำ: ประสบการณ์การพัฒนาและโปรเจ็กต์ Sketch

• Philip Zeyliger และเพื่อนร่วมงานรู้สึกประหลาดใจกับประสิทธิภาพที่สูงของ โครงสร้างลูปเอเจนต์แบบเรียบง่ายที่ผสาน LLM กับการใช้เครื่องมือ ระหว่างพัฒนา Sketch เครื่องมือช่วยเขียนโปรแกรมที่ขับเคลื่อนด้วย AI
• โครงสร้างหลักคือโค้ดลูปเพียง 9 บรรทัด ซึ่งส่ง system prompt, ประวัติการสนทนา และข้อความล่าสุดไปยัง LLM API
• LLM จะสร้างผลลัพธ์ และหากจำเป็นก็จะส่งคืน tool_calls (คำขอเรียกใช้เครื่องมือ)

การผสานรวม LLM และการใช้เครื่องมือ

• “การใช้เครื่องมือ (tool use)” หมายถึงการที่ LLM ส่งคืน เอาต์พุตที่เป็นไปตามสคีมาที่กำหนดไว้ล่วงหน้า และผ่าน system prompt กับพรอมป์ต์อธิบายเครื่องมือ ทำให้ LLM เข้าถึงเครื่องมืออเนกประสงค์อย่าง bash ได้
• LLM รุ่นใหม่ (เช่น Claude 3.7 Sonnet) สามารถทำงานอัตโนมัติกับปัญหาหลากหลายได้อย่างรวดเร็วด้วยเครื่องมืออเนกประสงค์เพียงตัวเดียว และบางกรณีก็แก้ได้ด้วยการรันครั้งเดียว (“one shot”)
• ก่อนหน้านี้ต้องค้นหาคำสั่ง git ที่ซับซ้อน คัดลอกมาวาง และรวมโค้ดด้วยตนเอง แต่ตอนนี้สามารถสั่ง Sketch ให้จัดการได้ทันที
• แม้แต่ข้อผิดพลาด type check จำนวนมากที่เกิดขึ้นหลังจากเปลี่ยน type, Sketch ก็สามารถจัดการให้อัตโนมัติได้เป็นครั้งแรก
• ลูปเอเจนต์ทำงานแบบ ต่อเนื่องและปรับตัวได้ โดยหากยังไม่ได้ติดตั้งเครื่องมือก็จะติดตั้งให้อัตโนมัติ และยังปรับรับความแตกต่างของออปชันคำสั่งได้ด้วย
• ระหว่างใช้งาน บางครั้ง LLM อาจเสนอทางเลือกที่ไม่คาดคิด เช่น “ข้ามการทดสอบ” เมื่อการทดสอบล้มเหลว แต่โดยรวมแล้วคุณภาพของงานอัตโนมัติก็ดีขึ้น

การเพิ่มความหลากหลายและความเฉพาะทางของเครื่องมือ

• Sketch พบว่าเมื่อใช้ เครื่องมือเพิ่มเติมนอกเหนือจาก bash (เช่น เครื่องมือแก้ไขข้อความ) จะช่วยยกระดับคุณภาพงานและทำให้เวิร์กโฟลว์การพัฒนามีประสิทธิภาพยิ่งขึ้น
• การให้ LLM แก้ไขข้อความอย่างแม่นยำด้วย sed และเครื่องมือคล้ายกันนั้นยากกว่าที่คิด และรู้สึกได้ว่าเครื่องมือแบบเอดิเตอร์เชิงภาพ (visual) ทำได้ดีกว่า

แนวโน้มในอนาคตและการเปลี่ยนแปลงของเวิร์กโฟลว์

• คาดว่า โครงสร้างลูปเอเจนต์ จะถูกนำไปใช้มากขึ้นเรื่อยๆ กับ งานซ้ำๆ ในชีวิตประจำวันของนักพัฒนาที่เครื่องมืออัตโนมัติอเนกประสงค์แบบเดิมจัดการได้ยาก
• ตัวอย่างเช่น งานที่น่ารำคาญและต้องทำซ้ำอย่างการวิเคราะห์ความสัมพันธ์ระหว่าง stack trace กับ git commit ก็สามารถให้ LLM ช่วยประมวลผลขั้นต้นได้อย่างรวดเร็ว
• ในอนาคตคาดว่าจะได้เห็น ลูปเอเจนต์ LLM แบบสร้างเฉพาะและใช้ครั้งเดียว มากขึ้นในสภาพแวดล้อมของนักพัฒนา เช่น ในไดเรกทอรี bin/
• ผู้ใช้เพียงเตรียม bearer token ที่ต้องการ ก็สามารถทดลองใช้งานในสภาพแวดล้อมของตนเองได้อย่างง่ายดาย

ลิงก์อ้างอิง

• เนื้อหานี้เผยแพร่ไว้ที่ บล็อก philz.dev ด้วย
• สามารถดูข้อมูลเพิ่มเติมเกี่ยวกับโปรเจ็กต์และข้อมูลที่เกี่ยวข้องได้ที่ sketch.dev, merde.ai, pi.dev

[GN⁺]

ความคิดเห็นจาก Hacker News

• อยากแนะนำโพสต์บล็อกนี้อย่างมากเช่นกัน เพราะอธิบายประเด็นเดียวกันได้ละเอียดและน่าเชื่อถือกว่ามาก ผู้เขียนได้ลองสร้าง coding agent ขึ้นมาเองตั้งแต่ศูนย์ ดูได้ที่ https://ampcode.com/how-to-build-an-agent ประสบการณ์ที่ได้เห็นว่า LLM จัดการงานได้หลากหลายแค่ไหนเมื่ออยู่ในลูปที่เรียกใช้เครื่องมือได้นั้นน่าทึ่งจริง ๆ แน่นอนว่ามันยังไม่สมบูรณ์ และยังมีปัญหาอย่างเช่นไปไม่ถึงความน่าเชื่อถือ 100% แต่ผมก็คิดว่าอย่างน้อยมันก็น่าทึ่งอยู่พอสมควร ถ้าลองทำเองก็น่าจะตามได้ภายใน 30 นาที เป็นสิ่งที่ทำให้ทั้งรู้สึกมหัศจรรย์ไปพร้อมกับยังรักษาความสงสัยอย่างมีเหตุผลไว้ได้ว่า AI เหมาะกับงานบางประเภทจริงหรือไม่ “ประสิทธิภาพที่ผิดธรรมดา” ของการเอา LLM มาไว้ในลูปนี่เองคือเหตุผลที่ตอนนี้มี code generation agent ออกมามากมาย: Claude Code, Windsurf, Cursor, Cline, Copilot, Aider, Codex และอีกเยอะมาก รวมถึงโปรเจกต์ที่ทำตามก็มีเพียบเช่นกัน นี่จึงเป็นเหตุผลว่าทำไมไม่มีสูตรลับอะไรเป็นพิเศษ เพราะเวทมนตร์ 95% แท้จริงแล้วอยู่ที่ตัว LLM เองกับการ fine-tune ให้มันเรียกใช้เครื่องมือได้ ซึ่งหัวหน้านักพัฒนาของ Claude Code ก็เพิ่งยอมรับตรง ๆ ในบทสัมภาษณ์ล่าสุด แน่นอนว่าการทำให้เครื่องมือพวกนี้ใช้งานได้ดีต้องใช้ความพยายามมาก แต่โดยพื้นฐานแล้วแกนกลางยังเป็นโครงสร้างง่าย ๆ ที่แทบเหมือนกัน
  • รู้สึกขอบคุณมาก เพราะผมหาบทความแบบนี้มานานมาก หลายคนเห็น Agents แล้วมักจะตอบว่า “คงแก้ปัญหาที่ซับซ้อนจริง ๆ ไม่ค่อยได้หรอกมั้ง?” แต่สำหรับผม ประเด็นสำคัญของเอเจนต์ไม่ได้อยู่ตรงนั้น LLM ทำงานได้ดีมากเมื่อมีคอนเท็กซ์เยอะ และเอเจนต์ก็คือโครงสร้างที่ช่วยให้ LLM ไปหาคอนเท็กซ์เพิ่ม เพื่อยกระดับคุณภาพของคำตอบต่อคำถาม
  • จากประสบการณ์ของผม นึกไม่ค่อยออกว่ามีงานอะไรที่ LLM จะทำเองในลูปได้ดีเกินไม่กี่รอบโดยไม่ต้องมีการชี้แนะเพิ่มเติม สักพักก็ต้องมีจุดที่ผมต้องเข้าไปแทรกอยู่ดี
  • มีทิวทอเรียลที่ทำอะไรคล้ายกันโดยใช้ไลบรารี graph abstraction ชื่อ pocketflow ผมลองใช้จริงแล้วและพอใจมาก เพราะมันค่อนข้างเรียบง่าย https://github.com/The-Pocket/PocketFlow-Tutorial-Cursor/blob/main/blog.md
  • เพิ่งสังเกตนี่เองว่าผู้เขียนคือ Thorsten Ball ผมจำได้ว่าเคยอ่านงาน "สร้าง interpreter" ของเขาอย่างสนุกมาก ตอนนี้ผมเองก็คงได้เวลาลองสร้างเอเจนต์บ้างแล้ว
  • ก่อนเปิดลิงก์ข้างบน ผมยังลังเลเลยว่าควรเติม ?utm_source=hn&utm_medium=browser เข้าไปก่อนดีไหม
• วันนี้ผมเพิ่งลอง “vibe-coding” เองเป็นครั้งแรกกับ GPT-4o และ 4.1 วิธีที่ใช้คือคอยป้อน compile errors, warnings และข้อเสนอแนะเข้าไปวนลูปผ่านอินเทอร์เฟซแบบ canvas ด้วยมือ ไฟล์ก็เล็ก แค่ประมาณ 150 บรรทัด เริ่มจาก 4o ก่อน แต่มันใช้แพ็กเกจเก่า แม้ผมจะชี้ให้เห็นแล้ว มันก็ไม่ได้อัปเดตการใช้งานทั้งหมด ผมต้องมานั่งแก้เอง พอเสนอให้เปลี่ยน logic ก็เกิดสถานการณ์ที่ไวยากรณ์พังเละและกู้กลับมาไม่ได้อีกเลย แม้จะคอยป้อน compile errors ต่อไป มันก็ไม่เข้าใจว่าปัญหาเป็นเรื่อง syntax และกลับไปแก้ส่วนสุ่ม ๆ ของโค้ดแทน เลยหวังว่า 4.1 จะดีกว่า แต่ 4.1 กลับปฏิเสธที่จะใช้ canvas แล้วเอาแต่ อธิบายอย่างเดียว แนวประมาณให้ผมไปแก้เอง พอพยายามกล่อมอยู่นานมันถึงยอมใส่โค้ดลง canvas แต่คราวนี้กลับเป็นเวอร์ชันที่โดนตัดกลางด้วยอะไรทำนอง // omitted for brevity จนใช้การไม่ได้ ผมเลยยอมแพ้ตรงนั้น อยากรู้ว่าเอเจนต์ต่าง ๆ ช่วยแก้ปัญหานี้ได้ไหม ตอนนี้ผมรู้สึกว่าประสบการณ์นี้พังโดยสิ้นเชิง และก็ยังกังวลว่าการให้สิทธิ์เข้าถึง bash ในสภาพแบบนั้นอันตรายเกินไป
  • ประเด็นที่ว่า “มันใช้แพ็กเกจเก่า” เป็นเพราะช่วงเวลาของข้อมูลฝึกของโมเดลถูกตัดไว้ นี่เป็นสิ่งที่ต้องระวังมากเวลาใช้ LLM ผมเปลี่ยนไปใช้ o4-mini-high ใน ChatGPT บ่อยมาก เพราะโมเดลนี้ใช้ความสามารถค้นหาเพื่อหาเอกสารล่าสุดได้ด้วย ถ้าขอว่า “ช่วยเช็กเวอร์ชันล่าสุดของไลบรารี X แล้วใช้ตามนั้น” มันมักจะทำได้ดี ไม่นานมานี้ผมมีงานแปลง JavaScript บางส่วนให้ใช้ไลบรารีที่ Google แนะนำรุ่นล่าสุด แค่แปะโค้ดเดิมเข้าไปแล้วขอให้พอร์ตไปยังไลบรารีใหม่ มันก็ไปหาเอกสารและพอร์ตให้อย่างถูกต้อง https://simonwillison.net/2025/Apr/21/ai-assisted-search/#lazily-porting-code-to-a-new-library-version-via-search
  • GPT 4.1 กับ 4o ได้คะแนนต่ำมากใน benchmark งานเขียนโค้ดของ Aider จากประสบการณ์ใช้งานจริง ผมว่าต้องได้เกิน 70% ถึงจะพอให้ผลลัพธ์มีประโยชน์ ถึงอย่างนั้นงานซับซ้อนก็ยังต้องอาศัยการช่วยเหลือค่อนข้างมาก ใช้ไปเรื่อย ๆ จะเริ่มจับทางได้ว่าอะไรเวิร์กอะไรไม่เวิร์ก https://aider.chat/docs/leaderboards/
  • คำว่า “เป็นปัญหาเรื่องฝีมือ” อาจฟังแล้วไม่อยากได้ยิน แต่การใช้ LLM นั้นเป็นทักษะเฉพาะทางที่ต้องฝึกจริง ๆ ต้องเข้าใจข้อดีข้อเสียของเครื่องมือต่าง ๆ ทดลองหลายเทคนิค และฝึกฝนอย่างต่อเนื่อง ถ้าจะให้สิทธิ์เข้าถึง bash ผมเองก็คงใช้เฉพาะในสภาพแวดล้อมแบบคอนเทนเนอร์ (docker) เท่านั้น
  • แบบนั้นเรียกว่า vibe coding ไม่ได้ ต้องใช้เครื่องมือที่สามารถนำการเปลี่ยนโค้ดไปใช้จริงแบบอัตโนมัติถึงจะนับว่าเป็น vibe coding ถ้าคอยให้ feedback ทีละอย่างด้วยมือตลอด สุดท้ายก็จะติดกับ error แล้วไปต่อไม่ได้ หัวใจของ vibe coding คือย้อนกลับได้ รันใหม่ได้ และลองโยนวิธีแก้หลายแบบแล้วทิ้งได้ง่าย จะได้ประสบการณ์แบบนั้นต้องมี tooling ช่วย
  • ไม่นานมานี้ผมใช้ปลั๊กอิน Cline กับ Claude ใน VSCode เพื่อสร้างต้นแบบแอป Android “จากศูนย์” เริ่มจาก template พื้นฐานที่ Android Studio ให้มา แล้วสร้างโค้ดออกมาหลายพันบรรทัดโดยไม่มี compile error แม้แต่บรรทัดเดียว แอปทำงานได้ตามที่คาดไว้ และบั๊กไม่กี่จุดที่พบก็ไม่ได้เป็นความผิดของ LLM แต่เป็นพฤติกรรมประหลาดของ Android API พอผมชี้บั๊กให้ LLM ดูและให้ผลลัพธ์ debug message มันก็แก้ให้เอง ตอนแรกการแก้อาจยังหยาบ ๆ แต่พอ feedback กันไม่กี่รอบก็ออกมาดี ผมคิดว่าถ้าเอา code-writing agent กับ code-review agent มาใส่ไว้ในลูป ก็น่าจะช่วยรับมือเรื่องแบบนี้ได้ดีขึ้นในภาพรวม
• ผมใช้ Claude Code หรือก็คือเทอร์มินัลอินเทอร์เฟซของ Sonnet 3.7 มาตั้งแต่วันเปิดตัว เคยใช้เขียนทั้งแอป CLI ขนาดค่อนข้างใหญ่ ระบบเว็บ full-stack และ utility อีกมากมาย มันทำให้ผมกล้าลองอะไรทะเยอทะยานขึ้น คล้ายตอนที่เคยเป็นหัวหน้าทีมโปรแกรมมิง แม้ในเชิงโครงสร้างมันอาจไม่ได้ต่างจากเครื่องมืออื่นมากนัก แต่รู้สึกว่า Anthropic ใส่ฟีเจอร์ที่มีประโยชน์มากเข้ามาเยอะ แน่นอนว่าไม่มีอะไรสมบูรณ์แบบ และถ้าจะได้โค้ดคุณภาพดีก็ยังต้องออกแรงพอ ๆ กับเมื่อก่อน หลายอย่างที่ค่อนข้างซับซ้อนก็ยังทำให้ใช้งานได้ แต่บางครั้งพอจะเพิ่มฟีเจอร์ถัดไปกลับเริ่มยากขึ้น เมื่อชินกับวิธีใช้งานแล้ว กระบวนการ refactor และเก็บรายละเอียดก็ลดลงไปมาก แม้จะไม่หายไปหมดก็ตาม ปัญหาที่ kgeist เจอนั้นพูดตรง ๆ ว่าผมนึกภาพไม่ออก Claude เองบางครั้งก็เลือกทางไม่เหมือนผมหรือทำอะไรโง่ ๆ บ้าง แต่ไม่เคยถึงขั้นทำให้ผมอยากยอมแพ้เลย มันแทบจะให้ผลลัพธ์ที่ดีพอเสมอ และช่วยลดภาระทางความคิดไปได้มหาศาล แถมยัง refactor ได้ยอดเยี่ยมมาก เวลาผมเปิดโค้ดขึ้นมาดูเป็นระยะ แล้วขอให้ Claude อธิบายว่ามีวิธีที่ดีกว่านี้ไหม ความซับซ้อนจะลดลงอย่างเห็นได้ชัด คำขออย่าง “เปลี่ยน data structure” ก็จัดการให้ได้ทันที เป็นความสามารถที่เจ๋งมาก และเพื่อความสนุก ผมยังลองเปิดไดเรกทอรี archive อายุ 30 ปีที่เต็มไปด้วยไฟล์สารพัดอย่างที่ไม่ใช่โค้ด แล้วถามว่า “มีอะไรอยู่ในไดเรกทอรีนี้บ้าง?”, “อ่านเรซูเม่เก่าของฉันแล้วเขียนใหม่ให้หน่อย”, “ชื่อลูก ๆ ของฉันคืออะไร?” อะไรทำนองนั้น มันน่าทึ่งจริง ๆ แม้ยังอยู่ในระยะเริ่มต้นก็ทำให้ผมมีความสุขมาก
  • เมื่อไม่นานมานี้ผมต้องจัดการงานที่มีทั้งการนิยามโครงสร้างข้อมูลระยะไกล, สเปก API, การ parse และบันทึกข้อมูล, ไปจนถึงการแสดงผลให้ผู้ใช้ ทั้งหมดในคราวเดียว Claude ช่วยจัดการงานทั้งหมดนี้พร้อมกันได้ดีมาก ทำให้เห็นได้ทันทีว่าการเปลี่ยนเล็ก ๆ ที่ปลายด้านหนึ่งจะส่งผลต่อชั้นกลางอย่างไร ผมจึงวนทดลองหลายแนวคิดได้อย่างรวดเร็วเพื่อหาแนวทางที่ดีที่สุด สิ่งที่น่าทึ่งคือเราสามารถสำรวจหลายชั้นของความซับซ้อนสูงแบบนี้ได้ด้วยความเร็วในการวนซ้ำที่มาก ซึ่งทั้งเพิ่มผลิตภาพและเพิ่มความเข้าใจเชิงโครงสร้างของระบบโดยรวมไปพร้อมกัน
  • งาน refactoring ที่พูดถึงข้างบนนี่แหละสนุกมาก ฟีเจอร์ที่เมื่อก่อนแทบยัดลง sprint ไม่ได้ ตอนนี้เสร็จได้ใน 5 นาที มันเหมือนมีทีมที่พร้อมอยู่แล้วคอยรอรับคำสั่งจากผมตลอดเวลา ถ้าผลลัพธ์ไม่ถูกใจก็แค่ปฏิเสธได้ทันที และความกังวลเรื่องการรีวิวที่ไม่จำเป็นหรือการจัดตารางเวลาก็ดูเหมือนหายไปหมด
• ผมหงุดหงิดมากเวลาที่ LLM พูดทำนองว่า “อ๋อ เทสต์นี้ใช้ไม่ได้... งั้นข้ามมันไปก็แล้วกัน” ผมมีไอเดียหนึ่งให้นึกเล่น ๆ คือให้รัน policy-enforcing LLM ที่เป็นอิสระและทำงานขนานกัน เพื่อคอยบังคับให้ LLM ตัวหลักทำตามคำสั่ง ตัวอย่างเช่น ให้ LLM ตัวช่วยไปปรับความน่าจะเป็นของผลลัพธ์ไม่ให้มีคำว่า “skip” โผล่มาหลังคำว่า “let's just” กล่าวคือถ้าห้ามคำว่า “skip” ได้ ก็อาจเบี่ยงเส้นทางมันออกจากพฤติกรรมที่ไม่ต้องการได้ มันจะทำงานคล้าย JSON mode หรือ structured outputs แต่เป็นแบบที่ LLM ตัวช่วยคอยควบคุมนโยบายแบบไดนามิกและเรียลไทม์ ถ้ามันเวิร์ก ก็น่าจะต่อยอดได้อีก เช่น ใส่นโยบายห้ามลบเทสต์เพื่อให้เทสต์ผ่าน หรือห้ามพ่นคอมเมนต์ไร้สาระต่าง ๆ ลงไปใน prompt ของ LLM ตัวช่วย แล้วให้มันคอยเฝ้าและควบคุมแบบเรียลไทม์ อยากรู้เหมือนกันว่าทีม Outlines จะคิดอย่างไรกับสถาปัตยกรรมแบบนี้
  • ถ้า LLM ตัวหนึ่งสามารถตรวจผลลัพธ์ของอีกตัวได้ ก็ชวนให้สงสัยว่า mixture of experts LLM จะสามารถมอบหมายผู้เชี่ยวชาญอัลกอริทึมตัวหนึ่งให้ทำหน้าที่เฝ้าระวังและตรวจสอบอีกตัวได้ไหม หรืออาจแยก thread ความคิดออกมาต่างหากเพื่อให้มันตรวจผลลัพธ์ของตัวเอง แล้วถ้าจำเป็นก็มีอีก thread มาตรวจผู้ตรวจอีกที เพื่อทำให้ระบบแน่นขึ้นไปอีก
  • ในบริบทนี้ยังนึกภาพได้ด้วยว่า ถ้า LLM ตัวหลักกำลังออกนอกลู่นอกทาง LLM ที่ทำหน้าที่เฝ้าระวังอาจ “rewind” โมเดลกลับไปถึงจุดนั้นได้ เช่น ถ้าตรวจพบ “let's just skip the test” ก็ rollback กลับไปหลังคำว่า “just ” แล้วคอยใส่ bias ต่อเนื่องเพื่อไม่ให้คำบางคำถูกใช้ งานแบบนี้อาจทำให้ทางเลือกของผู้ให้บริการโมเดลที่ใช้งานได้จำกัดลง และโดยเฉพาะ OpenAI ดูจะมีแนวโน้มไม่เป็นมิตรกับฟีเจอร์สำหรับ power user แบบนี้มากขึ้นเรื่อย ๆ ในช่วงหลัง
• เช้านี้ผมใช้ cursor ดึงส่วนที่ซับซ้อนบางส่วนออกมาจาก main loop ของเกมต้นแบบ และให้มันสร้างชุดโค้ดทดสอบสำหรับส่วนนั้นโดยอัตโนมัติ ตอนนี้มีเทสต์ทั้งหมด 341 รายการ ครอบคลุมทั้ง core math และคอมโพเนนต์สำคัญทั้งหมด บางทีก็ให้ความรู้สึกเหมือนต้อนแมว แต่ยิ่งระบุข้อจำกัดให้มากขึ้น เช่น ต้องใช้ฟังก์ชันไหน ตำแหน่งไหน ไฟล์ template แบบใด หรืออะไรที่ต้องหลีกเลี่ยง ผลลัพธ์ก็ยิ่งดีขึ้นเรื่อย ๆ สุดท้ายผมได้โค้ดเทสต์ 3500 บรรทัดโดยไม่ต้องเขียนเอง และถ้ามีปัญหาก็ลบทิ้งแล้วสร้างใหม่ได้ทุกเมื่อ มันยังช่วยเรื่องการปรับความชันของความยาก การแปรผันของมิชชัน และอีกหลายอย่างมากด้วย
  • จากประสบการณ์ของผม การสร้างเทสต์อัตโนมัติคือ use case ที่ดีที่สุดของ LLM มันลบงานน่าเบื่อและซ้ำซากที่อาจกินเวลาหลายชั่วโมงหรือหลายวันออกไปได้ในครั้งเดียว อีกทั้งยังครอบคลุม edge cases จำนวนมากที่ผมเองอาจนึกไม่ถึง และยังช่วยเพิ่มความปลอดภัยของโค้ดด้วย เป็นความสามารถที่ยอดเยี่ยมรอบด้านจริง ๆ
• ช่วงนี้ผมตื่นเต้นมากกับความสามารถในการใช้เครื่องมือของ LLM จริง ๆ แล้วทริกนี้ไม่ใช่ของใหม่ ผมรู้จักมันครั้งแรกจากงานวิจัย ReAcT เมื่อ 2 ปีก่อน หลังจากนั้นก็ถูกใช้ใน ChatGPT plugins, MCP และอย่างอื่นอีกมากมาย จนตอนนี้โมเดลส่วนใหญ่ถูกฝึกมาโดยคำนึงถึง tool call/function calling อยู่แล้ว สิ่งที่น่าสนใจตอนนี้คือมันเก่งขึ้นแค่ไหน ความสามารถด้านการค้นหาที่ยอดเยี่ยมของ o3/o4-mini ก็มีรากฐานจากความสามารถในการ tool call เช่นกัน แม้แต่ Qwen3 4B (Ollama 2.6GB, รันบน Mac ได้สบาย) ก็ทำสิ่งนี้ได้ดี เมื่อวานผมจัดเวิร์กช็อปเรื่องการสร้างซอฟต์แวร์ด้วย LLM ที่ PyCon US และจากจุดนั้นก็เลยเพิ่มฟีเจอร์การใช้เครื่องมือเข้าไปในเครื่องมือ command-line สำหรับ LLM ของผม ดูได้ที่ https://building-with-llms-pycon-2025.readthedocs.io/en/latest/tools.html ตอนนี้ผมสามารถใช้แพ็กเกจ LLM ของตัวเองจัดการงานอย่าง “นับว่าในคำว่า strawberry มีตัว R กี่ตัว” ได้อย่างเสถียรผ่าน shell one-liner
  • ผมชอบการผสมกันอย่างแปลกประหลาดระหว่างความสนุกกับความทรงพลังที่ฟีเจอร์นี้มอบให้
  • เวิร์กช็อปนี้มีการบันทึกวิดีโอไว้ไหม
• ผมสงสัยว่า agent ตัวไหนใช้โทเคนมากที่สุด cline ดูเหมือนจะอยู่แถวบน ๆ ของรายการ ส่วน roo น่าจะใช้น้อยกว่า cline อยากรู้ว่ามี agent ที่ให้เราตั้งค่ารูปแบบการโต้ตอบเองได้ไหม และ Claude code เป็นอย่างไรเมื่อเทียบกับ agent ตัวอื่น
• จุดที่น่ากลัวคือ “ถ้าไม่มีเครื่องมือที่ต้องใช้ มันก็จะติดตั้งให้” LLM มีความ “เชื่อฟัง” มากเกินไป และพร้อมจะรันทันทีถ้ามีใครสั่ง นี่เป็นความกังวลด้านความปลอดภัยที่ร้ายแรงกว่า SQL injection เสียอีก
  • บางครั้งผมก็สงสัยว่าเมื่อไหร่หายนะตัวแรกจาก agent-based system จะเกิดขึ้น (โดยเฉพาะในบรรยากาศตลาด AI ที่เร่งกันออกของแบบนี้) ผมกังวลว่าเมื่อเวลาผ่านไปจะต้องมีหายนะที่ย้อนกลับไม่ได้เกิดขึ้นอย่างแน่นอน
• เหมือนชื่อเรื่องจะอ้างอิงจากบทความของ Eugene Wigner ชื่อ "The Unreasonable Effectiveness of Mathematics in the Natural Sciences"
  • บทความนั้นอาจเป็นต้นฉบับก็จริง แต่ผมคิดว่ามันกลายเป็นสำนวนเชิงมีมมานานแล้ว https://scholar.google.com/scholar?q=unreasonable+effectiveness
  • สำหรับผมกลับคิดว่าชื่อเรื่องน่าจะยืมมาจากงานของ Karpathy ปี 2015 เรื่อง "Unreasonable Effectiveness of RNNs" มากกว่า แน่นอนว่า Karpathy เองก็คงหยิบยืมมาจากงานของ Wigner อีกทอดหนึ่งเหมือนกัน https://karpathy.github.io/2015/05/21/rnn-effectiveness/
  • ทุกครั้งที่เห็นพาดหัวที่มีคำว่า “unreasonable effectiveness” ผมมักจะไม่ค่อยเห็นด้วยกับข้อสรุปของผู้เขียนอย่างแรงเสมอ แม้แต่ในบทความของ Wigner เองก็ตาม ตอนนี้มันให้ความรู้สึกคล้ายกฎของ Betteridge ไปแล้ว
• เราสร้างเครื่องมือเพื่อให้ embedded ai chatbot ในผลิตภัณฑ์ของเรามีคอนเท็กซ์มากขึ้น ทั้งล็อกกิจกรรมล่าสุด นิยามของอ็อบเจ็กต์ปัจจุบัน การค้นหาและการท่องบทความช่วยเหลือต่าง ๆ ผ่านมาหลายเดือนแล้ว คุณภาพของแชตบอตก็ยังทำให้ประหลาดใจอยู่เสมอ ถ้าแชตบอตตอบอะไรผิด เราก็จะอัปเดตบทความช่วยเหลือที่เกี่ยวข้องให้เฉพาะเจาะจงยิ่งขึ้นเป็นกระบวนการต่อไป