webvise liefert Kundensoftware über einen dokumentierten, KI-gestützten Entwicklungsworkflow: Plan-Modus vor jeder Zeile Code, eine DESIGN.md vor jedem UI, eine öffentliche Skill-Bibliothek und Verifier-Agents, die ihre eigene Arbeit nie selbst freigeben. Der stehende Beweis ist webvise.io selbst, zu 100 % KI-codiert mit Claude Code, 96 Punkte im Lighthouse, Repo öffentlich unter github.com/sebastiankehle.
Ein Beleg vorab: eine 61-seitige zweisprachige Website für ein Architekturbüro, in einem Tag neu gebaut und mit einem QA-Report über 60 Seitenaufrufe ohne einen einzigen Konsolenfehler abgenommen. Sie haben vermutlich dieselben Tools installiert, und das Ergebnis wirkt trotzdem generisch. Dieser Artikel dokumentiert die Pipeline, die diese Lücke schließt. Sechs Build-Stufen, drei Modell-Ebenen, drei Agentenrollen und die Zahlen, die jede davon geliefert hat.
- Jeder Build durchläuft sechs feste Stufen: Validate, Scaffold, DESIGN.md, Build, Polish, Ship. Die Design-Constraints existieren als Datei, bevor die erste Zeile UI-Code entsteht.
- Modelle laufen in drei Ebenen. Das stärkste Modell plant, ein effizientes Modell implementiert, ein günstiges Modell übernimmt Lookups. Das teure Modell schreibt einen Skill einmal, danach führen ihn günstige Modelle aus.
- Ein Verifier-Agent gibt nie seine eigene Arbeit frei. Das Review läuft in einem frischen Kontext ohne Erinnerung an den geschriebenen Code, und UI-Änderungen werden vor dem Shipping in einem echten Browser geprüft.
- Neun Skills liegen im öffentlichen Repo, von animation-vocabulary bis shadcn. Ein neuer Skill wird mit einer einzigen Symlink-Zeile registriert.
- Die Belege sind öffentlich: webvise.io ist zu 100 % KI-codiert mit 96 Lighthouse-Punkten, und dieselbe Pipeline hat 25+ Kundenprojekte mit im Schnitt 3 Wochen bis zum Launch geliefert.
Die Pipeline bleibt gleich, ob am Ende eine Marketing-Site steht oder ein Portal mit Auth, Rollen und Dashboards. Wenn Sie diese Klasse von Software brauchen: Der Full-Stack-Service von webvise führt jedes Projekt durch genau die Stufen unten.
Die sechs Build-Stufen
Jedes Projekt durchläuft sechs Stufen in fester Reihenfolge, und jede Stufe hat eine Exit-Bedingung, die vor der nächsten geprüft wird. Die Abfolge ist bewusst unspektakulär. Unspektakuläre Abläufe überleben Termindruck.
| Stufe | Was passiert | Exit-Bedingung |
|---|---|---|
| 1. Validate | Scope, Inhalte und Erfolgskriterien werden festgezurrt | Eine schriftliche Build-Entscheidung |
| 2. Scaffold | Better-T-Stack generiert die Basis, die Beispiel-App wird gelöscht | Ein sauberes Repo, das baut und läuft |
| 3. DESIGN.md | Farben, Typo-Skala, Abstände und Motion-Regeln als Datei | Constraints, an die sich das Modell halten muss |
| 4. Build | Features nach Plan, Plan-Modus vor dem Code | Funktionierende Software hinter jeder Route |
| 5. Polish | Motion, Empty States, Edge Cases, Texte | Review durch einen separaten Verifier-Agent |
| 6. Ship | Browser-verifizierte QA, dann Deployment | Null Konsolenfehler auf allen Seiten |
Stufe 3 lassen die meisten Teams aus, und genau dieses Auslassen macht KI-generierte Interfaces generisch: Das Modell hat keinen Constraint, an den es sich halten muss. Eine DESIGN.md legt Palette, Typo-Skala, Abstandssystem und Motion-Regeln fest, bevor UI-Code existiert. Aus "mach es hübsch" wird eine prüfbare Anweisung.
Stufe 2 enthält eine Gewohnheit, die sich zu übernehmen lohnt: Direkt nach dem Scaffolding mit Better-T-Stack wird die mitgelieferte Beispiel-App gelöscht. Demo-Code, der Woche zwei erlebt, wird tragend.
Drei Modell-Ebenen und eine ökonomische Regel
Das stärkste Modell plant. Ein effizientes Modell der Mittelklasse implementiert gegen diesen Plan. Ein günstiges Modell übernimmt Lookups, Doku-Recherchen und Dateizugriffe. Diese Verteilung reserviert den teuren Kontext für die Entscheidungen, die das Projekt verzweigen, und hält die Kosten im mechanischen Mittelteil niedrig.
Eine Regel trägt die Ökonomie: Das teure Modell schreibt einen Skill genau einmal, danach führen ihn günstige Modelle bei jedem weiteren Lauf aus. Das Schreiben ist der urteilsintensive Teil, die Ausführung folgt Mustern, und der Preis sollte jeweils dazu passen.
Orchestrator, Executor, Verifier
Agentenarbeit teilt sich in drei Rollen. Ein Orchestrator hält den Plan und verteilt Aufgaben. Executor-Agents implementieren je eine Aufgabe, mit genau dem Kontext, den diese Aufgabe braucht. Ein Verifier prüft das Ergebnis, und er läuft nie in dem Kontext, der den Code erzeugt hat.
Selbstfreigabe ist der Fehlermodus, den das verhindert. Ein Modell, das seinen eigenen Output prüft, übernimmt seine eigenen Annahmen, und das Review bestätigt den Code, statt ihn zu testen. Ein frischer Verifier-Kontext muss die Logik aus dem Diff rekonstruieren, und genau dort zeigen sich die Lücken.
Bei UI-Arbeit ist der Job des Verifiers physisch: Dev-Server starten und die Änderung in einem echten Browser durchklicken. Der 61-seitige zweisprachige Rebuild für Gabrys Architektur ging in einem Tag durch dieses Gate, und zur Übergabe gehörte ein QA-Report über 60 Seitenaufrufe mit null Konsolenfehlern.
Eine Skill-Bibliothek statt Prompts im Chatverlauf
Wiederkehrendes Urteilsvermögen wird als Skill verpackt, als Anweisungsdatei, die der Agent lädt, sobald eine Aufgabe passt. Neun davon liegen im öffentlichen webvise-Repo: animation-vocabulary, apple-design, blog-article, design-webvise-asset, emil-design-eng, find-animation-opportunities, improve-animations, review-animations und shadcn. Ein neuer Skill ist für Claude Code mit einer Symlink-Zeile registriert.
Derselbe Mechanismus geht auch an Kunden. MP Bau, ein Bauunternehmen, bekam einen Dokumentkonvertierungs-Skill als eigenes, kundenseitiges Tool. Für Gabrys Architektur schrieben drei Agents parallel Blog-Inhalte mit einem gemeinsamen Autoren-Skill, sodass jeder Artikel in derselben Stimme herauskam.
Der MP-Bau-Build hat einen eigenen Beitrag: der Artikel zur Dokumentautomatisierung. Wenn noch offen ist, welcher Workflow in Ihrem Unternehmen zuerst einen Skill verdient, beginnt die AI-Beratung von webvise jedes Projekt genau an dieser Stelle.
AGENTS.md ist der Vertrag
Jedes Repo trägt eine AGENTS.md, die der Agent liest, bevor er eine Datei anfasst. Darin stehen die Kommandotabelle (dev, build, lint, test, db), die Konventionen (Biome fürs Formatieren, typisierte Env-Variablen, Server Components als Standard) und die Verhaltensregeln, die den Output berechenbar halten.
- Lesen vor dem Editieren. Keine Änderung landet in einer Datei, die der Agent nie geöffnet hat.
- Minimaler Code, der das Problem löst. Keine spekulativen Abstraktionen, keine Konfigurierbarkeit, die niemand bestellt hat.
- Bei UI-Arbeit: Dev-Server starten und die Änderung im Browser prüfen. Die Regel, die aus "sieht fertig aus" ein "verifiziert fertig" macht.
Ein produktionsreifes Template mit dem vollständigen Regelsatz steht im AGENTS.md-Template-Artikel. Das Kopieren dauert fünf Minuten und beseitigt eine ganze Kategorie von Agenten-Fehlgriffen.
Der Beweis ist öffentlich
webvise.io ist die Dauervorführung der Pipeline: zu 100 % KI-codiert mit Claude Code, 96 Punkte im Lighthouse, Repo öffentlich unter github.com/sebastiankehle. Jede Seite, jede Animation und das Blog-System selbst sind durch die sechs Stufen oben gegangen.
| Projekt | Durch die Pipeline geliefert | Zahlen |
|---|---|---|
| webvise.io | Marketing-Site, Blog, Dashboard | 100 % KI-codiert, 96 Lighthouse |
| Gabrys Architektur | 61-seitiger zweisprachiger Rebuild | 1 Tag, 60 Seitenaufrufe geprüft, 0 Konsolenfehler |
| MP Bau | Dokumentkonvertierungs-Skill als Kunden-Tool | Einmal geschrieben, läuft auf günstigen Modellen |
| Alle Projekte | Kundensoftware über 25+ Lieferungen | Im Schnitt 3 Wochen bis zum Launch |
Jede Behauptung oben hat eine öffentliche URL oder ein Repo hinter sich. Wenn Ihr nächster Build durch diese Pipeline laufen soll, melden Sie sich bei webvise, und Sebastian legt die sechs Stufen auf Ihr Projekt um.
Die Praktiken von webvise sind an den ISO 27001- und ISO 42001-Standards ausgerichtet.