KI macht Umsetzung billig. Urteilsvermögen bleibt knapp.

10 Min. Lesezeit

Die Geschichte vom Ersetzen übersieht die Entscheidung

Angenommen, der Vertrieb verspricht Kunden einen aktuellen Bestellstatus. Der Betrieb aktualisiert das Quellsystem aber nur einmal täglich. Ein weiterer Entwickler kann ein Dashboard bauen. Ein KI-Agent kann bis zum Mittag einen Entwurf liefern. Beides macht das Versprechen nicht wahr. Jemand muss Vertrieb, Betrieb, Produkt und Entwicklung zusammenbringen, klären, was „aktuell“ ehrlich bedeuten kann, und entweder das Versprechen oder den Arbeitsablauf ändern.

Das ist ein Problem des Urteilsvermögens. Wer es als Kapazitätsproblem behandelt, bekommt eine hübsche Anzeige mit den Daten von gestern.

Mehr oder weniger Entwickler sind keine Strategie

Der wiederkehrende Traum vom Ersetzen der Entwickler hat schon viele Kostüme getragen. Lesbare Programmiersprachen, Codegeneratoren, visuelle Werkzeuge, Low-Code-Plattformen und jetzt KI haben echte Reibung beseitigt. Keines dieser Werkzeuge hat die Notwendigkeit beseitigt, Geschäftsregeln, Ausnahmen und Folgen sorgfältig zu durchdenken.

Die gegenteilige Reaktion ist ebenso verlockend: Wenn die Lieferung stockt, stellt man einen weiteren Entwickler ein. Die eine Geschichte will Entwickler durch Technik ersetzen, die andere zusätzliche Entwickler einstellen. Beide können die unbequeme Frage umgehen, warum das bestehende Team nicht vorankommt.

Ist die Arbeit verstanden und kann das Team jemanden einarbeiten, hilft mehr Kapazität. Hat eine begrenzte Aufgabe klare Prüfkriterien, kann KI sie beschleunigen. Nutzen Sie beides dort, wo es passt.

Doch beides ist keine Diagnose. Fragen Sie zuerst:

• Ist das Ziel klar genug, damit es überhaupt jemand umsetzen kann?
• Verstehen Geschäfts- und Technikteam unter der Anforderung dasselbe?
• Kann das System das Versprechen nach dem Release erfüllen?

Fehlen diese Antworten, ändert auch der Wechsel zwischen Menschen und Agenten nichts. Nur die Geschwindigkeit, mit der aus Unklarheit Code wird.

Autonome Agenten lassen das alte Versprechen endgültig klingen

Ein KI-Agent kann eine Codebasis untersuchen, eine Änderung planen, Dateien bearbeiten, Tests ausführen und es erneut versuchen. Das vergrößert die technische Reichweite erheblich. Das Wort autonom klingt, als könnte das System auch das Urteilsvermögen übernehmen, das der Aufgabe ihren Sinn gibt.

Das kann es nicht. Wie der Beitrag Was ein KI-Agent tatsächlich ist erklärt, ist ein Agent ein Modell in einer Software-Schleife mit Werkzeugen, Berechtigungen und einer Abbruchbedingung. Autonomie beschreibt, wie viele Schritte er zwischen menschlichen Entscheidungen gehen darf. Sie überträgt ihm keine Produktverantwortung.

Die Fantasie, KI könne das Unternehmen allein führen hat denselben Fehler im größeren Maßstab: Handlungen lassen sich delegieren, Verantwortung bleibt bei den Menschen, die das System entworfen und freigegeben haben.

Geben Sie dem Agenten den Dashboard-Auftrag, und er baut vielleicht das Dashboard. Lassen Sie ihn den Auftrag hinterfragen, und er entdeckt womöglich, dass gestrige Daten kein Versprechen über einen aktuellen Status tragen. Gut. Vertrieb, Betrieb und Produkt müssen trotzdem entscheiden, welches Versprechen gelten soll. Diese Entscheidung kann der Agent nicht verantworten.

Doch lokale Geschwindigkeit beweist nicht, dass das Gesamtsystem stimmig ist. Ein Unternehmen kann jetzt vor dem Mittag fünf plausible Implementierungen erzeugen und noch immer nicht wissen, welche ins Produkt gehört.

Das Gespräch von Lenny Rachitsky mit Elizabeth Stone, Chief Product and Technology Officer bei Netflix macht dieselbe Unterscheidung: KI liefert Ergebnisse im Überfluss. Systemdenken verhindert, dass Qualität und Richtung in dieser Flut verloren gehen.

Je schneller sich die Teile bewegen, desto mehr schaden schlechte Verbindungen:

• Ein Vertriebsversprechen wird zur Anforderung, ohne dass ein Fachbereich die Verantwortung übernimmt.
• Zwei Teams lösen dasselbe Problem mit unvereinbaren Modellen.
• Ein KI-Prototyp wird ohne klare Verantwortung zur produktiven Software.
• Eine Abkürzung verändert, was das Unternehmen seinen Kunden guten Gewissens versprechen kann.

Der Engpass hat sich verschoben. Tippen war nie der ganze Job. Inzwischen fällt es sogar schwer, noch so zu tun. Knapp ist die Fähigkeit zu entscheiden, was überhaupt entstehen soll, wie es zusammenpasst, wer dafür verantwortlich ist und womit die Organisation nach dem Release leben muss.

Das ist Systemdenken.

Über den ganzen Stack reicht noch nicht über die Fachgrenzen

Die Rückkehr des Generalisten wird oft als technische Erweiterung beschrieben. Frontend-Entwickler lernen das Backend kennen. Backend-Entwickler kümmern sich um Infrastruktur. Alle lernen noch vor dem Frühstück genug KI-Werkzeuge, um gefährlich zu werden.

Nützlich, aber nicht genug.

Die schwierigen Grenzen verlaufen zwischen Kundenverhalten, Vertriebszusagen, fachlichen Regeln, Produktentscheidungen, Architektur, Betrieb und der Art, wie Entscheidungen fallen.

Nehmen wir eine vermeintlich einfache Automatisierung. Das Ticket verlangt einen Genehmigungsschritt.

Wer nur technisch umsetzt, kann den Zustandswechsel implementieren.

Wer das System versteht, stellt andere Fragen:

• Wer darf genehmigen, und worauf gründet sich diese Befugnis?
• Was passiert, wenn diese Person nicht da ist?
• Ist eine genehmigte Handlung endgültig, umkehrbar oder erst für den nächsten Schritt zugelassen?
• Welche Nachweise brauchen Betrieb, Finanzabteilung oder Kunden später?

Das sind keine Unterbrechungen vor der eigentlichen Arbeit.

Das ist die eigentliche Arbeit.

Code macht die Antworten ausführbar. Er macht sie nicht richtig. Oft scheitert die Lieferung bei der Übersetzung zwischen Zuständigkeiten: Eine fachliche Annahme verliert ihren Vorbehalt, ein Termin wird zur Architekturentscheidung oder ein Entwickler löst das Ticket wortgetreu, während der Ablauf kaputt bleibt. Anpassungsfähige Generalisten verfolgen eine Entscheidung über diese Grenzen hinweg und merken, wo sich ihre Bedeutung ändert.

Diese Breite ist kein Mangel an Spezialisierung. Fachgebiete zu verbinden ist die Spezialisierung.

Warum Führungskräfte den Schmerz sehen, aber nicht das Muster

Der CEO sieht verzögerte Vorhaben, steigende Kosten und wandernde Zusagen durch Berichte, die unbequeme Zusammenhänge auslassen. Der CTO sieht mehr Details. Doch ein Vorfall unterbricht eine Architekturentscheidung, eine Personalfrage ein Produktgespräch und ein dringendes Kundenproblem genau die Arbeit, die das nächste Problem verhindern könnte.

Das Team sieht die Ursachen vor Ort: eine instabile Anforderung, ein fragiles Deployment, uneinige Beteiligte, einen Notbehelf, der zum Dauerzustand wird. Niemand hat gleichzeitig Auftrag und Zeit, das Muster über all diese Stellen hinweg zu verfolgen.

Der Organisation fehlt es nicht an Intelligenz. Sie ist nur verteilt, beschäftigt und in Rollen gefangen.

Hilfreiches Urteilsvermögen bleibt nah genug an der Arbeit, um die Wirklichkeit zu prüfen, und unabhängig genug, um routinierte Erklärungen infrage zu stellen. Sein Vorteil ist ungeteilte Aufmerksamkeit: einem Problem durch Entscheidungen, Code, Übergaben und Releases folgen, bis der Engpass sichtbar wird.

Warum die Geschichte vom Ersetzen weiterlebt

Die Geschichte vom Ersetzen schmeichelt einem alten Managementwunsch: Denken und Tun trennen, das Tun billig machen und die bisherigen Entscheidungen unangetastet lassen. Passt die Software danach immer noch nicht zum Geschäft, liegt es angeblich an der Umsetzung. Also sucht man jemand anderen dafür.

Einen weiteren Entwickler einzustellen kann demselben Ausweichen dienen. Es sieht nach Handeln aus, ohne einzugestehen, dass die Aufgabenstellung falsch ist, drei unvereinbare Vorstellungen vom Produkt existieren oder niemand für ein Vertriebsversprechen im Betrieb verantwortlich ist.

Der Rahmen bestimmt, was Menschen und Werkzeuge überhaupt tun dürfen. Bitten Sie sie, das Ticket umzusetzen, dann tun sie das. Bitten Sie sie, die Annahmen dahinter zu prüfen, und sie finden vielleicht den Grund, warum die Lieferung immer wieder am selben Punkt landet.

Die zweite Bitte ist unbequemer. Sie führt durch Vertrieb, Produkt, Entwicklung und Betrieb. Vielleicht zeigt sie, dass ein Team tagelang auf Entscheidungen wartete und dann für wochenlange Lieferzeiten verantwortlich gemacht wurde.

Also verlangt das Unternehmen lieber eine schnellere Implementierung.

Danach kauft es einen Workshop zur Abstimmung.

Offenbar gibt es für Ironie eine eigene Kostenstelle.

Urteilsvermögen muss nah an der Arbeit bleiben

Diese Verbindungen kann ein erfahrener Entwickler herstellen, ein Produktverantwortlicher oder der CTO. Der Titel ist weniger wichtig als das Mandat: einem Problem durch die beteiligten Fachgebiete folgen und eine Aufgabenstellung infrage stellen, die der Wirklichkeit nicht standhält.

So sieht dieses Urteilsvermögen aus:

• erkennen, dass mehrere scheinbar unabhängige Verzögerungen am selben Entscheidungsengpass hängen
• einen wiederkehrenden Fehler auf ungeklärte Verantwortung oder ein fachliches Problem zurückführen
• eine Architekturgrenze von einem Koordinationsproblem unterscheiden
• sehen, wann das Team das bestellte Problem löst, während das Unternehmen ein anderes gelöst braucht

Technische Fähigkeiten erlauben es, Code selbst zu prüfen statt einer Präsentation zu vertrauen und Erklärungen am realen System zu testen. KI kann diese Prüfung beschleunigen. Weder Codekenntnis noch KI-Ergebnisse allein liefern den Geschäftskontext oder die Befugnis zur Entscheidung.

Die Nähe zur praktischen Arbeit hält das Urteil ehrlich. Unabhängigkeit und geschützte Zeit machen das Muster sichtbar.

Warum sich das wirtschaftlich lohnt

Ein CEO sollte bei einem Plan misstrauisch sein, der Agenten-Output oder eingesparte Stellen meldet, während Nacharbeit und Lieferzeiten gleich bleiben. Entscheidend sind konkrete Ergebnisse im Betrieb.

Das Unternehmen sollte Folgendes sehen:

• weniger Vorhaben, die zwischen Geschäftsentscheidungen und technischer Arbeit feststecken
• weniger bezahlte Kapazität, die in Nacharbeit und missverstandenen Anforderungen verschwindet
• frühere Warnungen vor Zusagen, die das Liefersystem nicht sicher erfüllen kann
• funktionierende Software, die Kunden und Betrieb schneller erreicht

Weniger Stellen und mehr Agenten-Ergebnisse lassen sich leicht zählen. Beides beweist nicht, dass sich Durchlaufzeit, Zuverlässigkeit von Releases oder Kundenergebnisse verbessert haben.

Der wirtschaftliche Unterschied ist einfach: Mehr Menschen oder mehr Automatisierung erhöhen, was das bestehende Liefersystem versuchen kann. Besseres Urteilsvermögen kann verändern, warum es überhaupt ständig Zeit verliert.

Der CTO bleibt die technische Führungskraft

Die Fiktion des autonomen Agenten verführt dazu, eine lange Folge von Werkzeugaufrufen mit abgegebener Verantwortung zu verwechseln. Die Organisation hat die Aufgabe gestellt, Werkzeuge angebunden, Berechtigungen erteilt und entschieden, wo die Schleife zur Prüfung anhalten muss.

Der CTO bleibt für die technische Organisation und ihre Richtung verantwortlich. Fachexperten bleiben für fachliche Richtigkeit verantwortlich. Produktverantwortliche entscheiden über das Produkt. Entwickler verantworten die Qualität ihrer Arbeit.

Der CTO muss nicht jeden Werkzeugaufruf genehmigen. Er muss aber Berechtigungen, Prüfpunkte und Nachweise festlegen und dem Team Raum geben, Widersprüche sichtbar zu machen. Wenn ein Agent eine falsche Annahme meldet, müssen die zuständigen Menschen entscheiden, was sich ändert. Es geht darum, diese Entscheidung sichtbar zu machen und direkt in der Arbeit darauf zu reagieren.

Erst verstehen, dann ergänzen oder ersetzen

Stellen Sie einen weiteren Entwickler ein, wenn die Arbeit verstanden ist und das Team zusätzliche Kapazität in nützliche Ergebnisse verwandeln kann. Nutzen Sie einen Agenten, wenn die Aufgabe begrenzt, das Ergebnis überprüfbar und seine Berechtigungen und Abbruchbedingungen klar sind. Das sind echte Einsatzmöglichkeiten, keine allgemeinen Antworten.

Geschütztes Urteilsvermögen über Fachgrenzen hinweg wird wichtiger, wenn:

• mehr Leute weder die Durchlaufzeit noch die Zuverlässigkeit von Releases verbessert haben
• Führungskräfte unterschiedliche Vorstellungen vom Problem haben
• kritische Releases von Heldentaten, Erinnerung oder manuellen Eingriffen abhängen
• Sie nicht erklären können, ob der Engpass bei Kapazität, Entscheidungen, Architektur, Verantwortung oder der Arbeitsweise liegt

Menschen und Agenten können zusammenarbeiten. Manchmal ist die sinnvolle Reihenfolge, erst den tatsächlichen Engpass sichtbar zu machen, den Lieferweg zu reparieren und dann Menschen oder Automatisierung dort einzusetzen, wo sie endlich helfen.

Wenn Sie noch nicht verstehen, warum die Lieferung stockt, sind weder eine neue Stelle noch eine Agenten-Demo die vorsichtige Wahl.

Beides kann dazu dienen, die schwierige Frage aufzuschieben.

Urteilsvermögen braucht Zugang

Wenn Sie nur technische Umsetzung wollen, definieren Sie die Aufgabe, ihre Prüfkriterien und die Verantwortung. Wählen Sie dann die passenden Menschen und Werkzeuge. Es ist nichts Verwerfliches daran, den Bedarf ehrlich zu benennen.

Wenn jemand die Lieferung über Geschäft, Fachbereich, Produkt, Technologie und Betrieb hinweg verbessern soll, sperren Sie ihn nicht in die technische Ecke. Geben Sie Zugang zu den Annahmen, Fachexperten, gegensätzlichen Interessen und Entscheidungen, die die Arbeit schon vor dem Backlog prägen.

Messen Sie das Ergebnis dann am Gesamtsystem:

• weniger Nacharbeit durch missverstandene Bedürfnisse
• kürzere Zeit von der Entscheidung bis zur nützlichen Software
• sicherere Releases und schnellere Erholung nach Störungen
• bessere Akzeptanz, weil die Software zum wirklichen Ablauf passt

KI wird immer mehr Ergebnisse verfügbar machen. Das bedeutet nicht, dass die Organisation besser darin wird zu entscheiden, Verbindungen herzustellen und Verantwortung zu übernehmen.

Unternehmen, die den Unterschied verstehen, werden nicht bloß mehr Artefakte ausliefern. Sie bauen Systeme, die auch dann noch sinnvoll sind, wenn alle schnell gearbeitet haben.

Dafür braucht es technische Fähigkeiten.

Und das Urteilsvermögen zu erkennen, wann Technologie nicht das einzige Fachgebiet am Tisch ist.