Nodar Daneliya, CEO và Đồng sáng lập của Shuttle – Loạt Phỏng vấn

Nodar Daneliya, CEO và Đồng sáng lập của Shuttle – Loạt Phỏng vấn: Nodar Daneliya đã từng là Đồng sáng lập và CEO của Shuttle từ khi thành lập công ty vào năm 2019, dẫn dắt sự phát triển của công ty từ một công ty khởi nghiệp mùa hè năm 2020 của YC đến một công ty kỹ sư nền tảng tập trung vào nhà phát triển; trước khi gia nhập Shuttle, ông đã từng giữ các vị trí như Giám đốc rủi ro tại Provenance Technologies Ltd, nơi ông đã làm việc về các chiến lược quỹ đầu tư định lượng, và trước đó là các vị trí công nghệ và dữ liệu tại London và Google.

Shuttle là một nền tảng cơ sở hạ tầng đám mây mã nguồn mở giúp đơn giản hóa việc phát triển và triển khai backend bằng cách suy diễn cơ sở hạ tầng từ các chú thích mã, cho phép các nhà phát triển tập trung vào việc viết mã Rust hoặc các ngôn ngữ khác mà không cần quản lý các tệp cấu hình riêng biệt hoặc thiết lập đám mây phức tạp; nền tảng này cho phép triển khai nhanh chóng, cung cấp tài nguyên và mở rộng quy mô liền mạch, và được sử dụng bởi hàng chục nghìn kỹ sư với hơn 130.000 lần triển khai, nhằm mục đích mở rộng trải nghiệm không cấu hình, hỗ trợ bởi AI của mình cho tất cả các ngôn ngữ và tích hợp với các công cụ như GitHub Copilot và Cursor.

Điều gì đã thúc đẩy bạn đồng sáng lập Shuttle, và vấn đề bạn đang cố gắng giải quyết ngay từ đầu?

Điểm chuyển đổi đến trong thời gian tôi lãnh đạo giao dịch tại một quỹ đầu tư định lượng. Chúng tôi có những kỹ sư xuất sắc – tiến sĩ, người đứng đầu nền tảng, nhà nghiên cứu học máy – nhưng ngay cả với tài năng đó, cơ sở hạ tầng đám mây vẫn là nút thắt. Xây dựng một mô hình giao dịch hoặc dịch vụ backend không phải là phần khó. Vấn đề là triển khai: đưa nó lên trực tuyến một cách an toàn, mở rộng quy mô, kết nối các dịch vụ đám mây lại với nhau. Đó là nơi mọi thứ chậm lại. Tại một thời điểm, hơn một nửa đội ngũ kỹ sư của chúng tôi đang làm việc về DevOps chỉ để giữ cho hệ thống hoạt động.

Điều gì vẫn còn với tôi không phải là sự tinh vi của mã hoặc toán học. Đó là việc xem những người có khả năng cao bị cháy hết thời gian của họ để chiến đấu với đám mây thay vì xây dựng những gì thực sự quan trọng. Không ai muốn làm công việc đó, nhưng nó không thể tránh khỏi. Ma sát – khoảng cách giữa “Tôi đã xây dựng một thứ gì đó” và “nó đang chạy đáng tin cậy” – là điều mà Shuttle được tạo ra để giải quyết.

Shuttle được thành lập vào năm 2019, trước khi có làn sóng công cụ mã hóa AI hiện nay. Tầm nhìn ban đầu của bạn đã thay đổi như thế nào khi phát triển hỗ trợ bởi AI trở nên phổ biến?

Vấn đề cốt lõi vẫn không thay đổi, nhưng AI đã khuếch đại nó một cách đáng kể. Khi chúng tôi bắt đầu, cơ sở hạ tầng đã là yếu tố hạn chế đối với các đội kỹ sư mạnh. Khi các công cụ như Copilot, Cursor và Claude xuất hiện, nút thắt đó trở nên không thể bỏ qua.

Đột nhiên, các nhà phát triển có thể tạo ra các ứng dụng đầy đủ trong vài phút, nhưng những ứng dụng đó ngay lập tức gặp phải một rào cản. AI có thể viết mã, nhưng nó không thể cấu hình và quản lý tài nguyên đám mây một cách đáng tin cậy. Khoảng cách mà chúng tôi đang giải quyết đã trở nên rộng hơn và cấp thiết hơn. Hàng triệu người đang xây dựng các nguyên mẫu, nhưng chỉ một phần nhỏ trong số họ đi đến sản xuất.

Tầm nhìn của chúng tôi đã thay đổi từ “làm cho cơ sở hạ tầng dễ dàng hơn cho các nhà phát triển” thành “làm cho cơ sở hạ tầng hoạt động cho một thế hệ xây dựng hoàn toàn mới” – các nhà sáng lập solo, các đội nhỏ và các đại lý AI có thể tạo ra mã backend nhưng không quan tâm đến việc đấu tranh với cấu hình đám mây. Chúng tôi không chỉ phục vụ các kỹ sư truyền thống nữa. Khán giả đã bùng nổ.

Công cụ AI như Cursor và GitHub Copilot đã thay đổi cách các nhà phát triển viết mã. Từ quan điểm của bạn, những phần nào của chu kỳ phát triển phần mềm đã được cải thiện nhiều nhất, và các đội vẫn gặp khó khăn ở đâu?

Sự phát triển mã đã nhảy vọt. Phần đó gần như đã được giải quyết. Bạn có thể mô tả một tính năng, và AI sẽ tạo ra nó. Đặc biệt, frontend đã được hưởng lợi vì các mẫu đã được hiểu rõ – thành phần, phong cách, bố cục.

Nơi các đội gặp khó khăn là mọi thứ sau đó: triển khai, cơ sở hạ tầng, vận hành. AI có thể tạo ra một điểm cuối API, nhưng nó không thể tự động tạo cơ sở dữ liệu, lưu trữ, hàng đợi, mạng, quyền và đường ống triển khai làm cho nó trở thành hiện thực. Cơ sở hạ tầng backend chưa theo kịp với việc tạo mã.

Kết quả là tiến bộ không đồng đều. Thay vì mọi thứ trở nên đơn giản hơn từ đầu đến cuối, các điểm áp lực mới xuất hiện. Các đội tạo ra toàn bộ backend trong vài phút, sau đó bị kẹt trong vài ngày khi cố gắng triển khai chúng một cách an toàn. Đôi khi AI làm cho nó trở nên tồi tệ hơn bằng cách tạo ra nhiều mã hơn so với những gì các đội có thể thực sự chạy hoặc duy trì. Đó là nơi ma sát thực sự tồn tại bây giờ.

Triển khai thường được mô tả là nút thắt lớn nhất đối với các ứng dụng được tạo ra bởi AI. Cụ thể, điều gì làm cho việc đưa các hệ thống này vào sản xuất trở nên thách thức so với việc tạo mã chính nó?

Vấn đề là độ tin cậy và hậu quả. Tạo mã là thứ có thể tha thứ – nếu AI mắc lỗi, bạn sẽ thấy nó ngay lập tức và sửa nó. Những sai lầm về cơ sở hạ tầng khác. Một quyền bị sai, một tài nguyên bị cấu hình sai, một giả định sai về chi phí hoặc bảo mật, và bạn đã tạo ra một vấn đề thực sự có thể không xuất hiện cho đến sau này.

Trước đây, chúng tôi đã thử để cho AI suy diễn tự do cơ sở hạ tầng từ mã ứng dụng. Nó trông tuyệt vời trong các bản demo. Trong các hệ thống thực, nó sụp đổ. AI sẽ tạo ra các thiết lập mà gần như đúng nhưng không hoàn toàn – quyền quá rộng, lựa chọn tài nguyên kỳ lạ, cấu hình sẽ trở nên tốn kém một cách im lặng.

Điều đó đã dạy cho chúng tôi một điều quan trọng: trong sản xuất, trí tuệ không có giới hạn tạo ra vấn đề. AI không cần nhiều quyền tự do. Nó cần đường ray tốt hơn. Bạn phải thiết kế các hệ thống nơi AI có thể đề xuất và tăng tốc, nhưng không thể chạy điên loạn. Đó là thách thức kỹ thuật làm cho việc đưa các ứng dụng được tạo ra bởi AI vào sản xuất trở nên khó khăn hơn so với việc tạo mã.

Shuttle gần đây đã giới thiệu Neptune như sự tiến hóa tiếp theo của nền tảng của mình. Neptune được mô tả là một kỹ sư nền tảng AI phổ quát – điều đó có nghĩa là gì trong thực tế đối với các nhà phát triển khi chuyển từ một nguyên mẫu sang một backend sản xuất?

Neptune hoạt động như một lớp thiếu giữa mã và sản xuất. Trong thực tế, điều đó có nghĩa là các nhà phát triển – hoặc các đại lý AI – có thể tập trung vào việc viết logic ứng dụng, và Neptune sẽ xử lý mọi thứ khác: hiểu cơ sở hạ tầng nào là cần thiết, cung cấp tài nguyên, quản lý bí mật, xử lý triển khai, điều phối dịch vụ.

Thay vì yêu cầu các nhà phát triển dịch ứng dụng của họ thành cơ sở hạ tầng đám mây, Neptune hiểu ứng dụng và tạo ra cơ sở hạ tầng xung quanh nó. Mã của bạn là bản thiết kế. Neptune xây dựng môi trường cần thiết để chạy nó. Không có tệp Docker, không Terraform, không cấu hình vô tận.

Đối với một người đang chuyển từ nguyên mẫu sang sản xuất, điều đó có nghĩa là bạn không gặp phải tường lửa nơi bạn cần học DevOps. Ứng dụng bạn xây dựng vẫn hoạt động khi bạn mở rộng quy mô nó. Neptune bắc cầu khoảng cách giữa “Tôi đã xây dựng một thứ gì đó” và “nó đang chạy đáng tin cậy trong sản xuất.”

Làm thế nào bạn cân bằng giữa tốc độ và trừu tượng hóa với nhu cầu kiểm soát, bảo mật và quan sát được khi các nhà phát triển ngày càng phụ thuộc vào AI để tạo ra hệ thống backend?

Niềm tin là câu trả lời. Trong cơ sở hạ tầng, niềm tin quan trọng hơn khả năng. Một bất ngờ xấu – một lỗ hổng bảo mật, một triển khai bị hỏng, một hóa đơn đám mây khổng lồ – và bạn đã mất người.

Chúng tôi đã học được sớm rằng bất cứ điều gì AI chạm vào cần phải được hiểu và xem xét lại. Ngay cả khi một nhà phát triển không cấu hình một thứ gì đó bằng tay, họ vẫn cần xem những gì đang xảy ra và tại sao. Đó là lý do Neptune sử dụng các quy tắc cơ sở hạ tầng quyết định. AI có thể đề xuất và tăng tốc, nhưng mọi thứ nó làm đều được dựa trên các thông số kỹ thuật có thể được xem xét, dự đoán và thử nghiệm.

Sự thay đổi chúng tôi đã thực hiện là từ “AI quyết định” sang “AI đề xuất trong các ràng buộc.” Đó là sự khác biệt giữa một bản demo thú vị và một thứ gì đó bạn có thể tin cậy khi nó quan trọng. Các nhà phát triển không dành ít thời gian hơn để đưa ra quyết định – họ dành ít thời gian hơn để nhập và nhiều thời gian hơn để quyết định những gì nên tồn tại, những gì được chấp nhận, những sự đánh đổi nào có ý nghĩa. Các đội tốt nhất đối xử với AI như một kỹ sư junior có khả năng: hữu ích, năng suất, nhưng không phải là người đứng đầu.

Loại đội nào đang thấy giá trị mạnh nhất từ Neptune ngày nay, cho dù là nhà phát triển solo, các công ty khởi nghiệp hay các tổ chức kỹ sư lớn hơn?

Hồ sơ đã thay đổi đáng kể. Ban đầu, trên phía Rust, chúng tôi có một cơ sở đa dạng – các nhà phát triển cá nhân, các công ty khởi nghiệp giai đoạn đầu, các công ty đang phát triển, thậm chí các đội kỹ sư doanh nghiệp trong các lĩnh vực như ô tô, IoT, tài chính, tiền điện tử, bất cứ nơi nào độ tin cậy và hiệu suất quan trọng. Những đội này muốn sức mạnh của Rust mà không có gánh nặng của việc quản lý cơ sở hạ tầng đám mây phức tạp.

Tuy nhiên, trong hơn một năm qua, sự trỗi dậy của phát triển hỗ trợ bởi AI đã hoàn toàn thay đổi những người xây dựng phần mềm. Bây giờ chúng tôi thấy các nhà sáng lập solo, các nhà phát triển độc lập, các đại lý AI, các đội nhỏ và các công ty phần mềm truyền thống đều tạo ra mã backend với tốc độ chưa từng có. Khán giả không chỉ là các kỹ sư cao cấp trong các lĩnh vực chuyên biệt nữa.

Chúng tôi thường thấy các nhà sáng lập solo và các đội nhỏ chuyển từ một ý tưởng đến một backend được triển khai trong một lần ngồi vì họ không cần phải dành vài ngày để thiết lập. Đó không chỉ là thời gian được tiết kiệm – đó là động lực được bảo tồn, điều đó là mọi thứ vào giai đoạn đầu. Đó là nơi giá trị mạnh nhất xuất hiện: những người có thể xây dựng nhưng không muốn trở thành chuyên gia cơ sở hạ tầng chỉ để đưa ý tưởng của họ lên trực tuyến.

Từ quan điểm kỹ thuật, Neptune xử lý cấu hình môi trường, quản lý bí mật và điều phối cơ sở hạ tầng như thế nào khi chuyển mã được tạo ra bởi AI thành một backend sản xuất có thể triển khai?

Neptune đối xử với mã và cơ sở hạ tầng như một hệ thống thống nhất. Hầu hết các công cụ triển khai hoạt động như một dịch vụ giao hàng – bạn đưa cho họ một容器, và họ sẽ cố gắng chạy nó. Điều đó vẫn để lại cho bạn trách nhiệm khâu các tài nguyên đám mây lại với nhau, viết cấu hình, xử lý biến môi trường, quản lý bí mật, cấp phép tài nguyên.

Neptune đảo ngược mô hình đó. Thay vì yêu cầu nhà phát triển dịch ứng dụng của họ thành cơ sở hạ tầng đám mây, Neptune hiểu ứng dụng và tạo ra cơ sở hạ tầng xung quanh nó. Đó là một cách tiếp cận AI-native đối với DevOps: mã là bản thiết kế, và Neptune xây dựng môi trường cần thiết để chạy nó – bao gồm quản lý bí mật, cấu hình môi trường và điều phối tài nguyên.

Chìa khóa là AI hoạt động trong các quy tắc cơ sở hạ tầng quyết định. Nó không thể tạo ra các cấu hình tùy ý. Mọi thứ vẫn có thể xem xét và dự đoán, điều đó là cần thiết cho bảo mật và kiểm soát chi phí trong các môi trường sản xuất.

Nhìn về tương lai, bạn thấy vai trò của Neptune sẽ thay đổi như thế nào trong một hệ sinh thái nơi các hệ thống AI ngày càng xây dựng, triển khai và quản lý các hệ thống phần mềm khác?

Chúng tôi đang chuyển hướng đến một thế giới nơi khoảng cách giữa một ý tưởng và một sản phẩm hoạt động gần như bằng không. Rất sớm, sản phẩm sẽ không chỉ được xây dựng nhanh hơn – chúng sẽ liên tục cải thiện bản thân dựa trên phản hồi thực tế về cách mọi người thực sự sử dụng chúng.

Trong thế giới đó, phần mềm sẽ không tĩnh. Các ứng dụng, đại lý và hệ thống sẽ được tạo ra, sửa đổi và tiến hóa liên tục. Tất cả những điều đó vẫn cần phải chạy ở một nơi nào đó. Nó vẫn cần cơ sở hạ tầng, quyền, tài nguyên và độ tin cậy.

Mục tiêu dài hạn của chúng tôi là trở thành hệ thống mặc định cho DevOps hỗ trợ bởi AI – cơ bản là Kỹ sư Nền tảng AI. Cho dù mã được viết bởi một nhà phát triển trong Cursor hay được tạo ra tự động bởi một đại lý AI, Neptune nên là lớp mà đưa nó từ mã đến một dịch vụ sản xuất hoàn chỉnh, có thể mở rộng và đáng tin cậy.

Nếu sự sáng tạo trở nên không giới hạn, cơ sở hạ tầng không thể là ràng buộc. Khi các đại lý AI và sản phẩm tự tiến hóa trở nên bình thường, công việc của chúng tôi là làm cho tương tác với cơ sở hạ tầng đám mây trở nên liền mạch, dự đoán và an toàn. Chúng tôi tập trung vào việc làm cho điều đó trở nên vô hình, để các nhà phát triển, người sáng lập và công ty có thể tập trung vào việc tạo ra giá trị thay vì đấu tranh với cơ sở hạ tầng.

Cảm ơn vì cuộc phỏng vấn tuyệt vời, độc giả muốn tìm hiểu thêm nên truy cập Shuttle.