Kann OpenCode Designarbeit tatsächlich bewältigen?
Ja — mit einer ästhetischen Skill, einem Design-System und echten Referenzbildern im Kontext erzeugt OpenCode produktionsreife, responsive UI und kann diese im Browser überprüfen. Da es modellunabhängig ist, nutzen Sie das jeweils beste Modell für Frontend-Arbeit. Ohne diesen kuratierten Kontext tendiert es zu einem generischen Look — genau diese Lücke schließt OpenDesign.
Welches Modell sollte ich mit OpenCode für Design verwenden?
Welches Ihnen am besten gefällt — OpenCode ist über models.dev anbieterunabhängig, sodass Sie Anthropic, OpenAI, Google, OpenRouter oder lokale Modelle hinter demselben Workflow betreiben und jederzeit wechseln können. Die Qualität des Design-Outputs hängt weit stärker von Ihrer Skill, Ihrem Design-System und Ihren Referenzen ab als vom Modell allein.
Wird OpenDesign vom OpenCode-Team (SST) entwickelt?
Nein. OpenDesign ist ein unabhängiges Open-Source-Projekt, das OpenCode als Agent integriert. Es ergänzt OpenCode um eine lokal-first, offene Skill- und Design-System-Bibliothek.
Brauche ich ein spezielles Abonnement, um mit OpenCode zu designen?
Nein — OpenCode ist BYOK. Sie bringen Ihren eigenen API-Key des Modellanbieters mit, und OpenDesign leitet Ihre Zugangsdaten niemals über einen Proxy. Es gibt keine Anbieterbindung.
OpenCode, Codex oder Claude Code für Frontend-Design?
Alle sind stark, und viele Teams kombinieren sie. Der Vorteil von OpenCode liegt darin, vollständig Open-Source und modellunabhängig zu sein; Codex glänzt bei delegierten, sandboxed Builds; Claude Code ist bekannt für konkrete, codebase-bewusste Design-Entscheidungen. OpenDesign lässt Sie Agents wechseln, ohne Ihren Design-Workflow zu ändern.
Was OpenCode genau ist
OpenCode ist ein quelloffener KI-Coding-Agent, der für das Terminal gebaut wurde und vom Team hinter SST (Anomaly Innovations) gepflegt wird. Er liest dein Repository, führt Befehle aus, bearbeitet Dateien und kommuniziert mit einem großen Sprachmodell — doch anders als herstellergebundene Agenten bringt er kein eigenes Modell mit. Du richtest ihn auf den Anbieter und das Modell deiner Wahl aus und bringst deinen eigenen Schlüssel mit.
Er läuft als Terminal-UI (TUI), ergänzt um eine Desktop-App und IDE-Erweiterungen auf derselben Engine. Unter der Haube nutzt er eine Client/Server-Architektur, sodass der Agent, der die Arbeit erledigt, von der Oberfläche entkoppelt ist, über die du ihn steuerst. Zwei integrierte Agenten — build und plan — lassen sich mit der Tabulatortaste umschalten.
Modellagnostisch: Modelle und Anbieter stammen aus models.dev, einem offenen Katalog. Du konfigurierst sie in opencode.json mit einem provider/model-id-String und kannst Anbieter deaktivieren, die nicht geladen werden sollen — so läuft derselbe Design-Workflow auf Anthropic, OpenAI, Google, OpenRouter, lokalen Modellen und mehr.
Instruktionsdatei: OpenCode liest eine AGENTS.md-Datei in deinem Projekt (der herstellerübergreifende Standard, ebenfalls kompatibel mit CLAUDE.md) für Projektregeln — der natürliche Ort, um deine Design-Konventionen zu hinterlegen. Führe /init aus, um eine zu erzeugen.
Erweiterbar: Er unterstützt LSP-Integration, MCP-Server, Themes, Tastenbelegungen und eigene Befehle, dazu teilbare Sitzungslinks für die Zusammenarbeit.
Maintainer: SST / Anomaly Innovations (Open-Source-Projekt)
Zugangsdaten: dein(e) eigener(n) API-Schlüssel des Modellanbieters — BYOK, kein Vendor-Lock-in
Lizenz: MIT, Open Source
Warum ein offener Agent für jedes Modell zu Designarbeit passt
OpenCode hat kein einzelnes „Design-Modell“ wie ein Hersteller-Agent — und genau darum geht es. Weil er modellagnostisch und offen ist, kannst du denselben Design-Workflow auf dem Modell laufen lassen, das gerade im Frontend am stärksten ist, es später wechseln oder auf ein lokales Modell zurückfallen, ohne dein Setup zu ändern.
Doch die Modellwahl allein bringt keinen Geschmack. Wie jeder Coding-Agent erzeugt OpenCode generische UI, solange du ihm keine Vorgaben machst. Gutes Design-Output entsteht aus drei Zutaten, die du lieferst.
Ein Design-System: Echte Tokens, Primitive und Konventionen, die der Agent wiederverwendet, damit der Output zu einer Marke passt, statt auf ein generisches Aussehen zurückzufallen.
Eine ästhetische Skill: Eine kuratierte Skill, die echten Geschmack durchsetzt — zurückhaltende Bewegung, markenorientierte Hierarchie, höchstens zwei Schriftarten und eine Akzentfarbe — und den Agenten dazu bringt, sich vor dem Bauen auf eine Richtung festzulegen.
Konkrete Referenzen: Tatsächliche Referenzbilder und mehrere Zustände (Desktop und Mobile, Hover, Empty, Loading), nicht ein einziges Hero-Bild.
Geschmack entsteht aus drei Zutaten, die du lieferst: einem Design-System, einer Skill und echten Referenzbildern — unabhängig davon, welches Modell du laufen lässt.
Die Lehre: OpenCode gibt dir Modellfreiheit, doch Geschmack kommt weiterhin aus einem kuratierten Design-Kontext. OpenDesign bündelt genau diese Zutaten, weshalb die beiden zusammenpassen — beide sind quelloffen und local-first (mehr dazu weiter unten).
OpenCode für Design von Grund auf einrichten
Die Einrichtungsreihenfolge: installieren → authentifizieren (dein Anbieterschlüssel) → AGENTS.md konfigurieren → eine Skill hinzufügen → in einem echten Browser prüfen.
Deine Design-Regeln festhalten: Lege deine Tokens, Primitive und Konventionen in AGENTS.md ab (oder in einer DESIGN.md, auf die von dort verwiesen wird), damit der Output zu einer Marke passt, statt auf ein generisches Aussehen zurückzufallen. Die Option instructions in opencode.json kann über Globs auf zusätzliche Regeldateien zeigen.
Ein leistungsfähiges Modell wählen: Weil OpenCode modellagnostisch ist, nimm den Anbieter bzw. das Modell, das derzeit im Frontend für den Design-Durchlauf am stärksten ist — und lass den Rest deines Workflows unverändert.
Nutze den Abschnitt zum aktuellen Setup für Befehle und versionsspezifische Details, die sich ändern können.
# 1. Install OpenCode
curl -fsSL https://opencode.ai/install | bash
# or: npm i -g opencode-ai@latest
# or: brew install sst/tap/opencode
# 2. Start the TUI in your project, then authenticate your provider
opencode # then run /login and pick your provider + paste your key
# 3. Generate project context
opencode # inside your project, run /init to create AGENTS.md
# 4. Pick your model (any provider, via models.dev)
# set "provider/model-id" in opencode.json or switch in the TUI
# 5. Add an MCP server (optional, e.g. for design handoff)
# configure it under the "mcp" key in opencode.json
Historisches Befehlsbeispiel aus dem vorherigen Leitfaden; prüfe die aktuelle Syntax in der verlinkten Herstellerdokumentation.
Screenshot-zu-UI-Workflow in OpenCode
Die wirkungsvollste Design-Schleife mit einem Agenten besteht darin, ein Referenzbild in funktionierende, responsive UI zu verwandeln und zu iterieren, bis es passt. Dieselbe fünfteilige Form gilt auch in OpenCode.
Beginne mit den klarsten visuellen Referenzen, die du hast — und beziehe mehrere Zustände ein (Desktop und Mobile, Hover, Empty, Loading), nicht nur ein einziges Hero-Bild.
Sei im Prompt konkret; vage Prompts erzeugen generische UI.
Bereite ein Design-System vor und sag OpenCode, wo die Tokens und kanonischen Primitive liegen (in AGENTS.md).
Starte einen Dev-Server und lass den Agenten in einem echten Browser rendern, indem er auf Breakpoints umbricht, um das Ergebnis zu prüfen.
Iteriere, indem OpenCode seine Implementierung mit den Screenshots abgleicht — nicht bloß bestätigt, dass sie baut.
Referenziere Dateien in der TUI mit @ für eine unscharfe Suche in deinem Arbeitsverzeichnis, führe Shell-Befehle inline mit einem vorangestellten ! aus und steuere Aktionen mit /-Befehlen. Prompt dann mit konkreten Vorgaben:
Halte Prompts klein und fokussiert, committe gelungene Iterationen und verwirf misslungene (sag OpenCode, wenn du etwas verwirfst), damit jeder Durchlauf auf einer sauberen Basis aufbaut.
opencode
# in the TUI:
> @reference-desktop.png @reference-mobile.png
Implement this design in React + Vite + Tailwind + TypeScript.
Reuse my existing design-system components and tokens from AGENTS.md.
Match spacing, layout, and hierarchy; make it responsive.
Run the dev server, open it in a browser, and iterate until the
UI matches the references across breakpoints.
Historisches Befehlsbeispiel aus dem vorherigen Leitfaden; prüfe die aktuelle Syntax in der verlinkten Herstellerdokumentation.
AGENTS.md, MCP und teilbare Sitzungen
Drei Erweiterungspunkte machen OpenCode für dauerhafte Designarbeit praktikabel, und alle drei lassen sich sauber auf einen offenen Design-Workflow abbilden.
AGENTS.md-Regeln: Projektregeln liegen in einer AGENTS.md im Repo-Stamm (oder global in ~/.config/opencode/AGENTS.md). Sie ist das dauerhafte Zuhause für deine Design-Konventionen, wird bei jedem Lauf gelesen und ist mit den CLAUDE.md-Dateien kompatibel, die andere Agenten verwenden.
MCP-Server: OpenCode unterstützt sowohl lokale (Befehl) als auch entfernte (URL) MCP-Server, konfiguriert unter dem Schlüssel mcp — der portable Weg, Design-Kontext und externe Tools einzubringen, die über Agenten hinweg funktionieren, nicht nur in OpenCode.
Teilbare Sitzungen: Der Befehl /share erstellt einen öffentlichen Link zu einer Konversation für Zusammenarbeit oder Review, und /unshare widerruft ihn — nützlich, um Feedback zu einem Design-Durchlauf einzuholen.
Das sind portable Multi-Agent-Fähigkeiten — genau die Art von Sache, für deren Orchestrierung OpenDesign gebaut ist, statt sie pro Projekt neu zu erfinden.
OpenCode vs Codex vs Claude Code vs Cursor fürs Design
Für Designarbeit gibt es keinen einzelnen Sieger — jeder Agent hat eine andere Stärke, und erfahrene Teams kombinieren sie. Eine faire Zusammenfassung:
OpenCode — Quelloffen und modellagnostisch; jeder Anbieter läuft hinter einem Terminal-Workflow — BYOK-Freiheit, Modellwechsel, vollständig offene und local-first Setups
Codex — Starke visuelle Politur mit einer Frontend-Skill; Bildverständnis — Delegierte asynchrone, sandboxed Builds, portable AGENTS.md-Regeln
Claude Code — Konkrete Design-Entscheidungen (Hex, Abstände, Typografie) und codebasissensitives UX — Frontend-Argumentation und Refactorings mit großem Kontext
Cursor — Visuelle Bau-und-Schau-Schleife mit Live-Vorschau und Inline-Edits — Enges Iterieren-und-Beobachten bei UI-Arbeit innerhalb einer IDE
Das wiederkehrende Urteil der Community ist, dass Geschmack von Menschen kommt: Ohne Skills, Referenzen und Vorgaben fallen alle auf eine generische Ästhetik zurück. Das ist das eigentliche Problem, das es zu lösen gilt — und es hat die Form eines Design-Werkzeugs, nicht eines Modells, weshalb ein offener Agent wie OpenCode so gut mit einer offenen Design-Schicht zusammenpasst.
Agent — Design-Stärke — Am besten geeignet für
Fallstricke und das Vermeiden des „AI-Slop“-Looks
Die häufigste Klage über KI-generiertes Design ist, dass es generisch aussieht — weiche Verläufe, schwebende Panels, überdimensionierte abgerundete Ecken, dramatische Schatten, ein Inter-und-Lila-Vibe, der „schreit, dass eine KI das gemacht hat“. Weitere gemeldete Probleme sind kaputte Mobile-Layouts und Anweisungen, die in die UI-Texte durchsickern. Nichts davon ist OpenCode-spezifisch; es passiert, wenn ein Agent ohne kuratierten Design-Kontext läuft.
Eine ästhetische Skill hinzufügen: Eine kuratierte Design-Skill zwingt den Agenten, sich auf eine echte Richtung festzulegen, statt auf das Standardaussehen.
In einem echten Browser prüfen: Über Breakpoints hinweg rendern und selbst kontrollieren, damit Layouts auf Mobile nicht still kaputtgehen.
Tokens und Referenzen liefern: Echte Design-Tokens und Referenz-Screenshots sind der mit Abstand größte Hebel für die Output-Qualität.
Regeln in AGENTS.md verankern: Lege Regeln im Stil „keine Hero-Cards, maximal zwei Schriftarten, markenorientierte Hierarchie“ dort ab, wo der Agent sie bei jedem Lauf liest.
Beachte, dass jede Gegenmaßnahme darum geht, dem Agenten einen kuratierten Design-Kontext zu geben — unabhängig davon, welches Modell du laufen lässt. Diesen Kontext pro Projekt von Hand zu pflegen, ist die Mühsal, die OpenDesign beseitigt.
Designen mit OpenCode innerhalb von OpenDesign
OpenDesign ist die quelloffene Design-Schicht, nach der der obige Workflow ständig verlangt. Es behandelt OpenCode als First-Party-Adapter und hüllt ihn in eine kuratierte Skill- und Design-System-Bibliothek, eine strukturierte Render-Pipeline und eine lokale Desktop-UI — sodass der Design-Kontext, der jeden Agenten gut macht, schon beim ersten Lauf da ist und nicht jedes Mal von Hand zusammengesetzt werden muss. Beide Projekte sind quelloffen und local-first, was die Kombination zu einer natürlichen Passung macht.
Authentifiziere dich mit deinem eigenen API-Schlüssel des Modellanbieters (BYOK) — Zugangsdaten bleiben auf deiner Maschine und werden nie über uns geleitet.
Wähle einen beliebigen Anbieter und ein Modell, dazu ein Design-System und eine Skill, und generiere dann Decks, Prototypen und Landing Pages mit konsistentem Geschmack.
Jedes Artefakt und jede DESIGN.md-Datei liegt in deinem eigenen Repo, nicht in einer gehosteten Cloud.
Derselbe OpenCode-Agent, dieselbe Modellfreiheit — plus ein echter, portabler, quelloffener Design-Workflow darum herum. Er ist local-first und Apache-2.0, sodass nichts an deiner Arbeit oder deinen Zugangsdaten deine Maschine verlässt.
Installiere OpenDesign und wähle OpenCode als deinen Agenten.
Welcher OpenCode ist das?
Der quelloffene Terminal-Agent unter github.com/anomalyco/opencode (früher sst/opencode), gepflegt von Anomaly. Nicht mit ähnlich benannten Tools zu verwechseln.
Ist OpenDesign dasselbe Projekt wie OpenCode?
Nein. Beide sind quelloffen, aber es sind getrennte Projekte. OpenDesign integriert OpenCode als First-Party-Agent-Adapter.
OpenCode
OpenDesign
