Die Roboter stehen bereit. Aber wer liefert die Anforderungen?

Warum Agentic Coding auch die fachliche Zulieferung, Engineering-Rollen und die Organisation von Produktentwicklung verändern könnte.

Eine modernisierte Fabrik ohne Material

Stellen wir uns eine Fabrik vor, deren Produktion über Jahre hinweg auf eine bestimmte Geschwindigkeit ausgelegt war. Die Mitarbeiter konnten nur so viele Produkte fertigen, wie ihre Maschinen, Arbeitsabläufe und verfügbaren Stunden zuließen. Entsprechend hatten sich auch die Zulieferung, die Produktionsplanung und die Qualitätskontrolle auf diesen Durchsatz eingestellt. Das System war vielleicht nicht besonders schnell, aber die einzelnen Teile passten einigermaßen zueinander.

Dann investiert das Unternehmen in neue Roboter. Plötzlich können mehrere Arbeitsschritte gleichzeitig stattfinden, Routinetätigkeiten laufen automatisiert und die eigentliche Fertigung benötigt deutlich weniger menschliche Eingriffe. Die erste Diskussion dreht sich erwartungsgemäß um die Produktivität der neuen Maschinen – und ziemlich schnell auch darum, wie viele Mitarbeiter man künftig noch benötigt.

Nur hat niemand die Materialversorgung angepasst.

Die neue Produktionsstraße besitzt jetzt eine wesentlich höhere Kapazität, bekommt aber nicht entsprechend mehr brauchbares Material geliefert. Ihre Leistungsfähigkeit ist beeindruckend; als Produktionssystem wird die Fabrik deshalb noch lange nicht automatisch produktiver.

An dieses Bild muss ich denken, wenn ich die aktuelle Diskussion über Coding Agents verfolge. Wir sprechen viel darüber, wie schnell sich Code erzeugen lässt, wie viele Aufgaben parallel laufen können und welche Tätigkeiten früher ganze Entwicklerteams beschäftigt hätten. Wesentlich seltener höre ich die Anschlussfrage, wie eine Organisation dafür sorgt, dass diese neue Umsetzungskapazität überhaupt die richtigen Probleme bearbeitet.

Software ist natürlich kein Fließbandprodukt. Anforderungen sind keine austauschbaren Rohstoffe, die man vorne einfüllt und hinten als fertiges Feature erhält. Gerade in komplexen Produkten entwickeln sich Problemverständnis und Lösung häufig gemeinsam. Trotzdem hilft mir die Metapher, einen möglichen neuen Engpass sichtbar zu machen: Wir automatisieren die Fertigung und behandeln die fachliche Zulieferung, als hätte sich an deren Anforderungen nichts verändert.

Mehr Umsetzungskapazität allein schafft noch keinen Durchsatz. Die Fabrik ist eine Metapher: Anforderungen und Lösungen entwickeln sich in Rückkopplungen.

Grafik in Originalgröße öffnen

Drei Arbeitsströme sind nicht drei neue Fachdomänen

In meiner privaten Entwicklungsarbeit versuche ich gerade bewusst herauszufinden, wie sich mehrere Coding Agents sinnvoll parallel einsetzen lassen. Dabei laufen bei mir beispielsweise drei unterschiedliche Arbeitsströme: Ein Feature befindet sich im Feinschliff, bei einem zweiten entwickeln wir das fachliche und visuelle Konzept und starten die erste Implementierung, während ich für einen dritten Bereich ein neues Theme definiere und Varianten bewerte.

Das funktioniert, weil diese Arbeiten ganz unterschiedliche Anforderungen an meine Aufmerksamkeit stellen. Wenn die wesentlichen Entscheidungen für eine Funktion bereits getroffen sind, kann ein Agent vergleichsweise selbstständig implementieren oder korrigieren. Währenddessen kann ich an einer UX-Idee arbeiten, einen Entwurf prüfen oder die nächste fachliche Entscheidung vorbereiten. Ich versuche also nicht, drei unbekannte Fachdomänen gleichzeitig zu verstehen. Ich versuche, meine begrenzte menschliche Aufmerksamkeit so einzusetzen, dass die Agents möglichst wenig auf mich warten müssen.

Diese Art von Parallelität gefällt mir ausgesprochen gut. Sie ist aber keine magische Vermehrung meiner kognitiven Kapazität. Drei Agenten können gleichzeitig Code bearbeiten. Ich kann nicht gleichzeitig drei komplexe Entscheidungen mit derselben Tiefe durchdenken und drei Ergebnisse zuverlässig abnehmen. Deshalb ist die Wahl der Arbeitsströme fast wichtiger als ihre Anzahl.

Im Berufsalltag erlebe ich gelegentlich die entgegengesetzte Situation. Mehrere Produkte benötigen Pflege und Weiterentwicklung, aber es kommen nicht genügend fachlich geklärte, priorisierte Anforderungen nach. Ich kann dann Architektur verbessern, technische Schulden abbauen oder bestehende Strukturen konsolidieren. Das ist sinnvolle Arbeit, die mir durchaus Spaß macht. Nur entsteht daraus noch keine fachliche Roadmap.

In solchen Situationen fällt manchmal der Satz: „Du musst doch nur die Fachlichkeit durchdringen. Dann kannst du die Anforderungen selbst definieren.“

Genau hier beginnt für mich der eigentliche Denkfehler. Nicht weil Entwickler keine Fachlichkeit verstehen sollten, sondern weil wir oft drei Dinge ineinanderwerfen: ein fachliches Problem verstehen, eine fachliche Lösung mitgestalten und verbindlich entscheiden, welche Geschäftsregeln überhaupt gelten sollen. Diese Aufgaben hängen zusammen. Sie besitzen aber nicht automatisch dieselben Voraussetzungen, dieselbe Expertise oder dieselbe Verantwortung.

Acht Tage Geoinformatik – ohne Geoinformatiker zu sein

Ein aktuelles Projekt hat mir gezeigt, was möglich wird, wenn diese Voraussetzungen stimmen. Ich sollte eine anspruchsvolle geoinformatische Funktionalität in einer bestehenden Anwendung umsetzen. Es ging um Geometrien, Vektoren, geografische Grenzen, Berechnungen und ihre kartografische Darstellung. Das war nicht einfach eine neue CRUD-Maske, sondern eine Aufgabe mit fachlichen und mathematischen Zusammenhängen, in denen ich keineswegs zu Hause bin.

Geoinformatik ist eine eigenständige Spezialisierung. Das Institut der deutschen Wirtschaft wies in einer 2025 veröffentlichten Untersuchung für 2023 genau 1.694 sozialversicherungspflichtig Beschäftigte in der eng abgegrenzten Berufsgattung „Geoinformatik – Experte (Master/Diplom)“ aus. Daraus lässt sich nicht ableiten, dass nur 1.694 Menschen in Deutschland eine solche Software implementieren könnten. Die Zahl beschreibt eine statistische Berufsgattung, nicht die Menge qualifizierter Entwickler. Sie zeigt aber, warum ich die fachliche Expertise hinter dieser Aufgabe keineswegs als selbstverständlich voraussetzen konnte.

Ich bin Softwarearchitekt und kein Geoinformatiker. Und ich muss zugeben, dass ich zu Beginn erhebliche Zweifel hatte, ob wir das Problem in der vorgesehenen Form lösen würden.

Was wir allerdings hatten, war ein ungewöhnlich gutes Pflichtenheft. Es beschrieb die fachlichen Erwartungen so präzise, dass wir nicht zuerst geografische Regeln erfinden oder aus vagen Beispielen erraten mussten, welches Ergebnis wohl gemeint sein könnte. Stattdessen konnten wir die bestehende Implementierung systematisch mit den Anforderungen abgleichen, Lücken identifizieren, die relevanten Daten- und Berechnungsmodelle verstehen und daraus eine umsetzbare Planung ableiten.

Das eigentliche Ergebnis hat mich überrascht: zwei Tage Planung, zwei Tage agentische Implementierung, zwei Tage Review und zwei Tage Abnahme. In diesem acht Arbeitstage umfassenden Ablauf blieb bei der Abnahme lediglich ein kleinerer Rendering-Fehler übrig.

Um die Größenordnung etwas einzuordnen: Am Ende standen knapp 5.000 Zeilen fachlicher Implementierungscode und rund 10.000 Zeilen Testcode. Besonders bemerkenswert fand ich die ungefähr 800 fachlich motivierten Tests, mit denen wir die beschriebenen Anforderungen und zahlreiche relevante Szenarien überprüfen konnten. Das sind gerundete Erfahrungswerte, keine exakten wissenschaftlichen Messwerte.

Codeumfang ist für sich genommen kein Qualitätsmaßstab, und auch viele Tests garantieren keine fachliche Korrektheit. Die Größenordnung verdeutlicht für mich aber, wie umfangreich die technische Umsetzung war. Das präzise Pflichtenheft gab uns die Grundlage, die komplexe Problemstellung systematisch zu modellieren, agentisch zu implementieren und anhand zahlreicher fachlich motivierter Tests zu überprüfen. Die fachliche Abnahme blieb dabei unverzichtbar.

Ich möchte daraus ausdrücklich keinen Produktivitätsbenchmark machen. Der Aufwand zur Erstellung des Pflichtenhefts war in diesen acht Tagen nicht enthalten. Es gab bereits eine Anwendung, gegen deren Ist-Zustand wir die Anforderungen abgleichen konnten. Ich habe auch keinen kontrollierten Vergleich durchgeführt, wie lange dieselbe Arbeit ohne Coding Agents gedauert hätte.

Interessant finde ich die Verteilung dennoch. Nur zwei der acht Tage entfielen auf die agentische Implementierung; die übrigen sechs gingen in Planung, Review und Abnahme. Die fachliche Spezifikation war bereits eine vorhandene Vorleistung. Das eigentliche Engineering bestand darin, sie in eine tragfähige Lösung zu übersetzen, nicht darin, die Geoinformatik als Wissenschaft nebenbei neu zu erlernen.

Für mich ist diese Erfahrung ein starkes persönliches Argument dafür, wie leistungsfähig gute Arbeitsteilung werden kann. Ein erfahrener Ingenieur muss nicht jede Fachdisziplin beherrschen, wenn das notwendige Fachwissen in nachvollziehbaren Regeln, Randbedingungen und überprüfbaren Erwartungen verfügbar ist. Er muss aber erkennen können, wo die Spezifikation endet, welche technischen Fragen noch offen sind und wann wieder ein wirklicher Domänenexperte entscheiden muss.

Beobachtete Verteilung: 2 + 2 + 2 + 2 Arbeitstage. Erstellung des Pflichtenhefts nicht enthalten; einzelne Praxiserfahrung, kein Benchmark. Gerundete Erfahrungswerte: knapp 5.000 Zeilen fachlicher Implementierungscode, rund 10.000 Zeilen Testcode, ungefähr 800 fachlich motivierte Tests. Bei der Abnahme blieb ein kleinerer Rendering-Fehler. Codeumfang und Testanzahl garantieren keine fachliche Korrektheit.

Grafik in Originalgröße öffnen

„Du musst doch nur …“

In diesem Satz steckt noch ein zweites Problem, das mir inzwischen fast wichtiger geworden ist. Es beginnt selten damit, dass eine Organisation ausdrücklich verlangt, jeder Entwickler müsse sämtliche Disziplinen beherrschen. Die Erwartung wächst vielmehr in kleinen, vernünftig klingenden Schritten.

Du musst doch nur die Fachlichkeit etwas besser verstehen. Du musst doch nur die Pipeline anpassen. Du musst dich doch nur kurz um das Deployment kümmern. Security sollte natürlich ebenfalls von Anfang an berücksichtigt werden. Die UX kannst du doch mitgestalten. Und wenn du ohnehin gerade dabei bist, wäre Kubernetes vielleicht auch noch ein Thema.

Jede einzelne Aufforderung kann gerechtfertigt sein. In ihrer Summe entsteht jedoch ein Kompetenzprofil, das kaum noch eine einzelne Person vollständig ausfüllen kann. Schon Software Engineering selbst besteht aus einer Vielzahl eigenständiger Wissensgebiete. Frontend, Backend, verteilte Systeme, Datenbanken, Plattform-Engineering, Cloud-Infrastruktur, Security, Observability, Testautomatisierung und Softwarearchitektur lassen sich nicht beliebig auf Expertenniveau addieren. Jedes Mal, wenn ich glaube, im Engineering inzwischen halbwegs alles durchdrungen zu haben, kommt irgendwo ein Kubernetes um die Ecke.

Und jetzt soll zusätzlich aus jedem Entwickler ein Domänenexperte werden?

Ich kenne Menschen, die für fachliche Prozesse brennen. Sie arbeiten gern mit Anwendern, wollen Geschäftsregeln verstehen und entwickeln ihre größte Stärke an der Schnittstelle zum Produkt. Diese Menschen sollten wir unbedingt fördern. Andere begeistern sich vor allem für Software Engineering. Sie möchten komplexe technische Probleme lösen, Systeme entwerfen, Algorithmen verstehen und saubere Abstraktionen entwickeln. Auch sie sollten sich in dieser Richtung entfalten können.

Besonders vorsichtig werde ich bei den Menschen, die beides lieben. Nicht weil diese Kombination falsch wäre. Sie kann für ein Team außerordentlich wertvoll sein. Aber gerade solche Menschen laufen Gefahr, aus ihrer Neugier heraus immer mehr Aufgaben zu übernehmen, weil sie es können, weil sie helfen möchten und weil es zunächst gut funktioniert. Die Organisation lernt schnell, bei der nächsten offenen Frage wieder dieselbe Person anzusprechen.

Irgendwann sitzt dort jemand, an dem sämtliche Entscheidungen vorbeimüssen. Aus besonderem Engagement ist ein Single Point of Failure geworden. Und aus Begeisterung kann Überlastung entstehen, lange bevor alle Beteiligten die Schieflage erkennen.

Vielleicht kommt da bei mir ein bisschen der Vater durch. Ich möchte niemandem die Freude nehmen, Neues zu lernen oder über die eigenen Grenzen hinauszuwachsen. Aber Lernbereitschaft ist keine unbegrenzte Ressource, und Begeisterung für zwei Disziplinen ist keine Zustimmung dazu, dauerhaft die Verantwortung für beide vollständig zu tragen.

Crossfunktionalität bedeutet für mich deshalb, dass ein Team gemeinsam über die notwendigen Fähigkeiten verfügt. Nicht, dass jeder Einzelne alles können muss. Das ist auch die Grundidee, die der Scrum Guide für crossfunktionale Teams beschreibt. Selbstmanagement hebt unterschiedliche Verantwortlichkeiten nicht auf – und schon gar nicht die Grenzen dessen, was ein einzelner Mensch dauerhaft leisten kann.

Eine Spezifikation ersetzt keine Zusammenarbeit

Nach meinem GIS-Beispiel könnte leicht der Eindruck entstehen, ich würde mir eine Rückkehr zu klassischen Übergaben zwischen Fachabteilung und IT wünschen: Die Fachseite schreibt ein perfektes Pflichtenheft, anschließend verschwindet die Anforderung bei den Entwicklern, und einige Monate später kommt das Ergebnis zurück.

Das wäre ein Missverständnis. Eine gute Spezifikation muss weder besonders lang noch vor der ersten Umsetzung endgültig abgeschlossen sein. Gerade komplexe Anforderungen werden häufig erst durch gemeinsame Modelle, Fragen, Prototypen und erste Ergebnisse wirklich verstanden. Auch bei unserem geoinformatischen Beispiel mussten wir zunächst den Ist-Zustand abgleichen und Lücken identifizieren. Das funktionierte, weil wir einen belastbaren Bezugspunkt hatten, nicht weil jede denkbare Frage bereits ein für alle Mal beantwortet gewesen wäre.

Requirements Engineering beschreibt genau diese interdisziplinäre Zusammenarbeit. ISO/IEC/IEEE 29148:2018 behandelt das Erheben, Analysieren, Überprüfen, Validieren, Kommunizieren und Verwalten von Anforderungen über den Lebenszyklus eines Systems hinweg. Die Norm unterscheidet dabei auch, ob Anforderungen gut formuliert sind und ob sie tatsächlich das von den Stakeholdern beabsichtigte System beschreiben. Und noch einmal davon zu trennen ist die spätere technische Verifikation, ob das implementierte System seine spezifizierten Anforderungen erfüllt.

Für mich folgt daraus kein Plädoyer für mehr Bürokratie. Im Gegenteil: Je schneller implementiert werden kann, desto wertvoller werden kurze, präzise und überprüfbare Entscheidungen. Eine eindeutige Regel, ein guter Beispieldatensatz, nachvollziehbare Akzeptanzkriterien oder ein erreichbarer fachlicher Ansprechpartner können wesentlich nützlicher sein als ein umfangreiches Dokument voller ungeklärter Aussagen.

Der Entwickler soll fachliche Zusammenhänge verstehen, Widersprüche erkennen und sich aktiv an der Lösungsfindung beteiligen. Aber die fachliche Legitimation muss bei den Menschen und Rollen bleiben, die diese Entscheidung kompetent und verbindlich treffen dürfen. Ein ärztliches Fachurteil entsteht nicht dadurch, dass ein Entwickler das zugrunde liegende Datenmodell versteht. Und ein grüner Test beweist nicht, dass eine falsch vorgegebene Geschäftsregel plötzlich richtig ist.

Die Zusammenarbeit muss also enger werden, nicht strikter voneinander getrennt. Was ich kritisiere, ist etwas anderes: Wenn fachliche Verantwortung organisatorisch fehlt, wird sie gern stillschweigend auf die Person verlagert, die das Feature gerade technisch umsetzen kann.

Was Coding Agents an der Zulieferung ändern

Warum wird diese alte Frage ausgerechnet jetzt dringlicher? Weil die technische Umsetzung schneller werden kann, während fachliche Klärung nicht automatisch im selben Maß beschleunigt wird.

Ein Agent kann aus einer Beschreibung ein plausibles Datenmodell, eine Benutzeroberfläche, Services, Tests und eine komplette Änderung über mehrere Dateien hinweg ableiten. Das ist beeindruckend und in vielen Fällen ausgesprochen nützlich. Aber der Agent kann auch fachliche Annahmen ergänzen, die nie von einer zuständigen Person bestätigt wurden. Technische Konsistenz ist noch keine fachliche Autorisierung.

Die Forschung liefert inzwischen erste Hinweise auf diese Trennung. ClarifyCodeBench, ein 2026 veröffentlichter Preprint von Fang und Kollegen, untersucht an einem interaktiven Benchmark mit sechs Modellen, wie gut LLMs mehrdeutige Anforderungen selbstständig erkennen und durch Rückfragen klären. Die Ergebnisse deuten darauf hin, dass gute Codegenerierung nicht automatisch mit guter Anforderungsklärung einhergeht. Zusätzliche Reasoning-Leistung verbesserte die Identifikation von Mehrdeutigkeiten nur begrenzt, besonders wenn mehrere Unklarheiten zusammentrafen.

SpecBench von Hamblin und Kollegen untersucht ebenfalls 2026 eine verwandte, aber andere Fähigkeit: Agents sollen in Designvorschlägen aus realen RFC-Prozessen von Kubernetes, React, Rust, TVM und vLLM Auslassungen, Widersprüche und falsche Annahmen erkennen. Der beste untersuchte Agent erreichte dabei 44,4 Prozent Genauigkeit. Das ist keine allgemeine Fehlerquote für Product Ownership und kein Beleg dafür, dass künftige Modelle diese Aufgaben nicht besser bewältigen können. Es zeigt lediglich, dass das Prüfen einer Spezifikation eine eigene anspruchsvolle Aufgabe bleibt, die sich nicht aus einem guten Coding-Ergebnis ableiten lässt.

Und selbstverständlich kann KI auch die Zulieferung verbessern. Ich nutze sie selbst, um fachliche Fragen zu strukturieren, verschiedene UX-Ansätze zu vergleichen, Unklarheiten sichtbar zu machen und aus geklärten Entscheidungen konkrete Umsetzungsaufträge abzuleiten. Die interessante Grenze verläuft also nicht zwischen „KI darf implementieren“ und „KI darf keine Anforderungen bearbeiten“. Sie verläuft zwischen dem Erarbeiten von Vorschlägen und dem verbindlichen Entscheiden über ihre fachliche Gültigkeit.

Der DORA-Report 2025 beschreibt KI als Verstärker organisatorischer Stärken und Schwächen. Das passt zu meiner Beobachtung, beweist aber nicht, dass in Unternehmen mit Coding Agents zwangsläufig Product Ownership zum neuen Flaschenhals wird. Genau diese weitergehende Schlussfolgerung ist meine Hypothese.

Nicht mehr Product Owner zählen, sondern Entscheidungsfähigkeit

Früher konnte ein Product Owner – abhängig von Reife, Produkt und Komplexität – mehrere Entwickler oder auch mehr als ein Team begleiten. Je mehr Implementierungsarbeit auf der technischen Seite anfiel, desto größer war der Zeitraum, in dem neue Anforderungen vorbereitet und bestehende Entscheidungen abgestimmt werden konnten.

Wenn Coding Agents nun einen Teil dieser Implementierungszeit drastisch verkürzen, könnte das Verhältnis aus fachlicher Vorbereitung und technischer Umsetzung kippen. Meine ursprüngliche Intuition war, dass aus Verhältnissen von etwa einem Product Owner zu zehn Entwicklern in manchen Konstellationen etwas deutlich Engeres werden könnte. Ich würde daraus allerdings keine neue Sollquote von eins zu eins oder eins zu drei ableiten. Ein Product Owner ist schließlich nicht identisch mit Requirements Engineering, UX, fachlicher Expertise und Abnahme.

Mich interessiert vielmehr die Entscheidungskapazität pro gleichzeitig aktivem Arbeitsstrom. Wie viele fachliche Fragen kann eine Organisation rechtzeitig beantworten? Wie viele UX-Konzepte kann sie qualifiziert bewerten? Wie viele Anforderungen sind konkret genug, um sie zu implementieren und später gegen überprüfbare Erwartungen abzunehmen? Wie viel Zeit vergeht zwischen einer Rückfrage und einer verbindlichen Antwort?

Wenn ein Entwicklungsteam mangels geklärter Anforderungen vor allem nach eigenen Aufgaben sucht, ist das nicht automatisch ein Versagen der Entwickler. Ebenso wenig lösen zusätzliche Coding Agents diese Lücke von selbst. Mehr Produktionskapazität kann nur dann zusätzlichen Wert schaffen, wenn klar ist, welcher Wert überhaupt entstehen soll.

Die Lösung muss deshalb nicht lauten, für jeden Agenten einen Product Owner einzustellen. Vielleicht fehlen Business Analysts, vielleicht UX-Kapazität, vielleicht echte Domänenexperten, vielleicht ein entscheidungsfähiger Produktverantwortlicher oder schlicht ein klarer Produktauftrag. Auch die beste Rollenverteilung ist nutzlos, wenn niemand erreichbar ist, der einen fachlichen Widerspruch verbindlich auflösen kann.

Und manchmal ist die richtige Entscheidung tatsächlich, keinen weiteren Code zu erzeugen. Das Ziel einer guten Produktorganisation ist nicht, alle Agenten permanent auszulasten. Es ist, die richtigen Veränderungen zu liefern und uns die falschen zu ersparen.

Die Pfeile verbinden Verantwortlichkeiten und führen Erkenntnisse zurück zu den Anforderungen. Der mögliche Engpass vor der Implementierung bleibt eine Hypothese; weder eine feste Rollenquote noch ein Wasserfallprozess wird daraus abgeleitet.

Grafik in Originalgröße öffnen

Die Hypothese hinter der Fabrik

Aus diesen Erfahrungen leite ich eine bisher nicht direkt belegte Hypothese ab: Je stärker Coding Agents die technische Implementierung beschleunigen, desto stärker könnte der Gesamtdurchsatz einer Produktorganisation von ihrer Fähigkeit abhängen, fachlich validierte Anforderungen und zeitnahe Entscheidungen bereitzustellen.

Die Konsequenz wäre nicht automatisch ein Personalaufbau an einer bestimmten Stelle. Sie könnte eine andere Verteilung der Arbeit bedeuten: mehr bewusste Product Discovery, professionelleres Requirements Engineering, bessere technische Modellierung, früheres UX-Feedback und klar geregelte fachliche Abnahmen. KI könnte auch diese Tätigkeiten unterstützen und damit manche Engpässe abschwächen. Ob eine Organisation dadurch mehr oder weniger Menschen benötigt, ließe sich nur in ihrem konkreten Kontext beurteilen.

Eine zweite, menschliche Dimension gehört für mich dazu. Wenn ein begeisterter Entwickler heute schon Frontend, Backend, Architektur und Deployment übernimmt, darf die frei werdende Implementierungszeit nicht automatisch zur Einladung werden, ihm auch noch sämtliche Fachentscheidungen, UX-Fragen und regulatorischen Nachweise zu überlassen. Andernfalls haben wir zwar die Produktionsstraße automatisiert, aber ihre Abhängigkeiten auf einen einzigen Menschen konzentriert.

Vielleicht wird gerade die Fähigkeit, Spezialisten gut zusammenarbeiten zu lassen, zu einem der wichtigsten Erfolgsfaktoren von Agentic Work. Fachliche Experten bringen die Tiefe ihrer Disziplin ein. Softwareingenieure übersetzen diese Tiefe in Modelle und belastbare Systeme. Coding Agents übernehmen dort Arbeit, wo ihre Ergebnisse ausreichend eingegrenzt und verifiziert werden können. Und alle Beteiligten bleiben über die notwendigen Rückkopplungen verbunden.

Das ist keine Rückkehr zum Wasserfall. Es ist der Versuch, den gesamten Wertstrom so zu organisieren, dass Geschwindigkeit nicht mit ungeklärter Verantwortung bezahlt wird.

Fazit: Die Fabrik muss als Ganzes funktionieren

Mein geoinformatisches Praxisbeispiel hat mich überrascht, weil es gezeigt hat, wie weit erfahrenes Engineering mit einer guten Spezifikation und agentischer Unterstützung kommen kann – ohne dass der technische Umsetzer zugleich Fachwissenschaftler sein muss. Meine beruflichen Erfahrungen mit fehlenden Anforderungen zeigen mir die andere Seite: Selbst eine ausgezeichnete technische Produktionskapazität kann wenig bewirken, wenn fachlich nicht geklärt ist, was als Nächstes entstehen soll.

Wir sollten die Diskussion deshalb nicht auf die Frage verengen, wie viele Entwickler Coding Agents künftig ersetzen können. Wir müssen ebenso untersuchen, welche Voraussetzungen dadurch wichtiger werden – und wie sich die Arbeit zwischen Product Ownership, Fachseite, Requirements Engineering, UX, Architektur und Implementierung verändert.

Und wir sollten uns davor hüten, Menschen, die gern über ihren Tellerrand schauen, zu Allzwecklösungen für jede organisatorische Lücke zu machen. Ein crossfunktionales Team darf viel können. Ein einzelner Entwickler muss nicht Arzt, Geoinformatiker, UX-Designer, Plattform-Engineer und Softwarearchitekt zugleich sein.

Ich halte die neuen Möglichkeiten von Coding Agents für beeindruckend. Gerade deshalb möchte ich ihren Erfolg nicht allein daran messen, wie schnell sie die nächste Implementierung erzeugen. Für mich wird interessanter, wie zuverlässig eine Organisation aus fachlichem Wissen, verbindlichen Entscheidungen und guter Engineering-Arbeit tatsächlich richtige Software macht.

Die Roboter stehen bereit. Vielleicht sollten wir jetzt endlich auch über die Zulieferung, die Produktionsplanung und die Qualitätskontrolle sprechen.

Quellen und Einordnung

Dieser Artikel unterscheidet persönliche Praxiserfahrungen (GIS-Projekt: zwei Tage Planung, zwei Tage agentische Implementierung, zwei Tage Review, zwei Tage Abnahme; ein kleinerer Rendering-Fehler), angrenzende Forschung und eine ausdrücklich offene organisatorische Hypothese. Die acht Tage schließen die Erstellung des fachlichen Pflichtenhefts aus und sind keine vergleichende Produktivitätsstudie.

Burstedde, Alexander & Tiedemann, Jurek (2025): Kompetenzbarometer – Fachkräftesituation in Digitalisierungsberufen bis 2028. Institut der deutschen Wirtschaft, Tabelle 3-1 (Beschäftigte 2023: Geoinformatik – Experte, 1.694). https://www.iwkoeln.de/fileadmin/user_upload/Studien/Gutachten/PDF/2025/DIZ_Fachkr%C3%A4ftesituation_2023-2028.pdf

ISO/IEC/IEEE 29148:2018: Systems and software engineering – Life cycle processes – Requirements engineering. https://committee.iso.org/standard/72089.html

Fang, Zheng et al. (2026): ClarifyCodeBench: Evaluating LLMs on Clarifying Ambiguous Requirements for Code Generation. Preprint. https://arxiv.org/abs/2607.00711

Hamblin, Grant et al. (2026): SpecBench: Evaluating Specification-Level Reasoning for Software Engineering LLM Agents. Preprint. https://arxiv.org/abs/2605.30314

DORA / Google Cloud (2025): State of AI-assisted Software Development. https://dora.dev/research/2025/dora-report/

Schwaber, Ken & Sutherland, Jeff (2020): The Scrum Guide. https://scrumguides.org/scrum-guide.html

Weiterführend innerhalb der Serie: Prompt Engineering beginnt vor dem Prompt · Generation is cheap, verification is expensive · Die Ökonomie von Agentic Work · Software Engineering war nie nur Coding · KI beschleunigt unseren Weg in den Big Ball of Mud – eine Hypothese.