Le goulot d’étranglement n’a jamais été le code
(thetypicalset.com)- Chez .txt, Codex a produit en quelques heures une première version fonctionnelle d’une expérimentation d’algorithme de génération structurée repoussée depuis plus d’un an, mais le changement clé a surtout été de révéler un goulot d’étranglement dans la collaboration plutôt qu’un gain de vitesse de codage individuel
- Quand des agents prennent en charge l’implémentation, ce qui ralentit l’équipe n’est plus l’auteur du code, mais la création de spécifications précises — roadmap, critères d’acceptation, documents de conception — que l’agent peut exécuter immédiatement
- Quand le coût d’écriture du code baisse, les prototypes et outils internes qu’on n’aurait pas construits auparavant se multiplient, tandis que la capacité des utilisateurs à absorber ce rythme reste la même ; la discipline du focus pour décider ce qu’il ne faut pas construire devient donc plus importante
- Les agents peuvent extraire des décisions implicites et des conventions à partir de Slack, des PR, des issues, des commits et des documents de conception pour créer une base de connaissances, sans pour autant reconstituer entièrement le contexte partagé que les humains accumulent directement
- Dans les dix prochaines années, l’avantage pourrait surtout revenir non pas aux entreprises dotées des meilleurs modèles, mais à celles qui maintiennent une cohérence organisationnelle alignée sur un ensemble de décisions qui se resserre, même à l’échelle de 50, 200 ou 2 000 personnes
Le goulot d’étranglement transformé par les agents de codage
- L’expérimentation repoussée depuis plus d’un an chez .txt consistait à tester des algorithmes de génération structurée et des alternatives open source, et à vérifier non pas simplement « cette chaîne est-elle acceptée ? », mais quelque chose de plus proche de « génère-t-elle la bonne distribution de tokens ? »
- Cette expérimentation était restée sur la roadmap, mais après avoir expliqué l’approche à Codex pendant environ 30 minutes, une première version fonctionnelle a été produite en quelques heures
- Les agents de codage transforment déjà fortement la manière dont les individus écrivent du code, mais il est difficile d’affirmer qu’un gain de productivité individuelle se traduira directement par une augmentation de la vitesse de l’industrie logicielle dans son ensemble
- Les logiciels influents sont souvent construits par la collaboration de plusieurs personnes, et l’unité d’analyse la plus intéressante n’est pas la productivité individuelle mais la collaboration
- Le logiciel ressemble davantage au résultat qui subsiste une fois que des personnes ont négocié ce que le système doit faire ; le code est important, mais il est aussi le résidu d’un travail plus difficile
La roadmap devient la limite
- Dans les équipes où les agents prennent en charge l’implémentation, ce qui ralentit le rythme est la création de spécifications assez précises pour que l’agent puisse les prendre et les exécuter immédiatement
- La roadmap, les critères d’acceptation et « ce que nous voulons réellement » doivent être explicitement formulés sous forme de suite de tests, tickets ou documents de conception
- Les fonctionnalités sont implémentées très vite, et au lieu d’attendre qu’un autre ingénieur termine son travail, les ingénieurs se retrouvent à attendre la prochaine spécification correctement rédigée
- Le goulot d’étranglement se déplace de la personne qui écrit le code vers celle qui décide quel code doit exister ; c’est donc en fin de compte une question de management
Un code moins cher exige davantage de consensus
- Quand le coût d’écriture du code baisse, on ne fournit pas 10 % d’effort pour obtenir le même résultat ; on investit le même effort dans des résultats qui n’auraient auparavant pas valu la peine
- Des prototypes qui, il y a trois mois encore, auraient été jugés « une perte de temps » se réalisent en un après-midi, et des outils internes sans demande claire sont parfois créés puis oubliés
- Le rythme auquel les utilisateurs peuvent absorber des fonctionnalités reste globalement le même, qu’une équipe en livre 10 ou 50
- Comme l’a dit Steve Jobs en 1997, « se concentrer, c’est dire non », et Apple a supprimé environ 70 % de sa gamme de produits cette année-là
- Avec des agents, la sensation de lancer une nouvelle fonctionnalité devient plus facile ; la discipline qui consiste à décider non seulement quoi construire, mais aussi ce qu’il ne faut pas construire, devient donc plus difficile
Le contexte devient la ressource clé
- La négociation et le consensus reposent sur un contexte partagé au sein de l’organisation
- Ce contexte comprend ce qui est en train d’être construit, pourquoi c’est important, ce qui a déjà été essayé, qui a décidé quoi, ce qui est essentiel et ce qui n’est qu’une trace laissée par le passé
- Les humains d’une équipe accumulent naturellement ce contexte en étant dans la même pièce, en lisant les mêmes canaux Slack et en déboguant la même panne à 2 heures du matin
- Une grande partie de ce contexte n’est pas documentée, et lorsqu’un ingénieur senior dit dans une review de PR « ça va casser la migration », il s’appuie parfois sur un contexte qui n’existe dans aucun document
- Les agents ne peuvent pas absorber ce contexte par osmose ; ils ne l’obtiennent pas en étant dans la pièce, en entendant à moitié une discussion de planification ou en gardant le souvenir d’un incident passé
- Le contexte qui n’est pas présent dans le prompt, l’arborescence de fichiers, les outils ou des instructions explicites n’est pas disponible de manière fiable pour l’agent
- Sans contexte, l’agent peut produire une réponse plausible à une question légèrement erronée
- Même lorsque l’agent a accompli un travail utile chez .txt, c’est en réalité parce qu’un humain avait déjà effectué le travail de contextualisation ; cela ne signifie pas que les 10 ingénieurs suivants disposeront automatiquement de cette vision
- Le contexte sur lequel les organisations se sont toujours appuyées implicitement est désormais devenu un input qui limite la vitesse, et les humains ont tendance à le laisser implicite faute d’avoir eu jusque-là un destinataire capable d’en lire une version explicite
La boucle où les agents produisent du contexte
- Produire un contexte facilement consommable par des humains est une tâche que les humains n’aiment pas faire
- Les agents excellent à lire exhaustivement des commentaires de PR, des issues fermées, des messages de commit, d’anciens documents de conception et des archives Slack, puis à en extraire des schémas que personne n’avait documentés
- Chez .txt, on a commencé à construire un agent qui parcourt le codebase, les issues, les PR et les fils de discussion pour transformer les décisions implicites, les conventions et les « pourquoi avons-nous fait cela ? » en base de connaissances
- Cette base de connaissances ne se contente pas de dire « ce module existe », elle capture aussi du contexte comme « ce module est étrange parce que les migrations doivent préserver le comportement existant » ou « ce benchmark est important parce qu’une optimisation précédente a discrètement modifié la distribution »
- D’autres agents utilisent ensuite cette base de connaissances lorsqu’ils doivent agir sur le codebase
- L’osmose informelle autrefois assurée par les humains est externalisée dans une forme lisible à la fois par les agents et par les humains
- Les agents qui consomment du contexte ont besoin d’agents qui produisent du contexte, et lorsque cette boucle fonctionne, l’organisation se dote d’un socle documentaire qu’elle n’aurait pas créé d’elle-même
- Cela dit, la représentation produite par cette boucle reste toujours partielle
- Comme l’a dit Michael Polanyi, « nous savons plus de choses que nous ne pouvons en dire », et une partie du contexte essentiel existe justement parce qu’elle n’a jamais été formulée, voire peut changer dès qu’on essaie de l’écrire
- La couche d’osmose que les humains accumulent en se rencontrant directement ne peut pas être entièrement reconstruite à partir de seuls sous-produits documentés
- Le résultat ressemble donc moins à une restauration complète qu’à un point de départ utile, et la question de savoir si cela suffit à produire des effets cumulatifs reste encore expérimentale
Le nouveau fossé défensif est plus organisationnel que technique
- Les gagnants des dix prochaines années ne seront pas forcément les entreprises disposant des meilleurs modèles ou de la meilleure infrastructure d’agents, mais probablement celles qui, en passant à 50, 200 puis 2 000 personnes, continuent à produire davantage par personne tout en restant alignées sur un ensemble de décisions qui se resserre
- Ce type d’entreprise est une organisation qui savait déjà, avant l’arrivée des agents, que son problème le plus difficile était la cohérence
- C’est une question de culture et de management, et ça l’a toujours été
- Les outils des générations précédentes comme les IDE, le contrôle de version, la CI, les microservices ou le DevOps promettaient de résoudre la coordination avec de meilleurs outils, mais dans les faits ils ont surtout amplifié la cohérence organisationnelle qui existait déjà
- Les petites équipes obtiennent la cohérence presque gratuitement, donc cet effet d’amplification y est généralement positif ; cela explique aussi pourquoi tant de voix très favorables aux agents viennent de petites équipes, car dans leur contexte elles ont le plus souvent raison
- Au-delà d’une certaine taille, la cohérence doit être créée puis entretenue, et l’effet d’amplification devient tranchant dans les deux sens
- Les bonnes organisations deviennent meilleures, et les mauvaises se dégradent plus vite
- Les agents sont un amplificateur bien plus puissant que les outils précédents ; ils sont surestimés comme moyen de faire écrire du code plus vite aux individus, et sous-estimés comme moyen de pousser une organisation à externaliser ce qu’elle sait
Les agents comme extension de la culture d’entreprise
- Les agents peuvent donner l’impression d’être une extension de sa propre pensée, et cette sensation est puissante
- La tâche plus difficile consiste à faire des agents une extension de la culture de l’entreprise
- Cela exige une culture de l’écrit, un management assez réfléchi pour identifier les endroits où il reste lui-même le goulot d’étranglement du contexte, et des personnes qui traitent la cohérence comme un véritable livrable à maintenir
- Ce qui est nouveau, c’est que certaines de ces choses peuvent désormais être construites
- La boucle de lecture et d’extraction en est une forme, et d’autres formes pourront apparaître
1 commentaires
Avis sur Hacker News
C’est assez drôle de voir des ingénieurs qui, pendant toute leur carrière, se plaignaient de tout ce qui interrompait leurs heures de flow de codage — réunions d’équipe, rituels agiles, suivi des tickets, backlog, Slack, e-mails, revues de conception — qu’ils présentaient comme leur activité la plus essentielle et sacrée, commencer soudainement, sans la moindre gêne, à prêcher l’importance de la collaboration et le caractère insignifiant du code et du codage, dès lors qu’une machine s’est mise à écrire du code plus vite qu’eux
Ce n’est pas faux en soi, mais il reste surprenant de voir une hypocrisie aussi flagrante de la part de ceux qui, il y a encore un an, étaient dans n’importe quelle équipe les personnes les plus asociales et les moins collaboratives
Quoi qu’il en soit, deux choses peuvent être vraies en même temps : écrire du code n’est pas le goulot d’étranglement, donc on peut développer des fonctionnalités plus vite qu’on ne peut les déployer, et être interrompu quand on fait un travail qui demande une concentration profonde reste agaçant et casse le rythme
https://en.wikipedia.org/wiki/Group_attribution_error
Les réunions qui améliorent réellement la synchronisation entre le client et le développeur sont rares et précieuses. Dans les grandes organisations, les réunions ritualisées prolifèrent souvent pour de mauvaises raisons. Les gens essaient de s’insérer dans le processus entre le client et le développeur pour montrer qu’ils existent
Personnellement, j’aime les réunions avec les clients, les utilisateurs finaux, les designers UX et les vraies parties prenantes. Je déteste les réunions avec les faux occupés de la politique d’entreprise qui monopolisent de la bande passante pour leur influence interne. Je n’ai pas besoin d’un manager intermédiaire supplémentaire entre mes utilisateurs et moi
À l’inverse, dans un nouveau monde où écrire du code est devenu très rapide et où la partie difficile consiste à comprendre les exigences métier et techniques à satisfaire, la même personne peut donner plus de priorité à ces rituels et accepter les interruptions pendant qu’un agent IA écrit le code
Changer d’avis quand les faits de la situation changent, ce n’est pas de l’hypocrisie
Si tu faisais un projet créatif avec quelqu’un en dehors d’une entreprise, il y a plein de raisons pour lesquelles tu ne penserais pas d’abord à des rituels Scrum ou à Jira. On peut valoriser la collaboration tout en critiquant ce genre de choses, c’est parfaitement cohérent
L’équipe se plaint d’avoir trop de travail et de ne plus rien pouvoir faire, alors le manager me fait intervenir. Et là, soudain, plus personne ne veut rien me passer. Je suis exactement au milieu de ça en ce moment
L’équipe dit être « complètement débordée », mais trouve quand même l’énergie d’affirmer que presque tout ce que je pourrais prendre en charge est mieux fait par eux, et qu’ils n’ont besoin d’aucune aide. Moi ça me va, je peux rester assis et être payé. Mais l’odeur est toujours la même
A : ils ne veulent pas reconnaître qu’ils sont remplaçables et que leur travail n’a rien d’unique, B : ils ne veulent pas admettre que le goulot d’étranglement, ce n’est ni le processus ni la charge de travail, mais eux-mêmes
Les ingénieurs expérimentés semblaient déjà savoir que la vraie cause des problèmes de vitesse relevait toujours davantage de l’organisation que de la technique
L’incapacité du métier à définir une roadmap productive et centrée était un problème de longue date en ingénierie logicielle. Le fait de courir sans cesse après le prochain objet brillant à très faible ROI, tout en empêchant le traitement de la dette technique systémique, a fini par ruiner à long terme plusieurs entreprises où j’ai travaillé
Je connais des ingénieurs juniors qui ont fait du C++ pendant un an entier sans jamais comprendre
std::unique_ptr, et ce genre de personne est toujours la plus lente de toute l’équipeQuand j’écrivais autrefois les évaluations de performance des juniors, la performance dépendait effectivement fortement de la vitesse, et se mesurait à peu près au nombre de lignes de code sans bug produites dans un délai donné. Les bons juniors prenaient une fonctionnalité bien définie et écrivaient vite du bon code ; les moins bons recevaient la même tâche et écrivaient soit lentement, soit rapidement mais avec beaucoup de bugs, créant beaucoup plus de travail de débogage et de réécriture
Quand on comprend clairement la justification métier, le périmètre, les entrées et la sortie attendue, le modèle de données, l’architecture système et le code en découlent presque naturellement, ou au moins deviennent beaucoup plus évidents
— Melvin E. Conway, 1967
Il faut déjà se demander si l’on comprend ce que sont les lois d’échelle comme Chinchilla, et comment fonctionne fondamentalement l’apprentissage par renforcement avec vérification
Je suis totalement d’accord sur le fait que la limite fondamentale est la capacité du métier à exprimer de manière cohérente sa propre stratégie
Mais l’avantage aujourd’hui, c’est qu’on peut essentiellement prototyper gratuitement. Avant, il fallait être extrêmement prudent dans ses investissements en effectifs d’ingénierie ; maintenant, on peut essayer bien plus de choses dans les mêmes contraintes de temps
Le vrai défi a toujours été de décider quelles fonctionnalités et quels correctifs sortir, quand les sortir, et comment développer et gérer le produit dans son ensemble ; et une grande partie de cette stratégie dépend de boucles de feedback que l’IA ne peut pas accélérer rapidement
En même temps, j’ai aussi l’impression que les dirigeants côté métier font souvent de la vitesse des ingénieurs un bouc émissaire, au lieu d’assumer les mauvaises décisions prises de leur côté
En général, le goulot d’étranglement, c’est bien le code, mais pas l’écriture du code : le code lui-même. Dans ma carrière, j’ai connu d’innombrables retards causés par des applications lentes
Il faut utiliser un éditeur basé sur Eclipse, il est lent, se fige périodiquement ou plante. Les builds prennent 15 à 20 minutes. Je tombe aussi souvent sur des applications web qui mettent une éternité à faire quelque chose qui devrait prendre 50 ms maximum
Cette liste pourrait continuer sans fin. Chaque délai est une interruption qui pulvérise ma concentration. Aujourd’hui je suis manager, je gère des dizaines de personnes et des interruptions administratives, mais j’écris encore du code dans mon entreprise
Si le logiciel est lent, il devient ma priorité la plus basse. Peu importe qui cela impacte. Si c’était vraiment important, nous ne serions pas tous pris en otage par cette mélasse logicielle lente qui nous tire vers le bas
Le code est une dette
On peut facilement voir le code comme un actif, mais fondamentalement c’est une dette. Une partie des « goulots d’étranglement » vers du nouveau code existe pour garantir que la valeur produite soit supérieure à la dette accrue. Des agents qui produisent plus de code plus vite produisent aussi plus de dette plus vite
Une grande partie de l’enthousiasme et du scepticisme autour des agents de codage tourne autour de cette question : l’augmentation immédiate de productivité — donc des livrables immédiats comme de nouvelles fonctionnalités, de nouveaux produits et de nouveaux revenus — compense-t-elle l’augmentation de la dette à long terme ? La réponse ne sera claire que dans 1 à 3 ans, et elle variera selon les domaines
Vu sous cet angle, les tentatives d’intégrer directement ce genre de goulot d’étranglement dans des workflows agentiques ont un certain sens. Il est utile de donner à l’agent de codage davantage de contexte supplémentaire, lui permettant de privilégier une vision produit cohérente et de s’opposer à de nouvelles fonctionnalités ou à des processus sans contrainte
Est-ce bien ce que l’article essaie de dire ? Que certains agents devraient assumer une responsabilité de product management, synthétiser autant que possible en une vision produit cohérente, puis rappeler cette vision de façon aussi stricte que possible aux agents de codage ?
Ces agents devraient-ils examiner les nouvelles propositions et les nouvelles pull requests sous l’angle de leur « adéquation avec la vision d’ensemble » ? Qu’on appelle cela contexte, vision ou autrement
Ces agents pourraient être très bons pour synthétiser le contexte et présenter une roadmap cohérente qui semble, sur le plan du langage, alignée avec les valeurs et la vision de l’équipe. Mais je doute qu’ils aient le discernement d’un bon manager ou d’une bonne équipe. Approuver rapidement et de façon convaincante une roadmap donnée pourrait faire plus de mal que de bien
Le minimum de code nécessaire pour répondre aux besoins métier sans complexité supplémentaire est un actif assorti d’une dette de maintenance. Comme le tracteur d’un agriculteur : c’est un actif qui demande de l’entretien, et qui se déprécie sous l’effet de la dégradation des bits si on le laisse à l’abandon
Le code qui n’existe que pour créer de la complexité inutile est, lui, de la dette pure
Oui, mais écrire du code apprend toujours quelque chose
J’ai travaillé aussi bien dans des startups à taille de fondateur que dans des sociétés cotées valant des dizaines de milliards, et je n’ai jamais vu de spécification produit, de pitch deck ou de PRD qui décrive une solution qui résoudrait effectivement le problème si on l’implémentait tel quel. C’est en le construisant qu’on apprend comment cela doit fonctionner
Le logiciel est un médium complexe et interactif. Itérer dans le code avec des gens qui veulent comprendre et résoudre le problème a toujours été la seule façon de produire un produit qui ait de la valeur. Les réunions et les diagrammes aident, mais tant qu’on n’a pas écrit un logiciel qui fonctionne, on ne sait pas si on tient quelque chose
« Le but était de tester notre algorithme de génération structurée et son équivalent open source, et de remplacer la naïve question “est-ce que ça accepte cette chaîne ?” par une question plus proche des problèmes réels : “est-ce que ça génère la bonne distribution de tokens ?”… Le mois dernier, j’ai expliqué la méthode à Codex pendant 30 minutes. Quelques heures plus tard, j’avais une première version fonctionnelle. C’était tout »
Cela prouve justement que le goulot d’étranglement était bien le code. Simplement, c’est l’IA qui l’a écrit cette fois
Quiconque pensait que « le goulot d’étranglement n’était pas le code » avait déjà discuté de l’objectif et l’avait clarifié de façon cohérente dans sa tête
Dire que le code est un goulot d’étranglement ne signifie pas forcément « je voulais cette fonctionnalité mais il fallait des mois pour la coder ». Cela peut aussi vouloir dire : « je voulais cette fonctionnalité depuis deux ans, mais je l’ai repoussée à cause de la friction consistant à m’asseoir, la traduire en code et y consacrer 5 à 10 jours »
Si le code n’avait pas été le goulot d’étranglement, il se serait simplement assis et l’aurait écrit lui-même. Mais il ne voulait pas fournir l’effort ni le temps nécessaires pour le coder, et il savait bien que cela ne demanderait pas aussi peu d’effort qu’avec un LLM
Même quand la spécification finale n’est pas claire, l’écriture exploratoire de code, la vérification, l’abandon, puis l’essai d’une nouvelle conception vont plus vite avec un LLM. Parce que c’est précisément la partie « code » qui a été accélérée
En d’autres termes, le goulot d’étranglement, c’était bien le code
D’ailleurs, ce texte lui-même ressemble à un texte généré par IA avec une instruction du type « évite les formulations trop évidentes », ce qui le rend malgré tout ennuyeux à lire
L’article disait : « Paradoxe de Jevons : quand quelque chose devient moins cher, on n’en utilise pas moins mais davantage », mais cette formulation dénature le paradoxe de Jevons
Cette phrase ne décrit pas un paradoxe, mais un effet parfaitement naturel. Quand quelque chose devient moins cher, il est normal que son usage augmente
Ce que décrit réellement le paradoxe de Jevons, c’est une situation où l’usage d’une ressource devient plus efficace, donc où la quantité nécessaire pour une tâche donnée diminue, mais où la consommation totale de cette ressource augmente malgré tout
Mais n’est-il pas tout aussi normal que le prix de cet « usage » baisse lorsque l’utilisation des ressources devient plus efficace ?
Donc oui, l’efficacité augmente et l’usage monte naturellement. Si on appelle cela un paradoxe, c’est parce que certaines personnes imaginent naïvement qu’améliorer l’efficacité est un bon moyen de réduire la consommation
Presque tout ce qu’on appelle un « paradoxe » est aussi évident que ça
Ou bien qu’un processus devenant plus efficace, donc plus rapide, nous finissions par y consacrer plus de temps ?
Goulot d’étranglement pour quoi faire ? Plus de fonctionnalités ?
Je ne pense pas que la quantité de logiciel détermine le succès d’une entreprise. Je ne pense pas non plus que capter davantage de contexte soit si important
Ce qui compte, c’est la qualité du contexte. À quel point les humains raisonnent-ils bien ?
Ensuite vient l’attitude. À quel point les humains gèrent-ils bien les mauvaises situations ?
Ensuite vient la gestion des ressources. À quel point l’entreprise gère-t-elle bien ses personnes et son argent ?
Enfin, il y a la chance. Combien d’éléments hors de notre contrôle jouent en notre faveur ?
Voilà des goulots d’étranglement assez sérieux pour une entreprise. Je ne vois pas les agents les résoudre de sitôt
Le goulot d’étranglement quand on veut améliorer les applications utilisées par une entreprise non logicielle consiste à s’assurer que le logiciel accomplit bien toutes les tâches logicielles qui apportent réellement un bénéfice au métier
Faire gagner du temps, rendre les humains plus productifs, réduire les erreurs humaines, rendre l’entreprise plus efficace, améliorer les marges
Tout cela est assez difficile à prévoir et à quantifier. On peut partir d’idées susceptibles d’aider l’entreprise, concevoir, prototyper et tester. Au final, on essaie de construire ou d’améliorer une application logicielle, puis de mesurer à quel point elle améliore réellement l’entreprise
À toutes les étapes, il est difficile de garantir que le logiciel traite le bon problème de la bonne manière et améliore effectivement l’entreprise à la fin. Peu importe à quel point créer le logiciel est devenu rapide ou facile
Cela dit, la vitesse peut vraiment aider. On peut prototyper, tester et améliorer les boucles de feedback
Avec les assistants de codage IA, des tâches qui relevaient autrefois de développeurs juniors sont désormais exécutées via un prompt rapide et un agent qui tourne en arrière-plan
Ces tâches de développeurs juniors sont maintenant livrées presque sans intervention humaine par les assistants de codage. Le backlog se vide plus vite qu’on n’y ajoute de nouveaux éléments. Et comme la capacité de traitement n’est plus le problème, on ajoute aussi de plus en plus de nouveaux éléments
Le défi devient maintenant de suivre le volume de changements. C’est ce que nous observons directement dans notre organisation
Ce n’est pas parce qu’on peut imaginer d’autres goulots d’étranglement que la génération de code n’en était pas un, ou qu’elle n’en est pas un aujourd’hui. Le concept même de backlog montre que c’est bien un goulot d’étranglement
« Le logiciel, c’est ce qu’il reste après qu’un groupe d’humains a négocié entre eux ce que le système doit faire »
J’aime bien cette formule. Je suis particulièrement d’accord sur le contexte. C’est précisément là qu’une équipe expérimentée, stable dans le temps, est récompensée
J’ai dirigé ce type d’équipe pendant des décennies. Quand notre département a fini par être fusionné, même l’ingénieur avec le moins d’ancienneté avait 10 ans de maison
Quand une équipe travaille ensemble aussi longtemps, les surcoûts de communication tombent à un niveau presque négligeable
C’est pour cela que la culture actuelle des passages éclair dans les entreprises me déprime autant
Aujourd’hui, je travaille surtout seul. Ma productivité est très élevée, mais mon périmètre est vraiment limité
L’époque où je faisais partie d’une bonne équipe me manque
Sur quel genre de projet travaillez-vous exactement pour que la seule partie difficile soit de comprendre les fonctionnalités voulues par le management, et que tout le reste puisse simplement être « tapé » ou, aujourd’hui, délégué à un LLM ?
Si c’est vraiment votre boulot, il n’est pas étonnant que tant de gens sur HN pensent que les LLM peuvent les remplacer
Donc nous refaisons encore un tour de manège à parler d’anxiété, à nous répondre à côté, puis à attendre la prochaine occasion de commenter 30 minutes plus tard
La plupart sont des déchets brûlants en termes de qualité de code, à cause des cycles d’offshoring et de licenciements