Copilot เขียนมันแล้ว แต่ใครเป็นเจ้าของ? ช่องว่างด้านการกำกับดูแลที่ทีมวิศวกรรมอาจมองข้าม

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

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

AI และการเขียนโค้ดกำลังกลายเป็นสิ่งที่หลีกเลี่ยงไม่ได้

เครื่องมือการเขียนโค้ดด้วย AI กำลังได้รับความสนใจอย่างรวดเร็วและก้าวเข้าสู่การพัฒนาหลักตามกระแส ตามผลสำรวจ 2025 Stack Overflow Developer Survey, 84% ของผู้ตอบแบบสอบถามใช้หรือกำลังวางแผนใช้เครื่องมือ AI ในกระบวนการพัฒนาของตน

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

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

AI กำลังทำลายความสัมพันธ์ระหว่างชั่วโมงทำงานและผลผลิต

ค่าตอบแทนสำหรับการพัฒนาซอฟต์แวร์เคยอิงอยู่บนสมมติฐานว่าผลผลิตของวิศวกรรมสัมพันธ์อย่างใกล้ชิดกับความพยายามของวิศวกรรม อย่างไรก็ตาม AI สร้างสรรค์ตอนนี้ทำให้สมการนี้ซับซ้อนยิ่งขึ้น

การทดลองที่ควบคุมโดยมีนักพัฒนาจำนวน 95 คนพบว่าผู้เข้าร่วมที่มีการเข้าถึง GitHub Copilot สามารถทำภารกิจเซิร์ฟเวอร์ HTTP JavaScript เฉพาะได้ เร็วกว่า 55.8% เมื่อเทียบกับผู้ที่ไม่มีการเข้าถึง

สิ่งนี้ชี้ให้เห็นว่า AI สามารถเร่งการพัฒนาได้โดยอาจไม่เสียคุณภาพ แต่ตัวเลขเหล่านี้สำเร็จเพราะการทดลองใช้ภารกิจการเขียนโปรแกรมที่เฉพาะเจาะจง แม้ว่างานจะเสร็จเร็วขึ้น ไม่ได้หมายความว่า Copilot ทำให้ทั้งองค์กรวิศวกรรมเพิ่มประสิทธิภาพขึ้น 55.8%

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

มีหลักฐานเพิ่มเติมว่า AI ทำให้เวลาเขียนโค้ดช้าลง การศึกษาแบบสุ่มโดย randomized study by METR ที่รวมนักพัฒนาโอเพนซอร์สที่มีประสบการณ์ 16 คนซึ่งทำงานบนปัญหาจริง 246 รายการในคลังที่พวกเขารู้จักดี โดยใช้เครื่องมือที่มีในต้นปี 2025 รวมถึง Claude Sonnet 3.5 และ 3.7 และ Cursor Pro พวกเขาใช้เวลานานกว่างานประมาณ 19% แม้ว่าหลายคนจะคาดว่าเครื่องมือเหล่านี้จะช่วยประหยัดเวลา

โดยรวม การศึกษาต่างๆ เหล่านี้ทำลายความคาดหวังว่า AI จะทำให้นักพัฒนาทำงานได้เร็วขึ้น แต่จริงๆ แล้วมันทำให้เวลาและคุณค่าของนักพัฒนานั้นคาดเดาได้ยากขึ้นสำหรับธุรกิจที่ให้บริการเว็บและสำหรับลูกค้าที่รับบริการ

ปัญหาการกำหนดราคา ที่ไม่มีใครพูดถึง

Time & Material (T&M) เป็นโมเดลที่พบทั่วไปในงานพัฒนาเว็บสำหรับการซื้อซอฟต์แวร์ เนื่องจากมันตอบโจทย์ปัญหาอุตสาหกรรมที่เกิดซ้ำ: โครงการที่พัฒนาอย่างต่อเนื่อง

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

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

วิธีแก้ไม่ได้อยู่ที่การกระตุ้นให้นักพัฒนาทำงานช้าลง โมเดล T&M ตอนนี้เผชิญกับปัญหาโครงสร้างเกี่ยวกับการออกแบบราคาและแรงจูงใจ การใช้ค่าแรงต่อชั่วโมงเพื่อกำหนดคุณค่าอาจจำกัด ผู้ซื้ออาจรู้ว่าชั่วโมงวิศวกรรมหนึ่งชั่วโมงมีค่าใช้จ่ายเท่าไหร่ แต่ยังไม่แน่ใจเกี่ยวกับการลงทุนทั้งหมดที่จำเป็นเพื่อให้ได้ผลลัพธ์ที่ต้องการ

เมื่อ AI เปลี่ยนประสิทธิภาพของวิศวกรรม คำถามอาจเปลี่ยนจาก:

“ชั่วโมงของนักพัฒนามีค่าใช้จ่ายเท่าไหร่?” → “ค่าของสิ่งนั้นจะเป็นอย่างไรเมื่อต้องการชั่วโมงของนักพัฒนาน้อยลง?”

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

ช่องว่างด้านการกำกับดูแลมีเจ้าของสี่ฝ่าย

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

มีอย่างน้อยสี่ประเภทของการเป็นเจ้าของที่องค์กรวิศวกรรมควรกำหนด

1. ใครเป็นเจ้าของโค้ด?

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

2. ใครเป็นเจ้าของความเสี่ยง?

โค้ดที่เร็วขึ้นมีคุณค่าเฉพาะเมื่อไม่ก่อให้เกิดปัญหาในที่อื่น การศึกษาเชิงประจักษ์เกี่ยวกับโค้ดที่สร้างโดย AI empirical study of AI-generated code พบว่ามีช่องโหว่ด้านความปลอดภัยใน 29.5% ของส่วนย่อย Python ที่ตรวจสอบและ 24.2% ของส่วนย่อย JavaScript งานวิจัยยังระบุช่องโหว่ที่ครอบคลุม 43 หมวดหมู่ของ Common Weakness Enumeration

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

NIST’s SP 800-218A สะท้อนหลักการนี้โดยขยาย Secure Software Development Framework ด้วยแนวปฏิบัติที่ดีที่สุดที่จัดการกับ AI สร้างสรรค์และโมเดลพื้นฐานแบบใช้สองประการ

3. ใครเป็นเจ้าของผลกำไรจากประสิทธิภาพ?

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

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

4. ใครเป็นเจ้าของการจัดลำดับความสำคัญ?

AI สามารถทำให้การสร้างฟีเจอร์เป็นเรื่องที่ถูกและเร็วขึ้น แต่ไม่สามารถตัดสินได้ว่าฟีเจอร์เหล่านั้นจำเป็นหรือไม่

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

การกำกับดูแล AI กำลังกลายเป็นประเด็นทางการเงิน

คำถามเหล่านี้ทำให้การกำกับดูแล AI มีความสำคัญมากขึ้น ลองนึกภาพพันธมิตรการพัฒนาสองฝ่ายที่เรียกเก็บอัตราต่อชั่วโมงคล้ายกัน

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

ผู้ซื้อจะต้องประเมิน:

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

T&M ยังสามารถเป็นประโยชน์ต่อทั้งสองฝ่ายได้ หากพวกเขายอมรับความไม่แน่นอนในบริการอย่างรู้ตัว การจัดทำสัญญาราคาแบบคงที่ก็สามารถทำงานได้เมื่อความต้องการและผลลัพธ์มีความเสถียร

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

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

การสนทนา AI เดียวกัน

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

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

แต่มีคำถามการเป็นเจ้าของครั้งที่สองที่อาจมีผลกระทบต่องบประมาณเทคโนโลยีอย่างมาก: ใครเป็นเจ้าของคุณค่าที่สร้างหรือสูญเสียเมื่อ AI เปลี่ยนความเร็วในการสร้างซอฟต์แวร์

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

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