Karpathy’s Software 3.0: wat ik in 2026 bouw

Karpathy’s Software 3.0: wat ik in 2026 bouw

Ik heb afgelopen weekend drie zijprojecten gedood.

Een maaltijdplanner die boodschappenfoto's omzet in recepten. Een 'tweede brein'-samenvatting van spraaknotities. Een Chrome-extensie die LinkedIn-berichten met uw stem herschreef. Allemaal half gebouwd. Ze staan ​​nu allemaal op mijn ~/projects/abandoned/-kerkhof, met in elk een enkel KILLED.md-bestand waarin wordt uitgelegd waarom.

De reden was in alle drie de gevallen dezelfde: een enkele multimodale LLM-prompt kon al 80% doen van wat de app deed. Ik was geen software aan het bouwen. Ik was loodgieterswerk aan het bouwen rond de mogelijkheden die het model al standaard had.

Wat mij ertoe aanzette om die mappen daadwerkelijk te openen en mv ~/projects/[name] ~/projects/abandoned/ uit te voeren, was geen nieuwe modelrelease. Het was de Sequoia AI Ascent 2026-toespraak van Andrej Karpathy - de lezing waarin hij vibe coding twaalf maanden nadat hij de term had bedacht als "verouderd" verklaarde, agentic-engineering als de nieuwe standaard verklaarde en iets zei dat mij dagenlang bijbleef: "De meeste bestaande apps zouden niet moeten bestaan."

Ik heb dit jaar veel AI keynotes bekeken. De meeste ervan zijn verkooppraatjes van leveranciers, gekleed als visie. Karpathy was anders. Hij vertelde me niet wat ik moest gebruiken; hij gaf me een raamwerk om elke regel code die ik nu aan het schrijven ben, te evalueren. Karpathy Software 3.0 is geen product. Het is een lens. En toen ik er eenmaal doorheen begon te kijken, bleef ik overal dode apps zien.

Dit is wat ik aan het verwerken ben. Wat ik nu aan het bouwen ben. Wat ik weiger te bouwen. En die ene test – de MenuGen-test – voer ik nu uit op elk project voordat ik een regel code schrijf.

Wat Karpathy eigenlijk zei (en waarom het er nu toe doet)

Laat me eerst het kader verduidelijken, omdat de zinsnede "Software 3.0" zo vaak wordt rondgeschopt dat het zijn scherpte verliest.

In de keynote van Karpathy [juni 2025 YC AI Startup School] (https://x.com/karpathy/status/1935518272667217925) schetste hij een geschiedenis van software in drie fasen:

• Software 1.0 — code die mensen schrijven. Expliciete regels, deterministische logica, het hele internet van vóór 2012. Wat mijn CS-diploma mij heeft geleerd.
• Software 2.0 — Gewichten van neurale netwerken getraind op basis van gegevens. Het model leert de functie in plaats van dat de ingenieur deze specificeert. Beeldclassificatoren, aanbevelingssystemen, het hele decennium van 'machine learning'.
• Software 3.0 — grote taalmodellen als programmeerbare computers. Je "programmeert" ze in het Engels (of welke taal dan ook), met aanwijzingen, voorbeelden, hulpmiddelen en context. De prompt is de broncode. De LLM is de tolk.

Die derde categorie is degene die ieders brein heeft gebroken. We schrijven al vijftig jaar 1.0 en al tien jaar 2.0. Nu is er nog een derde ding: het compileert niet, heeft geen typecontrole en past niet in een van onze bestaande IDE's of mentale modellen voor versiebeheer.

Tijdens zijn Fireside in Sequoia 2026 ging Karpathy verder: hij markeerde december 2025 als keerpunt – de maand waarin de door AI gegenereerde code niet langer ‘nuttig maar rommelig’ was, maar consistent goed genoeg begon te zijn om op de productie te vertrouwen. Zijn eigen ratio keerde die maand om. In november schreef hij ongeveer 80% van zijn code met de hand. In december delegeerde hij 80% naar agents.

Ik merkte hetzelfde op mijn eigen machine; ik had er gewoon geen taal voor. Rond half december stopte ik met het regel voor regel beoordelen van elke Claude Code diff. Ik stopte met het ritueel van ‘beweeg over de functie en lees het karakter voor karakter’ dat ik in de loop der jaren had opgebouwd. De verschillen waren precies... goed. Niet altijd perfect, maar vaak genoeg dat de kosten van een volledige beoordeling de voordelen overtroffen.

Dat was het moment dat de vloer bewoog.

En dit is wat niemand duidelijk genoeg zegt: de vloer die beweegt, betekent niet dat het plafond omhoog ging. Het betekent dat de meeste apps die mensen momenteel bouwen, niet langer hoeven te bestaan.

Dat brengt ons bij de test.

De MenuGen-test (mijn nieuwe pre-build-filter)

Het voorbeeld van Karpathy was MenuGen – een app die hij bouwde en die een foto maakte van het menu van een restaurant en afbeeldingen van elk gerecht weergaf, zodat je kon zien wat je bestelde. Nuttig idee. Hij heeft het verzonden.

Toen gebeurde de Nano Banana-update van Gemini. U kunt nu de menufoto uploaden, 'laat me zien hoe elk gerecht eruit ziet' typen en hetzelfde resultaat inline krijgen. Geen app. Geen back-end. Geen API key-beheer. Geen App Store-distributie. Slechts één enkele multimodale prompt.

MenuGen is verouderd op het moment dat een grensmodel hetzelfde werk native kon doen.

Ik voer nu wat ik de MenuGen-test noem uit op elk projectidee voordat ik me eraan vastleg:

"Als een enkele multimodale LLM-prompt (naar GPT-5.4, Claude Opus 4.7 of Gemini 3) 80% kan doen van wat deze app doet, zou de app niet als een zelfstandige app moeten bestaan. Hij zou moeten bestaan als een prompt, een systeembericht, een opgeslagen vaardigheid, of hij zou helemaal niet moeten bestaan. "

Dat is het. Dat is het filter.

Dit is hoe mijn drie gedode projecten scoorden:

Maaltijdplanner van boodschappenfoto's. Een gebruiker uploadt een foto van de inhoud van zijn koelkast → app haalt ingrediënten eruit → stelt recepten voor. MenuGen-test: Plaats een koelkastfoto in Gemini en typ "geef me 3 recepten die ik kan maken op basis van wat zichtbaar is." Het werkt. Beter dan mijn app eigenlijk, omdat Gemini verstand heeft van kooktechnieken en ik twee maanden zou hebben besteed aan een vage visie API-integratie. Gedood.

Spraaknotitie-samenvatting met integratie van het tweede brein. Spraakmemo opnemen → transcriberen → samenvatten → opslaan in Obsidian-stijlhiërarchie. MenuGen-test: Claude met audio-invoer en een enkele MCP-server gericht op mijn Obsidian-kluis. Klaar. De "app" bestond uit slechts drie regels orkestratielijm. Gedood.

LinkedIn bericht herschrijven met je stem. Bericht plakken → herschrijven in de tonale stijl van de gebruiker op basis van eerdere berichten. MenuGen test: Hier moest ik over nadenken. De eigenlijke prompt zou gedaan kunnen worden in een enkele LLM-oproep: voer eerdere berichten in als stijlvoorbeelden, plak het nieuwe concept, zorg voor een herschrijving. Het werk dat ik aan het bouwen was, was niet het herschrijven. Het was de authenticatie, de LinkedIn API-integratie, de planning, de teamwerkruimte, de analyses. Niets waar de gebruiker daadwerkelijk om heeft gevraagd. Ze vroegen om "dit bericht met mijn stem te herschrijven." Gedood.

Die derde is waar de test pijn doet. Want wat ik eigenlijk aan het bouwen was, was een SaaS-verpakking rond een prompt van 12 regels. En ik zou het verzonden hebben. Ik zou er kosten voor hebben gemaakt. En zes maanden later, toen ChatGPT of Claude de functie 'match mijn schrijfstijl vanuit een verbonden document' toevoegde, zou mijn SaaS van de ene op de andere dag zijn overleden, samen met ongeveer 4.000 andere 'AI X voor Y'-wrappers.

De MenuGen-test is geen pessimisme. Het is een overlevingsfilter. Als uw product met één enkele prompt kan worden gerepliceerd, bouwt u geen software, maar bouwt u een functie voor het product van iemand anders.

Dat betekent niet dat er niets gebouwd mag worden. Het betekent dat we verschillende dingen moeten bouwen.

Daar gaat de rest van dit verhaal over.

Wat Vibe Coding goed had (en waarom Karpathy het begroef)

Voordat we beginnen met wat we gaan bouwen, moeten we het hebben over de workflowverschuiving - omdat de meeste mensen die ik ken nog steeds vibe coding zijn, en Karpathy het zojuist tot een junior-league-activiteit heeft verklaard.

Vibe-codering, om eerlijk te zijn, had ik veel gelijk. Het verhoogde de vloer. Iedereen met smaak en geduld kan nu werkende apps verzenden. Ik heb niet-ingenieurs Shopify-winkelintegraties, interne teamdashboards en persoonlijke tools in één weekend zien verzenden. Die verdiepingsverhoging is echt. Het is niet verdwenen.

Maar het argument van Karpathy in 2026 is dat vibe coding een plafond heeft – en dat is een laag plafond. Je kunt vibreren naar een werkend prototype. Je kunt vibe-coderen naar een v1 die goed demonstreert. Je kunt niet coderen voor productiebetrouwbaarheid. U kunt niet via een beveiligingsaudit coderen. Je kunt geen integratie coderen die 10.000 gelijktijdige gebruikers verwerkt met eventuele consistentievereisten over drie databases.

Dat is waar agentic engineering om de hoek komt kijken. De discipline die hij nu aan het pushen is, heeft een specifieke vorm:

• Specificaties vóór code. Schrijf op wat het systeem moet doen, niet alleen hoe u wilt dat het eruit ziet. (Mijn OpenSpec-beschrijving behandelt de versie hiervan die ik dagelijks gebruik.)
• Plannen vóór bewerkingen. Laat de agent wijzigingen voorstellen voordat deze deze doorvoert. Bekijk het plan. Vervolgens uitvoeren. - Tests als primair signaal. Geen trillingen. Niet 'ziet er goed uit'. Tests die eerst niet slagen en dan slagen als bewijs dat iets werkt. - CI-loops bij elke wijziging. Lint, test, typecontrole, beveiligingsscan: geautomatiseerd, elke commit, geen uitzonderingen. - Verschilinspectie. Lees wat de agent heeft gewijzigd voordat u deze accepteert. Vooral voor alles wat te maken heeft met authenticatie, facturering of gebruikersgegevens. - Permissie-isolatie. Geef geen agent root op uw machine.

Use git worktrees for parallel work. Zandbak wat je kunt.

If that list looks familiar, it's because it's just... software engineering. De dingen die senior engineers altijd hebben gedaan. The version of the practice that survived a decade of "move fast and break things." Karpathy is essentially saying: AI didn't kill the engineering discipline. Het maakte de technische discipline belangrijker, omdat je medewerker nu een vloeiende maar niet voorzichtige junior is die jouw oordeel nodig heeft, niet je typesnelheid.

The shift in 2026 is not "AI replaces engineers." It's "engineers who can supervise AI replace engineers who only type code."

Er is iets dat ik tegen elke ontwikkelaar met wie ik werk nu zeg: de waarde van jouw oordeel is zojuist gestegen. De waarde van uw typen is gedaald. Als u nog steeds typen verkoopt, bent u al verouderd. Als u met een hoog signaal kunt specificeren, plannen, evalueren en beoordelen, heeft u zojuist een hefboomvermenigvuldiger van 10x gekregen.

En cruciaal: Karpathy maakte een waarschuwing die bijna iedereen over het hoofd ziet.

De valstrik van "10 agenten" (waar ik verbrand werd)

Er gaat momenteel een meme rond: "Ik heb 20 Claude Code agents parallel lopen, hier is mijn workflow." Karpathy keek ernaar en zei in essentie: niet doen.

Zijn visie: de meeste bouwers die 10 tot 20 gelijktijdige agents's proberen te orkestreren, lopen vooruit op wat de huidige modellen betrouwbaar kunnen ondersteunen. De toezichtlast groeit niet-lineair. Tegen de tijd dat u 15 agents beheert, besteedt u al uw tijd als contextwisselende middenmanager en produceert u slechtere resultaten dan een enkele agent onder zorgvuldig toezicht.

Ik heb dit op de harde manier geleerd. Twee maanden geleden probeerde ik een volledig parallelle pijplijn voor het genereren van inhoud op te zetten: één agent voor onderzoek, één voor schetsen, één voor concepten, één voor bewerking, één voor SEO-controles, één voor distributiekopieën. Zes agents. Ze draaien allemaal tegelijk. Allemaal ‘autonoom’.

Wat er feitelijk gebeurde: elke agent produceerde werk dat de volgende agent niet helemaal kon gebruiken, omdat geen van hen de volledige context had. Het onderzoek agent bracht feiten aan het licht waarvan agent niet wist hoe hij deze moest wegen. Het concept agent bedacht de framings die de redacteur agent vervolgens half herschreef. De SEO agent stopte trefwoorden in proza ​​dat de redacteur al had opgepoetst. Tegen de tijd dat de inhoud mij bereikte, besteedde ik meer tijd aan het afstemmen van zes agents-uitvoer dan ik zou hebben besteed aan het hele ding met één Aria-achtige agent onder strikte contextcontrole.

Ik heb de pijpleiding vermoord. Nu voer ik één agent tegelijk uit, diep, met rijke context - precies de context-over-configuratie-aanpak waar ik eerder dit jaar over schreef. Het werk wordt sneller verzonden. De kwaliteit is hoger. De cognitieve belasting voor mij is lager.

De voorzichtigheid van Karpathy komt perfect overeen met wat ik heb waargenomen: minder agents, zorgvuldig beheerd, met beoordelingslussen, verslaat meer agents losjes beheerd. Totdat modellen materieel beter worden in de multi-agent-coördinatie – wat ze wel zullen doen, maar ze zijn er nog niet – is de juiste zet het optimaliseren van de single-agent-lus.

Dit is een van die momenten waarop het discours op sociale media en de praktijkervaring scherp uiteenlopen. Twitter wil dat je denkt dat de toekomst 50 agents in een zwerm is. Karpathy – die meer context heeft over modelmogelijkheden dan vrijwel iedereen op deze planeet – zegt: nog niet. Niet voor de meeste bouwers. Niet in 2026.

Ik vertrouw hem via Twitter. Dat zou jij ook moeten doen.

De vier dingen die de moeite waard zijn om nu te bouwen

Oké. De meeste apps zouden dus niet moeten bestaan. Vibe-codering is de warming-up. Multi-agent-orkestratie is voorbarig. Wat is eigenlijk de moeite waard om te bouwen?

Karpathy gaf vier pijlers in zijn Sequoia-toespraak. Ze doorstaan ​​allemaal de MenuGen-test, omdat ze allemaal aanvullend zijn op wat frontier-modellen standaard doen - en geen omhulsel zijn van wat ze al doen.

1. Tools die het begrip verscherpen (niet alleen snelheid)

De eerste golf AI-tools verkocht snelheid. Snellere code. Snellere e-mails. Snellere ontwerpen. Die race is grotendeels voorbij: elk model van elke leverancier is nu snel genoeg.

De volgende golf verkoopt strategische duidelijkheid. Tools waarmee u beter kunt nadenken, beter kunt beslissen, duidelijker kunt zien en fouten kunt vermijden die u zelf niet zou hebben opgemerkt.

Het patroon: in plaats van 'Ik zal dit voor je schrijven', is het 'Laat me je laten zien wat je mist'. In plaats van output te genereren, brengt de tool de vragen naar boven die je niet hebt gesteld, de aannames die je impliciet maakt, de beslissingen die verborgen zitten in wat lijkt op één enkele keuze.

Ik ben momenteel precies dit soort tool aan het bouwen voor mijn eigen contentworkflow. Aria — de agent die schrijft voor [mijn merknetwerk] (https://www.ramlit.com) — produceert niet alleen berichten. Het voert een zelfevaluatierubriek uit op elk concept, scoort tien retentiedimensies en weigert te verzenden totdat de rubriek is goedgekeurd. De uitvoer is niet sneller. Het is duidelijker, omdat de agent aan het licht brengt wat zwak is voordat het moet.

Dat is het patroon. Niet 'Ik zal het voor je doen'. Maar "Ik zal je laten zien wat je niet kon zien, en ik laat je beslissen."

Als je aan het bouwen bent in 2026, vraag jezelf dan af: verkoop ik snelheid, of verkoop ik duidelijkheid? Snelheid is een handelswaar. Duidelijkheid is een gracht.

2. Agent-First-infrastructuur

Hier wordt het leuk. We hebben dertig jaar besteed aan het bouwen van software voor mensen: toetsenborden, muizen, schermen, GUI's. Elke API heeft een ‘ontwikkelaarsdashboard’. Elk product heeft een onboarding-stroom. Elke database heeft een gebruikersinterface voor het maken van query's.

Nu zijn agents de klanten. En agents wil geen gebruikersinterfaces. Ze willen API's. Ze willen schone metadata. Ze willen machinaal leesbare schema's. Ze willen voorspelbare foutreacties waarvan ze kunnen herstellen. Ze willen documentatie die gestructureerd is en niet veel proza ​​bevat.

De verschuiving is enorm en de meeste productteams hebben deze nog niet geïnternaliseerd. Als uw product namens een gebruiker door een AI agent zal worden gebruikt, is elk UI-element een wrijvingspunt. Elke "klik hier om te bevestigen" is een plaats waar de agent een brug moet slaan tussen de machine-intentie en de menselijke vorm-interface.

De concrete stappen die u nu moet zetten:

• Verzend een llms.txt-bestand. De acceptatie is ongeveer 10% vanaf begin 2026. Het bewijs voor citatieverbetering is gemengd. Maar het duurt 1 tot 4 uur om te implementeren en er zijn geen nadelen als de specificatie breed wordt overgenomen. Het is een goedkope optie voor een toekomst met grote impact. - Laat op elke pagina een Markdown-variant zien. Agentische crawlers – GPTBot, ClaudeBot, PerplexityBot – geven consequent de voorkeur aan Markdown boven HTML wanneer beide worden aangeboden. Dit is reëel, waargenomen en al zichtbaar in de citatiecijfers. - Documenteer uw API's op dezelfde manier als u ze zou documenteren voor een LLM. Duidelijke invoer, duidelijke uitvoer, idempotente bewerkingen, voorspelbare fouten. Sla het proza ​​met marketingsmaak over. Een LLM hoeft niet verkocht te worden; het moet verteld worden.

• Verzend MCP servers voor uw product. Als uw tool kan worden aangeroepen vanuit Claude Code, ChatGPT of een andere agent-runtime, heeft u het zojuist 10x nuttiger gemaakt voor bouwers. (Mijn kijk op de must-have MCPs gaat over wat echt werkt.)

• Behandel agents als eersteklas gebruikers. Geen zijkanaal voor ervaren gebruikers. Geen 'toekomstig routekaartitem'. Behandel de agent-persona op dezelfde manier waarop u vandaag de mobiele persona behandelt.

De bedrijven die dit in een vroeg stadium goed doen, zullen achteraf gezien voor de hand liggend lijken. Degenen die gebruikersinterfaces blijven optimaliseren voor menselijke klikken, terwijl hun concurrenten stilletjes AI-agent-native worden, zullen zich afvragen waarom hun groei afvlakt.

3. Apps met verifieerbare domeinen (waar RL een gracht heeft)

Dit is de diepste pijler, en ook de minst begrepen. Karpathy voerde aan dat de echte verdedigbare slotgrachten in de komende tien jaar niet in zuivere taaltaken zullen liggen; die worden snel gemeengoed. Ze bevinden zich in verifieerbare domeinen: gebieden waar u mechanisch kunt controleren of de uitvoer van het model correct is.

Code ligt voor de hand. U kunt tests uitvoeren. Je kunt pluizen. U kunt typecontrole uitvoeren. Je kunt inzetten en observeren. Elk daarvan is een feedbacksignaal waarmee versterkend leren het model in de loop van de tijd echt beter kan maken in code.

Maar code is niet het enige verifieerbare domein. Kijk naar de lijst:

• Algoritmische handel. P&L is een verifieerbaar signaal. Backtests zijn reproduceerbaar. De markt is wreed, maar kwantificeerbaar.
• Toeleveringsketen. Voorraadniveaus, levertijden, kosten per eenheid: allemaal meetbaar, allemaal verifieerbaar, allemaal vatbaar voor verfijning van RL.
• Gegevensopschoning en ETL. Schemacorrectheid, typevalidatie, referentiële integriteit: deze zijn verifieerbaar. Het model kan worden getraind tegen ground-truth pipelines.
• Compliance en audit. Regelgevende vereisten zijn regels. Ofwel voldoen de gegevens eraan, ofwel niet. Dat is een verificatiesignaal.
• Wetenschappelijke simulatie. Natuurkunde, scheikunde, materiaalkunde: overal waar u een referentiemodel heeft dat voorspellingen kan valideren.

Als je bouwt in een domein waar de juistheid verifieerbaar is, heb je een echte slotgracht. Omdat de gegevens die u uit de productie verzamelt, trainingsgegevens worden die uw specifieke model beter maken in uw specifieke taak – en uw concurrenten die vanille GPT-5.4 met een slimme prompt aanroepen, zullen op dezelfde plaats eindigen als alle andere vanille-prompte concurrenten.

Als je bouwt in een domein waar correctheid niet verifieerbaar is – pure creatieve taken, ‘voelt goed’-beslissingen, zachte oordeelsoproepen – is de slotgracht veel zwakker. Het frontiermodel zal uw snelle engineering uiteindelijk, en waarschijnlijk binnenkort, inhalen.

Dit is het allerbelangrijkste strategische inzicht uit de lezing van Karpathy, en bijna niemand herhaalt het. Verifieerbaarheid is de slotsom. Als uw product een meetbaar correctheidssignaal heeft, kunt u compounderen. Als dat niet het geval is, ben je een wrapper.

4. Software 3.0-native apps (niet snellere spreadsheets)

De vierde pijler is de moeilijkste omdat deze om verbeeldingskracht vraagt, en niet alleen om techniek.

De meeste "AI-functies" die in 2026 verschijnen, zijn Software 1.0-apps met een AI-functie. Spreadsheet met een zijbalk waarin formules worden uitgelegd. E-mailclient met de knop 'Dit onderwerp samenvatten'. Projecttracker met de opdracht "teken mijn standup-update".

Deze zijn nuttig. Ze zijn niet Software 3.0.

Een Software 3.0-native-app is er een die niet kon bestaan voordat LLM's het substraat waren. Het gaat uit van de LLM zoals een 1.0-app uitgaat van een CPU. Het model is geen functie binnen de app; het model is de runtime waarop de app draait.

Kijk naar Vibe App Builder van monday.com. Denk eens na over wat het eigenlijk is: een systeem waarbij een niet-ontwikkelaar een app in natuurlijke taal beschrijft, en het platform een ​​werkende interne tool genereert: gebruikersinterface, dataverbindingen, machtigingen, de werken. Maandag zijn alleen al in het eerste kwartaal van 2026 meer dan 19 functies en 26 A/B-tests voor Vibe-apps verzonden. Het schaaltempo vertelt je dat ze iets echts hebben gevonden.

Het interessante is niet dat het apps genereert. Het is dat het interactiemodel fundamenteel verschilt van de no-code-tools uit het verleden. Er is geen sprake van slepen en neerzetten. Er is geen visueel stroomdiagram. De gebruiker beschrijft in het Engels wat hij wil, de LLM stelt een werkende app voor, de gebruiker verfijnt via chat. De app bestaat niet als statische code; hij bestaat als een levend gesprek tussen intentie en uitvoering.

Dat is Software 3.0-native. De Engelse beschrijving is de broncode. De LLM is de compiler. De app is het uitvoerbare bestand.

Als je nu aan het bouwen bent, kun je het beste vragen: wat wordt er mogelijk als de LLM het substraat is en geen feature? Niet 'hoe voeg ik AI toe aan mijn app', maar 'welke app kan alleen maar bestaan ​​omdat LLM's bestaan?'

Voorbeelden die ik nauwlettend in de gaten houd:

• Persoonlijke context-engines: apps die uw specifieke patronen diep genoeg leren kennen zodat ze werkhulpmiddelen genereren die op u zijn afgestemd, niet op 'gebruikers'. Zie Karpathy's eigen CLAUDE.md-vaardighedenbenadering voor de vroege versie hiervan.
• Efemere apps: applicaties die voor één workflow bestaan ​​en daarna verdwijnen. Geen installatie, geen aanmelding. Het model spint ze op als antwoord op een behoefte.
• Agent-beheerde services — producten waarbij de gehele klantgerichte laag een agent is, en geen UI, en het "product" de redeneringslus van de agent is.
• Continuous-spec-systemen: software waarbij de specificaties naast de code staan ​​en wijzigingen zich automatisch door beide lagen voortplanten. (Traycer's Bart mode is hier een glimp van.)

Dit zijn geen sciencefiction. Ze worden momenteel in kleine aantallen gebouwd door bouwers die de valstrik van "Laat me een AI-functie aan mijn SaaS toevoegen" hebben overgeslagen.

Hoe ik mijn eigen werk herstructureer

Genoeg theorie. Dit is wat ik feitelijk heb veranderd in mijn workflow nadat ik een week lang bij de lezing had gezeten.

Eén. Ik heb drie zijprojecten verwijderd en een MenuGen test-checklist toegevoegd aan mijn projectintakesjabloon. Elk nieuw idee moet nu de vraag beantwoorden: kan één enkele multimodale prompt 80% hiervan doen? Zo ja, dan wordt het niet gebouwd. Het wordt opgeslagen als een prompt in mijn map Claude Skills.

Twee. Ik heb mijn agent-opstelling verschoven van parallel-experimenteel naar single-agent-diep. Ik schrapte een zes-agent-inhoudspijplijn en ging terug naar het uitvoeren van één Aria-instantie tegelijk, met rijke context, zorgvuldig toezicht en strakke beoordelingsloops. De uitvoerkwaliteit ging onmiddellijk omhoog. Het bericht dat je nu leest, is op deze manier tot stand gekomen.

Drie. Ik heb een llms.txt toegevoegd aan mejba.me, ramlit.com, colorpark.io en xcybersecurity.io. Het duurde misschien 90 minuten voor alle vier. De adoptie is matig, het bewijsmateriaal voor citaten is wisselend, maar de kosten voor het overslaan zijn hoog als de zoekopdracht AI blijft groeien zoals het is gegroeid. Goedkope optie.

Vier. Ik begon elk actief project te controleren op de vier pijlers. Als een project niet aan een van deze criteria voldoet (duidelijkheidstool, agent-eerste infra, verifieerbaar domein of Software 3.0-native), staat het op het hakblok. Tot nu toe is nog een project stopgezet en zijn er twee geherstructureerd.

Vijf. Ik investeer agressief in de disciplinekant van AI-ontwikkeling - specificaties, plannen, recensies, tests - en leg de nadruk op typsnelheid, prompt-tweaking en het verzamelen van tools. De hefboomwerking ligt nu in het oordeel. Ik handel dienovereenkomstig.

Zes. Ik wacht op de volgende buiging. Karpathy had rond december 2025 gelijk. De volgende grote verandering – wanneer het parallel draaien van 20 agents daadwerkelijk werkt, wanneer modellen zichzelf betrouwbaar kunnen specificeren, wanneer RL met een verifieerbaar domein echte bovenmenselijke capaciteiten produceert in een niche – komt eraan. Ik wil er klaar voor zijn om het binnen een week te herkennen, niet binnen een kwartaal. Dat betekent dat je dicht bij de rand van de praktijk moet blijven, en niet bij de kern van de keynote.

Het enige dat de moeite waard is om mee te zitten

Als je één ding uit de toespraak van Karpathy en uit dit hele bericht haalt, neem dan dit:

Het is niet de taak om software te bouwen. Het is de taak om de dingen te bouwen die software nu mogelijk maakt.

Dertig jaar lang was 'software bouwen' het doel omdat software de beperking was. Je had een app nodig omdat je zonder die app niet voor elkaar kon krijgen. De app was de bottleneck.

Software is niet langer de bottleneck. De LLM-as-runtime is het knelpunt – en het knelpunt beweegt zich sneller dan welk enkel productteam dan ook kan. Dus het bouwen van 'een app' binnen een categorie die op de modellaag al gemeengoed is, is een verloren zaak. Je wordt verzonden en drie maanden later zal het model je onderbrengen.

Het winnende spel is om te bouwen voor het model, bovenop het model, of in domeinen waar het model alleen niet kan winnen. Gereedschappen voor duidelijkheid. Agent-first infrastructuur. Verifieerbare domeinexpertise. Software 3.0-native-ervaringen. Dat zijn de vier weddenschappen die over vijf jaar voor de hand liggen.

Al het andere (inclusief de meeste projecten die ik vorige week in mijn IDE had geopend) was MenuGen. En MenuGen is nu een functie, geen product.

Ga vanavond eens naar je ~/projects/-map kijken. Voer de test op elk van hen uit. Wees eerlijk. De meesten van ons bouwen loodgieterswerk rond mogelijkheden die al in het model bestaan. Sommigen van ons bouwen iets dat alleen bestaat omdat het model bestaat.

Het verschil tussen die twee is het verschil tussen een bijproject en een carrièrebepalend project. Karpathy heeft ons zojuist de test overhandigd om ze uit elkaar te houden. De rest is voor ons.

Wat heb je deze week vermoord?

Veelgestelde vragen

Wat is Karpathy's Software 3.0 in gewoon Engels?

Software 3.0 is wanneer LLM's de runtime worden en natuurlijke taal de broncode. Software 1.0 was handgeschreven code. Software 2.0 was getraind op neurale netwerkgewichten. Software 3.0 vraagt ​​om een ​​LLM die uw bedoeling interpreteert en uitvoert. Voor het volledige mentale model, zie het openingsgedeelte hierboven.

Is vibe coding dood in 2026?

Nee – vibe coding werkt nog steeds voor prototypes, weekendprojecten en vloerverhoging voor niet-ingenieurs. Wat Karpathy stopte, was vibe coding als de productie-aanpak. Voor leverbare software is agentic-engineering (specificaties, plannen, tests, CI en diff-beoordeling) nu de standaard. Zie "Wat Vibe Coding goed heeft" hierboven.

Wat is de MenuGen-test?

De MenuGen-test vraagt: als een enkele multimodale LLM-prompt 80% kan doen van wat uw app doet, zou de app niet als een zelfstandig product moeten bestaan. Het komt uit het MenuGen-voorbeeld van Karpathy - een echte app die hij heeft gebouwd en die achterhaald raakte op het moment dat Gemini's Nano Banana-update hetzelfde werk in één prompt kon doen.

Moet ik in 2026 een multi-agent-systeem bouwen?

Waarschijnlijk nog niet. Karpathy waarschuwde expliciet tegen het gelijktijdig uitvoeren van 10-20 agents - de huidige modellen coördineren niet zo goed, en de toezichtlast vernietigt de kwaliteit. Eén agent onder zorgvuldig toezicht verslaat zes losjes beheerde. Herhaal dit over zes tot twaalf maanden.

Wat is agent-eerste infrastructuur?

Agent-first-infrastructuur is software die is ontworpen voor AI agents als primaire gebruikers: schone API's, machinaal leesbare metagegevens, llms.txt-bestanden, Markdown-first-documentatie, MCP servers en voorspelbare foutreacties. De verschuiving behandelt agents als een eersteklas persona, niet als een zijkanaal. Zie pijler 2 hierboven voor concrete stappen.

Laten we samenwerken

Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.

• Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (ondernemingsoplossingen): ramlit.com
• ColorPark (ontwerp en branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io