🍉 รู้ไหม ทำไมโลกการเขียนโค้ดจะเข้าสู่ Contract-Driven Architecture
ก่อนจะไปถึงจุดนั้น มันไม่ได้เกิดขึ้นเพราะมีใครคิด framework นี้ขึ้นมาก่อน แต่มันค่อย ๆ ไหลมา จากวิธีที่เราพยายามใช้ AI เขียนโค้ดนี่แหละ
🍉 ช่วงแรก เราใช้ AI แบบง่าย ๆ
เหมือนถาม StackOverflow เวอร์ชันเร็วขึ้น ถามมันทีละฟังก์ชันให้ช่วยคิด logic หรือแก้ bug จุดเล็ก ๆ
🍉 ตอนนั้นมันยังไม่มีปัญหาอะไรใหญ่
เพราะคนยังเป็นคน “ถือภาพรวมของระบบ” อยู่ AI แค่ช่วยเร่ง
ถึงมันจะเขียนไม่ตรง naming บ้างหรือ style ไม่เหมือนในโปรเจ็ค เราก็แค่ copy มาแก้ๆ แล้วก็จบ มันยังเป็นโลกที่
คนคิด แล้วให้ AI ช่วย จากนั้น คนประกอบเข้าด้วยกันอีกทีหนึ่ง แล้วทดสอบว่ามันใช้งานได้
🍉 พอเข้าสู่ยุค agent
พวก Claude Code, Codex อะไรพวกนี้เริ่มมา มันไม่ใช่แค่ช่วยเขียนแล้ว
มันเริ่ม อ่าน repo เริ่ม พยายามเข้าใจระบบ แล้วก็เขียนโค้ดให้เราเลยทั้งก้อน
ตอนแรกมันรู้สึกโคตรเจ๋ง เหมือนมี junior ที่อ่านโค้ดเป็นแล้ว
แต่พอใช้จริงไปสักพัก จะรู้ว่ามันมีความไม่สมบูรณ์ โปรเจ็คมันใหญ่เกิน
การให้มันไล่อ่านทั้งระบบ มันทำได้ “แต่แค่ทำได้เฉยๆนะ” ไม่ได้การันตีว่ามันจะเข้าใจระบบเราจริง
มันอ่านได้บางส่วนจำได้บางช่วง แล้วก็ “สรุปเอาเอง”
ในหัวมัน มันไม่ได้มี mental model ของระบบ แบบที่พวกเรามี
🍉 ปัญหาหลักว่าทำไม
เราไม่สามารถพึ่งให้ AI เข้าใจระบบจากการ “สแกนโค้ดทั้งโปรเจ็ค” ด้วยตัวของมันเอง
เพราะ:
- context จำกัด
- scan ไม่ครบ
- ปรัชญาการออกแบบของระบบ มักไม่อยู่ในโค้ดตรง ๆ ต้องเล่าจากผู้เข้าใจ
ผลคือ AI จะ “😡จะเดาความเข้าใจเอง😡 ในส่วนที่มันอ่านไม่พบ หรือส่วนที่ เกินขอบเขต context ที่มันเก็บไว้ได้”
🍉 กลับมาที่ปัญหาที่เราจะเจอ ในตอนเราใช้ AI แรกๆ จะเป็นแบบนี้
-
มันเขียนโค้ดที่ “เหมือนจะถูกต้อง” แต่ดันไปขัดกับอีก service หนึ่ง
-
มันใช้ abstraction ผิด layer แต่ดูผิวเผินไม่มี error ทำงานได้จริง แต่ภาพรวมแล้ว ทำให้โค้ดใน Project ยุ่งเหยิงเกินไป โค้ดเริ่มบวม
-
มัน bypass logic บางอย่าง ที่ไม่มีใครเขียนไว้ชัดๆ เราต้องมาคอยจับผิด ว่าจุดไหนที่มันลืม
หรือบางที มันแก้โค้ดให้เรา แล้วดันไป refactor ส่วนอื่นเพิ่มเอง บางครั้งดี บางครั้ง เห้..
เหมือนมันพยายาม “จัดระบบให้ดีขึ้น” แต่จริง ๆ แล้วมันกำลังทำให้ system drift ตัดทางด่วนแบบไม่รู้ผังเมืองระยะยาว
🍉 จุดนี้แหละที่คนเริ่มรู้สึกว่า
ปัญหาไม่ใช่ AI เขียนไม่เก่ง ปัญหาคือ ❌มันไม่รู้ว่าอะไรห้ามทำ
🍉 แล้วสิ่งที่คนทำโดยไม่ได้นัดกันคือ 😢 เริ่มเขียนเอกสาร
ตอนแรกก็แค่
- อธิบายว่า service นี้ทำอะไร
- input / output เป็นยังไง
- flow เป็นยังไง
แล้วพอเอาไปให้ AI อ่าน จะรู้เลยว่า มันเขียนได้ดีขึ้นแบบชัดเจน
ตรงนี้หลายคนจะคิดว่า “โอเค งั้นก็แค่ต้องมี doc ดี ๆ” แต่ถ้าใช้ไปอีกหน่อย จะเริ่มรู้ว่า
doc ธรรมดามันยังไม่พอเว้ยยยย
เหมือนพยายามอุดรูรั่วในเรือ อุดรูนั้น ก็พบรูถัดไป ใช้เวลาทั้งวันเพื่อหารูให้ครบ
🍉 เพราะสิ่งที่พังจริง ๆ ไม่ใช่ logic ธรรมดา
มันคือพวกนี้
- auth ไม่ถูก enforce
- data บาง field หลุดออกไป
- flow ที่ควร async กลายเป็น sync
- service ไปเรียกของที่ไม่ควรเรียก
พวกนี้มันไม่ใช่ bug โดยการเขียนผิด แต่มันคือ AI มันไม่รู้ว่ากฏไหนไม่ควรละเมิด อันที่จริง มันไม่รู้ด้วยซ้ำ ว่าเรามีกฏพวกนั้น (ที่ส่วนมาก เราจะสอนกันในทีม กันอยู่แล้วตามปรกติ)
🍉 แล้วคุณจะเริ่มเขียน doc แบบใหม่โดยไม่รู้ตัว
ไม่ใช่แค่เขียนว่า “อะไรคืออะไร” แต่เริ่มเขียนว่า
- อันนี้ห้ามทำ
- อันนี้ต้องผ่านตรงนี้ก่อน
- อันนี้ต้องมี field นี้เสมอ
- อันนี้ห้ามออกไป public
ตอนนี้มันไม่ใช่คำอธิบายแล้วใช่มะ
มันเริ่มเป็น กฎ อย่างชัดเจน
แถมยังเป็น กฏที่โคตรจะ ระแวดระวัง อันนั้นห้าม อันนี้ห้าม ต้องเขียนให้ครบ อย่าให้มันเดาไปเอง
แล้วพอมีสิ่งนี้เกิดขึ้น flow มันจะเปลี่ยนเองเลย จากเดิมเขียนโค้ดก่อน แล้วค่อย review กลายเป็น
⭐️ เขียนกฎก่อน แล้วค่อยให้ AI เขียนโค้ดตาม ⭐️
🍉 ลองนึกภาพเคสง่าย ๆ
คุณอยากเพิ่ม feature export report
ถ้าไม่มีอะไรเลย AI ก็จะ:
- ดึง data
- format
- expose endpoint
จบ
🍉 แต่ในโลกจริง คุณรู้อยู่แล้วว่า:
- ต้องไม่ expose field บางตัว
- ต้อง log ทุกครั้ง
- ต้องไม่ block system
- ต้อง limit request
- งานบางตัวจะต้องใช้ฟังชั่นก์ที่กำหนดเท่านั้นไม่ใช่เขียนฟังก์ชั่นขึ้นใหม่
🍉 ถ้าคุณไม่เขียนสิ่งพวกนี้ไว้ AI จะไม่รู้
และมันจะเขียนโค้ดที่ “ถูก” กับ Promt ปัจจุบัน ไม่ใช่ “ถูก” กับโครงสร้างโดยรวมของระบบเรา
แล้วตรงนี้แหละ ที่มันเริ่มชัด สิ่งที่เรากำลังเขียนอยู่ มันไม่ใช่ documentation มันคือ “⭐️contract⭐️”
🍉 contract หมายถึง คำสัญญา หรือข้อตกลงกลาง
ว่า
- อะไรคือ input อะไรคือ output
- อะไรคือ boundary
- อะไรคือ invariant
- อะไรคือสิ่งต้องห้าม
- อะไรคือสิ่งที่ต้องเกิดเสมอ
พอมี contract ดีพอ AI จะเขียนโค้ด ตรงมากขึ้น ( แต่ดีหรือเปล่าก็ไปรีวิวกันเองต่อ )
บางทีนะ แทบไม่ต้องแก้ ไม่หลุด layer ไม่ละเมิดของสำคัญ
แต่ถ้า contract ไม่ชัด
AI จะเดา แล้วเดาผิดในจุดที่คุณไม่ได้เขียนไว้
🦄 เมื่อก่อน code คือของจริง architecture คือคำอธิบาย
🦄 ตอนนี้ contract กลายเป็นของจริง code เป็นแค่สิ่งที่เติมเข้าไป
🍉 และพอทำแบบนี้ไปสักพัก เราจะเริ่มเห็นอีกเรื่องหนึ่งชัดขึ้น
เรากำลังสร้าง “ทักษะใหม่” ขึ้นมา
นั่นคือทักษะแบบ Contract-Driven
⭐️ Contract-Driven Skill เป็นทักษะใหม่ที่กำลังเกิดขึ้น ⭐️
เมื่อก่อน คนเก่งอาจวัดกันที่การออกแบบระบบเก่ง เขียนโค้ดเก่ง หรือ review เก่ง
แต่พอ AI เข้ามารับงานเขียนมากขึ้น สิ่งที่มีค่าขึ้นมาทันที คือความสามารถในการ
♥️ “นิยามกรอบของระบบ” ให้ชัดพอ จนไม่ต้องอาศัยการเดา ♥️
🍉 ทักษะนี้จึงไม่ใช่แค่การเขียนเอกสารให้ละเอียด
-
แต่มันคือการแปลงความเข้าใจเชิงสถาปัตยกรรม ให้ออกมาเป็นข้อตกลงที่ใช้ได้จริง
-
บอกได้ว่าอะไรคือขอบเขต อะไรคือสิ่งที่ต้องเกิดเสมอ อะไรคือสิ่งต้องห้าม และการเปลี่ยนแปลงครั้งนี้ควรหยุดอยู่ตรงไหน
พูดอีกแบบ มันคือทักษะของการทำให้ architecture ไม่ได้อยู่แค่ในหัวคน แต่กลายเป็นกฎที่ทั้งมนุษย์และ AI ใช้ร่วมกันได้
⭐️⭐️⭐️ ดังนั้น คนที่มีค่ามากขึ้นเรื่อย ๆ จะไม่ใช่แค่คนที่ implement ได้เร็ว แต่คือคนที่กำหนด contract ของระบบได้ชัด ⭐️⭐️⭐️
» ทำไมโลกการเขียนโค้ดจะเข้าสู่ Contract-Driven Architecture «
🍉 คำตอบไม่ได้ซับซ้อนนัก
มันเป็นเพราะเมื่อความเร็วในการสร้างสูงขึ้น การควบคุมด้วยความเข้าใจแบบกระจายอยู่ในคนอย่างเดียวมันไม่พออีกแล้ว
- สิ่งที่เคยอาศัยการรู้กันเอง ต้องถูกเขียนออกมา
- สิ่งที่เคยเป็นสามัญสำนึกของทีม ต้องถูกแปลงเป็นข้อตกลงของระบบ