ทำไมข้อเท็จจริงเหล่านี้ยังสำคัญเมื่อ AI เขียนโค้ดได้เร็ว\n\nAI สามารถสร้างโค้ดที่ดูใช้งานได้ภายในไม่กี่นาที นั่นเปลี่ยนความเร็วของโปรเจกต์ แต่ไม่เปลี่ยนสิ่งที่ทำให้ซอฟต์แวร์ประสบความสำเร็จ บทเรียนใน “ข้อเท็จจริงซอฟต์แวร์” ของ Joel Spolsky ไม่ได้เกี่ยวกับความเร็วในการพิมพ์จริงๆ แต่มันเกี่ยวกับการตัดสินใจ วงจรป้อนกลับ และการหลีกเลี่ยงความซับซ้อนที่เราสร้างขึ้นเอง\n\nสิ่งที่เปลี่ยนคือต้นทุนการสร้างโค้ด คุณขอสามแนวทาง ห้าตัวแปร หรือรีไรท์ทั้งระบบและได้ผลลัพธ์กลับมาในทันที แต่สิ่งที่ไม่เปลี่ยนคือต้นทุนของการเลือกแนวทางที่ถูกต้อง การตรวจสอบมัน และการอยู่กับมันเป็นเดือนๆ เวลาที่ประหยัดจากการเขียนมักย้ายไปที่การตัดสินใจความหมายของสิ่งที่คุณต้องการ ยืนยันกรณีขอบ และมั่นใจว่า “ชัยชนะรวดเร็ว” ของวันนี้จะไม่กลายเป็นภาษีบำรุงรักษาของวันพรุ่งนี้\n\nความถูกต้อง ความปลอดภัย และความสามารถในการบำรุงรักษายังคงต้องใช้เวลาเพราะพวกมันต้องการหลักฐาน ไม่ใช่แค่ความมั่นใจ. ฟลูว์การล็อกอินไม่เสร็จเมื่อมันคอมไพล์ มันเสร็จเมื่อมันปฏิเสธอินพุตที่ไม่ดีอย่างเชื่อถือได้ จัดการสถานะแปลกๆ ได้ และไม่รั่วไหลข้อมูล AI อาจฟังดูแน่นอนแต่พลาดรายละเอียดสำคัญ เช่น การเช็กสิทธิ์บน endpoint หรือเงื่อนไขการแข่งขันในการอัปเดตการชำระเงิน\n\nAI แข็งแกร่งที่สุดเมื่อคุณปฏิบัติต่อมันเหมือนเครื่องร่างเร็ว มันยอดเยี่ยมในการสร้างบอยเลอร์เพลท รูปแบบทำซ้ำ การรีแฟคเตอร์ด่วน และการสำรวจตัวเลือกให้คุณเปรียบเทียบกัน ใช้ดีมันจะย่นระยะเวลาของเฟส 'หน้าเปล่า'\n\nAI ทำร้ายมากที่สุดเมื่อคุณส่งเป้าหมายคลุมเครือให้มันและยอมรับผลลัพธ์ตามหน้าเดียวกัน รูปแบบความล้มเหลวเดิมๆ จะเกิดซ้ำ: สมมติฐานที่ซ่อนอยู่ (กฎธุรกิจที่ไม่ได้ระบุ), เส้นทางที่ไม่ได้ทดสอบ (การจัดการข้อผิดพลาด การลองใหม่ สถานะว่าง), ความผิดพลาดที่ดูมั่นใจ (โค้ดที่เป็นไปได้แต่ผิดอย่างละเอียดอ่อน), และโซลูชัน "ฉลาด" ที่อธิบายยากภายหลัง\n\nเมื่อโค้ดถูกทำให้มีราคาถูกลง ทรัพยากรที่ขาดแคลนใหม่คือความไว้วางใจ ความจริงเหล่านี้มีความสำคัญเพราะช่วยปกป้องความไว้วางใจนั้น: กับผู้ใช้ เพื่อนร่วมทีม และตัวคุณในอนาคต\n\n## การทดสอบยังคงเป็นคอขวด และนั่นเป็นเรื่องดี\n\nเมื่อ AI สามารถสร้างฟีเจอร์ได้ในไม่กี่นาที มันยั่วยวนให้มองว่าการทดสอบเป็นส่วนช้าที่ต้องตัดออก ข้อสังเกตของ Spolsky ยังคงเป็นจริง: ส่วนที่ช้าคือที่ที่ความจริงอยู่ โค้ดผลิตง่าย พฤติกรรมที่ถูกต้องไม่ได้เป็นเช่นนั้น\n\nการเปลี่ยนมุมมองที่มีประโยชน์คือมองการทดสอบเป็นข้อกำหนดที่คุณรันได้ ถ้าคุณอธิบายพฤติกรรมที่คาดหวังไม่ได้ในแบบที่ตรวจสอบได้ แปลว่าคุณยังคิดไม่เสร็จ ในงานที่มี AI ช่วย เรื่องนี้สำคัญขึ้น ไม่ใช่ลดลง เพราะโมเดลสามารถสร้างสิ่งที่มั่นใจแต่ผิดเล็กๆ น้อยๆ\n\nเริ่มทดสอบจากสิ่งที่จะทำให้เกิดความเสียหายมากที่สุดถ้ามันพัง สำหรับสินค้าส่วนใหญ่ นั่นคือฟลูว์หลัก (สมัคร, เช็คเอาต์, บันทึก, ส่งออก), สิทธิ์ (ใครดู แก้ไข ลบได้) และความสมบูรณ์ของข้อมูล (ไม่มีซ้ำ ยอดถูกต้อง การย้ายข้อมูลปลอดภัย) แล้วจงครอบคลุมขอบที่มักทำให้เกิดเหตุการณ์ดึกๆ เช่น อินพุตว่าง ข้อความยาว เขตเวลา การลองใหม่ และพรมแดนภายนอกที่ไม่น่าเชื่อถือ เช่น การชำระเงิน อีเมล และการอัปโหลดไฟล์\n\nAI ดีในการเสนอเคสการทดสอบ แต่ไม่รู้ว่าคุณสัญญากับผู้ใช้ไว้จริงๆ ใช้มันเป็นพาร์ทเนอร์ระดมสมอง: ขอกรณีขอบที่ขาด สถานการณ์การใช้งานผิดปกติ และการรวมสิทธิ์ จากนั้นทำงานของมนุษย์: จับความครอบคลุมให้ตรงกับกฎจริงของคุณและลบการทดสอบที่ "ทดสอบการดำเนินงาน" แทนที่จะเป็นพฤติกรรม\n\nทำให้ความล้มเหลวเป็นสิ่งที่แก้ไขได้โดยปฏิบัติ การทดสอบที่ล้มเหลวควรบอกคุณว่าพังอะไร ไม่ใช่ส่งคุณไปล่าหาสาเหตุราวกับล่าสมบัติ เก็บการทดสอบให้เล็ก ตั้งชื่อเหมือนประโยค และทำให้ข้อความผิดพลาดเฉพาะเจาะจง\n\n### ตัวอย่างสั้นๆ\n\nสมมติคุณสร้างแอป "โน้ตทีม" ง่ายๆ โดยมี AI ช่วย หน้าจอ CRUD ปรากฏอย่างรวดเร็ว ความเสี่ยงด้านความถูกต้องไม่ใช่ UI แต่เป็นการควบคุมการเข้าถึงและกฎข้อมูล: ผู้ใช้คนหนึ่งต้องไม่เห็นโน้ตของทีมอื่น การแก้ไขต้องไม่เขียนทับการเปลี่ยนแปลงที่ใหม่กว่า และการลบโน้ตไม่ควรทิ้งไฟล์แนบโดดเดี่ยว การทดสอบที่ล็อกกฎเหล่านี้จะรู้สึกเป็นคอขวด แต่ก็เป็นตาข่ายนิรภัยของคุณ\n\nเมื่อการทดสอบเป็นคอขวด มันบังคับให้ชัดเจน ความชัดเจนนั้นคือสิ่งที่ป้องกันไม่ให้โค้ดเร็วกลายเป็นบั๊กเร็ว\n\n## ความเรียบง่ายชนะความฉลาด โดยเฉพาะเมื่อมี AI อยู่ในวงจร\n\nหนึ่งในความจริงที่ทนทานที่สุดคือโค้ดเรียบง่ายชนะโค้ดฉลาด AI ทำให้ยั่วยวนที่จะยอมรับนามธรรมซับซ้อนเพราะมันมาบรรจบและรวดเร็ว แต่ต้นทุนจะปรากฏทีหลัง: เพิ่มจุดซ่อนบั๊ก มากขึ้นที่จะสแกน และช่วงเวลา "นี่มันทำอะไร" มากขึ้น\n\nเมื่อโค้ดถูกทำให้ถูก การจ่ายคือความซับซ้อน การออกแบบเล็กๆ น่าเบื่อ ง่ายต่อการทดสอบ ง่ายต่อการเปลี่ยน และง่ายต่อการอธิบาย นั่นสำคัญยิ่งขึ้นเมื่อร่างแรกมาจากโมเดลที่ฟังดูแน่นอนแต่ผิดเล็กๆ น้อยๆ\n\nกฎปฏิบัติ: ให้ฟังก์ชัน คอมโพเนนต์ และโมดูลเล็กพอที่เพื่อนร่วมทีมอ่านได้ในไม่กี่นาที ไม่ใช่หลายชั่วโมง ถ้าคอมโพเนนต์ React ต้องการหลาย custom hooks เครื่องสถานะท้องถิ่น และเลเยอร์ renderer อัจฉริยะ หยุดแล้วถามว่าคุณกำลังแก้ปัญหาจริงหรือยอมรับสถาปัตยกรรมเพราะ AI เสนอมา\n\nไม่กี่ "การทดสอบความเรียบง่าย" จะช่วยให้คุณต้านได้:\n\n- เพื่อนร่วมงานใหม่เข้าใจฟลูว์หลักได้ภายในครั้งเดียวหรือไม่?\n- คุณลบ abstraction นี้และแทนที่ด้วยโค้ดธรรมดาโดยไม่เสียความชัดเจนได้ไหม?\n- มีที่ชัดๆ ที่จะแก้บั๊กแค่ที่เดียว หรือห้าแห่ง?\n\nพรอมท์สำคัญ ถ้าคุณขอ "สถาปัตยกรรมที่ดีที่สุด" มักได้สิ่งที่โอเวอร์บิลด์ ถามด้วยข้อจำกัดที่จะดันไปสู่ชิ้นส่วนเคลื่อนไหวให้น้อยลง ตัวอย่าง: ใช้วิธีที่เรียบที่สุดกับไฟล์น้อยที่สุด; หลีกเลี่ยงนามธรรมใหม่เว้นแต่จะลดการทำซ้ำใน 3 จุดขึ้นไป; ให้โค้ดชัดเจนมากกว่าฮีลเปอร์ทั่วไป\n\nตัวอย่างเป็นรูปธรรม: คุณขอให้ AI เพิ่มการเข้าถึงตามบทบาทในหน้าผู้ดูแล รุ่นฉลาดอาจแนะนำกรอบสิทธิ์ decorators และ DSL คอนฟิก รุ่นเรียบง่ายเช็กบทบาทผู้ใช้ที่จุดเดียว กั้นเส้นทางที่จุดเดียว และบันทึกการปฏิเสธการเข้าถึง รุ่นเรียบง่ายตรวจทานง่าย ทดสอบง่าย และตีความยากน้อยกว่า\n\nถ้าคุณสร้างในเครื่องมือแชท เช่น Koder.ai ความเรียบง่ายยังทำให้ snapshot และ rollback มีคุณค่า การเปลี่ยนเล็กๆ ชัดเจนง่ายต่อการเปรียบเทียบ เก็บ หรือย้อนกลับ\n\n## การจ้าง: คุณต้องการบรรณาธิการและผู้ตัดสินใจ ไม่ใช่พิมพ์ดีด\n\nเมื่อโค้ดผลิตง่าย ทักษะที่ขาดแคลนคือการเลือกสิ่งที่จะมีอยู่และตรวจสอบว่ามันถูกต้อง คำแนะนำเดิม "จ้างโปรแกรมเมอร์เก่ง" ยังใช้ได้ แต่ตำแหน่งงานเปลี่ยนไป คุณไม่ได้จ้างใครให้พิมพ์เร็วขึ้น คุณจ้างคนให้ตัดสิน ปรับแต่ง และปกป้องผลิตภัณฑ์\n\nคนที่มีค่านิยมสูงในงานที่มี AI ช่วยมักมีสี่ลักษณะร่วมกัน: การตัดสินใจ (อะไรสำคัญ), รสนิยม (อะไรดี), ทักษะแก้บั๊ก (หาสาเหตุจริง), และการสื่อสาร (อธิบายการแลกเปลี่ยนอย่างชัดเจน) พวกเขาสามารถเอาฟีเจอร์ที่ AI เขียนว่า "เกือบใช้งานได้" และเปลี่ยนให้เป็นสิ่งที่คุณเชื่อถือได้\n\n### การสัมภาษณ์ที่ดีกว่า: ปรับปรุงการเปลี่ยนแปลงที่ AI ทำ\n\nแทนที่จะขอวิธีแก้สมบูรณ์ตั้งแต่ต้น ให้ผู้สมัครดู pull request ที่สร้างโดย AI (หรือ diff ที่วางมา) ที่มีปัญหาจริง: ตั้งชื่อไม่ชัด, มีกรณีขอบซ่อนอยู่, ขาดเทสต์, และมีข้อผิดพลาดความปลอดภัยเล็กน้อย\n\nขอให้พวกเขาอธิบายว่าโค้ดพยายามทำอะไรด้วยภาษาธรรมดา หาส่วนที่มีความเสี่ยงสูงสุด เสนอการแก้ไข และเพิ่ม (หรือร่าง) การทดสอบที่จะจับการถอยหลัง ถ้าต้องการสัญญาณที่ชัดขึ้น ให้ถามว่าพวกเขาจะเปลี่ยนคำสั่งอย่างไรเพื่อให้การพยายามครั้งต่อไปของ AI ดีขึ้น\n\nสิ่งนี้เผยให้เห็นวิธีคิดของพวกเขาในเงื่อนไขจริง: โค้ดไม่สมบูรณ์ เวลาไม่มาก และต้องเลือกความสำคัญ\n\n### พลังพิเศษ: การพูดว่า "ไม่"\n\nAI มักฟังดูมั่นใจ พนักงานที่ดีสบายใจที่จะปฏิเสธ พวกเขาพูดไม่กับฟีเจอร์ที่เพิ่มความซับซ้อน ไม่กับการเปลี่ยนที่ทำให้ความปลอดภัยอ่อนลง และไม่กับการปล่อยโดยไม่มีหลักฐาน\n\nสัญญาณชัดคือการตอบคำถาม "คุณจะ merge อันนี้ไหม" ผู้สมัครดีไม่ตอบแบบให้ความรู้สึก พวกเขาตัดสินใจและให้รายการสั้นๆ ของการเปลี่ยนที่ต้องทำ\n\nตัวอย่าง: คุณขอการอัปเดตการควบคุมการเข้าถึงแบบ "ด่วน" และ AI แนะนำการโรยเช็กทั่ว handler ผู้สมัครที่แข็งแกร่งจะปฏิเสธและเสนอเลเยอร์ authorization เดียวชัดเจน พร้อมการทดสอบสำหรับเส้นทาง admin และ non-admin\n\nสุดท้าย สร้างมาตรฐานร่วมกันเพื่อให้ทีมแก้ไขผลลัพธ์จาก AI ในแนวทางเดียวกัน รักษาให้เรียบง่าย: คำนิยามของความเสร็จหนึ่งข้อ, ความคาดหวังการตรวจทานที่สอดคล้อง, และมาตรฐานการทดสอบพื้นฐาน\n\n## สเปคและการวางแผน: พรอมท์ที่ชัดเริ่มจากความคิดที่ชัด\n\nเมื่อ AI สร้างโค้ดมากในไม่กี่นาที มันยั่วยวนให้ข้ามการคิดและวนแก้ไปเรื่อยๆ ใช้งานได้ดีกับเดโม แต่พังเมื่อต้องการความถูกต้อง พฤติกรรมที่คาดได้ และความประหลาดใจน้อยลง\n\nพรอมท์ที่ดีมักเป็นสเปคสั้นๆ ที่ซ่อนอยู่ ก่อนขอโค้ด แปลงเป้าหมายคลุมเครือนั้นให้เป็นเกณฑ์การยอมรับไม่กี่ข้อและสิ่งที่เป็น non-goals ชัดๆ นี่ป้องกันไม่ให้ AI (และทีม) ขยายขอบเขตเงียบๆ\n\nรักษาสเปคให้เล็กแต่เฉพาะ คุณไม่ได้เขียนนิยาย คุณกำลังตั้งขอบเขตรอบ:\n\n- อินพุต: อะไรเข้ามา (ฟิลด์, รูปแบบ, กรณีขอบ)\n- เอาต์พุต: อะไรต้องออกมา (รวมตัวอย่าง)\n- ข้อผิดพลาด: อะไรอาจผิดและตอบอย่างไร\n- ข้อจำกัด: ประสิทธิภาพ ความเป็นส่วนตัว การพึ่งพา หรือตรงที่ "ห้ามเปลี่ยน"\n- สิ่งที่ไม่ทำ: สิ่งที่คุณจะไม่ทำในการเปลี่ยนครั้งนี้\n\nกำหนด "เสร็จ" ก่อนการสร้าง ไม่ใช่หลัง "เสร็จ" ควรมากกว่า "คอมไพล์ได้" หรือ "UI ดูถูกต้อง" รวมความคาดหวังการทดสอบ ความเข้ากันย้อนหลัง และสิ่งที่ต้องมอนิเตอร์หลังปล่อย\n\nตัวอย่าง: ต้องการ "เพิ่มรีเซ็ตรหัสผ่าน" สเปคที่ชัดเจนอาจบอก: ผู้ใช้ขอรีเซ็ตทางอีเมล; ลิงก์หมดอายุ 15 นาที; ข้อความเดียวกันแสดงไม่ว่าอีเมลมีอยู่หรือไม่; rate limit ต่อ IP; บันทึกความพยายามโดยไม่เก็บโทเค็นเป็นข้อความธรรมดา Non-goal: ไม่ redesign หน้าเข้าสู่ระบบ ตอนนี้พรอมท์มีรั้วกันและการตรวจทานง่ายขึ้น\n\nเก็บบันทึกการเปลี่ยนแปลงแบบเบาๆ หนึ่งย่อหน้าต่อการตัดสินใจพอ บันทึกว่าทำไมเลือกวิธีนี้และทำไมไม่เลือกทางอื่น เมื่อมีคนถามว่า "ทำไมถึงเป็นแบบนี้" สองสัปดาห์ต่อมา คุณจะมีคำตอบ\n\n## เวิร์กโฟลว์ปฏิบัติที่มี AI ช่วยที่ทำซ้ำได้\n\nการเปลี่ยนที่ใหญ่ที่สุดกับ AI คือการสร้างโค้ดง่ายขึ้น ส่วนที่ยากคือตัดสินใจว่าโค้ดนั้นควรทำอะไรและพิสูจน์ว่าทำได้\n\nเริ่มด้วยการเขียนเป้าหมายและข้อจำกัดเป็นภาษาธรรมดา ระบุสิ่งที่ห้ามเกิดขึ้น สิ่งที่ช้าได้ และสิ่งที่อยู่นอกขอบเขต ข้อจำกัดที่ดีมักทดสอบได้: "ห้ามให้ผู้ใช้เห็นข้อมูลของผู้ใช้อื่น" หรือ "ยอดรวมต้องตรงกับการส่งออกทางการเงินเป็นเศษส่วน"\n\nก่อนขอโค้ด ขอการออกแบบเรียบง่ายและการแลกเปลี่ยนที่จะทำให้คุณตัดสินใจได้: มันจะเก็บอะไร จะตรวจสอบอะไร และจะบันทึกอะไร หากมันเสนอสิ่งฉลาด ให้ต้านและขอเวอร์ชันที่เรียบที่สุดที่ยังตรงตามข้อจำกัด\n\nลูปที่ทำซ้ำได้มีลักษณะดังนี้:\n\n1. เขียนปัญหาแบบสั้นและ 3–5 เกณฑ์ยอมรับแบบ pass/fail\n2. ขอแผนมินิมอล: แบบข้อมูล ฟังก์ชันหลัก และสิ่งที่อาจผิด\n3. สร้างการเปลี่ยนแปลงเล็กๆ ครั้งละหนึ่งชิ้น (หนึ่ง endpoint, หนึ่งหน้าจอ, หนึ่ง migration) ไม่ใช่ทิ้งแอปทั้งแอป\n4. ตรวจทานแบบบรรณาธิการ: อ่าน diff, รันเทสต์, ลองกรณีล้มเหลว แล้วขอแก้ไข\n5. ปล่อยอย่างปลอดภัย: ใช้ฟีเจอร์ flag หรือโรลเอาต์จำกัด มอนิเตอร์ล็อกและเมตริก และเตรียมย้อนกลับ\n\nตัวอย่างเล็กๆ: คุณเพิ่ม "สถานะคืนเงิน" ในหน้ารายการสั่งซื้อ AI สร้าง UI ได้เร็ว แต่ความถูกต้องอยู่ที่กรณีขอบ ถ้ามีการคืนเงินบางส่วนเป็นอย่างไร? ถ้า payment provider retry webhook ล่ะ? เขียนกรณีเหล่านั้นก่อน แล้วทำชิ้นเดียว (คอลัมน์ฐานข้อมูลพร้อม validation) และยืนยันด้วยเทสต์ก่อนจะไปต่อ\n\nถ้าคุณใช้ Koder.ai ฟีเจอร์เช่น planning mode, snapshots, และ rollback จะเข้ากับลูปนี้อย่างเป็นธรรมชาติ: วางแผนก่อน สร้างเป็นชิ้น แล้วจับจุดคืนค่าที่ปลอดภัยสำหรับการเปลี่ยนแปลงที่มีความหมายทุกอัน\n\n## ความผิดพลาดทั่วไปเมื่อการสร้างโค้ดด้วย AI ทำให้รู้สึกง่ายเกินไป\n\nเมื่อการสร้างโค้ดเร็ว มันยั่วยวนให้มองว่าโค้ดคือผลผลิตจริง งานจริงคือพฤติกรรม: แอปทำสิ่งที่ถูกต้องแม้เมื่อสิ่งต่างๆ ผิดพลาด\n\n### 1) เชื่อผลลัพธ์ที่มั่นใจโดยไม่พิสูจน์\n\nAI มักฟังดูแน่นอน แม้กำลังคาดเดา ความผิดพลาดคือข้ามส่วนที่น่าเบื่อ: รันเทสต์ ตรวจสอบกรณีขอบ และยืนยันอินพุตจริงๆ เว้นนิสัยง่ายๆ: ก่อนยอมรับการเปลี่ยน ถามว่า "เรารู้ได้อย่างไรว่านี่ถูกต้อง?" ถ้าคำตอบคือ "มันดูถูก" คุณกำลังเสี่ยง\n\n### 2) ให้เครื่องมือขยายขอบเขตงาน\n\nAI ชอบเพิ่มของ: caching, retries, การตั้งค่ามากขึ้น, endpoint เพิ่ม, UI สวยขึ้น บางอย่างดี แต่เพิ่มความเสี่ยง บั๊กส่วนใหญ่มาจากฟีเจอร์เสริมที่ไม่มีใครขอ\n\nตั้งขอบเขตแน่น: แก้ปัญหาที่ตั้งไว้ แล้วหยุด ถ้าข้อเสนอมีค่า ให้จับเป็นงานแยกที่มีเทสต์ของมันเอง\n\n### 3) ผสานการเปลี่ยนแปลงที่ใหญ่เกินจะตรวจทาน\n\nคอมมิทขนาดใหญ่ที่สร้างโดย AI อาจซ่อนการตัดสินใจหลายข้อ การตรวจทานกลายเป็นการรับรอง พังให้เล็ก: เปลี่ยนทีละฟีเจอร์ migration ทีละอัน พื้นที่ความเสี่ยงสูงทีละจุด อัปเดตเทสต์ในชุดเดียวกัน และเขียน "วิธีตรวจสอบ" สั้นๆ\n\n### 4) คัดลอกโค้ดที่มีความเสี่ยงด้านสิทธิ์การใช้งานหรือความปลอดภัยไม่ชัดเจน\n\nAI อาจทำซ้ำรูปแบบจากข้อมูลเทรนหรือแนะนำ dependency ที่คุณไม่เข้าใจ แม้ลิขสิทธิ์จะโอเค ความเสี่ยงใหญ่มาจากความปลอดภัย: รหัสผ่านหรือความลับฝังในโค้ด, การจัดการโทเค็นอ่อนแอ, หรือการจัดการไฟล์/คิวรีที่ไม่ปลอดภัย\n\nถ้าคุณอธิบายสรุปสิ่งที่ snippet ทำไม่ได้ อย่าเอามันขึ้น production ขอเวอร์ชันที่เรียบง่ายกว่า หรือเขียนใหม่เอง\n\n### 5) ลืม migration ข้อจำกัด และโหมดล้มเหลว\n\nบั๊กแบบ "มันใช้ได้บนเครื่องฉัน" หลายตัวเป็นบั๊กข้อมูลและสเกล AI อาจสร้างการเปลี่ยนสคีมาโดยไม่คิดถึงแถวที่มีอยู่ ตารางใหญ่ หรือ downtime\n\nตัวอย่างสมจริง: โมเดลเพิ่มคอลัมน์ NOT NULL ใหม่ใน PostgreSQL และ backfill ในลูปช้า ในโปรดักชันนั่นอาจล็อกตารางและทำให้แอปพัง เสมอพิจารณาว่าเกิดอะไรขึ้นกับหนึ่งล้านแถว เครือข่ายช้า หรือ deploy ล้มกลางทาง\n\n## ตัวอย่าง: แอปเล็กๆ ที่ความถูกต้องสำคัญกว่าความเร็ว\n\nจินตนาการแอปติดตามคำขอภายใน: ผู้คนส่งคำขอ ผู้จัดการอนุมัติหรือปฏิเสธ และฝ่ายการเงินทำเครื่องหมายว่าได้รับชำระ มันดูเรียบง่าย และด้วย AI คุณสามารถสร้างหน้าจอและ endpoint ได้เร็ว ส่วนที่ชะลอคุณคือความจริงเดิม: กฎ ไม่ใช่การพิมพ์\n\nเริ่มจากการเขียนขั้นต่ำที่ต้องถูกต้อง ถ้าคุณอธิบายเป็นคำธรรมดาไม่ได้ คุณทดสอบไม่ได้\n\nคำจำกัดความเวอร์ชันแรกที่เข้มงวดมักเป็นแบบนี้: ฟิลด์ (title, requester, department, amount, reason, status, timestamps); บทบาท (requester, approver, finance, admin); สถานะ (draft, submitted, approved, rejected, paid). แล้วระบุการเปลี่ยนสถานะที่สำคัญ: มีเพียง approver เท่านั้นที่เปลี่ยน submitted เป็น approved หรือ rejected; มีเพียง finance เท่านั้นที่เปลี่ยน approved เป็น paid\n\nใช้ AI ในลำดับที่ควบคุมได้เพื่อจับข้อผิดพลาดแต่ต้น:\n\n1) กำหนดสคีมาฐานข้อมูลและ enum สถานะก่อน\n2) สร้าง endpoint รอบการเปลี่ยนสถานะ (submit, approve, reject, pay) ไม่ใช่ route generic update-anything\n3) สร้าง UI เป็นขั้นสุดท้าย ตามที่ API อนุญาต\n\nการทดสอบที่มีค่าสูงสุดไม่ใช่ว่า "หน้าโหลดได้หรือไม่" แต่เป็นการเช็กสิทธิ์และการเปลี่ยนสถานะ พิสูจน์ว่า requester ไม่สามารถอนุมัติคำขอของตัวเอง approver ไม่สามารถมาร์กเป็นจ่ายได้ คำขอที่ถูกปฏิเสธจ่ายไม่ได้ และ (ถ้าเป็นกฎของคุณ) ยอดไม่สามารถแก้ไขหลังส่งได้\n\nสิ่งที่ใช้เวลานานที่สุดคือการชัดเจนในกรณีขอบ ผู้อนุมัติเปลี่ยนใจหลังปฏิเสธได้ไหม ถ้าสองผู้อนุมัติคลิกอนุมัติพร้อมกันจะเกิดอะไรขึ้น ฝ่ายการเงินต้องการจ่ายบางส่วนไหม AI สามารถสร้างโค้ดตามคำตอบใดๆ ที่คุณเลือก แต่ไม่สามารถเลือกคำตอบให้คุณ ความถูกต้องมาจากการตัดสินใจเหล่านั้น แล้วบังคับให้โค้ดทำตาม\n\n## เช็กลิสต์ด่วนก่อนปล่อยการเปลี่ยนที่สร้างโดย AI\n\nAI สร้างโค้ดได้เร็ว แต่ไมล์สุดท้ายยังคงเป็นงานมนุษย์: พิสูจน์ว่ามันทำอย่างที่คุณตั้งใจ และล้มอย่างปลอดภัยเมื่อไม่ใช่\n\nก่อนเช็กรายการ ให้เลือกคำจำกัดความ "เสร็จ" เล็กที่สุดที่สำคัญ สำหรับฟีเจอร์เล็กๆ อาจเป็นทางผ่านเดียว สองทางล้มเหลว และการอ่านความเข้าใจไว้อย่างรวดเร็ว สำหรับการชำระเงินหรือ auth ยกระดับมาตรฐาน\n\n### ห้าเช็ค\n\n- ข้อกำหนดทุกข้อสามารถตรวจสอบได้ สำหรับแต่ละข้อ คุณมีเทสต์หรือการตรวจสอบด้วยมือชัดเจนเป็นประโยคเดียว ถ้าคุณอธิบายวิธีตรวจสอบไม่ได้ คุณอาจไม่เข้าใจสิ่งที่สร้าง\n- การล้มเหลวถูกจัดการและอธิบาย ลองกรณีข้อผิดพลาดสำคัญ (อินพุตไม่ถูก, ขาดสิทธิ์, เครือข่ายล้ม, ฐานข้อมูลว่าง) ให้แน่ใจว่าแอปแสดงข้อความที่เป็นประโยชน์และไม่รั่วไหลข้อมูลละเอียดอ่อน\n- การออกแบบยังคงเรียบง่าย ถ้า AI เพิ่ม helper, abstraction หรือ pattern ฉลาดๆ ถาม: คุณจะเก็บมันไว้ถ้าคุณเขียนเองไหม? ลบเลเยอร์เกินความจำเป็น\n- ผู้ตรวจทานใหม่ตามอ่านได้ สมมติว่าผู้ตรวจทานไม่ได้ดูเซสชันแชท โค้ดควรอ่านราวกับเรื่อง: ชื่อชัด ฟังก์ชันสั้น และโน้ตสั้นว่าทำไมเปลี่ยนแปลงนี้ถึงมีอยู่\n- คุณย้อนกลับได้อย่างปลอดภัย รู้ว่า "กลับสู่สภาวะปกติ" คืออะไร จับเวอร์ชันที่รู้ว่าดีและยืนยันว่าคุณย้อนกลับได้อย่างรวดเร็วถ้าโปรดักชันทำงานต่างไป\n\n### ตัวอย่างสั้นๆ\n\nสมมติ AI เพิ่ม "เชิญผู้ใช้จำนวนมาก" ในหน้าผู้ดูแล เส้นทางปกติทำงาน แต่ความเสี่ยงคือกรณีขอบ: อีเมลซ้ำ ความล้มเหลวแบบบางส่วน และข้อจำกัด rate A การตัดสินใจส่งที่แข็งแรงอาจเป็นเทสต์อัตโนมัติหนึ่งรายการสำหรับการซ้ำ แบบตรวจด้วยมือหนึ่งรายการสำหรับข้อความในกรณีล้มเหลวบางส่วน และแผนย้อนกลับ\n\n## ขั้นตอนถัดไป: เพิ่มเกราะกัน แล้วขยายกระบวนการของคุณ\n\nเมื่อโค้ดถูกทำให้ถูก ความเสี่ยงย้ายไปที่คุณภาพการตัดสินใจ: คุณขออะไร คุณยอมรับอะไร และคุณส่งอะไร วิธีที่เร็วที่สุดที่จะทำให้ข้อเท็จจริงเหล่านี้ได้ผลในการทำงานด้วย AI คือเพิ่มเกราะกันที่ป้องกันการเปลี่ยนแปลง "เกือบถูก" ไหลผ่าน\n\nเริ่มด้วยสเปคหน้ากระดาษสำหรับฟีเจอร์ถัดไป รักษาให้ชัด: ใครใช้ มันทำอะไร ไม่ทำอะไร และชุดการทดสอบการยอมรับเป็นภาษาธรรมดา หลักการรับ/ปฏิเสธเหล่านี้จะเป็นสมอเมื่-AI แนะนำทางลัดที่ล่อใจ\n\nชุดเกราะที่ขยายได้โดยไม่เพิ่มกระบวนการหนามาก:\n\n- ทำให้การเปลี่ยนเล็กพอที่ตรวจทานได้ในไม่กี่นาที ไม่ใช่ชั่วโมง\n- ต้องมีเทสต์ (หรืออย่างน้อยโน้ตกการทดสอบ) สำหรับทุกการเปลี่ยนพฤติกรรม\n- ใช้เทมเพลตพรอมท์มาตรฐาน: ข้อจำกัด สไตล์การเขียนโค้ด และความคาดหวังการทดสอบ\n- เตรียมทางย้อนกลับที่เชื่อถือได้สำหรับทุกการดีพลอย\n- ติดตามสิ่งที่ไม่รู้ในฐานะ TODO ชัดเจน ไม่ใช่สมมติฐานที่ซ่อนอยู่\n\nพรอมท์เป็นส่วนหนึ่งของกระบวนการของคุณแล้ว ตกลงสไตล์บ้าน: ไลบรารีที่อนุญาต การจัดการข้อผิดพลาด ความหมายของ "เสร็จ" และเทสต์ที่ต้องผ่าน หากพรอมท์ใช้ซ้ำไม่ได้กับเพื่อนร่วมงาน มันอาจคลุมเครือเกินไป\n\nถ้าคุณชอบวิธีสร้างเว็บ backend และแอปมือถือแบบแชทเป็นหลัก Koder.ai เป็นตัวอย่างหนึ่งของแพลตฟอร์มที่มี vibe-coding ซึ่ง planning mode, snapshots, และการส่งออกซอร์สโค้ดสามารถสนับสนุนเกราะกันเหล่านี้ เครื่องมือนั้นช่วยเร่งร่าง แต่ระเบียบวินัยต่างหากที่ทำให้มนุษย์ยังคุมความถูกต้องอยู่
