Récemment, je ne parle presque que de LLM sur mes tweets. Je suis complètement accro. Dès que j'ai un moment de libre, je demande ou je pose des questions à un LLM. En particulier, faire écrire du code par un agent me donne l'impression d'être absorbé par un jeu social dès sa sortie, à tel point que je n'ai pas une minute à perdre.
C'est amusant de faire écrire du code par un agent. Je suis en train de créer un SGBDR et j'ai l'impression que les implémentations apparaissent les unes après les autres avec des sensations du genre "Qu'est-ce que je fais ensuite ?", "Est-ce que je crée une interface compatible PostgreSQL ?", "Hein ? C'est possible ?", "C'est fait !". Bien sûr, ce n'est pas parfait dès le début, et au fur et à mesure que je lui fais écrire des tests unitaires, de plus en plus de défauts apparaissent, mais la vitesse de développement compense largement cela. Plus que tout, le fait qu'un code de près de 100 000 lignes apparaisse en un clin d'œil avec à peu près la même charge de travail que si j'avais un interlocuteur de plus en dehors du travail est quelque chose qui inspire la crainte plus que l'admiration.
Comme ceux qui suivent mes propos sur les réseaux sociaux le savent, je n'ai jamais vraiment fait confiance au génie logiciel pendant de nombreuses années. J'avais l'impression que ce n'était pas quelque chose qu'un simple programmeur pouvait apprendre et maîtriser, mais plutôt une discipline pour l'ingénierie du comportement collectif lors de la programmation en groupe, et je doutais fortement qu'elle puisse être appliquée à tous les domaines de la programmation, qui sont si divers. Cependant, lorsque j'utilise plusieurs agents, je me rends compte que j'adopte naturellement une approche de génie logiciel, car j'ai besoin de repérer l'existence de bogues sans lire le code, ou d'étendre progressivement les zones de confiance. Je n'intègre pas spécialement la densité de bogues ou les courbes de convergence, mais je suis conscient que si je prenais du recul, je ne serais pas si loin de ces concepts.
Même dans une situation où un amateur pourrait crier à un agent : "Crée un logiciel sans bogues !!!", si vous donnez des instructions persistantes avec une connaissance du logiciel, que vous analysez le travail abandonné par le biais du dialogue et que vous donnez à nouveau des instructions, la plupart des problèmes seront résolus. En répétant ce genre de travail, je suis soulagé de constater que les intuitions que j'ai cultivées jusqu'à présent n'ont pas été vaines, mais en même temps, je sens viscéralement que ce n'est qu'une question de temps avant que l'agent ne soit capable de résoudre ce genre de problèmes de manière proactive. Sur ce point, je suis assez pessimiste quant à l'avenir du travail des programmeurs.
Le code écrit par l'agent ressemble honnêtement à une vallée dérangeante et ne me donne pas envie de le maintenir, mais le point de départ est que les ingénieurs logiciels ne veulent pas maintenir le code. Ils ne le maintiennent qu'à contrecœur parce que ce code génère de l'argent dans leur travail, et la lecture du code est considérée comme un dernier recours en matière de maintenance pour les programmeurs professionnels (je pense que les programmeurs artisans devraient faire ce qu'ils veulent s'ils aiment manipuler certains codes dans le but de les améliorer, et je suis moi-même plus enclin à cela). La programmation est un travail de construction, tandis que le génie logiciel est une activité continue qui permet de créer de la valeur de manière continue, et, sans vouloir choquer, c'est le résultat d'années d'efforts pour garantir la qualité sans avoir à lire un code qu'on ne veut pas lire.
x.com
Les règles ont considérablement changé, donc certaines choses peuvent être utilisées et d'autres non. J'écrirai autant de conseils que possible que je ressens actuellement ci-dessous.
L'ingénierie du contexte est une théorie organisationnelle
Que ce soit écrit par une IA ou non, la vérité universelle du logiciel est que le code continue de croître en permanence. Je pense que la longueur du contexte des LLM continuera d'augmenter à l'avenir, mais la vitesse de croissance du code logiciel la dépassera toujours. Même si le LLM pouvait éviter le problème du contexte, la plage de contexte sur laquelle il peut se concentrer avec succès est limitée, et le problème de la recherche d'une aiguille dans une botte de foin sera toujours présent. Bien sûr, toute l'équipe ne peut pas mettre l'intégralité du code de production dans sa tête, donc la division du travail se fera sans qu'on le leur dise. Cette division du travail est une ingénierie du contexte sous un angle différent. En d'autres termes, si vous jetez l'ensemble du projet dans le contexte, il sera trop grand pour que vous puissiez penser à quoi que ce soit, donc la façon de diviser le travail est de dire "Je veux que vous ajoutiez cette fonction à ce module pour ce travail, et vous n'avez pas besoin de savoir quoi que ce soit qui ne soit pas nécessaire pour l'exécution de cette tâche", ce qui est fait pour les nouveaux employés dans la plupart des professions, et ce n'est pas limité aux agents d'IA. Comme vous le constaterez si vous utilisez des agents d'IA, ils sont pathologiquement rapides pour transformer 0 en 1. Ils ont été élevés sur un tel ensemble de benchmarks, et résoudre des bogues que les humains auraient du mal à résoudre n'est qu'un bonus. La raison pour laquelle ils sont rapides pour transformer 0 en 1 est qu'il y a très peu de points de contact à prendre en compte, car il n'y a pas de code existant à mettre dans leur tête pour exécuter cette tâche. Plus le contexte d'un programmeur est petit, plus il a tendance à vouloir créer des microservices, car les microservices réduisent le contexte qu'il doit mettre dans sa tête. Les microservices sont un exemple extrême, mais la division interne du logiciel est une façon de limiter la portée dont les autres ont besoin de se soucier, et la "séparation des préoccupations" a toujours été la séparation des informations qui devraient être mises dans la tête de l'agent. Il n'y a toujours pas de consensus complet sur ce qu'est "l'architecture logicielle", mais à mon sens, c'est la division du contexte qui doit être mis dans le cerveau des personnes qui travaillent dessus. Même si un architecte introduit un objet valeur sur un coup de tête, si le contexte que le programmeur subalterne doit mettre dans sa tête ne change pas, alors on ne peut pas dire que l'architecte a fait du bon travail. Je pense que la façon de diviser les tâches d'une manière qui facilite le travail de l'agent et la façon de diviser l'intérieur du logiciel d'une manière qui facilite le travail des humains sont assez similaires. Mon intuition actuelle est que les préoccupations à ce niveau sont plus importantes que je ne l'imaginais, donc je pense que nous devrions utiliser des modèles haut de gamme avec un contexte important et intelligent, mais peut-être que des modèles moins chers fonctionneraient bien si nous déchargions avec succès vers des agents de recherche, etc.
Les LLM sont chers
Tout le monde dit que les modèles haut de gamme produisent un code nettement meilleur, mais les modèles haut de gamme coûtent 10 ou 20 dollars par million de jetons. Le travail effectué à l'aide de ce contexte prendra des heures à un programmeur, donc je pense que cela en vaut la peine, mais il est préférable de pouvoir confier le travail à un modèle moins cher si possible. En fin de compte, la concurrence par les prix peut entraîner une baisse drastique du coût des modèles haut de gamme actuels et une utilisation excessive, mais à ce moment-là, il y aura des modèles haut de gamme qui seront mis en avant et annoncés comme étant capables de résoudre des problèmes difficiles qui ne peuvent pas être résolus ailleurs. Par conséquent, je pense qu'à l'avenir, nous continuerons à confier les tâches de programmation qui ne sont pas si difficiles à des modèles moins chers. De plus, les LLM locaux, qui sont l'extrême des modèles moins chers, sont attrayants en tant que destination de délestage, et je pense qu'un groupe d'agents locaux qui sous-traitent les tâches définies à l'aide de modèles haut de gamme est une possibilité réaliste. Je ne sais pas dans quelle mesure les LLM locaux actuels peuvent effectuer des tâches de codage complexes, mais l'histoire de laisser un modèle moins cher écrire le code, d'abandonner la partie débogage et de transmettre ce savoir-faire à un modèle plus intelligent deviendra bientôt du bon sens, je pense. Les LLM locaux et haut de gamme travailleront ensemble en appelant des sous-agents, et la forme accomplie d'une société de développement de logiciels pourrait en fait être une équipe de quelques personnes qui continuent à exécuter un grand nombre de LLM locaux. Le prix des AMD Ryzen AI Max aura probablement tendance à augmenter considérablement, car leur concurrent est un programmeur humain.
Les agents d'IA sont instables
Je ne sais pas exactement où les implémentations sont mauvaises, donc je ne dirai rien de définitif, mais des arrêts inexpliqués, des erreurs intermittentes et des choses incompréhensibles se produisent constamment. Il n'est pas rare que le noyau ne plante pas, mais que la vitesse de réponse de l'éditeur devienne de l'ordre de la minute. De plus, la qualité des réécritures est très variable, et il arrive souvent que les numéros de ligne de la destination de réécriture soient complètement décalés, ce qui cause beaucoup de dégâts. Ils remarquent volontairement quand ils sont cassés et vont les réparer, donc ce n'est pas si fatal, mais en tant que tel, il existe des astuces pour utiliser des choses instables telles quelles, et autant que je sache, la boucle de Larval et le suivi des progrès qui l'accompagne sont efficaces.
x.com
En un mot, la boucle de Larval consiste à mettre le lancement de l'agent lui-même dans une boucle. Cependant, demandez dans l'invite d'écrire les progrès de cette fois quelque part, et de lire ces progrès au début de la boucle. Ensuite, l'agent exécutera la "tâche de cette fois" après avoir reçu les "progrès jusqu'à présent" comme contexte. Le bon côté de cette approche est que l'agent continuera à fonctionner d'une manière ou d'une autre, même s'il s'arrête en cours de route ou s'il est tué par OOM. Les mémos de progrès peuvent devenir trop volumineux, mais vous pouvez écrire l'invite pour les résumer et les compresser au besoin. Cependant, si vous avez une seule boucle, toutes les tâches seront effectuées avec un seul modèle coûteux, de sorte que la phase de conception et de division des tâches sera confiée à un modèle coûteux, et les tâches qui semblent faciles seront confiées à des agents moins chers, etc. De plus, le contenu de la boucle elle-même devient de plus en plus complexe, et puisque vous programmez pour savoir s'il faut appeler ou non un agent de codage, c'est en fait de la métaprogrammation. Je ne suis pas encore arrivé à ce stade... Améliorer la boucle elle-même avec un LLM deviendra naturellement une évidence à un moment donné.
bsky.app
Dans l'invite qu'antirez a publiée pour accélérer le code, il est intéressant de noter qu'il indique "5. Utilisez ce fichier pour suivre les progrès". Puisque le travail se poursuivra en se référant au même texte même s'il se termine en cours de route, il est très logique que le texte contienne les progrès jusqu'à présent.
5 auto-évaluations
Le code produit par les agents de codage fonctionne bien dans 90 % des cas, mais une fois qu'il atteint une quantité importante, des points à améliorer sont trouvés chaque fois qu'il est auto-évalué. Bien sûr, j'aimerais qu'ils écrivent un code parfait qui n'a pas besoin d'être évalué dès le début, mais comme c'est difficile même pour les humains, il doit y avoir des défauts que les LLM ne peuvent pas trouver à moins qu'ils ne soient évalués dans un contexte différent. Il faut parfois du temps aux humains pour réfléchir à leur propre code, mais les ingénieurs étrangers écrivent que lorsqu'un agent de codage s'auto-évalue, il converge souvent en 5 fois.
Bien sûr, cela coûte cher, mais c'est toujours beaucoup moins cher qu'un humain, et si vous l'intégrez dans le système, il n'y aura plus de place pour l'intervention humaine. Je ne sais pas si le chiffre 5 a une signification spécifique, et il deviendra probablement un chiffre différent à l'avenir, mais intuitivement, même si vous faites évaluer le code écrit par un agent plusieurs fois, des points à améliorer ressortiront toujours. La spécialité des LLM est la réflexion. (Il est possible que des commentaires d'évaluation soient ajoutés comme des défauts pour établir un dialogue, de sorte qu'une évaluation des commentaires d'évaluation eux-mêmes puisse être nécessaire). Il semble que l'on continuera encore pendant un certain temps à dire qu'un humain doit examiner le code écrit par un agent de codage avant qu'il ne soit utilisé en production, mais en tant que tel, il deviendra du bon sens que la machine elle-même l'évalue N fois avant qu'un humain ne l'examine. Il semble que les côtés créatif et critique s'améliorent mutuellement lorsqu'ils sont séparés. L'évaluation par des agents de plusieurs entreprises pourrait faire émerger de nouvelles perspectives.
C'est un peu trop long, alors je vais poster à partir d'ici pour le moment.