The NEXT4I Micro-batching Architecture for Enterprise Software Implementation

“ผมขอแชร์เรื่องราวและสถิติการ run Workflow การทำงานของ AI Agent ที่ผมพัฒนาและปรับปรุงจนเริ่มใช้งานจริงกับ project ภายใน และขอตั้งชื่อเท่ๆ ว่า "N-Flow Agentic Inception" เป็น AI Workflow ภายในของ NEXT4I เอง โดยใช้คอนเซปต์ Micro-batching ที่ทำงานสเกล Enterprise มีปริมาณงานประมาณ 1,200 Tasks ซึ่งตอนนี้ผมให้ AI ปั่นงานออกมาด้วยความเร็วประมาณ 5-7 Tasks/ชั่วโมง ทำให้ผมเปลี่ยนจาก 'Dev ที่นั่งเขียนโค้ด' เป็น 'Dev ที่คุมโรงงาน AI คอยดูการทำงานว่าสายพานการผลิตยังดีอยู่ไหม และดู report ของโรงงานที่ run งานตลอด 24 ชั่วโมงครับ'”

จากระยะเวลาหลายเดือนที่ผมลองผิดลองถูกในการทำ workflow กับ AI Agent เพื่อ Develop software แบบ Long running Implementation โดยอาศัย Micro-batching Concept เป้าหมายคือให้ AI Agent ทำงานต่อเนื่อง 24 ชั่วโมง++ ใช้ต้นทุนให้คุ้มค่า และยังต้องทำงานให้ตรง requirement ไม่ออกทะเล รวมถึงทำงานข้าม services ตาม scope งาน ต้องสามารถทดสอบตัวเองได้ และต้องมี evidence ด้วย ทั้งหมดนี้ผมจะทยอยเล่าให้ฟังเรื่อยๆ จนจบการทำงาน ซึ่งจากสถิติ AI ช่วยประเมินว่าน่าจะใช้เวลา run ทั้งหมดประมาณ 20 วัน

สถิติจากการรันงานจริง เมื่อเดือนก่อน (wave ที่ 1):

• Speed & Scale: หลังจากแก้ไขยกชุด (ผมจะเขียนเล่าความล้มเหลวครั้งใหญ่ในบทความถัดๆ ไป) เริ่ม run ได้ 30 Tickets ใน 4 วัน (ไม่ได้ run ทั้งวัน) Ticket ติดปัญหาบ่อย run ได้แค่ชุดละ 3-5 tasks เท่านั้นก็ไปต่อไม่ได้แล้ว ต้องกลับมาแก้ ticket เรื่อยๆ

• Low-Accuracy: ticket ไม่ผ่าน Quality Gate บ่อยมาก เป็นทั้งที่ไม่ผ่านจริง และที่ Quality Gate เองตรวจไม่ make sense เช่น expected code coverage ทั้งที่ยังไม่มี Unit Test หรือ Ticket Dependency ที่ Block กันจนไปต่อไม่ได้

• Trackable: ระบบจัดการ Commit โค้ดลง Git ได้เองอย่างเป็นระเบียบ โดยในชุดแรก model ที่ปิดงานจะเป็น gpt-5.6-sol (หลัก), gpt-5.6-luna และ gpt-6-astra

• สถิติยังไม่มีอะไรน่าสนใจ และต้องแก้บ่อยมาก จนยังไม่เข้าใกล้การ run ต่อเนื่องแบบหลายชั่วโมง ผมจึงตัดสินใจรื้อ workflow ใหม่อีกครั้ง

สถิติจากการรันงานจริง เมื่อ 7 วันก่อน (wave ที่ 2):

• Speed & Scale: ระบบสเกลความเร็วขึ้นเรื่อยๆ จาก wave แรกที่ช้ามาก ตอนนี้ทำได้ 3.5-7 tickets ต่อชั่วโมง และเคลียร์ Epic งานไปประมาณ 11.7% (146 จาก 1,243 ใบ)

• Run-to-run variation: ใน wave นี้ run ประมาณ 4-5 รอบ มีช้าบ้างในบาง service หรือ loop หยุดบ่อยจนความเร็วตกลงเหลือ 2-4 ใบต่อชั่วโมง ความสามารถในการ run ต่อเนื่องอยู่ที่ประมาณ 3 ชั่วโมง และไปได้ถึง 6 ชั่วโมงในบางรอบ

• 100% Accuracy: ใน ticket ที่สำเร็จ งานทุกใบผ่าน Quality Gate ตั้งแต่รอบแรก

• Trackable: ระบบยังจัดการ Commit โค้ดลง Git และระบุชัดเจนว่า Task ไหนใช้ Model อะไรรับจบ (เช่น [sonnet], [opus])

สถิติจากการรันจริง หลังจาก Refactor Workflow อีกรอบ (wave ที่ 3):

• Speed & Scale: ใน wave นี้ทำได้ 5-7 tickets ต่อชั่วโมง และ Clear งานทั้งหมดไปแล้ว 43.4%

• รันงานบน Local Claude Code 100% ปิดงานไป 109 Tasks ในรอบแรก ใช้ Weekly Quota ของ Claude Max 5x ไป 28% โดย Cache hit 99% และ Context 54%

• จากนั้นในช่วงที่ติด weekly quota limit ผมใช้ Free Claude Cloud credit ที่เหลือ 197 USD ระหว่างรอ weekly quota reset ปิดไปได้อีก 82 tickets เฉลี่ยแล้ว 2.4 USD ต่อ 1 Task (model ส่วนใหญ่ที่ทำเป็น sonnet 78 tasks และมี opus หยิบไปทำ 4 tasks ครับ)

Project Estimate

โปรเจกต์สเกลนี้ปกติอาจต้องใช้ทีม Dev ประมาณ 12 คน (Backend 8-9, Frontend 2-3, DevOps 1-2) และรันประมาณ 12 เดือน Task ทั้งหมด 1,243 tasks ประมาณ 3,500 Man-days (Claude Sonnet 5.5 Estimate ให้) และด้วย speed นี้ ระบบคาดการณ์ว่าจะรันเสร็จสมบูรณ์ในประมาณ 20 วัน (เฉพาะเวลาในการ dev)

N-Flow Agentic Inception คืออะไร?

โปรเจกต์ที่ใช้ workflow นี้เป็นงานสเกล Enterprise ของ NEXT4I เอง งานต้องข้ามหลาย service และถูกแตกออกมาเป็น task ทั้งหมด 1,243 ใบ (ผมจะเรียกสลับกันว่า task, ticket หรือใบสั่งงาน ความหมายเดียวกันครับ)

แกนของมันคือ Micro-batching แทนที่จะโยนงานก้อนใหญ่ให้ AI ทำทีเดียว เราหั่นงานเป็นชิ้นเล็กที่มี scope ชัด แล้วให้ AI ทำทีละชุดเล็กๆ ทุกชิ้นต้องผ่านการตรวจก่อน ถึงจะไปชิ้นถัดไปได้

ขั้นตอนจริงมีแบบนี้ครับ:

• ขั้นที่ 0 คน: ผมเป็นคนให้ requirement แล้วปรับร่วมกับ AI โดยใช้ Claude, GPT-SOL และ Gemini เป็นที่ปรึกษา ส่วนนี้ใช้เวลารวมประมาณ 5 ถึง 6 เดือน
• ขั้นที่ 1 AI ฝ่ายวางแผน: รับ requirement มาย่อยเป็น task ที่มีเป้าหมาย ข้อห้าม guardrails, test ที่จะใช้ verify และระดับความซับซ้อนของงาน แล้วรัน unit test ตรวจความครบของ “ใบสั่งงาน” อีกชั้น
• ขั้นที่ 2 AI ฝ่ายผลิต: หยิบใบสั่งงานไปทำ ระบบเลือกโมเดลตามความซับซ้อนของงาน งานมีสองแบบ คือ implement ที่ผลลัพธ์เป็นโค้ด และงาน test ที่ผลลัพธ์เป็นหลักฐาน (evidence)
• ขั้นที่ 3 Quality Gate: ตรวจผลงานของแต่ละใบ ผ่านแล้วค่อย commit ลง Git พร้อมระบุว่าโมเดลไหนปิดงาน เช่น [sonnet] หรือ [opus]
• ขั้นที่ 4 เมื่อไม่ผ่าน: ลองแก้ใหม่หรือส่งต่อให้โมเดลที่เก่งกว่า และมีจุด human-in-the-loop ที่ state สำคัญให้ผมเข้าไปรีวิวได้

Requirement (คน + AI ที่ปรึกษา)
        │
        ▼
AI ฝ่ายวางแผน ──► ใบสั่งงาน 1,243 ใบ ──► unit test ตรวจใบสั่งงาน
        │
        ▼
AI ฝ่ายผลิต (เลือกโมเดลตามความซับซ้อน)
        │
        ▼
Quality Gate ──► ผ่าน ──► commit + tag โมเดล ──► ใบถัดไป
        │
        └──► ไม่ผ่าน ──► แก้ใหม่ / escalate ไปโมเดลที่เก่งกว่า / คนรีวิว

การจัดการ เมื่อ AI ทำงานพลาด

ผมขอยกตัวอย่างจาก log ช่วงหนึ่งที่ผมชอบมากครับ:

• Ticket 2: script เจอ sed filter broke แต่แทนที่ระบบจะหยุด มันกลับไปเช็ก state ซ้ำ เห็นว่างานจริงๆ เสร็จแล้ว ก็ปล่อยผ่านจนจบ
• Ticket 3 และ 4: ได้สถานะ DONE_WITH_CONCERNS (เสร็จแบบ ไม่สมบูรณ์) ระบบถือว่า “ยังไม่ผ่าน” แล้ว escalate จาก Sonnet ขึ้นไปให้ Opus ดูแทนโดยอัตโนมัติ
• Opus กับ Ticket 3: ไม่ได้เข้ามาแก้โค้ดเลย แต่สรุปว่า “ไม่ต้องแก้โค้ด เปลี่ยนสถานะเป็น DONE ก็พอ” โดยอ้าง ticket เรื่อง MCP ก่อนหน้าที่เคยเจอกรณีเดียวกันเป็นบรรทัดฐาน

ถ้ามองเป็นโรงงาน ก็คือมีพนักงานหน้าสายพาน (Sonnet) ทำงานส่วนใหญ่ และมีหัวหน้า QC (Opus) ที่ถูกเรียกมาเฉพาะตอนที่งานมีปัญหา ซึ่งก็ตรงกับตัวเลขใน Wave 3 ที่ Opus ทำแค่ 4 จาก 82 ใบครับ

แต่ก็ไม่ได้แปลว่าเราควรเชื่อทุกการตัดสินใจของ AI นะครับ การที่ Opus บอกว่า “ไม่ต้องแก้” ก็เป็นการตัดสินใจที่อาจผิดได้เหมือนกัน นี่คือเหตุผลที่ทุก commit ต้องระบุว่าโมเดลไหนทำ และผมยังวางจุด human-in-the-loop ไว้ที่ state สำคัญ เพื่อให้ตรวจย้อนหลังได้เสมอ

บทเรียนที่ผมได้จากรอบก่อน

ปัญหาคลาสสิกของการให้ AI เขียนโค้ดสเกลใหญ่ คือการที่เรา "สั่งงานกว้างเกินไป" AI เลยเดาใจผิด (Hallucinate) ผลาญ Token ทิ้ง เราก็ต้องมานั่งแก้เอง ไหนจะ cost ที่แพงมาก จากการที่ผมใช้ LLM API แล้วใช้ tools ที่วนทำงานมากเกินไปจน token บวม ตามมาด้วย cost ที่บานปลาย ปรับอยู่นาน ซึ่งผมเองก็เจ็บกับเรื่องนี้มาเยอะเหมือนกัน

ผมเลยรื้อใหม่ด้วยคอนเซปต์ Micro-batching โดยใช้ชื่อ "N-Flow Agentic Inception" (AI สั่งงาน AI และ AI ตรวจงาน AI) โดยมีกระบวนการคือ:

1. AI ฝ่ายวางแผน: รับ Requirement ที่ผมออกแบบไว้มาย่อยเป็น tasks ที่มี Scope ชัดเจน

2. AI ฝ่ายผลิต: รับ "ใบสั่งงาน" ไปรันต่อ โดยระบบจะเลือก Model ที่เหมาะสมกับความซับซ้อนของงานโดยอัตโนมัติ เขียนโค้ดและ Test ให้ผ่าน Quality Gate แล้ว Commit งาน โดย AI พวกนี้จะรับทำทั้งงานที่ ticket เป็น implement ซึ่งผลลัพธ์เป็น code และงาน test ที่ผลลัพธ์เป็น evidence

ผลลัพธ์ทำให้ผม monitor task ที่ AI ทำน้อยลงเรื่อยๆ ครับ เพราะจากการปรับและแก้มาเรื่อยๆ ก็ทำให้นิ่งระดับนึง จากที่แต่ก่อนคอยดู Report การปั่นงานของ AI ทุกๆ 1-3 ชั่วโมง บางที run ได้ 50-80 tasks แล้วก็ติดปัญหาบ้าง จนตอนนี้ผม run ได้ยาวๆ 100 tasks++ ซึ่งใช้เวลา run ทั้งหมดประมาณ 24 ชั่วโมง และใน 1 วันผมก็จะมาดูบ้างนานๆ ครั้ง โดยใน 1 วันนั้นจะใช้ weekly quota ประมาณ 25-30% ครับ จนตอนนี้ผมต้อง upgrade เป็น Max 20x เพื่อจะได้ run ได้ครบทั้ง week เนื่องจาก Free Cloud credit ผมใช้หมดแล้ว และสถิติการรันงาน 24 ชั่วโมงล่าสุดคือ ยังไม่มี Task ใบไหนต้อง Escalate กลับมาให้ผมแก้เลย

สรุป

การที่หลังขดหลังแข็งทำ Task Decomposition เพื่ออุดช่องโหว่ Garbage In, Garbage Out ไปแล้ว ทำให้ระบบไม่ติดคอขวดที่เรา เรามีหน้าที่เคลียร์ requirement ให้จบ สรุปงานให้ชัด แล้วก็ปล่อย AI ทำหน้าที่รันงานยาวๆ ไปเลย

จากเป้าหมายแรกของผมสำหรับสถาปัตยกรรมนี้คือการเซฟต้นทุนและเร่งสปีดโปรเจกต์ ถึงตอนนี้ผมว่ามันเริ่มดีขึ้น จนผมกล้าที่จะปล่อยมันทิ้งไว้ แล้วลุกออกจากหน้าจอคอมฯ เอาเวลาไปทำอย่างอื่นแบบสบายใจ โดยที่ NEXT4I Factory ของผมยังปั่นโค้ดเป็นสายการผลิตอัตโนมัติต่อไปเรื่อยๆ

ส่วนผลลัพธ์ต่อไปจนจบงานจะเป็นยังไง ติดตามชมจากช่องทางนี้ได้เรื่อยๆ นะครับ

Welcome to the era of Agentic Workflow. 🚀