KI-Coding macht Senior Engineering zu Agentenmanagement

KI-Coding ist in einer interessanteren Phase angekommen als reiner Codegenerierung.

Die erste Frage war einfach: Kann das Tool brauchbaren Code schreiben? Für viele Teams lautet die Antwort inzwischen ja. Claude Code, Cursor, Replit, Devin, Lovable und ähnliche Werkzeuge können Oberflächen bauen, Bugs untersuchen, Tests schreiben, Komponenten refactoren und fremde Codebasen erstaunlich schnell erschließen.

Das heißt nicht, dass der schwierige Teil von Software verschwunden ist.

Es heißt, dass sich der Engpass verschiebt.

In den letzten 24 Stunden wurde auf X intensiv über Claude Code und die Idee diskutiert, dass Software Engineering zunehmend zu Agentenmanagement wird. Der interessante Punkt ist nicht der Satz selbst. Interessant ist die praktische Konsequenz: Wenn ein KI-Agent Branches, Diffs, Tests und Implementierungsversuche schneller erzeugen kann, als ein Mensch tippen kann, verschiebt sich Senior Engineering vom Schreiben jeder einzelnen Zeile zur Steuerung des Systems, das diese Zeilen erzeugt, prüft und integriert.

Für Gründer, CTOs, Product Owner und Mittelstandsteams ist das deutlich wichtiger als der nächste Benchmark.

Die Frage ist nicht mehr nur: “Welches KI-Coding-Tool sollten wir einsetzen?”

Die bessere Frage lautet: “Wer managt die Agenten, und worauf werden sie gesteuert?”

Entwickler werden nicht durch ein Chatfenster ersetzt

Eine naheliegende, aber schwache Interpretation von KI-Coding lautet: Entwickler werden weniger wichtig.

Das ist nicht das, was ernsthafte Teams gerade lernen.

Was sich verändert, ist die Form der Arbeit. Ein fähiger Agent kann ein kleines Feature umsetzen, einen Bug untersuchen, eine Testsuite entwerfen, wiederkehrende Muster migrieren oder ein Refactoring vorschlagen. Er kann das schnell tun, manchmal parallel, manchmal über Nacht, manchmal über eine Codebasis hinweg, die für eine einzelne Person schwer vollständig zu überblicken ist.

Aber der Agent braucht weiterhin Führung.

Er muss wissen, was wichtig ist und was nicht. Er braucht eine Aufgabe, die klein genug ist, um abgeschlossen zu werden, aber relevant genug, um Wert zu schaffen. Er braucht die richtigen Dateien, die richtigen Einschränkungen, den richtigen Testbefehl, eine klare Definition of Done und sinnvolle Grenzen um das Risiko.

Das sind keine Tipp-Probleme.

Das sind Probleme technischer Urteilskraft.

Deshalb werden erfahrene Menschen in einem agentengestützten Workflow wichtiger, nicht unwichtiger. Sie können ein vages Produktziel in sichere technische Schritte zerlegen. Sie erkennen, wann eine scheinbar elegante Abkürzung die Wartbarkeit beschädigt. Sie reviewen einen Diff nicht nur auf Syntax, sondern auf architektonische Richtung. Sie entscheiden, ob der Agent das richtige Problem gelöst oder nur plausible Bewegung erzeugt hat.

KI-Coding macht Low-Context-Implementierung günstiger.

Es macht High-Context-Urteilskraft wertvoller.

Agentenmanagement ist zuerst Scope-Management

Die erste Fähigkeit im Agentenmanagement ist Scope.

Ein menschlicher Entwickler kann eine unklare Aufgabe manchmal auffangen, weil er innehält, nachfragt und sozialen Kontext aus früheren Gesprächen mitbringt. Ein Agent versucht oft sofort, Fortschritt zu erzeugen. Das ist nützlich, wenn die Aufgabe klar ist. Es wird teuer, wenn die Aufgabe unscharf ist.

“Verbessere das Onboarding” ist keine gute Agentenaufgabe.

“Ergänze im Onboarding-Checklist-Empty-State einen Hinweis, wenn keine Integrationen existieren, behalte das bestehende Layout bei, füge einen Regressionstest hinzu und ändere den API-Vertrag nicht” ist deutlich besser.

Der Unterschied ist nicht Prompt-Magie. Der Unterschied ist Produkt- und Engineering-Klarheit.

Gutes Agentenmanagement definiert:

• welches Nutzerergebnis erreicht werden soll;
• welchen Teil der Codebasis der Agent anfassen darf;
• welche Dateien oder Module außerhalb des Scopes liegen;
• welche Test- oder Review-Evidenz nötig ist;
• wie viel Designfreiheit erlaubt ist;
• welche Risiken menschliche Freigabe brauchen;
• wann der Agent stoppen und nachfragen soll.

Hier werden viele Teams entweder Hebel gewinnen oder Lärm erzeugen.

Wenn jede Agentenaufgabe in einer breiten Exploration, einem ausufernden Diff und einer langen Review-Diskussion endet, hat das Tool die Lieferung nicht beschleunigt. Es hat die Arbeit in die Bereinigung verschoben. Wenn die Aufgabe sauber geschnitten ist, kann der Agent ein nützlicher Implementierungspartner werden.

Bei McDougall Digital ist das einer der Gründe, warum wir mit Architektur und Produkturteil starten, bevor wir automatisieren. KI kann schnell arbeiten, aber sie arbeitet am besten innerhalb einer klaren Form. Ohne diese Form wird Geschwindigkeit zu Reibung.

Review wird zum Zentrum des Workflows

Wenn Agenten mehr Code erzeugen, wird Review wichtiger.

Das klingt offensichtlich. Genau hier scheitern viele KI-Experimente trotzdem leise.

Teams freuen sich über Generierungsgeschwindigkeit und unterschätzen die Integrationskosten. Ein Tool erzeugt fünf mögliche Umsetzungen. Jetzt muss ein Entwickler sie prüfen, Annahmen verstehen, Tests ausführen, Ansätze vergleichen und entscheiden, was ins Produkt gehört. Wenn dem Team klare Review-Standards fehlen, hat der Agent mehr Arbeit erzeugt, nicht weniger.

In einem reifen agentengestützten Workflow ist Review nicht der bürokratische letzte Schritt. Review ist das Zentrum der Schleife.

Der Agent schlägt vor. Das System testet. Der Mensch prüft Intention, Architektur und Risiko. Der Agent überarbeitet. Der Mensch entscheidet, ob das Ergebnis ins Produkt gehört.

Das verändert, was Teams messen sollten.

Generierte Codezeilen sind keine hilfreiche Metrik. Anzahl der Agentensessions ist keine hilfreiche Metrik. Selbst Pull-Request-Volumen kann täuschen, wenn die Arbeit fragmentiert oder oberflächlich ist.

Bessere Fragen sind:

• Hat der Agent die Durchlaufzeit für klar geschnittene Arbeit reduziert?
• Ist die Review-Last vernünftig geblieben?
• Hat sich Testabdeckung verbessert oder verschlechtert?
• Ist die Architektur kohärent geblieben?
• Erkennt das Team mehr Probleme vor Produktion?
• Werden Produktentscheidungen klarer oder unklarer?

KI-Coding macht es leicht, mehr Softwareaktivität zu erzeugen.

Kunden brauchen nicht mehr Aktivität. Sie brauchen verlässlichen Fortschritt.

Senior Engineers werden Workflow-Designer

Die interessanteste Senior-Engineering-Arbeit in einem KI-gestützten Team kann Workflow-Design werden.

Nicht im abstrakten Enterprise-Prozess-Sinn. Sondern ganz praktisch: Wie bewegt sich Arbeit von einer Idee bis in Produktion?

Welche Aufgaben darf ein Agent allein versuchen? Welche brauchen zuerst eine Planungsphase? Welche Änderungen benötigen eine von Menschen geschriebene technische Notiz? Welche Dateien sind sensibel? Welche Befehle dürfen automatisch laufen? Welche Tests sind vor einem Pull Request verpflichtend? Welche Teile der Codebasis brauchen strengere Ownership?

Diese Entscheidungen prägen das Ergebnis oft stärker als das Modell.

Ein schwacher Workflow verwandelt einen starken Agenten in eine Quelle zufälliger Diffs.

Ein starker Workflow macht denselben Agenten zu einem nützlichen Teil des Delivery-Systems.

Ein Team kann zum Beispiel unterschiedliche Spuren definieren:

• Exploration, bei der der Agent Code liest und eine kurze technische Notiz erstellt;
• Implementierung, bei der der Agent einen eng begrenzten Produktbereich ändert;
• Tests, bei denen der Agent Regression Coverage für bekanntes Verhalten ergänzt;
• Refactoring, bei dem der Agent nur innerhalb vereinbarter Grenzen arbeitet;
• Operations, bei denen der Agent Logs untersucht, aber nicht auf Produktionssysteme wirkt.

Jede Spur braucht andere Berechtigungen, Review-Erwartungen und Erfolgskriterien.

Das muss nicht schwergewichtig sein. Ein kleines SaaS-Team kann mit einfachen Templates und Branch-Regeln starten. Ein Mittelstandsteam mit Compliance-Pflichten braucht eventuell stärkere Audit Trails, Zugriffskontrollen und Freigabepunkte. Das Prinzip ist gleich: Die Freiheit des Agenten muss zum Risiko der Aufgabe passen.

Das ist Engineering Management in der Agenten-Ära.

Produkturteil gewinnt weiterhin

Im KI-Coding-Hype steckt noch ein anderes Risiko: Implementierungsgeschwindigkeit wird mit Produktfortschritt verwechselt.

Ein Agent kann ein Feature entstehen lassen. Das heißt nicht, dass dieses Feature existieren sollte.

Er kann eine Einstellungsseite bauen, ein Dashboard-Widget ergänzen, eine Integration verdrahten, ein Admin-Tool generieren oder einen polierten Prototyp liefern. Das Ergebnis kann echt genug aussehen, um Momentum zu erzeugen. Aber Produktarbeit besteht nicht nur darin, Dinge möglich zu machen. Produktarbeit besteht darin, zu entscheiden, was es wert ist gebaut zu werden, was vereinfacht werden sollte und was besser weggelassen wird.

Das ist besonders relevant für Gründer.

KI-Coding senkt die Kosten, Ideen auszuprobieren. Das ist nützlich. Es senkt aber auch die Kosten, das Produkt zu überladen, halb verantwortete Features einzubauen und technische Verpflichtungen zu erzeugen, bevor der Business Case klar ist.

Die besten Teams werden Agenten nutzen, um mehr Optionen zu erkunden, und gleichzeitig strenger werden bei dem, was in Produktion kommt.

Sie trennen Prototypgeschwindigkeit von Produktverpflichtung. Sie fragen, ob ein Feature Aktivierung, Retention, operative Effizienz oder Kundenvertrauen verbessert. Sie prüfen, ob die Architektur es tragen kann. Sie entfernen experimentellen Code, der seinen Platz nicht verdient.

Agentenmanagement ist nicht nur technische Kontrolle.

Es ist Produktkontrolle.

Was ernsthafte Teams jetzt tun sollten

Der praktische Schritt ist nicht, KI-Coding zu verbieten oder jeden improvisieren zu lassen.

Der praktische Schritt ist, es als Operating Model einzuführen.

Starten Sie mit wenigen Use Cases, bei denen das Risiko niedrig und Feedback klar ist. Bug-Analysen. Testgenerierung. Verbesserungen interner Tools. Dokumentationsupdates. Enge UI-Änderungen. Refactorings in gut verstandenen Modulen.

Definieren Sie dann die Schleife:

• wie die Aufgabe geschrieben wird;
• welchen Kontext der Agent bekommt;
• was der Agent ändern darf;
• welche Befehle er ausführen darf;
• welche Evidenz er liefern muss;
• wer das Ergebnis reviewt;
• wie das Team aus Fehlern lernt.

Danach kann der Einsatz schrittweise wachsen.

Das Ziel ist nicht, dass alle Entwickler “mehr KI nutzen”. Das Ziel ist, KI-gestützte Lieferung verlässlicher zu machen als spontane Begeisterung.

Hier kann McDougall Digital helfen. Wir arbeiten mit Teams, die die Geschwindigkeit von KI-gestützter Entwicklung nutzen möchten, ohne Architektur, Wartbarkeit oder Produkturteil zu verlieren. Das bedeutet oft: zuerst den Delivery-Workflow entwerfen. Wo gehören Agenten hinein? Wo behalten Menschen die Kontrolle? Wo sind Review-Gates wichtig? Und wie werden Prototypen zu Systemen, die echte Kunden aushalten?

KI-Coding ist inzwischen stark genug, dass Ignorieren teuer wird.

Aber Einführung ohne Management wird ebenfalls teuer.

Gewinnen werden nicht die Teams, die den meisten Code generieren.

Gewinnen werden die Teams, die lernen, Agenten auf das richtige Produkt auszurichten, innerhalb der richtigen Architektur und mit dem richtigen Maß an Kontrolle.