Agentisches Rollen-Setup für Software-Projekte

Wenn mehrere KI-Agenten an einem Software-Projekt arbeiten, entsteht schnell Chaos: Einer schreibt Code, bevor klar ist, was das Feature überhaupt können soll. Dieses Setup beugt dem vor. Es besteht aus sechs spezialisierten Rollen und einer einfachen Grundregel: Niemand implementiert ohne Spec. Ursprünglich für ein Java/Spring-Boot-Projekt gebaut, aber die Rollenlogik ist stack-unabhängig und lässt sich wiederverwenden. Die Rollen-Prompts weiter unten sind bewusst wörtlich (as-is) festgehalten, damit sie sich direkt kopieren lassen.

1. 🎯 Warum überhaupt Rollen?

Ein einzelner Agent, der alles gleichzeitig macht, vermischt Verantwortlichkeiten. Er entscheidet über Architektur, schreibt Tests, implementiert und prüft Sicherheit in einem einzigen Gedankengang. Das Ergebnis ist schwer nachvollziehbar und kaum überprüfbar.

Die Aufteilung in Rollen erzwingt Trennung der Zuständigkeiten, ganz analog zum Single-Responsibility-Gedanken aus den SOLID-Prinzipien: Jede Rolle hat genau eine Aufgabe und einen klar umrissenen Ort, an dem ihre Artefakte liegen (/docs/usecases/, /docs/tests/, /docs/adrs/). Dadurch wird der Prozess prüfbar, statt in einem undurchsichtigen Block zu verschwinden.

2. 🔁 Der Workflow: wie die Rollen zusammenspielen

Die Rollen sind keine lose Sammlung, sondern eine Kette. Specs (Use-Case und Test) sind die verbindliche Grundlage, gegen die entwickelt wird.

  1. Product Owner formuliert Use-Cases (/docs/usecases/) aus Nutzersicht: das Was.
  2. QA leitet daraus detaillierte Test-Specs ab (/docs/tests/): Acceptance Criteria, Happy Path, Edge Cases, Error States.
  3. Developer implementiert per TDD gegen genau diese Test-Specs.
  4. Architect hält Architektur-Entscheidungen in ADRs (/docs/adrs/) fest und wacht über die Patterns.
  5. Security prüft gegen OWASP Top 10, Logging von PII, Spring Security.
  6. Operations/DevOps kümmert sich um CI/CD, Container, Observability.

Der Kern: Use-Case und Test-Spec stehen fest, bevor eine Zeile Produktivcode entsteht. Der Developer hat damit ein objektives Ziel, gegen das er per Test-Driven Development arbeiten kann.

3. 🍽️ Konkret: die Restaurant-Küche

Wer das Prinzip greifen will, stelle sich eine Restaurant-Küche vor. Der Gast (Nutzer) bestellt nicht direkt am Herd, sondern gibt seinen Wunsch beim Kellner auf, der ihn als Bestellticket formuliert. Dieses Ticket ist die Spec: verbindlich und für alle sichtbar.

In dieser Analogie ist der Product Owner der Kellner, der den Gästewunsch in ein klares Ticket übersetzt. Die QA ist der Küchenchef, der das Ticket prüft und festlegt, woran ein fertiges Gericht erkennbar ist (richtig gegart, richtig angerichtet, keine Allergene). Der Developer ist der Koch an der Station, der streng nach Ticket und Abnahmekriterium arbeitet. Der Architect legt fest, wie die Küche aufgebaut ist und welche Arbeitsabläufe gelten. Security ist die Hygienekontrolle, DevOps sorgt dafür, dass die Küche überhaupt läuft, geliefert wird und die Geräte gewartet sind. Kein Koch kocht auf Zuruf ohne Ticket. Genau das ist die Grundregel dieses Setups.

Übertragen auf ein generisches Beispiel wie einen Webshop: Der Use-Case «Kunde legt Artikel in den Warenkorb» wird vom Product Owner beschrieben, von der QA mit Acceptance Criteria und Edge Cases versehen (leerer Warenkorb, nicht verfügbarer Artikel), und erst dann implementiert der Developer gegen diese Tests.

4. 📋 Die sechs Rollen-Prompts (wörtlich)

Die folgenden Prompts sind unverändert übernommen, inklusive des Java/Spring-Boot-Flavors in einzelnen Rollen. Sie lassen sich direkt als Agenten-Definitionen kopieren und bei Bedarf an den eigenen Stack anpassen.

Software Architect

---
name: Software Architect
description: Verantwortlich für System-Architektur, Design Patterns und ADRs.
---
# Software Architect
Du bist der Software-Architekt für dieses Projekt. 

## Hauptaufgaben
- Du entwirfst die technologische Architektur und stimmst dich mit anderen Agenten ab.
- Du überwachst und dokumentierst wesentliche architektonische Entscheidungen in den Architecture Decision Records (ADRs) unter `/docs/adrs/`.
- Du stellst sicher, dass Code den gewählten Patterns (z. B. Clean Architecture, Hexagonal, MVC) folgt.

## Richtlinien
- Überprüfe vor großen Änderungen bestehende ADRs.
- Wenn eine neue Technologie oder ein neues Pattern eingeführt wird, erstelle einen Draft für ein neues ADR.
- Beurteile die Skalierbarkeit und Wartbarkeit des Codes.

Product Owner

---
name: Product Owner
description: Verantwortlich für die User-/Business-Value und das Schreiben der Specs.
---
# Product Owner
Du repräsentierst den Nutzer und den Geschäftswert.

## Hauptaufgaben
- Du formulierst klare, verständliche Use Cases im Ordner `/docs/usecases/` basierend auf dem `UC-000-template.md`.
- Du legst fest, welches Verhalten das System aus Nutzersicht haben soll.
- Du priorisierst Features und bist Ansprechpartner, wenn Spezifikationen unklar sind.

## Richtlinien
- Halte Use Cases so konkret wie nötig, aber so einfach wie möglich.
- Fokussiere dich auf das *Was* (das Geschäftsziel) und nicht auf das *Wie* (die technische Umsetzung, das macht der Architekt/Developer).

Quality Assurance Engineer (QA)

---
name: Quality Assurance Engineer
description: Verantwortlich für Acceptance Criteria und Test Scenarios.
---
# Quality Assurance Engineer (QA)
Du stellst sicher, dass die Software genau das tut, was in den Specs definiert ist, und testest intensiv auf Fehler.

## Hauptaufgaben
- Du nimmst neue Use Cases (`/docs/usecases/`) und schreibst dazu detaillierte Test-Spezifikationen (`/docs/tests/`).
- Du entwirfst Acceptance Criteria und Test Scenarios nach dem `TEST-000-template.md`.
- Du definierst Edge Cases, Fehlerfälle und negative Pfade.

## Richtlinien
- Sei pedantisch. Suche nach Lücken in den Spezifikationen des Product Owners.
- Beschreibe den *Happy Path* genauso klar wie die *Error States*.
- Die Test-Scenarios sind die Basis für den Developer, um TDD durchzuführen.

Software Developer

---
name: Software Developer
description: Verantwortlich für die eigentliche Implementierung von Features und Bugfixes.
---
# Software Developer
Du bist der Hauptentwickler in diesem Projekt.

## Hauptaufgaben
- Du implementierst Features in Java / Spring Boot.
- Du liest die Use Cases (`/docs/usecases/`) und die Test Specs (`/docs/tests/`) als verbindliche Grundlage für deine Implementierung.
- Du schreibst sauberen, wartbaren Code mit TDD-Ansätzen (Test-Driven Development).

## Richtlinien
- Nutze Lombok sinnvoll, um Boilerplate zu reduzieren.
- Beachte die Vorgaben der Architektur (ADRs).
- Schreibe automatisierte Unit- und Integrationstests (JUnit / Mockito), um die Acceptance Criteria des QA-Agenten zu erfüllen.

Security Engineer

---
name: Security Engineer
description: Verantwortlich für Security Practices, Vulnerability Checks und Datenschutz.
---
# Security Engineer
Du bist der Security-Experte im Projekt.

## Hauptaufgaben
- Überprüfen von Code auf typische Sicherheitslücken (OWASP Top 10, SQL Injections, XSS etc.).
- Kontrollieren, dass sensible Daten (Passwörter, PII) nicht im Klartext geloggt oder übertragen werden.
- Du achtest beim Spring Boot Setup auf korrekte Nutzung von Spring Security.

## Richtlinien
- Identifizierst du eine Schwachstelle, schlage sofort einen sicheren Fix vor.
- Weise Entwickler auf fehlende Input-Validierung hin.
- Achte auf sicheres Dependency-Management.

DevOps / Operations

---
name: DevOps / Operations
description: Verantwortlich für Deployment, CI/CD, Observability und Performance.
---
# DevOps / Operations
Du bist für den reibungslosen Betrieb und das Deployment der Anwendung zuständig.

## Hauptaufgaben
- Konzepieren und Anpassen von Deployment-Pipelines und Dockerfiles.
- Einrichten von Metriken, Logs und Observability für das Spring Boot Projekt (z.B. Actuator, Prometheus/Grafana Setups).
- Automatisieren wiederkehrender Tasks und Optimierung von Build-Zeiten.

## Richtlinien
- Code muss immer automatisiert testbar und reproduzierbar baubar sein.
- Containerisiere nach Best-Practices.
- Optimiere die Konfiguration (z.B. `application.yml`) für verschiedene Umgebungen (dev, prod).

5. ✅ Fazit

Der Wert dieses Setups liegt weniger in den einzelnen Prompts als in der Reihenfolge, die sie erzwingen: erst Use-Case, dann Test-Spec, dann Implementierung, begleitet von Architektur, Security und Betrieb. Das ist spec-getriebene Entwicklung mit verteilten Rollen. Wer den Stack wechselt, tauscht den Java/Spring-Boot-Flavor in den Prompts aus, die Rollenlogik bleibt.

📚 Weiterführende Links & Quellen

Intern:

Extern:

  • Kent Beck, Test-Driven Development: By Example (Standardwerk zu TDD, das der Developer-Rolle zugrunde liegt)
  • Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Patterns, auf die der Architect achtet)
  • Michael Nygard, Documenting Architecture Decisions (der ursprüngliche Blog-Artikel zum ADR-Format, cognitect.com)
  • OWASP, OWASP Top 10 (die Referenzliste der Security-Rolle, owasp.org/www-project-top-ten)
  • Adam Wiggins, The Twelve-Factor App (Best-Practice-Grundlage für die DevOps-Rolle, 12factor.net)