somatic-web.de ist ein Vibe Coding Projekt. Kein Photoshop-Mockup, kein Elementor-Drag-and-Drop, kein Theme-Customizer-Marathon. Stattdessen: ein Claude Projekt mit MCP-Anbindung an WordPress, fünf klar definierte Phasen — und am Ende eine Website, die steht.
Ich erzähle hier, wie das funktioniert hat. Nicht als Anleitung zum Nachmachen, sondern als Bericht von jemandem, der seit 17 Jahren IT macht und trotzdem überrascht war, wie gut das läuft.
Was Vibe Coding eigentlich heißt
Der Begriff kommt von Andrej Karpathy, Anfang 2025. Die Idee: Du beschreibst in natürlicher Sprache, was du willst — und eine KI generiert den Code. Du steuerst die Richtung, nicht jede Zeile.
Karpathy meinte damit ursprünglich Wegwerf-Projekte. Schnell was zusammenklicken, schauen ob’s funktioniert, fertig. Aber das ist nicht, was ich damit gemacht habe.
Ich habe Vibe Coding als Methode genutzt. Mit Struktur. Mit einem 5-Phasen-System, das ich in einem Claude Projekt hinterlegt habe. Analyse, Setup, Seitenbau, Feinschliff, Übergabe — jede Phase mit klaren Regeln, Templates und Qualitätskontrollen. Das ist kein „fully give into the vibes“. Das ist Prompt Engineering mit Projektmanagement-Disziplin.
Warum Claude und nicht Cursor, Bolt oder Lovable
Kurze Antwort: Weil Claude direkt mit meinem WordPress sprechen kann.
Über das Model Context Protocol — kurz MCP — verbindet sich Claude mit dem WordPress-Backend. Nicht über Umwege, nicht über Copy-Paste. Direkt. Claude kann Posts erstellen, Seiten anlegen, Medien verwalten, Taxonomien pflegen. Alles über eine strukturierte API-Verbindung.
Das ändert den gesamten Workflow. Bei den meisten Vibe Coding Tools bekommst du Code ausgespuckt, den du dann irgendwo einfügst. Bei mir generiert Claude den HTML-Block und kann ihn direkt ins WordPress schieben. Der Unterschied zwischen „hier ist dein Code“ und „der Code ist live“ — das ist halt ein anderer Film.
Das Projekt-Setup: Fünf Phasen, ein System
Ich habe Claude nicht einfach gefragt: „Bau mir eine Website.“ Ich habe ein komplettes Projekt-System aufgebaut, das Claude als Arbeitsanweisung bekommt. Fünf Markdown-Dateien, jede für eine Phase:
Phase 1 — Analyse. Claude analysiert die Projektbeschreibung, identifiziert Lücken, recherchiert selbstständig Branchenstandards und Wettbewerber. Was fehlt, wird erst eigenständig gelöst — und nur bei echten Lücken nachgefragt. Am Ende steht ein technischer Plan mit Farbpalette, Fonts, Seitenstruktur und Plugin-Liste.
Phase 2 — Setup. Claude erstellt die Tailwind-Konfiguration, die Google Fonts Einbindung und eine Schritt-für-Schritt-Anleitung für WordPress. Jeder Schritt mit exaktem Pfad im Backend: „Design → Customizer → Zusätzliche Scripts“. Kein Raten, kein Suchen.
Phase 3 — Seitenbau. Hier passiert das Eigentliche. Claude baut jede Seite als Sammlung von Custom HTML-Blöcken. Jede Sektion ist nummeriert, kommentiert und so formatiert, dass sie als einzelner Gutenberg-Block eingefügt wird. Kein Page Builder nötig. Gutenberg + Custom HTML + Tailwind — das reicht.
Phase 4 — Feinschliff. QA-Checklisten für Navigation, Responsive Design, SEO, Barrierefreiheit, Datenschutz. Claude liefert die Prüfliste, ich arbeite sie ab. Probleme melde ich zurück, Claude liefert korrigierte Blöcke.
Phase 5 — Übergabe. Komplette Dokumentation. Technischer Aufbau, installierte Plugins, Wartungshinweise, Anleitungen für Textänderungen und Bildtausch. Alles in Markdown, alles im Projektordner.
Warum Elementor tot ist
Ja, das ist eine steile These. Ich stehe dazu.
Elementor, Divi, WPBakery — diese Page Builder hatten ihre Zeit. Sie haben WordPress-Nutzern ermöglicht, Websites visuell zusammenzubauen, ohne Code zu schreiben. Das war 2018 ein gutes Argument.
Heute ist es keins mehr.
Erstens: Performance. Elementor lädt ein eigenes CSS-Framework, eigenes JavaScript, eigene Render-Engine. Jede Seite schleppt Hunderte Kilobyte an Code mit, den sie nicht braucht. Meine Tailwind-Lösung? Ein CDN-Script und eine handvoll Utility-Klassen. Der PageSpeed-Score spricht für sich.
Zweitens: Abhängigkeit. Wer Elementor nutzt, ist an Elementor gebunden. Die Inhalte stecken in proprietären Shortcodes und Datenstrukturen. Deaktivierst du das Plugin, siehst du: nix. Meine Sektionen sind reines HTML mit Tailwind-Klassen. Deaktiviere Tailwind — und du hast immer noch lesbaren, semantischen HTML-Code.
Drittens — und das ist der eigentliche Punkt: KI-Tools wie Claude können HTML und Tailwind. Nativ. Ohne Plugin, ohne Abstraktion. Claude schreibt besseren, saubereren Tailwind-Code als jeder Page Builder generiert. Weil es auf Millionen von Tailwind-Projekten trainiert wurde. Claude ist der Page Builder.
Warum also noch ein Plugin dazwischenschalten, das Performance kostet, Abhängigkeit schafft und am Ende schlechteren Code produziert als das, was Claude direkt liefert?
Die MCP-Verbindung: Wo es spannend wird
MCP — Model Context Protocol — ist das Stück Infrastruktur, das aus einem Chat-Tool einen echten Arbeits-Assistenten macht. Anthropic hat MCP als offenen Standard veröffentlicht, und es gibt inzwischen MCP-Server für alles Mögliche: Google Calendar, Gmail, Slack, Salesforce — und eben WordPress.
Für somatic-web.de habe ich einen MCP-Server direkt an meine WordPress-Installation angebunden. Claude kann darüber:
- Posts und Seiten erstellen und aktualisieren
- Medien hochladen und verwalten
- Taxonomien und Kategorien pflegen
- Plugin-Listen abrufen
- Optionen lesen und setzen
Das klingt technisch, ist es auch. Aber die Auswirkung ist praktisch: Ich beschreibe, was ich will. Claude baut es. Und es landet direkt dort, wo es hingehört.
Kein Export, kein Import, kein Zwischenschritt. Vom Prompt zur fertigen Seite — in einem Workflow.
Was ich dabei gelernt habe
Drei Dinge, die ich vorher nicht erwartet hätte:
Die Projekt-Dateien sind wichtiger als die Prompts. Einzelne Prompts bringen dich nirgendwohin. Was den Unterschied macht, sind die System-Anweisungen — die Project Instructions, die Claude bei jedem Gespräch im Kontext hat. Mein 5-Phasen-System ist im Grunde ein digitaler Projektleiter, der Claude bei der Stange hält. Ohne das wäre das Ergebnis ein Flickenteppich.
Claude braucht klare Grenzen, nicht kreative Freiheit. Klingt kontraintuitiv. Aber je enger ich die Leitplanken gesetzt habe — welches Theme, welches CSS-Framework, welche Sektions-Architektur, welche Dateistruktur — desto besser wurde das Ergebnis. Claude blüht auf, wenn es einen klaren Rahmen hat und sich darin austoben kann. Unbegrenzte Freiheit führt zu generischem Output.
Der Mensch bleibt Architekt. Vibe Coding heißt nicht: KI macht alles. Es heißt: Ich entscheide was gebaut wird und wiedie Struktur aussieht. Claude entscheidet, wie die einzelnen Sektionen im Detail umgesetzt werden. Das ist Arbeitsteilung, nicht Ersetzung. Ich bin der Architekt, Claude ist das Bauunternehmen.
Die Website als Arbeitsnachweis
somatic-web.de ist kein Showcase-Projekt im luftleeren Raum. Es ist meine eigene Website. Mein Portfolio, meine Visitenkarte, mein erster Eindruck bei potenziellen Kunden und Arbeitgebern.
Dass ich sie so gebaut habe — mit einem Claude Projekt, über MCP, ohne Page Builder — ist selbst der beste Beweis dafür, dass diese Methode funktioniert. Nicht nur für Prototypen. Nicht nur für Wegwerf-Projekte. Für echte Websites, die im echten Internet stehen und echte Menschen überzeugen sollen.
GeneratePress als minimales Base-Theme. Tailwind CSS via CDN für das Styling. Gutenberg mit Custom HTML-Blöcken als Editor. Vanilla JavaScript wo nötig. Und Claude als der Motor, der alles zusammenbaut.
Das ist kein Tech-Stack der Zukunft. Das ist der Tech-Stack von jetzt.
Du willst wissen, wie so ein Projekt für dein Unternehmen aussehen könnte? Schreib mir.