KI als Team, nicht als Werkzeug

Marcel Raddatz · 2026

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

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

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.

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

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

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

.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

Idee & UI-Exploration

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

→ stammbaum-tree-spec.html

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

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

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

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

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

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)

Fazit

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