คำแนะนำสำหรับการเขียนโค้ดแบบ Agentic

• แชร์กรณีการใช้งานจริงของ Agentic coding
• ใช้ Claude Code Sonnet model เป็นหลัก และชอบแนวทางมอบหมายงานทั้งก้อนให้ AI มากกว่าการผสานกับ IDE
• ภาษา Go แนะนำเป็นพิเศษสำหรับโปรเจกต์แบ็กเอนด์ใหม่ เพราะมีโครงสร้างที่เป็นมิตรกับเอเจนต์และระบบนิเวศที่เสถียร
• ความเร็วและความเรียบง่าย คือหัวใจของการเขียนโค้ดแบบ agentic โดย test cache และชุดเครื่องมือที่เรียบง่ายมีความสำคัญ
• ควรจัดโครงสร้างโค้ดให้เรียบง่ายและทำงานแบบขนานได้ และการเลือกจังหวะรีแฟกเตอร์มีความสำคัญมากหากต้องการดึงประสิทธิภาพของเอเจนต์ออกมาให้สูงสุด

---

Preface

• ช่วงหลังมานี้มีนักพัฒนาที่แชร์ประสบการณ์การเขียนโค้ดแบบ agentic เพิ่มขึ้นอย่างมาก
• ปัจจุบันฉันใช้ Claude Code Sonnet model ในแพ็กเกจ Max ($100/เดือน)
• บทบาทของ IDE ลดลง และกลับไปใช้ Vim แทน โดยใช้เวิร์กโฟลว์แบบมอบงานให้ Claude แล้วค่อยตรวจผลลัพธ์
• ความเร็วของนวัตกรรมสูงมากจนเนื้อหาในโพสต์อาจล้าสมัยได้อย่างรวดเร็ว จึงเน้นไปที่แนวคิดที่น่าจะใช้ได้นาน

The Basics

• ตั้ง alias ให้คำสั่ง claude --dangerously-skip-permissions เป็น claude-yolo เพื่อ ยกเลิกข้อจำกัดสิทธิ์ทั้งหมด
  • ทำได้เพราะสามารถแยกและจัดการสภาพแวดล้อม dev อย่างปลอดภัยด้วย Docker
• Claude ใช้เครื่องมือพื้นฐานส่วนใหญ่ได้ดีอยู่แล้ว ดังนั้นจึงใช้ MCP(Multi Capability Protocol) เฉพาะในกรณีพิเศษเท่านั้น
  • ตัวอย่าง: browser automation ผ่าน playwright-mcp
• เครื่องมือที่ทำเองจะทำเป็นสคริปต์ทั่วไป และพยายาม คงโครงสร้างเครื่องมือให้เรียบง่ายที่สุด

Choice Of Language

• จากการทดลอง agentic coding กับหลายภาษา พบว่า Go เหมาะที่สุดสำหรับโปรเจกต์แบ็กเอนด์ใหม่
  • ระบบ Context: ให้โครงสร้างข้อมูลที่ไหลผ่านทั้งโค้ดอย่างชัดเจน ทำให้ส่งผ่านข้อมูลแบบ explicit ให้เอเจนต์ได้ง่าย
  • test cache: เมื่อเทียบกับภาษาอื่นอย่าง Rust การรันทดสอบและ cache ทำได้ง่ายกว่า ทำให้วงจร code-test ของเอเจนต์มีประสิทธิภาพ
  • ความเรียบง่าย: ความเรียบง่ายของ Go เองก็ส่งผลดีต่อเอเจนต์ด้วย
  • structural interface: ถ้า type มีเมธอดตรงตามเงื่อนไขก็ถือเป็น interface ได้ ทำให้ LLM จัดการได้ง่าย
  • อัตราการเปลี่ยนแปลงของ ecosystem ต่ำ: เวอร์ชันอยู่ได้นานและการเปลี่ยนแปลงชัดเจน ช่วยลดการสร้างโค้ดล้าสมัยโดยอัตโนมัติ
• Python ก่อปัญหาหลายอย่าง
  • เรื่อง fixture, การจัดการ async และความช้าในการรัน ทำให้ประสิทธิภาพใน agentic loop ลดลง
• ฝั่งฟรอนต์เอนด์คือ Tailwind + React + Tanstack Query/Router + Vite
  • สัญลักษณ์ $ ในชื่อไฟล์ของ Tanstack Router ทำให้เอเจนต์สับสนและเกิดปัญหาได้

Tools, Tools, Tools

• เกณฑ์ในการเลือกเครื่องมือมีดังนี้
  • ต้องเร็ว
  • มีข้อความ error ที่เป็นมิตร
  • ต้องทำงานได้อย่างเสถียรแม้ LLM จะใช้งานผิดวิธี
  • สังเกตการณ์และดีบักได้ง่าย
• ใช้ Makefile เป็นฐานและมีคำสั่งอย่าง make dev, make tail-log เป็นต้น
  • ใช้ shoreman เวอร์ชันฟอร์กเพื่อจัดการ pid ป้องกันสถานะการรันซ้ำซ้อน
  • บันทึก log ทั้งลง stdout และไฟล์ เพื่อให้ เอเจนต์ดึงข้อมูลจาก log ได้โดยตรง
• ตัวอย่างเช่น ตั้งค่าให้ลิงก์ยืนยันอีเมลถูกบันทึกลง log ด้วย เพื่อให้ ทำขั้นตอนยืนยันอีเมลผ่าน browser automation ได้

It's All About Speed

• ความไม่มีประสิทธิภาพสูงสุดของ agentic coding มาจากต้นทุนการอนุมานและการใช้เครื่องมืออย่างไม่มีประสิทธิภาพ
• ความเร็วในการตอบสนองของเครื่องมือ คือหัวใจของผลิตภาพ
• หากเอเจนต์สร้างและใช้เครื่องมือชั่วคราวด้วยตัวเอง ความเร็วในการรัน/คอมไพล์ที่สูงจะช่วยเพิ่มประสิทธิภาพการทำงานอย่างมาก
• ในสภาพแวดล้อมที่ช้า การใช้ทางเลือกอย่าง dynamic module loading (เช่น การเฝ้าดู file module สำหรับ Sentry และรันอัตโนมัติ) จะได้เปรียบ
• ควรปรับ log ให้กระชับและชัดเจน เพื่อเพิ่มประสิทธิภาพด้านความเร็วและการใช้โทเค็น และหากจำเป็น การมีอินเทอร์เฟซให้ LLM ปรับระดับ log ได้เองก็มีประโยชน์
• การออกแบบให้มี log/observability ที่มีความหมายตั้งแต่ขั้นสร้างโค้ดเป็นสิ่งสำคัญ

Stability and Copy/Paste

• ความเสถียรของ ecosystem สำคัญมากต่อ การนำโค้ดกลับมาใช้ซ้ำและการลดความสับสนของเอเจนต์
  • แนะนำให้ใช้ภาษา/เฟรมเวิร์กที่เปลี่ยนแปลงน้อยและคาดเดาได้ เช่น Go และ Flask
• ระวังการอัปเกรดไลบรารีอัตโนมัติ เพราะอาจทำให้คอมเมนต์หรือโฟลว์โค้ดที่เอเจนต์ทิ้งไว้เสียหาย
• ถ้าเป็นไปได้ แนะนำกลยุทธ์แบบ เขียนโค้ดเองโดยตรง → ลด dependency ให้น้อยที่สุด

Write Simple Code

• เอเจนต์รับมือกับ โค้ดที่เรียบง่ายและชัดเจน ได้ดีกว่า
• แนวทางที่แนะนำ
  • ชอบใช้ฟังก์ชันที่มี ชื่อยาวและอธิบายชัดเจน และเขียนแบบเน้นฟังก์ชันมากกว่าคลาส
  • หลีกเลี่ยง inheritance และเทคนิคที่ซับซ้อน
  • แนะนำให้ใช้ SQL ตรงๆ เพราะเอเจนต์เก่ง SQL และเปรียบเทียบกับ log รวมถึงติดตามได้ง่าย
  • การตรวจสอบสิทธิ์ที่ชัดเจน ควรจัดให้เห็นได้ตรงไปตรงมาในโค้ด (ไม่แยกไปไว้ในไฟล์/คอนฟิกอื่น)

Make It Parallelizable

• ความเร็วของเอเจนต์แต่ละตัวไม่ได้สูงมาก แต่สามารถเพิ่มประสิทธิภาพโดยรวมได้ด้วย การประมวลผลแบบขนาน
  • ตัวอย่าง: คัดลอก checkout โดยอิงจาก file system
  • ต้องคิดวิธีแยกทรัพยากรร่วมอย่าง Redis หรือ DB
  • เครื่องมือตัวอย่าง: แยกเซสชันบน Docker ด้วย container-use
• งานแบบขนานบนฐาน CI และเครื่องมืออย่าง background agent ของ Cursor ก็เป็นสิ่งที่น่าจับตามอง

Learn To Refactor

• ในแนวทาง agentic นั้น การรีแฟกเตอร์ในจังหวะที่เหมาะสม สำคัญมาก
  • เมื่อความซับซ้อนสูงขึ้น เอเจนต์จะเริ่มจัดการโค้ดได้ไม่ดี
  • ตัวอย่าง: ก่อนที่คลาส Tailwind จะกระจายไปทั่ว 50 ไฟล์ ควร แยกเป็น component library เสียก่อน
• การรีแฟกเตอร์เร็วเกินไปหรือช้าเกินไปล้วนไม่มีประสิทธิภาพ จึงต้องสั่งปรับโครงสร้างในจังหวะที่เหมาะสม

What Next?

• agentic coding กำลังพัฒนาอย่างรวดเร็ว และ หลักการสำคัญคือ ‘ความเรียบง่าย ความเสถียร การมองเห็นได้ และความขนาน’
  • ต่อให้เครื่องมือและวิธีวิทยาจะเปลี่ยนไป หลักการเหล่านี้ก็ยังใช้ได้
• เป้าหมายไม่ใช่แค่ เพิ่มผลิตภาพ แต่รวมถึงการมุ่งสู่คุณภาพโค้ดที่ดีกว่า
• คุณภาพของโค้ดที่เอเจนต์เขียนดีขึ้นอย่างชัดเจนเมื่อเทียบกับไม่กี่เดือนก่อน
• ปรับตัวต่อการเปลี่ยนแปลงอย่างยืดหยุ่น และขยายประสบการณ์การเขียนโค้ดต่อไป

[helloppfm]

ตอนนี้ผมเองก็ยังใช้ AI แค่ถามเรื่องโค้ดทดสอบง่ายๆ หรือขอตัวอย่างโค้ดอยู่เลย แต่ตอนนี้ก็เริ่มมีคนที่พยายามนำไปใช้ในภาพรวมกันมากขึ้นเรื่อยๆ

แม้อาจจะยังเร็วเกินไปอยู่บ้าง แต่พอผ่านไปอีกไม่กี่ปีมันก็คงกลายเป็นเรื่องปกติแน่นอน

[GN⁺]

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

• ฉันกำลังใช้ co-pilot กับ Claude Sonnet 4 ร่วมกันบน VS Code Nightlys เพื่อทำงานแบบ Agentic Coding อยู่ แม้ว่าครึ่งวันจะหมดไปกับการประชุม แต่ถ้าดูแค่ git history ก็คงไม่รู้เลย เพราะรู้สึกได้ว่าผลิตภาพดีขึ้นมาก ตอนนี้ฉันแทบไม่ได้จมอยู่กับรายละเอียดการลงมือเขียนอีกต่อไป แต่คิดแทนว่า การเปลี่ยนแปลงนี้ทำงานถูกต้องไหม เราเข้าใจโค้ดนี้ได้ไหม ควรวางโครงสร้างยังไงให้เข้าใจได้ดีกว่าเดิม และควรเพิ่มอะไรใน AI convention markdown เพื่อลดความเข้าใจผิดของ Agent บ้าง เมื่อคืนฉันโยนไฟล์ที่มี mypy error ถึง 38 จุดให้ Agent จัดการ แล้วไปคุยกับครอบครัว 15 นาที พอกลับมา Agent ก็สรุปให้ว่ามันแก้อะไรไปบ้างและเพราะอะไร เราถกกันเรื่องหนึ่งในรายการที่เปลี่ยน แต่สุดท้ายฉันเห็นว่าความเห็นของ Agent ถูกต้อง และ mypy check ก็ผ่านด้วย ตอนนี้ฉันพยายามทำให้ทีมเข้าใจศักยภาพที่แท้จริงของเทคโนโลยีนี้เช่นกัน แม้จะยังมีคนมองด้วยความสงสัยและคัดค้านเพราะ AI ยังไม่สมบูรณ์แบบก็ตาม แต่ถ้ายืมคำเพื่อนมาพูดว่า "วันนี้คือวันที่แย่ที่สุดที่คุณและเทคโนโลยีนี้จะได้เจอจากนี้ไป" ฉันคิดว่านั่นแหละคือหลักฐานของนวัตกรรม

  • error ของ type checker จริง ๆ แล้วควรเป็นส่วนที่ใช้เวลาในงานพัฒนาน้อยที่สุด เลยสงสัยว่าทำไมมันถึงกินเวลานานขนาดนั้น ผมคิดว่าถ้าการพูดคุยเรื่องการใช้ AI ทั้งหมดเปิดให้เห็นกันชัด ๆ ว่าแต่ละคนใช้มันกับงานอะไรจริงบ้าง (เหมือนโพสต์ของ cloudflare) ผลลัพธ์น่าจะดีกว่านี้มาก

  • ส่วนตัวผมเชื่อมือ Agent กับโค้ด Rust มากกว่า Python เพราะ Python ยังมีการวิเคราะห์แบบ static ที่ไม่ดีเท่า clippy หรือ rust-analyzer เลยต้องไล่รันทุก code path ด้วยตัวเองทุกครั้ง

  • ที่บอกว่าถึงจะประชุมครึ่งวัน แต่ดูจาก git history แล้วไม่รู้เลย ถ้าผมเป็นนายจ้างของคุณ ผมคงคาดหวังผลงานระดับนี้ต่อไปในไม่ช้าเหมือนกัน

  • อยากรู้ workflow ครับ ผมกำลังใช้ Claude Code ทดลองกับโปรเจกต์ส่วนตัว และก็เคยใช้ Copilot ด้วยบัญชีบริษัทใน agent mode ของ VS Code โดยผสมทั้ง 3.5, 3.7 Sonnet และ 04-mini ใช้กับโปรเจกต์ Go ขนาดใหญ่ แต่ผลลัพธ์แย่มาก ยกเว้นฝั่งเทสต์ เลยสงสัยว่าผมใช้เครื่องมือผิดหรือเปล่า จนลอง "best practice ล่าสุด" หมดแล้ว ทั้งเปลี่ยน context, เปลี่ยนโมเดล, กำหนดกฎ, ปรับ prompt ก็ยังไม่ดีขึ้นเลย

  • ที่คุณพูดถึงการเพิ่มเนื้อหาใน AI convention markdown เพื่อลดความผิดพลาดของ Agent นั้น อยากรู้ว่ามันคือไฟล์ที่แนบเป็น context ทุกงานหรือเป็น convention อย่างเป็นทางการของ VS Code Copilot Agent แล้วก็อยากถามด้วยว่าคุณมีแหล่งอ้างอิงในการจัดโครงสร้างเอกสารไหม หรือเป็นผลลัพธ์ที่คุณค่อย ๆ ปรับปรุงเองตามความผิดพลาดซ้ำ ๆ ของ AI

• เป็นเรื่องที่น่าตื่นเต้นมากที่เทคนิคส่วนใหญ่ซึ่งทำให้ agentic coding มีประสิทธิภาพ กลับช่วยเพิ่มประสิทธิภาพการเขียนโค้ดของมนุษย์ด้วย เมื่อก่อนมีความกังวลว่าเราจะได้โค้ดแบบ 'ก้อนโคลนยักษ์' ที่มีแต่ AI เท่านั้นที่เข้าใจ แต่ความจริงกลับตรงกันข้าม โค้ดที่ชัดเจนกลับยิ่งสำคัญต่อผลิตภาพของ AI มากขึ้น และทำให้ความต่างด้านผลิตภาพวัดออกมาเป็นตัวเลขได้ชัดเจน เราสามารถชี้ให้เห็นเป็นตัวเลขได้ว่า Claude ทำงานกับ codebase ไหนได้ดีแค่ไหน ดังนั้นการถกเถียงว่าโค้ดมีโครงสร้างดีหรือไม่ จึงไม่ใช่แค่เรื่องความเห็นอีกต่อไป แต่คุยกันบนหลักฐานที่เป็นรูปธรรมได้

  • ความกังวลว่าโค้ดจะกลายเป็น 'ก้อนโคลน' นี่จริง ๆ เป็นเรื่องที่วงการโปรแกรมมิ่งกังวลกันมาตลอดอยู่แล้ว (ลองดูบรรยายของ Rich Hickey) ผู้คนมักเลือกทางที่ "สบายตอนนี้" แล้วไปแบก technical debt มหาศาลในวันหน้า LLM ยิ่งทำให้การผลิต boilerplate แบบไร้ความหมายง่ายขึ้นอีก และเมื่อความเจ็บปวดลดลง ก็อาจทำให้คนหมดแรงจูงใจที่จะกลับไปแก้ให้ถูกต้องจริง ๆ

  • ผมอยากทิ้งข้อสังเกตไว้ด้วยว่า "ความกังวลว่าโค้ดจะมีแต่ AI เข้าใจ แม้ตอนนี้จะยังไม่ใช่ แต่อนาคตจะเป็นอย่างไรก็ไม่มีใครรู้"

  • เห็นด้วยกับจุดนี้มาก ทั้ง error message ที่ดี เครื่องมือที่เร็ว ecosystem ที่เสถียร โค้ดที่เรียบง่ายและไม่มี 'magic' รวมถึง SQL ที่เข้าใจง่าย นี่คือสภาพแวดล้อมการพัฒนาที่ผมฝันไว้แต่แรกอยู่แล้ว พอ agent ทำงานเร็วมาก ความหน่วงเล็ก ๆ น้อย ๆ ก็รู้สึกได้ทันที ผมเลยคิดว่าเทคโนโลยีแบบนี้จะช่วยยกระดับประสบการณ์การพัฒนาโดยรวมได้

• เคยได้ยินว่าพอใช้ Agent ไปเรื่อย ๆ มันจะพาเราไหลไปหา Go กับ Tailwind แบบธรรมชาติ เพราะ AI จัดการกับสิ่งเหล่านี้ได้ดีจากข้อมูลฝึกที่มีเยอะ ถ้าอย่างนั้นในอนาคตที่ทุกคนใช้เครื่องมือแบบนี้กันหมด มันจะทำให้ภาษาใหม่ framework ใหม่ หรือไลบรารีใหม่เกิดได้ยากขึ้นหรือเปล่า ก็เลยกังวลว่าโซลูชันใหม่จะสู้ของเดิมได้ยากขึ้น และชุมชนมนุษย์อย่าง StackOverflow ก็อาจหายไป

  • ผมไม่เห็นด้วยกับความกังวลว่าจะไม่มีภาษาใหม่หรือ framework ใหม่เกิดขึ้นเลย LLM เก่งเรื่องการแปลมาก ต่อให้ไม่มีข้อมูลฝึก มันก็สามารถดูจาก codebase แล้วเรียนรู้ framework ที่มีลักษณะเฉพาะแต่โครงสร้างชัดเจนได้ทันที ผมเคยเห็นกับ framework C# แบบเฉพาะทางของตัวเองที่ไม่มีใครเคยเห็นมาก่อน ซึ่ง LLM ก็จัดการได้ดีมาก แน่นอนว่าคุณลักษณะเฉพาะอย่าง lifetime ของ Rust อาจไม่เข้ากันได้ทันที แต่ของที่เรียบง่ายแบบ Go มันปรับตัวได้เร็ว อนาคตเราอาจต้องออกแบบภาษาใหม่โดยคำนึงถึงความเข้ากันได้กับ LLM ตั้งแต่แรก ทั้งด้านการออกแบบ tooling และเอกสาร

  • นี่เป็นคำถามที่สำคัญมาก พูดอีกแบบคือเมื่ออินเทอร์เน็ตถูกท่วมด้วยข้อมูลที่ LLM สร้างขึ้น คุณภาพของข้อมูลฝึกก็จะลดลง และนักพัฒนาที่เป็นมิตรกับ LLM อาจหันไปหาเทคโนโลยีเก่า ๆ ที่ "ปนเปื้อนกัมมันตรังสีน้อยกว่า" อย่าง JS/React มากขึ้น ในอนาคต JavaScript/React อาจกลายเป็น COBOL แห่งยุคใหม่ แต่ไม่ต้องใช้ที่ปรึกษาราคาแพงอีก เพราะ LLM จะดูแลงานบำรุงรักษาได้หมด ถ้าอยากหลีกหนีกระแส AI การพัฒนาภาษาใหม่ โดยเฉพาะภาษาประหลาดอย่าง Lisp+DSL ที่ LLM เรียนรู้ไม่ได้ทันที อาจยังค่อนข้างปลอดภัยไปจนกว่าจะถึงยุค AGI

  • วงจรดั้งเดิมของ software stack มีประมาณนี้: (1) stack เดิมขยายตัวจนรองรับ niche ทุกอย่างและซับซ้อนขึ้น ผู้เชี่ยวชาญก็เริ่มสร้าง 'atotecture' ที่เกินจำเป็นเต็มไปหมด (2) จากนั้นจะมี stack ใหม่ที่ง่ายกว่า ชัดเจนกว่า และแก้ปัญหาเทรนด์ใหม่ได้ดีกว่าออกมาจนได้รับความนิยม (3) พอเวลาผ่านไป stack ใหม่นี้ก็หนักขึ้นด้วยปัญหาเดิม แล้ววงจรก็วนซ้ำ ผมคิดว่า AI coding ก็คงไม่ทำให้วงจรนี้แตกง่าย ๆ เพราะขีดความสามารถด้าน context กำลังขยายตัวเร็วมาก

  • ข้ออ้างว่า Go กับ Tailwind ถูกบังคับใช้นั้น จริง ๆ แล้วสะท้อนรสนิยมส่วนตัวของผู้เขียนค่อนข้างมาก Sonnet มีปัญหากับ cargo test CLI ไม่ได้แปลว่า Rust, cargo หรือ AI ทั้งหมดมีปัญหา ในการทดสอบ PHP จริง ๆ Junie ก็ใช้ built-in runner ได้ไม่ค่อยดีเหมือนกัน แต่ถ้าสร้างสคริปต์ bin/test-php ให้ มันก็ใช้งานได้ดีเอง การเขียน requirement ไว้ใน guideline แบบชัดเจนช่วยได้จริง แต่ความต่างคือมันชอบยึดเครื่องมือที่มีมาให้ตั้งต้น ส่วนเรื่องประสบการณ์กับ Stack Overflow นั้น ผู้ช่วย AI ของผมมีข้อดีคือไม่ปิดคำถามซ้ำ ความพยายามคัดกรองของ SO มีประโยชน์ แต่ก็เป็นความจริงที่มันผลักผู้ใช้ออกไปจำนวนมากเช่นกัน

  • เมื่อวานผมก็เพิ่งให้ Claude (ผ่าน Zed) สร้างโปรเจกต์ใหม่ด้วย elixir phoenix จากเงื่อนไขล้วน ๆ และมันก็ทำได้ไม่มีปัญหา ใช้ tailwind สำหรับ CSS แต่ผมคิดว่านั่นเพราะ phoenix ตั้งค่าเริ่มต้นมาแบบนั้นอยู่แล้ว ผมไม่ค่อยเห็นด้วยกับคำกล่าวว่า AI ชอบพาไปทาง Go ตรงกันข้าม เวลาถามแบบไม่มีบริบท มันกลับเสนอฝั่ง Python รัว ๆ และแม้แต่ elixir ที่ชุมชนเล็กกว่า ก็ยังใช้งานได้ดีไม่มีปัญหา

• ผมลองใช้ Claude Code Sonnet 4.0 กับโค้ด Rust มาประมาณสัปดาห์หนึ่งแล้ว แต่ต่ำกว่าที่คาดไว้มาก (แถมใช้ผ่าน Bedrock เลยแพงด้วย) มันใช้เวลาวางแผนตอนต้นนานมาก แต่สุดท้ายก็มักทำเสร็จแค่ครึ่งเดียว เลยสงสัยว่าผมพลาดอะไรไปหรือเปล่า

  • ผมก็รู้สึกแทบเหมือนกันหมด ใน Cursor โหมด Edit/Agent มันมักแก้ได้ตรงที่อยากได้ในรอบเดียวจนมีประสิทธิภาพมาก แต่พออยู่ในสภาพแวดล้อม CLI กลับใช้งานยากมาก เลยอยากรู้ว่าคุณใช้ Claude Code แบบโยนงานให้ทำ 10~15 นาทีแล้วค่อยมาดู diff อย่างเดียวหรือเปล่า หรือยังทำ code review อย่างจริงจังอยู่

  • ผมเจอเหมือนกันทุกอย่างเป๊ะ ๆ เลย ถึงขั้นพยายามออกตามหา use case ที่น่าจะใช้ได้ก็ยังทำงานไม่ดี เลยงงมากจริง ๆ

  • ไม่ควรรู้สึกว่ามันแพงนะ Pro plan ราคา 20 ดอลลาร์ต่อเดือน ส่วน Max อยู่ที่ 100~200 ดอลลาร์ ซึ่งก็ยังถูกกว่าการใช้ผ่าน API ที่อาจเกิน 1,000 ดอลลาร์ต่อเดือน

• ดีใจที่มีการพูดถึงการใช้ container อยู่พอสมควร ผมมีส่วนร่วมกับ dagger/container-use และในทีมก็มีทั้งอดีตสมาชิก Docker กับผู้ก่อตั้ง docker ด้วย ผมคิดว่าการรัน Agent แบบขนานจะเป็นจุดแตกหักสำคัญของความก้าวหน้าทางเทคนิคครั้งใหญ่ครั้งถัดไป (ถ้าเราทำให้มันใช้งานได้อย่างน่าเชื่อถือจริง) ระหว่างนี้เอง ถ้าคุณอยากทำอย่างอื่นไปพร้อมกับปล่อยให้ Agent ทำงาน หรือกังวลว่า Agent จะไปแตะส่วนที่ไม่เกี่ยว การทำสภาพแวดล้อมพัฒนาให้เป็น container จะมีประโยชน์มาก เทคโนโลยีด้านการใช้ container ยังอยู่ช่วงต้นมาก แต่กำลังพัฒนาเร็วมาก ตอนนี้โฟกัสหลักคือเสถียรภาพ การลด git conflict และการเพิ่มปฏิสัมพันธ์ระหว่างมนุษย์กับ Agent

• มุมมองของผมเรื่องการเลือกภาษาเป็นแบบนี้ 1) Java ครอบคลุมที่สุดเพราะ LLM มีทั้งขนาดข้อมูลอ้างอิงมหาศาลและชุดข้อมูลเก่าแก่ยาวนานให้ใช้ (ไม่ได้แปลว่าแม่นที่สุดเสมอไป) 2) ที่สำคัญที่สุดคือควรทำงานในภาษาที่ตัวเองรู้ดีที่สุด เพื่อให้จับความผิดพลาดอย่างการให้เหตุผลผิด error และ hallucination ของ LLM ได้เร็ว

  • ความเห็นที่ว่า Java เป็นชุดข้อมูลที่ใหญ่ เก่า และชัดเจนที่สุด ฟังดูเหมือนเป็นคำแนะนำที่ใช้ได้เฉพาะตอน LLM ไม่มีเครื่องมือไปค้นหา API, เอกสาร หรือซอร์สโค้ดจาก 3rd party มากกว่า ถ้าเครื่องมือช่วยมันหาได้อัตโนมัติว่าควรใช้อะไร ไม่ว่าคุณจะเลือกภาษาไหน สุดท้ายก็แค่ขอให้ Agent อ่านซอร์สได้ก็พอ แต่ผมเห็นด้วยเต็มที่กับข้อที่สองว่าควรใช้ภาษาที่เรารู้จักดี สุดท้ายแล้วการตรวจละเอียดโดยมนุษย์ยังจำเป็นอยู่ และถ้าเป็นภาษาที่เราคุ้นเคยก็จะตัดสินข้อผิดพลาดได้ง่ายกว่า

  • ทำไม Java ถึงถูกมองว่ามีชุดข้อมูลใหญ่ที่สุด? เป็นเพราะโปรเจกต์โอเพนซอร์สที่เป็น Java มีจำนวนมากที่สุดหรือเปล่า (เช่นทั้ง Apache suite) หรือเป็นเพราะเอกสารของไลบรารีโอเพนซอร์ส Java มีความสมบูรณ์มากเป็นพิเศษ

  • ผมกลับคิดมาตลอดว่าชุดข้อมูลที่มีโค้ด Python น่าจะมากที่สุด เวลาไม่ได้ระบุอะไรไว้ LLM ส่วนใหญ่ก็มักเริ่มแนะนำ Python ก่อน

• มีคำวิจารณ์ต่อข้ออ้างที่ว่า context system ของ Go (การส่งข้อมูลแบบชัดเจนตามเส้นทางการทำงานของโค้ด) ให้ความเรียบง่ายกับ AI agent ว่า "การใส่ข้อมูลอื่นนอกจาก tracing data ลงใน context.Context เป็นธรรมเนียมปฏิบัติที่ไม่ดีอยู่แล้ว"

  • เห็นด้วยครับ ใน chromedp (chrome headless driver สำหรับ Go) เขาใช้ context.Context เป็นอาร์กิวเมนต์ตัวแรก แต่โครงสร้างกลับบังคับให้ใช้ context ที่ได้จาก factory พิเศษเท่านั้น ไม่ใช่แค่ context.Background() ธรรมดา ส่วนการตั้ง timeout ค่อยทำแยกด้วย context.WithTimeout สุดท้ายมันเลยถูกใช้แทบเหมือนพอยน์เตอร์ void*

  • ผมไม่ถึงกับเป็นผู้เชี่ยวชาญ Go แต่ในทางปฏิบัติก็เห็นหลายไลบรารีใส่ข้อมูลอย่าง database connection, config, rate limiter หรือ cache backend ลงใน context กันเยอะ ดังนั้น ณ ตอนนี้ผมยังไม่รู้สึกว่ามันเป็นปัญหาขนาดนั้น

• การเขียน 'โค้ดที่เรียบง่ายพอให้ AI เข้าใจ' ไม่ใช่จุดแห่งนวัตกรรมที่ผมเคยหวังไว้ ผมเลยสงสัยว่ามันขัดกับแนวคิดในบทความเรื่อง ugly code ของผมก่อนหน้าอย่างไรบ้าง

  • วิธีเขียนโค้ดให้เรียบง่ายและชัดเจนแบบนี้ จริง ๆ แล้วแทบจะช่วยงานทีมเสมอ มีบางช่วงที่ต้องจดจ่อกับโค้ดอย่างหนักหรือเขียนอย่างสร้างสรรค์มากจริง ๆ แต่กรณีแบบนั้นเป็นข้อยกเว้นและควรเกี่ยวข้องกับคุณค่าทางธุรกิจอย่างใกล้ชิด โค้ดส่วนใหญ่ "ทางออกที่ใครเห็นก็ชัดอยู่แล้ว" นักพัฒนาไม่ได้ช้าเพราะพิมพ์ช้า แต่ช้าเพราะต้องแบก 'แนวคิด' ไว้ในหัวพร้อมกันมากเกินไป อย่า overengineer interface อย่ารีบทำ abstraction ปล่อยให้มีการคัดลอกวางและประกอบแบบง่าย ๆ ได้ pattern ก็ใช้ตามเอกสารทางการตรง ๆ และอย่าพยายามฉลาดเกินไป แก่นสำคัญคือโค้ดไม่ต้องสวย แต่ต้องชัดเจนและเรียบง่าย และสิ่งที่ยากจริง ๆ ไม่ใช่ตัวโค้ด แต่คือ 'ตัวผลิตภัณฑ์'

• อย่างที่ผู้เขียนบอกเกี่ยวกับ Claude Code ตอนนี้มีทางเลือกหลายแบบจริง ทั้ง OpenCode, goose, Codex, Devin, Cursor background agent ฯลฯ มีคนถามว่ามีโซลูชันโอเพนซอร์ส+local LLM ที่คล้าย Claude Code ไหม

  • ตอนนี้ยังไม่มีโซลูชันโอเพนซอร์ส+local LLM ที่ผมกล้าแนะนำแบบเต็มปากเต็มคำ แต่ OpenCode ของ SST กำลังพัฒนา UX อย่างรวดเร็ว และถ้าในอนาคตมี local model ที่ดีขึ้น ก็น่าจะเอามาใช้ได้ง่าย ปัญหาใหญ่สุดคือแทบไม่มีโมเดลดี ๆ ที่เก่งเรื่อง 'การใช้เครื่องมือ' จริง Sonnet ทำได้ดีจนน่าตกใจเพราะผ่านการฝึกเฉพาะด้านนี้มา Gemini ก็ยังห่างอยู่มาก และสุดท้ายผมคิดว่านี่เป็นปัญหาที่จะแก้ได้เองเมื่อมีโมเดลที่ดีพอออกมา

  • สำหรับ Aider มันเกือบถึงแล้ว แต่ตั้งใจไม่ทำให้เป็น agentic แบบเต็มตัว มันรันเทสต์อัตโนมัติ รัน static analysis อัตโนมัติ แก้ error อัตโนมัติได้ และยังจัดการสเปกทั้งโปรเจกต์แบบอิง to-do list ได้ด้วย ตอนนี้มีข้อจำกัดเป็นจำนวนรอบ reflection แบบฮาร์ดโค้ดไว้ที่ 3 รอบ แต่ถ้าจะแฮ็กก็เพิ่มได้ตามใจ และถ้าเติม self prompting เข้าไปก็แทบจะกลายเป็น agent อัตโนมัติเต็มรูปแบบได้เลย

  • แอปของผมที่กำลังจะเปิดตัวก็น่าจะเป็นทางเลือกที่ดีได้เช่นกัน ดาวน์โหลดไฟล์เดียว ไม่ต้องติดตั้ง ใช้ได้ทั้งบน Mac, Windows, Linux และ Docker รองรับทุกโมเดลที่เข้ากันได้กับ OpenAI API (รวมถึงที่รันเองโดยตรง) เป็นแบบ browser-based ใช้งานสะดวกไม่แพ้ Claude Code และยังทำเป็นแอปคอนโซลแบบสั่งคำสั่งได้ด้วย นอกจากนี้ยังเปิด terminal โดยตรงเพื่อเชื่อมกับบริการได้ ตอนนี้ยังอยู่ใน closed alpha แต่ถ้าอยากใช้ก็ส่งอีเมลมาได้

  • แทบทุกวันมีทางเลือกใหม่ (หรืออย่างน้อยก็มีคนพยายามทำ) ออกมาเรื่อย ๆ เลยคาดว่าอีกไม่นานก็คงมีตัวเลือกที่ 'พอดี' สำหรับแต่ละคน เช่น app.build ที่ทีม Neon (ตอนนี้คือ Databricks) เพิ่งเปิดตัว ดูมีแววทีเดียว

  • ปลั๊กอิน Neovim อย่าง CodeCompanion ก็พัฒนาไปทาง agentic มากขึ้นในช่วงหลัง ตอนนี้รองรับทั้ง auto-submit loop, เครื่องมือในตัว และการเชื่อม MCP แม้จะไม่ใช่เครื่องมือแยกแบบ CLI แต่ข้อดีคือใช้งานในสภาพแวดล้อม editor เต็มรูปแบบได้ทันที ซึ่งยิ่งดีถ้าคุณชอบแนวแฮ็ก ปรับแต่งเอง หรือใช้ editor น้ำหนักเบา

• เดือนละ 100~200 ดอลลาร์แพงเกินไปสำหรับ AI เขียนโค้ดที่ยังไม่พิสูจน์ตัวเอง จากประสบการณ์ส่วนตัวก็ยังไม่ค่อยน่าพอใจ แถมยังมีประเด็นด้านจริยธรรมอีก เลยยิ่งเป็นกำแพงในการเริ่มใช้งาน

  • Claude Code ใช้ผ่าน API key ก็ได้ หรือสมัคร Pro รายเดือน 20 ดอลลาร์ก็พอ

  • แนะนำให้ลอง Aider แบบคิดค่าบริการตาม API context size คุมได้ด้วย /clear, /add, /drop ให้จำกัดราว 25K ได้ ใช้โมเดลที่ต้องการเองได้ (เช่น Sonnet 4, Gemini 2.5 Pro) สคริปต์ง่าย ๆ ส่วนใหญ่ทำเสร็จได้ในราคาต่ำกว่า 1 ดอลลาร์ และตอนทำเครื่องมือขนาดใหญ่มาก แม้รวม prompt + โค้ด + ทดสอบร่วมร้อยครั้งก็ยังต่ำกว่า 6 ดอลลาร์ได้ พอคุณชินกับการให้ AI เขียนโค้ดแล้ว ค่อยขยับไป Claude Code ซึ่งแรงกว่าแต่ถ้าไม่ได้ใช้บ่อยก็อาจกลับกลายเป็นแพงกว่า

  • ถ้าจ่ายค่าสมาชิกเดือนละ 20 ดอลลาร์ ก็เพียงพอจะลองกับโปรเจกต์เล็ก ๆ สักสองสามตัว แล้วค่อยตัดสินว่าควรขยับไปแผน 100 ดอลลาร์ไหม หรือจะรออีกสักไม่กี่เดือน ดูรีวิวจากคนที่ใช้งานจริงของคนอื่นไปก่อนก็ได้