Wann man nicht automatisieren sollte: die Entscheidungsregel, die ich vor jedem Aufbau anwende

Ich habe mehr Automatisierungen gelöscht, als ich derzeit betreibe. Nicht weil sie kaputtgingen, sondern weil sie einwandfrei funktionierten und die Dinge dadurch schlechter machten.

Dieser Satz lohnt sich zum Nachdenken, denn genau das spricht die “Automatisiere alles”-Fraktion nie an. Eine Automatisierung, die zuverlässig läuft und die Qualität Ihrer Arbeit verschlechtert, ist kein Produktivitätsgewinn. Sie ist eine Belastung, die wie ein Gewinn aussieht. Das einzige Signal, das dies erkennt, ist die Feststellung, mehrere Wochen später, dass die produzierten Ergebnisse still schlechter geworden sind und die Automatisierung diesen Verfall verdeckt hat.

Dies ist die Entscheidungsregel, die ich nun vor jedem Aufbau anwende. Es ist eine einzige Frage mit drei Teilprüfungen, und sie hat mir mehr Zeit gespart als die meisten Automatisierungen, die ich ohne sie gebaut hätte.

Die Fälle, die mir die Regel beigebracht haben

Ich habe vier Automatisierungen gebaut, die ich später gelöscht habe. Alle vier funktionierten. Hier ist, was sie taten und warum sie verschwanden.

Automatisch zusammengefasste Meeting-Notizen. Ein Modell, das auf jedem Meeting-Transkript lief – sofortige Meeting-Zusammenfassungen, dreißig Minuten nach jedem Anruf versendet. Das Problem: Die Zusammenfassungen waren präzise und nutzlos. Meeting-Notizen brauchen Kuration, keine Komprimierung. Die Automatisierung stellte das Gesagte proportional zu seinem Umfang dar. Was in den meisten Meetings tatsächlich zählte, war ein Satz, einmal und zögerlich ausgesprochen, den ich annotiert hatte und um den herum ich das Briefing aufgebaut hätte. Dieser Satz stach in einer Zusammenfassung nicht hervor. Er sah aus wie die anderen neunundvierzig Sätze. Die Automatisierung produzierte saubere, professionell formatierte Dokumentation der unwichtigsten Teile jedes Meetings.

Ersetzt durch: das Drei-Tag-Annotationssystem. Manuell. Nicht automatisierbar.

Automatisch generierte Kunden-Follow-up-Entwürfe. Ein Modell, das Follow-up-E-Mails aus der Meeting-Zusammenfassung entwarf. Das Problem: Es wandte auf Beziehungen, die eine differenzierte Behandlung erforderten, ein einheitliches professionelles Register an. Ein Kunde wollte Kürze und Direktheit. Ein anderer brauchte Wärme und Kontext. Ein weiterer befand sich in einer politisch sensiblen Position, die sorgfältige Formulierung erforderte. Das Modell produzierte korrekte, glatte, professionelle Follow-ups. Sie waren für die Beziehung falsch, auf dieselbe Weise, wie eine vorgefertigte Beileidskarte falsch ist – grammatikalisch einwandfrei, situativ daneben. Drei Kunden antworteten in einem Ton, der mir zeigte, dass sie das Fehlen einer echten Person am anderen Ende gespürt hatten. Die Automatisierung war technisch korrekt; die Ergebnisse waren professionell falsch.

Ersetzt durch: nichts. Manche Follow-ups müssen von Hand geschrieben werden.

Briefing-Digests. Ein tägliches Digest von allem, was in meinen Notizen der vergangenen Woche als wichtig markiert war. Das Problem: Die Gewohnheit täglicher Digests machte mich weniger selektiv dabei, was ich als wichtig markierte. Wenn ein System alles aggregiert, verliert man die Disziplin, vor der Erfassung zu entscheiden, was zählt. Das Digest häufte sich an. Vollständigkeit ersetzte Selektivität, und Selektivität war der eigentliche Punkt.

Ersetzt durch: eine wöchentliche, fünfzehnminütige manuelle Durchsicht der rohen Notizen der Woche. Ich wähle die drei Dinge aus, die tatsächlich etwas bewegt haben. Diese Einschränkung trägt das gesamte System.

Konfidenzwerte. Ich bat das Modell, seine eigenen Rechercheergebnisse auf einer Skala von 1 bis 10 zu bewerten. Das Problem: Die Zahlen waren erfunden. Das Modell erkannte das Muster, wie ein Konfidenzwert aussieht, und produzierte plausible Zahlen. Ich vertraute ihnen. Ich hatte die Nachahmung von Urteilsvermögen automatisiert und sie mit dem Urteilsvermögen selbst verwechselt.

Ersetzt durch: meine eigene Unsicherheitskennzeichnung. Wenn ich mir bei etwas nicht sicher bin, schreibe ich davor “PRÜFEN:”. Wenn ich sicher bin, schreibe ich die Aussage. Dieses System ist binär und ehrlich. Es kostet nichts.

Alle vier wurden gelöscht, nicht weil sie kaputtgingen, sondern weil sie an Stellen auf Effizienz optimierten, an denen Effizienz nicht die begrenzende Einschränkung war.

Die Entscheidungsregel

Bevor ich eine Automatisierung baue, stelle ich eine Frage:

Liegt der Engpass dieser Aufgabe in der benötigten Zeit oder im erforderlichen Urteilsvermögen?

Wenn die Antwort Zeit ist, lohnt sich eine Automatisierung.

Wenn die Antwort Urteilsvermögen ist, lohnt es sich, Automatisierung zu vermeiden – oder zumindest sollte der urteilshaltige Schritt der eine sein, den die Automatisierung nicht anfasst.

Drei Teilprüfungen ergeben sich daraus:

Teilprüfung eins: Wie sieht Versagen aus, und wie schnell zeigt es sich? Manche Fehler sind offensichtlich und schnell – die Automatisierung bricht ab, nichts funktioniert, man bemerkt es sofort. Manche Fehler sind unsichtbar und langsam – die Automatisierung läuft, produziert plausible Ergebnisse und verschlechtert die Qualität über Wochen hinweg. Die langsamen sind schlimmer. Vor dem Bauen frage ich: Wenn diese Automatisierung stillschweigend schlechte Ergebnisse produziert, wie lange dauert es, bis ich es bemerke? Wenn die Antwort “mehr als eine Woche” ist, möchte ich einen menschlichen Kontrollpunkt vor der Verwendung des Ergebnisses, nicht danach.

Teilprüfung zwei: Automatisiere ich die Darstellung der Arbeit oder die Arbeit selbst? Dies ist die wichtigste Unterscheidung, die ich gefunden habe, und sie ist leicht zu übersehen, weil gute KI-Ergebnisse wie gute Arbeit aussehen. Ein Briefing zu formatieren, eine Zusammenfassung zu entwerfen, ein Dokument zu strukturieren – das sind Darstellungen des Denkens, nicht das Denken selbst. Diese zu automatisieren ist risikoarm, wenn das zugrunde liegende Denken von Ihnen stammt. Aber wenn die Automatisierung die Darstellung produziert, bevor das Denken stattgefunden hat, erhalten Sie etwas, das vollständig aussieht und es nicht ist. Die Automatisierung, die ich bauen sollte, ist diejenige, die das Ergebnis formatiert, nachdem ich die Urteilsarbeit geleistet habe. Diejenige, die ich vermeiden sollte, ist diejenige, die das Ergebnis anstelle davon produziert.

Teilprüfung drei: Verstärkt sich diese Aufgabe kumulativ? Manche Tätigkeiten werden wertvoller, je öfter man sie ausführt – man entwickelt Mustererkennung, baut Beziehungswissen auf, verfeinert ein Modell der Situation eines Kunden. Wenn Sie eine sich kumulativ verstärkende Tätigkeit automatisieren, stoppen Sie diese Verstärkung. Die Maschine läuft die Wiederholungen, Sie nicht. Über ein Jahr hinweg ist der Unterschied erheblich. Über drei Jahre hinweg ist es die Kluft zwischen jemandem, der einen wirklich tiefen Blick auf sein Fachgebiet hat, und jemandem, der gutes Werkzeug hat. Alles, was sich kumulativ verstärkt, behalte ich in eigener Hand.

Was die Regel erlaubt

Zur Klarheit: Ich automatisiere eine Menge. Diese Regel erzeugt keinen Skeptiker, der alles von Hand macht. Sie erzeugt Klarheit darüber, wohin die Automatisierung gehört.

Ich automatisiere Formatierung und Struktur. Ich automatisiere die Komprimierung von Material, das ich bereits kuratiert und annotiert habe. Ich automatisiere den Abruf – Systeme aufbauen, die früheres Denken auf Abruf zutage fördern. Ich automatisiere Terminplanung und Weiterleitung: die administrative Schicht jedes Workflows, bei dem es rein darum geht, Dinge von einem Ort zum anderen zu bewegen.

Ich automatisiere nicht die erste Artikulation meiner Position zu irgendetwas. Ich automatisiere keine Beziehungspflege. Ich automatisiere nicht den Schritt, der von mir verlangt zu entscheiden, was zählt. Und ich automatisiere nichts, bei dem der Fehlermodus selbstbewusst klingende Falschheit ist, denn dieser Fehlermodus ist unsichtbar, bis er es nicht mehr ist.

Die Frage ist nie “Kann das automatisiert werden?” Sie lautet: “Was sind die tatsächlichen Kosten, wenn dies eine plausible falsche Antwort produziert, und wer bemerkt es?”

Das Dokument, das ich führe

Ich pflege ein kurzes Dokument, ein Entscheidungsprotokoll, in dem ich jede Automatisierung festhalte, die ich in Erwägung gezogen und nicht gebaut habe, und warum. Es enthält etwa zwei Dutzend Einträge. Es ist, ehrlich gesagt, nützlicher als die Liste der Automatisierungen, die ich betreibe, denn die Einträge enthalten die Begründung dafür, warum eine bestimmte Aufgabe Urteilsarbeit ist, und diese Begründung überträgt sich auf neue Entscheidungen. Jedes Mal, wenn ich in Versuchung bin, etwas für eine ähnliche Aufgabe zu bauen, prüfe ich zuerst das Protokoll.

Die Entscheidung, nicht zu automatisieren, ist genauso bewusst wie die Entscheidung, zu automatisieren. Treffen Sie sie bewusst, dokumentieren Sie sie, und sie hört auf, eine verpasste Gelegenheit zu sein. Sie wird zur Richtlinie.

Dieses Dokument – die Tool-Entscheidungsmatrix und das Entscheidungsprotokoll-Format, das ich verwende – ist als Vorlage verfügbar. Die Logik in der Vorlage ist dieselbe Logik, die ich hier beschrieben habe; die Vorlage macht sie über wiederkehrende Entscheidungen hinweg wiederverwendbar.

→ Tool Decision Framework – 39 $. Strukturierte Entscheidungsmatrix + Entscheidungsprotokoll. Direkt in Obsidian oder Notion einfügbar. (Zuerst an die Newsletter-Liste ausgeliefert; unten anmelden.)

Vier gelöschte Automatisierungen. Jede einzelne hat etwas gelehrt, das die Build-first-Community nie offen ausspricht: Die Frage ist nicht, ob Sie es automatisieren können. Sie lautet, ob Sie in zwei Monaten froh sein werden, es getan zu haben.

Nächster Beitrag in Systems → Wie ich KI-Ergebnisse ehrlich halte – die Prüfungen, die ich durchführe, bevor irgendetwas zu einem Kunden geht.