Toma una interacción real y síguela hasta el final, porque el discurso abstracto —"un asistente que actúa, no solo responde"— no te dice nada hasta que lo ves ocurrir. Alguien escribe "hazme un rastreador de hábitos con rachas" en el botón Ask-AI que flota en cada página de este sitio. Esto es lo que ocurre realmente entre esa frase y un build en marcha, y dónde decidimos volver a poner una mano humana sobre el volante.
La frase
Nueve palabras, sin puntuación, sin navegar menús, sin siquiera saber en qué página vive el builder. Esa es la entrada, y tiene la misma forma que la mayoría de las solicitudes que recibe esto: no es una orden, es un deseo. Nadie lo redacta como "abre el builder, nombra el proyecto Habit Tracker, completa el campo de prompt con una descripción del seguimiento de rachas, y pon el foco en el botón de inicio". Simplemente dicen lo que quieren que exista. La brecha entre esas dos formas de expresarlo —deseo versus instrucciones— es toda la funcionalidad.
El análisis
En cualquier idioma en que llegue esa frase, se procesa en ese idioma —admitimos veinte en todo el producto, en línea con la postura multilingüe más amplia de la plataforma— y el asistente no ejecuta una capa de traducción sobre un guion fijo en inglés, razona de forma nativa en lo que sea que hayas escrito. Para "rastreador de hábitos con rachas" en concreto, el análisis debe hacer tres cosas a la vez:
- Reconocer que esto es una solicitud de build, no una pregunta
- Extraer un nombre de proyecto
- Extraer suficiente especificación para que el campo de prompt no quede vacío
Si falla en cualquiera de esos puntos, el usuario termina en un builder que no coincide con lo que pidió, lo cual es peor que no actuar en absoluto: ahora tiene que notar la discrepancia, luego corregirla, y luego empezar de nuevo.
La pantalla preparada
Esta es la parte fácil de subestimar en una demo y fácil de hacer mal en la práctica: no inicia el build. Abre el builder con el proyecto nombrado, el campo de prompt ya escrito, y la ejecución lista a un clic de distancia. Es un punto de parada deliberado, no un atajo que dejamos a medias por falta de tiempo. Abrir una página y prellenar un formulario es barato de deshacer si sale mal —en el peor caso, editas el texto o cierras la pestaña—. Así que el asistente simplemente lo hace, sin diálogo de confirmación, sin "¿estás seguro de que quieres navegar?".
El clic que seguía siendo tuyo
Iniciar el build es una categoría distinta, porque iniciar el build gasta créditos —reales, descontados de tu cuenta en el momento en que arranca la ejecución—. Ahí es donde entra en juego la regla proporcional:
| Tipo de acción | Qué ocurre |
|---|---|
| Barato de deshacer — navegación, texto preparado | Ocurre automáticamente, sin confirmación |
| Gasta dinero o cómputo real — iniciar el build | Espera un clic deliberado de tu parte |
Llegamos a esto tras darle muchas vueltas, y admito que ninguno de los dos extremos parecía obviamente correcto. Confirmar todo y habrás recreado la vieja experiencia de hacer clic en tres menús, con una ventana de chat encima, lo cual es peor que lo que reemplazaba. No confirmar nada y, eventualmente, el análisis se equivoca en una solicitud ambigua y dispara una ejecución que nadie pidió, con el dinero de otro. Para este ejemplo concreto, eso significa: el asistente te lleva al builder cargado de un solo golpe, y el botón que realmente gasta algo sigue siendo un clic humano, real y deliberado.
El riel de fondo
Hay algo que no puedes ver en ninguna parte de este flujo, y es precisamente por eso que importa: cada parte de él —la navegación, el prompt preparado, el build final— ocurre dentro de tu espacio de trabajo y de ningún otro. No hay forma de convencer al asistente de que se meta en el espacio de otro inquilino sin importar cómo se formule la solicitud, porque no es una función de chat con reglas especiales fuera del sistema de permisos: mecánicamente, es solo otro agente de la plataforma, ejecutándose bajo el mismo límite por cuenta que todos los demás agentes. No existe una pregunta aparte de "¿puede el chatbot ver esto?", porque la respuesta ya la había decidido la infraestructura antes de que existiera esta función de chat.
Lo que no ocurre
Sigue este mismo ejemplo un paso más y llegarás al límite de lo que el asistente hará sin que se lo pidas, y vale la pena precisar dónde está ese límite. Abrirá el constructor por ti. Más allá de eso:
- No gastará más de lo que ya aprobaste
- No publicará el proyecto terminado en ningún sitio bajo tu nombre
- No realizará ninguna acción que salga del sandbox de tu propio espacio de trabajo y afecte al mundo exterior
Toda esa categoría no tiene un camino guiado por el asistente: no hay una confirmación más estricta, no hay ningún camino en absoluto. Si quieres que un proyecto sea público, sigue siendo un botón que tú mismo buscas y pulsas, igual que siempre.
Por qué los puntos de parada están donde están, no en un lugar «más seguro»
Podríamos haber hecho que cada uno de estos pasos pidiera permiso y llamarlo prudencia. No creo que eso hubiera sido prudencia: creo que habría sido una versión más lenta del mismo trabajo tedioso que esta función existe para eliminar. Un chatbot que solo describe dónde está el botón de construir tiene un radio de impacto pequeño cuando se equivoca: te hace perder treinta segundos, te molesta un poco, no se gasta nada. Un asistente que prepara una construcción real se equivoca de forma más costosa si las salvaguardas no son correctas, y esa es la razón real por la que existe el paso de confirmar antes de gastar: no como una cobertura que añadimos para parecer responsables, sino porque observamos dónde caería el modo de fallo y pusimos la parada exactamente ahí. Todo lo anterior a esa línea —leer la frase, preparar la pantalla, quedar a un clic de terminar— no necesitaba permiso alguno, porque nada de eso puede perjudicarte.
