Piattaforma
Inspect-to-prompt per una delivery software AI seria
Clicca su qualsiasi elemento nell'app in esecuzione per riferirlo nel tuo prossimo prompt — così la modifica atterra sulla cosa che hai indicato, non sulla cosa che l'AI ha indovinato.
Inspect-to-prompt è una funzionalità del Builder di Ciao che ti permette di cliccare su qualsiasi elemento nell'anteprima live — un pulsante, una tabella, un grafico o un campo di modulo — e riferirlo direttamente nel tuo prossimo prompt. A differenza di descrivere l'interfaccia a parole e sperare che l'AI conti le stesse schede che conti tu, inspect-to-prompt rende il bersaglio inequivocabile, così le modifiche atterrano delimitate al componente selezionato con un diff piccolo e revisionabile.
Pubblicato 2026-07-03 · Ultimo aggiornamento 2026-07-03
La maggior parte dei prompt falliti sono indirizzi sbagliati, non idee sbagliate
"Rendi più piccola la terza scheda" funziona finché l'AI non conta schede diverse da te. Descrivere un'interfaccia utente a parole è un esercizio con perdite: il tuo "header", l'"header" del modello e l'"header" del codice possono essere tre cose diverse. Entra l'ambiguità, esce la modifica sbagliata, e passi i tre prompt successivi ad annullare danni a elementi che non hai mai menzionato.
Inspect-to-prompt elimina il problema dell'indirizzamento. L'app gira dal vivo accanto alla chat mentre viene costruita; clicca su qualsiasi elemento in quell'anteprima e viene riferito nel tuo prossimo prompt. Il Builder sa esattamente quale componente intendi — nessun conteggio, nessuna descrizione, nessuna negoziazione di vocabolario.
È un'interazione piccola con conseguenze enormi. Il Builder abbina una conversazione a un'applicazione in esecuzione proprio perché puntare sia possibile — l'anteprima non è un pannello demo, è un quadro di riferimento condiviso tra te e l'AI.
Come funziona inspect-to-prompt
Il ciclo richiede secondi, ed è lo stesso per un founder che rifinisce una landing page e un ingegnere che regola una tabella admin.
1. Apri l'anteprima live
L'applicazione gira accanto alla conversazione mentre viene costruita — componenti reali, strutture di dati reali, clic reali.
2. Clicca sull'elemento che intendi
Un pulsante, una colonna di tabella, un grafico, un campo di modulo, un'etichetta persa. La selezione funziona sull'app in esecuzione, non su uno screenshot.
3. Diventa parte del tuo prossimo prompt
L'elemento selezionato viene riferito direttamente nel prompt, così il Builder lo risolve nel componente esatto nel codice.
4. Descrivi la modifica in linguaggio semplice
"Rendilo un menu a tendina", "spostalo sopra il riepilogo", "questo dovrebbe apparire solo agli admin." Il cosa resta naturale; il dove è già stabilito.
5. La modifica atterra delimitata
La modifica prende di mira il componente selezionato, producendo un diff piccolo su un vero branch git invece di una riscrittura speculativa.
6. Verifica sul posto
L'anteprima si aggiorna accanto alla chat. Se non è ancora giusto, clicca di nuovo — annulla e checkpoint rendono l'iterazione economica.
Perché è importante
La precisione si accumula. Quando le modifiche atterrano dove hai puntato, le iterazioni diminuiscono, i diff si riducono, e la revisione diventa più facile — un revisore che conferma "il pulsante selezionato è cambiato" lavora più velocemente di uno che verifica una riscrittura. Le modifiche piccole e delimitate sono anche esattamente ciò in cui Guardrails e QA sono migliori nel vincolare.
Amplia anche chi può dirigere il lavoro. Un founder, un designer o un cliente non ha bisogno di vocabolario CSS per dire cosa intende — punta all'app in esecuzione. Il divario tra "persona che vede il problema" e "persona che può esprimere la correzione" si riduce a un clic.
I team sentono la differenza soprattutto durante i round di feedback. Una call di revisione in cui le modifiche richieste atterrano mentre le persone guardano è una relazione di prodotto diversa da una call che produce una lista di ticket per la settimana successiva.
Chi usa inspect-to-prompt
Chiunque possa vedere il problema ora può indirizzarlo con precisione:
- Founder e designer — Rifiniscono le interfacce puntando, senza imparare la differenza tra padding e margin.
- Agenzie — Trasformano il feedback del cliente "spostalo lì" in modifiche esatte durante le call di revisione, non dopo.
- Product manager — Dirigono modifiche verso l'elemento preciso di cui uno stakeholder si è lamentato, senza perdite di traduzione nei ticket.
- Sviluppatori — Delimitano le modifiche AI strettamente così i diff restano piccoli e le revisioni restano veloci.
Note di sicurezza e governance
La precisione non allenta le regole — le modifiche puntate passano attraverso gli stessi gate di quelle digitate.
- ✓ Le modifiche delimitate producono diff piccoli e revisionabili su veri branch git.
- ✓ Ogni modifica — puntata o digitata — supera la revisione delle policy Guardrails prima del merge.
- ✓ Il registro di controllo append-only registra il prompt e la modifica risultante insieme.
- ✓ L'annulla e il ripristino dei checkpoint rendono qualsiasi errore recuperabile in secondi.
- ✓ Il controllo degli accessi basato sui ruoli governa chi può modificare e chi può unire.
Descrivere modifiche all'interfaccia: solo parole contro inspect-to-prompt
Il confronto smette di essere sottile dopo il primo pomeriggio di lavoro in entrambi i modi.
| Solo parole | Inspect-to-prompt | |
|---|---|---|
| Puntamento | Dipende da vocabolario condiviso e conteggio | Clicca sull'elemento esatto nell'app in esecuzione |
| Iterazioni | Diversi tentativi mentre le descrizioni vengono rifinite | Meno — il riferimento è inequivocabile |
| Effetti collaterali | Le modifiche possono atterrare su elementi simili | Delimitate al componente selezionato |
| Dimensione del diff | Spesso più grande della richiesta | Piccolo e legato a un elemento |
| Chi può dirigere il lavoro | Persone fluenti nel vocabolario dell'interfaccia | Chiunque possa puntare al problema |
Domande frequenti
Inspect-to-prompt funziona su qualsiasi parte dell'app?
Puoi selezionare elementi in tutta l'interfaccia in esecuzione — pulsanti, tabelle, grafici, moduli, etichette — perché l'anteprima live è l'applicazione reale, non un'immagine. La selezione si risolve nel componente reale nel codice React e TypeScript generato.
Devo capire il codice per usarlo?
No. Punti all'elemento e descrivi la modifica in linguaggio semplice. Il Builder gestisce la mappatura dall'elemento selezionato al componente nel codice, e il diff è lì per chiunque voglia leggerlo.
E le modifiche che riguardano molti elementi insieme?
Descrivi il pattern nel prompt — "applica questo stile a tutte le schede di riepilogo" — oppure metti in coda una sequenza di modifiche delimitate con la coda di prompt. Inspect-to-prompt è per la precisione; non ti impedisce di fare modifiche ampie quando le vuoi.
C'è un registro di cosa è stato selezionato e modificato?
Sì. Ogni modifica è un diff su un branch git, e il registro di controllo append-only registra prompt, merge e deploy. I revisori possono vedere cosa è stato chiesto ed esattamente cosa è cambiato.
Inspect-to-prompt è incluso nei piani self-serve?
Sì — è una capacità principale del Builder, e i singoli builder iniziano in self-serve con i crediti. I programmi di produzione seri partono da 10.000 USD all'anno.
Pagine correlate
Costruisci il software che prima dovevi solo aspettare.
Inspect-to-prompt: clicca l'interfaccia, prompt esatto | Ciao