## KI als Team, nicht als Werkzeug

Marcel Raddatz · 2026

Einstieg: „Die meisten nutzen KI als sehr schnelle Schreibkraft. Ich nutze sie als Team von Spezialisten." Kein Agenda-Slide — das Workflow-Diagramm kommt nach der Team-Vorstellung.

## Das Projekt: Familienarchiv

Handgeschriebene Kurrent- und Sütterlin-Briefe, 1899–1950

- Crowd-Transkription durch 60+-Jährige am Laptop
- Jüngere Familienmitglieder lesen's am Handy
- Solo-Entwickler — kein Team zum Review oder Pair-Programming

PM-Takeaway: echte Domäne, echte Nutzer, echte Constraints.

### Stack & Umfang

Backend | Spring Boot 4 · Java 21 · JPA · Flyway · Spring Security
Frontend | SvelteKit 2 / Svelte 5 · TypeScript · Tailwind CSS 4
DB / Storage | PostgreSQL 16 · MinIO (S3-kompatibel)
OCR | Python · FastAPI · lernende ML-Modelle für Kurrent & Sütterlin
i18n | Paraglide.js — de / en / es
Umfang | 40+ UI/UX-Specs · 360+ Gitea-Issues · 7 Personas

Dev-Takeaway: kein Toy-Projekt — voller Stack, Backend und Frontend.

## Das Problem mit „Einfach die KI fragen"

Was man tut | Was schiefläuft
--- | ---
Vage Idee → Code anfordern | Output passt nicht zu dem, was man wollte
Review in derselben Session | Befangenheit: genehmigt sich selbst
Die KI einfach fragen ob's gut ist | Kein echter Widerspruch
Auf Gesprächskontext vertrauen | Nächste Session startet blank

Das ist ein Workflow-Problem, kein Prompt-Problem.

Dieser Slide schafft das Warum für alles was folgt. Das Publikum erkennt sich in mindestens einer Zeile wieder.

## Wo stehst du?

1 — Autocomplete | Tab-Completion, eine Zeile vorschlagen
2 — Chat / Pair | Fragen stellen, Code kopieren, selbst einfügen
3 — Agentic Edit | KI editiert Dateien direkt — Cursor, Claude Code
4 — Spec → Code | Mensch schreibt Spec, KI implementiert
5 — Idea → Spec → Code | KI hilft beim Spec-Schreiben — Mensch behält jedes Gate
6 — Fully Autonomous | KI plant, spezifiziert, implementiert, testet — kein Mensch

Kurz im Publikum fragen: wer nutzt Autocomplete? Wer Chat? Wer Agentic? Pointe: Stufe 6 klingt verlockend — aber ohne Gates verliert man Kontrolle und Kontext. Stufe 5 ist der Sweet Spot: KI als Denkpartner, Mensch als Entscheider.

## Der Workflow im Überblick

    Vage Idee
      │
      ▼
    UI-Exploration ──▶ Spec (Elicit) ──▶ Gitea-Issue
                                              │
                                              ▼
                                   Persona-Review ──▶ discuss(Persona) ─┐
                                   (6 Spezialisten)                      │
                                          ▲                              │
                                          └──────────────────────────────┘
                                              │
                                              ▼
                                   Feature-Branch
                                        │
                                  TDD: Red → Green → Refactor → Commit
                                        │
                                        ▼
                                   Pull Request ──▶ Persona-PR-Review ──▶ Merge

Roter Faden: wir verfolgen Issue #358 (Stammbaum) durch jeden Schritt. Jeder folgende Abschnitt zoomt in einen Schritt hinein.

## Das Team

Name | Rolle | Kernprinzip
--- | --- | ---
Elicit | Requirements Engineer | Schreibt nie Code
Markus Keller | Architekt | Boring technology wins
Felix Brandt | Senior Developer | Test first. Immer.
Leonie Voss | UX Design Lead | Hardest constraint first
Sara Holt | QA Engineer | A passing test that was never failing is a lie
Nora „NullX" Steiner | Security Engineer | Jeder neue Endpoint braucht `@RequirePermission`
Tobias „tobi" Wendt | DevOps | Komplexität ist eine Liability

Markdown-Dateien in .claude/personas/ — jede mit echtem Namen und Biografie. Überleitung: jetzt zoomen wir in jede Persona hinein.
.claude/personas/developer.md

## Aufbau einer Persona

## Your Identity
## Readable & Clean Code
## Reliable Code
## Modern Code
## Secure Code ◀
## Testable Code
## How You Work
## Relationships
## Your Tone
## Secure Code
### General — projektunabhängig

Secure code treats all external input as hostile. Authentication and authorization are enforced via framework annotations, not scattered if-statements. Error messages reveal nothing about the implementation.

### per Stack — projektspezifisch (Frontend · Java · Python)
✓ DO
Java: `@RequirePermission` on every write endpoint
Python: SSRF host whitelist before any outbound request
✗ DON'T
Java: string concat in JPQL queries
Svelte: `fetch('/api/…')` inside `onMount`
Alle Personas teilen dieselbe Abschnittsstruktur — aber jede schreibt sie aus ihrer eigenen Perspektive. Dieser Abschnitt ist Felix' Kernphilosophie: TDD ist kein Tool, es ist die einzige Arbeitsweise. "Never write implementation code before a failing test exists" — das ist sein Hard Limit.

## Idee & UI-Exploration

1. Vage Anforderung: „Wir brauchen einen Stammbaum"
2. UI-Persona bitten, 4 Specs mit unterschiedlichem Fokus zu generieren
3. Einen Spec auswählen — Elemente aus anderen übernehmen
4. Finales vollständiges Spec schreiben lassen
5. Committen und am Issue verlinken

→ stammbaum-tree-spec.html

stammbaum-tree-spec.html im Browser zeigen. Der Trick mit den 4 Varianten: man merkt erst beim Vergleichen was man eigentlich will. Scope-Entscheidungen auf Pixel-Ebene sind billiger als im Issue.

## Spec mit Elicit → Gitea-Issue

Warum Gitea, nicht eine Datei?

- LLM-Gespräche sind flüchtig — Issues sind dauerhaft
- Issues sind verlinkbar: jeder Commit referenziert sie
- Review-Kommentare, Spec und Entscheidungen leben im selben Thread
- Kein Risiko einer veralteten Spec-Datei im Repo

Das ist die architektonische Kernidee des ganzen Talks.

### Aufbau eines Spec-Issues

- Problem statement — was fehlt und warum es wichtig ist
- User Journey — Schritt für Schritt in Prosa
- E2E-Szenarien (Given/When/Then) → werden zu Red-Tests
- Requirements — funktional + NFR
- Out of scope — explizite Ausschlüsse

→ Issue #358 — Stammbaum

Echtes Issue #358 zeigen — annotiert. PM: das ist der Vertrag vor Baubeginn. Dev: das Szenario IST der erste fehlschlagende Test.

## Persona Issue Review

Vor dem ersten Code: die Spec reviewen lassen

- Jede Persona liest das Issue für sich — kein Austausch untereinander
- Kommentare werden direkt als Gitea-Kommentare gepostet
- Nora: Auth spezifiziert? · Sara: testbar? · Leonie: Mobile? · Markus: Domain-Grenzen?

→ Issue #358 — Kommentar

review-issue-Skill schickt einen Agenten pro Persona. „Hier zu finden kostet null. Nach dem PR-Öffnen kostet es einen Tag." Den Kommentar zeigen der den größten Impact hatte.

## Implementierung: Red/Green/Refactor

- Die Szenarien aus dem Issue werden direkt zu Unit-Tests
- Failing Unit-Test → minimaler Code → grün → Refactor → Commit
- Immer Feature-Branch · ein logischer Change pro Commit

deliver-issue-Skill koordiniert den gesamten Zyklus. PM: die Akzeptanzkriterien aus dem Issue sind die Definition of Done.

### Red/Green im git log

    // Erst der Test — schlägt fehl (RED)
    @Test
    void getFamilyNetwork_excludesEdgesWithNonFamilyEndpoints() {
        var result = service.getFamilyNetwork(personId);
        assertThat(result.edges())
            .noneMatch(e -> isNonFamilyPerson(e.targetId()));
    }

    32622b9b test(stammbaum): getFamilyNetwork excludes edges ...  ← RED
    656c93ca fix(stammbaum): exclude non-family edges in network   ← GREEN

Das Log ist der Beweis, dass der Red-Schritt stattgefunden hat. Test und Implementierung im selben atomaren Commit.

## PR Review Loop

`review-pr`-Skill liest den Diff — jede Persona postet Kommentare zur PR

- Felix: Projektstil, Dead Code?
- Nora: `@RequirePermission` auf jedem neuen Endpoint?
- Sara: fehlende Randfallstests?
- Leonie: stimmt der Output mit der Spec überein?

Kommentare adressieren → pushen → Review wiederholen → Merge

→ PR #360 — feat(stammbaum)

Einen PR-Kommentar zeigen der den Merge blockiert hat. Merge erst wenn alle Stimmen zufrieden sind.

## Fazit

1. Separation of Concerns gilt auch für KI-Rollen — eine Persona die alles macht, reviewed sich selbst
2. Das LLM vergisst. Das Issue nicht. — Spec, Entscheidungen und Review-Kommentare überleben jeden Context Reset

Ehrliches Caveat: Aufwand am Anfang. Der Ertrag ist kumulativ.