Der Papagei und sein Schiedsrichter

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

01 / 12

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 / 12

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 / 12

Glück? Magie? Hype?

Nein: ein Verfahren.

Das Playbook in 7 Phasen – der rote Faden dieses Vortrags:

Inventur

Grill → Spec

Design-Gate

Harness bauen

Vertikale Phasen

Inventur & Zwischenbericht

Review & Parallelbetrieb

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

04 / 12

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 / 12

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 / 12

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

line-art car chassis frame on workshop floor, minimal sketch style, black and white

07 / 12

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)

line-art vertical stack or layered architecture diagram, minimal black and white sketch style

08 / 12

Phase 4 · Vertikale Phasen

„Feature für Feature, nicht Schicht für Schicht” – Ende-zu-Ende entwickeln

Slice 1: Auftragsübersicht

Anzeige und grundlegende Verwaltung der bestehenden Aufträge inklusive Such- und Filterfunktionen.

Slice 2: Stammdaten

Erfassung, Bearbeitung und Validierung von Kernstammdaten wie Kunden- oder Produktdetails.

Slice 3: Netzsegmente

Verwaltung der Netzsegmente, einschließlich Definition und Zuweisung von Konfigurationen.

Slice 4: Kommunikationsmatrix

UI zur Definition und Pflege von Kommunikationsflüssen und Verantwortlichkeiten.

agent or developer reviewing code/metrics on a screen, minimal black and white sketch

09 / 12

Phase 5 · Inventur & Zwischenbericht

„Checkpoint: Was haben wir erreicht?” – Regelmäßige Statusprüfung

Fortschritts-Checkliste

Alle 12 Bereiche zu X% portiert, Y Views abgeschlossen

Code-Qualität

Line-Coverage aktuell bei 87%, ESLint-Findings: 0

Test-Abdeckung

Unit-Tests: 340, e2e-Tests: 75, Playwright-Szenarien: 120

Risiken & Blockers

Dokumentierte Abweichungen zur Legacy, offene Fragen an Backend-Team

line-art minimal sketch style black and white: aerial view of two parallel highways or roads running side by side, one slightly elevated or offset from the other, showing the concept of parallel systems running together

10 / 12

Phase 6 · Review & Parallelbetrieb

„Die Legacy läuft noch – wir fahren parallel” – Sicherheitsnetz und Validierung

Fachliche Review

Stakeholder testen neue UI parallel zur Legacy, Feedback wird dokumentiert

Parallelbetrieb

Beide UIs laufen live, Nutzer können umschalten, Fehler werden sofort sichtbar

Abschaltplan

Legacy wird erst abgeschaltet, wenn neue UI 100% stabil läuft und alle Szenarien validiert sind

11 / 12

Phase 7 · Go-Live & Lessons Learned

„Das Playbook funktioniert – wenn man es befolgt”

Was funktioniert hat

Generate-and-Verify Ansatz: Stochastische Generierung + deterministische Prüfung

Vertikale Slices: Jeder Slice ist sofort lauffähig und testbar

Harness first: Feedback-Loop vor dem ersten Feature

Parallelbetrieb: Sicherheitsnetz statt Big-Bang-Risiko

Was wir gelernt haben

Der Agent ist kein Ersatz für Architektur-Entscheidungen

Deterministische Prüfungen sind nicht optional – sie sind das Fundament

Menschen entscheiden, Maschinen führen aus

Dokumentation ist Code – und Code ist Dokumentation

line-art parrot on a perch with a referee whistle and scoreboard, minimal sketch style, black and white

12 / 12

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.