Nodar Daneliya, PDG et co-fondateur de Shuttle – Série d’entretiens

Nodar Daneliya, PDG et co-fondateur de Shuttle – Série d’entretiens : Nodar Daneliya a occupé le poste de co-fondateur et PDG de Shuttle depuis la création de l’entreprise en 2019, menant sa croissance d’une startup de l’été 2020 de YC à une entreprise d’ingénierie de plateformes axée sur les développeurs ; avant Shuttle, il a occupé des postes tels que directeur des risques chez Provenance Technologies Ltd, où il a travaillé sur des stratégies de fonds spéculatifs quantitatifs, et des postes techniques et de données à Londres et chez Google.

Shuttle est une plateforme d’infrastructure cloud open source qui simplifie le développement et le déploiement de backend en dérivant l’infrastructure à partir d’annotations de code, permettant ainsi aux développeurs de se concentrer sur l’écriture de code Rust ou autre sans gérer des fichiers de configuration séparés ou des configurations cloud complexes ; la plateforme permet un déploiement rapide, une provision de ressources prête à l’emploi et un scaling sans accroc, et est utilisée par des dizaines de milliers d’ingénieurs avec plus de 130 000 déploiements, visant à étendre son expérience zéro-config et assistée par l’IA à tous les langages et à intégrer des outils comme GitHub Copilot et Cursor.

Quel moment ou quelle frustration vous a finalement poussé à co-fonder Shuttle, et quel problème essayiez-vous de résoudre au tout début ?

Le point de basculement est survenu pendant mon temps en tant que responsable du trading dans un fonds spéculatif quantitatif. Nous avions des ingénieurs exceptionnels – des doctorats, des personnes senior de la plateforme, des chercheurs en apprentissage automatique – mais même avec ce talent, l’infrastructure cloud était le goulet d’étranglement constant. Construire un modèle de trading ou un service de backend n’était pas la partie difficile. Le problème était le déploiement : le rendre live de manière sécurisée, le mettre à l’échelle, relier les services cloud ensemble. C’est là que tout ralentissait. À un moment donné, plus de la moitié de notre équipe d’ingénieurs faisait du travail de DevOps juste pour maintenir les systèmes en fonctionnement.

Ce qui m’a marqué, ce n’était pas la sophistication du code ou des mathématiques. C’était regarder des personnes très capables brûler la majeure partie de leur temps à lutter contre le cloud au lieu de construire ce qui comptait vraiment. Personne ne voulait faire ce travail, mais c’était inévitable. Cette friction – l’écart entre “j’ai construit quelque chose” et “ça fonctionne de manière fiable” – est ce que Shuttle a été créé pour résoudre.

Shuttle a été fondé en 2019, avant la vague actuelle d’outils de codage assistés par l’IA. Comment votre vision originale a-t-elle évolué à mesure que le développement assisté par l’IA est devenu mainstream ?

Le problème de base est resté le même, mais l’IA l’a amplifié de manière dramatique. Lorsque nous avons commencé, l’infrastructure était déjà le facteur limitant pour les équipes d’ingénieurs solides. Lorsque des outils comme Copilot, Cursor et Claude sont apparus, ce goulet d’étranglement est devenu impossible à ignorer.

Soudain, les développeurs pouvaient générer des applications complètes en quelques minutes, mais ces applications heurtaient un mur immédiatement. L’IA peut écrire du code, mais elle ne peut pas configurer et gérer de manière fiable les ressources cloud. L’écart que nous résolvions est devenu beaucoup plus large et plus urgent. Des millions de personnes construisent maintenant des prototypes, mais seulement une fraction aboutit à la production.

La vision a évolué de “rendre l’infrastructure plus facile pour les développeurs” à “faire fonctionner l’infrastructure pour une nouvelle génération entière de constructeurs” – des fondateurs solo, de petites équipes et des agents IA qui peuvent créer du code de backend mais n’ont aucun intérêt à lutter contre la configuration du cloud. Nous ne servons plus seulement les ingénieurs traditionnels. Le public a explosé.

Des outils d’IA comme Cursor et GitHub Copilot ont changé la façon dont les développeurs écrivent du code. De votre point de vue, quelles parties du cycle de vie logiciel ont le plus amélioré, et où les équipes ont-elles encore des difficultés ?

La génération de code a fait un bond en avant. Cette partie est presque résolue. Vous pouvez décrire une fonctionnalité, et l’IA la créera. Le frontend a particulièrement bénéficié parce que les modèles sont bien compris – les composants, les styles, les dispositions.

Là où les équipes ont des difficultés, c’est tout ce qui vient après : le déploiement, l’infrastructure, les opérations. L’IA peut générer un point de terminaison d’API, mais elle ne peut pas créer automatiquement la base de données, le stockage, la file d’attente, le réseau, les autorisations ou la pipeline de déploiement qui le rend réel. L’infrastructure de backend n’a pas suivi le rythme de la génération de code.

Le résultat est un progrès inégal. Au lieu que les choses deviennent plus simples de bout en bout, de nouveaux points de pression apparaissent. Les équipes génèrent des backends entiers en quelques minutes, puis restent bloquées pendant des jours en essayant de les déployer en toute sécurité. Parfois, l’IA rend les choses pires en produisant plus de code que les équipes ne peuvent réellement exécuter ou maintenir. C’est là que vit la véritable friction.

Le déploiement est souvent décrit comme le goulet d’étranglement le plus important pour les applications générées par l’IA. Qu’est-ce qui rend la mise en production de ces systèmes si difficile par rapport à la génération du code lui-même ?

Le problème est la fiabilité et les conséquences. La génération de code est indulgente – si l’IA fait une erreur, vous la voyez immédiatement et la corrigez. Les erreurs d’infrastructure sont différentes. Une autorisation incorrecte, une ressource mal configurée, une mauvaise hypothèse sur le coût ou la sécurité, et vous avez créé un véritable problème qui peut ne pas apparaître avant plus tard.

Tôt, nous avons essayé de laisser l’IA déduire librement l’infrastructure à partir du code d’application. Cela ressemblait bien dans les démonstrations. Dans les systèmes réels, cela s’est effondré. L’IA produisait avec confiance des configurations qui étaient presque correctes mais pas tout à fait – des autorisations trop larges, des choix de ressources étranges, des configurations qui deviendraient silencieusement coûteuses.

Cela nous a enseigné quelque chose de critique : en production, l’intelligence sans limites crée des problèmes. L’IA n’a pas besoin de plus de liberté. Elle a besoin de meilleures rails. Vous devez concevoir des systèmes où l’IA peut suggérer et accélérer, mais ne peut pas faire des folies. C’est le défi technique qui rend la mise en production d’applications générées par l’IA beaucoup plus difficile que la génération du code.

Shuttle a récemment introduit Neptune comme l’évolution suivante de sa plateforme. Neptune est décrit comme un ingénieur de plateforme universel assisté par l’IA – qu’est-ce que cela signifie en termes pratiques pour les développeurs qui passent d’un prototype à un backend prêt pour la production ?

Neptune agit comme la couche manquante entre le code et la production. En termes pratiques, cela signifie que les développeurs – ou les agents IA – peuvent se concentrer sur l’écriture de la logique d’application, et Neptune gère tout le reste : comprendre quelles infrastructures sont nécessaires, provisionner les ressources, gérer les secrets, gérer le déploiement, orchestrer les services.

Au lieu de faire traduire les développeurs leur application en infrastructure cloud, Neptune comprend l’application et génère l’infrastructure autour d’elle. Votre code est le plan. Neptune construit l’environnement nécessaire pour le faire fonctionner. Pas de fichiers Docker, pas de Terraform, pas de configuration interminable.

Pour quelqu’un qui passe d’un prototype à une production, cela signifie que vous ne heurtez pas le mur où vous devez soudainement apprendre le DevOps. L’application que vous avez construite continue de fonctionner à mesure que vous la mettez à l’échelle. Neptune comble l’écart entre “j’ai construit quelque chose” et “ça fonctionne de manière fiable en production”.

À mesure que les développeurs s’appuient davantage sur l’IA pour générer des systèmes de backend, comment équilibrez-vous la vitesse et l’abstraction avec le besoin de contrôle, de sécurité et d’observabilité ?

La confiance est la réponse. Dans l’infrastructure, la confiance compte plus que la capacité. Une mauvaise surprise – un trou de sécurité, un déploiement cassé, une facture cloud massive – et vous avez perdu les gens.

Nous avons appris tôt que tout ce que l’IA touche doit être compréhensible et examinable. Même si un développeur n’a pas configuré quelque chose manuellement, il doit toujours voir ce qui se passe et pourquoi. C’est pourquoi Neptune utilise des règles d’infrastructure déterministes. L’IA peut suggérer et accélérer, mais tout ce qu’elle fait est ancré dans des spécifications qui sont examinables, prévisibles et testables.

Le changement que nous avons opéré est allé de “l’IA décide” à “l’IA propose dans les limites”. C’est la différence entre une démonstration amusante et quelque chose que vous pouvez faire confiance lorsqu’il s’agit de choses importantes. Les développeurs ne passent pas moins de temps à prendre des décisions – ils passent moins de temps à taper et plus de temps à décider ce qui devrait exister, quels compromis ont du sens. Les meilleures équipes traitent l’IA comme un jeune ingénieur très capable : utile, productif, mais pas en charge.

Quels types d’équipes voient la plus forte valeur de Neptune aujourd’hui, que ce soit des développeurs solo, des startups ou de plus grandes organisations d’ingénieurs ?

Le profil a changé de manière dramatique. À l’origine, du côté Rust, nous avions une base diverse – des développeurs individuels, des startups en démarrage, des scaleups, même des équipes d’entreprise dans l’automobile, l’IoT, la finance, la crypto, partout où la fiabilité et les performances comptent. Ces équipes voulaient la puissance de Rust sans la charge de gérer des infrastructures cloud complexes.

Mais au cours de la dernière année, l’essor du développement assisté par l’IA a complètement changé qui construit des logiciels. Maintenant, nous voyons des fondateurs solo, des développeurs indépendants, des agents IA, de petites équipes et des entreprises logicielles traditionnelles générer du code de backend à une vitesse sans précédent. Le public n’est plus seulement composé d’ingénieurs seniors dans des domaines spécialisés.

Nous voyons régulièrement des fondateurs solo et de petites équipes passer d’une idée à un backend déployé en une seule séance parce qu’ils n’ont pas à passer des jours sur la configuration. Ce n’est pas seulement du temps économisé – c’est de l’élan préservé, ce qui est tout au début. C’est là que la plus forte valeur apparaît : les personnes qui peuvent construire mais ne veulent pas devenir des experts en infrastructure juste pour mettre leurs idées en ligne.

D’un point de vue technique, comment Neptune gère-t-il la configuration de l’environnement, la gestion des secrets et l’orchestration de l’infrastructure lorsqu’il transforme le code généré par l’IA en un backend de production déployable ?

Neptune traite le code et l’infrastructure comme un système unifié. La plupart des outils de déploiement agissent comme un service de livraison – vous leur apportez un conteneur, et ils essaient de le faire fonctionner. Cela laisse encore les développeurs responsables de coudre ensemble les ressources cloud, d’écrire des configurations, de gérer les variables d’environnement, de gérer les secrets, de provisionner les bases de données.

Neptune inverse ce modèle. Au lieu de faire traduire les développeurs leur application en infrastructure cloud, Neptune comprend l’application et génère l’infrastructure autour d’elle. C’est une approche native de DevOps pour l’IA : le code est le plan, et Neptune construit l’environnement nécessaire pour le faire fonctionner – y compris la gestion des secrets, la configuration de l’environnement et l’orchestration des ressources.

La clé est que l’IA fonctionne à l’intérieur de règles d’infrastructure déterministes. Elle ne peut pas produire des configurations arbitraires. Tout reste examinable et prévisible, ce qui est essentiel pour la sécurité et le contrôle des coûts dans les environnements de production.

En regardant vers l’avenir, comment voyez-vous l’évolution du rôle de Neptune dans un écosystème où les systèmes d’IA construisent, déployeront et géreront de plus en plus de logiciels ?

Nous nous dirigeons vers un monde où l’écart entre une idée et un produit fonctionnel est proche de zéro. Très bientôt, les produits ne seront pas seulement construits plus rapidement – ils s’amélioreront continuellement eux-mêmes en fonction des retours réels de la façon dont les gens les utilisent réellement.

Dans ce monde, les logiciels ne seront pas statiques. Les applications, les agents et les systèmes seront créés, modifiés et évolueront constamment. Tout cela aura encore besoin de fonctionner quelque part. Il aura encore besoin d’infrastructure, d’autorisations, de ressources et de fiabilité.

Notre objectif à long terme est de devenir le système par défaut pour le DevOps assisté par l’IA – essentiellement l’ingénieur de plateforme d’IA. Que le code soit écrit par un développeur dans Cursor ou généré de manière autonome par un agent IA, Neptune devrait être la couche qui prend le code et le transforme en un service entièrement fonctionnel et prêt pour la production.

Si la créativité devient sans limite, l’infrastructure ne peut pas être la contrainte. À mesure que les agents IA et les produits qui s’auto-évoluent deviennent la norme, notre travail est de rendre l’interaction avec l’infrastructure cloud transparente, prévisible et sûre. Nous nous concentrons sur le fait de rendre cela invisible, afin que les développeurs, les fondateurs et les entreprises puissent se concentrer sur la création de valeur au lieu de lutter contre l’infrastructure.

Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Shuttle.