Browser-Werkstatt ist ein Projekt, das ich (Torsten) als Solo-Projekt gestartet habe. Und obwohl ich viel Erfahrung mit Produktentwicklung habe, bin ich kein routinierter Software-Entwickler. Daher habe ich es nicht alleine gebaut, sondern mit einem Team aus KI-Agenten, das die Entwicklungsarbeit übernommen hat: Produktmanager, Architekten, UX-Experte, Entwickler, QA-Ingenieure — alle aus dem BMAD-Framework. Diese Geschichte erzähle ich hier.
Warum Browser-Werkstatt?
Ausgangspunkt war ein persönliches Interesse: Ich arbeit schon lange mit KI und habe auch einiges mit Vibe-Coding gebaut (zum Beispiel aus Spaß diese kleine Website und auch frühe Versionen einiger Tools auf dieser Website). Das ging schnell, war einfach, und die Ergebnisse waren technisch brauchbar. Aber sie haben nie die Anforderungen an professionelle Software erfüllt, die ich aus vielen Jahren Erfahrung im Bereich R&D kenne: Dokumentation, Robustheit, Architektur, Modularität, Änderungsfähigkeit, UX, Skalierbarkeit, Sicherheit uvm.
Ich wollte daher ausprobieren, ob man mit heutigen KI-Werkzeugen tatsächlich ein vollständiges, professionelles Produkt bauen kann — von der Idee über Architektur, Methodik, UX und Tests bis zur Deployment-Pipeline. Und das Ganze nicht als Experiment, sondern als echtes Produkt, das echte Nutzer verwenden und das wartbar und robust ist. Genau so, wie man es bei einem Software-Produkt von einer guten Firma erwarten würde.
Für dieses Experiment musste also eine Produktidee her, und da konnte ich mich an meinem eigenen Bedarf orientieren. Die Idee ist simpel: Es gibt viele kleine Aufgaben im Alltag, für die man eigentlich kein großes Programm braucht. Wörter oder Zeichen in einem Text zählen, ein Bild verkleinern, einen QR-Code erstellen — das sollte schnell, zuverlässig und kostenlos funktionieren.
Genau diese kleinen Aufgaben waren für mich der eigentliche Ausgangspunkt. Nicht die große Vision einer Tool-Plattform, sondern viele sehr konkrete Momente: schnell die Länge einer SMS prüfen, einem Familienmitglied ein Bild in kleinerer Dateigröße schicken, für eine Veranstaltung einen QR-Code erzeugen u.ä. Und das alles, ohne dafür erst einen Account bei irgendeinem Dienst anzulegen. Für diese Dinge gibt es zwar unzählige Angebote, aber nur wenige fühlten sich für mich respektvoll an. Oft stehen Pop-ups, aggressive Werbebanner oder künstliche Limits zwischen dir und der eigentlichen Aufgabe. Ich wollte das Gegenteil bauen: eine Werkstatt, in der man genau die Tools findet, die man braucht, und die den Job schnell und unaufdringlich erledigen.
Dazu kam noch ein zweiter Gedanke: Wenn ein Tool wirklich simpel wirkt, ist das meistens kein Zeichen dafür, dass wenig Arbeit drinsteckt, sondern dafür, dass jemand bewusst unnötige Komplexität entfernt hat. Genau das wollte ich bei Browser-Werkstatt erreichen. Die Oberfläche sollte ruhig bleiben, die Werkzeuge sofort verständlich sein, und die eigentliche technische Sorgfalt sollte im Hintergrund passieren. Wenn du auf den Wortzähler oder den Zeichenzähler gehst, sollst du nicht erst eine Anleitung studieren müssen. Die Seite soll dir das Gefühl geben: hier bin ich richtig, ich kann sofort loslegen, und ich kriege sofort mein Ergebnis.
Was mich an bestehenden Angeboten oft gestört hat: viele verlangen eine Registrierung, und man weiß nicht, was mit den hochgeladenen Dateien passiert. Die Idee von Browser-Werkstatt war daher von Anfang an klar: alle Berechnungen finden lokal im Browser statt. Keine Daten werden an Server übertragen. Wenn du das selber testen möchtest: einfach mal WLAN während der Benutzung der Seite abschalten – die Tools funktionieren weiter!
Das ist nicht nur ein Datenschutzversprechen, es ist auch technisch der sauberere Ansatz. Kein Backend, das gewartet werden muss, auf einem Server, der Kosten verursacht. Nur statische HTML-Seiten mit JavaScript, das im Browser des Nutzers läuft.
Das BMAD-Framework — ein Team aus KI-Agenten
Das Herzstück des Projekts ist das BMAD-Framework. BMAD (kurz für "Build More Architect Dreams") ist ein Ansatz, bei dem spezialisierte KI-Agenten verschiedene Rollen im Entwicklungsprozess übernehmen — ähnlich wie in einem echten Softwareteam. Sie sind eingebettet in entsprechende Abläufe ("Workflows"), haben geeignete Fähigkeiten (als "Skills" abgebildet) und arbeiten intensiv mit standardisierter Dokumentation, die sie selbstständig und kontinuierlich pflegen. So kann BMAD skalieren von einfachen Bug-Fixes bis hin zur Entwicklung komplexer Unternehmens-Systeme. Und durch die umfangreiche Dokumentation kann die Arbeit auch an jeder Stelle unterbrochen und später nahtlos dort wieder aufgegriffen werden - sogar von anderen Entwicklern.
So zumindest das Versprechen. Ich fand das so interessant, dass ich mich für dieses Projekt für BMAD entschieden habe.
Wichtig ist dabei: BMAD ist kein magischer Autopilot. Das Framework ersetzt nicht die Notwendigkeit, gute Entscheidungen zu treffen. Es schafft vielmehr ein Betriebssystem für Zusammenarbeit. Rollen, Übergaben, Artefakte und Qualitätskriterien werden so klar beschrieben, dass ein Agent nicht jedes Mal von null anfangen muss (oder raten muss, was der Nutzer will). Das war für mich der entscheidende Unterschied zu Vibe-Coding Ansätzen. Dort bekommt man mit Glück einmal ein gutes Ergebnis. Mit BMAD bekommt man eher die Chance auf wiederholbare Ergebnisse, weil die Regeln und Dokumente Teil des Prozesses sind.
Im Alltag merkt man das an vielen kleinen Stellen. Eine Story ist nicht nur eine Aufgabenbeschreibung, sondern enthält Akzeptanzkriterien, technische Hinweise, bereits bekannte Risiken und die genaue Reihenfolge der Arbeit. Wenn ein Developer-Agent loslegt, hat er dadurch nicht bloß ein Ziel, sondern auch Leitplanken. Wenn anschließend der QA-Agent übernimmt, prüft er nicht diffus auf "Qualität", sondern gegen dieselben Kriterien.
Hier sind die wichtigsten Rollen in BMAD:
Product Manager (PM) — Verantwortlich für das Product Requirements Document (PRD). Er definiert, welche Funktionen das Produkt haben soll, welche Nutzergruppen angesprochen werden und was der Geschäftssinn hinter jedem Feature ist. Der PM stellt sicher, dass nicht einfach drauflos entwickelt wird.
Architect — Entwirft die technische Lösung. Welche Tools, welche Architektur, welche Muster? Der Architekt schreibt Architecture Decision Records (ADRs) und sorgt dafür, dass technische Entscheidungen (auch neue Entscheidungen im Laufe des Projektes) nachvollziehbar dokumentiert sind.
Scrum Master (SM) — Erstellt einen Gesamtplan für die schrittweise Entwicklung der Software in Form von Epics, und dann daraus detaillierte Story-Dateien als Grundlage für die Entwicklung. Jede Story enthält: die User Story, Akzeptanzkriterien, Aufgaben und Unteraufgaben, Dev Notes mit technischen Details und eine Definition of Done. Der SM sorgt dafür, dass die Entwickler-Agenten alles haben, was sie brauchen.
Developer (Dev) — Implementiert die Stories, schreibt den Code, führt Tests durch. Folgt strikt der Red/Green/Refactor-Disziplin: erst ein fehlschlagender Test, dann minimale Implementierung, dann Refactoring.
QA Engineer — Überprüft fertige Stories durch Code Review, testet auf Randfälle und stellt sicher, dass Akzeptanzkriterien vollständig erfüllt sind.
Ich (Torsten) bin der Product Owner. Ich genehmige Stories, mache finale Reviews, treffe Priorisierungsentscheidungen und bin das letzte Qualitätsgate vor jedem Release.
Wie funktioniert die Zusammenarbeit in der Praxis?
Ein typischer Workflow sieht so aus:
- Ich formuliere einen Bedarf oder genehmige eine Idee aus dem PRD.
- Der SM erstellt eine Story-Datei mit allem Kontext, den der Entwickler brauchen wird.
- Der Dev-Agent liest die Story und entwickelt das Feature.
- Nach jedem Task markiert der Agent den Fortschritt in der Story-Datei.
- Der QA-Agent macht anschließend einen unabhängigen Code Review.
- Ich reviewe das Ergebnis und gebe Feedback (falls erforderlich).
Das klingt nach Overhead — aber der Vorteil ist deutlich: Jede Entscheidung ist dokumentiert, jede Änderung ist rückverfolgbar, und der Code hat von Anfang an Testabdeckung. So kann das Produkt sehr gut gepflegt und weiterentwicklet werden, auch weit über den ursprünglich geplanten Umfang hinaus.
Gerade bei einem Solo-Projekt ist das wichtiger, als es auf den ersten Blick wirkt. Wenn man allein arbeitet, entstehen viele Entscheidungen sonst nur im Kopf. Ein paar Wochen später weiß man zwar noch ungefähr, warum etwas so gebaut wurde, aber nicht mehr genau. Mit dem agentischen Prozess ist das anders. Wenn ich heute eine Story oder ein ADR lese, kann ich (oder auch der Agent) nachvollziehen, warum ein Tool eine bestimmte Grenze hat, warum ein Test so geschrieben wurde oder weshalb eine Architekturentscheidung gefallen ist. Das hilft enorm wenn bei späteren Änderungen weitere Entscheidungen getroffen werden müssen.
Der Entwicklungsprozess — Red/Green/TDD von Anfang an
Eine der wichtigsten Entscheidungen war: Test-Driven Development (TDD) von Tag 1. Nicht als nachträgliche Maßnahme, sondern als grundlegende Arbeitsweise.
Konkret bedeutet das für jeden Task:
- Red: Schreibe zuerst einen Test, der fehlschlägt. Der Test definiert, was die Implementierung leisten muss.
- Green: Schreibe den minimalen Code, der den Test zum Bestehen bringt.
- Refactor: Verbessere die Codestruktur, ohne die Tests zu brechen.
Für Browser-Werkstatt gibt es drei Testebenen entlang einer klassischen Testpyramide:
- Unit-Tests (Vitest): Testen die Logik-Module isoliert — z.B. die Zeichenzähl-Logik des Zeichenzählers oder die Passwort-Generierungslogik des Passwort-Generators. Diese Tests laufen in Millisekunden.
- Integration-Tests (Playwright): Prüfen die Build-Artefakte — z.B. ob alle erwarteten HTML-Seiten generiert werden, ob Sitemap-Einträge korrekt sind, ob JSON-LD-Strukturdaten vorhanden sind.
- Acceptance-Tests (Playwright): Testen die vollständige User-Experience im echten Browser — Navigation, Interaktionen, mobile Layouts, Barrierefreiheit.
Diese Aufteilung klingt trocken, hat aber im Alltag direkte Folgen. Wenn ich etwa beim QR-Code-Generator einen neuen Modus ergänze, möchte ich zuerst sicher sein, dass die Berechnungslogik stimmt. Das ist Sache der Unit-Tests. Danach interessiert mich, ob der Build die richtige HTML-Struktur erzeugt, ob strukturierte Daten sauber bleiben und ob keine Meta-Tags doppelt ausgegeben werden. Das ist Sache der Integration-Tests. Und erst danach kommt die Frage: Funktioniert das Ding für echte Menschen in einem echten Browser auch auf einem kleinen Handy? Das stellen die Acceptance-Tests sicher. Genau für diese Reihenfolge ist die Testpyramide da.
Der Effekt ist erheblich. Zum einen ist zu jedem Zeitpunkt eine hervorragende Testabdeckung gewährleistet, die sich in guter Software-Qualität niederschägt. Zum anderen werden die schnellen Test zuerst ausgeführt, so dass man sehr schnell Feedback hat, wenn etwas nicht stimmt. Unit Tests laufen in Millisekunden, können aber fast 80% aller Software-Fehler finden. Best "Bang-for-the-Buck"!
Ohne diesen Ablauf hätte ich viele Änderungen wahrscheinlich gar nicht durchführen können (zumindest nicht mit gutem Gewissen). Mit Tests kann ich relativ mutig umbauen, weil ich sofort sehe, ob ich etwas beschädigt habe. Das ist gerade mit KI-Agenten entscheidend. Sie sind schnell, aber Geschwindigkeit allein ist wertlos, wenn du anschließend nicht mehr weißt, ob das Ergebnis tragfähig ist.
Das Ergebnis: Regressionsfehler werden sofort gefunden. Wenn ein Refactoring etwas kaputt macht, zeigt der Test es unmittelbar an. Das gibt dem KI-Agenten (und mir) das Vertrauen, Änderungen durchzuführen, ohne Angst vor unerwarteten Nebenwirkungen.
Was gut funktioniert hat
Nach mehreren Monaten mit diesem Ansatz gibt es klare Stärken:
Strukturierte Stories sind ein Multiplikator. Je besser eine Story geschrieben ist — mit klaren Akzeptanzkriterien, konkreten Dev Notes und einem eindeutigen "Definition of Done" — desto besser ist die Implementierung. Der Agent folgt der Story exakt. Unklare Stories produzieren unklare Ergebnisse.
TDD verhindert Regressionen. Jedes Mal, wenn neue Features hinzugefügt wurden, gab es auch neue Tests. Das Testnetz ist gewachsen — und hat mehrfach verhindert, dass eine Änderung in einem Tool unbemerkt etwas in einem anderen kaputt gemacht hat. Und da Tests von den Agenten geschrieben werden, gibt es auch keine Ausrede mehr für fehlende Tests!
Das Test-Konstrukt wird laufend besser. Wenn dann doch einmal etwas durchgerutscht ist (sogenannter "Test Escape"), dann lässt sich einfach ein neuer Test Case hinzufügen ("Regression Guard"), so dass diese Art von Fehler in der Zukunft verhindert wird.
Die Geschwindigkeit ist real. Was früher Wochen gedauert hätte, läuft in Stunden. Der QR-Code-Generator mit mehreren strukturierten Modi (URL, WLAN, vCard, GiroCode) wurde in einer einzigen Session vollständig implementiert und getestet.
Dokumentation entsteht automatisch. ADRs, Story-Dateien, Sprint-Status, Dev Agent Records — all das ist ein Nebenprodukt des Prozesses. Nicht zusätzlicher Aufwand, sondern integraler Bestandteil der Arbeit.
Die Kombination aus festen Abläufen und flexiblen Agenten ist mächtig. In BMAD kann man entlang der definierten Abläufe arbeiten und so sehr gute Ergebnisse erzielen. Aber wenn man mal etwas anderes braucht, kan man es den Agenten einfach sagen! Bei heiklen Operationen immer erst nach Freigabe umsetzen? Dem Agenten einfach sagen "Erst die Ergebnisse der Analyse; ich gebe dir dann Anweisungen". Bei einfachen Operationen einfach machen ohne dem Nutzer lästig zu werden? Dem Agenten sagen "Mach YOLO". Das hat sich für mich als eine der großen Stärken von BMAD erwiesen - zum einen strikte Anleitung durch Workflows, zum anderen volle Flexibilität im Dialog mit den Agenten.
Ein weiterer Punkt, den ich unterschätzt hatte: Gute Dokumentation verbessert nicht nur die Nachvollziehbarkeit, sondern auch die Qualität der Gespräche mit den Agenten. Wenn eine Story sauber geschrieben ist, muss ich viel seltener nachsteuern oder umfangreiche Prompts schreiben. Kurze Anweisungen reichen und erlauben mir, sehr konkret einzugreifen. Das spart Zeit auf beiden Seiten. Die Agenten arbeiten präziser, und ich verbringe weniger Zeit damit, Missverständnisse wieder einzufangen.
Was wir (bisher) gelernt haben
Wo Licht ist, ist auch Schatten! Nicht alles hat auf Anhieb geklappt, und es gibt auch Grenzen.
Context-Limits sind real. Bei sehr langen Dateien oder komplexen Refactorings über mehrere Dateien hinweg verliert der Agent mitunter den Überblick. Die Lösung: Stories klein genug halten und in fokussierte Tasks zerteilen. Das macht der Scrum Master in der Regel automatisch, aber manchmal muss er angewiesen werden, die ein oder andere Story aufzuteilen. Ein Agent, der genau weiß, was er tun soll, liefert bessere Ergebnisse als einer, der versucht, alles auf einmal zu lösen.
Kleine Stories erweisen sich manchmal als überraschend groß. Trotz guter Aufteilung in Stories kann es Überraschungen geben und eine Aufgabe beschäftigt den Agenten mehr, als erwartet. Dann hat er sein Context Window bereits voll ausgeschöpft, obwohl er noch nicht fertig ist. Im aktuellen Context Window möchte man aber nicht mehr weitermachen, um Fehler zu vermeiden. Die Lösung: den Agenten bitten, einen Hand-Off Promt zu schreiben, mit dem die Aufgabe dann in einem neuen Chat fortgesetzt werden kann.
Der Agent sieht nichts. Design-Bugs (z.B. bei tückischen CSS-Kaskaden, wenn ein Element an einem Breakpoint falsch aussieht oder ein Layout-Problem auftritt) sind schwerer zu debuggen als Logik-Bugs. Der Agent sieht den Browser nicht! Playwright-Tests helfen, aber visuelle Regressionstests sind aufwändiger zu pflegen. Und Design oder UX kann er auch nicht gut beurteilen; hier sind Tests durch Menschen unumgänglich.
Der Human-in-the-Loop ist unverzichtbar. Ich bin nicht nur "Auftraggeber", sondern aktiv im Qualitätsprozess. Content-Entscheidungen, finale Design-Calls, das Reviewen von Artikeln — das bleibt menschliche Arbeit. KI-Agenten sind Multiplizierer, keine Ersatzspieler.
Agenten lügen nicht, aber sie erfinden manchmal. Ein Agent, der eine komplexe Aufgabe nicht lösen kann, sagt das üblicherweise nicht explizit — er versucht es trotzdem, mit manchmal unvollständigen Ergebnissen. Das ist der Grund, warum ein gründliches Testregime und menschliche Reviews unverzichtbar sind.
Geniale Programmierer und kleine Kinder zugleich. In einem Moment baut der Agent Lösungen zusammen, bei denen man nur staunen kann. Im nächsten Moment macht er einen blöden Fehler, so als wäre er ein 10-jähriges Kind an seinem ersten Computer. Diese Dissonanz im Charakter der Agenten ist man von Menschen nicht gewohnt, und sie macht die Arbeit mit Agenten manchmal zur Geduldsprobe.
Selbst große Modelle verlieren schnell den Überblick. Für komplexe Aufgaben nutze ich Opus 4.6, aber selbst dieses hervorragende SOTA-Modell (State of the Art) macht oft Fehler, wenn es um komplexe Abhängigkeiten im System oder über viele Stories hinweg geht. Hier bleibt es wichtig, Ergebnisse zu prüfen, Plausibilität zu hinterfragen und logische Konsistenz nachzuvollziehen. Beispiel: für einen Server-Dienst hatten die Agenten sich ordentlich um IT Security gekümmert, aber als weitere Dienste auf dem Server ergänzt wurden, habe sie es vergessen. Da schon eine Story zum THema Security existierte, war das Tema für sie erledigt. Auf gezielte Nachfrage habe die Agenten dann die Lücke entdeckt und geschlossen. Dieser Verlust des Überblicks ist gerade bei diesem Thema sehr kritisch!
Deshalb ist das Zusammenspiel zwischen Mensch und Agent für mich keine lästige Notwendigkeit, sondern der eigentliche Arbeitsmodus. Ich versuche nicht, jede Entscheidung an das System abzugeben. Ich nutze die Stärken der Agenten dort, wo sie stark sind: Geschwindigkeit, Struktur, Ausdauer, Testdisziplin, Wiederholbarkeit. Und ich halte bewusst die Bereiche bei mir, in denen Erfahrung, Urteil und Verantwortungsgefühl den Unterschied machen: Produktentscheidungen, inhaltliche Qualität, Priorisierung, System-Design und die Frage, ob sich etwas für echte Nutzer wirklich gut anfühlt.
Was als Nächstes kommt
Browser-Werkstatt wächst weiter. Geplant oder schon in Arbeit:
- Mehr Tools: Der Wortzähler, der Farbcode-Umrechner und Passwort-Generator sind bereits live. Weitere Tools aus den Bereichen Text und Konvertierung folgen.
- Verbesserungen der existierenden Tools: Z.B. kommt eine Satzmethode beim Passwort-Generator: ein neuer Modus, bei dem du einen einfach merkbaren deutschen Satz erhältst und ein daraus abgeleitetes sicheres Passwort.
- Dieser Blog: Mehr Einblicke in die Technik, den Prozess und die Learnings rund um Browser-Werkstatt.
Wenn du Tools vermisst, oder Feedback zum bestehenden Angebot hast, dann gerne Feedback! Die Feedback-Schaltfläche auf jeder Tool-Seite ist genau dafür da. Jede Rückmeldung landet direkt bei mir.
Auch wenn ich mit dem Projekt noch nicht fertig bin, soviel sage ich schon jetzt: Mit dem richtigen Rahmen, strukturierten Prozessen und gutem Testansatz lässt sich mit KI-Agenten tatsächlich professionelle Software bauen. Nicht als Prototyp, sondern als echtes Produkt.
Oh, one more thing: Als nächste große Entwicklung werde ich versuchen, ein weiteres System aus Agenten aufzubauen, das sich autonom um Wartung und Betrieb der Browserwerkstatt kümmert. Das wird sicher spannend! Ich werde hier bei Gelegenheit davon berichten.