โนดาร์ ดาเนลิยา 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 ได้เปลี่ยนแปลงวิธีการเขียนโค้ดของนักพัฒนา จากมุมมองของคุณ ส่วนใดของวงจรชีวิตซอฟต์แวร์ที่ได้รับการปรับปรุงมากที่สุด และทีมงานยังคงดิ้นรนในเรื่องใด?

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

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

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

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

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

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

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

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

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

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

สำหรับผู้ที่ย้ายจากต้นแบบไปสู่การใช้งานจริง นั่นหมายความว่าคุณจะไม่ชนกำแพงที่จู่ ๆ ต้องเรียนรู้ DevOps แอปพลิเคชันที่คุณสร้างยังคงทำงานได้เมื่อขยายขนาด Neptune เชื่อมช่องว่างระหว่าง «ฉันสร้างบางอย่างแล้ว» กับ «มันทำงานได้อย่างเชื่อถือได้ในระบบจริง»

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

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

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

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

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

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

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

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

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

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

Neptune กลับโมเดลนี้ แทนให้นักพัฒนาแปลแอปเป็นโครงสร้างพื้นฐานคลาวด์ Neptune เข้าใจแอปและสร้างโครงสร้างพื้นฐานรอบแอป เป็นแนวทาง DevOps แบบ AI-native: โค้ดคือพิมพ์เขียว และ Neptune สร้างสภาพแวดล้อมที่จำเป็นต่อการรัน รวมถึงการจัดการข้อมูลลับ การตั้งค่าสภาพแวดล้อม และการประสานทรัพยากร

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

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

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

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

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

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

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