Plattform
Builder: der KI-Partner, der echte Apps ausliefert
Beschreibe in einfacher Sprache, was du willst, und beobachte, wie neben der Konversation eine echte React-, TypeScript- und Supabase-Anwendung entsteht — mit Git, Checkpoints und Live-Vorschau eingebaut.
Builder ist der Entwicklungs-Workspace von Ciao: Chat links, deine Live-Anwendung rechts. Anders als KI-Coding-Tools, die beim generierten Code aufhören, verbindet Builder jede Konversation mit Inspect-to-Prompt, einer Prompt-Warteschlange, branch-nativem Git, Undo, Checkpoints, Live-Vorschau und einer Full-Stack-Konsole — sodass aus Anfragen in einfacher Sprache echte, laufende Software wird, die dir gehört.
Veröffentlicht 2026-07-03 · Zuletzt aktualisiert 2026-07-03
Ein einziges Fenster zwischen einer Idee und einer laufenden App
Die meisten KI-Coding-Tools produzieren Code und betrachten die Arbeit als erledigt. Diesen Code auszuführen, ihn in der Vorschau zu sehen, ihn zu versionieren und sich von der Änderung zu erholen, die den Login kaputt gemacht hat, bleibt dir überlassen — genau dort, wo Nicht-Ingenieure ins Stocken geraten und Ingenieure den Nachmittag verlieren. Die Distanz zwischen einem generierten Diff und einer funktionierenden Anwendung ist die eigentliche Kostenstelle KI-gestützter Entwicklung, und sie zeigt sich selten in der Demo.
Builder schließt diese Distanz. Es ist ein einziger Workspace: die Konversation mit Ciao links, deine Live-Anwendung rechts. Du beschreibst in einfacher Sprache, was du willst, Ciao schreibt echtes React und TypeScript gegen ein Supabase-Backend, und die Vorschau vor dir aktualisiert sich. Branching, Checkpoints, Undo und Logs sind bereits im Fenster, sodass eine ernsthafte Änderung es nie verlassen muss.
Wie eine Builder-Session abläuft
1. Die Änderung beschreiben
Schreibe in einfacher Sprache, was du willst — einen neuen Bildschirm, eine Regeländerung, einen Report. Ciao plant die Arbeit und schreibt echten Code, keine Konfiguration in einem geschlossenen Tool.
2. Zeigen statt beschreiben
Mit Inspect-to-Prompt klickst du auf jedes Element in der Live-Vorschau, und dein nächster Prompt bezieht sich exakt auf diese Komponente. Keine Absätze mehr, um zu erklären, welchen Button du meinst.
3. Die nächsten Gedanken in die Warteschlange stellen
Die Prompt-Warteschlange hält Folgeanfragen in Reihenfolge, während der aktuelle Build läuft. Ideen landen in der Warteschlange, nicht in einer Notizdatei, die du vergisst.
4. Auf einem echten Branch arbeiten
Builder ist branch-nativ: Jede Arbeit findet auf einem Git-Branch statt, sodass Experimente isoliert bleiben und nichts direkt die veröffentlichte Anwendung verändert.
5. Live zusehen
Die Live-Vorschau ist die echte Anwendung — echte Routen, echte Daten, echte Authentifizierung — kein statisches Mock-up. Was du siehst, wird auch veröffentlicht.
6. Undo, oder zu einem Checkpoint springen
Ein Klick auf Undo macht die letzte Änderung rückgängig; Checkpoints markieren bekannt funktionierende Zustände, zu denen du jederzeit zurückkehren kannst. Mutige Versuche hören auf, riskant zu sein.
7. Unter die Haube schauen
Die Full-Stack-Konsole zeigt Frontend-Fehler, Backend-Logs und Datenbankaktivität an einem Ort, sodass die Frage „warum ist das kaputt“ nur einen Ort hat, an dem man nachsehen muss.
Warum es wichtig ist
Builder produziert Standard-React, TypeScript und Tailwind, das dir vollständig gehört — jederzeit exportierbar in dein eigenes Repository. Das ist wichtig, weil die Alternative Momentum innerhalb des Formats eines anderen ist: Monate an Arbeit, die du nicht mitnehmen kannst.
Es ist auch wichtig, weil Builder nicht allein arbeitet. Jeder Ciao-Workspace kommt mit einer KI-Softwareorganisation — CTO, Doctor, QA-Analyst, Security-Engineer, Coder und SysOps-Operator —, sodass das, was du in Builder baust, in die Guardrails-Prüfung, automatisierte QA und Live-Sicherheitstests einfließt, bevor es Nutzer erreicht. Das Chatfenster ist die Eingangstür zu einem Delivery-Loop, nicht das gesamte Produkt.
Wer Builder nutzt
- Gründer und Operator — Menschen, die das Produkt präzise beschreiben können, aber keinen Code schreiben — sie bekommen eine echte Anwendung, die ihnen gehört, kein Prototyp mit Ablaufdatum.
- Product Manager und Fachexperten — Die Menschen, die dem Workflow am nächsten stehen, bauen das interne Tool selbst, auf einem Branch, mit Prüfung vor jedem Merge.
- Ingenieure — Entwickler nutzen Builder, um bei gut verstandener Arbeit schneller voranzukommen, während sie die Git-Disziplin, Checkpoints und Full-Stack-Sichtbarkeit behalten, die sie ohnehin eingerichtet hätten.
- Agenturen — Kundenarbeit bekommt denselben Kreislauf: in der Konversation bauen, die Live-Vorschau in Review-Calls zeigen, durch die Gates ausliefern.
Hinweise zu Sicherheit und Governance
- ✓ Jede Änderung findet auf einem Git-Branch statt — nichts verändert direkt die veröffentlichte Anwendung.
- ✓ Guardrails ordnet Code Geschäftsbereichen zu und wendet Richtlinien in einfacher Sprache an, bevor riskante Änderungen gemerged werden.
- ✓ QA führt Smoke-Gates vor der Veröffentlichung und Prüfungen in Produktion danach aus.
- ✓ Ein unveränderliches Audit-Protokoll (append-only) deckt Prompts, Merges, Deployments und administrative Aktionen ab.
- ✓ Kundencode wird nicht zum Training von Modellen verwendet; Inferenz läuft unter Zero-Retention-Modellverträgen.
- ✓ 100 % Code-Eigentum — exportiere jederzeit Standard-React, TypeScript und Tailwind in dein eigenes Repository.
Builder im Vergleich zu einem reinen Prompt-Workflow
Der Unterschied ist nicht das Modell, das den Code schreibt — es ist alles rund um den Code.
| Reines Prompt-KI-Coding | Ciao Builder | |
|---|---|---|
| Das Ergebnis sehen | Code kopieren, lokal ausführen | Live-Vorschau aktualisiert sich neben dem Chat |
| Eine Korrektur anvisieren | Das Element in Worten beschreiben | Draufklicken — Inspect-to-Prompt bindet die Komponente ein |
| Folgeideen | Auf den Lauf warten, dann neu tippen | Die Prompt-Warteschlange hält sie in Reihenfolge |
| Versionskontrolle | Manuelle Commits, falls überhaupt | Branch-natives Git, Undo und Checkpoints |
| Debugging | Separate Terminals und Dashboards | Full-Stack-Konsole im selben Fenster |
Häufig gestellte Fragen
Muss ich Git kennen, um Builder zu nutzen?
Nein. Builder ist unter der Haube branch-nativ: Es erstellt Branches, committet Arbeit und verwaltet Merges für dich. Ingenieure können jederzeit auf die Git-Ebene wechseln, und die vollständige Historie steht beim Export des Codes zur Verfügung.
Was genau macht Inspect-to-Prompt?
Du klickst auf ein Element in der Live-Vorschau — einen Button, eine Tabelle, ein Formular — und Builder hängt den Kontext dieser Komponente an deinen nächsten Prompt an. Eine Anfrage wie „mach das sortierbar“ landet gleich beim ersten Mal im richtigen Code, statt aus einer schriftlichen Beschreibung interpretiert zu werden.
Was passiert, wenn eine Änderung etwas kaputt macht?
Du hast drei Ebenen: Undo mit einem Klick für die letzte Änderung, Checkpoints, um zu einem bekannt funktionierenden Zustand zurückzukehren, und QA-Smoke-Gates, die Fehler abfangen, bevor eine Veröffentlichung stattfindet. Produktionsprüfungen laufen auch nach der Veröffentlichung.
Kann ich den Code woanders hin mitnehmen?
Ja. Ciao generiert Standard-React, TypeScript und Tailwind mit einem Supabase-Backend, und dir gehören 100 % davon. Exportiere jederzeit in dein eigenes Repository — es gibt keine proprietäre Laufzeitumgebung, von der die App abhängt.
Wie fange ich an, und was kostet es?
Einzelne Builder starten Self-Service mit Guthaben — beschreibe deine erste App und leg los. Ernsthafte Produktionsprogramme beginnen bei 10.000 USD pro Jahr; sieh dir die Preisseite an oder sprich mit dem Vertrieb darüber, was dein Team braucht.