𝗧𝗵𝗲 𝗖𝗼𝗱𝗲 𝗜𝘀 𝗖𝗵𝗲𝗮𝗽. 𝗧𝗵𝗲 𝗦𝗽𝗲𝗰 𝗜𝘀 𝗧𝗵𝗲 𝗔𝘀𝘀𝗲𝘁.
โค้ดกำลังกลายเป็นสิ่งที่หาได้ง่ายและมีราคาถูก แต่คุณค่าที่แท้จริงในตอนนี้อยู่ที่การกำหนดรายละเอียด (specification)
ผมใช้เวลาเขียนแผนการดำเนินงาน (implementation plans) ด้วยมือลดลง แต่ใช้เวลาไปกับการออกแบบมากขึ้น AI ทำให้สิ่งนี้เป็นไปได้ มันไม่ได้มาแทนที่การตัดสินใจทางวิศวกรรม (engineering judgment) แต่มันเปลี่ยนจุดที่คุณต้องใช้มัน
ผมให้ AI ช่วยร่างสเปกและโค้ด งานของผมในตอนนี้คือการกำหนดเจตจำนง (intent) และการระบุข้อจำกัด (constraints) การเขียนเป็นส่วนที่มีคุณค่าน้อยที่สุดในกระบวนการนี้
สเปกของผมไม่ได้มีไว้เพื่อให้มนุษย์อ่านใน wiki แต่มีไว้สำหรับเซสชัน AI ครั้งถัดไป มันต้องช่วยให้ AI สามารถทำงานต่อได้โดยไม่ต้องมีการอธิบายใหม่
สเปกที่มีประสิทธิภาพจะมุ่งเน้นไปที่:
- ข้อกำหนด (Requirements)
- ข้อจำกัด (Constraints)
- เกณฑ์การยอมรับ (Acceptance criteria)
- ขั้นตอนการตรวจสอบ (Verification steps)
สเปกเหล่านี้ถูกสร้างขึ้นเพื่อให้นำไปปฏิบัติได้จริง ไม่ใช่แค่เพื่อการอ่าน ผู้รับสารคือผู้ร่วมพัฒนาคนถัดไป ไม่ว่าจะเป็นมนุษย์หรือ AI agent ก็ตาม
วิศวกรรมสมัยใหม่คือปัญหาเรื่องการจัดการข้อจำกัด (constraint management) AI ทำงานได้ดีกับข้อจำกัดหากคุณระบุพวกมันได้อย่างชัดเจน เวิร์กโฟลว์ของผมดำเนินตามขั้นตอนเหล่านี้: Intent → AI Specification → Human Review → AI Implementation Plan → Human Review → AI Code Generation → Testing
ผมกำหนดเป้าหมาย ข้อกำหนด และขอบเขต AI จะร่างสเปก ผมตรวจสอบ AI จะร่างแผน ผมตรวจสอบ และหลังจากนั้นเท่านั้นเราจึงจะสร้างโค้ด
ผมเขียนน้อยลง แต่ตรวจสอบอย่างละเอียดมากขึ้น นี่คือจุดที่มูลค่าทางวิศวกรรมยังคงอยู่
สเปกที่ดีจะกำหนดว่า "อะไรต้องเป็นจริง" ไม่ใช่ "ทำอย่างไรให้เป็นจริง" ตัวอย่างเช่น สเปกสำหรับการทำ refactoring ควรระบุว่า:
- ห้ามคลาสใดๆ ใน application layer อ้างอิงถึง DAO implementations
- เกณฑ์การยอมรับ: การละเมิดลำดับชั้น (layering violations) ต้องไม่พบข้อมูลใดๆ (zero matches) ระหว่างการค้นหา
งานที่สำคัญที่สุดคือการระบุข้อจำกัดที่เป็นโครงสร้างหลัก (load-bearing constraints) ซึ่งเป็นกฎที่สำคัญ เช่น:
- กลยุทธ์การเริ่มต้นระบบฐานข้อมูล (Database initialization strategies)
- รูปแบบการติดตั้งใช้งาน (Deployment models)
- ขอบเขตการเชื่อมต่อระบบ (Integration boundaries)
หากคุณพลาดสิ่งเหล่านี้ ระบบจะพัง
เซสชันของ AI นั้นเป็นเรื่องชั่วคราว มันผ่านมาแล้วก็ผ่านไป คุณค่าที่แท้จริงมาจากความจำร่วมกัน (shared memory):
- สเปก (Specifications)
- แผนการดำเนินงาน (Implementation plans)
- บันทึกการตัดสินใจด้านสถาปัตยกรรม (Architecture Decision Records หรือ ADRs)
- ข้อตกลงร่วมกัน (Conventions)
ความจำเหล่านี้ช่วยป้องกันการคลาดเคลื่อนของเอกสาร (documentation drift) เมื่อ README, โค้ด และ ADR ของคุณให้ข้อมูลที่ไม่ตรงกัน ความเชื่อมั่นจะหมดไป คุณต้องทำให้สิ่งเหล่านี้สอดคล้องกับความเป็นจริง
Repository ควรมีโครงสร้างดังนี้:
- CLAUDE.md: เวิร์กโฟลว์และขั้นตอนการตรวจสอบ (review gates)
- status.md: ดัชนีที่มีการอัปเดตอยู่เสมอสำหรับสเปกและแผนงานทั้งหมด
- specs/: ส่วนที่ระบุว่า "ทำอะไร" และ "ทำไม"
- plan/: ส่วนที่ระบุว่า "ทำอย่างไร"
- rules/: ข้อกำหนดในการเขียนโค้ดระดับคลาส (Class-level coding conventions)
- docs/adr/: บันทึกการตัดสินใจที่สำคัญซึ่งไม่สามารถเปลี่ยนแปลงได้
AI สามารถสร้างโค้ดได้ แต่มันไม่สามารถระบุได้อย่างแม่นยำว่าข้อจำกัดใดที่มีความสำคัญต่อธุรกิจของคุณ นั่นคือความรับผิดชอบของคุณ
สร้างความรู้ที่นำไปใช้งานได้จริง เริ่มต้นทุกโปรเจกต์ด้วยหน่วยความจำร่วมกัน (shared memory) ไม่ใช่หน้ากระดาษที่ว่างเปล่า
ที่มา: https://dev.to/daniel_wu_cac679a2760ba0a/the-code-is-cheap-artifact-now-the-spec-is-the-asset-3b02
ชุมชนแห่งการเรียนรู้ (ไม่บังคับ): https://t.me/GyaanSetuAi