| Plam |
DDT a écrit :
Note que j'ai pas exactement dit ça. Ma cogip est encore loin d'avoir toute la plomberie nécessaire à pousser 10x plus de code qu'avant, donc on a encore largement le temps de lire le code avant d'accepter les PRs par exemple.
Mes juniors me demandent comment les choses vont évoluer et je prétends pas lire l'avenir mais très clairement:
- Le management veut qu'on double le nombre de produits par équipe l'année prochaine. Le chef du département nous explique au calme que 40% des effectifs vont se prendre des mauvaises évaluations sur la trajectoire actuelle.
- Y a tout un savoir-faire dans notre métier qui est tribal, impossible à acquérir sans être passé par une écriture et plusieurs ré-écritures de bases de code de manière organique. Je vais pas leur mentir, c'est déjà mort, ils apprendront jamais, donc autant se concentrer sur autre chose.
- La revue de code a toujours été très loin d'être infaillible sans une infrastructure conséquente de tests, intégration, validation, déploiements graduels... Donc je pense que c'est l'occasion de déléguer l'étape chiante et peu utile à un modèle, et mettre en place des stratégies qui étaient trop complexes et couteuses avant.
Si j'étais cynique je pourrais leur donner des mauvais conseils et attendre qu'ils se fassent dégager mais bon. :)
Le coût du token me semble pas être un sujet malgré l'augmentation des prix qu'on a observés cette année:
- OpenAI et Google sont en compétition frontale avec Anthropic sur le prix. Par exemple GPT 6.1 Sol est franchement bon marché, Luna suffit à plein de tâches, on commence à revoir des modèles intéressants entre les deux (Sonnet, Terra, Argon...)
- Pour mes besoins persos je fais tout avec les modèles chinois Flash. C'est Opus 4.8 pour 1/100e du prix, et les fournisseurs font de la marge sur l'inférence. Et la progression s'accélère. D'ailleurs mon employeur va acheter davantage de B300 pour augmenter notre capacité on-prem.
J'ai bossé sur une plateforme avec plus d'1M de LoC dans mon équipe précédente et personne ne maîtrisait tout le contexte. Là avec juste le point d'entrée, un agent peut répondre à n'importe quelle question. Sur les nouveaux produits je peux me concentrer exactement là dessus: faire en sorte que la taille du contexte n'explose pas de manière injustifiée, modulariser, virer le code mort, les tests inutiles, etc.
|
Je suis plutôt aligné avec DDT : le métier change. Les seniors/architectes comprennent bien les mécanismes, ils peuvent énormément accélérer (x10) en ayant le focus de tester plein de choses en parallèle et choisir ce qui sembler être la meilleure approche pour résoudre un problème. Là, plus que la génération de code, c'est le raccourcissement entre une idée et le prototype, puis les tests à l'échelle (j'ai introduit metal-broker, un programme en MCP qui fait l’intermédiaire pour facilement louer et installer des machines physiques sur notre solution avec des budgets par équipe, ça permet d'éviter le bottleneck précédent qui était la dispo de machines dans le lab, géré par des humains).
Donc oui, quand tu enlèves un bottleneck, un autre apparait, mais dans le lot il y a aussi pas mal de bottleneck « dans la tête ».
Quand aux juniors, je pense que c'est plus possible d'être « dev pur » (genre « faites moi pas chier j'ai rien à foutre du métier je vais juste pisser du code »). Ça, c'est terminé oui. Ta valeur c'est d'être à la place de l'utilisateur final et de comprendre le métier.
Jubijub a écrit :
Plus que les LLM, les réactions claquées des leads me font peur :D
On a plusieurs problèmes non résolus (dont les reviews, la perte massive de connaissance de ce que fait ce qui est en prod). Y’a aussi le fait que la culture de décision n’est pas adaptée à un monde avec des LLM, où tu peux trivialement aller modifier le code du voisin (et du coup qu’importe qu’on ait généré 100kLoC en 2h, si il te faut 3 mois de négociations pour pouvoir merger chez l’équipe voisine, on a gagné 0 productivité. Je parle meme pas des process de launch / validation qui sont tous human gated, et lents (après je serais pas à l’aise de pas avoir d’humains, mais faut avoir conscience du bottleneck)
Tl;dr: c’est très prématuré de virer tout le monde parce que « les LLM donnent une productivité énorme »
|
Comme je disais, enlever un bottleneck et un autre va apparaître, c'est logique. Il y a une vraie transformation à faire. Mais je reste persuadé que c'est le chemin vers x10 en vitesse de livraison et en qualité, les 2 en même temps. Mais ça veut pas dire virer, au contraire : c'est avoir la puissance de 600 ingénieurs avec seulement 60. |