Karpathys Software 3.0: Was ich 2026 baue

Ich habe letztes Wochenende drei Nebenprojekte getötet.

Ein Essensplaner, der Lebensmittelfotos in Rezepte verwandelt. Eine Zusammenfassung von Sprachnotizen im „zweiten Gehirn“. Eine Chrome-Erweiterung, die LinkedIn-Beiträge mit Ihrer Stimme umschreibt. Alle halb fertig. Alle liegen jetzt auf meinem ~/projects/abandoned/-Friedhof, mit jeweils einer einzigen KILLED.md-Datei, die erklärt, warum.

Der Grund war in allen drei Fällen derselbe: Eine einzige multimodale LLM-Eingabeaufforderung konnte bereits 80 % der Aufgaben der App erledigen. Ich habe keine Software entwickelt. Ich habe die Sanitäranlagen um die Funktionen herum aufgebaut, die das Modell bereits nativ ausgeliefert hat.

Was mich dazu bewogen hat, diese Ordner tatsächlich zu öffnen und mv ~/projects/[name] ~/projects/abandoned/ auszuführen, war keine neue Modellversion. Es war der Sequoia AI Ascent 2026-Vortrag von Andrej

Ich habe dieses Jahr viele Keynotes von AI gesehen. Bei den meisten davon handelt es sich um als Vision getarnte Verkaufspräsentationen von Anbietern. Karpathys war anders. Er hat mir nicht gesagt, was ich verwenden soll – er hat mir einen Rahmen gegeben, mit dem ich jede Codezeile bewerten kann, die ich gerade schreibe. Karpathy Software 3.0 ist kein Produkt. Es ist eine Linse. Und als ich anfing, darin zu stöbern, konnte ich nicht mehr aufhören, überall tote Apps zu sehen.

Das habe ich verarbeitet. Was ich jetzt baue. Was ich nicht bauen möchte. Und den einen Test – den MenuGen-Test – führe ich jetzt bei jedem Projekt aus, bevor ich eine Codezeile schreibe.

Was Karpathy tatsächlich gesagt hat (und warum es gerade jetzt wichtig ist)

Lassen Sie mich zunächst den Rahmen klären, denn die Phrase „Software 3.0“ wurde so oft herumgeworfen, dass sie ihre Schärfe verliert.

In Karpathys Juni 2025 YC AI Startup School Keynote legte er eine dreistufige Geschichte der Software dar:

• Software 1.0 – Code, den Menschen schreiben. Explizite Regeln, deterministische Logik, das gesamte Internet vor 2012. Das, was mir mein CS-Abschluss beigebracht hat.
• Software 2.0 – auf Daten trainierte neuronale Netzwerkgewichte. Das Modell lernt die Funktion, anstatt dass der Ingenieur sie vorgibt. Bildklassifizierer, Empfehlungssysteme, das ganze Jahrzehnt des „maschinellen Lernens“.
• Software 3.0 – große Sprachmodelle als programmierbare Computer. Sie „programmieren“ sie auf Englisch (oder einer anderen Sprache), mit Eingabeaufforderungen, Beispielen, Tools und Kontext. Die Eingabeaufforderung ist der Quellcode. Der LLM ist der Interpreter.

Diese dritte Kategorie hat allen das Gehirn gebrochen. Wir schreiben 1.0 seit fünfzig Jahren und 2.0 seit einem Jahrzehnt. Jetzt gibt es noch eine dritte Sache – und sie lässt sich nicht kompilieren, verfügt nicht über eine Typprüfung und passt in keine unserer vorhandenen IDEs oder mentalen Versionskontrollmodelle.

In seiner Sequoia 2026-Fireside ging Karpathy noch einen Schritt weiter: er markierte den Dezember 2025 als Wendepunkt – der Monat, in dem der von AI generierte Code nicht mehr „hilfreich, aber chaotisch“ war und anfing, durchweg gut genug zu sein, um der Produktion zu vertrauen. Sein eigenes Verhältnis kehrte sich in diesem Monat um. Im November schrieb er etwa 80 % seines Codes von Hand. Im Dezember delegierte er 80 % an agents.

Dasselbe ist mir auch auf meinem eigenen Computer aufgefallen – mir fehlte einfach die Sprache dafür. Ungefähr Mitte Dezember habe ich aufgehört, jeden Claude Code-Diff Zeile für Zeile zu überprüfen. Ich hörte auf, das über Jahre aufgebaute Ritual „Bewegen Sie den Mauszeiger über die Funktion und lesen Sie sie Zeichen für Zeichen“ durchzuführen. Die Unterschiede waren einfach... richtig. Nicht immer perfekt, aber oft genug, dass die Kosten für eine vollständige Überprüfung den Nutzen überstiegen.

Das ist der Moment, in dem sich der Boden bewegt.

Und das sagt niemand klar genug: Der Boden, der sich bewegt, bedeutet nicht, dass die Decke angehoben wurde. Es bedeutet, dass die meisten Apps, die die Leute derzeit entwickeln, nicht mehr existieren müssen.

Das bringt uns zum Test.

Der MenuGen-Test (Mein neuer Pre-Build-Filter)

Das Beispiel von Karpathy war MenuGen – eine von ihm entwickelte App, die ein Foto einer Restaurantkarte machte und Bilder von jedem Gericht renderte, damit Sie sehen konnten, was Sie bestellten. Nützliche Idee. Er hat es verschickt.

Dann geschah das Nano Banana-Update von Gemini. Sie könnten nun das Menüfoto hochladen, „Zeig mir, wie jedes Gericht aussieht“ eingeben und inline das gleiche Ergebnis erhalten. Keine App. Kein Backend. Keine API key-Verwaltung. Kein Vertrieb über den App Store. Nur eine einzige multimodale Eingabeaufforderung.

MenuGen wurde veraltet in dem Moment, in dem ein Frontier-Modell die gleiche Aufgabe nativ erledigen konnte.

Ich führe jetzt für jede Projektidee den so genannten MenuGen-Test durch, bevor ich mich dazu verpflichte:

*„Wenn eine einzelne multimodale LLM-Eingabeaufforderung – GPT-5.4, Claude

Das ist es. Das ist der Filter.

So haben meine drei getöteten Projekte abgeschnitten:

Essensplaner anhand von Lebensmittelfotos. Ein Benutzer lädt ein Foto seines Kühlschrankinhalts hoch → App extrahiert Zutaten → schlägt Rezepte vor. MenuGen Test: Legen Sie ein Kühlschrankfoto in Gemini ab und geben Sie „Gib mir 3 Rezepte, die ich aus dem Sichtbaren machen kann“ ein. Es funktioniert. Eigentlich besser als meine App, denn Gemini kennt sich mit Kochtechniken aus und ich hätte zwei Monate mit einer flockigen Vision-API-Integration verbracht. Getötet.

Sprachnotizen-Zusammenfassung mit Second-Brain-Integration. Sprachnotizen aufzeichnen → transkribieren → zusammenfassen → in einer Hierarchie im Obsidian-Stil ablegen. MenuGen-Test: Claude mit Audioeingang und einem einzelnen MCP-Server, der auf meinen Obsidian-Tresor zeigt. Erledigt. Die „App“ bestand nur aus drei Zeilen Orchestrierungskleber. Getötet.

LinkedIn-Beitrag mit Ihrer Stimme umschreiben. Beitrag einfügen → im Tonstil des Benutzers basierend auf früheren Beiträgen neu schreiben. MenuGen Test: Darüber musste ich nachdenken. Die eigentliche Eingabeaufforderung könnte in einem einzigen LLM-Aufruf erfolgen – frühere Beiträge als Stilbeispiele einspeisen, den neuen Entwurf einfügen, umschreiben lassen. Die Arbeit, die ich baute, war nicht das Umschreiben. Es war die Authentifizierung, die LinkedIn API-Integration, die Terminplanung, der Teamarbeitsbereich, die Analysen. Nichts davon hat der Benutzer tatsächlich verlangt. Sie baten darum, diesen Beitrag mit meiner Stimme umzuschreiben. Getötet.

Beim dritten Punkt tut der Test weh. Denn was ich eigentlich erstellt habe, war ein SaaS-Wrapper um eine 12-zeilige Eingabeaufforderung. Und ich hätte es verschickt. Ich hätte dafür eine Gebühr erhoben. Und sechs Monate später, als ChatGPT oder Claude die Funktion „Meinen Schreibstil aus einem verbundenen Dokument anpassen“ hinzufügten, wäre mein SaaS zusammen mit etwa 4.000 anderen „AI X für Y“-Wrappern über Nacht gestorben.

Der MenuGen-Test ist kein Pessimismus. Es ist ein Überlebensfilter. Wenn Ihr Produkt durch eine einzige Eingabeaufforderung repliziert werden kann, erstellen Sie keine Software, sondern eine Funktion für das Produkt eines anderen.

Das bedeutet nicht, dass nichts gebaut werden sollte. Das bedeutet, dass wir verschiedene Dinge bauen müssen.

Darum geht es im Rest davon.

Was Vibe Coding richtig gemacht hat (und warum Karpathy es begraben hat)

Bevor wir dazu kommen, was wir bauen sollen, müssen wir über die Workflow-Veränderung sprechen – denn die meisten Leute, die ich kenne, sind immer noch vibe coding, und Karpathy hat es gerade zu einer Aktivität der Juniorenklasse erklärt.

Vibe-Codierung, um fair zu sein, habe ich vieles richtig gemacht. Es hat den Boden erhöht. Jeder mit Geschmack und Geduld kann jetzt funktionierende Apps versenden. Ich habe beobachtet, wie Nicht-Ingenieure an einem einzigen Wochenende Shopify-Shop-Integrationen, interne Team-Dashboards und persönliche Tools auslieferten. Diese Bodenerhöhung ist real. Es ist nicht verschwunden.

Aber das Argument von Karpathy im Jahr 2026 ist, dass vibe coding eine Obergrenze hat – und diese ist niedrig. Sie können per Vibe-Code einen funktionierenden Prototyp erstellen. Sie können einen Vibe-Code für eine Version 1 erstellen, die sich gut demonstrieren lässt. Sie können Vibe-Code nicht auf Produktionszuverlässigkeit umstellen. Sie können keinen Vibe-Code durch eine Sicherheitsüberprüfung durchführen. Sie können eine Integration, die 10.000 gleichzeitige Benutzer mit eventuellen Konsistenzanforderungen über drei Datenbanken hinweg verwaltet, nicht per Vibe-Code programmieren.

Hier kommt agentic Engineering ins Spiel. Die Disziplin, die er jetzt vorantreibt, hat eine bestimmte Form:

• Spezifikationen vor dem Code. Schreiben Sie, was das System tun soll, nicht nur, wie es aussehen soll. (Mein OpenSpec-Beitrag deckt die Version davon ab, die ich tatsächlich täglich verwende.)
• Pläne vor Änderungen. Lassen Sie den agent Änderungen vorschlagen, bevor er sie vornimmt. Überprüfen Sie den Plan. Dann ausführen. - Testet als primäres Signal. Keine Vibrationen. Nicht „sieht richtig aus“. Tests durch Nichtbestehen und dann Bestehen als Beweis dafür, dass etwas funktioniert. - CI-Schleifen bei jeder Änderung. Lint, Test, Typprüfung, Sicherheitsscan – automatisiert, bei jedem Commit, keine Ausnahmen. - Diff-Inspektion. Lesen Sie, was der agent geändert hat, bevor Sie ihn akzeptieren. Insbesondere für alles, was mit Authentifizierung, Abrechnung oder Benutzerdaten zu tun hat. - Berechtigungsisolation. Geben Sie auf Ihrem Computer keinen agent-Root an.

Verwenden Sie git worktrees für paralleles Arbeiten. Sandboxen Sie, was Sie können.

Wenn Ihnen diese Liste bekannt vorkommt, liegt das daran, dass es sich einfach um ... Software-Engineering handelt. Das, was leitende Ingenieure schon immer gemacht haben. Die Version der Praxis, die ein Jahrzehnt des „Bewegen Sie sich schnell und machen Sie Dinge kaputt“ überlebte. Karpathy sagt im Wesentlichen: AI hat die Ingenieursdisziplin nicht getötet. Dadurch wurde die Ingenieursdisziplin wichtiger, denn jetzt ist Ihr Mitarbeiter ein gewandter, aber nicht sorgfältiger Junior, der Ihr Urteilsvermögen und nicht Ihre Tippgeschwindigkeit benötigt.

Die Verschiebung im Jahr 2026 lautet nicht „AI ersetzt Ingenieure“. Es heißt: „Ingenieure, die AI beaufsichtigen können, ersetzen Ingenieure, die nur Code eingeben.“

Eines sage ich jetzt jedem Entwickler, mit dem ich zusammenarbeite: Der Wert Ihres Urteils ist gerade gestiegen. Der Wert Ihrer Schreibmaschinen ist gesunken. Wenn Sie immer noch Schreibmaschinen verkaufen, sind Sie bereits veraltet. Wenn Sie bei hoher Signalstärke spezifizieren, planen, bewerten und überprüfen können, haben Sie gerade einen 10-fachen Hebelmultiplikator erhalten.

Und kritisch: Karpathy machte eine warnende Bemerkung, die fast jeder beschönigt.

Die „10 Agenten“-Falle (Wo ich verbrannt wurde)

Im Moment kursiert ein Meme: „Ich habe 20 Claude Code agents parallel laufen, hier ist mein Workflow.“ Karpathy schaute sich das an und sagte im Wesentlichen: nicht.

Seine Begründung: Die meisten Entwickler, die versuchen, 10 bis 20 gleichzeitige agents zu orchestrieren, übertreffen das, was aktuelle Modelle zuverlässig unterstützen können. Die Aufsichtsbelastung wächst nichtlinear. Wenn Sie 15 agents verwalten, verbringen Sie Ihre ganze Zeit als mittlerer Manager, der den Kontext wechselt, und produzieren schlechtere Ergebnisse als ein einzelner agent unter sorgfältiger Aufsicht.

Das habe ich auf die harte Tour gelernt. Vor zwei Monaten habe ich versucht, eine vollständig parallele Content-Generierungspipeline einzurichten: einen agent für die Recherche, einen für Gliederungen, einen für Entwürfe, einen für die Bearbeitung, einen für SEO-Prüfungen und einen für die Verteilungskopie. Sechs agents. Alles läuft gleichzeitig. Alles „autonom“.

Was tatsächlich geschah: Jeder agent produzierte Arbeit, der nächste agent konnte ihn nicht ganz nutzen, da keiner von ihnen über den vollständigen Kontext verfügte. Die Recherche agent brachte Fakten ans Licht, deren Umriss agent nicht zu gewichten wusste. Der von agent erfundene Entwurf wurde vom Herausgeber agent umrahmt und dann zur Hälfte umgeschrieben. Der SEO agent hat Schlüsselwörter in Prosa gestopft, die der Redakteur bereits ausgefeilt hatte. Als der Inhalt mich erreichte, verbrachte ich mehr Zeit damit, sechs agents'-Ausgaben abzugleichen, als ich das Ganze mit einem Aria-artigen agent unter strenger Kontextkontrolle verbracht hätte.

Ich habe die Pipeline zerstört. Jetzt führe ich einen agent nach dem anderen aus, umfassend und mit umfassendem Kontext – genau der Kontext-über-Konfigurations-Ansatz, über den ich Anfang des Jahres geschrieben habe. Die Arbeit wird schneller versendet. Die Qualität ist höher. Die kognitive Belastung für mich ist geringer.

Die Warnung von Karpathy passt perfekt zu dem, was ich beobachtet habe: weniger agents, sorgfältig verwaltet, mit Überprüfungsschleifen, übertrifft mehr agents, die locker verwaltet werden. Bis die Modelle bei der multi-agent-Koordination wesentlich besser werden – was zwar der Fall sein wird, aber noch nicht so weit ist – besteht der richtige Schritt darin, die Single-agent-Schleife zu optimieren.

Dies ist einer dieser Momente, in denen der Social-Media-Diskurs und die tatsächliche Erfahrung des Praktikers stark voneinander abweichen. Twitter möchte, dass Sie glauben, die Zukunft sei 50 agents im Schwarm. Karpathy – der mehr Kontext zu Modellfähigkeiten hat als praktisch jeder andere auf dem Planeten – sagt: Noch nicht. Nicht für die meisten Bauherren. Nicht im Jahr 2026.

Ich vertraue ihm mehr als Twitter. Das solltest du auch.

Die vier Dinge, die es wert sind, jetzt aufgebaut zu werden

Okay. Daher sollten die meisten Apps nicht existieren. Vibe-Coding ist das Aufwärmen. Die Multi-agent-Orchestrierung ist verfrüht. Was lohnt sich eigentlich zu bauen?

Karpathy nannte in seinem Sequoia-Vortrag vier Säulen. Jeder von ihnen besteht den MenuGen-Test, weil jeder zu dem, was Frontier-Modelle nativ tun, additiv ist – und kein Wrapper um das, was sie bereits tun.

1. Werkzeuge, die das Verständnis schärfen (nicht nur die Geschwindigkeit)

Die erste Welle von AI-Tools verkaufte Geschwindigkeit. Schnellerer Code. Schnellere E-Mails. Schnellere Designs. Dieses Rennen ist weitgehend vorbei – jedes Modell von jedem Anbieter ist jetzt schnell genug.

Die nächste Welle verkauft strategische Klarheit. Tools, die Ihnen helfen, besser zu denken, besser zu entscheiden, klarer zu sehen und Fehler zu vermeiden, die Sie selbst nicht bemerkt hätten.

Das Muster: Anstelle von „Ich schreibe das für Sie“ heißt es „Lass mich dir zeigen, was dir fehlt.“ Anstatt eine Ausgabe zu generieren, zeigt das Tool die Fragen auf, die Sie nicht gestellt haben, die Annahmen, die Sie implizit treffen, die Entscheidungen, die sich in etwas verbergen, das wie eine einzige Wahl aussieht.

Ich baue gerade genau ein solches Tool für meinen eigenen Content-Workflow. Aria – der agent, der für mein Markennetzwerk schreibt – produziert nicht nur Beiträge. Es führt für jeden Entwurf eine Selbstbewertungsrubrik durch, bewertet zehn Retentionsdimensionen und verweigert den Versand, bis die Rubrik bestanden ist. Die Ausgabe ist nicht schneller. Es ist klarer, weil der agent die Schwachstellen aufdeckt, bevor ich es muss.

Das ist das Muster. Nicht „Ich werde es für dich tun.“ Aber „Ich zeige dir, was du nicht sehen konntest, und lasse dich entscheiden.“

Wenn Sie im Jahr 2026 bauen, fragen Sie sich: Verkaufe ich Geschwindigkeit oder verkaufe ich Klarheit? Geschwindigkeit ist eine Ware. Klarheit ist ein Graben.

2. Agent-First-Infrastruktur

Hier wird es lustig. Wir haben dreißig Jahre damit verbracht, Software für Menschen zu entwickeln – Tastaturen, Mäuse, Bildschirme, GUIs. Jeder API verfügt über ein „Entwickler-Dashboard“. Jedes Produkt hat einen Onboarding-Ablauf. Jede Datenbank verfügt über eine Benutzeroberfläche zum Erstellen von Abfragen.

Jetzt sind agents die Kunden. Und agents möchte keine Benutzeroberflächen. Sie wollen APIs. Sie wollen saubere Metadaten. Sie wollen maschinenlesbare Schemata. Sie wollen vorhersehbare Fehlerreaktionen, die sie beheben können. Sie wollen eine strukturierte und nicht prosalastige Dokumentation.

Der Wandel ist enorm und die meisten Produktteams haben ihn noch nicht verinnerlicht. Wenn Ihr Produkt von einem AI agent im Namen eines Benutzers verwendet werden soll, ist jedes UI-Element ein Reibungspunkt. Jedes „Zum Bestätigen hier klicken“ ist ein Ort, an dem der agent eine Brücke zwischen Maschinenabsicht und Mensch-Form-Schnittstelle schlagen muss.

Die konkreten Schritte, die Sie jetzt unternehmen müssen:

• Versenden Sie eine llms.txt-Datei. Die Akzeptanz beträgt ungefähr 10 % ab Anfang 2026. Die Belege für den Anstieg der Zitate sind gemischt. Die Implementierung dauert jedoch ein bis vier Stunden und es gibt keine Nachteile, wenn die Spezifikation am Ende allgemein übernommen wird. Es ist eine kostengünstige Option für eine Zukunft mit großen Auswirkungen. - Stellen Sie eine Markdown-Variante jeder Seite bereit. Agentische Crawler – GPTBot, ClaudeBot, PerplexityBot – bevorzugen konsequent Markdown gegenüber HTML, wenn beide angeboten werden. Dies ist real, beobachtet und spiegelt sich bereits in den Zitationsraten wider. - Dokumentieren Sie Ihre APIs so, wie Sie sie für einen LLM dokumentieren würden. Klare Eingaben, klare Ausgaben, idempotente Operationen, vorhersehbare Fehler. Überspringen Sie die Marketing-Prosa. Ein LLM muss nicht verkauft werden; es muss erzählt werden.

• Versenden Sie MCP servers für Ihr Produkt. Wenn Ihr Tool aus Claude Code, (Meine Meinung zu den unverzichtbaren MCPs deckt ab, was tatsächlich funktioniert.)

• Behandeln Sie agents als erstklassige Benutzer. Kein Seitenkanal für Power-Benutzer. Kein „zukünftiges Roadmap-Element“. Behandeln Sie die agent-Persona genauso, wie Sie heute die mobile Persona behandeln.

Die Unternehmen, die dies frühzeitig richtig machen, werden im Nachhinein offensichtlich aussehen. Diejenigen, die weiterhin Benutzeroberflächen für menschliche Klicks optimieren, während ihre Konkurrenten still und leise AI-agent-nativ werden, werden sich fragen, warum ihr Wachstum stagniert.

3. Verifizierbare Domain-Apps (wo RL einen Burggraben hat)

Dies ist die tiefste Säule und die am wenigsten verstandene. Karpathy argumentierte, dass die wirklich zu verteidigenden Gräben im nächsten Jahrzehnt nicht in reinen Sprachaufgaben liegen werden – diese werden schnell zur Ware. Sie befinden sich in überprüfbaren Bereichen: Bereichen, in denen Sie mechanisch überprüfen können, ob die Ausgabe des Modells korrekt ist.

Code ist das Offensichtliche. Sie können Tests durchführen. Sie können fusseln. Sie können eine Typprüfung durchführen. Sie können einsetzen und beobachten. Jedes davon ist ein Rückkopplungssignal, das es dem Modell durch Verstärkungslernen ermöglicht, den Code im Laufe der Zeit wirklich zu verbessern.

Aber Code ist nicht die einzige überprüfbare Domäne. Schauen Sie sich die Liste an:

• Algorithmischer Handel. P&L ist ein überprüfbares Signal. Backtests sind reproduzierbar. Der Markt ist brutal, aber quantifizierbar.
• Lieferkette. Lagerbestände, Lieferzeiten, Kosten pro Einheit – alles messbar, alles überprüfbar, alles zugänglich für eine RL-Feinabstimmung.
• Datenbereinigung und ETL. Schemakorrektheit, Typvalidierung, referenzielle Integrität – diese sind überprüfbar. Das Modell kann gegen Ground-Truth-Pipelines trainiert werden.
• Compliance und Audit. Regulatorische Anforderungen sind Regeln. Entweder entsprechen die Daten ihnen oder nicht. Das ist ein Bestätigungssignal.
• Wissenschaftliche Simulation. Physik, Chemie, Materialwissenschaften – überall dort, wo Sie ein Referenzmodell haben, das Vorhersagen validieren kann.

Wenn Sie in einer Domäne bauen, in der die Korrektheit überprüfbar ist, haben Sie einen echten Burggraben. Denn die Daten, die Sie aus der Produktion sammeln, werden zu Trainingsdaten, die Ihr spezifisches Modell für Ihre spezifische Aufgabe besser machen – und Ihre Konkurrenten, die Vanilla GPT-5.4 mit einem cleveren Prompt aufrufen, werden an der gleichen Stelle ein Plateau erreichen wie alle anderen Vanilla-Prompt-Konkurrenten.

Wenn Sie in einem Bereich bauen, in dem die Korrektheit nicht überprüfbar ist – reine kreative Aufgaben, Entscheidungen, die sich richtig anfühlen, weiche Urteilssprüche – ist der Burggraben viel schwächer. Das Grenzmodell wird Ihre schnelle Entwicklung irgendwann und wahrscheinlich bald einholen.

Dies ist die wichtigste strategische Erkenntnis aus dem Vortrag von Karpathy, und fast niemand wiederholt sie. Überprüfbarkeit ist der Burggraben. Wenn Ihr Produkt ein messbares Korrektheitssignal aufweist, können Sie eine Verbindung herstellen. Wenn nicht, sind Sie ein Wrapper.

4. Software 3.0-Native Apps (keine schnelleren Tabellenkalkulationen)

Die vierte Säule ist die schwierigste, weil sie Fantasie und nicht nur Technik erfordert.

Die meisten „AI-Funktionen“, die im Jahr 2026 ausgeliefert werden, sind Software 1.0-Apps mit einem AI-Anbauteil. Tabellenkalkulation mit einer Seitenleiste, die Formeln erklärt. E-Mail-Client mit der Schaltfläche „Diesen Thread zusammenfassen“. Projekt-Tracker mit dem Befehl „Mein Standup-Update entwerfen“.

Diese sind nützlich. Sie sind nicht Software 3.0.

Eine Software 3.0-native-App ist eine App, die nicht hätte existieren können, bevor LLMs das Substrat waren. Es geht von LLM aus, so wie eine 1.0-App von einer CPU ausgeht. Das Modell ist keine Funktion innerhalb der App – das Modell ist die Laufzeit, auf der die App ausgeführt wird.

Schauen Sie sich den Vibe App Builder von monday.com an. Denken Sie darüber nach, was es eigentlich ist: ein System, bei dem ein Nicht-Entwickler eine App in natürlicher Sprache beschreibt und die Plattform ein funktionierendes internes Tool generiert – Benutzeroberfläche, Datenverbindungen, Berechtigungen, das funktioniert. monday hat allein im ersten Quartal 2026 mehr als 19 Funktionen und 26 A/B-Tests für Vibe Apps ausgeliefert. Das Skalierungstempo verrät Ihnen, dass sie etwas Echtes gefunden haben.

Das Interessante daran ist nicht, dass es Apps generiert. Das Interaktionsmodell unterscheidet sich grundlegend von den No-Code-Tools der Vergangenheit. Es gibt kein Drag-and-Drop. Es gibt kein visuelles Flussdiagramm. Der Benutzer beschreibt auf Englisch, was er möchte, der LLM schlägt eine funktionierende App vor, der Benutzer verfeinert dies per Chat. Die App existiert nicht als statischer Code, sondern als lebendige Konversation zwischen Absicht und Ausführung.

Das ist Software 3.0-native. Die englische Beschreibung ist der Quellcode. Der LLM ist der Compiler. Die App ist die ausführbare Datei.

Wenn Sie gerade mit der Entwicklung beginnen, besteht die größte Wirkung darin, sich zu fragen: Was wird möglich, wenn LLM das Substrat und kein Feature ist? Nicht „Wie füge ich AI zu meiner App hinzu“ – sondern „Welche App könnte nur existieren, weil LLMs existieren?“

Beispiele, die ich genau beobachte:

• Persönliche Kontext-Engines – Apps, die Ihre spezifischen Muster tief genug lernen, um Arbeitstools zu generieren, die auf Sie und nicht auf „Benutzer“ zugeschnitten sind. Die frühe Version davon finden Sie unter Karpathys eigener CLAUDE.md-Kompetenzansatz.
• Ephemere Apps – Anwendungen, die für einen Workflow vorhanden sind und sich danach auflösen. Keine Installation, keine Anmeldung. Das Modell aktiviert sie als Reaktion auf einen Bedarf.
• Von Agenten verwaltete Dienste – Produkte, bei denen die gesamte kundenorientierte Ebene ein agent und keine Benutzeroberfläche ist und das „Produkt“ die Argumentationsschleife des agent ist.
• Kontinuierliche Spezifikationssysteme – Software, bei der sich die Spezifikation neben dem Code befindet und Änderungen automatisch durch beide Ebenen weitergegeben werden. (Traycer's Bart mode ist ein kleiner Einblick hiervon.)

Das ist keine Science-Fiction. Sie werden gerade in kleinen Stückzahlen von Entwicklern erstellt, die die Falle „Lass mich eine AI-Funktion zu meinem SaaS hinzufügen“ übersprungen haben.

Wie ich meine eigene Arbeit umstrukturiere

Genug der Theorie. Hier ist, was ich tatsächlich an meinem Arbeitsablauf geändert habe, nachdem ich eine Woche lang mit dem Vortrag gesessen habe.

Erstens. Ich habe drei Nebenprojekte gelöscht und meiner Projektaufnahmevorlage eine MenuGen test-Checkliste hinzugefügt. Jede neue Idee muss nun die Frage beantworten: Kann ein einzelner multimodaler Prompt 80 % davon leisten? Wenn ja, wird sie nicht umgesetzt. Es wird als Eingabeaufforderung in meinem Claude Skills-Ordner gespeichert.

Zwei. Ich habe mein agent-Setup von parallel-experimentell auf einfach-agent-tief umgestellt. Ich habe eine Content-Pipeline mit sechs agent-Inhalten verworfen und bin wieder dazu übergegangen, jeweils eine Aria-Instanz auszuführen, mit umfassendem Kontext, sorgfältiger Überwachung und engen Überprüfungsschleifen. Die Ausgabequalität stieg sofort. Der Beitrag, den Sie gerade lesen, wurde auf diese Weise erstellt.

Drei. Ich habe einen llms.txt zu mejba.me, ramlit.com, colorpark.io und xcybersecurity.io hinzugefügt. Hat für alle vier vielleicht 90 Minuten gedauert. Die Akzeptanz ist mäßig, die Zitationsnachweise sind gemischt, aber die Kosten für das Überspringen sind hoch, wenn die AI-Suche weiterhin so wächst, wie sie es bisher getan hat. Günstige Option.

Vier. Ich begann, jedes aktive Projekt anhand der vier Säulen zu prüfen. Wenn ein Projekt nicht zu einem dieser Kriterien passt – Clarity Tool, Bisher wurde ein weiteres Projekt eingestellt und zwei wurden umstrukturiert.

Fünf. Ich investiere aggressiv in die disziplinäre Seite der AI-Entwicklung – Spezifikationen, Pläne, Rezensionen, Tests – und lege weniger Wert auf Tippgeschwindigkeit, Eingabeaufforderungen und das Sammeln von Werkzeugen. Die Hebelwirkung liegt jetzt im Urteil. Ich handle entsprechend.

Sechs. Ich warte auf den nächsten Tonfall. Karpathy hatte im Dezember 2025 Recht. Die nächste große Veränderung – wenn 20 agents parallel ausgeführt werden, funktioniert tatsächlich, wenn Modelle sich zuverlässig selbst spezifizieren können, wenn RL in überprüfbaren Domänen echte übermenschliche Fähigkeiten in einer Nische hervorbringt – kommt. Ich möchte in der Lage sein, es innerhalb einer Woche zu erkennen, nicht innerhalb eines Vierteljahres. Das bedeutet, nah am Praktiker-Rand zu bleiben, nicht am Keynote-Rand.

Die eine Sache, mit der es sich zu sitzen lohnt

Wenn Sie etwas aus dem Vortrag von Karpathy und aus diesem ganzen Beitrag mitnehmen, dann nehmen Sie Folgendes:

Der Job besteht nicht darin, Software zu entwickeln. Die Aufgabe besteht darin, die Dinge zu entwickeln, die Software heute möglich macht.

Dreißig Jahre lang war „Software erstellen“ das Ziel, weil Software die Einschränkung darstellte. Sie brauchten eine App, weil Sie die Sache ohne sie nicht erledigen konnten. Die App war der Flaschenhals.

Software ist nicht länger der Flaschenhals. Der LLM-as-runtime ist der Engpass – und der Engpass bewegt sich schneller, als es ein einzelnes Produktteam kann. Daher ist die Entwicklung einer „App“ innerhalb einer Kategorie, die auf der Modellebene bereits zur Ware geworden ist, ein verlorenes Spiel. Sie versenden und drei Monate später wird das Modell Sie übernehmen.

Das Gewinnerspiel besteht darin, für das Modell, auf dem Modell oder in Bereichen zu bauen, in denen das Modell allein nicht gewinnen kann. Klarheitswerkzeuge. Agent-First-Infrastruktur. Überprüfbare Fachkompetenz. Software 3.0-native Erfahrungen. Das sind die vier Wetten, die in fünf Jahren offensichtlich erscheinen.

Alles andere – einschließlich der meisten Projekte, die ich letzte Woche in meiner IDE geöffnet hatte – war MenuGen. Und MenuGen ist jetzt eine Funktion, kein Produkt.

Schauen Sie sich heute Abend Ihren ~/projects/-Ordner an. Führen Sie den Test für jeden einzelnen von ihnen durch. Seien Sie ehrlich. Die meisten von uns bauen ihre Anlagen auf der Grundlage von Funktionen auf, die bereits im Modell vorhanden sind. Einige von uns bauen etwas, das nur existiert, weil das Modell existiert.

Der Unterschied zwischen diesen beiden ist der Unterschied zwischen einem Nebenprojekt und einem karrierebestimmenden Projekt. Karpathy hat uns gerade den Test gegeben, um sie voneinander zu unterscheiden. Der Rest liegt bei uns.

Was hast du diese Woche getötet?

Häufig gestellte Fragen

Was ist Karpathy's Software 3.0 im Klartext?

Software 3.0 ist, wenn LLMs zur Laufzeit und natürliche Sprache zum Quellcode werden. Software 1.0 war handgeschriebener Code. Mit Software 2.0 wurden neuronale Netzwerkgewichte trainiert. Software 3.0 fordert einen LLM auf, der Ihre Absicht interpretiert und ausführt. Das vollständige mentale Modell finden Sie im Eröffnungsabschnitt oben.

Ist vibe coding im Jahr 2026 tot?

Nein – vibe coding funktioniert weiterhin für Prototypen, Wochenendprojekte und Bodenerhöhungen für Nicht-Ingenieure. Was Karpathy zurückzog, war vibe coding als Produktions-Ansatz. Für auslieferbare Software ist agentic-Engineering – Spezifikationen, Pläne, Tests, CI und Diff-Überprüfung – mittlerweile der Standard. Siehe oben „Was Vibe Coding richtig gemacht hat“.

Was ist der MenuGen-Test?

Der MenuGen-Test fragt: Wenn eine einzelne multimodale LLM-Eingabeaufforderung 80 % der Aufgaben Ihrer App erledigen kann, sollte die App nicht als eigenständiges Produkt existieren. Es stammt aus dem Beispiel MenuGen von

Soll ich im Jahr 2026 ein multi-agent-System bauen?

Wahrscheinlich noch nicht. Karpathy warnt ausdrücklich davor, 10–20 agents gleichzeitig auszuführen – aktuelle Modelle koordinieren nicht so gut und die Überwachungslast zerstört die Qualität. Ein agent unter sorgfältiger Aufsicht schlägt sechs lose verwaltete. Besuchen Sie dies in 6–12 Monaten noch einmal.

Was ist die agent-first-Infrastruktur?

Agent-First-Infrastruktur ist eine Software, die für AI agents als Hauptbenutzer entwickelt wurde – saubere APIs, maschinenlesbare Metadaten, Der Wandel geht dahin, agents als erstklassige Persona und nicht als Nebenkanal zu behandeln. Konkrete Umzüge finden Sie oben in Säule 2.

Lasst uns zusammenarbeiten

Möchten Sie AI-Systeme aufbauen, Arbeitsabläufe automatisieren oder Ihre technische Infrastruktur skalieren? Ich würde gerne helfen.

• Fiverr (benutzerdefinierte Builds und Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Unternehmenslösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io