Der Loop bewegt sich.
Bewegst du dich mit?

01Wo wir stehen: Human-in-the-Loop

Heute ist KI Assistent. Du fährst jeden Schritt. Du nickst jede Änderung ab. Der Gewinn ist echt, aber er hat eine harte Deckelung: Ein Mensch, der in der Mitte jedes Loops liest und entscheidet – in menschlicher Geschwindigkeit.

Das machte Sinn, solange Modelle unzuverlässig waren. Heute, wo sie planen, ausführen und ihre eigene Arbeit prüfen können? Ist genau dieses Modell der Flaschenhals.

02Wo’s hingeht: CAO – Continuous Agent Orchestration

Beim CAO bewegst du dich aus dem Loop raus, drüber. Du definierst Intent, Constraints und was „gut“ aussieht. Agenten zerlegen die Arbeit, laufen parallel, liefern Ergebnisse – keine Vorschläge. Gates entscheiden, ob eine Änderung überhaupt existieren darf. Du entscheidest, ob sie es wert ist, geshippt zu werden.

03Drei Rollen, sauber getrennt

Der Fehler: „KI“ als einen Brei behandeln, der alles ersetzt. In der Praxis sind es drei Parteien, und jede ist gut in etwas, worin die anderen scheitern. Vermischst du sie? Entweder Mensch-Flaschenhals oder unüberwachter Slop-Maschine.

04Gates sind wichtiger denn je

Ein Modell findet viele Patterns, die auch CodeQL oder Sonar finden. Heißt nicht, dass die Tools obsolet sind. Heißt: Sie werden wertvoller. Sie sind deterministisch. Gleicher Input = gleiches Verdikt. Jedes Mal. In Sekunden. Für fast nichts. Sie werden nicht müde. Man redet sie nicht um. Sie haben keine schlechten Tage.

Genau das willst du von einer Minimum Bar. CI/CD wird zur kontinuierlichen, binären Gate auf jeder Änderung: Baut es? Halten Types? Passen Tests? Keine bekannten Vulns? Oder nicht. Merge oder nicht.

Agenten sind super darin, diese Bar zu räumen – fütter sie mit Failures, sie fixen sie. Aber sie sind ein schlechter Ersatz dafür, die Bar zu sein.

Und genau dieser garantierte Floor befreit dich. Wenn du vertraust, dass nichts unterhalb der Linie shipped, geht deine Aufmerksamkeit dahin, wo sie hingehört: Das Produkt. Du kannst in Details gehen, mehr iterieren, schneller iterieren – ohne jedes Mal die Basics neu zu prüfen.

05Wo der Mensch hingehört: Usage Approval

Mit Gates, die Code bewachen, und Agenten, die ihn produzieren, wird Zeile-für-Zeile-PR-Review nebensächlich. Spot-Checks okay. Aber jeden Diff lesen? Skaliert nicht. Und dupliziert mostly, was Tools schon verifizieren.

Deine Approval-Ebene rutscht hoch: Von „ist der Code okay?“ zu „ist das Produkt richtig?“

Das heißt: Eigentlich benutzen. Auf nem echten Device durchklicken. Empty State, Error State, langsames Netz, absurder Input, zweiter User, Tastatur only. Fragen: Wie liest jemand, der das nie sah, das Label? Merken, was sich falsch anfühlt – auch wenn alle Checks grün sind.

Automation sagt dir: „Funktioniert wie spezifiziert.“ Nur ein Mensch sagt: „Funktioniert für Menschen.“

06Jede abgeschnittene Ecke ist ein Schritt in den Slop

Mit Agenten kannst du an jeder Ecke sparen. Und jede sieht einzeln harmlos aus. Geht schneller. Output wirkt plausibel. Heute bricht nix.

• Tests „nur diesmal“ skippen, weil Agent sagte „läuft“
• Lint-Regel deaktivieren oder Warning suppressen statt Ursache fixen
• Mergen, ohne selbst durchs Feature geklickt zu haben
• Generierten Code akzeptieren, den niemand im Team erklären könnte
• Architecture Drift zulassen, weil jede Änderung einzeln okay aussah
• Happy Path shippen, Edge Cases auf „später“ schieben

Jede Ecke = ein Schritt in den Slop. Und Slop compoundiert schneller, als du ihn generieren kannst.

07Eine Warnung: Mehr, schneller, kaputter

Zum ersten Mal sind die meisten Teams nicht mehr durch Output geblockt. Code, PRs, Features – quasi on demand. Der natürliche Reflex: Reinhauen. Mehr Features. Noch schneller. Noch mehr. Velocity-Charts sehen unglaublich aus.

Niemand spürt den Pull stärker als die, deren Job es ist, Dinge voranzutreiben: Dev Leads, PMs, Stakeholders. Meist die motiviertesten im Raum. Jahrelang war ihr Frust: Kapazität. Plötzlich wirkt Kapazität gelöst – der ganze Roadmap erreichbar dieses Quartal. Jedes Gespräch wird zu: „Was können wir noch shippen?“

Und dann hört das Produkt auf, Sinn zu ergeben. Features überlappen. Flows widersprechen sich. Niemand erinnert sich, warum was existiert. Jede neue Änderung baut auf einem Layer, den niemand wirklich versteht. Das Team wurde nicht langsamer – es hat nur aufgehört, den Mist zu bemerken, den es shipped.

Die Geschwindigkeit ist ein Geschenk, kein Mandat. Nutze sie, um zwei Versionen zu bauen und zu vergleichen. Um etwas heute Nachmittag vor echte User zu stellen statt nächsten Monat. Um am selben Feature dreimal weiterzuiterieren – nicht einfach die nächsten zehn draufzupacken.

Die Lektion ist alt und immer noch Gold: Test. Und bleib dran. Wissen, was du hast, bevor du mehr draufpackst. Statische Tools helfen hier auch – nicht als Verdikt über einzelne Änderungen, sondern als grober Kompass. Coverage, Complexity, Duplication, Hotspots zeigen dir, wo das Produkt really steht als etwas, das du shippst und maintainable ist: Ein Codebase, den Devs lesen, verstehen und in die Tiefe gehen können, wenn sie müssen. Weil irgendwann immer jemand muss.

08Die bessere Geschichte: Richtige Konfiguration, richtig für dich

Zwei Teams. Gleiche Agenten. Gleiche Models. Auf Papier gleiche Tools: Formatter, Linter, Type-Checks, Tests, CodeQL, Sonar. Halbjahr später: Eines fliegt, das andere ertrinkt in Noise. Der Unterschied? Nicht die Tools. Sondern wie sie konfiguriert sind, wo sie laufen, wie sie ins Environment passen.

Team 1 bolzt Tools drauf. Formatting nur in CI. Jeder Push = Glücksspiel. Agent öffnet PR, wartet 8 Min, scheitert an Trailing Comma, liest Log, fixed, pusht, wartet wieder. Zwei Branches formatieren dieselbe Datei unterschiedlich → Whitespace-Kollision. Import/Key-Order driftet mit dem, wer zuletzt dran war → jeder PR-Update konfliktet. PRs aktuell halten wird stillschweigend zum Job. Review-Threads voll mit Style-Nits. Und wenn ne Regel im Weg ist? Schnellster Fix (Mensch oder Agent): Ausschalten. Sind genau die Gewohnheiten, die wir Devs vor KI hatten – nur schneller und teurer: CI-Minuten, Tokens, Attention für Dinge, die nicht ändern, was das Produkt tut.

Team 2 trifft ein paar Entscheidungen einmal. Schreibt sie als Config nieder. Formatting ist kanonisch und automatisch – zwei Menschen (oder zwei Agenten) schreiben dieselbe Änderung → dieselben Bytes. Imports/Keys sortieren Tools → parallele Branches kämpfen nicht um Order. Whitespace/Line-Endings geklärt durch .editorconfig und .gitattributes. Lint-Regeln, die sich selbst fixen, tun’s; die wenigen übrigen fangen Bugs, nicht Geschmack. Merge-Queue hält PRs aktuell mit Base-Branch und rerunt Gates → niemand babysittet Rebase – und mit kanonischem Formatting konfliktieren Updates fast nie.

Die billigen, offensichtlichen Fixes passieren zuerst und lokal: Alles, was Behavior nicht ändert oder im Worst Case vernachlässigbar. Ein Git-Hook-Manager wie lefthook macht das zur Single File:

# fix what doesn't change behaviour, before it's committed
pre-commit:
  commands:
    fix:
      glob: "*.{js,ts,tsx,json}"
      run: npx biome check --write --no-errors-on-unmatched {staged_files}
      stage_fixed: true

pre-push:
  commands:
    types:
      run: npx tsc --noEmit

Biome hier – Prettier, ESLint, Ruff, gofmt funktionieren gleich. Hooks vom Setup-Script des Projekts installieren, damit Agent-Sandboxes sie auch laufen, nicht nur Laptops.

Die Kosten folgen derselben Reihenfolge. Pre-commit Fix = Millisekunden, null Tokens. CI-Roundtrip für denselben Trailing Comma = Minuten Runner-Zeit + voller Agent-Turn für Log lesen & Retry – mal jeder PR, jeder Agent, jeder Tag.

Der subtile Part: CI läuft immer noch jeden Check. Bleibt die bindende, binäre Bar. Wird ein Hook je geskippt, hält die Bar trotzdem. Aber Checks um Form statt Funktion können nicht mehr scheitern – bis ein Commit existiert, sind sie schon applied. Die Minimum Bar ist gesichert, bevor sie je getestet wird. Und erzeugt null Reibung: Nicht für Menschen. Nicht für Agenten.

Agenten schreiben Code & Features – nicht Formatting. Tools formatieren, sortieren, flaggen. Menschen urteilen über das Produkt.

Es gibt kein Universal-Preset zum Kopieren. Die richtige Config ist die, die zu deinem Stack, deinem Repo, deinem CI-Budget, deinem Team passt – einmal entschieden, mit dem Code versioniert, identisch auf jedem Laptop, in jeder Agent-Sandbox, in CI, und schnell genug, dass niemand je versucht ist, sie zu umgehen. Hast du das hin, macht jeder das, worin er am besten ist: Tools tun, wofür sie gebaut wurden. Agenten verbraten Iterationen auf Behavior. Menschen verbraten ihre auf das Produkt.

09Die Last Mile: Ein Klick von „Done“ zu „Probier’s aus“

Zurück zu der Ecke: Mergen, ohne selbst durchs Feature geklickt zu haben. Meist nicht Faulheit. Sondern: Ausprobieren ist einfach härter als es sein müsste. Das ist ein CI/CD-Problem, kein Disziplin-Problem.

Agenten schreiben Feature in Minuten. Gut konfigurierte Gates beweisen Minimum Bar Minuten später. Dann erreicht es einen Menschen – und alles stoppt. Um’s zu sehen: Branch checkouten, Dependencies installieren, Tokens ausgraben, Migrationen laufen, Seed-Daten, hoffen dass lokales Setup matcht. Lokale KI-Tools und Skills nehmen etwas Grind weg, aber: Context Switch. Minuten bis Stunden. Grund, es zu skippen.

Da sickert die Speed still aus. Nix gewonnen, wenn Schreiben automatisiert ist, aber Validieren der Flaschenhals bleibt. Gute Gates sagen: „Change ist sound.“ Sie können nicht sagen: „Ist es richtig – für dein Team, für deine User.“ Wenn der Check teuer ist, wird er geskippt. Und die abgeschnittene Ecke wird zum Prozess.

Feature in Minuten schreiben macht dich nicht schnell, wenn Ausprobieren einen Nachmittag frisst.

Also: Ausprobieren zum billigsten Step machen. Jeder Change bekommt sein eigenes Environment, gebaut von der Pipeline:

• Ein Link für jeden Change – oder installierbarer Build für Apps, Desktop, CLIs
• Eigene Daten: Migrationen applied, realistischer Seed, Test-Accounts ready
• Secrets & Integrationen schon verdrahtet, niemand reicht Tokens rum
• Dieselben Gates & Config wie Prod – nur disposable
• Auto Teardown bei Merge oder Close
• Notification, wenn ready – kein Dashboard, das du beobachten musst

Dann schließt sich der Loop, wie er soll. Agent fertig, Gates grün, du kriegst Ping. Klickst Link oder lädst Build runter. Nutzt es wie ein User. Stupst Edge Cases an. Entscheidest – Ship it, oder nächste Schritte & Fokus an Agenten zurück. Minuten. Nicht Nachmittag. Das ist „schnell mit Confidence“: Nicht nur schneller Output. Sondern schnelles, billiges, ehrliches Validieren.

10Warum KI in Enterprise-Workflows klobig wird

Die meisten großen Orgas adoptieren KI gleich: Bestehenden Prozess nehmen – Tickets, Handoffs, Approvals, Sprint-Ceremonies – und jedem Step einen Assistant spendieren. Fühlt sich safe an. Demot gut. Aber: Der Prozess wurde um menschliche Flaschenhälse designed. Ein System bewegt sich nur so schnell wie sein langsamstes Gate.

Einzelne Steps in einem für Menschen gebauten Prozess zu beschleunigen, macht meist die Queues länger. Arbeit wird schneller. Outcome nicht.

Meine Erwartung: Die meisten Firmen, die so rangehen, werden kämpfen, meaningful Improvement zu zeigen. Sie sehen Produktivitäts-Inseln, viele Lizenzen, und eine Delivery-Speed, die verdächtig nach letztem Jahr aussieht. Nicht weil Models nicht gut genug sind – sondern weil die Orga nie redesigned wurde, sie zu nutzen.

11Geteiltes Memory, unterschiedliche Perspektiven

Zwei dieser Reibungen – Context in Köpfen, Tools für Menschen – sind keine Prozess-Probleme. Infrastruktur-Probleme. Mit Infrastruktur-Antworten. Das erste: Memory.

Persönliches Projekt? Memory ist simpel: Claude Code starten, Memory an, es lernt nach und nach Codebase, Conventions, Preferences. Ein Mensch, ein Repo – reicht.

In der Orga bricht das Modell. Jeder Agent startet bei Null. Eigenes Repo. Eigene Sandbox. Eigene Session. Agent im Payments-Service weiß nicht, was Checkout-Team letzte Woche entschied. Agent in Mobile App weiß nicht, dass die API, die er ruft, retired wird. Niemand erinnert sich, warum zwei Produkte einen Login teilen. Jeder Agent: lokal korrekt, global lost.

Also muss Memory Shared Infrastructure werden: Verfügbar für jeden Agent, an jedem Step, across Products & Microservices. Product Principles. Architecture. Contracts zwischen Services. Entscheidungen und ihr Why. Vocabulary. Known Pitfalls. Damit selbst ein Agent in isoliertem Repo/Environment weiß: Andere Produkte existieren. Was sie erwarten. Wie alles zusammenhält. Das fehlende Piece, das die meisten Multi-Repo-Orgas nie hatten – nicht mal für ihre Menschen.

Und es muss von Menschen orchestrierbar sein. Memory ist, wo Menschen at Scale steuern: Falsche Annahme einmal korrigieren → jeder Agent hört auf, sie zu machen. Priority shiften → jeder Agent sieht es. Heißt: Owned, Reviewable, Versioned. Kein Haufen Chat-Transkripte, den niemand editieren kann.

Der Key: Agenten mit Perspektiven. Alle lesen dasselbe Memory. Aber jeder fokussiert einen anderen Aspekt. Einer refined den Goalpost. Einer owned Acceptance. Einer judged Usability. Einer guarded die Seams. Selbe Facts, verschiedene Linsen. Wenn sie disagreen → surfaced es früh, offen, wo ein Mensch es settlen kann – statt spät, in Prod.

12Guardrails: Dein Geschmack, aufgeschrieben

Agenten können viel – genau deshalb müssen sie wissen, was sie NICHT tun sollen. Jedes Product hat seinen eigenen Geschmack an Do’s und Don’ts: Patterns, die du nutzt, die du gebannt hast. Libraries, denen du vertraust. Wie Errors gehandhabt werden. Was nie in Logs geht. Welche Daten nie die Region verlassen. Wie das Interface mit Menschen redet. Wann fragen statt raten.

Diese Regeln verdienen dieselbe Behandlung wie CI/CD-Tooling: Aufgeschrieben. Versioned. Reviewed. Überall automatisch angewendet. Aber ein großer Unterschied: Lint-Config = einmal gesetzt, selten angefasst. Guardrails leben mit dem Product – sie ändern sich, während es reift, das Team lernt, Markt & Regulation sich bewegen. Sie brauchen Owner, History, Platz im regulären Gespräch.

Die letzte Row ist wichtiger, als sie aussieht. Guardrails sollen nicht exklusiv für Agenten sein. Gut geschrieben sind sie das klarste Statement darüber, wie dein Team baut – und halten genauso im Kopf eines Developers. Dieselbe Page, die den Agent stoppt, noch ne State-Lib hinzuzufügen, erinnert den New Hire, warum ihr das nicht tut – und gibt dem Reviewer was Besseres als „Gefällt mir nicht.“

Wenn ne Regel nur im Prompt lebt, ist sie kein Guardrail – sie ist ein Secret.

Was uns zum Step bringt, den die meisten Orgas verpassen: Die richtige Infrastructure für die Architecture. Wenn jedes Team seine eigenen Agenten verdrahtet, endet jedes Repo mit eigener Guardrails-Kopie, eigenen MCP-Servern, eigenen Keys, eigener Idee von „erlaubt“ – ab Tag 1 auseinanderdriftend. Shared Pieces an einen Ort packen: Ein Gateway vor Inference (oder Proxy davor), durch das jeder Agent und jedes Developer-Tool geht.

Da werden Guardrails angewendet. Da wird Memory geservt. Da werden MCP-Server geteilt statt in jedem Repo re-implementiert. Da werden Access, Audit, Cost, Model Choice einmal gemanagt. Guardrail einmal ändern → jeder Agent kriegt’s beim nächsten Request mit. Das ist kein Overhead. Das ist, was 100 Agenten wie ein Team verhalten lässt.

13Was stattdessen funktioniert

Teams, die Step-Changes hinbekommen, fügen KI nicht ihrem Workflow hinzu – sie bauen den Workflow neu, sodass Menschen, Agenten, Gates jeweils das tun, worin sie am besten sind.

1. Intent & Acceptance Criteria upfront definieren – klar genug, dass der Agent weiß, wann er done ist.
2. In Gates investieren, bevor Agenten kommen: Strenges Linting, Types, Tests, CodeQL/Sonar, Preview Builds auf jeder Änderung.
3. Tools fixen lassen, was sie können, bevor committed wird – Formatting, Whitespace, Import/Key-Order – damit CI nie auf Style scheitert und niemand es reviewed.
4. Memory zur Shared Infrastructure machen: Principles, Architecture, Contracts, Decisions für jeden Agent an jedem Step verfügbar – curated & korrigierbar von Menschen.
5. Guardrails wie Config aufschreiben, aber lebendig halten – Owned, Versioned, mit Developern geteilt, aus einem Gateway serviert zusammen mit Memory & MCP-Servern.
6. Agenten echte, scoped Environments geben – Safe für Unattended, easy zum Wegwerfen.
7. Jedem Change ein Preview geben – Link oder installierbarer Build, mit Daten & Secrets verdrahtet – und Ping, wenn ready, damit Human Review vom Diff zum Produkt rutscht.
8. Teams klein & Ownership End-to-End – damit der Loop von Idee zu Shipped nicht über Handoffs zersplittert.
9. Outcomes messen, nicht Output: Zeit schützen für Reflektion, echte User beobachten, Optionen Side-by-Side vergleichen – da wird gut zu großartig.
10. Klein anfangen, End-to-End: Ein Product, ein Team, ein Value Stream richtig redesigned schlägt KI über 100 unveränderte Prozesse gestreut.

Je mehr Arbeit Agenten übernehmen, desto mehr wird der menschliche Part – Geschmack, Urteil, Empathie für die Leute, die das Ding nutzen, und Accountability, wenn es shipped – zum eigentlichen Job.

14Aus der Praxis: Der Staff Engineer

Mensch, ich sitz hier und schau mir an, was gerade in den Teams um mich herum passiert. Und ehrlich? Die Hälfte hätte ich vor einem Jahr noch für Science-Fiction gehalten.

Da ist dieser Senior-Entwickler bei einem Mittelständler in der Nähe von Frankfurt. Letztes Jahr noch Lead Developer. Heute? Er hat sich „degradiert“ – offiziell nur noch „Staff Engineer“. Kein Team mehr, keine Personalverantwortung, keine Sprint-Plannings mehr moderieren. Und verdient trotzdem deutlich mehr als vorher. Weil er endlich das tut, wofür er eigentlich bezahlt wird: Architekturentscheidungen treffen. Produktvision in technische Realität übersetzen. Erfahren genug sein, um zu sagen: „Das wird in sechs Monaten scheitern, weil …“ – und die Agenten dann die Details ausarbeiten lassen, während er schon beim nächsten Hebel ansetzt.

Der Typ tippt kaum noch Code. Er denkt Code. Und die Agenten? Die tippen. Parallel. Zehn Dateien gleichzeitig. Tests dazu. Dokumentation gleich mit. Er reviewt nur noch die Stellen, wo Erfahrung den Unterschied macht: Schnittstellen zwischen Services. Datenmodelle, die überleben müssen. Die eine Abstraktion, die entweder alles trägt oder alles bricht.

Die drei Rollen haben sich nicht in einem Meeting entschieden. Die sind einfach passiert.

Mensch – Intent. Nicht „User Stories schreiben“. Sondern: Mit dem Product Owner am Whiteboard stehen und streiten: „Bauen wir das jetzt oder ziehen wir erst das Technical Debt aus dem Zahlungsmodul? Weil wenn wir das nicht tun, blockiert uns der nächste Feature-Request drei Monate lang.“ Der Stakeholder will alles gestern. Der Mensch übersetzt: „Okay, wir liefern Feature X in zwei Wochen – aber nur, wenn wir gleichzeitig den Refactor im Auth-Service machen. Agent, plan das mal durch.“

Agent – Build. Der kriegt den Auftrag: „Refactor Auth-Service und Feature X parallel. Hier sind die Constraints: Keine Breaking Changes an der API. Tests müssen grün bleiben. Migration muss rollback-fähig sein.“ Und der Agent? Der fängt sofort an. Nicht nach Sprint-Start. Nicht nach Ticket-Refinement. Sofort. Er schreibt den Migrationsplan. Er schreibt die Tests für den neuen Code, bevor der neue Code existiert. Er probiert drei Varianten durch – eine mit Event-Sourcing, eine klassisch, eine hybrid – und legt dem Menschen morgens um 8:30 drei PRs vor: „Option A: sicherer, zwei Wochen. Option B: schneller, technisches Risiko hier. Option C: sauberste Architektur, aber drei Tage mehr Arbeit.“

Gates – Pass/Fail. Die Gates? Die schlafen nicht. Die prüfen jede Variante. Types, Lint, Unit, Integration, E2E, CodeQL, Sonar, Bundle-Size, a11y. Variante B fällt raus – der Security-Scan findet was. Variante A und C laufen durch. Der Mensch klickt sich durch die Previews (die automatisch gebaut wurden, mit echten Daten, echten Secrets, echtem Everything), probiert die Edge Cases aus, nickt bei Option C: „Nimm die. Merge. Ship.“

Während er das entscheidet, haben die Agenten längst angefangen, das nächste Ding vorzubereiten. Weil sie den Kontext haben. Weil sie das Memory teilen. Weil sie wissen: „Ah, der Auth-Refactor ist durch – dann kann ich jetzt das Feature-Flag für die neue Payment-Methode schon mal sauber einbauen.“

15Was das mit Rollen macht

Das Crazy: Das passiert schon. Heute. In echten Firmen.

Nicht in Demos. Nicht in Side-Projects. In Produktionssystemen, die Geld verdienen.

Die normalen Devs? Viele gehen. Nicht, weil sie schlecht sind – sondern weil sie nur coden können. Und Coden ist jetzt die billigste Aktivität im ganzen Stack. Wer „nur“ Tickets abarbeitet, wird ersetzt. Nicht von KI – von einem Senior + Agenten, der das Zehnfache durchzieht.

Die, die bleiben? Die werden wertvoller. Viel wertvoller. Weil ihre Kompetenz plötzlich skaliert. Ein Architect, der früher drei Teams betreuen konnte, betreut jetzt fünfzehn – weil die Agenten die Fleißarbeit machen, die früher Junior-Entwickler gemacht haben. Und die Juniors? Die gibt’s kaum noch. Zumindest nicht im klassischen Sinn. Die Junior-Rolle verschiebt sich: Wer neu anfängt, lernt nicht „Wie schreibe ich eine Funktion?“ – sondern „Wie formuliere ich Intent so präzise, dass der Agent das Richtige baut?“ und „Wie erkenne ich, ob das Ergebnis wirklich gut ist?“

16Menschen arbeiten immer noch mit Menschen

Aber – und das ist der Teil, den die ganzen „KI ersetzt Programmierer“-Artikel nie verstehen – Menschen arbeiten immer noch primär mit Menschen.

Feature-Priorisierung? Ein Agent kann dir eine Liste von 200 Tasks generieren, sauber geschätzt, mit Dependencies, Risiken, Impact-Scores. Beeindruckend. Aber welche davon wir jetzt bauen? Das verhandelt ein Mensch mit Stakeholdern. Das ist Politik. Das ist Vertrauen. Das ist: „Kunde X droht abzuhauen, wenn wir Feature Y nicht nächsten Monat liefern – aber wenn wir Y bauen, brechen wir Z für Kunde A, unseren größten Umsatzbringer. Was tun wir?“

Kein Agent entscheidet das. Kein Agent soll das entscheiden.

Was der Agent kann: Er sagt dir: „Wenn wir Y bauen, brechen wir Z hier und hier – hier sind die betroffenen Tests, hier der Migrationsaufwand, hier drei Optionen, wie wir Z retten können. Option 1 kostet zwei Wochen. Option 2 kostet drei Tage, aber wir brauchen ein Feature-Flag. Option 3: Wir sagen Kunde A, dass er migrieren muss – hier ist der Migrationsleitfaden, den ich schon mal vorbereitet habe.“

Der Mensch entscheidet. In Minuten. Nicht in zwei Wochen Architecture-Review-Meetings.

17Refactor zuerst – mit Zahlen statt Bauchgefühl

Refactoring vor neuem Feature? Früher: „Machen wir später. Jira-Ticket erstellen. Vergessen.“ Heute: Der Agent analysiert die Codebase, findet die Hotspots, simuliert den Impact: „Wenn wir Feature X ohne Refactor bauen, steigt die Change-Failure-Rate im Payment-Modul um 34 %. Der Refactor kostet 4 Agenten-Tage. Feature X allein 6 Tage. Feature X mit Refactor 8 Tage – aber danach ist das nächste Feature 40 % schneller.“ Der Mensch sieht die Zahlen. Nickt. „Mach den Refactor zuerst. Ich sag dem PO, dass Feature X zwei Tage später kommt, aber die nächsten drei Features schneller gehen.“

Und während der Mensch das dem PO erklärt, hat der Agent den Refactor schon gestartet. Nicht „geplant“. Gestartet. Branches erstellt. Tests geschrieben. Erste Commits gepusht. CI läuft. Previews stehen bereit.

18Keine Zukunftsmusik: letzten Dienstag

Das ist keine Zukunftsmusik. Das ist letzten Dienstag passiert. In einem Team, das ich kenne. Fünf Leute. Zwei Senior, ein Mid, zwei „Agenten-Orchestratoren“ – eine neue Rolle mit eigenem Gehaltsband. Sie haben in einer Woche geshippt, wofür sie früher sechs gebraucht hätten. Mit besserer Code-Quality. Weil die Gates nicht müde werden. Weil die Agenten nicht „schnell, schnell“ machen, sondern „richtig, richtig“ – weil der Mensch ihnen gesagt hat, wie „richtig“ aussieht.

Und das Beste? Die Senior-Entwickler gehen wieder mit Freude nach Hause. Nicht, weil sie weniger arbeiten – sondern weil sie das Richtige arbeiten. Architektur. Produkt. Mentoring. Die Entscheidungen, die Erfahrung brauchen. Das Tippen? Erledigen die Agenten. Während der Mensch Kaffee trinkt und mit dem Product Owner streitet.

Die Firmen, die das kapiert haben? Die stellen gerade ein. Nicht „Entwickler“. Architekten mit Agenten-Flotten. Und bezahlen sie entsprechend.

Die Firmen, die noch „KI-Assistenten in Jira integrieren“? Die werden nächstes Jahr fragen, warum ihre Velocity nicht gestiegen ist – während ihre besten Leute kündigen, weil sie woanders für genau die Arbeit, die sie eigentlich gelernt haben, deutlich besser bezahlt werden.

19Die neue Seniorität

Oben ging’s um YAML-Configs. Lefthook-Setups. Gateway-Architekturen für Shared Memory. Guardrails als Code. Preview-Pipelines, die dir für jeden PR einen klickbaren Link in Slack posten.

Aber ehrlich? Das sind nur Werkzeuge. Das eigentliche Spiel findet zwischen den Ohren statt. Und in den Gesprächen am Whiteboard. Und in der Frage, die du dir jeden Morgen stellst:

Was ist heute der Hebel, den nur ich bewegen kann – und wie bringe ich die Agenten dazu, den Rest zu bauen?

Das ist die neue Seniorität. Nicht „Ich codiere am schnellsten“. Sondern: „Ich weiß, was gebaut werden muss – und ich habe die Armee, die es baut, während ich schon den nächsten Hebel suche.“

Genau deshalb designe und baue ich so.