Métaconnaissance

Tu n'as pas besoin de savoir comment faire. Tu dois juste savoir ce que tu fais.

La plateforme sur laquelle tu lis ceci a été construite par un agent IA selon mes instructions. Le pipeline de publication qui la soutient aussi. Cet article parle de ce qui a mal tourné lors de ce processus, et ce que ça dit sur la direction où ça nous mène.

L'incident du ballonnement

J'ai d'abord construit cette application d'écriture pour moi-même — un outil pour prendre des notes et composer plus vite, taillé exactement sur ma manière de travailler. Quand est venu le moment de publier, j'ai eu besoin d'une interface. Donc j'ai fait ce que ferait tout vibe coder sensé : j'ai lancé un agent Opus pour la construire.

Je ne me souviens pas des mots exacts — je ne sauvegardais pas automatiquement mes prompts à cette époque, quelque chose que j'ai corrigé depuis — mais l'essentiel était : rends-la découvrable, SEO-friendly, facile à indexer. Regarde comment les vrais éditeurs construisent leurs sites. Fais ça.

Ça a tourné pendant 45 minutes. Brûlé une tonne de tokens. Puis est revenu avec une approche qui ne ressemblait pas beaucoup à ce que tu vois maintenant, mais qui l'a inspirée — de cette manière que les agents ont.

Plus important, l'agent m'a dit qu'il avait intégré quelque chose appelé Ghost Publishing Platform.

J'ai téléchargé Ghost, lu la doc. Bon outil. Des millions d'utilisateurs, y compris des vrais éditeurs. Le problème : c'est lourd. Bourré de features. Et j'avais déjà un backend. Donc quand j'ai commencé à ajouter des trucs et que j'ai remarqué que chaque petite modification prenait une éternité, j'ai demandé à l'agent : on en a vraiment besoin ?

On n'en utilise presque rien, m'a-t-il dit. Mais tu as dit que tu voulais quelque chose de vraiment professionnel, alors j'ai utilisé un outil professionnel.

D'accord. Ma faute. Je lui ai demandé de trouver quelque chose de plus léger. Il a suggéré Payload CMS — mieux adapté, moins de surcharge. D'accord, on y va. Encore une grosse refonte. Plus de tokens, plus d'attente.

Puis Next.js. Même histoire. Excellente librairie. Complètement surdimensionnée pour ce qu'on faisait réellement. Encore des ralentissements, encore des questions, encore cette réalisation que j'aurais dû poser toutes ces questions dès le début. Finalement, j'ai dû tout enlever et reconstruire en accordant l'attention nécessaire à ce qui était réellement utile et à l'ordre dans lequel on superposait les couches.

Si tu es développeur en train de lire ça : oui, je le sais. Il n'y a rien de subtil là-dedans. Mais c'est précisément le point que je veux faire passer.


Le slop de clanker

Dans les cercles de développeurs, ce genre de résultat s'appelle du clanker slop — du code généré par IA qui fonctionne mais qui est d'une certaine manière pourri. Trop lourd, mal structuré, qui résout un problème adjacent au vrai problème. Les agents prennent le blâme.

Le blâme est mal placé. Un agent avec des instructions incomplètes produira quelque chose qui ressemble à ce qu'il a compris que tu voulais. Si tu as demandé quelque chose de « professionnel » sans préciser la portée, il va chercher des outils professionnels. Ce n'est pas une faute de l'agent. C'est une faute de spécification.

Ce qui mène au vrai problème : si tu ne sais pas assez pour spécifier correctement, et tu ne sais pas assez pour repérer quand le résultat est pourri, tu te retrouves avec un machin ballonné qui fonctionne jusqu'à ce que ça ne fonctionne plus. Maintenant que la construction logicielle est sensément quelque chose que n'importe qui peut faire, il y a beaucoup plus de gens dans cette situation.

Le feature creep est le même problème au niveau produit. Plus c'est facile d'ajouter des choses, plus c'est tentant d'ajouter tout. Certaines des apps les plus réussies maintenant gagnent précisément parce qu'elles n'ont pas certaines choses — une interface hyper focalisée qui fait bien peu de trucs. Ça demande du goût, bien sûr. Mais ça demande aussi de savoir, à un certain niveau, comment le logiciel et les utilisateurs interagissent réellement. Sans ça, tu ajoutes juste des features à la vitesse des idées.


Le moine et la dactylographe

Ce n'est pas nouveau. Ça fait juste nouveau parce que c'est le code qui change maintenant.

L'écriture — la vraie écriture, des mots sur une page — était une fois un métier spécialisé. Des moines assis à la lumière des chandelles recopiaient les manuscrits avec soin. L'effort qu'il fallait pour mettre le langage en forme permanente était lui-même un filtre : si quelqu'un avait fait cet effort, ça valait probablement la peine de lire. Puis la presse à imprimer est arrivée. Puis la machine à écrire. Chaque étape a abaissé la barrière, élargi qui pouvait participer, et déclenché les mêmes anxiétés sur les standards qui s'effondrent. Les taux d'alphabétisation ont augmenté. On a continué.

Une haute alphabétisation n'a rendu personne bon écrivain. Savoir former des lettres ne veut pas dire que tu peux structurer un argument. Écrire des mots n'est pas la même chose que savoir communiquer. Tu dois toujours apprendre la grammaire, la composition, comment tenir l'attention d'un lecteur sur cinq mille mots sans perdre le fil. Ces compétences vivent à un niveau supérieur à l'acte mécanique d'écrire — et c'est ce qui compte vraiment.

Le code traverse la même transition. L'acte mécanique devient accessible à n'importe qui avec un prompt. Les moines regardent la presse arriver. Ce qui reste, après que la mécanique soit automatisée, c'est la compréhension à un niveau plus élevé. Cette partie ne disparaît pas.


Ce qui s'atrophie, ce qui ne le fait pas

On va perdre la capacité à écrire du code, comme on a largement perdu la capacité à écrire à la main. On m'a appris l'écriture cursive. C'était déjà un peu cérémoniel à ce moment-là — quelque chose que tu apprenais, que tu utilisais brièvement, et que tu rangeais parmi les curiosités. Maintenant la plupart des gens tapent. Bientôt la plupart dicteront, et l'IA gérera le reste. Chaque couche d'automatisation érode la compétence qu'elle remplace.

C'est correct. Les dactylographes surpassaient vastement les gens qui écrivaient à la main. Les gens qui dictent à des assistants IA vont surpasser les gens qui tapent. Les compétences ne disparaissent pas — elles remontent, loin de l'exécution et vers la direction.

Ce qui se libère n'est pas accessoire. Quand tu n'utilises pas ta bande passante mentale à former une phrase, tu en as plus pour ce que la phrase doit dire et si elle a besoin d'être dite du tout. Quand tu n'écris pas du code, tu peux réfléchir plus dur à ce que le logiciel devrait réellement faire. Ce n'est rien. C'est peut-être la partie qui a toujours compté.

Mais — et c'est ce qui ne cesse d'être minimisé — « ne pas écrire les mots toi-même » n'est pas la même chose que « ne pas avoir besoin de comprendre l'écriture ». Tu dois toujours décider ce qu'il faut dire, dans quel ordre, à quelle longueur. Tu dois toujours savoir quand quelque chose est redondant, quand la logique ne tient pas. Un agent implémentera ce que tu lui dis ; il ne te dira pas que ta structure est un désastre ou que tu as fait le même point trois fois.

Pareil avec le code. Tu ne peux pas faire du bon logiciel en donnant un prompt à un agent si tu n'as aucune idée de comment le logiciel fonctionne. Tu vas obtenir quelque chose qui a l'air de pouvoir fonctionner — jusqu'à ce que tu essaies de changer quelque chose et que le tout commence à grincer sous le poids de décisions que tu n'as pas assez comprises pour les remettre en question.


Métaconnaissance

La tendance générale de l'ère de l'information a été ceci : à mesure que la connaissance devient plus disponible, ce qui devient précieux n'est pas la connaissance elle-même mais la capacité à la naviguer. La spécialisation a toujours sa place, mais la direction du voyage est vers une abstraction plus élevée. Processus. Structures. Comment les choses se superposent, comment elles communiquent, où les goulots d'étranglement se forment.

Tu n'as pas besoin de savoir bien écrire pour écrire bien. Mais tu dois comprendre comment fonctionne la communication.

Tu n'as pas besoin de savoir écrire du code pour construire du logiciel. Mais tu dois comprendre comment fonctionne le logiciel.

Le niveau auquel tu dois comprendre les choses remonte, ça ne disparaît pas. Les détails sont gérés par les outils ; l'architecture reste la tienne. Et si tu abandonnes l'architecture — si tu envoies simplement un prompt, tu acceptes, et tu mets en ligne — tu obtiens des librairies Ghost-sized dans des tiny apps, Next.js où un dossier statique ferait l'affaire, et des features que personne n'a demandées enterrées trois menus sous.

Ça aura des conséquences pour la façon dont on enseigne. Beaucoup des programmes actuels pointent vers des spécialisations qui sont sur le point de changer radicalement ou de cesser d'exister complètement. Ce avec quoi les remplacer, et comment — ça mérite son propre traitement. Mais la réponse aura quelque chose à voir avec la compréhension à l'échelle : savoir comment les choses fonctionnent sans avoir besoin de les faire fonctionner toi-même.

C'est la métaconnaissance. Et si les derniers mois de construction de cette plateforme m'ont appris quelque chose, c'est qu'on sent exactement quand on n'en a pas assez.