Jeremy Freeman, Co-Fondateur et CTO d’Allstacks – Série d’entretiens

Jeremy Freeman, Co-Fondateur et CTO d’Allstacks, est un ingénieur logiciel, architecte technologique et entrepreneur avec une carrière couvrant le développement de logiciels, l’ingénierie matérielle, l’apprentissage automatique et l’innovation de produits. Depuis la co-fondation d’Allstacks en 2017, il a dirigé l’architecture et le développement de la plate-forme principale de l’entreprise, aidant à transformer la gestion de la livraison de logiciels grâce à l’analyse prédictive et à la prévision basée sur l’IA. Avant Allstacks, Freeman a occupé des postes de direction chez Ravioli Labs et CertiRx, où il a travaillé sur l’ingénierie logicielle, la recherche, les technologies anti-contrefaçon et le développement de produits. Plus tôt dans sa carrière, il a acquis de l’expérience dans les startups, les entreprises technologiques et l’enseignement, y compris l’enseignement du développement web au Wake Technical Community College. Son expérience technique couvre les systèmes intégrés, la conception matérielle, les plates-formes logicielles à grande échelle, l’apprentissage automatique et le leadership d’ingénierie, lui donnant une perspective unique sur la construction de produits basés sur les données qui aident les organisations à améliorer les résultats de la livraison de logiciels.

Allstacks est une plate-forme d’intelligence d’ingénierie logicielle et de gestion de la chaîne de valeur qui aide les organisations à améliorer la prévisibilité et l’efficacité du développement de logiciels. La plate-forme intègre des données provenant d’outils utilisés dans tout le cycle de vie du développement de logiciels, y compris la gestion de projet, le contrôle de source et les systèmes de déploiement, puis applique l’IA et l’apprentissage automatique pour identifier les risques, prévoir les résultats de la livraison et fournir des informations exploitables. En fournissant aux dirigeants d’ingénierie et de produits une visibilité sur la santé des projets, les performances des équipes et les tendances de développement, Allstacks permet aux organisations de prendre des décisions plus éclairées, de réduire l’incertitude de la livraison et de mieux aligner les efforts d’ingénierie avec les objectifs commerciaux. Sa technologie est conçue pour aider les entreprises à aller au-delà de la planification basée sur l’intuition en exploitant les données opérationnelles en temps réel pour améliorer les performances de la livraison de logiciels et l’exécution stratégique.

Vous avez eu un parcours unique en tant que dirigeant d’équipes de recherche et d’ingénierie appliquant l’apprentissage automatique aux données de développement de logiciels, puis en co-fondant Allstacks en 2017. Quels sont les problèmes ou les lacunes spécifiques que vous avez observés qui vous ont finalement poussé à créer l’entreprise ?

Lorsque nous avons lancé Allstacks, nous avons passé beaucoup de temps à effectuer une découverte de clients, et le modèle qui est apparu était cohérent : entreprise après entreprise disposait d’énormes quantités de données et n’avait toujours aucune idée de ce qui se passait réellement. La livraison de logiciels était imprévisible, même avec certaines des personnes les plus intelligentes dans la salle. Ce problème n’avait pas été résolu.

Ce qui est devenu clair assez rapidement, c’est que ce n’était pas un problème de rapport ou d’intégration. C’était un problème de relation. Pour savoir si quelque chose est à risque, vous devez savoir comment un élément de travail se connecte à une branche, la branche se connecte à une PR, la PR se connecte à un objectif de sprint et l’objectif de sprint se connecte à une initiative commerciale. Ce graphique n’existe pas par défaut nulle part dans la chaîne d’outils standard. Vous devez le construire. Et le construire correctement est fondamentalement un problème d’inférence, ce qui rend l’expérience en apprentissage automatique directement utile.

Notre objectif dès le départ n’était pas de rendre un développeur individuel plus rapide sur la fonctionnalité X. C’était de rendre toute l’organisation meilleure. Comment aligner les efforts d’ingénierie sur les résultats commerciaux ? Comment faire en sorte que l’ingénierie serve réellement l’entreprise plutôt que de simplement exister à côté d’elle ? Vous avez besoin d’une meilleure compréhension des relations de données pour répondre à ces questions. Ce sont ces questions qui ont guidé presque toutes les décisions de produits que nous avons prises.

Allstacks se concentre sur l’analyse des données dans tout le cycle de vie du développement de logiciels. Quels types de signaux ou de modèles sont les plus prédictifs pour identifier les risques de livraison précoces ?

Je ne pense pas qu’il y ait un ensemble unique de métriques qui prédit le bon et le mauvais, mais plutôt des modèles pour différentes phases et types d’organisations. Ce que j’ai trouvé plus utile, c’est de reconnaître que les organisations d’ingénierie passent par des saisons d’amélioration. Ce mois-ci, c’est la performance de la base de données. Le mois prochain, c’est la communication inter-équipes. Ensuite, c’est « pourquoi ne pouvons-nous pas fermer de PR ? » Ensuite, c’est l’observabilité. En tant que dirigeant d’ingénierie, vous êtes submergé de signaux : certains diagnostiques, certains de surveillance et beaucoup qui ne sont que du bruit.

Ce qui aide, c’est de commencer par le problème que vous voyez réellement, et non par une métrique que vous souhaitez améliorer. Si vous demandez « pourquoi il semble que nous livrons moins que l’année dernière », c’est le bon point de départ. À partir de là, je pense que vous avez besoin de trois types de métriques : premièrement, comment savez-vous que le problème est réel (peut-être le nombre de PR par développeur dans le temps) ; deuxièmement, quels changements apportez-vous et comment les suivez-vous en cours de route (disons, l’adoption d’un réviseur de PR IA si c’est votre intervention) ; et troisièmement, à quel point ce problème est-il important pour l’entreprise. Votre instinct pourrait être correct que vous livrez 20 pour cent moins de code, mais l’histoire réelle pourrait être que la QA prend maintenant trois fois plus de temps. Vous avez besoin de ces trois lentilles pour savoir si vous résolvez la bonne chose.

Vous avez travaillé dans des secteurs tels que les soins de santé, l’énergie et la technologie. Comment les défis de la livraison de logiciels diffèrent-ils entre ces secteurs, et comment cela a-t-il façonné la plate-forme Allstacks ?

Je valorise vraiment mon expérience dans des secteurs non purement technologiques. Dans les entreprises SaaS, il est facile de se perdre dans l’idée que le logiciel lui-même est l’objectif. Lorsque vous êtes dans un secteur où vous n’êtes pas directement en train de vendre le logiciel, votre rôle devient beaucoup plus clair : la technologie est là pour soutenir l’entreprise. Je plaisante souvent en disant que si l’entreprise pouvait accomplir tout cela à la même vitesse sans avoir à faire face à moi, elle choisirait cette option sans hésitation.

Cette perspective est en fait utile. Cela contextualise ce que nous faisons tous dans cette industrie et remet certains débats technologiques à leur place. L’entreprise ne se soucie pas de savoir si vous utilisez Python ou Go. Passer des cycles sur cette réécriture n’est probablement pas où se trouve le véritable retour.

Ce qui reste constant dans tous les secteurs, cependant, c’est le problème de fragmentation. Quel que soit le secteur, chaque organisation d’ingénierie a des données éparpillées sur une douzaine d’outils avec une connectivité limitée entre eux. Les détails varient : les industries réglementées ont des cycles de planification plus longs et une tolérance plus faible à l’ambiguïté dans les exigences, car le coût de construction de la mauvaise chose est plus élevé. Les entreprises technologiques à haute vélocité accumulent plus rapidement des dettes cachées. Mais le mode de défaillance de base est le même. Les équipes peuvent vous dire ce qui a été livré. Ils ne peuvent pas tracer pourquoi quelque chose a glissé, ce que cela a coûté ou où le risque était visible avant qu’il ne devienne un problème. C’est ce qui a façonné la façon dont nous avons construit la plate-forme.

Il y a un récit croissant selon lequel l’IA est en train d’accélérer la programmation elle-même tout en exposant des faiblesses ailleurs. Pourquoi les exigences, la planification et la préparation des spécifications deviennent-elles les vrais goulets d’étranglement ?

Nous voyons cela quotidiennement. Avec un bon agent et un harnais solide autour de lui, vous pouvez passer d’une idée, parfois directement de la bouche d’un client, à la production en quelques heures.

Une partie de ce qui rend ce changement si significatif est le changement de la boucle de rétroaction. Avec des outils de type copilot, l’humain est dans la boucle sur chaque suggestion. L’IA propose une complétion ; vous l’acceptez ou la refusez immédiatement. Lorsqu’il est incorrect, vous le découvrez rapidement. La zone d’impact d’une mauvaise suggestion est d’une ligne de code. Les outils d’agent fonctionnent différemment : vous donnez à l’agent un objectif, il décompose le travail, exécute un plan à plusieurs étapes et livre un module fonctionnel. L’humain examine le résultat, et non chaque étape. Lorsque la spécification est incorrecte, l’agent construit toute la mise en œuvre jusqu’à la mauvaise spécification et vous découvrez cela lors de l’examen.

Cela semble être un avantage pur jusqu’à ce que vous reconnaissiez ce que le retard précédent faisait réellement. Le retard servait un but réel. Plusieurs tours de personnes intelligentes examinant, planifiant, testant et travaillant sur des idées pour produire un meilleur système.

La tentation maintenant est de contourner tout cela et de laisser les choses se faire. Mais les agents et les harnais ne sont pas encore prêts pour l’ensemble du cycle de vie du développement logiciel. La vitesse est réelle. La fonction de contrôle de la qualité qui se produisait à travers toutes ces étapes plus lentes n’a pas été remplacée. C’est l’écart.

De nombreuses organisations mesurent toujours la productivité à l’aide de métriques obsolètes. Qu’est-ce que les dirigeants se trompent fondamentalement sur la productivité dans un environnement de développement basé sur l’IA ?

Les gens ont considérablement mûri sur ce sujet depuis que nous avons lancé Allstacks. La mesure a évolué vers des choses qui comptent vraiment, et les cadres sont devenus plus sophistiqués. L’IA bouleverse tout cela.

Le développement de logiciels traditionnel était fondamentalement limité par la vitesse à laquelle un développeur pouvait écrire du code qui répondait aux exigences de l’entreprise et de la technologie sous-jacente. Ce coût approche zéro. Ce à quoi nous nous dirigeons, c’est quelque chose de plus proche d’un développeur individuel en tant que gestionnaire d’agents. Ce modèle nécessite une approche complètement différente de la mesure de la productivité, basée sur autre chose que les jetons générés ou les heures de développeur passées.

Une partie du danger avec les métriques actuelles est qu’elles cachent ce qui se passe réellement au niveau de l’équipe. Les ingénieurs seniors avec des outils d’IA sont en train de renforcer leur avantage : ils ont le contexte du codebase et le jugement pour diriger la sortie de l’agent et attraper ses défaillances. Les ingénieurs en début de carrière génèrent le même volume de code, mais passent plus de temps à auditer la sortie qu’ils ne peuvent pas évaluer pleinement. La vitesse globale semble bonne, peut-être même améliorée. L’écart entre ces deux groupes n’apparaît nulle part dans un tableau de bord standard. La bonne question à poser n’est pas « combien de fois allons-nous plus vite » mais « combien de ce que nous avons livré était correct dès la première fois ».

Nous n’avons pas encore de consensus de l’industrie sur le bon modèle de mesure, mais les équipes qui commencent à suivre la qualité de la production et le taux de reprise, et non seulement le débit et l’adoption, seront mieux positionnées que les équipes qui attendent que quelqu’un d’autre le fasse.

Votre plate-forme connecte des données provenant d’outils tels que des systèmes de gestion de projet et des référentiels de code. Quelle est l’importance de l’unification de ces sources de données fragmentées, et que se passe-t-il lorsque les organisations ne parviennent pas à le faire ?

Allstacks a réussi dans cet espace parce que nous avons commencé à construire des graphiques de contexte avant même que cela ne devienne un terme. Nous avons reconnu tôt qu’il était nécessaire de connecter toutes les données ensemble pour répondre aux questions que les clients posaient réellement.

Lorsque cette connexion n’existe pas, l’IA qui fonctionne sur vos données d’ingénierie ne peut voir qu’une partie de l’image. Elle peut analyser ce qui se trouve dans votre système de gestion de projet. Elle peut analyser ce qui se trouve dans votre référentiel de code. Ce qu’elle ne peut pas faire, c’est retracer un retard de livraison à une dépendance bloquée à travers trois outils, car la relation entre ces signaux n’existe pas dans la couche de données. Vous obtenez une analyse superficielle au mieux, et des recommandations confiantes et incorrectes au pire. La qualité du modèle ne résout pas cela. Vous pouvez mettre le modèle le plus capable disponible sur des intégrations d’API brutes et toujours manquer la véritable cause d’un problème, car les données ne codent pas la relation entre les signaux. Données de mauvaise qualité, résultats de mauvaise qualité, quel que soit à quel point le modèle est intelligent.

Cette connexion est la fondation. C’est ce qui nous a permis d’être les premiers sur le marché avec des capacités qui n’ont toujours pas été reproduites.

À mesure que les agents d’IA sont de plus en plus intégrés dans les flux de travail de développement, à quoi ressemble une organisation d’ingénierie bien préparée par rapport à une qui ne l’est pas ?

Ironiquement, ce n’est pas très différent d’être prêt à accueillir une classe d’étudiants en stage. Vous avez besoin de suites de tests automatisées solides, d’une documentation solide, d’un pipeline CI/CD mature et des garde-fous que vous mettriez en place lorsque vous ajoutez un développeur de confiance mais non formé à l’équipe.

Ce qui est également important, et que les gens ont tendance à sous-estimer, c’est de revenir régulièrement sur les bases : vos règles d’agent, vos fichiers AGENTS.MD. Vous pouvez faire un bon premier passage, mais il est facile de se laisser aller à un rythme de livraison dans la nouvelle façon et oublier que vous pouvez en fait former à l’écart beaucoup de mauvaises valeurs par défaut. Des choses comme enseigner à l’agent à exécuter des tests avant chaque validation ne devraient pas nécessiter un rappel humain à chaque fois.

Une question de diagnostic que je poserais à tout dirigeant d’ingénierie : pouvez-vous me dire ce que vos agents ont produit au sprint précédent, lequel de cette production a été accepté tel quel par opposition à révisé, et où l’effort de révision a été concentré ? Si vous pouvez répondre à cela, vous avez l’instrumentation pour améliorer. Si vous ne pouvez pas, vous volez à l’aveugle.

Vous avez souligné l’importance de l’alignement des travaux d’ingénierie sur les résultats commerciaux. Comment les organisations peuvent-elles combler cet écart de manière pratique et mesurable ?

J’ai vu deux modes de défaillance principaux. Le premier sont les entreprises qui n’associent pas les équipes d’ingénierie aux produits. De nombreuses structures d’équipe sont des héritages et ont été en place depuis longtemps. Une équipe peut posséder une partie de trois produits différents, tandis qu’une autre possède quatre produits entièrement. L’investissement en ingénierie se résume en grande partie au nombre de personnes, et lorsque les équipes ne sont pas alignées sur les produits, il devient très difficile de voir où les attentes commerciales divergent de la réalité.

Le deuxième mode de défaillance est de ne pas tenir compte de tout le travail qui va dans la construction et la maintenance de logiciels. Il y a une grande catégorie de travail d’ingénierie invisible pour l’entreprise. Mon exemple préféré est la mise à jour des packages. Les dirigeants non techniques ont souvent du mal à comprendre la valeur ou pourquoi cela se poursuit et est imprévisible. Mais ils peuvent comprendre les catégories d’investissement. Si vous le formulez comme « mises à jour de sécurité critiques » et montrez en moyenne combien de capacité cela consomme, vous leur parlez dans un langage avec lequel ils peuvent travailler.

Si vous demandez à un dirigeant commercial de choisir entre certaines mises à jour de package npm et la fonctionnalité dont il a besoin pour conclure un accord, la fonctionnalité gagne à chaque fois. Mais si vous le formulez comme « nous sortons de la conformité SOC ou nous livrons cette fonctionnalité », vous lui montrez maintenant deux compromis qu’il peut réellement évaluer. Ce repositionnement est le jeu. Nous avons vu des clients réduire leur temps de rapport de capitalisation de R&D de plus de deux tiers simplement en rendant ce travail de classification automatique plutôt que manuel. Le mécanisme est le même, que l’objectif soit la déclaration de capitalisation, la justification de l’effectif, ou la preuve du retour sur investissement en IA : les données connectées remplacent les tableurs corrélés.

Étant donné votre expérience dans l’ingénierie pratique et l’enseignement du développement web, comment voyez-vous le rôle des développeurs évoluer à mesure que l’IA prend en charge une partie croissante de la charge de travail de codage ?

Franchement, je suis un peu inquiet, même si je fais confiance aux personnes intelligentes pour résoudre cela.

Mes préoccupations sont réelles. Les diplômés fraîchement sortis des universités entreront bientôt sur le marché du travail sans avoir jamais codé dans un monde sans agents de codage. L’éducation a-t-elle rattrapé ce retard ? Les outils évoluent rapidement ; l’enseignement supérieur ne suit pas toujours le rythme. L’autre changement que je surveille est le flou entre les ingénieurs seniors et les personnes seniors du produit. Les praticiens les plus performants dans le nouveau modèle sont des ingénieurs qui sont profondément investis dans la réflexion produit.

Ce qui devient plus précieux, c’est le jugement : la capacité à définir un problème avec précision suffisante pour qu’un agent puisse le résoudre, évaluer si la solution est correcte et attraper les défaillances subtiles qui passent le CI mais créent des problèmes architecturaux plus tard. Les ingénieurs seniors renforcent leur avantage : ils ont le contexte du codebase et le jugement pour diriger la sortie de l’agent et attraper ses défaillances. La préoccupation est pour la trajectoire de carrière plus précoce. La façon traditionnelle de construire ce jugement était d’écrire beaucoup de code et d’apprendre des erreurs. Cette boucle de rétroaction change de manière que l’industrie n’a pas encore pleinement résolue.

Cela étant dit, l’histoire offre un certain réconfort. Il y avait un contingent important de personnes qui croyaient que les compilateurs mettraient les développeurs d’assembleur au chômage. Le changement technologique s’est produit comme ils l’avaient prédit. Que s’est-il passé pour les développeurs qui n’ont pas suivi le même scénario ? Au cours de la décennie suivante, le nombre total de développeurs a augmenté. Beaucoup de ces programmeurs d’assembleur ont appris un nouveau langage et ont excellé grâce à leurs connaissances fondamentales. Je pense qu’une version de ce modèle se reproduit à nouveau.

En regardant vers l’avenir, comment voyez-vous l’IA remodeler le cycle de vie du développement de logiciels au cours des trois à cinq prochaines années, et où les entreprises gagneront-elles le plus grand avantage concurrentiel ?

Nous allons assister à une course aux armements de fonctionnalités sans précédent. À mesure que le coût de construction approche zéro, les entreprises, même les grandes, sont confrontées à une nouvelle contrainte : collecter et valider suffisamment de rétroaction des clients pour continuer à construire des choses de qualité à grande échelle.

Le changement qui doit se produire est que la barre pour ce qui est construit doit monter. La contrainte actuelle dans la plupart des organisations d’ingénierie est simple : cinq priorités principales, peut-être deux livrées. Avec les agents, le ratio s’inverse. Vous pourriez avoir cinq en tête, dix suivants et vingt peut-être sur la liste, et livrer cent. La question à laquelle personne n’a encore pleinement répondu est comment empêcher que ces soixante-cinq derniers ne soient mal conçus et mal exécutés.

Deux choses dont je suis assez sûr pour la fenêtre de trois à cinq ans. Premièrement, l’avantage concurrentiel dans l’IA d’ingénierie viendra de la profondeur et de la largeur du contexte, et non de la qualité du modèle. Les modèles deviennent des éléments de base ; chaque outil en aura des capables. Ce qui différenciera les plates-formes leaders est à quel point elles comprennent votre organisation spécifique : vos référentiels, votre structure d’équipe, votre historique de livraison, vos modèles de déploiement. Les outils qui connaissent votre système produiront fondamentalement des réponses différentes de ceux qui ne le font pas. Deuxièmement, le passage de la réaction à la proactivité. Les outils d’aujourd’hui répondent aux questions lorsqu’on les pose. Dans quelques années, les outils leaders observeront en continu et feront surface des risques avant que vous ne les demandiez. Les organisations qui construisent cette couche de contexte maintenant sont en train de renforcer leur avantage. La prochaine génération d’outils doit résoudre le problème de la qualité à grande échelle, et les organisations qui le résolvent en premier auront un véritable avantage.

Je vous remercie pour cette grande interview. Les lecteurs qui souhaitent en savoir plus peuvent visiter Allstacks.