แพตเทิร์นวิศวกรรมแบบ Agentic

 (simonwillison.net)
82 คะแนน โดย GN⁺ 2026-03-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คู่มือที่สรุปแนวทางการพัฒนาในยุคของ coding agent อย่าง Claude Code และ Codex พร้อมนำเสนอ แพตเทิร์นวิศวกรรมรูปแบบใหม่ สำหรับการทำงานร่วมกับเอเจนต์
  • อธิบายผ่านหลากหลายแพตเทิร์นว่า ในสภาพแวดล้อมที่ ต้นทุนการเขียนโค้ดลดลงอย่างมาก เราควรเปลี่ยนนิสัยการพัฒนาและเวิร์กโฟลว์อย่างไร
  • จัดหมวดหมู่ ประเด็นสำคัญของการพัฒนาแบบยึดเอเจนต์เป็นศูนย์กลาง อย่างเป็นระบบ เช่น หลักการ การทดสอบ ความเข้าใจโค้ด และการออกแบบพรอมป์ต์
  • แต่ละแพตเทิร์นอยู่ในรูปแบบ เอกสารแพตเทิร์นที่เน้นการใช้งานจริง พร้อมตัวอย่างโค้ด วิธีทำงาน และกรณีใช้งานของพรอมป์ต์
  • เป็นแหล่งอ้างอิงเชิงปฏิบัติสำหรับนักพัฒนาในยุค coding agent ที่ต้องการ ออกแบบสภาพแวดล้อมการเขียนโค้ดแบบเอเจนต์อย่างเป็นระบบและรักษาคุณภาพงาน

ภาพรวมของ Agentic Engineering Patterns

  • คู่มือที่รวบรวมแนวทางวิศวกรรมที่มีประสิทธิภาพเมื่อพัฒนาร่วมกับ coding agent (Claude Code, OpenAI Codex ฯลฯ)
  • ดูบทความแนะนำ Writing about Agentic Engineering Patterns
    • เป็นเอกสารที่มีโครงสร้างแบบค่อย ๆ เพิ่ม แพตเทิร์น (chapter) หลายรายการอย่างต่อเนื่อง คล้ายรูปแบบ “Design Patterns”
    • เน้นประเด็นการเปลี่ยนแปลงของ เวิร์กโฟลว์และวิธีตัดสินใจของนักพัฒนา ในสภาพแวดล้อมที่ต้นทุนการเขียนโค้ดลดลงมาก
    • ดำเนินการในรูปแบบเนื้อหาแบบ guide ที่อัปเดตได้ ไม่ใช่บทความบล็อก และมีแผนจะขยายต่อเนื่อง

1. หลักการ

  • Writing code is cheap now

    • การมาถึงของ AI coding agent ทำให้ ต้นทุนการเขียนโค้ดเบื้องต้นลดลงจนแทบเป็นศูนย์
    • ในอดีต การเขียนโค้ดมีต้นทุนสูงจึงเน้นการออกแบบและวางแผนก่อน แต่ตอนนี้สามารถใช้ แนวทางทดลองไอเดียด้วยโค้ดได้ทันที
    • แม้ต้นทุนการสร้างโค้ดจะลดลง แต่ โค้ดที่ดี (เช่น การทดสอบ ความสามารถในการบำรุงรักษา) ก็ยังมีต้นทุนอยู่

  • Hoard things you know how to do

    • ทรัพย์สินสำคัญของนักพัฒนาคือ “การสะสมความรู้ว่าอะไรทำได้บ้าง”
    • เน้นนิสัยการ เก็บสะสมกรณีแก้ปัญหาและการทดลองโค้ดเล็ก ๆ ในรูปแบบที่นำกลับมาใช้ซ้ำได้
    • โค้ดและตัวอย่างที่สะสมไว้เช่นนี้สามารถใช้เป็น ข้อมูลนำเข้าที่ทรงพลังเมื่อสั่งให้ coding agent สร้างฟีเจอร์ใหม่

  • Anti-patterns: things to avoid

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

2. การทดสอบและ QA

  • Red/green TDD

    • การพัฒนาแบบทดสอบก่อน (TDD) เป็น แพตเทิร์นการพัฒนาที่มีประสิทธิภาพเป็นพิเศษเมื่อใช้ร่วมกับ coding agent
    • เมื่อเขียนเทสต์ก่อน เอเจนต์จะสามารถ สร้างโค้ดให้สอดคล้องกับเทสต์ ได้
    • แม้ใช้พรอมป์ต์เพียงเล็กน้อย ก็ยังช่วยให้ สร้างโค้ดที่แม่นยำและเชื่อถือได้

  • First run the tests

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

3. ความเข้าใจโค้ด

  • Linear walkthroughs

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

  • Interactive explanations

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

4. พรอมป์ต์แบบมีคำอธิบายประกอบ

  • GIF optimization tool using WebAssembly and Gifsicle

    • มีตัวอย่างพรอมป์ต์สำหรับสร้าง เครื่องมือปรับแต่ง GIF โดยใช้ WebAssembly และ Gifsicle
    • นำเสนอวิธีการสร้าง เครื่องมือหน้าเดียว ที่รวม HTML, JavaScript และ CSS
    • อธิบายวิธีใช้ coding agent ผ่าน พรอมป์ต์จริงและตัวอย่างโค้ด

5. ภาคผนวก

  • Prompts I use

    • รวม ตัวอย่างพรอมป์ต์สำหรับ coding agent ที่ใช้งานจริง
    • สรุป แพตเทิร์นพรอมป์ต์เชิงปฏิบัติ ที่ใช้ได้กับงานหลากหลายประเภท
    • มี เทมเพลตที่ใช้งานได้จริง สำหรับการทำงานร่วมกับเอเจนต์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-05
ความคิดเห็นจาก Hacker News

  • ดูเหมือนว่าเรากำลังจะทำเรื่องเดิมซ้ำอีกครั้ง
    เอาแนวคิดง่าย ๆ และสมเหตุสมผล — เช่น "เขียนเทสต์ก่อน", "สร้างโมดูลเล็ก ๆ ที่นำมาประกอบกันได้" — ไปห่อด้วยชื่อที่ซับซ้อน แล้วก็น่าจะสร้างเป็น อุตสาหกรรมที่ปรึกษา ขึ้นมาอีก
    แต่รอบนี้เป้าหมายคือ “เครื่องจักรที่พูดได้” โลกที่แค่สั่งด้วยคำพูดก็พอ

    • COBOL ก็เคยให้คำสัญญาคล้ายกัน บอกว่าเป็นภาษาที่มนุษย์อ่านง่ายจนไม่ต้องมีโปรแกรมเมอร์ แต่สุดท้ายการแยกปัญหาและแก้มันก็ยังต้องอาศัยมนุษย์ คิดแบบโปรแกรมเมอร์ อยู่ดี กล่าวคือ ต่อให้ภาษาเป็นมิตรกับมนุษย์ ก็ไม่ได้แปลว่าโปรแกรมเมอร์จะหายไป
    • รอบนี้ก็น่าจะเป็นการวนซ้ำของ วัฏจักรกระแส AI อีกครั้ง ตอนนี้ถ้าวิจารณ์ก็จะโดนตอบกลับว่า “ไม่เข้าใจมัน” แต่ไม่นานปัญหาต่าง ๆ ก็จะปะทุออกมา โดยเฉพาะสถานการณ์ที่ “AI สร้างโค้ดมากเกินจนทั้งมนุษย์และ AI เองก็รับมือไม่ไหว” ถึงตอนนั้นก็คงมีทั้ง แพตเทิร์นและแอนตี้แพตเทิร์น รวมถึงที่ปรึกษาที่อ้างว่าแก้ปัญหานี้ได้โผล่มาอีก
    • การที่ AI พูดและเข้าใจภาษาอังกฤษได้ ทำให้ ความชัดเจนของอินเทอร์เฟซ ลดลง มันทรงพลังเหมือน CLI แต่ไม่ชัดเจนว่าวิธีไหนได้ผลจริง ดังนั้นการบันทึกและแชร์ว่า “ควรสั่งอะไรอย่างไรถึงจะได้ผลลัพธ์ที่ดี” จึงสำคัญ เพียงแต่ต้องไม่ปล่อยให้มันกลายสภาพเป็นแบบ อุตสาหกรรมโค้ช OOP อีก
    • ใช่ มันจะเป็นแบบนั้นอีก และครั้งนี้จะเร็วขึ้นมาก วงจร 10 ปีแบบ บล็อกเกอร์ → วิทยากร → หนังสือ → ที่ปรึกษา → สถาบันรับรอง จะถูกบีบอัดให้เกิดขึ้นภายในไม่กี่ปี
    • ฉันไม่เห็นด้วยกับคำวิจารณ์ว่าชื่อบทความซับซ้อนเกินไป แต่ปัญหาคือความเข้าใจผิดแบบ “แค่สั่งเป็นคำพูดก็พอ” ในความเป็นจริงแต่ละคนได้ผลลัพธ์ต่างกันมาก สุดท้ายบทเรียนที่ได้คือ "นิสัยการพัฒนาที่ดีสำหรับมนุษย์ ก็เป็นผลดีกับ AI ด้วย" AI ดูเหมือนมนุษย์ แต่ไม่ใช่มนุษย์ ดังนั้นจึงต้องอธิบายให้มากกว่าเดิม

  • อยากถาม Simon ว่า — “ในโลกที่โค้ดราคาถูกลง เราควรทำ code review อย่างไร?”
    คนในทีมเข้าหาแบบ “มันใช้ได้ก็โอเคแล้วนี่” โดยที่ยังไม่เข้าใจโครงสร้าง รีวิวก็ยิ่งใหญ่ขึ้นเรื่อย ๆ และฉันกลายเป็นคอขวด ก็กำลังคิดเรื่อง ใช้ AI reviewer เป็นตัวแทน อยู่เหมือนกัน แต่ก็ไม่ชอบที่ความรู้สึกแบบมนุษย์จะหายไป

    • เป็นหัวข้อที่น่าสนใจมาก ถ้าความเร็วในการสร้างโค้ดเพิ่มขึ้น การรีวิวจะกลายเป็นคอขวด ถ้าโค้ดราคาถูก เราอาจลดมาตรฐานการรีวิวลงได้ แต่ฉันกลับอยากได้คุณภาพที่ดีกว่าเดิม โดยเฉพาะ การตรวจสอบความปลอดภัย ที่ละไม่ได้เด็ดขาด อาจต้องใช้แนวทางที่เป็นระบบเหมือนทีมความปลอดภัยขององค์กรขนาดใหญ่
    • ถ้าจะใช้ การรีวิวแบบ agent-based การตั้งค่าบริบทเป็นเรื่องสำคัญ ถ้ารันลูปแบบ วางแผน → ลงมือทำ → ทดสอบ/แก้ไข → รีวิว/รีแฟกเตอร์ → สร้างคู่มือ QA ก็จะทำให้ไม่ใช่แค่โค้ด แต่รวมถึง เอกสารและแนวทางการทดสอบ พัฒนาไปพร้อมกัน
    • “มันใช้ได้ก็โอเคแล้วนี่” ไม่ใช่ปัญหาเชิงเทคนิค แต่เป็น ปัญหาวัฒนธรรมองค์กร บางบริษัทยังให้ความสำคัญกับ โค้ดที่อ่านง่าย อยู่ และนั่นอาจกลายเป็นความได้เปรียบในการแข่งขันได้
    • ฉันลงทุนกับ ระบบอัตโนมัติสำหรับ static/dynamic analysis ใช้เครื่องมือคุณภาพอย่าง custom lint rules, การตรวจ type ที่เข้มงวด, และ mutation testing อย่างจริงจัง เพราะการพึ่งรีวิวอย่างเดียวช้าและไม่มีประสิทธิภาพ ดังนั้นหัวใจคือ การทำ early feedback ให้เป็นอัตโนมัติ
    • ทัศนคติแบบนี้เปลี่ยนยากมาก ทางที่ดีกว่าอาจเป็นการย้ายไปอยู่ ทีมที่ให้ความสำคัญกับคุณภาพซอฟต์แวร์

  • ฉันใช้ AI เป็นหลักกับ โค้ด boilerplate หรือช่วยแก้ปัญหาเรื่องเอกสาร
    เคยลองงานแบบ agent แล้ว แต่ผลลัพธ์ยังไม่น่าเชื่อถือพอ ขณะที่บางคนกลับบอกว่า “ตอนนี้แทบไม่ได้เขียนโค้ดเองแล้ว” ช่องว่างนี้น่าสนใจดี

    • สำหรับฉัน หลายครั้ง เขียนโค้ดเองเร็วกว่า AI การวางแผน สั่งให้ทำ และตรวจสอบ กลับทำให้ช้าลง แต่กับ การรีแฟกเตอร์ขนาดใหญ่ AI เร็วกว่ามาก
    • ในช่วงไม่กี่เดือนที่ผ่านมา ความสามารถของ agent พุ่งขึ้นมาก ตอนนี้มันไม่ได้อยู่แค่ระดับ autocomplete ง่าย ๆ แต่ไปถึงขั้น ทำฟีเจอร์ทั้งก้อนได้ แล้ว
    • อาจอธิบายได้จากความต่างระหว่างนักพัฒนาที่รู้สึก "อี๋" กับโค้ด AI แบบ “อันนี้ AI เขียนแน่เลย” กับคนที่ไม่รู้สึกแบบนั้น
    • สุดท้ายแล้ว ขึ้นอยู่กับประเภทของงาน อย่างชัดเจนว่ากรณีไหน AI เหมาะ และกรณีไหนไม่เหมาะ
    • ฉันเองก็ไม่ชอบผลลัพธ์รอบแรกเหมือนกัน แต่ถ้า วนลูปรีวิวหลายรอบ คุณภาพจะดีขึ้นชัดเจน ถ้าให้ AI รีวิวกันเอง หรือกำหนดเกณฑ์การทดสอบให้ชัด ก็จะดีขึ้นมาก

  • ช่วงนี้กำลังทดลอง ลูปการเขียนโค้ดแบบ agent
    ตัวอย่างเช่น ใน โปรเจกต์ fesh เป้าหมายคือ “บีบอัด Linux binary ให้เล็กลง” เป็นปัญหาที่มีเทสต์ชัดเจน จึงเหมาะกับลูป AI
    สิ่งที่เรียนรู้มีดังนี้:

    • test harness คือทุกอย่าง ถ้าไม่มีลูปตรวจสอบ ทิศทางจะหลุด
    • การปล่อยให้ AI ลองผิดลองถูกเชิงทดลองเป็นเรื่องสำคัญ
    • ต้องมี .md scratchpad ข้ามเซสชันไว้ เพื่อให้การเรียนรู้ต่อเนื่อง
    • เทสต์สำคัญมากจริง ๆ AI ล้มเหลวด้วยวิธีประหลาด ๆ ดังนั้นจึงควรใช้ การสร้างเทสต์อัตโนมัติ อย่างจริงจัง
    • ถ้าไม่มีเทสต์ ก็เชื่อผลลัพธ์ของลูปไม่ได้ ต้องมี กระบวนการตรวจสอบแบบ deterministic
    • การแยกบันทึก decision log กับ rejection log ออกจากกันมีประโยชน์มาก โดยเฉพาะ rejections.md มีค่ามากกว่า ต้องบันทึกว่า “ทำไมถึงทิ้งแนวทางนี้” เพื่อไม่ให้ AI ทำพลาดซ้ำแบบเดิม
    • ในงาน browser automation ก็คล้ายกัน นอกจากการตรวจสอบเชิงฟังก์ชันแล้ว ต้องเพิ่ม การตรวจสอบเชิงพฤติกรรม (ดูเหมือนมนุษย์หรือไม่) ถึงจะใช้งานได้ดี และ .md log ก็ช่วยยกระดับคุณภาพของเซสชันถัดไปได้มาก

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

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

  • ทุกครั้งที่มี LLM รุ่นใหม่ออกมา ก็รู้สึกเหมือนบทเรียนเดิม ถูกทำให้ใช้ไม่ได้ทั้งหมด
    โครงสร้างซับซ้อนที่สร้างขึ้นมาเพื่อเลี่ยงข้อจำกัดของโมเดลเก่าอย่าง LangChain พอหลัง GPT-3.5 มาก็ดูไม่จำเป็นแล้ว อีกไม่นาน agent เดี่ยวตัวเดียว อาจพอสำหรับจัดการทุกอย่างก็ได้

    • เพราะแบบนั้นฉันจึงพยายามสรุป แพตเทิร์นที่ไม่ยึดติดกับเวอร์ชันของโมเดล เช่น red/green TDD ที่อีกหน่อยโมเดลอาจทำเองได้ แต่ตัวแนวคิดก็ยังมีประโยชน์อยู่
    • ท้ายที่สุดทุกอย่างอาจไหลไปสู่รูปแบบอย่าง ClaudeVM
      ดูบทความที่เกี่ยวข้อง

  • มีจุดหนึ่งที่มักหายไปจากการถกเรื่อง agent engineering
    บทเรียนส่วนใหญ่มักถูกพูดราวกับเป็น ความจริงสากล แต่ในความเป็นจริงมันขึ้นกับขนาดทีม ระดับความ成熟ของ codebase ระดับของเทสต์ และระดับการยอมรับความเสี่ยง สิ่งสำคัญคือ ต้องบอกให้ชัดว่า “แพตเทิร์นนี้ใช้ได้เมื่อไร”

    • เพราะอย่างนั้นฉันจึงสรุปแพตเทิร์นในรูปแบบ เว็บไซต์แทนหนังสือ จะได้อัปเดตต่อเนื่องและระบุขอบเขตการใช้งานได้ชัด
    • ในฐานะที่ปรึกษาที่ได้ทำกับหลาย codebase จะเห็นชัดว่า ประสิทธิภาพของ Claude Code ต่างกันสุดขั้วตามคุณภาพของ codebase โปรเจกต์ที่มี type แข็งแรงและมีเทสต์ทำงานได้แทบสมบูรณ์ แต่กับสภาพแวดล้อม JavaScript ที่หลวม ๆ กลับไม่ค่อยดี
    • ถึงอย่างนั้น บางแพตเทิร์นก็เป็นสากล เช่น การมี source of truth (harness) ที่เป็นอิสระนั้นใช้ได้ทุกที่ เครื่องมืออย่าง showboat และ rodney กำลังช่วยเรื่องนั้นอยู่

  • ทุกวันนี้มี “framework สำหรับ agent team” โผล่มาวันละเป็นสิบ ๆ ตัว
    มันเป็นช่วง ทดลองอย่างสับสนวุ่นวาย คล้ายวิศวกรรมซอฟต์แวร์ยุคแรก แต่สุดท้ายจะมีบางแพตเทิร์นกลายเป็นมาตรฐาน
    ทีมของเราเจอว่าการ เข้าหาแบบทีมมนุษย์ ได้ผลดี — เริ่มจากเขียน spec ของผลิตภัณฑ์ ก่อน จากนั้นให้ AI ช่วยขัดเกลา แล้วค่อยส่งต่อบนฐานนั้นไปยัง โฟลว์ของ agent ที่แยกบทบาทกัน

  • วันนี้ฉันสอนในวิชาปริญญาตรีเรื่องวิวัฒนาการของสถาปัตยกรรม CPU·GPU
    ในอดีต Moore’s Law ทำให้ฮาร์ดแวร์แก้ทุกอย่างได้ แต่ตอนนี้ ความขนาน คือหัวใจ
    แนวคิดที่ Simon พูดว่า “โค้ดมีราคาถูก” ก็เป็น การเปลี่ยนกระบวนทัศน์ แบบเดียวกัน
    เหมือนกับที่ยุคฮาร์ดแวร์แบบขนานทำให้โค้ดที่มีประสิทธิภาพเปลี่ยนไปโดยสิ้นเชิง ในยุค AI กระบวนการพัฒนาเองก็จะเปลี่ยนไป คนที่เข้าใจเรื่องนี้ก่อนจะได้เปรียบระดับ 10 ถึง 100 เท่า

  • ในทีมของเรา ‘ลูปที่มีการตรวจสอบโดยมนุษย์เป็นระยะ’ ใช้งานได้จริงที่สุด
    agent แบบอัตโนมัติเต็มรูปแบบมักผ่านเทสต์ แต่กลับไปทำลาย เงื่อนไขคงอยู่โดยนัย
    ดังนั้นเราจึงให้มนุษย์เข้ามาก่อนถึง การตัดสินใจที่ย้อนกลับไม่ได้
    แต่การทำให้ AI เข้าใจว่า “อะไรคือสิ่งที่ย้อนกลับไม่ได้” ก็เป็นโจทย์อีกข้อหนึ่ง
    นอกจากเอกสารอย่าง CLAUDE.md แล้ว เรายังกำลังมองหาวิธีที่เป็นระบบในการถ่ายทอด กฎโดยนัยของ codebase ด้วย