Leonardo entsteht: 5 von 7 Phasen in einem Tag

An einem Morgen begonnen. Am selben Tag lief Phase 5.5 durch. Das ist der aktuelle Stand von Leonardo.

Nicht die romantisierte Version, in der alles reibungslos läuft und jede Entscheidung brillant war. Sondern die tatsächliche: mit den Abzweigungen, den verworfenen Ideen und den Momenten, in denen Teile zusammengewachsen sind, die ich noch nicht für fertig gehalten hatte. Echtes Vibe Coding: Claude Code in der einen Hand, Notion-Dokumentation in der anderen, Ollama im Hintergrund.

Leonardo soll ein lokaler KI-Coding-Assistent für Windows (und später Mac) werden. Kein Cloud-Zwang, keine API-Kosten. Für EPU, die Websites, Tools und kleine Anwendungen brauchen, aber keine Entwicklungsabteilung dahinter haben. Fertig ist er noch nicht. Aber er nimmt Form an, und diese Form ist es wert, dokumentiert zu werden.

Das Problem, das Leonardo löst

Ich berate EPU und kleine Unternehmen. Das Muster ist immer dasselbe: Der Bedarf an digitalen Tools ist da. Das Budget für Entwickler nicht. Und die Cloud-Alternativen fressen sich durch Abrechnungen, die niemand richtig überblickt.

ChatGPT oder Claude für Code-Generierung zu nutzen ist eine Option. Aber wer sensible Geschäftsdaten, Preislisten oder interne Prozesse in einen Prompt steckt, schickt diese Informationen auf fremde Server. Wer in Österreich als EPU tätig ist und das regelmäßig macht, spielt mit dem DSGVO-Feuer. Nicht hypothetisch, sondern praktisch und konkret.

Dazu kommt ein anderes Problem, das seltener diskutiert wird: Die gängigen Coding-Assistenten sind für Entwickler gemacht. Copilot, Cursor, Windsurf. Sie setzen voraus, dass der Nutzer weiß, was ein Commit ist. Oder was TypeScript von JavaScript unterscheidet. EPU, die eine Angebotsseite brauchen oder einen einfachen Kalkulator für ihre Kunden, wollen das nicht lernen. Die wollen ein Ergebnis.

Was fehlt: ein Werkzeug, das lokal läuft, kein Konto braucht, keine monatliche Rechnung produziert und trotzdem KI-gestützt arbeitet. Eines, das mit einer Textbeschreibung startet und mit einer funktionierenden Website endet. Ohne Terminal-Kenntnisse, ohne Git, ohne Cloud-Abhängigkeit.

Das ist das Ziel. Und seit heute früh ist klar: Es ist machbar.

Was unter der Haube steckt

Kurz zur Klarheit, weil diese Kombination nicht selbstverständlich ist: Leonardo ist eine native Desktop-Applikation für Windows, gebaut mit Electron als Shell. Das Frontend läuft auf React 19 mit TypeScript, gebaut mit electron-vite für kurze Dev-Zyklen. Das Styling kommt von Tailwind CSS v4 mit einem eigenen Design-System: Vinci. Renaissance Gold auf Obsidian Noir, Inter als einzige Schriftfamilie in drei Gewichten. Schlicht, aber nicht beliebig.

Die KI kommt von Ollama, lokal installiert auf dem Rechner des Nutzers. Das empfohlene Modell ist qwen2.5-coder:7b, weil es auf 16 GB RAM vernünftig läuft und für Code-Generierung optimiert ist. Wer 32 GB hat, kann auf deepseek-coder-v2:16b hochschalten. Wer nur 8 GB hat, landet bei einem 1.5B-Modell. Das erkennt Leonardo automatisch.

Ich mache das nicht als Konzern. Ich mache das als EPU, der genau weiß, was andere EPU brauchen. Und das ist ein Tool, das auf dem eigenen Rechner läuft, ohne einen Cent laufende Kosten zu erzeugen, sobald es eingerichtet ist.

Sieben Phasen, fünfeinhalb davon abgeschlossen

Leonardo ist in sieben klar abgegrenzten Phasen geplant. Heute Morgen habe ich mit Phase 1 begonnen. Der aktuelle Stand nach einem langen Bautag: Phase 5.5 ist durch, Phase 6 und 7 stehen noch aus.

Hier ist, was in diesem einen Tag entstanden ist.

Phase 1: Das Grundgerüst steht

Das Repo ist aufgesetzt mit electron-vite, React 19 und TypeScript. Tailwind CSS v4 konfiguriert, das Vinci-Design-System implementiert: Farbtokens, Schrift-Skala, Komponenten-Tokens. Electron Main mit frameless Window und nativer Window-Control-Bar. Ein Screen-Router mit vier Ziel-Screens. Der Dev-Server läuft auf Port 5173, die App startet.

Ein Designsystem wurde zuerst verworfen. Das Studio Noir-Konzept hat im Browser gut ausgesehen, in Electron aber merkwürdig gewirkt. Also neu: Vinci. Der Name ist kein Zufall.

Phase 2: Das Backend denkt

Sieben neue Module. Das klingt abstrakt, ist aber sehr konkret: Hardware-Detection liest RAM, CPU und OS aus und gibt eine Modellempfehlung. Der Settings Store schreibt persistent in userData/settings.json. Das Workspace-System verwaltet Projekte mit sicherem Path-Resolving: safeResolve() blockt Path-Traversal-Angriffe über ..-Escapes.

Die Modellempfehlung folgt einer einfachen, aber praktisch erprobten Logik: 8 GB RAM bekommt ein 1.5B-Modell zugewiesen, 16 GB landen bei qwen2.5-coder:7b, 24 GB bei der 14B-Variante, 32 GB oder mehr bei deepseek-coder-v2:16b. Das ist keine Marketingangabe, sondern eine Einschätzung, die auf tatsächlichem Betrieb basiert. Ein 7B-Modell auf 8 GB shared Memory produziert Latenz, die kein Nutzer tolerieren will.

Das ist der Punkt, an dem es interessant wird. Der XML Action Parser ist streaming-fähig. Leonardo bekommt vom LLM keine fertige Ausgabe und verarbeitet sie dann. Es liest den Token-Stream, parst Actions heraus, schreibt Dateien, gibt Feedback zurück. Live. Das ist der Unterschied zwischen einem Chatbot und einem Werkzeug.

Die IPC-Schicht verdrahtet alle Kanäle zwischen Electron Main und dem React-Frontend über Preload. Kein direkter Node-Zugriff aus dem Renderer, keine Sicherheitslücken durch nodeIntegration: true. Der TypeScript-Type LeonardoAPI definiert die vollständige Schnittstelle, damit der Frontend-Code nie raten muss, was verfügbar ist.

Das Abstraktions-Interface IModelBackend trennt Ollama vom Rest. Wenn später MLX für macOS kommt, ändert sich der Rest der Applikation nicht. Das ist kein Over-Engineering, das ist die Voraussetzung dafür, dass eine Entscheidung von heute nicht die Architektur von morgen blockiert.

Phase 3: Der Setup-Wizard läuft durch

Vier Schritte: Welcome mit Hardware-Tabelle, Verzeichnis-Picker mit nativem Dialog, Ollama-Check mit Auto-Ping und Retry-Button, Modellauswahl mit RAM-basiertem Empfehlungs-Badge. Dann der Pull: NDJSON-Stream von Ollama, über IPC direkt in den React-State, als Live-Fortschrittsanzeige mit Bytes und Prozent.

Erster echter End-to-End-Test: Wizard durchgelaufen, lokales LLM geladen. Das ist der Moment, in dem aus Komponenten ein Produkt wird.

Phase 4: Der Home Screen als Ausgangspunkt

Fünf Templates stehen zur Auswahl: Landing Page, Portfolio, Kalkulator, Dashboard, Präsentation. Jedes Template hat einen maßgeschneiderten System-Prompt mit Action-Protokoll. Daneben eine freie Textarea für Custom-Builds mit Ctrl+Enter als Shortcut. Klick auf ein Template erstellt automatisch ein Projekt und navigiert zum Build-Screen mit den Session-Daten.

Sprachauswahl war geplant, wurde auf nach v1 verschoben. Richtige Entscheidung. Scope-Creep im ersten Release ist der häufigste Grund, warum Projekte nicht fertig werden.

Phase 4.5: Profil und Logo

Das ist der Teil, den ich am meisten unterschätzt habe, der dann aber sofort Sinn ergeben hat. Ein EPU baut mit Leonardo zum Beispiel eine Landing Page. Das LLM weiß nicht, wie das Unternehmen heißt, welches Logo es hat, welche Kontaktdaten relevant sind.

Also: Profil-Datenstruktur in den Settings (Name, Tagline, Anschrift, Kontakt, Logo-Upload). Der Logo-Picker akzeptiert PNG, JPG, SVG und WebP, speichert in userData/profile/logo.{ext}. Beim Build wird der Profil-Block automatisch an den System-Prompt gehängt. Das Logo wird automatisch ins Projektverzeichnis kopiert. Das LLM bekommt den Hinweis, es via <img src="logo.png" /> einzubinden.

Wenn das Profil leer ist, erscheint auf dem Home Screen ein Hinweis-Banner. Kein unsichtbares Feature, das niemand findet.

Phase 5: Der Build-Screen als Kern-Canvas

Das ist das Herzstück. Chat-Panel links, Canvas rechts, 60/40-Split. Drei Tabs im Canvas: Vorschau, Code, Dateien. Der Code-Viewer hat Zeilennummern und Syntax-Highlighting für HTML, CSS und JavaScript. Der Datei-Baum ist klickbar. Multi-turn Chat mit dem Modell funktioniert.

Die Live-Vorschau läuft über ein leonardo://-Custom-Protocol in einem iframe und lädt sich nach jedem File-Write automatisch neu. Kein manuelles Refresh, kein separater Browser.

Hier ist, was ich dabei gelernt habe: Das Custom-Protocol ist notwendig, weil Electron-iframes keine file://-URLs aus dem Renderer-Prozess laden können, ohne dass man webSecurity: false setzt. Das ist eine Sicherheitseinstellung, die man nicht leichtfertig anfasst. Das leonardo://-Protocol umgeht dieses Problem sauber: Leonardo registriert es im Main-Prozess, serviert Dateien aus dem Workspace-Verzeichnis und der iframe läuft in einer kontrollierten Sandbox. Kleines Detail, große Auswirkung auf die Sicherheitsarchitektur.

Eine Entscheidung, die erst in dieser Phase gefallen ist: Das Format für die LLM-Ausgabe. Ursprünglich war ein XML-Action-Format geplant. Das funktioniert gut für große Modelle. Für 7B-Modelle, die auf durchschnittlicher EPU-Hardware laufen, war der Format-Overhead zu hoch. Also gewechselt auf fenced Code-Blocks mit Pfadangabe. Das Modell schreibt, Leonardo liest, der Nutzer sieht das Ergebnis. Einfacher, stabiler, besser für die Zielgruppe.

Die Templates wurden in dieser Phase neu strukturiert: Format-Regeln stehen jetzt oben im System-Prompt, mit konkretem Beispiel, bevor der inhaltliche Teil beginnt. Das klingt selbstverständlich, war es aber nicht. 7B-Modelle haben ein kürzeres effektives Aufmerksamkeitsfenster als 70B-Modelle. Was am Ende eines langen System-Prompts steht, wird unzuverlässig befolgt. Also kommt das, was Leonardo produzieren soll, zuerst.

Phase 5.5: Kontext, den das Modell braucht

Das ist der Teil, der aus einem Spielzeug ein produktives Werkzeug macht. Ein 7B-Modell hat kein Wissen über aktuelle Steuersätze, laufende Lohnnebenkosten oder branchenspezifische Preislisten. Es weiß, was es gelernt hat, und das ist endlich.

Die Lösung: zwei Felder auf dem Home Screen unter einer aufklappbaren „Erweitert“-Section.

Hintergrund-Infos: Eine Textarea. Der EPU trägt ein, was das LLM über das Projekt wissen muss. Zahlen, Texte, Kontextinformationen. Diese werden direkt in den System-Prompt injiziert.

Recherche-Quellen: URLs. Leonardo lädt die Seiten vor der Generation, extrahiert den relevanten Plain-Text (Scripts, Styles und Navigation werden entfernt, HTML-Entities werden decoded), kürzt auf 6.000 Zeichen pro Quelle und injiziert den Text ebenfalls in den System-Prompt. Eine Status-Anzeige informiert während des Fetch-Vorgangs.

Das ist kein RAG-System im technischen Sinn. Das ist zweckdienliche Informationslogistik: Das Modell bekommt genau das, was es braucht, um die Aufgabe zu erledigen.

Was noch kommt

Zwei Phasen fehlen. Phase 6 ist der Projekte-Screen: Verwaltung, Verlauf, Wiederöffnen abgeschlossener Projekte. Wer morgen ein Projekt weiterbauen will, das er gestern angefangen hat, muss das ohne Reibungsverlust tun können. Das ist kein Feature, das man ans Ende schiebt. Das ist die Voraussetzung dafür, dass Leonardo tatsächlich im Arbeitsalltag landet.

Phase 7 ist Distribution: .exe, Installer, kein Code-Signing in v1. Code-Signing für Windows kostet Zeit, Zertifikate und Prozesse, die eine erste Version unnötig blockieren würden. Wer Leonardo installiert, wird einen Sicherheitshinweis von Windows Defender bekommen, weil der Publisher unbekannt ist. Das ist lösbar mit einem Klick auf „Trotzdem ausführen“. Keine elegante Lösung, aber eine ehrliche. Für v2 ist das anders geplant.

macOS-Support mit MLX als Backend kommt nach v1. MLX ist Apples Framework für effiziente Inferenz auf Apple-Silicon-Chips. Ein M2 mit 16 GB unified Memory ist schneller als ein Windows-Laptop mit derselben RAM-Menge, weil keine Datenkopie zwischen CPU und GPU stattfindet. Das macht MLX zur richtigen Entscheidung für macOS, und das Abstraktions-Interface aus Phase 2 stellt sicher, dass dieser Wechsel den Rest der App nicht berührt. Linux lasse ich weg, hab ich nicht, kann ich also nicht testen.

Was Vibe Coding hier tatsächlich bedeutet

Das ist kein AI-generierter Code, den ich überflogen habe. Das ist Vibe Coding im praktischen Sinn: Ich kenne die Architektur, ich kenne jede Entscheidung, ich habe jede Phase durchgeplant und dokumentiert. Claude Code hat die Implementierung massiv beschleunigt. Aber die Entscheidungen, die Architektur, die Produktlogik: die kommen von mir.

Was ich dabei konkret gemacht habe: Vor jeder Phase eine klare Spezifikation. Nicht ein vages „Bau mir einen Build-Screen“, sondern: Chat-Panel links, Canvas rechts, 60/40-Split, drei Tabs, klickbarer Datei-Baum, Streaming-Caret, Multi-turn. Das ist der Unterschied. Claude Code implementiert präzise, was man ihm gibt. Unklarheit im Input produziert Code, der nicht passt und dreimal umgebaut wird.

Das kostet Zeit, die man in den ersten Minuten einer Phase investiert, und spart Stunden in der Mitte davon.

Ich beobachte das seit Monaten in der täglichen Arbeit als KI-Berater: Der häufigste Irrtum über Vibe Coding ist, dass es Programmierkenntnis ersetzt. Das tut es nicht. Es multipliziert, was man einbringt. Wer mit einem vagen Konzept anfängt, bekommt vagen Code. Wer mit klarer Architektur, konkreten Phasen und durchdachten Entscheidungen arbeitet, bekommt ein Produkt.

Und noch etwas, das ich heute bestätigt habe: Der Rhythmus aus Bauen, Testen, Dokumentieren ist kein Overhead. Die Notion-Seite für Leonardo ist parallel zum Code entstanden. Jede Phase hat einen Build-Log. Das zwingt dazu, Entscheidungen in Worte zu fassen, bevor man weitermacht. Das erkennt Widersprüche, bevor der Code sie einbaut.

Das ist keine neue Methodik. Das ist konsequentes Handwerk.

Leonardo ist noch kein fertiges Produkt. Aber die Architektur steht, der Build-Loop funktioniert, und der Weg zu v1 ist klar. Das zählt.

Häufige Fragen zu lokalen KI-Assistenten für EPU