J'ai laissé Claude construire mon projet seul. J'ai compris pourquoi certains explosent leur quota de tokens.

Depuis plusieurs mois, j’utilise quotidiennement l’IA dans mon travail de développeur.

Je vois régulièrement passer des discussions sur les plafonds de tokens, les abonnements Cursor consommés en quelques jours, les coûts liés au fameux “vibe coding”.

J’avoue que ça m’a toujours paru un peu abstrait. De mon côté, même en utilisant intensivement l’IA, je n’ai quasiment jamais rencontré ce problème.

Jusqu’à récemment.

L’expérience

Pour créer ce blog, j’ai décidé de tenter quelque chose de différent.

Plutôt que de partir de mon workflow habituel, j’ai ouvert un dossier vide et demandé à Claude de construire le projet à partir d’un simple besoin métier.

Je lui ai expliqué ce que je voulais obtenir — un blog technique personnel, les fonctionnalités attendues, l’expérience utilisateur recherchée. Mais volontairement, je ne lui ai donné aucune indication technique.

Le résultat m’a surpris

Avant même de commencer à coder, Claude a généré un document d’architecture d’environ 1700 lignes.

En regardant les statistiques de la session, j’ai découvert qu’il avait déjà consommé plus de 200 000 tokens — sans avoir écrit une seule ligne de code fonctionnel.

1 700

lignes d'architecture

200k+

tokens consommés

lignes de code

Statistiques de la session avant la première ligne de code

Ma première réaction a été très simple : pourquoi il en fait autant ?

La prise de conscience

En parcourant le document, j’ai réalisé quelque chose.

La plupart des décisions prises par Claude étaient des décisions que je prends moi-même instinctivement lorsque je démarre un projet. Choisir une stack. Définir une architecture. Organiser les dossiers. Déterminer des conventions. Prévoir certains cas d’usage.

C’est là que j’ai compris pourquoi certains utilisateurs atteignent très rapidement les limites de leur abonnement.

Ce que j’ai compris sur mon workflow

Lorsque je travaille avec l’IA au quotidien, je lui fournis déjà une grande partie des décisions importantes. L’IA intervient principalement pour exécuter.

Dans cette expérience, je lui ai demandé de faire beaucoup plus. Je lui ai demandé de décider.

Laisser l'IA décider

1 Exploration des possibilités
↓
2 Comparaison des options
↓
3 Arbitrage et formalisation
↓
4 Génération du code

Mon workflow habituel

1 Stack et structure définies
↓
2 Contexte fourni dès le départ
↓
3 L'IA exécute directement
↓
4 Itérations ciblées

Ça ne veut pas dire que c’est une mauvaise approche

Pour un blog personnel, un site vitrine ou un POC, il est aujourd’hui possible d’obtenir des résultats impressionnants sans être développeur.

C’est probablement l’une des révolutions les plus fascinantes apportées par ces outils. Mais cette expérience m’a permis de mieux comprendre ce qui se passe réellement sous le capot.

La leçon principale

Plus le contexte est clair, plus les choix sont déjà définis, plus elle devient rapide et efficace.

À l’inverse, lorsqu’on lui demande de partir d’une feuille blanche, elle doit explorer, comparer, arbitrer et formaliser un grand nombre de possibilités.

Et tout cela a un coût — en temps, en complexité, et parfois en tokens.