Du YC à AWS : Tusk transforme le trafic de production en tests optimisés par l’IA sur AWS

Le code généré par l’IA redéfinit rapidement le développement logiciel. Ce qui prenait autrefois des jours prend désormais des heures, et ce qui exigeait des équipes peut de plus en plus être réalisé par des individus. Le problème ? Plus de code est généré que jamais auparavant. Cela signifie davantage de demandes d’extraction, davantage de cas extrêmes et une demande accrue pour les équipes d’ingénierie. Le temps gagné sur la rédaction ne vaut pas grand-chose s’il est simplement englouti par des exigences accrues en matière d’assurance qualité, une responsabilité qui incombe de plus en plus à ceux qui élaborent le logiciel.

Tusk, une start-up pionnière et ancienne élève de Y Combinator (YC), aide les entreprises à prévenir les bogues qui seraient autrement ignorés par les agents de codage et les humains grâce à des tests optimisés par l’IA basés sur un trafic de production réel. En utilisant des modèles de fondation (FM) performants dans Amazon Bedrock, Tusk signale automatiquement les problèmes tels que les régressions inattendues et la dérive des contrats d’API avant la fusion du code, permettant ainsi aux équipes d’ingénierie de se concentrer sur des tâches à plus forte valeur ajoutée.

Les tests logiciels sont basés sur la réalité et non sur des suppositions

Fondée en 2023 par deux diplômés de l’université de Berkeley, Tusk aide les entreprises à envoyer du code de qualité grâce à des tests générés par l’IA et basés sur le comportement réel des utilisateurs. « Tusk transforme votre trafic de production en tests unitaires et API réalistes », déclare Marcel Tan, PDG. « Pour ce faire, nous enregistrons des traces lorsque les utilisateurs interagissent avec votre application dans le monde réel, et nous relisons ces traces en fonction des modifications apportées à votre code afin de détecter et d’empêcher les régressions. » Cela représente un changement significatif dans la manière dont les entreprises de toutes tailles peuvent aborder les tests de code à l’ère de l’IA.

« Si vous considérez toutes les meilleures équipes d’ingénierie actuelles, ce sont généralement les personnes chargées de l’assurance qualité qui créent également la fonctionnalité », explique M. Tan. Le raisonnement qui sous-tend cette tendance est solide. Ces équipes disposent d’un meilleur contexte pour aborder les tests, car ce sont elles qui mettent à jour et optimisent le code. Cependant, à mesure que le volume de code augmente, la correction des bogues prend de plus en plus de temps. « Dans le passé, l’assurance qualité représentait environ la moitié de votre cycle de distribution. Avec les agents de codage actuels, les meilleurs ingénieurs consacrent 90 % de leur temps à l’assurance qualité, ce qui n’est pas une bonne utilisation de leur temps », explique M. Tan.

« La plupart des tests écrits manuellement ou à l’aide de l’IA ne reflètent pas réellement la manière dont les utilisateurs interagissent avec votre produit dans le monde réel », explique M. Tan. « Parce que nous captons le trafic réel, nous proposons une couverture complète des cas extrêmes qui seraient autrement passés inaperçus. » Cela inclut les défaillances silencieuses résultant d’un comportement sémantique involontaire. Dans ces cas, une sortie semble valide mais ne fonctionne pas correctement. Tusk exécute et itère les tests qu’il génère et, en les évaluant par rapport au trafic de production réel, il permet de détecter plus facilement des régressions qui seraient quasiment impossibles à prévoir autrement.

Incuber le succès, de la première présentation à l’adéquation entre le produit et le marché

Tusk a commencé sa vie en tant que l’un des premiers agents de codage accessibles au public. « Nous voulions créer un agent de codage qui permettrait aux chefs de produit, aux ingénieurs logiciels et même aux personnes non techniques de passer d’un ticket JIRA à une demande d’extraction », explique M. Tan. « Nous avons sans doute été le premier agent capable de le faire dans une base de code mature. » Après avoir présenté cette première version de son produit, l’entreprise a été acceptée dans le lot YC W24, où le Tusk d’aujourd’hui a commencé à prendre forme.

« Les trois mois du YC sont très intensifs », explique M. Tan. « Il s’agit essentiellement d’un séance de travaux pratiques et vous ne pensez à rien d’autre qu’à la start-up ». Pour Tusk, l’un des aspects les plus précieux de l’expérience du YC a été d’entrer en contact avec d’autres fondateurs, y compris un groupe plus restreint et mieux organisé au sein du groupe. Ces groupes se réuniraient régulièrement pour discuter de leurs objectifs et de leurs progrès. « C’est très motivant, car on peut voir à quelle vitesse les gens peuvent évoluer en l’espace de trois ou quatre jours. Ce sentiment d’urgence est inhérent à la start-up : il lui confère un bon ADN », explique M. Tan.

L’une des leçons durables de l’incubateur est la valeur de l’engagement direct avec les clients. « Au lieu d’essayer de comprendre les besoins de nos clients, nous avons été encouragés à leur demander directement », explique M. Tan. « Cela semble tellement évident, non ? Parfois, le conseil le plus simple est le meilleur. » En fait, c’est après avoir consulté les clients que l’équipe Tusk a commencé à repenser l’orientation de son activité.

« Nos clients ont ensuite souligné à plusieurs reprises que le fait de générer davantage de demandes d’extraction  créait plus de travail pour leurs ingénieurs », explique M. Tan. Ceci, associé à la disponibilité croissante de compagnons de codage alimentés par l’IA, a clairement indiqué la direction que prenait l’industrie. « Écrire du code devenait une commodité », explique M. Tan. « Nous avons réalisé que dans 18 mois, le problème serait de vérifier que le code fonctionne. » En conséquence, l’équipe a changé d’orientation, réorientant l’entreprise autour des tests et jetant les bases du produit qu’elle propose aujourd’hui.

La liberté de se concentrer sur le client, et non sur les coûts

Peu après avoir quitté le YC, Tusk a commencé à collaborer avec AWS. L’entreprise a participé à AWS Activate, un programme dédié au soutien des start-ups avec une expertise technique, des opportunités de mise sur le marché et un financement sous forme de crédits AWS. « Cela a été incroyable », déclare Sohil Kshirsagar, directeur technique. « L’équipe AWS a été très réactive, même lorsque nous étions beaucoup plus petits. De plus, le montant des crédits que nous avons reçus nous a beaucoup aidés. Il s’agit essentiellement d’un investissement que nous obtenons sans aucun capital. » C’est particulièrement précieux pour les start-ups qui s’appuient sur l’infrastructure de l’IA.

« En tant que start-up préIA, vos coûts liés au cloud seraient limités à des éléments tels que l’hébergement et le stockage, mais aujourd’hui, les grands modèles de langage (LLM) constituent votre principal coût », explique M. Kshirsagar. « Si nous n’avions pas ces crédits, chaque fois que nous offrions un produit au client, nous nous demanderions combien cela va coûter. Cela va-t-il affecter notre piste ? Mais maintenant, nous pouvons simplement résoudre le problème et trouver comment l’optimiser après coup. »

Outre les économies réalisées, AWS Activate a permis à l’équipe Tusk de se concentrer sur l’essentiel. « Il y a déjà tellement de choses qui nous préoccupent chaque jour. Vous ne voulez pas vraiment que votre utilisation du cloud ou vos dépenses en fassent partie », explique M. Kshirsagar. « Activate nous permet de rester concentrés sur le client, à savoir quel est le problème qu’il rencontre et comment le résoudre au mieux, sans nécessairement penser aux implications financières à terme. »

L’observabilité en temps réel rencontre une intelligence évolutive

Tusk utilise une combinaison de services AWS pour l’inférence et la surveillance. « Amazon Bedrock est notre principale solution d’inférence LLM », déclare M. Kshirsagar. « L’un des principaux avantages que cela nous apporte est l’inférence interrégionale évolutive, ce qui est important dès le début lorsque vous pouvez passer de un à dix clients en quelques semaines et que vous devez augmenter les limites tarifaires. »

Les modèles utilisés par Tusk dans Amazon Bedrock favorisent la compréhension sémantique et la classification par régression. « Lorsque Tusk examine les différences dans les résultats d’une réponse d’API , il doit tenir compte du fait que vous êtes peut-être en train de modifier la structure de l’API ou de modifier légèrement la réponse », explique M. Kshirsagar. « Nous utilisons des modèles de raisonnement dans Bedrock pour déterminer si ce changement est une régression ou une mise à jour prévue en fonction du contexte de la demande d’extraction. »

Amazon Bedrock aide Tusk à optimiser l’utilisation des modèles et des jetons. « Nous changeons souvent de modèle en fonction de la complexité de la tâche », explique M. Kshirsagar. Si un changement de modèle est nécessaire, Amazon Bedrock facilite ce processus, souvent aussi simple que la mise à jour de l’identifiant du modèle.

Au-delà du goulot d’étranglement en matière d’assurance qualité, vers une assurance de bout en bout

Alors que Tusk continue de croître et d’évoluer, l’état d’esprit centré sur le client, développé pendant au cours du YC, reste central. « Nous assistons à un épuisement professionnel chez les ingénieurs », explique M. Tan. « Nous voulons les aider à passer moins de temps à effectuer des tests et à consacrer plus de temps à des activités amusantes, comme concevoir des solutions à des problèmes complexes ou travailler sur des fonctionnalités destinées aux utilisateurs. »

Pour concrétiser cette ambition, Tusk renforce sa collaboration avec AWS en utilisant Amazon Bedrock. « Alors que nous continuons à proposer de nouvelles fonctionnalités et à toucher de nouveaux clients, notre utilisation d’Amazon Bedrock est susceptible d’évoluer de façon exponentielle », déclare M. Kshirsagar. « Nous avons également discuté avec AWS de la possibilité de peaufiner des modèles ou de créer et de former nos propres modèles sur les instances AWS Trainium EC2. »

« Nous avons l’intention de devenir la plateforme de test tout-en-un », déclare M. Tan. « Nous couvrirons intelligemment tous les principaux types de logiciels de test sur lesquels les entreprises s’appuient : tests unitaires, d’intégration (API) et tests de bout en bout. Cela permettrait à Tusk de fonctionner comme un ingénieur de test d’IA au niveau du personnel que tout le monde peut engager, même pour une start-up composée d’une seule personne, pour contrôler les modifications de code et les demandes d’extraction que vous créez. C’est la vision ultime. »