- สำหรับข้ออ้างของ agentic coding ที่ว่า “สามารถใช้เอกสารสเปกแทนโค้ดได้” มีการชี้ให้เห็นข้อจำกัดพื้นฐานว่า เมื่อสเปกมีความแม่นยำมากพอ สุดท้ายก็หลีกเลี่ยงไม่ได้ที่จะลู่เข้าไปสู่ รูปแบบเดียวกับโค้ด
- เมื่อดูโครงการ Symphony ของ OpenAI จะเห็นว่า SPEC.md นั้นไม่ใช่สเปก แต่แท้จริงแล้วคือ pseudocode ในรูปแบบ Markdown
- เมื่อลองอิมพลีเมนต์ด้วย Haskell โดยอิงจากสเปกของ Symphony จริง ๆ พบปัญหาความน่าเชื่อถือ เช่นบั๊กจำนวนมากและ เอเจนต์ค้างรอไม่สิ้นสุด
- เดิมทีงานเขียนสเปกต้องใช้การคิดที่ลึกกว่าการเขียนโค้ด แต่ในกระแสอุตสาหกรรมปัจจุบันที่ มุ่งเพิ่มความเร็ว กลับกลายเป็นโครงสร้างที่ผลิตสเปกคุณภาพต่ำจาก AI ออกมาจำนวนมาก
- หลักการ “garbage in, garbage out” ใช้ได้กับ coding agent เช่นกัน และเอกสารที่ขาดความชัดเจนกับรายละเอียดก็ ไม่อาจสร้างโค้ดที่เชื่อถือได้
ความเข้าใจผิด 2 ประการของ agentic coding
- มีความเข้าใจผิดหลัก 2 ประการที่ผู้สนับสนุน agentic coding ยึดถือ
- ความเข้าใจผิด 1: เอกสารสเปกเรียบง่ายกว่าโค้ดที่สอดคล้องกัน — มองแบบการเอาต์ซอร์ซว่าผู้พัฒนาสามารถเปลี่ยนบทบาทเป็นผู้จัดการที่เขียนเอกสารสเปก แล้วมอบงานให้ทีมเอเจนต์ทำได้
- ความเข้าใจผิด 2: งานเขียนสเปกย่อมรอบคอบกว่างานเขียนโค้ดเสมอ — เชื่อว่าการผ่านเอกสารสเปกจะช่วยยกระดับคุณภาพและส่งเสริมแนวปฏิบัติทางวิศวกรรมที่ดีกว่า
โค้ดที่ปลอมตัวเป็นสเปก: วิเคราะห์กรณีของ Symphony
- โครงการ Symphony ของ OpenAI ถูกนำเสนอว่าเป็น agent orchestrator ที่สร้างจากเอกสารสเปก (SPEC.md) แต่เมื่อดูเนื้อหาจริงใน SPEC.md จะพบว่ามันใกล้เคียงกับ pseudocode ในรูปแบบ Markdown มากกว่าสเปก
- ประเภทของเนื้อหาที่อยู่ใน SPEC.md:
- การ dump schema ฐานข้อมูลแบบร้อยแก้ว — ไล่รายการฟิลด์อย่าง
session_id, thread_id, codex_input_tokens เป็นต้น
- การถอดโค้ดเป็นข้อความร้อยแก้ว — เช่นสูตรควบคุม concurrency อย่าง
available_slots = max(max_concurrent_agents - running_count, 0) หรือสูตร retry backoff (delay = min(10000 * 2^(attempt-1), agent.max_retry_backoff_ms))
- ส่วนที่ซ้ำซ้อนอย่าง "Config Fields Summary (Cheat Sheet)" ซึ่งเพิ่มเข้ามาอย่างชัดเจนเพื่อช่วยให้โมเดลสร้างโค้ดได้ง่ายขึ้น
- ส่วน "Reference Algorithms" ที่แทบจะเป็น โค้ดโดยตรง เช่นฟังก์ชัน
start_service()
- การอ้างว่าเอกสารสเปกเป็นสิ่งทดแทนโค้ด ทั้งที่ตัวเอกสารเองกลับอ่านเหมือนโค้ด ถือเป็นเรื่อง ชวนให้เข้าใจผิด
- หากต้องการให้เอกสารสเปกมีความแม่นยำเพียงพอ ก็ จำเป็นต้องแปลงมันให้เป็นรูปแบบโค้ด หรือไม่ก็เขียนด้วยภาษาอังกฤษเชิงรูปแบบที่มีโครงสร้างสูง
ข้อโต้แย้งเรื่อง “อินเทอร์เฟซที่แคบ” ของ Dijkstra
- มีการอ้างงานเขียนของ Dijkstra ว่าการเลือกอินเทอร์เฟซไม่ใช่แค่การแบ่งงานง่าย ๆ แต่ยังเพิ่ม ต้นทุนของการทำงานร่วมกันและการสื่อสาร ข้ามอินเทอร์เฟซด้วย
- ยกตัวอย่างทางประวัติศาสตร์ว่า คณิตศาสตร์กรีกหยุดชะงักเพราะติดอยู่กับกิจกรรมเชิงภาษาและเชิงภาพ, พีชคณิตอิสลามเสื่อมถอยเมื่อหวนกลับไปสู่รูปแบบเชิงวาทศิลป์, และ ยุโรปตะวันตกพัฒนาขึ้นได้เพราะหลุดพ้นจาก “ความพยายามสร้างความแม่นยำทางภาษาที่ไร้ผล” ของสกอลาสติกยุคกลาง แล้วหันมาใช้ระบบสัญลักษณ์เชิงรูปแบบของ Vieta, Descartes, Leibniz และ Boole
- นักพัฒนาแบบ agentic หลีกเลี่ยง “อินเทอร์เฟซที่แคบ” (= โค้ด) ที่แรงงานวิศวกรรมต้องการไม่ได้ และทำได้เพียง แปลงแรงงานนั้นไปอยู่ในรูปแบบอื่น ที่ภายนอกดูต่างออกไป แต่ยังคงต้องการความแม่นยำระดับเดียวกัน
ความไม่เสถียร: ปัญหาความน่าเชื่อถือของการสร้างโค้ดจากสเปก
- เมื่อลองทำตามที่ README ของ Symphony แนะนำ โดยให้ Claude Code อิมพลีเมนต์ด้วย Haskell ผลคือ ใช้งานไม่ได้
- เกิดบั๊กจำนวนมาก และต้องแก้ผ่านพรอมป์ต์เพิ่มเติม (ตรวจสอบได้จากประวัติ commit)
- แม้ในกรณีที่ดูเหมือน “ทำงาน” โดยไม่มีข้อความ error แต่เอเจนต์
codex ก็ ค้างรอแบบไม่คืบหน้าไม่สิ้นสุด กับงาน Linear ง่าย ๆ (“สร้าง git repository ว่าง”)
- หากยืมถ้อยคำของ Dijkstra มาใช้ ก็กล่าวได้ว่า “ความพยายามสร้างความแม่นยำทางภาษาที่ไร้ผล” ของ Symphony ยัง ล้มเหลวในการสร้างอิมพลีเมนต์ที่เชื่อถือได้
- ปัญหานี้ไม่ได้จำกัดอยู่แค่ Symphony — แม้แต่สเปกอย่าง YAML ที่ละเอียดมาก ใช้กันแพร่หลาย และมีชุดทดสอบความสอดคล้องครบถ้วน ก็ยังมีอิมพลีเมนต์ YAML ส่วนใหญ่ที่ ไม่สามารถทำตามสเปกได้ครบถ้วน
- สเปกของ Symphony มีขนาดถึง 1/6 ของอิมพลีเมนต์ Elixir ที่รวมมาแล้ว และหากขยายต่อไปก็จะไปสู่สถานการณ์แบบเรื่องเปรียบเปรยของ Borges ใน “On Exactitude in Science” ที่สร้างแผนที่ขนาดเท่าจักรวรรดิ จนสุดท้ายไร้ประโยชน์
- สำหรับข้อโต้แย้งว่า “ถ้าให้สร้างด้วยภาษาที่เป็นกระแสหลักกว่านี้ ผลลัพธ์คงดีกว่า” ผู้เขียนชี้ว่าหากเอเจนต์ยังลำบากกับการสร้างโค้ด Haskell ก็สะท้อนถึง การขาดความสามารถในการ generalize เลยข้อมูลฝึก
Slop: ปัญหาคุณภาพของสเปกที่ AI สร้าง
- โดยหลักแล้ว งานเขียนสเปกควร ยากกว่าการเขียนโค้ด และมีจุดประสงค์เพื่อบังคับให้มองโครงการอย่างครุ่นคิดและวิพากษ์วิจารณ์ก่อนเริ่มลงมือเขียนโค้ด
- แต่ในกระแสอุตสาหกรรมที่มุ่งลดทอนและลดคุณค่าของแรงงานในบริษัทเทคโนโลยี หากเริ่มต้นจากสมมติฐานว่า “งานเขียนสเปกง่ายกว่างานเขียนโค้ด” ก็ ถูกกำหนดให้ล้มเหลวตั้งแต่แรก
- การพยายาม optimize ความเร็วในการส่งมอบ ไปพร้อมกับทำงานเขียนสเปกซึ่งทั้งยากและไม่สบายตัวนั้นเป็นไปไม่ได้
- Section 10.5 ของ SPEC.md ของ Symphony (
linear_graphql extension contract) เป็นตัวอย่างเด่นของ slop — ผลลัพธ์จากเอเจนต์ที่เป็น ประโยคซึ่ง “ดูเหมือนสเปก” แต่ขาดทั้ง ความสอดคล้อง จุดมุ่งหมาย และความเข้าใจภาพรวม
- มีการไล่กฎย่อยทีละข้อ เช่น
query ต้องเป็นสตริงที่ไม่ว่าง ต้องมี GraphQL operation เพียงหนึ่งเดียวอย่างแม่นยำ ฯลฯ แต่ ไม่มีบริบทโดยรวม
- ต่อให้เอกสารสเปกแบบนี้จะเขียนโดยมนุษย์ มันก็ หลีกไม่พ้นที่จะเป็น slop เพราะถูก optimize เพื่อเวลาส่งมอบ ไม่ใช่เพื่อความสอดคล้องหรือความชัดเจน
- การที่ code snippet ถูกใส่เป็นคอมเมนต์แบบ
text โดยไม่มี syntax highlighting ก็เป็น สัญญาณของเอกสารที่ AI สร้าง — คาดว่าเป็นผลจากโมเดลทำตามคำสั่งแบบตัวอักษร มากกว่าจะเข้าใจเจตนาของคำขอ
บทสรุป
- โดยเดิมแล้ว สเปก ไม่ได้ถูกออกแบบมาเพื่อประหยัดเวลา
- หากเป้าหมายคือ optimize เวลาส่งมอบ การ เขียนโค้ดโดยตรง ย่อมได้เปรียบกว่าการมีเอกสารสเปกคั่นกลาง
- หลักการ “garbage in, garbage out” ยังใช้ได้ตรงตัว — หากป้อนเอกสารที่ขาดความชัดเจนและรายละเอียด ก็ไม่มีโลกไหนที่ coding agent จะเติมส่วนที่หายไปได้อย่างน่าเชื่อถือ
- coding agent ไม่ใช่สิ่งมีชีวิตที่อ่านใจได้ และต่อให้มันทำได้จริง หากความคิดตั้งต้นยังสับสน มันก็ช่วยอะไรไม่ได้
6 ความคิดเห็น
เหมือนกับตอนทำ Model-Driven Development เลยครับ
การพัฒนาที่ขับเคลื่อนด้วยสเปกอย่าง SDD เดิมทีก็มีอยู่แล้วไม่ใช่เหรอครับ
ดูเหมือนว่าโซลูชันที่อิงกับ Python หรือ JavaScript จะสามารถทำ implementation ที่น่าพอใจได้ด้วยเอกสารสเปกระดับรายละเอียดเพียงอย่างเดียว ผมทำงานฝั่งเกม/การแพทย์ที่อิงกับ C/C++ และช่วงนี้ยิ่งรู้สึกมากขึ้นว่า ไม่ต้องพูดถึงการมอบหมายให้ FULL AI AGENT ทั้งหมดเลย แม้แต่การทำให้เป็นอัตโนมัติด้วยเอกสารสเปกระดับรายละเอียดเพียงอย่างเดียวก็ยังเป็นการเสี่ยงเกินไปมาก
ความคิดเห็นจาก Hacker News
ไม่เห็นด้วยกับคำกล่าวที่ว่าใส่เอกสารที่ไม่ชัดเจนลงไปแล้ว coding agent จะเติมรายละเอียดให้ไม่ได้
โดยพื้นฐานแล้ว LLM คือ เครื่องจักรสำหรับ interpolation/extrapolation ของภาษา จึงเก่งมากในการเติมรายละเอียดที่ขาดหายไป
มีหลายกรณีที่มันสร้างโค้ดที่ใช้งานได้จากคำอธิบายสั้นและกระชับเท่านั้น
อย่างไรก็ดี การเติมรายละเอียดแบบนี้ไม่ได้ถูกต้องเสมอไป และถ้าต้องการความน่าเชื่อถือก็จำเป็นต้องกำหนดข้อจำกัดในส่วนสำคัญอย่างชัดเจน
ตอนนี้เรามีวัฒนธรรมการเขียนโค้ด แต่แทบไม่มีวัฒนธรรมการเขียนสเปกที่ละเอียดระดับสูงมาก ยกเว้นในที่อย่าง NASA
ยิ่งโค้ดสั้นและพบได้บ่อยก็ยิ่งทำงานได้ดี แต่พอเป็นคำอธิบายที่ซับซ้อนก็พังได้ง่าย
สุดท้ายแล้วการยอมรับว่า “การเติมรายละเอียดอาจผิดได้” ก็หมายถึงการยอมรับว่าการสร้างอย่างน่าเชื่อถือเป็นเรื่องยาก
ตัวอย่างเช่นมีภาษาสำหรับ program synthesis อย่าง Synquid
มันแสดงให้เห็นว่าการสร้างโปรแกรมจากสเปกที่ถูกต้องทางคณิตศาสตร์มีข้อจำกัดอะไรบ้าง
ปัญหาหลักคือสิ่งที่เรียกว่า specification gap หรือการพิสูจน์ว่าโปรแกรมได้ทำตามสเปกอย่างครบถ้วนหรือไม่
ภาษาธรรมชาติกำกวมเกินไปจึงไม่เหมาะสำหรับนิยามโปรแกรม
ต่อให้ LLM เติมรายละเอียดที่ดู plausible ได้ ก็ไม่ได้แปลว่าช่องว่างนี้จะถูกแก้
ภาษาสเปกเชิงคณิตศาสตร์มีความแม่นยำ แต่เส้นโค้งการเรียนรู้สูง และยากรวมถึงใช้แรงงานมากกว่าการเขียนพรอมป์ต์เป็น Markdown มาก
โมเดลอาจจำความสนใจของฉันได้ หรือเติมช่องว่างด้วยความรู้ของมันเอง แล้วสร้างแอป เกม หรือ whitepaper ที่สมบูรณ์ขึ้นมา
บางครั้งมันคือ “สิ่งที่ฉันต้องการเป๊ะ” และบางครั้งก็เป็น “อารมณ์แบบที่ฉันกำลังจะสื่อ”
ความสามารถในการจัดการความหมาย บริบท และนัยยะบางส่วนอาจเหนือกว่ามนุษย์ด้วยซ้ำ
AI กำลัง ฉลาดและมีความสามารถ มากขึ้นเรื่อย ๆ
กล่าวคือมันไม่ได้สร้างรายละเอียดใหม่ทั้งหมด แต่ใกล้เคียงกับการดึงมาจากข้อมูลฝึกมากกว่า
เห็นด้วยกับคำพูดที่ว่า “สเปกที่ละเอียดเพียงพอก็คือโค้ด”
นี่สอดคล้องกับข้อถกเถียงใน Brooks's No Silver Bullet
แต่คนส่วนใหญ่ไม่ได้ต้องการรายละเอียดระดับนั้น
ถ้าพูดว่า “ช่วยสร้างแอป to-do ให้ AI หน่อย” ความหมายจริง ๆ คือ “ช่วยสร้างแอปที่ดีกว่าที่ฉันจินตนาการไว้”
แต่แนวทางแบบนี้ขยายไปยังซอฟต์แวร์ประเภทอื่นได้ไม่ดีนัก
สุดท้ายก็ต้องแสดงความแตกต่างนั้นออกมาเป็นสเปก
แต่ในพื้นที่อย่าง ฐานข้อมูล, ระบบไฟล์, การประมวลผลแบบขนาน ที่ความถูกต้องและประสิทธิภาพสำคัญ การอิมพลีเมนต์จริงยากกว่าสเปกมาก
การให้ AI สร้างโค้ดที่ผ่าน formal verification ในจุดแบบนี้เป็นความท้าทายใหญ่
ถ้าต้องการทำเงินหรือแข่งขัน ก็ต้องมีข้อกำหนดที่เป็นรูปธรรม
หากมอง vibe coding ผ่านมุมมองของทฤษฎีสารสนเทศ มันคือสมมติฐานว่ามี decoder ที่สามารถกู้คืนพื้นที่ของโปรแกรมที่มีประโยชน์จากพื้นที่พรอมป์ต์เล็ก ๆ ได้
อัตราการบีบอัดตรงนี้เองคือประโยชน์ของ vibe coding
พรอมป์ต์อย่าง “แอปสื่อสารในทีมที่อิง IRC channel” จะถอดความไม่ได้เลยถ้าไม่รู้จัก Slack
ดังนั้นการรับรู้ว่า มีอะไรที่หายไป จึงสำคัญ
ถ้าจะทำ AI coding ให้ได้ผล ควรแบ่งพรอมป์ต์เป็นหน่วยสั้น ๆ และส่งเอกสารเดิมหรือโค้ดที่เคยลองไปด้วย
ตาม Algorithmic Information Theory ปริมาณข้อมูลของสตริงเท่ากับความยาวของตัวแทนแบบกระชับที่สุดที่อธิบายตัวเองได้ครบ
แต่เงื่อนไขเรื่อง “อธิบายตัวเองได้ครบ” จะเป็นจริงก็ต่อเมื่อ weights ของโมเดลทำหน้าที่เป็น codebook
มนุษย์มักสมมติว่ามี บริบทที่แชร์ร่วมกัน มากกว่า LLM มาก จึงประเมินขีดจำกัดของ decoder สูงเกินไป
แต่ถ้าเป็นระบบที่มีข้อจำกัดชัดและมีจุดเน้นที่ชัดเจน ก็น่าจะเพิ่มอัตราการบีบอัดของ vibe coding ได้อย่างมหาศาล
ภาษาธรรมชาติยังเปิด อินเทอร์เฟซแบบใหม่ ให้กับคนที่เข้าถึงภาษาการเขียนโปรแกรมได้ยากกว่า
LLM ไม่ได้คิดแทนทั้งหมด แต่กำลังเปิด ช่องทางใหม่ ในการเปลี่ยนไอเดียให้กลายเป็นระบบที่ทำงานได้
อีกไม่นานผู้คนอาจสร้างภาษาถิ่นอังกฤษเชิงเทคนิคแบบ LLMSpeak ขึ้นมาเพื่อประสิทธิภาพของโมเดลและการใช้โทเค็น
แนวคิดคือทำให้กำกวมน้อยลง ประหยัดโทเค็น และบีบแนวคิดซับซ้อนให้เหลือคำเดียว
ในทางไวยากรณ์ก็อาจมีหลักแบบ Oxford comma เพื่อเพิ่มความชัดเจน
ถ้าจะสเปกละเอียดขนาดนั้น ก็ไม่มีเหตุผลมากนักที่จะต้องใช้พรอมป์ต์
สุดท้ายก็ต้องนิยามกลับเป็นภาษามนุษย์อีกอยู่ดี ผลประหยัดโทเค็นจึงมีจำกัด
ดู วิกิ Lojban, วิดีโอผู้พูด Lojban
ความพยายามสร้างภาษาถิ่นประดิษฐ์อาจล้มเหลวเหมือน Esperanto
ภาษาพวกนี้อาจมีประโยชน์มากกว่าตอนที่ LLM คุยกันเอง
และภาษาการเขียนโปรแกรมก็ทำหน้าที่นั้นอยู่แล้ว
สเปก(spec) เป็นเหมือน ซอง(envelope) ที่ครอบโปรแกรมทั้งหมดซึ่งตรงตามเงื่อนไขนั้น
การสร้างซองนี้ยากกว่าการเขียนโปรแกรมเดียวเสียอีก
เช่นเดียวกับที่ LLM สร้างโค้ดต่างกันได้ทุกครั้ง สเปกก็อนุญาตทั้งอิมพลีเมนต์ที่ดีและที่แย่
ในทางปฏิบัติพอเลือกอิมพลีเมนต์หนึ่งมาใช้ มันก็มักกลายเป็นสเปกโดยพฤตินัยของเวอร์ชันถัดไป
ในสภาพแวดล้อมที่มี โค้ดเดิมอยู่แล้ว(brownfield) สเปกมักไม่สะอาด ทำให้ LLM รับมือได้ยาก
มี combinatorial explosion ที่ต้องคิดว่าสเปกหนึ่งบรรทัดจะปฏิสัมพันธ์กับบรรทัดอื่นอย่างไร
แต่สำหรับคอมไพเลอร์แล้ว โค้ดเองก็เป็นสเปกเหมือนกัน
สุดท้ายคำว่า “โค้ดง่ายกว่าสเปก” ก็เป็นเรื่องสัมพัทธ์
สเปกอย่าง “เก็บข้อมูลรับรองผู้ใช้” ครอบตั้งแต่ bcrypt ไปจนถึง cookie แบบ plaintext
มนุษย์จะมีสัญชาตญาณว่า “แบบนั้นทำไม่ได้” แต่เอเจนต์จะไม่รู้ถ้าไม่ได้ระบุไว้
ดังนั้นถ้าจะให้ปลอดภัย ก็ต้องสเปกแม้กระทั่ง สิ่งที่ห้ามทำ
ถ้าประสิทธิภาพหรือความปลอดภัยสำคัญ ก็ต้องระบุคุณสมบัติเหล่านั้นเข้าไป
ตัวอย่างเช่นประโยคว่า “โปรแกรมนี้ต้องเป็น O(n)” ง่ายกว่าอิมพลีเมนต์จริงมาก
ดูเหมือนแต่ละคนจะใช้คำว่า spec ไม่เหมือนกัน
สำหรับฉัน spec คือการนิยาม “what” ส่วน plan คือ “how” และ build packet คือ “ขั้นตอนละเอียด”
ในกรณีส่วนใหญ่ สิ่งสำคัญคือ “what”
การเขียนเป็นสเปกว่า ข้อมูลจะไหลจาก A ไป B ผ่าน C ถูกเก็บรักษาไว้ที่ D และแสดงผลในรูปแบบ F ที่ E นั้นง่ายกว่าการอิมพลีเมนต์เป็นโค้ด Rust มาก
ถ้าลองทำ “agentic engineering” จะพบว่าหลายครั้ง เอกสารสเปกยาวกว่าโค้ด
ภาษาธรรมชาติไม่สมบูรณ์ แต่โค้ดแม่นยำ
จุดประสงค์ของสเปกคือการรักษาฟังก์ชันไว้แม้จะมีการพัฒนาแบบวนซ้ำหลายรอบ
เอกสารออกแบบแบบ waterfall มีประสิทธิภาพกว่าการพึ่งเทสต์หรือคอมเมนต์
ด้วยวิธีนี้ยังรีแฟกเตอร์โปรเจกต์ vibe coding แบบเต็มรูปแบบหรือเปลี่ยนภาษาได้อย่างลื่นไหล
ตอนนี้ให้ความรู้สึกเหมือนกำลังย้อนกลับไปสู่รูปแบบการพัฒนาในยุค 70–80
ประโยคอย่าง “อิมพลีเมนต์อินเทอร์เฟซ TCP” สั้นกว่าโค้ดจริงมาก
สุดท้ายถ้าแมปไปยัง สคีมาที่ชัดเจน ได้ ภาษาธรรมชาติก็กระชับพอได้เหมือนกัน
ทิศทาง Spec → LLM ไม่มีประสิทธิภาพและสิ้นเปลือง
ตรงกันข้าม LLM → Spec ดูสมจริงกว่า
ถ้าสเปกอยู่ในรูปที่คอมไพล์ได้ LLM ก็สามารถรับ feedback นั้นแล้วสร้างโค้ดที่ดีขึ้นได้
ความพยายามจะสร้าง “อังกฤษที่ตรวจสอบได้(validated English)” กลับยิ่งเพิ่มความซับซ้อน
สุดท้ายสิ่งสำคัญก็คือโค้ดที่ทำงานได้จริง
โค้ดมีสิ่งที่บรรจุอยู่มากกว่าสเปกมาก
โปรเจกต์ส่วนใหญ่มี 90% เป็น โค้ดเฟรมเวิร์กหรือโครงสร้างพื้นฐาน และมีเพียง 10% เท่านั้นที่เป็น business logic
สเปกไม่ต้องแตะรายละเอียดของภาษาและเฟรมเวิร์ก จึงกระชับกว่ามาก
ถ้าทำได้แบบนี้ โค้ดก็จะใกล้เคียงกับสเปกมาก
ผู้เชี่ยวชาญโดเมนก็อ่านได้และเขียนเทสต์ได้ง่ายด้วย
แต่โค้ดจริงจะเปลี่ยนไปมากพอสมควร
ความขัดแย้งระหว่างการมองสเปกเป็น เครื่องมือจัดการ กับการมองเป็น เครื่องมือวิศวกรรม ทำให้เกิดความไม่ลงรอยทางความคิด
ผู้จัดการมองสเปกเป็นตั๋วมอบหมายงาน แต่ฝั่งนักพัฒนาใช้มันเป็น เครื่องมือในการขัดเกลาความคิด
นักพัฒนาบางคนเริ่มจากวิธีคิดแบบผู้จัดการเพราะความสะดวก แต่ไม่นานก็จะตระหนักได้
จะประคองไปได้ชั่วคราวด้วยกระแสหรือการประชุมนักลงทุนก็จริง แต่สุดท้ายผู้ใช้ต้องการ ผลิตภัณฑ์จริง
ต่อไปก็คงจะไปประดิษฐ์ทั้ง Waterfall กับ Agile ขึ้นมาใหม่อีกสินะ
ในฐานะนักพัฒนา C แบบ embedded ผมจะทำสเปกให้สามารถตรวจสอบแทบทุก flow ของ Feature/Subfeature ได้ด้วย chart ก่อน
จากนั้นก็ทบทวนสเปกอย่างยาวนานและยืนยันขั้นสุดท้าย
แล้วสร้างโค้ดที่สอดคล้องกับสเปกแบบ 1:1 อย่างสมบูรณ์เพื่อนำมาใช้งาน
เพราะถ้าตรวจทานด้วยสเปก ความอ่านง่ายจะเหนือกว่าการตรวจโค้ดอย่างมากครับ