80/20 Engineering: Wie ich meine Website an einem Wochenende neu aufgebaut habe

Die Kraft der Planung vor dem Coden

80/20 Engineering: Wie ich meine Website an einem Wochenende neu aufgebaut habe

Lassen Sie mich Ihnen ein Geheimnis verraten: Ich habe meine persönliche Website an einem Wochenende nicht neu geschrieben, weil ich besonders schnell im Programmieren bin. Ich habe es getan, weil ich kaum überhaupt programmiert habe.

Stattdessen habe ich die meiste Zeit mit dem verbracht, wovor die meisten Entwickler wie der Teufel das Weihwasser zurückschrecken — Vorbereitung. Dokumentation. Dinge aufschreiben. Und als ich dann endlich meinen Editor öffnete und mit OpenAIs Codex zu arbeiten begann, flog die eigentliche Implementierung vorbei wie ein perfekt einstudierter Zaubertrick.

Dies ist die Geschichte davon, 80 % der Arbeit vor dem Schreiben einer einzigen Codezeile zu erledigen und wie das alles verändert hat.

Warum die Seite neu schreiben?

Meine Website lief auf Qwik v3. Solide Technik, gute Stimmung, aber ich wollte mehr Flexibilität — vor allem beim Routing. Ich wechselte zu React Router im Framework-Modus. Ein kompletter Neuaufbau, kein Refactoring. Neue Architektur, klare Ordnerstruktur, aktualisiertes Styling (hallo Tailwind v4) und eine leere Leinwand.

Doch hierüber war ich überrascht: Das eigentliche Coden dauerte nur etwa 2–3 Stunden. Von Anfang bis Ende. Und es funktionierte beim ersten Versuch.

Was passierte also in den anderen 5 Stunden?

Die 80 %: Codex vorbereiten wie ein Berater ein Pitch-Deck

Der größte Teil der Arbeit floss in den Aufbau eines „Mega-Prompt-Systems“ — nicht in einer schicken Benutzeroberfläche, sondern direkt in meinem Projektordner. Das habe ich getan, bevor ich Codex bat, auch nur eine einzige Komponente zu schreiben:

  • Ich lud die komplette React Router Dokumentation herunter und speicherte sie im Verzeichnis /guides.

  • Dasselbe tat ich für Tailwind CSS v4, indem ich die relevantesten Seiten mit Firecrawl in Markdown umwandelte.

  • Ich schrieb eine PROMPT.md-Datei, die eine Projektübersicht enthielt:

    • „Legacy-Code befindet sich unter /, neuer Code kommt ins /app-Verzeichnis.“
    • „Nur minimale UI, Fokus auf Business-Logik.“
    • „Verwende Tailwind v4. Bleibe im Framework-Modus von React Router.“
    • Und so weiter.

Das war kein Firlefanz. Das war operativer Kontext — so detailliert, wie man ihn einem neuen Teammitglied am ersten Tag geben würde. Codex hat nicht nur geraten, was ich will. Es hatte Dokumentation im Repo. Es hatte genaue Regeln in klarem Englisch. Es hatte Einschränkungen.

Als ich dann endlich tippte:

„Lies PROMPT.md. Migriere zuerst alle Routen zur neuen App.“

Antwortete Codex, als hätte es sein ganzes Leben auf diesen Auftrag gewartet.

Mega Prompts, minimale Halluzinationen

Die Ergebnisse waren unheimlich beeindruckend. Codex hielt sich exakt an die Anweisungen. Es halluzinierte nicht. Es versuchte nicht, Dinge zu erfinden. Die Anweisung „nicht auf UI fokussieren“ wurde respektiert. Die Server-Logik wurde präzise migriert. Die Routen-Konfiguration sah aus, als hätte ich sie selbst geschrieben — wenn ich die Geduld eines Compilers hätte.

Es ging hier nicht nur um „Prompt Engineering“. Es ging darum, Codex auf reale, aktuelle Spezifikationen zu gründen. Keine vage Aufgabenliste. Keine Wunschliste von Features. Sondern strukturierte Eingaben, klare Beispiele und lokaler Zugriff auf die tatsächlich benötigte Dokumentation.

Was kostete Zeit? Nicht der Code

Als das Fundament gelegt war, teilte sich die Arbeit in zwei Phasen:

  1. Codex-Modus – Schnelle, strukturierte, wiederholbare Ausführung. Codex arbeitete Migration, Logik und sogar etwas Layout-Grundgerüst mit nahezu perfekter Genauigkeit ab.
  2. Design-Erkundungsmodus – Langsam, manuell und offen. Das war der menschliche Teil: einen Look wählen, Layouts ausprobieren, mit Komponenten experimentieren. Sobald ich einen funktionierenden visuellen Stil hatte, griff Codex wieder ein, um die Designpatterns zu verbreiten.

Die einzige echte Verzögerung lag darin, dass ich nicht genau wusste, wie etwas aussehen sollte — nicht wie es funktionieren sollte.

Die wahre Erkenntnis: Codex ist nur so gut wie deine Vorbereitung

Dieses Wochenende verstärkte eine Beobachtung, die ich in meiner Arbeit gemacht habe:

Programmieren wird zum einfachen Teil. Planung ist der harte Teil — und der wichtigste.

Bei kleinen bis mittleren Projekten sehe ich die Implementierung jetzt als 20%-Aufgabe. Die 80 % werden vorangestellt: Dokumentation sammeln, abgegrenzte Aufgaben schreiben, kontextuelle Prompts bauen.

Codex gedeiht mit dieser Art von Struktur. Wenn man ihm Mehrdeutigkeit füttert, gibt es Mehrdeutigkeit zurück. Wenn man seine Umgebung aber mit Intention aufbaut — Dokumente, Einschränkungen, klare Beschreibungen — arbeitet es wie ein Senior-Entwickler mit perfektem Gedächtnis und ohne Ego.

Blick nach vorn: Behandle KI wie ein Teammitglied, nicht wie einen Genie

Das Fazit ist einfach: Behandle deine KI-Coding-Tools wie Kollaborateure. Gib ihnen die gleichen Materialien, die du einem echten Entwickler gibst. Bereite den Kontext vor. Sei spezifisch. Sei ausführlich.

Beim nächsten, größeren Projekt werde ich noch weiter gehen:

  • Ein Master-Plan-Dokument, das den gesamten Projektumfang definiert.
  • Einzelne Aufgabenspezifikationen für Teilbereiche oder Komponenten.
  • Ein Satz aus Markdown-Dokumenten und Beispiel-Dateien als lokale Referenzbasis.

Codex braucht keine magischen Worte — es braucht Struktur.

Willst du schneller bauen? Fang damit an, nicht zu bauen. Plane zuerst. Dann prompten Sie zielgerichtet.

Die Entwicklung des Designs: Eine visuelle Reise

Im Laufe der Zeit hat meine Website mehrere Transformationen durchlaufen — jede ein Spiegel neuer Ideen, Werkzeuge und Erkenntnisse. Hier eine kurze visuelle Tour der Entwicklung:

Version 1: Der Ausgangspunkt

Ein minimalistisches, typografieorientiertes Layout. Einfach, klar und funktional.
Ein minimalistisches, typografieorientiertes Layout. Einfach, klar und funktional.

Version 2: Eine definiertere Stimme

Eine überarbeitete Landingpage mit verbesserter Struktur und klarerer Botschaft.
Eine überarbeitete Landingpage mit verbesserter Struktur und klarerer Botschaft.
Eine visuelle Projektübersicht – mit Fokus auf Kundenprojekte, die nicht unter NDA stehen.
Eine visuelle Projektübersicht – mit Fokus auf Kundenprojekte, die nicht unter NDA stehen.
Eine „Bento-Grid“-artige „Über mich“-Seite, die sich visueller Erzählung widmete.
Eine „Bento-Grid“-artige „Über mich“-Seite, die sich visueller Erzählung widmete.

Version 2.1: Anpassungen und Verfeinerung

Eine subtile Weiterentwicklung – Farbverlauf-Hintergrund, verbessertes Layout und allgemeine Politur nach einem Jahr Feedback.
Eine subtile Weiterentwicklung – Farbverlauf-Hintergrund, verbessertes Layout und allgemeine Politur nach einem Jahr Feedback.

Version 3: Die Qwik-Ära

Ein kompletter Architekturrelaunch, basierend auf Qwiks Performance-first-Philosophie.
Ein kompletter Architekturrelaunch, basierend auf Qwiks Performance-first-Philosophie.
Dark-Theme-Unterstützung und aktualisiertes Post-Layout und Header.
Dark-Theme-Unterstützung und aktualisiertes Post-Layout und Header.
Neue Kacheln für relevante Vorschläge.
Neue Kacheln für relevante Vorschläge.

Version 4: Fokussierte Einfachheit mit Remix

Ein neues Landing-Erlebnis mit Vollbild-Animation und ultraklarem Layout.
Ein neues Landing-Erlebnis mit Vollbild-Animation und ultraklarem Layout.
Generative Visuals, gesteuert durch Seed-Werte wie Seitentitel – maßgeschneidert, sauber, einzigartig.
Generative Visuals, gesteuert durch Seed-Werte wie Seitentitel – maßgeschneidert, sauber, einzigartig.
Die bisher minimalistischste Typografie – nur Inhalt, perfekt komponiert.
Die bisher minimalistischste Typografie – nur Inhalt, perfekt komponiert.

Jede Version brachte neue Erkenntnisse darüber, was eine Website effektiv macht — nicht nur in Ästhetik, sondern in Klarheit, Benutzbarkeit und Wartbarkeit. Die Designreise spiegelte die Entwicklungsreise wider: bewusst, iterativ und immer nach vorne schauend.

Categories