Je développe des logiciels depuis suffisamment longtemps pour avoir connu une époque où la réponse à la question « qui a fait ce programme ? » était généralement assez simple.

Moi.

Bien sûr, ce « moi » n’a jamais signifié que j’avais tout inventé. J’utilisais un langage créé par d’autres, des bibliothèques écrites par d’autres, des systèmes d’exploitation, des bases de données, de la documentation, des exemples trouvés sur Internet et parfois les conseils d’un collègue qui connaissait mieux que moi le problème du jour. Le développement informatique a toujours été un empilement de connaissances et d’outils construits par une multitude de gens.

Pourtant, lorsque je terminais une application, je pouvais dire sans trop réfléchir : « Je l’ai faite. »

Depuis quelque temps, cette phrase me demande une fraction de seconde supplémentaire.

Codex est passé par là.

Et plus je travaille avec lui, plus une question apparemment ridicule me revient : faut-il dire Codex et moi, ou moi et Codex ?

La grammaire a probablement déjà sa réponse. Moi, je m’intéresse davantage à ce que cache l’ordre des mots.

Parce que Codex n’est plus tout à fait l’équivalent du compilateur, de la documentation ou de la bibliothèque que j’utilisais auparavant. Je peux lui décrire ce que je veux, lui montrer le projet, lui demander de comprendre ce qui existe déjà puis de modifier plusieurs fichiers pour obtenir le résultat recherché. Il peut proposer une architecture, repérer une incohérence, écrire des tests, corriger ce qu’il vient de produire et parfois découvrir avant moi les conséquences d’une décision que je viens de prendre.

Le mot « outil » reste juste.

Mais il commence à être un peu petit.

Je peux soumettre à Codex une idée et lui demander quelles technologies permettraient réellement de la mettre en œuvre. Je peux lui demander d’examiner une architecture, de chercher ses faiblesses ou de réfléchir aux conséquences d’un choix technique.

La différence avec mes anciens outils devient alors difficile à ignorer.

Un compilateur ne me disait pas : « Ta manière de concevoir cette partie va probablement poser un problème plus loin. »

Une bibliothèque ne me proposait pas trois manières différentes d’atteindre mon objectif.

Visual Studio ne décidait pas spontanément qu’il fallait ajouter des tests autour d’un comportement que je venais de modifier.

Et aucun de ces outils ne pouvait prendre une demande formulée en français, parfois encore approximative parce que l’idée elle-même était en train de se construire, puis aller travailler directement dans le projet.

Je ne suis plus seulement en train d’utiliser un outil.

Je travaille avec quelque chose qui participe à la fabrication.

Et c’est précisément là que les mots commencent à devenir intéressants.

« J’ai fait cette application »

Lorsque je montre une application à quelqu’un, il me demande :

— Qui a développé ça ?

La réponse la plus naturelle reste :

— Moi.

Et elle est vraie.

L’idée est la mienne. Les choix de produit sont les miens. L’architecture générale est sous ma responsabilité. Je décide ce que l’application doit faire, ce qu’elle ne doit surtout pas faire, ce que je refuse d’y mettre, ce qui correspond ou non au projet que je veux construire. Je choisis de conserver une proposition de Codex, de la modifier ou de la jeter.

Surtout, lorsque quelque chose ne fonctionne pas, je ne pourrai probablement pas expliquer à un utilisateur :

— Voyez ça avec Codex, c’est lui qui a écrit cette partie.

Cela ferait une assistance technique assez remarquable.

La responsabilité reste humaine.

Mais si je réponds simplement « moi », quelque chose me gêne quand même.

Parce que je sais très bien que certaines parties du logiciel ont été directement écrites par Codex. Certaines solutions sont les siennes. Certaines corrections viennent de problèmes qu’il a repérés. Il m’est arrivé de lui donner un objectif sans connaître moi-même à l’avance la solution technique précise qui permettrait de l’atteindre.

Dire que Codex a développé l’application serait évidemment faux.

Dire qu’il n’a fait qu’exécuter mes instructions devient parfois tout aussi approximatif.

Il existe une zone étrange entre les deux.

Et c’est peut-être cette zone qui est nouvelle.

Lorsque je travaillais avec un autre développeur, la question ne se posait pas vraiment. Nous pouvions dire : « Nous avons développé cette application. » Chacun était une personne avec ses intentions, son expérience, ses responsabilités, ses opinions et, quelquefois, son ego soigneusement fourni avec le reste.

Avec Codex, le « nous » devient plus difficile.

Nous avons fait ?

Qui est « nous » ?

Codex n’a aucune raison personnelle de vouloir que mon application existe. Il ne se réveillera pas demain matin avec une idée pour améliorer le produit parce que quelque chose le tracasse depuis la veille. Il ne risque pas son argent, son temps ou sa réputation. Il ne connaîtra pas la satisfaction de voir quelqu’un utiliser le logiciel.

Il ne porte pas le projet.

Et pourtant il travaille dessus.

L’intention ne se délègue pas aussi facilement que le code

Cela m’amène à une distinction qui me paraît plus importante que celle entre ce qui aurait été écrit par un humain et ce qui aurait été généré par une intelligence artificielle.

Il y a faire et il y a vouloir faire.

Codex peut faire énormément de choses.

Mais jusqu’à présent, il ne veut rien, par lui-même, pour mon application.

C’est moi qui décide qu’un problème mérite une application. C’est encore moi qui décide qu’elle doit fonctionner de telle manière plutôt que d’une autre. Et il m’arrive régulièrement de refuser une solution techniquement excellente simplement parce qu’elle ne correspond pas à ce que je veux construire.

Cette différence paraît abstraite jusqu’au moment où l’on travaille réellement avec une IA.

Une intelligence artificielle peut optimiser très efficacement la mauvaise direction.

Elle peut produire en quelques minutes une solution parfaitement propre à un problème qu’on n’aurait jamais dû lui demander de résoudre.

Elle peut ajouter une fonctionnalité logique qui détruit précisément ce que l’on voulait préserver.

Et lorsqu’elle propose quelque chose de techniquement séduisant, il devient extrêmement tentant de modifier son propre projet pour profiter de ce qu’elle sait facilement faire.

C’est probablement là que la relation devient la plus intéressante.

Parce que le véritable risque n’est peut-être pas qu’une IA commence à décider à ma place.

Le risque est que je cesse progressivement de décider parce qu’elle rend trop facile le fait de lui abandonner certaines décisions.

Ce déplacement serait presque invisible.

Je demande une solution.

Elle propose.

Je valide.

Puis je demande davantage.

Elle propose davantage.

Et un jour, je pourrais me retrouver à piloter un projet constitué d’une succession de bonnes réponses à des questions que je n’ai pas suffisamment choisies.

C’est pour cette raison que je continue à intervenir énormément dans le processus, y compris lorsque Codex pourrait probablement aller beaucoup plus loin seul.

Je ne cherche pas à prouver que je sais encore coder.

Ce serait une compétition assez étrange avec un outil que j’ai précisément choisi pour m’aider à coder.

Je cherche à conserver quelque chose de beaucoup plus important : la direction.

Le développeur qui ne tape plus tout le code reste-t-il développeur ?

Cette question apparaîtra probablement de plus en plus souvent.

Pendant longtemps, une partie importante de l’identité du développeur s’est construite autour de sa capacité à transformer une idée en code. Il fallait connaître suffisamment bien un langage, ses bibliothèques, ses pièges et son environnement pour écrire chaque étape permettant à la machine d’exécuter ce que nous voulions.

Avec Codex, cette couche commence à se déplacer.

Je peux passer davantage de temps à décrire ce que le système doit accomplir, examiner la solution proposée, tester son comportement et réfléchir aux conséquences de son intégration.

Je tape parfois moins de code.

Est-ce que je développe moins ?

Je n’en suis pas certain.

Lorsque je demande à Codex d’implémenter une fonctionnalité et que je passe ensuite mon temps à vérifier qu’elle respecte le reste du système, je mobilise justement ce que des années de développement m’ont appris : reconnaître ce qui tient debout.

Le paradoxe est assez amusant.

Plus Codex devient capable d’écrire du code, plus mon expérience de développeur devient utile pour savoir ce qu’il ne faut pas lui laisser écrire aveuglément.

La compétence se déplace.

Elle ne disparaît pas nécessairement.

Cela rappelle d’ailleurs quelque chose que l’informatique a déjà vécu plusieurs fois. Les premiers programmeurs manipulaient des niveaux de détail que la plupart des développeurs actuels ignorent presque totalement. Puis sont venus les langages de haut niveau, les frameworks, les interfaces graphiques, les bibliothèques et les services cloud.

Chaque couche nous a permis de déléguer une partie du travail à des abstractions créées par d’autres.

Personne ne considère aujourd’hui qu’utiliser une base de données plutôt que d’écrire soi-même le stockage sur disque revient à tricher.

Codex ajoute une couche différente parce qu’elle n’abstrait plus seulement la machine.

Elle commence à abstraire une partie du raisonnement nécessaire pour lui parler.

C’est beaucoup plus déstabilisant.

Et moi dans tout ça ?

Après des mois à travailler avec Codex, je ne me sens pas moins développeur.

Mais je ne développe plus exactement de la même manière.

J’explore davantage.

Je tente plus facilement une idée parce que son coût initial est devenu beaucoup plus faible. Certaines choses que j’aurais autrefois rangées dans la catégorie « intéressant, mais beaucoup trop long à essayer » peuvent désormais devenir un prototype fonctionnel avant que j’aie eu le temps de perdre mon enthousiasme.

C’est probablement l’un des changements les plus profonds.

Codex ne m’a pas seulement permis de produire plus vite.

Il a réduit la distance entre une idée et la possibilité de vérifier si elle tient debout.

Et cette réduction change forcément les idées elles-mêmes.

Je peux me permettre d’en abandonner davantage.

Je peux tester quelque chose simplement pour découvrir que c’était une mauvaise piste.

Je peux construire une première version sans avoir besoin de savoir exactement jusqu’où elle ira.

Une démonstration automatique imaginée à quatre heures du matin peut exister quelques heures plus tard.

C’est grisant.

Et précisément pour cette raison, cela demande probablement davantage de vigilance.

Lorsque fabriquer devient très facile, choisir ce qui mérite d’être fabriqué devient encore plus important.

Voilà peut-être ce que Codex change le plus profondément dans mon travail.

Il ne me remplace pas devant le clavier.

Il rend progressivement le clavier moins central.

Il me pousse vers l’intention, la sélection, l’architecture, la vérification, les limites et la responsabilité.

Cela changera peut-être encore. Il est tout à fait possible que dans quelques années je relise ces lignes avec le même sourire que lorsque je repense aux débats sur les générateurs automatiques de code d’autrefois.

Mais aujourd’hui, lorsque je regarde une application construite avec Codex, je peux encore dire :

« Je l’ai faite. »

Simplement, je sais désormais que cette petite phrase contient davantage de monde qu’avant.

Alors, Codex et moi ou moi et Codex ?

Je crois finalement que l’ordre importe moins que ce que chacun apporte.

Codex peut écrire, proposer, chercher, corriger, tester et parfois me surprendre.

Moi, je dois encore savoir pourquoi nous sommes là.

Et tant que cette différence demeure, je crois que je sais encore qui doit passer en premier.