OpenAI Symphony: เมื่อ Issue Tracker กลายเป็นหัวหน้าทีม Codex Agent

ปัญหาใหญ่ของ AI agent ไม่ใช่ว่ามันเขียนโค้ดไม่ได้แล้วครับ

แต่คือ คนคุมไม่ทัน

OpenAI เพิ่งเปิดตัว Symphony เป็น open-source specification และ reference implementation สำหรับ orchestrate Codex coding agents ผ่าน issue tracker เช่น Linear

ฟังเผิน ๆ เหมือนเป็นข่าวสำหรับ developer เท่านั้น

แต่ผมว่าไม่ใช่ครับ

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

เพราะเมื่อ agent เก่งขึ้น ปัญหาไม่ได้อยู่ที่มันทำงานไม่เป็นอย่างเดียว

ปัญหาใหม่คือ:

มนุษย์จะออกแบบงาน ตรวจงาน และคุม agent หลายตัวอย่างไร โดยไม่ให้ attention ตัวเองพัง

1) Symphony เกิดจาก bottleneck ที่หลายทีมกำลังจะเจอ

ในบทความ OpenAI เล่าว่า ทีมเคยทดลองสร้าง internal project ที่ไม่มี human-written code เลย

ทุกอย่างให้ Codex เขียน:

• application logic
• tests
• CI configuration
• documentation
• observability
• tooling

แนวคิดนี้ต่อยอดจากสิ่งที่ OpenAI เรียกว่า Harness Engineering

หรือพูดง่าย ๆ คือ มนุษย์ไม่ได้ทำหน้าที่เขียน code ทุกบรรทัดแล้ว

มนุษย์ทำหน้าที่ออกแบบสนามให้ agent ทำงานได้ดี:

• repo structure
• docs
• tests
• guardrails
• automation
• review loop
• tools ที่ agent ใช้เองได้

พอทำแบบนี้ Codex ทำงานได้เร็วมาก

แต่ปัญหาใหม่เกิดขึ้นทันที

OpenAI บอกว่า engineer คนหนึ่งมักคุม Codex session ได้สบาย ๆ ประมาณ 3 ถึง 5 sessions

มากกว่านั้นเริ่มเหนื่อย

เพราะต้องจำว่า session ไหนกำลังทำอะไร

ต้องสลับ terminal

ต้องอ่าน output

ต้องคอย nudge

ต้องดูว่าอันไหน fail, อันไหนค้าง, อันไหนควรปล่อยต่อ

บทความสรุปไว้ตรงมาก:

The agents were fast, but we had a system bottleneck: human attention.

นี่คือประโยคที่ผมว่าทุกบริษัทที่อยากใช้ AI agent ควรแปะไว้หน้าห้องประชุมครับ

เพราะถ้าเราเพิ่ม agent แต่ไม่เพิ่มระบบคุม agent

เราจะไม่ได้ automation

เราจะได้ attention debt

2) Shift สำคัญ: จาก “session” ไปเป็น “ticket”

ก่อนมี Symphony วิธีทำงานกับ coding agent จำนวนมากมักผูกกับ session

เปิด Codex session หนึ่ง

ให้มันทำงานหนึ่ง

รอดูผล

เปิดอีก session

ให้มันทำอีกงาน

ปัญหาคือโลกธุรกิจไม่ได้จัดงานด้วย session

โลกธุรกิจจัดงานด้วย:

• issue
• ticket
• task
• milestone
• customer request
• bug
• feature
• deliverable

Symphony จึงเปลี่ยน unit of work จาก Codex session เป็น issue tracker ticket

ใน model นี้ issue tracker กลายเป็น control plane

มี ticket ที่พร้อมทำ ก็มี agent ไปทำ

agent แต่ละตัวมี workspace แยกของตัวเอง

ระบบคอยดูว่า ticket ไหน eligible, ticket ไหน blocked, agent ไหนค้าง, agent ไหน fail และควร retry เมื่อไร

ประโยคแกนของ Symphony คือ:

For every open task, guarantee that an agent is running in its own workspace.

แปลแบบ Data-Espresso:

ถ้างานเปิดอยู่และพร้อมทำ ระบบต้องมี agent รับผิดชอบงานนั้นใน workspace ของตัวเอง

นี่เป็นแนวคิดที่ powerful มาก

เพราะมันเปลี่ยน AI agent จาก “ของเล่นที่คนต้องเรียกใช้เอง” เป็น “worker ที่ผูกกับระบบงานขององค์กร”

3) ทำไม Issue Tracker ถึงเหมาะเป็น control plane ของ AI agent

หลายคนอาจถามว่า ทำไมไม่ทำ dashboard ใหม่ไปเลย

คำตอบคือ issue tracker มีสิ่งที่ทีมใช้จัดงานอยู่แล้ว:

• title
• description
• labels
• status
• priority
• assignee
• dependency
• comments
• links to PR
• review history

ถ้าเอา agent ไปผูกกับระบบนี้ ทีมไม่ต้องสร้าง world ใหม่ทั้งหมด

แค่ทำให้ ticket อ่านง่ายพอสำหรับ agent

ใน Symphony spec เวอร์ชันนี้ Linear เป็น tracker หลัก

แต่บทเรียนใหญ่กว่า Linear ครับ

บทเรียนคือ ticket ต้องกลายเป็น contract ระหว่างมนุษย์กับ agent

ticket ที่ดีในยุค agent ไม่ใช่แค่ “ทำ feature X”

แต่ควรมี:

• context ว่าทำไมต้องทำ
• scope ว่าอะไรอยู่ในงานนี้ อะไรไม่อยู่
• definition of done
• test หรือ validation ที่ต้องผ่าน
• constraint ด้าน security, data, UX, performance
• expected proof เช่น screenshot, log, test output, PR link

ถ้า ticket คลุมเครือ agent จะเดา

และถ้า agent เดาผิด มันอาจไม่ได้ผิดแบบช้า ๆ

มันจะผิดแบบเร็วมาก

4) Symphony ไม่ใช่แค่ dispatcher แต่เป็น operating loop

จาก SPEC.md ของ Symphony แกนระบบมีหลายชั้น:

1. Workflow Loader อ่าน WORKFLOW.md ใน repo เพื่อรู้ policy และ prompt template
2. Config Layer จัดการ setting และ validation
3. Issue Tracker Client ดึง candidate issues และ normalize ข้อมูล
4. Orchestrator คุม poll tick, concurrency, retry, stopped work และ runtime state
5. Workspace Manager สร้าง workspace แยกตาม issue
6. Agent Runner เปิด Codex app-server ใน workspace นั้น
7. Logging และ status surface ช่วยให้คน debug ได้

พูดง่าย ๆ คือ Symphony ทำให้งาน agent มี lifecycle

ไม่ใช่แค่ “prompt แล้วหวังว่ามันจะเสร็จ”

แต่มีวงจร:

• เห็นงาน
• ตัดสินว่าเริ่มได้ไหม
• สร้าง workspace
• ส่ง prompt + context
• รัน agent
• เก็บ log
• retry ถ้าพลาดชั่วคราว
• หยุดถ้า ticket ไม่ eligible แล้ว
• เปิดพื้นที่ให้ human review

จุดที่ผมชอบคือ policy อยู่ใน repo ผ่าน WORKFLOW.md

เพราะสำหรับ agent workforce แล้ว policy ต้อง version-controlled เหมือน code

ถ้าเราสั่ง agent ด้วยกฎลอย ๆ ในหัวคน กฎจะหาย กฎจะเปลี่ยน และ agent จะทำงานไม่สม่ำเสมอ

แต่ถ้ากฎอยู่ใน repo มันตรวจได้ แก้ได้ review ได้ และ evolve ตามทีมได้

5) สิ่งที่น่ากลัวกว่า “AI เขียนโค้ดได้” คือ “AI สร้างงานต่อเองได้”

บทความ OpenAI เล่าว่า ticket หนึ่งไม่จำเป็นต้องจบเป็น PR เดียว

บาง ticket อาจกลายเป็น:

• PR เดียว
• หลาย PR ข้าม repo
• investigation report
• implementation plan
• follow-up task tree

และ agent อาจสร้าง issue ใหม่เมื่อเจอ:

• performance problem
• refactoring opportunity
• architecture smell
• out-of-scope improvement

นี่คือจุดที่น่าสนใจมาก

เพราะ agent ไม่ได้แค่ทำงานที่ได้รับมอบหมาย

มันเริ่ม “จัดระเบียบงานใหม่” ได้ด้วย

ถ้าทำดี นี่คือ leverage มหาศาล

เช่น ให้ agent วิเคราะห์ codebase แล้วแตกงาน migration ออกเป็น DAG

งานไหน blocked ก็ยังไม่เริ่ม

งานไหนไม่ blocked ก็วิ่ง parallel ได้

OpenAI ยกตัวอย่างงาน React upgrade ที่ต้องรอ Vite migration ก่อน

Symphony จะไม่ dispatch งาน upgrade จน blocker เสร็จ

นี่เริ่มเหมือนทีมวิศวกรรมจริงมากขึ้น

ไม่ใช่ prompt เดียวทำทุกอย่าง

แต่เป็นระบบที่แตกงาน รอ dependency และ parallelize งานที่ปลอดภัยได้

6) ตัวเลข 500% น่าสนใจ แต่ไม่ควรอ่านแบบตื่นเต้นเกินไป

OpenAI รายงานว่าบางทีมเห็น landed PR เพิ่มขึ้น 500% ใน 3 สัปดาห์แรกหลังใช้ workflow แบบนี้

ตัวเลขนี้น่าสนใจมากครับ

แต่ผมอยากให้ตีความอย่างระวัง

500% ไม่ได้แปลว่าทุกทีมติดตั้ง Symphony แล้ว productivity จะเพิ่ม 5 เท่าทันที

เพราะเงื่อนไขเบื้องหลังสำคัญมาก:

• repo ต้อง agent-friendly
• tests ต้องดีพอ
• CI ต้องเชื่อถือได้
• task ต้องเขียนชัด
• review process ต้องรับ throughput ได้
• security boundary ต้องชัด
• คนต้องรู้ว่า output แบบไหนควรเชื่อ และแบบไหนควร reject

ถ้าไม่มีสิ่งเหล่านี้ การเพิ่ม agent อาจเพิ่ม noise มากกว่า output

ในภาษาองค์กร:

AI throughput จะขยายทั้งคุณภาพและความเละของ process เดิม

ถ้า process ดี agent จะช่วย scale

ถ้า process มั่ว agent จะช่วยทำให้ความมั่วเกิดเร็วขึ้น

7) บทเรียนสำหรับทีมไทย: อย่าเริ่มจาก “มี agent กี่ตัว” ให้เริ่มจาก “งานชัดแค่ไหน”

หลายทีมกำลังถามว่า ควรมี coding agent ไหม

ผมว่าเป็นคำถามที่ยังไม่พอ

คำถามที่ควรถามก่อนคือ:

งานของเราพร้อมให้ agent รับไปทำหรือยัง

ลองเช็ค 7 ข้อนี้ครับ

1. มี issue tracker ที่ทีมใช้จริงไหม
2. ticket เขียน context พอไหม หรือมีแค่หัวข้อสั้น ๆ
3. มี definition of done ไหม
4. มี automated tests หรือ smoke tests ไหม
5. มี environment ที่ agent รันได้เองไหม
6. มี review gate ก่อน merge หรือ publish ไหม
7. มี rollback path ไหม ถ้างาน agent พลาด

ถ้าตอบ “ยัง” หลายข้อ ผมไม่แนะนำให้เริ่มจาก orchestration ใหญ่ ๆ

เริ่มจากทำ repo และ workflow ให้ agent-friendly ก่อน

เช่น:

• เขียน AGENTS.md ให้ชัด
• ทำ command ทดสอบให้รันง่าย
• ทำ seed data หรือ mock environment
• แยก task ให้เล็กพอ
• เพิ่ม checklist ใน issue template
• ให้ agent ต้องแนบ proof ทุกครั้ง
• ใช้ labels แยกงานที่ให้ AI ทำได้กับงานที่ต้องมนุษย์ดูเอง

ตรงนี้อาจดูน่าเบื่อ

แต่เป็น infrastructure ของความเร็วครับ

8) สำหรับธุรกิจที่ไม่ใช่ software house ก็ยังเกี่ยวมาก

แม้ Symphony จะเริ่มจาก coding agents

แต่ pattern นี้ไม่ได้หยุดที่ code

ลองแทน Codex ด้วย agent แบบอื่น:

• content agent
• sales research agent
• customer support agent
• data analyst agent
• compliance review agent
• training material agent

แล้วแทน issue tracker ด้วยระบบงานของบริษัท:

• CRM task
• support ticket
• campaign calendar
• content queue
• onboarding checklist
• internal request form

หลักคิดเดียวกันใช้ได้เลย:

งานต้องถูกจัดรูปให้ agent เข้าใจ ทำเอง ส่ง proof และรอมนุษย์ตัดสินใจในจุดสำคัญ

นี่คือเหตุผลที่ผมมอง Symphony เป็นสัญญาณของ operating model ใหม่

ไม่ใช่แค่เครื่องมือ developer ตัวหนึ่ง

บริษัทที่เริ่มจัดงานเป็น ticket ที่ชัด จะพร้อมกว่าเมื่อ AI agent เก่งขึ้น

บริษัทที่งานยังอยู่ในแชตกระจัดกระจาย จะเอา AI ไปต่อยากกว่า

9) ความเสี่ยง: Orchestration ไม่ได้แทน governance

จุดที่ต้องระวังคือ อย่าเข้าใจผิดว่า orchestration แปลว่าปลอดภัยแล้ว

Symphony ช่วย dispatch, isolate workspace, retry และ observe ได้

แต่ไม่ได้ทำให้ทุกงานถูกต้องโดยอัตโนมัติ

SPEC.md เองก็ชัดว่า Symphony ไม่ใช่ rich web UI, ไม่ใช่ general workflow engine, ไม่ได้ prescribe sandbox policy เดียว และไม่ได้บังคับ approval policy เดียวสำหรับทุกกรณี

แปลว่าแต่ละทีมยังต้องออกแบบ governance เอง

สิ่งที่ต้องมีคือ:

• permission boundary
• secret handling
• data access rules
• branch protection
• CI gate
• human approval สำหรับงานเสี่ยง
• audit log
• incident rollback

โดยเฉพาะในธุรกิจไทยที่มีข้อมูลลูกค้า เอกสารภายใน หรือระบบ production จริง

อย่าปล่อย agent ทำงานเหมือน intern ที่ถือกุญแจทุกห้อง

ให้มันทำงานเหมือนทีมงานที่มี badge access ตามหน้าที่

เข้าได้เท่าที่จำเป็น

ทำได้เท่าที่อนุญาต

และทุก action สำคัญต้องตรวจย้อนหลังได้

10) มุมมองของผม: คนที่ชนะคือคนที่ออกแบบ “งาน” ให้ AI ทำได้ดี

💡 ในความเห็นของผม Symphony สำคัญเพราะมันชี้ว่า AI coding กำลังเข้า phase ใหม่

phase แรกคือ AI ช่วยเขียน code

phase ต่อมาคือ AI ทำ task ได้

phase ที่กำลังมา คือ AI รับงานจากระบบงานจริง แล้วทำต่อเนื่องจนมี proof ให้มนุษย์ review

นี่เปลี่ยน skill ของหัวหน้าทีมและ founder มาก

จากเดิมถามว่า:

“ใครเขียน code เก่งที่สุด?”

เริ่มกลายเป็น:

“ใครออกแบบระบบงานให้คนและ AI agent ทำงานร่วมกันได้ดีที่สุด?”

ในยุคนี้ ticket ไม่ใช่แค่ reminder

ticket คือ spec

ticket คือ contract

ticket คือ context package

ticket คือ boundary

ticket คือจุดเริ่มต้นของ execution

ถ้า ticket ดี agent จะวิ่งได้เร็ว

ถ้า ticket แย่ agent จะเดาเร็ว

และการเดาเร็วในระบบ production ไม่ใช่เรื่องน่ารักครับ

สรุป

Codex ทำให้การเขียนโค้ดเร็วขึ้น

Symphony ทำให้การคุม Codex หลายตัวเริ่มเป็นระบบขึ้น

แต่บทเรียนใหญ่กว่านั้นคือ:

อนาคตของ AI agent ไม่ได้อยู่ที่ model อย่างเดียว แต่อยู่ที่ operating system รอบตัวมัน

ถ้าทีมมี issue tracker ที่ดี มี test มี proof มี review และมี governance

AI agent จะกลายเป็นแรงขยายมหาศาล

แต่ถ้าทีมยังไม่มีระบบงานที่ชัด

AI agent จะขยายความมั่วให้เร็วขึ้นเหมือนกัน

สำหรับ SME ไทย ผมยังไม่แนะนำให้เริ่มจาก “ติดตั้ง orchestrator ใหญ่ ๆ” ทันที

เริ่มจากทำงาน 3 อย่างก่อน:

1. เขียน ticket ให้ AI เข้าใจได้
2. สร้าง proof/checklist ให้ AI ต้องส่งกลับมา
3. ทำ review gate ให้คนตัดสินใจในจุดที่เสี่ยง

พอ 3 อย่างนี้แข็งแรงขึ้น ค่อยเพิ่ม agent และ orchestration

เพราะเป้าหมายไม่ใช่มี agent เยอะที่สุด

เป้าหมายคือมีระบบที่ทำให้ agent ทำงานแทนเราได้จริง โดยเรายังถือพวงมาลัยอยู่ครับ