GPT im Engineering: Warum der unreflektierte Einsatz von KI-Tools Softwarearchitekturen langfristig gefährdet.

Veröffentlicht am 9. Juni 2024 - ⏱️ Ca. (wird berechnet) min. Lesezeit

Seit GPT und ähnliche Technologien in Entwicklungsumgebungen Einzug gehalten haben, herrscht eine Mischung aus Aufbruchsstimmung und Unsicherheit. Was zunächst als praktische Unterstützung für Routineaufgaben erscheint, kann sich schnell verselbstständigen. Wer glaubt, ein Large Language Model (LLM) könne das Systemdesign übernehmen, übersieht die aktuellen Grenzen dieser Werkzeuge. Die Vorstellung einer allgemeinen künstlichen Intelligenz ist zwar verlockend, doch gegenwärtig arbeiten wir mit Modellen, die klare Einschränkungen haben. Denn um dies ganz klar zu sagen und damit mit Nachdruck anderen Stimmen zu wiedersprechen: LLMs sind keine allgemeine Intelligenz! Einstweilen bleibt es ein Werkzeug!

Warum GPT kein echtes Verständnis besitzt

Ein Large Language Model ist im Kern ein statistisches Sprachmodell. Es berechnet auf Basis von Trainingsdaten und Wahrscheinlichkeiten, welche Wortfolgen sprachlich plausibel sind. Es verfügt jedoch nicht über ein tatsächliches Verständnis von Inhalten oder Konzepten. Konkret gilt:

• Es hat keine echte Historie, da es kein kontinuierliches Gedächtnis über Sessions hinweg besitzt.
• Es verfügt nicht über einen echten Kontext, denn jeder Prompt steht für sich, abgesehen von kurzfristigem Kontext innerhalb des Prompts.
• Es besitzt kein Systemverständnis, da es keine tatsächlichen Architekturen oder Zusammenhänge kennt, sondern nur sprachliche Muster verarbeitet.

Was bedeutet das im Detail? „Historie“ beschreibt die Fähigkeit, sich an frühere Entscheidungen, Änderungen oder Diskussionen zu erinnern. Ein Entwickler weiß zum Beispiel, warum ein bestimmtes Modul vor Monaten angepasst wurde. Ein LLM hingegen verliert diesen Verlauf nach jeder Session. Wenn man es heute nach einer Designentscheidung von gestern fragt, fehlt ihm dieses Vorwissen.

„Kontext“ bezieht sich auf das Verständnis der aktuellen Situation, der Anforderungen oder der Systemumgebung. Während ein Mensch beim Review einer Codebasis die Projektziele oder Abhängigkeiten mitdenkt, kennt das LLM nur die Informationen aus dem aktuellen Prompt. Es verliert schnell den Überblick, wenn die Konversation länger oder komplexer wird.

„Systemverständnis“ bedeutet, die Beziehungen, Regeln und Prinzipien eines Systems zu durchdringen. Ein erfahrener Architekt erkennt beispielsweise, warum bestimmte Services voneinander getrennt sind. Ein LLM kann zwar plausible Begriffe aneinanderreihen, aber nicht zwischen einer gewachsenen, konsistenten Architektur und einer bloßen Ansammlung von Codefragmenten unterscheiden.

Agenten helfen, erzeugen aber oft nur den Eindruck von Kohärenz

Agentensysteme können diese Defizite teilweise kaschieren. Sie verwalten Kontext über längere Konversationen hinweg und steuern gezielt die Nutzung von LLMs. Die grundlegende Einschränkung bleibt jedoch bestehen: Der Agent versteht das System nicht als eine explizite, konsistente Architektur. Er verwaltet Verläufe innerhalb der Prompteingaben und arbeitet mit Heuristiken, ohne ein echtes systemisches Modell.

Moderne Agentensysteme bestehen häufig aus mehreren Komponenten. Ein „Memory“-Modul speichert frühere Interaktionen, sodass der Agent sich an vergangene Fragen oder Antworten erinnern kann. Das ist vergleichbar mit einem Notizbuch, ohne jedoch die Zusammenhänge wirklich zu verstehen. „Tools“ ermöglichen es dem Agenten, externe Ressourcen zu nutzen, etwa Dokumentationen abzufragen oder Code zu analysieren. „Strategien“ steuern, wie der Agent Aufgaben angeht, beispielsweise durch schrittweises Vorgehen oder gezieltes Nachfragen bei Unsicherheiten.

Trotz dieser Funktionen bleibt der Agent in seinem Handeln reaktiv und oberflächlich. Er kann zum Beispiel eine Liste von API-Endpunkten zusammenstellen, aber nicht beurteilen, ob diese zur bestehenden Systemlandschaft passen. Wenn ein Memory-Modul die letzten Architekturentscheidungen speichert, kann der Agent diese zwar wiedergeben, aber nicht ihre Relevanz für neue Anforderungen einschätzen. Dadurch entsteht leicht eine trügerische Kohärenz. Das System wirkt konsistent, ist es jedoch nicht zwangsläufig.

Wenn KI einfach „irgendwas Gutes“ erzeugt

LLMs sind sehr gut darin, kleinere, klar abgegrenzte Aufgaben zu lösen. Beispiele sind Skripte für die Datenanalyse, eine kleine statische Homepage oder ein Unit-Test für eine klar beschriebene Funktion. Solange alle Anforderungen und der relevante Code im Prompt oder im kurzfristigen Kontext enthalten sind, liefert das Modell oft hilfreiche Ergebnisse.

Die Grenzen zeigen sich, sobald die Aufgabe über diesen Kontext hinausgeht. Wenn Teile der Architektur, historische Designentscheidungen oder implizite Systemregeln nicht im Prompt enthalten sind, beginnt das Modell zu halluzinieren. Es füllt Lücken kreativ, ohne echtes Verständnis. Das Ergebnis ist Code, der oberflächlich passend wirkt, aber systemisch nicht integriert ist. Dieser Effekt wird besonders deutlich, wenn Entwickler komplexere Systemteile im sogenannten „Vibe Coding“ erzeugen. Dabei verlassen sie sich auf GPT-generierte Strukturen, die im aktuellen Prompt gut erscheinen, aber in der Gesamtarchitektur keinen stabilen Platz haben.

Was in der Vorschau gut aussieht, kann in der Architektur wie ein Fremdkörper wirken.

In solchen Fällen besteht ein hohes Risiko, dass vermeintliche Produktivität heute technische Schulden für die Zukunft schafft.

Welche Bedeutung das für Architektur und Engineering hat

In der Softwareentwicklung sind diese Grenzen von großer Relevanz. Architektur ist keine bloße Aneinanderreihung sprachlicher Muster, sondern eine bewusste Gestaltung von Strukturen und Zusammenhängen im Raum und in der Zeit. Wer diese Verantwortung an ein LLM oder Agentensystem abgibt, verliert die aktive Steuerung des entstehenden Systems.

Sam Altman sagte: „Most users will soon trust AI with most decisions“. Das ist ein besorgniserregender Ausblick. In vielen Disziplinen und Lebensbereichen, insbesondere im Engineering, kann das nicht gelten. Architektur ist kein Bereich für blindes Vertrauen in generierte Vorschläge.

Das dargestellte Prinzip bleibt dabei entscheidend. Der Mensch muss im Steuerkreis der Architekturführung bleiben. Dieses Konzept stammt ursprünglich aus sicherheitskritischen Bereichen wie der Luft- und Raumfahrt, wo autonome Systeme zwar unterstützen, der Mensch jedoch als letzte Entscheidungsinstanz zwingend eingebunden bleibt. In der Softwarearchitektur bedeutet das: LLMs und Agenten können Beiträge liefern, Kontext andeuten und Vorschläge machen. Die finale Bewertung, Kontextvalidierung und Systemführung liegen jedoch ausdrücklich beim Architekten oder Entwickler. Wer dieses Prinzip konsequent umsetzt, schafft die Grundlage für einen verantwortungsvollen und strukturell gesunden Einsatz von KI im Engineering.

Wie ein verantwortungsvoller Einsatz konkret aussehen kann, zeigt folgendes Beispiel aus der Praxis:

Praxisbeispiel: Wie GPT im Engineering echten Mehrwert bieten kann

GPT kann bei reflektiertem Einsatz produktive Beiträge im Engineering leisten, sofern die Verantwortung klar beim Menschen verbleibt. In meiner eigenen Arbeit setze ich GPT gezielt unterstützend ein:

• Analyse fremder Codestrukturen: GPT hilft mir, in unbekanntem Code gezielt relevante Stellen zu identifizieren. Es bietet schnelle Orientierung, ohne selbst als endgültige Quelle betrachtet zu werden.
• Dokumentationssuche: Bei Fragen zur Funktionsweise von Technologien liefert GPT oft hilfreiche Impulse. Ich prüfe diese jedoch stets kritisch, da Halluzinationen hier besonders häufig auftreten.
• Strukturelle Hilfestellung: In einem aktuellen Projekt habe ich GPT für die Erstellung eines Swift-Plugins für Ionic genutzt, einem Bereich, der nicht mein primärer Schwerpunkt ist. GPT konnte mir dabei die Grundstruktur effizient liefern. Durch eigene Prüfung, Nachvollziehen und gezielte Anpassung entstand daraus eine tragfähige Lösung. Dieser Ansatz - GPT als Assistent, der Mensch als validierende und führende Instanz - zeigt den tatsächlichen Mehrwert der Technologie.

Diese Beispiele verdeutlichen, dass GPT Engineering-Prozesse bereichern kann. Voraussetzung ist jedoch, dass Entwickler und Architekten den methodischen Rahmen aktiv gestalten und die Verantwortung für Qualität und Architekturführung nicht abgeben.

Wer verantwortungsvoll mit GPT und ähnlichen Technologien arbeiten möchte, sollte sich mit den methodischen Grundlagen auseinandersetzen. Denn Klarheit beginnt nicht mit der Optimierung von Prompts, sondern mit einem fundierten Verständnis der Architektur.

Das Prinzip „Human in the Loop“ bleibt dabei zentral. LLMs und Agenten können Beiträge liefern, Kontext andeuten und Vorschläge machen. Die finale Bewertung, Kontextvalidierung und Systemführung liegen jedoch ausdrücklich beim Architekten oder Entwickler. Wer dieses Prinzip konsequent umsetzt, schafft die Grundlage für einen verantwortungsvollen und strukturell gesunden Einsatz von KI im Engineering.

LLMs können wertvolle Werkzeuge sein, etwa als Assistenten, Reflexionspartner und Helfer für Routineaufgaben. Architekturführung bleibt jedoch eine genuin menschliche Kompetenz. Wer diese unreflektiert an KI-Werkzeuge abgibt, riskiert, Systeme zu schaffen, die langfristig strukturell brüchig und schwer beherrschbar sind.

Fazit

LLMs haben die Softwareentwicklung nachhaltig verändert. Zwischen euphorischer Erwartung und tiefer Verunsicherung schwankt der Umgang mit diesen Werkzeugen. Viele Entwickler können derzeit nicht klar einschätzen, wo die Grenzen liegen und welche Rolle sie selbst im Zusammenspiel mit solchen Systemen einnehmen.

LLMs sind leistungsfähige Werkzeuge, übernehmen jedoch keine Führung. Sie urteilen nicht und tragen keine Verantwortung. Diese Aufgaben bleiben beim Menschen, insbesondere dort, wo Systeme wachsen, altern und dauerhaft tragfähig bleiben müssen.

Ein sicherer und methodischer Umgang mit dieser neuen Klasse von Werkzeugen erfordert klare Rahmenbedingungen. Solche Methoden fehlen heute häufig. An dieser Stelle möchte ich in den kommenden Wochen konkrete Impulse geben. Es geht um einen bewussten und verantwortungsvollen Einsatz von GPT und ähnlichen Technologien im Engineering.

In den nächsten Beiträgen werde ich aufzeigen, wie sich eine solche Führung konkret verankern lässt. Dabei geht es nicht um Tricks zur Optimierung von Prompts, sondern um methodische Klarheit, durchdachte Modularisierung und nachvollziehbares Architekturhandwerk. GPT kann viel leisten, jedoch nicht führen.