Les stats d'abord, pour les nerds ! 1 conversation glm-5.3, 3 compactages, 607 agents, 9 milliards de tokens cramés qui auraient coûté 1.5k$ si j'avais payé, et tout ça qui tourne pendant... 8 jours !
Le résultat ? https://slopcad.dbuild.dev et https://github.com/DimitriGilbert/slopcad ! Enjoy !
Bon. Maintenant que ceux qui voulaient juste le résumé en 3 secondes sont partis, on peut parler comme des grands. L'article qui suit ne parle pas de SlopCad, mais de ce qui l'a rendu possible.
Ce run, c'est ce que donnent des années à bosser avec l'IA autour d'une idée fixe : make no mistakes.
Zéro erreur est un miroir aux alouettes
Moi, toi, un agent IA : rien ni personne n'est à l'abri des conneries. Toi, tu les vois venir. T'as l'expérience pour reconnaître les patterns. Tu mets des process pour que ce que tu crées soit à (tes) standards. Et parfois tu apprends en te plantant très publiquement...
Un agent IA ne fait rien de tout ça. Par contre, il s'exécute si tu le lui demandes... mais... tu lui demandes quoi exactement ?
Des tests, des tests, et encore des tests au cas où
J'ai vu la lumière et j'utilise surtout typescript en mode ultra strict sur les types, donc cette partie est réglée. Mais si tu continues avec des langages vraiment-pas-terrible genre javascript ou python, tu vas vouloir tester à mort les inputs et outputs de tes fonctions. Les unit tests ou le type checking, c'est la première tranche de fromage, et en général c'est presque gratuit !
Par contre, être sûr de recevoir et d'émettre ce que tu attends, ça ne veut pas dire que t'es sorti d'affaire. Il faut aussi tester le comportement réel du code... Ça me fait mal de l'admettre, mais je crois que le TDD est la voie ici ! Tests en premier, implémentation qui les valide ensuite. J'ai toujours bossé solo ou en petites équipes, donc les tests en général, le TDD surtout, c'était très cher pour le retour (EN PETITE ÉQUIPE OU SOLO). Mais maintenant qu'ils mettent presque plus de temps à tourner qu'à être écrits, il n'y a littéralement AUCUNE EXCUSE !
"Ayé, c'est bon, on a fini ?!" te traverse peut-être l'esprit. Nan. Pas encore. Des types serrés et un algo correct, tes users s'en foutent (au début). Ils ne voient même pas le code. Ce qui les intéresse, c'est comment ils interagissent avec : l'UI ! Tu pourrais unit-tester ton UI, bien sûr. J'ai essayé. Je trouve ça stupide. Ce qui ne l'est pas, par contre, c'est les tests E2E ! Et pour parler de cher (mais non, pas elle...)... Je ne sais pas pour toi, mais les rares fois où j'ai essayé dans le passé, c'était un cauchemar : des heures, et une charge de travail continue si je voulais les garder à jour... Tu sais ce qui n'en a rien à carrer de la tâche écrasante, qui te fait fondre le cerveau, qu'est le testing E2E ? L'IA.
Et maintenant que les modèles peuvent réellement VOIR leur travail, construire les tests E2E les force à vraiment utiliser ce qu'ils ont fait, et ça choppe plein de problèmes au passage. Ça m'a pris des mois pour m'y mettre et je le regrette : ça m'aurait probablement fait gagner des semaines de taf sur l'année...
Comme chaque décision d'ingénierie, les tests présentent un problème... Ils sont chers. Pas en cerveau, pas en tokens : en temps ! Tu te souviens quand je parlais des tests qui mettent plus de temps à tourner qu'à être écrits ? Ouais, beh... c'est arrivé sur SlopCad. Chaque test E2E tournait sur une nouvelle instance playwright séparée, en séquentiel... Au pic, 30 minutes pour faire tourner les E2E. (HAAAAAAAAAAAAAAAAAAAAAAAAA........ ^^')
Je l'ai réglé en 2 passes. D'abord une exécution concurrente, N à la fois : 12 minutes (6 threads étaient le plus rapide et stable mais CPU de ma machine à plat à 100%...). Ensuite une qui mimait vraiment une session utilisateur, tout dans un seul onglet. Et là, on est redescendus à environ 5 minutes !
Garde ce truc en tête si tu comptes faire ça sur tes projets.
Coverage, DRY et un petit CRAP
Les tests aident, mais la tranche de fromage est pleine de trous, et le slop ça rentre partout. Donc on en rajoute (plus de fromage est une solution acceptable à tous les problèmes). La deuxième couche anti-slop, c'est les métriques !
À quel point ton code est testé ? IMO, en dessous de 50% autant pas le faire, et une cible low cost c'est au-dessus de 65%.
Comme tout le monde le sait, l'IA redéclare joyeusement des types et réécrit des fonctions/méthodes/fonctionnalités sur place au lieu de réutiliser l'existant ou de le rendre accessible pour plus tard. C'est une source majeure de bugs dans plein de projets vibe-codés (veni, vidi, pas vici), et c'est généralement très chiant à réparer, alors que ça ne coûte quasiment rien si c'est forcé tout le temps pendant le dev. La détection de code redondant aide beaucoup à choper ces cas, mais il y a un autre truc dont je parlerai plus tard.
Et le boss final : les god modules/fonctions, le fichier cauchemar de 1K+ lignes plein de if, de switches, de callbacks mariné aux fonctions anonymes... on les adore tous ceux-là, hein ? Demander du code testable (et testé) règle déjà une bonne partie du truc, mais la plupart des modèles ont un talent pour fourrer de la complexité partout où ils peuvent... C'est mauvais pour toi (pire si tu relis le code), c'est mauvais pour eux quand ils le maintiennent, personne ne gagne ! Je ne donnerai pas de chiffre ici, et je ne pense pas qu'il soit utile de devenir dingue sur ta cible CRAP, mais en avoir une est clairement un besoin !
Si une de ces métriques n'atteint pas la cible, le travail est renvoyé direct à son créateur pour le battre jusqu'à exécution parfaite (mon boulot rêvé dans la vie ? ministre de l'intérieur...).
Bon, maintenant qu'on a fini avec le blabla, on va peut-être se mettre à travailler sur le bouzin, non ?
Préparer le taf
J'ai dit 1 conversation ? Huum... j'ai peut-être un peu menti. Roooh cavaaaaa, tu peux pas t'attendre à ce qu'un logiciel de CAD sorte d'une seule conversation avec l'IA ! Soyons sérieux !
C'était 3, en fait... Je sais, scandaleux, mais laisse-moi expliquer...
La 1ère conversation, c'était avec chatGPT (probablement Luna, je n'ai pas de sub) sur le site (side note : OMG, l'expérience était atroce ! ça rame du cuuuuuuuul p'tin ! ça lag, ça reste vide bref, ni fait, ni à faire !). J'ai demandé, de manière très candide, s'il y avait un truc CAD open source en react. Ça m'a ressorti un tas de trucs... rien qui faisait ce que je voulais...
Par contre, gpt m'a dit que je pouvais me faire le mien avec des kernels CAD OSS. Donc j'ai demandé un peu plus d'info en précisant ce que je voulais : composants shadcn, browser first, complètement paramétrique, etc, etc...
Quelques allers-retours plus tard, j'avais un PRD et un plan, en utilisant les skills "grilling" et "to-spec" de Matt Pocock et ma propre "subagent-orchestration".
Ensuite j'ai switché sur Zcode pour utiliser glm-5.3, une review bien raide organisée par la Kommandantür et un autre tour de grilling, pour avoir les fichiers PRD et plan finaux. Le plan de développement orchestré qui en est sorti est ici (repo encore privé pour un moment).
C'est l'étape la plus engageante du processus, et ça peut prendre des heures pour avoir un plan qui convient. Ne zap pas ça. C'est ce qui va déterminer TOUTE la suite.
Oui, un plan ne survit jamais au contact avec l'ennemi. Mais un bien ficelé, ça fait la différence entre un projet bien organisé et un jus de YOLO...
Des fondations solides
On peut demander à une IA de bootstrapper un projet de 0. C'est une façon de faire. Je ne pense pas que ce soit une façon valide !
Utilise des repos templates ou des stack builders, pour avoir un workspace prêt en une seule commande !
En plus d'être plus rapide, le vrai bénéfice c'est que tu sais à quoi vont ressembler tes projets. Et ça veut aussi dire que tes agents IA ne sont pas laissés à deviner où vont les trucs.
Comme j'ai vu la lumière et que j'utilise typescript, j'ai survolté l'ampoule avec https://better-t-stack.dev. N'importe quel framework et outil digne d'intérêt dans l'écosystème typescript est supporté : SPA browser only, fullstack NextJS ou tanstack, backend spécifique (avec ou sans DB), app native/mobile, web extension... Ça te range tout pour toi et ton agent, pour que le taf démarre plus vite avec plus de cohérence !
Je ne connais pas d'équivalent en python ou autres langages, mais tu peux toujours faire ton propre script de bootstrap. Ce n'est pas si dur avec l'IA, et si t'es un serial-builder, ça te fera gagner des heures et des tokens à ne plus compter ! (Je serais curieux de savoir ce que vous utilisez BTW, même dans les langages vraiment-pas-terrible 3:D)
C'est à ce moment-là que tu devrais faire configurer ton harnais de test par ton agent. better-t-stack ne gère pas ça pour l'instant, malheureusement...
Maintenant, armé de ces tranches denses de fromage anti-slop, du pain bootstrappé et de la recette, je pense que c'est le moment de monter ce sandwich, non ?
Le Chef, les Cuisiniers et la cuisine
P'tin, j'ai la dalle déjà ^^ ... Breeeef.
Avec le plan, tu pourrais te dire que c'est bon, on y va là ! Il est bien construit et relu et corrigé, et découpé en phases et sous-phases, et on a des contrôles qualité partout, on est bons, hein ?
Pour être honnête, avec un modèle récent et un bon harness, il trouverait probablement tout seul à utiliser des subagents et orchestrer le truc. Mais pourquoi laisser ça au hasard ?
En plus, ça voudrait dire que je pourrais pas vous briser les oreilles avec ma skill subagent-orchestration... c'est littéralement le perso principal de l'histoire !
J'ai créé cette skill en janvier et je l'utilise tout le temps depuis. C'est une skill pour aider à orchestrer des subagents... chocbar de ouf n'est-il pas ?
Donc ça marche comment, concrètement ?
Boucle implementer-verifier-fixer
Normalement, t'es censé avoir compris que le plan est déjà découpé en phases et sous-phases. Ça veut dire que, pour chaque sous-phase, l'orchestrateur dispatch un agent implementer qui va faire ce travail.
Quand cet agent a fini, un verifier est dispatché pour, oui, vérifier le travail. (ouais, je sais, je pense aussi que je mérite un taf pour trouver des noms, je suis vachement bon) Idéalement, un modèle différent, ou même plusieurs modèles pas chers (avec une réconciliation), pourraient être utilisés ici. Je suis fauché mais z.ai avait des offres vraiment pas chères l'an dernier, donc glm only pour moi.
Voici venu le temps des rires et... pardon, c'est sorti tout seul... plus sérieusement, tu te souviens de mon truc sur les types stricts et le code DRY dont je parlais plus tôt : ne laisse pas ça seulement sur l'agent qui fait le travail, fais vérifier par un autre / d'autres !
Qualité non respectée ? Bug ? code perave ? le travail part chez un fixer (ça peut être l'implementer si ton harness le permet) pour remettre les choses bien droites (comme les bottes du ministre de l'intérieur).
On peut danser comme ça jusqu'à 3 fois (ça me paraît un bon compromis pour éviter les boucles infernales) ensuite, l'IA fait appel à toi pour démêler la situation. Ça ne m'est arrivé qu'une seule fois depuis janvier :)
Enfin, quand c'est bon, la sous-phase d'après est faite, jusqu'à ce que la phase soit finie. C'est le moment où un autre validateur phase-wide est dispatché pour vérifier le travail total. Ça peut sembler overkill, souvent... ça l'est, mais j'ai attrapé de vrais défauts tôt comme ça sur d'autres projets, donc ça reste. (à voir comment les modèles évoluent dans le futur...)
Ce serait un bon endroit pour faire tourner un modèle plus gros / fort / malin qui chopperait le code sloppy et l'archi... Étant un pauvre avec seulement un sub z.ai, je ne l'ai pas fait, mais une intervention Fable de temps en temps aiderait clairement le codebase, pour sûr !
Commit (ou pas), PR (ou pas) : c'est à la fin d'une phase principale que je demande à l'agent de faire toute la danse de versioning (c'est comme la danse de la pluie, sauf que ça aide l'eau à rester dans tes yeux :D)... Ça ne suffit peut-être pas... Je n'ai pas encore eu de surprise, but mileage may vary, c'est pour ça que c'est laissé hors de la skill, chacun fait son assiette !
Et t'as pigé l'idée : découpe le travail, boucle sur une phase jusqu'à ce que ce soit fait et testé, rince, répète. Rien de compliqué, surtout parce que ton orchestrateur gère tout ça tout seul :D
Des preuves, ou ça n'est pas arrivé
Exact. Des rapports de métriques navigables, et au moins des screenshots des tests E2E. Mais ces jours-ci je demande carrément que la session E2E soit enregistrée !
Il n'y a pas grand-chose de plus à dire ici. Je l'ai déjà dit : les agents mentent. Ils te diront qu'ils ont fini et que tout est vert... c'est faux.
La seule façon pour moi de checker jusqu'à récemment, c'était de tester le vrai travail, et invariablement rager en moins d'une minute. Et puis quelqu'un a mentionné d'enregistrer ses tests, et ça a été une révélation !
Tu n'as même pas besoin de regarder la vidéo à chaque fois (ou du tout pendant un moment). Ça force juste l'agent à faire quelque chose en demandant des preuves. C'est génial (et je ne me souviens plus qui c'était ^^') !
"J'ai fini !" — Non.
Toutes les phases sont finies, les PRs sont stackées, les preuves vidéo sont là et validées. Tu aimerais entendre que la prochaine étape c'est le bouton publish !
XD. Genre, t'as lu quoi au-dessus ? On a demandé à l'IA de créer un plan, le code, de le review et le tester AVEC preuves vidéo, et tu penses qu'on a fini ? C'est mignon...
Donc j'ai reparlé, encore, de subagent-orchestration. Mais un truc dont je parle moins, c'est ma skill subagent-review, que j'utilise probablement encore plus !
Le nom est parlant (encore) : c'est une review, menée par des subagents, avec une première étape qui est toujours une phase de mapping. Un agent mappe le code et crée un plan de review, groupe les fichiers (souvent par fonctionnalité) à reviewer, et l'orchestrateur mène ensuite le plan par vagues de 5 (nombre complètement arbitraire pour les limites de concurrence de z.ai). Le code dans ces fichiers est relu pour lui-même, mais l'agent a aussi pour tâche de le comprendre (en lisant des fichiers en plus au besoin) et de s'assurer de trouver les failles logiques / sécu aussi.
Quand toutes les reviews sont finies, un autre groupe d'agents est lancé pour vérifier les problèmes remontés (autant que d'agents d'exploration, mais je devrais travailler là-dessus maintenant qu'on a des modèles avec plus de contexte !). Cette review de review vient du fait que je suis parti à la chasse à un bug inexistant y a quelques mois, et ça a prouvé son utilité dans la plupart de mes reviews cette année : rejeter des bugs hallucinés, mais plus souvent en trouver de nouveaux.
Et ensuite, une fois que toute cette ménagerie est terminée, un plan de fix est créé par un agent final pour organiser le travail. Et ensuite tu devines ?
Si t'as dit un autre round de subagent-orchestration pour exécuter le plan, t'es malin et t'as raison (tu vois, ce n'est pas si dur ;)) !
S'il te PLAÎT, dis-moi qu'on a fini maintenant...
Qui va leur dire ? La vraie réponse... ça dépend :)
C'est un outil interne ou un side project ? Ça marche assez bien, et tu peux toujours travailler / améliorer dessus ? Beh alors ship, utilise, casse, et ainsi de suite ! T'as fait ce sandwich, autant en prendre une bouchée !
Maintenant, si c'est de l'infra critique, du taf client ou un projet public... je ne le laisserais pas comme ça ! Autant l'IA fait un job décent ces jours-ci, la charge reste sur toi de valider. Donc utilise-le et casse-le jusqu'à ce qu'il n'y ait plus rien à casser ! T'as déjà tous les E2E hors du chemin, donc fais des trucs cons auxquels l'IA ne pense pas. À chaque fois que ça casse, en plus de faire réparer par un agent, demande-lui d'ajouter un test pour être certain que le problème ne revienne pas, et pourquoi pas de trouver d'autres patterns similaires ! Trouvé une fois, plus jamais à y penser.
Et si t'es d'humeur, c'est le moment où tu peux toujours ajouter "une feature de plus"... :P
Regarde l'horloge, les tokens et ton portefeuille cramer
Le principal inconvénient de bosser comme ça (en plus d'être assez lent), c'est que c'est une vraie fournaise à tokens... J'utilise un plan coding glm z.ai (pro) et j'ai un legacy plan, ce qui veut dire que je n'ai pas de limites hebdo... et putain que c'est bien...
Le résultat : un run de 8 jours qui a consommé près de 9 milliards de tokens (70% en glm-5.3 et le reste en 5.3-flash) et 607 agents, ce qui aurait frôlé les 1.5k$ si j'avais payé les tokens (/déglutition gênée)
Tu pourrais couper sur la review et toute l'étape review-validation pendant le subagent-review, mais je ne pense pas que leurs coûts soient significatifs si tu pèses les bénéfices. Comme je disais plus tôt : trade off d'ingénierie... un peu plus de coût, un peu moins de slop...
La bonne nouvelle (enfin, bonne-ish) : la partie lente a une solution : les worktrees ! (La mauvaise-ish : ça empire le premier problème)
La skill d'orchestration prévoit déjà du parallélisme, mais seulement s'ils ne touchent pas les mêmes fichiers, donc ça n'arrive pas si souvent...
J'ai été réticent à utiliser les worktrees jusqu'ici... Je me suis déjà brûlé avec les git submodule et j'étais méfiant de la magie git... Mais j'ai essayé le dernier jour et demi sur SlopCad, et maintenant je regrette de n'avoir jamais plongé !
Certaines parties du taf auraient pu en bénéficier dramatiquement si j'avais commencé plus tôt au lieu de rester séquentielles, en plus, je pense que le coût de réconciliation aurait été minimal. Meh, plus tu essaies...
Le workflow agent ultime (*pas)
Je ne vais pas mentir, je suis assez fier de mon workflow ! Comme je l'ai dit, je l'utilise et le raffine depuis des mois, et ça matche très bien mon style de travail.
Ça marche à merveille sur les nouveaux projets, et si tu omets toute la partie bootstrap, ça rentre bien dans un projet existant (juste assure-toi de planifier avec accès au code, duh ^^)...
Malgré mon petit moment d'auto-congratulation, je pense que des améliorations sont possibles !
Comme j'ai touché plus tôt : les tests ne doivent jamais devenir un fardeau, et ça doit être encodé et forcé strictement tout au long de l'orchestration. 30 minutes de tests run 3 fois dans une phase, c'est déjà 20% d'une journée de taf, et ce n'est pas acceptable.
Les dispatches de phase basés sur worktrees sont un must, comme dit avant, et un process UI/UX dédié doit être mis en place, parce que c'est souvent la partie la plus faible de tous les projets que j'ai créés jusqu'ici.
Un autre point sur lequel j'ai déjà écrit, c'est l'utilisation de plusieurs modèles : on pourrait imaginer Astra/Fable en orchestrateur, GLM/sol/opus en implementers, glm-5.3-flash/lune/deepseek en reviewer de sous-phase, etc...
t3-code a l'air particulièrement bien taillé pour ça avec son truc "orchestration-v2", où un agent peut appeler un autre modèle même s'il tourne dans un autre harnais ! Je vais clairement y jeter un œil dans le futur !
Pour l'instant, si tu veux faire la même chose sur ton projet, j'ai créé une autre skill appelée "create-a-project" qui englobe tout ce dont j'ai parlé ici, et que j'ai utilisé pour run la création de SlopCad. La seule chose que t'aies à faire c'est de donner une idée, loader la skill et suivre ^^ Tu la trouveras ici, et j'ai créé un script pour s'assurer que chaque skill nécessaire est installé :)
Et SlopCad alors ?
Ah oui, le vrai projet ^^. Beh... je ne vais pas trop m'y étendre, ce post est déjà assez long, et pour être parfaitement honnête, j'ai à peine essayé le truc ! Je suis à la fourche "ça dépend"...
Pour commencer, et avant d'en parler trop, je vais d'abord m'en taper une grosse bouchée, de ce 'dwich. Peut-être laisser tomber une tranche de tomate et un peu de mayo par terre avant de faire le cake :P
C'est open source par contre, donc si t'as de l'expérience en modélisation 3D ou juste envie d'essayer, je serais content que tu le cassasses (X'D oh p'tin celui-là il reste X"D) un peu et que tu m'en parles ! Si le repo reste assez vivant, je m'en servirai de plateforme de test, voir ce que ça prend pour qu'un agent fasse du babysitting pour un repo :WINK-WINK: (oui, le but c'est de me mettre au chômage, et alors ?)
Je crois que c'est tout ce que j'ai à dire là-dessus, mais je suis vraiment curieux ! T'en penses quoi ? C'est une façon complètement stupide de bosser, ou tu veux essayer ? Des améliorations qui te viennent à l'esprit ?
T'as un workflow similaire peut-être ? Ou des mauvaises expériences qui t'éloignent de ça ?
Il y a plein de questions, mais c'est elles qui m'ont mené au workflow que je viens de présenter, et j'ai très probablement loupé des trucs, donc j'adorerais entendre comment vous bossez de nos jours !