Ich habe an einem Wochenende eine echte Produktiv-Website mit KI gebaut, null Zeilen Code von Hand. Die Lektion hat mich überrascht: Ich hatte erwartet, dass die KI der schwierige Teil wird. Am Ende war ich es.

Über KI-Coding reden gerade alle, meist in der Variante "schau, ich hab ChatGPT eine Todo-App schreiben lassen". Ich schreibe hier stattdessen die ehrliche Version eines echten Projekts auf: zweisprachig, mit KI-gestützter Personalisierung, geschütztem Chat, einer Datenbank, die Besucher erfasst, eigener Domain und SEO (damit die Seite bei Google gefunden wird). Gebaut habe ich sie mit Claude Code, dem KI-Werkzeug, das nicht nur Text vorschlägt, sondern selbst Dateien ändert und Befehle ausführt. Hier kommt, was funktioniert hat, was kaputtging, und was ich beim nächsten Mal anders machen würde.

Wie es anfing, nämlich nicht wie geplant

Ich hatte nicht vor, eine Website zu bauen.

An einem Freitagabend hatte ich gerade KIRA aufgesetzt, ein persönliches KI-Agenten-System aus sechs spezialisierten Agenten mit je einer Rolle, Recherche, Strategie, Content, Analyse. Ich wollte herausfinden, wie weit man KI-Orchestrierung als persönliches Werkzeug treiben kann. Irgendwo in dem Prozess las ich einen Substack-Artikel über das agentic web, also die Idee, dass persönliche KI-Agenten dich online vertreten, Fragen beantworten und Interaktionen übernehmen könnten.

Da landete der Gedanke: Was, wenn meine Website selbst ein KI-Agent wäre? Statt einer statischen Seite mit Lebenslauf eine Website, auf der eine KI, die meinen Werdegang kennt, mit Besuchern spricht, ihre Fragen beantwortet und ihre Inhalte anpasst. Eine Website, die beweist, dass ich die Technologie verstehe, indem sie die Technologie ist.

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, aber der Weg von der Idee bis zum Launch war alles andere als glatt.

Die Zahlen

Volle Transparenz, was das gekostet hat:

  • Zeit: 3 Tage. Freitagabend bis Sonntagnacht. Vielleicht 15 Stunden echte Arbeit, verteilt auf 4 Chats mit Claude Code.
  • Tokens: Rund 15 Millionen Tokens (die Abrechnungseinheit für KI-Nutzung) über alle Chats. Das entspricht ungefähr 50 Romanen an gelesenem und geschriebenem Text.
  • Kosten: Etwa 60-80 Dollar API-Nutzung für Claude Code (Opus-Modell). Weniger, als ein Freelancer pro Stunde nimmt.
  • Code: ~7.000 Zeilen in 93 Dateien. 51 Commits (gespeicherte Zwischenstände des Codes). Null Zeilen 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 klingt irre, bis du siehst, wie die Arbeit abläuft. Claude liest eine Datei, schlägt eine Änderung vor, ich sage "das stimmt so nicht", es liest die Datei nochmal, versucht es anders, liest drei weitere Dateien für Kontext (was es sich merken muss), generiert neuen Code, ich sage "näher dran, aber mobil sieht es kaputt aus", es schaut sich den Screenshot an und passt an. Jede solche Runde vervielfacht die Tokens. Die Intelligenz ist billig, die Iteration teuer.

Drei Gehirne, ein Projekt

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 Seiten-Personalisierung, und Haiku, das kleinste, beantwortet einzelne kurze Fragen. Jede Aufgabe bekommt das Gehirn, das sie verdient.

Die Kehrseite habe ich mehrfach zu spüren bekommen: Claude Code läuft auf Opus, und mit einem Abo erreichst du die Nutzungsgrenzen schnell. Mehrmals war ich mitten im Flow, beim Bugfixen, wurde abgeschnitten, musste warten, zurückkommen und den Kontext neu erklären. Dieses Momentum zu verlieren kostet mehr als Tokens.

Wo es chaotisch wurde

Der Hamburger-Menü-Vorfall. Auf dem Handy deckte das Navigations-Overlay nicht den ganzen Bildschirm ab, dahinter war Inhalt sichtbar. Klingt simpel, oder? Der Fix brauchte drei Anläufe, weil backdrop-blur auf dem übergeordneten Nav-Element in CSS einen neuen Containing Block erzeugt, und der bricht fixed-Positionierung bei den Kindelementen. Der eigentliche Fix war, das gesamte Nav-Element bildschirmfüllend zu machen, sobald das Menü offen ist, ganz ohne verschachteltes Overlay. Claude fand das erst, nachdem ich mehrfach gesagt hatte, es gehe immer noch nicht.

Das Chat-Sprachproblem. Die Website ist zweisprachig, und der Chat antwortete trotzdem immer auf Englisch, auch in der deutschen Version. Der Grund: Eine Einstellung namens locale (welche Sprache) erreichte nie vom Frontend das Backend. Sie existierte in der Komponente, im Hook (einem wiederverwendbaren Code-Stück) und in der API-Route, aber nichts verband sie. Vier Dateien brauchten je eine Zeile: ein klassischer Integrationsfehler, leicht zu übersehen, leicht zu beheben.

DNS-Hölle. Die Domain hatte ich bei Cloudflare gekauft und auf Vercel deployt (live geschaltet), und die Haupt-Domain reagierte sofort. Die www-Subdomain tat stundenlang gar nichts. Es stellte sich heraus, dass sich CNAME-Records langsamer im Internet verbreiten als A-Records, und ich hatte 20 Minuten damit verbracht, nach einem eigenen Konfigurationsfehler zu suchen, den es gar nicht gab. Die richtige Antwort lautete 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, aber die Onboarding-Nachrichten erschienen als rohe API-Eingabe, VISITOR'S NAME: Theo WHAT THEY TOLD ME ABOUT THEMSELVES: "Tester", weil sie genau so in der Datenbank liegen. Die dritte gruppiert nach Besuchern, zerlegt alles in lesbare Felder und hebt in den Chat-Nachrichten die eigentlichen Fragen hervor.

Ich schaute es immer wieder an und sagte "das ist es noch nicht", und Claude baute es immer wieder neu, bis es passte.

Die KI kennt meinen Lebenslauf. Sie kennt meine Geschichte nicht.

Ich habe Claude detaillierte Markdown-Dateien (einfache Textdateien) über meinen Werdegang gegeben: Zeitlinien, Projekte, Zahlen, Ergebnisse, alles, was es brauchte, und es hat sie auch benutzt. Aber Fakten benutzen und die richtige Geschichte erzählen sind zwei verschiedene Dinge.

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

Das meiste habe ich erwischt. Aber mir wurde dabei 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 fragt, ob das wirklich so passiert ist.

Das Profilbild, das 1,4 MB kostete

Das Profilfoto war ein 1,4-MB-PNG auf einer Website, die schnell sein soll. Beim Entwickeln fiel das niemandem auf, weil lokal alles sofort lädt, und erst das SEO-Audit hat es markiert. Konvertiert zu WebP: 26 KB bei gleicher Qualität, also 98 Prozent kleiner. Es ist die Sorte Ding, die im Rückblick offensichtlich ist und beim Bauen unsichtbar.

Gelernt: Was ich anders machen würde

1. Den Umfang vorher festlegen. Die Website wuchs organisch von "ich experimentiere mal mit KI-Agenten" zu "vollständige Produktiv-Website mit Admin-Dashboard, Security-Härtung und SEO-Optimierung". Im Moment ist das aufregend, aber ich habe damit 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 und baue Features dann, 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, und weiß nicht, wann Schluss ist. Mehrmals fand ich mich in einem Kaninchenloch wieder, weil die KI etwas vorschlug und ich "klar, warum nicht" sagte, ohne zu merken, dass es immer Zeit kostet. Nächstes Mal schreibe ich vor dem ersten Prompt (was du der KI tippst) auf, was im Umfang ist und was nicht.

3. Inhalte früher und gründlicher prüfen. Die KI hat Website-Texte generiert, Abschnittstitel, Beschreibungen, und ich habe das meiste geprüft. Trotzdem rutschte einiges durch, das nicht nach mir klang oder meine Erfahrung subtil verzerrte. Inhalte zu reparieren, nachdem sie in mehrere Komponenten verwoben sind, ist schwerer, als sie vorher in einem eigenen Dokument richtig hinzubekommen. Nächstes Mal schreibe ich alle Inhalte in eine einzige Markdown-Datei, prüfe sie gründlich, und lasse die KI danach die Oberfläche drumherum bauen.

4. Token-Limits einplanen. Ich bin mehrfach an die Abo-Grenze von Claude Code gestoßen, immer im ungünstigsten Moment: mitten im Bugfix, mitten im Deployment, mitten im Security-Review. Wenn ein Chat abbricht, verliere ich den Kontext und muss ihn von Hand wieder aufbauen. Nächstes Mal teile ich die Arbeit in abgeschlossene Chats und 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 war ein Mobil-Problem, das Hamburger-Menü, das zentrierte Profilfoto, der Textüberlauf, und ich baute am Laptop und schaute auf Laptop-Bildschirme. Nächstes Mal prüfe ich nach jeder visuellen Änderung mobil, nicht am Ende.

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

7. Der KI-Version deiner Geschichte nicht trauen. Das ist der große Punkt. KI ist hervorragend darin, Text zu erzeugen, der richtig klingt, und schlecht darin zu wissen, ob der Text deiner Erfahrung treu ist. Jeder Inhalt über mich brauchte eine sorgfältige, faktische Lektüre: Habe ich das wirklich gemacht? Waren es wirklich so viele? Ist es so gelaufen? Nächstes Mal behandle ich KI-generierte persönliche Inhalte wie den ersten Entwurf eines Ghostwriters, der gut recherchiert hat, aber nicht dabei war.

Worin KI gut ist, und worin nicht

KI ist gut darin:

  • Boilerplate-Code (Standardcode) schnell zu schreiben. API-Routen, Datenbankschemata, Metadaten. In Sekunden fertig.
  • Framework-Details zu kennen. "Wie behandelt Next.js 16 (das Framework, auf dem die Seite läuft) Metadaten für Client-Komponenten?" Claude weiß es einfach.
  • Stumpfe Refactorings zu erledigen. x-forwarded-for zu x-real-ip über 7 API-Routen ändern? Ein Prompt.
  • Security-Reviews. Die KI fand Timing-Probleme beim Vergleichen (eine subtile Lücke im Werte-Vergleich) und IP-Spoofing-Vektoren, auf die ich nicht gekommen wäre.
  • Nicht müde zu werden. In Stunde 6 ist die KI so scharf wie in Stunde 1. Ich nicht.

KI ist nicht gut darin:

  • Zu erkennen, wenn etwas falsch aussieht. Jedes Layout-Problem war ich, der auf einen Screenshot schaute und sagte "das ist schief".
  • Content-Entscheidungen zu treffen. "Soll das eine Geschichte sein oder eine Liste?" "Ist das zu selbstbeweihräuchernd?" "Klingt das nach LinkedIn-Sprech?" Alles ich.
  • Aufzuhören. KI fügt immer weiter Features hinzu, verbessert Code, refactort, und weiß nicht, wann man liefern muss. Ich schon.

Die eigentliche Lektion

Die Website ist live auf adrianfoehl.com, mit KI-Personalisierung, geschütztem Chat, zweisprachigen Inhalten, Datenbank-Tracking, Admin-Dashboard, SEO-Optimierung und Security-Härtung. 15 Millionen Tokens, ~7.000 Zeilen Code, 51 Commits, ein Wochenende, null Zeilen von Hand.

Was ich wirklich gelernt habe, ist aber etwas anderes: Technologie scheitert nie an der Technologie.

Das Hamburger-Menü ging wegen einer CSS-Containing-Block-Regel kaputt, der Chat sprach wegen eines fehlenden Parameters die falsche Sprache, das DNS funktionierte wegen Propagations-Timing nicht, und das Admin-Dashboard war hässlich, weil niemand gefragt hatte, was der Nutzer hier eigentlich sehen muss.

Jedes einzelne Problem war am Ende ein menschliches: verstehen, was Nutzer brauchen, wissen, was man baut, Entscheidungen treffen, die die KI nicht treffen kann, und Geschmack haben.

Mit KI habe ich schneller gebaut. Zu wissen, was man baut, wann man aufhört, und ob das Ergebnis wirklich gut ist, blieb ganz bei mir.

Genau das sage ich Organisationen jeden Tag: KI ist nicht der schwierige Teil. Du bist es.