Meat Proxy: Wie KI-Slop Unternehmen von innen ausbrennt

Heute Morgen habe ich auf X einen Beitrag von Mike Fishbein gelesen, der ziemlich genau beschreibt, was wir seit Monaten bei Kunden, Partnern und vergleichbaren Agenturen beobachten:

„AI slop is melting down companies from the inside. […] People have become ‚meat proxies.' They paste context into a prompt, add zero thinking of their own, and send along the output. The burden shifts from the person doing the work to the person reading it."

Frei übersetzt: KI-Slop lässt Unternehmen von innen heraus durchschmelzen. Menschen werden zu Meat Proxies, zu Weiterleitungen aus Fleisch und Blut. Sie kopieren Kontext in einen Prompt, denken selbst nicht mit und schicken das Ergebnis weiter. Die Arbeit verschwindet dabei nicht. Sie landet bei dem, der das Ganze lesen muss.

Wir nutzen KI jeden Tag, in der Entwicklung, im Projektmanagement und im Support. Sie nimmt uns richtig viel Arbeit ab. Aber eine Sache kann sie nicht: verstehen, was ein Kunde eigentlich will, und dafür geradestehen. Wer genau diesen Teil an die KI auslagert, baut sich eine sehr teure Stille Post.

TL;DR
Ein Meat Proxy ist jemand, der KI-Output ungelesen weiterreicht. Der Begriff stammt aus einem Essay des Entwicklers Niklas Gruhn vom August 2026 und hat sich seitdem schnell verbreitet.
In Agenturen sehen wir eine ganze Kette davon: Kundenmail per ChatGPT, KI-Vorsortierung, KI-Fragenkatalog, Anforderung in Claude, und am Ende hat niemand die Mail gelesen.
Laut einer Studie von Stanford und BetterUp haben 40 % der Büroangestellten im Vormonat solchen „Workslop“ bekommen. Jeder Fall kostet im Schnitt knapp zwei Stunden Nacharbeit.
KI eignet sich gut zum Vorsortieren, Zusammenfassen und Umsetzen. Verstehen, Abwägen und Verantworten bleiben bei Menschen, besonders im Anforderungsmanagement.
Unsere Regel: Jede Anforderung hat einen Menschen, der sie gelesen hat und sie ohne Bildschirm in zwei Sätzen erklären kann.

Was ist ein Meat Proxy?

Ein Proxy ist in der IT ein Vermittler, der Anfragen entgegennimmt und unverändert weiterreicht. Ein Meat Proxy macht dasselbe, nur eben als Mensch: Er nimmt eine Frage, kippt sie in ChatGPT oder Claude und gibt die Antwort weiter, ohne sie gelesen, geprüft oder verstanden zu haben.

Geprägt hat den Begriff der Entwickler Niklas Gruhn im August 2026 mit seinem Essay „Don't be a meat proxy“. Seine Kernaussage ist simpel: KI benutzen ist völlig in Ordnung. Den Output aber lesen, verstehen, prüfen und dann in eigenen Worten antworten. Thoughtworks hat den Begriff inzwischen sogar als Anti-Pattern in seinen Technology Radar aufgenommen.

Das Tückische daran: Meat-Proxy-Output sieht gut aus. Er ist sauber formatiert, höflich, lang und voller Aufzählungspunkte. Genau deshalb fällt erst beim Empfänger auf, dass keine Substanz drinsteckt.

Stille Post mit KI: Eine Kundenmail auf Reisen

So sieht ein Ablauf aus, den wir in dieser oder ähnlicher Form inzwischen regelmäßig erleben, bei Kunden, bei Partnern und bei Agenturen, mit denen wir zusammenarbeiten:

Der Kunde hat eine Idee für ein neues Feature. Statt drei Sätze zu schreiben, lässt er ChatGPT eine ausführliche, professionelle Mail formulieren. Mit Einleitung, Zielsetzung, Aufzählungen und einem freundlichen Ausblick.
Das Agentur-Postfach wird von einer KI vorsortiert. Sie erkennt „Feature-Anfrage“, fasst die Mail zusammen und draftet gleich eine Antwort.
Das Projektmanagement liest die Zusammenfassung, nicht die Mail. Es lässt die KI daraus einen Fragenkatalog für die Entwickler erstellen.
Die Entwickler kopieren Anforderung und Fragenkatalog ungelesen in Claude und fragen: „Welche Änderungen sind notwendig? Ist alles geklärt?“
Und dann geht die ganze Schlange rückwärts. Claudes Antwort wird zur Rückmeldung an das Projektmanagement, daraus wird per KI eine Kundenmail, und der Kunde lässt sich diese Mail von ChatGPT zusammenfassen.

An jeder Station saß ein Mensch. Jeder hat etwas getan. Und trotzdem hat niemand die ursprüngliche Mail des Kunden wirklich gelesen und verstanden. Die KI macht das schon.

Das eigentliche Problem: Niemand hat verstanden, was der Kunde will

Jede einzelne Station in dieser Kette ist für sich genommen sinnvoll. Mails vorsortieren lassen? Gute Idee. Einen Fragenkatalog vorbereiten lassen? Spart Zeit. Mit Claude prüfen, welche Dateien eine Änderung betrifft? Machen wir selbst ständig.

Kaputt ist nicht der einzelne Schritt. Kaputt ist, dass das Verstehen in der Kette niemandem mehr gehört. Jede KI-Station verdichtet, interpretiert und glättet ein bisschen. Nach fünf Stationen ist aus „Kunden sollen ihre alten Rechnungen als PDF herunterladen können“ ein Feature-Konzept mit Rechnungsarchiv, Filterfunktion, Export in drei Formaten und Rollenkonzept geworden. Klingt alles plausibel. Gewollt hat es so niemand.

Dazu kommt das, was eine KI grundsätzlich nicht sehen kann:

Was zwischen den Zeilen steht. Der Kunde hat sich letzte Woche am Telefon über die Ladezeiten beschwert. Die neue Anfrage ist eigentlich ein Hilferuf wegen genau dieses Problems.
Was nicht in der Mail steht. Die Buchhaltung des Kunden arbeitet mit DATEV, das Feature muss also an einer ganz anderen Stelle andocken.
Was wirtschaftlich sinnvoll ist. Ein Teil der Anforderung kostet 80 % des Budgets und bringt 10 % des Nutzens. Das muss jemand ansprechen, und zwar ein Mensch, der dafür geradesteht.

Eine KI beantwortet die Frage „Ist alles geklärt?“ übrigens fast immer mit einer gut strukturierten Liste offener Punkte. Ob das die richtigen offenen Punkte sind, kann sie nicht wissen. Dafür müsste sie den Kunden, das Projekt und die Vorgeschichte kennen. Das ist der Job von Menschen.

Workslop in Zahlen: Was KI-Slop im Büro kostet

Dass das kein Bauchgefühl einzelner genervter Entwickler ist, zeigt eine Studie von BetterUp Labs und dem Stanford Social Media Lab, die in der Harvard Business Review erschienen ist. Die Forscher nennen das Phänomen Workslop: KI-generierte Arbeitsergebnisse, die nach guter Arbeit aussehen, aber die eigentliche Aufgabe nicht voranbringen.

Kennzahl	Ergebnis
Befragte, die im Vormonat Workslop bekommen haben	40 %
Geschätzter Anteil am erhaltenen Arbeitsmaterial	rund 15 %
Nacharbeit pro Fall	knapp 2 Stunden
Geschätzte versteckte Kosten pro Mitarbeiter	rund 186 US-Dollar pro Monat
Hochgerechnet auf 10.000 Mitarbeiter	über 9 Millionen US-Dollar pro Jahr
Empfänger, die sich davon genervt fühlen	53 %

Die Dollarbeträge sind Schätzungen auf Basis selbst angegebener Zeiten und Gehälter. Die Richtung ist aber eindeutig. Und die Studie zeigt noch etwas, das in keiner Tabelle steht: Wer Workslop verschickt, verliert bei Kollegen an Vertrauen. Die Empfänger halten die Absender für weniger kompetent und weniger zuverlässig.

Genau das ist das langsame Ausbrennen von innen, von dem Fishbein schreibt. Nicht der eine große Fehler, sondern hunderte kleine Momente, in denen jemand eine KI-Antwort bekommt und denkt: Hast du das überhaupt gelesen?

Blinde KI-Operatoren statt Fachleute

Am Ende dieser Entwicklung stehen Mitarbeiter, die wir intern etwas bissig blinde KI-Operatoren nennen. Sie fügen in der richtigen Reihenfolge Text in die richtige KI ein und hoffen, dass kein Kollege nachfragt. Denn auf Rückfragen haben sie keine Antwort. Sie haben die Anforderung ja nie selbst durchdacht.

Das ist für alle Beteiligten schlecht:

Für den Kunden, der ein Feature bekommt, das an seinem Problem vorbeigeht, und dafür bezahlt.
Für die Kollegen, die die Denkarbeit am Ende doch machen müssen, nur später, unter Zeitdruck und mit weniger Kontext.
Für den Meat Proxy selbst, der keine Erfahrung mehr aufbaut. Wer nie eine Anforderung selbst zerlegt hat, lernt auch nicht, worauf es dabei ankommt.

Gerade der letzte Punkt macht uns Sorgen. Anforderungsmanagement lernt man nicht aus einem Tutorial, sondern indem man viele Kundenmails liest, falsch versteht, nachfragt und es beim nächsten Mal besser macht. Wer diesen Lernprozess an eine KI abgibt, wird nicht schneller besser. Er wird gar nicht besser.

Fishbein hat recht, aber nur zur Hälfte

Fishbein schreibt, KI-Slop sei weder ein People- noch ein KI-Problem, sondern ein Engineering-Problem. Seine Lösung: Agenten bauen, die Playbooks selbstständig abarbeiten und in die Tools integriert sind, die das Team ohnehin nutzt.

Dem ersten Teil stimmen wir zu. Mit noch einem Workshop oder einer weiteren Folie zum Thema „verantwortungsvoller KI-Einsatz“ ist es nicht getan. Wer allen eine ChatGPT- oder Claude-Lizenz gibt und auf Magie hofft, bekommt Slop. Gute Prozesse und gut integrierte Agenten helfen enorm, gerade bei wiederkehrenden Aufgaben.

Beim zweiten Teil sind wir vorsichtiger. Ein Agent, der ein Playbook abarbeitet, löst das Problem nur dort, wo es ein Playbook gibt. Eine neue Kundenanforderung ist aber selten Routine. Sie ist unscharf, widersprüchlich und hängt an Vorgeschichte, Budget und Menschen. Hier verschiebt ein weiterer Agent die Verantwortung nur noch eine Station weiter. Gelesen hat die Mail dann immer noch niemand.

KI-Slop ist deshalb aus unserer Sicht beides: ein Engineering-Problem bei den Abläufen und ein Haltungsproblem bei der Frage, wer für das Verstehen zuständig ist.

Wie wir KI im Anforderungsmanagement einsetzen

Wir wollen auf KI nicht verzichten, im Gegenteil. Aber wir haben ein paar einfache Regeln, damit aus Unterstützung keine Stille Post wird:

Die Original-Mail wird von einem Menschen gelesen. Immer. Eine KI-Zusammenfassung darf zusätzlich dabei sein, aber nie stattdessen.
Jede Anforderung hat einen Owner. Ein Mensch, der sie verstanden hat, Rückfragen beantworten kann und dafür geradesteht. Nicht „das Team“, nicht „die KI“.
Der Zwei-Sätze-Test. Wer eine Anforderung weitergibt, muss sie ohne Bildschirm in zwei Sätzen erklären können. Wer das nicht kann, hat sie noch nicht verstanden.
Rückfragen an den Kunden in eigenen Worten. Kurz, konkret, ohne generierte Einleitung. Lieber drei gute Fragen als zwanzig, die eine KI für möglicherweise relevant hält.
Entwickler lesen das Ticket, bevor sie prompten. Claude darf danach helfen, die betroffenen Stellen im Code zu finden und Lücken aufzuzeigen. Ob die Anforderung geklärt ist, entscheidet aber der Entwickler, nicht die KI.
Im Zweifel anrufen. Ein zehnminütiges Telefonat mit dem Kunden klärt oft mehr als fünf Runden KI-generierter Mails.

Für die Code-Seite haben wir übrigens ein eigenes Werkzeug gebaut: Mit gitclash bewerten wir Commits nach Qualität, Stack-Treue und Größe, damit ungelesene KI-Diffs gar nicht erst im Review landen. Für Anforderungen gibt es so ein Tool nicht. Dort hilft nur, dass jemand liest.

Fazit: KI soll Arbeit abnehmen, nicht das Denken

KI ist großartig. Sie sortiert vor, fasst zusammen, schreibt Code und findet Lücken, die wir übersehen hätten. Wir arbeiten damit schneller als je zuvor. Aber sie ersetzt nicht den Moment, in dem ein Mensch eine Kundenmail liest, die Stirn runzelt und denkt: Moment, was will er eigentlich?

Wer diesen Moment aus seinen Abläufen streicht, wird zum Meat Proxy. Und ein Unternehmen voller Meat Proxies produziert jede Menge KI-Slop, also Mails, Tickets, Konzepte und Code, die alle gut aussehen und trotzdem am Kunden vorbeigehen. Das passiert nicht auf einen Schlag, sondern langsam und von innen.

Unser Rat für das Anforderungsmanagement mit KI: Nutzt die Werkzeuge, so viel ihr wollt. Aber sorgt dafür, dass jede Anforderung mindestens einen Menschen hat, der sie gelesen, verstanden und sich eine eigene Meinung dazu gebildet hat. Das kostet ein paar Minuten und spart Tage.

Quellen

Interesse? Dann schreib uns!

Wir helfen KMU dabei, KI und Automatisierung sinnvoll einzusetzen, ganz ohne Technikjargon.

Kostenlos anfragen →