Agiles Engineering in fünf Ebenen: Von Spezifikationen und parallelen Agenten bis hin zu Regeln und Überwachung.
Karpathy bezeichnete den vorangegangenen Prozess als „Vibe Coding“. Siehe die fünf Ebenen des agilen Engineerings: Spezifikationen, Orchestrierung, kodifizierte Regeln, menschliche Überprüfung und Beobachtbarkeit sowie ein Wochenplan.
Vibe Coding war eine Zeit lang sehr beliebt. Andrej Karpathy, der Begründer dieses Konzepts, hat seitdem erklärt, dass diese Ära vorbei sei. Er hat nicht nur das Problem benannt, sondern auch eine Lösung vorgeschlagen: agitives Engineering, bei dem KI-Agenten Code planen, schreiben, testen und bereitstellen, während ein Mensch eine strukturierte Überwachung durchführt. Der Mensch legt die Absicht fest, die Agenten führen sie aus und der Mensch überprüft das Ergebnis. Das ist eine professionelle Methode, mit KI zu arbeiten – und nicht nur nebenher –, und sie steht in starkem Kontrast zum gelegentlichen Anfordern von Ergebnissen in der Hoffnung auf Erfolg.
Eine frühere Initiative für eine spezifikationsgetriebene Entwicklung, bei der zunächst festgelegt wird, was ein System tun muss, bevor irgendein Agent etwas erstellt, umfasst laut Erfahrung nur eine Schicht dieser Disziplin. Seitdem haben Teams in der Produktion vier weitere Schichten hinzugefügt. Im Folgenden werden alle fünf Schichten dargestellt, gezeigt, wie jede in der Praxis aussieht, und es wird ein einwöchiger Übungsplan zum Einstieg vorgestellt.
Warum der Name wichtig ist
Der Begriff ist mehr als nur eine Marke. Er markiert die Grenze zwischen zwei sehr unterschiedlichen Arbeitsweisen, und Karpathy zeichnete diese Grenze mit einem Paar Fragen. Beim Vibe Coding wird gefragt, ob etwas funktionieren kann. Beim Agentic Engineering wird gefragt, ob es zuverlässig und in großem Maßstab funktionieren kann, ohne Sicherheitslücken zu schaffen.
Die erste Frage hebt die Grenzen. Jeder kann jetzt Prototypen erstellen: Ein Wochenend-Entwickler beschreibt, was er möchte, akzeptiert das Ergebnis und erhält schließlich eine funktionierende Demo – was für die Erkundung wirklich nützlich ist. Die zweite Frage setzt Grenzen. Software, die Zahlungen verarbeitet, Gesundheitsdaten handhabt oder Infrastruktur betreibt, erfordert weiterhin professionelle Disziplin. Der Entwickler mag den Code schreiben, doch eine Person muss das System entwerfen, seine Grenzen festlegen und die Ergebnisse überprüfen.
Karpathys eigene Formulierung war unverblümt: Agentenbasiertes Engineering ist ein Ingenieurwissenschaftsfach, und die darin verwendeten Agenten sind unvorhersehbar, stochastisch und äußerst mächtig. Das eigentliche Problem besteht daher darin, sie so zu koordinieren, dass sie schneller arbeiten können, ohne den Qualitätsstandard zu senken. Dieses Problem – Geschwindigkeit ohne Kompromisse bei der Qualität – ist heute die zentrale Frage dieses Fachgebiets. Das ist nicht nur seine Ansicht. IBM, Forrester und Anthropic veröffentlichten jeweils im selben Quartal formale Rahmenwerke für ein neues, eigenständiges Fachgebiet und kamen dabei unabhängig voneinander zu denselben Erkenntnissen. Wenn Organisationen, die selten übereinstimmen, zum gleichen Zeitpunkt zu denselben Schlussfolgerungen gelangen, hat die Idee Substanz.
Der Begriff hat sich durchgesetzt, weil Ingenieure ein Wort für die Arbeit brauchten, die sie bereits verrichteten: strukturierter als das Eingeben von Anweisungen, disziplinierter als „Vibe Coding“ und dennoch anders als die traditionelle Entwicklung. Die damit bezeichnete Disziplin umfasst fünf Ebenen, wobei jede auf der darunterliegenden beruht. Wenn eine Ebene weggelassen wird, wird alles darüber unzuverlässig.
Ebene 1: Spezifikation
Schreiben Sie die Spezifikation, bevor ein Agent irgendeinen Code erzeugt. Legen Sie fest, was das System stets tun muss, was es auf keinen Fall tun darf, wie man erkennen kann, dass es funktioniert, und wie man feststellt, dass es aufgehört hat. Bringen Sie all das in ein Dokument, halten Sie dieses Dokument aktuell und messen Sie alles, was der Agent erstellt, daran.
Unterschiedliche Ansätze in der KI-Entwicklung nennen dies strategische Planung, Definition von Absichten oder einfach nur die Spezifikation. Die Bezeichnung variiert, doch die Praxis bleibt dieselbe: Man muss wissen, was gewünscht wird, bevor man einen Agenten bittet, es zu erstellen.
Ein Punkt wird leicht übersehen. Eine Spezifikation ist kein Produkt aus dem Veröffentlichungstag – sie ist ein lebendiges Dokument. Immer dann, wenn die Implementierung etwas aufzeigt, was die Spezifikation nicht vorausgesehen hat – und das wird sie –, wird die Spezifikation aktualisiert. Teams, deren Mitarbeiter allmählich von der ursprünglichen Absicht abweichen, sind fast immer Teams, die die Spezifikation am ersten Tag verfasst haben und sie danach nie wieder geöffnet haben.
Ein minimales Template beginnt mit einem Header, der das Dokument als Quelle der Wahrheit deklariert:
# Feature Spec: [Feature Name]
## Last updated: [Date] — this document is the source of truth
Dann folgen die Verhaltenschecklisten, ein Abschnitt mit erforderlichen Verhaltensweisen sowie ein Abschnitt mit strengen Grenzen, wie beispielsweise das Verbot, eine Rückerstattung über 500 Dollar ohne menschliche Genehmigung zu bearbeiten:
## What this must always do
- [ ] [Behaviour 1 — specific, testable]
- [ ] [Behaviour 2 — specific, testable]## What this must never do
- [ ] [Boundary 1 — e.g. "Never process refund >$500 without human approval"]
- [ ] [Boundary 2 — e.g. "Never fabricate a citation"]## Success criteria (measurable)
- Context recall: >0.85
- Faithfulness: >0.90
- Cost per query: <$0.15
- Latency p95: <2s## Failure signals (alert if breached)
- Any metric drops >5% from 7-day baseline
- Cost per task exceeds 3x expected range
- User complaint rate exceeds 2% of sessions## Decomposition (for parallel agents)
- [ ] Task A: [scope] — can be delegated independently
- [ ] Task B: [scope] — depends on Task A output
- [ ] Task C: [scope] — can run parallel with Task A
Beschränken Sie sich auf eine Seite. Wenn die Spezifikation länger wird, ist die Funktion zu umfangreich und sollte in kleinere Teile aufgeteilt werden, bis jeder Teil hineinpasst.
Auch eine perfekte Spezifikation, die einem einzelnen Agenten übergeben wird, stößt an eine Leistungsgrenze – deshalb gibt es eine zweite Ebene.
Ebene 2: Orchestrierung
Betrachten Sie eine Funktion, die das Datenbankschema, die API, die Frontend-Plattform sowie den Testumfang betrifft. Traditionell arbeitet ein Ingenieur nacheinander an den einzelnen Teilen oder ein Team koordiniert sich über einen Sprint hinweg. Im agilen Engineering übernehmen vier Agenten alle vier Teile gleichzeitig: Einer schreibt die Migration, ein anderer die Endpunkte, ein Dritter die Frontend-Komponenten und ein Vierter schreibt Tests sowie prüft den Rest auf Sicherheitsprobleme. Jeder hat seinen eigenen Kontext und seine eigenen Einschränkungen, und ihre Ausgaben werden zu einer kohärenten Änderung zusammengeführt.
Das ist keine Hypothese. Stripe setzt dieses Muster in der Produktion ein, mit einem internen Agentensystem, das wöchentlich mehr als 1.000 zusammengeführte Pull Requests erzeugt – jeder davon wird von einem Agenten verfasst, von einem Menschen überprüft, durch die CI-Prüfung geführt und schließlich veröffentlicht. Der Gewinn ist um ein Vielfaches größer als nur ein Faktor zwei.
Der Ablauf ist ein Zyklus, der für jede Funktion wiederholt wird: Planen, Ausführen, Überprüfen. Einige Teams nennen diesen Zyklus PEV-Zyklus.
- Planen. Der Mensch erstellt die Spezifikationen auf Basis von Layer 1 und teilt die Arbeit in unabhängig delegierbare Einheiten auf. Eine wichtige Entscheidung hier ist, welche Aufgaben parallel ausgeführt werden können, da sie nicht von den Ergebnissen der anderen abhängen, und welche nacheinander ausgeführt werden müssen.
Was früher einen zweiwöchigen Sprint erforderte, wird nun zu einer fokussierten Arbeitssession von einigen Stunden oder einem Tag. Die menschliche Arbeit konzentriert sich hauptsächlich auf Planung und Überprüfung, während die Agenten den größten Teil der Arbeit zwischen diesen Schritten übernehmen.
Eine Nuance erfordert Zeit zum Verstehen: Das Ziel ist nützlicher Parallelismus, nicht maximaler Parallelismus. Drei Agenten auf eng vernetzten Modulen erzeugen Konflikte, deren Beilegung mehr kostet, als durch paralleles Arbeiten eingespart werden könnte. Zwei Agenten auf unabhängigen Modulen, wobei ein dritter beide überwacht, liefern kohärente Ergebnisse. Die Fähigkeit besteht darin, Aufgaben zu zerlegen, sodass sie ohne spätere Integrationsprobleme delegiert werden können.
Ein Skelett-Orchestrator kann die Schleife in seiner Dokumentation beschreiben:
class AgenticOrchestrator:
"""Plan → Execute (parallel) → Verify"""
und führen den Planungsschritt durch, bei dem eine Funktion in delegierbare Aufgaben aufgeteilt wird:
def plan(self, feature_spec: dict) -> dict:
"""Decompose feature into independently delegatable tasks."""
tasks = []
for component in feature_spec["decomposition"]:
tasks.append({
"id": component["id"],
"spec": component["scope"],
"constraints": feature_spec["must_never"] + component.get("local_rules", []),
"depends_on": component.get("depends_on", []),
"verification": component.get("success_criteria", []),
})
independent = [t for t in tasks if not t["depends_on"]]
sequential = [t for t in tasks if t["depends_on"]]
return {"parallel": independent, "sequential": sequential} async def execute(self, plan: dict):
"""Run independent tasks in parallel, sequential tasks in order."""
parallel_results = await asyncio.gather(*[
self.delegate_to_agent(task) for task in plan["parallel"]
])
for task in plan["sequential"]:
result = await self.delegate_to_agent(task, prior=parallel_results)
parallel_results.append(result)
return parallel_results def verify(self, results: list, spec: dict) -> dict:
"""Check all outputs against the spec — structural, not line-by-line."""
issues = []
for result in results:
if not self.satisfies_spec(result, spec):
issues.append(f"{result['id']}: does not satisfy spec")
if self.conflicts_with(result, results):
issues.append(f"{result['id']}: conflicts with another module")
return {"passed": len(issues) == 0, "issues": issues}
Das Leitprinzip ist eine enge Begrenzung des Kontexts. Jeder Agent sollte nur seinen Spezifikationsabschnitt, seine Code-Dateien sowie seine Regeln erhalten. Das Hineinbringen der gesamten Codebasis in jedes Kontextfenster verschwendet Ressourcen, erhöht die Kosten und schwächt die Aufmerksamkeit des Modells.
Orchestrierung steigert die Durchsatzrate – doch Durchsatz ohne Konsistenz führt zum Chaos. Jeder Agent muss die Konventionen des Teams, die architektonischen Einschränkungen sowie die Sicherheitsrichtlinien kennen, genauso wie die Spezifikationen für seine eigene Aufgabe. Die nächste Schicht stellt dies bereit.
Schicht 3: kodifizierte Regeln
Die meisten Tools verfügen bereits über eine Variante davon. Claude Code lädt zu Beginn jeder Sitzung ein CLAUDE.md, Cursor liest .cursorrules und Codex liest AGENTS.md. Das Konzept ist dasselbe: eine Datei im Projektverzeichnis, die dem Agenten vorgibt, wie er sich verhalten soll.
Im Jahr 2026 sind Teams noch einen Schritt weiter gegangen und haben ihre gesamte Entwicklungskultur als von Agenten verarbeitbare Einschränkungen kodiert – jenseits des Technologiestacks. Praktiker wie Paul Duvall dokumentieren die Muster, die aus Produktionsteams hervorgehen, und InfoQ verfolgt deren Reifegrad. Vier Muster treten überall dort auf, wo agiles Engineering angewandt wird:
- Spezifikationsgetriebene Entwicklung, bei der die Spezifikation die Arbeit leitet (Schicht 1).
- Kodifizierte Regeln und architektonische Einschränkungen: Konventionen, Sicherheitsrichtlinien, Muster zur Fehlerbehandlung, Namensstandards sowie Bereitstellungsverfahren – alles in Dateien, die von Agenten vor dem Start geladen werden.
- Atomare Aufteilung mit parallelen Agenten: Funktionen werden in die kleinstmöglichen Teile zerlegt, die eigenständig weitergeleitet werden können (Schicht 2).
Bei der Skalierbarkeit stoßen die meisten Teams auf Grenzen. Ein CLAUDE.md eignet sich gut für ein 1.000-Zeilen-Prototyp. Eine Codebasis mit 100.000 Zeilen lässt sich nicht in einer Datei beschreiben, und selbst wenn es möglich wäre, würden die Regeln den Kontextfenster bereits vor dem Erreichen der eigentlichen Aufgabe aufbrauchen.
Teams, die dieses Problem lösen, erstellen hierarchische Regelwerke – ähnlich wie ESLint-Konfigurationen von Organisationseinstellungen geerbt werden und pro Projekt überschrieben werden können. Die Ordnerstruktur sieht wie folgt aus:
your-company/
├── .ai-rules/
│ └── org-rules.md ← Company-wide: security, compliance, style
│
├── team-payments/
│ ├── .ai-rules/
│ │ └── team-rules.md ← Team-level: error handling, testing, deploys
│ │
│ ├── service-checkout/
│ │ ├── CLAUDE.md ← Repo-level: architecture, tech stack, builds
│ │ ├── src/
│ │ │ ├── auth/
│ │ │ │ └── .ai-rules.md ← Module: auth-specific constraints
│ │ │ └── payments/
│ │ │ └── .ai-rules.md ← Module: PCI compliance rules
Oben befindet sich die Organisationseintragsdatei, die für jeden Agenten in jedem Repository geladen wird. Sie regelt Aspekte wie das Vermeiden des Commitzens von Geheimnissen, die Erforderlichkeit einer Authentifizierung bei öffentlichen APIs sowie das Vermeiden der Offenlegung von Stack-Traces in Fehlerrückmeldungen:
# org-rules.md (loaded for every agent, every repo)
- Never commit secrets or credentials
- All public APIs require authentication
- Error responses must never expose stack traces
- Log every state-changing operation with user context
Unter ihm erbt eine Team-Datei diese Regeln und fügt eigene hinzu, wie zum Beispiel das Resultat-Muster anstelle von geworfenen Ausnahmen, jeder Datenbankzugriff über eine Repository-Schicht sowie Tests, die den erfolgreichen Ablauf sowie mindestens zwei Fehlerfälle abdecken:
# team-rules.md (inherits org, adds team specifics)
- Use Result<T, E> pattern — never throw exceptions
- All database queries go through the repository layer
- Tests must cover the happy path + 2 failure modes minimum# CLAUDE.md (inherits team, adds repo specifics)
- This repo uses Express.js + Prisma + PostgreSQL
- Run `npm test` before suggesting any PR is ready
- Migrations are append-only — never modify applied migrations# module .ai-rules.md (inherits repo, adds module specifics)
- auth/: All token operations must use constant-time comparison
- payments/: PCI DSS requires field-level encryption on card data
Ein Agent lädt die Organisationsregeln, die Teamregeln, das CLAUDE.md des Repositories sowie die Regeln für den Modulbereich, mit dem er arbeitet. Dadurch bleibt der Kontext begrenzt und übersichtlich. Der Agent im Zahlungsmodul erhält Regeln zur PCI-Konformität, während der Agent im Frontend diese nicht erhält – schließlich würden solche Regeln den Kontextbudget ohne Nutzen aufbrauchen.
Regeln legen fest, wie gearbeitet werden soll, doch die Ausgabe erfordert dennoch menschliches Urteilsvermögen. Code kann allen Konventionen folgen und dennoch architektonisch falsch sein, wodurch das behobene Problem an einer anderen Stelle zu einem größeren wird. Deshalb ist die nächste Schicht nicht optional.
Schicht 4: menschliche Überwachung
Drei Wörter beschreiben das entstandene Betriebsmodell: Delegieren, Überprüfen, Verantwortung übernehmen.
Delegieren. Übergeben Sie dem Agenten eine klar definierte Aufgabe mit eindeutigen Vorgaben und lassen Sie ihn arbeiten. Mikromanagen Sie die Umsetzung nicht und beobachten Sie nicht, wie er tippt. Die Spezifikationen und Regeln dienen dazu, sicherzustellen, dass man dem Agenten vertrauen kann, sie einzuhalten.
Überprüfen. Betrachten Sie die zurückgegebene Ausgabe als Pull Request von einem fähigen, aber jüngeren Entwickler: schnell, kompetent – doch anfällig für subtile Fehler, die nur jemand erkennen kann, der das gesamte System versteht. Prüfen Sie die architektonische Passgenauigkeit sowie Randfälle. Bestätigen Sie, dass die Spezifikationen erfüllt wurden, was bedeutet, dass der ursprüngliche Zweck erreicht wurde und nicht nur, dass die Tests bestehen.
Verantwortung übernehmen. Der Mensch trägt die letztendliche Verantwortung für die Qualität. Der Agent hat die Arbeit erledigt, die Person gibt ihre Zustimmung – bei Produktionsfehlern liegt die Verantwortung bei dieser Person. Diese Verantwortung unterscheidet das agierende Engineering vom sogenannten „Vibe Coding“, bei dem niemand für die Ergebnisse verantwortlich ist.
Das Engpassproblem ist real. Agenten erzeugen Code schneller, als Menschen ihn überprüfen können, und es besteht die Versuchung, die Strenge zu verringern, um mit dem Tempo Schritt zu halten. Genau diese Versuchung führte dazu, dass „Vibe Coding“ Fuß fasste: Entwickler akzeptierten die Ergebnisse, weil sie richtig aussahen, die Tests bestanden und ein Abgabetermin bevorstand. Agentic Engineering existiert dazu, dieses Muster davon abzuhalten, sich zu wiederholen.
Der Bericht von Anthropic zu den Trends im agilen Programmieren beschreibt, wie erfahrene Ingenieure damit umgehen. Sie delegieren Aufgaben, deren Korrektheit auf den ersten Blick leicht überprüft werden kann oder bei denen die Risiken gering sind. Je konzeptionell schwieriger oder designabhängiger eine Aufgabe ist, desto wahrscheinlicher ist es, dass sie sie selbst übernehmen oder gemeinsam mit dem Agenten bearbeiten. Zu wissen, was delegiert und was behalten werden soll, ist die neue Kernkompetenz. Sie entwickelt sich durch Praxis, wird durch keine Frameworks oder Tool-Shortcuts beschleunigt, und sie unterscheidet den Ingenieur, der Agenten produktiv einsetzt, vomjenigen, der beeindruckende Ergebnisse liefert, die unter genauer Prüfung zusammenbrechen.
Eine Überprüfungsliste hilft, bevor etwas, das von einem Agenten erstellt wurde, in die Produktion geht. Ihr Überschrift lautet:
## Agent Output Review Checklist
und sein Inhalt, der in Abschnitten gegliedert ist – beginnend mit der Spezifikationsübereinstimmung (sind alle erforderlichen Verhaltensweisen umgesetzt, werden Grenzen eingehalten, sind die Erfolgskriterien erfüllt) und weitergehend mit Architektur und wirtschaftlichem Sinn:
### Spec alignment (does it do what was asked?)
- [ ] All "must always do" behaviours are implemented
- [ ] No "must never do" boundaries are violated
- [ ] Success criteria from the spec are met or tested### Architectural coherence (does it fit the system?)
- [ ] No new dependencies introduced without justification
- [ ] Consistent with naming, patterns, and structure of existing code
- [ ] No duplication of logic that exists elsewhere### Safety and edge cases
- [ ] Error handling covers the failure modes the spec anticipated
- [ ] No hardcoded credentials, keys, or environment-specific values
- [ ] Input validation present on all external-facing boundaries### What the agent cannot check for itself
- [ ] Does this make business sense? (not just technical correctness)
Es lohnt sich, diesen Text auszudrucken und neben dem Monitor aufzuhängen. Linters und CI können die ersten drei Abschnitte teilweise automatisieren. Der letzte Aspekt, der Geschäftssinn, ist der Grund, warum ein Mensch weiterhin involviert sein muss.
Überprüfungen erkennen Probleme vor der Veröffentlichung. Eine langsame Verschlechterung der Qualität, subtile Rückschritte sowie eine Kostensteigerung, die erst bei Erhalt der Rechnung auffallen, zeigen sich erst danach – und erfordern daher die letzte Überprüfungsstufe.
Ebene 5: Beobachtbares Entwickeln
Monitoring und beobachtbares Entwickeln klingen ähnlich, erfüllen aber unterschiedliche Aufgaben. Monitoring informiert darüber, dass das System verfügbar ist, mit normaler Latenzzeit, wenigen Fehlern und einem grünen Dashboard. Beobachtbares Entwickeln zeigt hingegen auf, was das System getan hat: Welcher Agent welche Aufgabe gemäß welcher Spezifikation mit welchen Werkzeugen bearbeitet hat, welchen Code erzeugt wurde und ob das Ergebnis den ursprünglichen Zielen entsprach.
Der Unterschied zeigt sich um 2 Uhr morgens. Bei reinem Monitoring ist klar, dass etwas nicht in Ordnung ist, doch die Ursache ist unbekannt, weshalb die Nacht damit verbracht wird, Unterschiede zu prüfen und an den Modulen zu rätseln. Bei beobachtbarem Entwicklungsprozess zeigt die Überwachung der Bereitstellung, dass Agent 3 den Authentifizierungsablauf gegenüber einer Spezifikation geändert hat, die gleichzeitige Token-Aktualisierungen ignorierte. Das bedeutet zwölf Minuten gezielten Debuggens anstelle von zwei Stunden Spekulation.
In der Praxis kommt es auf drei Gewohnheiten an:
- Jede Agentenaufgabe erzeugt einen strukturierten Überblick: die empfangene Spezifikation, die verwendeten Tools, die geänderten Dateien, die Modellversion, die verbrauchten Tokens sowie das Überprüfungsergebnis. Wenn drei Tage später ein Fehler auftritt, zeigt der Überblick, was passiert ist, und niemand muss sich daran erinnern.
Eine minimale Einrichtung beginnt mit Importen für eine kleine Protokolldatei:
from dataclasses import dataclass, field
from datetime import datetime
und die trace-Datenklasse, die auf jede delegierte Aufgabe angewendet wird:
@dataclass
class AgentTrace:
"""Minimum trace for every agent-delegated task."""
task_id: str
agent_id: str
spec_given: str # What was the agent told to do?
tools_used: list[str] # Which tools did it invoke?
files_modified: list[str] # What did it change?
model_version: str # Which model, which version?
tokens_consumed: int # What did it cost?
started_at: datetime = field(default_factory=datetime.utcnow)
completed_at: datetime | None = None
verification_result: str = "" # pass / fail / needs_review
human_reviewer: str = "" # Who signed off?
issues_found: list[str] = field(default_factory=list)
Fügen Sie eine wöchentliche Fünfzehn-Minuten-Besprechung hinzu. Der Überschrift lautet:
## Weekly Observable Development Review (15 minutes)
und dazu gehörende Fragen: Wie viele Aufgaben wurden delegiert, wie viele bestanden die Überprüfung beim ersten Versuch (Zielwert über 80 %), in welcher Kategorie gab es die meisten Probleme und welche drei Hauptprobleme trat auf:
1. How many agent tasks were delegated this week? ___
2. How many passed verification on first attempt? ___ (target: >80%)
3. Which task category had the most issues? ___
4. Top 3 issues found during review:
- ___
- ___
- ___
5. Which issues should become codified rules (Layer 3)? ___→ Update CLAUDE.md with any new rules from this week's observations.
Fünfzehn Minuten pro Woche schließen den Kreislauf. Beobachtungen werden zu Regeln, Regeln verbessern die Orchestrierung, eine bessere Orchestrierung führt zu besseren Ergebnissen, und diese Ergebnisse ergeben neue Beobachtungen.
Beweise dafür, dass es funktioniert
Zwei Zahlen heben sich ab. Stripe verarbeitet mehr als 1.000 zusammengeführte Pull Requests pro Woche – diese werden von Automaten erstellt, von Menschen überprüft, bestehen die CI-Tests und sind in der Produktion im Einsatz, was kein Sandkastenexperiment ist. Dieser Durchsatz war vor einem Jahr noch nicht möglich. Eine andere Zielgruppe sieht eine andere Zahl: Eine Umfrage von McKinsey weist auf Kostensenkungen von 20 bis 40 Prozent hin – solche Zahlen bringen KI von einer Innovationsinitiative zu einer operativen Infrastruktur, etwas, das der CFO verlangt und nicht nur der CTO.
Was es für eine Ingenieurkarriere bedeutet
Die Rolle ändert sich und verschwindet nicht. Ingenieure im Jahr 2026 schreiben weniger grundlegende Code und verbringen mehr Zeit damit, Agenten zu koordinieren, Architekturen zu entwerfen, Ziele sowie Richtlinien festzulegen und die Ergebnisse zu überprüfen. Die zentrale Fähigkeit verschiebt sich von der Syntax zum Systemsdenken – von der Frage, wie man eine Funktion schreibt, zur Frage, wie man ein System entwirft, in dem Agenten diese Funktion korrekt schreiben können.
Karpathy erweiterte dies auf die Einstellung: Man sollte auf Rätselfragen verzichten und stattdessen ein umfangreiches Projekt vorgeben, beispielsweise den Bau eines sicheren Twitter-Klons, und anschließend sehen, wie die Kandidaten mit Tools, Spezifikationen und Überwachung umgehen. Das prüft Disziplin und nicht die Tippgeschwindigkeit.
Drei Kompetenzen tauchen immer wieder in Gesprächen mit Führungskräften im Ingenieurwesen auf:
- Spezifikationskompetenz. Es ist schwieriger, eine Spezifikation so präzise zu formulieren, dass ein Agent sie ohne Unklarheiten ausführen kann, als Code zu schreiben. Bei Code gibt es einen Compiler, der Fehler aufspürt, während eine Spezifikation nur auf die Interpretation des Agents angewiesen ist. Ist die Spezifikation vage, wird der Agent eine bestimmte Auslegung wählen, darauf aufbauen und das Ergebnis als genau das präsentieren, was angefordert wurde.
- Orchestrierungssinn. Zu wissen, was delegiert und was selbst übernommen werden sollte, wann parallele Ausführungen hilfreich sind und wann die Verknüpfung zu eng ist, sowie wann eine Ausgabe einer gründlichen Überprüfung statt nur einer strukturellen Prüfung bedarf. Dies entwickelt sich durch zahlreiche Delegierungen, wobei jede davon zeigt, was funktioniert und was zu Integrationsproblemen führt.
Gergely Orosz hat es gut ausgedrückt: Es gibt etwas Weitaus Größeres als das Programmieren, das Ingenieure besonders macht – und dieses sollte gefördert werden. Was Ingenieure im Jahr 2026 auszeichnet, sind die Systeme, die sie entwerfen, die Spezifikationen, die sie verfassen, ihr Urteilsvermögen bei der Delegation sowie das Qualitätsniveau, das sie nicht senken wollen. Genau weil die mechanische Ausführung automatisiert wurde, sind diese Fähigkeiten heute umso wertvoller.
Ein fünftägiger Einstiegsplan
Fünf Übungen über eine Woche, wobei jede auf der vorherigen aufbaut:
- Montag: Wissen des Teams kodieren. Erstellen Sie ein CLAUDE.md oder .cursorrules für das aktuelle Projekt. Überspringen Sie die Liste der Technologien und dokumentieren Sie die Konventionen: wie Fehler behandelt werden, wie Tests strukturiert sind, wie Dinge benannt werden, sowie die ungeschriebenen Regeln, die jeder Neue bereits am ersten Tag lernen sollte.
- Dienstag: Spezifizieren und delegieren. Wählen Sie eine Funktion aus dem Backlog aus und erstellen Sie ihre Spezifikation nach dem Vorlageformat: Was sie tun muss, was sie nicht tun darf, Erfolgskriterien und Fehlerindikatoren. Delegieren Sie die Arbeit vollständig an einen Agenten und planen Sie Zeit für sowohl die Spezifizierung als auch die Überprüfung ein. Das Verhältnis zeigt, wohin die Anstrengungen tatsächlich fließen.
Eine Woche macht noch keinen agilen Ingenieur. Sie zeigt jedoch, wie diese Disziplin ist, und ob der Wechsel vom Schreiben von Code zur Orchestrierung von Agenten Energie gibt oder raubt. Beide Antworten sind legitim, aber es hilft zu wissen, welche zutrifft.
Warum eine ausschließlich auf Spezifikationen basierende Sichtweise unzureichend ist
Die Spezifikation als die einzige Antwort zu betrachten – sie zu schreiben, ihr zu folgen und sie zur Überprüfung heranzuziehen – ist notwendig, aber nicht ausreichend. Die Spezifikation dient als Eingabe für ein Orchestrierungssystem und nicht als eigenständige Vorgehensweise. Eine perfekte Spezifikation, die einem Agenten übergeben wird, führt zu guter Arbeit. Derselbe Spezifikationsinhalt, aufgeteilt auf fünf parallele Agenten, wobei jeder durch kodifizierte Regeln gebunden ist, jeder unter strukturierter Überwachung überprüft wird und jeder durch beobachtbaren Entwicklungsverlauf nachvollzogen werden kann, erzielt bei derselben Qualität etwa das Zehnfache an Arbeit.
Auch Schicht 4 wird leicht unterschätzt. Die Spezifikation gibt den Zweck an, und der Mensch entscheidet, ob dieser Zweck erreicht wurde. Eine Spezifikation durchsetzt sich nicht von selbst, und der Überprüfungsprozess erfordert genauso viel Disziplin wie die Erstellung der Spezifikation selbst. Die Überprüfung – mehr als das Modell, das Framework oder die Tools – ist der Bereich, in dem die meisten Teams Kompromisse eingehen, sobald die Fristen enger werden.
Was kommt als Nächstes
Zwei Richtungen sind sichtbar: eine nahezu sicher und eine spekulativ.
Die nahezu sichere ist, dass agentenbasiertes Engineering innerhalb von etwa 18 Monaten zur Standardmethode für professionelle Softwareentwicklung wird – nicht, weil jeder darüber liest, sondern weil die wirtschaftlichen Vorteile unwiderstehlich sind. Drei Ingenieure, die dieses Verfahren anwenden, mit klaren Spezifikationen, paralleler Orchestrierung und disziplinierter Überwachung, erzeugen denselben Output wie zwölf Personen auf traditionelle Weise. Wenn die Rechnung so eindeutig ist, endet die Debatte.
Die spekulative Richtung betrifft agentenbasierte Schwärme: Netzwerke von Agenten, die untereinander koordinieren und ganze Arbeitsabläufe oder Geschäftsprozesse mit minimalem menschlichen Eingriff abwickeln. Einige Teams experimentieren bereits damit. Ob dies in unternehmensweiter Skala mit der erforderlichen Zuverlässigkeit funktioniert, ist unbekannt – daher sollte Interesse stets mit Skepsis einhergehen.
Was nicht spekulativ ist, ist die Tatsache, dass die Rolle des Ingenieurs bereits geändert hat. Die entscheidende Frage ist, ob die Kompetenzen für die neue Rolle – Spezifikation, Orchestrierung und Überprüfung – bereits entwickelt werden oder ob die Arbeit weiterhin so abläuft, als wäre das Schreiben von Code die Hauptaufgabe. Früher bestand die Arbeit darin, den Code einzutippen. Heute besteht die Arbeit darin, das System zu entwerfen, das den Code erzeugt, und sicherzustellen, dass das Erzeugte korrekt ist.