Bis hier weißt du: ein Artefakt ist Code, der nur bei dir läuft. Ein Produkt ist Code, der ohne dich läuft. SaaS-Baukästen machen schöne Artefakte mit URL, aber die wohnen in fremdem Garten. Bleibt die Frage: was tust du stattdessen?
Die kurze Antwort: Du nutzt das richtige Werkzeug (Claude Code) und eine Methode. Werkzeug alleine reicht nicht. Genauso wie ein guter Hammer alleine kein Haus baut — er braucht einen Bauplan und einen Bauleiter, der weiß, in welcher Reihenfolge welche Wand kommt.
Dieser Kurs liefert beides: das Werkzeug und die Methode. Die Methode heißt becoss Coding Framework. In dieser Lektion lernst du, was das ist und warum es der entscheidende Hebel zwischen „mit Claude Code rumtippen" und „strukturiert ein Produkt bauen" ist.
Was passiert ohne Framework
Du hast Claude Code installiert. Du tippst „bau mir die Anmelde-Seite für meine App". Claude legt los — fragt nach, schreibt Code, du committest. Das Login funktioniert.
Eine Woche später willst du eine Premium-Funktion dazubauen. Du tippst „bau mir den Bezahl-Flow mit Stripe". Claude fragt: „welcher Auth-Provider, wo lebt die User-Tabelle, wie heißen die Routen?" — und weil du seit zwei Wochen nichts dazu aufgeschrieben hast, beantwortest du es ungenau. Claude rät, baut etwas, das nicht zu deiner Login-Logik passt. Du fixt nach. Du merkst zwei Tage später, dass die User-Email mal als email, mal als user_email heißt — je nachdem, in welcher Datei.
Das ist nicht Claude Code, das ist auch nicht du — das ist das, was passiert, wenn niemand die Architektur des Projekts kennt. Du hast einen guten Hammer. Aber keinen Bauplan.
Was ein Framework ist (und was nicht)
Ein Framework ist drei Dinge zusammen:
- Eine Methode — eine Reihenfolge, in der du arbeitest. Erst spec'en, dann reviewen, dann bauen, dann reviewen. Nicht: direkt drauflos und in der Mitte korrigieren.
- Werkzeuge, die zu der Methode passen — vorgefertigte Skills (
/requirements,/architecture,/frontend,/backend,/qa,/deploy), die jeden Schritt der Methode ausführbar machen. - Konventionen, die du nicht jedes Mal neu treffen musst — welche Datei wohin gehört, wie Specs aussehen, wann du committest, wie ein guter PR-Titel aussieht.
Ein Framework ist drei Dinge nicht:
- Kein Code-Generator — es schreibt nicht für dich, es strukturiert, was du mit Claude zusammen baust.
- Kein Drag-and-Drop — kein UI, kein „App in 20 Minuten zusammenklicken". Wenn du das willst, schau in die letzte Lektion zurück.
- Keine Magie — es nimmt dir das Denken nicht ab. Es nimmt dir das Improvisieren ab.
Reihenfolge: die, die dir gerade einfällt.
Reihenfolge in 6 Wochen: nicht mehr nachvollziehbar.
Wenn jemand anders einsteigt: drei Tage Onboarding plus Stirnrunzeln.
Bei Bug: du suchst alle Stellen, an denen das Pattern auftauchen könnte.
Reihenfolge: die, die dir gerade einfällt.
Reihenfolge in 6 Wochen: nicht mehr nachvollziehbar.
Wenn jemand anders einsteigt: drei Tage Onboarding plus Stirnrunzeln.
Bei Bug: du suchst alle Stellen, an denen das Pattern auftauchen könnte.
Reihenfolge: requirements → architecture → frontend → backend → qa → deploy.
Reihenfolge in 6 Wochen: immer noch genau die.
Wenn jemand anders einsteigt: liest die Spec-Files, ist nach 30 Minuten produktiv.
Bei Bug: du weißt, in welchem Modul du suchst.
Was das becoss Coding Framework konkret liefert
Im Vollzugang lädst du ein Starter-Kit-Repo runter. Drin steckt:
- Acht Standard-Skills als fertige Slash-Commands —
/requirements,/architecture,/frontend,/backend,/qa,/seo,/deploy,/help. Jeder mit klarem Job. - Drei Subagents für die kontextfressenden Aufgaben (Frontend-Build, Backend-Build, QA-Audit) — sie arbeiten parallel in eigenem Speicher, dein Haupt-Chat bleibt schlank.
- Templates für
PROJECT_CONTEXT.md(was bauen wir),CLAUDE.md(wie bauen wir),features/PROJ-X.md(was bauen wir konkret als Nächstes). - Konventionen als kurze, ausgelagerte Rule-Files — wie heißen Files, wie sehen Commits aus, wie strukturierst du Components.
- CI-Setup und Production-Patterns, die du nicht selbst herleiten musst.
Das ist kein „mehr Magie als Claude Code alleine". Es ist Claude Code plus eine vorgedachte Methode, die du nicht jedes Mal neu erfinden musst.
Wofür Methode wichtiger ist als Werkzeug
Eine Erfahrung, die in der Coding-Community immer wieder kommt: Leute wechseln von ChatGPT auf Claude Code, hoffen, dass dadurch alles besser wird. Es wird ein bisschen besser. Aber das wahre Plus kommt erst, wenn die Reihenfolge stimmt — wenn du nicht mehr „mal eben"-Prompts feuerst, sondern strukturiert arbeitest.
Drei konkrete Patterns, die Methode wichtiger machen als Tool:
- Spec-first. Eine Idee in 2 Sätze gedrückt vs. eine Spec mit User-Story und Acceptance-Criteria — das Modell liefert in beiden Fällen Code. Nur in einem Fall passt der Code zu deinem realen Projekt. Methode liefert die Specs.
- Reviewbarkeit. Mit Spec ist „passt das?" eine Vergleichsoperation. Ohne Spec ist es ein Bauchgefühl-Vergleich. Methode liefert die Vergleichsbasis.
- Reproduzierbarkeit. Dieselbe Spec in einer Session am Montag und in einer Session am Freitag ergibt vergleichbaren Code. Ohne Spec sind das zwei verschiedene Apps. Methode liefert die Stabilität.
Die ehrliche Gegenposition
Es gibt einen Fall, wo Methode Overkill ist: eine Wegwerf-Idee in 30 Minuten. Wenn du dir was zusammentippst, was du danach nicht mehr brauchst, ist die Spec-Investition Verschwendung. Schreib einen Prompt, lass dir was bauen, fertig.
Faustregel: Sobald du eine zweite Session zu der Idee aufmachst, lohnt sich Methode. Bis dahin ist Improvisieren effizienter.
Dieser Kurs ist für alles ab der zweiten Session — alles, was länger lebt oder von mehreren Personen angefasst wird. Wegwerf-Skripts sind eine andere Welt, und das ist auch in Ordnung.