ในยุคที่ AI Agent สำหรับช่วยเขียนโค้ดกำลังผุดขึ้นมาเป็นดอกเห็ด หลายคนอาจจะยังสับสนว่าเราควรจะใช้งานมันยังไงให้มีประสิทธิภาพสูงสุด? 

ล่าสุด Armin Ronacher (โปรแกรมเมอร์ระดับตำนาน ผู้สร้าง Flask, Jinja, และอีกหลายโปรเจคท์) ได้ออกมาแชร์ประสบการณ์และคำแนะนำส่วนตัวของเขาในการทำงานกับ AI Agent ผ่านบล็อกล่าสุดในหัวข้อ Agentic Coding Recommendations ซึ่งเต็มไปด้วยเทคนิคและแนวคิดที่น่าสนใจมาก ๆ ครับ

Armin บอกว่าวงการนี้เปลี่ยนแปลงเร็วมาก สิ่งที่เขาเขียนวันนี้ อีกเดือนเดียวก็อาจจะล้าสมัยไปแล้ว แต่เขาก็จะพยายามเน้นไปที่หลักการ (Fundamentals) ที่น่าจะยังคงอยู่ไปอีกนานครับ

Workflow และเครื่องมือส่วนตัวของ Armin Ronacher

Armin เล่าว่าปัจจุบันเครื่องมือหลักที่แกใช้คือ Claude Code โดยเลือกใช้แพ็กเกจ Max ราคา $100/เดือน และที่น่าสนใจคือแกชอบใช้โมเดล Sonnet (ตัวที่ถูกกว่า) มากกว่า Opus เพราะรู้สึกว่า output มันตรงใจเขากว่า

สไตล์การทำงานของเขาคือ Asynchronous คือจะมอบหมายงานหรือ "job" ให้ Agent ไปทำ แล้วปล่อยให้มันทำงานเบื้องหลัง (background task) ไปเลย แกจะไม่ค่อยเข้าไปขัดจังหวะมัน ยกเว้นจะเป็นงานเล็ก ๆ 

ซึ่งนี่ก็ทำให้บทบาทของ IDE (แกใช้ Vim) จะลดลงไปเหลือแค่การเข้ามาแก้ไขโค้ดในขั้นตอนสุดท้ายเท่านั้น


การตั้งค่าพื้นฐาน (The Basics)

ในส่วน Permissions แกเลือกที่จะปิดการตรวจสอบ permission ทั้งหมด โดยตั้ง Alias claude-yolo (มาจาก claude --dangerously-skip-permissions) แกบอกว่ามันอาจจะดูเสี่ยง แต่ก็สามารถจัดการความเสี่ยงนั้นได้ด้วยการย้าย Dev Environment ไปรันใน Docker แทน

MCP (Model Context Protocol)

คุณ Armin แกบอกว่าใช้มันน้อยมาก เพราะ Claude Code สามารถรันเครื่องมือ Command Line ทั่วไป (เช่น psql) ได้ดีอยู่แล้ว แกจะใช้ MCP ก็ต่อเมื่อต้องให้ Agent ไปทำงานกับบางอย่างที่มันใช้งานเองตรง ๆ ได้ยาก เช่น การทำ Browser Automation ที่แกใช้ playwright-mcp


ภาษาอะไรที่เหมาะกับ Agent ที่สุด? (และทำไม Python ถึงไม่เวิร์คเท่าไหร่)

ประเด็นนี้เป็น insight ที่น่าสนใจมากครับ Armin บอกว่าถ้าเลือกได้ เขาขอแนะนำ Go อย่างยิ่ง สำหรับโปรเจคท์ Backend ใหม่ ๆ ที่จะทำงานกับ AI Agent ด้วยเหตุผลหลายข้อ

1. Context System ที่ชัดเจน

Go มี context package ที่ถูกส่งต่อไปในฟังก์ชันต่าง ๆ อย่างชัดเจน ทำให้ AI Agent เข้าใจได้ง่ายมากว่าจะต้องส่งผ่านข้อมูล Context ไปยังส่วนต่าง ๆ ของโค้ดได้อย่างไร

2. Test Caching ที่มีประสิทธิภาพ

go test ทำงานตรงไปตรงมาและมีระบบ Caching ที่ดี ทำให้ Agentic loop (วงจรการทำงานของ Agent ที่อาจจะต้องมีการเทสต์โค้ดซ้ำ ๆ) ทำงานได้อย่างรวดเร็ว ไม่ต้องมานั่งเดาว่าต้องรัน test ตัวไหน

3. Go มัน Sloppy (เรียบง่าย)

เขาอ้างถึงคำพูดของ Rob Pike (ผู้สร้าง Go) ที่บอกว่า Go เหมาะกับ Developer ที่อาจจะไม่พร้อมรับมือกับภาษาที่ซับซ้อน พอเราแทนคำว่า "Developer" ด้วย "Agent" มันก็เข้ากันพอดี ความเรียบง่ายของ Go คือข้อดีสำหรับ AI

4. Structural Interfaces

Interface ใน Go เป็นแบบ Structural (ถ้า Type ไหนมี Method ตรงตามที่ Interface คาดหวัง ก็ถือว่า Implement Interface นั้นแล้ว) ซึ่งมันง่ายมากสำหรับ LLM ที่จะเข้าใจและสร้างโค้ดให้สอดคล้องกัน

5. Ecosystem ที่เปลี่ยนแปลงช้า (Low Churn)

Go ให้ความสำคัญกับ Backwards Compatibility มาก ทำให้โอกาสที่ AI จะ Generate โค้ดที่ตกรุ่นมีน้อยมาก (ตรงข้ามกับ Ecosystem ของ JavaScript ที่เปลี่ยนแปลงเร็วสุด ๆ)

ในทางกลับกันคุณ Armin แกพบว่า Python (ซึ่งเป็นภาษาแรกที่ลองใช้) กลับสร้างความท้าทายให้ Agent มากกว่า ทั้งจาก Magic ของภาษา (เช่น Pytest fixture injection ที่ AI งง) ปัญหาด้าน Runtime ที่ซับซ้อน (เช่น การใช้ Event Loop ผิดตัวในงาน async) และที่สำคัญคือ Interpreter ของ Python มัน Boot ช้า ทำให้ Loop การทำงานของ Agent ที่ต้องมีการ spawn process เพื่อรัน test บ่อย ๆ ช้าลงอย่างมาก

ส่วน Frontend แกเลือกใช้ Tailwind, React (กับ Tanstack Query/Router), และ Vite ครับ แกบอกว่ายังไม่ค่อยแฮปปี้กับ File-based Router ของ Tanstack เท่าไหร่ เพราะมันชอบใช้เครื่องหมาย $ (ดอลล่าไซน์) ในชื่อไฟล์ ซึ่งมักจะทำให้ Agent สับสนกับ Shell Interpolation ได้


ปรัชญาการสร้าง Tool ให้ AI ใช้

Armin ย้ำว่า Tooling ที่ดีคือหัวใจสำคัญของการทำงานกับ Agent โดยมีหลักการคือ

อะไรก็เป็น Tool ได้

แค่ Agent สามารถโต้ตอบหรือสังเกตมันได้ (Shell script, MCP server, หรือแม้แต่ Log file)

Tool ต้องเร็ว ยิ่งตอบสนองเร็วและมี Output ที่ไร้ประโยชน์น้อยเท่าไหร่ยิ่งดี

Tool ต้อง User-friendly (สำหรับ AI) ต้องแจ้งข้อผิดพลาดหรือการใช้งานที่ผิดพลาดให้ Agent เข้าใจได้ เพื่อให้มันทำงานต่อไปได้

Tool ต้องทนทานต่อความผิดพลาดของ LLM ต้องป้องกันกรณีที่ AI เรียกใช้ Tool แบบมั่ว ๆ ได้

และ Tool ต้องมี... Observability ที่ดี

ตัวอย่าง

.

แกใช้ Makefile ในการจัดการโปรเจคท์ (เช่น make dev เพื่อรัน service) แต่เขาปรับปรุงมัน 2 อย่างคือ

1. ป้องกันการรันซ้ำซ้อน โดยปรับ Process Manager ให้เขียน pidfile เพื่อป้องกันไม่ให้ Agent เผลอรัน make dev ซ้ำในขณะที่ Server กำลังรันอยู่แล้ว

2. Log ทุกอย่างลงไฟล์ นอกจากจะแสดง Output บน Terminal แล้ว เขายังให้มันเขียน Log ลงไฟล์ด้วยเสมอ นี่คือจุดเปลี่ยน เพราะมันทำให้ Agent สามารถอ่าน Log file เพื่อวินิจฉัยปัญหาได้เอง เช่น ถ้า Server รันอยู่แล้ว Agent ก็จะไปอ่าน Log เพื่อหา URL ของ Frontend แล้วทำงานต่อได้เลย (ดูตัวอย่างในบทความต้นทางได้ครับ)


เคล็ดลับอื่น ๆ เพื่อรีดประสิทธิภาพ Agent (More Pro-Tips)

ให้ความสำคัญกับ Stability ของ Ecosystem อย่ารีบอัปเกรด Library บ่อยเกินไป เพราะ Agent อาจจะยังจำ Pattern เก่า ๆ อยู่ แล้วสร้างโค้ดที่ไม่เข้ากับเวอร์ชันใหม่ได้

ชอบ Code Generation มากกว่าการเพิ่ม Dependencies เขาเชื่อว่าการให้ AI ช่วย Generate โค้ดที่จำเป็นขึ้นมาเอง ดีกว่าการไปเพิ่ม Library ใหม่ ๆ เข้ามา

เขียนโค้ดให้ง่ายที่สุด ทำสิ่งที่โง่ที่สุดเท่าที่จะเป็นไปได้แต่ให้มันทำงานได้ (The dumbest possible thing that will work) คือแนวทางที่ดีสำหรับ Agent

ใช้ Plain SQL ไปเลย เขาบอกว่า Agent เก่งเรื่องการเขียน SQL ตรง ๆ มาก และมันสามารถเทียบเคียงกับ SQL log ได้ง่ายกว่าการไปพยายามใช้ ORM ที่ซับซ้อนแล้ว AI หลงทาง

ทำให้ Parallelizable

.

Agent แต่ละตัวอาจจะทำงานไม่เร็วมาก แต่ถ้าเราสามารถรันมันพร้อม ๆ กันหลาย ๆ ตัวได้ ประสิทธิภาพโดยรวมจะพุ่งกระฉูด

เรียนรู้ที่จะ Refactor ในจังหวะที่เหมาะสม

.

เมื่อโปรเจคท์เริ่มซับซ้อนเกินกว่าที่ Agent จะจัดการได้อย่างมีประสิทธิภาพ (เช่น มี class ของ Tailwind กระจายอยู่ 50 ไฟล์) ก็ถึงเวลาที่ต้องสั่งให้มัน Refactor สร้างเป็น Component Library

เรียกได้ว่าบทความจากท่านเทพ Armin Ronacher นี้เป็นเหมือนคู่มือชั้นดี สำหรับเพื่อน ๆ ชาว dev ที่ต้องการจะก้าวเข้าสู่โลกของ Agentic Coding อย่างแท้จริงเลยครับ

อ้างอิง