Wer Browser-Werkstatt nutzt, sieht eine schlichte Seite mit nützlichen Tools. Was dahintersteckt, ist ein durchdachter Tech-Stack, der auf Einfachheit, Testbarkeit und schnelles Deployment ausgelegt ist — und der von KI-Agenten entwickelt und gepflegt wird. Hier ist der Überblick.
Der Stack auf einen Blick
| Technologie | Zweck |
|---|---|
| 11ty (Eleventy) | Static Site Generator |
| Nunjucks | Template-Engine für das Design Shell |
| Vitest | Unit-Tests für JavaScript-Logik |
| Playwright | Integration- und Acceptance-Tests |
| ESLint | JavaScript-Linting |
| GitHub Actions | CI/CD-Pipeline |
| Strato | Web-Hosting (rsync über SSH) |
| Hetzner | VPS für Analytics (privacy-focused) |
Keine Datenbank. Kein Backend. Kein komplexes JavaScript-Framework im Browser — nur die Tool-Logik, die für das jeweilige Werkzeug nötig ist. Das ist bewusste Einfachheit.
11ty — Static Site Generator ohne Overhead
11ty (Eleventy) ist der Kern des Projekts. Es liest Markdown-Dateien und Nunjucks-Templates und erzeugt daraus rein statische HTML-Seiten. Kein React, kein Vue, kein Next.js — einfach HTML, das der Browser direkt versteht.
Warum dieser Ansatz?
- Geschwindigkeit: Statische Seiten laden in unter 100ms. Kein Server-Rendering, kein Hydration-Overhead.
- Wartungsfreiheit: Es gibt kein Backend, das gepatcht werden muss, keine Datenbank, die ausfallen kann.
- Kosten: Hosting kostet einen niedrigen zweistelligen Euro-Betrag pro Monat — kein Cloud-Provider, kein serverless-Pricing.
- Sicherheit: Ohne Backend gibt es keine SQL-Injections, keine Server-Side-Angriffsflächen.
Die Tools selbst sind einzelne HTML-Dateien mit eingebettetem JavaScript. Kein Build-Step für die Tool-Logik — der Browser führt sie direkt aus. Das passt zum Datenschutzversprechen: Alle Berechnungen laufen lokal, nichts verlässt den Browser.
Für mich war das nicht nur eine technische, sondern auch eine redaktionelle Entscheidung. Die Seite sollte nicht wie eine App wirken, die zufällig auch ein paar Texte hat. Sie sollte sich wie eine Website anfühlen, deren Inhalte stabil, lesbar und langlebig sind. 11ty passt dafür sehr gut, weil Markdown und Templates sauber zusammenspielen. Ein neuer Blogartikel (wie dieser Text hier) ist am Ende genau das: eine Datei im Repository mit klarer Struktur, Frontmatter für Metadaten und normalem Text, der sich gut versionieren lässt. Keine Datenbank, kein Admin-Panel, kein versteckter Zustand irgendwo im Hintergrund.
Das Design Shell — Nunjucks-Template-Hierarchie
Die "Design Shell" ist das Herzstück des Frontend-Designs. Es gibt drei Basis-Layouts:
base.njk— Gemeinsame HTML-Struktur:<head>, Meta-Tags (inkl. Open Graph), Stylesheets, Header, Footer, Cookie-Consent-Banner.tool.njk— Erbt vonbase.njk, fügt Tool-spezifische Strukturen hinzu (Titel, Beschreibung, Tool-Widget-Slot, SEO-Inhaltsbereich, Verwandte Tools, FAQ-Sektion).blog-article.njk— Erbt vonbase.njk, fügt Blog-Artikel-Struktur hinzu (Überschrift, Metadaten, Lesezeit, Article-JSON-LD, FAQPage-JSON-LD).
Jedes neue Tool oder jeder neue Blogartikel erbt automatisch das gesamte Design, die Navigation und alle Strukturdaten — ohne dass ein Entwickler etwas manuell kopieren muss.
Das hilft besonders dann, wenn man bestehende Seiten nachschärfen will. Ein Beispiel aus dieser Story war die Open-Graph-Metadatenlogik für Blogartikel. Statt auf jeder Seite Sonderfälle einzubauen, lässt sich die Meta-Logik zentral im Layout halten und pro Seitentyp nur gezielt überschreiben. Genau solche Eingriffe sind in einer Template-Hierarchie deutlich sauberer als in einem Wildwuchs aus Einzeldateien. Die Oberfläche bleibt konsistent, aber man kann trotzdem fachliche Unterschiede zwischen Tool-Seiten, Blogartikeln und rechtlichen Seiten abbilden.
Die Testpyramide
Ein zentrales Prinzip: Test-Driven Development (TDD) von Anfang an. Dies ist die erste Handlung bei jeder neuen Funktionalität.
Die Testpyramide sieht so aus:
Ebene 1: Unit-Tests (Vitest)
Vitest testet die JavaScript-Logik-Module isoliert. Jedes Tool hat ein separates Logik-Modul (z.B. zeichenzaehler-logic.js, passwort-generator-logic.js), das reine Funktionen enthält — kein DOM, keine Seiteneffekte.
Beispiel aus dem Zeichenzähler: Die Funktion countSmsUnits() zählt SMS-Einheiten korrekt für Standard-GSM-7-Zeichen (160 Zeichen pro SMS) und für UCS-2-Zeichen wie Emojis oder Sonderzeichen (70 Zeichen pro SMS). Diese Logik ist 100% unit-testbar — kein Browser nötig.
Ergänzend zur Red/Green/Refactor TD Anweisung haben die Agenten auch noch die Aufgabe, zu jeder Unit mindestens 3+3+3 Unit Test Cases zu erstellen. 3 normale Tests ("Happy Case"), 3 Grenzfälle ("Edge Cases") und 3 Robustheits-Tests (Bereichsüberschreitungen und andere ungültige Eingaben). So erzielen die Agenten robuste Software ("Defensive Programming"), die auch bei späteren Änderungen nicht gleich zusammenbricht. Und da nun Agenten die Tests schreiben, gibt es auch keine Ausrede mehr, sie nicht zu erstellen und zu pflegen.
Unit-Tests laufen in Millisekunden. Ein vollständiger Durchlauf des gesamten Projekts dauert unter zwei Sekunden.
Diese Geschwindigkeit ist in der Praxis enorm wichtig. Wenn ein Testlauf träge ist, wird er im Alltag automatisch seltener gestartet. Bei Browser-Werkstatt ist das Gegenteil der Fall: Gerade weil Vitest schnell reagiert, lässt sich der Red/Green-Zyklus wirklich leben. Der Agent kann eine kleine Änderung vornehmen, sofort testen, nachjustieren und erst dann weitermachen. Das klingt banal, ist aber einer der Gründe, warum auch kleine Tools wie der Wortzähler oder spezialisiertere Funktionen wie SMS-Zählung im Zeichenzähler stabil bleiben, obwohl ständig weiterentwickelt wird.
Ebene 2: Integration-Tests (Playwright)
Integration-Tests prüfen die Build-Artefakte. Nach npm run build wird geprüft:
- Existieren alle erwarteten HTML-Seiten in
_site/? - Enthält der gebäute HTML-Code die richtigen JSON-LD-Strukturdaten?
- Sind Sitemap-Einträge vorhanden?
- Gibt es keine doppelten Open-Graph-Tags?
Diese Tests laufen ohne Browser — sie lesen direkt die erzeugten Dateien. Schnell und deterministisch.
Gerade für statische Seiten ist das Gold wert. Viele Fehler entstehen nicht in der eigentlichen Logik, sondern in der fertigen Ausgabe: ein fehlender Canonical-Link, doppelte Meta-Tags, ein nicht erzeugter Sitemap-Eintrag oder eine kaputte JSON-LD-Struktur. Solche Dinge sind in klassischen manuellen Checks leicht zu übersehen. Aber ein Integrationstest ist unbestechlich! Er schaut direkt in die erzeugte Datei und prüft, ob die Seite wirklich das enthält, was sie enthalten soll.
Ebene 3: Acceptance-Tests (Playwright)
Acceptance-Tests testen die vollständige User-Experience im echten Browser (Chromium). Sie prüfen u.a.:
- Funktioniert die Navigation?
- Reagiert die Seite korrekt auf Nutzerinteraktionen?
- Gibt es horizontales Scrollen auf 375px-Mobilgeräten?
- Sind ARIA-Attribute korrekt gesetzt?
Für komplexe Features wie den QR-Code-Generator gibt es mehrere Acceptance-Tests, die verschiedene Modi prüfen: URL, WLAN, Visitenkarte, GiroCode (EPC QR).
Playwright führt diese Tests in vier Runnern parallel aus. Ein vollständiger Acceptance-Test-Lauf dauert typischerweise 2-3 Minuten und wird von den Agenten lokal durchgeführt (bevor die neue Version auf GitHub geht).
Ergänzend zu den funktionalen Acceptance Test laufen auch noch Kompatibilitäts-Test in drei Browsern parallel (Chromium, Firefox, WebKit) bevor eine neue Version der Website ausgerollt wird. Diese laufen auf GitHub als Teil der Remote CI Pipeline, und sind mit ca. 15 Minuten Dauer die langsamsten Tests. So wird aber konsistente Darstellung auf allen führende Browsern und auf verschiedenen Viewport (Responsive Design) sichergestellt.
Der Agentenaufbau — wer macht was?
Das BMAD-Framework definiert klare Rollen und Verantwortlichkeiten. Ich nutze VS Code für die Entwicklung, und jeder Agent arbeitet somit in GitHub Copilot. Als Sprachmodell verwende ich typischerweise Anthropic's Claude Opus 4.6 für komplexere Aufgaben, Claude Sonnet 4.6 für Aufgaben mit normalen Schwierigkeitesgrad, und GPT 5.4 für Reviews (immer in einem neuen Chat für ein frisches Context Window).
SM (Scrum Master): Vorbereitung von Story-Dateien aus Epics. Der SM liest das PRD und die Architektur-Dokumente und erstellt detaillierte Story-Dateien mit Akzeptanzkriterien, Tasks/Subtasks und Dev Notes. Er entscheidet auch über die Story-Reihenfolge im Sprint.
Dev (Developer): Implementiert Stories strikt in der Reihenfolge der Tasks/Subtasks. Schreibt zuerst fehlschlagende Tests (Red), dann minimalen Code (Green), dann Refactoring. Dokumentiert Entscheidungen im "Dev Agent Record" der Story-Datei.
QA: Code Review nach Abschluss einer Story. Prüft auf Randfälle, unerfüllte Akzeptanzkriterien, Sicherheitslücken und Code-Qualität. Der QA-Agent bekommt die Story und alle geänderten Dateien als Kontext. Wenn die erforderlichen Maßnahmen nach dem Review einfach sind, lasse ich den QA sie direkt durchführen. Sind sie umfangreicher, erstellt der QA einen Hand-Off Prompt mit dem ich dann den Dev erneut anstoße, um die Maßnahmen umzusetzen.
PM (Product Manager): Verwaltet das PRD und Epics-Dokument. Schreibt neue Feature-Beschreibungen und Acceptance Criteria für Stories. Entscheidet über Priorisierung zusammen mit mir als PO.
Architect: Hat die ursprüngliche Architektur erstellt, und wartet sie nun. Verfasst "Architecture Decision Records" (ADRs) für wichtige technische Entscheidungen. Z.B. ADR-001 für die Ops-Agent-Topologie oder die Entscheidung, 11ty statt eines SPA-Frameworks zu verwenden.
Ich — Torsten — bin Product Owner. Ich approve Stories, reviewe Content (wie diesen Artikel), treffe finale Design-Entscheidungen und bin das letzte Qualitätsgate vor jedem Deployment.
Diese letzte Instanz ist kein Misstrauensvotum gegen die Agenten, sondern eine sinnvolle Arbeitsteilung. Die Agenten bringen Tempo und Struktur. Ich bringe Kontext über Zielgruppe, Ton, Prioritäten und die vielen kleinen Entscheidungen, die man nicht sauber aus einem Prompt heraus erzwingen kann. Genau deshalb funktioniert die Kombination aus BMAD-Framework und menschlichem Review für dieses Projekt besser als reine "Lass die KI mal machen"-Experimente.
GitHub Actions als CI/CD-Pipeline
Jeder Push auf main triggert die Pipeline:
npm install— Dependencies installierennpm run build— Site bauen mit 11tynpx vitest run— Unit-Tests ausführennpx playwright test --project=integration-*— Integration-Tests ausführennpx playwright test --project=acceptance-*— Acceptance-Tests ausführen (multi-browser)- Bei Erfolg: Deploy automatisch auf Strato per rsync über SSH
Wenn auch nur ein Test fehlschlägt, stoppt die Pipeline. Kein defekter Code landet auf der Live-Seite!
Was gut funktioniert
Der Stack hat sich in der Praxis bewährt — mit klaren Stärken:
11ty ist schnell genug. Der gesamte Build (31 Seiten, CSS, Sitemap, alle Templates) dauert unter einer halben Sekunde. Für ein Projekt dieser Größe ist das mehr als ausreichend.
Die Testpyramide hält, was sie verspricht. Mehrfach hat ein Unit-Test Regressionen gefangen, die bei manuellem Testing leicht übersehen worden wären.
Nunjucks-Templates halten das Design konsistent. Alle 14+ Seiten sehen identisch aus, weil sie dasselbe base.njk erben. Eine Änderung im Header gilt automatisch überall.
CI/CD automatisiert Buidl, Test und Deployment. Sowohl lokal wie auch remote auf GitHub wird mit der gleichen Pipeline gearbeitet, und nach Änderungen am Produkt wird innerhalb von Minuten eine neue Version der Website ausgerollt.
Dokumentation als Byproduct. ADRs, Story-Dateien, Sprint-Status, Dev Agent Records — das alles entsteht als natürlicher Teil des Prozesses. Kein gesonderter Dokumentationsaufwand.
Auch infrastrukturell ist der Stack bewusst konservativ. Hosting auf Strato per rsync über SSH ist kein hipper Konferenz-Talk, aber für dieses Projekt eine solide Wahl. Es gibt keine Container-Orchestrierung für die Website, keine komplexe Buildfarm und keinen Deploy-Zirkus. Das Deployment ist nachvollziehbar, preiswert und robust genug für eine statische Website. Diese Nüchternheit zieht sich durch das ganze Projekt: lieber ein Werkzeug, das transparent und boring ist, als eine schicke Plattform, die für den eigentlichen Zweck unnötig viel Reibung erzeugt.
Was nicht funktioniert
Ehrlichkeit über die Grenzen:
Versionierung von Tools und Konfiguration. Auch wenn die CI/CD Pipeline im Großen und Ganzen sehr gut funktioniert, gab es doch mehrfach Probleme wegen Inkompatibilitäten von Tools in unterschiedlichen Versionen. Beispiel: Auf GitHub lief Node in einer unterschiedlichen Patch-Version als bei mir lokal, was zu Testfehlern führte. Oder auf meinem Mac Book zu Hause war die Python Umgebung etwas anders konfiguriert als auf meinem Rechner im Büro, was mit den Init-Skripten von BMAD zu Fehlern führte. Alles korrigierbar, aber immer wieder erst mal lästig.
BMAD entwickelt sich rasant weiter. Es gibt ständig Fortschritte bei BMAD. Zum Beispiel wurden vorherige System-Prompts für Agenten und Workflows Anfang des Jahres auf Skills umgestellt, dann wurden sie umgebaut für besserer Performance, dann wurde Python Init-Skripte eingeführt für das Laden den Konfiguration. Alles positive Entwicklungen, die die Mehode noch weiter verbessert haben - aber auch jedes Mal eine Änderung in der Bedienung und in den Tool-Artefakten.
Fazit: Ein Stack, der funktioniert
Browser-Werkstatt ist der Beweis, dass man mit 11ty, Vitest, Playwright und einem disziplinierten Agenten-Prozess professionelle Software bauen kann — mit minimalem Overhead, geringem Wartungsaufwand, mit echten Tests und echtem Live-Deployment.
Der Wortzähler, der Farbcode-Umrechner, der Bildkomprimierer und alle anderen Tools laufen auf genau diesem Stack. Stabil, getestet, schnell.