Emergent: vibe coding para quien no sabe programar

Le escribí una frase: "una web donde la gente apunte su nombre y su correo para una lista de espera, con un panel donde yo vea quién se ha apuntado".

Y me fui a hacer café.

Cuando volví había una web funcionando. Con formulario, con base de datos detrás, con un panel donde se veían las filas. No era bonita, pero funcionaba y estaba en internet. Yo no había escrito una línea de código ni había tocado nada más que esa frase.

Esto es Emergent, y llevo una semana entera dándole caña para saber si esto es lo que dicen que es o es otra demo bonita que se cae en cuanto le pides algo real.

¿Qué es Emergent y en qué se diferencia?

Emergent es un agente que construye aplicaciones a partir de lo que le describes. Le hablas en español, él decide la estructura, escribe el código, lo despliega y te devuelve un enlace que funciona.

La diferencia con lo que ya conoces está en dónde ocurre el trabajo.

Con las herramientas sin código clásicas tú montas la aplicación con el ratón: arrastras un formulario, conectas una tabla, configuras una vista. Tú haces el trabajo, la herramienta te quita el código. Con Emergent tú no montas nada. Describes el resultado y el agente hace el camino entero.

Y con Claude Code trabajas contra archivos en tu ordenador, con tu carpeta, tu terminal, tu control. Emergent vive en el navegador y se encarga también de la parte de subirlo a internet, que es justo la que más gente abandona.

Si esta distinción te suena a chino, tengo un post sobre qué es el vibe coding y otro que compara no-code frente a vibe coding con ejemplos concretos. Aquí voy directo a cómo se usa.

Paso 1: entrar y describir lo que quieres

Te registras con tu cuenta de Google y entras a una pantalla con un cuadro de texto grande. Eso es todo el interfaz al principio. Un cuadro y un botón.

Aquí viene el primer error que cometí. Escribí algo tipo "quiero una app para gestionar mis clientes". Cuatro palabras, expectativas de veinte.

Lo que salió fue genérico y no me servía. Porque "gestionar clientes" significa cosas distintas para cada persona, y el agente eligió una versión que no era la mía.

La segunda vez escribí esto:

"Una aplicación donde yo pueda dar de alta clientes con nombre, correo, teléfono y estado (contactado, propuesta enviada, cerrado, perdido). Quiero una lista con filtro por estado y poder editar cada cliente. Solo entro yo, con contraseña."

Cuatro líneas. Y lo que salió ya se parecía a lo que tenía en la cabeza.

La regla es sencilla: nombra los campos, nombra los estados y di quién entra. Con eso el agente ya no tiene que adivinar.

Paso 2: mirar cómo trabaja (y no interrumpirlo)

Cuando le das a enviar, empieza a trabajar delante de ti. Va escribiendo lo que hace: crea el proyecto, define la base de datos, monta las pantallas, arranca el servidor.

Tarda. Depende de lo que le pidas, entre tres y quince minutos para la primera versión. Esto no es un chat que responde en dos segundos, es un agente que ejecuta muchas tareas seguidas.

Mi consejo: déjalo. La primera vez me puse a escribirle correcciones mientras trabajaba y lo único que conseguí fue liarlo. Espera a que termine y a que te dé el enlace. Luego corriges.

Paso 3: el primer vistazo y las correcciones

Te da un enlace. Lo abres y ahí está tu aplicación, funcionando, en internet.

Y aquí es donde empieza el trabajo de verdad, porque la primera versión nunca es la buena. Nunca. Con Emergent, con Claude Code, con lo que sea.

Las correcciones se piden como se pediría a una persona:

"El botón de guardar no se ve en el móvil, hazlo más grande y ponlo abajo del todo."

"Cuando marco un cliente como cerrado, quiero que se ponga en verde en la lista."

"Falta un campo de notas, un texto largo, en la ficha de cada cliente."

Cada corrección es un ciclo nuevo. Tarda menos que la primera vez, entre uno y cinco minutos. Y aquí es donde ves si el agente ha entendido tu proyecto o no: si le pides un cambio pequeño y te reescribe media aplicación, mala señal. En mi prueba se portó bien en cambios visuales y en añadir campos, y se puso raro cuando le pedí cambiar la lógica de permisos a mitad de camino.

Paso 4: los datos y la publicación

La parte que más me sorprendió: la aplicación viene con base de datos desde el minuto uno. No tienes que conectar nada externo ni configurar credenciales.

Eso es una ventaja enorme al principio y una atadura después. Los datos viven dentro de su plataforma. Si un día quieres llevarte el proyecto a otro sitio, tendrás que exportar y rehacer parte del montaje. No es imposible, pero no es un clic.

La publicación es un botón. Le das y la aplicación queda en una dirección pública que puedes compartir. Para una lista de espera, un formulario interno o una herramienta que usan cinco personas de tu equipo, esto es todo lo que necesitas.

Lo que se te va a atascar

Los proyectos con muchas reglas. Si tu aplicación necesita quince reglas de negocio distintas ("si el cliente es de este tipo y ha pagado más de tanto, entonces..."), el agente empieza a perder hilos. Funciona bien hasta cierta complejidad. Pasada esa raya, cada corrección rompe algo que ya funcionaba.

Los cambios de opinión a mitad. Si arrancas describiendo una cosa y a los diez mensajes quieres otra distinta, sale mejor empezar de cero con la descripción buena que arrastrar el proyecto a base de parches. Es contraintuitivo, pero se pierde menos tiempo.

El consumo. Cada ciclo del agente consume créditos. Mi primera tarde me los fundí probando tonterías porque cada "cambia el color del botón" es un ciclo completo. Agrupa los cambios: pide cinco correcciones en un solo mensaje en vez de cinco mensajes.

El diseño. Lo que sale funciona, pero tiene la cara de todo lo que sale de estas herramientas. Si lo vas a enseñar a clientes, cuenta con dedicar varios ciclos solo al aspecto, o con que alguien le meta mano después.

Lo que no ves. El código existe, pero tú no lo estás mirando. Si algo va mal por dentro (una consulta lenta, un dato que se guarda mal) te vas a enterar tarde y solo si te da la cara. Para una herramienta interna me da igual. Para algo con datos de clientes de verdad, me lo pensaría.

¿Para quién sí y para quién no?

Sí, si quieres validar una idea esta semana. Si necesitas una herramienta interna para tu equipo. Si tienes un proceso que ahora mismo vive en una hoja de cálculo compartida y se está cayendo a pedazos. Si nunca has programado y lo que te frena no es la idea sino no saber ni por dónde se empieza.

No, si el proyecto va a crecer durante años y tú quieres control del código. No, si manejas datos sensibles de terceros y necesitas saber exactamente dónde y cómo se guardan. No, si ya sabes moverte con Claude Code, porque ahí tienes más control por el mismo esfuerzo.

Yo lo veo como lo que es: la forma más rápida que existe hoy de pasar de una frase a una cosa que funciona en internet. Y eso, para validar, no tiene precio. Lo que salga de ahí y merezca la pena seguir vivo, ya lo moveré a otro sitio con calma.

Si quieres el mapa completo de opciones para crear aplicaciones sin programar, ahí están todas comparadas.

Algunos enlaces de este artículo son de afiliado: si contratas la herramienta, me llevo una comisión sin que a ti te cueste más.

Si no tienes claro por dónde meterle mano a la IA en tu caso concreto, el test te da una ruta según lo que ya sabes hacer.

Hacer el test de IA