Gautam Korlam, วิศวกรอาวุโสที่ Sonar – ซีรีส์สัมภาษณ์

Gautam Korlam, วิศวกรอาวุโสที่ Sonar, เป็นวิศวกรซอฟต์แวร์อาวุโสและผู้นำด้านเทคโนโลยีที่มีประสบการณ์ยาวนานโดยอาชีพของเขามุ่งเน้นที่โครงสร้างพื้นฐานสำหรับนักพัฒนา, คุณภาพของโค้ด, การทำอัตโนมัติ, และการพัฒนาซอฟต์แวร์ที่ช่วยโดย AI. ก่อนเข้าร่วม Sonar, เขาเป็นผู้ร่วมก่อตั้ง Gitar และดำรงตำแหน่ง CTO, สร้างแพลตฟอร์มที่เป็น AI‑native ที่ออกแบบมาเพื่อทำการตรวจสอบโค้ดอัตโนมัติ, วินิจฉัยความล้มเหลวของการบูรณาการต่อเนื่อง (CI), ระบุสาเหตุรากฐาน, และสร้างการแก้ไข. Sonar ได้เข้าซื้อ Gitar ในเดือนพฤษภาคม 2026, โดย Korlam และทีม Gitar เข้าร่วมบริษัทเพื่อพัฒนาเทคโนโลยีต่อไปเป็นส่วนหนึ่งของแพลตฟอร์มการตรวจสอบโค้ดที่กว้างขวางของ Sonar. ก่อนหน้า Gitar, Korlam ทำงานที่ Uber เกือบหนึ่งทศวรรษ, เริ่มจากวิศวกรผู้ก่อตั้งทีมแพลตฟอร์มมือถือจนถึงตำแหน่งวิศวกรอาวุโส. ระหว่างที่อยู่ที่นั่น, เขาช่วยสร้างและขยายโครงสร้างพื้นฐานศูนย์กลางสำหรับนักพัฒนาของ Uber, นำโครงการ monorepo และระบบการสร้างขนาดใหญ่, พัฒนาสภาพแวดล้อมการพัฒนาระยะไกลและเครื่องมือ CI/CD, และทดลองใช้โมเดลภาษาใหญ่แบบโอเพ่นซอร์สเช่น StarCoder, OctoCoder, และ Code Llama เพื่อปรับปรุงการเขียนโค้ดที่ช่วยโดย AI ภายในฐานโค้ดของ Uber. ประสบการณ์ก่อนหน้านี้ของเขารวมถึงบทบาทวิศวกรรมที่ Lookout และงานวิจัยที่ UC Santa Barbara, รวมถึงการฝึกงานที่ Microsoft และ Oracle.

Sonar เป็นบริษัทซอฟต์แวร์ที่มุ่งเน้นการตรวจสอบโค้ด, การตรวจสอบโค้ดอัตโนมัติ, คุณภาพของโค้ด, และความปลอดภัยของแอปพลิเคชัน. แพลตฟอร์มหลัก SonarQube ของบริษัทวิเคราะห์โค้ดที่เขียนโดยนักพัฒนาและโค้ดที่สร้างโดย AI เพื่อระบุบั๊ก, ช่องโหว่, ปัญหาการบำรุงรักษา, และปัญหาคุณภาพอื่น ๆ ก่อนที่โค้ดจะเข้าสู่การผลิต, โดยมีบริการที่ครอบคลุมคลาวด์, การจัดการด้วยตนเอง, และเวิร์กโฟลว์ในสภาพแวดล้อมการพัฒนาแบบบูรณาการ. Sonar กล่าวว่าเทคโนโลยีของบริษัทถูกใช้โดยนักพัฒนากว่า 7 ล้านคนและลูกค้า 22,000 ราย และวิเคราะห์โค้ดมากกว่า 750 พันล้านบรรทัดต่อวัน. การเข้าซื้อ Gitar ได้ขยายแนวทางนี้ไปสู่การตรวจสอบโค้ดและการแก้ไขที่เป็น AI‑native, ผสานเครื่องยนต์การตรวจสอบของ SonarQube กับเครื่องมือที่มีความสามารถในการตรวจสอบโค้ด, สืบค้นความล้มเหลวของ CI, และเสนอหรือดำเนินการแก้ไขเมื่อการพัฒนาซอฟต์แวร์ก้าวสู่การขับเคลื่อนโดย AI มากขึ้น.

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

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

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

คุณได้อ้างว่าการตรวจสอบโค้ดด้วย AI ควรเสริมการวิเคราะห์เชิงกำหนดแทนที่จะทดแทนมัน. ปัญหาแบบใดที่เหมาะกับการระบุผ่านการวิเคราะห์แบบกฎที่ทำซ้ำได้, และ AI สามารถให้ความสามารถอะไรที่เทคนิคดั้งเดิมทำไม่ได้?

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

สิ่งที่กฎไม่ครอบคลุมคือเจตนา. ไม่มีพาร์เซอร์ใดจะบอกคุณว่าสตริงที่ผู้ใช้มองเห็นอาจทำให้ผู้แปลสับสน, หรือว่าการเปลี่ยนแปลงอ้างว่าปิดตั๋วในขณะที่ทำเพียงครึ่งหนึ่งของที่ตั๋วต้องการ, หรือว่าลูป retry ใหม่ขัดแย้งกับวิธีที่บริการส่วนอื่นจัดการกับ back‑pressure. โมเดลที่อ่าน diff พร้อมกับปัญหาที่เชื่อมโยงและบริบทของฐานโค้ดทั้งหมดจะระบุสิ่งเหล่านั้น, และมันควรปรากฏเป็นผลการค้นหาที่คนตรวจสอบแทนที่จะเป็นคำตัดสิน.

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

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

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

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

Sonar กำลังผสานการตรวจสอบ pull request ที่รับรู้บริบทกับการวิเคราะห์เชิงกำหนดและ quality gates. กระบวนการตรวจสอบหลายชั้นที่มีประสิทธิภาพควรเป็นอย่างไร, และชั้นต่าง ๆ ควรทำงานร่วมกันอย่างไรโดยไม่ทำซ้ำงานหรือทำให้ผู้พัฒนาถูกผลการค้นหามากเกินไป?

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

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

เมื่อเอเจนต์การเขียนโค้ดสร้างโค้ดและ pull request มากขึ้น, การตรวจสอบและการตรวจสอบซอฟต์แวร์อาจกลายเป็นคอขวดใหม่ได้หรือไม่? ส่วนใดของกระบวนการตรวจสอบควรทำอัตโนมัติ, และการตัดสินใจใดควรคงไว้กับวิศวกรที่มีประสบการณ์?

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

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

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

สิ่งสำคัญคือการปฏิเสธการถือสีเขียวเป็นเกณฑ์การยอมรับ, เนื่องจากการสร้างที่ผ่านพ้นบ่งบอกเพียงว่าเทสที่มีอยู่ไม่ได้ล้มเหลว.

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

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

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

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

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

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

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

เมตริกใดที่ผู้นำด้านวิศวกรรมควรใช้เพื่อกำหนดว่าการตรวจสอบโค้ดด้วย AI ปรับปรุงการพัฒนาซอฟต์แวร์จริงหรือไม่? พวกเขาควรให้ความสำคัญกับเวลาในการตรวจสอบ, ข้อบกพร่องที่หลุดออก, อัตรา false‑positive, ความล้มเหลวของ CI, technical debt, ความเชื่อมั่นของนักพัฒนา หรือมาตรการอื่น?

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

จากนั้นตรวจสอบสัญญาณคุณภาพเช่นอัตรา false‑positive และการปฏิเสธ, ปัญหาที่เปิดใหม่, การถดถอยที่เชื่อมโยงกับการเปลี่ยนแปลงที่เพิ่งผสาน, และความคิดเห็นของนักพัฒนาว่าผลการค้นหานั้นสามารถดำเนินการได้หรือไม่. การผสมเมตริกที่เหมาะสมจะแตกต่างตามทีม, แต่คำถามคงที่: เรากำลังลดงานซ้ำและเวลารอการตรวจสอบโดยไม่ลดมาตรฐานของซอฟต์แวร์ที่ปลอดภัยและเชื่อถือได้หรือไม่?

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

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

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

ขอบคุณสำหรับการสัมภาษณ์ที่ยอดเยี่ยม, ผู้อ่านที่ต้องการเรียนรู้เพิ่มเติมควรเยี่ยมชม Sonar.