Plataforma
Inspect-to-prompt para una entrega de software con IA seria
Haz clic en cualquier elemento de la app en marcha para referenciarlo en tu próximo prompt, así el cambio cae sobre lo que señalaste, no sobre lo que adivinó la IA.
Inspect-to-prompt es una función del Builder de Ciao que te deja hacer clic en cualquier elemento de la vista previa en vivo (un botón, una tabla, un gráfico o un campo de formulario) y referenciarlo directamente en tu próximo prompt. A diferencia de describir la interfaz con palabras y esperar que la IA cuente las mismas tarjetas que tú, inspect-to-prompt hace inequívoco el objetivo, así las ediciones caen delimitadas al componente seleccionado con un diff pequeño y revisable.
Publicado 2026-07-03 · Última actualización 2026-07-03
La mayoría de prompts fallidos son direcciones equivocadas, no malas ideas
«Haz más pequeña la tercera tarjeta» funciona hasta que la IA cuenta tarjetas distintas a las tuyas. Describir una interfaz de usuario con palabras es un ejercicio con pérdidas: tu «encabezado», el «encabezado» del modelo y el «encabezado» del código pueden ser tres cosas distintas. Entra ambigüedad, sale la edición equivocada, y pasas los tres prompts siguientes deshaciendo daños en elementos que nunca mencionaste.
Inspect-to-prompt elimina el problema de la dirección. La app corre en vivo junto al chat mientras se construye; haz clic en cualquier elemento de esa vista previa y quedará referenciado en tu próximo prompt. El Builder sabe exactamente a qué componente te refieres: sin contar, sin describir, sin negociar vocabulario.
Es una interacción pequeña con consecuencias enormes. El Builder empareja una conversación con una aplicación en marcha precisamente para que señalar sea posible: la vista previa no es un panel de demo, es un marco de referencia compartido entre tú y la IA.
Cómo funciona inspect-to-prompt
El ciclo tarda segundos, y es el mismo para un founder puliendo una landing page que para un ingeniero ajustando una tabla de administración.
1. Abre la vista previa en vivo
La aplicación corre junto a la conversación mientras se construye: componentes reales, estructuras de datos reales, clics reales.
2. Haz clic en el elemento que quieres decir
Un botón, una columna de tabla, un gráfico, un campo de formulario, una etiqueta suelta. La selección funciona sobre la app en marcha, no sobre una captura de pantalla.
3. Se convierte en parte de tu próximo prompt
El elemento seleccionado se referencia directamente en el prompt, así el Builder lo resuelve al componente exacto en el código.
4. Describe el cambio en lenguaje sencillo
«Convierte esto en un desplegable», «mueve esto encima del resumen», «esto solo debería mostrarse a administradores». El qué se queda en lenguaje natural; el dónde ya está resuelto.
5. La edición cae delimitada
El cambio apunta al componente seleccionado, produciendo un diff pequeño en una rama git real en lugar de una reescritura especulativa.
6. Verifica en el momento
La vista previa se actualiza junto al chat. Si aún no está bien, haz clic de nuevo: el deshacer y los checkpoints hacen barata la iteración.
Por qué importa
La precisión se acumula. Cuando las ediciones caen donde señalaste, bajan las iteraciones, se reducen los diffs y la revisión se vuelve más fácil: un revisor que confirma «cambió el botón seleccionado» trabaja más rápido que uno que audita una reescritura. Los cambios pequeños y delimitados son también justo lo que mejor saben filtrar Guardrails y QA.
También amplía quién puede dirigir el trabajo. Un founder, diseñador o cliente no necesita vocabulario de CSS para decir lo que quiere decir; señala la app en marcha. La brecha entre «persona que ve el problema» y «persona que puede expresar la corrección» se cierra a un clic.
Los equipos notan más la diferencia durante las rondas de feedback. Una llamada de revisión donde los cambios pedidos caen mientras la gente mira es una relación de producto distinta a una llamada que produce una lista de tickets para la semana siguiente.
Quién usa inspect-to-prompt
Cualquiera que pueda ver el problema ahora puede abordarlo con precisión:
- Founders y diseñadores — Pulen interfaces señalando, sin aprender la diferencia entre padding y margin.
- Agencias — Convierten feedback de cliente del tipo «mueve eso ahí» en ediciones exactas durante las llamadas de revisión, no después.
- Product managers — Dirigen cambios al elemento preciso del que se quejó un stakeholder, sin pérdida de traducción a un ticket.
- Desarrolladores — Delimitan las ediciones de IA con precisión para que los diffs sigan siendo pequeños y las revisiones rápidas.
Notas de seguridad y gobernanza
La precisión no relaja las reglas: los cambios señalados pasan las mismas verificaciones que los escritos.
- ✓ Las ediciones delimitadas producen diffs pequeños y revisables en ramas git reales.
- ✓ Cada cambio, señalado o escrito, pasa la revisión de políticas de Guardrails antes del merge.
- ✓ El registro de auditoría de solo adición registra juntos el prompt y el cambio resultante.
- ✓ El deshacer y la restauración de checkpoints hacen recuperable en segundos cualquier fallo.
- ✓ El control de acceso basado en roles gobierna quién puede editar y quién puede fusionar.
Describir cambios de UI: solo palabras frente a inspect-to-prompt
La comparación deja de ser sutil tras la primera tarde trabajando de las dos formas.
| Solo palabras | Inspect-to-prompt | |
|---|---|---|
| Apuntar | Depende de vocabulario compartido y de contar | Haz clic en el elemento exacto de la app en marcha |
| Iteraciones | Varios intentos mientras se afinan las descripciones | Menos: la referencia es inequívoca |
| Efectos secundarios | Las ediciones pueden caer en elementos parecidos | Delimitadas al componente seleccionado |
| Tamaño del diff | A menudo mayor que la petición | Pequeño y ligado a un elemento |
| Quién puede dirigir el trabajo | Personas con soltura en vocabulario de UI | Cualquiera que pueda señalar el problema |
Preguntas frecuentes
¿Inspect-to-prompt funciona en cualquier parte de la app?
Puedes seleccionar elementos en toda la interfaz en marcha (botones, tablas, gráficos, formularios, etiquetas) porque la vista previa en vivo es la aplicación real, no una imagen. La selección se resuelve al componente real en el código de React y TypeScript generado.
¿Necesito entender el código para usarlo?
No. Señalas el elemento y describes el cambio en lenguaje sencillo. El Builder gestiona el mapeo del elemento seleccionado al componente en el código, y el diff está ahí para quien sí quiera leerlo.
¿Y los cambios que afectan a muchos elementos a la vez?
Describe el patrón en el prompt («aplica este estilo a todas las tarjetas de resumen») o encola una secuencia de cambios delimitados con la cola de prompts. Inspect-to-prompt es para precisión; no te impide hacer cambios amplios cuando quieras.
¿Hay un registro de qué se seleccionó y cambió?
Sí. Cada cambio es un diff en una rama git, y el registro de auditoría de solo adición registra prompts, merges y despliegues. Los revisores pueden ver qué se pidió y qué cambió exactamente.
¿Inspect-to-prompt está incluido en los planes self-serve?
Sí, es una capacidad central del Builder, y los creadores individuales empiezan en self-serve con créditos. Los programas de producción serios empiezan en 10.000 USD al año.
Páginas relacionadas
Construye el software que antes tenías que esperar.
Inspect-to-prompt: haz clic en la UI, indica con precisión | Ciao