← Zurück

Tech & KI

Software-Architektur für Vibe Coders: Die 7 Prinzipien die du brauchst

März 2026 · 8 Min. Lesezeit · Max Götte

Vibe Coding erzeugt funktionierenden Code. Aber funktionierender Code ohne Struktur ist wie ein Haus ohne Fundament — es steht, bis du ein Stockwerk draufsetzt. 7 Architektur-Prinzipien verhindern dass dein Projekt nach zwei Wochen unbewohnbar wird. Du brauchst dafür keinen Informatik-Abschluss — nur Disziplin beim Ordnung halten.

Frequently Asked Prompts

Architektur-Review
Analysiere die Dateistruktur und Code-Organisation dieses Projekts. Zeige mir wo die Architektur Probleme verursachen wird wenn das Projekt wächst. Schlage eine bessere Struktur vor.
Aufteilen
Diese HTML-Datei hat 800 Zeilen. Teile sie in logische Module auf: shared CSS in eine Datei, JavaScript in Module, wiederverwendbare Komponenten extrahieren. Vanilla JS, kein Framework.
Naming
Überprüfe alle Dateinamen, CSS-Klassen und JavaScript-Variablen auf konsistente Benennung. Schlage ein einheitliches System vor und benenne um.
I

7 Architektur-Prinzipien für Vibe Coders

  1. Eine Datei, eine Aufgabe — Jede Datei hat genau eine Verantwortung. style.css für Layout, nav.js für Navigation, hero.js für die Hero-Section. Wenn eine Datei über 200 Zeilen wächst: aufteilen. Faustregel: Wenn du scrollen musst um den Anfang zu sehen, ist die Datei zu lang.
  2. Ordner = Denkmodell — Deine Ordnerstruktur ist dein mentales Modell des Projekts. Für statische Sites: posts/ für Artikel, components/ für wiederverwendbare Teile, assets/ für Bilder. Wenn du eine Datei nicht in 3 Sekunden findest, stimmt die Struktur nicht.
  3. Shared statt kopiert — CSS-Variablen, Farben, Spacing, Fonts: einmal definieren, überall referenzieren. Eine style.css mit CSS Custom Properties statt Farb-Hex-Werte in jeder Datei. Wenn du einen Farbwert ändern willst und 15 Dateien anfassen musst: die Architektur ist kaputt.
  4. Namenskonventionen durchhalten — Entscheide einmal: kebab-case für Dateien (hero-section.html), camelCase für JavaScript (heroSection), BEM oder einfache Klassen für CSS (.hero-title). Mische nie. Schreibe die Konvention in deine CLAUDE.md.
  5. Separation of Concerns — HTML für Struktur, CSS für Aussehen, JavaScript für Verhalten. Kein Styling per JavaScript (außer Animationswerte). Keine Logik in HTML-Attributen. Jede Technologie macht genau ihren Job.
  6. Progressive Enhancement — Die Seite funktioniert ohne JavaScript. JavaScript fügt Extras hinzu: Animationen, interaktive Elemente, dynamische Inhalte. Wenn JavaScript fehlschlägt, sieht der Nutzer trotzdem den Content. Das ist kein Idealismus — es ist Lighthouse-Performance.
  7. Dokumentiere Entscheidungen, nicht Code — Eine README.md mit 5 Zeilen die erklären was das Projekt ist, wie man es startet und welche Konventionen gelten. Plus: eine CLAUDE.md die der KI den Kontext gibt. Besser als 200 Code-Kommentare die niemand liest.
II

Beispiel: Ordnerstruktur für eine Vanilla-Website

projekt/ ├── index.html ← Homepage ├── style.css ← Shared Styles (CI, Layout, Reset) ├── CLAUDE.md ← Regeln für die KI ├── README.md ← Was ist das Projekt ├── posts/ │ ├── erster-artikel.html │ └── zweiter-artikel.html ├── components/ │ ├── nav.js ← Navigation (scroll, mobile menu) │ ├── reveal.js ← Scroll-Animationen │ └── progress-bar.js ← Lese-Fortschritt ├── assets/ │ ├── hero.webp │ └── favicon.ico └── fonts/ ├── dm-sans-400.woff2 └── source-serif-400.woff2

Keine node_modules. Kein Build-Schritt. git push und Vercel deployt. Jede Datei ist per Name auffindbar, jeder Ordner hat einen klaren Zweck.

Warum das bei Vibe Coding wichtiger ist als sonst

Bei handgeschriebenem Code baust du die Struktur während du programmierst. Bei Vibe Coding generiert die KI Code in der Reihenfolge deiner Prompts — ohne Rücksicht auf Gesamtarchitektur. Du bist der Architekt. Claude ist der Bauarbeiter. Wenn du keinen Plan gibst, baut er ein Haus aus lauter Türen.

Häufige Fragen

Muss ich die Architektur vorher planen oder wächst sie mit?

Plane die Grundstruktur vorher (Ordner, Naming, Shared CSS). Details wachsen mit. Umstrukturieren nach 20 Dateien ist schmerzhaft. Umstrukturieren nach 3 Dateien ist trivial. Früh anfangen.

Kann Claude die Architektur für mich planen?

Ja — mit dem richtigen Prompt: "Schlage eine Ordnerstruktur für [Projektbeschreibung] vor. Vanilla JS, kein Framework. Erkläre warum jeder Ordner existiert." Dann übernimmst du die Struktur in deine CLAUDE.md.

Ab wann ist ein Projekt zu gross für Vanilla JS?

Wenn du mehr als 10 JavaScript-Dateien hast die sich gegenseitig importieren, oder wenn State-Management über 3+ Komponenten nötig wird. Der Vanilla vs. Next.js Vergleich hat die genaün Schwellenwerte.

Zum Thema: Web Dev for Vibe Coders — Der komplette Guide 2026

Quellen

Martin Fowler — Patterns of Enterprise Application Architecture (Prinzipien)

Anthropic — Claude Code Best Practices (CLAUDE.md)