Aller au contenu

Cinq ans à apprendre à bâtir des agents de code

C’était intéressant de voir les gens s’adapter au coding par agents.

Ça fait cinq ans que je suis dedans, donc mon point de vue est un peu différent. J’ai commencé par entraîner des modèles GPT2 pour prédire mon propre comportement de code stochastique. Et j’ai eu pas mal de chance là-dessus. Jusqu’à l’année dernière, il y avait un plafond de complexité. L’endroit où les modèles décrochent et où tout part en vrille.

Au début, j’ai essayé de changer ma façon d’utiliser les mots pour que la machine puisse les analyser sans perdre son gradient. Et ça a aidé. À partir de là, j’ai commencé à écrire des agents de code multi-modèles pour qu’ils se contrôlent entre eux. Mais une partie du problème, c’étaient les hallucinations.

Vous lancez une réunion de planification avec deux d’entre eux pour concevoir une application web, et la seconde d’après, ils sont en train de dessiner les porte-gobelets de votre navette spatiale parce qu’ils ont trouvé un chemin tangentiel plus intéressant.

J’ai fini par trouver un moyen de régler ça, mais l’état par défaut, c’était le chaos dadaïste !

De Klara aux outils actuels

Ensuite, je suis passée aux modèles d’Anthropic et j’ai développé l’agent Klara. C’était plus qu’intéressant. Klara avait des comportements inhabituels et uniques pour un agent de code, des choses que je n’avais jamais vues avant, ni depuis. Tout ça a duré environ un an, et j’ai développé des outils respectables pour le job.

Et puis on arrive à l’ère actuelle, avec les nouveaux outils que je change toutes les huit semaines pour rester à jour sur l’industrie et les tendances. Certains sont bons, d’autres non.

Mais ça m’a fait réfléchir à l’importance réelle du processus d’ingénierie. Pour n’importe quel projet, il faut comprendre que l’agent n’est pas un développeur professionnel, mais un outil. Tout le travail d’ingénierie banal et moyen doit toujours être fait si vous voulez construire quoi que ce soit pour le monde réel.

En d’autres termes, l’humain dans la boucle signifie que vous devez toujours être impliqué dans le processus de réflexion sur votre design, la vérification du code et le guidage de l’agent sur les points qu’il ne peut possibly pas connaître.

Faites-le correctement, et votre avantage sera soit la vitesse, soit l’échelle. Parfois les deux.
Faites-le mal, et tout votre système fond.

Certains agents sont meilleurs que d’autres, mais au bout du compte, les décisions qui vous mènent au résultat sont les vôtres.

Et je pense que c’est ce que les gens oublient quand ils parlent des méfaits du « vibe coding ».

Ils attendent que la machine soit un auteur, mais on ne peut pas être auteur sans intention.

Cette partie-là, c’est toujours votre boulot.