AI-Native SDLC มนุษย์อยู่ตรงจุดไหน และใช้ส่งต่องานกันอย่างไร

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

พอดีผมไปอ่านบทความของ Anthropic เรื่อง The AI-Native SDLC playbook ของ Louis Claxton ผู้เขียนจาก Anthropic แล้วรู้สึกว่า นี่คือภาคต่อของคำถามนั้นพอดีครับ นอกจากเขาคิดว่า code ไม่ใช่คอขวดแล้ว แต่เขาแบทั้งวงจรว่า ถ้าการสร้างซอร์ฟแวร์ได้เร็วขึ้นจากสัปดาห์-เดือน เหลือเพียงไม่กี่ชั่วโมง การทำ Plan, Design, Test, Deploy และ Maintain จะต้องเปลี่ยนตามอย่างไร

คำตอบของ Louis Claxton คือ AI-Native SDLC ที่เอา AI เข้าไปอยู่ทุกช่วง ใช้เอกสารที่ทั้งคนและ agent อ่านได้ ส่งงานต่อกันได้ วาง automation ในจุดที่ตรวจแบบตรงไปตรงมาได้ แล้วเหลือมนุษย์ไว้ตรงจุดที่ต้องใช้ judgment และรับผิดชอบต่อความเสี่ยง อ่านแล้วตรงกับที่ผมสงสัยในวิธีการที่ผมทำอยู่พอดิบพอดี ซึ่งผมชอบนะ แต่ก็มีหลายจุดที่ในบทความบอกว่าถ้าเอาไปใช้แบบยกชุดโดยไม่ดูบริบท ทีมอาจได้ระบบเอกสารใหม่ที่หนักพอๆ กับของเดิมก็ได้ 5555

หมายเหตุ: บทความนี้เอเจ้นชมพูช่วยแปลและเรียบเรียงจากบทความ The AI-Native SDLC playbook ของ Louis Claxton และใช้มุมมองกับประสบการณ์ของฟิวส์ และค้นข้อมูลเสริมจาก Second Brain ของฟิวส์ เพื่อปรับเรื่องให้ผู้อ่านเห็นภาพชัดเจนยิ่งขึ้น

สรุปสั้นๆ สำหรับคนขี้เกียจอ่าน

• Code ไม่ใช่คอขวดหลักแล้ว แต่คิวงานย้ายไปกองที่ planning, review, security และ deployment
• Artifact chain กลายเป็นทางส่งงาน ผ่าน intent.md, spec.md, plan.md, tests, PR และ incident record
• Guideline กับ control ต้องแยกกัน skills ใช้บอกแนวทาง ส่วน hooks, tests, sandbox และ branch protection ใช้บังคับสิ่งที่ห้ามพลาด
• คนต้อง reskill และรับผิดชอบกว้างขึ้น จากการทำงานเฉพาะช่วง ไปสู่การเข้าใจ architecture, spec, plan, task, implementation และ test ตลอดสาย
• แต่ละสำนักมองคนละมุม Anthropic เน้น control architecture, AWS เน้น AI-first collaboration, McKinsey เน้น operating model, Snyk เน้น security และ Addy Osmani เน้น loop, ส่วนฟิวส์ อะไรที่เขาว่าดี ฟิวส์ก็ว่าดี ฮ่าๆ

วันที่ Build เร็วขึ้น แต่คิวงานรอบข้างยาวกว่าเดิม

SDLC แบบเดิมถูกออกแบบในยุคที่การเขียน code ใช้เวลานาน และมีขั้นตอนสูง เลยจำเป็นต้องมีคนที่ชำนาญเพื่อทำในแต่ละหน้าที่ และส่งต่องานกัน ตั้งแต่ Product Manager/BA เขียน requirement, Architect/SA ออกแบบระบบ, Developer ลงมือสร้าง, QA/Tester ตรวจสอบ, Release team ปล่อยของ และ Operations/Support ทำการเฝ้าดูระบบ ซึ่งแต่ละช่วงเราต้องมีเอกสาร มีการส่งมอบ และมีคนอนุมัติ อาจกินเวลาหลายเดือน เพื่อให้ได้หนึ่งระบบ

พอ coding agent สร้าง implementation ได้เร็วขึ้น โครงสร้างรอบข้างกลับไม่ได้เร็วตาม Security team ยังมีคนเท่าเดิม, Reviewer ยังอ่าน PR ด้วยตาคู่เดิม, Change Advisory Board ก็ยังประชุมตามรอบเดิม ผลคือเราไม่ได้กำจัดคอขวดครับ เราแค่ย้ายมันจากโต๊ะ Developer ไปกองไว้หน้าโต๊ะคนอื่น

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

เรื่องนี้ต่อกับสิ่งที่ผมเขียนไว้ก่อนหน้า แต่บทความของ Anthropic ตั้งคำถามไปไกลกว่า requirement โดยมองครบทั้งหกช่วง ตั้งแต่การ Plan ไปจนถึง Maintain และถามใหม่ว่า control เดิมต้องรักษาอะไรไว้ แล้วควรเปลี่ยนวิธีบังคับอย่างไร มาถึงจุดนี้ เริ่มน่าสนใจแล้วไหมครับ เช่นนั้นตามมาดูกันต่อ

AI-Native SDLC ไม่ได้ตัดขั้นตอน แต่เปลี่ยนวิธีส่งงาน

สิ่งที่ผมคิดว่าน่าสนใจที่สุดคือ committed artifact โดยทุกช่วงการทำงานจะต้องทิ้งของบางอย่างไว้ให้ช่วงถัดไปอ่านได้ ไม่ใช่จบอยู่ในห้องประชุมหรือใน chat ที่หายไปพร้อม context

ผมมองว่ามันเหมือนการส่งไม้ผลัดครับ ถ้าคนวิ่งแต่ละคนส่งกันด้วยคำพูดว่า เอาประมาณที่คุยเมื่อกี้นะ ต่อให้ทุกคนวิ่งเร็ว ไม้ก็หล่นอยู่ดี แต่ถ้า artifact เก็บทั้ง intent, constraint, decision และ proof ไว้ งานช่วงถัดไปก็เริ่มจากสิ่งที่ตรวจย้อนกลับได้

ตรงนี้เชื่อมกับ Spec-Driven Development ที่ผมเคยเขียนไว้ค่อนข้างตรง ต่างกันตรงที่ Spec-Driven Development สนใจ spec ในฐานะ living contract ขณะที่ Anthropic พยายามต่อ contract ให้ครบทั้งสาย ตั้งแต่ความต้องการไปถึง production feedback

ตรงนี้ผมมองว่าเป็นวิวัฒนาการหนึ่งในการใช้ AI เขียนโค้ดนะครับ ตั้งแต่เราทำ Vibe Coding สั่งด้วย Prompt มาจนถึง Context Engineering เขียนเอกสารในฉบับเดียว และมาตอนนี้ที่เราเริ่มเซ็ตเอกสารได้ตามช่วงการทำงาน และใช้ส่งต่องานกันระหว่าง AI เอง และผมคิดว่าผมเป็นคนหนึ่งที่ตามลองอยู่เรื่อยๆ จะเห็นได้ว่าวิวัฒนาการนี้มันไปไวมากนะครับ ภายในระยะเวลาไม่กี่เดือน อะไรที่เคยคิดว่าเหมาะสมแล้ว ก็จะมีที่เหมาะสมกว่า (ผมไม่ได้บอกว่าของเดิมไม่ดีนะ แต่อาจจะเหมาะกับงานบางลักษณะ เช่น การสั่งทีละ prompt ผมก็ยังใช้กับงานโค้ดเล็กๆ อยู่นะ)

เอกสารใน AI-Native SDLC ไม่ควรเป็นรายงานที่เขียนไว้ให้ครบพิธี แต่มันต้องเป็น state ที่ทั้งคนและ agent ใช้ทำงานรอบถัดไปได้จริง

Skills บอกเส้นทางไป ส่วน hooks ทำหน้าที่เป็นรั้วกั้น (Guardrails)

ในบทความเขาแยกบทบาทของเครื่องมือรอบๆ agent ได้ชัดดีครับ

CLAUDE.md คือไฟล์ความรู้ประจำ repository เช่นคำสั่ง build, test, conventions, architecture และสิ่งที่ Claude มักทำพลาด

ส่วน Skills คือความรู้หรือ policy ที่จะถูกเรียกใช้ซ้ำๆ ในงานแต่ละอย่าง เพื่อให้ได้ของที่มีแนวทางเดิมเสมอ

แต่ Skills เป็นคำแนะนำครับ มันช่วยให้ agent มีแนวโน้มทำถูก ไม่ได้แปลว่าจะบังคับได้ทุกครั้ง (ผมเลยใช้คำว่าเป็น “แนวทางเดิม”) ถ้าเป็นกฎที่ห้ามผิด เช่นห้ามอ่าน secret, ห้ามแก้ generated code, ต้อง run test หรือห้าม deploy production โดยไม่มี approval บทความเสนอให้มี Hooks ซึ่งเป็น script ที่ allow, ask หรือ block การกระทำ ร่วมกับการตั้งค่าใน Tools ต่างๆ เช่น permissions, sandbox และ branch protection

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

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

Policy ที่ควรทำ เขียนเป็น skill ได้ แต่ policy ที่ต้องไม่พลาด ควรมี Hooks เป็น deterministic control รองรับ

Test code อย่างเดียวไม่พอ ต้อง test ตัว harness ด้วย

ส่วนที่ผมชอบอีกอย่างคือการพูดถึง continuous evaluations (ในบทความจะเขียนสั้นๆว่า continuous evals) ถ้าเราเปลี่ยน model, prompt, CLAUDE.md, skill หรือ hook แล้วพฤติกรรมของ agent อาจเปลี่ยนทั้งที่ application code ไม่ได้เปลี่ยนเลย ดังนั้น configuration รอบ agent ก็ควรมี regression test ของมันเองด้วย

เรื่องนี้ต้องทดสอบจริงๆครับ จากประสบการณ์ผมเจอเองตั้งแต่ตอนย้ายจาก OpenClaw มา Hermes Agent และที่ทีมผมก็เพิ่งเจอเมื่อเร็วๆ นี้ คือตอนที่ทำ MCP เรียกใช้ข้อมูลในองค์กร โดย harness ที่ต่อ มีทั้งบน Claude, Hermes Agent ที่ผมตั้ง, Agent ที่ทีมผมใช้ Google ADK ทำขึ้น ปรากฎว่าผลลัพธ์มันต่างกันพอสมควร แม้บน LLM Models เดียวกัน ได้คำตอบและ Artifacts ต่างกันแบบเห็นได้ชัด

Anthropic แนะนำให้รวบรวมงานจริงประมาณ 20 ถึง 50 เคส พร้อมผลลัพธ์ที่ยอมรับได้ แล้วรัน suite นี้เมื่อ agent configuration เปลี่ยน สำหรับ bug fix ให้เขียน failing test ก่อน ล็อกไม่ให้ agent แก้ test เพื่อเอาตัวรอด แล้วให้แก้ implementation จน test ผ่าน วิธีนี้ไม่ได้ทำให้ AI ไม่มีวันโกงนะครับ แต่มันทำให้หลักฐานว่าทำงานเสร็จแยกออกจากคำบอกของ agent ชัดขึ้น

แนวคิดนี้สอดคล้องกับ Addy Osmani วิศวกรและผู้เขียนด้าน web performance ที่เสนอเรื่อง Loop Engineering ว่า leverage เริ่มย้ายจากการเขียน prompt ทีละรอบ ไปอยู่ที่ loop ซึ่งค้นงาน มอบหมาย ตรวจผล และเก็บ state ได้เอง ยิ่ง loop ทำงานโดยไม่มีคนเฝ้ามากเท่าไร verifier และ stop condition ก็ยิ่งสำคัญขึ้นเท่านั้น

ผมเคยสรุปอีกมุมของเรื่องนี้ไว้ใน Loop Engineering: 3 ลูปที่ทำร่วมกับ AI Agent เพื่อสร้าง Product ได้จริง ใครสนใจเรื่อง feedback loop ระหว่าง agent, developer และผู้ใช้ ลองอ่านต่อได้ครับ

เมื่อเทียบกับแนวทางของสำนักต่างๆ แต่ละคนกำลังแก้คนละชั้น

ใน Second Brain ของผมมีบทความกลุ่ม AI SDLC ที่เก็บไว้หลายชิ้น พอผมให้วิเคราะห์แล้วเอามาเทียบกันแล้ว พบว่าไม่ได้มีใครเสนอคำตอบเดียวกันทั้งหมด แต่ละสำนักกำลังซ่อมคนละชั้นของระบบ

AWS ใช้ภาพว่า AI เริ่มต้นงาน คนตรวจสอบ แล้ว AI จึงลงมือทำต่อ, McKinsey ขยายไปถึง operating model ที่มนุษย์ใช้เวลากับ judgment และ agent ทำงานที่มีโครงสร้างต่อเนื่อง รวมถึงเสนอ machine-readable handoff กับ knowledge layer เพื่อไม่ให้บริบทกระจัดกระจาย

Snyk เติมคำเตือนที่ควรมีอยู่ในทุก playbook คือ ถ้า AI เร่งทุก phase ได้ มันก็เร่งการสร้าง security debt ได้เช่นกัน จึงต้องมี access control, logging, audit trail และการค่อยๆ เพิ่ม autonomy จาก pilot แทนการเปิดทั้งองค์กรในครั้งเดียว

ส่วน Microsoft ก็มีแนวทาง AI-led SDLC บน Azure และ GitHub ที่พยายามเชื่อม agentic development เข้ากับ delivery pipeline จริง ตั้งแต่ development environment ไปถึงการ promote งานตามลำดับ ผมมองว่ามุมนี้ช่วยเตือนว่า framework จะมีค่าก็ต่อเมื่อมันเชื่อมกับ toolchain ที่ทีมใช้อยู่ ไม่ใช่จบเป็นรูปวงกลมสวยๆ ใน slide

ยืนยันสิ่งที่ตนเองทำร่วมกับทีมทำงาน

ก่อนอ่าน playbook ชิ้นนี้ ผมทำ template และ workflow มาตรฐานกลางให้ทีมในบริษัทใช้อยู่แล้ว ชื่อภายในคือ AI Project Boilerplate เป็นโครงตั้งต้นที่รวม skills, agents, rules, CI และเอกสารมาตรฐานไว้ด้วยกัน เพื่อให้โปรเจกต์ใหม่เริ่มจากวิธีทำงานชุดเดียวกัน แทนที่แต่ละคนจะเปิด coding agent แล้วสั่งกันตามความถนัดของตัวเอง

กระบวนการเริ่มจากมนุษย์เขียน requirement ซึ่งเป็น source of truth จากนั้น AI ช่วย คิด/brainstorming ถามกลับเรื่องขอบเขต เสนอทางเลือก และเขียน design ให้คนอนุมัติ ก่อนแตกออกมาเป็น plan, ADR, Git issue และ feature branch โดยการ implement ผมบังคับให้ใช้ TDD เสมอ และแยก subagent ทำหน้าที่ในการ implementer, tester กับ reviewer แล้วจึงให้คนเข้าทดสอบแบบผู้ใช้จริง ก่อนที่ท้ายสุดเลยคือกระบวนการ Continuous Integration (CI) ในช่วง merge เข้า dev branch จะทำการตรวจ lint, test และ DevSecOps และแจ้งให้ Team Lead review เพื่ออนุมัติการ merge main branch ขึ้น production environment

พอใช้งานจริง ผมพบว่าแนวทางนี้ทำงานได้ดีครับ ทีมไม่ต้องจำว่าจะเรียก skill ไหนต่อ เพราะ workflow พาไปจาก brainstorming, spec, plan, issue, branch, TDD และ review ตามลำดับ Artifact ที่เกิดขึ้นก็ทำให้ย้อนดูได้ว่า งานเริ่มจากโจทย์อะไร ตัดสินใจอะไรไป และผลทดสอบอยู่ตรงไหน

สิ่งที่ตรงกับ Anthropic มากคือ เราไม่ได้พยายามทำให้ AI เก่งด้วย prompt ยาวๆ อย่างเดียว แต่จัด environment รอบมันให้ชัด ทั้งไฟล์กฎ skills ที่เลือกใช้ตามงาน การแยก agent ตามบทบาท และ CI ที่ไม่ยอมให้ของไม่ผ่านเงื่อนไขไหลต่อไปเอง พอระบบรอบข้างดีขึ้น model เดิมก็ทำงานสม่ำเสมอขึ้นอย่างเห็นได้ชัด

ประสบการณ์ของผมคือ AI ทำงานร่วมกับทีมได้ดี เมื่อเราเลิกคาดหวังความเก่งของ model อย่างเดียว แล้วออกแบบ workflow, role และ artifacts ให้ครบ ตามบริบทการทำงานของเรา ซึ่งถ้าใครทำคล้ายๆกันนี้แล้ว บทความของ Anthopic เองเป็นตัวยืนยันว่าคุณมาถูกทาง

ปัญหาที่ยากกว่า tool คือ คนต้องล้างวิธีคิดเดิม

ส่วนที่ผมคิดว่ายากที่สุดกลับไม่ใช่การทำ template หรือเลือก coding agent ครับ แต่คือการ reskill และ upskill คน รวมถึงการล้างวิธีคิดเดิมว่าแต่ละคนรับผิดชอบเฉพาะชิ้นของตัวเองก็พอ

ในกระบวนการเดิม architect อาจส่งแบบให้ developer ต่อมา developer เขียน code แล้วส่งให้ tester จากนั้นแต่ละคนก็รอ feedback จากคนถัดไป แต่เมื่อ AI ทำ implementation ได้เร็วมาก คนทำงานไม่ควรมองเฉพาะ task ตรงหน้าได้เหมือนเดิม เพราะความผิดพลาดจาก spec หรือ architecture จะถูก AI ขยายให้กลายเป็น code และ test จำนวนมากในเวลาไม่นาน

Developer ยุคนี้จึงต้องมองงานตั้งแต่ต้นน้ำถึงปลายน้ำ architecture, spec, plan, task, implementation ไปจนถึง test เองให้ได้ ไม่ได้หมายความว่าทุกคนต้องเก่งที่สุดทุกด้าน หรือองค์กรไม่ต้องมี specialist แล้วนะครับ แต่คนที่ใช้ AI ต้องเข้าใจว่าสิ่งที่อยู่ก่อนและหลัง code เชื่อมกันอย่างไร ต้องกล้าถาม requirement ต้องเห็นผลกระทบเชิงสถาปัตยกรรม ต้องตรวจว่า plan ขาดอะไร และต้องอ่าน test ว่าพิสูจน์ behavior จริงหรือเพียงทำให้ตัวเลข coverage ดูดี

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

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

AI ลดภาระการพิมพ์ code แต่เพิ่มความจำเป็นที่คนทำงานต้องเข้าใจ software ทั้งสาย ตั้งแต่โจทย์จนถึงหลักฐานว่ามันใช้งานได้จริง

ถ้าคนยังทำงานแบบโยนบอลข้ามกำแพง ต่อให้เปลี่ยนกำแพงนั้นเป็น Markdown และมี agent วิ่งรับส่งเอกสารให้ เราก็ยังมี process เดิมที่เคลื่อนที่เร็วขึ้นเท่านั้น ปัญหาของผู้จัดการจึงไม่ใช่แค่ซื้อเครื่องมือหรือเขียน policy แต่ต้องช่วยให้ทีมมองเห็นความรับผิดชอบแบบ end-to-end และให้เวลาเขาในการพัฒนาทักษะที่จำเป็นจริงๆ

ถ้าจะเริ่มกับทีมจริง ผมแนะนำว่าอย่าเริ่มจากระบบอัตโนมัติทั้งวงจร

Playbook ของ Anthropic ยาวและครอบคลุมมาก ถ้าอ่านแล้วเกิดไฟลุก ไปพยายามทำทุกอย่างพร้อมกัน เราอาจใช้เวลาสร้าง process จนไม่ได้ส่งของจริงๆ ผมแนะนำให้เริ่มจากส่วนที่ลดงานซ้ำและตรวจผลได้ก่อน

1. ทำคำสั่ง build, test และ lint ให้ agent เรียกใช้ได้ง่าย และคืนผลสำเร็จหรือล้มเหลวชัดเจน
2. เขียน CLAUDE.md หรือ AGENTS.md ให้สั้นพอที่จะอ่านจริง เก็บ conventions กับ recurring mistakes ที่กระทบงาน
3. กำหนดว่างานระดับไหนต้องมี intent.md, spec.md และ plan.md งานเล็กไม่จำเป็นต้องแบกเอกสารเท่างานเสี่ยงสูง
4. เลือก policy ที่ห้ามผิดเลย สักหนึ่งหรือสองเรื่อง แล้วทำ hook หรือ CI check ให้บังคับได้จริง
5. เก็บงานจริงเป็น eval ทีละเคส โดยเฉพาะ bug หรือ review comment ที่เกิดซ้ำ
6. เมื่อ feedback loop และ rollback ใช้งานได้แล้ว ค่อยเพิ่ม autonomy ใน development ก่อนขยับไป staging และ production

อย่าเริ่ม AI-Native SDLC ด้วยการให้อำนาจ agent มากขึ้น เริ่มด้วยการทำให้มันพิสูจน์งานของตัวมันเองได้ก่อน

อีกเรื่องที่ต้องตกลงให้ชัดคือ source of truth ถ้าองค์กรใช้ Jira/ServiceNow เป็นระบบหลักอยู่แล้ว ไม่จำเป็นต้องย้ายทุกอย่างเข้า Markdown แต่ artifact ใน repository กับ record ในระบบเดิมต้องเชื่อมกลับหากันได้ ไม่อย่างนั้นเราจะได้ข้อมูลสองชุดที่ดูน่าเชื่อถือพอๆ กัน แล้วไม่มีใครรู้ว่าชุดไหนล่าสุด อันนี้น่ากลัวกว่าไม่มีเอกสารอีกครับ 555

ส่วนตัวผม ไม่ได้ใช้พวก Project Management อย่าง Jira/ServiceNow อยู่แล้ว ข้อนี้ผมเลยทำ spec/plan/task หลักไว้ที่ Markdown แต่ผมให้แตก task ไว้บน GitLab Issues และให้ AI จัดการปิดงานตาม Checklist ด้วย เพื่อคอย monitor สถานะงานและใข้รวบรวมเปิด PR Merge แทนคน

บทสรุป

หลังอ่าน The AI-Native SDLC playbook แล้วเทียบกับสิ่งที่ผมกำลังทำกับทีม ผมรู้สึกว่าประโยค code is no longer the bottleneck เป็นเพียงตัวเปิดเรื่อง สิ่งที่กำลังเปลี่ยนจริงคือทั้งหน่วยของการทำงานและขอบเขตความรับผิดชอบ จากเดิมที่แบ่งกันตามตำแหน่ง กลายเป็นการส่งต่อ intent, constraint, implementation และ proof ผ่าน artifact ที่ตรวจย้อนหลังได้ โดยคนทำงานต้องเข้าใจความเชื่อมโยงของมันตลอดสาย

ผมยังไม่คิดว่าทุกทีมควรเปลี่ยนไปใช้ไฟล์ intent.md หรือ spec.md เหมือนกันหมด ชื่อไฟล์ไม่ใช่สาระเท่ากับคำถามว่า คนกับ agent กำลังอ่านความจริงชุดเดียวกันหรือเปล่า งานที่บอกว่าเสร็จมีหลักฐานอะไร และใครเป็นคนมีสิทธิ์รับความเสี่ยงเมื่อจะขึ้น production

ถ้าเราตอบสามข้อนี้ไม่ได้ การเพิ่ม agent อีกสิบตัวอาจทำให้ทีมผลิตของที่ต้องตามแก้ได้เร็วขึ้นเท่านั้น แต่ถ้าตอบได้ AI-Native SDLC ก็ไม่ใช่ buzzword ใหม่ครับ มันคือการค่อยๆ เปลี่ยน process ให้ความเร็วของ AI ไม่วิ่งหนีความสามารถในการควบคุมของทีม

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

ผู้อ่านได้อะไรจากบทความนี้

• มองเห็นคอขวดใหม่ หลัง AI ทำให้การเขียน code เร็วขึ้น
• เข้าใจ artifact chain ตั้งแต่ intent, spec และ plan ไปจนถึง production feedback
• แยกคำแนะนำออกจากการบังคับ ว่าเรื่องใดใช้ skill และเรื่องใดควรมี hook หรือ CI gate
• เห็นความต่างของแต่ละแนวทาง จาก Anthropic, AWS, McKinsey, Snyk, Microsoft และ Addy Osmani
• มีลำดับเริ่มต้นที่เล็กพอ สำหรับทดลองกับทีม โดยเริ่มจาก verification ก่อน autonomy
• วางแผน reskill ทีม ให้คนเข้าใจ architecture, spec, plan, implementation และ test แบบ end-to-end พร้อมปรับบทบาทของหัวหน้าทีมจากผู้ติดตามงานเป็นผู้ออกแบบระบบการทำงาน

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

• The AI-Native SDLC playbook โดย Louis Claxton, Anthropic
• AI-Driven Development Life Cycle จาก AWS
• Rewiring software delivery for the agentic era จาก McKinsey & Company
• Complete guide to AI-powered software development จาก Snyk
• Loop Engineering โดย Addy Osmani
• An AI-led SDLC with Azure and GitHub จาก Microsoft