Platform
Inspect-to-prompt voor serieuze AI-softwarelevering
Klik elk element in de draaiende app om ernaar te verwijzen in je volgende prompt — zodat de wijziging landt op wat je aanwees, niet op wat de AI raadde.
Inspect-to-prompt is een functie van de Ciao Builder waarmee je op elk element in de live preview kunt klikken — een knop, tabel, grafiek of formulierveld — en er direct naar verwijzen in je volgende prompt. In tegenstelling tot UI in woorden beschrijven en hopen dat de AI dezelfde kaarten telt als jij, maakt inspect-to-prompt het doel ondubbelzinnig, zodat wijzigingen scoped landen op het geselecteerde component met een kleine, reviewbare diff.
Gepubliceerd 2026-07-03 · Laatst bijgewerkt 2026-07-03
De meeste mislukte prompts zijn slechte adressen, geen slechte ideeën
'Maak de derde kaart kleiner' werkt prima tot de AI andere kaarten telt dan jij. Een gebruikersinterface in woorden beschrijven is een verlieslatende oefening: jouw 'header', het 'header' van het model en het 'header' van de code kunnen drie verschillende dingen zijn. Ambiguïteit gaat erin, de verkeerde wijziging komt eruit, en je besteedt de volgende drie prompts aan het ongedaan maken van schade aan elementen die je nooit noemde.
Inspect-to-prompt verwijdert het adresseringsprobleem. De app draait live naast de chat terwijl hij gebouwd wordt; klik op elk element in die preview en het wordt verwezen in je volgende prompt. De Builder weet precies welk component je bedoelt — geen tellen, geen beschrijven, geen woordenschatonderhandeling.
Het is een kleine interactie met buitenmatige gevolgen. De Builder combineert een gesprek met een draaiende applicatie precies zodat aanwijzen mogelijk is — de preview is geen demopaneel, het is een gedeeld referentiekader tussen jou en de AI.
Hoe inspect-to-prompt werkt
De loop duurt seconden, en is hetzelfde voor een founder die een landingspagina polijst en een engineer die een admin-tabel aanpast.
1. Open de live preview
De applicatie draait naast het gesprek terwijl hij gebouwd wordt — echte componenten, echte datastructuren, echte klikken.
2. Klik het element dat je bedoelt
Een knop, een tabelkolom, een grafiek, een formulierveld, een verdwaald label. Selectie werkt op de draaiende app, niet op een screenshot.
3. Het wordt onderdeel van je volgende prompt
Het geselecteerde element wordt direct verwezen in de prompt, zodat de Builder het naar het exacte component in de code oplost.
4. Beschrijf de wijziging in gewone taal
'Maak dit een dropdown', 'verplaats dit boven de samenvatting', 'dit zou alleen voor admins moeten tonen.' Het wat blijft natuurlijk; het waar staat al vast.
5. De wijziging landt scoped
De wijziging richt zich op het geselecteerde component, wat een kleine diff oplevert op een echte git-branch in plaats van een speculatieve herschrijving.
6. Verifieer ter plekke
De preview werkt bij naast de chat. Als het nog niet goed is, klik opnieuw — ongedaan maken en checkpoints maken itereren goedkoop.
Waarom dit ertoe doet
Precisie stapelt op. Wanneer wijzigingen landen waar je aanwees, dalen iteraties, krimpen diffs, en wordt review makkelijker — een reviewer die bevestigt dat 'de geselecteerde knop is gewijzigd' werkt sneller dan een die een herschrijving audit. Kleine, scoped wijzigingen zijn ook precies waar Guardrails en QA het beste in zijn om te gaten.
Het verbreedt ook wie werk kan sturen. Een founder, ontwerper of klant heeft geen CSS-woordenschat nodig om te zeggen wat ze bedoelen — ze wijzen de draaiende app aan. De kloof tussen 'persoon die het probleem ziet' en 'persoon die de fix kan uitdrukken' sluit tot een klik.
Teams voelen het verschil het meest tijdens feedbackrondes. Een reviewgesprek waar gevraagde wijzigingen landen terwijl mensen toekijken is een andere productrelatie dan een gesprek dat een ticketlijst voor volgende week oplevert.
Wie gebruikt inspect-to-prompt
Iedereen die het probleem kan zien kan het nu precies aanpakken:
- Founders en ontwerpers — Polijst interfaces door aan te wijzen, zonder het verschil tussen padding en margin te leren.
- Bureaus — Verander 'zet dat daar' klantfeedback in exacte wijzigingen tijdens reviewgesprekken, niet erna.
- Product managers — Stuur wijzigingen naar het precieze element waarover een stakeholder klaagde, zonder ticketvertaalverlies.
- Ontwikkelaars — Scope AI-wijzigingen strak zodat diffs klein blijven en reviews snel blijven.
Security- en governance-notities
Precisie versoepelt de regels niet — aangewezen wijzigingen doorlopen dezelfde gates als getypte.
- ✓ Scoped wijzigingen produceren kleine, reviewbare diffs op echte git-branches.
- ✓ Elke wijziging — aangewezen of getypt — doorloopt Guardrails-beleidsreview vóór merge.
- ✓ De append-only audit trail legt de prompt en de resulterende wijziging samen vast.
- ✓ Ongedaan maken en checkpoint-herstel maken elke misser binnen seconden herstelbaar.
- ✓ Rolgebaseerde toegangscontrole bepaalt wie kan bewerken en wie kan mergen.
UI-wijzigingen beschrijven: alleen woorden vs inspect-to-prompt
De vergelijking houdt op subtiel te zijn na de eerste middag om beide manieren te proberen.
| Alleen woorden | Inspect-to-prompt | |
|---|---|---|
| Aanwijzen | Hangt af van gedeelde woordenschat en tellen | Klik het exacte element in de draaiende app |
| Iteraties | Meerdere pogingen terwijl beschrijvingen verfijnd worden | Minder — de verwijzing is ondubbelzinnig |
| Neveneffecten | Wijzigingen kunnen landen op gelijkende elementen | Scoped naar het geselecteerde component |
| Diff-grootte | Vaak groter dan het verzoek | Klein en gebonden aan één element |
| Wie werk kan sturen | Mensen vloeiend in UI-woordenschat | Iedereen die het probleem kan aanwijzen |
Veelgestelde vragen
Werkt inspect-to-prompt op elk deel van de app?
Je kunt elementen selecteren over de hele draaiende interface — knoppen, tabellen, grafieken, formulieren, labels — omdat de live preview de echte applicatie is, geen afbeelding. De selectie wordt opgelost naar het daadwerkelijke component in de gegenereerde React- en TypeScript-code.
Moet ik de code begrijpen om het te gebruiken?
Nee. Je wijst het element aan en beschrijft de wijziging in gewone taal. De Builder handelt de mapping af van het geselecteerde element naar het component in code, en de diff is er voor iedereen die hem wel wil lezen.
Hoe zit het met wijzigingen die veel elementen tegelijk raken?
Beschrijf het patroon in de prompt — 'pas deze stijl toe op alle samenvattingskaarten' — of zet een sequentie scoped wijzigingen in de wachtrij met de promptwachtrij. Inspect-to-prompt is voor precisie; het weerhoudt je niet van brede wijzigingen wanneer je die wilt.
Is er een vastlegging van wat werd geselecteerd en gewijzigd?
Ja. Elke wijziging is een diff op een git-branch, en de append-only audit trail legt prompts, merges en deploys vast. Reviewers kunnen zien wat werd gevraagd en precies wat er veranderde.
Is inspect-to-prompt inbegrepen in self-serve-plannen?
Ja — het is een kernmogelijkheid van de Builder, en individuele bouwers starten self-serve met credits. Serieuze productieprogramma's beginnen bij 10.000 USD per jaar.