J’utilise aujourd’hui ChatGPT et Codex presque quotidiennement dans mes développements.
Laravel, Filament, Livewire, intégrations d’API, tests, migrations, refactorisation… l’IA peut intervenir pratiquement partout.
Mais avec l’expérience, j’en suis arrivé à une conclusion assez simple :
je ne veux surtout pas que l’IA développe mes projets à ma place.
Je veux qu’elle développe pour moi.
La nuance est importante.
ChatGPT réfléchit, Codex agit
Dans ma façon de travailler, ChatGPT et Codex n’ont pas exactement le même rôle.
J’utilise principalement ChatGPT pour réfléchir au projet : conception fonctionnelle, architecture, choix techniques, avantages et inconvénients d’une solution, découpage d’une fonctionnalité, recherche d’alternatives…
Puis vient Codex.
Codex peut accéder au projet, examiner son architecture, lire les fichiers concernés, modifier le code, créer des classes, lancer des commandes ou exécuter les tests.
OpenAI le présente d’ailleurs comme un agent dédié au développement logiciel, capable d’écrire, relire et déboguer du code.
Dans mon organisation, je résumerais donc les choses ainsi :
ChatGPT m’aide à décider ce qu’il faut faire.
Codex est le bras armé qui le réalise dans le projet.
Mais je reste le chef de projet.
Le piège : « développe-moi cette application »
Les agents de développement sont devenus suffisamment performants pour qu’il soit tentant de leur donner une mission très large :
« Je veux une application permettant de gérer X, Y et Z. Développe-la. »
Codex peut effectivement produire beaucoup de choses.
Le problème est qu’on lui demande alors également de prendre une multitude de décisions : architecture, découpage des responsabilités, structure de données, conventions, composants à utiliser, comportement métier…
Et chacune de ces décisions devra tôt ou tard être vérifiée.
C’est là que l’on peut facilement perdre une partie du bénéfice apporté par l’IA.
Une architecture inutilement complexe, une fonctionnalité déjà existante réimplémentée autrement, des fichiers créés alors qu’une abstraction existe déjà dans le projet… Tout cela génère du code supplémentaire à lire, à comprendre et éventuellement à corriger.
Sans parler de la consommation du quota de l’agent.
Plus je laisse l’IA décider à ma place, plus je dois ensuite contrôler ses décisions.
Je préfère donc inverser la logique.
Je découpe le développement en missions
Prenons un exemple volontairement simple.
Imaginons que je veuille ajouter un système de newsletters à une application Laravel.
Je pourrais demander :
« Ajoute un système complet de newsletters. »
Je ne le fais généralement pas.
Je commence plutôt par travailler avec ChatGPT sur le besoin :
Que doit réellement faire la fonctionnalité ?
Qu’est-ce qui existe déjà dans le projet ?
Quelles données doivent être stockées ?
Quelle partie doit être développée et quelle partie peut être confiée à une solution existante ?
Comment l’intégrer sans casser l’architecture actuelle ?
Une fois ces décisions prises, Codex reçoit des tâches beaucoup plus précises.
Par exemple :
Analyse le système actuel de gestion des articles et identifie les classes concernées par l’ajout d’une newsletter. Ne modifie encore aucun fichier.
Puis éventuellement :
Nous allons conserver l’architecture actuelle. Crée uniquement la migration et le modèle nécessaires à la gestion des abonnements.
Puis :
Ajoute maintenant l’interface Filament correspondante en réutilisant les conventions déjà présentes dans les autres ressources.
Et enfin :
Ajoute les tests nécessaires et exécute la suite de tests concernée.
Chaque étape possède un objectif précis et un résultat que je peux vérifier.
Ce principe rejoint d’ailleurs les recommandations d’OpenAI : Codex fonctionne très bien sur des tâches bien cadrées telles que l’inspection d’un dépôt, la correction d’un bug, l’ajout d’un test ou l’implémentation d’une modification ciblée.
Moins de contexte inutile, moins de tokens consommés
Cette façon de travailler présente un autre avantage : elle évite de gaspiller inutilement le contexte et les quotas de l’IA.
Un agent qui doit constamment comprendre l’intégralité d’un gros projet doit parcourir beaucoup de fichiers, retrouver les relations entre les différentes parties de l’application et déterminer lui-même ce qui peut être modifié.
Pour une petite évolution, ce n’est pas toujours nécessaire.
Je préfère lui indiquer le périmètre.
Par exemple, plutôt que :
Analyse le projet et adapte le système de pages.
je peux demander :
Analyse le système actuel de versioning des pages. Je veux ajouter cette fonctionnalité sans modifier son fonctionnement. Commence par identifier uniquement les classes directement concernées.
Le champ de recherche est beaucoup plus réduit.
Cela ne signifie pas qu’il faut empêcher Codex d’explorer le projet. Au contraire : il doit pouvoir regarder le code existant lorsque c’est nécessaire.
Mais il faut lui donner une direction.
L’objectif n’est pas de lui dire comment écrire chaque ligne de code. Ce serait contre-productif.
L’objectif est de lui expliquer ce que l’on veut obtenir, les contraintes qu’il doit respecter et ce qu’il ne doit pas modifier.
Une étape que j’utilise beaucoup : « ne modifie rien »
C’est probablement l’une des habitudes que j’ai le plus adoptées avec Codex.
Avant une modification importante, je lui demande régulièrement :
Analyse cette partie du projet. Ne modifie rien pour l’instant. Explique-moi comment elle fonctionne et propose la modification la moins intrusive.
Cette petite phrase change énormément la façon de travailler.
Codex devient momentanément un outil d’analyse plutôt qu’un outil de génération.
Je peux alors vérifier sa compréhension du projet, discuter de sa proposition avec ChatGPT si nécessaire et décider de la marche à suivre.
Ensuite seulement vient :
Implémente cette solution.
On retrouve finalement un fonctionnement assez proche d’une véritable équipe de développement :
analyse → décision → réalisation → tests.
L’IA accélère énormément chacune de ces étapes, mais elle ne supprime pas leur nécessité.
Plus le projet est structuré, meilleure est l’IA
Il y a également un phénomène intéressant que j’observe sur les projets qui prennent de l’ampleur.
Lorsque l’application possède déjà une architecture cohérente, des tests, des conventions et des composants réutilisables, Codex dispose d’exemples sur lesquels s’appuyer.
Il peut examiner une ressource Filament existante avant d’en créer une nouvelle, reproduire la façon dont les tests sont organisés ou respecter une architecture déjà utilisée ailleurs dans le projet.
Les projets peuvent également fournir à Codex des instructions et des règles persistantes afin de lui transmettre leurs conventions. OpenAI propose notamment des mécanismes permettant d’enseigner à Codex les standards et méthodes de travail d’une équipe.
C’est presque un cercle vertueux :
un projet bien structuré permet à l’IA de produire plus facilement du code bien structuré.
L’IA ne remplace pas le développeur, elle déplace son travail
Avec ChatGPT et Codex, j’écris aujourd’hui beaucoup moins de code manuellement qu’auparavant.
Mais cela ne signifie pas que je travaille moins sur le développement.
Une partie de mon travail s’est simplement déplacée.
Je passe davantage de temps à définir les fonctionnalités, réfléchir à l’architecture, découper les problèmes, vérifier les propositions et contrôler les résultats.
L’IA, elle, peut prendre en charge une grande partie du travail mécanique nécessaire pour transformer ces décisions en code.
C’est précisément là que je la trouve la plus efficace.
Je ne cherche donc pas à disposer d’une IA capable de prendre un cahier des charges et de disparaître pendant plusieurs heures pour revenir avec une application terminée.
Je préfère disposer d’un développeur extrêmement rapide, capable de parcourir mon projet, de comprendre mes instructions et d’exécuter les tâches que je lui confie.
ChatGPT m’aide à réfléchir. Codex exécute. Je garde la direction du projet.
Et paradoxalement, c’est en donnant moins de liberté à l’IA que j’ai l’impression d’en tirer le plus de valeur.
Un besoin en lien avec ce sujet ?
Échangeons ensemble ↗