Ali-Reza Adl-Tabatabai, Fondateur et PDG de Gitar – Série d’entretiens

Ali-Reza Adl-Tabatabai, Fondateur et PDG de Gitar, est un vétéran du leadership technique dont la carrière s’étend sur certaines des entreprises technologiques les plus influentes de la Silicon Valley, notamment Uber, Google, Facebook, Intel, AMD et IBM. Avant de lancer Gitar en 2023, il a occupé le poste de Directeur senior de l’ingénierie chez Uber, où il a aidé à diriger les initiatives de plate-forme de développement de l’entreprise, après avoir occupé des postes de leadership chez Google pour superviser l’ingénierie de la fiabilité des sites pour des produits tels que Communications, Photos, Social, Cloud et infrastructure technique.

Au début de sa carrière, il a travaillé sur les technologies de compilation, les machines virtuelles, les systèmes de calcul parallèle et l’optimisation du matériel chez Intel Labs et chez l’équipe HipHop VM de Facebook, tout en enseignant la conception avancée de compilateurs à l’Université de Stanford. Son expérience de plusieurs décennies dans les langages de programmation, la fiabilité des infrastructures, les outils de développement et l’architecture des systèmes à grande échelle l’a positionné comme une figure éminente dans le paysage de l’ingénierie logicielle alimentée par l’IA en évolution.

Gitar se concentre sur un problème croissant qui émerge de l’essor du développement de logiciels assisté par l’IA : la validation et la sécurisation du volume considérable de code généré par machine qui entre maintenant dans les systèmes d’entreprise. La plate-forme utilise des agents IA pour automatiser la révision de code, enquêter sur les échecs de pipeline CI/CD, identifier les bogues et les vulnérabilités, recommander des correctifs et s’intégrer directement dans les flux de travail d’ingénierie existants via des outils tels que GitHub, GitLab, Jenkins, Jira et Slack. Plutôt que de concurrencer uniquement la génération de code IA, l’entreprise se positionne autour de ce qu’elle décrit comme des « portes de qualité agente », aidant les équipes d’ingénierie à maintenir la fiabilité, la sécurité et la surveillance opérationnelle à mesure que le développement de logiciels passe de plus en plus à des flux de codage autonomes et assistés par l’IA.

Vous avez dirigé l’ingénierie chez Uber, Google et Intel Labs, en travaillant sur de grandes plateformes de développement et d’infrastructure. Quelles expériences spécifiques de ce parcours vous ont amené à fonder Gitar, et pourquoi vous concentrez-vous sur la validation de code plutôt que sur la génération de code ?

À travers Uber, Google, Facebook et Intel Labs, j’ai travaillé sur des plateformes de développement à différentes échelles, et la même leçon est apparue à chaque fois : l’expérience du développeur est un avantage concurrentiel. Les outils de qualité attirent et retiennent les meilleurs ingénieurs et permettent aux entreprises de progresser rapidement. Les développeurs veulent des outils rapides et sans bruit qui les maintiennent dans le flux et automatisent les tâches fastidieuses. Mais les outils de développement sont profondément fragmentés, et la plupart des entreprises consacrent d’énormes ressources à créer une expérience cohérente. J’ai vu de visu à quel point il y a un levier à actionner pour résoudre ce problème.

L’IA change l’équation en rendant possible l’automatisation de beaucoup plus de flux de travail de développement que jamais auparavant. La génération de code est déjà bien couverte, mais cela n’a fait que déplacer le goulet d’étranglement en aval, vers la validation, la refactoring et la maintenance du code que nous produisons maintenant à un volume sans précédent. C’est là que Gitar se concentre. Lorsque l’IA écrit plus de code, la ressource rare n’est pas la génération ; c’est la confiance, la correction et la maintenabilité de ce qui est expédié. La validation de code est la partie du flux de travail qui détermine si le code généré par l’IA peut réellement atteindre la production en toute sécurité, et c’est le problème le plus difficile et le plus précieux à résoudre.

Avec l’essor du code généré par l’IA, de nombreuses équipes sont maintenant confrontées à ce que certains appellent la surcharge de code. Quelle est l’importance de ce problème au sein des entreprises aujourd’hui, et où les équipes ont-elles le plus de mal ?

Le changement n’est pas dans l’écriture de code. Cette partie est déjà en train de progresser plus vite que la plupart des équipes ne peuvent l’absorber. Ce qui a changé, c’est tout ce qui suit. Les outils IA génèrent un flux constant de demandes de tirage, souvent plus rapidement que les équipes ne peuvent les examiner, ce qui crée une pression sur les parties du système qui n’ont jamais été conçues pour ce niveau de sortie.

Chaque modification doit toujours passer par la validation. Examen de code. CI. Vérifications de sécurité. Approbations. Rien de tout cela ne disparaît simplement parce que le code est généré plus rapidement. Ce qui était autrefois un flux gérable est devenu un backlog. Les équipes ne sont pas bloquées sur les idées ou la mise en œuvre, mais sur la confiance. Peut-on expédier ? Est-ce sécurisé ? A-t-il cassé quelque chose de subtil ?

C’est là que se situe maintenant la friction. Pas dans la création, mais dans l’obtention du code sans introduire de risque.

L’industrie s’est largement concentrée sur la génération de code plus rapide. Pourquoi pensez-vous que la validation a été négligée, et pourquoi est-elle devenue plus critique maintenant ?

Parce que le système en aval de la génération de code n’a pas évolué au même rythme. Lorsque la production augmente, tout ce qui se trouve en aval est stressé. Les demandes de tirage deviennent plus importantes et plus fréquentes. Les échecs CI commencent à s’empiler. Les cycles d’examen sont compressés car personne n’a le temps de creuser chaque modification.

La qualité commence à baisser, non pas parce que les ingénieurs ne se soucient pas, mais parce que le volume force des compromis. Les équipes de plateforme prennent en charge davantage de la charge de travail, en gérant les problèmes de pipeline, en triant les échecs et en essayant de maintenir les choses en mouvement. Les ingénieurs seniors finissent par agir comme des coordinateurs, en rassemblant des journaux, en diagnostiquant des problèmes et en décidant de ce qui est sécurisé pour fusionner.

Les équipes sont confrontées à un choix qui ne fonctionne vraiment dans aucun cas. Pousser le code rapidement et traiter les régressions plus tard, ou ralentir et protéger la qualité, mais accepter que la vitesse diminue. Cette tension se manifeste actuellement dans les organisations d’ingénierie.

Gitar utilise des agents IA pour gérer les examens de code, les tests et les flux de travail CI. De quelle manière ces agents diffèrent-ils fondamentalement des outils d’analyse statique traditionnels et des pipelines basés sur des règles ?

La différence n’est pas cosmétique. Un véritable agent doit faire plus que répondre à des invites. Il doit gérer des tâches mult étapes, planifier, utiliser des outils, suivre le contexte et faire progresser les tâches sans input constant.

La plupart des systèmes ne répondent pas à cette norme. Ils génèrent des sorties, mais ils ne gèrent pas l’exécution. Lorsque ces outils sont placés dans de véritables flux de travail, les lacunes apparaissent rapidement. Ils ne réduisent pas la complexité. Dans de nombreux cas, ils ajoutent une autre couche que quelqu’un doit gérer.

C’est pourquoi la conversation passe de « avons-nous des agents » à « quel travail peut réellement être géré de manière fiable ».

La confiance est un obstacle majeur à l’automatisation dans le développement de logiciels. Comment Gitar garantit-il que son processus de validation est suffisamment fiable pour que les équipes puissent s’y fier ?

Le modèle qui fonctionne est simple. Diviser le travail en petites étapes. Définir des limites claires. Valider les sorties en continu. Maintenir les humains impliqués là où les décisions comportent des risques.

Les agents peuvent examiner le code et mettre en évidence des problèmes qui sont faciles à manquer à grande échelle. Ils peuvent analyser les échecs CI, regrouper les erreurs liées et pointer vers une cause racine probable. Ils peuvent suggérer des correctifs et, dans certains cas, les appliquer de manière contrôlée.

Cela réduit la quantité de triage manuel que les ingénieurs doivent effectuer. Il ne retire pas les ingénieurs de la boucle, mais il change où ils passent leur temps. La plupart des systèmes fonctionnent avec des points de contrôle, et non avec une indépendance complète.

Votre plateforme permet aux équipes de créer leurs propres agents. Quelle est l’importance de la personnalisation pour l’adoption des entreprises, et quels sont certains des cas d’utilisation les plus intéressants que vous voyez ?

La personnalisation est essentielle pour l’adoption des entreprises. Chaque équipe de plateforme consacre des ressources importantes pour adapter le CI à ses besoins spécifiques, et cela a traditionnellement nécessité des scripts sur mesure, des configurations, des intégrations d’outils, des processeurs de journaux et tout le ruban adhésif qui maintient l’infrastructure de développement moderne ensemble.

Gitar simplifie ce travail. Les équipes de plateforme peuvent écrire des vérifications personnalisées à l’aide d’invites en langage naturel, ce qui leur permet de valider des choses qui sont difficiles ou impossibles avec l’analyse de programme traditionnelle, par exemple, signaler des chaînes utilisateur qui sont ambigües pour la traduction, ou valider les mises à jour des fichiers AGENTS.md. Ils peuvent également automatiser des flux de travail personnalisés sur les demandes de tirage : lier les demandes de tirage aux problèmes Jira, ouvrir des tickets de suivi pour les commentaires d’examen non résolus, réessayer automatiquement les tests fragiles ou ajouter des listes de tâches personnalisées aux résumés de demande de tirage.

Les cas d’utilisation les plus intéressants ont tendance à être ceux que nous n’avions pas anticipés. Les équipes connaissent mieux leur base de code et leurs points de douleur que tout fournisseur, donc lorsqu’on leur donne une primitive qui transforme « nous souhaitons que le CI puisse vérifier X » en une invite de 10 lignes, ils commencent immédiatement à automatiser des choses que nous n’aurions jamais construites par défaut. C’est exactement ce que nous voulons.

Les équipes d’ingénierie modernes s’appuient sur une pile complexe d’outils comme GitHub, GitLab et Jira. Quelle est l’importance de l’intégration de Gitar dans les flux de travail existants plutôt que d’essayer de les remplacer ?

L’adoption dépend de la rencontre des développeurs là où ils sont déjà. Les ingénieurs ne veulent pas une autre surface à apprendre, un autre tableau de bord à vérifier, ou plus de commutation de contexte entre les outils. Ils veulent que leurs flux de travail existants deviennent plus rapides et plus silencieux. Ainsi, l’intégration profonde avec GitHub, GitLab, Jira et le reste de la pile n’est pas un « agréable à avoir » pour nous ; c’est toute la stratégie.

Mais notre ambition va plus loin que l’intégration. Nous n’essayons pas de remplacer ces outils, et nous n’essayons pas non plus de simplement les brancher. Nous automatisons les flux de travail qui s’exécutent à travers eux. L’examen de la demande de tirage, le lien du ticket, les tâches de suivi, les réessais de tests fragiles, tout cela devrait se produire de manière autonome, en arrière-plan. Et nous allons plus loin : un agent modifie directement la demande de tirage pour répondre aux commentaires d’examen et corriger les échecs CI, et gère finalement l’approbation et la fusion pour les modifications qui répondent aux politiques de l’équipe. Le rôle du développeur passe de la conduite de chaque étape à la définition de l’intention, à l’examen des résultats et à la gestion des exceptions.

L’état final n’est pas un nouvel outil que les développeurs se connectent. Ce sont les outils existants qui font plus de choses seuls, afin que les développeurs puissent rester concentrés sur le travail qui nécessite réellement leur jugement.

Vous avez suggéré que les examens de code humains pourraient finalement devenir l’exception plutôt que la règle. Qu’est-ce qui doit se passer pour que les organisations se sentent à l’aise avec ce changement ?

La confiance se construit par étapes, et non d’un seul coup. Les organisations doivent voir, avec leur propre code, que l’IA peut trouver les bogues et les vulnérabilités qui comptent vraiment et appliquer leurs règles personnalisées avec précision et une grande couverture. À partir de là, le chemin vers la fusion autonome est une progression naturelle à travers quatre niveaux de confiance croissante.

Le premier niveau est la détection. Les équipes construisent la confiance que les agents trouvent des problèmes réels avec un faible taux de faux positifs. Une fois que cette confiance est établie, ils laissent l’IA bloquer automatiquement les demandes de tirage lorsqu’elle trouve des problèmes critiques.

Le deuxième niveau est la remédiation. L’IA ne signale pas seulement les problèmes, elle les corrige, débloquant la demande de tirage et rendant le CI vert sans intervention humaine. La confiance ici signifie que l’agent peut résoudre les problèmes et les échecs CI avec précision, sans casser les choses.

Le troisième niveau est l’approbation. Une fois que les équipes voient les agents approuver de manière fiable les demandes de tirage, ils laissent l’IA approuver les demandes de tirage selon les règles qu’ils définissent. Donner aux organisations un contrôle explicite sur les conditions d’approbation automatique est ce qui rend cette étape sûre plutôt que téméraire.

Le quatrième niveau est la fusion. L’IA atterrit le changement, à nouveau selon les conditions que l’équipe est à l’aise avec. Cette étape a sa propre barre : l’agent doit résoudre les conflits de fusion avec précision, sans introduire de régressions ou de cassure du principal. Cela compte plus que les gens le réalisent, car la fréquence des conflits augmente avec le débit des validations, et le débit explose à mesure que l’IA génère plus de code. Les grandes bases de code monorepo ressentent déjà cela ; tout le monde d’autre est sur le point de le faire.

Le passage à l’IA en tant que réviseur par défaut n’est pas un seul saut de foi. C’est une échelle, et les organisations la gravissent une marche à la fois à mesure que les preuves s’accumulent.

À mesure que l’IA prend en charge davantage du processus de codage, comment voyez-vous le rôle des ingénieurs seniors évoluer au cours des prochaines années ?

Les ingénieurs seniors sont déjà en train de passer à des rôles de coordination, en rassemblant des journaux, en diagnostiquant des problèmes et en décidant de ce qui est sécurisé pour fusionner. Ce n’est pas un rôle que quiconque a prévu. C’est une réaction au système qui se brise sous la charge.

À mesure que les agents prennent en charge plus de travail de validation répétitif, les ingénieurs restent dans la boucle mais passent plus haut dans la pile. Ils passent moins de temps sur le triage manuel et plus de temps à prendre des décisions sur ce qui devrait être expédié et pourquoi.

Gitar a récemment levé 9 millions de dollars pour développer la plateforme. Quels sont vos principaux objectifs pour ce capital, et à quoi ressemble le succès au cours des 12 à 18 prochains mois ?

Le capital est destiné à deux priorités. La première est le marché : nous développons notre mouvement d’entreprise et investissons dans la sensibilisation des développeurs afin que les équipes qui pourraient bénéficier de Gitar sachent que nous existons. La deuxième est le produit : nous continuons à construire vers notre vision de validation de code et de qualité entièrement autonomes, ce qui signifie des capacités d’agent plus approfondies, une couverture de flux de travail plus large et une intégration plus étroite avec les outils que les développeurs utilisent déjà.

Le succès au cours des 12 à 18 prochains mois ressemble à une base significative de clients d’entreprise exécutant Gitar sur leurs bases de code, une communauté de développeurs qui nous reconnaît comme la référence pour la validation de code alimentée par l’IA, et des preuves claires que nos agents font plus de travail d’examen, de remédiation et de fusion de manière autonome avec le temps. Si nous sommes sur la bonne voie, la conversation dans un an ne portera pas sur la question de savoir si l’IA peut valider le code, mais sur la quantité de pipeline de validation que une équipe a confiée aux agents. Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus devraient visiter Gitar.