Automatisierungsschulden: Warum zu schnelles Automatisieren mehr Arbeit schafft, als es spart

Kurzfassung. Jede Automatisierung ist ein Kredit. Heute bekommen Sie Zeit zurück, später zahlen Sie Zinsen: für das Prüfen von Ergebnissen, das Behandeln von Ausnahmen, das Reparieren von Ausfällen und dafür, dass noch jemand die Aufgabe von Hand erledigen kann. Den offenen Saldo nennen wir Automatisierungsschulden. Die Belege dafür, dass diese Zinsen real sind, sind stark: In einer randomisierten Studie sagten erfahrene Open-Source-Entwickler voraus, dass KI-Tools ihre Bearbeitungszeit um 24 % verkürzen würden, und brauchten tatsächlich 19 % länger; Googles DORA-Bericht 2024 schätzt, dass jeder Anstieg der KI-Nutzung um 25 % mit einem Rückgang des Liefer-Durchsatzes um 1,5 % und der Lieferstabilität um 7,2 % einhergeht; und 66 % der Entwickler in der Stack-Overflow-Umfrage 2025 nennen KI-Ergebnisse, die „fast richtig, aber eben nicht ganz“ sind, als größtes Ärgernis. Unser Break-even-Modell für fünf gängige Automatisierungen zeigt: Sobald Prüfung, Ausnahmen und Wartung eingerechnet werden, amortisieren sich zwei davon nie, und eine dritte braucht mehr als drei Jahre. Die Lösung ist nicht weniger Automatisierung. Es ist das Urteilsvermögen eines Eigentümers darüber, was automatisiert wird, plus die Disziplin des Studenten, einen Prozess erst von Hand zu lernen, bevor man ihn einer Maschine übergibt.

Der Kredit, den niemand verbucht

Ward Cunningham führte die Schulden-Metapher 1992 in seinem OOPSLA-Erfahrungsbericht über das Portfoliosystem WyCash ein. Code in erster Fassung auszuliefern, schrieb er, sei wie Schulden aufzunehmen: Ein wenig Schulden beschleunigt die Entwicklung, solange sie zügig zurückgezahlt werden, doch jede Minute, die man mit nicht ganz richtigem Code verbringt, zählt als Zins, und eine Organisation kann unter dieser Last zum Stillstand kommen. Dreiundzwanzig Jahre später übertrug ein Google-Team um D. Sculley denselben Blick auf maschinelles Lernen, im NeurIPS-Paper „Hidden Technical Debt in Machine Learning Systems“. Ihre einleitende Warnung passt auf jedes Automatisierungsprojekt: Es sei gefährlich, schnelle Erfolge für kostenlos zu halten, denn reale Systeme verursachen häufig „massive laufende Wartungskosten“. Sie ergänzen, dass nicht alle Schulden schlecht sind, aber alle Schulden bedient werden müssen, und dass versteckte Schulden gefährlich sind, weil sie sich still verzinsen.

Automatisierungsschulden sind dasselbe Phänomen auf der Ebene des Arbeitsablaufs einer Einzelperson oder eines Teams. Ein Zap, ein Skript, ein KI-Agent, eine Mailregel oder ein Tabellenmakro entfernt jeweils eine sichtbare Aufgabe und schafft weniger sichtbare:

• jemand muss prüfen, ob das Ergebnis stimmt;
• jemand muss die Fälle auffangen, die die Automatisierung nicht bewältigt;
• jemand muss sie reparieren, wenn sich eine API, ein Formular, ein Spaltenname oder ein Modell ändert;
• jemand muss wissen, wie der Prozess funktioniert, für den Tag, an dem die Automatisierung ausfällt.

Wenn diese vier Aufgaben niemandem gehören, sieht die Automatisierung am Tag des Starts wie reiner Gewinn aus und wird danach zum schleichenden Abfluss. Das Tückische: Der Abfluss taucht selten dort auf, wo die Ersparnis verbucht wird. Wer den Ablauf gebaut hat, meldet die gesparten Stunden; wer die Fehler bereinigt, meldet nichts, weil niemand gefragt hat.

Was die Evidenz über versteckte Zinsen sagt

Drei unabhängige Datensätze, aus einer randomisierten Studie, einer großen Branchenumfrage und einer sehr großen Entwicklerumfrage, zeigen in dieselbe Richtung. Tabelle 1 enthält nur Zahlen, die wir in den Primärdokumenten bestätigt haben.

Tabelle 1. Belege dafür, dass Automatisierung versteckte Kosten verursacht (verifizierte Daten)

Quelle	Stichprobe	Befund
METR, randomisierte kontrollierte Studie (Becker et al., 2025)	16 erfahrene Entwickler, 246 reale Aufgaben in ausgereiften Open-Source-Projekten	Die Entwickler erwarteten, dass KI die Bearbeitungszeit um 24 % senkt; im Nachhinein schätzten sie eine Senkung um 20 %; gemessen wurde eine Verlängerung der Bearbeitungszeit um 19 %
Dieselbe Studie, Zuverlässigkeitsanalyse (Appendix C.1.4)	Bildschirmaufzeichnungen von 44 Issues mit gültigen Labels	Die Entwickler übernahmen weniger als 44 % der KI-Generierungen und verbrachten rund 9 % der Zeit mit KI-Erlaubnis damit, KI-Ergebnisse zu prüfen und zu bereinigen; 75 % gaben an, jede Zeile des KI-Codes zu lesen
Google DORA, Accelerate State of DevOps 2024	Knapp 3.000 Fachleute, 2024 befragt	Pro 25 % mehr KI-Nutzung: Liefer-Durchsatz geschätzt -1,5 %, Lieferstabilität -7,2 %, Zeit für wertvolle Arbeit -2,6 %, Zeit für mühsame Routinearbeit +0,4 %
Google DORA 2024, Vertrauen	Dieselbe Umfrage	39,2 % gaben wenig (27,3 %) oder kein (11,9 %) Vertrauen in die Qualität von KI-generiertem Code an
Stack Overflow Developer Survey 2025	Zehntausende Entwickler (33.244 beantworteten die Vertrauensfrage)	46 % misstrauen der Genauigkeit von KI-Tools, 33 % vertrauen ihr; 66 % nennen „fast richtig, aber eben nicht ganz“ als Ärgernis, und 45,2 % sagen, das Debuggen von KI-generiertem Code sei zeitaufwendiger; 20 % sagen, sie seien in ihre eigene Problemlösungsfähigkeit weniger zuversichtlich geworden

Zusammen gelesen beschreiben die Zahlen die Anatomie von Automatisierungsschulden.

Die Wahrnehmungslücke ist die erste Zinszahlung. Die Entwickler in der METR-Studie waren keine Anfänger: Sie hatten im Schnitt fünf Jahre Erfahrung mit den Repositories, an denen sie arbeiteten, und glaubten auch nach der Studie noch, KI habe sie schneller gemacht. Wenn Experten sogar das Vorzeichen des Effekts auf ihre eigene Arbeit falsch einschätzen, ist eine beiläufige Schätzung der „gesparten Stunden“ durch eine neue Automatisierung ein schwacher Beleg. Die Autoren betonen, dass ihr Ergebnis für ein bestimmtes Umfeld gilt (erfahrene Entwickler, große ausgereifte Codebasen, Tools von Anfang 2025), und es sollte nicht als „KI bremst alle aus“ gelesen werden. Die übertragbare Lehre ist enger und nützlicher: Gefühlte Geschwindigkeit ist keine gemessene Geschwindigkeit.

Prüfung ist ein wiederkehrender Kostenblock, kein einmaliger. Weniger als die Hälfte der Generierungen übernehmen, rund ein Zehntel der Zeit mit Prüfen und Bereinigen verbringen und jede Zeile lesen: So sieht Prüfen aus, wenn der Verantwortliche hohe Ansprüche hat. Die Stack-Overflow-Daten zeigen dasselbe Muster über Zehntausende Entwickler hinweg: Fast richtige Ergebnisse sind teuer, weil man sie finden, verstehen und korrigieren muss.

Lokale Geschwindigkeit kann den Systemergebnissen schaden. Der DORA-Befund ist der am wenigsten intuitive. KI-Nutzung ging mit besserer Dokumentationsqualität, besserer Codequalität und höherer individueller Produktivität einher, aber mit schlechterem Liefer-Durchsatz und geringerer Stabilität. Die Hypothese des Berichts: Schnellere Generierung verleitete Teams dazu, eines der grundlegendsten DORA-Prinzipien zu vergessen, kleine Batch-Größen. Wenn KI es erlaubt, in derselben Zeit mehr Code zu produzieren, werden Changelists vermutlich größer, und DORA hat immer wieder festgestellt, dass größere Änderungen langsamer und anfälliger für Instabilität sind. Außerdem sank die Zeit für wertvolle Arbeit, während die Zeit für Routinearbeit unverändert blieb, also das Gegenteil dessen, was Automatisierung verspricht. Für alle, die einen Arbeitsablauf automatisieren, ist das die Warnung: Schnellere Schritte garantieren kein schnelleres System.

Diese Befunde stammen aus der Softwareentwicklung, wo die Messung ungewöhnlich gut ist. Wir nutzen sie als den am besten gemessenen Fall eines Musters, das die Human-Factors-Forschung schon Jahrzehnte zuvor für Automatisierung im Allgemeinen beschrieben hat; darauf kommen wir weiter unten zurück.

Die echte ROI-Rechnung: ein Break-even-Modell

Die meisten Automatisierungsentscheidungen beruhen auf einer naiven Rechnung: gesparte Minuten pro Durchlauf mal Durchläufe pro Jahr, abzüglich der Bauzeit. Tabelle 2 rechnet fünf gängige Automatisierungen der Wissensarbeit mit drei zusätzlichen Termen neu: Prüfminuten pro Durchlauf, eine Ausnahmequote mit manueller Bearbeitungszeit und Wartungsstunden pro Monat. Die Eingaben sind illustrative Annahmen, die für ein kleines Team realistisch gewählt sind, keine Messwerte; entscheidend ist die Form des Ergebnisses, und Sie können die Rechnung mit Ihren eigenen Zahlen wiederholen.

Tabelle 2. CEOtudent-Berechnung: naiver vs. tatsächlicher Ertrag im ersten Jahr für fünf Automatisierungen (Stunden)

Automatisierung	Gesparte Minuten pro Durchlauf	Durchläufe pro Jahr	Bauzeit (Stunden)	Naive Bruttoersparnis	Naives Netto Jahr 1	Versteckte Kosten (Anteil am Brutto)	Tatsächliches Netto Jahr 1	Naiver Break-even (Wochen)	Tatsächlicher Break-even (Wochen)
Wöchentliche Berichtserstellung	45	52	6	39,0	+33,0	23,3 (60 %)	+9,7	8,0	19,8
Tägliche Posteingangs-Triage	10	260	8	43,3	+35,3	51,1 (118 %)	-15,8	9,6	nie
Monatlicher Rechnungsabgleich	120	12	12	24,0	+12,0	20,4 (85 %)	-8,4	26,0	173,3
CRM-Anreicherung pro Lead	3	2.080	10	104,0	+94,0	88,0 (85 %)	+6,0	5,0	32,5
Quartalsweise Formatierung der Board-Unterlagen	90	4	10	6,0	-4,0	8,3 (139 %)	-12,3	86,7	nie

Annahmen (Prüfminuten pro Durchlauf / Ausnahmequote x manuelle Minuten pro Ausnahme / Wartungsstunden pro Monat): Wochenbericht 10 / 10 % x 30 / 1; Posteingangs-Triage 4 / 15 % x 15 / 2; Rechnungsabgleich 30 / 20 % x 60 / 1; CRM-Anreicherung 1 / 5 % x 10 / 3; Board-Unterlagen 20 / 25 % x 60 / 0,5. Versteckte Kosten = Prüfung + Ausnahmen + Wartung pro Jahr. Tatsächlicher Break-even = Bauzeit geteilt durch die wiederkehrende Nettoersparnis pro Jahr, mal 52; „nie“ bedeutet, dass die wiederkehrende Nettoersparnis null oder negativ ist.

Vier Muster fallen auf.

1. Jede naive Rechnung sah nach einem Gewinn aus, bis auf eine. Vier der fünf zeigen nach der naiven Methode ein positives Netto im ersten Jahr. Nach der tatsächlichen Methode bleiben nur zwei positiv, und beide schrumpfen deutlich: Der Wochenbericht fällt von +33,0 auf +9,7 Stunden, die CRM-Anreicherung von +94,0 auf +6,0.
2. Hohe Frequenz rettet keine störanfällige Aufgabe. Die Posteingangs-Triage läuft 260 Mal im Jahr und spart jedes Mal 10 Minuten, doch vier Minuten Prüfung pro Durchlauf, eine Ausnahmequote von 15 % und zwei Stunden Regelpflege im Monat verbrauchen 118 % der Bruttoersparnis. Sie amortisiert sich nie.
3. Geringe Frequenz plus hohe Baukosten ist die klassische Falle. Die quartalsweisen Board-Unterlagen amortisieren sich nicht einmal nach der naiven Methode, und jeder Durchlauf hat eine Wahrscheinlichkeit von eins zu vier, eine Stunde manuelle Rettung zu erfordern.
4. Wartung ist der entscheidende Term. Die Rechnungsautomatisierung springt von einer naiven Amortisation in sechs Monaten auf mehr als drei Jahre, vor allem wegen 12 Stunden Wartung pro Jahr bei nur 24 Stunden Bruttoersparnis.

Tabelle 3 zeigt, wie empfindlich selbst eine solide Automatisierung auf die beiden versteckten Terme reagiert, die am häufigsten vergessen werden.

Tabelle 3. CEOtudent-Berechnung: tatsächliche Nettostunden im ersten Jahr für die Wochenbericht-Automatisierung, nach Wartungs- und Prüfaufwand

Wartungsstunden pro Monat	0 Min. Prüfung pro Durchlauf	10 Min.	20 Min.	30 Min.
0	+30,4	+21,7	+13,1	+4,4
0,5	+24,4	+15,7	+7,1	-1,6
1	+18,4	+9,7	+1,1	-7,6
2	+6,4	-2,3	-10,9	-19,6
3	-5,6	-14,3	-22,9	-31,6

Konstant gehalten: 45 gesparte Minuten pro Durchlauf, 52 Durchläufe pro Jahr, 6 Stunden Bauzeit und eine Ausnahmequote von 10 % bei je 30 Minuten.

Dieselbe Automatisierung reicht von 30 Stunden Gewinn bis 32 Stunden Verlust, abhängig von zwei Zahlen, die selten in einem Business Case auftauchen. Wenn Sie diese noch nicht schätzen können, wissen Sie nicht genug über den Prozess, um ihn zu automatisieren. Das ist der Kern der folgenden Argumentation.

Die sechs Komponenten von Automatisierungsschulden

Die Schulden haben mehr als eine Quelle. Tabelle 4 benennt die Komponenten, die wir verwenden, wie jede davon im Arbeitsalltag aussieht und welche Forschung sie jeweils widerspiegelt.

Tabelle 4. CEOtudent-Redaktionsrahmen: die sechs Komponenten von Automatisierungsschulden

Komponente	Was sich ansammelt	Frühes Warnsignal	Echo in der Forschung
1. Wartungsschulden	Reparaturen, wenn sich Eingaben, Tools, APIs, Prompts oder Modelle ändern	„Schon wieder kaputt“ taucht öfter als einmal pro Quartal im Chat auf	Sculley et al.: Glue Code und „Changing Anything Changes Everything“
2. Ausnahmeschulden	Manuelle Bearbeitung von Fällen, die die Automatisierung nicht verarbeiten kann	Ein wachsender Ordner „muss geprüft werden“, den niemand leert	Bainbridge: Dem Bediener bleiben die Aufgaben, die der Entwickler nicht automatisieren konnte
3. Prüfschulden	Zeit für das Prüfen von Ergebnissen, die fast richtig sind	Sie lesen jedes Ergebnis „sicherheitshalber“ noch einmal	METR: unter 44 % der Generierungen übernommen, rund 9 % der Zeit für Prüfung
4. Abhängigkeitsschulden	Versteckte Kopplung: Andere Abläufe oder Personen verlassen sich auf das Ergebnis	Jemand, mit dem Sie nicht gerechnet haben, beschwert sich, wenn es stoppt	Sculley et al.: nicht deklarierte Konsumenten und versteckte Rückkopplungsschleifen
5. Kompetenzschulden	Verlust der Fähigkeit, die Aufgabe von Hand zu erledigen, zu beurteilen oder zu retten	Niemand kann die Aufgabe manuell erledigen, wenn die Automatisierung ausfällt	Bainbridge: Fähigkeiten verkümmern ohne Nutzung; Stack Overflow 2025: 20 % weniger zuversichtlich in die eigene Problemlösung
6. Verantwortungsschulden	Kein benannter Verantwortlicher, kein Budget, kein Stilllegungsdatum	Sie können nicht sagen, wem ein stiller Ausfall auffallen würde	Parasuraman und Riley: „Abuse“ von Automatisierung durch Entwickler und Manager

Zwei davon verdienen mehr Aufmerksamkeit, weil sie am wenigsten sichtbar sind.

Kompetenzschulden sind die Ironie im Kern der Automatisierung. Lisanne Bainbridges Aufsatz „Ironies of Automation“ von 1983 in Automatica hat das Argument vier Jahrzehnte vor der generativen KI formuliert. Die Automatisierung eines Prozesses lässt dem Menschen meist zwei Aufgaben: überwachen, ob das automatische System funktioniert, und übernehmen, wenn es das nicht tut. Doch das Übernehmen erfordert genau die Fähigkeiten, die verblassen, wenn ein Mensch nur noch überwacht: Physische Fertigkeiten verkümmern, wenn sie nicht genutzt werden, und das Wissen für ungewöhnliche Situationen entsteht nur durch Anwendung und Feedback. Unter Verweis auf die Vigilanzforschung merkte sie zudem an, dass selbst ein hoch motivierter Mensch seine Aufmerksamkeit auf eine Quelle, bei der kaum etwas passiert, nicht länger als etwa eine halbe Stunde wirksam aufrechterhalten kann. Ihre Ironie: Je fortgeschrittener die Automatisierung, desto entscheidender kann der menschliche Beitrag werden, genau dann, wenn dieser Mensch am wenigsten Übung hatte.

Bei den Verantwortungsschulden läuft das Management schief. In ihrem Aufsatz von 1997 in Human Factors unterschieden Raja Parasuraman und Victor Riley vier Arten, wie Menschen mit Automatisierung umgehen. Wie ihr Abstract zusammenfasst, ist Misuse übermäßiges Vertrauen, das zu Überwachungsfehlern und Entscheidungsverzerrungen führt; Disuse ist Vernachlässigung, oft durch Fehlalarme verursacht; und Abuse bedeutet, Funktionen „ohne gebührende Rücksicht auf die Folgen für die menschliche Leistung“ zu automatisieren, sodass die Rollen der Menschen zu Nebenprodukten der Automatisierung werden. Für Manager oder Solo-Selbstständige ist Abuse am relevantesten: automatisieren, weil ein Tool es möglich macht, und dann annehmen, dass die Übriggebliebenen die Ausnahmen und die Prüfung schon auffangen.

Die Scorecard „Jetzt automatisieren / Warten / Nie“

Die folgende Entscheidungsregel macht aus den sechs Komponenten eine Bewertungscheckliste. Bewerten Sie jede Frage mit 0, 1 oder 2 Punkten, bevor Sie irgendetwas bauen.

Tabelle 5. CEOtudent-Redaktionsrahmen: Scorecard für Automatisierungsschulden

Frage	0 Punkte	1 Punkt	2 Punkte
Frequenz: Wie oft läuft die Aufgabe?	Seltener als monatlich	1 bis 8 Mal im Monat	Mehr als 8 Mal im Monat
Stabilität: Hat sich der Prozess in den letzten 3 Monaten geändert?	Geändert und nicht dokumentiert	Stabil, aber nicht dokumentiert	Stabil und als SOP festgehalten
Prüfung: Wie lange dauert das Prüfen eines Ergebnisses im Verhältnis zur manuellen Erledigung?	Über 30 %	10 % bis 30 %	Unter 10 %
Ausnahmen: Welcher Anteil der Durchläufe braucht einen Menschen?	Über 20 %	5 % bis 20 %	Unter 5 %
Fehlerkosten: Was passiert, wenn das Ergebnis unbemerkt falsch ist?	Erreicht einen Kunden, eine Aufsichtsbehörde oder eine Zahlung	Wird nachgelagert mit gewissen Kosten entdeckt	Wird günstig und folgenlos entdeckt
Verantwortung: Gibt es einen benannten Verantwortlichen mit Zeit für Wartung?	Niemand	Verantwortlicher, aber ohne eingeplante Zeit	Benannter Verantwortlicher, Zeit eingeplant, Überprüfungstermin festgelegt
Kompetenz: Kann noch jemand die Aufgabe von Hand erledigen und beurteilen?	Niemand könnte es	Eine Person, aus der Übung	Ja, und die Fähigkeit wird aktiv genutzt

Entscheidungsregel (maximal 14 Punkte):

• Jetzt automatisieren: 10 Punkte oder mehr und keine Null bei Fehlerkosten oder Verantwortung.
• Warten und lernen: 6 bis 9 Punkte oder eine Null bei Stabilität oder Verantwortung. Führen Sie die Aufgabe noch einige Male manuell aus, schreiben Sie das Verfahren auf, messen Sie Prüfzeit und Ausnahmequote, benennen Sie einen Verantwortlichen und bewerten Sie dann erneut.
• Nie (vorerst): 5 Punkte oder weniger oder eine Null sowohl bei Fehlerkosten als auch bei Prüfung. Das sind Aufgaben, bei denen Fehler teuer und schwer zu erkennen sind: Lassen Sie einen Menschen die Arbeit machen und setzen Sie Tools nur unterstützend ein.

Zwei Gestaltungsentscheidungen sind bewusst getroffen. Erstens wirken Verantwortung und Fehlerkosten als Veto, weil eine hohe Gesamtpunktzahl weder eine Automatisierung ausgleichen kann, die niemand wartet, noch stille Fehler, die einen Kunden erreichen. Zweitens punktet Stabilität höher, wenn der Prozess aufgeschrieben ist, weil sich ein Prozess, den man nicht beschreiben kann, auch nicht prüfen lässt. Wenn Sie Ihre Arbeit noch nicht kartiert haben, beginnen Sie mit dem Workflow-Audit in 7 Schritten und machen Sie aus dem Ergebnis ein schriftliches Verfahren nach dem Ansatz aus der SOP-Renaissance. Die Scorecard ergänzt eine Priorisierungsmethode wie die 80/20-Regel dafür, welche Aufgaben der Wissensarbeit zuerst automatisiert werden sollten, statt sie zu ersetzen: Die 80/20-Perspektive zeigt Ihnen, wo der Wert liegt, und die Schulden-Scorecard, ob Sie ihn tatsächlich einstreichen können.

Die CEO+Student-Perspektive: den Prozess lernen, bevor man ihn automatisiert

Ein CEO genehmigt keine Investition, ohne zu fragen, was ihr Betrieb kosten wird. Automatisierung ist eine Investition mit laufenden Kosten, und die Aufgabe des Eigentümers ist es, alle zu sehen: die Bauzeit im Antrag, die Prüf- und Reparaturstunden, die auf dem Schreibtisch eines anderen landen, und die Fähigkeit, die die Organisation verliert, wenn niemand die Aufgabe mehr übt. Urteilsvermögen auf Eigentümerebene heißt, drei Fragen zu stellen, die jeder Automatisierungsvorschlag beantworten sollte:

1. Wer prüft es, wie, und wie lange dauert das? Lautet die Antwort „niemand“ oder „mal sehen“, sind die Prüfschulden nicht eingepreist. Bewusste Kontrollpunkte zu setzen ist eine Gestaltungsaufgabe, die in menschliche Aufsicht by Design behandelt wird.
2. Wem gehört es, wenn es ausfällt, und wann prüfen wir, ob wir es behalten? Eine Automatisierung ohne Überprüfungstermin ist ein Abonnement ohne Kündigungsknopf.
3. Was passiert mit unserer Kompetenz? Handelt es sich um eine Aufgabe, bei der das Urteil das eigentliche Produkt ist, etwa Preisgestaltung, Personalauswahl, Kundenberatung oder Lektorat, dann verbraucht die Automatisierung der gesamten Aufgabe genau die Expertise, die man braucht, um das Ergebnis zu beurteilen.

Die Studenten-Hälfte der These ist die praktische Verteidigung. Der verlässlichste Weg, Automatisierungsschulden zu vermeiden, ist, einen Prozess von Hand zu verstehen, bevor man ihn automatisiert: ihn oft genug ausführen, um seine Ausnahmen zu kennen, den Prüfschritt zu stoppen, das Verfahren aufzuschreiben und erst dann zu entscheiden. Die METR-Entwickler hatten jahrelange Erfahrung mit ihren Repositories und waren trotzdem überrascht; wer einen Prozess automatisiert, den er zweimal durchlaufen hat, hat noch weit weniger in der Hand. Zuerst zu lernen schützt auch vor Bainbridges Ironie. Wer die Arbeit selbst gemacht hat und sie gelegentlich weiter macht, kann das Ergebnis der Automatisierung noch beurteilen und sie retten, wenn sie versagt. Dieses Urteilsvermögen aufzubauen ist eine eigene Fähigkeit, beschrieben in der Bewertungskompetenz für KI-Ausgaben.

Die Chance ist real: In Tabelle 2 amortisieren sich zwei der fünf Automatisierungen dennoch innerhalb eines Jahres. Stabile, häufige und günstig zu prüfende Aufgaben sind der Ort, an dem Automatisierung sich bezahlt macht. Die Gewinner werden ausgewählt, nicht vorausgesetzt.

Wie Sie bestehende Automatisierungsschulden abbauen

Die meisten, die das hier lesen, betreiben bereits Automatisierungen. Eine vierteljährliche Überprüfung in vier Schritten hält den Saldo unter Kontrolle:

1. Bestandsaufnahme. Listen Sie jede Automatisierung auf, auch Mailregeln, geplante Skripte, KI-Agenten und No-Code-Abläufe. Notieren Sie daneben den Verantwortlichen und das letzte Datum, an dem jemand geprüft hat, ob sie funktioniert. Leere Zellen sind Verantwortungsschulden.
2. Die Zinsen messen. Protokollieren Sie eine typische Woche lang für jede Automatisierung die Minuten für das Prüfen von Ergebnissen, das Behandeln von Ausnahmen und das Beheben von Ausfällen. Setzen Sie diese Zahlen in die Formel aus Tabelle 2 ein.
3. Umschulden oder stilllegen. Für Automatisierungen, die sich nicht mehr rechnen, gibt es drei Optionen: vereinfachen (weniger Schritte, weniger Abhängigkeiten), auf die Fälle eingrenzen, die zuverlässig funktionieren, und den Rest an einen Menschen weiterleiten, oder abschalten. Eine Automatisierung abzuschalten, die mehr kostet, als sie spart, ist ein Gewinn, kein Scheitern.
4. Die Fähigkeit warm halten. Lassen Sie bei allem Kritischen den Verantwortlichen die Aufgabe von Zeit zu Zeit manuell ausführen, damit die Rückfallebene existiert, wenn sie gebraucht wird.

Diese Überprüfung passt natürlich in die Wartungsschicht eines strukturierten Arbeitstags; wo sie hingehört, zeigt der KI-Workflow in 5 Schichten.

Häufige Fragen

Was sind Automatisierungsschulden?
Automatisierungsschulden sind die angesammelte künftige Arbeit, die durch das Automatisieren einer Aufgabe entsteht: Ergebnisse prüfen, Ausnahmen behandeln, die Automatisierung warten, wenn sich etwas ändert, steuern, was von ihr abhängt, und die menschliche Fähigkeit erhalten, die man braucht, wenn sie ausfällt. Es ist ein CEOtudent-Rahmen, der Ward Cunninghams Metapher der technischen Schulden vom Code auf Arbeitsabläufe überträgt.

Sind Automatisierungsschulden immer schlecht?
Nein. Wie finanzielle Schulden können sie eine vernünftige Entscheidung sein, wenn der Ertrag größer ist als die Zinsen und jemand sie bedient. In unserem Break-even-Modell bringt eine Wochenbericht-Automatisierung nach Abzug aller versteckten Kosten im ersten Jahr immer noch netto 9,7 Stunden. Das Problem sind nicht eingepreiste Schulden ohne Verantwortlichen.

Verschärft KI-Automatisierung das Problem?
Das kann sie, weil KI-Ergebnisse oft „fast richtig“ sind, was den Prüfaufwand erhöht. In der Stack-Overflow-Umfrage 2025 nannten 66 % der Entwickler genau das als Ärgernis, und in der METR-Studie übernahmen die Entwickler weniger als 44 % der KI-Generierungen. KI macht es außerdem schneller, Automatisierungen zu bauen, und damit leichter, unbemerkt Schulden aufzunehmen.

Woran erkenne ich, ob eine Automatisierung mehr kostet, als sie spart?
Protokollieren Sie eine Woche lang die Zeit für Prüfung, Ausnahmebehandlung und Reparaturen, rechnen Sie sie aufs Jahr hoch und ziehen Sie sie von der gesparten Bruttozeit ab. Ist das wiederkehrende Netto null oder negativ, wird die Automatisierung ihre Bauzeit nie wieder einspielen, wie bei zwei der fünf Beispiele in Tabelle 2.

Sollte ich mit dem Automatisieren aufhören, bis ich jeden Prozess beherrsche?
Nein. Nutzen Sie die Scorecard: Stabile, häufige und günstig zu prüfende Aufgaben mit einem benannten Verantwortlichen können jetzt automatisiert werden. Die Kategorie „Warten“ bedeutet lediglich, den Prozess von Hand zu lernen, ihn aufzuschreiben und zu messen, bevor man baut.

Quellen

1. Becker, J., Rush, N., Barnes, B., and Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR. arXiv:2507.09089v2.
2. Google Cloud DORA (2024). Accelerate State of DevOps Report 2024 (v. 2024.3).
3. Stack Overflow (2025). 2025 Developer Survey, KI-Abschnitt.
4. Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., and Dennison, D. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NeurIPS 2015).
5. Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6), 775-779.
6. Parasuraman, R., and Riley, V. (1997). Humans and Automation: Use, Misuse, Disuse, Abuse. Human Factors, 39(2), 230-253 (Abstract).
7. Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA ‘92 Experience Report.

Tabelle 1 enthält verifizierte Zahlen aus der METR-Studie, dem DORA-Bericht 2024 und der Stack-Overflow-Umfrage 2025. Die Tabellen 2 und 3 sind CEOtudent-Berechnungen auf Basis der unter jeder Tabelle genannten illustrativen Annahmen; jede Zelle wurde per Skript berechnet und unabhängig nachgeprüft. Die Tabellen 4 und 5 bilden den CEOtudent-Redaktionsrahmen; die Forschungsbezüge in Tabelle 4 verweisen auf verwandte Befunde und stellen keine Validierung des Rahmens dar.

---

Dieser Inhalt wurde nach eingehender Recherche mit Unterstützung von KI zusammengestellt und vom CEOtudent-Redaktionsteam geschrieben und für die Veröffentlichung aufbereitet.

This post is also available in: