Software 3.0 de Karpathy : ce que je construis en 2026

Software 3.0 de Karpathy : ce que je construis en 2026

J'ai tué trois projets parallèles le week-end dernier.

Un planificateur de repas qui transforme les photos d'épicerie en recettes. Un résumé de notes vocales « second cerveau ». Une extension Chrome qui réécrit les publications LinkedIn avec votre voix. Tous à moitié construits. Tous se trouvent maintenant dans mon cimetière ~/projects/abandoned/, avec un seul fichier KILLED.md dans chacun expliquant pourquoi.

La raison était la même dans les trois cas : une seule invite multimodale LLM pouvait déjà faire 80 % de ce que l’application faisait. Je ne construisais pas de logiciel. Je construisais la plomberie autour des capacités que le modèle était déjà livré nativement.

Ce qui m'a poussé à ouvrir ces dossiers et à exécuter mv ~/projects/[name] ~/projects/abandoned/ n'était pas une nouvelle version de modèle. Il s'agissait de la conférence Sequoia AI Ascent 2026 d'Andrej Karpathy, celle dans laquelle il a déclaré vibe coding "obsolète" douze mois après avoir inventé le terme, a déclaré l'ingénierie agentic comme nouvelle valeur par défaut et a dit quelque chose qui m'a marqué pendant des jours : "La plupart des applications existantes ne devraient pas exister."

J'ai regardé beaucoup de keynotes de AI cette année. La plupart d’entre eux sont des arguments de fournisseurs habillés en vision. Celui de Karpathy était différent. Il ne m'a pas dit quoi utiliser – il m'a donné un cadre pour évaluer chaque ligne de code que j'écris en ce moment. Karpathy Software 3.0 n'est pas un produit. C'est un objectif. Et une fois que j’ai commencé à le parcourir, je n’ai pas pu m’empêcher de voir des applications mortes partout.

C'est ce que j'ai traité. Ce que je construis actuellement. Ce que je refuse de construire. Et le seul test — le test MenuGen — que j'exécute désormais sur chaque projet avant d'écrire une ligne de code.

Ce que Karpathy a réellement dit (et pourquoi c'est important en ce moment)

Permettez-moi d'abord de clarifier le cadrage, car la phrase "Software 3.0" a été tellement malmenée qu'elle en perd son avantage.

Dans le discours d'ouverture de la Startup School YC AI de juin 2025 de Karpathy (https://x.com/karpathy/status/1935518272667217925), il a présenté une histoire en trois étapes du logiciel :

• Logiciel 1.0 — code que les humains écrivent. Des règles explicites, une logique déterministe, tout l’Internet d’avant 2012. Ce que mon diplôme CS m'a appris.
• Logiciel 2.0 — pondérations des réseaux neuronaux entraînées sur les données. Le modèle apprend la fonction au lieu que l'ingénieur la spécifie. Classificateurs d'images, systèmes de recommandation, toute la décennie du "machine learning".
• Software 3.0 — grands modèles de langage en tant qu'ordinateurs programmables. Vous les « programmez » en anglais (ou dans n’importe quelle langue), avec des invites, des exemples, des outils et du contexte. L'invite est le code source. Le LLM est l'interprète.

Cette troisième catégorie est celle qui a brisé le cerveau de tout le monde. Nous écrivons du 1.0 depuis cinquante ans et du 2.0 depuis une décennie. Maintenant, il y a une troisième chose - et il ne compile pas, n'a pas de vérification de type, ne rentre dans aucun de nos IDE existants ou modèles mentaux de contrôle de version.

Dans son coin du feu Sequoia 2026, Karpathy est allé plus loin : [il a signalé décembre 2025 comme point d'inflexion] (https://analyticsdrift.com/andrej-karpathy-agentic-engineering-software-3/) - le mois où le code généré par AI a cessé d'être "utile mais compliqué" et a commencé à être systématiquement suffisamment bon pour faire confiance à la production. Son propre ratio s’est inversé ce mois-là. En novembre, il écrivait environ 80 % de son code à la main. En décembre, il déléguait 80 % à agents.

J'ai remarqué la même chose sur ma propre machine : je n'avais tout simplement pas de langage pour cela. Vers la mi-décembre, j'ai arrêté d'examiner chaque différence Claude Code ligne par ligne. J'ai arrêté de faire le rituel « survolez la fonction et lisez-la caractère par caractère » que j'avais construit au fil des années. Les différences étaient juste... correctes. Pas toujours parfait, mais assez souvent pour que le coût d’un examen complet dépasse les avantages.

C'est à ce moment-là que le sol a bougé.

Et voici ce que personne ne dit assez clairement : le déplacement du sol ne signifie pas que le plafond a augmenté. Cela signifie que la plupart des applications que les gens créent actuellement n'ont plus besoin d'exister.

Ce qui nous amène au test.

Le test MenuGen (mon nouveau filtre de pré-construction)

L'exemple de Karpathy était MenuGen, une application qu'il a créée qui prenait une photo du menu d'un restaurant et restituait des images de chaque plat afin que vous puissiez voir ce que vous commandiez. Idée utile. Il l'a expédié.

Ensuite, la mise à jour Nano Banana de Gemini a eu lieu. Vous pouvez maintenant télécharger la photo du menu, taper « montre-moi à quoi ressemble chaque plat » et obtenir le même résultat en ligne. Aucune application. Pas de back-end. Pas de gestion API key. Pas de distribution sur l'App Store. Juste une seule invite multimodale.

MenuGen est devenu obsolète à partir du moment où un modèle frontière pouvait faire le même travail de manière native.

J'exécute maintenant ce que j'appelle le test MenuGen sur chaque idée de projet avant de m'y engager :

* "Si une seule invite multimodale LLM — vers GPT-5.4, Claude Opus 4.7 ou Gemini 3 — peut faire 80 % de ce que fait cette application, l'application ne devrait pas exister en tant qu'application autonome. Elle devrait exister en tant qu'invite, message système, compétence enregistrée, ou elle ne devrait pas exister du tout."*

C'est tout. C'est le filtre.

Voici les scores de mes trois projets tués :

** Planificateur de repas à partir de photos d'épicerie. ** Un utilisateur télécharge une photo du contenu de son réfrigérateur → l'application extrait les ingrédients → suggère des recettes. Test MenuGen : Déposez une photo du réfrigérateur dans Gemini et tapez "donnez-moi 3 recettes que je peux préparer à partir de ce qui est visible". Ça marche. Mieux que mon application, en fait, car Gemini connaît les techniques de cuisine et j'aurais passé deux mois sur une vision feuilletée de l'intégration API. Tué.

Résumateur de notes vocales avec intégration du deuxième cerveau. Enregistrez un mémo vocal → transcrire → résumer → classer dans une hiérarchie de style Obsidian. Test MenuGen : Claude avec entrée audio et un seul serveur MCP pointé vers mon coffre-fort Obsidian. Fait. L '«application» n'était constituée que de trois lignes de colle d'orchestration. Tué.

** Réécriture de publication LinkedIn avec votre voix. ** Coller la publication → réécrire dans le style tonal de l'utilisateur en fonction des publications précédentes. Test MenuGen : Celui-ci, je devais y réfléchir. L'invite réelle pourrait être effectuée en un seul appel LLM : alimentez les publications passées en tant qu'exemples de style, collez le nouveau brouillon, obtenez une réécriture. Le travail que je construisais n’était pas une réécriture. Il s'agissait de l'authentification, de l'intégration LinkedIn API, de la planification, de l'espace de travail d'équipe, des analyses. Rien de ce que l’utilisateur a réellement demandé. Ils ont demandé de « réécrire ce message avec ma voix ». Tué.

C’est dans ce troisième cas que le test fait mal. Parce que ce que je construisais en fait était un wrapper SaaS autour d'une invite de 12 lignes. Et je l'aurais expédié. Je l'aurais facturé. Et six mois plus tard, lorsque ChatGPT ou Claude ont ajouté une fonctionnalité « faire correspondre mon style d'écriture à partir d'un document connecté », mon SaaS serait mort du jour au lendemain avec environ 4 000 autres wrappers « AI X pour Y ».

Le test MenuGen n’est pas du pessimisme. C'est un filtre de survie. Si votre produit peut être répliqué à l'aide d'une seule invite, vous ne créez pas de logiciel : vous créez une fonctionnalité pour le produit de quelqu'un d'autre.

Cela ne veut pas dire qu’il ne faut rien construire. Cela signifie que nous devons construire des choses différentes.

C’est de cela dont parle le reste.

Ce que Vibe Coding a réussi (et pourquoi Karpathy l'a enterré)

Avant de savoir quoi construire, nous devons parler du changement de flux de travail – car la plupart des gens que je connais sont toujours vibe coding, et Karpathy vient de le déclarer comme une activité de ligue junior.

Vibe coding, pour être honnête, a fait beaucoup de choses correctement. Cela a soulevé le plancher. Toute personne ayant du goût et de la patience peut désormais proposer des applications fonctionnelles. J'ai vu des non-ingénieurs expédier des intégrations de boutique Shopify, des tableaux de bord d'équipe internes et des outils personnels en un seul week-end. Cette hausse du plancher est réelle. Cela n'a pas disparu.

Mais l'argument de Karpathy en 2026 est que vibe coding a un plafond – et il est bas. Vous pouvez vibe-coder sur un prototype fonctionnel. Vous pouvez vibe-coder sur une v1 qui fait une bonne démonstration. Vous ne pouvez pas vibe-coder pour garantir la fiabilité de la production. Vous ne pouvez pas vibe-coder via un audit de sécurité. Vous ne pouvez pas vibe-coder une intégration qui gère 10 000 utilisateurs simultanés avec d'éventuelles exigences de cohérence sur trois bases de données.

C'est là qu'intervient l'ingénierie agentic. La discipline qu'il défend désormais a une forme spécifique :

• Spécifications avant le code. Écrivez ce que le système doit faire, pas seulement à quoi vous voulez qu'il ressemble. (Mon article OpenSpec couvre la version que j'utilise réellement au quotidien.)
• Planifie avant les modifications. Demandez au agent de proposer des modifications avant de les effectuer. Passez en revue le plan. Puis exécutez. - Tests comme signal principal. Pas de vibrations. Pas "ça a l'air bien". Échouer puis réussir les tests comme preuve que quelque chose fonctionne. - Boucles CI à chaque modification. Lint, test, vérification de type, analyse de sécurité — automatisé, à chaque validation, sans exception. - Inspection différentielle. Lisez ce que le agent a modifié avant de l'accepter. Surtout pour tout ce qui concerne l'authentification, la facturation ou les données utilisateur. - Isolement des autorisations. Ne donnez pas de racine agent sur votre machine.

Utilisez git worktrees pour le travail parallèle. Bac à sable ce que vous pouvez.

Si cette liste vous semble familière, c'est parce qu'il s'agit simplement de... génie logiciel. Ce que les ingénieurs seniors ont toujours fait. La version de la pratique qui a survécu à une décennie de « avancer vite et casser les choses ». Karpathy dit essentiellement : AI n'a pas tué la discipline de l'ingénierie. Cela a rendu la discipline de l'ingénierie plus importante, car désormais votre collaborateur est un junior parlant couramment mais pas prudent qui a besoin de votre jugement, pas de votre vitesse de frappe.

Le changement en 2026 n'est pas "AI remplace les ingénieurs". Il s'agit de "les ingénieurs qui peuvent superviser AI remplacent les ingénieurs qui ne tapent que du code".

Il y a une chose que je dis à tous les développeurs avec lesquels je travaille maintenant : la valeur de votre jugement vient d'augmenter. La valeur de votre dactylographie a diminué. Si vous vendez toujours de la dactylographie, vous êtes déjà obsolète. Si vous pouvez spécifier, planifier, évaluer et examiner à un signal élevé, vous venez d'obtenir un multiplicateur de levier 10x.

Et surtout, Karpathy a émis une mise en garde que presque tout le monde passe sous silence.

Le piège des « 10 agents » (là où je me suis brûlé)

Il y a un mème qui circule en ce moment : "J'ai 20 Claude Code agents exécutés en parallèle, voici mon flux de travail." Karpathy a regardé cela et a dit, en gros, ne le faites pas.

Son cadrage : la plupart des constructeurs essayant d'orchestrer 10 à 20 agents simultanés sont en avance sur ce que les modèles actuels peuvent prendre en charge de manière fiable. La charge de surveillance augmente de manière non linéaire. Au moment où vous gérez 15 agents, vous passez tout votre temps en tant que gestionnaire intermédiaire à changement de contexte et produisez un résultat pire qu'un seul agent sous une supervision attentive.

J'ai appris celui-ci à mes dépens. Il y a deux mois, j'ai essayé de mettre en place un pipeline de génération de contenu entièrement parallèle : un agent pour la recherche, un pour les plans, un pour les brouillons, un pour l'édition, un pour les vérifications SEO, un pour la copie de distribution. Six agents. Tout fonctionne simultanément. Tous « autonomes ».

Ce qui s'est réellement passé : chaque agent produisait un travail que le prochain agent ne pouvait pas vraiment utiliser, car aucun d'entre eux n'avait un contexte complet. La recherche agent a fait ressortir des faits que agent ne savait pas comment pondérer. Le brouillon agent a inventé des cadrages que l'éditeur agent a ensuite réécrit à moitié. Le référencement agent a inséré des mots-clés dans une prose que l'éditeur avait déjà peaufinée. Au moment où le contenu m'est parvenu, je passais plus de temps à réconcilier six sorties agents que j'aurais passé à tout faire avec un agent de style Aria sous un contrôle de contexte strict.

J'ai tué le pipeline. Maintenant, j'exécute un agent à la fois, en profondeur, avec un contexte riche - exactement l'approche de contexte sur configuration dont j'ai parlé plus tôt cette année. Le travail est expédié plus rapidement. La qualité est supérieure. La charge cognitive sur moi est moindre.

La prudence de Karpathy correspond parfaitement à ce que j'ai observé : moins de agents, gérés avec soin, avec des boucles de révision, bat plus de agents gérés de manière lâche. Jusqu'à ce que les modèles s'améliorent sensiblement au niveau de la coordination multi-agent - ce qui sera le cas, mais ils n'y sont pas encore - la bonne décision consiste à optimiser la boucle unique agent.

C’est l’un de ces moments où le discours sur les réseaux sociaux et l’expérience réelle des praticiens divergent fortement. Twitter veut vous faire croire que l'avenir est constitué de 50 agents en essaim. Karpathy – qui a plus de contexte sur la capacité du modèle que quiconque sur la planète – dit : pas encore. Pas pour la plupart des constructeurs. Pas en 2026.

Je lui fais confiance sur Twitter. Et vous aussi.

Les quatre choses qui valent la peine d'être construites dès maintenant

D'accord. La plupart des applications ne devraient donc pas exister. Le codage vibratoire est l’échauffement. L’orchestration multi-agent est prématurée. Qu’est-ce qui vaut vraiment la peine d’être construit ?

Karpathy a donné quatre piliers dans son discours sur Sequoia. Chacun réussit le test MenuGen, car chacun est additif à ce que font les modèles frontières de manière native - et non un wrapper autour de ce qu'ils font déjà.

1. Des outils qui améliorent la compréhension (pas seulement la vitesse)

La première vague d'outils AI s'est vendue rapidement. Code plus rapide. Des e-mails plus rapides. Des conceptions plus rapides. Cette course est en grande partie terminée : tous les modèles de tous les fournisseurs sont désormais suffisamment rapides.

La prochaine vague vend de la clarté stratégique. Des outils qui vous aident à mieux réfléchir, à mieux décider, à voir plus clairement et à éviter des erreurs que vous n'auriez pas repérées par vous-même.

Le modèle : au lieu de « Je vais écrire ceci pour toi », c'est « laisse-moi te montrer ce qui te manque ». Au lieu de générer un résultat, l'outil fait apparaître les questions que vous n'avez pas posées, les hypothèses que vous faites implicitement, les décisions cachées dans ce qui ressemble à un choix unique.

Je construis exactement ce genre d'outil en ce moment pour mon propre flux de travail de contenu. Aria — le agent qui écrit pour [mon réseau de marque] (https://www.ramlit.com) — ne produit pas seulement des publications. Il exécute une rubrique d'auto-évaluation sur chaque brouillon, note dix dimensions de rétention et refuse d'expédier jusqu'à ce que la rubrique soit adoptée. La sortie n'est pas plus rapide. C'est plus clair, car le agent fait ressortir ce qui est faible avant que je doive le faire.

C'est le modèle. Pas "Je le ferai pour toi". Mais "je vais vous montrer ce que vous ne pouviez pas voir et vous laisser décider."

Si vous construisez en 2026, demandez-vous : est-ce que je vends de la vitesse ou est-ce que je vends de la clarté ? La vitesse est une marchandise. La clarté est un fossé.

2. Infrastructure axée sur les agents

C'est ici que ça devient amusant. Nous avons passé trente ans à créer des logiciels pour les humains : claviers, souris, écrans, interfaces graphiques. Chaque API dispose d'un « tableau de bord du développeur ». Chaque produit a un flux d’intégration. Chaque base de données dispose d'une interface utilisateur de création de requêtes.

Maintenant, agents sont les clients. Et agents ne veut pas d'interface utilisateur. Ils veulent des API. Ils veulent des métadonnées propres. Ils veulent des schémas lisibles par machine. Ils veulent des réponses aux erreurs prévisibles dont ils peuvent se remettre. Ils veulent une documentation structurée et non lourde de prose.

Le changement est énorme et la plupart des équipes produit ne l’ont pas encore internalisé. Si votre produit doit être utilisé par un AI agent au nom d'un utilisateur, chaque élément de l'interface utilisateur est un point de friction. Chaque « cliquez ici pour confirmer » est un endroit où le agent doit faire le lien entre l'intention de la machine et l'interface de la forme humaine.

Les gestes concrets à entreprendre dès maintenant :

• Expédier un fichier llms.txt. L'adoption est de environ 10 % au début de 2026. Les preuves de l’augmentation des citations sont mitigées. Mais la mise en œuvre prend 1 à 4 heures et il n'y a aucun inconvénient si la spécification finit par être largement adoptée. Il s'agit d'une option peu coûteuse pour un avenir à fort impact. - Expose a Markdown variant of every page. Agentic crawlers — GPTBot, ClaudeBot, PerplexityBot — consistently prefer Markdown over HTML when both are offered. Ceci est réel, observé et apparaît déjà dans les taux de citation. - Document your APIs the way you'd document them for an LLM. Clear inputs, clear outputs, idempotent operations, predictable errors. Évitez la prose à saveur marketing. Un LLM n'a pas besoin d'être vendu ; il faut le dire.

• Expédiez MCP servers pour votre produit. Si votre outil peut être appelé depuis Claude Code, ChatGPT ou tout autre environnement d'exécution agent, vous venez de le rendre 10 fois plus utile pour les constructeurs. (Mon point de vue sur les MCP incontournables couvre ce qui fonctionne réellement.)

• Traitez agents comme des utilisateurs de première classe. Il ne s'agit pas d'un canal secondaire pour les utilisateurs expérimentés. Il ne s’agit pas d’un « élément de la future feuille de route ». Traitez le personnage agent de la même manière que vous traitez le personnage mobile aujourd'hui.

Les entreprises qui y parviendront rapidement apparaîtront rétrospectivement évidentes. Ceux qui continuent d’optimiser les interfaces utilisateur pour les clics humains alors que leurs concurrents deviennent discrètement natifs de AI-agent vont se demander pourquoi leur croissance a stagné.

3. Applications à domaine vérifiable (où RL a un fossé)

C’est le pilier le plus profond et le moins compris. Karpathy a fait valoir que les véritables fossés défendables au cours de la prochaine décennie ne concerneront pas les tâches en langage pur – celles-ci deviennent rapidement une marchandise. Ils se trouveront dans des domaines vérifiables : des zones où vous pourrez vérifier mécaniquement si la sortie du modèle est correcte.

Le code est l’évidence. Vous pouvez exécuter des tests. Vous pouvez pelucher. Vous pouvez vérifier la saisie. Vous pouvez déployer et observer. Chacun d’entre eux est un signal de rétroaction qui permet à l’apprentissage par renforcement d’améliorer réellement le code au fil du temps.

Mais le code n’est pas le seul domaine vérifiable. Regardez la liste :

• Trading algorithmique. Le P&L est un signal vérifiable. Les backtests sont reproductibles. Le marché est brutal mais quantifiable.
• Chaîne d'approvisionnement. Niveaux de stocks, délais de livraison, coût par unité : tous mesurables, tous vérifiables, tous susceptibles d'un réglage précis du RL.
• Nettoyage des données et ETL. Exactitude du schéma, validation de type, intégrité référentielle – ces éléments sont vérifiables. Le modèle peut être entraîné sur des pipelines de vérité terrain.
• Conformité et audit. Les exigences réglementaires sont des règles. Soit les données les satisfont, soit non. C'est un signal de vérification.
• Simulation scientifique. Physique, chimie, science des matériaux : partout où vous disposez d'un modèle de référence capable de valider les prédictions.

Si vous construisez dans un domaine où l'exactitude est vérifiable, vous disposez d'un véritable fossé. Parce que les données que vous collectez à partir de la production deviennent des données de formation qui rendent votre modèle spécifique meilleur pour votre tâche spécifique - et vos concurrents qui appellent vanilla GPT-5.4 avec une invite intelligente plafonneront au même endroit que tous les autres plateaux concurrents à invite vanille.

Si vous construisez dans un domaine où l'exactitude n'est pas vérifiable – tâches créatives pures, décisions « qui semblent bonnes », jugements doux – le fossé est beaucoup plus faible. Le modèle frontière finira par rattraper votre ingénierie rapide, et probablement bientôt.

Il s’agit de l’idée stratégique la plus importante issue de l’exposé de Karpathy, et presque personne ne le répète. La vérifiabilité est le fossé. Si votre produit a un signal d'exactitude mesurable, vous pouvez composer. Si ce n'est pas le cas, vous êtes un wrapper.

4. Applications natives Software 3.0 (feuilles de calcul pas plus rapides)

Le quatrième pilier est le plus difficile car il fait appel à de l'imagination, pas seulement à de l'ingénierie.

La plupart des « fonctionnalités AI » livrées en 2026 sont des applications logicielles 1.0 avec un module complémentaire AI. Feuille de calcul avec une barre latérale expliquant les formules. Client de messagerie avec un bouton "Résumer ce fil". Suivi de projet avec une commande "rédiger ma mise à jour standup".

Ceux-ci sont utiles. Il ne s'agit pas de Software 3.0.

Une application Software 3.0-native est une application qui n'aurait pas pu exister avant que les LLM ne soient le substrat. Il assume le LLM de la même manière qu'une application 1.0 assume un processeur. Le modèle n'est pas une fonctionnalité à l'intérieur de l'application : il s'agit du moteur d'exécution sur lequel l'application s'exécute.

Regardez Vibe App Builder de monday.com. Pensez à ce que c'est réellement : un système dans lequel un non-développeur décrit une application en langage naturel et la plate-forme génère un outil interne fonctionnel : interface utilisateur, connexions de données, autorisations, le tout. lundi a livré plus de 19 fonctionnalités et 26 tests A/B pour les applications Vibe au cours du seul premier trimestre 2026. Le rythme de mise à l'échelle vous indique qu'ils ont trouvé quelque chose de réel.

La partie intéressante n’est pas qu’il génère des applications. C'est que le modèle d'interaction est fondamentalement différent des outils sans code du passé. Il n'y a pas de glisser-déposer. Il n'y a pas d'organigramme visuel. L'utilisateur décrit ce qu'il souhaite en anglais, le LLM propose une application fonctionnelle, l'utilisateur affine via le chat. L'application n'existe pas sous forme de code statique : elle existe sous la forme d'une conversation vivante entre l'intention et l'exécution.

C'est Software 3.0-native. La description anglaise est le code source. Le LLM est le compilateur. L'application est l'exécutable.

Si vous construisez en ce moment, la solution la plus efficace est de demander : qu'est-ce qui devient possible lorsque le LLM est le substrat, pas une fonctionnalité ? Non pas "comment ajouter AI à mon application" - mais "quelle application ne pourrait exister que parce que les LLM existent ?"

Exemples que je surveille de près :

- Moteurs de contexte personnel : des applications qui apprennent suffisamment profondément vos modèles spécifiques pour générer des outils de travail adaptés à vous, et non aux "utilisateurs". Voir [l'approche des compétences CLAUDE.md de Karpathy] (https://www.mejba.me/blog/karpathy-claude-md-skills-install-guide) pour la première version de celui-ci.

• Applications éphémères : applications qui existent pour un flux de travail et se dissolvent ensuite. Aucune installation, aucune inscription. Le modèle les fait tourner en réponse à un besoin.
• Services gérés par agent — produits pour lesquels l'intégralité de la couche orientée client est un agent, et non une interface utilisateur, et le « produit » est la boucle de raisonnement du agent.
• Systèmes à spécifications continues : logiciel dans lequel la spécification se trouve à côté du code et les modifications se propagent automatiquement à travers les deux couches. (Bart mode de Traycer en est un aperçu.)

Ce n’est pas de la science-fiction. Ils sont construits en ce moment, en petit nombre, par des constructeurs qui ont ignoré le piège « laissez-moi ajouter une fonctionnalité AI à mon SaaS ».

Comment je restructure mon propre travail

Assez de théorie. Voici ce que j'ai réellement changé dans mon flux de travail après avoir assisté à la conférence pendant une semaine.

Un. J'ai supprimé trois projets parallèles et ajouté une liste de contrôle MenuGen test à mon modèle de réception de projet. Chaque nouvelle idée doit désormais répondre à la question : une seule invite multimodale peut-elle faire 80 % de cela ? Si oui, elle n'est pas construite. Il est enregistré sous forme d'invite dans mon dossier Claude Skills.

Deux. J'ai déplacé ma configuration agent de parallèle-expérimentale à simple agent-deep. J'ai abandonné un pipeline de contenu de six agent et je suis revenu à l'exécution d'une seule instance Aria à la fois, avec un contexte riche, une supervision minutieuse et des boucles de révision étroites. La qualité de sortie a augmenté immédiatement. Le message que vous lisez en ce moment a été réalisé de cette façon.

Trois. J'ai ajouté un llms.txt à mejba.me, ramlit.com, colorpark.io et xcybersecurity.io. Cela a pris peut-être 90 minutes pour les quatre. L'adoption est modérée, les preuves de citation sont mitigées, mais le coût de l'omission est élevé si la recherche AI continue de croître comme elle l'a fait. Option bon marché.

Quatre. J'ai commencé à auditer chaque projet actif par rapport aux quatre piliers. Si un projet ne correspond pas à l'un d'entre eux (outil de clarté, agent-first infra, vérifiable-domain ou Software 3.0-native), il est sur le billot. Jusqu’à présent, un autre projet a été abandonné et deux ont été restructurés.

Cinq. J'investis de manière agressive dans [le côté discipline du développement de AI] (https://www.mejba.me/blog/restraint-most-important-dev-skill) — spécifications, plans, critiques, tests — et je mets moins l'accent sur la vitesse de frappe, le réglage des invites et la collecte d'outils. L’effet de levier est désormais à juger. J'agis en conséquence.

Six. J'attends la prochaine inflexion. Karpathy avait raison à propos de décembre 2025. Le prochain grand changement – ​​lorsque l'exécution de 20 agents en parallèle fonctionne réellement, lorsque les modèles peuvent s'auto-spécifier de manière fiable, lorsque le RL à domaine vérifiable produit de véritables capacités surhumaines dans une niche – est à venir. Je veux être prêt à le reconnaître dans une semaine, pas dans un quart. Cela signifie rester proche de l’avantage du praticien, et non de l’avantage du keynote.

La seule chose qui vaut la peine d'être assise

Si vous retenez une chose du discours de Karpathy et de tout cet article, prenez ceci :

Le travail ne consiste pas à créer des logiciels. Le travail consiste à créer ce que les logiciels rendent désormais possibles.

Pendant trente ans, « construire un logiciel » était l'objectif parce que le logiciel était la contrainte. Vous aviez besoin d’une application parce que vous ne pouviez pas accomplir vos tâches sans une. L’application était le goulot d’étranglement.

Le logiciel n’est plus le goulot d’étranglement. Le LLM-as-runtime est le goulot d'étranglement - et le goulot d'étranglement évolue plus rapidement que n'importe quelle équipe produit. Ainsi, créer « une application » dans une catégorie déjà banalisée au niveau du modèle est un jeu perdu. Vous expédierez et trois mois plus tard, le modèle vous englobera.

Le jeu gagnant consiste à construire pour le modèle, au-dessus du modèle ou dans des domaines où le modèle seul ne peut pas gagner. Outils de clarté. Infrastructure axée sur les agents. Expertise dans un domaine vérifiable. Expériences Software 3.0-native. Ce sont les quatre paris qui semblent évidents dans cinq ans.

Tout le reste – y compris la plupart des projets que j'avais ouverts dans mon IDE la semaine dernière – était MenuGen. Et MenuGen est désormais une fonctionnalité, pas un produit.

Allez regarder votre dossier ~/projects/ ce soir. Exécutez le test sur chacun d’eux. Soyez honnête. La plupart d'entre nous construisent la plomberie autour de capacités qui existent déjà dans le modèle. Certains d’entre nous construisent quelque chose qui n’existe que parce que le modèle existe.

La différence entre ces deux-là est la différence entre un projet parallèle et un projet déterminant une carrière. Karpathy vient de nous faire passer le test pour les distinguer. Le reste est pour nous.

Qu'as-tu tué cette semaine ?

Questions fréquemment posées

Qu'est-ce que Software 3.0 de Karpathy en anglais simple ?

Software 3.0 est le moment où les LLM deviennent le moteur d'exécution et le langage naturel devient le code source. Le logiciel 1.0 était un code écrit à la main. Le logiciel 2.0 a été formé aux poids des réseaux neuronaux. Software 3.0 invite un LLM qui interprète votre intention et l'exécute. Pour le modèle mental complet, voir la section d'ouverture ci-dessus.

vibe coding est-il mort en 2026 ?

Non – vibe coding fonctionne toujours pour les prototypes, les projets de week-end et les élévations de sol pour les non-ingénieurs. Ce que Karpathy a retiré était vibe coding en tant qu'approche de production. Pour les logiciels livrables, l'ingénierie agentic (spécifications, plans, tests, CI et examen des différences) est désormais la norme. Voir « Ce que Vibe Coding a réussi » ci-dessus.

Qu'est-ce que le test MenuGen ?

Le test MenuGen demande : si une seule invite multimodale LLM peut effectuer 80 % de ce que fait votre application, celle-ci ne devrait pas exister en tant que produit autonome. Cela vient de l'exemple MenuGen de Karpathy - une véritable application qu'il a créée et qui est devenue obsolète au moment où la mise à jour Nano Banana de Gemini a pu faire le même travail en une seule invite.

Dois-je construire un système multi-agent en 2026 ?

Probablement pas encore. Karpathy a explicitement mis en garde contre l'exécution simultanée de 10 à 20 agents : les modèles actuels ne se coordonnent pas très bien et la charge de supervision détruit la qualité. Un agent sous surveillance attentive bat six agent sous une surveillance attentive. Revisitez ceci dans 6 à 12 mois.

Qu'est-ce que l'infrastructure agent-first ?

L'infrastructure axée sur l'agent est un logiciel conçu pour AI agents en tant qu'utilisateurs principaux : API propres, métadonnées lisibles par machine, fichiers llms.txt, documentation Markdown-first, MCP servers et réponses d'erreur prévisibles. Le changement consiste à traiter agents comme un personnage de première classe, et non comme un canal secondaire. Voir le pilier 2 ci-dessus pour des actions concrètes.

Travaillons ensemble

Vous cherchez à créer des systèmes AI, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.

• Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
• Portefeuille : mejba.me
• Ramlit Limited (solutions d'entreprise) : ramlit.com
• ColorPark (conception et image de marque) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io