Plateforme
Aperçu en direct pour une livraison logicielle IA sérieuse
L'application tourne en direct à côté du chat pendant sa construction — vrais flux, vrais clics — et des liens d'aperçu permettent aux parties prenantes de la voir avant que quoi que ce soit ne soit livré.
L'aperçu en direct est l'application en cours d'exécution à côté du chat dans Ciao Builder : à mesure que l'IA construit, la vraie app se met à jour et répond à de vrais clics. Contrairement aux outils où vous déployez pour découvrir ce que vous avez obtenu, l'aperçu en direct montre chaque modification au moment où elle atterrit, alimente le ciblage d'inspect-to-prompt, et génère des liens d'aperçu partageables pour que les parties prenantes revoient la vraie app avant sa publication.
Publié 2026-07-03 · Dernière mise à jour 2026-07-03
Ne construisez jamais à l'aveugle
Le plus ancien mode d'échec de la livraison logicielle est la distance : des semaines passent entre la demande et la démo, et le résultat est faux de manières qui auraient pris trente secondes à repérer le premier jour. L'IA comprime le calendrier, mais elle peut aggraver la cécité — le code apparaît maintenant plus vite que quiconque ne peut le lire, et une mauvaise hypothèse se cumule à la vitesse de la machine.
Ciao réduit la distance à zéro. L'application tourne en direct à côté du chat pendant sa construction. Pas une maquette, pas une capture d'écran — la vraie app, sur de vraies structures de données, répondant à de vrais clics. Quand quelque chose ne va pas, vous le voyez maintenant, pendant que le contexte est encore frais et que le correctif n'est qu'à un prompt de distance.
L'aperçu est aussi l'ancrage des autres habitudes de Builder : inspect-to-prompt l'utilise comme cadre de référence partagé, les prompts en file sont revus contre lui au fur et à mesure qu'ils atterrissent, et la console full-stack explique ce qu'elle fait sous la surface.
Comment fonctionne l'aperçu en direct
Du premier prompt à la publication, l'aperçu est la constante — la chose que tout le monde regarde pendant que les décisions se prennent.
1. Décrivez, et regardez-le apparaître
À mesure que Builder travaille, l'app prend forme dans le panneau d'aperçu à côté de la conversation. Le progrès est visible, pas promis.
2. Cliquez dans de vrais flux
Connectez-vous, créez un enregistrement, lancez la recherche, soumettez le formulaire. L'aperçu est l'application fonctionnelle, donc les tests commencent à la minute où la construction commence.
3. Pointez ce qu'il faut changer ensuite
L'aperçu en direct alimente inspect-to-prompt : cliquez sur n'importe quel élément dans l'app en cours d'exécution pour le référencer dans votre prochain prompt.
4. Partagez un lien d'aperçu
Envoyez aux parties prenantes un lien vers l'app en cours d'exécution avant que quoi que ce soit ne soit publié. Le feedback arrive contre la vraie chose, pas un jeu de diapositives.
5. Passez les portes
Quand vous publiez, QA exécute d'abord des replays de navigateur déterministes et des smoke gates, puis des contrôles en production après — l'aperçu est où vous attrapez les problèmes d'intention avant que les portes n'attrapent les défauts.
6. Publiez délibérément
Aperçu et production sont séparés. Rien n'atteint les utilisateurs tant que vous ne choisissez pas de le livrer.
Pourquoi c'est important
Le coût du feedback détermine la qualité du build. Quand voir une modification coûte un cycle de déploiement, les gens regroupent leurs doutes et découvrent les problèmes tard ; quand cela coûte un coup d'œil, chaque hypothèse est vérifiée pendant qu'elle est encore bon marché à corriger. L'aperçu en direct réduit le prix de la vérification à presque zéro.
Cela change aussi la revue des parties prenantes d'une réunion en un lien. Clients, dirigeants et utilisateurs finaux réagissent à l'app en cours d'exécution des jours avant le lancement — ce qui est précisément quand leurs opinions sont encore abordables à intégrer.
Il y a aussi un bénéfice de gouvernance caché dans la commodité : les gens approuvent ce qu'ils ont réellement vu tourner. Une validation contre une application en direct signifie moins de surprises le jour du lancement et une responsabilité plus claire quand quelqu'un demande plus tard qui a revu ceci.
Qui utilise l'aperçu en direct
L'aperçu en direct est la fonctionnalité la moins spécialisée de la plateforme — tous ceux qui ont un intérêt dans l'app finissent par l'utiliser :
- Fondateurs — Valident les décisions produit contre l'app en cours d'exécution en temps réel au lieu d'imaginer comment ça se sentira.
- Agences — Envoient aux clients des liens d'aperçu en cours de projet — moins de surprises à la révélation, validation plus rapide, lancements plus calmes.
- Product managers — Font la démo de l'application réelle aux parties prenantes avant publication et intègrent leurs réactions dans la file de prompts.
- Équipes d'opérations — Font que les personnes qui utiliseront l'outil cliquent dedans avant qu'il ne leur soit livré.
Notes sur la sécurité et la gouvernance
Voir tôt ne signifie pas livrer relâché :
- ✓ Aperçu et production sont séparés — publier est une action délibérée et contrôlée.
- ✓ Les smoke gates de QA s'exécutent avant publication et les contrôles en production après, quel que soit à quel point l'aperçu semblait bon.
- ✓ Les modifications derrière l'aperçu vivent sur de vraies branches git avec diffs et checkpoints.
- ✓ La revue de policy Guardrails et la revue humaine enregistrée se tiennent entre l'aperçu et le merge.
- ✓ Publications et déploiements sont enregistrés dans l'audit trail append-only.
Déployer-pour-voir vs aperçu en direct
La différence de workflow se cumule sur la vie d'un projet :
| Workflow déployer-pour-voir | Aperçu en direct Ciao | |
|---|---|---|
| Temps pour voir une modification | Après un cycle de build-et-déploiement | Immédiatement, à côté du chat |
| Feedback des parties prenantes | Réunions, captures d'écran, demandes d'accès au staging | Un lien d'aperçu vers l'app en cours d'exécution |
| Coût d'une mauvaise hypothèse | Se cumule jusqu'à ce que quelqu'un déploie et remarque | Attrapé pendant que le contexte est frais |
| Diriger la prochaine modification | Décrite de mémoire | Pointée directement avec inspect-to-prompt |
| Décision de publication | Emmêlée avec le fait de voir le résultat | Séparée, délibérée et contrôlée |
Questions fréquentes
L'aperçu en direct est-il l'application réelle ou une simulation ?
L'application réelle. C'est l'app React, TypeScript et Supabase générée tournant en direct, c'est pourquoi vous pouvez cliquer dans de vrais flux et pourquoi inspect-to-prompt peut résoudre ce sur quoi vous cliquez vers de vrais composants.
Des personnes en dehors de la construction peuvent-elles voir l'aperçu ?
Oui — les liens d'aperçu sont faits exactement pour ça. Clients et parties prenantes revoient l'app en cours d'exécution avant publication, si bien que le feedback se produit contre la réalité plutôt qu'une maquette.
Quelque chose dans l'aperçu affecte-t-il la production ?
Non. Aperçu et production sont séparés, et publier est une étape délibérée contrôlée par les smoke gates de QA. Tant que vous ne publiez pas, les utilisateurs ne voient rien.
Que se passe-t-il entre l'aperçu et la publication ?
La modification merge sous Guardrails avec une revue humaine enregistrée, QA exécute des replays de navigateur déterministes et des smoke gates avant publication, et des contrôles en production s'exécutent après. L'aperçu est où vous corrigez l'intention ; les portes sont où les défauts sont attrapés.
L'aperçu en direct fait-il partie du Builder standard ?
Oui — l'app tournant à côté du chat, c'est comment Builder fonctionne, et les builders individuels démarrent en self-serve avec des crédits. Les programmes de production sérieux démarrent à 10 000 USD par an.
Pages associées
Construisez le logiciel que vous attendiez.
Aperçu en direct : regardez votre app tourner pendant que l'IA construit | Ciao