Depuis 2022, je ne me demande plus vraiment si l’IA peut coder. La réponse est oui. Elle peut même sortir beaucoup de code, très vite, dans des directions différentes, avec une qualité du code que je vois progresser à chaque génération de modèles.
J’ai vu cette montée en puissance de près. D’abord comme curiosité, puis comme outil de travail, puis comme environnement dans lequel une partie de mon métier se déplace. Je préfère le regarder à l’échelle d’une journée de travail : les lignes que je n’écris plus, les diffs que je lis, les décisions que je garde.
Le vrai sujet commence après : qu’est-ce que je fais de cette vitesse ? Est-ce que je lui laisse prendre la réflexion à ma place, ou est-ce que je m’en sers pour explorer au-delà de mes limites humaines ? Je reste limité par mon corps, mon attention, ma fatigue, et le temps que je peux réellement donner à ce métier.
Explorer plus vite que mon temps humain
Je peux creuser longtemps, mais je ne peux pas explorer toutes les pistes à la main. Écrire 500 lignes de code utiles à la main dans une journée, c’est déjà beaucoup, parce que ces lignes finales cachent souvent deux ou trois fois plus d’essais, de refactoring, de suppressions et de retours en arrière.
Ce rapport au temps change. L’IA peut produire une première piste, une variante, une deuxième approche, puis un contre-exemple, beaucoup plus vite que moi. Elle ne rend pas ces pistes bonnes par magie. Elle me donne un volume d’exploration que je n’aurais pas pu me payer seul.
C’est dans ce sens que je la vois comme un outil d’exploration temporelle. Elle ne remplace pas l’expérience ; elle me permet de traverser plus de chemins possibles avant de choisir. Mon travail ne consiste pas à accepter la première sortie. Il consiste à lire, comparer, sentir ce qui tient, puis ramener le système vers la direction qui a le plus de sens.
Penser un cran au-dessus du code
Je n’écris presque plus le code à la main. Si coder veut dire taper les lignes, alors oui, je code beaucoup moins qu’avant. Mais si coder veut dire transformer une intention en système qui marche, je code encore : j’écris l’intention, les contraintes, les critères de fin, puis je relis la traduction produite par la machine.
Vu comme ça, les LLM ne sortent pas de l’histoire du code. Ils ajoutent une couche d’abstraction de plus : après les compilateurs, les langages, les IDE et l’autocomplétion, le langage naturel devient une partie de l’interface de programmation.
Il y a un danger évident : demander à l’IA de penser à ma place. Dans ce cas, je gagne peut-être du temps sur une tâche, mais je perds l’exercice qui me rend capable de juger la suivante. Je ne veux pas de ça.
Je l’ai appris en me prenant un mur. Au tout début de Claude Code, pendant la bêta, quand je commençais à mettre la main dans les agents et l’outil, j’ai vu sortir des diffs qui tenaient debout. J’ai commencé à relire moins. Puis presque plus. J’acceptais les plans, je laissais les agents enchaîner, et je partais du principe que le résultat serait bon parce que les sorties précédentes avaient l’air bonnes. Ça a fini comme ça devait finir : trop de complexité, des régressions, des incohérences, et un système que je devais reprendre à la main alors que je ne le comprenais plus vraiment moi-même.
Le point n’est pas de lire chaque boucle for ou chaque if dans le détail. Le point, c’est de comprendre le système : les frontières entre les modules, les contrats, les interfaces, les tests qui me disent quand ça casse. Quand ces frontières sont floues, l’agent peut faire passer une responsabilité au mauvais endroit, raccorder deux blocs trop vite, ou produire une solution qui marche localement mais abîme l’architecture. Je l’ai vécu. Tant que je comprends comment les blocs communiquent entre eux, tant que les tests racontent une intention lisible, je continue à faire mon métier. Je travaille juste à un niveau plus haut.
C’est là que l’expression “amplificateur de pensée” a du sens pour moi. L’IA n’amplifie pas une pensée absente. Elle m’aide surtout quand je sais déjà où regarder, quoi refuser, et quelle vérification lancer derrière. Mon expertise reste là, et l’IA me donne de quoi construire autour : un prototype, une interface, un script, une documentation, une piste d’architecture. Elle ne remplace pas ma technique. Elle me donne plus de prise.
Orchestrer sans lâcher le volant
L’image du chef d’orchestre me parle encore, si elle reste attachée au travail réel. Dans mon quotidien, ça veut dire : je donne l’intention, je borne la tâche, je choisis parfois un agent ou un sous-agent, je relis ce qui revient, je coupe quand le cadre devient trop lourd.
Piloter des agents ne veut pas dire regarder le travail de loin. Au contraire, plus ils vont vite, plus je dois savoir où regarder. Une consigne floue produit vite beaucoup de code flou. Un relais mal cadré perd une nuance. Un workflow trop ambitieux devient une usine à gaz. Mon travail, ici, c’est de garder le signal lisible.
Ce déplacement m’a forcé à regarder mes propres méthodes. Au début, je pensais beaucoup en prompts. Puis en contexte. Puis en orchestration. Puis en garde-fous. Ce n’était pas un plan tracé d’avance. C’était une phase d’apprentissage, comme mes premières années de développeur : je teste, je me trompe, je corrige, je comprends mieux où sont les vraies limites. La différence, c’est que cette fois, j’apprends au début de l’ère des agents, pendant que les usages, les techniques et les outils se construisent encore.
Ce qui reste utile
Après tous ces essais, je ne garde pas les outils les plus impressionnants. Je garde ce qui réduit vraiment le flou : des frontières visibles, du contexte chargé au bon moment, des règles courtes, et des contrôles automatiques qui refusent ce qui sort du cadre.
Je garde le contexte utile. Le contexte maximal finit vite par coûter plus cher que ce qu’il apporte. Un agent n’a pas besoin de tout savoir au démarrage. Il a besoin de comprendre le cadre pour agir sans l’inventer, puis de pouvoir charger le reste quand la tâche le demande.
Je garde les règles courtes, proches du code, accompagnées de leur raison. Une règle sèche se contourne vite. Une règle qui explique pourquoi une frontière existe tient mieux, surtout quand l’agent doit choisir entre deux solutions plausibles.
Je garde les vérifications exécutables : ne pas seulement écrire une règle, mais faire en sorte que le système puisse la contrôler. Quand une contrainte peut devenir un test, un lint, un check d’architecture ou une validation CI, je préfère la sortir du prompt et la faire répondre automatiquement.
Je coupe les scans exhaustifs trop lents, les fichiers de contexte maintenus à la main, les workflows d’orchestration qui coûtent plus cher que ce qu’ils évitent. Je coupe aussi l’idée qu’un meilleur prompt peut compenser une architecture floue. À partir d’un certain point, plus de mots ne donnent pas plus de contrôle. Ils donnent seulement plus de bruit.
Je ne coupe pas pour viser plus petit. Je coupe pour pouvoir continuer à comprendre ce que je construis.
Ce que j’aurais aimé lire plus tôt
J’ai appris ça au moment où les usages étaient encore instables. Il n’y avait pas d’autoroute propre, pas de bonne pratique évidente, pas de réponse simple à copier.
Certaines erreurs valent mieux quand elles ne restent pas privées. Si une partie de ce journal peut éviter à quelqu’un de perdre du temps dans les mêmes impasses, il aura déjà servi à quelque chose.
Mise à jour (28 avril 2026)
Aujourd’hui, ça va faire un an que j’ai découvert Claude Code et que je l’utilise, entre autres. Sur cette année, j’ai passé plus de 2 000 heures à coder avec des agents IA. Je ne sais pas où tout ça mène, mais je sais que ce temps passé avec eux a changé mon regard : je vois plus vite où ils aident, où ils dérivent, et où le développeur doit rester présent.
Si tu veux m’en parler, tu peux m’écrire ici : augustin.bengolea@gmail.com.
Je n’en sors pas avec une doctrine. J’en sors avec un réflexe : tant que je comprends encore le système, je peux déléguer. Le jour où je ne comprends plus, le gain de vitesse se transforme en dette.