Wertschöpfung jenseits des Editors

Die eigentliche Wertschöpfung der Softwareentwicklung war schon immer die Auslieferung funktionierender Systeme (working software) und nie das manuelle Schreiben von Code. Das Schreiben von Code ist die notwendige Übersetzungsschicht, also die handwerkliche Barriere, um z. B. fachliche Anforderungen maschinenlesbar zu machen.

Dass dieser Schritt historisch als der größte Engpass wahrgenommen wurde, lag vermutlich weniger an der Zeit, die das Schreiben von Code beanspruchte. Empirische Untersuchungen zur Zeiteinteilung von Entwicklern zeigen beständig, dass innerhalb der eigentlichen Programmiertätigkeit der Großteil der Zeit in das Lesen von Code und das Verstehen komplexer Systeme fließt1, während die Programmiertätigkeit gemessen an der Gesamtarbeitszeit von Entwicklern nur einen geringen Anteil ausmacht2. Diese Beobachtung lässt sich in Beziehung setzen zu der von Fred Brooks bereits 1986 in seinem einflussreichen Aufsatz No Silver Bullet getroffenen Unterscheidung zwischen essenzieller Komplexität, also der Fachlogik eines Problems selbst, und akzidenteller Komplexität, der Mühe ihrer technischen Umsetzung.3 Daraus lässt sich ableiten, dass die Herausforderung schon immer im Mangel an Personen lag, die essenzielle Komplexität überhaupt durchdringen und in eine korrekte Struktur überführen konnten.

Wenn generative KI-Systeme die Implementierung nun beschleunigen, werden die eigentlichen Engpässe im SDLC, also die Definition der Absicht (Intent) und das kritische Urteil über das Ergebnis (Judgment), deutlicher sichtbar. Beides wurde bisher größtenteils während der manuellen Implementierung adressiert. Im Kontext mittlerer und größerer Unternehmen, wo Skalierbarkeit, Governance und IT-Sicherheit über den Erfolg entscheiden, wird insbesondere die menschliche Aufsicht, also der Human-in-the-Loop (HITL), zum kritischen Nadelöhr.

Intent und Judgment als Kernkompetenzen

Der in einem Whitepaper von Google formulierte Leitsatz “The human provides intent, architecture, and judgment”4 beschreibt den konkreten Aufgabenzuschnitt im modernen SDLC. Die menschliche Wertschöpfung konzentriert sich zunehmend auf die präzise Formulierung der Absicht und die kritische Bewertung des Ergebnisses.

Intent: Die präzise Formulierung der Absicht

Der Mensch gibt die strategische Richtung und die fachlichen Regeln vor (Was), während der Agent die Ausführung übernimmt (Wie). Domänenexpertise wird hierbei zum entscheidenden Hebel. Je tiefer das Fachwissen des Menschen, desto effektiver arbeitet der Agent pro Prompt.5

In meinen privaten Projekten habe ich beobachtet, dass sich der Schwerpunkt der frühen Entwicklungsphasen massiv verschiebt:

  • Requirements Engineering und Business Analysis: Das Schreiben maschinen- und menschenlesbarer Spezifikationen gewinnt wieder an Bedeutung und vage formulierte User Stories treten in den Hintergrund. Dies habe ich in meinem Beitrag Spec-Driven Development im SDLC aufgegriffen.
  • Context Engineering: Die gezielte Bereitstellung von Systemkontext, Richtlinien und Constraints an den Agenten über strukturierte Konfigurationsdateien wird zur Kernkompetenz.

Ich kann also ein weiteres Zitat aus dem Whitepaper bestätigen: “We are no longer waiting on human hands to type boilerplate; we are waiting on human minds to define the boundaries.”4

Judgment: Das Urteilsvermögen und die Verifikation

Die autonome Codegenerierung macht eine kontinuierliche Verifikation erforderlich. Der Entwickler muss den generierten Code verstehen und bewerten können. Da KI-Systeme (zumindest aktuell noch) keine rechtliche Verantwortung übernehmen können, bleibt das Judgment beim Menschen verankert.

Ein Praxisbeispiel zeigt, wie eng Verantwortung und Judgment miteinander verwoben sind. Die offiziellen Richtlinien der Kernel-Entwicklung für Linux6 untersagen das automatische Einfügen von Signed-off-by-Tags durch KI-Systeme. Nur ein Mensch darf das Developer Certificate of Origin (DCO) rechtlich wirksam zeichnen, um die Herkunft und Korrektheit des Codes zu garantieren. Der Mensch urteilt folglich nicht nur über die Qualität des Codes, sondern auch darüber, ob er die daraus entstehende Verantwortung tragen kann und will. Beiträge mit KI-Beteiligung müssen stattdessen transparent mit einem Assisted-by:-Tag deklariert werden.

Diese Verschiebung hin zu einer überwachenden Rolle (Supervisory Engineering) verändert bereits heute die tägliche Arbeit. Ergebnisse einer Längsschnittstudie von 2026 deuten darauf hin, dass 82 % der Entwickler über eine Reduktion der reinen Implementierungszeit berichten.7 Trotz hoher wahrgenommener Produktivität stieg jedoch der Anteil der Entwickler mit verschlechterter Developer Experience in mindestens einer Dimension von 14 % auf 27 %.7 Dieses Paradoxon spiegelt die Frustration über das reine “Abnicken” wider.

Die trügerische Plausibilität generierten Codes

Die Fähigkeit zum Judgment setzt voraus, dass der Mensch Fehler im generierten Code zuverlässig erkennen kann. Je plausibler der Code aussieht, desto herausfordernder ist dies.

Moderne Sprachmodelle erzeugen Code, der syntaktisch einwandfrei kompiliert, sich flüssig liest und auf den ersten Blick absolut schlüssig wirkt. Subtile logische Fehler, wie fehlerhafte Annahmen über eine API, ein falscher logischer Operator oder ein übersehener Edge Case in der Schleifensteuerung, verstecken sich perfekt hinter einer syntaktisch sauberen Fassade.

Die Erfahrung mit meinen privaten Projekten bestätigt mir, dass das manuelle Reviewen von solchem Code kognitiv weitaus anstrengender ist als die Überprüfung von klassisch von Menschen geschriebenem Code. Das Gehirn wird durch die optische Plausibilität regelrecht ausgetrickst. Da der Code fehlerfrei kompiliert, signalisiert unser Gehirn vorzeitig “Erledigt”.

Die psychologischen Folgen im Entwickleralltag sind aus der Forschung zur Automatisierung bekannt. Es entstehen zwei typische Effekte, die unter Mehrfachbelastung und Zeitdruck drastisch zunehmen:

  • Automation Complacency8: Eine unzureichende Überwachung des Systems aufgrund einer hohen gefühlten Zuverlässigkeit.
  • Automation Bias8: Die Tendenz, fehlerhafte Vorschläge des Systems aktiv zu übernehmen, selbst wenn eigene Zweifel vorliegen.

Hinzu kommt eine ausgeprägte “AI Fatigue”, wenn Entwickler triviale KI-Entscheidungen im Minutentakt freigeben müssen. Diese monotone Kontrolltätigkeit führt zu Ermüdung, die die Aufmerksamkeit verringert und letztlich unachtsame Freigaben provoziert. Das vermeintliche Sicherheitsnetz des menschlichen Reviews wird dadurch unbemerkt durchlässig.

Auf systemischer Ebene entspricht dies genau den von Lisanne Bainbridge bereits 1983 beschriebenen “Ironies of Automation”9. Die Ironie liegt darin, dass die Automatisierung den Menschen zwar von der Routine entlasten soll, ihn aber gleichzeitig in die anspruchsvollere Rolle des Supervisors drängt. Je zuverlässiger das automatisierte System im Schnitt arbeitet, desto schwieriger wird es für den menschlichen Operator, die verbleibenden, seltenen Abweichungen und Edge Cases durch passive Überwachung noch rechtzeitig zu erkennen.

Wenn nun die Barrieren für die Erstellung von Quellcode fallen, steigt die Frequenz der Änderungen exponentiell an. Ohne einen Filter verlagert sich die kognitive Last als “Review Rent” auf erfahrene Entwickler.10 Eine empirische Analyse von über 300.000 Commits zeigt, dass durch KI erzeugter Code vermehrt Qualitätsprobleme und Code Smells in Repositories einbringt, von denen fast ein Viertel langfristig ungelöst im Code verbleibt.11

Die Grenzen von Evals und Guardrails

Ein naheliegender Lösungsansatz für diese Flut an Pull Requests wäre die vollständige Automatisierung der Qualitätskontrolle durch nachgelagerte KI-Instanzen, namentlich durch automatisierte Guardrails und Evaluations-Frameworks (Evals). Doch diese Werkzeuge sind selbst noch nicht ausgereift und beruhen auf einem häufigen Missverständnis bezüglich ihrer Leistungsfähigkeit.

Während Unit- und Integrationstests deterministische Regressionen zuverlässig erkennen, messen Evals das nicht-deterministische Verhalten der Sprachmodelle. Mittels generativer KI versuchen sie, qualitative Bandbreiten zu bewerten, um logische Abweichungen aufzudecken.12 Da diese Evals und Guardrails jedoch selbst auf probabilistischen Modellen basieren, sind sie inhärent fehleranfällig und erzeugen eine zweite Ebene des Nicht-Determinismus. Sie können die Fehlerquote von Agenten statistisch senken, aber sie ersetzen nicht das finale Urteil des Menschen. Die Vorstellung einer vollautomatischen Pipeline, in der “KI die KI kontrolliert”, bleibt vorerst eine Vision.

Regulatorische und rechtliche Treiber

Hinweis: Ich bin kein Anwalt und dies ist keine Rechtsberatung.

Im Enterprise-Umfeld ist die menschliche Aufsicht kein rein technisches Qualitätsmerkmal, sondern eine rechtliche Notwendigkeit. Der Haftungsdruck entsteht aus dem Zusammenspiel verschiedener europäischer Regulierungswerke, die das Risikomanagement in der Softwareentwicklung neu definieren:

  • Cyber Resilience Act (CRA): Für alle Unternehmen, die Softwareprodukte oder digitale Komponenten auf dem EU-Markt bereitstellen, schreibt der CRA eine strenge Produkthaftung und Schwachstellenverwaltung vor. Da Code-Generatoren unberechenbare Sicherheitslücken erzeugen können, könnte das ungeprüfte Einschleusen von KI-Code in marktplatzierte Software direkt die gesetzliche Sorgfalts- und Dokumentationspflicht der Hersteller verletzen.
  • NIS2-Richtlinie: Für Unternehmen, die als wichtige oder wesentliche Einrichtungen in den Anwendungsbereich von NIS2 fallen (insbesondere ab mittlerer Größe in kritischen Sektoren), ist die Absicherung der IT-Lieferkette zwingend vorgeschrieben. Der unkontrollierte Einsatz von Code-Generatoren ohne menschliche Verifikation könnte diese Sorgfaltsanforderungen verletzen und stellt somit ein Compliance-Risiko dar, das im Ernstfall eine persönliche Haftung der Geschäftsführung nach sich ziehen kann.
  • EU AI Act (Dokumentationspflicht & Schatteneffekt): Ein Coding-Agent ist im Regelfall kein Hochrisiko-KI-System, da Softwareentwicklung an sich nicht unter die Anwendungsbereiche von Anhang III fällt. Dennoch erzeugt die Verordnung erheblichen Governance-Druck: Einerseits zwingt Artikel 6 Absatz 4 Unternehmen zu einer lückenlosen Dokumentation der Selbsteinschätzung, warum ihre Systeme nicht als Hochrisiko einzustufen sind. Andererseits etablieren Enterprises freiwillige Verhaltenskodizes (Codes of Conduct nach Artikel 95), um die strengen Anforderungen an die menschliche Aufsicht (Human Oversight) als Praxis im Risikomanagement zu adaptieren und zukünftige regulatorische Verschärfungen abzufedern.
  • DSGVO (Data Protection by Design & Sicherheit der Verarbeitung): Nach den Artikeln 25 (Data Protection by Design) und 32 DSGVO müssen Unternehmen den Schutz und die Sicherheit personenbezogener Daten durch geeignete technische und organisatorische Maßnahmen bereits bei der Entwicklung und im Betrieb sicherstellen. Da Coding-Agenten unbeabsichtigt Sicherheitslücken (z. B. aus den OWASP Top 10) generieren oder Datenschutzprinzipien verletzen können, wird ein menschliches Code Review zu einem zentralen Baustein, um diese gesetzlichen Schutzpflichten in der produktiven Anwendung umzusetzen.

Sicherheitsrisiken im agentischen SDLC

Neben regulatorischen Vorgaben zwingen konkrete Angriffsvektoren zur Vorsicht. Ein überprivilegierter Coding-Agent birgt das Risiko des Confused-Deputy-Problems13. Durch indirekte Prompt-Injektionen, beispielsweise über manipulierte Anweisungen in einer README-Datei eines geklonten Third-Party-Repositories, kann der Agent dazu verleitet werden, schädliche Befehle auf dem Host- oder im CI-System auszuführen.

Eine technisch raffiniertere Variante dieser Angriffsklasse sind unsichtbare Schadcodes (Invisible Payloads) in Repositories.13 Angreifer nutzen zero-width Unicode-Zeichen oder Homoglyphen, um versteckte Steuerbefehle direkt in den Code einzuschleusen. Während der menschliche Reviewer nur sauberen, harmlosen Code sieht, liest das Sprachmodell diese unsichtbaren Zeichen ein und interpretiert sie. Da Agenten Code in hohem Tempo replizieren, kann sich eine solche Prompt-Injektion innerhalb kürzester Zeit unbemerkt über das gesamte System verbreiten.

Um dieses Risiko zu minimieren, ist insbesondere Zero-Trust notwendig:

  1. Zero Ambient Authority: Ein Agent darf niemals standardmäßig die Admin-Rechte des angemeldeten Benutzers erben.
  2. Just-in-Time Downscoping: Zugriffstoken und API-Schlüssel dürfen nur für die exakt benötigte Operation und mit minimalen Rechten ausgestellt werden.
  3. Sandboxing: Alle agentischen Operationen (wie Testausführungen oder Dateioperationen) müssen in flüchtigen, isolierten Containern stattfinden.
  4. Egress Filtering: Der ausgehende Netzwerkverkehr der Agenten muss standardmäßig blockiert und auf eine restriktive Whitelist, wie interne Paket-Registries und zugelassene APIs, beschränkt werden. Dies verhindert, dass ein kompromittierter Agent nach einer Prompt-Injektion sensible Daten wie Quellcode oder Umgebungsvariablen an externe Server abfließen lässt.
  5. Immutable Audit Trails: Jede vom Agenten ausgeführte Aktion, einschließlich aller Tool-Aufrufe, Terminal-Befehle und Dateiveränderungen, muss in einem unveränderlichen, zentralen Logbuch aufgezeichnet werden. Dies ist unerlässlich für die Compliance und ermöglicht im Schadensfall eine lückenlose forensische Rekonstruktion der agentischen Trajektorie.
  6. Dependency Gatekeeping: Dem Agenten muss die autonome Installation neuer externer Abhängigkeiten untersagt sein. Jedes neue Paket muss vorab eine automatisierte Verifikationsstufe durchlaufen, um die Einschleusung von Malware über manipulierte oder vom Modell halluzinierte Paketnamen zu blockieren.
  7. Centralised Agent Gateways: Um das Spoofing von Tool-Schnittstellen wie dem Model Context Protocol (MCP) zu verhindern, müssen alle Zugriffe auf interne Werkzeuge über ein zentrales Gateway laufen. Dieses Gateway prüft dynamisch, ob die vom Agenten angeforderte Tool-Verbindung mit der ursprünglichen, vom Entwickler definierten Absicht übereinstimmt (Contextual Authorisation).

Das geschichtete Review-Modell

Um die Produktivitätsgewinne der KI-Generierung nicht durch manuelle Review-Prozesse zu neutralisieren, ist ein geschichtetes Review-Modell erforderlich. Damit nicht jeder Change auf dieselbe Weise geprüft werden muss, erscheint es sinnvoll, stattdessen eine risikobasierte Eskalation zu etablieren, die den menschlichen Aufwand am potenziellen Schaden ausrichtet.

Ebene 1: Vollautomatisierte Syntax- und Stilkontrolle

Typ-Integrität, Syntaxfehler, Formatierung, statische Code-Analysen (Lints) und einfache Regressionstests werden, ohne menschliches Zutun, vollständig an die Toolchain und die CI-Pipeline ausgelagert.

Ergänzt wird diese Stufe durch ein automatisiertes Pre-Review und Red Teaming, bei dem unabhängige Sicherheitsagenten den generierten Code vorab auf logische Angriffsvektoren und Schwachstellen untersuchen. Schlägt ein Test oder ein Sicherheitsscan fehl, geht der PR direkt zurück an den Ersteller-Agenten zur Selbstkorrektur (Self-Healing) unter Einhaltung eines strikten maximalen Retry-Budgets, um endlose Schleifen und Kosten bei logischen Konzeptionsfehlern zu verhindern. Erst bei Überschreitung dieses Budgets erfolgt eine Eskalation an ein menschliches Review. Zudem muss die Testintegrität überwacht werden, denn autonome Agenten neigen in Self-Healing-Schleifen dazu, fehlschlagende Test-Assertions einfach abzuschwächen oder anzupassen, anstatt den zugrundeliegenden Logikfehler im Produktivcode korrekt zu beheben.

Auf Ebene 1 sollte zusätzlich ein Policy Server zum Einsatz kommen, der mittels Structural Gating12 schnelle, regelbasierte Binärprüfungen von Werkzeugaufrufen nutzt, um z. B. Verstöße gegen Architekturvorgaben aufzudecken, ohne einen dedizierten Agenten für diese Aufgabe einbeziehen zu müssen.

Ebene 2: Fachlogik und architektonische Integrität

Statt Zeile für Zeile zu lesen, fokussiert sich der Reviewer auf aggregierte Deltas und das Verhalten des Systems. PRs müssen zwingend eine KI-generierte Zusammenfassung der Änderungen und eine strukturierte Risikoabschätzung enthalten (Bundled Summaries).12

Der Mensch verifiziert die architektonische Integrität und die Geschäftslogik anhand des “Vibe Diffs”13. Dieser übersetzt den komplexen generierten Code zurück in eine verständliche, reintextliche Absichtserklärung und vergleicht die ursprüngliche Intention mit der tatsächlichen Ausführung. Dieses Verfahren birgt jedoch ein neues Risiko: Verlassen sich Teams zu stark auf abstrakte Zusammenfassungen, verlagert sich die Automation Complacency auf eine höhere Ebene. Der Reviewer verifiziert dann nicht mehr den tatsächlichen Code, sondern lediglich die Plausibilität seiner Beschreibung.

Um diese kognitive Last zu senken, müssen Agenten einer strukturierten Erklärungspflicht (Explainable Actions) unterliegen. Sie dürfen nicht nur Code-Änderungen einreichen, sondern müssen ihre architektonischen Entscheidungen und Absichten in einer verständlichen Erklärung parallel zum Diff begründen.

Zusätzlich lässt sich hier das Konzept des Conditional LGTM12 etablieren: Die Freigabe eines PRs erfolgt unter Vorbehalt. Der tatsächliche Merge in den Hauptzweig wird automatisch vollzogen, sobald alle nachgelagerten CI-Pipelines und Integrationstests erfolgreich durchlaufen sind. Dies erfordert jedoch eine robuste Merge-Queue-Architektur, um Konflikte zwischen parallel freigegebenen PRs zu vermeiden.

Ebene 3: Bereiche mit hohem Risiko

Bei kritischen Änderungen ist das manuelle Review einzelner Zeilen durch erfahrene Entwickler nach wie vor unverzichtbar. Dazu gehören insbesondere kryptografische Implementierungen oder Authentifizierungsmechanismen. Aber auch das Hinzufügen externer Abhängigkeiten ist kritisch, denn diese sind anfällig für Malware, welche z. B. durch Slopsquatting13 verbreitet wird.

Auch hier sollte wieder ein Policy Server zum Einsatz kommen, der diesmal durch Semantic Gating12 die inhaltlichen Absichten des Agenten mittels eines separaten Sicherheitsmodells gegen Richtlinien prüft. Da auf großen Sprachmodellen basierende Prüfungen nicht-deterministisch sind und zusätzliche Latenz erzeugen, führt dies in der aktuellen Praxis zu einem spürbaren Performance-Overhead in den CI-Pipelines, weshalb Semantic Gating derzeit meines Erachtens nur als experimentelle, nachgelagerte Kontrollinstanz und nicht als blockierendes Gate betrieben werden kann.

Kritische Freigaben auf dieser Ebene könnten zusätzlich kryptografisch durch ein physisches Hardware-MFA-Token abgesichert werden.

Die Zukunft des SDLC

Die Verschiebung hin zu Intent und Judgment wirft eine grundlegende zukünftige Herausforderung auf: Wie entwickeln Juniorentwickler die notwendige tiefe Fachexpertise und Urteilskraft, wenn das klassische “Learning by Doing” beim Schreiben einfacherer Programmteile durch generative KI wegfällt? Wer nie selbst fehlerhaften Code geschrieben und stundenlang Race Conditions gejagt hat, wird kaum die nötige Urteilskraft besitzen, um subtile logische Fehler in plausibel aussehendem Code zu entdecken. Die Gefahr des schleichenden Kompetenzverlustes ist hoch.

Die Zukunft des SDLC im Enterprise-Umfeld liegt in der klugen Orchestrierung von automatisierten Sicherheitsnetzen und fokussierten, menschlichen Kontrollpunkten an den Stellen, wo der größte Schaden verhindert werden kann.

Quellen

  1. Minelli, R., Mocci, A., & Lanza, M. (2015). I know what you did last summer: An investigation of how developers spend their time. 2015 IEEE 23rd International Conference on Program Comprehension (ICPC). ↩︎

  2. IDC (2025). How Do Software Developers Spend Their Time? (Document #US53204725). ↩︎

  3. Brooks, F. P. (1986). No Silver Bullet: Essence and Accidents of Software Engineering. University of North Carolina at Chapel Hill, Technical Report TR86-020. ↩︎

  4. Osmani, A., Saboo, S., & Kartakis, S. (2026). The New SDLC With Vibe Coding ↩︎ ↩︎

  5. Anthropic (2026). Agentic coding and persistent returns to expertise ↩︎

  6. Linux Kernel AI Coding Assistants Guidelines ↩︎

  7. Vella, A., & Blincoe, K. (2026). The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study (Preprint). ↩︎ ↩︎

  8. Parasuraman, R., & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation. Human Factors, 52(3), 381-410. ↩︎ ↩︎

  9. Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6), 775-779. ↩︎

  10. Kamalı, H.Ö., et al. (2026). Rethinking Code Review in the Age of AI: A Vision for Agentic Code Review (Preprint). ↩︎

  11. Liu, Y., et al. (2026). Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild (Preprint). ↩︎

  12. Boonstra, L. (2026). Spec-Driven Production Grade Development in the Age of Vibe Coding. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  13. Kartakis, S., et al. (2026). Vibe Coding Agent Security and Evaluation (Preprint). ↩︎ ↩︎ ↩︎ ↩︎