Die Kritiker – Prüfung gegen Regeln und gegen den Bestand

In den beiden vorherigen Beiträgen ging es um Assistenten, die Artefakte erzeugen und überführen. Jetzt um die, die sie prüfen. Das ist die Operation, bei der mir am deutlichsten klar geworden ist, wie sehr Kontext über Brauchbarkeit entscheidet.

Drei Ebenen der Prüfung

Nicht jede Prüfung ist gleich teuer. Ich unterscheide drei Ebenen, und sie unterscheiden sich vor allem darin, was sie an Kontext brauchen:

Ebene 1 und 2 sind fast geschenkt. Ebene 3 ist die, um die es eigentlich geht — und die einzige, die ohne Zugriff auf den vollständigen Bestand grundsätzlich nicht funktioniert. Warum ich Kontext in Stufen einteile, beschreibe ich in einem eigenen Beitrag.

Der praktische Punkt: Prüfen ist teurer als Erstellen. Ein Artefakt zu erzeugen braucht die Vorlage und ein paar Muster. Ein Artefakt gegen den Bestand zu prüfen braucht den Bestand. Wer beim Aufsetzen eines Assistenten-Systems nur das Erstellen kalkuliert, unterschätzt die Betriebskosten deutlich.

Zum Mitnehmen: die Vorlage für einen Prüfbericht

Ein Prüfergebnis darf keine Prosa sein. Prosa liest man einmal, nickt und macht weiter. Befunde arbeitet man ab.

Auch diese Vorlage ist allgemein gehalten — Kategorien, Schweregrade und Sprache lassen sich an das anpassen, was bei euch üblich ist. Was ich nicht weglassen würde, sind die beiden letzten Abschnitte.

# Prüfbericht: <Artefakt>

## Zusammenfassung
- **Geprüfte Ebenen:** Form · Innere Logik · Äußere Konsistenz
- **Befunde:** <n> Blocker · <n> Wichtig · <n> Hinweis

## Befunde

### B-1 · <Form | Logik | Konsistenz | Sprache> · <Blocker | Wichtig | Hinweis>
- **Fundstelle:** <Feld oder Abschnitt>
- **Beobachtung:** <Was konkret auffällt>
- **Vorschlag:** <Konkrete Formulierung oder Maßnahme>
- **Stützt sich auf:** <Regel, Dokument, bestehendes Artefakt>

### B-2 · … · …
- …

## Nicht geprüft
| Prüfung | Grund |
|---------|-------|
| <z. B. Duplikatsprüfung> | <Quelle nicht erreichbar / veraltet / nicht vorhanden> |

## Gesamturteil
<Nur ausfüllen, wenn „Nicht geprüft" leer ist.
Sonst: „Kein Gesamturteil möglich — siehe oben.">

Und das Regelwerk dazu:

## Regeln für diesen Assistenten

**Pflicht**
- Jeder Befund nennt eine konkrete Fundstelle. Allgemeine Bedenken
  sind kein Befund.
- Jeder Befund nennt einen Vorschlag, nicht nur ein Problem.
- Jede Prüfung, die nicht durchgeführt werden konnte, steht unter
  „Nicht geprüft" — mit Grund.

**Verboten**
- Ein Gesamturteil abgeben, solange „Nicht geprüft" nicht leer ist.
- Befunde abschwächen, um höflich zu wirken.
- Fehlende Befunde als Bestätigung darstellen.

Der Abschnitt Nicht geprüft ist der Kern der ganzen Vorlage. Dazu jetzt.

Was beim ersten Entwurf nicht funktioniert hat

Problem 1: Der Assistent war zu höflich.

Sprachmodelle sind zustimmungsfreudig. Der erste Prüfassistent fand fast immer, dass alles im Wesentlichen in Ordnung sei, und formulierte Kritik so vorsichtig, dass sie beim Lesen unterging. Ein Prüfer, der nichts findet, ist wertlos — und schlimmer als wertlos, weil er ein Gefühl von Sicherheit erzeugt.

Geholfen hat die Umstellung von Prosa auf Befunde mit Kategorie und Schweregrad. Ein Feld, das ausgefüllt werden muss, lässt sich schlechter weichspülen als ein Absatz. Dazu die Vorgabe, jeden Befund mit einer konkreten Fundstelle zu versehen — allgemeine Bedenken fallen damit weg.

Problem 2: Fehlende Befunde sahen aus wie ein sauberes Ergebnis.

Das war der gefährlichere Fehler. Wenn der Bestand gerade nicht erreichbar war, prüfte der Assistent eben nur Form und Logik — und meldete: keine Befunde. Für den Nutzer sah das identisch aus zu einer vollständigen Prüfung ohne Beanstandung.

Daraus ist die Regel geworden, die ich für die wichtigste bei Prüfassistenten halte:

Ein Prüfassistent, der nicht sagen kann „das konnte ich nicht prüfen", ist gefährlicher als gar keiner.

Deshalb der Pflichtabschnitt Nicht geprüft und die Regel, dass ein Gesamturteil nur erlaubt ist, wenn dieser Abschnitt leer bleibt. Aus einem stillschweigenden blinden Fleck wird eine sichtbare Einschränkung.

Das ist derselbe Gedanke wie bei Offene Fragen und Annahmen im Erstellungsassistenten. Beide Male geht es darum, dass das System seine eigenen Grenzen ausweist, statt sie zu überspielen.

Problem 3: Sprachprüfung nach den falschen Maßstäben.

Sprachliche Analyse klingt harmlos und ist es nicht. Was allgemein als gute Sprache gilt — kurze Sätze, wenig Fachbegriffe, aktive Formulierung — ist für eine Anforderung im Enterprise-Kontext teilweise falsch. Fachbegriffe sind dort Präzision, keine Barriere. Passivkonstruktionen sind manchmal genau richtig, weil der Handelnde bewusst offenbleibt.

Der Assistent hat anfangs in Richtung allgemeiner Lesbarkeit optimiert und dabei Präzision gekostet. Die Regeln mussten auf das umgestellt werden, was in diesem Kontext richtig ist: Eindeutigkeit vor Verständlichkeit, definierte Begriffe statt Umschreibungen, keine Weichmacher.

Grenzen

Ein Prüfassistent findet Kandidaten, keine Wahrheiten. Ein gemeldetes Duplikat ist ein Hinweis, den ein Mensch bestätigen muss — Ähnlichkeit im Text ist nicht dasselbe wie Gleichheit in der Sache.

Und er prüft gegen den Bestand, wie er dokumentiert ist. Wo Dokumentation und Wirklichkeit auseinanderlaufen, prüft er gegen die Vergangenheit.

Fazit

Prüfen ist die Operation mit dem größten Nutzen und den höchsten Kosten. Der Nutzen entsteht fast vollständig auf Ebene 3 — und die gibt es nicht umsonst.

Die Regel, die ich mitnehme: Ein Assistent muss seine eigenen Grenzen ausweisen können. Alles andere ist Scheinsicherheit, und Scheinsicherheit ist schlechter als keine.

Im nächsten Beitrag geht es um eine Aufgabe, die mit Anforderungen nichts mehr zu tun hat und trotzdem auf derselben Architektur läuft: Fehlersuche in einer verteilten Landschaft.

→ Der Baukasten im Überblick