Écrire du code, cette question est essentiellement résolue

Écrit par : Boris Cherny

Au sein d’Anthropic, Boris Cherny est surnommé par ses collègues « le père de Claude Code ». Il a personnellement dirigé la création de cet assistant de programmation basé sur un modèle de grande intégration, et a vécu le grand tournant, passant de « complétion automatique de code » à « agent écrivant 100 % du code » .

Dans cette présentation destinée aux entrepreneurs et ingénieurs, il raconte systématiquement l’histoire de la naissance de Claude Code, pourquoi on dit que « la programmation est résolue (coding is solved) », et quels changements cela implique pour l’industrie logicielle et la configuration des équipes.

De « projet accidentel » à produit phénomène

Boris a rejoint Anthropic fin 2024, à l’époque où l’entreprise disposait d’une petite équipe incubatrice appelée AnthropicLabs. Cette petite équipe a rapidement développé plusieurs produits clés, dont Claude Code, MCP, et une application desktop, puis s’est dissoute après avoir accompli sa mission, avant d’être rappelée pour un « second round ».

Dans le contexte de 2024, l’imagination dominante dans l’industrie concernant « l’écriture de code par IA » se limite encore à l’IDE avec « suggestion/autocomplétion » — appuyer sur Tab pour que le modèle complète une ligne. La intuition de Boris est que : la capacité du modèle dépasse déjà largement cette forme, et la « vraie forme de produit » est très en retard, ce qu’ils appellent en interne « product overhang ».

Ainsi, l’objectif initial de Claude Code était très ambitieux : ne pas simplement faire une autocomplétion plus intelligente, mais faire en sorte que l’agent prenne en charge « l’écriture de tout le code », laissant à l’humain la revue et la prise de décision.

Mais la réalité n’a pas été aussi simple. Pendant les six premiers mois, presque personne n’a vraiment utilisé Claude Code, qui pouvait à peine écrire environ 10 % du code, avec une expérience très rudimentaire, et n’était qu’un outil expérimental chez Anthropic. Ce n’est qu’après la sortie du modèle Opus 4 en mai 2025 que la courbe d’utilisation a commencé à grimper exponentiellement, chaque mise à jour du modèle (4.5, 4.6, 4.7) marquant un tournant « en s’améliorant encore beaucoup ».

En regardant en arrière, ce qui rend ce produit si particulier, c’est qu’il n’a jamais été conçu pour le « modèle actuel », mais pour la « prochaine génération de modèles dans six mois ». L’équipe savait que, pendant un certain temps, il n’y aurait pas d’adéquation produit-marché (PMF), mais elle a insisté pour d’abord établir « la bonne interaction », en attendant que le modèle rattrape.

Pourquoi dit-on que « l’écriture de code est résolue » ?

Sur scène, Boris a directement demandé aux programmeurs dans la salle : qui écrit encore 100 % du code à la main ? Qui utilise 100 % Claude Code ou un agent similaire pour coder ? La majorité est dans une zone intermédiaire, il plaisante en disant : « alors c’est déjà 50 % résolu ».

Mais pour lui, la réponse est déjà très extrême : il écrit maintenant 100 % de son code avec Claude Code.

Le code de Claude Code lui-même est entièrement généré par le modèle, avec une stack technologique très classique : TypeScript + React, sans technologies de pointe sophistiquées.

L’une des raisons de choisir cette stack est qu’au début, lorsque les capacités du modèle étaient encore faibles, il était préférable d’utiliser « la stack technologique principale du domaine d’entraînement du modèle », ce qui améliorait significativement la qualité de génération.

Avec l’évolution du modèle, il peut désormais apprendre sans difficulté de nouvelles langues et frameworks, et le choix de la stack n’est plus un goulot d’étranglement.

Dans son flux de travail personnel, Boris peut réaliser une dizaine de PR par jour, et il a même un jour « tiré » 150 PR, juste pour tester jusqu’où il pouvait pousser l’efficacité ; derrière tous ces PR, c’est Claude qui écrit réellement le code. Son rôle est celui de product owner, architecte, et relecteur.

Il admet aussi que cette « résolution à 100 % » ne s’applique actuellement qu’à certains scénarios :

Les petites bases de code claires et utilisant des stacks principaux peuvent être entièrement confiées au modèle.

Les bases de code très volumineuses, complexes ou utilisant des langages rares ou dans des environnements très spécifiques, restent encore en deçà des capacités du grand modèle.

Mais sa conclusion est simple : la plupart de ces limitations ne sont qu’une question de « prochaine version du modèle ».

Un smartphone + mille agents : son flux de travail personnel

Boris a partagé sur les réseaux sociaux son environnement de développement, qu’il ne pensait pas susciter autant de discussions, car pour lui, c’était simplement une « évolution naturelle » de sa façon de travailler.

Aujourd’hui, il effectue la majorité de ses tâches sur son téléphone : il ouvre ClaudeApp, passe à l’onglet Code, et voit plusieurs conversations en parallèle. Il maintient généralement 5 à 10 conversations, chacune avec de nombreux sous-agents, totalisant facilement plusieurs centaines ; le soir, il peut y en avoir plus de mille en arrière-plan pour des tâches plus longues.

Le concept clé qui soutient ce système est une commande apparemment simple : /loop.

/loop consiste à faire que Claude utilise une méthode similaire à cron pour s’organiser une « tâche répétée automatiquement dans le futur » : programmée pour s’exécuter toutes les minutes, toutes les 5 minutes, ou quotidiennement.

Grâce à ce « loop », il a construit tout un « système d’entretien automatique » :

Un loop surveille « les PR » : il gère CI, fait du rebase automatique, et maintient la liste des PR propre.

Un autre loop veille à « la santé du CI du projet » : détecte et corrige automatiquement les flaky tests et autres problèmes.

Un autre encore extrait toutes les 30 minutes des retours d’utilisateurs sur Twitter, les regroupe, et en tire un résumé exploitable pour la prise de décision.

Selon lui, le loop est déjà comme une primitive de programmation orientée vers l’avenir : la forme la plus simple et réalisable, mais très puissante. Associé aux routines (longs workflows tournant côté serveur, qui continuent même si l’ordinateur est éteint), le modèle peut faire avancer le projet en arrière-plan en permanence.

La configuration des équipes : tous sont « polytechniciens »

Quand une personne peut utiliser l’IA pour écrire 100 % du code, avec une efficacité multipliée par 10 à 100, la façon dont les équipes s’organisent doit forcément changer.

Boris pense que : « Les généralistes interdisciplinaires » seront beaucoup plus courants qu’aujourd’hui.

Aujourd’hui, un « généraliste » désigne souvent un « touche-à-tout » dans l’ingénierie — par exemple, quelqu’un qui gère iOS, Web, et Serveur ; mais la tendance qu’il voit est :

Les généralistes couvriront plus de frontières fonctionnelles, comme : ingénierie + design, ingénierie + produit + science des données, ingénierie + finance/operations.

Dans leur équipe Claude Code, on voit déjà cette configuration : managers techniques, product managers, designers, data scientists, financiers, chercheurs utilisateur, tous écrivant du code et utilisant massivement Claude Code pour faire avancer leur travail.

En d’autres termes, chacun conserve sa spécialité, mais « écrire du code » ne sera plus une prérogative d’une minorité, mais une compétence de base, aussi répandue que l’utilisation d’Office ou PowerPoint aujourd’hui.

Cela mène à une autre conclusion macro : le seuil de productivité logicielle sera drastiquement abaissé, et ceux qui maîtrisent le mieux leur domaine seront les développeurs les plus avantageux.

Par exemple, dans le développement de logiciels comptables, ce ne sera pas forcément le meilleur ingénieur qui dirigera la conception, mais un comptable très compétent en affaires, capable de maîtriser l’IA pour coder, car « coder » deviendra une tâche relativement facile, et « la compréhension approfondie du domaine » sera la ressource rare.

De « programmeur élite » à « programmation pour tous » : une analogie avec l’imprimerie

Pour illustrer cette transformation en profondeur, Boris propose une analogie qu’il aime beaucoup dans l’histoire technologique : l’impact de l’IA sur la production logicielle sera probablement similaire à celui de l’imprimerie en Europe au XVe siècle.

Avant l’invention de l’imprimerie à caractères mobiles, seulement environ 10 % des Européens savaient lire et écrire, et ils étaient employés dans la structure de pouvoir (rois, nobles, Église), pour faire de la lecture ou de l’écriture à la place des autres. La lecture et l’écriture étaient des compétences très spécialisées, que la majorité ne pouvait pas acquérir dans leur vie.

Après l’apparition de l’imprimerie, en seulement 50 ans, la quantité de textes publiés en Europe a dépassé celle des mille années précédentes, et le coût d’un livre a été réduit d’environ 100 fois. Au fil des siècles suivants, avec l’évolution des systèmes éducatifs et des structures sociales, le taux d’alphabétisation a atteint environ 70 % : la lecture et l’écriture sont passées d’un métier réservé à une minorité à une capacité fondamentale pour la majorité.

Selon Boris, le logiciel et la programmation vivent une courbe similaire, mais à une vitesse encore plus rapide.

Autrefois, écrire du logiciel était une profession « hautement spécialisée, avec un seuil d’entrée très élevé ».

Désormais, écrire du logiciel deviendra une compétence aussi courante que « taper à la machine » ou « envoyer des SMS ».

Il y aura toujours des ingénieurs professionnels et des architectes de systèmes de haut niveau, mais la division du travail sera radicalement transformée : de nombreux experts de domaine, entrepreneurs, et employés ordinaires pourront directement « collaborer avec des modèles pour écrire du logiciel ».

Le SaaS va-t-il connaître une « grande extinction » ?

Quand l’IA réduit le coût de l’écriture de logiciel par un facteur 10 ou 100, que va-t-il arriver aux produits SaaS existants ? Va-t-on assister à une « grande extinction du SaaS » ? C’est l’une des questions que Boris se fait souvent poser.

Sa réponse est beaucoup plus complexe qu’un simple oui ou non, et il s’appuie sur le cadre des « Seven Powers » (sept types de barrières concurrentielles) évoqué dans le podcast Acquired pour analyser.

Selon lui, l’IA va rapidement faire perdre de leur valeur certains types de barrières :

Coûts de changement (Switching Costs) : si vous pouvez rapidement migrer des données et réorganiser votre workflow avec un modèle, l’effet de verrouillage basé sur des intégrations complexes et des configurations va s’affaiblir.

Capacités de processus (Process Power) : beaucoup d’entreprises comptent sur la conception de processus et des workflows complexes pour leur avantage concurrentiel, mais les grands modèles deviennent de plus en plus capables de comprendre et d’améliorer ces processus, notamment avec des modèles comme 4.7 qui peuvent « hillclimb » (améliorer itérativement jusqu’à atteindre un objectif), ce qui leur permet d’optimiser les inefficacités.

Par ailleurs, certains avantages fondamentaux ne disparaîtront pas, mais deviendront encore plus importants :

Effets de réseau

Économies d’échelle

Ressources rares (données exclusives, canaux, qualifications particulières)

Une autre tendance clé est que, dans les dix prochaines années, le nombre de startups capables de « produire des produits comparables à ceux des grandes entreprises avec peu de personnel » va considérablement augmenter, peut-être dix fois plus qu’au cours des dix dernières années.

Les raisons :

Les grandes entreprises devront réorganiser leurs processus et former massivement leurs employés à l’IA, ce qui entraînera une inertie et une résistance internes importantes.

Les nouvelles équipes, dès le départ, seront « nativement IA », utilisant très peu de personnel pour créer une valeur très élevée, et pourront ainsi concurrencer les acteurs traditionnels dans de nombreux segments.

Selon lui, cette époque est très favorable aux entrepreneurs et développeurs — « c’est peut-être l’un des meilleurs moments pour créer des produits ou lancer une startup ».

Comment Anthropic « consomme » ses propres produits ?

Beaucoup pensent que, dans une société comme Anthropic, qui développe des modèles, l’organisation utilise en interne des « versions plus avancées et secrètes » pour garder une longueur d’avance. Boris dit exactement le contraire :

Au niveau des modèles, l’organisation utilise la même version que le public (par exemple, beaucoup d’Opus 4.7), avec quelques expérimentations sur des modèles de recherche comme Mythos, mais sans dépendre à long terme d’une version privée « inaccessible » à l’extérieur.

Selon lui, le vrai avantage concurrentiel ne réside pas dans le modèle lui-même, mais dans la profondeur de l’intégration de l’IA dans l’organisation.

Plus concrètement :

Il n’y a plus de pratique de « code écrit à la main » pure dans l’entreprise, même pour des requêtes SQL, tout est généré par le modèle.

Les différents Claude des équipes collaborent via Slack, s’échangeant des « conversations » pour combler les lacunes, partager des infos, et coordonner.

De nombreux processus sont réorganisés autour de mécanismes comme loop, sous-agents, routines, pour que le modèle continue à faire avancer le travail en arrière-plan.

Pour lui, la plus grande « différence » actuelle n’est pas la disponibilité technologique, mais l’organisation et la conception des processus. Pour une startup, c’est une opportunité énorme : plutôt que de transformer petit à petit ses processus existants, il vaut mieux concevoir dès le départ une organisation « native IA ».

Opportunités produits pour les 6 à 12 prochains mois

Revenant à la question des produits et de l’entrepreneuriat : si, il y a quelques années, il voyait un « overhang » dans la programmation, où voit-il le prochain ?

Il évoque plusieurs directions :

ClaudeDesign : une direction déjà utilisable aujourd’hui, mais qui deviendra encore plus impressionnante avec la prochaine génération de modèles. Elle représente une « ébauche de workflow de design profondément IA ».

Loop/Batch/agents massivement parallèles : faire en sorte que des centaines ou milliers de tâches soient traitées simultanément par différents agents, pour devenir une capacité standard, et non une magie noire réservée aux experts.

ComputerUse (modèle contrôlant directement un ordinateur) : grâce à la vision et au contrôle, faire que le modèle manipule des logiciels locaux comme un humain, une solution universelle pour les anciens systèmes sans API ou MCP.

Ces directions ont en commun d’être « déjà utilisables » aujourd’hui, mais leur véritable explosion pourrait venir après une ou deux générations de modèles.

Comme pour Claude Code à ses débuts, des équipes ambitieuses peuvent commencer dès maintenant à concevoir des formes de produits pour la « prochaine génération » de modèles, afin de prendre de l’avance quand ils seront prêts.