• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Künstliche Intelligenz
  • Datenbanken
  • Server
  • IT-Security
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
  • IT-Karriere
• Aktuelles
• Termine
• IT-Jobs

☰

• Entwicklung/Architektur
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

Stefan Zörner 29. April 2026

Ein erster AI-Agent für die Softwarearchitektur: Qualitätsziele im Dialog

Der von Andrej Karpathy Anfang 2025 geprägte Begriff des Vibe Coding beschreibt einen Programmierstil, bei dem die Entwicklerin oder der Entwickler die Ziele in natürlicher Sprache beschreibt und den dazu von einer KI generierten Quelltext akzeptiert, ohne ihn im Detail zu verstehen. Im Extremfall sogar, ohne ihn überhaupt auch nur zu betrachten. Auch wenn man es nicht ganz so durchzieht: Heute entsteht durch agentische Systeme viel Quelltext, der die Entwickelnden nicht im Einzelnen interessiert.

Wieviel Vorgabe oder Rahmen dabei Menschen-gemacht ist und wieviel von der KI kommt, hängt von der Arbeitsweise ab. Mitunter fügt ein AI-Agent neue Funktionen in eine bestehende Lösung ein und erbt dabei quasi den Technologie-Stack. Bei einem Start auf der grünen Wiese hängt es an den Anweisungen, ob Struktur oder Technologieauswahl bewusst getroffen wurden ("Schreibe mir ein Programm in Python") oder ob die KI das "mitgevibed" hat. Wenn mich der Quelltext nicht genauer interessiert, warum sollte es die zugrundeliegende Architektur tun? Von außen beobachtbare Schwächen der Lösung, wie eine schlechte Performance oder fehlende Portierbarkeit, tun es sehr wohl.

Was ist Architekturarbeit?

Grady Booch führt in seinem berühmten Artikel "The Accidental Architecture" [2] aus, dass Architekturentscheidungen in jedem hinreichend interessanten Softwaresystem vorhanden sind. Mitunter seien sie aber nicht bewusst getroffen, sondern eher implizit passiert ("verunfallte" oder zufällige Architektur). Vibe Coding wäre ein klassischer Fall davon. Aber wenn schon KI – was wäre, wenn wir Architekturarbeit durch entsprechende Agenten explizit machen? Beispielsweise Nachvollziehbarkeit einfordern und uns eine grobe Lösungsidee als Artefakt miterzeugen lassen?

AI-Agenten und Softwarearchitektur

Agentic AI-Lösungen im Bereich Programmierung fahren ein ganzes Arsenal spezialisierter Agenten auf, bei Ruflo [5] beispielsweise sind es über 100 für Coding, Code-Reviews, Testing, Security-Audits, Dokumentation, DevOps etc. – welche für Architektur sind auch dabei.
Anstatt eines einzelnen, machtvollen Agenten ist es bei Softwarearchitektur also naheliegend, sich spezialisierte AI-Agenten vorzustellen für unterschiedliche Bereiche. Sie sind dann optimiert auf konkrete Ziele wie beispielsweise:

• eine Technologieentscheidung treffen
• die Einhaltung bestimmter Rahmenbedingungen prüfen
• die Erreichung von Qualitätszielen sicherstellen
• ein informelles Überblicksbild anfertigen
• Architektur-relevante Anforderungen erheben
• das System (oder einen Teil davon) strukturieren
• …

Das Begriffsbild in Abbildung 1 gibt uns eine gute Idee bezüglich möglicher Bereiche (Entwurf, Dokumentation, Bewertung, …). Spannend ist dabei, wie stark spezialisiert ein einzelner Agent ist und was sein Startpunkt wäre. Gibt es zum Beispiel unterschiedliche Agenten für die verschiedenen Qualitätsmerkmale, etwa spezialisiert auf Safety, Wartbarkeit, Portierbarkeit, …?  Oder kann ein Agent ein Überblicksbild für ein bestehendes System aus einer Implementierung ableiten, ein anderer skizziert im Dialog mit einem User einen ersten Wurf? Auf welche Weise agieren die Agenten untereinander und mit dem Menschen (oder dem Team)?
Aber bevor wir uns verzetteln: Fokussieren wir auf einen einzelnen AI-Agenten und schauen, wie er sich schlägt. Qualitätsziele eignen sich dabei besonders gut als Einstieg:

• Sie stehen früh im Entstehungsprozess einer Software, zum Beispiel im Rahmen einer Architekturvision.
• Sie sind als Architektur-relevante Anforderungen Stakeholder-lastig und erfordern den Dialog.
• Sie setzen für die Erarbeitung keine komplexen Werkzeuge voraus.

Ein erster Agent: Qualitätsziele im Dialog erarbeiten

Als Ziel setzen wir unserem Agenten die Aufgabe, einen ersten, fundierten Vorschlag für die Qualitätsziele für ein konkretes Softwaresystem zu erarbeiten. Dies soll er im Dialog mit einem Ansprechpartner tun, welcher die Anforderungen des Systems kennt. Eine Fachexpertin oder der Product Owner zum Beispiel.
Qualitätsziele sind die wichtigsten Qualitätsmerkmale, die ein Softwaresystem erreichen soll. Die Eigenschaften neigen im Deutschen dazu, auf -heit und -keit zu enden (Sicherheit, Benutzbarkeit, Zuverlässigkeit, …). In Abbildung 1 sind oben links die neun Oberbegriffe der passenden ISO-Norm für Softwarequalität aufgezählt. In Architekturüberblicken ist es üblich, die Top 3 bis maximal Top 5 dieser Ziele zu nennen, zu beschreiben und zu motivieren: Was heißt Benutzbarkeit für uns? Warum ist es wichtig? …
Der Agent soll dabei so vorgehen:

1. die Art des Softwaresystems erfragen
2. herausfinden, was das System macht, was seine Aufgabe ist und was es auszeichnet
3. ein Risiko-Brainstorming durchführen
4. einen ersten Ergebnisvorschlag machen und den Ansprechpartner einladen, Verbesserungen vorzunehmen

Wir geben ihm dazu detailliertere Anweisungen und einen Vorrat an Qualitätsmerkmalen inklusive Kurzbeschreibungen und Untermerkmalen mit auf den Weg. Hierzu setzen wir auf das Qualitätsmodell von LASR (Lightweight Approach für Software-Reviews, [6]) mit 14 Merkmalen, das die ISO-Norm aufgreift und um weitere von Stakeholdern oft gewünschte Aspekte ergänzt (z.B. Kosteneffizienz).
Um diesen Agenten, wie in Abb. 2 gezeigt, zu bauen, können wir ein passendes Framework wie LangChain (Python) oder Spring AI (Java, siehe z.B. [7]) benutzen. Für den Einstieg genügt aber ein etwas erweiterter Prompt, den Sie direkt in ein Chat-Interface Ihres Vertrauens wie Le Chat (Mistral), Claude, ChatGPT o.ä. werfen und dort ausprobieren können.
Wir verzichten dabei auf den System-Prompt und geben die Rolle stattdessen am Anfang unserer Anweisungen an ("Role Playing"). Überhaupt bedienen wir uns einiger fortgeschrittenerer Prompt-Engineering-Techniken (vergleiche [3]). Tabelle 1 fasst sie zusammen.

Tabelle 1: Prompt-Engineering-Techniken und ihre Anwendung im Beispiel

Technik	Anwendung im Beispiel
Persona / Role Playing	Du bist Experte für … Klassisches Role Prompting, das Ton und Fachwissen des Modells ausrichtet.
Chain of Thought	Vier explizite Schritte zwingen das Modell zu einer strukturierten Vorgehensweise statt eines einzigen Sprungs zur Antwort.
Knowledge Injection	Vollständige Liste der 14 Qualitätsmerkmale nach LASR direkt mit im Prompt. Das Modell arbeitet so mit einem definierten Vokabular.
Vorgabe der Ausgabe	Das Ergebnis geben wir präzise vor: Tabelle, max. 5 Zeilen, Spalten definiert, Sortierung nach Wichtigkeit.
One-Shot Prompting	Zusätzlich geben wir ein konkretes Beispiel für ein echtes System an, um die Ausgabequalität weiter zu erhöhen.
Checkliste als Quality Guard	Eine Checkliste für Qualitätsziele wirkt als implizites Kriterium zur Selbstbewertung. Das Modell kann seine eigenen Vorschläge daran überprüfen.

Der Prompt in Aktion

Ich lade Sie herzlich ein, die Lösung einfach mal auszuprobieren. Falls Sie dies für ein echtes Softwaresystem aus Ihrem Umfeld tun möchten: In vielen Unternehmen und Organisationen ist der Einsatz von Gen AI heute grundsätzlich geregelt. Natürlich lohnt für sensible Architekturinformationen ein genauer Blick in die Richtlinien, bevor Sie diese von ChatGPT & Co verarbeiten lassen …
Alternativ können Sie den Prompt auch mit einem öffentlichen Chat-Interface für ein imaginäres System testen. Oder für ein bekanntes, was Sie selbst nutzen und wo Sie sich in die Rolle einer Produktverantwortlichen hineinversetzen können.

Je nach Hardware-Ausstattung können Sie den Prompt mit etwas Aufwand (z.B. Ollama, LM Studio o.ä. installieren) auch lokal auf Ihrem Rechner oder einem Server in Ihrem Netzwerk ausprobieren. Tabelle 2 zeigt den Start des Dialogs in einem lokalen Ollama [9] mit dem Modell Gemma 4 von Google. (Variante 26b, siehe [10]).

Tabelle 2: Anfang eines Beispiel-Dialoges in einem Chat-Interface (lokal, Gemma 4, 26b)

Dialog
LLM (gemma4:26b): Hallo! Ich bin bereit. Ich werde Sie als Experte dabei unterstützen, die wichtigsten Qualitätsziele für Ihr System präzise zu definieren, damit Ihre Softwarearchitektur auf einem soliden Fundament steht. Wir gehen methodisch Schritt für Schritt vor. Schritt 1: Systemtyp Um den Kontext der Anforderungen zu verstehen: Um welche Art von System handelt es sich? (Ist es beispielsweise ein Web-System, ein Embedded-System, eine Mobile App, ein Informationssystem, ein Desktop-Programm etc.?)
StefanZ (Benutzer): Es ist ein eingebettetes System. Die Software steuert Flipper-Automaten und dient als Basis für unsere zukünftigen Geräte.
LLM (gemma4:26b): Verstanden, ein Embedded-System zur Steuerung von Flipper-Automaten. Das ist ein spannendes Feld, da hier Hardware und Software sehr eng verzahnt sind und die Interaktion mit der physischen Welt (Mechanik, Sensoren, Aktoren) im Vordergrund steht. Schritt 2: Systemfunktionen und Stakeholder Um die Anforderungen besser einordnen zu können: Was genau sind die Hauptaufgaben des Systems? Wer sind die primären Nutzergruppen (z. B. Spieler, Techniker, Besitzer) und gibt es wichtige Fremdsysteme (z. B. Münzprüfer, Netzwerk für Highscores, Wartungs-Dashboards), mit denen der Automat interagieren muss?
StefanZ (Benutzer): Die Software steuert die gesamte Mechanik, den Sound, die Beleuchtung, das Gameplay. Nutzer der Software sind (indirekt) die Spieler und auch Technikpersonal, welches die Geräte in der Spielhalle wartet. Also Fehler suchen beispielsweise.
…

Tabelle 3 zeigt ein Beispielergebnis für die Top-Qualitätsziele für unsere imaginäre Flipper-Software, erzeugt lokal in Ollama mit Google Gemma 4 (26b Parameter). Es war der erste Vorschlag des LLMs ohne Nachbessern im Dialog.

Tabelle 3: Beispiel-Ergebnis für eine imaginäre Flipper-Software, erster Vorschlag mit Gemma 4 (26b Parameter) als LLM

#	Ziel	Qualitätsmerkmal	Beschreibung
1	Verlässliches und korrektes Spielerlebnis	Zuverlässigkeit	Das Gameplay verläuft ohne Unterbrechungen und die Spielstände sowie der Ballstatus sind jederzeit korrekt und konsistent.
2	Schnelle Fehlerdiagnose und geringe Ausfallzeiten	Betreibbarkeit	Systemzustände und auftretende Fehler sind für das Wartungspersonal unmittelbar erkennbar, sodass die Ausfallzeiten der Automaten minimal bleiben.
3	Personalsicherheit im Wartungsbetrieb	Safety	Die Software unterstützt die physische Sicherheit des Technikpersonals, indem sie Gefahren durch elektrische oder mechanische Einwirkungen minimiert.
4	Effiziente Anpassung an neue Hardware	Wartbarkeit	Die Softwarearchitektur erlaubt die einfache Erweiterung und Anpassung an neue mechanische oder elektrische Komponenten zukünftiger Flipper-Modelle.

Ich finde es beeindruckend, wie hoch die Qualität der Ergebnistabelle regelmäßig bereits im ersten Wurf ist. Der Prompt macht ein LLM zu einem wertvollen Gesprächspartner für die Erarbeitung der Qualitätsziele im Dialog. Wichtig dabei: Der Mensch entscheidet. Wenn Sie mit dem Prompt einen Vorschlag erarbeiten, lassen Sie sich von den maßgeblichen Stakeholdern eine Rückmeldung dazu geben. Nicht umsonst schlägt LASR einen Gruppenprozess zur Erarbeitung des Bewertungsmaßstabes vor ("Top 5 Challenger“, siehe [12]).

Ist das schon ein AI-Agent?

Es lässt sich tatsächlich darüber streiten, ob das Gezeigte bereits ein AI-Agent ist. Eine allgemein akzeptierte, messerscharfe Definition für den Begriff gibt es nicht. Mein Kollege Alexander Kaserbacher, mit dem ich die Lösung entwickelt habe, bezeichnete es als "Glorious Prompt". Es trägt agentische Züge:

• Qualitätsziele identifizieren und beschreiben als Ziel
• vierstufiges Vorgehen als Plan
• Rollen-Persona (Experte für Qualitätsanforderungen)
• Selbst-Prüfung via Checkliste
• Abbruch-/Fertigstellungskriterium (zumindest implizit: fertige Tabelle, welche die Checkliste erfüllt)

Auf der anderen Seite fehlen einige wichtige Aspekte von AI-Agenten, oder sind zumindest schwach ausgeprägt:

• kein Werkzeugeinsatz (Tools)
• Wenig Autonomie, das System wartet nach jeder Antwort auf den Menschen. Für den konkreten Anwendungsfall ist das aber eher Feature als Bug.  
• Umgebung auf Text-Dialog beschränkt. Das System greift nicht auf Dateien, APIs, frühere Gespräche, Dokumente oder andere externe Quellen zu.
• keine Erinnerung (Memory) über das Kurzzeitgedächtnis hinaus

Bestimmte Aspekte ließen sich natürlich integrieren und so aus dem Prompt im Chat-Interface noch etwas mehr machen. Unser Ansatz vereint aktuell Aspekte, die in agentischen Systemen typischerweise auf mehrere Schritte oder Agenten verteilt wären. Beim Prompt Chaining (vgl. [3]) erfolgen mehrere LLM-Calls hintereinander, jeder mit einer Teilaufgabe. Das würde den Ablauf strikter einhalten, die Lösung besser testbar machen und einzelne Schritte gezielt aufwerten können. Das Risiko-Brainstorming ist in unserem Prompt beispielsweise wenig geführt.

Anthropic definiert Workflows als Systeme, in denen LLMs und Tools entlang vordefinierter Pfade orchestriert werden, und Agenten als Systeme, bei denen LLMs ihre eigenen Prozesse und Tool-Nutzung dynamisch steuern (siehe [13]). Nach dieser Unterscheidung wäre unser Dialog eher ein Workflow in Prompt-Form. Der Pfad ist durch die vier Schritte vordefiniert, das Modell folgt ihm. Ein echter Agent würde z.B. selbst entscheiden, ob er erst Tools aufruft, welche das wären und wann er genug Informationen hat.

Nächste Schritte

Unabhängig von formalen Definitionen von AI-Agenten sind im Zusammenhang mit unserem Qualitätsziel-Dialog folgende Dinge aus meiner Sicht spannend und mögliche Verbesserungen.

• Ein Zugriff auf bereits vorhandene Informationen zum System würde es dem Dialogpartner ggf. ersparen, Details zu erfassen. Vielleicht gibt es bereits ein Mission Statement, Rahmenbedingungen oder eine Kontextabgrenzung mit Nutzergruppen und Fremdsystemen in irgendeiner Form. Dies wäre ein Beispiel für Umweltwahrnehmung und Tool-Use (Lesen).
• Eine spezifische UI, in der sich neben Texteingaben per Chat-Interface auf Inhalte Einfluss nehmen ließe, würde den Komfort erhöhen. Insbesondere die Ziele per Drag & Drop o.ä. umpriorisieren zu können, wäre toll. Wenn Sie mit dem Prompt arbeiten, werden Sie das oft tun wollen. Weswegen die Ziele in der Tabelle nummeriert sind. Sonst rate ich eher von Zahlen in den Qualitätszielen ab, da es leicht zu anstrengenden Diskussionen rund um die Rangfolge unter den Stakeholdern führt.
• Ein Wegschreiben der Ergebnistabelle in strukturierter Form bietet wertvollen Input für weitere Arbeit an der Softwarearchitektur. Die Ziele können in Architekturentscheidungen aufgegriffen oder in Qualitätsszenarien verfeinert werden. Ein Beispiel für Tool-Use (Schreiben) und die Integration mit nachgelagerten Agenten.

Bei der Umsetzung verlassen wir unseren Prompt-Ansatz und bauen tatsächlich ein agentisches System. Unser Qualitätsziel-Dialog war nur ein spannender, aber für sich genommen bereits nützlicher erster Schritt.

Fazit

Ob AI-Agent oder "Glorious Prompt" ist letztlich nicht entscheidend. Wichtig ist, dass Architekturarbeit in Zeiten von Vibe Coding explizit bleibt. Unser Qualitätsziel-Beispiel zeigt: Dafür braucht es kein Multi-Agenten-Framework, sondern vor allem einen methodischen Rahmen, den Sie und Ihre Entwicklungsteams setzen.

Autor