Professeur Eran Yahav, Co-Fondateur et Co-PDG de Tabnine – Série d’entretiens

Professeur Eran Yahav, Co-Fondateur et Co-PDG de Tabnine est un professeur de sciences informatiques au Technion – Institut de technologie d’Israël dont les recherches portent sur les langages de programmation, l’apprentissage automatique et l’ingénierie logicielle, en particulier la synthèse de programmes et l’analyse de code à grande échelle. Parallèlement à ses travaux universitaires, il a co-fondé Tabnine (à l’origine Codota) pour appliquer des années de recherche à des outils pratiques pour les développeurs, aidant à pionnier l’achèvement de code et l’automatisation pilotés par l’IA. Son travail relie l’université et l’industrie, avec un accent sur le fait de rendre le code généré par l’IA plus fiable, sécurisé et sensible au contexte pour les environnements d’entreprise réels.

Tabnine est une plateforme de codage alimentée par l’IA conçue pour aider les développeurs tout au long du cycle de vie du développement logiciel, de l’écriture et du débogage du code à la génération de tests et de documentation. Initialement lancé comme outil d’achèvement de code, il a évolué vers une plateforme plus large axée sur l’entreprise qui intègre l’IA générative et les flux de travail basés sur des agents, permettant aux équipes d’automatiser des tâches de développement complexes tout en maintenant un contrôle solide sur la confidentialité, la sécurité et la conformité. Avec une prise en charge de dizaines de langages de programmation et des intégrations dans les principales IDE, Tabnine vise à améliorer la productivité des développeurs tout en veillant à ce que le code généré par l’IA reste digne de confiance et conforme aux normes de l’organisation.

Vous avez passé des années à rechercher l’analyse et la synthèse de programmes au Technion et avez précédemment travaillé à la recherche d’IBM. Quel problème dans le développement logiciel vous a convaincu de co-fonder Tabnine, et comment vos recherches universitaires ont-elles façonné la vision originale de l’entreprise ?

Mes travaux universitaires se sont concentrés sur l’analyse et la synthèse de programmes, qui consistent essentiellement à enseigner aux machines à comprendre et à générer du code. J’ai fait mon doctorat sur l’analyse de programmes, et c’est également là que j’ai passé mes premières années de travail de recherche appliqué. Résoudre les problèmes de qualité logicielle avec l’analyse de programmes a rendu clair que certains problèmes sont très difficiles à résoudre une fois que le programme a été écrit de manière incorrecte. Une once de prévention vaut mieux qu’une livre de cure, si vous voulez. Cela m’a convaincu que la bonne façon de résoudre les problèmes de qualité logicielle est via la synthèse de programmes, qui est où j’ai passé la majeure partie de mon temps et de mon énergie de recherche.

J’ai initialement travaillé sur la synthèse de programmes pour les programmes concurrents, en essayant d’automatiser la création de programmes concurrents à partir de programmes séquentiels. J’ai ensuite basculé vers une synthèse de programmes plus généralement applicable en utilisant l’apprentissage automatique.

La synthèse de programmes en utilisant l’apprentissage automatique était également l’idée fondamentale qui alimentait Tabnine. L’idée, qui semble maintenant évidente, était que les modèles pourraient apprendre des modèles de codage directement à partir de grandes collections de code et aider les développeurs en temps réel. Cette idée générale est applicable à toutes les étapes du cycle de vie du développement logiciel – de la création de code à la révision de code, au déploiement et au-delà.

La vision a toujours été d’augmenter le développeur humain en lui fournissant des outils qui accélèrent le processus de développement et éliminent les frictions. Le développement logiciel est une discipline créative et de résolution de problèmes, et l’objectif était que l’IA élimine les frictions du processus en gérant les tâches routinières et en aidant les développeurs à rester dans le flux. Cette vision nous guide encore aujourd’hui, même si la technologie a évolué de manière significative depuis ces premiers jours.

Tabnine a été pionnier dans les assistants de codage IA des années avant que l’IA générative ne devienne mainstream avec des outils comme les modèles d’OpenAI. En regardant en arrière, comment le rôle de l’IA dans le développement logiciel a-t-il évolué depuis ces premiers jours, et quels enseignements l’industrie a-t-elle tirés de la première vague d’assistants de codage ?

La première génération d’assistants de codage IA s’est concentrée principalement sur la prédiction. Ils étaient essentiellement des systèmes d’autocomplétion avancés qui aidaient les développeurs à écrire du code plus rapidement en prédisant la prochaine ligne ou la prochaine fonction.

Ce qui a changé avec les boucles d’agents est que l’IA peut maintenant gérer des tâches avec une plus grande autonomie, au point où nous pouvons considérer les agents (avec une orientation appropriée) comme des développeurs juniors indépendants.

Cependant, cela a également enseigné à l’industrie une leçon importante. La capacité brute du modèle n’est pas suffisante pour le développement logiciel d’entreprise. Les modèles formés sur des données publiques peuvent produire des sorties impressionnantes, mais ils manquent souvent de conscience de l’architecture, des dépendances et des conventions de l’organisation.

C’est pourquoi la prochaine étape de l’évolution n’est pas seulement de plus grands modèles ou de plus grandes fenêtres de contexte, mais de connecter ces modèles au contexte réel dans lequel le logiciel est construit.

De nombreuses entreprises découvrent que la mise à l’échelle des agents IA nécessite plus que de plus grands modèles – cela nécessite un contexte organisationnel plus profond. Pourquoi pensez-vous que le contexte devient la véritable frontière pour le développement fiable piloté par l’IA ?

Les systèmes logiciels sont des réseaux complexes de relations. Un seul changement peut affecter plusieurs services, API ou composants en aval.

Les modèles d’IA d’aujourd’hui sont très bons pour générer du code plausible, mais ils opèrent souvent sans une compréhension structurée de ces relations. Sans cette compréhension, l’IA ne peut pas raisonnablement raisonner sur les conséquences d’un changement.

Ce que les entreprises découvrent, c’est que la fiabilité des systèmes d’IA dépend de la qualité du contexte dans lequel ils opèrent. Si un système d’IA comprend l’architecture du système, les dépendances entre les services et les normes de codage de l’organisation, il peut générer du code qui s’aligne beaucoup plus étroitement sur la façon dont ce système fonctionne réellement.

Dans ce sens, le contexte devient la prochaine frontière pour le développement d’IA d’entreprise.

Votre nouveau Moteur de contexte d’entreprise vise à donner aux agents d’IA une compréhension structurée de l’architecture, des dépendances et des pratiques d’ingénierie d’une organisation. Comment cette approche diffère-t-elle des méthodes courantes telles que la génération augmentée par récupération que de nombreuses entreprises utilisent actuellement ?

La génération augmentée par récupération est une technique utile. Elle permet aux modèles de récupérer des documents ou des extraits de code pertinents lors de la génération d’une réponse.

Cependant, la récupération seule ne crée pas de compréhension. Elle fournit un accès à l’information, et non à la structure.

Le Moteur de contexte d’entreprise est conçu pour aller plus loin en construisant une représentation structurée de l’environnement logiciel. Il analyse les référentiels, les services, les dépendances, les API et les relations architecturales et les organise en un modèle de la façon dont le système fonctionne réellement.

Cela permet aux systèmes d’IA de raisonner sur les relations entre les composants plutôt que de simplement récupérer des morceaux de texte. Pour les environnements d’entreprise complexes, cette distinction devient très importante.

Les outils de codage IA évoluent des suggestions d’autocomplétion vers des agents autonomes capables d’exécuter des flux de travail multi-étapes. Comment voyez-vous l’équilibre entre les développeurs humains et les systèmes agents changer au cours des cinq prochaines années ?

Les agents d’IA prendront de plus en plus en charge les tâches de développement routinières. Ils sont déjà capables de mettre en œuvre des fonctionnalités de bout en bout, y compris les tests et la documentation. Chaque développeur deviendra un chef d’équipe de développeurs d’IA. Le principal défi serait de communiquer les exigences à cette équipe et de vérifier que les artefacts générés correspondent aux exigences définies.

Cependant, le développement logiciel est fondamentalement une discipline de résolution de problèmes et de conception. Les développeurs humains continueront à définir l’architecture, à faire des compromis et à guider la direction générale des systèmes.

Ce qui changera, c’est le niveau d’abstraction auquel les développeurs travaillent. Au lieu de se concentrer sur le code, les développeurs orchestreront de plus en plus des flux de travail de niveau supérieur et collaboreront avec des systèmes d’IA qui exécutent des parties de ces flux de travail.

En d’autres termes, le rôle des développeurs devient plus stratégique à mesure que l’IA gère davantage du travail mécanique.

Tabnine a indiqué que les utilisateurs d’entreprise peuvent voir les taux d’acceptation de code généré par l’IA atteindre environ 80 % dans certains environnements. Quels indicateurs les organisations doivent-ils utiliser pour déterminer si les outils de codage IA améliorent réellement la productivité des développeurs plutôt que de simplement générer plus de code ?

La question clé n’est pas de savoir combien de code l’IA génère, mais combien de travail utile il produit réellement.

Il existe plusieurs indicateurs que les organisations doivent suivre. L’un est le taux d’acceptation à la première passe, qui mesure à quelle fréquence le code généré par l’IA peut être utilisé sans modification. Un autre est le temps de cycle de révision – combien d’itérations sont nécessaires avant qu’une demande de tirage ne puisse être fusionnée.

Les organisations doivent également examiner le temps que les développeurs passent à réviser, ainsi que le délai de modification de la conception à la production.

Si les outils d’IA améliorent réellement la productivité, vous devriez voir des améliorations dans ces indicateurs. Les développeurs passent moins de temps à corriger le code généré et plus de temps à travailler sur des tâches à plus forte valeur.

Les entreprises restent prudentes quant à l’exposition de leur code propriétaire à des modèles externes. Comment le concept de « Codage IA de confiance » répond-il aux préoccupations de gouvernance, de confidentialité et de conformité qui ont ralenti l’adoption d’outils de développement d’IA par les entreprises ?

La confiance est l’un des facteurs les plus importants pour l’adoption d’IA par les entreprises.

La confiance est l’ultime défi pour réaliser l’ingénieur d’IA. Comment pouvons-nous faire confiance à l’ingénieur d’IA pour agir de manière autonome pour effectuer des tâches d’ingénierie logicielle critiques ? Comment pouvons-nous nous assurer que ses actions sont conformes à nos attentes en matière de qualité, de sécurité et de conformité avec nos politiques ? Si l’ingénieur d’IA doit être un membre accepté de nos équipes d’ingénierie, il doit être aussi digne de confiance que nos collègues bien vérifiés et correctement formés.

La résolution de ce défi repose sur deux piliers critiques :

• Personnalisation : Équiper l’ingénieur d’IA d’une compréhension approfondie de votre organisation, de votre base de code et de vos meilleures pratiques.
• Contrôle : Mettre en œuvre des systèmes solides pour garantir que tout le code – généré par l’IA et écrit par l’homme – répond aux normes de qualité, de sécurité, de performances et de fiabilité de votre organisation.

De plus, le codage IA de confiance signifie donner aux organisations le contrôle sur la façon dont l’IA est déployée et garantir une gouvernance et un contrôle centralisés.

Vous avez suggéré que le contexte organisationnel pourrait devenir une couche fondamentale dans la pile d’IA d’entreprise – similaire aux bases de données ou à l’infrastructure cloud dans les ères de calcul précédentes. À quoi ressemble cette architecture future ?

Si l’on regarde comment la technologie d’entreprise évolue, on voit souvent de nouvelles couches d’infrastructure émerger.

Les bases de données sont devenues la fondation pour la gestion des données. Les plates-formes cloud sont devenues la fondation pour exécuter des applications à grande échelle.

À l’ère de l’IA, les organisations auront besoin d’une infrastructure qui permet aux systèmes d’IA de comprendre la structure interne de l’entreprise – ses systèmes, ses relations et ses contraintes opérationnelles.

Cette couche d’infrastructure fournira un contexte structuré que plusieurs systèmes d’IA peuvent utiliser, qu’il s’agisse d’assistants de codage, d’agents de support ou d’outils d’automatisation opérationnelle.

Dans ce sens, le contexte devient une fondation partagée pour l’IA d’entreprise.

De nombreuses entreprises construisent des assistants de codage étroitement couplés à un seul modèle de base. Tabnine permet aux entreprises de connecter différents modèles en fonction de leurs besoins. Pourquoi la flexibilité des modèles est-elle importante pour l’évolution à long terme des outils de développement d’IA d’entreprise ?

L’écosystème d’IA évolue très rapidement. De nouveaux modèles sont publiés fréquemment, et différents modèles ont souvent des forces dans différents domaines.

Les entreprises ne devraient pas avoir à reconcevoir leurs flux de travail de développement chaque fois que le paysage des modèles change. En permettant aux organisations de choisir et de basculer entre les modèles, nous offrons une flexibilité qui aide à pérenniser leur stratégie d’IA.

La flexibilité des modèles permet également aux organisations d’équilibrer les performances, les coûts, les exigences de confidentialité et les contraintes de déploiement.

À long terme, les entreprises fonctionneront probablement dans un environnement multi-modèles, et les plateformes de développement devraient être conçues en tenant compte de cette réalité.

Pour les DSI et les dirigeants d’ingénierie qui évaluent les plateformes de développement d’IA aujourd’hui, quels sont les plus grands erreurs que les organisations commettent lors du déploiement d’outils de codage IA, et comment peuvent-elles les éviter ?

Une erreur courante est de se concentrer uniquement sur la capacité du modèle. Les modèles plus grands sont certainement un composant critique, mais la fiabilité dans les environnements du monde réel dépend de la façon dont l’IA comprend le système dans lequel il opère.

Une autre erreur est de déployer des outils d’IA sans tenir compte des exigences de gouvernance et de sécurité. Les entreprises ont besoin de politiques claires sur la façon dont le code est accédé, comment les modèles sont déployés et comment les sorties sont validées.

Enfin, les organisations s’attendent parfois à ce que l’IA apporte des gains de productivité immédiats sans adapter les flux de travail ou fournir un contexte suffisant. Les déploiements réussis impliquent généralement l’intégration de l’IA dans les processus de développement existants et la connexion à l’architecture et au code de l’organisation.

Quand ces éléments se combinent, l’IA peut devenir un accélérateur puissant pour le développement logiciel plutôt que juste un autre outil.

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