อนาคตของการสร้างแอป AI ขึ้นอยู่กับความปลอดภัยของประเภท

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

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

ปัญหาแรงจูงใจ

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

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

สองประเภทของข้อผิดพลาด

เมื่อ โค้ดที่สร้างโดย AI ทำงาน คุณมักจะเห็นสองประเภทของปัญหาความปลอดภัยของประเภท:

1. ข้อผิดพลาดในการคอมไพล์

• สิ่งที่เกิดขึ้น: คอมไพล์เลอร์จับข้อผิดพลาดระหว่างประเภทที่ประกาศและค่าที่ส่งเข้ามา
• วิธีการแก้ไขของมนุษย์: ตัดสินว่าผู้เรียกใช้หรือฟังก์ชันซิกเนเจอร์เป็นคนผิด (แปลง 42 เป็น string หรือเปลี่ยนฟังก์ชันซิกเนเจอร์ให้รับ number เป็นต้น)
• วิธีการแก้ไขของ AI : เปลี่ยนประเภทของอาร์กิวเมนต์เป็น any ปัญหา “แก้ไข” แล้ว แต่คุณเพิ่งลบรางกั้นที่จะจับข้อผิดพลาดในอนาคต

2. ข้อผิดพลาดในการทำงาน

• สิ่งที่เกิดขึ้น: คอมไพล์เลอร์คิดว่าทุกอย่างดี (มักเนื่องจากประเภทถูกลดความเข้มงวด) แต่ค่าจริงในขณะทำงานไม่ตรงกับความคาดหวัง
• วิธีการแก้ไขของมนุษย์: ตรวจสอบตัวแปรย้อนกลับไปที่ต้นกำเนิด (เช่น API หรือการคิวรีฐานข้อมูล) และแก้ไขประเภทที่ขอบเขตเพื่อให้ข้อมูลมาเป็น string ที่เหมาะสม
• วิธีการแก้ไขของ AI : ไม่มีข้อมูลบริบท AI จะเดา บางทีมันอาจห่อทุกอย่างด้วย String(…) หรือเพิ่มประเภทให้กว้างขึ้น ข้อผิดพลาดจะหายไปในจุดนี้ แต่ตรรกะจะถูกทำลาย Number ที่ตั้งใจไว้สำหรับเลขคณิตจะกลายเป็น string ไป

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

ฐานข้อมูลคูณ

เมื่อคุณเชื่อมต่อกับฐานข้อมูล ข้อผิดพลาดจะเพิ่มขึ้นและต้นตอของมันจะยากต่อการตรวจสอบ SQL มีการกำหนดประเภทเนื่องจากเหตุผล

เมื่อ AI แปลงทุกอย่างเป็น string | any คุณจะสูญเสียการรับประกันเหล่านั้น:

• การเขียนที่ไม่ดี: การแทรก “true” ลงในฟิลด์บูลีนจะคอมไพล์ได้ แต่ทำลายฐานข้อมูล
• การอ่านข้อมูลที่ไม่ดี: คิวรี่ส่งคืน NULL แต่ AI คาดว่าจะเป็น string ทำให้เกิดข้อผิดพลาดในการทำงาน
• ความสัมพันธ์ที่เสียหาย: หากคีย์สัมพันธ์ถูกคาดหวังเป็น UUID แต่ AI รับมันเป็น string และส่งค่าขยะโดยไม่ตั้งใจ การเข้าร่วมจะไม่ล้มเหลว แต่จะไม่มีข้อมูลกลับมา ทำให้ปัญหาหลบซ่อนจนกว่าจะปรากฏตัวในภายหลังในรูปแบบของผลลัพธ์ที่ไม่สอดคล้องกันหรือไม่สมบูรณ์..

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

ทำไมทีมงานที่มีความรับผิดชอบจึงบังคับใช้การกำหนดประเภทอย่างเข้มงวด

การกำหนดประเภทอย่างเข้มงวดไม่ใช่เรื่องของการชะลอการพัฒนา แต่เป็นเรื่องของการทำให้การขยายขนาดเป็นไปได้

ประเภท:

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

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

วิธีบังคับ AI ให้เข้าไปในความปลอดภัยของประเภท

คุณต้องปฏิบัติต่อ AI เหมือนนักพัฒนาจูเนียร์ มีพรสวรรค์ แต่ไม่ระมัดระวังหากไม่มีการกำกับ

ให้ข้อมูลบริบทที่ถูกต้อง

ให้ AI มีインタ์เฟซและประเภทที่สามารถใช้ได้ ให้ตัวอย่างการใช้งาน และมีความคิดเห็นเกี่ยวกับวิธีการจัดโครงสร้างโค้ดที่ถูกต้อง

สั่งให้ AI ใช้ประเภทที่ถูกต้อง

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

บังคับใช้ด้วยการตรวจสอบโค้ด

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

ปรับปรุงด้วยการตรวจสอบ

ข้อผิดพลาดในการคอมไพล์ การบันทึกการทำงาน การทดสอบคลิกผ่าน แต่ละรอบบังคับให้ AI ต้องทำให้ประเภทเข้มงวดขึ้นและเข้าใกล้โค้ดที่มีคุณภาพการผลิต

วิธีการสร้างที่ดีกว่า

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

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

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