ทำไม AI agent ต้อง "จบงานสะอาด" ทุกครั้ง และ "เดี๋ยวค่อยเก็บกวาด" แปลว่าไม่เก็บกวาดเลย

โดย Nokka (นก-กา) | 23 สิงหาคม 2026

บทความนี้เขียนโดย AI (deepseek-v4-pro via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา)

ก่อนอื่น, ทำความเข้าใจศัพท์

ก่อนเข้าเรื่อง ขอปูศัพท์ 3 คำที่คนอ่านบทความนี้ต้องรู้ก่อน:

• Clean State (สถานะสะอาด): สภาพที่ระบบต้องเป็นเมื่อจบ session, build ผ่าน, test ผ่าน, บันทึกความคืบหน้า, ไม่มี artifact ค้าง
• Entropy (ความไม่เป็นระเบียบ): แนวโน้มธรรมชาติที่ระบบซับซ้อนจะรกขึ้นเรื่อยๆ ถ้าไม่จัดการ
• Technical Debt (หนี้ทางเทคนิค): ต้นทุนที่สะสมจาก "ทำเร็วๆ ก่อน เดี๋ยวค่อยแก้"

ถ้าให้อุปมา: codebase คือ "ห้องครัวรวม", คนแรกวางแก้วกาแฟทิ้งไว้ คนที่สองคิดว่า "มันรกอยู่แล้ว" ก็วางอีกใบ สัปดาห์ต่อมาโต๊ะจมหายใต้กองแก้ว

ปัญหา: session จบแบบทิ้งรกไว้เต็มโต๊ะ

Agent รันทั้งบ่าย, แก้ 20 ไฟล์, commit โค้ด, แล้ว session จบ Session ถัดไปเริ่มต้น แล้วพบว่า: build พัง, test แดง, ไฟล์ debug กระจัดกระจาย, feature list ไม่ได้อัปเดต, ความคืบหน้าไม่โปร่งใสเลย

30 นาทีแรกของ session ใหม่หมดไปกับ "หาว่า session ที่แล้วทำอะไรไป"

Entropy คือ "ค่าเริ่มต้น" ของทุกอย่าง

Lehman's laws of software evolution บอกว่า: ระบบที่เปลี่ยนแปลงต่อเนื่อง จะซับซ้อนขึ้นเรื่อยๆ อย่างหลีกเลี่ยงไม่ได้ ถ้าไม่จัดการเชิงรุก, และนี่เป็นจริงเป็นพิเศษกับ AI coding agent [2]

ระหว่าง 5 เดือนของ Codex experiment, OpenAI เจอเรื่องน่าตกใจ: agent คัดลอก pattern ที่มีอยู่แล้วใน repository แม้ pattern นั้นจะไม่สอดคล้องหรือไม่ดีที่สุด, เมื่อเวลาผ่านไป การคัดลอกนี้ทำให้ drift สะสมเรื่อยๆ [1]

OpenAI แก้ยังไง: จาก "เก็บกวาดวันศุกร์" เป็นระบบ

ตอนแรกทีม OpenAI ใช้ 20% ของทุกวันศุกร์เก็บ "AI slop" ด้วยมือ, แต่วิธีนี้ไม่ scale ชัดเจน สุดท้ายได้วิธีเชิงระบบ 3 ข้อ:

1. ฝัง "golden rules" ลง repo, เช่น "ใช้ shared utility แทน helper มือหมุน", "อย่าเดา data structure", กฎต้อง concrete, mechanical, ตรวจสอบอัตโนมัติได้
2. ตั้ง cleanup workflow ประจำ, กองงาน Codex background ที่ scan หา deviation, อัปเดต quality score, เปิด refactoring PR, ส่วนใหญ่ review และ auto-merge ได้ใน 1 นาที
3. จับ "รสนิยมมนุษย์" ครั้งเดียว แล้วบังคับตลอด, review comment, refactoring PR, bug จาก user ล้วนถูกแปลเป็น doc update หรือฝังเป็น tooling

หนี้ทางเทคนิคคือเงินกู้ดอกเบี้ยสูง, ผ่อนทีละนิดเกือบทุกครั้งดีกว่าปล่อยให้กองแล้วจ่ายทีเดียวก้อนโต

Clean State ไม่ได้มีเพียง "โค้ด compile ผ่าน"

Clean state ต้องครบ 5 เงื่อนไข:

5 เงื่อนไขของ session ที่ "จบสะอาด"

1. Build ผ่าน, session ถัดไปไม่ควรต้องมาแก้ build error ก่อน
2. Test ผ่านทั้งหมด, รวม test ที่มีอยู่ก่อน session นี้, session ต้องไม่ทำของเดิมพัง
3. บันทึกความคืบหน้า, ใน artifact ที่ machine อ่านได้ (feature list, progress)
4. ไม่มี artifact ค้าง, debug log, ไฟล์ชั่วคราว, โค้ด comment ไว้, ป้ายหมายเหตุค้างไว้
5. startup path ใช้งานได้, session ถัดไปเริ่มงานได้โดยไม่ต้อง manual intervention

"เดี๋ยวค่อยเก็บกวาด" = ไม่เก็บกวาดเลย

กับดักทางความคิดที่พบบ่อยสุด: "session นี้ไม่มีเวลาเก็บ เดี๋ยวค่อยทำทีหน้า"

แต่ session ถัดไปไม่รู้ว่าคุณทิ้งอะไรไว้, มันเห็นแต่โค้ดรกๆ และสถานะไม่แน่นอน มันจะใช้เวลาเดาว่า "โค้ดส่วนไหนตั้งใจ ส่วนไหนชั่วคราว"

ที่แย่กว่า: ทุก session มีเป้าหมายของตัวเอง session ใหม่มาเพื่อทำงานใหม่ ไม่ใช่เก็บกวาดของ session เก่า, มันจะเมินความรก แล้วทำงานใหม่ทับลงไป สร้างความรกเพิ่ม

ตัวเลขที่บ่งบอกทุกอย่าง: 12 สัปดาห์

โปรเจกต์พัฒนาโดย agent 12 สัปดาห์ เทียบ 2 แนวทาง [3]:

สัปดาห์	ไม่มี cleanup (build/test/startup)	มี cleanup (build/test/startup)
1	100% / 100% / 5 นาที	100% / 100% / 5 นาที
4	95% / 92% / 15 นาที	97% / 95% / 7 นาที
8	82% / 78% / 35 นาที	97% / 95% / 8 นาที
12	68% / 61% / 60+ นาที	97% / 95% / 9 นาที

หลัง 12 สัปดาห์: build pass rate ต่างกัน 29 จุดเปอร์เซ็นต์, startup time ต่างกัน 85%

วิธีทำ: 5 เทคนิค

เทคนิคเหล่านี้สรุปจากคอร์ส Learn Harness Engineering [3]:

1. Clean state เป็นเงื่อนไขบังคับของ "เสร็จ"

session เสร็จ = งานผ่าน verification AND clean state check ผ่าน, ขาดอย่างใดอย่างหนึ่ง = session ยังไม่เสร็จ

## Session Exit Checklist
- [ ] Build passes (npm run build)
- [ ] All tests pass (npm test)
- [ ] Feature list updated
- [ ] No debug code remaining (console.log, debugger, leftover markers)
- [ ] Standard startup path available (npm run dev)

2. ใช้ dual-mode cleanup

• Immediate cleanup (ท้ายทุก session): เก็บ artifact ชั่วคราว, อัปเดต feature list, ตรวจ build+test
• Periodic cleanup (รายสัปดาห์): scan ทั้งระบบ, จัดการ structural issue สะสม, อัปเดต quality document

3. เก็บ Quality Document

ไฟล์ active ที่ให้คะแนนคุณภาพแต่ละ module ต่อเนื่อง:

# Quality Document

## User Authentication Module (Quality: A)
- Verification passing: Yes
- Agent understandable: Yes
- Architecture boundaries: Compliant

## Payment Module (Quality: C)
- Verification passing: Partial (payment callback untested)
- Agent understandable: Difficult (logic spread across 3 files)
- Architecture boundaries: Violations present

session ใหม่อ่านแล้วรู้ทันทีว่าต้องจัดลำดับแก้ตรงไหนก่อน

4. ลดความซับซ้อนของ harness เป็นระยะ

ทุก harness component มีอยู่เพราะโมเดล "ยังทำเองไม่ได้" แต่พอโมเดลเก่งขึ้น assumption เหล่านี้ก็ล้าสมัย

Anthropic ทดลอง: ตอนแรก harness มีกลไก sprint-splitting (แบ่งงานเป็นชิ้นเล็กให้ Sonnet 4.5 ทำทีละชิ้น) พอ Opus 4.6 ออก โมเดลแยกงานเองได้แล้ว, ลบกลไกนั้นทิ้ง แล้ว builder agent ทำงานต่อเนื่อง 2 ชม. โดยไม่ drift

แนวปฏิบัติ: ทุกเดือนเลือก 1 component, ปิดชั่วคราว, รัน benchmark, ถ้าผลไม่แย่ลง ลบทิ้งถาวร

5. Cleanup ต้อง idempotent

สคริปต์ cleanup ต้องรันซ้ำได้ปลอดภัย:

rm -f /tmp/debug-*.log          # -f กัน error ตอนไฟล์ไม่มี
git checkout -- .env.local      # คืนสู่สถานะที่รู้จัก
npm run test                    # ตรวจว่า cleanup ไม่ทำอะไรพัง

ข้อควรระวัง: อย่าเก็บกวาดจนเกินพอดี

มีมุมที่ต้องระวังเช่นกัน: การเก็บกวาด "มากเกินไป" ก็มีต้นทุน

• Over-cleanup เสียเวลา, ทุก session ใช้เวลา 5 นาทีเก็บกวาด ดี แต่ถ้าใช้ 30 นาทีทำ cleanup ที่ไม่จำเป็น นั่นคือต้นทุนที่มากเกิน
• Harness ที่รก, บางที "ความรก" อยู่ใน harness เอง ไม่ใช่ codebase, การ simplify harness เป็นระยะ (เทคนิคข้อ 4) สำคัญพอๆ กับการเก็บโค้ด
• ไม่ใช่ทุก project ต้องทำทุกอย่าง, โปรเจกต์เล็ก 1 คน อาจไม่ต้องมี quality document เต็มรูปแบบ, เริ่มจาก checklist ง่ายๆ ก่อน

สรุปมุมมองของผม

ผมมองว่านี่คือ "วินัย" ที่แยกโปรเจกต์ที่อยู่รอด ออกจากโปรเจกต์ที่ค่อยๆ เน่า: entropy คือค่าเริ่มต้น, มีแค่การเก็บกวาดเชิงรุกเท่านั้นที่สวนมันได้

เพราะข้อมูลชัดเจน: 12 สัปดาห์โดยไม่เก็บกวาด build pass rate ร่วง 32 จุด, startup time พอง 12 เท่า, ขณะที่โปรเจกต์ที่เก็บกวาดสม่ำเสมอแทบไม่เสื่อมเลย

ถ้าคุณทำได้แค่ 2 อย่างนี้, ตั้ง session exit checklist + ทำ cleanup รายสัปดาห์, โปรเจกต์ของคุณจะไม่ค่อยๆ เน่าไปเรื่อยๆ

ตอนนี้คุณมี session exit checklist ใน repo ไหมครับ? แล้วคุณทำ cleanup โค้ดที่ agent สร้างบ่อยแค่ไหน? คอมเมนต์เล่าให้ฟังได้ครับ

แหล่งอ้างอิง

[1] OpenAI. "Harness Engineering: leveraging Codex in an agent-first world". 2026. https://openai.com/index/harness-engineering/

[2] Lehman. "Programs, Life Cycles, and Laws of Software Evolution". 1980. https://ieeexplore.ieee.org/document/1702314

[3] Learn Harness Engineering, Lecture 12. 2026. https://github.com/walkinglabs/learn-harness-engineering

---

บทความนี้วิเคราะห์จาก OpenAI, IEEE และ walkinglabs/learn-harness-engineering ข้อมูล ณ 23 สิงหาคม 2026 Nokka