ช่องว่างนั้นมีอยู่เสมอ AI ทำให้มันกว้างขึ้น.

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

ในขณะนั้น ฉันกำลังคิดถึงการแผ่ขยายของ SaaS ไม่ใช่โค้ดที่สร้างโดย AI แต่วันนี้ปรัชญาของฉันยิ่งเร่งด่วนและสำคัญยิ่งต่อการยืนหยัด.

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

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

ช่องว่างนั้นมีอยู่เสมอ AI ทำให้มันกว้างขึ้น.

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

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

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

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

มีข้อคัดค้านที่สมเหตุสมผลที่นี่. รายงาน ROI ของ DORA 2026 อธิบายถึงรูปแบบ J-curve: การลดลงของผลิตภาพทันทีหลังการนำไปใช้ ซึ่งเกิดจากเส้นโค้งการเรียนรู้ ค่าใช้จ่ายในการตรวจสอบโค้ดที่สร้างโดย AI และกระบวนการต่อเนื่องที่ยังไม่ทัน พวกเขาเรียกมันว่า “ค่าใช้จ่ายการเรียนรู้” ของการเปลี่ยนแปลง และเตือนผู้นำไม่ให้สับสนกับความล้มเหลว นั่นก็พอเข้าใจได้ แต่ค่าใช้จ่ายการเรียนรู้และปัญหาจริงดูเหมือนกันบนแดชบอร์ดที่สร้างจากตั๋ว หากคุณไม่สามารถบอกได้ว่าคุณอยู่ในสถานะใด คุณก็ไม่ได้อดทน คุณกำลังเดา.

เราต้องกลับไปสู่พื้นฐาน รู้จักตัวเอง รู้จักทีมของคุณ รู้ว่าปัญหาอะไรที่คุณกำลังแก้ไข.

คุณจะ “รู้จักตัวเอง” ด้วย AI อย่างไร?

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

จุดบอด 1: การแสดงความเร็ว

คอมมิตและ PR ที่เพิ่มขึ้นอาจให้ความรู้สึกว่าเป็นความก้าวหน้า และบ่อยครั้งก็เป็นเช่นนั้น AI ทำให้จำนวนทั้งสองเพิ่มขึ้นโดยอัตโนมัติ. การศึกษา Stanford แสดงให้เห็นว่าการนำ AI มาใช้ทำให้จำนวน PR เพิ่มขึ้น 14% แต่สิ่งที่คุณพลาดคือปริมาณกิจกรรมที่เป็นงานฟีเจอร์ที่ส่งออกได้เทียบกับการบำรุงรักษา การทำซ้ำ หรือการเปลี่ยนแปลงที่ไม่คงที่จากการรีแฟคเตอร์ที่ไม่สำเร็จ.

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

จุดบอด 2: หนี้การตรวจสอบ

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

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

จุดบอด 3: งานที่ซ่อนอยู่

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

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

จุดบอด 4: การเสื่อมคุณภาพ

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

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

จุดบอด 5: การใช้จ่ายที่ยังไม่ได้รับการพิสูจน์

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

สังเกตว่าความพยายามของวิศวกรรมไหลไปที่ฐานโค้ดจริง ๆ อย่างไรในแต่ละไตรมาส — ไม่ใช่ที่แผนงานบอกว่าจะไหลไปที่ไหน. หากไม่มีการเชื่อมโยงนั้น, คุณจะต้องปกป้องงบประมาณของปีถัดไปด้วยเรื่องเล่า, และเรื่องเล่าไม่สามารถยืนหยัดต่อการสนทนาที่เข้มงวดกับ CFO.

เริ่มต้นด้วยสิ่งที่คุณมองไม่เห็น

คำถามของฝ่ายการเงินเกี่ยวกับการใช้จ่ายที่ทำเป็นทุนและหน้าการเรียกใช้งานตอนตี 2 ดูเหมือนจะไม่เกี่ยวข้อง, แต่จริง ๆ แล้วไม่ใช่. ทั้งสองสามารถ “ประมาณการโดยคร่าว ๆ” จากกิจกรรม. แต่ทั้งสองสามารถตอบได้จริง, ด้วยหลักฐาน, จากโค้ดเอง.

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

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