Meat Proxies in der Softwareentwicklung: Brauchen wir sie noch?

Für diejenigen unter euch, die diesem Begriff bislang entgehen konnten: „Meat Proxy“ ist eine abwertende Bezeichnung für jemanden, dessen einzige Tätigkeit darin besteht, Aufgaben aus einem Ticket-Backlog an einen Coding Agent wie Claude oder Codex zu übergeben und nach Fertigstellung das dazugehörige Ticket weiterzuschieben. Vor generativer KI hatten wir für eine sehr ähnliche Rolle den Begriff „Code Monkey“. Hier ging es um die einfache Übersetzung von Aufgaben in Code und die anschließende Erstellung eines Pull Requests.

Ich kenne Leute, die manchmal gerne Code Monkey gespielt haben. Ich kenne Leute, die freiwillig die Rolle eines Meat Proxys übernehmen. Und ich kenne Unternehmen, die diese Leute in Zeiten generativer KI als Streichkandidaten sehen. „Was die machen, kann auch ein Agent übernehmen.“

„Meat Proxies“ in freier Wildbahn?

Vor ein paar Wochen war meine Vermutung: Engineers, die ihre Expertise (und Verantwortung) freiwillig an einen Coding Agent abgeben, würde ich sicher nicht auf einer teuren Software-Konferenz wie der GOTO Kopenhagen antreffen. Ich hatte angenommen, unter den Besuchern seien Architekten, Designer, Manager, Selbstständige und Engineers, die sich weiterentwickeln wollen. Ich war davon ausgegangen, dort niemanden zu treffen, den viele Unternehmen heute als Streichkandidaten sehen würden.

Zu meinem Erstaunen begegnete mir dort genau die Verunsicherung, von der ich eigentlich etwas Abstand gewinnen wollte. Während einer Panel-Diskussion darüber, wie Engineers generative KI in ihrem Alltag einsetzen, hatten Zuschauer die Möglichkeit, Fragen zu stellen und ihre Meinung zu äußern. Genutzt wurde ein kleines, extra für die Konferenz gebautes Tool, mit dem Fragen und Kommentare direkt auf den großen Bildschirmen hinter und neben der Bühne erschienen. Hier ein paar Beispiele für Kommentare und Fragen, teils übersetzt und paraphrasiert:

• I’m tired, boss.
• I’m still tired, boss.
• Wenn Agents den Code schreiben, was bleibt dann für mich übrig?
• Wozu brauchen wir noch Juniors?
• Lass die Slop-Aufgaben die Slop-Entwickler erledigen; wir machen dann die schönen Aufgaben per Hand, „the old-school way“.
• I hate this timeline.
• Was ist eigentlich noch unsere Aufgabe?

Ich war überrascht. In meiner Naivität war ich davon ausgegangen, dass wir als Teilnehmer auf der Konferenz nach vorne schauen und gemeinsam Wege finden würden, unsere Industrie in der neuen Realität (die der Coding Agents) weiterzuentwickeln – und hier waren plötzlich Leute, die noch mit einer viel grundsätzlicheren Frage beschäftigt waren: Welche Rolle spielen wir in dieser Realität überhaupt noch?

Viele Fragen, kaum (direkte) Antworten

Einen starken Kontrast zu den Leuten, die in dieser neuen Realität fast schon verloren wirkten, bildeten Speaker, die genau das taten, was ich vermutet hatte: Sie akzeptierten diese neue Realität ohne Wertung – Agents schreiben den Code und wir als Industrie müssen die Probleme lösen, die das mit sich bringt. Fragen, die angerissen und teils beantwortet wurden, waren unter anderem:

• Wie beseitigen wir den Flaschenhals Code Review?
• Ist Code Review überhaupt der primäre Flaschenhals oder verbirgt sich dahinter ein wesentlich größerer?
• Wie gehen wir mit den Kontextwechseln um?
• Wie stellen wir sicher, dass wir weiterlernen und unsere kognitive Leistung weiterhin fördern?
• Was können wir heute schaffen, was vorher nicht denkbar war?

Was eben nicht beantwortet wurde, waren die zuvor genannten Fragen: „Was machen wir jetzt eigentlich den ganzen Tag? Und wozu überhaupt?“ Besonders die Veteranen unter den Speakern (von denen ich dieses Jahr einige schmerzlich vermisst habe) sprachen einfach nicht mehr von Code und blickten fast sorglos in die Zukunft, zumindest im Hinblick auf die Frage „Ist mein Job sicher?“

Ein Erklärungsversuch

Warum ist das so? Eine kohärente Geschichte, die man sich selbst erzählen kann und die sicherlich einen Teil der Erklärung liefert, ist: Die Veteranen wissen längst, dass das Aufgabenfeld eines Software Engineers wesentlich mehr beinhaltet als das bloße Schreiben von Code. Sie haben die letzten Jahrzehnte damit verbracht, Methoden zu entwickeln, anzuwenden und zu vermitteln, die den gesamten Wertschöpfungsprozess in der Softwareentwicklung abdecken. Auch vor Claude und Codex ging es auf Konferenzen wie der GOTO bereits um Design Patterns, Performance, Sicherheit, Ways of Working, Softwarearchitektur, Agilität, Kommunikation mit Stakeholdern und Kunden, Wartung, Delivery und vieles mehr. Wie viele dieser Themen werden durch generative KI obsolet? Beantworte das für dich selbst.

Die viel größere Frage ist folglich: Wie viele dieser Themen sind tatsächlich Teil der täglichen Arbeit eines durchschnittlichen Softwareentwicklers in einem durchschnittlichen Unternehmen? Wenn ich die Fragen in Panel-Diskussionen und die Kommentare auf dem Bildschirm bei einigen Vorträgen als Indikator nehme, dann lautet die Antwort:

Zu wenige!

Die genannten Veteranen stimmen mir sicherlich zu, wenn ich sage: Viele Unternehmen ignorieren, bewusst oder unbewusst, große Teile dessen, was die Industrie über Jahrzehnte erarbeitet hat. Sie haben sich Hierarchien und Strukturen geschaffen, in denen Engineers kleine Zahnräder in riesigen Getrieben sind. Engineers in diesen Organisationen erhalten ausgearbeitete und vermeintlich „vollständige“ Tickets mit der Aufgabe, diese Anforderungen in Code zu übersetzen. Sie sprechen nicht mit Kunden. Sie haben keinen Raum, kreative Entscheidungen zu treffen. Sie können kaum experimentieren, iterieren, lernen und sich stetig verbessern. Oft kennen sie nicht einmal einen Teil der Roadmap oder das übergeordnete Ziel ihrer Arbeit und können dementsprechend auch nicht vorausschauend arbeiten.

Coding Agents (und Menschen) im Wald und in der Wüste

Das sind die Engineers, die gerade leiden. Klar, es gibt auch solche, die das Handwerk des Codings lieben und die wesentlich mehr Freude an ihrer Arbeit haben, wenn sie diejenigen sind, die den Code schreiben. Auch das muss man respektieren. (Man kann sich allerdings auch fragen, wie viele Engineers den Code nur deshalb so sehr lieben, weil er alles ist, was man ihnen in ihrer Organisation gelassen hat.)

Generative KI macht die Diskrepanz zwischen dem, was Veteranen seit Jahren predigen, und dem, wie Unternehmen tatsächlich arbeiten, offensichtlich. Trotzdem muss man genau hinschauen, um die richtigen Lehren daraus zu ziehen. Die Botschaft für Unternehmen ist eben nicht „Wir brauchen keine Engineers mehr“, sondern vielmehr: „Hm! Vielleicht setzen wir unsere Engineers nicht optimal ein.“

Wie setzt man Engineers optimal ein? Die Antwort hängt in Teilen natürlich von der Organisation ab. Ein paar bewährte Ansätze:

• Engineers nicht erst dann beteiligen, wenn ein fertig ausformuliertes Jira-Ticket existiert. So lassen sich technische Constraints früh erkennen und Feedback-Schleifen reduzieren.
• Engineers regelmäßig mit Kunden und Stakeholdern sprechen lassen, um Probleme besser verstehen zu können.
• Raum für Experimente (und damit auch für Innovation) schaffen.
• Engineers an der Erstellung der Roadmap beteiligen, damit sie zukünftige Entwicklungen technisch ermöglichen können, ohne diese bereits vorwegzunehmen (Optionality).

Coding Agents schaffen Zeit für diese Aufgaben, aber die Strukturen und Prozesse des Unternehmens müssen diese Veränderung unterstützen und entsprechend hinterfragt werden. Das ist nicht leicht, lohnt sich aber. Untersuchungen wie die DORA-Studien bestätigen seit Jahren den Zusammenhang zwischen Nutzerorientierung, guten organisatorischen Rahmenbedingungen und der Leistungsfähigkeit von Softwareorganisationen.

Kent Beck, der dankenswerterweise auch dieses Jahr in Kopenhagen war und eine tolle Abschluss-Keynote gehalten hat, würde sagen: Ihr habt lange genug in der Wüste gelebt. Vielleicht ist es Zeit, in den Wald zu ziehen.