maierzone · Der Papagei und sein Schiedsrichter – Teil 2/2
Gamma-Deck

Der Papagei und sein Schiedsrichter – Teil 2/2

Fortsetzung: die Prüf-Pyramide, gefundene Fallstricke und das Playbook zum Nachmachen

Agentic Engineering aus der Praxis · Software-Entwickler 2026-09-13 10 Karten Original in Gamma
01 / 10

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
02 / 10

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

03 / 10

„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
04 / 10

„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
05 / 10

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.

06 / 10

Harness vs. Brain

Das Brain ist Voraussetzung. Der Harness ist der Hebel.

🧠 Das Brain — Motor

Leistungsmetriken

Code Analysis

Toten Legacy-Code erkannt

Pattern Recognition

zoneless-Falle & computed()-Reaktivität identifiziert

Architecture Understanding

O(R×C×n)-Rebuild pro Klick analysiert

🛡️ Der Harness — Fahrwerk

Kontroll- & Sicherheitsmetriken

Gate Enforcement

Blob-Bug trotz grüner Specs abgefangen

Test Coverage

Still rote Tests nach Refactoring aufgedeckt

Feedback Loop

Vergessener Stand zwischen Sessions wiederhergestellt

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

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

07 / 10

„Das Brain habt ihr schon”

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

Mein SetupEuer Äquivalent mit Copilot
Copilot mit Opus-5 als Arch-AgentCopilot Agent Mode
COPILOT.md / Projektregeln.github/copilot-instructions.md bzw. AGENTS.md
IMPLEMENTATION-PLAN.md mit ChecklistePLAN.md im Repo, genauso
Memory über SessionsPlan + Zwischenberichte im Repo
Grill-Skill„Stell mir eine Frage nach der anderen, mit Empfehlung”
mvn verify / npm run e2e als Feedback-Loopidentisch
08 / 10

Der Coding Agent Harness in der Praxis

Coding Agent Harness technical infographic, tree-like network structure with metrics and principles: Data Provenance, Secure Coding Policy, Channel Power, Constraint Bias, Double Growth, Effective Audit, Copy Biography, Test Validity, Audit Inspection Chain, Policy Enforcement, Quality Gates

Dies ist die konkrete Umsetzung des Harness, der alle besprochenen Prüf-Loops, Metriken und Gates integriert.

09 / 10

Das Playbook

Wiederholbar für die nächste Legacy-UI. Mensch-Gates vorne und hinten — der Agent in der prüfbaren Mitte.

checkmark circle green

Inventur

Agent analysiert

blue decision diamond human

Grill → Spec

Mensch entscheidet

blue gate shield review

Design-Gate

Mensch entscheidet

checkmark wrench build

Harness bauen

Agent baut, Mensch prüft

checkmark layers vertical slices

Vertikale Phasen

Agent

checkmark report document

Inventur & Zwischenbericht

Agent schreibt, Mensch liest

blue parallel review toggle

Review & Parallelbetrieb

Mensch entscheidet

🤖 Agent-driven

Schritte 1, 4, 5, 6 — automatisiert, auditierbar, prüfbar

👤 Human Decision

Schritte 2, 3, 7 — strategische Gates, Mensch behält die Kontrolle

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

Morgen fangt ihr an

Drei Schritte:

Harness zuerst

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

Grill → Spec → Plan-Datei

Mit Checkliste im Repo

Ein kleiner vertikaler Schnitt mit vollem Gate

Erst dann skalieren

Fragen?