Je n'écris plus mon repo pour moi, je l'écris pour les agents

Le matin, j’ouvre mon terminal et une partie du travail est déjà faite.

Le watch CI a tourné toutes les 30 minutes pendant la nuit. Les commits ont été relus. Le travail en cours a été committé pour ne pas être perdu. Ce n’est pas de la magie, et ce n’est même pas une question de modèle. C’est du rangement.

Parce que pendant longtemps, j’ai fait l’inverse. Je recollais le même paragraphe de contexte au début de chaque session, je m’agaçais quand l’agent oubliait une règle, et je concluais que le modèle était limité. La règle en question n’était écrite nulle part. Elle était dans ma tête.

Aujourd’hui je ne pense plus mon repo pour moi. Je le pense pour les agents qui vont travailler dedans. L’objectif tient en une ligne : que l’agent puisse comprendre, coder, tester, reviewer et même merger sans avoir besoin de moi à chaque étape.

1. Le contexte est un artefact du repo, pas un prompt

Le contexte du projet vit dans le dépôt.

À la racine, un AGENTS.md sert de routeur : « tu veux faire X, lis Y ». La doctrine du projet est versionnée avec le code, j’ai une vingtaine de skills maison chargées à la demande, des hooks, une mémoire de projet.

Et surtout : si le contexte est faux, ça se corrige par une PR. Le contexte n’est plus quelque chose que je garde dans ma tête ou que je recopie dans un prompt. C’est une partie de la codebase, avec un historique, un auteur et une revue.

2. Je travaille spec-first

Je pars de l’intention, pas de la syntaxe. Avec BMAD ou OpenSpec, je décris ce que je veux faire, un agent produit la spec et le découpage.

Moi, je tranche l’architecture, le produit, le business et les compromis. Je ne passe plus mon temps à décider comment écrire chaque fonction.

Ensuite on découpe en unités minuscules et indépendantes. Ce n’est pas une préférence esthétique : plus la tâche est petite, moins elle consomme de contexte, et plus on peut la paralléliser.

3. Plusieurs agents travaillent en parallèle

Quand les tâches sont indépendantes, je ne fais plus A, puis B, puis C. Je fais A, B et C en même temps. Quand plusieurs agents doivent toucher aux mêmes fichiers, chacun travaille dans son worktree.

Et quand je ne sais pas encore quelle solution est la meilleure, je fais du fan-out : plusieurs agents proposent, un jury adversarial essaie de les casser, je garde ce qui survit.

Je ne demande donc pas seulement « donne-moi une solution ». Je demande aussi « essaie de prouver que cette solution est mauvaise ». C’est la question qui change le plus la qualité de ce qui sort.

4. La vérification se fait avant que je regarde

Je ne veux pas être le premier filtre de qualité.

L’agent lance le lint, les tests, le build. Puis un autre agent fait une review adversariale du diff, avec pour consigne de trouver des problèmes, pas de dire que c’est bon.

C’est aussi pour ça que je garde ma logique métier pure, sans entrées-sorties. Un agent peut la tester sans émulateur, sans secret, sans environnement compliqué, en quelques secondes. Pour moi c’est le vrai critère d’une codebase faite pour l’IA, et il compte beaucoup plus que le choix du modèle : une codebase qu’un agent peut tester tout seul est une codebase qu’un agent peut faire évoluer tout seul.

5. Une partie du système tourne sans moi

Mes agents et mes crons tournent en production 24/7 sur mes produits. Un agent surveille les commits, review les PR, peut merger une fois les checks passés. Le watch CI tourne toutes les 30 minutes. Le travail en cours est committé automatiquement. L’hygiène de la mémoire projet est faite sans moi.

Et mes outils tiers sont branchés en MCP. L’agent envoie lui-même une campagne, lit les données produit, consulte les logs, agit sur les outils dont il a besoin.

Je ne suis plus l’API humaine entre l’agent et mes outils. C’est la partie que j’ai mis le plus de temps à lâcher.

6. Quand ça casse, je ne lis plus les logs

Avant, je passais trente minutes à chercher la ligne qui avait cassé.

Maintenant je donne à l’agent l’accès aux logs et à la base, et je lui pose trois questions : quelle est ton hypothèse, quel est le repro, quel est le patch minimal.

L’agent fait l’investigation. Moi je tranche.

7. Je ne dépends pas d’un seul modèle

Je fonctionne en multi-provider. Chaque agent a son modèle et son fallback, avec un routing qui tient compte du coût. Claude Code au quotidien, GLM et Gemini pour le volume.

J’ai même écrit mon propre harness d’agent depuis zéro, capable de faire tourner un LLM local : github.com/yelkamel/sarj. Je veux comprendre ce qu’il y a dans la boucle. Je ne veux pas que ma compréhension du système dépende entièrement du produit d’un vendeur.

Le garde-fou

L’idée n’est pas que l’IA fasse tout.

Autonome dans l’exécution, contrôlé dans le résultat. Un agent peut merger du code qui a passé les checks. Il ne décide pas de ce qu’on construit, ni des règles de sécurité, ni des paiements, ni des arbitrages business. Ça reste humain, et ça le restera.

La vraie transformation

Le changement n’est pas « je code avec l’IA ». C’est plus profond que ça.

J’organise mon environnement de développement pour que des agents puissent travailler dedans. Le repo devient leur environnement de travail, les specs deviennent leur contrat, les tests deviennent leur garde-fou, les hooks deviennent leurs automatismes, les serveurs MCP deviennent leurs outils. Et moi je deviens de plus en plus l’architecte et le pilote du système.

C’est la même mécanique que je décris dans mon organisation : une company, une capacité, un résultat. Et elle repose sur l’architecture logicielle que j’installe partout, parce qu’un agent ne peut faire évoluer proprement que ce que le compilateur et le lint tiennent à sa place.

La meilleure preuve, c’est que beedone.co, up-drive.com et evolum.co tournent déjà sans que j’aie besoin d’y toucher tous les jours.

Et j’ai hâte de voir à quoi ressemblera tout ça dans un an.