Ich habe an einem Wochenende eine echte Produktiv-Website mit KI gebaut. Keine Zeile Code habe ich von Hand geschrieben. Ich hatte erwartet, dass die KI der schwierige Teil wird. Am Ende war ich es. Jedes Problem, das mich Zeit gekostet hat, war im Kern ein menschliches.

Ich glaube, das ist wichtiger als die Frage, welches Werkzeug man nimmt. Die KI hat mir viel Arbeit abgenommen. Entscheiden, prüfen und aufhören musste ich trotzdem selbst.

Über KI-Coding reden gerade alle, meist in der Variante „schau, ich hab ChatGPT eine Todo-App schreiben lassen“. Meine Website ist dagegen ein echtes Projekt. Sie ist zweisprachig und passt ihre Inhalte mit KI an jeden Besucher an. Sie hat einen geschützten Chat, eine Datenbank, die Besucher erfasst, und eine eigene Domain. Dazu kommt SEO, damit Google die Seite findet. Gebaut habe ich sie mit Claude Code. Das ist ein KI-Werkzeug, das nicht nur Text vorschlägt, sondern selbst Dateien ändert und Befehle ausführt.

Die Website entstand aus einem Experiment mit Agenten

Ich hatte nicht vor, eine Website zu bauen. An einem Freitagabend hatte ich gerade KIRA aufgesetzt. Das ist ein persönliches KI-Agenten-System aus sechs spezialisierten Agenten. Jeder hat eine Rolle: Recherche, Strategie, Content, Analyse. Ich wollte herausfinden, wie weit man KI-Orchestrierung als persönliches Werkzeug treiben kann.

Nebenbei las ich einen Substack-Artikel über das agentic web. Gemeint ist die Idee, dass persönliche KI-Agenten dich online vertreten. Sie könnten Fragen beantworten und Interaktionen übernehmen.

Daraus entstand eine Frage: Was, wenn meine Website selbst ein KI-Agent wäre? Statt einer statischen Seite sollte dort eine KI mit den Besuchern sprechen, ihre Fragen beantworten und die Inhalte anpassen. Ich wollte ausprobieren, ob das funktioniert. Die Website sollte die Technologie nicht beschreiben, sondern selbst anwenden.

Ich schrieb Claude: „Ich würde gern meine eigene Website aufsetzen.“ Die Antwort kam zurück: „Verstanden. Ich höre auf, Fragen zu stellen, und fange an zu bauen.“ Drei Tage später hatte ich eine Produktiv-Website. Der Weg von der Idee bis zum Launch war aber alles andere als glatt.

Ein Wochenende kostete 15 Millionen Tokens

So viel hat der Bau gekostet:

  • Zeit: 3 Tage, Freitagabend bis Sonntagnacht. Vielleicht 15 Stunden echte Arbeit, verteilt auf 4 Chats mit Claude Code.
  • Tokens: Rund 15 Millionen Tokens über alle Chats. Tokens sind die Einheit, in der KI-Nutzung abgerechnet wird. Die Menge entspricht ungefähr 50 Romanen an gelesenem und geschriebenem Text.
  • Kosten: Etwa 60-80 Dollar API-Nutzung für Claude Code mit dem Opus-Modell. Das ist weniger, als ein Freelancer pro Stunde nimmt.
  • Code: ~7.000 Zeilen in 93 Dateien und 51 Commits. Ein Commit ist ein gespeicherter Zwischenstand des Codes. Keine Zeile davon habe ich von Hand geschrieben.
  • Ergebnis: Eine Produktiv-Website mit Features, für die ein einzelner Entwickler Wochen bräuchte.

15 Millionen Tokens für eine persönliche Website klingen irre. Verständlich wird die Zahl, wenn du siehst, wie die Arbeit abläuft. Claude liest eine Datei und schlägt eine Änderung vor. Ich sage: „Das stimmt so nicht.“ Claude liest die Datei nochmal und versucht es anders. Für den Kontext, also das, was es sich merken muss, liest es drei weitere Dateien. Dann generiert es neuen Code. Ich sage: „Näher dran, aber mobil sieht es kaputt aus.“ Claude schaut sich den Screenshot an und passt an. Jede solche Runde vervielfacht die Tokens. Die einzelne Antwort ist billig, teuer sind die vielen Runden.

Jede Aufgabe bekommt das Modell, das sie braucht

Ich habe nicht für alles dasselbe Modell benutzt. Die Website läuft auf drei verschiedenen Claude-Modellen. Opus, das größte, hat über Claude Code den Code gebaut. Sonnet aus der Mittelklasse betreibt den Chat und die Personalisierung der Seiten. Haiku, das kleinste, beantwortet einzelne kurze Fragen.

Die Kehrseite habe ich mehrfach gespürt. Claude Code läuft auf Opus, und mit einem Abo erreichst du die Nutzungsgrenzen schnell. Mehrmals wurde ich mitten im Bugfixen abgeschnitten. Ich musste warten, zurückkommen und den Kontext neu erklären. Der unterbrochene Arbeitsfluss hat mich mehr gekostet als die Tokens.

Kleine Fehler brauchten mehrere Anläufe

Das Hamburger-Menü. Auf dem Handy deckte das Navigations-Overlay nicht den ganzen Bildschirm ab. Dahinter war Inhalt sichtbar. Das klingt simpel, der Fix brauchte trotzdem drei Anläufe. Der Grund liegt in CSS: backdrop-blur auf dem übergeordneten Nav-Element erzeugt einen neuen Containing Block. Der bricht die fixed-Positionierung der Kindelemente. Vereinfacht gesagt: Ein Effekt, der den Hintergrund unscharf macht, verhinderte, dass das Overlay den ganzen Bildschirm füllt. Der richtige Fix war, das ganze Nav-Element bildschirmfüllend zu machen, sobald das Menü offen ist. Ein verschachteltes Overlay braucht es dann nicht mehr. Claude fand das erst, nachdem ich mehrfach gesagt hatte, dass es immer noch nicht geht.

Die Sprache im Chat. Die Website ist zweisprachig. Trotzdem antwortete der Chat immer auf Englisch, auch in der deutschen Version. Eine Einstellung namens locale legt die Sprache fest. Sie kam vom Frontend nie im Backend an. Sie existierte in der Komponente, im Hook und in der API-Route. Ein Hook ist ein wiederverwendbares Stück Code. Nur verband nichts diese drei Stellen. Vier Dateien brauchten je eine Zeile. Das ist ein klassischer Integrationsfehler: leicht zu übersehen und leicht zu beheben.

Die DNS-Einträge. Die Domain hatte ich bei Cloudflare gekauft und die Seite auf Vercel deployt, also live geschaltet. Die Haupt-Domain reagierte sofort. Die www-Subdomain tat stundenlang gar nichts. Wie sich herausstellte, verbreitete sich der CNAME-Record in meinem Fall langsamer im Internet als der A-Record. Ich hatte 20 Minuten nach einem eigenen Konfigurationsfehler gesucht, den es gar nicht gab. Die richtige Antwort war schlicht: warten.

Das Admin-Dashboard, dreimal. Die erste Version war eine flache Liste von Datenbankeinträgen, hässlich und schwer zu lesen. Die zweite hatte ein besseres Layout. Die Onboarding-Nachrichten erschienen dort aber als rohe API-Eingabe: VISITOR'S NAME: Theo WHAT THEY TOLD ME ABOUT THEMSELVES: "Tester". Genau so liegen sie in der Datenbank. Die dritte Version gruppiert nach Besuchern und zerlegt alles in lesbare Felder. In den Chat-Nachrichten hebt sie die eigentlichen Fragen hervor.

Ich schaute es mir immer wieder an und sagte: „Das ist es noch nicht.“ Claude baute es immer wieder neu, bis es passte.

Die KI kennt meinen Lebenslauf, aber nicht meine Geschichte

Ich habe Claude detaillierte Markdown-Dateien über meinen Werdegang gegeben. Das sind einfache Textdateien, hier mit Zeitlinien, Projekten, Zahlen und Ergebnissen. Es stand alles darin, was Claude brauchte, und es hat die Dateien auch benutzt. Fakten zu benutzen und die richtige Geschichte zu erzählen, sind aber zwei verschiedene Dinge.

Claude stellte eine echte Leistung falsch dar. Es blähte eine Zahl auf und verschmolz zwei Projekte zu einem. Es behauptete, ich sei seit zwei Jahren in meiner aktuellen Rolle. Dabei ist es nicht mal eins. Und etwas, womit ich gerungen habe, stellte es als glatten Erfolg dar. Die Fakten standen in den Dateien. Die Interpretation war nicht immer das, was ich meinte.

Das meiste habe ich erwischt. Dabei wurde mir klar: KI kann deine Geschichte schreiben. Sie kann aber nicht wissen, welche Version davon wahr ist. Dafür braucht es einen Menschen, der jeden Satz nochmal liest und prüft, ob es wirklich so passiert ist.

Das Profilfoto war 1,4 MB groß

Das Profilfoto war ein PNG mit 1,4 MB, auf einer Website, die schnell sein soll. Beim Entwickeln fiel das niemandem auf, weil lokal alles sofort lädt. Erst das SEO-Audit hat es markiert. Als WebP ist das Bild bei gleicher Qualität 26 KB groß, also 98 Prozent kleiner. Im Rückblick ist so etwas offensichtlich. Beim Bauen habe ich es nicht gesehen.

Sieben Dinge würde ich beim nächsten Mal anders machen

1. Den Umfang vorher festlegen. Die Website wuchs nach und nach. Aus „ich experimentiere mal mit KI-Agenten“ wurde eine „vollständige Produktiv-Website mit Admin-Dashboard, Security-Härtung und SEO-Optimierung“. Im Moment ist das aufregend. Ich habe damit aber Zeit in Features gesteckt, die ich noch nicht brauchte. Ein Admin-Dashboard am ersten Tag, für eine Website mit null Besuchern? Nächstes Mal liefere ich erst den Kern. Weitere Features baue ich, wenn es einen Grund gibt.

2. Die KI nicht das Tempo bestimmen lassen. Claude baut begeistert immer weiter: noch ein Feature, noch ein Refactoring, noch eine Verbesserung. Wann Schluss ist, weiß es nicht. Mehrmals verlor ich mich in einem Nebenthema, weil die KI etwas vorschlug und ich „klar, warum nicht“ sagte. Dass es immer Zeit kostet, merkte ich erst später. Nächstes Mal schreibe ich vor dem ersten Prompt, also der ersten Anweisung an die KI, auf, was zum Umfang gehört und was nicht.

3. Inhalte früher und gründlicher prüfen. Die KI hat die Website-Texte generiert, also Abschnittstitel und Beschreibungen. Das meiste davon habe ich geprüft. Trotzdem rutschte einiges durch, das nicht nach mir klang oder meine Erfahrung leicht verzerrte. Stecken die Inhalte schon in mehreren Komponenten, sind sie schwer zu reparieren. Leichter ist es, sie vorher in einem eigenen Dokument richtig hinzubekommen. Nächstes Mal schreibe ich alle Inhalte in eine einzige Markdown-Datei und prüfe sie gründlich. Erst danach baut die KI die Oberfläche drumherum.

4. Token-Limits einplanen. Ich bin mehrfach an die Grenze meines Abos für Claude Code gestoßen. Es passierte immer im ungünstigsten Moment: mitten im Bugfix, mitten im Deployment, mitten im Security-Review. Bricht ein Chat ab, verliere ich den Kontext und muss ihn von Hand wieder aufbauen. Nächstes Mal teile ich die Arbeit in abgeschlossene Chats. Ich fange nichts an, das drei Stunden am Stück braucht, wenn nach einer Stunde Schluss sein könnte.

5. Von Anfang an mobil testen. Jedes Layout-Problem trat auf dem Handy auf: das Hamburger-Menü, das zentrierte Profilfoto, der Textüberlauf. Ich baute aber am Laptop und schaute auf Laptop-Bildschirme. Nächstes Mal prüfe ich nach jeder sichtbaren Änderung die mobile Ansicht, nicht erst am Ende.

6. Die Modelle früher trennen. Drei Claude-Modelle für verschiedene Aufgaben waren die richtige Entscheidung: Opus für Code, Sonnet für den Chat, Haiku für schnelle Fragen. Dahin kam ich aber durch Versuch und Irrtum. Der Kostenunterschied ist gewaltig. Nächstes Mal lege ich die Aufteilung der Modelle vorab als Teil der Architektur fest.

7. Der KI-Version deiner Geschichte nicht trauen. Das ist für mich der wichtigste Punkt. KI ist hervorragend darin, Text zu erzeugen, der richtig klingt. Sie ist schlecht darin zu wissen, ob der Text deiner Erfahrung treu ist. Jeder Inhalt über mich brauchte deshalb eine sorgfältige Prüfung der Fakten. Habe ich das wirklich gemacht? Waren es wirklich so viele? Ist es so gelaufen? Nächstes Mal behandle ich KI-Texte über mich wie den ersten Entwurf eines Ghostwriters. Er hat gut recherchiert, war aber nicht dabei.

KI schreibt schnell Code, aber sie hört nicht auf

Darin ist KI gut:

  • Boilerplate-Code schnell schreiben, also Standardcode wie API-Routen, Datenbankschemata und Metadaten. Das ist in Sekunden fertig.
  • Details des Frameworks kennen. Die Seite läuft auf Next.js 16. „Wie behandelt Next.js 16 Metadaten für Client-Komponenten?“ Claude weiß es einfach.
  • Stumpfe Refactorings erledigen. x-forwarded-for über 7 API-Routen durch x-real-ip zu ersetzen, hat einen einzigen Prompt gebraucht.
  • Security-Reviews. Die KI fand Timing-Probleme beim Vergleichen von Werten, eine subtile Lücke. Sie fand auch Wege für IP-Spoofing, auf die ich nicht gekommen wäre.
  • Nicht müde werden. In Stunde 6 ist die KI so scharf wie in Stunde 1. Ich bin es nicht.

Darin ist KI nicht gut:

  • Erkennen, wenn etwas falsch aussieht. Bei jedem Layout-Problem war ich es, der auf einen Screenshot schaute und sagte: „Das ist schief.“
  • Entscheidungen über Inhalte treffen. „Soll das eine Geschichte sein oder eine Liste?“ „Ist das zu selbstbeweihräuchernd?“ „Klingt das nach LinkedIn-Sprech?“ Das alles habe ich entschieden.
  • Aufhören. KI fügt immer weiter Features hinzu, verbessert Code und refactort. Wann man liefern muss, weiß sie nicht, ich aber schon.

Fazit

Die Website ist live auf adrianfoehl.com. Sie hat KI-Personalisierung, einen geschützten Chat, zweisprachige Inhalte, Tracking in der Datenbank und ein Admin-Dashboard. Dazu kommen SEO-Optimierung und Security-Härtung. Gebraucht habe ich 15 Millionen Tokens, ~7.000 Zeilen Code, 51 Commits und ein Wochenende. Von Hand geschrieben habe ich null Zeilen.

Gelernt habe ich vor allem etwas anderes: Technologie scheitert nie an der Technologie. Das Hamburger-Menü ging wegen einer CSS-Regel für Containing Blocks kaputt. Der Chat sprach die falsche Sprache, weil ein Parameter fehlte. Das DNS funktionierte nicht, weil sich die Einträge erst verbreiten mussten. Das Admin-Dashboard war hässlich, weil niemand gefragt hatte, was der Nutzer dort sehen muss.

Am Ende war jedes dieser Probleme ein menschliches. Es ging darum zu verstehen, was Nutzer brauchen, und zu wissen, was man baut. Es ging um Entscheidungen, die die KI nicht treffen kann, und um Geschmack. Mit KI habe ich schneller gebaut. Was ich baue, wann ich aufhöre und ob das Ergebnis wirklich gut ist, blieb ganz bei mir.

Der schwierige Teil war deshalb nicht die KI, sondern meine eigenen Entscheidungen. Diese Arbeit konnte mir kein Modell abnehmen.

Was hat bei deinem letzten KI-Projekt mehr Zeit gekostet, der Code oder die Entscheidungen? Und wer entscheidet bei dir, wann es fertig ist?