Arbeitsweise

Wie ich ohne Entwickler-Vergangenheit Produkte baue

Bevor eine Zeile Code entsteht, lasse ich ein Arbeitspaket nach meiner Vorlage definieren: Hypothese, Akzeptanzkriterien und was ausdrücklich nicht dazugehört.

Bei bonwise sind so über hundert Arbeitspakete entstanden, jedes erst nach meiner Freigabe umgesetzt.

  1. Playbooks
  2. Arbeitspakete
  3. Prüfstrecke
Stand
September 2026
In Betrieb
2 Anwendungeneine Beta, ein Live-Produkt
Tech Stack
Claude Code · GitHub · VS Code · Vercel

Auf einen Blick

IdeeBrainstormingProjekt-SteckbriefFragestellungenDeep ResearchPlaybooksProjekt-Setuproadmap.mdUser StoryMockupCodeReleaseV1 → V2 → …IdeeBrainstormingProjekt-SteckbriefFragestellungenDeep ResearchPlaybooksProjekt-Setuproadmap.mdUser StoryMockupCodeReleaseV1 → V2 → …
01

Projekt-Setup — einmal je Projekt

Aus einem Deep Research leite ich Entscheidungen und Projektregeln ab.

  1. Deep Research
  2. Playbooks
  3. Entscheidungen und Regeln

Als bonwise Multi-User-fähig werden sollte, brauchte die App eine Datenbank, meine erste. Mir war bewusst: Bei der Sicherheit von Daten darf kein Fehler passieren. Statt direkt mit der Einrichtung zu beginnen, startete ich Deep-Research-Aufträge: Stärken und Schwächen verschiedener Datenbank-Anbieter, bewährte Standards, typische Fehler, Sicherheitsrisiken.

Bei einem neuen Thema lese ich zuerst, woran andere gescheitert sind.

Artefakt · Vom Deep Research zum Playbook, Mai 2026 — drei Ausschnitte, unverändert
1 · Deep-Research-Bericht, 16. Mai 2026
Deep-Research-Bericht zur Datenbank-Wahl — Titel, Zielgruppe und Inhaltsverzeichnis
2 · Ordner: Berichte und Playbooks
Ordneransicht — Research-Berichte und daraus destillierte Playbooks
  1. aus den Berichten destilliert: die Playbooks
3 · Index: welches Playbook wann gilt
Index der Datenbank-Playbooks — welches Modul in welcher Phase gilt
  1. Wann greift Claude auf welches Playbook zu?

Damit stand die Grundlage für die Einrichtung meiner ersten Datenbank: Best Practices, Anti-Patterns und die Regeln, die für das Projekt gelten sollten.

Was ein Playbook festhält

  • Best Practices: Standards, die für das Projekt gelten
  • Entscheidungslogiken: wann welche Option die richtige ist
  • Anti-Patterns: Lösungswege, die nicht angewandt werden dürfen
  • Risiken: Fehler, die typischerweise begangen werden

So beginnt jedes Thema, das ich zum ersten Mal anfasse: erst der Deep Research, dann die Playbooks, dann die Entscheidungen. Was für das Projekt gilt, übernehme ich als Regel in die CLAUDE.md, die Datei, die Claude Code in jeder Session mitliest. Andere Regelwerke stehen in separaten Dateien, etwa das Design-System oder das Deploy-Runbook; die CLAUDE.md verweist darauf und legt fest, wann welches Regelwerk gelesen wird.

Regelwerke · Acht Dateien aus einem Projekt
  • CLAUDE.mdRegeln, die Claude Code in jeder Session mitliest
  • design-system.mdFarben, Typografie, Komponenten, ein Wortlaut für alle Screens
  • R0-1-backup-routine.mdEin Arbeitspaket: Hypothese, Scope, Slices, Akzeptanzkriterien
  • 001-ADR.mdEine Architekturentscheidung mit Optionen und Begründung
  • DSGVO_compliance.mdWarum Kassenbons Gesundheitsdaten sind und was daraus folgt
  • teststrategie.mdWas wann geprüft wird: Unit, E2E, Mess-Harnesse
  • nutzerfeedback_playbook.mdNutzerfeedback erfassen, clustern, priorisieren
  • deploy-runbook.mdStaging, Risikostufe, Rollback, Migration
02

Arbeitszyklus — je Arbeitspaket

Zwischen Auftrag und Code stehen Auftaktrunde, Arbeitspaket und meine Freigabe.

  1. Auftaktrunde
  2. Arbeitspaket
  3. Freigabe
  4. Mockup
  5. Code
  6. Akzeptanzkriterien

Zu Beginn eines Auftrags steht eine Auftaktrunde: Claude Code lädt den Kontext und skizziert in Stichpunkten das eigene Verständnis des Auftrags, die Optionen und die offenen Fragen. Erst wenn dieses Verständnis mit meinem übereinstimmt, lasse ich das Arbeitspaket ausformulieren: Hypothese, Scope und Akzeptanzkriterien.

User-Interfaces iteriere ich zunächst über Mockups, von Skeleton bis High-Fidelity. Arbeitspakete werden in Slices umgesetzt, jeder einzeln abschließbar und committbar.

Architektur-Entscheidungen halte ich als ADRs fest (Architecture Decision Records): die Optionen, die Entscheidung und das Verworfene samt Begründung. So sieht ein Entwickler später nicht nur, was gebaut wurde, sondern warum.

Was ein Arbeitspaket definiert

  • User Story oder Hypothese
  • Ist-Stand am Code geprüft
  • Optionen mit Vor- und Nachteilen
  • Scope in und Scope out
  • Slices: Schritte, die einzeln umsetzbar und committbar sind
  • Akzeptanzkriterien: messbar oder eindeutig prüfbar
Artefakt · Arbeitspaket R0-19, geschlossene Testphase, September 2026 — zwei Ausschnitte
Arbeitspaket R0-19, Kopf und Abschnitt 1: Stufe L, live seit 16. September 2026, Anlass, Hypothese, woran man merkt, dass sie stimmt, und Appetite
  1. die Hypothese
  2. woran man merkt, dass sie stimmt
1 · Anlass und Hypothese
Lo-Fi-Mockup des Tor-Bildschirms in drei Zuständen: ohne Code, über den Einladungslink gekommen, Code stimmt nichtArbeitspaket R0-19, Abschnitt 3: drei Wege für das Tor, A und B verworfen, Weg C gewählt, Entscheid vom 10. September 2026
2 · Mockup und Entscheid

Abgeschlossen ist ein Paket erst, wenn seine Akzeptanzkriterien abgehakt sind.

Nicht jeder Auftrag wird so ausführlich geplant: Eine Stufe von S bis L regelt in der Auftaktrunde, wie detailliert das Paket wird. Berührt der Auftrag Datenbank oder Live-Betrieb, gilt Stufe L; reine Hygiene kommt ohne Paket aus. Jedes größere Paket endet mit einem Lehr-Teil in einfacher Sprache.

03

Absicherung im Betrieb — je Merge

Für den Merge auf main habe ich eine Prüfstrecke gebaut.

  1. /finish
  2. Risikostufe
  3. Tests gegen Staging
  4. Linter und Tests
  5. CI
  6. Merge
  7. DB-Migration

Bei bonwise erfassen echte Nutzer ihre Kassenbons, während ich weiterentwickle. Ein Fehler, den ich auf main merge, landet bei ihnen auf dem Handy. Pflicht-Prüfungen vor dem Merge bietet GitHub für ein privates Repository erst im Bezahlplan. Diese Rolle übernimmt bei mir ein eigener Befehl.

Der Befehl heißt /finish. Er stellt drei Fragen: Ändert der Code, wie Daten gespeichert werden? Wer sie sehen darf? Kann er etwas löschen? Aus den Antworten wird eine Risikostufe. Grün heißt: CI genügt. Rot heißt: erst auf der Staging-Umgebung mit eigener Datenbank testen, Nachweis im Pull Request. Fehlt der Nachweis, stoppt der Befehl und fragt mich.

Gemergt wird erst, wenn die CI bestanden ist: Typprüfung, Unit-Tests, Build, Secret-Scan. Automatisch geschieht das nie. Eine Datenbank-Migration läuft getrennt vom Merge, erst auf Staging, dann auf Produktion.

Artefakt · Risikostufen aus dem /finish-Befehl, Auszug unverändert
Risikostufen aus dem /finish-Befehl — drei Fragen entscheiden die Stufe
  1. drei Fragen entscheiden die Stufe

Eine meiner Regeln: Komponenten über 150 Zeilen werden gesplittet. Beim Nachmessen fand ich 36 Dateien darüber; die längste Funktion hatte 294 Zeilen. Bemerkt hatte das niemand, ich lese Code nicht Zeile für Zeile. Heute prüft der Linter die Regeln bei jedem Commit. Den Altbestand hält eine Baseline als Zähler fest, und der darf nur sinken. Steigt er, blockt der Push und nennt die Datei.

Code-Qualität ist ein Messwert, keine Ermessensfrage.

Zählwerk · Linter-Baseline von bonwise je Regel, nachgezeichnet aus dem Repository
Regel5. Sep25. Sep
Funktionen länger als 50 Zeilenmax-lines-per-function195183
Funktionen mit mehr als 12 Verzweigungencomplexity9290
Wenn-dann-Ausdrücke ineinander verschachteltno-nested-ternary8382
Funktionen mit mehr als 3 Parameternmax-params5655
Fehlende Typangabe an der Modulgrenzeexplicit-module-boundary-types130

454 → 425

darf nur sinken

04

Resümee

Claude Code schreibt den Code, die Entscheidungen treffe ich.

Jedes Ergebnis lese ich, bevor es weitergeht: den Plan, das Arbeitspaket, den fertigen Text. Darin finde ich regelmäßig Logikfehler und falsche Annahmen, die später teuer geworden wären.

Claude Code schlägt vor, was es am häufigsten gesehen hat. Überlasse ich ihm jede Weiche, entsteht ein Produkt wie jedes andere. Deshalb bringe ich an jeder Entscheidung meine Erfahrung und meine Meinung ein.

Wer alles dem Modell überlässt, bekommt den Durchschnitt.

Im Deutschen schreibt Claude Code gern abstrakt und verschachtelt. Einfache Sätze muss ich einfordern, und es erklärt gern mehr, als notwendig wäre. Ob eine Lösung im Alltag des Nutzers taugt, etwa das Fotografieren eines langen Kassenbons in der Hand, daran denkt Claude Code selten.

Aus Sicht der Nutzer zu denken, bleibt meine Arbeit.

So sind bonwise und callmeunicorn.de entstanden. Was dabei entschieden wurde und was schiefging, steht auf ihren Produktseiten: bonwisecallmeunicorn.de