Zum Hauptinhalt springen

Grenzen und Risiken

LLMs und agentische Systeme sind leistungsfähige Werkzeuge, bringen jedoch auch neue Risiken mit sich.
Diese Seite beschreibt technische und organisatorische Grenzen sowie typische Fehlanreize, die beim Einsatz solcher Systeme entstehen können.

Dabei geht es nicht darum, KI grundsätzlich abzulehnen. Vielmehr soll sichtbar werden, wo zusätzliche Aufmerksamkeit notwendig ist – insbesondere bei Architektur, Sicherheit, Review-Prozessen und langfristigem Systemverständnis.

Architekturdrift und Architekturblindheit​

LLMs sind besonders stark bei lokalen Lösungen.
Sie optimieren einzelne Funktionen, Module oder Konfigurationsprobleme oft sehr effektiv.

Das Problem entsteht dort, wo viele lokale Lösungen ohne übergeordnetes Systemverständnis zusammenkommen.

Typische Folgen sind:

  • inkonsistente Implementierungen
  • neue Abhängigkeiten zwischen Modulen
  • divergierende Architekturentscheidungen
  • wachsende Komplexität

Dieser Effekt wird häufig als Architekturdrift beschrieben:
Das System entfernt sich schrittweise von seiner ursprünglichen Struktur, ohne dass einzelne Änderungen offensichtlich problematisch erscheinen.

Ein weiterer Faktor ist Architekturblindheit.
Wenn generierter Code primär danach bewertet wird, ob er funktioniert, geraten Fragen der langfristigen Systemstruktur leicht in den Hintergrund.

Funktionierender Code ist nicht automatisch gute Architektur.

Sicherheits-, Compliance- und Lizenzrisiken​

Generierter Code kann auch Sicherheits- und Compliance-Risiken enthalten.

Bekannte Beispiele aus Studien und Praxis sind:

  • fehlende Eingabevalidierung
  • unsichere Authentifizierungslogik
  • SQL-Injection-anfällige Implementierungen
  • Nutzung ungeeigneter kryptographischer Verfahren

Zusätzlich können rechtliche Fragen entstehen, etwa durch:

  • Verwendung von Bibliotheken mit inkompatiblen Lizenzen
  • Übernahme von Codefragmenten unbekannter Herkunft

Da Modelle Trainingsdaten statistisch reproduzieren können, ist eine sorgfältige Überprüfung generierten Codes weiterhin notwendig.

Reviewkosten und Verifikationsaufwand​

LLMs können Code sehr schnell erzeugen.
Die Verantwortung für dessen Qualität bleibt jedoch beim Entwicklerteam.

Dadurch verschiebt sich ein Teil der Arbeit:

  • weniger Zeit für das Schreiben von Code
  • mehr Zeit für Review und Verifikation

Typische zusätzliche Aufgaben sind:

  • Überprüfung generierter Implementierungen
  • Validierung von Randfällen
  • Sicherstellung der Konsistenz mit bestehenden Architekturentscheidungen

Dieser Aufwand wird häufig unterschätzt, insbesondere in frühen Einführungsphasen.

Verantwortung und Entscheidbarkeit​

LLMs und agentische Systeme können Vorschläge generieren, Alternativen formulieren und vorhandene Informationen strukturieren. Sie übernehmen jedoch keine Verantwortung für Entscheidungen.

Ein Modell bewertet keine langfristigen Konsequenzen. Es führt keine Risikoabwägung durch und trägt keine Folgen falscher Entscheidungen. Seine Antworten entstehen aus statistischen Mustern in Trainingsdaten und Kontextinformationen.

Dadurch entsteht ein grundlegender Unterschied zwischen Unterstützung und Entscheidung.

LLMs können beispielsweise:

  • mögliche Lösungsansätze formulieren
  • Code generieren
  • Dokumentation erklären
  • Alternativen aufzeigen

Die Entscheidung darüber, welche Lösung sinnvoll ist, bleibt jedoch eine menschliche Aufgabe.

Halluzination und falsche Gewissheit​

Ein besonderes Risiko entsteht durch sogenannte Halluzinationen.

Modelle können:

  • falsche Informationen erzeugen
  • nicht existierende APIs vorschlagen
  • Dokumentation falsch wiedergeben
  • scheinbar plausible, aber falsche Erklärungen liefern

Problematisch ist dabei weniger der Fehler selbst, sondern die plausible Formulierung solcher Aussagen.

Wenn eine falsche Information ungeprüft übernommen wird, kann sie:

  • Sicherheitsprobleme verursachen
  • Fehlentscheidungen auslösen
  • technische Schulden erzeugen

Deshalb gilt eine einfache Regel:

Kritische Aussagen sollten überprüft werden – unabhängig davon, ob sie von einer KI oder von einem Menschen stammen.

Der Einsatz von LLMs verändert diese Verantwortung nicht.
Er macht sie lediglich sichtbarer.

Wissenserosion und Epistemic Debt​

Ein weiteres Risiko entsteht, wenn generierter Code übernommen wird, ohne vollständig verstanden zu werden.

In diesem Zusammenhang wird häufig der Begriff Epistemic Debt verwendet.
Er beschreibt Code, dessen Annahmen, Randbedingungen oder Designentscheidungen im Team nicht mehr nachvollziehbar sind.

Langfristige Folgen können sein:

  • längere Debuggingzeiten
  • schwerere Architekturentscheidungen
  • steigende Wartungskosten

Wissen über das System verschiebt sich dann teilweise von Menschen zu Werkzeugen – ohne dass das System selbst einfacher wird.

Abhängigkeitseffekte​

Mit zunehmender Nutzung von KI-Werkzeugen kann eine gewisse Abhängigkeit entstehen.

Typische Beispiele sind:

  • geringere Routine beim Schreiben bestimmter Codearten
  • weniger Erfahrung mit grundlegenden Bibliotheken
  • stärkere Bindung an bestimmte Tools oder Plattformen

Diese Effekte sind nicht zwangsläufig problematisch, können aber langfristig Auswirkungen auf die Kompetenzentwicklung von Teams haben.

Fehlanreize durch Output-Metriken​

Viele Organisationen messen Produktivität über leicht sichtbare Kennzahlen wie:

  • Anzahl von Commits
  • erzeugte Codezeilen
  • Anzahl Pull Requests

LLMs können solche Kennzahlen leicht erhöhen, ohne dass sich die tatsächliche Systemqualität verbessert.

Wenn solche Metriken unreflektiert verwendet werden, entstehen Fehlanreize:

  • mehr Code statt besserer Struktur
  • schnellere Implementierung statt nachhaltiger Architektur
  • inkonsistente Entscheidungen über Modulgrenzen hinweg

Eine stärkere Fokussierung auf Outcome statt Output kann helfen, diese Effekte zu reduzieren.

Funktionierender Code ist nicht automatisch wartbarer Code​

Ein besonders kritischer Punkt entsteht durch die Kombination aus zwei Faktoren:

  • begrenztem Wissen oder Erfahrung des Entwicklers
  • halluzinierten oder unvollständigen Modellantworten

In solchen Situationen kann Code entstehen, der zwar scheinbar korrekt funktioniert, dessen Struktur oder Annahmen jedoch problematisch sind.

Typische Folgen sind:

  • schwer wartbare Implementierungen
  • versteckte Randfälle
  • unklare Verantwortlichkeiten im Code

Dieser Effekt ist besonders gefährlich, weil Probleme oft erst später sichtbar werden.

Rolle des Entwicklers​

LLMs können Entwicklungsarbeit unterstützen, aber sie ersetzen nicht die Verantwortung eines gut ausgebildeten Entwicklers.

Stand heute (2026) können solche Systeme:

  • Vorschläge generieren
  • Lösungen skizzieren
  • Code analysieren
  • Dokumentation erstellen

Sie können jedoch nicht zuverlässig:

  • Architekturentscheidungen verantworten
  • Systemwirkungen langfristig bewerten
  • komplexe organisatorische Kontexte verstehen

Der Einsatz von KI verändert daher vor allem wie Software entwickelt wird – nicht wer die Verantwortung für das System trägt.

Diese Grenzen und Risiken bedeuten nicht, dass LLMs vermieden werden sollten.
Sie zeigen vielmehr, wo zusätzliche Aufmerksamkeit notwendig ist, damit ihre Stärken genutzt werden können, ohne neue strukturelle Probleme zu erzeugen.

Im nächsten Abschnitt wird daher betrachtet, welche Auswirkungen der Einsatz von KI auf Softwaresysteme und Organisationen insgesamt haben kann.