Quand le logiciel évolue plus vite que notre compréhension

Vous confiez une tâche à un agent de code. Un peu plus tard, la fonctionnalité marche et les tests passent. Les modifications portent sur des dizaines de fichiers, introduisent de nouvelles structures et corrigent quelques problèmes que vous n’aviez jamais explicitement demandé de traiter.

Le résultat semble bon. Quelques essais ne révèlent aucun problème évident, alors vous passez à la tâche suivante.

Mais certaines questions restent sans réponse. Pourquoi cette implémentation ? Quels comportements découlent de vos exigences, et lesquels reflètent des choix de l’agent ? Que faudra-t-il préserver lorsque vous modifierez à nouveau cette partie du système ?

Le logiciel a avancé. Votre compréhension en est encore au point de départ.

1. Préserver notre compréhension quand le logiciel change

Un logiciel existe sous forme de code et de processus en cours d’exécution, mais aussi dans la compréhension des personnes qui le façonnent. À quoi sert-il ? Pourquoi fonctionne-t-il ainsi ? Quels choix doivent être maintenus, et lesquels peuvent changer ? C’est cette compréhension qui nous permet de continuer à façonner notre logiciel au fil du temps.

Elle n’a pas besoin de couvrir chaque détail de l’implémentation. Vous pouvez ne pas connaître certaines fonctions tout en sachant ce que le logiciel devrait devenir, en jugeant si une modification sert votre intention et en intervenant lorsque ce n’est pas le cas.

Dans le développement traditionnel, la complexité et les changements au sein de l’équipe peuvent dissocier compréhension et implémentation. Pourtant, la conception, la programmation, le débogage et les révisions nous donnent aussi régulièrement l’occasion de construire et de corriger notre compréhension au cours du travail.

Les agents de code changent le rythme. Ils peuvent passer par-dessus de nombreuses étapes qui exigeaient auparavant notre participation directe et réaliser seuls des implémentations conséquentes. Le logiciel continue de changer. Notre compréhension ne suit pas forcément.

La fonctionnalité vient d’abord ; comprendre devient une tâche à accomplir ensuite. Lire les modifications. Demander pourquoi. Déterminer ce qu’elles affectent par ailleurs. Ces tâches occupent une partie du temps économisé sur la programmation. L’agent peut continuer à générer, et ce qu’il nous reste à comprendre peut continuer à s’accumuler.

Il y a aussi un changement plus difficile à vivre : le logiciel peut progresser exactement comme demandé tout en vous devenant moins familier. Vous passez la journée à attribuer des tâches, répondre aux questions et vérifier les résultats. Chaque agent avance, mais il vous reste à comprendre comment ces changements s’articulent. Le sentiment qui se développe quand on construit soi-même quelque chose — savoir où l’on en est et comment le modifier ensuite — ne vient pas automatiquement une fois les tâches terminées.

Votre propre travail vous devient peu à peu étranger. Vous vous souvenez de ce que vous avez demandé, mais il devient plus difficile d’expliquer pourquoi le résultat est ainsi, si les décisions antérieures restent valables ou ce que la prochaine modification affectera. La continuité de cette compréhension — savoir ce que vous avez construit, pourquoi cela fonctionne ainsi et comment le changer — commence à se rompre. Il devient plus difficile de continuer à le façonner.

2. Une meilleure IA n’efface pas le droit de décider

Une réponse naturelle consiste à rendre les modèles plus fiables : un meilleur code, une meilleure détection des erreurs, des vérifications plus approfondies. Si un modèle devient suffisamment bon, les humains ont-ils encore besoin de comprendre leur travail et de décider ce qu’il devrait devenir ?

Notre droit de diriger notre propre travail ne dépend pas du fait que l’IA continue à commettre des erreurs.

« L’IA peut écrire le code, mais les humains devront toujours concevoir l’architecture. » Cette réponse rattache notre rôle à une compétence dans laquelle nous avons actuellement l’avantage. Et si les modèles devenaient aussi d’excellents architectes ? Se replier sur la vérification ou la compréhension des systèmes mène à la même question : dès qu’un modèle devient bon dans ces domaines également, perdons-nous notre raison de participer ?

Poussons le raisonnement jusqu’au bout. Supposons que l’IA atteigne l’intelligence générale. Elle comprend les systèmes complexes, fait d’excellents choix techniques et vérifie les implémentations plus rigoureusement que nous. Devrions-nous alors lui confier toutes les décisions concernant ce que nous créons ?

Tant qu’une personne souhaite créer selon sa propre intention et choisir la direction de son travail, cette question demeure.

La capacité de prendre une meilleure décision ne confère pas, à elle seule, le droit de décider à la place de quelqu’un d’autre.

Vous pouvez choisir de déléguer de nombreux jugements à l’IA tout en vous réservant une décision particulière. Vous pouvez accepter un conseil, changer d’avis ou reconnaître qu’un choix antérieur était erroné. Ce qui compte, c’est de faire un choix éclairé, plutôt que de découvrir après coup que le logiciel a déjà changé.

Le droit de diriger votre propre travail ne dépend pas du fait d’être plus capable que l’IA. Il ne dépend pas non plus du nombre de personnes qui souhaitent encore l’exercer. Même si presque tout le monde accepte volontiers de tout déléguer, la personne qui ne le souhaite pas conserve le droit de décider ce que son logiciel devrait devenir.

Tant qu’une personne souhaite rester l’auteur de son travail, nous avons toujours besoin de savoir comment maintenir son intention en vigueur.

3. Ce qu’il faut pour continuer à façonner votre logiciel

Être l’auteur ne s’arrête pas lorsque la première idée devient un logiciel fonctionnel. Vous devez pouvoir comprendre les choix importants, changer de direction, rejeter les résultats contraires à votre intention et continuer à réviser votre travail. Le droit de le diriger doit se traduire en capacités concrètes.

Si votre seule possibilité est de cliquer sur « Accepter » quand l’agent a terminé, sans connaître les choix importants contenus dans le résultat, votre contrôle est limité. Il en va de même si vous pouvez rejeter un résultat sans trouver comment le modifier, ou si une exigence que vous avez formulée explicitement hier cesse discrètement d’être respectée dans l’implémentation d’aujourd’hui. Vous pouvez encore approuver le travail tout en perdant la capacité de le façonner selon votre intention.

Conserver cette capacité signifie pouvoir répondre à des questions concrètes :

• Ce que le logiciel doit devenir est-il toujours clair ?
• Pouvez-vous voir comment l’implémentation actuelle répond à vos exigences ?
• Pouvez-vous distinguer vos décisions importantes des choix de l’agent ?
• Lorsque vous changez de direction, pouvez-vous comprendre les effets probables et intervenir ?
• Après la prochaine modification de l’implémentation, les décisions que vous avez prises explicitement seront-elles toujours respectées ?

Prenons un outil d’écriture personnel assorti d’une exigence explicite : conserver son contenu sur l’appareil local. Vous laissez à l’agent l’organisation des fichiers, l’implémentation du stockage et de nombreux détails internes. Plus tard, pour faciliter l’utilisation de l’outil sur plusieurs appareils, l’agent propose une synchronisation dans le cloud.

Autoriser ou non le contenu à quitter l’appareil touche à une décision que vous avez déjà prise. Ce choix doit être visible, et vous devez comprendre ce qu’il change avant de pouvoir l’accepter ou le refuser. Un résultat peut être plus pratique et plus fiable tout en s’écartant de l’exigence initiale.

Les tests peuvent aider à établir que le logiciel se comporte d’une certaine façon. Il vous reste à juger si ce comportement est acceptable et s’il respecte les décisions que vous souhaitez maintenir.

L’agent peut implémenter la synchronisation, vérifier que les données sont correctement transférées et corriger les bugs. Mais savoir si le contenu doit quitter l’appareil, quelles preuves suffisent pour accepter ce changement et qui est responsable en cas de problème exige des réponses explicites au-delà de l’implémentation elle-même. Votre jugement doit déterminer la direction du travail et le moment où il s’arrête, au lieu de servir seulement de signature une fois tout terminé.

4. Lire tout le code permet-il de rester l’auteur ?

La revue de code offre une réponse directe. L’agent écrit le code ; une personne le lit et vérifie ce qu’il fait.

Le code peut contenir des comportements que le compte rendu du modèle ne mentionne jamais, des structures qui influencent la maintenance et des problèmes que vous ne pouvez juger qu’en examinant attentivement l’implémentation.

Mais à mesure que la génération s’accélère, lire chaque modification peut-il rester un moyen durable de garder le contrôle ?

Même sans lire ligne par ligne, votre journée peut rester bien remplie : préciser des exigences vagues, repérer les écarts dans un résultat, décider quelles preuves permettraient d’en établir la justesse et ramener l’agent dans la bonne direction. Chaque étape exige de l’expérience et de la concentration. Lire très peu de code et travailler intensément peuvent être vrais en même temps.

Lire du code est aussi une occasion de construire sa compréhension. Relire les modifications d’un collègue aide une équipe à apprendre ce que fait désormais le système, pourquoi il a été conçu ainsi et à quoi faire attention lors des prochains changements. Si nous lisons moins de code, nous avons besoin d’autres moyens de développer cette compréhension.

Pourtant, lorsque les modifications s’accumulent et que les personnes ne peuvent que les parcourir avant de les approuver, conserver le processus de revue ne préserve pas nécessairement la compréhension. Notre attention limitée doit atteindre les endroits qui demandent un jugement : les compromis de conception aux conséquences importantes, les changements de grande portée et les résultats encore incertains.

Quels choix devons-nous continuer à comprendre au fil du temps ? Quels détails d’implémentation pouvons-nous examiner au besoin ? Comment éviter de consacrer toute notre attention aux détails en passant à côté des décisions qui ont réellement besoin de nous ?

5. Et si nous remplacions le code par de longues spécifications ?

Une autre réponse consiste à déplacer notre travail vers le langage naturel. Décrire le comportement attendu du logiciel, puis demander à un agent d’implémenter la spécification. Ou demander à l’agent d’expliquer le code, pour transformer le système en une documentation plus facile à lire.

Des exigences claires réduisent les malentendus. La documentation préserve le contexte. Une bonne explication rend le code inconnu plus accessible. Mais le langage naturel ne fait pas disparaître le coût de la lecture.

Si un logiciel contient de nombreux comportements et compromis, un document qui les décrit tous peut grandir en même temps que l’implémentation. Nous pouvons passer d’une quantité excessive de code à lire à une quantité excessive de texte à lire. Même si chaque phrase est plus facile à comprendre que le code correspondant, l’ensemble peut toujours dépasser le temps et l’attention dont nous disposons.

Et si l’agent continue d’enrichir la spécification tandis que nous nous contentons de l’approuver, la qualifier de document validé par un humain ne prouve pas qu’une personne a compris chacune des décisions qu’elle contient.

Ce que fait le logiciel, ce que l’agent dit qu’il fait et ce que nous comprenons réellement et choisissons d’assumer sont trois choses différentes.

Un relevé complet et une explication approfondie peuvent encore nous laisser dans l’incertitude quant à la façon de continuer à façonner le logiciel. Nous devons pouvoir trouver ce qui compte, comprendre comment cela se traduit dans l’implémentation actuelle et voir les choix possibles lors du prochain changement.

Garder la création entre les mains des humains

À mesure que l’implémentation devient moins coûteuse, davantage de personnes peuvent transformer leurs idées en logiciels. Elles devraient aussi pouvoir comprendre et continuer à façonner ce qu’elles créent.

Cette liberté va au-delà du logiciel. Dans toute création, la personne qui en est l’auteur devrait pouvoir choisir ce qu’elle délègue à l’IA et ce qu’elle décide elle-même.

La mission de Finite Ground est d’aider les personnes à créer selon leur propre intention et à continuer de façonner leur travail à mesure que l’IA élargit le champ des possibles.

Noema porte cette mission dans le domaine du logiciel, en maintenant l’intention des personnes en vigueur alors que l’implémentation continue de changer.

Si un jour une intelligence artificielle générale prend en charge tous les aspects de la vie humaine et que chacun renonce à son autonomie, cette question ne se posera plus. Finite Ground n’aura plus de raison d’exister.

Tant qu’une personne refuse de renoncer à cette autonomie, il y a une raison de poursuivre.

L’IA peut donner vie à davantage d’idées. Le droit de décider ce qu’elles deviennent appartient toujours aux personnes qui choisissent de le conserver.