J'ai cofondé une entreprise. Je peux vous dire exactement ce qu'elle fait. Chaque fonctionnalité, chaque parcours, ce qui se passe quand un utilisateur clique sur quoi que ce soit, quelles décisions on a prises et pourquoi. Je serais incapable de vous dire comment elle est architecturée.
Cette phrase, j'ai mis du temps à accepter de l'écrire. Ça sonne comme l'aveu de ne pas être un vrai ingénieur. J'ai fini par y voir autre chose.
Ce qui a changé
Quand j'ai commencé, utiliser l'IA était optionnel. Une autocomplétion plus rapide, un canard en plastique qui répondait. C'était un outil qu'on pouvait raisonnablement refuser tout en restant bon dans le métier.
C'est terminé. C'est devenu le cœur de la façon dont le travail se fait, et la forme du travail a changé avec.
Je ne passe pas mes journées à écrire du code. Je les passe à lire du code écrit très vite, à décider s'il est juste, et à décider de ce qui devrait exister ensuite. Le volume, c'est la partie dont personne ne prévient. Un modèle produit en une heure plus que ce que je peux lire attentivement en trois. Le goulot d'étranglement est passé de la frappe à la relecture, et relire coûte plus cher à la ligne que n'a jamais coûté écrire, parce qu'il faut reconstituer une intention qu'on n'a pas formée.
Certains jours, je n'ai pas assez de budget cognitif pour rattraper ce que j'ai moi-même demandé.
Ce que j'ai vraiment abandonné
Voilà le coût honnête, et ce n'est pas celui qu'on cite d'habitude.
Quand un modèle rédige, ce n'est pas moi qui ai défini la base. Je n'ai pas choisi l'angle. Je n'ai pas choisi les mots, ni l'ordre, ni la manière particulière dont une chose se dit. J'approuve ou je rejette, et approuver n'est pas le même geste que choisir. L'espace de ce qui aurait pu être écrit se referme avant que je le voie.
C'est une perte réelle. Je ne vais pas prétendre que la relecture la rattrape.
Ce que je récupère, c'est un autre type de contrôle. Pas chaque mot, mais l'orientation. L'angle que je voulais. Le fait que la chose soit fonctionnelle, qu'elle réponde à la question réellement posée. Je pilote désormais par blocs plutôt que par étapes, et je suis devenu bien meilleur pour repérer quand un bloc est faux.
Le producteur et l'usine
Près de chez moi, des gens fabriquent des choses entièrement à la main. Ils contrôlent chaque étape de la chaîne, connaissent chaque lot, et aiment sincèrement le geste manuel. Cet amour n'est pas décoratif, c'est ce qui rend le travail bon.
Puis une usine s'installe à côté. Elle contrôle moins sa propre chaîne. Personne là-bas ne touche chaque unité. Mais elle itère plus vite, et sur cinq ans elle sort plus de versions, apprend de davantage d'entre elles, et finit par faire un meilleur produit.
Les deux sont vrais en même temps, et c'est ça qui dérange. Beaucoup de développeurs pensent que l'artisanat manuel est le cœur noble du métier. Je comprends le sentiment. Je ne suis pas sûr que le sentiment prédise qui produira le meilleur logiciel en 2031.
Ce que ça m'a coûté avant que j'apprenne à le faire correctement
Je veux être précis sur le mode d'échec, parce que j'y ai vécu un moment.
J'ai tout délégué. Pas les parties ennuyeuses, tout. Et je me suis retrouvé avec trois choses.
Des décisions que je ne pouvais pas expliquer. Quelqu'un demandait pourquoi le système marchait d'une certaine façon et je n'avais aucune réponse qui soit vraiment la mienne.
Des résultats incohérents entre eux. Chaque pièce défendable isolément, l'ensemble tirant dans des directions différentes, parce que rien ne tenait la forme.
Et le pire : des solutions à des problèmes qui n'existaient pas. Un modèle à qui on demande d'améliorer quelque chose améliorera quelque chose. Il ne vous dira pas que la chose n'avait pas besoin d'être améliorée. J'ai livré des correctifs pour des problèmes que j'avais inventés en posant la question.
C'est le coût caché de la délégation totale, et on ne le découvre qu'en aval, au moment où l'explication est due.
Ce qui ne s'est pas délégué
Cette année, j'ai passé des mois sur l'interopérabilité des portefeuilles d'identité. Lire le code source de portefeuilles en production, intégrer une même couche de confiance dans plusieurs d'entre eux, faire tourner de vrais échanges de credentials sur de vrais appareils.
Le résultat qui comptait n'était pas du code. C'était une phrase : chacun de ces portefeuilles passe ses tests de conformance, et ils restent incapables de se parler. Les normes ont des bords. La conformance n'est pas la compatibilité. Il n'existe aucune offre de credential unique qui fonctionne sur l'ensemble.
Aucun modèle n'allait me tendre ça. Pas par manque de raisonnement, mais parce que personne n'avait posé la question, et la question est toute la contribution. Savoir quel résultat est intéressant, pourquoi il l'est, et qu'il vaut huit mois de travail, ce n'est pas une tâche qu'on délègue. C'est le métier, maintenant.
Être trop junior pour micromanager m'a servi
Je suis arrivé là-dedans à un moment étrange. Je n'avais pas la profondeur pour diriger chaque détail technique, donc je n'ai pas essayé. J'ai piloté à un niveau que je pouvais réellement tenir, avec un regard plus frais et moins d'a priori sur la façon dont les choses sont censées se faire.
Je ne pense pas que ça m'ait rendu meilleur que les ingénieurs autour de moi. Plusieurs en savent bien plus que moi. Ce que j'ai remarqué, c'est qu'eux aussi utilisent ces outils, et ce qui les rend bons avec n'est pas la profondeur elle-même, c'est le goût que la profondeur a laissé derrière elle. Ils savent où se trouvent les bons résultats avant de pouvoir le démontrer. Ils savent dans quel raisonnement lancer un modèle.
Cette intuition est le vrai actif, et on peut la construire sans avoir écrit à la main chaque couche en dessous. On ne peut pas travailler sans aucune couche d'abstraction. La seule question a toujours été : à quel étage.
Donc, les généralistes
C'est la partie que je crois sans pouvoir encore la prouver.
Si l'intelligence technique brute devient quelque chose qui se loue au token, elle cesse d'être ce qui distingue les gens. Les modèles retiendront plus de spécifications et plus de détails qu'aucun de nous. Ce qu'ils ne feront pas, c'est décider de ce qui vaut la peine d'être construit, ni remarquer que deux domaines sans rapport décrivent le même problème.
Ce remarquer, c'est ce que font les généralistes. Relier des domaines, rester curieux au-delà du point où c'est immédiatement utile, transporter du contexte d'un système vers un autre. C'était un trait légèrement suspect, celui qui n'allait assez loin dans rien. Dans un monde où la profondeur s'achète et pas l'étendue, je pense que ça s'inverse.
Le corollaire, c'est qu'il faut traiter ces systèmes pour ce qu'ils sont. Pas comme un développeur junior, pas comme un collègue, pas comme une personne. Il y a des tâches qu'une IA fait très bien et qu'un humain fait très mal, et l'inverse, et être sentimental sur la répartition ne fait que vous coûter. Savoir où passe la ligne, et la revérifier à mesure qu'elle bouge, fait désormais partie du fait d'être techniquement à jour.
Une dernière chose
J'ai enregistré la version brute de ce texte en ne faisant absolument rien pendant seize minutes. Pas d'écran, pas d'entrée, rien à quoi réagir.
C'est l'intrant le plus rare dont je dispose, et je pense que ma génération le sous-estime gravement. On est devenus très bons pour combler les vides, et quand on se repose, on se distrait au lieu de s'arrêter. Presque rien de ce que j'ai écrit ici n'est arrivé pendant que je travaillais. C'est arrivé pendant que je ne travaillais pas.
Si le métier est vraiment monté d'un étage, la compétence rare n'est pas le débit. C'est d'avoir quelque chose à dire sur la direction. Et ça ne vient pas de plus d'outillage.