โนดาร์ ดาเนลิยา CEO และผู้ร่วมก่อตั้ง Shuttle – สัมภาษณ์ซีรีส์

นодар ดาเนลิยา เป็น CEO และผู้ร่วมก่อตั้ง Shuttle ซึ่งเขาร่วมก่อตั้งบริษัทในปี 2019 และนำบริษัทเติบโตจากสตาร์ทอัพในช่วง Summer 2020 ของ YC มาเป็นบริษัทที่มุ่งเน้นการสร้างแพลตฟอร์มสำหรับวิศวกรพัฒนา ซึ่งก่อนหน้านี้เขาทำงานในตำแหน่ง Chief Risk Officer ที่ Provenance Technologies Ltd โดยทำงานเกี่ยวกับกลยุทธ์ quantitative hedge fund และในตำแหน่งทางเทคนิคและข้อมูลในลอนดอนและกูเกิล

Shuttle เป็นแพลตฟอร์มโครงสร้างพื้นฐานคลาวด์แบบโอเพ่นซอร์สที่ช่วยให้การพัฒนาและวางระบบแบ็กเอนด์ง่ายขึ้นโดยการสร้างโครงสร้างพื้นฐานจากโค้ดแอนโนเตชัน ทำให้นักพัฒนาสามารถมุ่งเน้นในการเขียนโค้ด Rust หรือโค้ดอื่น ๆ โดยไม่ต้องจัดการไฟล์คอนฟิกหรือการตั้งค่าคลาวด์ที่ซับซ้อน แพลตฟอร์มนี้ช่วยให้วางระบบได้อย่างรวดเร็ว มีการจัดสรรทรัพยากรแบบ out-of-the-box และการปรับขนาดที่ราบรื่น และถูกใช้โดยวิศวกรหลายหมื่นคน โดยมีการวางระบบมากกว่า 130,000 ครั้ง โดยมีเป้าหมายที่จะขยายประสบการณ์แบบ zero-config ที่ได้รับการช่วยเหลือจาก AI ไปยังภาษาทั้งหมด และรวมเข้ากับเครื่องมือเช่น GitHub Copilot และ Cursor

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

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

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

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

ปัญหาพื้นฐานยังคงเหมือนเดิม แต่ AI เพิ่มมันขึ้นอย่างมาก เมื่อเริ่มต้น โครงสร้างพื้นฐานคลาวด์เป็นปัจจัยที่จำกัดทีมวิศวกรที่มีศักยภาพสูง เมื่อเครื่องมืออย่าง Copilot, Cursor และ Claude ปรากฏขึ้น ปัญหานั้นกลายเป็นสิ่งที่ไม่สามารถเพิกเฉยได้

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

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

เครื่องมือ AI เช่น Cursor และ GitHub Copilot ได้เปลี่ยนแปลงวิธีการเขียนโค้ดของนักพัฒนา จากมุมมองของคุณ ส่วนใดของวงจรชีวิตซอฟต์แวร์ที่ได้รับการปรับปรุงมากที่สุด และทีมงานยังคงดิ้นรนใน đâu?

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

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

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

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

Shuttle ได้แนะนำ Neptune เป็นรุ่นต่อไปของแพลตฟอร์มแล้ว Neptune ถูกอธิบายว่าเป็นแพลตฟอร์มวิศวกร AI ที่เป็นสากล – สิ่งนี้หมายถึงอะไรในทางปฏิบัติสำหรับนักพัฒนาที่ย้ายจากโพรโทไทป์ไปสู่แบ็กเอนด์ที่พร้อมสำหรับการผลิต?

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

แทนที่จะทำให้นักพัฒนาต้องแปลแอปพลิเคชันของตนเป็นโครงสร้างพื้นฐานคลาวด์ Neptune จะเข้าใจแอปพลิเคชันและสร้างโครงสร้างพื้นฐานรอบๆ มัน โค้ดของคุณคือแผนผัง Neptune สร้างสภาพแวดล้อมที่จำเป็นในการรัน มันไม่ต้องใช้ Dockerfiles, Terraform หรือการกำหนดค่าที่ไม่สิ้นสุด

เมื่อนักพัฒนาพึ่งพา AI มากขึ้นในการสร้างระบบแบ็กเอนด์ คุณสร้างสมดุลระหว่างความเร็วและความเป็นนามธรรมกับความต้องการในการควบคุม ความปลอดภัย และการตรวจสอบอย่างไร?

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

เมื่อมองไปข้างหน้า คุณเห็นบทบาทของ Neptune วิวัฒนาการอย่างไรในระบบนิเวศที่ระบบ AI สร้าง ระบบวาง และจัดการซอฟต์แวร์อื่น ๆ?

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

ในโลกนั้น ซอฟต์แวร์จะไม่ใช่สิ่ง静态 แอปพลิเคชัน ตัวแทน และระบบจะถูกสร้าง ปรับเปลี่ยน และพัฒนาอย่างต่อเนื่อง ทั้งหมดนี้ยังคงต้องทำงานที่ไหนสักแห่ง ยังคงต้องมีโครงสร้างพื้นฐาน สิทธิ์ ทรัพยากร และความน่าเชื่อถือ

เป้าหมายระยะยาวของเราคือการเป็นระบบมาตรฐานสำหรับการ DevOps ที่ได้รับการช่วยเหลือจาก AI – โดยพื้นฐานแล้วคือวิศวกรแพลตฟอร์ม AI ไม่ว่าโค้ดจะถูกเขียนโดยนักพัฒนาที่ใช้ Cursor หรือสร้างโดยตัวแทน AI ในอิสระ Neptune ควรเป็นชั้นที่นำโค้ดไปสู่การวางระบบที่สมบูรณ์แบบและปรับขนาดได้

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

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