Von Mikro-Aktionen zu Makro-Aktionen.
Warum sich die Arbeitseinheit verschoben hat.
Andrej Karpathy hat seit Dezember 2025 keine einzige Zeile Code mehr selbst geschrieben. Nicht aus Faulheit – sondern weil sich die Arbeitseinheit verschoben hat: Weg von der einzelnen Codezeile, hin zur ganzen Funktionalität. Von Mikro-Aktionen zu Makro-Aktionen. Was das konkret bedeutet und welches Umdenken es erfordert.
Andrej Karpathy – ehemaliger Director of AI bei Tesla, Mitgründer von OpenAI – beschreibt im No Priors Podcast einen Zustand, den er „AI Psychosis“ nennt: das Gefühl, dass sich gerade alles verschiebt und man nicht schnell genug hinterherkommt. Nicht weil die Tools zu kompliziert wären – sondern weil das, was damit möglich ist, noch kaum jemand ausgereizt hat.
Der Dezember-Moment: Von 80/20 zu 2/98
Karpathy beschreibt einen konkreten Wendepunkt. Im Dezember 2025 kippte sein Verhältnis von eigenem Code zu delegiertem Code radikal:
„I kind of went from 80/20 of writing code by myself versus just delegating to agents. And I don’t even think it’s 20/80 by now. I think it’s a lot more than that. I don’t think I’ve typed like a line of code probably since December basically.“
Das betrifft nicht nur Karpathy. Es betrifft jeden, der professionell mit Software arbeitet. Die Arbeitseinheit hat sich verschoben: Nicht die Codezeile zählt, sondern die Funktionalität.
Was sind Makro-Aktionen?
Früher war die kleinste sinnvolle Handlung eine Codezeile, eine Funktion, ein Commit. Heute ist es eine ganze Funktionalität – delegiert an einen Agenten.
„You can move in much larger macro actions. It’s not just ‘here’s a line of code, here’s a new function.’ It’s ‘here’s a new functionality’ and delegate it to agent one. Here’s a new functionality that’s not going to interfere with the other one. Give it to two.“
Das Vorbild: Peter Steinberger (Gründer von OpenClaw, jetzt bei OpenAI). Ein berühmtes Foto zeigt ihn vor einem Monitor voller paralleler Codex-Agenten – jeder arbeitet etwa 20 Minuten an einem Task. Steinberger wechselt zwischen ihnen, verteilt Arbeit, reviewt Ergebnisse. Er schreibt nicht. Er orchestriert.
- Mikro-Aktion: Eine Funktion schreiben, einen Bug fixen, einen Test anpassen.
- Makro-Aktion: „Baue ein komplettes Authentifizierungssystem mit OAuth2 und Session-Management.“
Der Unterschied ist nicht nur Granularität. Es ändert die Art, wie Entwickler über Arbeit nachdenken: nicht mehr in Syntax, sondern in Systemen.
Der erforderliche Mindset-Wechsel
Ein neues Tool installieren reicht hier nicht. Es geht um ein anderes Verständnis der eigenen Rolle:
1. Der Mensch ist der Engpass – nicht die Technologie
Die Fähigkeit der Agents ist da. Was fehlt, ist das Geschick im Umgang damit.
„Everything is skill issue. It’s not that the capability is not there. It’s that you just haven’t found a way to string it together.“
Karpathy beschreibt, wie er sich schuldig fühlt, wenn sein Token-Kontingent nicht ausgeschöpft ist. Früher war das Äquivalent: nervös werden, wenn GPUs idle sind. Heute: nervös werden, wenn man kein Compute für Agents verbrennt. Die knappe Ressource ist der Entwickler selbst – seine Fähigkeit, gute Instruktionen zu geben, Agents zu parallelisieren, Ergebnisse zu bewerten.
2. Von Token-Typing zu Token-Throughput
Die alte Metrik: Tippgeschwindigkeit, Lines of Code, Commits pro Tag. Die neue Metrik: Token-Durchsatz. Wie viele Agents laufen parallel? Wie effizient sind die Instruktionen? Wie schnell lassen sich Ergebnisse validieren?
„To get the most out of the tools that have become available now, you have to remove yourself as the bottleneck. You need to take yourself outside.“
3. Wenige Inputs, großer Output
Das Ziel ist nicht mehr, den ganzen Tag produktiv zu tippen. Sondern: wenige, präzise Inputs geben – und ein System orchestrieren, das autonom den Rest erledigt.
„I put in just very few tokens just once in a while and a huge amount of stuff happens on my behalf.“
Die Schichten der Makro-Aktion: Karpathys Zwiebel-Metapher
Karpathy beschreibt die Evolution als Schichten einer Zwiebel. Jede Schicht wird zur Selbstverständlichkeit – und darauf baut die nächste auf:
- LLM als Grundlage – mittlerweile selbstverständlich. Niemand diskutiert mehr, ob LLMs funktionieren.
- Agents – mittlerweile selbstverständlich. Ein Agent, der Code schreibt und testet, ist Standard.
- Claw-artige Entitäten – persistente, autonome Loops, die auch ohne menschliches Zutun weiterarbeiten. Eigene Sandboxes, eigenes Memory.
- Mehrere Claws parallel – zehn Repos offen, zehn Agents gleichzeitig aktiv.
- Instruktionen optimieren – bessere agents.md-Dateien, bessere Memory-Systeme, bessere Workflows.
- Meta-Optimierung – Agents, die die Instruktionen für andere Agents verbessern.
„The LLM part is now taken for granted. The agent part is now taken for granted. Now the claw-like entities are taken for granted and now you can have multiple of them and now you can have instructions to them and now you can have optimization over the instructions.“
Jede Schicht, die gestern noch innovativ war, ist morgen Commodity. Darauf baut die nächste.
Wohin das führt: AutoResearch
Karpathy testet das Prinzip bereits am Extrem: Sein Projekt „AutoResearch“ lässt Agents komplett autonom forschen – experimentieren, trainieren, optimieren, ohne menschliches Zutun. Über Nacht fand das System Verbesserungen an einem Modell, das er selbst nach 20 Jahren Erfahrung als ausoptimiert betrachtet hatte. Die Konsequenz aus dem Makro-Denken: Nicht nur Features delegieren, sondern ganze Arbeitsprozesse.
Die ehrliche Einschränkung: Zackige Intelligenz
Karpathy verklärt das nicht. Er beschreibt ein Phänomen, das er „Jaggedness“ nennt – ein zackiges, ungleichmäßiges Fähigkeitsprofil. Auf Deutsch: Die Modelle sind in manchen Bereichen brillant und in anderen erschreckend naiv. Es gibt kein gleichmäßiges Intelligenzniveau.
„I simultaneously feel like I’m talking to an extremely brilliant PhD student who’s been a systems programmer for their entire life and a 10-year-old. And it’s so weird.“
Alles, was verifizierbar ist – Code, Mathematik, Unit Tests – funktioniert hervorragend. Alles, was nicht per Reinforcement Learning optimiert wird, stagniert. Das berühmte Beispiel: ChatGPT erzählt seit vier Jahren denselben Witz über Atome. In trainierten Domänen liefern die Modelle Spitzenleistung. Außerhalb davon tappen sie im Dunkeln.
Für die Praxis heißt das: Makro-Aktionen funktionieren dort am besten, wo es objektive Metriken gibt. Wo Erfolg messbar ist, kann ein Agent autonom optimieren. Wo Nuance und Urteilsvermögen gefragt sind, bleibt der Mensch im Loop.
Was das für Entwickler bedeutet
Dieser Wechsel passiert gerade. Für Softwareentwickler, die ihn ernst nehmen, ergeben sich konkrete Konsequenzen:
- Delegieren statt implementieren. Die Aufgabe verschiebt sich: Agents gute Instruktionen geben – nicht selbst Code schreiben.
- In Systemen denken, nicht in Funktionen. Die Arbeitseinheit ist das Feature, nicht die Codezeile.
- Parallelisieren. Ein Agent ist gut. Fünf parallele Agents auf unabhängigen Tasks sind ein anderes Level.
- Instruktions-Qualität als Hebel begreifen. Die agents.md, die Rules, die Skills – das entscheidet über Output-Qualität. Nicht der Typing Speed.
- Review nicht abschaffen. Agents liefern stellenweise Spitzenleistung und patzen an unerwarteten Stellen. Prüfen bleibt Pflicht.
- Sich selbst aus dem kritischen Pfad nehmen. Ziel: Systeme, die auch laufen, wenn niemand zusieht.
„The things that agents can’t do is your job now. The things that agents can do, they can probably do better than you.“
Die Arbeitseinheit verschiebt sich von der Codezeile zur Funktionalität. Wer weiterhin in Mikro-Aktionen denkt, bremst sich selbst. Der entscheidende Skill ist Orchestrierung – nicht Programmierung.
Wie wir helfen
Wir unterstützen Teams beim Übergang von manueller Implementierung zu agentengestützter Softwareentwicklung – mit konkreten Workflows, Agent-Konfigurationen und Enablement.
