Kristin Isaac, CEO และผู้ร่วมก่อตั้ง Strudel – สัมภาษณ์系列

Kristin Isaac, CEO และผู้ร่วมก่อตั้ง Strudel เป็นผู้นำด้านเทคโนโลยีระดับองค์กรที่มีประสบการณ์ยาวนาน โดย曾ดำรงตำแหน่งระดับสูงใน LinkedIn, Udemy, ESPN และ Disney ก่อนที่จะก่อตั้ง Strudel เธอมุ่งเน้นในการแก้ไขจุดเสียขององค์กรซอฟต์แวร์: ช่องว่างระหว่างการสนับสนุนลูกค้าและการพัฒนา ซึ่งที่ Strudel เธอกำลังสร้างแพลตฟอร์มที่ขับเคลื่อนด้วย AI เพื่อช่วยให้ทีมสนับสนุนเทคนิคแก้ไขปัญหาเชิงซ้อนได้เร็วขึ้นโดยการเชื่อมต่อคำขอสนับสนุนโดยตรงกับข้อมูลเชิงลึกด้านวิศวกรรม ประสบการณ์ของเธอในการขยายทีม การสร้างกลยุทธ์การตลาด และการขับเคลื่อนการเติบโตในองค์กรระดับโลกได้ช่วย塑造การเติบโตเร็วในระยะแรกและตำแหน่งที่แข็งแกร่งของ Strudel ในตลาด AI ระดับองค์กรและเครื่องมือสำหรับนักพัฒนา

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

คุณเคยดำรงตำแหน่งผู้นำในองค์กรต่างๆ เช่น LinkedIn, Udemy และ Disney ก่อนที่จะก่อตั้ง Strudel ในปี 2025 ประสบการณ์ใดจากตำแหน่งเหล่านั้นที่ทำให้คุณเชื่อว่าทีมวิศวกรรมต้องการแพลตฟอร์ม “ข้อมูลเชิงลึกด้านวิศวกรรม” ที่ขับเคลื่อนด้วย AI และวิธีการที่ข้อมูลเชิงลึกนั้นช่วยในการก่อตั้ง Strudel?

ทุกองค์กรที่ผมทำงานด้วยมี版本ของปัญหาเดียวกัน ที่ Disney มีผลกระทบอย่างมาก – หากแพลตฟอร์มสตรีมมิ่งหยุดทำงานระหว่างการเปิดตัวครั้งสำคัญ มันไม่ใช่แค่ผลกระทบทางการเงิน แต่เป็นช่วงเวลาของแบรนด์ ที่ LinkedIn มีการขยายตัวอย่างไม่หยุดนิ่ง มีบริการหลายพันบริการที่สร้างเสียงรบกวน และแม้ทีมที่ดีที่สุดก็ยังต้องดิ้นรนเพื่อรักษาความต่อเนื่อง ที่ Udemy ผมเห็นทีมเล็กๆ ทำสิ่งที่น่ากลัวด้วยเครื่องมือที่จำกัด

สิ่งที่เชื่อมโยงทั้งสามและประสบการณ์ของผู้ร่วมก่อตั้ง Shai Rubin และ Brian Kaufman ในการเป็นผู้นำทีมวิศวกรรมคือว่าวิศวกรใช้เวลามากในการสร้างบริบทมากกว่าการแก้ปัญหาจริงๆ เมื่อมีคนถูกเรียกในเวลา 2 นาฬิกา และก่อนที่พวกเขาจะเริ่มวิเคราะห์ปัญหา พวกเขากำลังตรวจสอบข้อความใน Slack, แดชบอร์ด, ตั๋ว Jira, ล็อกการ_deploy – เพียงเพื่อพยายามเข้าใจว่าอะไรเปลี่ยนแปลงและเมื่อไหร่ พวกเขากำลังเล่นเป็นนักสืบก่อนที่จะทำงานจริงๆ นั่นคือการเสียเวลาไปกับคนมีพรสวรรค์อย่างมาก

ผมคิดว่ามีวิธีที่ฉลาดกว่าในการนำสิ่งที่สำคัญจริงๆ มาให้เห็นเมื่อถึงเวลา นั่นคือเมล็ดพันธุ์ของ Strudel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ลองนึกถึงความแตกต่างระหว่างเครื่องตรวจจับควันและผู้สืบสวนไฟ การตรวจสอบและ AIOps เป็นเครื่องตรวจจับควัน – สิ่งจำเป็น แต่พวกมันหยุดอยู่ที่การแจ้งเตือน ข้อมูลเชิงลึกด้านวิศวกรรมคือสิ่งที่เกิดขึ้นต่อมา: นี่คือสิ่งที่เกิดขึ้น นี่คือเหตุผล และนี่คือจุดเริ่มต้น

ตัวแทน AI กำลังถูกนำไปใช้เพิ่มมากขึ้นเพื่อทำให้กระบวนการทางเทคนิคที่ซับซ้อนเป็นแบบอัตโนมัติ คุณเห็นบทบาทของตัวแทน AI ในการวินิจฉัยและแก้ไขเหตุการณ์软件ในอีก 5 ปีหน้าอย่างไร?

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

ในอีก 5 ปีหน้า ผมคิดว่าตัวแทนจะรับหน้าที่ในการทำงานซ้ำๆ การจับคู่รูปแบบ การรวบรวมบริบท – สิ่งที่สำคัญแต่ไม่ใช่สิ่งที่วิศวกรระดับสูงควรใช้เวลาของพวกเขา นั่นจะปลดปล่อยให้คนมุ่งเน้นไปที่ปัญหาที่ซับซ้อน ตัดสินใจด้านสถาปัตยกรรม และสิ่งที่ต้องการการตัดสินใจของมนุษย์จริงๆ

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

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

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

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

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

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

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

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

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

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

สิ่งที่ผมรู้สึกอย่างแรงที่สุดในเรื่องนี้คือ: มนุษย์ควรตรวจสอบโค้ดที่เข้าไปในผลิต

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

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

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

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

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

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

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

ขอขอบคุณสำหรับการสัมภาษณ์ที่ดี ผู้อ่านสามารถเรียนรู้เพิ่มเติมได้ที่ Strudel