In einer spec-getriebenen Welt hat jede Änderung am laufenden System einen Grund. Entweder macht das System etwas, was es nicht tun sollte, oder wir wollen, dass es etwas Neues tut. AI Unified Process bildet das mit zwei Arbeitstypen ab, die neben dem eigentlichen Use Case Flow stehen: Bug und Enhancement.

Auf den ersten Blick scheint der Unterschied klar. Ein Bug ist ein Defekt, ein Enhancement ist neues Verhalten. Sobald man aber mit echten Teams arbeitet, wird die Grenze unscharf. Was, wenn der Code zur Spec passt, die Spec selbst aber falsch ist? Ist das immer noch ein Bug?

Die kurze Antwort lautet ja. Und wie man damit umgeht, sagt viel über die Gesundheit des Spezifikationsprozesses aus.

Die drei Arten von Bugs

Ein Bug ist in AIUP alles, wo das laufende System nicht den Wert liefert, den der Stakeholder erwartet. Die Ursache kann an drei verschiedenen Stellen sitzen:

  1. Code Bug. Die Spezifikation ist korrekt, der Code passt nicht dazu.
  2. Spec Bug. Der Code passt zur Spec, aber die Spec selbst ist falsch oder unvollständig.
  3. Test Bug. Der Test kodiert die falsche Erwartung, dadurch ist ein echter Defekt durchgerutscht.

Alle drei sind Bugs. Sie teilen dieselbe Absicht: wir korrigieren einen Fehler, wir ändern nicht die Richtung. Was sich unterscheidet, ist der Lösungsweg.

Einen Code Bug beheben

Das ist der Fall, der am vertrautesten wirkt, und der, den die meisten Teams falsch angehen.

Der naive Ablauf ist: reproduzieren, fehlschlagenden Test schreiben, Code reparieren, fertig. Der Use Case bleibt unangetastet, der Test wird grün, das Ticket geschlossen. Für ein Einzelprojekt funktioniert das. In AIUP greift es zu kurz.

In AIUP wird Code durch den Harness geformt. Skills, MCP Server und Guidelines machen aus einem Use Case lauffähigen Code. Wenn ein Code Bug auftaucht, ist die Frage nicht nur „wie patche ich diese Methode“, sondern „warum hat der Harness überhaupt fehlerhaften Code produziert?“

Der Ablauf ist:

  1. Das Problem reproduzieren und einen fehlschlagenden Test schreiben.
  2. Den Defekt bis zu seiner Ursache im Harness zurückverfolgen:
    • Hat ein Skill das falsche Muster erzeugt? Zum Beispiel ein Vaadin View Skill, der vergisst, einen Listener wieder abzuhängen.
    • Hat ein MCP Server der KI falschen oder fehlenden Kontext geliefert? Zum Beispiel ein jOOQ MCP, der eine Spalte nicht zurückgegeben hat, die die KI dann erraten musste.
    • Hat eine Guideline das fehlerhafte Muster zugelassen oder sogar gefördert? Zum Beispiel eine Namensregel, die die Absicht einer Methode verschleiert.
  3. Zuerst den Harness reparieren. Skill aktualisieren, MCP Integration fixen, Guideline schärfen.
  4. Dann den Code so anpassen, dass der Test grün wird.
  5. Die Test Suite erneut laufen lassen. Wenn der Defekt systemisch war, könnten andere Tests jetzt fehlschlagen oder anderer Code muss neu generiert werden.

Das ist der Punkt, der AIUP von „AI assisted Coding“ abgrenzt. Ein Code Bug ist selten nur ein Code Bug. Er ist ein Signal, dass die ausführbare Architektur eine Lücke hat. Wer nur das Symptom flickt, lässt die Lücke offen, und das nächste KI generierte Modul wird denselben Defekt reproduzieren.

Es gibt Ausnahmen. Ein reiner Tippfehler, ein Copy Paste Fehler oder ein einmaliger Fehler, den keine Harness Änderung hätte verhindern können, bleibt auf Code Ebene. Aber die Standardfrage muss lauten: was im Harness hat das zugelassen?

Einen Spec Bug beheben

Hier verheddern sich viele Teams. Der Ablauf ist:

  1. Das unerwünschte Verhalten reproduzieren und Soll gegen Ist festhalten.
  2. Den Bug auf den Use Case zurückführen und identifizieren, welcher Teil der Spec falsch ist. Das kann eine Vorbedingung sein, ein Schritt im Hauptablauf, ein alternativer Ablauf, eine Geschäftsregel oder ein Akzeptanzkriterium.
  3. Zuerst die Use Case Spezifikation aktualisieren. Das ist die eigentliche Korrektur.
  4. Den fehlschlagenden Test aktualisieren oder neu schreiben, sodass er die korrigierte Spec abbildet.
  5. Den Code so anpassen, dass der neue Test grün wird und die anderen Use Case Tests immer noch laufen.
  6. Den Bug mit Links zur Spec Änderung, zum Test und zum Commit schliessen.

Die Spec ändert sich, aber es bleibt ein Bug. Wir fügen keinen neuen Wert hinzu, wir korrigieren eine Beschreibung, die von Anfang an falsch war.

Einen Test Bug beheben

Ein Test Bug ist der gefährlichste der drei, weil er andere Defekte verdeckt. Die Korrektur besteht darin, den Test so anzupassen, dass er zur Spezifikation passt, und dann zu schauen, was bricht. Oft fördert ein Test Bug einen darunterliegenden Code Bug oder Spec Bug zutage.

Was ein Enhancement wirklich ist

Ein Enhancement ist eine bewusste Änderung bestehenden Verhaltens. Die alte Spezifikation war richtig für die alte Absicht. Jetzt wollen wir eine neue Absicht.

Typische Beispiele: ein Feld in einem Formular hinzufügen, eine Validierungsregel von optional auf zwingend ändern, eine Berechnung anpassen, weil die Fachseite eine neue Rundungsregel beschlossen hat.

Der Ablauf ist geradlinig:

  1. Den Use Case identifizieren, der das Verhalten besitzt.
  2. Die Use Case Spezifikation an die neue Absicht anpassen.
  3. Tests aktualisieren oder ergänzen, die zur neuen Spec passen.
  4. Die Änderung umsetzen.
  5. Sicherstellen, dass alle verwandten Use Case Tests grün sind.

Wenn die Änderung gross genug ist, um auf eigenen Füssen zu stehen, mit eigenen Akteuren, Vorbedingungen und Hauptablauf, dann ist es kein Enhancement. Dann ist es ein neuer Use Case.

Bug oder Enhancement? Die Entscheidungsregel

Die Mechanik einen Spec Bug zu beheben und ein Enhancement umzusetzen sieht fast identisch aus. Beide aktualisieren Spec, Tests und Code. Wie entscheidet man also?

Die Regel dreht sich um die Absicht, nicht um die Mechanik:

  • Bug: Die Spec sollte schon immer Verhalten X beschreiben, hat aber versehentlich Y beschrieben. Wir korrigieren einen Fehler.
  • Enhancement: Die Spec hat die alte Absicht korrekt beschrieben, und jetzt wollen wir bewusst neues Verhalten.

Frag dich: Hätte ein Stakeholder die Spec vor einem Jahr mit vollem Wissen über das gewünschte Verhalten abgenommen? Wenn ja, und jetzt wollen wir etwas anderes, dann ist es ein Enhancement. Wenn nein, und die Spec war von Anfang an falsch, dann ist es ein Bug.

Warum diese Unterscheidung wichtig ist

Man könnte alles in einen Topf werfen und es einfach „Arbeit“ nennen. Viele Teams tun das. AIUP trennt Bug und Enhancement aus einem Grund: die Zahlen zeigen, wo der Prozess leckt.

Wer Spec Bugs als Enhancements klassifiziert, dessen Defektrate sieht künstlich tief aus. Man verliert das Signal, dass die Anforderungserhebung, das Review oder der Audit der KI generierten Specs fehlerhafte Inhalte produziert. Die Feedback Schleife verstummt.

Wer sie als Bugs führt, kann sie weiter unterteilen:

  • Code Bugs zeigen Lücken im Harness: ein schwacher Skill, ein fehlender MCP Kontext oder eine Guideline, die das falsche Muster zulässt.
  • Spec Bugs deuten auf schwache Anforderungsarbeit hin, fehlende Einbindung der Stakeholder oder schlampige Reviews KI generierter Specs.
  • Test Bugs zeigen, dass die Test Suite selbst ein Review braucht, oder dass ein Test Skill spröde Tests erzeugt.

Jede Kategorie hat einen anderen Hebel weiter oben. Wer alles vermischt, kann keinen davon verbessern.

Wie die Nachvollziehbarkeit alles zusammenhält

In AIUP ist jeder Use Case, Bug und Enhancement über die @UseCase Annotation mit Code und Tests verbunden. Das AIUP Navigator Plugin zeigt die komplette Kette von der Anforderung über den Test bis zum Code.

Das macht die Unterscheidung praktisch statt theoretisch. Wenn ein Bug geschlossen wird, bleibt die Verknüpfung erhalten. Sechs Monate später kann man fragen: Wie viele Spec Bugs hatten wir in diesem Use Case? Hat derselbe Use Case mehrere Enhancements angezogen? Ist ein bestimmter Teil des Systems ein Defekt Magnet?

Ohne Nachvollziehbarkeit sind Bug und Enhancement nur Etiketten. Mit Nachvollziehbarkeit werden sie zu Rohdaten für die Verbesserung der Arbeitsweise.

Zusammenfassung

  • Ein Bug korrigiert einen Fehler. Der Fehler kann in der Spec, im Harness oder in einem Test liegen. Ein Defekt auf Code Ebene ist meistens ein Symptom einer Lücke im Harness, nicht ein eigenständiges Problem.
  • Ein Enhancement ändert die Richtung. Die alte Spec war richtig für die alte Absicht.
  • Ein neuer Use Case ist grösser als ein Enhancement und steht auf eigenen Füssen.
  • Die Entscheidung dreht sich um die Absicht, nicht darum, welche Artefakte angefasst werden.
  • Die Kategorien getrennt zu halten liefert das Signal, um den vorgelagerten Prozess zu verbessern.

Spec-getriebene Entwicklung heisst nicht nur, Specs vor dem Code zu schreiben. Es heisst, die Spec als lebendiges Artefakt zu behandeln, das selbst defekt sein kann. Sobald man das akzeptiert, wird die Kategorie Bug deutlich spannender.