[Claude Code Meetup] การสร้างสภาพแวดล้อมที่ทำให้เอเจนต์และคนทำงานเก่งไปด้วยกันในโค้ดเบสแบบเลกาซี

(นี่คือเอกสารประกอบการบรรยายที่นำเสนอในงาน Claude Code Meetup Seoul เมื่อวันที่ 17 ธันวาคม ดูสไลด์ฉบับเต็มได้ที่ลิงก์นี้.)

---

เป้าหมายของ “internal consulting” ของทีม KORCA AX

• ทำให้แนวปฏิบัติด้าน agentic engineering ที่ดีฝังรากใน KORCA และสร้างฐานที่ทำให้พัฒนาต่อร่วมกันได้อย่างต่อเนื่อง
  • ที่ KORCA นิยาม “แนวปฏิบัติด้าน agentic engineering” ว่าเป็น “วิธีปฏิบัติในการใช้ AI agent เพื่อยกระดับทั้งคุณภาพและประสิทธิภาพการผลิตของซอฟต์แวร์”
• ทำให้ความสามารถด้านวิศวกรรมกลายเป็นอีกหนึ่งความได้เปรียบเชิงการแข่งขันหลักของ KORCA
• เพื่อสิ่งนี้ จึงเริ่มจากการเข้าไปช่วยทีม Moonlight

สถานการณ์ของ Moonlight

• Moonlight คือผลิตภัณฑ์หลักของ KORCA โดยวางตัวเป็น “เพื่อนร่วมงาน AI ที่อ่านงานวิจัยไปด้วยกัน”
• ฟีเจอร์ “คุยกับ PDF” เป็นไอเดียที่มีมาตั้งแต่ยุคแรกมากของ ChatGPT แต่ Moonlight ก็ยังอยู่รอดท่ามกลางผลิตภัณฑ์คู่แข่งจำนวนมาก และตอนนี้อยู่ในช่วงต้นของ J-curve แล้ว (ช่วงหลังจำนวนผู้สมัครจากจีนเพิ่มขึ้นอย่างรวดเร็ว)
• กว่าจะมาถึงจุดนี้มีการลองผิดลองถูกมากมาย แต่ความสามารถแข่งขันหลักคือการรักษาความเร็วและจังหวะของการพัฒนาฟีเจอร์ “ไม่ว่าอย่างไรก็ตาม”
• การตัดสินใจช่วงแรกบางอย่างเพื่อรักษาความเร็ว
  • typescript strict: false
  • ลดการทดสอบอัตโนมัติให้เหลือน้อยที่สุด
  • ยอมให้มีโค้ดซ้ำและ hardcoding
  • ไม่มีการแบ่งสายงานชัดเจน สมาชิกทีมแทบทั้งหมด (6 จาก 7 คน) ใช้ coding agent ลงมือทำและเปิด PR
• แต่เมื่อเริ่มเข้าที่เข้าทางแล้ว หนี้ทางเทคนิคก็เริ่มทำให้ลำบากขึ้นทีละน้อย
  • ผลิตภัณฑ์ซับซ้อนขึ้น มีสมาชิกใหม่ในทีมมากขึ้น และมีการทดลองหลายอย่างรันพร้อมกัน
  • ความเร็วในการปรับปรุงผลิตภัณฑ์เริ่มช้าลงทีละน้อย ขณะที่ความกังวลค่อยๆ เพิ่มขึ้น
  • ภาระการรีวิวโค้ดกระจุกอยู่กับคนไม่กี่คน และเริ่มมีความผิดพลาดทั้งเล็กและใหญ่เกิดขึ้น

โจทย์เร่งด่วนของทีม AX

• [ผลิตภัณฑ์] ทำให้คุณภาพของ Moonlight ดีขึ้น พร้อมกับเพิ่มความเร็วในการเพิ่มและปรับปรุงฟีเจอร์
• [ทีม] ทำให้ทุกคนแก้โค้ดของ Moonlight ได้ง่ายขึ้น และลดความเครียดหลัง deploy
• [วัฒนธรรม] เพื่อข้อ 1 และ 2 ให้ทีม Moonlight กับทีม AX ร่วมกันค้นหา นำไปใช้ ยกระดับ และค่อยๆ กระจายแนวปฏิบัติด้าน agentic engineering ที่ดีภายในบริษัท
  → มองว่า ถ้าทำให้ coding agent ให้คำตอบที่ดีขึ้นได้ ปัญหาส่วนใหญ่ก็จะถูกแก้ไปเอง

ถ้าอยากให้เอเจนต์ให้คำตอบได้ดีขึ้น?

[1] ทำให้เดินไปบนเส้นทางที่ดีตั้งแต่แรก

• ถ้าคุณภาพของ codebase สูง จะได้เปรียบใน 3 ด้าน
• ใส่ context ที่ไม่จำเป็นน้อยลง (Less is More)
• เอเจนต์จะเดินตาม pattern ที่ดีที่มีอยู่แล้ว
• สามารถโน้มนำให้มีโอกาสมากขึ้นที่คำตอบจะถูก sampled ออกมาจากบริบทของโค้ดคุณภาพสูงในข้อมูล pretraining
  • มีงานวิจัยมากมายที่ชี้ว่าเมื่อใส่ context คุณภาพสูง ก็จะได้คำตอบที่ดี
  • (ความเห็นส่วนตัว) ถ้าส่งคำขอให้เอเจนต์ใน codebase ที่จัดลำดับ import เป็นระเบียบแล้วล่ะ? โค้ดในชุด pretraining ที่จัดลำดับ import ไว้ก็น่าจะมีแนวโน้มเป็นโค้ดคุณภาพสูงโดยรวมไม่ใช่หรือ?
  • จาก Anthropic Blog: "เพียงแค่ทำให้มันใช้ฟอนต์ที่น่าสนใจขึ้น องค์ประกอบการออกแบบอื่นๆ ก็ดีขึ้นตามไปด้วย"

[2] ป้องกันไม่ให้หลงไปในเส้นทางที่ผิด

• สามารถใช้เครื่องมือ static analysis หลากหลายแบบเพื่อปิดกั้นเส้นทางที่ผิดได้ เช่น ตรวจ type error, ตรวจ linter error, automated test, ตรวจ dead code, ตรวจความยาวไฟล์, ตรวจ complexity, บังคับ dependency relation, บังคับสัดส่วน test code เทียบกับ production code เป็นต้น (ให้มันกลับไปทำใหม่จนกว่าจะผ่านเกณฑ์)

[3] ขอให้ทำในสิ่งที่มันถนัดเป็นหลัก

• สิ่งที่คนเก่ง สิ่งที่ LLM เก่ง และสิ่งที่อัลกอริทึมเก่งนั้นไม่เหมือนกัน ถ้าเลือกได้อย่างฉลาดว่าเมื่อไรควรใช้อะไร ก็จะประหยัดทั้งเวลาและต้นทุน
  • เช่น บอกว่าอย่าลืม i18n key เทียบกับ บอกให้ลองรันสคริปต์หา i18n key ที่ตกหล่น
• ใครเก่งอะไรเมื่อไรนั้นเปลี่ยนไปตามเวลา และขึ้นอยู่กับโดเมนของปัญหาด้วย ถ้าปลูกฝังนิสัยอัปเดต “เซนส์” นี้ให้ทันสมัยในโดเมนของตัวเองไว้ จะได้เปรียบ
  • เช่น ถ้ามีโมเดลใหม่ออกมา ก็ลองทดสอบด้วย benchmark ของตัวเอง หรือทำตามตัวอย่างดังในโซเชียลมีเดีย

[4] งานที่มันทำไม่ได้ ก็ช่วยมัน

• แต่ต้องคอยตรวจสอบเสมอว่ามัน “ทำไม่ได้จริง” หรือไม่ ถ้าไม่ใช่งานที่เสี่ยงเกินกว่าจะมอบหมาย หรือไม่มีประสิทธิภาพเกินไป ก็ควรให้ AI/อัลกอริทึมทำมากกว่าคน (เพราะสุดท้ายค่าโทเค็นก็คงถูกลงจนใกล้เคียงค่าไฟฟ้าอยู่แล้ว)
• ถ้าทำไม่ได้จริงล่ะ? ก็ให้ LLM ตัวอื่นช่วยรีวิว
  • เช่น อย่างง่ายที่สุดคือ “อันนี้เหมือนโค้ดที่นักพัฒนามือใหม่เขียน...”
• ถ้าอยากให้ AI ทำงานได้ดีขึ้น ก็ต้องให้สภาพแวดล้อมที่ทำให้ AI ทำงานได้ดีขึ้น พูดอีกแบบคือ สิ่งที่เอเจนต์ (ในปัจจุบัน) น่าจะทำได้ไม่ดีในบริบทนี้ คน อัลกอริทึม และเอเจนต์ตัวอื่นต้องเข้ามาช่วยเสริม

สิ่งที่ระวังไว้

• ตอนนี้ Moonlight คือจรวดที่เพิ่งเริ่มบิน ส่วนทีม AX คือแขกที่มาจากภายนอก
• ต้องหลีกเลี่ยงภาพแบบ “คนนอกเข้ามาทำอะไรให้เสร็จแล้วก็กลับไป” อย่างเด็ดขาด
• ทำให้ความพยายามในการยกระดับคุณภาพไม่ไปถ่วงการพัฒนาฟีเจอร์ (ให้มากที่สุดเท่าที่จะทำได้)
• ตกลงกันว่าจะผสมงานที่ไม่เปลี่ยนวิธีทำงานเดิมมากนัก กับงานที่ท้าทายแต่ได้ผลดี ในสัดส่วนที่เหมาะสม
  → จินตนาการถึงภาพที่ทีม AX และทีม Moonlight “ร่วมกัน” ค้นหาและนำแนวปฏิบัติที่เหมาะกับทีมและผลิตภัณฑ์ไปใช้ และในกระบวนการนั้นคุณภาพของโค้ด คุณภาพของผลิตภัณฑ์ และความสามารถของทีมก็ยกระดับขึ้นพร้อมกัน

ผลลัพธ์เด่นๆ ที่ได้ใน 4 สัปดาห์ที่ผ่านมา

[1] นิสัยที่ดีเริ่มฝังตัว และเริ่มค้นพบ pattern ที่ดี

• เปิดคอมมิต refactoring ขนาดจิ๋ว (tidying) ทุกวัน โดยไม่ต้องรอ PR review
• พรอมป์ต์ที่ใช้เลียนแบบคอมมิตตัวอย่างที่ดีในอดีต (เช่น การรองรับโมเดลใหม่) และพรอมป์ต์สำหรับค้นหาและรวบรวม pattern เหล่านั้น
• SKILL สำหรับ code review แบบสิงร่างเป็น senior

[2] เริ่มวัดและทำให้มองเห็นตัวชี้วัดคุณภาพโค้ด จำนวน error/warning ต่อจำนวนบรรทัดโค้ดกำลังลดลงอย่างรวดเร็ว

• ตัวชี้วัดคุณภาพโค้ดบางอย่างลดลงแบบค่อยเป็นค่อยไป บางอย่างลดลงแบบเห็นชัดมาก
• สิ่งสำคัญคือการที่ tidying ค่อยๆ ปรับปรุง codebase ทุกวัน ทำให้ถึงจุดหนึ่งเริ่มกล้าคิดว่าจะทำ refactoring ใหญ่ๆ และงานใหญ่ๆ ได้แล้ว
• ใช้ knip ทีละแพ็กเกจเพื่อลบโค้ดเก่าและโค้ดที่ไม่ได้ใช้
• ตัวชี้วัดต้องมองประกอบกันเสมอ โค้ด 1,000 บรรทัดที่มี error 1,000 จุด แย่กว่าโค้ด 100,000 บรรทัดที่มี error 5,000 จุดมาก ดังนั้นจึงไม่ได้ดูแค่จำนวนล้วนๆ แต่ดูอัตรา error ต่อจำนวนบรรทัดเพื่อกำหนดตัวชี้วัดที่สะท้อนสุขภาพของโค้ดได้ดีกว่า
  • จำนวนบรรทัดที่มีความหมายจริง โดยไม่รวมคอมเมนต์และช่องว่าง วัดด้วย tokei

[3] แก้ปัญหา memory leak ที่ยืดเยื้อมากว่า 1 ปีได้

• ระดมใช้ทั้ง repomix และเครื่องมือกับพรอมป์ต์อีกหลายอย่าง จนในที่สุดก็จัดการ memory leak ที่ลากยาวมากว่า 1 ปีได้หลังจากลองหลายรอบ
• ตอนนี้กำลังดีใจเพราะน่าจะลด tier ของ server instance ลงได้

[4] ได้โครงสร้าง abstraction, พรอมป์ต์ และสคริปต์ที่ทำให้เพิ่ม/ลบการทดลองหลายรายการที่รันพร้อมกันทุกสัปดาห์ได้ง่ายและปลอดภัยขึ้น

สรุปคือ ตอนนี้ 3 อย่างกำลังส่งเสริมกันได้ดี: คุณภาพโค้ดสูงขึ้นเรื่อยๆ การพัฒนาฟีเจอร์เร็วขึ้นและปลอดภัยขึ้น และความสามารถด้าน (agentic) engineering ของทีมก็เพิ่มขึ้นอย่างต่อเนื่อง

การลองผิดลองถูก

• แน่นอนว่าไม่ได้ดีตั้งแต่แรก เดิมทีอยากทำสองอย่างพร้อมกัน
  • ใส่การเปลี่ยนแปลงใหญ่ที่มีมูลค่าสูงในคราวเดียว แม้จะเสี่ยงอยู่บ้าง: เปิด strict option, ใช้กฎ eslint ที่เข้มมาก, ลบ dead code ทั้งหมดในครั้งเดียว เป็นต้น
  • เดินทีละก้าวอย่างปลอดภัยแม้มูลค่าไม่มาก: เช่น ฝากคอมมิต tidying ไว้ทุกวัน
• แต่แบบแรก “ทำไม่ได้” เพราะกังวลเกินไป ส่วนแบบหลัง “ไม่ทำ” เพราะไม่น่าสนุก
• เลยเปลี่ยนมาเป็นแบบนี้
  • ทำเรื่องท้าทายให้ปลอดภัยขึ้น (เปิด tsc strict ทีละไฟล์แล้วแก้และปิด, ใช้ eslint ด้วยกฎขั้นต่ำ, ใช้ knip ทีละแพ็กเกจ ฯลฯ)
  • ทำเรื่องที่ปลอดภัยให้มีคุณค่ามากขึ้น (เช่น สร้างพรอมป์ต์เพื่อขอข้อเสนอ tidying จากการเปลี่ยนแปลงล่าสุด)
• แม้ตอนนี้ยังมีโจทย์เหลืออีกมาก
  • เปิด typescript: strict
  • นำ zod มาใช้เพื่อให้สัญญาระหว่างเซิร์ฟเวอร์-ไคลเอนต์ตรงกัน
  • ใช้กฎ eslint ที่เข้มขึ้น
  • เพิ่ม coverage ของ automated test ให้สูงขึ้น
  • ใช้เครื่องมือตรวจแบบ static ให้หลากหลายขึ้นเพื่อปิดกั้นเส้นทางที่ผิด
• แต่เราก็กำลังก้าวไปข้างหน้าอย่าง “ร่วมกัน” “ต่อเนื่อง” และ “ไม่ช้าเลย”

One More Thing: นิสัยการเรียนรู้ + ดีบักของผม

ในสถานการณ์แบบนี้ การถาม AI แล้วไปถามผู้เชี่ยวชาญเพื่อ cross-check จะได้เรียนรู้อะไรมากมาย กระบวนการนี้ก็ถูกเก็บไว้ใน GitHub PR, issue และ Slack เพื่อแชร์ให้ทั้งองค์กรด้วย

• สิ่งที่ผมไม่รู้ คนอื่นอาจรู้
  • คนนี้ไปรู้ความรู้/ประสบการณ์นี้มาได้อย่างไร? เขาใช้สัญญาณอะไรในการจับปัญหานี้?
• ค้นพบความผิดพลาดหรือบั๊กของตัวเอง รวมถึง anti-pattern ใน codebase
  • อะไรคือสาเหตุที่ทำให้ปัญหานี้ต้องเกิดขึ้น? ถ้าอยากพลาดน้อยลงในครั้งหน้า และเจอความผิดพลาดได้เร็วขึ้น ควรปรับโครงสร้างอย่างไร?

สรุปส่งท้าย

• ถ้าทำให้ AI ให้คำตอบได้ดีขึ้น ปัญหาจำนวนมากของทีมผลิตภัณฑ์ก็จะคลี่คลาย
  • ยกระดับคุณภาพของ codebase (เดินไปบนเส้นทางที่ดีตั้งแต่แรก) และนำเครื่องมือหลากหลายมาใช้ (ปิดกั้นเส้นทางที่ผิด)
  • ช่วยให้ความสามารถด้าน agentic engineering ของสมาชิกทีมสูงขึ้น (ให้มันทำงานที่ถนัด และช่วยมันในสิ่งที่ทำไม่ได้)
• หากร่วมมือกับ AI อย่างชาญฉลาด จนทำให้ความสามารถของทีมสูงขึ้นและมีสภาพแวดล้อมที่ดีพร้อมแล้ว “การยกระดับคุณภาพ” กับ “การเพิ่มความเร็วในการเพิ่ม/ปรับปรุงฟีเจอร์” ก็สามารถเกิดขึ้นพร้อมกันได้อย่างเต็มที่
• อย่าเป็นการเอาของดีมาช่วยจาก “ข้างนอก” แต่ให้ “ข้างใน” ร่วมกันค้นหาและลองทำ วัดผล ทำให้มองเห็นได้ ชื่นชม และเรียนรู้จากกันและกัน

[kunggom]

มีบทความเกี่ยวกับมีตอัปออกมาแล้วเหมือนกันนะครับ

[รีพอร์ต] "ผู้ใช้ Claude อันดับ 1 ถือกำเนิดในเกาหลี"…ไปดูงานมีตอัปของ Anthropic มา
https://n.news.naver.com/mnews/article/092/0002402940

ในวันนั้น พัคจินฮยอง วิศวกรจาก PsionicAI ซึ่งใช้งาน Claude Code มากที่สุดในโลก ก็เข้าร่วมงานและได้แบ่งปันเคล็ดลับการใช้งานเอเจนต์ด้วย
ก่อนหน้านี้ Anthropic ระบุว่าวิศวกรพัคเป็นผู้ใช้สาย heavy user อันดับ 1 ของโลก ตอนนี้เขาใช้เครื่องมือ AI หลายตัวในการทำงาน รวมถึง Claude Code ด้วย และจ่ายค่าซับสคริปชัน AI ราว 1.8 ล้านวอนต่อเดือน

ประมาณ 1.8 ล้านวอนต่อเดือน โหดจัดดดดด

[ds2ilz]

ดูแล้วน่าจะมีความหมายในฐานะวิธีที่ช่วยสนับสนุนการมีส่วนร่วมอย่างกระตือรือร้นและการเติบโตของนักพัฒนาระดับจูเนียร์ได้ด้วยนะครับ

[spilist2]

โอ ใช่ครับ 555 ทางนั้นก็ลุยอยู่เหมือนกันครับ