L’un des schémas d’utilisation les plus intéressants que j’ai observés avec Codex Plus n’a pas tant à voir avec la formulation des prompts qu’avec le moment où je les utilise.
Quand il ne me reste plus que 3 à 5 % de ma limite de 5 heures ou de ma limite hebdomadaire, je ne dépense plus cette marge sur de petites demandes. Je fais exactement l’inverse. J’utilise ce qu’il reste pour lancer les plus grosses tâches d’ingénierie possibles sur plusieurs projets déjà préparés.
Concrètement, cela veut souvent dire des migrations complètes vers TypeScript, un nettoyage ESLint à l’échelle du dépôt, des revues de bugs approfondies sur des bases de code entières, ou encore de gros refactorings qui paraîtraient trop coûteux à déclencher à la légère.
Ce qui a changé ma façon de travailler
La raison est simple : à plusieurs reprises, j’ai vu Codex continuer à travailler alors même que la limite visible semblait déjà atteinte. Tout laisse penser que la session devrait être terminée, mais la tâche continue d’avancer, et parfois elle se termine entièrement.
Je ne présente pas cela comme une règle garantie du produit. Je décris simplement une expérience répétée, suffisamment marquante pour changer mon comportement. À partir du moment où j’ai remarqué ce schéma, les derniers pourcents ont cessé de me sembler être quelque chose à préserver. Ils sont devenus, au contraire, le meilleur moment pour déclencher le travail le plus coûteux et le plus utile.
Comment j’utilise maintenant ces derniers pourcents
Au lieu de réserver la fin de ma limite à des prompts prudents et peu coûteux, je la traite désormais comme une fenêtre de lancement pour des opérations d’ingénierie lourdes, comme par exemple :
- des migrations complètes vers TypeScript
- un nettoyage ESLint à l’échelle du dépôt
- des revues de bugs profondes sur de grandes bases de code
- de vastes refactorings structurels
La clé, c’est la préparation. Cette méthode est surtout utile quand le projet est déjà prêt à être exécuté et que la tâche est clairement définie. À ce moment-là, utiliser la marge restante pour quelque chose de mineur ressemble souvent à un gaspillage.
Pourquoi cela me paraît important
Des outils comme Codex Plus ne se résument pas à leur puissance brute. La manière dont on place l’effort dans le temps compte aussi. Un petit changement de timing peut modifier de façon très concrète la valeur que l’on tire d’une même limite.
Dans mon cas, cela a même changé la psychologie du produit. Les derniers pourcents ne ressemblent plus à la fin d’une session. Ils ressemblent au moment où je dois arrêter d’hésiter et confier à l’outil la tâche la plus lourde que je peux raisonnablement lui donner.
Par moments, j’ai vraiment l’impression que Codex continue à travailler pour moi même après la disparition de la limite visible. Je ne sais pas si c’est un cas de figure voulu ou simplement la façon dont certaines tâches se terminent en pratique, mais cela a été suffisamment utile pour que j’organise désormais mon workflow autour de cette observation.
Une piste concrète pour les développeurs
Si vous utilisez Codex Plus pour l’ingénierie logicielle, cela vaut peut-être la peine de tester votre propre workflow de fin de limite au lieu de supposer que les derniers pourcents doivent être dépensés avec prudence. Dans mon cas, l’approche inverse s’est révélée plus efficace.
Je serais très curieux de savoir si d’autres développeurs ont remarqué le même schéma, notamment pour les migrations, le nettoyage de lint, les revues larges ou les gros refactorings sur plusieurs dépôts.