Je n'aime pas parler aux robots

J'ai un téléphone Android, mais j'ai désactivé les commandes vocales. Je n'ai jamais eu d'Alexa. Je ne suis pas sûr de ce que fait Siri, exactement, parce que j'ai réussi à vivre sans qu'il me trouve une playlist. Alors, quand les outils de codage IA sont devenus difficiles à ignorer, j'ai changé d'avis lentement. Pendant un moment, j'ai fait ce que certains appellent "délégation ponctuelle à l'IA" : travailler comme je le faisais toujours, déléguer occasionnellement une partie du travail à l'IA, puis attendre de voir ce qui revenait. C'est une approche vraiment géniale pour ceux qui aiment parier.

Pour moi, une partie de la friction venait de l'interface de chat elle-même. L'idée d'avoir une conversation avec le modèle me semblait ridicule. Je construis des choses. Je ne négocie pas avec des boîtes de texte.

Mais le développement piloté par les spécifications ne fonctionne pas de cette manière. Vous définissez précisément le problème, vous indiquez au modèle quels fichiers prendre en compte, vous décrivez le résultat souhaité, et vous échangez en discutant du plan avant que l'IA ne génère la moindre ligne de code. Les modèles d'IA actuels sont rapides pour coder mais restent dangereusement incohérents dans la prise de décision de haut niveau. Lorsque vous travaillez avec l'IA, votre rôle est de transformer votre jugement de conception en une spécification écrite, afin de pouvoir donner à l'IA une liste d'étapes à faible prise de décision qui correspondent à ce que vous feriez, si vous alliez taper le code vous-même. Pour obtenir cette spécification correctement, vous devez négocier.

J'ai appris cela au cours des six derniers mois. Et je suis devenu assez doué pour cela. Je code rarement/ne code jamais à la main, pourtant, je livre plus de fonctionnalités que je ne l'ai jamais fait auparavant. Et puisque je ne délègue pas la conception logicielle au modèle, j'applique les mêmes normes de qualité que j'ai appris à respecter au cours de ma carrière de 25 ans à construire des produits numériques.

Ce à quoi je ne m'attendais pas, c'était à quel point ce serait difficile à enseigner.

Suis-je déjà Picasso ?

Il y a une idée (parmi la direction senior ?) que les outils de modèles de langage de grande taille augmenteront la productivité de tous les ingénieurs. En pratique, je n'ai pas vu cela. Ce que je vois, ce sont des ingénieurs expérimentés et adaptables qui atteignent des multiples de ce qu'ils produisaient auparavant, tandis que d'autres produisent la même chose ou moins.

Ce n'est pas une bonne situation pour les personnes qui débutent. Les outils de codage assisté par IA semblent simples parce que leurs interfaces ne sont que des boîtes de texte. Mais on ne devient pas Picasso en étalant de la peinture de manière arbitraire sur une toile vierge.

Syndrome d'implémentation parallèle

Je tiens aux ingénieurs juniors pour de nombreuses raisons, et pas la moindre est que ce sont mes collaborateurs préférés ! Leur ouverture d'esprit ne s'est pas encore atrophiée, et ils m'aident à voir les choses différemment. Récemment, j'ai entrepris un parcours d'apprentissage en IA avec un jeune ingénieur qui est intelligent, enthousiaste à propos des outils d'IA, impatient de s'impliquer, et pas du tout hésitant à parler au robot.

Et pourtant, d'une manière ou d'une autre, cela ne fonctionnait pas.

Le premier signe était le système d'authentification. Elle devait ajouter OAuth à un service existant, et elle a demandé au modèle de construire le flux d'authentification complet en une seule spécification massive. Connexion, rafraîchissement de jeton, gestion de session, accès basé sur les rôles, et flux de déconnexion. Tout. Le modèle s'est exécuté avec plaisir. Il a produit plusieurs centaines de lignes de code qui semblaient complètes avec 100 % de couverture de code et des tests réussis.

Mais lorsque je l'ai examiné, les problèmes étaient structurels. Le modèle avait créé un nouveau stockage de session au lieu d'utiliser celui que nous avions déjà. Il a introduit un modèle de renouvellement de jeton qui entrait en conflit avec notre passerelle API. La logique d'accès basée sur les rôles dupliquait des règles métier qui existaient déjà dans un middleware partagé. Techniquement, rien de tout cela n'était faux—ça fonctionnait. Architecturalement, tout l'était.

Je me suis assis avec elle et j'ai posé une simple question : « Avant de faire cette demande, saviez-vous comment nous gérons les sessions aujourd'hui ? » Elle a marqué une pause. « Pas exactement. » C'était là l'écart. Elle n'avait pas cartographié le territoire avant de demander au modèle de s'appuyer dessus.

La tentative suivante s'est déroulée différemment, mais pas assez. Elle a demandé au modèle de modifier le flux de connexion pour prendre en charge un nouveau fournisseur. Cette fois, elle a effectué une réduction du périmètre, ce qui était bien. Mais elle a décrit le changement en termes de ce qu'elle voulait que l'interface utilisateur fasse, et non en termes de ce que le code existant gérait déjà. Le modèle, n'ayant aucune raison de connaître notre abstraction de fournisseur, a écrit une implémentation parallèle à partir de zéro. Même résultat : code fonctionnel, architecture incorrecte.

Nous avons discuté de ce qui s'était passé. Je lui ai dit de penser au modèle comme elle penserait à un nouveau prestataire dans l'équipe. Talentueux, rapide, aucune expérience avec notre base de code. Vous ne confieriez pas ce projet à un prestataire et ne partiriez pas. Vous diriez : voici notre magasin de session, voici le middleware, voici la méthode pour ajouter un nouveau fournisseur. Adaptez votre travail à cela.

Elle avait compris le concept. Mais les quelques tours suivants m'ont montré que le concept était la partie facile. Elle obtenait un seul plan du modèle et le validait sans exiger d'alternatives. Elle voyait la volonté du modèle de faire des changements de code importants comme étant méticuleuse ; je la voyais comme un risque inutile. Elle n'avait pas encore l'instinct de dire « non, c'est trop de surface d'impact pour ce changement. »

Un ingénieur expérimenté aurait traité cette même tâche OAuth en six ou sept tours concentrés, chacun délimité à une partie du système qu'elle comprenait déjà.

Les compétences comportementales sont les nouvelles compétences techniques.

Cela pourrait sembler être une surcharge qui annulerait les gains de productivité du codage par IA. Mais ce ne sont pas de nouvelles compétences. Les ingénieurs expérimentés ont toujours fait cela dans leur tête. La différence est que le développement piloté par les spécifications externalise la planification de la conception logicielle de toutes les tâches. La négociation de conception qui avait lieu en interne, entre vous et votre propre jugement, se déroule maintenant dans une fenêtre de discussion.

Avant d'ouvrir le chat, vous devez savoir ce que vous voulez. Pas l'implémentation, mais le comportement, les contraintes, la forme de la chose. Vous devez bien connaître votre base de code pour indiquer au modèle où son travail doit s'insérer. Lorsque le modèle propose une réponse, elle s'exécutera probablement. Ce n'est pas suffisant. Vous devez savoir si elle s'intègre réellement au système que vous avez déjà.

Parfois, vous reconnaissez que le modèle a raison et que vous avez tort, et vous avez besoin d'humilité pour évaluer cela équitablement.

Dans l'ensemble du processus, ce qui distingue les personnes qui utilisent bien ces outils de celles qui les utilisent rapidement, c'est la patience : la volonté de revenir en arrière cinq ou six fois au lieu d'accepter quelque chose de médiocre dès la deuxième itération. Il y a aussi la compétence d'écrire précisément sur le code sans écrire de code, en décrivant les flux de données, les cas limites et les modes de défaillance dans un langage simple. Et il y a la sensibilité, qui est plus difficile à définir mais facile à reconnaître : un sens de ce à quoi ressemble un bon logiciel du point de vue de la maintenance à long terme, pas seulement s'il fonctionne.

Et puis il y a la partie inconfortable. La plupart de ces compétences sont une reconnaissance de motifs construite après des années à se tromper. Vous reconnaissez une mauvaise décision architecturale parce que vous en avez subi les conséquences. Vous rejetez la première réponse du modèle parce que vous avez déjà livré votre première idée et l'avez regrettée.

Les ingénieurs juniors sont placés dans des situations où ils doivent réaliser une négociation de conception à un haut niveau, mais il ne semble pas y avoir de programme de formation pour cela. Il est temps de s'éloigner de « LeetCode » pour se concentrer sur la négociation de conception, et ce sera le sujet des futurs articles de cette série.

Addendum

Compétences comportementales pour négocier un cahier des charges avec l'IA

Pendant la négociation

• Fluidité en lecture de code : Analysez ce que le modèle produit pour vérifier la solidité structurelle, pas seulement la syntaxe. Vous lisez pour l'adéquation, pas pour les bugs. Pourquoi c'est important : Le modèle peut générer du code valide qui ne correspond pas à votre système. Vous devez le détecter rapidement.

• Sens architectural : Reconnaître quand une solution est techniquement valide mais inappropriée pour ce système. Pourquoi c'est important : Le modèle ne sait pas ce que "inapproprié pour nous" signifie. Vous, si.

• Orientation créative : Trouver des cadrages alternatifs lorsque le modèle est bloqué. Reformuler le problème, proposer une analogie, le contraindre différemment. Pourquoi c'est important : Le modèle réagit à la façon dont vous cadrez les choses, et un meilleur cadrage produit un meilleur résultat.

• savoir quand prendre position : Le modèle présente les options de manière neutre. Vous décidez, et expliquez pourquoi une approche est meilleure pour votre contexte. Pourquoi c'est important : C'est un jugement d'ingénierie, et cela prend des années à développer.

• Scepticisme productif : Considérer la première réponse du modèle comme un brouillon, pas une solution. Pas du cynisme, mais l'habitude de tester la résistance avant d'accepter. Pourquoi c'est important : Les sorties de première passe sont séduisantes parce qu'elles sont fluides. La fluidité n'est pas l'exactitude.

• Savoir ce que l'on ne sait pas : Reconnaître quand le modèle peut avoir raison et vous pouvez avoir tort. Pourquoi c'est important : La négociation va dans les deux sens. Parfois, elle fait émerger une approche que vous n'aviez pas envisagée, et vous avez besoin d'humilité pour l'évaluer équitablement.

À travers tout le processus

• Patience itérative : Faire des allers-retours cinq ou six fois au lieu d'accepter quelque chose de médiocre dès le deuxième tour. Pourquoi c'est important : Cela distingue les personnes qui utilisent bien l'outil de celles qui l'utilisent rapidement.

• Communication technique : Écrire avec précision sur le code sans écrire de code. Décrire les flux de données, les changements d'état, les edge cases, et les modes de défaillance en langage simple. Pourquoi c'est important : C'est plus difficile que ce que la plupart des ingénieurs pensent, et c'est l'interface principale entre vous et le modèle.

• Maintenir la complexité en tête: Suivre comment la décision actuelle interagit avec trois autres parties du système que le modèle ne connaît pas. Pourquoi c'est important: Le modèle n'a pas de contexte architectural persistant. Vous êtes la mémoire de travail.

• goût : Un sens de ce que ressent un bon logiciel du point de vue de l'utilisateur. Pas seulement "est-ce que ça fonctionne" mais "est-ce la bonne expérience, le bon comportement, le bon niveau de complexité." Pourquoi c'est important : Sans cela, vous accepterez des solutions qui sont fonctionnelles mais incorrectes.

• Savoir quand s'arrêter : Reconnaître quand la spécification est suffisamment bonne pour passer à l'exécution, et quand vous faites du sur-affinage. Pourquoi c'est important : Les rendements décroissants sont une réalité. À un certain moment, une négociation supplémentaire coûte plus qu'elle n'améliore.