ผมไปอ่านบทความของ Jaroslaw Wasowski เรื่อง How to write specs for AI แล้วรู้สึกว่าตรงกับสิ่งที่ผมทำอยู่ แต่ก็มีบางข้อน่าสนใจที่ผมต้องปรับเพิ่ม โดยเขาพูดตรงๆ ว่า หลายครั้งปัญหาไม่ได้อยู่ที่ model อย่างเดียว แต่อยู่ที่ spec ที่เราเขียนให้มันต่างหาก

เพราะ AI ไม่ได้อ่านใจเราออก ดังนั้นถ้าเราเขียน requirement แบบคลุมเครือ มันก็ไม่ได้หยุดแล้วถามเหมือน senior developer ที่นั่งข้างๆ แต่มันจะเดาต่อจาก pattern ที่มันเคยเห็นมาใน training data แล้วบางทีเดาได้เนียนมาก เนียนจนสรุปออกมา หรือ code ดูเหมือนจะถูกต้อง แต่การใช้งานผิด (เป็นเหตุผลว่าผมต้องมี skill ให้มันตั้งคำถามผมไปเรื่อยๆ นอกจากช่วยคิดแล้ว ผมใช้เพื่อคอยเช็กความเข้าใจของมัน)

หมายเหตุ: บทความนี้อ้างอิงจากประสบการณ์ฟิวส์กับเอเจ้นชมพู เพื่อเรียบเรียงและแปลจากต้นฉบับของ Jaroslaw Wasowski เรื่อง How to write specs for AI: 7 rules and a checklist for better code

ปัญหาไม่ใช่แค่ AI เขียนโค้ดผิด แต่คือมันไม่รู้ว่าอะไรห้ามเดา

ตั้งแต่ปีก่อนที่ vibe code มาใหม่ๆ จนถึงปัจจุบัน เรามักใส่ความต้องการของเราว่าอยากได้อะไร แต่ไม่ได้ใส่ว่ามันห้ามทำอะไร

ซึ่งประโยคที่ผมชอบที่สุดในบทความนี้คือ AI ไม่มีสถานะว่า “อันนี้ไม่แน่ใจ ขอถามเพิ่มก่อน” เวลา requirement ขาดอะไรไป มันจะไม่หยุด และมันจะเติมเอง

สิ่งที่ไม่อยู่ spec เราในตอนแรก แต่จู่ๆ มันก็โผล่มา เพราะ AI จะเอา pattern จาก training data มาเติมแทนเจตนาของเรา (ซึ่งอาจจะผิด)

นี่แหละครับที่น่ากลัว เพราะ code ที่ออกมาอาจ compile ผ่าน, test ผ่าน หน้าตาดูดี แต่จริงๆ มันกำลังทำระบบที่มีการใช้งานหรือ behavior คนละแบบกับที่เราต้องการ

เหมือนเราจ้างช่างมาทำบ้าน แล้วบอกแค่ว่า “ทำครัวให้ดีๆ หน่อย” ถ้าช่างทำครัวสวยมาก แต่ไม่มีปลั๊ก ไม่มีที่วางเตา หรือเปิดประตูตู้แล้วชนผนัง ปัญหาไม่ได้อยู่ที่ช่างไม่ขยันอย่างเดียว แต่อยู่ที่แบบบ้านของเราก็ไม่ได้บอกอะไรเขาเลย (อยากได้ครัวฝรั่งเตาไฟฟ้า แต่เอไอตั้งเตาอั่งโล่มาให้เพราะสเปกบอกว่ามีเตา 555)

Spec ที่ดีต้องปิด 5 เรื่อง ที่ AI ชอบเดาเอง

บทความนี้สรุป 5 เรื่องหลักๆ ซึ่งผมว่าตรงนี้เอาไปใช้กับ Jira ticket, GitHub/GitLab issue, Markdown spec หรือ prompt ตรงๆ ได้เลย

1. Outcome ต้องชัดว่าอยากได้พฤติกรรมอะไร

เริ่มจากบอกผลลัพธ์ที่ต้องการ ไม่ใช่บอกให้มันไปเขียน code แบบกว้างๆ เช่น แทนที่จะบอกว่า “ทำ endpoint export users เป็น CSV” ให้บอกว่า “endpoint นี้ต้องคืน active users เป็นไฟล์ CSV ที่ download ได้” และต้องมีเงื่อนไขความสำเร็จอะไรบ้าง (ภาษาเทคนิคจะเรียกว่า Acceptance Criteria)

จุดนี้ช่วยแยก what ออกจาก how ได้ดีมาก เพราะ AI จะได้ไม่รีบเลือก implementation pattern ที่มันคุ้น แต่เริ่มจาก behavior ที่เราต้องการก่อน

2. Scope กับ non-goals ต้องเขียนคู่กัน

อันนี้ผมว่าเป็นจุดที่หลายคนพลาด รวมถึงผมเองก็เคยและก็ยังพลาดบ่อย เราชอบเขียนว่า change นี้ต้องทำอะไร แต่ไม่ค่อยเขียนว่า change นี้ไม่ต้องทำอะไร

เช่น ถ้าให้ AI ทำ export users ก็ควรบอกไปเลยว่า export เฉพาะ active users เท่านั้น ไม่ export deleted accounts ไม่ export billing data และไม่แก้ database schema

เพราะถ้าไม่บอก มันอาจ “ใจดี” เพิ่ม feature ให้เอง ซึ่งฟังดูดี แต่ทำให้ diff บวม และบางทีไปแตะของที่ไม่ควรแตะ

จากประสบการณ์ผมเองที่สังเกต โมเดลฉลาดๆ อย่าง Claude Opus 4.8+ / ChatGPT 5.5+ มักจะบอกเลยว่า ผมจะทำสิ่งนี้ แต่ไม่ทำสิ่งนี้เพราะจะกระทบอะไรก็ว่าไป ซึ่งมันไม่เป็นกับบางโมเดลอื่นๆ ตรงนี้เราโดนพวก Frontier Model สปอยจนมองข้ามไป ฮ่าๆ

3. Constraints คือรั้วกัน AI หลุดโลก

AI ไม่ได้รู้จัดโค้ดทั้ง repo ของเราจริงๆ ถ้าเราไม่ได้ให้ context มันแต่แรก, มันไม่รู้ว่าใช้ framework เวอร์ชันไหน มี convention อะไร library ไหนห้ามใช้ response format ต้องเป็นแบบไหน หรือ performance limit คือเท่าไร (แต่ก็ได้ยินบ่อยจากคนรอบข้าง (ระดับมหาราชา/มหาราชินี) คือให้ AI อ่านโค้ดทั้ง repo ก่อนเลย)

ดังนั้น constraints ควรมีของพวกนี้:

• stack และ version ที่ใช้
• repo convention ที่ต้องตาม
• library ที่ใช้ได้หรือห้ามใช้
• output format เช่น UTF-8, JSON shape, CSV delimiter
• security หรือ performance limit
• integration boundary เช่นห้ามแก้ schema หรือห้ามกระทบ API เดิม

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

4. Acceptance criteria ต้องพิสูจน์ได้ ไม่ใช่แค่ฟังดูดี

คำว่า “ใช้งานได้ดี” หรือ “make it work nicely” เป็นประโยคที่น่ากลัวมากสำหรับ AI เพราะมันไม่มีทางรู้ว่า nicely ของเราคืออะไร ดังนั้นเราต้องบอกมันว่า เงื่อนไขการรับงาน (Acceptance criteria) ของเราคืออะไร

ซึ่ง Acceptance criteria ที่ดีควรเป็นแบบตรวจสอบได้ เช่น:

• ถ้ามี active users 3 คน ต้องได้ CSV 3 data rows และ header 1 แถว
• ถ้าไม่มี users ต้องได้ header อย่างเดียวและ status 200
• ถ้า user ไม่มี admin role ต้องได้ 403 และไม่ส่ง CSV body
• ถ้ามีข้อมูล 50,000 records ต้องใช้ streaming และ response ไม่เกินเวลาที่กำหนด

ถ้าไม่มีเกณฑ์ตรวจสอบได้ (ไม่ว่าจะมนุษย์ไม่เขียน หรือเอไอไม่ทำให้) ยังถือว่าเป็น Draft Requirement ไม่ใช่ Requirement จริง

เพราะการที่ Spec มี acceptance criteria มันจะเปลี่ยนจากคำอธิบายสวยๆ ให้กลายเป็น Goal ที่ AI ทำให้สำเร็จ และระบบเราจะใช้งานได้ตามที่ต้องการ

5. Edge case กับ failure path ต้องมีตั้งแต่ก่อนเขียน code

Happy path เป็นแค่ส่วนหนึ่งของ production เท่านั้น แต่ spec จำนวนมากเขียนเหมือนโลกมีแต่ happy path ฮาาา

อย่างน้อย spec ที่ส่งให้ AI ควรมี:

• error path 1 กรณี
• edge case 1 กรณี
• empty state หรือ permission case 1 กรณี

เพราะถ้าเราไม่เขียน มันจะเดาวิธี handle error จาก pattern ที่มันเห็นบ่อย ซึ่งอาจไม่ตรงกับระบบเราเลย

Checklist ก่อนโยนงานให้ AI coding agent

ผมลองเอาแนวคิดในบทความมาจัดเป็น checklist table แบบที่น่าจะใช้จริงกับงานประจำวันได้ประมาณนี้ครับ

checklist นี้ไม่ได้บอกให้เขียน spec ยาวเสมอไป แต่มันบอกให้ AI เขียน spec แบบเดาน้อยลง

Spec ไม่ได้ต้องยาว แต่ต้องมี signal พอ

บทความต้นฉบับใช้คำว่า signal redundancy matched to complexity ซึ่งผมแปลแบบบ้านๆ ว่า รายละเอียดต้องพอดีกับความเสี่ยงของงาน

ถ้าแค่แก้ margin หรือเปลี่ยน text เล็กๆ จะเขียน spec ยาว 3 หน้า ก็อาจเกินไป แต่ถ้างานแตะ authorization, payment, data integrity, migration, report export หรือ performance ตรงนี้ผมว่าไม่ควรประหยัด spec

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

Workflow ที่ผมคิดว่าเอาไปใช้ได้ทันที

ถ้าจะเอาเรื่องนี้ไปใช้กับทีม software จริงๆ ผมคิดว่าไม่ต้องเริ่มจาก process ใหญ่โต แต่เริ่มจากงานหนึ่งชิ้นก่อนก็พอ

1. เลือก feature หรือ change ที่มีขอบเขตงานและโค้ดชัดเจน (boundary)
2. เขียน spec ให้มี 5 เรื่องหลัก: outcome, scope, constraints, acceptance criteria, edge cases
3. review spec ก่อนให้ AI ลงมือ
4. ให้ AI implement พร้อม test
5. ถ้า test fail หรือ reviewer ต้องถามเพิ่ม ให้กลับไปแก้ spec ก่อน ไม่ใช่แค่สั่ง AI แก้ code ไปเรื่อยๆ

จุดนี้ผมว่ามันต่อกับแนวคิด Spec-Driven Development มาก คือ spec ไม่ใช่เอกสารประกอบงาน แต่เป็น contract ของงาน ถ้า code กับ spec ขัดกัน ต้องถามก่อนว่า spec ยังถูกไหม ไม่ใช่ปล่อยให้ code ที่ AI generate มาเป็นความจริงใหม่ของระบบ

ข้อสุดท้ายสำคัญมาก และทำให้ Spec มีการอัพเดทตลอดเวลา (หรือที่เรียกว่า Living documentation)

เรื่องที่ต้องระวัง อย่าเอา checklist ไปทำให้ทีมเหนื่อยกว่าเดิม

ถึงผมจะชอบ checklist นี้มาก แต่ก็ไม่คิดว่าต้องใช้เต็มรูปแบบกับทุกงานนะครับ

ถ้าเป็น bug fix เล็กๆ ที่ test เดียวพิสูจน์ได้ หรือ prototype ที่ตั้งใจ throw away อยู่แล้ว การเขียน spec ยาวอาจไม่คุ้ม

อีกอย่างคือ spec ที่ดีไม่ได้แก้ทุกปัญหา AI ยังพลาดได้จาก model limitation, context retrieval ไม่ครบ, repo ใหญ่เกินไป หรือระบบเดิมซับซ้อนจน spec อธิบายไม่หมด

ดังนั้นอย่าใช้ checklist นี้เป็นพิธีกรรมใหม่ของทีม แต่ใช้เป็นเครื่องมือถามตัวเองว่า “งานนี้มีอะไรที่ AI ไม่ควรเดาเองบ้าง”

สรุปแบบฟิวส์ๆ

สิ่งที่ผมได้จากบทความนี้คือ AI ไม่ได้ทำให้ requirement หายไป แต่มันทำให้ requirement ที่คลุมเครือส่งผลแรงขึ้นกว่าเดิม

เมื่อก่อนถ้า requirement คลุมเครือ senior developer อาจถามกลับ หรืออย่างน้อยก็รู้จาก context ของระบบว่าอะไรควรทำไม่ควรทำ แต่ AI coding agent ไม่ทำแบบนั้น ถ้าเราไม่บอก มันจะเดา

และบางครั้งมันเดาแบบมั่นใจมากด้วยว่าจะถูก!

ยิ่ง AI เขียน code เร็วเท่าไร เราก็ยิ่งต้องเขียนให้ชัดขึ้นเท่านั้นครับ

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

• How to write specs for AI: 7 rules and a checklist for better code โดย Jaroslaw Wasowski, Level Up Coding

แนวคิดที่ Anthropic ยกมาคือ ให้ Sonnet 5 เป็น executor ทำงานหลักใน loop ปกติ แล้วให้ Fable 5 เป็น advisor ที่ถูกเรียกเฉพาะตอนต้องใช้ judgment สูง เช่น วางแผน ตัดสินใจ architecture แก้ทางเมื่อเริ่มหลุด หรือ review ก่อนจบงาน ผมว่ามันเป็น pattern ที่ practical มาก เพราะมันไม่ได้พยายามลดคุณภาพด้วยการใช้โมเดลเล็กอย่างเดียว แต่ใช้โมเดลฉลาดให้ถูกจังหวะมากกว่า

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพูช่วยกันเรียบเรียง โดยอิงจากโพสต์ของ ClaudeDevs บน X, เอกสาร Advisor tool ของ Anthropic และ Claude Cookbook แล้วนำมาตีความเป็นแนวทางใช้งานจริงสำหรับคนทำ AI agent / coding agent

ต้นทางของเรื่องนี้สรุปไว้สั้นมากว่า หนึ่งใน pattern ที่ Anthropic ใช้กับ Fable 5 คือ “ใช้ Fable 5 เป็น advisor” โดย executor อย่าง Sonnet 5 จะเรียก Fable 5 เพื่อขอคำแนะนำ ดังนั้นการทำงานส่วนใหญ่จะใช้ token ไปกับ executor ที่ Sonnet 5 ทำมากกว่า

ต้องเข้าใจก่อนว่า agent workload ไม่ต้องใช้โมเดลฉลาดทุกงาน

เวลาพูดถึง AI coding agent หรือ agent ที่ทำงานหลาย step ผมคิดว่าหลายคนมักติดกับดักว่า “ใช้โมเดลฉลาดสุดไปเลยจะได้จบ” ซึ่งจริงในบางงาน แต่ไม่จริงเสมอไป โดยเฉพาะงานยาวๆ ที่มี token จำนวนมากถูกใช้ไปกับงาน mechanical มากกว่า reasoning

ในงานหนึ่งๆ มักมี 2 ส่วนปนกัน:

• ส่วนที่ต้องคิดจริง: แตกโจทย์, ตีความ requirement, เลือก architecture, ประเมิน trade-off, หาทางออกตอนติดปัญหา
• ส่วนที่ต้องทำเยอะ: อ่านไฟล์, อ่านเว็บ, grep โค้ด, ดู log, แก้ไฟล์, รัน test, สรุป output จาก tool

ถ้าใช้โมเดลระดับ frontier ทำทั้งสองส่วนทั้งหมด ก็โครตจะเปลือง token เลยครับ เพราะถูกใช้ไปกับงานทั่วไปที่ไม่ต้องการ frontier reasoning ทุกบรรทัด เช่น อ่านหน้าเว็บยาวๆ หรือไล่ log หลายพันบรรทัด ตรงนี้เองที่ทำให้ค่าใช้จ่ายสูงโดยไม่จำเป็น

ผมขอเปรียบให้เห็นภาพง่ายๆ เหมือนเอา senior engineer ไปนั่งอ่าน log ทุกบรรทัดเอง ซึ่งงานเขาควรเข้ามาตอนวางทิศทาง ตรวจจุดเสี่ยง หรือช่วยตัดสินใจเรื่องที่ถ้าผิดแล้วจะเสียเวลาเยอะ ส่วนงานอ่าน/เก็บข้อมูล/ทำตามขั้นตอนให้คนที่เร็วกว่าและต้นทุนต่ำกว่าช่วยทำได้

หรือเทียบในงานก่อสร้าง ก็เหมือนเอาวิศะไปก่ออิฐฉาบปูนแทนคนงานก่อสร้าง แทนที่วิศวะจะออกแบบ วางแผน และคนงานจะเป็นคนทำ

เแนวคิด: Sonnet 5 เป็นคนทำงานหลัก ส่วน Fable 5 เป็นคนให้คำปรึกษา

จาก diagram ในโพสต์ของ ClaudeDevs โครงสร้างคือ Sonnet 5 ทำหน้าที่ executor และรัน main loop ทุก turn ส่วน Fable 5 เป็น advisor ที่ถูกเรียกผ่าน tool call เฉพาะเมื่อจำเป็น พูดง่ายๆ คือ Sonnet ทำงานหนัก แต่ Fable ช่วยคิดตอนที่ต้องคิดอย่างมีเหตุมีผล

เอกสาร Advisor tool ของ Anthropic อธิบายแนวคิดนี้ว่า executor model ที่เร็วกว่า/ต้นทุนต่ำกว่า สามารถ consult advisor model ที่ฉลาดกว่า mid-generation ได้ โดย advisor จะเห็น conversation transcript ทั้งหมด แล้วส่งคำแนะนำกลับมาให้ executor ทำงานต่อ

จุดที่ผมว่าสำคัญคือ advisor ไม่ได้มาแทน executor แต่เป็นเหมือน reviewer หรือ architect ที่ถูกเรียกในจังหวะที่ควรเรียก ทำให้เรายังได้คุณภาพจากโมเดลใหญ่ในการตัดสินใจสำคัญๆ แต่ไม่ต้องจ่ายราคาโมเดลใหญ่กับทุกการทำงานง่ายๆ หลายงาน

แล้ว Advisor tool ทำงานยังไง?

เมื่อเราเพิ่ม advisor tool เข้าไปใน tools array แล้ว ตัว executor จะตัดสินใจเองว่าจะเรียก advisor เมื่อไรเหมือน tool อื่นๆ แต่การ call นี้เกิดฝั่ง server ภายใน request เดียว ไม่ใช่ client ต้อง orchestration เองหลายรอบ

• executor สร้าง server_tool_use ชื่อ advisor
• server ส่ง transcript ทั้งหมดให้ advisor model
• advisor ส่งคำแนะนำกลับมาเป็น advisor_tool_result
• executor ใช้คำแนะนำนี้ทำงานต่อจนจบ

ตัวอย่างแบบย่อจากเอกสาร Anthropic:

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    betas=["advisor-tool-2026-03-01"],
    tools=[
        {
            "type": "advisor_20260301",
            "name": "advisor",
            "model": "claude-opus-4-8",
        }
    ],
    messages=[
        {
            "role": "user",
            "content": "Build a concurrent worker pool in Go with graceful shutdown.",
        }
    ],
)

ถ้านำ concept นี้มาเทียบกับโพสต์ Fable 5 ภาพในหัวจะประมาณนี้:

tools=[
    {
        "type": "advisor_20260301",
        "name": "advisor",
        "model": "claude-fable-5",
        "max_tokens": 2048,
        "max_uses": 2,
    }
]

ตรงนี้ max_tokens กับ max_uses สำคัญมาก เพราะถ้าเปิด advisor ไว้แบบไม่จำกัด มันอาจกลายเป็น “เรียกโมเดลแพงบ่อยขึ้น” แทนที่จะช่วยประหยัด token

วิธีใช้ให้ประหยัด token จริง

1. ให้ executor อ่านบริบทก่อน แล้วค่อยเรียก advisor

ผมคิดว่าเราไม่ควรเรียก Fable 5 ตั้งแต่ครั้งแรกที่ยังไม่รู้อะไรเลย เพราะคำแนะนำจะกว้างเกินไป วิธีที่ดีกว่าคือให้ Sonnet 5 อ่านทำความเข้าใจบริบทแรกของเราก่อน เช่น requirement, โครง repo, error log หรือไฟล์หลัก แล้วค่อยเรียก Fable 5 เพื่อช่วยวางแผน

2. ใช้ advisor ในจุดที่ตัดสินใจผิดแล้วแพง

จุดที่คุ้มจะเรียก advisor คือจุดที่ถ้าคิดผิดแล้วต้องแก้งานเยอะ เช่น:

• เลือก architecture หรือ migration strategy
• ตีความ requirement ที่กำกวม
• เจอ test fail ซ้ำๆ แล้วแนวทางเดิมแก้ไม่ได้ หรือไม่ครอบคลุม
• ก่อนจบงาน เพื่อ review ว่าหลุด security, edge case หรือ test อะไรไหม

3. จำกัดจำนวนครั้งด้วย max_uses

ถ้างานหนึ่งควรเรียก advisor แค่ 1–2 ครั้ง ก็ตั้ง max_uses ไว้เลย จะช่วยไม่ให้ executor เรียก advisor ถี่เกินไปใน request เดียว

4. จำกัดคำตอบของ advisor ด้วย max_tokens

เอกสาร Anthropic แนะนำจุดเริ่มต้นที่ max_tokens: 2048 สำหรับ advisor output cap โดยระบุว่าในการทดสอบของเขา การตั้ง cap นี้ลด output ของ advisor ได้มากเมื่อเทียบกับการไม่ตั้ง และยังไม่เห็นว่าคุณภาพลดลงเท่าไรอย่างชัดเจน (quality degradation) แต่ประโยคสำคัญคือ เราต้องตรวจสอบกับ workload ของตัวเองเสมอนะ เพื่อป้องกันความผิดพลาด เนื่องจากจำกัด token (ผมเคยเจอบ่อยว่า output งานออกมาได้ไม่ถูกต้อง หรือโค้ดไม่ครบ)

5. เปิด caching เฉพาะงานที่เรียก advisor หลายครั้ง

ใน docs ระบุว่า advisor-side caching จะเริ่มคุ้มเมื่อคาดว่าจะมี advisor call ประมาณ 3 ครั้งขึ้นไปใน conversation เดียว ถ้างานสั้นๆ เรียกครั้งเดียวหรือสองครั้ง การเปิด cache อาจไม่คุ้ม เพราะ cache write ก็มีต้นทุนของมันเอง

อีกแนวคิดที่คล้ายกัน คือ Plan big, execute small

ใน Claude Cookbook เรื่อง Coordinator pattern Anthropic อธิบายอีก pattern ที่คล้ายกันมาก คือให้โมเดลใหญ่เป็น coordinator สำหรับวางแผนและสังเคราะห์คำตอบ ส่วน worker model ที่ถูกกว่าเป็นคนอ่านเว็บหรือดึงข้อมูลจำนวนมากใน context ของตัวเอง

ในการทดลองที่ Anthropic ยกตัวอย่าง ทีมแบบ split ราคาจะถูกลงกว่าประมาณ 2.5x และทำงานเร็วขึ้นประมาณ 3x โดยจำนวน input token 84–98% ถูกคิดที่ worker ที่ใช้ราคา Token ถูกกว่า

แต่ๆๆ เขาบอกว่า นี่แค่ตัวอย่างนะ อย่าเอาตัวเลขนี้ไปใช้อ้างอิงว่าทุกงานจะประหยัดเท่านี้ เพราะมันขึ้นกับ workload แต่ละงาน

แต่โครงสร้างวิธีการทำแบบนี้ก็ชัดเจนดี คือ งานอ่านเยอะๆ ให้ worker ทำ ส่วนโมเดลใหญ่แตะเฉพาะ planning/synthesis

จากที่อ่าน ถ้าผมจะใช้จริง จะวาง flow แบบนี้

1. เริ่มด้วย Sonnet 5: ให้ทำงานหลัก อ่านไฟล์ เรียก tool แก้โค้ด รัน test
2. Orientation: เก็บบริบทขั้นต่ำก่อน เช่น requirement, repo structure, error หลัก
3. Advisor call แรก: เรียก Fable 5 ให้ช่วยวางแผนและชี้ risk
4. Execute: ให้ Sonnet 5 ลงมือทำตาม plan โดยไม่เรียก advisor ทุกจุด
5. Replan เมื่อจำเป็น: ถ้า error วนหรือทางเดิมไม่ไปต่อ ค่อยเรียก Fable 5 อีกครั้ง
6. Review ก่อนจบ: เรียก advisor ช่วยดูว่าตกหล่น test, security, edge case หรือ assumption อะไรไหม
7. Finish: ให้ executor สรุปผลพร้อม evidence จาก test/diff/tool output

ต้องบอกว่า ผมยังแค่คิดนะ เพราะยังไม่มีโจทย์ซับซ้อนพอที่จะใช้ Fable ทำงาน และยังไม่อยากลองรันเทียบ เพราะต้องทำหลายครั้ง อาจจะเสีย Token เยอะ ฮาา, ไว้รอมีผลการทดสอบจากผู้กล้า หรือได้ลองจริงๆ แล้วจะเอามาเล่าให้ฟังอีกที หรือหากใครลองแล้วก็มาแชร์กันหน่อยครับ

ข้อควรระวัง

• งานเล็กมากอาจไม่คุ้ม: ถ้าเป็น single-turn Q&A หรือแก้ typo เล็กๆ advisor อาจเพิ่ม overhead มากกว่าประโยชน์
• ต้องวัดกับ workload จริง: ตัวเลขประหยัด token ไม่ใช่ค่าคงที่ ขึ้นกับชนิดงานและความยาวของ context
• อย่าแตกงานย่อยจนเกินพอดี: ใน cookbook เองก็เตือนว่าการแตก brief แคบเกินไปมี floor cost ของ worker thread (ขออธิบายเพิ่มเติมครับ: มันคือต้นทุนขั้นต่ำต่อ worker thread หมายถึง ทุกครั้งที่สร้าง worker หรือ sub-agent ใหม่ มันมี “ต้นทุนตั้งต้น” เสมอ ไม่ว่าจะงานเล็กหรือใหญ่ เช่น เปิด session ,รับ prompt, อ่าน context, เรียก Skill)
• advisor แก้โจทย์เท่าที่ได้รับจาก context: ถ้า executor ยังไม่ได้อ่านของสำคัญก่อนเรียก advisor คำแนะนำก็อาจกว้างหรือผิดทิศได้ เช่นเราใส่บริบทไม่ครบหรือไม่เข้าใจให้ advisor เองแต่แรก (นั่นคือเหตุผลของ Anthopic ว่าทำไมไม่ควรเอาตัวฉลาดมารับงานก่อน)
• ต้อง track cost แยก: usage ของ advisor อยู่ใน usage.iterations เป็น advisor_message เพราะถูก bill คนละ rate กับ executor

ผมขอขยายความข้อสุดท้ายนิดนึงคือ มันไม่สามารถคิด token cost แบบ usage.input_tokens + usage.output_tokens ทั่วไปนะ เพราะอาจจะเข้าใจผิดคิดว่าแพงทั้งหมด แต่ควรคิดจาก

total_cost = executor_tokens × ราคา Sonnet 5 + advisor_tokens × ราคา Fable 5

ดังนั้น ใน Anthropic API ที่ส่งค่า usage.iterations กลับมา เราต้องคิดราคาแยกตาม type ด้วย ว่าอะไรคือ executor (message) และอะไรคือ advisor (advisor_message)

สรุป

ผมคิดว่า “Fable 5 เป็น advisor” เป็นแนวทางที่น่าลองมากสำหรับ agent workflow ที่เราจะให้มันทำงานยากๆ หรือต้องใช้การตัดสินใจอย่างมีเหตุมีผลสูงมาก ส่วนงานง่ายๆ อย่างการ อ่าน/ทำ/ตรวจซ้ำ ก็ให้ใช้โมเดลรองๆ ลงมา ทำก็คิดว่าเพียงพอแล้ว (อย่างน้องชมพูที่ผมให้แชต ก็ใช้แค่ ChatGPT mini แต่หาข้อมูลและเขียนบทความ ผมจะใช้ ChatGPT ปกติ

อ้างอิง

• ClaudeDevs on X — Fable 5 as advisor pattern
• Anthropic Claude Platform Docs — Advisor tool
• Anthropic Claude Cookbooks — Coordinator pattern: big models for planning, small models for execution

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

ผมเลยอยากเอาบทความนี้มาเล่าในมุมที่นำไปต่อยอดได้จริง โดยเฉพาะสำหรับคนที่กำลังสนใจเรื่อง AI Agent, coding agent, workflow automation หรือระบบที่ให้ AI ทำงานต่อเนื่องแทนการ prompt ทีละครั้ง

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพู ได้เรียบเรียงและต่อยอดจากบทความต้นฉบับของ Anthropic Engineering เรื่อง Harness design for long-running application development เขียนโดย Prithvi Rajasekaran

Harness คืออะไรในบริบทของ AI Agent

ถ้าแปลแบบง่ายๆ harness คือชุดเครื่องมือที่หุ้ม AI Agent อีกทีเพื่อให้มันทำงานได้เป็นระบบ ไม่ใช่แค่โยน prompt ให้ model แล้วหวังว่ามันจะทำทุกอย่างถูกต้องเอง

ซึ่งในโลกของการเขียนโปรแกรม เรามักคุ้นกับ test harness หรือ automation harness อยู่แล้ว คือชุดเครื่องมือที่ช่วยรัน ทดสอบ ตรวจผล และคุมการทำงานบางอย่างให้เป็นระบบ พอมาอยู่ในโลกของ AI Agent แนวคิดก็คล้ายกัน แต่ขยายใหญ่กว่าเดิม

Harness ของ AI Agent อาจรวมหลายอย่าง เช่น

• วิธีแตกงานใหญ่ให้เล็กลง
• วิธีให้ agent วางแผนก่อนลงมือทำ
• วิธีเก็บ state ของงานไว้นอก context window
• วิธีส่งต่องานระหว่าง agent หรือ session
• วิธีตรวจคุณภาพของงานที่ทำเสร็จ
• วิธีบังคับให้ agent แก้ไขงานตาม feedback
• วิธีหยุดงานเมื่อถึงเงื่อนไขบางอย่าง

พูดอีกแบบคือ ถ้า model คือสมอง harness ก็คือระบบการทำงานรอบสมองนั้น

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

จริงๆ ลองทดสอบได้ง่ายๆ ครับ ถ้าเอา prompt ใส่ใน Claude Web ตั้งโมเดลเป็น Opus 4.8 กับใส่ในระบบแชตแจกฟรีเช่น Langflow โดยต่อโมเดล Opus 4.8 ผ่าน Claude API, คำตอบที่ได้ออกมาจะไม่เหมือนกัน แม้ว่าใช้สมอง Opus 4.8 เหมือนกัน (เรื่องนี้ 9arm ก็มีเล่าให้ฟังตอนทำ 9arm AI Passport)

ปัญหาของ Agent ที่ให้ทำงานยาวๆ

บทความนี้เริ่มจากโจทย์ที่ Anthropic ทดลองอยู่ 2 เรื่อง คือทำให้ Claude สร้าง frontend design ที่มีคุณภาพสูงขึ้น และทำให้ Claude สร้าง application เต็มรูปแบบได้โดยไม่ต้องมีมนุษย์เข้าไปช่วยระหว่างทาง

สองงานนี้ดูเหมือนคนละเรื่อง งานแรกเป็นเรื่องรสนิยมและความสวยงาม งานหลังเป็นเรื่องซอฟต์แวร์ที่ใช้งานได้จริง แต่ทั้งคู่มีปัญหาร่วมกันอย่างหนึ่ง คือถ้าให้ AI ทำงานยาวๆ แบบ naive เกินไป คุณภาพจะเริ่มแกว่ง

1. Context เต็มแล้วเริ่มหลุด

งานที่ยาวหลายชั่วโมงจะมีข้อมูลสะสมเยอะมาก ตั้งแต่ requirement, decision, bug, code, test result, feedback ไปจนถึงสิ่งที่ลองแล้วไม่เวิร์ก ถ้าทุกอย่างถูกกองอยู่ใน context window เดียว สุดท้าย agent จะเริ่มจับประเด็นไม่ครบ

Anthropic ยังพูดถึงอาการที่น่าสนใจชื่อว่า context anxiety คือ model เริ่มเหมือนรู้ตัวว่าบริบทใกล้เต็ม แล้วพยายามรีบ wrap up งานก่อนเวลา ทั้งที่งานจริงยังไม่เสร็จดี

ปัญหานี้ผมว่าคนที่ใช้ coding agent น่าจะเจอบ่อย บางทีมันทำงานดีมาตลอด แต่พอท้ายๆ เริ่มสรุปเองว่าทุกอย่างเรียบร้อย ทั้งที่ test ยังไม่ครบ หรือยังมี TODO ค้างอยู่

2. Agent มักตรวจงานตัวเองใจดีเกินไป

อีกปัญหาหนึ่งที่ตรงมากคือ self-evaluation

เวลาถาม agent ว่างานที่ตัวเองทำดีไหม มันมักตอบว่าดี ใช้ได้ พร้อมแล้ว หรือใกล้เสร็จแล้ว ทั้งที่ถ้ามนุษย์ลองใช้งานจริงอาจเห็นเลยว่ามีหลายจุดยังไม่ดีพอ

งาน coding ยังพอมี test ช่วยจับได้บ้าง แต่งานอย่าง design, UX, product completeness หรือบทความนี่ตรวจยากกว่าเยอะ เพราะไม่มีคำตอบแบบ pass/fail ชัดเจน

Anthropic เลยใช้แนวทางแยก agent ที่สร้างงาน ออกจาก agent ที่ตรวจงาน ซึ่งผมคิดว่าเป็น pattern ที่ควรใช้จริงในระบบ agent ที่ต้องการคุณภาพ

แนวคิดหลัก: Planner, Generator, Evaluator

โครงสร้างที่บทความนี้พูดถึงคือการแบ่ง agent ออกเป็น 3 บทบาทหลัก

ถ้ามองในเชิงทีมซอฟต์แวร์ มันก็คล้ายๆ การแยก role ในทีมจริง

• Planner ทำหน้าที่คล้าย product/tech lead
• Generator ทำหน้าที่คล้าย developer
• Evaluator ทำหน้าที่คล้าย QA, reviewer และ product tester

ข้อดีคือเราไม่ต้องหวังให้ agent ตัวเดียวทำทุกอย่างเก่งหมด เพราะในความเป็นจริง มนุษย์เองก็ยังไม่ค่อยทำงานแบบนั้น เรามีคนคิด คนทำ คนตรวจ และ feedback loop ที่ทำให้งานดีขึ้น

ทำเรื่อง subjective ให้ตรวจได้

ส่วนที่ผมชอบมากในบทความคือการทดลองกับ frontend design เพราะ design เป็นเรื่องที่วัดยาก

Anthropic พบว่า Claude มักสร้าง UI ที่ technically ใช้งานได้ แต่ดู generic มาก เช่น layout ปลอดภัย card เยอะๆ gradient เดิมๆ หรือหน้าตาที่ดูเหมือน AI สร้างแบบไม่มี character

เขาเลยสร้าง evaluator ที่มี criteria ชัดเจน เช่น

• Design quality งานดูเป็นภาพรวมเดียวกันไหม
• Originality มีความคิดสร้างสรรค์จริงไหม หรือเป็น template
• Craft typography, spacing, contrast, color harmony ดีไหม
• Functionality ผู้ใช้เข้าใจและใช้งานได้จริงไหม

จุดสำคัญคือเขาไม่ได้ถามกว้างๆ ว่า “สวยไหม” แต่แตกคำว่าสวยให้กลายเป็น rubric ที่ตรวจได้

ผมว่านี่เอาไปใช้กับงานอื่นได้เยอะมาก เช่นบทความดีไหม requirement ชัดไหม dashboard ใช้งานง่ายไหม หรือแม้แต่ระบบ automation ที่ agent สร้างขึ้นมามี failure mode อะไรบ้าง ถ้าเราไม่มี rubric evaluator ก็จะตอบกว้างๆ และหลุดง่าย

Context Reset ไม่ใช่แค่ล้างแชท แต่ต้องมี Handoff

อีกเรื่องที่สำคัญมากคือ structured handoff

ถ้า agent ทำงานยาวจนต้องเริ่ม session ใหม่ หรือให้ agent ตัวใหม่มารับช่วงต่อ เราไม่ควรส่งต่อด้วย chat history ยาวๆ อย่างเดียว แต่ควรมี artifact ที่สรุปสถานะงานอย่างเป็นระบบ

handoff ที่ดีควรบอกอย่างน้อยว่า

• เป้าหมายของงานคืออะไร
• ทำอะไรเสร็จแล้ว
• ไฟล์ไหนถูกแก้
• คำสั่งไหนรันแล้ว
• ผลลัพธ์จริงคืออะไร
• ยังเหลือปัญหาอะไร
• next step คืออะไร

ถ้าเป็นงาน coding ก็ควรมี test result, git diff, known issue และคำอธิบาย decision ที่สำคัญด้วย

ในมุมผม นี่คือจุดที่ทำให้ agent system เริ่มจริงจังขึ้นมาก เพราะเราเริ่มย้าย source of truth จาก “บทสนทนา” ไปอยู่ใน “artifact” ที่อ่านซ้ำได้ ตรวจได้ และส่งต่อได้

Sprint Contract: ก่อนทำ ต้องรู้ก่อนว่า Done คืออะไร

อีกไอเดียที่น่าสนใจคือก่อนแต่ละ sprint ให้ Generator และ Evaluator ตกลงกันก่อนว่า sprint นี้จะทำอะไร และจะตรวจยังไงถึงเรียกว่าสำเร็จ

ผมมองว่านี่คือ acceptance criteria สำหรับ agent โดยเฉพาะ

ถ้าให้ agent “สร้างระบบ task management” เฉยๆ มันอาจทำหน้าจอสวย แต่ข้อมูลไม่ persist หรือ filter ใช้ไม่ได้ แต่ถ้ามี sprint contract เช่น

• สร้าง task ได้
• แก้สถานะ task ได้
• filter ตาม status ได้
• refresh แล้วข้อมูลยังอยู่
• Evaluator ต้องทดสอบผ่าน browser จริง

แบบนี้งานจะตรวจได้ชัดขึ้นมาก และลดโอกาสที่ agent จะทำ feature แบบดูเหมือนเสร็จ แต่ใช้งานจริงไม่ได้

ผลลัพธ์ที่ Anthropic เจอ

บทความยกตัวอย่างให้ Claude สร้าง 2D retro game maker แล้วเทียบระหว่าง solo agent กับ full harness

full harness แพงกว่ามาก แต่คุณภาพต่างกันชัดเจน solo agent ทำหน้าตาได้บางส่วน แต่เกมเล่นจริงไม่ได้ดีนัก ส่วน full harness ทำ feature ได้ลึกกว่า polished กว่า และ play mode ใช้งานได้จริงกว่า

นี่เป็น trade-off ที่ต้องจำไว้ ไม่ใช่ว่าเราควรใช้ harness หนักๆ กับทุกงาน เพราะบางงาน single agent ก็พอ แต่ถ้างานสำคัญ งานซับซ้อน หรืองานที่ต้องการคุณภาพสูงมาก harness แบบนี้อาจคุ้ม

เมื่อ Model เก่งขึ้น Harness ก็ต้องเปลี่ยน

อีกประเด็นที่ผมชอบคือ Anthropic บอกว่าเมื่อ model รุ่นใหม่เก่งขึ้น บางส่วนของ harness ที่เคยจำเป็นอาจไม่จำเป็นอีกต่อไป

นี่เป็นความจริงที่สำคัญมาก ทุก component ใน harness คือสมมติฐานบางอย่างว่า model ยังทำเองได้ไม่ดีพอ เช่น ยังวางแผนไม่ดีพอ ยัง review ตัวเองไม่ดีพอ ยังทำงานยาวไม่ได้พอ หรือยังต้องแตกงานเป็น sprint เล็กๆ

แต่เมื่อ model ดีขึ้น สมมติฐานเหล่านี้อาจหมดอายุ

ดังนั้น harness ที่ดีไม่ควรเป็น pipeline แข็งๆ แต่ควรเป็นระบบที่ปรับได้ เช่น

• เปิดหรือปิด planner ได้
• เลือก evaluator แบบเบาหรือหนักได้
• ปรับจำนวนรอบ iteration ได้
• เลือกใช้ context reset หรือ compaction ได้
• ถอด component ที่ไม่ load-bearing ออกได้

ผมคิดว่านี่คือแนวคิดที่ดีมากสำหรับคนทำ agent platform เพราะเราไม่ได้ออกแบบระบบเพื่อ model รุ่นเดียว แต่ต้องออกแบบให้ evolve ตาม model ได้

ถ้าจะเอามาพัฒนาต่อ ผมจะเริ่มจากอะไร

ถ้าเอาแนวคิดนี้มาใช้กับระบบ agent ที่ผมกำลังทำอยู่ ผมคิดว่าสิ่งที่ควรเริ่มมีคือ 5 เรื่องนี้

1. Artifact-first workflow

อย่าให้ chat เป็นที่เก็บ state หลักของงาน แต่ให้ agent ทำงานผ่านไฟล์หรือ object ที่ชัดเจน เช่น

• SPEC.md
• PLAN.md
• TASKS.md
• STATE.md
• EVAL.md
• HANDOFF.md

ไฟล์เหล่านี้ทำให้ agent ตัวถัดไปอ่านต่อได้ และมนุษย์ก็ตรวจได้ด้วย

ซึ่งหากใครใช้ skill พวกทำ Spec Driven มันจะสร้างเอกสาร spec/plan/adr ให้อัตโนมัติ คอนเซ็ปประมาณนี้เลย

2. Maker กับ Checker ต้องแยกกัน

งานสำคัญไม่ควรให้ agent ตัวเดียวสร้างและรับรองงานตัวเอง ควรมี reviewer หรือ evaluator แยกออกมาเสมอ โดยเฉพาะงานที่ต้อง publish, deploy หรือกระทบข้อมูลจริง

3. Evaluator ต้องมี Rubric

rubric คือชุดเกณฑ์การให้คะแนน หรือเครื่องมือประเมินผลที่อธิบายระดับคุณภาพของชิ้นงาน

ดังนั้น Evaluator ที่ไม่มี rubric จะตรวจแบบลอยๆ และมักใจดีเกินไป rubric ที่ดีควรบอกว่าอะไรคือ pass, อะไรคือ fail, ต้องลอง edge case ไหน และอะไรที่ห้ามมองข้าม

4. Context Reset ต้องเป็น Feature ไม่ใช่ปล่อยให้แก้ตอนเต็ม

ถ้างานยาวพอ เราควรออกแบบไว้เลยว่า agent จะ reset ตอนไหน ส่งต่ออะไร และ agent ตัวใหม่ต้องอ่านอะไรบ้าง ไม่ใช่รอให้ context เต็มแล้วค่อยหาทางรอด

5. ต้องมี Stop Condition

Agent ที่ทำงานเองได้ต้องรู้ด้วยว่าเมื่อไรควรหยุด ถ้าไม่มี stop condition มันอาจวนแก้ไปเรื่อยๆ ใช้ token ใช้เวลา แต่คุณภาพไม่ได้ดีขึ้นตามสัดส่วน

ข้อควรระวัง

แนวทางนี้น่าสนใจมาก แต่ก็มีข้อควรระวังเยอะเหมือนกัน

• Cost สูงขึ้น เพราะใช้หลาย agent ทำงานหลายรอบ และต้องมี evaluation loop
• สร้างงานได้ช้าขึ้น เพราะงานบางอย่างต้องรอ browser test, QA หรือ iteration
• ซับซ้อนขึ้น เพราะต้องดูแล state, artifact, prompt, rubric และ orchestration
• Evaluator ก็พลาดได้ ถ้า rubric ไม่ดีหรือทดสอบไม่ลึกพอ
• Handoff ที่ไม่ดีอันตรายมาก เพราะ agent รุ่นถัดไปอาจสานต่อจากข้อมูลผิด

ดังนั้นผมคิดว่าควรใช้ harness หนักๆ เฉพาะงานที่คุ้มจริง เช่นงานที่มีผลลัพธ์สำคัญ งานที่ต้องใช้ซ้ำ หรืองานที่ถ้าพลาดแล้วเสียเวลามาก

สรุป

บทความนี้ทำให้ผมยิ่งเชื่อว่าอนาคตของ AI Agent ไม่ได้อยู่ที่ prompt อย่างเดียว แต่อยู่ที่การออกแบบ harness รอบๆ model ให้ดีพอ

Agent ที่ทำงานยาวได้จริงต้องมี plan ต้องมี state ต้องมี handoff ต้องมี evaluator ต้องมี rubric และต้องมีวิธีรู้ว่าเมื่อไรควรทำต่อหรือหยุด

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

สำหรับผม นี่เป็นทิศทางที่น่าทดลองมาก และน่าจะเป็นแกนสำคัญของระบบ agent รุ่นถัดไปที่ไม่ได้แค่ “ตอบเก่ง” แต่ “ทำงานเป็นระบบ” ได้จริง

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

เพราะความไม่ต้องการให้ AI เดาเอง และไม่อยากอารมณ์เสียเมื่อรอมันรันนานแต่ผลลัพธ์ที่ได้ไม่ตรงใจ ผมจึงมักจะระบุว่าใคร ทำอะไร อย่างไร ที่ไหน เมื่อไร อะไรควรทำ ไม่ควรทำ

ซึ่งเครื่องมือในโพสต์นี้เป็นประมาณนั้นเลยครับ เผื่อใครจะเอาไปเป็นไอเดียเสริมสไตล์การเขียน Prompt/Spec ให้กับผู้อ่านได้

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพู ได้เรียบเรียงและแปลจากต้นฉบับของ Vishal Mysore เรื่อง ZeeSpec- Spec Driven Development for Greenfield vs Brownfield Projects

AI มันไม่กลัว requirement ที่ไม่ชัด แต่มันจะเดาแทนเราเลย

บทความต้นฉบับพูดถึงเครื่องมือชื่อ ZeeSpec ซึ่งเป็นแนวคิดการทำ spec แบบบังคับให้เราตอบคำถามให้ครบก่อนเริ่มให้ AI สร้างระบบ

คำสำคัญของ ZeeSpec คือ มันไม่ได้เป็น documentation เฉยๆ แต่มันเป็น constraint system หรือระบบกรอบข้อจำกัดที่บอก AI ว่าอะไรทำได้ อะไรทำไม่ได้ อะไรห้ามเดา

ถ้าเราไม่ตอบ AI จะตอบแทนเรา และคำตอบนั้นอาจดูดีมากจนเราไม่ทันระวัง

ฟังดูเหมือนเรื่องเล็กนะครับ แต่คนทำ software น่าจะเคยเจออาการนี้กันบ่อยมาก เช่น บอกให้เพิ่ม feature นิดเดียว แต่ AI ดัน refactor service เดิมให้ด้วย หรือบอกให้เพิ่ม field ในตาราง แต่มัน generate migration ที่กระทบข้อมูลเดิมแบบชวนเสียวหลัง

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

ZeeSpec ใช้ 5W1H มาบีบให้เราคิดครบ

ZeeSpec วางอยู่บนแนวคิด Zachman Framework ซึ่งเป็นกรอบคิดด้าน enterprise architecture และโมเดล 5W1H ที่ประกอบด้วย What, Where, When, Who, Why, How

ในบทความบอกว่า ZeeSpec มีคำถาม 60 ข้อ แบ่งเป็น 6 มิติ มิติละ 10 ข้อ เป้าหมายไม่ได้อยู่ที่การเขียนเอกสารให้ยาว แต่อยู่ที่การบังคับให้ decision สำคัญถูกพูดออกมาก่อน AI จะลงมือเขียนโค้ด

ผมชอบตรงที่มันไม่ได้ถามแค่ว่า “อยากได้ feature อะไร” แต่มันถามด้วยว่า “อะไรห้ามเกิดขึ้น” ซึ่งปกติเราไม่ค่อยเขียนลง requirement กัน ทั้งที่ในโลกจริง สิ่งที่ห้ามเกิดขึ้นนี่สำคัญมาก

Greenfield คือพื้นที่ว่างที่อันตรายกว่าที่คิด

Greenfield project คือโปรเจกต์ที่เริ่มใหม่แทบทั้งหมด ไม่มี schema เดิม ไม่มี API เดิม ไม่มี legacy ให้ต้องเกรงใจ

ข้อดีคือเราออกแบบใหม่ได้เต็มที่ แต่ข้อเสียคือไม่มีอะไรคอยขัด AI เลย ถ้าเรา spec ไม่ครบ มันจะเติมโลกทั้งใบให้เราเอง

Greenfield ไม่ได้เสี่ยงเพราะไม่มีของเดิม แต่มันเสี่ยงเพราะไม่มีแรงต้านเวลา AI เดา

ในบทความเสนอว่า สำหรับ greenfield ต้องตอบให้ครบทุกมิติ โดยเฉพาะคำถามที่คนมักข้าม เช่น

• ระบบนี้ทำอะไร และไม่ทำอะไร
• entity ไหนมีจริง entity ไหนห้ามมี
• ข้อมูลอะไรห้ามเก็บเด็ดขาด เช่น PII, payment data, secret
• ใครเห็นข้อมูลอะไรได้บ้าง
• เมื่อเกิด error ระบบควร fail แบบไหน
• ถ้าเจอข้อมูลไม่ครบ ระบบควรหยุดหรือเดา

ถ้าเขียนแบบนี้ก่อนให้ AI ทำงาน โอกาสที่มันจะสร้าง table ประหลาดๆ หรือ flow ที่ดูสมเหตุสมผลแต่ผิด business rule จะน้อยลงมาก

Brownfield ต้องล็อกของเดิมก่อนค่อยสั่งของใหม่

Brownfield project คือระบบที่มีอยู่แล้ว อาจมี database จริง มี user ใช้งานจริง มี API consumer ภายนอก มี technical debt ที่ทุกคนรู้ว่าไม่สวย แต่แตะมั่วไม่ได้

ตรงนี้บทความให้แนวคิดที่ผมว่าโดนมาก คือ brownfield ไม่ควร spec ทั้งระบบใหม่ แต่ควร spec เฉพาะ delta หรือส่วนที่เปลี่ยน

Greenfield คือเติมทุกมิติ ส่วน brownfield คือ lock สิ่งที่มีอยู่ แล้วระบุเฉพาะสิ่งที่จะเปลี่ยน

นี่เป็นจุดที่หลายทีมพลาด รวมถึงผมเองก็เคยพลาดครับ เวลาใช้ AI กับระบบเดิม เรามักคิดว่าให้ context เยอะๆ แล้วมันจะเข้าใจ แต่ถ้าเราไม่บอกว่า “ห้ามแตะอะไร” มันอาจช่วยเกินหน้าที่

ตัวอย่างง่ายๆ เช่น เราขอเพิ่ม endpoint ใหม่สำหรับ export report แต่ถ้าไม่ได้ lock authentication pattern เดิมไว้ AI อาจ generate middleware แบบใหม่ หรือแก้ permission model ให้ดูสะอาดขึ้น ซึ่งดูดีใน diff แต่พังกับระบบจริง

ก่อน spec ระบบเก่า ต้องป้อน context ของระบบเก่าก่อน

สำหรับ brownfield บทความแนะนำให้เริ่มด้วย Step 0 คือป้อน context ของระบบเดิมก่อนตอบ ZeeSpec

• schema ปัจจุบัน แม้จะเป็น version ย่อก็ยังดีกว่าไม่มี
• API pattern ที่ใช้อยู่ เช่น naming, response shape, error format
• tech stack และ infrastructure ที่เปลี่ยนไม่ได้
• constraint ที่เป็น non-negotiable เช่น ต้องใช้ PostgreSQL 14 หรือห้าม breaking change กับ client เดิม

ผมว่าข้อนี้ practical มาก เพราะ AI ที่ไม่เห็น schema จะออกแบบรอบ schema ไม่ได้ มันจะออกแบบ schema ใหม่ให้เราแทน ซึ่งใน brownfield นี่คือความเจ็บปวดล้วนๆ

วิธีคิดต่างกันระหว่าง greenfield กับ brownfield

ถ้าเอามาแปลงเป็นภาษาคนทำงานจริง ผมจะสรุปแบบนี้ครับ

Conflict ใน spec ไม่ใช่ edge case แต่มันคือ bug ตั้งแต่ยังไม่เขียนโค้ด

อีกประเด็นที่ผมชอบคือ เวลาคำตอบใน spec ขัดกัน ZeeSpec ไม่ควรปล่อยผ่าน

เช่น ในมิติ WHO เราบอกว่าเฉพาะ Admin เท่านั้นที่ลบ user ได้ แต่ในมิติ WHEN เราบอกว่า unverified account จะถูกลบอัตโนมัติหลัง 30 วัน แบบนี้มันมี conflict อยู่แล้ว

ถ้าเราไม่ resolve ตอน spec AI อาจ resolve ให้เองแบบเงียบๆ และเราอาจไม่รู้ด้วยว่ามันเลือกทางไหน

Spec ที่ขัดกัน คือ bug ที่ยังไม่ได้ compile

ผมชอบประโยคนี้มาก เพราะมันทำให้เราเปลี่ยนมุมมองจาก “เดี๋ยวค่อยดูตอน implementation” เป็น “ต้องเคลียร์ก่อนให้ AI ลงมือ”

เอาไปใช้กับงานจริงได้ยังไง

ถ้าจะเอาแนวคิดนี้ไปใช้กับทีม software development ผมคิดว่าไม่จำเป็นต้องเริ่มด้วย 60 ข้อแบบเต็มทันที เพราะเดี๋ยวทีมจะรู้สึกว่าเอกสารกลับมาฆ่าเราอีกแล้ว 555

เริ่มแบบเบากว่านั้นก็ได้ เช่น ก่อนให้ AI ทำ feature ใดๆ ให้ตอบ 6 ช่องนี้ให้ได้ก่อน

• WHAT จะเพิ่มหรือเปลี่ยนอะไร และอะไรไม่อยู่ใน scope
• WHERE ต้องแตะ file, service, database, integration ไหนบ้าง และอะไรห้ามแตะ
• WHEN flow ใหม่เกิดตอนไหน กระทบ trigger เดิมไหม
• WHO role ไหนใช้ได้ role ไหนห้ามใช้
• WHY business rule สำคัญคืออะไร ทำไมต้องเป็นแบบนี้
• HOW migration, rollback, error, test ต้องเป็นอย่างไร

สำหรับ greenfield ให้ช่องพวกนี้เป็นการออกแบบระบบ สำหรับ brownfield ให้ช่องพวกนี้เป็นรั้วกัน AI ไม่ให้ไปช่วยแก้สิ่งที่ไม่ควรแก้

Prompt แบบย่อสำหรับ greenfield

อันนี้ผมเรียบเรียงเป็น template สั้นๆ เอาไว้ใช้ได้เลย

System: [ชื่อระบบ]
Assumption: เริ่มใหม่ ไม่มี infrastructure เดิม

WHAT: entity, relationship, boundary, สิ่งที่ห้ามมี, ข้อมูลที่ห้ามเก็บ
WHERE: infrastructure, data flow, integration, system boundary
WHEN: trigger ของ create/update/delete, expiry, blocking condition
WHO: role, permission, visibility, approval
WHY: business rule, intent, validation, เหตุผลของข้อจำกัด
HOW: error handling, recovery, consistency, idempotency, test

Generate a system spec with no unstated assumptions. If information is missing, ask before generating code.

Prompt แบบย่อสำหรับ brownfield

ส่วน brownfield ผมจะเน้นคำว่า unchanged และ delta ให้ชัด เพราะนี่คือหัวใจของระบบเดิม

Existing system context: [paste schema / API pattern / tech stack / non-negotiable constraints]

New feature: [ชื่อ feature] 

WHAT: delta only, new entity, changed field, สิ่งที่ exclude ชัดเจน 
WHERE: existing infrastructure unchanged, list what must not change 
WHEN: new trigger, conflict with existing trigger, blocking rule เดิมที่ยังต้องใช้ WHO: permission ใหม่อิง role เดิม, role ที่ห้าม access 
WHY: เหตุผลของ feature และเหตุผลที่ constraint เดิมยัง valid 
HOW: migration path, backward compatibility, rollback, tests Generate only the delta. 

Do not refactor existing components unless explicitly requested.

สิ่งที่ผมได้จากบทความนี้

ผมว่าประเด็นของ ZeeSpec ไม่ใช่แค่ “เขียน spec ให้ละเอียดขึ้น” แต่คือ “เปลี่ยนหน้าที่ของ spec”

เมื่อก่อน spec มักเป็นเอกสารอธิบายให้คนอ่าน แต่ในยุค AI coding spec กลายเป็นรั้วกั้นพฤติกรรมของเครื่องมือ ถ้ารั้วหลวม AI ก็เดินออกนอกเขต ถ้ารั้วไม่บอกตำแหน่งท่อ มันก็อาจขุดโดนท่อ

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

และยิ่ง AI เขียนโค้ดได้เร็วขึ้นเท่าไร spec ยิ่งสำคัญขึ้นเท่านั้น

เพราะความเร็วไม่ได้ช่วยอะไร ถ้าเอไอลากเราวิ่งหลงทาง ผ่าม!

แหล่งที่มา

• ZeeSpec- Spec Driven Development for Greenfield vs Brownfield Projects โดย Vishal Mysore
• Spec Driven Development with ZeeSpec : greenfield vs brownfield บน DEV Community

วันนี้ผมเอาคู่มือจาก Google Workspace มาแนะนำ ซึ่งดีมากครับ ชื่อ Writing effective prompts เขาอธิบายไว้ค่อนข้างง่าย โดยเฉพาะสำหรับคนที่ใช้ Gemini (เจ้าอื่นๆก็ได้นะ อย่าง ChatGPT, Claude) ใน Gmail, Docs, Sheets หรือเครื่องมือทำงานประจำวัน แนวคิดหลักไม่ได้ซับซ้อน แต่เอาไปใช้จริงแล้วช่วยให้คำตอบดีขึ้นเยอะ

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพู ได้เรียบเรียงและอ้างอิงจากต้นฉบับ Google Workspace : Writing effective prompts

Prompt คือการเริ่มบทสนทนา ไม่ใช่คำสั่งครั้งเดียว

จุดที่น่าสนใจในคู่มือนี้คือ Google บอกชัดว่า prompt ควรถูกมองเป็น “การเริ่มบทสนทนา” กับผู้ช่วย AI มากกว่าการสั่งครั้งเดียวแล้วรอคำตอบที่สมบูรณ์แบบทันที

มุมนี้สำคัญมาก เพราะเวลาเรา brief งานให้คนจริงๆ เราก็ไม่ได้คาดหวังว่าเขาจะเข้าใจทุกอย่างจากประโยคเดียว เราอธิบายบริบท เพิ่มรายละเอียด ตอบคำถาม และปรับทิศทางไปเรื่อยๆ การใช้ AI ก็ควรเป็นแบบเดียวกัน ถ้าคำตอบแรกยังไม่ตรง ก็ถามต่อ แก้ขอบเขต เพิ่มตัวอย่าง หรือบอกให้เปลี่ยนโทน

4 ส่วนที่ทำให้ prompt ชัดขึ้น

Google แนะนำว่าการเขียน prompt ให้ดีควรพิจารณา 4 ส่วน คือ role, task, context และ format แปลแบบใช้งานง่ายๆ ได้ประมาณนี้

• Role: ให้ AI รับบทอะไร เช่น ผู้จัดการโครงการ นักวิเคราะห์ธุรกิจ นักเขียน technical document หรือที่ปรึกษาด้าน HR
• Task: อยากให้ทำอะไร เช่น สรุป เขียน draft วิเคราะห์ เปลี่ยนโทน จัดหมวดหมู่ หรือสร้าง checklist
• Context: ข้อมูลแวดล้อมที่ AI ต้องรู้ เช่น กลุ่มผู้อ่าน วัตถุประสงค์ เอกสารที่เกี่ยวข้อง ข้อจำกัด หรือสถานการณ์จริง
• Format: ต้องการผลลัพธ์หน้าตาแบบไหน เช่น bullet points, email, table, executive summary, action plan หรือข้อความสั้นสำหรับ Slack

ไม่จำเป็นต้องใส่ครบทั้ง 4 ส่วนทุกครั้ง งานเล็กๆ อาจใช้แค่ task กับ format ก็พอ แต่ถ้าเป็นงานที่มีความเสี่ยง มีบริบทเฉพาะ หรือเอาไปใช้ต่อจริง การใส่ role และ context จะช่วยลดการเดาของ AI ได้มาก

ตัวอย่างที่เอาไปใช้ได้ทันที

แทนที่จะพิมพ์ว่า “ช่วยสรุปเอกสารนี้ให้หน่อย” ลองเขียนใหม่ให้มีกรอบมากขึ้น เช่น

คุณเป็น project manager ในทีม software development ช่วยสรุปเอกสารนี้เป็น executive summary สำหรับผู้บริหาร โดยเน้นความเสี่ยงหลัก timeline และ decision ที่ต้องตัดสินใจภายในสัปดาห์นี้ ขอเป็น bullet points ไม่เกิน 8 ข้อ

prompt แบบนี้ไม่ได้ยาวเพื่อความยาว แต่มันบอก AI ว่าควรมองข้อมูลจากมุมไหน ควรสกัดอะไร และควรส่งงานออกมาในรูปแบบใด

เขียนด้วยภาษาปกติ แต่ต้องเฉพาะเจาะจง

อีกคำแนะนำที่ใช้ได้จริงคือเขียนเหมือนกำลังคุยกับคน ใช้ประโยคธรรมชาติ ไม่ต้องพยายามใช้ศัพท์เทคนิคหรือ syntax แปลกๆ เพื่อให้ดูเหมือน prompt engineer

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

ทำให้สั้น แต่ไม่ตัดบริบทสำคัญ

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

หลักง่ายๆ คือถ้าข้อมูลนั้นมีผลต่อคำตอบ ให้ใส่เข้าไป เช่น audience, deadline, tone, constraint, success criteria หรือข้อมูลที่ใช้ตัดสินใจ แต่ถ้าเป็นรายละเอียดที่ไม่ได้เปลี่ยนผลลัพธ์ อาจไม่ต้องใส่ตั้งแต่ prompt แรก

ใช้ข้อมูลของตัวเองให้เป็นประโยชน์

สำหรับคนที่ใช้ Gemini ใน Workspace จุดแข็งคือการทำงานกับไฟล์ของเราเอง เช่น เอกสารใน Google Drive, อีเมล, ชีต หรือข้อมูลในโปรเจกต์ คู่มือของ Google แนะนำให้ใช้เอกสารเหล่านี้เป็นบริบทเพื่อให้ผลลัพธ์ใกล้กับงานจริงมากขึ้น

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

ให้ AI ช่วยปรับ prompt ก็ได้

ถ้ายังไม่แน่ใจว่าจะเขียน prompt อย่างไร Google แนะนำวิธีง่ายๆ คือให้ Gemini ช่วยปรับ prompt เดิมให้ดีขึ้นก่อน เช่น บอกว่า “ช่วยเปลี่ยน prompt นี้ให้เป็น prompt ที่มีประสิทธิภาพ” แล้วใส่ prompt เดิมลงไป

วิธีนี้เหมาะกับงานที่เราเริ่มจากความคิดคร่าวๆ แต่ยังจัดรูปไม่ดีพอ AI จะช่วยเติม role, context หรือ format ที่ขาดไป จากนั้นเราค่อยตรวจอีกทีว่ามันยังตรงกับสิ่งที่ต้องการหรือไม่

ต้องตรวจคำตอบก่อนใช้จริง

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

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

สรุป

ถ้าจะจำให้สั้นที่สุด prompt ที่ดีควรตอบคำถามเหล่านี้ให้ได้: ให้ AI รับบทอะไร, ต้องทำงานอะไร, ต้องรู้บริบทอะไร และต้องส่งผลลัพธ์ออกมาในรูปแบบไหน

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

อ้างอิง: Google Workspace: การเขียนพรอมต์ AI ที่มีประสิทธิภาพสำหรับธุรกิจ

Andrew Ng ก็เขียนถึงเรื่องนี้ใน The Batch โดยมองว่า “loop” เป็นวิธีคิดของการสร้าง product โดยเฉพาะงานแบบ 0-to-1 ที่ยังต้องหาทั้งรูปแบบของ product, user flow, feedback และ direction ไปพร้อมกัน

ผมชอบกรอบนี้ เพราะมันอธิบายความจริงของการใช้ coding agent ได้ตรงดีมาก: AI ทำให้การเขียนโค้ดเร็วขึ้นก็จริง แต่ product ที่ดีไม่ได้เกิดจากความเร็วของ coding loop อย่างเดียว มันต้องมีอีกสองลูปที่ช้ากว่า แต่สำคัญกว่า

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพู ได้เรียบเรียงจากประสบการณ์การใช้งานจริง และอ้างอิงจากต้นฉบับคุณ Andrew Ng https://www.facebook.com/share/16znXFaukb/?mibextid=wwXIfr

1. Agentic Coding Loop: ลูปของ AI ที่วนเป็นนาที

ลูปแรกคือการให้ AI coding agent ทำงานจาก product spec และอาจมี evals หรือ test cases เป็นตัววัดผล จากนั้น agent ก็เขียนโค้ด ทดสอบ แก้ แล้ววนต่อจนกว่าจะผ่านเงื่อนไขที่ตั้งไว้

นี่คือสิ่งที่ทำให้ coding agent เริ่มมีประโยชน์จริงในช่วงหลัง จากเดิมที่ช่วย autocomplete หรือเขียน function สั้นๆ ตอนนี้มันเริ่มทำงานต่อเนื่องได้เป็นสิบๆ นาที หรือติดกันหลายชั่วโมง หรืออย่างผมเอง สั่งรันทั้งคืนและเช้าค่อยตื่นมาดู (ตรงใจก็มี เป๋ก็เยอะ ฮ่าๆ) โดยเอไอเองจะเปิด browser ตรวจงานที่ตัวเองทำ รัน test แล้วกลับมาพร้อมผลลัพธ์

ความเร็วของลูปนี้อยู่ในระดับ “นาที” ทุกไม่กี่นาที agent อาจสร้าง version ใหม่ของ software ได้แล้ว นี่คือจุดที่ engineer หลายคนกำลังทดลองกันหนักมากว่าจะออกแบบ loop แบบไหนให้ agent ทำงานได้นานขึ้น แต่ยังไม่หลุดจาก spec

2. Developer Feedback Loop: ลูปของคน ที่วนเป็นชั่วโมง

ลูปที่สองคือมนุษย์ หรือ developer ที่กลับมาดู product ที่ agent ทำ แล้วให้ทิศทางต่อว่าจะปรับอะไร

เมื่อก่อน developer มักต้องทำหน้าที่เหมือน QA ให้ coding agent คอยไล่ดู bug แล้วสั่งให้แก้ แต่ตอนนี้ agent ตรวจงานตัวเองได้ดีขึ้นมาก บทบาทของ developer จึงเริ่มขยับขึ้นมาที่ระดับ product มากขึ้น หรือต้องเป็น Product Owner ซะเอง เช่น feature ไหนควรมี, UI ตรงไหนยังไม่ดี, flow แบบไหนใช้ง่ายกว่า หรือ spec ตรงไหนยังคลุมเครือ

Andrew Ng ยกตัวอย่างแอปฝึกพิมพ์ให้ลูกสาว เขาเปลี่ยนใจหลายครั้งทั้งเรื่อง visual design, ชุดแมวที่เด็กจะปลดล็อกได้ และ flow สำหรับผู้ใหญ่ที่ต้องเข้ามาดูแลการเรียนรู้ของเด็ก จุดนี้เป็นตัวอย่างที่ดีมาก เพราะมันไม่ใช่ bug ที่ agent ทำการ test และจับจุดได้ แต่มันคือ product judgment

หลายคนเรียกสิ่งนี้ว่ารสนิยม (taste) แต่ Andrew Ng ใช้คำว่า context advantage ซึ่งผมว่าชัดกว่า เพราะคนรู้บริบทของ user มากกว่า AI รู้ว่าลูกชอบอะไร รู้ว่าผู้ใหญ่จะใช้ระบบยังไง รู้ว่าของแบบไหน “ใช่” สำหรับ product นี้ คือคุณนั่นเอง ตราบใดที่ความรู้นี้ยังอยู่ในหัวคน มนุษย์ก็ยังต้องอยู่ในลูป (อันนี้ถูกใจ เพราะที่มีเทคโนโลยี ณ ขณะนี้ ผมเองยังมีความเชื่อเรื่อง HITL : Human-in-the-Loop แต่คนจะเข้ามามากหรือน้อย อยู่ที่กระบวนการออกแบบ Workflow ว่าจุดไหนเรายังไม่มั่นใจใน agent โดยเฉพาะจุดที่มนุษย์ต้องเป็นคนกำหนดทิศทาง)

3. External Feedback Loop: ลูปของโลกความเป็นจริง ที่วนเป็นวัน

ลูปสุดท้ายคือ feedback จากคนนอกทีม อาจเป็นเพื่อนกลุ่มเล็กๆ, alpha testers, user จริง หรือข้อมูลจากการเปิดใช้งานบน production เช่น การทำ A/B testing

ลูปนี้ช้าที่สุด อาจใช้เวลาหลายชั่วโมง หลายวัน หรือหลายสัปดาห์ แต่เป็นลูปที่ทำให้ product vision ไม่ลอยอยู่ในหัว developer อย่างเดียว ข้อมูลจากโลกความเป็นจริงจะย้อนกลับมาเปลี่ยนมุมมองของเรา (feedback) แล้วมุมมองใหม่นั้นก็จะกลายเป็น spec ใหม่ให้ coding agent ทำต่อ

พูดอีกอย่างคือ agentic coding loop ทำให้เราสร้างของได้เร็วขึ้น แต่ external feedback loop บอกเราว่าสิ่งที่เราสร้างนั้นควรไปทางไหนต่อ

Engineer กำลังเข้าใกล้บทบาท Product Owner มากขึ้น

จุดที่ผมคิดต่อเยอะที่สุดคือ เมื่อ coding agent ทำให้การ build เร็วขึ้น engineer ก็เริ่มต้องรับบท product management มากขึ้นโดยธรรมชาติ

งานที่ยากขึ้นไม่ใช่การสั่ง AI ให้เขียนโค้ด แต่คือการตัดสินใจว่าอะไรควรถูกสร้างก่อน อะไรควรตัดทิ้ง spec ควรละเอียดแค่ไหน feedback จาก user ควรรอเมื่อไหร่ และเมื่อไหร่ที่เราควรหยุดทำให้ระบบมันเพอเฟก (polish) แล้วเอาของออกไปให้คนใช้จริงๆ

นี่คือ balance ที่ยากมาก เพราะถ้า build อย่างเดียว เราอาจได้ software ที่ทำงานได้ แต่ไม่มีใครอยากใช้, ถ้ารอ feedback อย่างเดียว เราก็ไม่เดินหน้าเสียที Product ที่ดีต้องมีทั้งสองด้าน คือ build ให้เร็วพอ และรับ feedback จากโลกธุรกิจหรือการใช้จริงให้ทัน

สรุป

ผมมองว่า Loop Engineering เป็นคำที่มีประโยชน์กว่า “prompt engineering” มาก เพราะมันย้ายจุดสนใจจากการเขียนคำสั่งทีละรอบ ไปสู่การออกแบบระบบการทำงานที่วนเองได้

• Agentic coding loop ทำให้ AI สร้างและทดสอบ software ได้เร็วขึ้น
• Developer feedback loop ทำให้มนุษย์เติม context, taste และ product judgment
• External feedback loop ทำให้ product ไม่หลุดจาก user และโลกจริง

ถ้าจะใช้ AI agent ให้คุ้มจริง ผมคิดว่าเราไม่ควรถามแค่ว่า “จะ prompt ยังไงให้มันเขียนโค้ดเก่งขึ้น” แต่ควรถามว่า “เราจะออกแบบ loop ยังไงให้มันทำงานต่อเนื่อง ตรวจตัวเองได้ และรับ feedback กลับมาเปลี่ยน product ได้ดีขึ้น”

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

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

Source: The Batch by Andrew Ng

บางครั้งมันเริ่มจากความหวังดี บางครั้งเริ่มจากความคันมือของคนทำงานสายแก้ปัญหาแบบเราๆ นี่แหละ เห็นอะไรไม่ลื่นก็อยากจัดให้มันลื่นขึ้นอีกนิด

ปัญหาคือโลกการทำงานชอบเล่าเรื่องนี้แบบสวยเกินจริง เหมือนแค่ go above and beyond แล้วทุกอย่างจะดีเอง ทั้งเติบโต ได้โปรโมต ได้รับการยอมรับ แต่ในชีวิตจริง มันไม่ตรงไปตรงมาขนาดนั้นครับ บางครั้งมันคุ้มมาก บางครั้งก็พาเราไปสู่ burnout แบบงงๆ เหมือนกัน

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพู ได้เรียบเรียงจากประสบการณ์การใช้งานจริง

ปัญหาไม่ได้อยู่ที่ขยันหรือไม่ แต่อยู่ที่ขอบเขต

ผมว่าต้องแยกก่อนว่า การทำเกินหน้าที่ ไม่ได้เท่ากับ การแบกทุกอย่าง เสมอไป

ถ้าเราเห็นปัญหาแล้วเข้าไปช่วยปิดช่องโหว่ ช่วยทำให้ทีมเดินต่อได้ หรือช่วยยกระดับคุณภาพงาน แบบนี้มันคือ initiative ครับ มันมีค่า เพราะเราไม่ได้แค่ทำงานเพิ่ม แต่เรากำลังเพิ่มผลลัพธ์

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

การทำเกินหน้าที่ที่ดี ต้องเพิ่ม leverage ไม่ใช่เพิ่มภาระแบบไม่มีปลายทาง

ด้านที่คุ้ม มันคุ้มจริง

ต้องยอมรับก่อนว่าการทำเกินหน้าที่มีด้านดีจริงครับ โดยเฉพาะในช่วงที่เรายังอยากโต อยากเรียนรู้ หรืออยากสร้างความน่าเชื่อถือให้ตัวเอง

เวลาเราเข้าไปแตะงานที่กว้างกว่าขอบเขตเดิม เรามักได้เห็นภาพรวมมากขึ้น ได้ฝึกทักษะใหม่ และได้เข้าใจว่าธุรกิจเดินยังไง ไม่ใช่เห็นแค่ task ตรงหน้า จุดนี้สำคัญมาก เพราะหลายครั้งคนที่โตเร็ว ไม่ได้โตเพราะทำงานเยอะกว่าอย่างเดียว แต่โตเพราะเห็นระบบใหญ่กว่าเดิม

อีกอย่างที่มักได้กลับมาคือ trust ครับ ถ้าคนในทีมเริ่มรู้ว่าเวลาเรื่องมันติด เราเป็นคนที่ช่วยคลี่ได้ เขาก็จะเริ่มนึกถึงเราในงานสำคัญ อันนี้ไม่ใช่ personal branding แบบสร้างภาพนะ แต่มันคือเครดิตจากของจริง

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

แต่ถ้าทำไปเรื่อยๆ โดยไม่คิด มันเริ่มเจ็บ

ด้านมืดของเรื่องนี้คือ งานที่ทำเกินหน้าที่จำนวนมากกลายเป็น invisible labor ครับ ทำจริง เหนื่อยจริง แต่ไม่มีใครนับเป็นผลงานอย่างจริงจัง

ยิ่งถ้าองค์กรไหนขอบเขตงานไม่ชัด หรือหัวหน้าชินกับการที่เราช่วยตลอด มาตรฐานจะค่อยๆ ขยับเองโดยไม่รู้ตัว จากเดิมที่เราช่วยเพราะสถานการณ์พิเศษ สุดท้ายกลายเป็นความคาดหวังประจำไปเลย แล้ววันไหนเราไม่ช่วย กลับดูเหมือนเราทำไม่เต็มที่อีกต่างหาก ความหน้าแตกของคนขยันอยู่ตรงนี้แหละครับ

อีกเรื่องที่ผมคิดว่าสำคัญมากคือ การทำเกินหน้าที่บางแบบไม่ได้ทำให้เราโต แต่มันแค่ทำให้เราเหนื่อย เช่น งานจุกจิกที่ไม่มีโอกาสต่อยอด งานดับไฟรายวัน งานที่ไม่มีอำนาจตัดสินใจแต่ต้องรับผิดชอบผลทั้งหมด แบบนี้ทำไปนานๆ เราจะเริ่มหมดแรงโดยไม่ได้อะไรกลับมาเท่าไร

เพราะฉะนั้น ถ้าอะไรที่เราทำเพิ่ม ไม่ได้เพิ่มทักษะ ไม่ได้เพิ่มความไว้ใจ ไม่ได้เพิ่มอำนาจตัดสินใจ และไม่ได้เพิ่มค่าตอบแทนเลย ก็ควรถามตัวเองตรงๆ ว่าเรากำลังช่วยงาน หรือเรากำลังถูกใช้เป็น buffer ให้ระบบที่ไม่ยอมแก้กันแน่

ถ้าจะทำเกินหน้าที่ ควรเลือกทำแบบมีทรง

ถ้าถามผม ผมไม่ได้คิดว่าควรเลิกทำเกินหน้าที่นะครับ แต่ควรเลือกทำให้ดีมากกว่า เหมือนเลือกลงทุน อย่าเทเงินทุกตัวเพียงเพราะคำว่าโอกาส

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

ที่สำคัญคือ ต้องรู้จักพูดคำว่าไม่ด้วยครับ คนทำงานเก่งจำนวนมากไม่ได้พังเพราะทำไม่ไหว แต่พังเพราะรับทุกอย่างจนเลิกแยกว่าอะไรควรทำ อะไรควรปล่อย

ในยุค AI ความขยันอย่างเดียวเริ่มไม่พอ

ยิ่งต่อจากนี้ ผมยิ่งรู้สึกว่าแนวคิด go above and beyond ต้องตีความใหม่ครับ เพราะงาน routine จำนวนมาก AI และ automation จะเข้ามาช่วยได้มากขึ้นเรื่อยๆ

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

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

คนแบบนี้ยังไงก็มีค่าครับ เพราะเขาไม่ได้แค่เติมแรง แต่เติมทิศทาง

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

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

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

สุดท้าย ผมว่าเป้าหมายไม่ใช่การทำให้เกินหน้าที่ตลอดเวลา แต่คือการทำงานให้มีน้ำหนักพอที่คนเห็นคุณค่า โดยไม่ต้องเผาตัวเองทิ้งไปกับมัน

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

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพู ได้เรียบเรียงจากประสบการณ์การใช้งานจริง และอ้างอิงสรุปที่แปลจากต้นฉบับ เรื่อง Karpathy’s LLM Wiki: The Complete Guide to His Idea File

1. ปัญหาที่แท้จริงไม่ใช่การหาข้อมูล (information) แต่คือการสะสมความเข้าใจ (understanding)

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

สิ่งที่ Karpathy พยายามชี้ให้เห็นคือ ถ้าเราอยากให้การใช้งานแต่ละครั้งสร้างมูลค่าเพิ่มจริงๆ เราควรมีชั้นของความรู้ที่ถูกตีความ (compile) และสรุปไว้แล้วในระดับหนึ่ง ไม่ใช่ให้ทุกคำถามต้องเริ่มจากศูนย์เสมอ นี่แหละคือจุดตั้งต้นของแนวคิด LLM Wiki

2. แม้ RAG จะมีประโยชน์ แต่อาจไม่ใช่คำตอบทั้งหมด

แนวคิดนี้ไม่ได้บอกว่าให้เราทิ้ง RAG นะครับ แต่ตรงกันข้าม มันยังมีประโยชน์มากในงานที่ต้องดึงข้อมูลจากฐานชุดข้อมูลใหญ่ๆ ที่ต้องใช้ความเร็วและยืดหยุ่น แต่ข้อจำกัดของมันคือระบบไม่ได้ดีขึ้นตามจำนวนครั้งที่เราใช้งาน เพราะถังข้อมูลยังอยู่เท่าเดิม แต่มันตอบโจทย์เราได้จากชุดคำถาม (เช่น prompt) กับเครื่องมือที่ไปเรียกใช้ข้อมูลจากมัน (เช่น LLM Model)

RAG จะเก่งเรื่อง retrieval และ on-demand synthesis แต่ LLM Wiki เน้นการสร้าง knowledge artifact ที่อยู่ยาวๆ และได้คำตอบแน่นอนเสมอ พูดง่ายๆ คือ RAG ช่วยให้ “ตอบได้” ส่วน wiki ช่วยให้ “รู้เป็นระบบ” มากขึ้น ถ้าโจทย์คือการสร้างฐานความรู้ระยะยาว ผมคิดว่าจุดนี้สำคัญมาก

3. ชุดข้อมูล LLM Wiki จะมีลักษณะ Compounding

เรียกว่าเป็นหัวใจของระบบ LLM Wiki นี้เลยก็ได้ คือ ความรู้บางประเภทที่เราได้มาจากบทความ แชต หรือหนังสือเป็นเล่มๆ มันควรทำสรุปเพื่อให้เกิดบทความใหม่ ที่เราสามารถกลับมาอ่านซ้ำได้ แต่ในขณะเดียวกัน เมื่อมี data source ในเรื่องเดิมเติมเข้ามาใหม่ หน้าบทความสรุปเดิมก็ควรถูกอัพเดทตามไปด้วย ไม่ใช่ปล่อยให้มันเป็นเรื่องแยกออกจากกัน และสร้างลิงค์กลับมาอ้างอิงเฉยๆ

ผลลัพธ์คือระบบจะเริ่มมีคุณสมบัติ compounding (ไม่แน่ใจจะใช้ภาษาไทยว่าอะไรดี) ไม่ว่าจะเป็นการแตกหัวข้อที่เกียวเนื่องกัน การสรุปในแต่ละหัวข้อ การเชื่อมโยงข้ามหัวข้อ การเห็นข้อขัดแย้ง หรือการมี synthesis page ที่ช่วยย่นเวลาในการทำความเข้าใจเรื่องยากๆ ให้เข้าใจได้ง่ายขึ้น

เจ๋งไหมล่ะ!

4. LLM Wiki กับโมเดลเรียบง่ายแค่สามชุด

เป็นความเรียบง่ายที่ผมชอบ คือ เขาวางข้อมูลไว้แค่ 3 ชุดโดยมี Raw, Wiki, Schema โดย

ชั้นแรก คือ Raw สำหรับเก็บต้นฉบับหรือ source ดิบแบบไม่แก้ไข (Single source of truth) ตั้งแต่ text, pdf, docx, xlsx ที่เราส่งเข้าไป (ingest) อย่างไร มันก็เก็บไว้อย่างนั้น เพื่ออ้างอิง

ชั้นที่สอง คือ Wiki ซึ่งเป็นชั้นที่เกิดจาก LLM ทำการสังเคราะห์ข้อมูลจาก Raw ให้แตกเป็นความรู้ในหัวข้อต่างๆ หาความเชื่อมโยง และสรุปออกมาให้เราอ่าน

ส่วนชั้นที่สาม คือ Schema หรือ กติกาว่าระบบนี้จะ ingest ยังไง จะตั้งชื่อยังไง จะ cross-link ชุดข้อมูลกันยังไง หรือจะ review ยังไง

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

5. การ Ingest และ Query

หลายคนมักโฟกัสว่า AI Assistant ตอบคำถามได้ดีไหม แต่ถ้ามองให้ลึกกว่านั้น มันต้องดูตั้งแต่การนำเข้าข้อมูล (Ingest) ซึ่งเป็นงานระดับโครงสร้างเลยครับ เพราะทุกครั้งที่เอา data source ใหม่เข้าไป ระบบต้องรู้ด้วยว่าต้องทำการปรับปรุง knowledge graph ของความรู้เดิมด้วย ไม่ใช่แค่เก็บเอกสารเพิ่มอีกหนึ่งก้อน

ซึ่งถ้า Ingest ดีๆ เราจะได้ประโยชน์มากกว่าการเก็บเอกสารเพิ่ม เพราะระบบจะเริ่มรู้ว่าประเด็นไหนควรแยกเป็นหน้าใหม่ ประเด็นไหนควร merge กับหน้าเดิม และเรื่องไหนเริ่มขัดกันจนควรมี synthesis ใหม่เกิดขึ้น

ส่วนการ Query จะเป็นเหมือนเรื่องการใช้ prompt, ที่ถ้าเราถามได้ดี ข้อมูลก็ออกมาตามที่ต้องการ (แต่ยุคนี้แล้ว ความฉลาดของ LLM ช่วยเราได้เยอะ)

6. ทำไม idea file ถึงน่าสนใจกว่าการเขียนถึงวิธี implementation

อ่านมาถึงตรงนี้ อาจจะผิดหวังนิดหนึ่งที่ทำไมในบทความแปล หรือผมไม่สอนการติดตั้ง LLM Wiki สักทีนึง 555, เพราะผมคิดว่าถ้าเราเข้าใจหลักการ เราสามารถทำเองได้นะ เหมือนที่ผมเคยนั่งอ่าน LLM Wiki และนั่งทำขึ้นมาเอง ก่อนจะพบว่า สิ่งที่ตนเองอ่านนั้น คือ Markdown file ที่โยนไปสั่ง AI implement ได้เลย (ฮาาา)

จริงๆ แล้ว ความหน้าแตกของผม มันสะท้อนถึงความเก่งของคุณ Andrej Karpathy เลยนะ ที่เขียนเล่าเป็นไอเดีย (idea file) ไว้ที่ https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f , ซึ่งถ้าเข้าไปอ่านดู จะพบว่า มนุษย์อย่างเราสามารถอ่านแล้วเข้าใจคอนเซปเขาได้ แต่ในขณะเดียวกัน โยนให้ AI อ่าน มันจะสามารถนำไป Implement ระบบ LLM Wiki ได้ด้วยเช่นกัน

ซึ่งการการแชร์ idea file แบบนี้ ผมว่า เข้าใจง่ายกว่าการเขียนวิธีทำทีละขั้นตอนอีก เพราะมันส่งต่อเจตนา โครงสร้าง และ workflow โดยไม่บังคับว่าทุกคนต้องใช้ Technology stack อะไร, เครื่องคอมฯ แบบไหน หรือ AI อะไร

7. สิ่งที่เปลี่ยนจริงๆ คือบทบาทของมนุษย์

ถ้าเอาแนวคิดนี้มาใช้จริง บทบาทของคนจะไม่ได้อยู่ที่การเขียนสรุปทุกย่อหน้าด้วยตัวเองตลอดเวลา แต่ไปอยู่ที่การคัด data source ดีๆ การถามคำถามให้คม การออกแบบ taxonomy และการตัดสินใจว่าความรู้ชิ้นไหนควรนำเข้ามาสังเคราะห์เป็น Knowledge Based ของเรา

ส่วน LLM จะช่วยทำงานที่ซ้ำและกินแรง เช่น สรุป เชื่อมโยง สร้าง backlinks อัปเดตหน้าที่เกี่ยวข้อง และดูแลความสม่ำเสมอของฐานความรู้

พูดอีกแบบคือมนุษย์ขยับขึ้นไปทำงาน judgement มากขึ้น ส่วน AI จะรับงาน maintenance มากขึ้น

8. เริ่มต้นจากสิ่งเล็กๆ แต่เริ่มให้ถูก

ถ้าถามผม วิธีเริ่มที่ดี คือ อย่าเพิ่งไปคิด infrastructure ใหญ่โตเกินไปครับ เริ่มจากใช้ในเครื่องคอมพิวเตอร์เรานี่เอง ที่ติดตั้ง AI Code อะไรสักตัว เช่น Claude Code, ChatGPT Codex และโยนไฟล์ idea ไปให้สร้างระบบตามคอนเปซนั้น จากนั้นค่อยๆคัดว่าข้อมูลใดเราจะนำเข้า (ingest)

9. สรุปในมุมของผม

สิ่งที่ผมได้จากบทความนี้คือคอนเซปและวิธีคิดในการสร้าง Knowledge Based ด้วยหลักการ LLM WIki ของ คุณ Andrej Karpathy ซึ่งมันไม่ใช่ข้อสรุปนะว่า LLM Wiki ที่เป็น Markdown file จะดีกว่า RAG แต่เป็นการนำเสนอให้เห็นว่า ถ้าเราอยากสร้างระบบความรู้ที่ยิ่งใช้ยิ่งดี เราต้องสนใจเรื่อง structure, ingest และ maintenance มากพอๆ กับเรื่อง model capability หรือเทคโนโลยีที่อาจจะอลังการเกินไป

แต่ในโลกความเป็นจริง เราคงไม่ได้เลือกอย่างใดอย่างหนึ่งหรอกครับ อนาคตถ้าระบบใหญ่มากขึ้น เราอาจจะใช้ทั้ง RAG และ Wiki ร่วมกัน แต่ถ้าโจทย์คือการสร้างฐานความรู้ส่วนตัวหรือทีมที่สะสมความรู้ได้เรื่อยๆ ในระยะยาว แนวคิดแบบ LLM-maintained wiki ของ Karpathy น่าจะเป็นจุดเริ่มต้นที่ดี และง่ายกับใครหลายๆคน รวมถึงผมด้วย

อ้างอิง

• Karpathy’s LLM Wiki: The Complete Guide to His Idea File https://agentpedia.codes/blog/karpathy-llm-wiki-idea-file

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพู ได้เรียบเรียงและแปลจากต้นฉบับของ Evgeni Rusev เรื่อง Spec-Driven Development: A Practical Guide for AI-Accelerated Teams

วันที่โค้ดอาจไม่ใช่คอขวดอีกต่อไป

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

ผู้เขียนบทความ (Evgeni Rusev) มองว่าความสูญเสียครั้งใหญ่ของทีมยุค AI ไม่ได้เกิดตอนพิมพ์โค้ด แต่อยู่ในขั้นตอนก่อนหน้านั้นต่างหาก ตอนที่ทุกคนพยายามปะติดปะต่อว่า ซอร์ฟแวร์ที่ต้องการ จะต้องมีอะไรในเอกสาร requirement บ้าง ใครเคยตกลงอะไรไว้ เงื่อนไขทางธุรกิจคืออะไร ทำไมระบบถึงทำงานแบบนี้ และอะไรคือสิ่งที่ “ทุกคนรู้กันอยู่แล้ว” แต่ไม่มีใครพูดหรือเขียนมันออกมา

ประโยคนี้มักได้ยินบ่อยๆในวงสนทนาของชาวเดฟ และฟังดูเจ็บๆ เพราะ AI อาจช่วยเขียน feature ได้ในเวลาอันสั้น ทว่าถ้าทีมยังต้องเสียเวลาขุดแชตเก่า ไล่อ่าน ticket เดิม และถาม System Analyst หรือ Senior Engineer ซ้ำๆ แล้วหละก็, productivity ที่เหมือนได้มาจาก AI ก็จะค่อยๆ หายไป จนสุดท้าย อาจจะทำงานได้เร็วกว่ากระบวนการเดิมเพียง 10-30% เท่านั้น (อ้างอิงจากหลายบทวิเคราะห์ เช่น arxiv.org, getdx.com, mckinsey.com – ฟิวส์)

จาก Ticket และ PRD ที่เขียนครั้งเดียว ไปสู่ Living Spec

ข้อแนะนำของบทความนี้ คือ ให้ใช้ spec เป็นเอกสารกลาง และต้องยังอธิบายได้ว่า “ระบบควรทำอะไรในตอนนี้” ไม่ใช่เมื่อสามเดือนที่แล้ว หรือไม่ใช่ตอน kickoff โปรเจกต์ และไม่ใช่ตามความทรงจำของใครคนใดคนหนึ่ง.. (เจ็บปวดอีกแล้ว ฮ่าๆ)

ผู้เขียนได้แยกบทบาทของเอกสารได้คมมากๆ 3 ประเภท

นี่คือความต่างที่สำคัญมาก เพราะ PRD และ Ticket จะถูกฟลีชไว้และเก่าไปเรื่อยๆ ตามระยะเวลาที่พัฒนานานขึ้นเรื่อยๆ ผู้เขียนเรียกมันว่าเป็นหลักฐานของอดีต ในขณะที่ Spec ที่ดีควรเปลี่ยนตามความจริง ดังนั้นจุดแตกต่างของ Spec จึงไม่ใช่แค่การเปลี่ยนคำเรียกใหม่เท่านั้น แต่มันคือปรับวิธีการคิด และการต่อรองกันว่า ซอร์ฟแวร์เรากำลังไปในทิศทางไหน

อีกจุดที่ผู้เขียนเน้นชัด คือ Spec ไม่ควรกลายเป็น Technical Design Document หน้าที่ของมันคืออธิบาย What และ Why มากกว่า How ถ้าเอกสารเริ่มลงลึกถึง Endpoint, Database Schema หรือ Framework มากเกินไป เราก็กำลังเอาแปลนบ้านไปปนกับวิธีการก่ออิฐ เทปูน แล้ว (เป็นจุดที่ผมชอบใจการเปรียบเทียบมาก – ฟิวส์)

ตัวอย่าง เมื่อเทียบระหว่าง Spec (ในที่นี้คือ Product Spec) กับ Technical Spec

Spec ที่ดี ไม่ได้เขียนละเอียดหรือเยิ่นเย้อเกินไป แต่ต้องชัดเจน

ที่ผมชอบบทความนี้ คือ มันไม่ได้บอกแค่ว่า “ควรมี Spec” แต่ยังบอกด้วยว่า Spec ที่ใช้งานได้ควรมีอะไรบ้าง อย่างน้อยที่สุดควรตอบคำถามเหล่านี้ให้ได้

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

ฟังดูเหมือนเรื่องพื้นฐาน แต่หลายทีมกลับไม่ค่อยเขียนส่วนที่สำคัญที่สุดอย่าง non-goals และ acceptance criteria ทั้งที่สองอย่างนี้คือรั้วกัน scope creep และเป็นภาษากลางที่ช่วยให้ PM, Dev, QA และ AI มองโจทย์เดียวกันด้วยสายตาใกล้เคียงกันมากขึ้น

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

ลองดูตัวอย่างโครงสร้างของ Spec (ซึ่งถ้าใครเคยสังเกต Spec ที่ AI เขียน ก็จะมีหัวข้อพื้นฐานประมาณนี้แหละ – ฟิวส์)

# [Feature Name]

**Status:** Draft | In Review | Approved | Superseded
**Owner:** [Name / Team]
**Last Updated:** [YYYY-MM-DD]

## Problem
A specific story showing why the status quo doesn't work. Name the user.

## Users
| User           | Role           | Context              |
| -------------- | -------------- | -------------------- |
| [Name/Persona] | [What they do] | [Relevant details]   |

## Goals
- [Outcome this feature serves]

## Non-Goals
- [Thing we are deliberately not doing — prevents scope creep]

## Acceptance Criteria
- **AC-1:** [Concrete, testable, plain-language behavior]
- **AC-2:** ...

## Constraints
| Constraint | Source | Impact |

## Risks & Open Questions
- [ ] [Decision still to be resolved]

เหตุผลที่ AI ชอบเอกสารชัดๆ มากกว่าความคลุมเครือ

หนึ่งในประโยคที่คมที่สุดของบทความนี้คือ AI works from the spec, not from assumptions.

ถ้าเราส่งงานให้ AI โดยข้อมูลยังแยกกันอยู่ใน Slack, Jira, meeting transcript หรือจากความทรงจำของใครสักคนในทีม AI โมเดลก็จะต้องเติมช่องว่างเองด้วยการเดา และหลายครั้งสิ่งที่เราบ่นว่าเป็น AI Hallucination หรือ อาการหลอนของ AI ก็อาจเป็นเพาะเราเอง ที่ป้อนข้อมูลให้แบบขาดๆ เกินๆ (โทษตัวเองบ้างนะ ฮ่าๆ)

แต่ถ้าทีมมี Spec ที่ดี AI จะเห็นภาพรวมในที่เดียว มันรู้ว่าเป้าหมายคืออะไร อะไรเป็น non-goal อะไรห้ามเปลี่ยน และอะไรคือเกณฑ์ที่จะใช้ตัดสินว่างานเสร็จจริงหรือยังไม่เรียบร้อย แบบนี้ขอบเขตของความผิดพลาดจะลดลงเยอะมาก จากเดิมที่ให้ผลลัพธ์มั่วได้ตั้งแต่การตีความต้องการของเราผิด ก็จะเหลือเพียงปัญหาเชิง implementation ที่เราสามารถใช้กระบวนการ test และ review แก้ไขตามหลังได้

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

ถ้าอยากเริ่มใช้จริง ไม่จำเป็นต้องปฏิวัติทั้งองค์กรในวันเดียว

แนวคิดนี้สามารถเริ่มได้ไม่ยาก และเริ่มเล็กๆ ได้ ผู้เขียนแนะนำให้เริ่มจาก feature เดียวที่เจอความสับสนซ้ำๆ เช่น workflow อนุมัติเอกสาร การสร้างรายงาน การแจ้งเตือน หรือ onboarding flow แล้วเขียน spec ให้ชัดสำหรับเรื่องนั้นเรื่องเดียวก่อน

จากนั้นค่อยกำหนด Standard ให้ทีมเขียน Spec เช่น

• เขียน goals และ non-goals ให้ครบ
• ใช้ acceptance criteria เป็น definition of done ร่วมกัน
• แยก spec ออกจาก technical design ให้ชัด
• เมื่อ requirement เปลี่ยน ให้แก้ spec ก่อนเสมอ
• ถ้ายังต้องใช้ Jira อยู่ ก็ใช้ต่อได้ แต่ให้มันทำหน้าที่ระบบติดตามงาน ไม่ใช่ที่เก็บความจริงสูงสุดของระบบ (ระวังจะ Outdate)

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

ผมรู้สึกอย่างไรกับบทความนี้

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

Spec-Driven Development จึงไม่ใช่แฟชั่นในการทำเอกสาร หรือการกำหนดรูปแบบเอกสารใหม่ แต่มันคือความพยายามจะเก็บ “ความหมายของระบบ” ไว้ในที่ที่ทั้งคนและเครื่องเข้าไปหยิบใช้ได้และเข้าใจตรงกัน

อ้างอิง

• Evgeni Rusev, Spec-Driven Development: A Practical Guide for AI-Accelerated Teams
  https://evgenirusev.com/posts/spec-driven-development-guide/

“กาลเวลา ย่อมกลืนกินสรรพสัตว์ทั้งหลาย พร้อมกันไปกับตัวมันเอง”
พุทธพจน์ที่คอยเตือนใจ ว่าหลายสิ่งมา และหลายสิ่งก็ต้องจากไป
จริงๆ ก็เริ่มมองเห็นความเสื่อมถอยของตัวเองและสิ่งแวดล้อมรอบข้าง
บางอย่างก็เริ่มรับได้ ทำใจได้ แต่หลายอย่างก็ยังดื้ออยู่ ยังอยากฝืนตามที่ใจปราถนา
ไม่อยากปล่อยให้ตัวเองร่วงไปตามกาลเวลา เหมือนที่เคยคุยกับตัวเองไว้หลายปีก่อนว่า
“ยิ่งแก่ อยากจะยิ่งแข็งแรง..” แล้วก็เลยวิ่งเทรล เดินป่า เป็นบ้าเป็นหลัง
คนรอบตัวก็พยายามจะกระชากจาก comfort zone ให้กลับไปอยู่เนืองๆ
“เออ.. รอแป๊บ ยังไม่หมดไฟ หมดฝัน แค่ตอนนี้มันอ้วนแล้วขี้เกียจขยับ”

จริงๆ อยากเขียนเล่าให้เป็นเรื่องเป็นราวของสิ่งที่พบเจอช่วงไปเนปาลที่ผ่านมา
เกือบทุกวัน ได้มีโอกาสอยู่กับตัวเองด้วยจิตสงบอยู่หลายครั้ง
เป็นเพราะหายใจไม่ออก ไม่พอใจกับการดำรงอยู่กับตนเอง และไม่พอใจกับการอยู่ตรงนั้น
ไม่ใช่เพราะมันอยู่ลำบาก แต่เป็นอารมณ์ที่มันปะทุขึ้นมาตอนตี 4 สะดุ้งตื่น.. “กรูอยากออกไปจากที่ตรงนี้ เดี๋ยวนี้”
เป็นความอึดอัดที่เหมือนถูกขังไว้ในห้องสี่เหลี่ยม กับภูเขา กับอากาศหนาวเหน็บติดลบร่วมสิบองศา
แต่ก็ยังไม่ทรมานเท่า ความอึดอัดที่เหมือนถูกขังให้จมน้ำอยู่ในร่างกายตนเอง แล้วไม่สามารถโผล่หัวออกมาได้
แต่อีกไม่กี่นาที ก็ได้สติว่า เราไม่สามารถเอาตัวเองออกจากตัวเอง และไม่สามารถเอาออกจากสถานที่ตรงนั้นได้
สิ่งเหล่านี้ล้วนเกิดแต่ความคิดชั่ววูบ เช่นนั้นก็ปรับที่ความคิด ด้วยการทำสมาธิอยู่พักใหญ่
แล้วมันก็หายไป…

จากนั้นก็อยู่กับตัวเองไม่ได้อีกหลายวัน
ต้องคอยฟังเพลงขณะเดิน ต้องดูลมหายใจตัวเองก่อนนอน
และทริปนั้นก็เริ่มไม่ค่อยโอเค ทั้งใจ และกาย..

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

มันกลายเป็นสิ่งที่จดจำระดับ trigger ของชีวิต ก่อนถึงวันเกิดแค่ไม่กี่วัน
ตอกย้ำความเชื่อผมที่ว่า คนเราเปลี่ยนแปลงได้ตลอดเวลา และไม่ได้เป็นขาขึ้นเสมอ
มีชอบ ก็มีเกลียด
มีเต็มใจ ก็มีฝืน
มีรุ่งเรื่อง ก็มีเสื่อมถอย
มีแข็งแรง ย่อมมีอ่อนแอ
แต่ถึงกระนั้นอย่างที่เกริ่นไปตอนต้น
ตราบใดยังไม่หมดไฟ ก็ยังจะพยายามให้มันเป็นกราฟขาขึ้นอยู่
ยังคงมีฝันที่อยากแตะความสูง 6,000ม หรือแตะเทรลระยะทาง 100ไมล์
แต่รอก่อนนะ กราฟมันตกแป๊บนึง ขอถอยหลังตั้งหลักสักสองสามก้าว ไปจัดระเบียบชีวิตก่อน
เริ่มต้นใหม่ที่ 41

9 พค 2569
นั่งเขียนสลับเล่นกับมิลินท์เพราะคอยเรียกอยู่ตลอด..