Plattform

Live-Vorschau für ernsthafte KI-Softwarelieferung

Die Anwendung läuft live neben dem Chat, während sie gebaut wird — echte Abläufe, echte Klicks — und Vorschau-Links lassen Stakeholder sie sehen, bevor irgendetwas ausgeliefert wird.

Live-Vorschau ist die laufende Anwendung neben dem Chat im Ciao Builder: Während die KI baut, aktualisiert sich die echte App und reagiert auf echte Klicks. Anders als Tools, bei denen du deployen musst, um herauszufinden, was du bekommen hast, zeigt Live-Vorschau jede Änderung in dem Moment, in dem sie landet, treibt das Inspect-to-Prompt-Targeting an und generiert teilbare Vorschau-Links, damit Stakeholder die tatsächliche App prüfen, bevor sie veröffentlicht wird.

Ideal fürSofortige VerifikationStakeholder-Review-LinksVerhalten formen, während gebaut wird

Veröffentlicht 2026-07-03 · Zuletzt aktualisiert 2026-07-03

Nie blind bauen

Der älteste Fehlermodus in der Softwarelieferung ist Distanz: Wochen vergehen zwischen der Anfrage und der Demo, und das Ergebnis ist auf Arten falsch, die dreißig Sekunden gebraucht hätten, um es am ersten Tag zu entdecken. KI komprimiert die Zeitleiste, kann aber die Blindheit verschlimmern — Code erscheint jetzt schneller, als jemand ihn lesen kann, und eine falsche Annahme summiert sich mit Maschinengeschwindigkeit.

Ciao schließt die Distanz auf null. Die Anwendung läuft live neben dem Chat, während sie gebaut wird. Kein Mockup, kein Screenshot — die echte App, auf echten Datenstrukturen, reagiert auf echte Klicks. Wenn etwas nicht stimmt, siehst du es jetzt, während der Kontext noch frisch ist und die Korrektur einen Prompt entfernt ist.

Die Vorschau ist auch der Anker für die anderen Gewohnheiten des Builders: Inspect-to-Prompt nutzt sie als gemeinsamen Bezugsrahmen, eingereihte Prompts werden gegen sie geprüft, während sie landen, und die Full-Stack-Konsole erklärt, was unter der Oberfläche passiert.

Wie Live-Vorschau funktioniert

Vom ersten Prompt bis zur Veröffentlichung ist die Vorschau die Konstante — das, worauf alle schauen, während Entscheidungen getroffen werden.

  1. 1. Beschreiben, und zusehen, wie es erscheint

    Während der Builder arbeitet, nimmt die App im Vorschaubereich neben der Konversation Gestalt an. Fortschritt ist sichtbar, nicht versprochen.

  2. 2. Durch echte Abläufe klicken

    Anmelden, einen Datensatz anlegen, die Suche ausführen, das Formular absenden. Die Vorschau ist die funktionierende Anwendung, sodass Testen in dem Moment beginnt, in dem das Bauen beginnt.

  3. 3. Auf das zeigen, was als Nächstes geändert werden soll

    Live-Vorschau treibt Inspect-to-Prompt an: Klicke auf ein beliebiges Element in der laufenden App, um es in deinem nächsten Prompt zu referenzieren.

  4. 4. Einen Vorschau-Link teilen

    Sende Stakeholdern einen Link zur laufenden App, bevor irgendetwas veröffentlicht wird. Feedback kommt gegen das echte Ding, nicht eine Foliensammlung.

  5. 5. Die Gates bestehen

    Wenn du veröffentlichst, führt QA zuerst deterministische Browser-Replays und Smoke-Gates aus, dann Produktionsprüfungen danach — die Vorschau ist, wo du Absichtsprobleme fängst, bevor die Gates Fehler fangen.

  6. 6. Bewusst veröffentlichen

    Vorschau und Produktion sind getrennt. Nichts erreicht Nutzer, bis du dich entscheidest, es auszuliefern.

Warum es wichtig ist

Feedback-Kosten bestimmen die Build-Qualität. Wenn das Sehen einer Änderung einen Deploy-Zyklus kostet, bündeln Menschen ihre Zweifel und entdecken Probleme spät; wenn es einen Blick kostet, wird jede Annahme geprüft, während sie noch billig zu beheben ist. Live-Vorschau senkt die Kosten der Verifikation auf nahezu null.

Es verwandelt auch Stakeholder-Review von einem Meeting in einen Link. Kunden, Führungskräfte und Endnutzer reagieren auf die laufende App Tage vor dem Launch — genau dann, wenn ihre Meinungen noch bezahlbar sind, um danach zu handeln.

Es gibt auch einen Governance-Vorteil, der sich in der Bequemlichkeit versteckt: Menschen genehmigen, was sie tatsächlich laufend gesehen haben. Freigabe gegen eine laufende Anwendung bedeutet weniger Überraschungen am Launch-Tag und sauberere Verantwortlichkeit, wenn jemand später fragt, wer das geprüft hat.

Wer Live-Vorschau nutzt

Live-Vorschau ist die am wenigsten spezialisierte Funktion der Plattform — jeder mit einem Interesse an der App landet darin:

  • Gründer — Validieren Produktentscheidungen gegen die laufende App in Echtzeit, statt sich vorzustellen, wie es sich anfühlen wird.
  • Agenturen — Senden Kunden mitten im Projekt Vorschau-Links — weniger Überraschungsreveal, schnellere Freigabe, ruhigere Launches.
  • Product Manager — Demonstrieren die tatsächliche Anwendung Stakeholdern vor der Veröffentlichung und falten ihre Reaktionen in die Prompt-Warteschlange.
  • Betriebsteams — Lassen die Menschen, die das Tool nutzen werden, hindurchklicken, bevor es an sie ausgeliefert wird.

Hinweise zu Sicherheit und Governance

Früh sehen bedeutet nicht locker ausliefern:

  • ✓ Vorschau und Produktion sind getrennt — Veröffentlichen ist eine bewusste, gegatete Aktion.
  • ✓ QA-Smoke-Gates laufen vor der Veröffentlichung und Produktionsprüfungen danach, unabhängig davon, wie gut die Vorschau aussah.
  • ✓ Änderungen hinter der Vorschau leben auf echten Git-Branches mit Diffs und Checkpoints.
  • ✓ Guardrails-Richtlinienprüfung und protokollierte menschliche Prüfung stehen zwischen Vorschau und Merge.
  • ✓ Veröffentlichungen und Deploys werden im unveränderlichen Audit-Protokoll erfasst.

Deploy-um-zu-sehen vs Live-Vorschau

Der Workflow-Unterschied summiert sich über die Lebensdauer eines Projekts:

Deploy-um-zu-sehen-WorkflowCiao Live-Vorschau
Zeit, um eine Änderung zu sehenNach einem Build-und-Deploy-ZyklusSofort, neben dem Chat
Stakeholder-FeedbackMeetings, Screenshots, Staging-ZugriffsanfragenEin Vorschau-Link zur laufenden App
Kosten einer falschen AnnahmeSummiert sich, bis jemand deployt und es bemerktGefangen, während der Kontext frisch ist
Die nächste Änderung lenkenAus dem Gedächtnis beschriebenDirekt mit Inspect-to-Prompt angezeigt
VeröffentlichungsentscheidungVerwoben mit dem Sehen des ErgebnissesGetrennt, bewusst und gegatet

Häufig gestellte Fragen

Ist die Live-Vorschau die echte Anwendung oder eine Simulation?

Die echte Anwendung. Es ist die generierte React-, TypeScript- und Supabase-App, die live läuft, weshalb du durch tatsächliche Abläufe klicken kannst und weshalb Inspect-to-Prompt auflösen kann, worauf du klickst, zu echten Komponenten.

Können Menschen außerhalb des Builds die Vorschau sehen?

Ja — Vorschau-Links sind genau dafür gemacht. Kunden und Stakeholder prüfen die laufende App vor der Veröffentlichung, sodass Feedback gegen die Realität passiert statt gegen ein Mockup.

Beeinflusst irgendetwas in der Vorschau die Produktion?

Nein. Vorschau und Produktion sind getrennt, und Veröffentlichen ist ein bewusster Schritt, gegated von QA-Smoke-Gates. Bis du veröffentlichst, sehen Nutzer nichts.

Was passiert zwischen Vorschau und Veröffentlichung?

Die Änderung mergt unter Guardrails mit protokollierter menschlicher Prüfung, QA führt deterministische Browser-Replays und Smoke-Gates vor der Veröffentlichung aus, und Produktionsprüfungen laufen danach. Die Vorschau ist, wo du Absicht korrigierst; die Gates sind, wo Fehler gefangen werden.

Ist Live-Vorschau Teil des Standard-Builders?

Ja — die App, die neben dem Chat läuft, ist, wie der Builder funktioniert, und einzelne Builder starten Self-Service mit Guthaben. Ernsthafte Produktionsprogramme beginnen bei 10.000 USD pro Jahr.

Verwandte Seiten

Bau die Software, auf die du früher warten musstest.

Live-Vorschau: Sieh deine App laufen, während KI baut | Ciao