Der Papagei und sein Schiedsrichter

tangled wires and old computer hardware, line-art sketch style, black and white

01 / 18

Das Monster

Das TINA-Frontend, Stand 2026

Aurelia + proprietäres Arvato Volto/VoltoSPA (2018/19)
Bootstrap 3, jQuery, TypeScript 3.9, Webpack 4, moment.js, select2
12 Fachbereiche, 40 Views – Aufträge, Stammdaten, Netzsegmente, Kommunikationsmatrix …
Testabdeckung: ~1 %

02 / 18

Spoiler: Das Ergebnis

Tage bis Code-komplett

Alle 12 Bereiche portiert

Unit-Tests

~90 % Line-Coverage (Gate: 80 %)

Playwright-e2e-Tests

ESLint strict mit 0 Findings

Testabdeckung

Von Legacy zu neu

Technologie-Stack

Angular 21 (standalone, Signals, zoneless, strict TS) + PrimeNG + Tailwind

Fachlich reviewt – seit 2 Wochen auf TINA-DEV parallel zur Legacy-UI im Einsatz.

03 / 18

Glück? Magie? Hype?

Nein: ein Verfahren.

Das Playbook in 7 Phasen – von Fundament bis Spitze, jede Phase baut auf der vorherigen auf:

7 · Review & Parallelbetrieb

6 · Zwischenbericht

5 · Vertikale Phasen

4 · Harness bauen

3 · Design-Gate

2 · Grill → Spec

1 · Inventur

archaeologist carefully brushing dust off ancient artifact, line-art sketch style, black and white

04 / 18

Phase 0 · Inventur

„Code, den nie jemand aufgerufen hat" – Der Agent als Legacy-Archäologe

Vollständiges Legacy-Inventar

12 Bereiche, 40 Views, LOC und Komplexität je Bereich

Fund: Toter Code

auftragAnlegenProduktinstanzErweitern – im Legacy nie aufgerufen → nicht portiert

Fund: Impliziter Backend-Vertrag

Das Backend erwartet sortDirection wörtlich als "Ascending"/"Descending" – fehlt es, gibt es eine NullPointerException

Weiterer toter Code

getAllBetriebstypen in den Betriebstypzuordnungen

Hier glänzt das Brain: echtes Verständnis von fremdem Code.

05 / 18

Phase 1 · Grill → Spec

„Die KI fragt, ich entscheide" – Nicht prüfbare Entscheidungen gehören dem Menschen – und zwar vorne.

Stack

Angular (Team ist Java-lastig mit Angular-Erfahrung), PrimeNG + Tailwind

Scope

Re-Platform + Polish, kein kompletter UX-Redesign; Big-Bang, aber modulweise

Tests

Vitest + Playwright mock-first, 80 %-Coverage-Gate, ESLint strict

Spielregeln

Bei Unklarheit immer fragen, testbare Zwischenstände melden, keine git-Commits durch die KI

Ergebnis

IMPLEMENTATION-PLAN.md mit Fortschritts-Checkliste im Repo – geschrieben so, dass auch eine kleinere Modell-Instanz ihn abarbeiten kann.

06 / 18

Phase 2 · Design-Gate

Erst entscheiden, dann portieren.

Zwei komplett unterschiedliche, klickbare HTML-Mockups vor der ersten View:

Später dazu: Stil „TINA Klassik" in der Arvato-Farbwelt als neuer Default.

Heute: 3 Design-Stile zur Laufzeit umschaltbar.

„Kontrollraum"

Dunkel, Amber-Akzente

„Editorial" ✓

Warmes Papier, Serifen – Editorial gewann

07 / 18

Phase 3 · Harness bauen

„Erst das Fahrwerk, dann der Motor" – Bevor das erste Feature entsteht:

Vitest Coverage-Gate

80 %-Line-Coverage-Gate – der Maven-Build bricht darunter

ESLint strict

angular-eslint + typescript-eslint

Playwright mock-first

Jeder BFF-Aufruf gemockt, unbekannte Aufrufe scheitern laut

Ein Kommando

Pro Prüfebene, das der Agent selbst ausführen kann (mvn verify)

08 / 18

Einschub: Der stochastische Papagei

Zugestanden: Ein LLM rät das nächste Token.

Die Generierung ist stochastisch

Ja – der Papagei rät.

Die Prüfung ist deterministisch

Compiler, Linter, Tests, Build.

Generate-and-Verify

Der Papagei darf raten, solange ein Schiedsrichter jede Antwort prüft.

Warum KI in Informatik so gut funktioniert

Das Ergebnis ist auf vielen Ebenen maschinell prüfbar.

Es ist egal, wie die Antwort entsteht, wenn jede Antwort durch deterministische Prüfungen muss.

In einem Aufsatz über Geschichte gibt es keinen Compiler. In unserem Code gibt es sechs Prüfebenen.

09 / 18

Teil 2/2

Prüf-Pyramide, Grenzen des Verfahrens und das Playbook zum Nachmachen

10 / 18

Die Prüf-Pyramide

Je mehr Ebenen, desto enger der Korridor für den Zufall.

Mensch

Fachliches Review, Parallelbetrieb

Build & Budget

mvnd verify, Bundle-Budget

e2e

81 Playwright-Tests im echten Browser

Unit-Tests

372 Tests, ~90 % Coverage

Linter

ESLint strict, 0 Findings

Basis: Typsystem / Compiler – TypeScript strict

vertical slices of layered architecture blocks, technical blueprint line art, modular structure

11 / 18

Phase 4 · Vertikale Phasen

Bereich für Bereich, jeweils komplett.

Vollständiger Zyklus pro Fachbereich

Mapper → Store (Signals) → Page + Unit-Tests + e2e-Spec

Voller Gate-Lauf nach jedem Schritt

lint + unit + komplettes e2e – kein Schritt ohne vollständige Prüfung

Plan-Checkliste und Memory

Das externe Gedächtnis über Sessions hinweg

Wiederverwendbare Muster entstehen früh

TinaTable, CRUD-Dialoge, CSV-Import – beschleunigen jeden weiteren Bereich

12 / 18

„Grüne Tests, rote Realität"

Auch der Harness kann lügen.

Symptom

Bei Backend-Fehlern sahen Nutzer nur „HTTP 500" statt der echten Meldung

Alle Unit-Specs

grün – und trotzdem falsch

Ursache

Der generierte API-Client fordert alles als Blob an – die Specs flushten aber JSON. Die Fehlermeldung wurde nie geparst.

Zweiter Fund

Die Detail-Ursachen (causes) wurden komplett ignoriert

Gefangen von der nächsten Ebene

e2e-Test im echten Browser beweist den Fix – erst dort wurde das echte Verhalten sichtbar

red warning light on dashboard, minimal line art, technical indicator

13 / 18

„Still rot seit drei Sessions"

Immer den vollen Gate-Lauf – nie nur „meinen" Test.

Backend-Refactoring

Schlanke neue Endpoints für Dropdowns

Veraltete Mocks

Die e2e-Mocks zeigten noch auf die alten Pfade → 5 bestehende Tests rot

Niemand merkte es

Pro Session lief nur der Spec des neuen Features

Gleiche Fehlerklasse

Ein Test erwartete 13 Navigationslinks – real waren es längst 14

parallel railroad tracks converging, line art, technical blueprint style

14 / 18

Phase 5+6 · Inventur, Review, Parallelbetrieb

Und die ehrliche Grenze.

Zwischenberichte

Was ist identisch zur Legacy, was bewusst anders – schriftlich im Repo

Fachliches Gesamt-Review

Durch mich, danach Parallelbetrieb auf TINA-DEV

Keycloak-Endlosschleife

Race zwischen Login-Guard und Code-Austausch – erst beim manuellen Login in der echten Umgebung gefunden

Die Grenze

UX, fachliche Richtigkeit, „Richtige Anforderung?" – dort bleibt der Papagei ein Papagei

Manche Fehler findet nur ein Mensch in der echten Umgebung. Das Verfahren konzentriert nicht-prüfbare Entscheidungen beim Menschen: vorne im Design-Gate, hinten im Review und Parallelbetrieb. Dazwischen läuft alles Automatisierbare.

15 / 18

Harness vs. Brain

Das Brain ist Voraussetzung. Der Harness ist der Hebel.

Das Brain hat geliefert

Toten Legacy-Code erkannt
Die zoneless-Falle verstanden (computed() auf Formularwerten ist nicht reaktiv)
Die Kommunikationsmatrix analysiert: O(R×C×n)-Rebuild pro Klick, ~3 Queries pro Zelle im Backend

Der Harness hat gerettet

Blob-Bug trotz grüner Specs
Still rote Tests nach Refactoring
Vergessener Stand zwischen Sessions

Brain = Motor. Harness = Fahrwerk, Lenkung, Bremsen.

Ein stärkerer Motor ohne Fahrwerk landet nur schneller im Graben.

16 / 18

„Das Brain habt ihr schon"

Leistungsstarke Modelle stecken in eurer Copilot-Lizenz. Was fehlt, ist das Fahrwerk.

Mein Setup	Euer Äquivalent mit Copilot
Copilot mit Opus-5 als Arch-Agent	Copilot Agent Mode
COPILOT.md / Projektregeln	.github/copilot-instructions.md bzw. AGENTS.md
IMPLEMENTATION-PLAN.md mit Checkliste	PLAN.md im Repo, genauso
Memory über Sessions	Plan + Zwischenberichte im Repo
Grill-Skill	„Stell mir eine Frage nach der anderen, mit Empfehlung"
mvn verify / npm run e2e als Feedback-Loop	identisch

17 / 18

Das Playbook

Wiederholbar für die nächste Legacy-UI.

Inventur

Agent analysiert

Grill → Spec

Mensch entscheidet

Design-Gate

Mensch entscheidet

Harness bauen

Agent baut, Mensch prüft

Vertikale Phasen

Agent

Inventur & Zwischenbericht

Agent schreibt, Mensch liest

Review & Parallelbetrieb

Mensch entscheidet

Mensch-Gates vorne und hinten, der Agent in der prüfbaren Mitte.

starting line on a road, forward arrow, minimal line art, clean technical style

18 / 18

Morgen fangt ihr an

Drei Schritte:

Harness zuerst

Build, Lint und Tests mit je einem Kommando, das der Agent selbst ausführen kann