Software 3.0 — Was Karpathys Thesen für Interface Design bedeuten

Wesentliche Insights

1 — Software 3.0 ist kein Backend-Thema

Karpathys Kernthese: Software durchläuft drei Paradigmen — Code (1.0), Weights (2.0, neuronale Netze), Prompts (3.0, natürliche Sprache). Software 3.0 frisst 1.0 und 2.0. Was auf den ersten Blick nach Architekturverschiebung klingt, hat direkte Interface-Konsequenzen: Wenn das Programmierparadigma sich ändert, ändern sich die Interaktionsmuster. Ein Produkt, dessen Logik in natürlicher Sprache spezifiziert wird, braucht andere Oberflächen als eines, dessen Logik in Code lebt. Die Frage ist nicht mehr nur “Wie sieht das UI aus?”, sondern “Wie kommuniziert der Nutzer mit einer Laufzeitumgebung, die Sprache versteht?“

2 — Partial Autonomy statt binärer Automatisierung

Das stärkste Design-Pattern des Talks: Autonomy Sliders. Karpathys Analogie ist der Iron-Man-Suit — AI soll gleichzeitig Augmentation und Autonomie bieten, kontextabhängig steuerbar. Die Beispiele sind konkret: Cursor skaliert von Tab-Completion (minimal) über cmd+K (inline) zu cmd+L (Chat) bis cmd+I (Agent). Perplexity von Search über Research zu Deep Research. Tesla Autopilot von Level 1 bis 4.

Das Prinzip dahinter: Delegation ist kein Schalter, sondern ein Regler. Nutzer brauchen die Möglichkeit, Automatisierungsgrade kontextabhängig zu justieren. Für Interface Designer bedeutet das: Jede AI-Interaktion braucht ein Modell für graduell steuerbare Kontrolle — nicht nur “an” oder “aus”.

3 — Die dritte Consumer-Klasse

Bisher gab es zwei Arten von Interface-Nutzern: Menschen (GUIs) und Computer (APIs). Karpathy beschreibt eine dritte Klasse: Agents — menschenähnliches Verhalten, computerartige Ausführung. Das ist kein theoretisches Konstrukt. Agents brauchen eigene Interfaces, weil sie weder mit GUIs noch mit klassischen APIs optimal arbeiten. HTML ist für LLMs schlecht parsbar. Formate wie llms.txt und Tools wie Gitingest oder DeepWiki sind erste Antworten auf ein neues Designproblem: Informationen so strukturieren, dass Agents sie effizient konsumieren können.

Für Product Designer verschiebt sich die Aufgabe: Nicht mehr nur “Wie sieht das für den Nutzer aus?”, sondern zusätzlich “Wie liest ein Agent das?“

4 — Jagged Intelligence als UX-Problem

LLMs zeigen eine unintuitive Fähigkeitsverteilung — sie lösen komplexe mathematische Beweise, scheitern aber an der Frage, ob 9.11 größer ist als 9.9. Karpathy nennt das “Jagged Intelligence”. Im Unterschied zur menschlichen Entwicklung, wo Fähigkeiten korreliert wachsen, sind LLM-Fähigkeiten unvorhersagbar verteilt.

Das ist ein fundamentales Interface-Problem: Vertrauen muss kontextabhängig kalibriert werden. Ein Nutzer, der erlebt, dass die AI eine anspruchsvolle Aufgabe brillant löst, erwartet zu Recht, dass sie auch einfachere Aufgaben beherrscht. Das tut sie aber nicht zuverlässig. Trust-Patterns — visuelle und interaktive Signale, die dem Nutzer helfen, die Zuverlässigkeit der AI einzuschätzen — werden zu einer zentralen UX-Aufgabe.

5 — Demo vs. Produkt: Die ehrliche Lücke

“Demo is works.any(), product is works.all().” Karpathys schärfste Aussage. Untermauert mit der Waymo-Anekdote: 2014 funktionierte der Prototyp mit null Interventionen — trotzdem brauchte es 10+ Jahre bis zur Produktionsreife.

Für Interface-Designer ist das ein Korrektiv: Beeindruckende AI-Demos beweisen keine Produkttauglichkeit. Das Design muss die Lücke zwischen “funktioniert manchmal brillant” und “funktioniert immer zuverlässig” bewusst gestalten — durch Fallbacks, Verification-Loops und transparente Unsicherheitskommunikation.

6 — Vibe Coding: Ehrlicher Reality Check

Karpathy räumt ein, dass die anfänglichen AI-Speedups beim Entwickeln nach der lokalen Einrichtung verschwinden. Web-Entwicklung 2025 sei ein “disjoint mess of services designed for webdev experts to keep jobs, not accessible to AI.” Die Qualität der Dokumentation entscheidet, ob AI-Agents mit einem Tool arbeiten können oder nicht.

Für die Interface- und Tooling-Welt heißt das: Agentenfreundlichkeit wird zum Qualitätsmerkmal. Produkte, deren Dokumentation und Schnittstellen für AI-Consumption optimiert sind, werden von Vibe Codern und Agents bevorzugt. Wer das ignoriert, schließt eine wachsende Nutzerklasse aus.

Einordnung

Dieser Text liest Karpathys Thesen aus der Perspektive eines Product Designers, der Interface-Konsequenzen aus Technologieshifts ableitet — nicht aus der eines ML-Engineers oder Softwarearchitekten. Das schärft den Blick für Interaktionsmuster und Autonomiegrade, aber es fehlt die Tiefe in der technischen Bewertung der Architekturbehauptungen. Ein Infrastruktur-Engineer würde stärker auf die Machbarkeit der Drei-Consumer-Klassen-These eingehen; ein Kognitionspsychologe würde Jagged Intelligence nicht als UX-Problem, sondern als Wahrnehmungsproblem rahmen.

Kritische Einordnung

Was hält stand

• Autonomy Sliders als Designmuster sind durch bestehende Produkte validiert (Cursor, Perplexity, Tesla) — nicht nur Theorie
• Die Drei-Consumer-Klassen-These (Humans, Computers, Agents) beschreibt eine reale Verschiebung, die bereits in der Entwicklung von llms.txt, Context Buildern und Agent-first APIs sichtbar ist
• Jagged Intelligence ist empirisch gut dokumentiert und erklärt, warum AI-Interfaces andere Trust-Patterns brauchen als traditionelle Software
• Der Demo-Product Gap ist eines der konsistentesten Muster in der Technologiegeschichte — Waymo ist nur das jüngste Beispiel

Was man einordnen muss

• Silicon-Valley-Linse: Karpathys Beispiele kommen ausschließlich aus dem US-Tech-Kontext (Cursor, Perplexity, Tesla, Waymo). Ob die Patterns auf regulierte Branchen (Govtech, Gesundheit, Industrie) übertragbar sind, bleibt offen
• Fehlende Nutzerforschung: Die Thesen sind konzeptuell stark, aber nicht empirisch mit Nutzerverhalten unterfüttert. Ob “Autonomy Sliders” in der Praxis verstanden und genutzt werden, ist eine offene Frage
• Kein Design-Praktiker: Karpathy denkt von der Technologie zum Interface, nicht umgekehrt. Die Frage “Was brauchen Nutzer?” kommt erst nach “Was kann das System?”
• Vibe Coding als Maßstab: Die Web-Dev-Kritik (“disjoint mess”) ist anekdotisch und spiegelt die Perspektive eines AI-Researchers, nicht eines Design Engineers

Diskussionsfragen

01 Autonomy Sliders in der Praxis: Wie würde ein Autonomy-Slider-Pattern in einem Govtech-Kontext aussehen, wo Entscheidungstransparenz und Nachvollziehbarkeit Pflicht sind? Ist graduell steuerbare Autonomie mit den Anforderungen öffentlicher Verwaltung vereinbar?

02 Agent-first Design: Wenn Agents zur dritten Consumer-Klasse werden — was bedeutet das konkret für Design-Systeme in der Praxis? Brauchen wir parallele Interface-Layer (GUI + Agent-optimiert), oder konvergieren die Formate?

03 Trust-Patterns bei Jagged Intelligence: Wie gestaltet man Vertrauen in ein System, dessen Fähigkeiten unvorhersagbar verteilt sind? Gibt es Patterns jenseits von Confidence Scores und Disclaimern?

04 Demo-Product Gap als Designaufgabe: Wenn die Lücke zwischen Demo und Produkt bei AI-Systemen größer ist als bei traditioneller Software — welche Rolle spielt Interface Design, um diese Lücke zu überbrücken? Ist das eine UX-Aufgabe oder eine Architektur-Aufgabe?

05 Agentenfreundlichkeit als Qualitätsmerkmal: Sollten wir bei der Dokumentation und den Schnittstellen unserer eigenen Produkte “Agent Readiness” als Qualitätskriterium einführen?

Quellen

• Original: Andrej Karpathy — Software 3.0 (Latent Space)
• Karpathy — Software 2.0 (Medium, 2017)
• llms.txt — Proposed Standard for LLM-readable Documentation
• Ethan Mollick — Jagged Intelligence (One Useful Thing)

Glossar

Software 3.0 Karpathys Begriff für das dritte Software-Paradigma: natürliche Sprache als Programmiersprache. Prompts ersetzen Code (1.0) und trainierte Weights (2.0) als primäre Programmierschnittstelle.

Autonomy Slider Design-Pattern, bei dem Nutzer den Automatisierungsgrad einer AI-Interaktion kontextabhängig steuern können — von minimaler Unterstützung bis zu voller Delegation.

Jagged Intelligence Phänomen, bei dem LLMs unintuitive Fähigkeitsverteilungen zeigen: brillant bei komplexen Aufgaben, unzuverlässig bei scheinbar einfachen. Im Gegensatz zu menschlicher Kompetenzentwicklung, wo Fähigkeiten korreliert wachsen.

Agents (als Consumer-Klasse) Softwaresysteme, die autonom handeln, LLM-gesteuert navigieren und Aufgaben ausführen. Unterscheiden sich von menschlichen Nutzern (GUIs) und klassischen Computerprogrammen (APIs) durch menschenähnliches Verhalten bei computerartiger Ausführungsgeschwindigkeit.

Context Builder Tools wie Gitingest oder DeepWiki, die Informationen so aufbereiten, dass LLMs und Agents sie effizient verarbeiten können. Adressieren das Problem, dass bestehende Web-Formate (HTML) für AI-Consumption schlecht geeignet sind.