Codage agentique : table ronde avec des leaders du secteur

Bonjour à tous

Vous avez entendu de nombreux Googlers Android cette semaine, ou ces deux derniers jours.

Nous avons donc pensé qu'il serait intéressant de clore la conférence en écoutant des personnes extérieures, issues de la communauté des développeurs Android.

Nous allons parler du codage agentique et de son impact concret.

Commençons par nous présenter.

Je m'appelle Ben et je fais partie de l'équipe Android DevRel.

Vous m'avez déjà entendu une fois lors de cette conférence, mais passons en revue les intervenants.

Bonjour à tous.

Je m'appelle Vinay et je soutiens les efforts de Databricks en matière d'outils d'IA.

Je suis ravi d'être ici.

Bonjour, je m'appelle Luis Artola.

Je travaille pour Google Maps.

Je dirige des équipes qui utilisent l'IA pour créer des expériences agentiques et améliorer le cycle de développement logiciel.

Bonjour, je m'appelle Annyce Davis.

Je travaille chez Ford.

Je dirige des équipes d'ingénieurs qui développent nos produits d'abonnement et de fidélité.

Bonjour à tous.

Je m'appelle Ty Smith.

Je travaille chez Uber, où j'aide nos développeurs.

C'est le cas depuis très longtemps.

Ces deux dernières années, nous nous sommes beaucoup concentrés sur cette nouvelle période passionnante que nous vivons avec les outils d'IA.

Bonjour à tous.

Je m'appelle Kaushik Gopal.

Je travaille en tant qu'ingénieur principal chez Instacart, et j'ai lancé un podcast sur le développement Android appelé Fragmented.

Aujourd'hui, comme l'a dit Ty, nous avons un peu changé de stratégie et nous parlons de développement de l'IA.

Très bien.

Nous avons donc 30 minutes.

Je pense que le temps va passer très vite, alors nous allons passer directement aux questions les plus importantes.

Chez Android DevRel, nous avons toujours dit que nous voulions rendre la création d'applications plus rapide et plus facile.

Maintenant que l'IA est là, vous nous avez entendus dire : "C'est effectivement le cas.

Nous pensons qu'il est plus rapide et plus facile de créer des applications."

Mais je me pose la question : est-ce que nous livrons vraiment des applications plus rapidement, ou est-ce que nous générons simplement une tonne de code qui ne mène nulle part ?

C'est parti, Vinay.

OK.

Oui, on se regarde tous.

fantastique.

Si l'on s'en tient aux chiffres, nous constatons une accélération massive de la production en termes de demandes d'extraction et de lignes de code. Par conséquent, nous sommes également confrontés à des problèmes de scaling, même pour des aspects tels que l'emplacement de stockage de notre code.

Cette accélération est donc bien réelle.

Ce qui n'est pas évident, c'est l'impact sur les résultats. Je pense que l'ensemble du secteur essaie de trouver la bonne métrique pour mesurer les résultats et savoir comment ils impactent le chiffre d'affaires.

Mais je le vois clairement en action.

Je pense que nous avons livré plus de code au cours des six derniers mois que pendant une très longue période auparavant (je ne donnerai pas de chiffre précis).

Par conséquent, je pense que notre stratégie a changé, même en ce qui concerne la mesure de la productivité.

En effet, il existe différentes façons de l'envisager.

Nous essayons de trouver comment augmenter la médiane, n'est-ce pas ?

En effet, lorsque l'on examine les valeurs aberrantes et la médiane, on constate un écart de 5 à 10 fois entre ces deux catégories de personnes. Notre objectif est donc de relever le niveau de base, d'augmenter la médiane et de rendre ces personnes aussi productives que leurs pairs.

Nous voyons une combinaison de rôles.

Certaines personnes avancent beaucoup plus vite.

Certaines personnes ont une centaine de RP par jour et font un travail incroyable.

Mais il s'agit d'un type d'espace dans lequel ils opèrent.

C'est peut-être plus nouveau, ou ils maîtrisent mieux les outils.

Nous voyons aussi des personnes qui travaillent davantage sur des projets existants ou sur des plates-formes, et qui soutiennent un autre type de travail qui n'est peut-être pas aussi accéléré, car elles doivent passer plus de temps à faire appel au jugement humain et à s'assurer que les choses ne vont pas se casser.

La combinaison de ces deux éléments est nettement plus rapide qu'auparavant, mais je pense que le sujet le plus intéressant pour nous est de savoir si, même si nous livrons plus, l'entreprise livre réellement plus aux utilisateurs finaux.

C'est un domaine dans lequel nous avons investi l'année dernière pour vraiment comprendre si nous déployons des fonctionnalités plus rapidement, et pas seulement du code plus rapidement.

Les premiers signaux indiquent que oui, mais l'approche est très différente de celle des RP pures.

Je pense que ce qui s'est passé, c'est que les gens livrent beaucoup plus, vous savez, le nombre de demandes d'extraction a augmenté.

Mais je pense que même à l'heure actuelle, beaucoup de gens se demandent comment utiliser l'IA et cet outil dont nous disposons pour accélérer les processus existants.

Vous me suivez ?

Par exemple, la façon dont nous livrions le code auparavant donne l'impression que nous avons toujours considéré l'humain comme quelqu'un qui guiderait le code jusqu'à la production.

Mais je pense que ce que nous constatons aujourd'hui, c'est que oui, ça fonctionne.

Nous expédions plus de produits.

Mais nous rencontrons tous les goulots d'étranglement que nous n'aurions pas vus auparavant.

Nous n'avons jamais rencontré ces problèmes par le passé, mais maintenant, nous accélérons une partie d'un cycle en plusieurs étapes, et je pense que c'est là que ça devient intéressant.

Nous en livrons plus, mais maintenant, c'est comme un déluge d'effets."

Nous rencontrons donc d'autres problèmes.

C'est un point très intéressant, car quand on y réfléchit, il y a de nombreuses étapes différentes, mais d'un point de vue général, on peut les regrouper en trois phases, n'est-ce pas ?

Le codage, qui est clairement accéléré.

Il y a la capacité à passer en production, qui inclut un certain nombre d'éléments tels que les aspects juridiques et la confidentialité, ainsi que les éléments qui vous permettent de lancer un produit, puis il y a le lancement, n'est-ce pas ?

Ensuite, la livraison signifie vraiment des choses différentes selon l'endroit où vous vous trouvez, n'est-ce pas ?

Si vous proposez un produit entièrement côté serveur, la livraison signifie probablement un processus plus rationalisé. En revanche, lorsque vous livrez quelque chose qui va au consommateur, le fait de le mettre en expérimentation n'est que le milieu d'un parcours, n'est-ce pas ?

Vous devez encore faire beaucoup d'expérimentations et de mesures, et c'est là que cela rejoint ce que vous disiez : vous avez l'impression d'être dans une zone métropolitaine, sur une autoroute, et vous rencontrez un goulet d'étranglement, puis vous commencez à accélérer et vous vous dites : "Super !

Je vais très vite", mais vous vous heurtez au prochain goulet d'étranglement.

Et ce que l'IA met en évidence, c'est que vous voyez plus clairement les points de friction, et certains d'entre eux n'ont rien à voir avec le codage ou la technologie.

Il s'agit de processus et d'humains, et de la façon dont vous optimisez cela avec l'IA.

C'est un défi vraiment intéressant de simplifier le processus de bout en bout.

Une façon intéressante d'envisager cet espace est de se demander dans quelle mesure la personne ou l'équipe est autonome pour le livrer entièrement.

En interne, de nombreuses équipes créent des outils internes ou des éléments qui ne sont pas destinés aux clients.

Ils sont expédiés beaucoup plus rapidement, n'est-ce pas ?

Ils ont toute latitude pour les mettre immédiatement à la disposition de leurs clients.

Si vous avez un produit externe qui doit encore être testé par un utilisateur, ou, vous savez, les délais de déploiement sur l'App Store, ou, vous savez, la collaboration avec les équipes de conception et de produit, tous ces autres goulots d'étranglement s'accumulent, et les personnes qui écrivent le code ont beaucoup moins de marge de manœuvre pour agir rapidement.

Ils se heurtent donc aux autres goulots d'étranglement du système.

Je pense donc que le fait de les diviser en deux domaines distincts met vraiment en évidence les points sur lesquels vos processus métier pourraient être améliorés.

Oui, je suis d'accord. Et honnêtement, je pense que l'ingénierie n'a jamais été un goulot d'étranglement.

Je le dis depuis des années.

L'ingénierie a une façon de faire très rigide, et la question de l'entreprise était toujours : "Quel est le problème ?"

Vous obtiendrez 10 réponses différentes.

Et puis, "D'accord.

Voyons maintenant comment cela se traduit par des solutions avec des produits.

Réfléchissez-y un instant.

Oh, parlons un peu de la conception.

Envoie-le là-bas."

Quand le projet arrive à l'ingénierie, nous savons plus ou moins ce que nous devons faire.

Ensuite, nous essayons simplement d'aller sur Stack Overflow, de copier-coller quelques éléments et de publier le résultat.

Avec l'IA, les gains de temps les plus importants que je constate concernent le travail de conformité.

Ces choses où nous avons toujours voulu moderniser XYZ, ou nous avons toujours voulu mettre à niveau rapidement la version de Spring Boot.

Nous le faisons très rapidement.

Mais pour ce qui est de la livraison des fonctionnalités, je ne peux pas dire que j'ai vraiment constaté une amélioration significative.

Vous avez tous évoqué le fait que le goulot d'étranglement s'est peut-être déplacé et que vous rencontrez des processus qui n'étaient pas vraiment le goulot d'étranglement, mais qui le sont désormais.

Sauf que ces processus sont probablement issus de leçons durement apprises par le passé, n'est-ce pas ?

Ressentez-vous une pression pour changer ces pratiques ? Je pense que la plus évidente est la revue de code.

Quel est l'avenir de la revue de code ?

Que faisons-nous actuellement ?

Alors oui, j'aimerais beaucoup en savoir plus.

Cela nous ramène à ce que j'ai dit plus tôt.

J'ai l'impression que beaucoup de ces goulots d'étranglement sont dus au fait que nous avons pensé à… Si vous aviez une baguette magique, pour ainsi dire, et que vous pouviez réinventer l'ingénierie logicielle, et que vous disposiez de l'IA aujourd'hui, est-ce que nous utiliserions beaucoup les mêmes… Est-ce que nous ferions les mêmes choses ?

Par exemple, la revue de code était nécessaire, car nous avions besoin d'un humain pour valider les éléments, c'est-à-dire effectuer cette vérification finale.

Je pense que cela change aussi. Par exemple, la façon dont nous envisageons les revues de code aujourd'hui est peut-être que nous devrions être ouverts à l'idée que, si vous refactorisez le nom ou si vous essayez de refactoriser le code, et que vous savez que vous avez d'excellents tests, ce que tout le monde a clairement.

Nous avons demandé à l'IA de les écrire, tout va bien.

Non, par exemple, est-ce que vous allez faire un bien meilleur travail que cet agent ?

Je ne sais pas, par exemple, ne passez pas de temps à examiner cela.

En revanche, si vous déployez un bug et que votre PDG vous appelle pour vous dire que cela vous coûte X dollars, vous devez peut-être identifier les zones et les systèmes critiques.

Ce n'est pas un domaine critique", puis essayez de réimaginer.

Je ne pense pas que ce soit notre façon de procéder aujourd'hui, n'est-ce pas ?

Aujourd'hui, on se dit : "Tiens, il y a une demande d'extraction.

Je suis l'ingénieur.

Je me concentre sur cette chose.

Il va augmenter.

Je demande à Vinay de faire une revue de code au milieu de la nuit, parce que je veux juste que ce soit fusionné."

Par contre, nous devrions peut-être repenser un grand nombre d'entre eux.

Je suis tout à fait d'accord. Je vois la revue de code comme un problème de vérification. Ce que je veux dire par là, c'est que si j'avais une confiance absolue dans ma capacité à vérifier quelque chose, est-ce que je continuerais à examiner 100 % de mes demandes d'extraction ?

Probablement pas, n'est-ce pas ?

Les revues de code ont donc deux objectifs.

La première consiste évidemment à vérifier que nous faisons ce qu'il faut, et la seconde est l'éducation, n'est-ce pas ?

Par exemple, les personnes autour de vous savent ce que vous faites et si elles sont d'accord ou non avec cette décision.

Il existe donc une catégorie de travail que nous devrions pouvoir accélérer et intégrer au code, voire aux versions.

Cela ne s'applique peut-être pas à 100 % des cas, mais je pense que cela s'applique à un pourcentage très élevé, à deux chiffres.

Je pense que nous nous préparons à effectuer ces changements, et nous devons tous, en tant que communauté, nous assurer que nos systèmes sont prêts, car cela va arriver.

Il n'y a pas d'autre solution.

Le haut de l'entonnoir est très large, avec différentes surfaces qui vous permettent de créer plus de RP.

Et vous êtes aussi rapide que l'étape la plus lente du processus.

Pour de nombreuses équipes, il s'agit des revues de code. Les équipes qui avancent plus vite ont compris et accepté cette réalité.

Oui, et si nous sommes honnêtes avec nous-mêmes, je dirais que 70 % des demandes d'extraction que j'ai vues me semblent correctes.

Si nous recherchions toutes les bases de code du monde, les commentaires de RP seraient simplement "looks good to me" (ça me paraît bien), LGTM, partout.

En tant que professionnels de l'ingénierie, nous nous accordons parfois plus de crédit que nous ne le méritons.

On a vraiment l'impression d'y être.

"Ont-ils utilisé le modèle de commande ?"

Non, on se dit juste : "OK.

Oui, ça me semble bien."

Alors, pourquoi ne puis-je pas demander à un agent de le faire ?

Je pense vraiment que c'est l'avenir que nous allons voir, où l'on se demande ce qui nous plaît, quelles sont les caractéristiques, quels sont les comportements qui nous ont fait ressentir cela.

Ensuite, assurons-nous que l'agent recherche la même chose.

D'un autre côté, essayez aussi de réfléchir à différentes façons de réviser.

Par exemple, je connais des gens qui sont sur Twitter et qui disent ceci :

Par exemple, lorsque vous vérifiez une demande d'extraction, vous pouvez demander à vos agents de la visualiser d'une autre manière.

Hey, montre-moi un avant.

Montre-moi un après.

Montrez-moi les tests que vous avez écrits, plutôt que de me faire examiner le code ligne par ligne.

Mais cela remet en question… Vous vouliez dire quelque chose, Luis ?

Non, je pense que c'est une question qui pousse à la réflexion, n'est-ce pas ?

Nous allons ainsi arriver à un point où vous vous sentirez vraiment à l'aise pour laisser passer les CL ou les PR sans intervention humaine.

Je vais me faire l'avocat du diable. Quand on parle de friction, on a tendance à penser qu'elle est mauvaise, mais il y a de bonnes et de mauvaises frictions.

Je pense que les avis font toujours partie de la catégorie des frictions positives.

Il s'agit de rendre le processus moins fastidieux pour les développeurs, n'est-ce pas ?

Et parfois, il ne s'agit pas de savoir comment améliorer ou rendre plus efficace cet examen, à ce moment précis.

Comment rendre le développement en amont plus précis grâce à l'IA ?

En effet, selon la façon dont vous utilisez l'IA, de bonnes entrées produisent de meilleurs résultats, mais de mauvaises entrées produisent des résultats de mauvaise qualité.

Je pense donc que pour parvenir à ce résultat final attrayant, il faut améliorer le processus de manière globale avec l'IA dès le début, en l'utilisant pour mieux comprendre l'architecture, pour avoir des spécifications vraiment solides avec moins d'efforts de la part des développeurs, afin que le code produit soit de meilleure qualité.

Par conséquent, les examens sont moins contraignants pour les développeurs.

Je pense que l'état final de ce processus, qui ne devrait pas susciter de controverse, est que la plupart des gens se rendent compte que tout ce code finira par être déployé sans examen humain.

En attendant, nous sommes dans une situation évolutive où les modèles s'améliorent. Nous nous inquiétons moins des erreurs techniques qu'ils pourraient commettre, et davantage des erreurs commerciales, de jugement ou de conception qui pourraient survenir.

Cela fait également partie du signal que vous voudrez séparer lors de l'étape d'examen.

Par exemple, devons-nous examiner la demande d'extraction ligne par ligne ou plutôt l'intention qu'ils essaient de faire passer ?

Nous envisageons plusieurs approches.

La première est : comment fournir des informations plus pertinentes à l'utilisateur pour qu'il puisse commencer à les prioriser ?

L'autre est de savoir quels sont les domaines plus sûrs dans lesquels nous pouvons expérimenter et avancer plus rapidement dans ce type de programmes.

Comme le disait Kaushik, tous les domaines ne nécessitent pas le même niveau de rigueur.

Nous pouvons identifier cela et commencer à en laisser passer certains plus rapidement, en réduisant le risque tout en conservant, vous savez, les domaines qui sont plus axés sur la conformité ou, vous savez, très fondamentaux avec une friction plus élevée jusqu'à ce que nous arrivions vraiment à ce point de confiance non seulement dans les modèles, mais aussi dans les entrées qui y sont injectées.

étaient les bonnes.

Par exemple, refactoriser un nouveau module Android dans l'application Uber, peut-être.

En proposant des trajets sans frais à tous les développeurs Android, vous devriez probablement vérifier ce code.

Je vais devoir vérifier cela avec notre PDG.

Désolé, Kaushik.

Mais je pense aussi que ce problème est résolu.

Nous avons déjà des flags de fonctionnalité.

Nous avons déjà un déploiement bleu-vert.

Nous disposons déjà de nombreux éléments.

Le problème, c'est que nous avons été trop occupés pour vraiment le faire.

Nous disposons déjà d'un suivi comportemental.

Nous disposons de toutes ces données, mais elles sont réparties dans différents systèmes.

Nous suivons déjà les incidents.

Nous disposons de tellement de données, mais il nous manque la possibilité de les regrouper dans une seule trace complète.

Une fois que nous aurons enfin compris à quoi ressemble ce type de service de contexte d'ingénierie dans toutes ces différentes entreprises, nous n'aurons plus à nous inquiéter, car même si la demande d'extraction est simplement fusionnée, elle est sécurisée.

car nous savons que nous l'avons placé derrière un flag de fonctionnalité.

Nous avons le déploiement bleu-vert.

Nous avons mis en place l'observabilité.

Vous pourrez alors dire en toute confiance : "Oh, mettez-le dans le pipeline."

Si un problème survient, nous avons toutes ces protections et ces barrières en place.

Je pense que la rapidité de réponse est également très importante, n'est-ce pas ?

Si vous apportez une modification à Android, par exemple, et que celle-ci doit être déployée via le Play Store, puis auprès de vos clients, votre capacité à appliquer immédiatement un correctif d'urgence est vraiment limitée. En revanche, si vous effectuez un déploiement interne avec une observabilité interne et un agent qui s'en occupe immédiatement, vous avez beaucoup plus de possibilités d'agir rapidement.

L'une des questions que je me posais est la suivante : il y a aussi ce problème qu'il y a du travail à faire sur ces applications, mais vous avez ces applications greenfield qui sont plus faciles, puis vous avez ces applications brownfield, et puis il y a ce moment où vous avez besoin de temps pour mettre en place beaucoup de ces contrôles, vous savez, afin de pouvoir proliférer l'utilisation de l'IA.

Je sais que beaucoup d'entre vous travaillent sur des applications volumineuses.

Je me demande comment vous l'envisagez.

Est-ce qu'on dit au PDG : "Donnez-moi trois mois pour préparer cette application à l'IA", ou est-ce qu'on l'ajoute chaque jour ?

Oui.

De toute façon, ils ne le font jamais.

Je ne pense pas.

La plupart des entreprises n'auront jamais ce luxe.

Je pense que nous devons simplement y consacrer du temps, comme nous le faisions pour la dette technique. Par exemple, au lieu de consacrer 20 % de votre temps à cela, consacrez 5 % de ce temps à l'amélioration d'un prompt.

et même comprendre ce que fait la requête et améliorer le contexte.

Comme nous l'avons déjà évoqué, je pense que les ingénieurs ne comprennent toujours pas comment cela fonctionne.

Elle leur semble encore magique et mystique, et ils ne la configurent pas ni ne l'ajustent de manière à en tirer le meilleur parti et à en optimiser l'efficacité.

Je pense donc qu'il faut un moment où les dirigeants se demandent : "Que devons-nous faire pour améliorer notre équipe afin qu'elle comprenne comment cela fonctionne et que nous puissions en tirer davantage ?"

C'est aussi une continuité.

Comme l'IA évolue très vite, si je demandais à une équipe de passer une semaine à apprendre les dernières nouveautés et à les mettre en pratique, mais qu'elle n'avait pas le temps de continuer à apprendre ou à expérimenter, et que nous faisions le point l'année prochaine, elle serait très en retard par rapport aux nouvelles capacités.

Nous devons donc construire l'avion pendant que nous le pilotons, en mettant en place des garde-fous, en apprenant et en nous adaptant au fur et à mesure, et les équipes doivent rester au fait de tout cela.

Dans les grandes entreprises, des équipes comme la nôtre essaient de synthétiser ces informations et de les rendre plus accessibles et compréhensibles.

Mais c'est un défi pour tout le monde dans le secteur en ce moment.

J'aimerais bien changer un peu.

Vous êtes nombreux à travailler dans l'infrastructure des développeurs.

Des milliers de demandes d'extraction, votre infrastructure de test, vos serveurs, tout est en train de fondre ?

Et j'aimerais beaucoup que vous me racontiez quelques anecdotes.

Ty ?

Oui.

Ils sont en feu.

Mon IC pleure pour s- pleure mes pleure moi pour dormir chaque nuit.

À l'heure actuelle, presque toutes nos équipes d'infrastructure de développement sont confrontées à des problèmes de scaling du calcul et d'efficacité.

Il y a des alertes rouges.

Ils constatent une augmentation considérable du volume.

Nous apportons des modifications architecturales aux agents.

Nous essayons d'étendre aussi rapidement que possible l'exécution et la mise en cache de nos builds à distance avec Bazel. Nous nous demandons comment faire en sorte que tout le code principal soit toujours vert, ou si nous pouvons commencer à corriger les problèmes avec des agents dans certains domaines. Nous examinons le volume de code provenant des ingénieurs, nous essayons de mettre en place des choses comme l'auto-réparation de l'intégration continue ou des boucles de rétroaction plus courtes, et toutes les équipes investissent activement dans tous ces domaines pour essayer de suivre la croissance tout en maintenant un certain niveau d'efficacité.

Mais c'est extrêmement difficile.

Oui, je suis d'accord avec tout ce que Ty vient de dire, mais je pense que cela nous oblige aussi à réfléchir et à nous demander honnêtement si nous sommes prêts à multiplier par 10 notre activité à partir de maintenant.

Pour la plupart des gens, la réponse est probablement non.

Par conséquent, lorsque nous pensons à l'avenir, nous essayons d'adapter notre ambition à l'échelle que l'infrastructure peut supporter.

L'IA nous a tous rendus plus ambitieux, car nous avons déjà constaté un bond significatif. Nous repensons donc sincèrement nos systèmes.

En effet, nous réfléchissons à quel autre système va tomber en panne, ou nous anticipons qu'il va tomber en panne, et nous nous demandons ce que nous pouvons faire pour prendre les devants afin de ne pas être pris au dépourvu.

En réalité, nous essayons d'éviter les surprises.

C'est vrai, tant que nous avons l'impression de garder le contrôle, tout le monde est content.

Dès qu'on rencontre une surprise, je sais que c'est une mauvaise nouvelle pour tout le monde.

Vous me suivez ?

C'est donc le bon moment pour réfléchir, faire le point, auditer et déterminer ce qui va casser ensuite, car cela va se produire.

C'est inévitable.

Nous voulons juste prendre les devants.

J'ai entendu une citation intéressante du PDG d'Inflow.

Elle expliquait que c'était le temps qu'il avait fallu à Google pour atteindre le milliard de lignes de code qu'il possède aujourd'hui, soit environ 20 ans. Avec l'accélération de l'IA, beaucoup de nos entreprises vont atteindre une échelle similaire en quelques années seulement.

Et je ne pense pas que toutes les entreprises soient prêtes à disposer d'une infrastructure de niveau Google pour le développement.

À ce sujet, vos entreprises appliquent-elles une limite de dépense ?

Par exemple, comment gérer les développeurs qui utilisent des jetons pour tout et n'importe quoi, en utilisant toujours le meilleur modèle possible ?

Par exemple, avez-vous trouvé des stratégies ou est-il préférable de les laisser libres, car l'expérimentation donne de bons résultats ?

Je dirais que l'année dernière a été l'année de l'expérimentation.

Faites tout ce que vous voulez.

Et peut-être même que la première moitié de cette année, c'était juste de l'utiliser raisonnablement.

Et depuis septembre, nous avons des limites de jetons.

Nous avons donc des limites pour les développeurs concernant l'utilisation des jetons.

Nous avons également des instrumentations qui permettent de savoir si les sessions sont saines et de bonne qualité.

Qu'entend-on par "session saine" ?

Avez-vous autant de tours par session ?

Qu'est-ce qu'un tour ?

Nous essayons donc d'utiliser les outils pour former les développeurs.

Je pense que ce n'est qu'une première étape.

Vous savez, vous devez savoir que vous avez un problème avant de pouvoir le résoudre.

Et donc, au moins, ils voient que ce n'est pas sans frais.

Avant, on avait vraiment l'impression que l'IA était sans frais.

Et les gens l'utilisaient.

J'aimerais pouvoir dire "Change ma branche" et qu'il me réponde "Pas de problème, Annyce, je vais changer cette branche pour toi, ça fera 5 dollars".

On en arrive à se dire : "OK, je pourrais simplement accéder à la ligne de commande et le faire moi-même, n'est-ce pas ?"

Je pense donc que nous allons commencer à former les ingénieurs sur le coût réel.

Je ne me contenterais pas de lancer des instances ECS et de les laisser tourner.

Peut-être qu'au lancement d'AWS, on se disait : "Oui, je peux dépenser ma propre instance."

On coûtait tellement d'argent à l'entreprise.

Je pense qu'il se passe la même chose aujourd'hui avec les jetons.

Je pense que les limites pratiques offrent également des opportunités très intéressantes, n'est-ce pas ?

En effet, au début, nous avions tendance à envoyer toutes les données aux LLM.

Ils introspectaient le code, comprenaient les choses et faisaient de la magie pour vous, n'est-ce pas ?

Mais cela avait un coût.

Et nous sommes vraiment… Vous savez, le secteur s'en rend compte.

Cela oblige les développeurs et les entreprises à réfléchir à la manière d'optimiser ces coûts.

Je vais vous donner un exemple concret : si vous avez un générateur qui produit des composants d'interface utilisateur, et qu'ils doivent respecter une structure spécifique, des tests unitaires, etc., pourquoi demander aux modèles de générer cela à la volée, si vous pouvez en fait leur demander de générer un outil déterministe qui peut simplement créer cela pour vous ?

Vous avez donc de nombreuses occasions d'utiliser les limites de jetons et d'utilisation à votre avantage, et de gagner en efficacité.

Oui, et dans ce sens, nous avons absolument introduit des limites, du moins chez Instacart.

Mais je pense que l'objectif n'est pas nécessairement de limiter l'utilisation de l'IA, mais d'apporter une sorte d'hygiène, ou comme vous le dites, d'introspection, n'est-ce pas ?

Par exemple, quand utiliser certains modèles plutôt que d'autres.

Vous n'avez probablement pas besoin de Fable ou d'Astra pour vous donner l'heure ou changer de branche Git.

Vous me suivez ?

Vous pouvez probablement passer un peu de temps à écrire un script, et c'est sans frais pour toujours.

Aucun jeton n'est gaspillé.

Vous me suivez ?

Je pense donc que si vous pouvez ajouter une sorte de contrainte, celle-ci n'est pas nécessairement destinée à limiter l'utilisation, mais plutôt à vous aider à réfléchir au-delà du simple fait de tout lui jeter à la figure.

Vous me suivez ?

J'aime ce que vous avez dit : l'année dernière a été l'année de l'expérimentation.

Cette année, la question est plutôt : comment utiliser efficacement cette technologie ?

Oui.

Les histoires présentées ici nous parlent également beaucoup.

Surtout quand on passe d'une phase d'expérimentation à un équilibre entre efficacité et responsabilité.

Cela provient de divers investissements.

Il s'agit par exemple de former les développeurs et d'améliorer la visibilité.

Comme l'a mentionné Annyce, par exemple, avec le coût et les informations de la session active.

Nous investissons dans des paramètres par défaut sécurisés qui permettent d'éviter les interactions inutiles, en veillant à ce que les compétences utilisées soient efficaces pour rechercher les régressions et autres problèmes.

et de les responsabiliser par rapport aux coûts qu'elles engagent.

Nous avons donc des limites de jetons.

Et lorsqu'un développeur atteint ces limites, il peut, en un clic, saisir une justification que son responsable peut approuver.

S'il y a un travail de qualité, nous voulons qu'ils le voient.

Mais s'ils font quelque chose de plus coûteux ou d'expérimental, ils ne peuvent pas justifier auprès de leur responsable pourquoi ils devraient dépenser de l'argent pour cela. Cela les aide donc à garder le contrôle.

Cela ne se limite pas à ne pas faire le travail, mais à se demander si le modèle choisi est le bon.

Est-ce le bon poids ?

Comme vous le savez, le coût de ces jetons a commencé à baisser en raison de la pression concurrentielle.

Mais en général, le fait que nos ingénieurs y réfléchissent et gèrent correctement l'argent que nous leur donnons est, je pense, la bonne approche à adopter pour le moment.

Et à long terme, pouvoir les décharger complètement de cette décision.

Vous me suivez ?

Vous voulez un routage automatique vers les modèles et d'autres fonctionnalités de ce type, pour que les utilisateurs n'aient jamais à s'en soucier.

Mais en attendant, c'est un état sain.

Oui.

Je pense que nous nous sommes beaucoup concentrés sur des choses comme le routeur de modèles, afin de décharger le développeur de cette décision et d'essayer de mapper la tâche au bon modèle.

Mais il s'agit également de disposer des bons déclencheurs.

Nous abordons les limites de jetons de plusieurs façons.

Nous ne voulons jamais bloquer le développeur.

Mais nous voulons nous assurer qu'il y a des moments où nous pouvons faire une pause et nous assurer que l'argent est dépensé dans les bons domaines et de la bonne manière.

Par exemple, il existe des limites quotidiennes, qui servent uniquement de déclencheur et qu'un développeur peut débloquer lui-même.

Il lui suffit d'accéder au portail, de cliquer sur un bouton et de dire : "Rien d'inhabituel ne s'est produit.

Je contrôle la situation."

Vous me suivez ?

Et ce n'est qu'un simple levier, car tout le monde utilise des boucles, et ces boucles peuvent s'exécuter pendant la nuit. Nous ne voulons pas que cela entraîne des coûts.

C'est donc très raisonnable.

D'autre part, nous voulons également nous assurer que nos développeurs disposent des meilleurs modèles disponibles.

Mais pour cette catégorie de modèles, nous avons créé un budget de pointe.

Un budget mensuel est donc en place.

C'est assez haut.

Vous n'êtes pas bloqué.

Si vous devez être débloqué, il existe une procédure d'exception.

Elle est envoyée à votre responsable.

C'est un moment où vous décrivez ce que vous faites.

En tant qu'équipe de plate-forme, nous ne sommes pas les décideurs, car ces décisions doivent être prises au plus près de l'endroit où le travail est effectué.

En ce qui concerne l'utilisation du modèle de frontière, nous vous offrons une flexibilité totale avec un plafond.

Et si cela fonctionne, c'est parce que cela apporte de la prévisibilité au processus.

Vous me suivez ?

Nous voulons nous assurer que lorsque nous budgétisons nos dépenses de jetons (ce qui est un défi pour tout le monde), nous avons pris en compte ce que nous avions prévu, et ces leviers nous permettent de le faire.

Vous savez ce que je trouve fascinant dans ces conversations ?

Je pense que c'est parce que nous travaillons tous dans des entreprises.

Et donc, les entreprises.

Nous devons donc payer pour chaque jeton.

Vous me suivez ?

Mais il existe tout un pan d'Internet où les utilisateurs paient un abonnement.

Pour eux, le calcul est donc très différent.

Vous me suivez ?

Mais je pense que vous savez que ce n'est qu'une question de temps avant que tout le monde ne se retrouve dans la même situation, où il faut commencer à réfléchir à chaque jeton.

C'est à ce moment-là que les choses vont probablement se compliquer en termes de responsabilité, comme c'est le cas actuellement dans les entreprises.

Ou vous travaillez dans un laboratoire de pointe où vous disposez d'un budget illimité.

Ensuite, vous continuez à travailler et à créer de nombreuses méthodes de travail natives de l'IA, comme celles que l'on voit partout sur Twitter.

Toutes nos entreprises veulent refléter cela, mais elles ne pensent pas vouloir dépenser les jetons qui…

Nous avons des personnes qui travaillent chez Google ici.

Je suis très curieux.

Comment cela fonctionne-t-il ?

Quel est le budget de Google ?

Tu veux t'en charger, Luis ?

Je ne pense pas être la bonne personne pour parler de l'aspect économique.

Google est une très grande entreprise qui compte de nombreuses organisations différentes.

Mais cela nous amène parfaitement à la fin, car nous sommes pile dans les temps.

C'était pratique.

Sauvé par le gong.

C'est ça, une modération de qualité.

Les responsables des relations publiques sont…

Merci à nos intervenants et merci à vous d'être venus à l'ADS.