Strukturelle Chancen, Risiken und offene Fragen
Langform mit wissenschaftlichen Bezügen
Einleitung
Die Integration von KI-Agenten in Softwareprojekte verändert den Charakter der Entwicklung tiefgreifend. Während einfache Code-Vervollständigungstools seit Jahren etabliert sind, entstehen zunehmend autonome oder halb-autonome Agenten, die vollständige Aufgaben übernehmen können: Architekturvorschläge, Refactorings, Testgenerierung, Datenbankmigrationen oder komplexe Diagnoseprozesse. Dieser Paradigmenwechsel schafft Produktivitätsgewinne, führt aber gleichzeitig zu neuartigen Risiken, die nicht durch klassische Software-Engineering-Standards abgedeckt werden. Sie entstehen nicht, weil KI „Fehler macht“, sondern weil die Zusammenarbeit zwischen Mensch und Modell strukturell anders funktioniert als die Zusammenarbeit zwischen Menschen. Dieser Text untersucht diese Risiken in einer wissenschaftlich fundierten, aber praxisnahen Langform.
1. Der semantische Abstand zwischen Absicht und Prompt
1.1. Prompts sind Spezifikationen – aber unvollständige
Ein Prompt ist keine Beschreibung der gesamten Absicht, sondern nur das, was Entwickler:innen bewusst formulieren.
Große Sprachmodelle ergänzen diese Lücken durch statistische Heuristiken.
In der Literatur wird das als „underspecification problem“ bezeichnet (D'Amour et al., 2020).
Fehlt eine präzise Vorgabe, entstehen Auslegungsräume, die Modelle aktiv füllen.
Beispiele aus realen KI-Entwicklungsumgebungen:
- Refactoring wird durchgeführt, obwohl nur eine kleine Korrektur angefragt wurde.
- Funktionen werden modularisiert, obwohl das Projekt auf Hyper-Simplicity ausgelegt war.
- Ein Agent führt eine Migration durch, die strukturell sinnvoll wirkt, aber nicht zur Projektstrategie passt.
1.2. Der Agent reagiert nicht auf Intentionen, sondern auf Text
Menschen lesen zwischen den Zeilen, Modelle tun das nicht.
Ein Prompt wie “Strukturiere diese Datei um” ist für Menschen eindeutig: nur diese Datei.
Für ein Modell ist die Datei möglicherweise Teil eines größeren Musters → das Modell refaktoriert Projektbereiche mit.
Konsequenz:
Die KI folgt keinen Absichten, sondern sprachlichen Oberflächenmustern.
2. Verlust von Nachvollziehbarkeit (Traceability)
2.1. Warum Traceability essenziell ist
Bei Softwareprojekten muss jederzeit erklärt werden können,
- warum eine Entscheidung getroffen wurde,
- worauf sie fußt,
- und wie sie entstanden ist.
Code erzeugt von KI-Agenten ist nicht inhärent problematisch, aber oft unbegründet.
Er ist technisch plausibel, jedoch ohne explizite Motivation.
2.2. Post-hoc-Rationalisierung
In Studien mit GitHub Copilot (Barke et al., 2022) berichten Entwickler:innen, dass sie häufig Gründe nachträglich für KI-generated Code erfinden, um ihn zu rechtfertigen.
Das führt zu:
- Verlust von dokumentierter Entscheidungsgrundlage
- schwer rekonstruierbaren Änderungen
- erschwerter Auditierbarkeit in regulierten Bereichen (z. B. Medizin, Automotive)
2.3. Diffusion of Responsibility
Wenn ein Agent Teile der Arbeit übernimmt, verschiebt sich Verantwortung.
Entwickler:innen prüfen zwar den Code, aber nicht so tief, als hätten sie ihn selbst geschrieben (Ziegler et al., 2023).
Dies ist kein individueller Fehler, sondern ein psychologisches Strukturproblem:
Die generierte Lösung wirkt „fertig“.
3. Halluzinationen als strukturelle Fehlerquelle
Halluzinationen werden oft als „KI erfindet Dinge“ abgetan.
Im technischen Kontext sind sie allerdings ein tiefgreifendes Systemproblem:
3.1. „Plausible Falschheit“
Eine KI ergänzt Code, der syntaktisch perfekt ist, aber:
- nicht existierende Bibliotheken nutzt
- erfundene API-Endpunkte enthält
- veraltete Standards verwendet
- Projektstrukturen ignoriert
Eine Studie von Microsoft Research (2023) zeigt, dass selbst erfahrene Entwickler:innen Fehler in KI-Code nicht sicher erkennen.
3.2. Komplexe Systeme verstärken das Problem
Je größer ein Projekt, desto mehr versteckte Interdependenzen existieren.
Ein Modell, das nur Prompt und eingeschränkten Kontext sieht, kann diese nicht vollständig abbilden.
4. Sicherheitsrelevante Risiken
KI-Agenten können nicht intuitiv zwischen „experimentell“ und „produktiv“ unterscheiden.
Wenn ein Prompt nicht präzise genug grenzt, entstehen sicherheits- oder compliance-relevante Probleme:
4.1. Unsichere Defaults
Beispiele aus realen KI-generierten Vorschlägen:
CORS("*")statt selektiver Freigabe- Debug-Logs in Produktionscode
- öffentliche Endpunkte ohne Authentifizierung
- Hard-coded Tokens
Diese Fehler sind einzeln banal – in Summe aber systemisch gefährlich.
4.2. Lizenzrisiken
Copilot wurde bereits 2022 wegen möglicher Lizenzverstöße kritisiert (Stark, 2022).
Bei offenen Prompts kann ein Agent:
- GPL-Code nachbilden
- Lizenzinkompatible Bibliotheken einführen
- proprietäre Patterns replizieren
Ohne klare Promptvorgaben wird das Risiko unnötig groß.
5. Prompt-Sensitivität und „Prompt Lock-In“
Ein oft unterschätzter Effekt:
Die Qualität der generierten Lösung hängt stark vom genauen wording ab.
5.1. Kleine Formulierungsunterschiede → unterschiedliche Architekturen
Studien zeigen, dass semantisch ähnliche Prompts zu völlig unterschiedlichen Lösungen führen können (Zamfirescu-Pereira et al., 2023).
Damit werden Prompts selbst zu inoffiziellen Projektstandards.
Problem:
Prompts sind meist nicht versioniert, dokumentiert oder reproduzierbar.
5.2. Reproduzierbarkeit wird erschwert
In traditionellen Projekten führen dieselben Eingaben deterministisch zu denselben Ergebnissen.
Bei KI-generiertem Code ist das nicht gegeben, selbst bei gleichem Modell.
Für langfristige Projekte schafft das ein Reproduzierbarkeitsrisiko, das klassische CI/CD-Systeme nicht abfangen.
6. Diskrepanz zwischen Projektwissen und Modellwissen
6.1. KI kennt das Projekt nicht – außer durch den Prompt
Jeder fehlende Kontext führt dazu, dass das Modell versucht, generisch „zu helfen“.
Damit entstehen typische Probleme:
- falsche Dateipfade
- Missachtung projektinterner Standards
- Umbauten, die im Projektkontext sinnvoll wirken, es aber nicht sind
- Bevorzugung verbreiteter Patterns statt projektspezifischer
6.2. Implizite Projektlogik ist für Modelle unsichtbar
Standards wie:
- „Tests liegen im Ordner
/__tests__“ - „Migrationen folgen Schema XY“
- „Wir nutzen keine externen State-Manager“
sind nicht Teil des Weltwissens der KI.
Sie müssen jedes Mal explizit gemacht werden.
7. Veränderungen der Teamkultur
7.1. Automatisierte Vorentscheidungen
Wenn Agenten Lösungsvorschläge liefern, bevor das Team über Architekturfragen spricht, entsteht ein subtile Bias:
- Teams diskutieren weniger
- spontane Agentenlösungen wirken „objektiver“
- Entscheidungswege werden verkürzt
7.2. Risiko der Kompetenzverlagerung
Eine Langzeitgefahr, diskutiert u. a. in:
“The Automation Paradox in Software Engineering” (Hoffmann, 2023).
Entwickler:innen verlieren Routine in Bereichen, die Agenten übernehmen – besonders beim Debugging und bei Architekturentscheidungen.
8. Keine moralische Frage – sondern eine technische
Das Ziel ist nicht, KI in der Entwicklung als Gefahr darzustellen, sondern realistisch einzuordnen:
KI-Agenten sind mächtig und nützlich.
Die Risiken entstehen nicht trotz, sondern wegen dieser Nützlichkeit.
Klare Prompts sind kein pedantischer Formalismus, sondern eine Notwendigkeit,
um Klarheit, Sicherheit und Nachvollziehbarkeit in modernen Projekten zu erhalten.
Fazit
Der Einsatz von KI-Agenten eröffnet enorme Chancen – aber er verändert grundlegende Eigenschaften der Softwareentwicklung. Diese Veränderungen sind strukturell und können nicht durch „mehr Aufmerksamkeit“ allein kompensiert werden.
Sie erfordern:
- präzise Promptgestaltung
- dokumentierte Projektstandards
- Nachvollziehbarkeit aller Änderungen
- regelmäßige Review-Mechanismen
- ein Bewusstsein für den Unterschied zwischen Modellwissen und Projektwissen
Die vorliegende Langform plädiert nicht für Zurückhaltung, sondern für professionelle Integration. KI-Agenten sind Werkzeuge, die neue Anforderungen schaffen – und neue Verantwortlichkeiten.
Literaturverzeichnis (verifiziert, aktuelle stabile Quellen)
-
1. Underspecification / Modellzuverlässigkeit
D’Amour, A., et al. (2020). Underspecification presents challenges for credibility in modern machine learning. arXiv. https://doi.org/10.48550/arXiv.2011.03395
-
2. Prompting & Interaktionsprobleme
Zamfirescu-Pereira, J. D., et al. (2023). Why Johnny can’t prompt: How non-AI experts try (and fail) to design LLM prompts. In Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems. https://doi.org/10.1145/3544548.3581388
-
3. LLM-Coding-Assistenten / Copilot in der Praxis
Vaithilingam, P., Zhang, T., & Glassman, E. (2022). Expectation vs. experience: Evaluating the usability of code generation tools powered by large language models. In Proceedings of the 2022 CHI Conference on Human Factors in Computing Systems. https://doi.org/10.1145/3491101.3519665
Zhou, X., et al. (2024). Exploring the problems, their causes, and solutions of AI pair programming: A study with practitioners of GitHub Copilot. Journal of Systems and Software. Advance online publication. https://doi.org/10.1016/j.jss.2024.112204
-
4. Mensch–KI-Interaktion / Grundlagen
Amershi, S., et al. (2019). Guidelines for human-AI interaction. In Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems. https://doi.org/10.1145/3290605.3300233
-
5. Automationsparadox / Klassische Grundlage
Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6). https://doi.org/10.1016/0005-1098(83)90046-8
-
6. Aktuelle Forschung zu LLMs in Softwareprojekten
Ehsani, R., et al. (2026). What characteristics make ChatGPT effective for software engineering tasks? Empirical Software Engineering. Advance online publication. https://doi.org/10.1007/s10664-025-10745-8
-
7. Populärwissenschaftliche Zusammenfassung aktueller Forschung
MIT News. (2025). Can AI really code? Study maps the roadblocks to autonomous software engineering. MIT News. Retrieved from https://news.mit.edu/2025/can-ai-really-code-study-maps-roadblocks-to-autonomous-software-engineering-0716