อาลี-เรซา อัดล์-ทาบาตาบาอี, ผู้ก่อตั้งและซีอีโอของ Gitar – ซีรีส์สัมภาษณ์

อาลี-เรซา อัดล์-ทาบาตาบาอี, ผู้ก่อตั้งและซีอีโอของ Gitar, เป็นผู้นำด้านวิศวกรรมที่มีประสบการณ์ยาวนาน โดยเคยทำงานในบริษัทเทคโนโลยีที่มีอิทธิพลมากที่สุดใน Silicon Valley รวมถึง Uber, Google (GOOGL ), Facebook (META ), Intel (INTC ), AMD และ IBM ก่อนที่จะก่อตั้ง Gitar ในปี 2023 เขาเคยดำรงตำแหน่ง Senior Director of Engineering ที่ Uber โดยช่วยนำทีมในการพัฒนาแพลตฟอร์มสำหรับนักพัฒนา และก่อนหน้านั้นเคยดำรงตำแหน่งผู้นำที่ Google โดยดูแล Site Reliability Engineering สำหรับผลิตภัณฑ์ เช่น Communications, Photos, Social, Cloud และโครงสร้างพื้นฐานทางเทคนิค

ในระยะแรกของอาชีพการงาน เขาทำงานเกี่ยวกับเทคโนโลยีการคอมไพล์, เครื่องเสมือน, ระบบคอมพิวเตอร์แบบขนาน และการเพิ่มประสิทธิภาพฮาร์ดแวร์ที่ Intel Labs และทีม HipHop VM ของ Facebook นอกจากนี้เขายังเคยสอนการออกแบบคอมไพล์ขั้นสูง tại มหาวิทยาลัยสแตนฟอร์ด ประสบการณ์ยาวนานหลายทศวรรษของเขาในด้านภาษาโปรแกรมมิ่ง, ความน่าเชื่อถือของโครงสร้างพื้นฐาน, เครื่องมือสำหรับนักพัฒนา และสถาปัตยกรรมระบบขนาดใหญ่ ทำให้เขาเป็นบุคคลสำคัญในด้านวิศวกรรมซอฟต์แวร์ที่ใช้ AI

Gitar มุ่งเน้นไปที่ปัญหาที่เพิ่มขึ้นจากการพัฒนาซอฟต์แวร์ที่ได้รับการช่วยเหลือจาก AI ซึ่งก็คือการตรวจสอบและรักษาความปลอดภัยของโค้ดที่สร้างโดยเครื่องจักรจำนวนมากที่ไหลเข้าสู่ระบบขององค์กร แพลตฟอร์มนี้ใช้เอเย่นต์ AI เพื่อทำการตรวจสอบโค้ด, ตรวจสอบความล้มเหลวของ CI/CD, ระบุบั๊กและช่องโหว่, แนะนำการแก้ไข และรวมเข้ากับกระบวนการทำงานของวิศวกรผ่านเครื่องมือ เช่น GitHub, GitLab (GTLB ), Jenkins, Jira และ Slack แทนที่จะแข่งขันกันในด้านการสร้างโค้ด AI เพียงอย่างเดียว บริษัทนี้จัดตำแหน่งตัวเองรอบๆ “ประตูคุณภาพของเอเย่นต์” โดยช่วยให้ทีมวิศวกรรักษาความน่าเชื่อถือ, ความปลอดภัย และการควบคุมการดำเนินงาน ในขณะที่การพัฒนาซอฟต์แวร์เปลี่ยนไปสู่การเขียนโค้ดอัตโนมัติและช่วยเหลือโดย AI

คุณเคยเป็นผู้นำด้านวิศวกรรมที่ Uber, Google และ Intel Labs โดยทำงานเกี่ยวกับแพลตฟอร์มสำหรับนักพัฒนาขนาดใหญ่และโครงสร้างพื้นฐาน คุณมีประสบการณ์ใดบ้างที่นำไปสู่การก่อตั้ง Gitar และทำไมจึงมุ่งเน้นไปที่การตรวจสอบโค้ดแทนการสร้างโค้ด?

ตลอดการทำงานที่ Uber, Google, Facebook และ Intel Labs ฉันทำงานเกี่ยวกับแพลตฟอร์มสำหรับนักพัฒนาขนาดต่างๆ และสิ่งที่ฉันพบคือประสบการณ์ของนักพัฒนาเป็นข้อได้เปรียบในการแข่งขัน เครื่องมือที่ดีจะดึงดูดนักพัฒนาที่ดีที่สุดและทำให้บริษัทสามารถเคลื่อนไหวได้อย่างรวดเร็ว นักพัฒนาต้องการเครื่องมือที่เร็วและไม่มีเสียงรบกวน ซึ่งช่วยให้พวกเขาอยู่ในกระบวนการทำงานและทำให้การทำงานที่ไม่จำเป็นเป็นอัตโนมัติ แต่เครื่องมือสำหรับนักพัฒนานั้นกระจัดกระจายอย่างมาก และบริษัทส่วนใหญ่จะใช้ทรัพยากรengineering จำนวนมากเพียงเพื่อสร้างประสบการณ์ที่สอดคล้องกัน ฉันเห็นโอกาสที่จะแก้ไขปัญหานี้

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

การเพิ่มขึ้นของโค้ดที่สร้างโดย AI ทำให้ทีมหลายทีมต้องเผชิญกับปัญหาที่เรียกว่า “การอัดโค้ด” ปัญหานี้มีความสำคัญมากน้อยเพียงใดภายในองค์กรในปัจจุบัน และทีมต่างๆ ต้องดิ้นรนมากที่สุดในด้านใด?

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

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

นั่นคือที่ที่ความเสี่ยงนั้นอยู่ ไม่ใช่ในการสร้าง แต่ในการทำให้โค้ดผ่านเส้นชัยโดยไม่มีความเสี่ยง

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

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

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

Gitar ใช้เอเย่นต์ AI เพื่อจัดการการตรวจสอบโค้ด, ทดสอบ และการทำงานของ CI/CD อย่างไร เอเย่นต์เหล่านี้แตกต่างจากเครื่องมือวิเคราะห์สถานะแบบดั้งเดิมและสายงานที่ใช้กฎอย่างไร?

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

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

นั่นคือเหตุผลที่การอภิปรายเปลี่ยนจาก “เรามีเอเย่นต์หรือไม่” เป็น “งานใดที่สามารถจัดการได้อย่างน่าเชื่อถือ”

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

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

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

สิ่งนี้ลดการไต่สวนของวิศวกรที่ต้องทำ เอเย่นต์ไม่ถอดวิศวกรออกจากวงจร แต่เปลี่ยนจุดที่พวกเขาใช้เวลา ม hệ thốngส่วนใหญ่ทำงานด้วยการตรวจสอบ ไม่ใช่ความเป็นอิสระที่สมบูรณ์

แพลตฟอร์มของคุณช่วยให้ทีมสามารถสร้างเอเย่นต์ของตนเองได้ การปรับแต่งมีความสำคัญเพียงใดสำหรับการนำไปใช้ในองค์กร และคุณเห็นกรณีการใช้งานที่น่าสนใจใดบ้าง?

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

Gitar ลดงานนี้ลง ทีมพัฒนาสามารถเขียนการตรวจสอบแบบกำหนดเองโดยใช้คำสั่งภาษาธรรมชาติ ซึ่งช่วยให้พวกเขาตรวจสอบสิ่งที่ยากหรือเป็นไปไม่ได้กับการวิเคราะห์โปรแกรมแบบดั้งเดิม เช่น การตรวจสอบสตริงที่ไม่ชัดเจนสำหรับการแปล หรือการตรวจสอบการอัปเดตไฟล์ AGENTS.md พวกเขายังสามารถทำให้กระบวนการทำงานแบบกำหนดเองบนการขอ pull request เช่น การเชื่อมโยง PR กับปัญหา Jira, การเปิดตั๋วติดตามสำหรับคำวิจารณ์การรีวิวที่ไม่ได้รับการแก้ไข, การทดสอบแบบอัตโนมัติซ้ำ และการเพิ่มรายการงานแบบกำหนดเองไปยังสรุป PR

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

ทีมวิศวกรรมสมัยใหม่พึ่งพาสแตกของเครื่องมือ เช่น GitHub, GitLab และ Jira มากแค่ไหนที่ Gitar จะต้องรวมเข้ากับกระบวนการทำงานที่มีอยู่แทนที่จะพยายามแทนที่มัน?

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

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

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

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

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

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

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

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

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

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

เมื่อ AI เข้ามาเป็นส่วนหนึ่งของกระบวนการเขียนโค้ดมากขึ้น คุณเห็นว่าบทบาทของวิศวกรอาวุโสเปลี่ยนแปลงไปอย่างไรในอีกไม่กี่ปีข้างหน้า?

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

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

Gitar เพิ่งได้รับเงิน 9 ล้านดอลลาร์ในการขยายแพลตฟอร์ม สิ่งเหล่านี้เป็นจุดประสงค์หลักของคุณสำหรับเงินทุนนี้ และความสำเร็จหมายถึงอะไรในช่วง 12 ถึง 18 เดือนข้างหน้า?

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

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

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