Wir bauen unsere Website mit Claude. Die ersten fünf Lektionen.

Die neue westwerk.ac wird nicht “von Claude gebaut”. Sie wird mit Claude gebaut — das ist ein wichtiger Unterschied, und ich werde gleich erklären, was ich damit meine. Aber zuerst die Zahlen, damit der Kontext stimmt:

In drei Wochen sind etwa 100 Pull Requests entstanden. Jeder davon ist von einer Code-Session geschrieben worden, in der ich (Cheffe) Kontext gegeben, Richtung vorgegeben und Reviews gemacht habe, aber die eigentlichen Tastendrücke kamen aus einem Modell. Mein Anteil am Output ist im einstelligen Prozentbereich. Mein Anteil an den Entscheidungen ist nahe 100 Prozent.

Das ist eine neue Art zu arbeiten. Wir sind nicht die ersten, die das machen, aber wir sind eines der ersten Teams, das es am eigenen Marketing-Auftritt macht und darüber öffentlich schreibt. Hier sind fünf Lektionen aus den ersten drei Wochen.

1. Der Engpass ist nicht mehr die Hand, sondern der Kopf

Die offensichtliche Lektion zuerst: ich tippe nicht mehr Code, der weniger als drei Stunden Denkarbeit braucht. Ich schreibe einen Prompt, lese das Ergebnis, sage was passt und was nicht, und der Code ist da.

Das klingt nach Beschleunigung, ist aber etwas anderes. Was beschleunigt wird, ist das Schreiben. Was nicht beschleunigt wird — und sogar mehr Aufmerksamkeit braucht als vorher — ist das Denken vorher. Ein vager Prompt wird zu vager Code. Ein präziser Prompt wird zu präzisem Code. Der Unterschied zwischen “OK” und “richtig” ist fast immer im Prompt, nicht im Modell.

Praktische Konsequenz: ich verbringe jetzt mehr Zeit damit, vor der Code-Session aufzuschreiben, was ich eigentlich will. In freien Sätzen. Mit dem “warum”. Mit den Anti-Beispielen. Mit Verweisen auf bereits gebaute Stellen, die als Muster dienen sollen.

Das ist ironischerweise das, was gute Software-Engineering-Praxis schon immer war: Anforderungen klar machen, bevor man tippt. Nur war der Anreiz früher schwach, weil das Tippen sowieso passieren musste. Jetzt ist der Anreiz stark: ein klares Briefing spart 30 Minuten an Iteration. Ein unklares Briefing kostet 30 Minuten, in denen das Modell schöne, aber falsche Sachen produziert.

2. Die Skill-Verschiebung: weg von “kann ich das schreiben” hin zu “erkenne ich das, wenn ich es sehe”

Die zweite Lektion ist subtiler und beunruhigt mich gelegentlich, deswegen schreibe ich sie auf.

Beim klassischen Coden ist die zentrale Frage: kann ich das? Kann ich diese Abfrage formulieren, kann ich diese Schnittstelle implementieren, kann ich diesen Build-Schritt einrichten. Das ist eine produktive Frage, weil sie zu Lernen führt.

Beim Prompt-Driven Development ist die zentrale Frage anders: erkenne ich das, wenn ich es sehe? Wenn das Modell mir 200 Zeilen TypeScript liefert, kann ich auf den ersten Blick sagen, ob die Argumenttypen sinnvoll sind, ob das Error-Handling die richtigen Fälle abdeckt, ob die Performance-Charakteristik passt? Wenn ja: gut, ich akzeptiere oder ich präzisiere. Wenn nein: das Modell hat mir gerade einen blinden Fleck präsentiert, und ich weiß es nicht.

Die Skill, die dadurch gefährdet ist: das muskelhaft-eingeübte Schreiben von Standard-Code. Routing, Schema-Validierung, CRUD-Endpunkte. Das schreibt das Modell jetzt für mich, und ich werde im nächsten Jahr nicht mehr so viel Übung darin haben.

Die Skill, die dadurch gestärkt wird: das kritische Lesen von Code. Architektur-Verständnis. Das Erkennen, wann ein Pattern unangemessen ist, auch wenn der Code “funktioniert”.

Die zweite Skill ist die schwerere. Sie wird mit der Erfahrung gebaut. Sie kann nicht abgekürzt werden. Und sie ist genau das, was diese Art zu arbeiten verlangt.

Für ein erfahrenes Team ist das ein gutes Tauschverhältnis. Für ein Junior-Team — bin ich mir nicht sicher. Das ist eine offene Frage, die ich noch beantworten muss.

3. Pull Requests sind das Einheitsmaß, nicht Tickets

Wir haben unsere Arbeitsweise um Pull Requests herum organisiert — nicht um Tickets, nicht um Sprints, nicht um “wir basteln zusammen am Code”.

Eine Code-Session = ein Pull Request = eine zusammenhängende Idee. Das heißt:

• Eine PR ist klein genug, dass ein Review in 5 Minuten geht.
• Eine PR ist groß genug, dass sie eine Geschichte erzählt, nicht nur eine Datei verändert.
• Eine PR hat eine Beschreibung, die in zwei Sätzen das Warum erklärt — die wirklich gute PRs der letzten Wochen erklären auch, was sie nicht getan haben und warum.

Was wir damit verhindern: die berüchtigten 2.000-Zeilen-PRs, die niemand mehr review-en kann, und die genauso berüchtigten 12-Zeilen-PRs, die in 30 Sekunden mergen, aber keinen Zusammenhang erzählen.

Was wir damit gewinnen: jede Code-Session hat einen klaren Anfang und ein klares Ende. Wir verlieren nichts in “halben Branches”. Und der Bitbucket-PR-Verlauf wird zu einer lesbaren Chronik dessen, was die Site geworden ist — etwas, das wir bei Westwerk vorher nie so diszipliniert geführt haben.

Wer in unsere Bitbucket-Pull-Request-Liste schaut, kann die Genese der neuen Seite Stück für Stück nachvollziehen. Das ist auch ein Build-in-public-Asset — nicht nur die Artikel hier sind die Geschichte, sondern auch die PR-Liste.

4. Das Modell macht keine Architektur-Entscheidungen. Es hilft, sie zu verfeinern.

Eine Sache, die wir früh klar gemacht haben: das Modell entscheidet keine grundsätzlichen Architektur-Sachen. Die Entscheidungen — Astro statt Next, Cloudflare statt Vercel, MDX statt CMS, cookielose Analytics — kamen aus Konzeptphase-Diskussionen zwischen Menschen, dokumentiert in unserem Decisions-Log, bevor irgendeine Code-Session begonnen hat.

Das ist wichtig, weil das Modell sehr gut darin ist, innerhalb eines gewählten Stacks zu navigieren. Es kann mir in Sekunden eine Astro-Komponente schreiben, die alle Konventionen unseres Projekts beachtet. Was es aber nicht zuverlässig kann: zu wissen, ob Astro überhaupt die richtige Wahl für unser Problem ist. Das verlangt Markt-Verständnis, Team-Kapazität, Hosting-Anforderungen, regulatorischen Kontext (EU-Hosting, DSGVO). Das sind keine Code-Fragen.

Daher unser Arbeitsmuster: Menschen entscheiden, was gebaut wird. Das Modell hilft, es zu bauen. Das ist mehr als nur eine Aufgabentrennung — es ist eine Disziplin, die wir in jedem Onboarding-Gespräch mit dem Modell wieder herstellen müssen. Wenn ich anfange, das Modell um Architektur-Empfehlungen zu fragen, baue ich mir eine Welt, in der das Modell die schwierigen Sachen entscheidet, und ich nicke ab. Das wollen wir nicht.

5. Vertrauen ist eine Frage der Beobachtung, nicht der Theorie

Die letzte Lektion ist methodologisch und eher persönlich.

Bevor wir damit angefangen haben, war meine Skepsis groß. “Kann man eine ernsthafte Production-Site mit einem Modell bauen, ohne dass alle zwei Tage etwas Unsinniges deployed wird?” Die Theorie sagt: “kommt drauf an, wie man es macht”. Die Theorie hilft nicht beim Loslegen.

Was geholfen hat: klein anfangen, viel beobachten. Wir haben mit kleinen, abgeschlossenen Tasks begonnen — die Scaffold-Bootstrap. Die Tailwind-Tokens. Die ersten Seiten. Und nach jeder PR habe ich mich gefragt: “Wäre das, was ich gerade gemergt habe, von einem Junior-Dev gekommen — würde ich das durchwinken oder zurückschicken?”

Die Antwort war öfter “durchwinken” als ich erwartet hatte. Nicht weil der Code überlegen ist, sondern weil das Modell die Konventionen unseres Projekts schnell aufnimmt und konsequent anwendet. Eine Junior-Dev würde im Tutorial-Code schlampig sein, das Modell ist es nicht.

Was nicht funktioniert: blindes Vertrauen. Es gibt klar definierte Stellen, an denen das Modell schwächelt — neuere oder eher seltene APIs, präzise CSS-Layouts, manchmal komplexe Zustands-Verwaltung. An diesen Stellen muss man dichter dran sein. Nach drei Wochen hat das Team ein Gefühl dafür, wo die Modell-Sessions zuverlässig sind und wo nicht.

Das ist keine fertige Anleitung. Es ist eher: Vertrauen ist nichts, was man sich vorher überlegt, sondern was man sich erarbeitet, PR für PR.

Was die nächsten Wochen zeigen werden

Die fünf Lektionen oben sind Beobachtungen, keine Best Practices. Wir sind drei Wochen tief in einer Arbeitsweise, die wahrscheinlich noch ein Jahr braucht, bis sie wirklich verstanden ist. Die nächsten Wochen werden zeigen:

• Hält die Disziplin, wenn die einfachen Teile (Scaffold, Inhalte) fertig sind und es um Calculator, Formular-Integrationen, A/B-Testing geht?
• Was passiert beim Wartungs-Modus nach Launch — kann man Sites, die so entstanden sind, ohne Modell-Sessions weiter pflegen, oder bauen wir Abhängigkeit auf?
• Wie überträgt sich das auf Kunden-Projekte? Wir machen das gerade für uns selbst, weil wir hier alle Risiken tragen. Wann ist es reif genug, um es auch für Kund:innen-Arbeit anzubieten?

Wir werden über all das schreiben, wenn die Antworten kommen. Bis dahin: die neue Website wird in den nächsten Wochen Stück für Stück da sein, und du wirst hier mitlesen können, was wir auf dem Weg gelernt haben — auch das, was nicht funktioniert hat.