Chaque équipe d'ingénierie arrive à un moment où l'IA cesse d'être une expérience géniale pour devenir une infrastructure porteuse. Tu ne le planifies pas. Vous remarquez un jour que vos hypothèses relatives à la vélocité ont changé, que votre posture en matière de révision du code a changé et que les humains de votre équipe prennent des décisions différentes de ce qu'ils étaient il y a dix-huit mois.
Nous avons atteint ce moment à Rokt. Nous n'avons pas fini de le toucher. Mais nous avons parcouru suffisamment de chemin pour que je puisse décrire à quoi ressemblent réellement les étapes de l'intérieur. C'est différent de ce à quoi ils ressemblent dans les articles de blog et les conférences.
Étape 1 : saisie semi-automatique
C'est là que presque tout le monde commence et qu'un nombre surprenant d'organisations s'arrêtent discrètement.
À ce stade, l'IA est une astuce de productivité pour les individus. Complétion des onglets qui comprend le contexte. Génération standard. Le corps fonctionnel occasionnel qui sort presque exactement comme il faut. Les ingénieurs qui investissent du temps dans l'apprentissage de la précision des commandes accélèrent. Les ingénieurs qui ne le font pas, ne le font pas.
La structure organisationnelle ne change pas. Les processus de révision ne changent pas. L'architecture ne change pas. Vous obtenez des gains individuels grâce à un outil, de la même manière qu'un ordinateur portable plus rapide vous permet d'obtenir des gains individuels.
L'erreur que les équipes commettent ici est d'appeler cela une transformation. Non, c'est de l'efficacité. Ce n'est pas la même chose.
Étape 2 : Co-Pilote
Le passage au poste de copilote est moins une question d'outillage qu'une question de conversation.
À ce stade, l'IA participe aux discussions de conception. Vous ne lui demandez pas simplement de remplir un corps fonctionnel. Vous lui demandez de revoir votre approche avant de la créer, d'identifier les cas limites dans vos spécifications, de revenir sur vos décisions en matière d'architecture. Les ingénieurs qui réussissent dans ce domaine se déplacent nettement plus vite que ceux qui ne le font pas.
Le signal visible est un écart croissant entre les membres de l'équipe qui considèrent l'IA comme un partenaire d'opinion et ceux qui la considèrent comme un générateur de code. Les deux camps utilisent les mêmes outils. La différence, c'est ce qu'ils demandent.
L'artisanat rapide devient ici un véritable fossé entre les compétences. « Écrivez-moi une fonction qui fait X » est une invite du générateur de code. « Voici mon approche actuelle, voici la contrainte sous laquelle je travaille, voici ce qui m'inquiète : qu'est-ce qui me manque ? » est une invite de copilote. Les résultats se situent dans des ligues différentes.
La qualité de vos spécifications commence également à prendre de plus en plus d'importance. Les déchets entrants et sortants s'appliquent dans les deux sens. Les ingénieurs qui rédigent le contexte le plus clair obtiennent les résultats les plus utiles. Ceux qui veulent que l'IA détermine les exigences à partir de saisies vagues obtiennent un code vague en retour.
Étape 3 : Co-auteur
C'est à ce stade que se produit le changement d'identité, et c'est le plus inconfortable.
Au stade de co-auteur, les agents d'IA participent à l'ensemble du cycle de développement : suggestion, mise en œuvre, exécution de suites de tests, itération en cas d'échec, génération de PR. Le rôle humain commence à passer de la construction à la critique, de l'écriture à la mise en scène.
La plupart des organisations d'ingénierie s'arrêtent là, non pas parce que l'outillage ne fonctionne pas, mais parce que la culture n'a pas rattrapé son retard. Les ingénieurs qui ont passé leur carrière à valoriser l'artisanat (la fonction élégante, l'abstraction épurée, la boucle bien tournée) découvrent soudainement que ce qui est évalué n'est pas leur code. C'est leur jugement sur le code écrit par quelqu'un d'autre. Quelque chose d'autre. Ils commencent soudainement à ressembler beaucoup plus à des prospects et beaucoup moins à leur modèle mental d'un contributeur individuel.
Les organisations qui franchissent cette étape le plus rapidement sont celles qui autorisent explicitement le changement de rôle sur le plan culturel. Chez Rokt, cela impliquait d'être direct avec nos équipes : votre travail ne consiste plus à écrire du code. Il s'agit d'exprimer clairement l'intention, de vérifier rigoureusement les résultats et de s'approprier les résultats des navires. Le code se trouve en aval de celui-ci. Le code devient un outil parmi tant d'autres pour générer des résultats pour les clients.
Les prérequis architecturaux se sont révélés extrêmement importants ici également. Les services qui sont déployés de manière indépendante, possèdent leurs données et exposent des contrats plutôt que des services internes sont sûrs du point de vue architectural pour le développement des agences. Les systèmes étroitement couplés ne le sont pas. Vous ne pouvez pas laisser les agents opérer en toute sécurité dans une base de code où un changement effectué à un endroit peut se répercuter de manière imprévisible sur dix autres. Nous avions déjà misé sur l'encapsulation, et cet investissement a été rentable d'une manière que nous n'avions pas totalement anticipée lorsque nous l'avons réalisé.
Étape 4 : Superviseur
C'est là que le rôle de développeur converge avec le rôle de responsable de l'ingénierie, et cela change à quoi ressemblent réellement les talents d'ingénieur senior.
Au stade du superviseur, vous ne révisez pas les lignes de code. Vous dirigez une flotte d'agents : définissez les intentions, révisez les directives, appliquez les normes, surveillez les dérives. Les compétences qui comptent sont celles qui ont toujours compté pour une bonne gestion de l'ingénierie. Communication claire de ce à quoi ressemble la beauté. Jugement sur ce qu'il faut accepter et ce qu'il faut renvoyer. Sensibilisation au risque systémique.
Les ingénieurs qui excellent ici ne sont pas nécessairement ceux qui ont écrit le meilleur code. Ce sont eux qui communiquent avec le plus de précision. Qui peut examiner 400 lignes de sortie générées et identifier rapidement les trois problèmes. Qui comprennent suffisamment bien le système de manière holistique pour trouver une solution techniquement correcte qui n'est pas correcte sur le plan architectural. Ceux qui peuvent opposer deux agents l'un à l'autre et juger rapidement du résultat gagnant.
Claire Southey, notre directrice de l'IA, l'a bien exprimé récemment :
La compétence déterminante des futures équipes logicielles ne sera pas la quantité de code qu'elles écrivent, mais la clarté avec laquelle elles expriment leur intention, passent de l'ambiguïté à la clarté et déterminent l'impact de ce qu'elles créent.
C'est une description de poste pour un superviseur. Il décrit les CI seniors et les leaders de nos équipes les plus rapides à l'heure actuelle. Notre parcours dans le cadre de cette transition consiste à l'appliquer à tout le monde, du diplômé universitaire le plus débutant à nos cadres supérieurs.
Qu'est-ce qui fait que les transitions perdurent
Certaines choses ont eu plus d'importance que ce à quoi nous nous attendions.
Une route goudronnée. Un outillage approuvé avec de bons paramètres par défaut élimine les frictions et évite à chaque équipe de décider « quel outil dois-je utiliser ». Nous ne voulions pas quinze configurations de codage d'IA différentes dans le domaine de l'ingénierie. Nous avons fait du bon chemin le chemin le plus facile.
Apprentissages partagés. Les ingénieurs qui ont franchi chaque étape ont d'abord appris les choses dont le reste de l'organisation avait besoin. Nous avons mis en place des mécanismes pour diffuser rapidement ces enseignements, via des canaux asynchrones plutôt que des sites hors site trimestriels, afin que les utilisateurs puissent voir ce qui fonctionnait en temps réel.
Mesure. Nous avons appliqué la même rigueur à l'adoption interne de l'IA que nous appliquons aux décisions relatives aux produits : instrumentation, groupes de contrôle, critères de réussite clairs. « On se sent plus rapide » n'est pas un indicateur. Nous avons mesuré les résultats assistés par l'IA (temps de cycle, cycles de révision, taux de défauts) afin de voir si nous étions réellement en train de nous améliorer ou si nous avions simplement l'impression de l'être.
Les transitions entre les étapes ne sont pas automatiques. Ils nécessitent des décisions délibérées concernant la manière dont le travail est structuré, les compétences pour lesquelles vous recrutez et ce que vous demandez aux ingénieurs de devenir. Les organisations qui considèrent la transition comme passive (achetez les outils, attendez que la culture suive) se retrouvent coincées entre les étapes et se demandent pourquoi le retour sur investissement ne se concrétise pas.
Les outils sont bons et ils ne cessent de s'améliorer. Le goulot d'étranglement réside presque toujours dans les décisions organisationnelles qui les concernent. À ce stade, la technologie évolue plus vite que la culture. En tant que responsable de l'ingénierie, il est de mon devoir de m'assurer que la culture peut suivre le rythme.
À Rokt, prendre les bonnes décisions n'a fait que s'aggraver. La même culture d'ingénierie qui a rendu viable le développement des agences est ce qui nous permet d'avancer aussi vite que nous le faisons en matière de produits : des modèles d'expédition qui deviennent plus intelligents à chaque transaction, la création d'une infrastructure de personnalisation qui fonctionne en quelques millisecondes, l'itération sur les éléments qui comptent pour nos clients sans subir l'inertie organisationnelle. Les étapes ci-dessus ne sont pas abstraites. C'est sur eux que nous nous sommes appuyés.
Mélissa Benua est vice-présidente des expériences pour développeurs chez Rokt.
.jpg)
.jpg)
