ปัญญาประดิษฐ์สำหรับทีมซอฟต์แวร์: รูปแบบการทำงานและขีดจำกัด

กำไร:

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

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

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

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

ผู้ช่วยเขียนโค้ดทำอะไรได้จริง?

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

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

แผนที่จุดแข็งและจุดอ่อน

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

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

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

ประเภทภารกิจ

บทบาทของเอไอ

บทบาทของผู้ชาย

ผลิตสำเร็จรูป/โครงกระดูก

ผลิตร่าง

ดัดแปลง, วิจารณ์

คำอธิบายรหัส

ให้การสรุปอย่างรวดเร็ว

ตรวจสอบส่วนที่วิกฤตในโค้ด

การทดสอบการเขียน

กรณีแนะนำ

ยืนยันความครอบคลุมและความถูกต้อง

ตรรกะที่มีความสำคัญต่อความปลอดภัย

ความคิดที่เป็นประโยชน์

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

การใช้ API/ไลบรารี

สร้างตัวอย่าง

ตรวจสอบการมีอยู่และเวอร์ชัน

การตัดสินใจทางสถาปัตยกรรม

ประเภทของตัวเลือก

เลือกและปกป้องการรู้บริบท

ทีละขั้นตอน: วงจรการทำงานขั้นพื้นฐาน

1. ชี้แจงภารกิจ. หากคุณไม่สามารถเขียนสิ่งที่คุณต้องการในประโยคเดียว โมเดลก็ไม่สามารถเขียนได้ ความไม่แน่นอนที่เกิดขึ้นก่อนหน้านี้จะซึมเข้าสู่อินพุต ยิ่งมีมากขึ้นในเอาท์พุต
2. ให้บริบท เพิ่มรหัสที่เกี่ยวข้อง ข้อความแสดงข้อผิดพลาดแบบเต็ม เวอร์ชันภาษา/เฟรมเวิร์ก และข้อจำกัดในพรอมต์ อย่าพูดว่า "แก้ไขปัญหานี้" ให้พูดว่า "Python 3.11, FastAPI 0.110 ฟังก์ชันนี้ให้ข้อผิดพลาด 500 รายการ และจะระเบิดเมื่อเนื้อหาคำขอว่างเปล่า"
3. บทบาทและรูปแบบการจัดเก็บภาษี เฟรมเวิร์กเช่น "คุณเป็นนักพัฒนา Go อาวุโส เพียงให้โค้ดและเหตุผลสองประโยค" จะเน้นที่ผลลัพธ์
4. ขอเล็กๆ. แบ่งมันออกเป็นขั้นตอนมากกว่าการร้องขอครั้งใหญ่ ตรวจสอบแต่ละขั้นตอนแยกกัน การเปลี่ยนแปลงที่สำคัญมีความเสี่ยงเนื่องจากตรวจสอบได้ยากและมีแนวโน้มที่จะซ่อนข้อผิดพลาด
5. ตรวจสอบ. เรียกใช้ ทดสอบ อ่านด้วยภาพ รหัส AI ที่ไม่ได้รับการยืนยันเป็นเพียง "ภาพร่าง" ไม่ใช่ "วิธีแก้ปัญหา" นี่เป็นขั้นตอนที่ไม่สามารถต่อรองได้มากที่สุดของวงจร

มินิเคสสามอัน

กรณีที่ 1 — การประหยัดเวลาทำได้จริงแต่ทำได้เพียงเล็กน้อย เมื่อทีมสร้างจุดสิ้นสุด CRUD ใหม่ (สร้าง-อ่าน-อัปเดต-ลบ) ด้วย AI เวลาร่างครั้งแรกจะลดลงจากประมาณ 40 นาทีเหลือ 8 นาที อย่างไรก็ตาม จากการทบทวนและการทดสอบ ใช้เวลาทั้งหมด 25 นาที ดังนั้นกำไรที่แท้จริงคือจาก 40 เป็น 25 ประมาณ 38% อัตรานี้วัดแทนความคาดหวังว่า "เราเร่งความเร็วได้ 10 เท่า" ถือเป็นกำไรที่ยั่งยืน

กรณีที่ 2 — อาการประสาทหลอนมีค่าใช้จ่ายสูง นักพัฒนาใช้การร้องขอที่ AI แนะนำ request.get_json() โดยไม่มีการตรวจสอบความถูกต้อง ไม่มีวิธีการดังกล่าว (แม่นยำ response.json()) เสียเวลาไป 20 นาทีเมื่อโค้ดไม่ได้คอมไพล์ ง่ายๆ ก็คือ "วิธีนี้มีอยู่จริงหรือเปล่า" การยืนยันจะรีเซ็ตการสูญเสีย

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

เทมเพลตที่คัดลอกได้สี่แบบ

พร้อมท์การเริ่มต้นใช้งานทั่วไปที่มีประสิทธิภาพ:

บทบาท: คุณเป็นนักพัฒนา {{ภาษา}} ที่มีประสบการณ์ งาน: {{what_want}}บริบท:- กรอบงาน/เวอร์ชัน: {{framework_and_version}}- ข้อจำกัด: {{ประสิทธิภาพ, สไตล์, กฎการพึ่งพา}}กฎ:- ห้ามใช้ไลบรารี/ฟังก์ชันที่ไม่มีอยู่จริง; หากคุณไม่แน่ใจ ให้ทำเครื่องหมายว่า "ยืนยัน" - ขั้นแรก ให้แผนสั้นๆ จากนั้นให้เขียนโค้ด จากนั้นให้เหตุผล 2 ประโยค - สร้างรหัสที่ใช้งานได้และทดสอบได้

หากต้องการกรองความไม่แน่นอนกลับเข้าไปในโมเดล:

ก่อนที่จะแก้ไขปัญหาด้านล่าง ให้ระบุคำถามอย่างน้อย 3 ประเด็นที่คุณพบว่าขาดหายไปหรือไม่ชัดเจน อย่าเขียนโค้ดก่อนที่ฉันจะตอบกลับ งาน: {{task}}

หากต้องการให้ตรวจสอบเอาต์พุตด้วยตนเอง:

คุณได้ผลิตรหัสต่อไปนี้ ตอนนี้เปลี่ยนบทบาทของคุณและวิจารณ์โค้ดนี้:- ทำรายการ 3 กรณี (edge ​​case) ที่อาจใช้งานไม่ได้- มี API/ฟังก์ชันใดบ้างที่คุณสามารถสร้างขึ้นมาได้ Mark.- ให้เวอร์ชั่นที่แก้ไขแล้ว รหัส:{{code}}

หากต้องการแยกการตัดสินใจออกเป็นตัวเลือก:

แนะนำวิธีแก้ปัญหา 2-3 แนวทางสำหรับ {{problem}} สำหรับแต่ละรายการ: คำอธิบายสั้นๆ บวก/ลบ เมื่อเลือก ให้ในรูปแบบตาราง อย่าเลือกสำหรับฉัน เพียงแค่ชี้แจงตัวเลือก

พรอมต์อ่อน / พรอมต์แข็งแกร่ง

จุดอ่อน: "แก้ไขข้อบกพร่องในโค้ดนี้" (ข้อผิดพลาดใด ภาษาใด ลักษณะการทำงานที่คาดหวังคืออะไร)

แข็งแกร่ง: "Python 3.11 / FastAPI 0.110 จุดสิ้นสุดต่อไปนี้ส่งคืน 500 พร้อม KeyError เมื่อเนื้อหาคำขอว่างเปล่า ฉันต้องการให้ส่งคืน 400 และข้อความที่มีความหมายบนเนื้อหาว่างเปล่า ขั้นแรกให้อธิบายเหตุผล จากนั้นให้ฟังก์ชันที่แก้ไข จากนั้นจึงเขียนการทดสอบสำหรับสถานการณ์นี้ [รหัส]"

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

ข้อผิดพลาดทั่วไป

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

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

โดยสรุป

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

งานสมัคร

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

รายการตรวจสอบ

• [ ] ฉันตระหนักว่า LLM สร้างรูปแบบ ไม่ใช่โค้ดที่ "เข้าใจ"
• [ ] ฉันสามารถอธิบายแนวคิดของโทเค็น หน้าต่างบริบท และพรอมต์ได้ในประโยคเดียว
• [ ] ฉันสามารถแยกแยะระหว่างประเภทของงานที่ AI แข็งแกร่งและอ่อนแอได้
• [ ] ฉันรู้ว่าอาการประสาทหลอนคืออะไร และยาแก้พิษเพียงอย่างเดียวคือการตรวจสอบ
• [ ] ฉันปรับวงจร "เสนอ จัดทำ ตรวจสอบ" ให้เข้ากับงานของตัวเอง
• [ ] ฉันสามารถแสดงความแตกต่างระหว่างพร้อมท์ที่ชัดเจนและพร้อมท์ที่อ่อนแอได้ในตัวอย่างที่เป็นรูปธรรม