สำหรับโพสต์นี้ เอาใจสาย 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

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพู ได้เรียบเรียงและแปลจากต้นฉบับของ 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/