Ton article le dit très bien : les labs ont entraîné sur le code parce que le feedback est binaire. Ça compile ou ça plante. Pas d'ambiguïté. Et c'est précisément ce signal clair qui a permis le "transfer learning" vers le "raisonnement structuré". Mais il y a un paradoxe que tu traverse à mon avis : cette même propriété qui a fait du code le terrain d'entraînement idéal est exactement ce qui rend l'extrapolation compliquée dans notre monde "d'information" au sens théorie et pratique de l'information. Dans le code, "verify" veut dire faire passer un test. Dans l'information au sens le plus général, "verify " veut dire évaluer la fiabilité ou juger de la pertinence vs le monde réel, ou encore repérer ce qui manque dans un raisonnement qui a l'air complet. Aucun test unitaire au monde ne sait faire ça, mais je peux me tromper. Ton rticle met la vérification comme 4ème temps d'une boucle automatisable (read-process-output-verify), mais pour quiconque a déjà vérifié une information, c'est un peu comme mettre "jouer du piano" comme 4ème étape d'un tuto en cinq points, pour reprendre l'image ;)
Si je prends comme exemple la génération d'un document quelconque. L'agent cherche et lit des sources, les traite, et produit/génère. Le résultat a l'air solide. Mais pour moi c'est là que ça se complique, parce que le 4ème temps, celui qui fait la différence entre un document utile et un document inutile ou dangereux, n'est pas de la même nature que les trois précédents. Ce n'est pas une opération : c'est un jugement. Et un jugement, pour moi ça ne se code pas en Python ni ne se décrit in extenso en anglais/français. La cible à 15 000 milliards existe sûrement, mais elle repose sur l'hypothèse que "verify" est un verbe comme les autres dans la boucle.
Pour l'instant et de mon point de vue, "verify" c'est le verbe qui résiste. Même si les labs, par exemple Anthropic pour ne pas le nommer, tentent tant bien que mal à coup de "contitutions" et autres "rails guards" d'y parvenir. Mais s'ils y arrivaient vraiment, le problème alors serait bien plus compliqué : qui aurait la maitrise du jugement/verify au final ? L'humain ou un modèle guidé par une constitution "imposée" ? Ok je dévie ;)
Merci de ce commentaire détaillé ! Oui j’ai vu dans ta newsletter que tu étais sceptique :)
Tu as raison le verify est un nouveau bottleneck dans certains cas d’univers « ouvert » / sans « ground truth » (exemple : un contrat qui peut se rédiger de X façons). J’aurais dû le préciser
Néanmoins
1/ le point est pas de dire qu’on va automatiser les jobs mais remplacer le SaaS - mais peut être pas clair dans mon déroulé.
2/ Le verify c’est light pour justifier le SaaS sauf si justement ce SaaS se déplace > vers de la data propre qui boucle cette boucle, ou qui organise l auditabilité de ce jugement (qui / comment / pourquoi) etc… c’est le point de Benedict Evans et que j’évoque aussi
Alors pas totalement sceptique mais surtout assez interloqué par tout ce que j'ai pu voir passer et lire sur (je caricature à peine) : "le logiciel est mort", "tous les SaaS sont morts"...
Je pense que nos points de vue se rejoignent, mais corrige moi si ce n'est pas le cas : c'est le déplacement d'une couche et pas une disparition, seules des expressions de cette couche vont disparaitre (certains SaaS par ex)
1/ OK on est d'accord modulo le 2/
2/ Ma compréhension approximative des langues a dû me faire mal interpréter le passage avec lequel je suis en accord aussi
Oui, on est d accord sur l idée de « l’expression » (ou la valeur) du SaaS qui change
Et je te rassure je crois pas que ça soit une question d anglais mon texte n’est pas précis sur cette question … a dire vrai le cœur du message était plutôt en amont sur cette réalisation que le code était plus qu’une question de code, cette partie spécifique du SaaS est en soi un sujet
Pour moi l'emploi du mot "expression" englobe plus que la "valeur", mais tu as entièrement raison de recadrer car c'est principalement une problématique de "valeur" sous toutes ses formes
I keep coming back to your specificity point. I've been building with multiple AI tools on the same product — Claude, ChatGPT, Lovable — and the thing that actually makes it work isn't the models. It's three markdown files: architecture.md, constraints.md, and a decision log. Every session starts with those files as context.
These files are specificity artifacts. They're what's left after code stops being the container for intent. The interesting thing is they compound — every decision logged makes the next session's output more precise, across tools that share no memory with each other.
Your framing names what I've been watching happen in practice but hadn't articulated at that level: the discipline of specificity outlives the medium it was expressed in.
The Specificity Paradox framing is sharp — and I think it explains something beyond just training dynamics. It explains why the mastery gap you describe at the end is structural, not temporary.
The read-process-output loop scales beautifully through code. But verify — the fourth step — doesn't. Olivier's comment nails it: verification isn't an operation, it's a judgment. And judgment doesn't compress into the same substrate.
I've been running a multi-workspace AI practice for several weeks now and this is exactly where the operational reality diverges from the macro thesis. The system can produce more than I can verify. The bottleneck isn't generation capacity. It's the expertise required to know whether what was generated is actually right — and that cost increases with fluency, because the output looks more convincing as the models improve.
Your piano analogy is the right one. But I'd push it further: the instrument got easier to play, and simultaneously harder to tune.
Sorry in french ;)
Ton article le dit très bien : les labs ont entraîné sur le code parce que le feedback est binaire. Ça compile ou ça plante. Pas d'ambiguïté. Et c'est précisément ce signal clair qui a permis le "transfer learning" vers le "raisonnement structuré". Mais il y a un paradoxe que tu traverse à mon avis : cette même propriété qui a fait du code le terrain d'entraînement idéal est exactement ce qui rend l'extrapolation compliquée dans notre monde "d'information" au sens théorie et pratique de l'information. Dans le code, "verify" veut dire faire passer un test. Dans l'information au sens le plus général, "verify " veut dire évaluer la fiabilité ou juger de la pertinence vs le monde réel, ou encore repérer ce qui manque dans un raisonnement qui a l'air complet. Aucun test unitaire au monde ne sait faire ça, mais je peux me tromper. Ton rticle met la vérification comme 4ème temps d'une boucle automatisable (read-process-output-verify), mais pour quiconque a déjà vérifié une information, c'est un peu comme mettre "jouer du piano" comme 4ème étape d'un tuto en cinq points, pour reprendre l'image ;)
Si je prends comme exemple la génération d'un document quelconque. L'agent cherche et lit des sources, les traite, et produit/génère. Le résultat a l'air solide. Mais pour moi c'est là que ça se complique, parce que le 4ème temps, celui qui fait la différence entre un document utile et un document inutile ou dangereux, n'est pas de la même nature que les trois précédents. Ce n'est pas une opération : c'est un jugement. Et un jugement, pour moi ça ne se code pas en Python ni ne se décrit in extenso en anglais/français. La cible à 15 000 milliards existe sûrement, mais elle repose sur l'hypothèse que "verify" est un verbe comme les autres dans la boucle.
Pour l'instant et de mon point de vue, "verify" c'est le verbe qui résiste. Même si les labs, par exemple Anthropic pour ne pas le nommer, tentent tant bien que mal à coup de "contitutions" et autres "rails guards" d'y parvenir. Mais s'ils y arrivaient vraiment, le problème alors serait bien plus compliqué : qui aurait la maitrise du jugement/verify au final ? L'humain ou un modèle guidé par une constitution "imposée" ? Ok je dévie ;)
Merci de ce commentaire détaillé ! Oui j’ai vu dans ta newsletter que tu étais sceptique :)
Tu as raison le verify est un nouveau bottleneck dans certains cas d’univers « ouvert » / sans « ground truth » (exemple : un contrat qui peut se rédiger de X façons). J’aurais dû le préciser
Néanmoins
1/ le point est pas de dire qu’on va automatiser les jobs mais remplacer le SaaS - mais peut être pas clair dans mon déroulé.
2/ Le verify c’est light pour justifier le SaaS sauf si justement ce SaaS se déplace > vers de la data propre qui boucle cette boucle, ou qui organise l auditabilité de ce jugement (qui / comment / pourquoi) etc… c’est le point de Benedict Evans et que j’évoque aussi
Alors pas totalement sceptique mais surtout assez interloqué par tout ce que j'ai pu voir passer et lire sur (je caricature à peine) : "le logiciel est mort", "tous les SaaS sont morts"...
Je pense que nos points de vue se rejoignent, mais corrige moi si ce n'est pas le cas : c'est le déplacement d'une couche et pas une disparition, seules des expressions de cette couche vont disparaitre (certains SaaS par ex)
1/ OK on est d'accord modulo le 2/
2/ Ma compréhension approximative des langues a dû me faire mal interpréter le passage avec lequel je suis en accord aussi
Oui, on est d accord sur l idée de « l’expression » (ou la valeur) du SaaS qui change
Et je te rassure je crois pas que ça soit une question d anglais mon texte n’est pas précis sur cette question … a dire vrai le cœur du message était plutôt en amont sur cette réalisation que le code était plus qu’une question de code, cette partie spécifique du SaaS est en soi un sujet
Pour moi l'emploi du mot "expression" englobe plus que la "valeur", mais tu as entièrement raison de recadrer car c'est principalement une problématique de "valeur" sous toutes ses formes
I keep coming back to your specificity point. I've been building with multiple AI tools on the same product — Claude, ChatGPT, Lovable — and the thing that actually makes it work isn't the models. It's three markdown files: architecture.md, constraints.md, and a decision log. Every session starts with those files as context.
These files are specificity artifacts. They're what's left after code stops being the container for intent. The interesting thing is they compound — every decision logged makes the next session's output more precise, across tools that share no memory with each other.
Your framing names what I've been watching happen in practice but hadn't articulated at that level: the discipline of specificity outlives the medium it was expressed in.
The Specificity Paradox framing is sharp — and I think it explains something beyond just training dynamics. It explains why the mastery gap you describe at the end is structural, not temporary.
The read-process-output loop scales beautifully through code. But verify — the fourth step — doesn't. Olivier's comment nails it: verification isn't an operation, it's a judgment. And judgment doesn't compress into the same substrate.
I've been running a multi-workspace AI practice for several weeks now and this is exactly where the operational reality diverges from the macro thesis. The system can produce more than I can verify. The bottleneck isn't generation capacity. It's the expertise required to know whether what was generated is actually right — and that cost increases with fluency, because the output looks more convincing as the models improve.
Your piano analogy is the right one. But I'd push it further: the instrument got easier to play, and simultaneously harder to tune.