Wie wir tatsächlich mit KI-Assistenten bauen

Dies beschreibt unsere eigene Arbeitsmethode — Forschung und Entwicklung dazu, wie wir bauen, nicht einen Kundenauftrag. Die Aussage „wir arbeiten mit KI“ sagt nichts über Qualität aus. Entscheidend ist, wo im Ablauf der Assistent steht, wer sein Ergebnis prüft und was geschieht, wenn die Prüfung fehlschlägt.

Was es ist

Ein dokumentierter Ablauf aus fünf Etappen, in dem jede Etappe einen harten Eintrittspunkt für die nächste hat.

• Analyse — wir verwandeln Kundenmaterial in ein Entscheidungsinventar: was bleibt, was neu geschrieben, zusammengeführt oder entfernt wird.
• Briefing — strategische Richtung und Umfang. Die Grenze ist eine datiert festgehaltene Kundenzustimmung.
• Plan — Architektur, Datenmodell, Meilensteine mit Schätzungen und Verantwortungszuordnung.
• Umsetzung — Code, Tests und unabhängige Prüfung, Meilenstein für Meilenstein.
• Verifikation — Performance, Barrierefreiheit, technisches SEO und QA. Von hier führt eine Rückkopplung zur Umsetzung.

Die Reihenfolge ist linear. Reparaturen gehen zurück zur Umsetzung, neuer Umfang aber zum Plan, nicht zum Briefing — das Briefing ändern wir nur, wenn sich das Geschäftsziel ändert.

Welches Problem es löst

• „Es wurde schnell fertig, aber niemand weiß genau, was.“ Ein Assistent erzeugt Code in einem Tempo, das ohne Verfahren niemand vollständig prüfen kann. Entscheidungspunkte erzwingen die Prüfung, statt auf guten Willen zu hoffen.
• Fehlende Wiederholbarkeit. Dieselbe Arbeit kann in zwei Sitzungen unterschiedliche Qualität liefern. Eine Liste von Abschlussbedingungen hält ein gemeinsames Mindestniveau und deckt Lücken vor dem Zusammenführen auf.
• Code ohne Entscheidungen. Nach drei Monaten erinnert sich niemand, warum diese Lösung gewählt wurde. Das Entscheidungsprotokoll gehört zum Ablauf, nicht in den Anhang.
• Bauen vor dem Verstehen. Der teuerste Fehler ist etwas richtig gebaut zu haben, das gar nicht gebraucht wurde. Daher enthalten die ersten zwei Etappen keine einzige Zeile Code.

Wie wir es gebaut haben

Die Rollenverteilung ist explizit und asymmetrisch. Ein Agent koordiniert die Arbeit, teilt sie in Bereiche und schützt den gemeinsamen Vertrag. Die übrigen übernehmen getrennte Module oder erhalten denselben Kontext, um eine unabhängige Hypothese aufzustellen, wenn die Diagnose stockt. Je nach Aufgabe können die Rollen Claude Code, Codex oder anderen Werkzeugen zugewiesen werden; kein Ergebnis umgeht die Prüfung durch die projektverantwortliche Person.

Unabhängige Prüfung wichtiger Änderungen: Die Autorin oder der Autor prüft das eigene Ergebnis, ist aber nicht die einzige Schranke. Eine andere Agenteninstanz oder die projektverantwortliche Person bewertet die Änderung ebenfalls; die Entscheidung über das Zusammenführen bleibt beim Menschen.

Regel für Dateigrenzen: Parallele Aufgaben erhalten standardmäßig getrennte Dateimengen. Wenn mehrere Bereiche in einer Integrationsdatei zusammentreffen, bestimmen wir eine verantwortliche Person für die Änderung; die übrigen liefern ihre Erkenntnisse zur Zusammenführung. Den Vertrag zwischen Modulen — Typen, Signaturen, API-Form — vereinbaren wir vor der Aufteilung. Andernfalls kann ein Merge-Konflikt mehr kosten als die Parallelität einbringt.

Die Qualitätsgrenze ist maschinell, nicht deklarativ. In CI führen wir Linting, Typprüfung, Inhaltsvalidierung und einen Production-Build aus. Performance und Barrierefreiheit messen wir getrennt in einer laufenden Umgebung nach den im Briefing festgelegten Schwellen; wir mitteln nicht zwischen Vorlagen, denn eine schlechte Seite wird nicht durch ein gutes Ergebnis einer anderen unsichtbar.

Der Projektstand lebt in dauerhaften Artefakten, nicht im Gedächtnis einer Sitzung: technischer Plan und Entscheidungsprotokoll im Repository, Code und Grundinhalte in Git, redaktionelle Inhalte aus dem Panel in der Datenbank. Dadurch beginnt die nächste Sitzung mit einem gespeicherten Stand; Repository-Änderungen haben Historie und einen verständlichen Diff.

Benannter Kompromiss: Dieser Ablauf verlagert Aufwand an den Anfang. Analyse, Briefing und Planung brauchen Zeit, bevor der erste Bildschirm entsteht, und Änderungen an Grundinhalten brauchen wie Code eine Prüfung. Das Redaktionspanel erleichtert die Veröffentlichung neuer Beiträge, ersetzt aber nicht die Versionierung von Entscheidungen und Vorlagen. Für eine einmalige Visitenkarte kann sich diese Strenge nicht lohnen; bei einem weiterentwickelten System verringert sie die Kosten späterer Missverständnisse.

Was es belegt

Dass Planung vor dem Bauen bei uns ein Verfahren und kein Schlagwort ist — mit Artefakten, die sich öffnen und prüfen lassen. Das ist ein Beleg für die Leistung Design und Planung, also die Etappe, in der wir vor der Schätzung der gesamten Einführung klären, was und wofür wir bauen.

Auf demselben Ablauf basieren von Grund auf gebaute Anwendungen. Die Multi-Agenten-Schicht beschreiben wir in KI-Forschungsworkflows, die Kundenversion im Prozess.