ข้อเท็จจริงซอฟต์แวร์ของ Joel Spolsky สำหรับการพัฒนาด้วย AI

ทำไมข้อเท็จจริงเหล่านี้ยังสำคัญเมื่อ AI เขียนโค้ดได้เร็ว

AI สามารถสร้างโค้ดที่ดูใช้งานได้ภายในไม่กี่นาที นั่นเปลี่ยนความเร็วของโปรเจกต์ แต่ไม่เปลี่ยนสิ่งที่ทำให้ซอฟต์แวร์ประสบความสำเร็จ บทเรียนใน “ข้อเท็จจริงซอฟต์แวร์” ของ Joel Spolsky ไม่ได้เกี่ยวกับความเร็วในการพิมพ์จริงๆ แต่มันเกี่ยวกับการตัดสินใจ วงจรป้อนกลับ และการหลีกเลี่ยงความซับซ้อนที่เราสร้างขึ้นเอง

สิ่งที่เปลี่ยนคือต้นทุนการสร้างโค้ด คุณขอสามแนวทาง ห้าตัวแปร หรือรีไรท์ทั้งระบบและได้ผลลัพธ์กลับมาในทันที แต่สิ่งที่ไม่เปลี่ยนคือต้นทุนของการเลือกแนวทางที่ถูกต้อง การตรวจสอบมัน และการอยู่กับมันเป็นเดือนๆ เวลาที่ประหยัดจากการเขียนมักย้ายไปที่การตัดสินใจความหมายของสิ่งที่คุณต้องการ ยืนยันกรณีขอบ และมั่นใจว่า “ชัยชนะรวดเร็ว” ของวันนี้จะไม่กลายเป็นภาษีบำรุงรักษาของวันพรุ่งนี้

ความถูกต้อง ความปลอดภัย และความสามารถในการบำรุงรักษายังคงต้องใช้เวลาเพราะพวกมันต้องการหลักฐาน ไม่ใช่แค่ความมั่นใจ. ฟลูว์การล็อกอินไม่เสร็จเมื่อมันคอมไพล์ มันเสร็จเมื่อมันปฏิเสธอินพุตที่ไม่ดีอย่างเชื่อถือได้ จัดการสถานะแปลกๆ ได้ และไม่รั่วไหลข้อมูล AI อาจฟังดูแน่นอนแต่พลาดรายละเอียดสำคัญ เช่น การเช็กสิทธิ์บน endpoint หรือเงื่อนไขการแข่งขันในการอัปเดตการชำระเงิน

AI แข็งแกร่งที่สุดเมื่อคุณปฏิบัติต่อมันเหมือนเครื่องร่างเร็ว มันยอดเยี่ยมในการสร้างบอยเลอร์เพลท รูปแบบทำซ้ำ การรีแฟคเตอร์ด่วน และการสำรวจตัวเลือกให้คุณเปรียบเทียบกัน ใช้ดีมันจะย่นระยะเวลาของเฟส 'หน้าเปล่า'

AI ทำร้ายมากที่สุดเมื่อคุณส่งเป้าหมายคลุมเครือให้มันและยอมรับผลลัพธ์ตามหน้าเดียวกัน รูปแบบความล้มเหลวเดิมๆ จะเกิดซ้ำ: สมมติฐานที่ซ่อนอยู่ (กฎธุรกิจที่ไม่ได้ระบุ), เส้นทางที่ไม่ได้ทดสอบ (การจัดการข้อผิดพลาด การลองใหม่ สถานะว่าง), ความผิดพลาดที่ดูมั่นใจ (โค้ดที่เป็นไปได้แต่ผิดอย่างละเอียดอ่อน), และโซลูชัน "ฉลาด" ที่อธิบายยากภายหลัง

เมื่อโค้ดถูกทำให้มีราคาถูกลง ทรัพยากรที่ขาดแคลนใหม่คือความไว้วางใจ ความจริงเหล่านี้มีความสำคัญเพราะช่วยปกป้องความไว้วางใจนั้น: กับผู้ใช้ เพื่อนร่วมทีม และตัวคุณในอนาคต

การทดสอบยังคงเป็นคอขวด และนั่นเป็นเรื่องดี

เมื่อ AI สามารถสร้างฟีเจอร์ได้ในไม่กี่นาที มันยั่วยวนให้มองว่าการทดสอบเป็นส่วนช้าที่ต้องตัดออก ข้อสังเกตของ Spolsky ยังคงเป็นจริง: ส่วนที่ช้าคือที่ที่ความจริงอยู่ โค้ดผลิตง่าย พฤติกรรมที่ถูกต้องไม่ได้เป็นเช่นนั้น

การเปลี่ยนมุมมองที่มีประโยชน์คือมองการทดสอบเป็นข้อกำหนดที่คุณรันได้ ถ้าคุณอธิบายพฤติกรรมที่คาดหวังไม่ได้ในแบบที่ตรวจสอบได้ แปลว่าคุณยังคิดไม่เสร็จ ในงานที่มี AI ช่วย เรื่องนี้สำคัญขึ้น ไม่ใช่ลดลง เพราะโมเดลสามารถสร้างสิ่งที่มั่นใจแต่ผิดเล็กๆ น้อยๆ

เริ่มทดสอบจากสิ่งที่จะทำให้เกิดความเสียหายมากที่สุดถ้ามันพัง สำหรับสินค้าส่วนใหญ่ นั่นคือฟลูว์หลัก (สมัคร, เช็คเอาต์, บันทึก, ส่งออก), สิทธิ์ (ใครดู แก้ไข ลบได้) และความสมบูรณ์ของข้อมูล (ไม่มีซ้ำ ยอดถูกต้อง การย้ายข้อมูลปลอดภัย) แล้วจงครอบคลุมขอบที่มักทำให้เกิดเหตุการณ์ดึกๆ เช่น อินพุตว่าง ข้อความยาว เขตเวลา การลองใหม่ และพรมแดนภายนอกที่ไม่น่าเชื่อถือ เช่น การชำระเงิน อีเมล และการอัปโหลดไฟล์

AI ดีในการเสนอเคสการทดสอบ แต่ไม่รู้ว่าคุณสัญญากับผู้ใช้ไว้จริงๆ ใช้มันเป็นพาร์ทเนอร์ระดมสมอง: ขอกรณีขอบที่ขาด สถานการณ์การใช้งานผิดปกติ และการรวมสิทธิ์ จากนั้นทำงานของมนุษย์: จับความครอบคลุมให้ตรงกับกฎจริงของคุณและลบการทดสอบที่ "ทดสอบการดำเนินงาน" แทนที่จะเป็นพฤติกรรม

ทำให้ความล้มเหลวเป็นสิ่งที่แก้ไขได้โดยปฏิบัติ การทดสอบที่ล้มเหลวควรบอกคุณว่าพังอะไร ไม่ใช่ส่งคุณไปล่าหาสาเหตุราวกับล่าสมบัติ เก็บการทดสอบให้เล็ก ตั้งชื่อเหมือนประโยค และทำให้ข้อความผิดพลาดเฉพาะเจาะจง

ตัวอย่างสั้นๆ

สมมติคุณสร้างแอป "โน้ตทีม" ง่ายๆ โดยมี AI ช่วย หน้าจอ CRUD ปรากฏอย่างรวดเร็ว ความเสี่ยงด้านความถูกต้องไม่ใช่ UI แต่เป็นการควบคุมการเข้าถึงและกฎข้อมูล: ผู้ใช้คนหนึ่งต้องไม่เห็นโน้ตของทีมอื่น การแก้ไขต้องไม่เขียนทับการเปลี่ยนแปลงที่ใหม่กว่า และการลบโน้ตไม่ควรทิ้งไฟล์แนบโดดเดี่ยว การทดสอบที่ล็อกกฎเหล่านี้จะรู้สึกเป็นคอขวด แต่ก็เป็นตาข่ายนิรภัยของคุณ

เมื่อการทดสอบเป็นคอขวด มันบังคับให้ชัดเจน ความชัดเจนนั้นคือสิ่งที่ป้องกันไม่ให้โค้ดเร็วกลายเป็นบั๊กเร็ว

ความเรียบง่ายชนะความฉลาด โดยเฉพาะเมื่อมี AI อยู่ในวงจร

หนึ่งในความจริงที่ทนทานที่สุดคือโค้ดเรียบง่ายชนะโค้ดฉลาด AI ทำให้ยั่วยวนที่จะยอมรับนามธรรมซับซ้อนเพราะมันมาบรรจบและรวดเร็ว แต่ต้นทุนจะปรากฏทีหลัง: เพิ่มจุดซ่อนบั๊ก มากขึ้นที่จะสแกน และช่วงเวลา "นี่มันทำอะไร" มากขึ้น

เมื่อโค้ดถูกทำให้ถูก การจ่ายคือความซับซ้อน การออกแบบเล็กๆ น่าเบื่อ ง่ายต่อการทดสอบ ง่ายต่อการเปลี่ยน และง่ายต่อการอธิบาย นั่นสำคัญยิ่งขึ้นเมื่อร่างแรกมาจากโมเดลที่ฟังดูแน่นอนแต่ผิดเล็กๆ น้อยๆ

กฎปฏิบัติ: ให้ฟังก์ชัน คอมโพเนนต์ และโมดูลเล็กพอที่เพื่อนร่วมทีมอ่านได้ในไม่กี่นาที ไม่ใช่หลายชั่วโมง ถ้าคอมโพเนนต์ React ต้องการหลาย custom hooks เครื่องสถานะท้องถิ่น และเลเยอร์ renderer อัจฉริยะ หยุดแล้วถามว่าคุณกำลังแก้ปัญหาจริงหรือยอมรับสถาปัตยกรรมเพราะ AI เสนอมา

ไม่กี่ "การทดสอบความเรียบง่าย" จะช่วยให้คุณต้านได้:

• เพื่อนร่วมงานใหม่เข้าใจฟลูว์หลักได้ภายในครั้งเดียวหรือไม่?
• คุณลบ abstraction นี้และแทนที่ด้วยโค้ดธรรมดาโดยไม่เสียความชัดเจนได้ไหม?
• มีที่ชัดๆ ที่จะแก้บั๊กแค่ที่เดียว หรือห้าแห่ง?

พรอมท์สำคัญ ถ้าคุณขอ "สถาปัตยกรรมที่ดีที่สุด" มักได้สิ่งที่โอเวอร์บิลด์ ถามด้วยข้อจำกัดที่จะดันไปสู่ชิ้นส่วนเคลื่อนไหวให้น้อยลง ตัวอย่าง: ใช้วิธีที่เรียบที่สุดกับไฟล์น้อยที่สุด; หลีกเลี่ยงนามธรรมใหม่เว้นแต่จะลดการทำซ้ำใน 3 จุดขึ้นไป; ให้โค้ดชัดเจนมากกว่าฮีลเปอร์ทั่วไป

ตัวอย่างเป็นรูปธรรม: คุณขอให้ AI เพิ่มการเข้าถึงตามบทบาทในหน้าผู้ดูแล รุ่นฉลาดอาจแนะนำกรอบสิทธิ์ decorators และ DSL คอนฟิก รุ่นเรียบง่ายเช็กบทบาทผู้ใช้ที่จุดเดียว กั้นเส้นทางที่จุดเดียว และบันทึกการปฏิเสธการเข้าถึง รุ่นเรียบง่ายตรวจทานง่าย ทดสอบง่าย และตีความยากน้อยกว่า

ถ้าคุณสร้างในเครื่องมือแชท เช่น Koder.ai ความเรียบง่ายยังทำให้ snapshot และ rollback มีคุณค่า การเปลี่ยนเล็กๆ ชัดเจนง่ายต่อการเปรียบเทียบ เก็บ หรือย้อนกลับ

การจ้าง: คุณต้องการบรรณาธิการและผู้ตัดสินใจ ไม่ใช่พิมพ์ดีด

เมื่อโค้ดผลิตง่าย ทักษะที่ขาดแคลนคือการเลือกสิ่งที่จะมีอยู่และตรวจสอบว่ามันถูกต้อง คำแนะนำเดิม "จ้างโปรแกรมเมอร์เก่ง" ยังใช้ได้ แต่ตำแหน่งงานเปลี่ยนไป คุณไม่ได้จ้างใครให้พิมพ์เร็วขึ้น คุณจ้างคนให้ตัดสิน ปรับแต่ง และปกป้องผลิตภัณฑ์

คนที่มีค่านิยมสูงในงานที่มี AI ช่วยมักมีสี่ลักษณะร่วมกัน: การตัดสินใจ (อะไรสำคัญ), รสนิยม (อะไรดี), ทักษะแก้บั๊ก (หาสาเหตุจริง), และการสื่อสาร (อธิบายการแลกเปลี่ยนอย่างชัดเจน) พวกเขาสามารถเอาฟีเจอร์ที่ AI เขียนว่า "เกือบใช้งานได้" และเปลี่ยนให้เป็นสิ่งที่คุณเชื่อถือได้

การสัมภาษณ์ที่ดีกว่า: ปรับปรุงการเปลี่ยนแปลงที่ AI ทำ

แทนที่จะขอวิธีแก้สมบูรณ์ตั้งแต่ต้น ให้ผู้สมัครดู pull request ที่สร้างโดย AI (หรือ diff ที่วางมา) ที่มีปัญหาจริง: ตั้งชื่อไม่ชัด, มีกรณีขอบซ่อนอยู่, ขาดเทสต์, และมีข้อผิดพลาดความปลอดภัยเล็กน้อย

ขอให้พวกเขาอธิบายว่าโค้ดพยายามทำอะไรด้วยภาษาธรรมดา หาส่วนที่มีความเสี่ยงสูงสุด เสนอการแก้ไข และเพิ่ม (หรือร่าง) การทดสอบที่จะจับการถอยหลัง ถ้าต้องการสัญญาณที่ชัดขึ้น ให้ถามว่าพวกเขาจะเปลี่ยนคำสั่งอย่างไรเพื่อให้การพยายามครั้งต่อไปของ AI ดีขึ้น

สิ่งนี้เผยให้เห็นวิธีคิดของพวกเขาในเงื่อนไขจริง: โค้ดไม่สมบูรณ์ เวลาไม่มาก และต้องเลือกความสำคัญ

พลังพิเศษ: การพูดว่า "ไม่"

AI มักฟังดูมั่นใจ พนักงานที่ดีสบายใจที่จะปฏิเสธ พวกเขาพูดไม่กับฟีเจอร์ที่เพิ่มความซับซ้อน ไม่กับการเปลี่ยนที่ทำให้ความปลอดภัยอ่อนลง และไม่กับการปล่อยโดยไม่มีหลักฐาน

สัญญาณชัดคือการตอบคำถาม "คุณจะ merge อันนี้ไหม" ผู้สมัครดีไม่ตอบแบบให้ความรู้สึก พวกเขาตัดสินใจและให้รายการสั้นๆ ของการเปลี่ยนที่ต้องทำ

ตัวอย่าง: คุณขอการอัปเดตการควบคุมการเข้าถึงแบบ "ด่วน" และ AI แนะนำการโรยเช็กทั่ว handler ผู้สมัครที่แข็งแกร่งจะปฏิเสธและเสนอเลเยอร์ authorization เดียวชัดเจน พร้อมการทดสอบสำหรับเส้นทาง admin และ non-admin

สุดท้าย สร้างมาตรฐานร่วมกันเพื่อให้ทีมแก้ไขผลลัพธ์จาก AI ในแนวทางเดียวกัน รักษาให้เรียบง่าย: คำนิยามของความเสร็จหนึ่งข้อ, ความคาดหวังการตรวจทานที่สอดคล้อง, และมาตรฐานการทดสอบพื้นฐาน

สเปคและการวางแผน: พรอมท์ที่ชัดเริ่มจากความคิดที่ชัด

เมื่อ AI สร้างโค้ดมากในไม่กี่นาที มันยั่วยวนให้ข้ามการคิดและวนแก้ไปเรื่อยๆ ใช้งานได้ดีกับเดโม แต่พังเมื่อต้องการความถูกต้อง พฤติกรรมที่คาดได้ และความประหลาดใจน้อยลง

พรอมท์ที่ดีมักเป็นสเปคสั้นๆ ที่ซ่อนอยู่ ก่อนขอโค้ด แปลงเป้าหมายคลุมเครือนั้นให้เป็นเกณฑ์การยอมรับไม่กี่ข้อและสิ่งที่เป็น non-goals ชัดๆ นี่ป้องกันไม่ให้ AI (และทีม) ขยายขอบเขตเงียบๆ

รักษาสเปคให้เล็กแต่เฉพาะ คุณไม่ได้เขียนนิยาย คุณกำลังตั้งขอบเขตรอบ:

• อินพุต: อะไรเข้ามา (ฟิลด์, รูปแบบ, กรณีขอบ)
• เอาต์พุต: อะไรต้องออกมา (รวมตัวอย่าง)
• ข้อผิดพลาด: อะไรอาจผิดและตอบอย่างไร
• ข้อจำกัด: ประสิทธิภาพ ความเป็นส่วนตัว การพึ่งพา หรือตรงที่ "ห้ามเปลี่ยน"
• สิ่งที่ไม่ทำ: สิ่งที่คุณจะไม่ทำในการเปลี่ยนครั้งนี้

กำหนด "เสร็จ" ก่อนการสร้าง ไม่ใช่หลัง "เสร็จ" ควรมากกว่า "คอมไพล์ได้" หรือ "UI ดูถูกต้อง" รวมความคาดหวังการทดสอบ ความเข้ากันย้อนหลัง และสิ่งที่ต้องมอนิเตอร์หลังปล่อย

ตัวอย่าง: ต้องการ "เพิ่มรีเซ็ตรหัสผ่าน" สเปคที่ชัดเจนอาจบอก: ผู้ใช้ขอรีเซ็ตทางอีเมล; ลิงก์หมดอายุ 15 นาที; ข้อความเดียวกันแสดงไม่ว่าอีเมลมีอยู่หรือไม่; rate limit ต่อ IP; บันทึกความพยายามโดยไม่เก็บโทเค็นเป็นข้อความธรรมดา Non-goal: ไม่ redesign หน้าเข้าสู่ระบบ ตอนนี้พรอมท์มีรั้วกันและการตรวจทานง่ายขึ้น

เก็บบันทึกการเปลี่ยนแปลงแบบเบาๆ หนึ่งย่อหน้าต่อการตัดสินใจพอ บันทึกว่าทำไมเลือกวิธีนี้และทำไมไม่เลือกทางอื่น เมื่อมีคนถามว่า "ทำไมถึงเป็นแบบนี้" สองสัปดาห์ต่อมา คุณจะมีคำตอบ

เวิร์กโฟลว์ปฏิบัติที่มี AI ช่วยที่ทำซ้ำได้

การเปลี่ยนที่ใหญ่ที่สุดกับ AI คือการสร้างโค้ดง่ายขึ้น ส่วนที่ยากคือตัดสินใจว่าโค้ดนั้นควรทำอะไรและพิสูจน์ว่าทำได้

เริ่มด้วยการเขียนเป้าหมายและข้อจำกัดเป็นภาษาธรรมดา ระบุสิ่งที่ห้ามเกิดขึ้น สิ่งที่ช้าได้ และสิ่งที่อยู่นอกขอบเขต ข้อจำกัดที่ดีมักทดสอบได้: "ห้ามให้ผู้ใช้เห็นข้อมูลของผู้ใช้อื่น" หรือ "ยอดรวมต้องตรงกับการส่งออกทางการเงินเป็นเศษส่วน"

ก่อนขอโค้ด ขอการออกแบบเรียบง่ายและการแลกเปลี่ยนที่จะทำให้คุณตัดสินใจได้: มันจะเก็บอะไร จะตรวจสอบอะไร และจะบันทึกอะไร หากมันเสนอสิ่งฉลาด ให้ต้านและขอเวอร์ชันที่เรียบที่สุดที่ยังตรงตามข้อจำกัด

ลูปที่ทำซ้ำได้มีลักษณะดังนี้:

1. เขียนปัญหาแบบสั้นและ 3–5 เกณฑ์ยอมรับแบบ pass/fail
2. ขอแผนมินิมอล: แบบข้อมูล ฟังก์ชันหลัก และสิ่งที่อาจผิด
3. สร้างการเปลี่ยนแปลงเล็กๆ ครั้งละหนึ่งชิ้น (หนึ่ง endpoint, หนึ่งหน้าจอ, หนึ่ง migration) ไม่ใช่ทิ้งแอปทั้งแอป
4. ตรวจทานแบบบรรณาธิการ: อ่าน diff, รันเทสต์, ลองกรณีล้มเหลว แล้วขอแก้ไข
5. ปล่อยอย่างปลอดภัย: ใช้ฟีเจอร์ flag หรือโรลเอาต์จำกัด มอนิเตอร์ล็อกและเมตริก และเตรียมย้อนกลับ

ตัวอย่างเล็กๆ: คุณเพิ่ม "สถานะคืนเงิน" ในหน้ารายการสั่งซื้อ AI สร้าง UI ได้เร็ว แต่ความถูกต้องอยู่ที่กรณีขอบ ถ้ามีการคืนเงินบางส่วนเป็นอย่างไร? ถ้า payment provider retry webhook ล่ะ? เขียนกรณีเหล่านั้นก่อน แล้วทำชิ้นเดียว (คอลัมน์ฐานข้อมูลพร้อม validation) และยืนยันด้วยเทสต์ก่อนจะไปต่อ

ถ้าคุณใช้ Koder.ai ฟีเจอร์เช่น planning mode, snapshots, และ rollback จะเข้ากับลูปนี้อย่างเป็นธรรมชาติ: วางแผนก่อน สร้างเป็นชิ้น แล้วจับจุดคืนค่าที่ปลอดภัยสำหรับการเปลี่ยนแปลงที่มีความหมายทุกอัน

ความผิดพลาดทั่วไปเมื่อการสร้างโค้ดด้วย AI ทำให้รู้สึกง่ายเกินไป

เมื่อการสร้างโค้ดเร็ว มันยั่วยวนให้มองว่าโค้ดคือผลผลิตจริง งานจริงคือพฤติกรรม: แอปทำสิ่งที่ถูกต้องแม้เมื่อสิ่งต่างๆ ผิดพลาด

1) เชื่อผลลัพธ์ที่มั่นใจโดยไม่พิสูจน์

AI มักฟังดูแน่นอน แม้กำลังคาดเดา ความผิดพลาดคือข้ามส่วนที่น่าเบื่อ: รันเทสต์ ตรวจสอบกรณีขอบ และยืนยันอินพุตจริงๆ เว้นนิสัยง่ายๆ: ก่อนยอมรับการเปลี่ยน ถามว่า "เรารู้ได้อย่างไรว่านี่ถูกต้อง?" ถ้าคำตอบคือ "มันดูถูก" คุณกำลังเสี่ยง

2) ให้เครื่องมือขยายขอบเขตงาน

AI ชอบเพิ่มของ: caching, retries, การตั้งค่ามากขึ้น, endpoint เพิ่ม, UI สวยขึ้น บางอย่างดี แต่เพิ่มความเสี่ยง บั๊กส่วนใหญ่มาจากฟีเจอร์เสริมที่ไม่มีใครขอ

ตั้งขอบเขตแน่น: แก้ปัญหาที่ตั้งไว้ แล้วหยุด ถ้าข้อเสนอมีค่า ให้จับเป็นงานแยกที่มีเทสต์ของมันเอง

3) ผสานการเปลี่ยนแปลงที่ใหญ่เกินจะตรวจทาน

คอมมิทขนาดใหญ่ที่สร้างโดย AI อาจซ่อนการตัดสินใจหลายข้อ การตรวจทานกลายเป็นการรับรอง พังให้เล็ก: เปลี่ยนทีละฟีเจอร์ migration ทีละอัน พื้นที่ความเสี่ยงสูงทีละจุด อัปเดตเทสต์ในชุดเดียวกัน และเขียน "วิธีตรวจสอบ" สั้นๆ

4) คัดลอกโค้ดที่มีความเสี่ยงด้านสิทธิ์การใช้งานหรือความปลอดภัยไม่ชัดเจน

AI อาจทำซ้ำรูปแบบจากข้อมูลเทรนหรือแนะนำ dependency ที่คุณไม่เข้าใจ แม้ลิขสิทธิ์จะโอเค ความเสี่ยงใหญ่มาจากความปลอดภัย: รหัสผ่านหรือความลับฝังในโค้ด, การจัดการโทเค็นอ่อนแอ, หรือการจัดการไฟล์/คิวรีที่ไม่ปลอดภัย

ถ้าคุณอธิบายสรุปสิ่งที่ snippet ทำไม่ได้ อย่าเอามันขึ้น production ขอเวอร์ชันที่เรียบง่ายกว่า หรือเขียนใหม่เอง

5) ลืม migration ข้อจำกัด และโหมดล้มเหลว

บั๊กแบบ "มันใช้ได้บนเครื่องฉัน" หลายตัวเป็นบั๊กข้อมูลและสเกล AI อาจสร้างการเปลี่ยนสคีมาโดยไม่คิดถึงแถวที่มีอยู่ ตารางใหญ่ หรือ downtime

ตัวอย่างสมจริง: โมเดลเพิ่มคอลัมน์ NOT NULL ใหม่ใน PostgreSQL และ backfill ในลูปช้า ในโปรดักชันนั่นอาจล็อกตารางและทำให้แอปพัง เสมอพิจารณาว่าเกิดอะไรขึ้นกับหนึ่งล้านแถว เครือข่ายช้า หรือ deploy ล้มกลางทาง

ตัวอย่าง: แอปเล็กๆ ที่ความถูกต้องสำคัญกว่าความเร็ว

จินตนาการแอปติดตามคำขอภายใน: ผู้คนส่งคำขอ ผู้จัดการอนุมัติหรือปฏิเสธ และฝ่ายการเงินทำเครื่องหมายว่าได้รับชำระ มันดูเรียบง่าย และด้วย AI คุณสามารถสร้างหน้าจอและ endpoint ได้เร็ว ส่วนที่ชะลอคุณคือความจริงเดิม: กฎ ไม่ใช่การพิมพ์

เริ่มจากการเขียนขั้นต่ำที่ต้องถูกต้อง ถ้าคุณอธิบายเป็นคำธรรมดาไม่ได้ คุณทดสอบไม่ได้

คำจำกัดความเวอร์ชันแรกที่เข้มงวดมักเป็นแบบนี้: ฟิลด์ (title, requester, department, amount, reason, status, timestamps); บทบาท (requester, approver, finance, admin); สถานะ (draft, submitted, approved, rejected, paid). แล้วระบุการเปลี่ยนสถานะที่สำคัญ: มีเพียง approver เท่านั้นที่เปลี่ยน submitted เป็น approved หรือ rejected; มีเพียง finance เท่านั้นที่เปลี่ยน approved เป็น paid

ใช้ AI ในลำดับที่ควบคุมได้เพื่อจับข้อผิดพลาดแต่ต้น:

1. กำหนดสคีมาฐานข้อมูลและ enum สถานะก่อน
2. สร้าง endpoint รอบการเปลี่ยนสถานะ (submit, approve, reject, pay) ไม่ใช่ route generic update-anything
3. สร้าง UI เป็นขั้นสุดท้าย ตามที่ API อนุญาต

การทดสอบที่มีค่าสูงสุดไม่ใช่ว่า "หน้าโหลดได้หรือไม่" แต่เป็นการเช็กสิทธิ์และการเปลี่ยนสถานะ พิสูจน์ว่า requester ไม่สามารถอนุมัติคำขอของตัวเอง approver ไม่สามารถมาร์กเป็นจ่ายได้ คำขอที่ถูกปฏิเสธจ่ายไม่ได้ และ (ถ้าเป็นกฎของคุณ) ยอดไม่สามารถแก้ไขหลังส่งได้

สิ่งที่ใช้เวลานานที่สุดคือการชัดเจนในกรณีขอบ ผู้อนุมัติเปลี่ยนใจหลังปฏิเสธได้ไหม ถ้าสองผู้อนุมัติคลิกอนุมัติพร้อมกันจะเกิดอะไรขึ้น ฝ่ายการเงินต้องการจ่ายบางส่วนไหม AI สามารถสร้างโค้ดตามคำตอบใดๆ ที่คุณเลือก แต่ไม่สามารถเลือกคำตอบให้คุณ ความถูกต้องมาจากการตัดสินใจเหล่านั้น แล้วบังคับให้โค้ดทำตาม

เช็กลิสต์ด่วนก่อนปล่อยการเปลี่ยนที่สร้างโดย AI

AI สร้างโค้ดได้เร็ว แต่ไมล์สุดท้ายยังคงเป็นงานมนุษย์: พิสูจน์ว่ามันทำอย่างที่คุณตั้งใจ และล้มอย่างปลอดภัยเมื่อไม่ใช่

ก่อนเช็กรายการ ให้เลือกคำจำกัดความ "เสร็จ" เล็กที่สุดที่สำคัญ สำหรับฟีเจอร์เล็กๆ อาจเป็นทางผ่านเดียว สองทางล้มเหลว และการอ่านความเข้าใจไว้อย่างรวดเร็ว สำหรับการชำระเงินหรือ auth ยกระดับมาตรฐาน

ห้าเช็ค

• ข้อกำหนดทุกข้อสามารถตรวจสอบได้ สำหรับแต่ละข้อ คุณมีเทสต์หรือการตรวจสอบด้วยมือชัดเจนเป็นประโยคเดียว ถ้าคุณอธิบายวิธีตรวจสอบไม่ได้ คุณอาจไม่เข้าใจสิ่งที่สร้าง
• การล้มเหลวถูกจัดการและอธิบาย ลองกรณีข้อผิดพลาดสำคัญ (อินพุตไม่ถูก, ขาดสิทธิ์, เครือข่ายล้ม, ฐานข้อมูลว่าง) ให้แน่ใจว่าแอปแสดงข้อความที่เป็นประโยชน์และไม่รั่วไหลข้อมูลละเอียดอ่อน
• การออกแบบยังคงเรียบง่าย ถ้า AI เพิ่ม helper, abstraction หรือ pattern ฉลาดๆ ถาม: คุณจะเก็บมันไว้ถ้าคุณเขียนเองไหม? ลบเลเยอร์เกินความจำเป็น
• ผู้ตรวจทานใหม่ตามอ่านได้ สมมติว่าผู้ตรวจทานไม่ได้ดูเซสชันแชท โค้ดควรอ่านราวกับเรื่อง: ชื่อชัด ฟังก์ชันสั้น และโน้ตสั้นว่าทำไมเปลี่ยนแปลงนี้ถึงมีอยู่
• คุณย้อนกลับได้อย่างปลอดภัย รู้ว่า "กลับสู่สภาวะปกติ" คืออะไร จับเวอร์ชันที่รู้ว่าดีและยืนยันว่าคุณย้อนกลับได้อย่างรวดเร็วถ้าโปรดักชันทำงานต่างไป

ตัวอย่างสั้นๆ

สมมติ AI เพิ่ม "เชิญผู้ใช้จำนวนมาก" ในหน้าผู้ดูแล เส้นทางปกติทำงาน แต่ความเสี่ยงคือกรณีขอบ: อีเมลซ้ำ ความล้มเหลวแบบบางส่วน และข้อจำกัด rate A การตัดสินใจส่งที่แข็งแรงอาจเป็นเทสต์อัตโนมัติหนึ่งรายการสำหรับการซ้ำ แบบตรวจด้วยมือหนึ่งรายการสำหรับข้อความในกรณีล้มเหลวบางส่วน และแผนย้อนกลับ

ขั้นตอนถัดไป: เพิ่มเกราะกัน แล้วขยายกระบวนการของคุณ

เมื่อโค้ดถูกทำให้ถูก ความเสี่ยงย้ายไปที่คุณภาพการตัดสินใจ: คุณขออะไร คุณยอมรับอะไร และคุณส่งอะไร วิธีที่เร็วที่สุดที่จะทำให้ข้อเท็จจริงเหล่านี้ได้ผลในการทำงานด้วย AI คือเพิ่มเกราะกันที่ป้องกันการเปลี่ยนแปลง "เกือบถูก" ไหลผ่าน

เริ่มด้วยสเปคหน้ากระดาษสำหรับฟีเจอร์ถัดไป รักษาให้ชัด: ใครใช้ มันทำอะไร ไม่ทำอะไร และชุดการทดสอบการยอมรับเป็นภาษาธรรมดา หลักการรับ/ปฏิเสธเหล่านี้จะเป็นสมอเมื่-AI แนะนำทางลัดที่ล่อใจ

ชุดเกราะที่ขยายได้โดยไม่เพิ่มกระบวนการหนามาก:

• ทำให้การเปลี่ยนเล็กพอที่ตรวจทานได้ในไม่กี่นาที ไม่ใช่ชั่วโมง
• ต้องมีเทสต์ (หรืออย่างน้อยโน้ตกการทดสอบ) สำหรับทุกการเปลี่ยนพฤติกรรม
• ใช้เทมเพลตพรอมท์มาตรฐาน: ข้อจำกัด สไตล์การเขียนโค้ด และความคาดหวังการทดสอบ
• เตรียมทางย้อนกลับที่เชื่อถือได้สำหรับทุกการดีพลอย
• ติดตามสิ่งที่ไม่รู้ในฐานะ TODO ชัดเจน ไม่ใช่สมมติฐานที่ซ่อนอยู่

พรอมท์เป็นส่วนหนึ่งของกระบวนการของคุณแล้ว ตกลงสไตล์บ้าน: ไลบรารีที่อนุญาต การจัดการข้อผิดพลาด ความหมายของ "เสร็จ" และเทสต์ที่ต้องผ่าน หากพรอมท์ใช้ซ้ำไม่ได้กับเพื่อนร่วมงาน มันอาจคลุมเครือเกินไป

ถ้าคุณชอบวิธีสร้างเว็บ backend และแอปมือถือแบบแชทเป็นหลัก Koder.ai เป็นตัวอย่างหนึ่งของแพลตฟอร์มที่มี vibe-coding ซึ่ง planning mode, snapshots, และการส่งออกซอร์สโค้ดสามารถสนับสนุนเกราะกันเหล่านี้ เครื่องมือนั้นช่วยเร่งร่าง แต่ระเบียบวินัยต่างหากที่ทำให้มนุษย์ยังคุมความถูกต้องอยู่