Ejemplos de programación en Vibe: 6 proyectos prácticos para explorar

Introducción

La programación Vibe permite que casi cualquier persona describa una idea en lenguaje sencillo y obtenga a cambio una primera versión funcional, primando la rapidez frente al extenso proceso de ingeniería que requeriría una compilación tradicional. Sin embargo, saber por dónde empezar realmente es otro problema, sobre todo para los equipos acostumbrados a enviar un ticket y esperar a que se realice la compilación.

La programación Vibe puede materializarse en forma de maqueta visual rápida, un prototipo funcional o una pequeña prueba de concepto, dependiendo de lo que se intente aprender. Este artículo repasa seis ejemplos que los profesionales pueden probar. Se trata de proyectos ilustrativos que cualquiera podría crear, no de productos terminados ni comerciales.

6 ejemplos prácticos de «vibe coding» para equipos empresariales

El uso de herramientas de IA para el «vibe coding» permite generar rápidamente código ejecutable y componentes de aplicaciones a partir de descripciones sencillas de los usuarios, pero es importante familiarizarse con el proceso antes de lanzar nada. Estos seis ejemplos, del tipo de proyectos con los que la gente se encuentra en el trabajo, van desde los más sencillos y visuales hasta los más complejos, más cercanos a algo que cuenta con datos reales y una lógica de flujo de trabajo detrás. Cada uno de ellos parte de una necesidad empresarial, repasa un ejemplo de solicitud y un posible primer resultado, y termina indicando qué hay que comprobar antes de seguir adelante.

1. Visualizar una página de destino antes de crearla

Convertir el concepto de una página en algo sobre lo que el equipo pueda reaccionar suele implicar una espera en el tiempo de desarrollo que nadie tiene. La programación intuitiva se salta esa espera. Una sola indicación puede generar un diseño funcional con jerarquía y flujo reales, lo que proporciona al equipo algo concreto sobre lo que debatir, en lugar de un resumen escrito que cada persona interpreta de forma diferente.

Ejemplo de indicación: «Crea una página de destino para propietarios de pequeñas empresas que estén considerando [producto]. Incluye una sección principal con un titular y una llamada a la acción (CTA), tres tarjetas de ventajas, una sección de testimonios y una tabla comparativa de precios. Haz que el botón de llamada a la acción (CTA) permanezca fijo mientras el visitante se desplaza por la página».

Posible primer resultado. Una sola página funcional con un diseño y un espaciado reales, aunque el texto y las imágenes sean marcadores de posición, es suficiente para evaluar la jerarquía y el flujo antes de que llegue al primer usuario.

Qué hay que comprobar a continuación. Aún quedan por hacer la aprobación del texto, la revisión de accesibilidad, las directrices de marca y la implementación real. Una maqueta interactiva permite comprobar si la estructura funciona, no si está lista para su publicación.

2. Probar un selector de productos interactivo

Las gamas de productos complejas son difíciles de explorar. Ayudar a los clientes a dar con la opción adecuada suele implicar una larga lista de filtros o muchas conjeturas. Una indicación puede generar un flujo de cuestionario guiado en cuestión de minutos, planteando unas cuantas preguntas y orientando a los clientes hacia una recomendación antes de que nadie acceda al catálogo real.

Ejemplo de prompt: «Crea una aplicación web de selección de productos que plantee tres preguntas sobre el uso previsto, el presupuesto y el espacio disponible, y que luego recomiende uno de cinco tipos de productos con una breve explicación para cada recomendación».

Posible primer resultado: un flujo de cuestionario funcional con una lógica de recomendación provisional, suficiente para recorrer todas las rutas y ver adónde conduce cada respuesta.

Qué comprobar a continuación. Esto pone a prueba la interacción, no la precisión de las recomendaciones. Las preguntas confusas o las rutas sin salida se detectan rápidamente. Los datos reales del producto, la lógica de recomendación y la disponibilidad de existencias aún deben verificarse por separado antes de que la herramienta acceda al catálogo activo.

3. Explora un panel de control con datos de muestra

No todas las ideas de informes necesitan un flujo de datos completo antes de que se sepa si el diseño resulta realmente útil. Una indicación puede crear un panel de control construido íntegramente a partir de registros inventados, uno en el que las partes interesadas puedan navegar y responder de inmediato.

Ejemplo de comando: «Crea un panel de control utilizando datos de muestra de 50 solicitudes de asistencia. Incluye tarjetas de resumen con el recuento de solicitudes abiertas, en curso y resueltas, un filtro por prioridad y equipo asignado, y una tabla que muestre el tiempo medio de respuesta por categoría».

Posible primer resultado. Un panel de control funcional que las partes interesadas pueden filtrar y al que pueden reaccionar de inmediato, utilizando registros inventados en lugar de datos extraídos de un sistema en producción.

Qué comprobar a continuación. Un panel de control convincente creado a partir de datos de muestra no ha abordado de dónde procederán los datos en producción, si se alimentará de una base de datos real, con qué frecuencia se actualizará o si las cifras realmente significan lo que la gente supone.

4. Crear un prototipo del flujo de trabajo de incorporación de proveedores

La incorporación de proveedores suele estar dispersa entre hilos de correo electrónico, hojas de cálculo y la memoria de quien sea que recuerde el último paso. Nadie se da cuenta de lo desorganizado que está hasta que alguien lo traza en un mapa. Una indicación puede generar pantallas interactivas que abarquen la incorporación, el seguimiento del estado y la aprobación, permitiendo que los equipos de compras y operaciones recorran juntos todo el proceso por primera vez.

Ejemplo de solicitud: «Crea un flujo de incorporación de proveedores con un formulario de envío para los datos de la empresa y los documentos requeridos, una vista de estado que muestre en qué fase se encuentra cada envío y una pantalla de aprobación para que los revisores acepten o rechacen una solicitud con comentarios».

Posible primer resultado. Pantallas que los equipos de compras y operaciones pueden recorrer juntos para detectar pasos que faltan o traspasos poco claros antes de comprometerse con nada definitivo.

Qué comprobar a continuación. Una versión definitiva requiere estructuras de datos consensuadas, reglas de acceso reales para cada rol, una gestión de documentos que cumpla con los requisitos de cumplimiento aplicables y conexiones con los sistemas que ya realizan el seguimiento de proveedores y pagos.

5. Crear una maqueta de la experiencia de cuenta de autoservicio

Los clientes no deberían tener que llamar a nadie solo para revisar un pedido o actualizar la configuración de una cuenta. Crear una infraestructura de cuentas real para poner a prueba esa hipótesis supone un gran compromiso inicial. Un conjunto de pantallas navegables, creado a partir de datos de muestra, puede responder a la pregunta de si los usuarios pueden realmente encontrar lo que necesitan mucho antes de que exista esa infraestructura.

Ejemplo de indicación: «Crea una experiencia de cuenta de cliente con un panel de control que muestre los pedidos recientes, una página para actualizar los datos de contacto y las preferencias de pago, y un formulario de solicitud de asistencia con un seguimiento del estado, utilizando cinco cuentas de cliente de muestra».

Posible primer resultado: pantallas por las que un usuario real pueda navegar utilizando datos de cuenta inventados, lo suficiente para comprobar si el diseño y las etiquetas tienen sentido.

Qué comprobar a continuación. Esto comprueba si los clientes pueden encontrar información y completar una tarea sin ayuda. La verificación de la identidad real, los permisos y las conexiones con el sistema de cuentas real, junto con cualquier aspecto relacionado con datos sensibles, constituyen un trabajo aparte que el prototipo no abarca.

6. Comprobar una idea de integración con una pequeña prueba de concepto

Es raro que dos sistemas coincidan en cómo deben estructurarse los datos. Descubrirlo a mitad de la integración resulta costoso. Con una prueba de concepto de alcance limitado, un desarrollador puede crear una pequeña función que transforme datos de muestra de un sistema al formato que espera otro sistema, respondiendo a la pregunta en una tarde en lugar de en una semana.

Ejemplo de consigna: «Dada esta respuesta JSON de muestra procedente del [sistema A], escribe una función que la transforme a la estructura de campos que espera el [sistema B]. Trata los campos que falten dejándolos en blanco y marca cualquier campo que no coincida con el tipo esperado».

Posible primer resultado: Lógica de transformación funcional del lado del cliente que gestiona correctamente la entrada de ejemplo, probada con unos cuantos registros de ejemplo en lugar de una conexión en tiempo real.

Qué comprobar a continuación. Un ejemplo satisfactorio no verifica cómo se comportan realmente las API en tiempo real , cómo se almacenan y renuevan las credenciales (como las claves de API), qué ocurre cuando falla una solicitud o quién mantiene la correspondencia una vez que cambian los sistemas de origen.

¿Qué puedes aprender al probar los ejemplos de Vibe Coding?

Cada uno de estos ejemplos te enseña algo diferente, pero la lección subyacente es la misma. Descubres si una idea se sostiene una vez que existe como algo real, y no solo como una descripción en una reunión. Describir lo que quieres en lenguaje natural a un agente de IA , revisar lo que te devuelve y volver a darle indicaciones hasta que funcione es la forma de conseguirlo.

El verdadero valor va más allá de la primera indicación. Ves la interfaz o el comportamiento real que genera. También aprendes qué hay que cambiar una vez que alguien reacciona ante ello. A veces, esa reacción apunta a la propia herramienta. La gente suele empezar con una herramienta para una revisión visual rápida y luego pasa a algo como Cursor o Claude Code cuando el código subyacente requiere una atención más profunda. Las herramientas de «vibe coding» y las plataformas «low-code» adoptan enfoques realmente diferentes en este sentido: unas se basan en indicaciones y código, y otras, en la configuración visual.

Ninguno de los ejemplos anteriores está terminado ni listo para su uso en producción. Son un punto de partida. Lo que aprendas de la primera versión determinará si merece la pena seguir adelante con el proyecto.

¿Cómo elegir un proyecto de programación con Vibe para probar?

Seis direcciones diferentes son muchas entre las que elegir. El proyecto adecuado depende de lo que realmente estés intentando aprender. Unas cuantas preguntas te ayudarán a acotar las opciones:

• ¿Qué intentas aprender? El diseño de una página, un flujo de usuario, una vista de informes, un flujo de trabajo o una conexión técnica requieren cada uno un tipo diferente de prototipo, ya que las distintas tareas exigen distintos tipos de comprobación.
• ¿Puedes empezar con datos de muestra? Utiliza información que permita a los usuarios evaluar la idea sin acceder a registros empresariales reales, para que el experimento no suponga un gran riesgo.
• ¿Quién debe reaccionar ante el resultado? Dependiendo de si el ejemplo va dirigido a clientes, partes interesadas de la empresa, diseñadores o desarrolladores, cambia lo que realmente se considera «útil».
• ¿Qué haría que el experimento resultara útil? Identifica una decisión concreta en la que deba servir de base, como por ejemplo si merece la pena seguir desarrollando un flujo de trabajo.

No se trata de que esto se convierta en una revisión de seguridad completa. Sin embargo, merece la pena tomárselo en serio. Un estudio de Veracode reveló que el 45 % de las muestras de código generadas por IA contienen fallos de seguridad. Una comprobación rápida ahora es mejor que una costosa más adelante.

¿Qué ocurre cuando un ejemplo se convierte en una aplicación duradera?

Elegir el prototipo adecuado que se va a desarrollar es solo la primera decisión. Lo que ocurre después es igual de importante. Algunos prototipos responden a la pregunta planteada y pueden descartarse en ese mismo momento. Otros revelan un flujo de trabajo que la empresa realmente quiere seguir utilizando.

Tomemos el ejemplo anterior de la incorporación de proveedores. Una vez que los usuarios empiezan a utilizarlo de forma habitual, el equipo necesita registros fiables, permisos claramente definidos, un proceso de aprobación real, integraciones que funcionen y alguien que se haga cargo de él en el futuro. Estos son los mismos requisitos que necesita cualquier flujo de trabajo operativo, independientemente de si la primera versión la escribió o no uno de los modelos de IA actuales .

Las capacidades «low-code» de Liferay DXP pueden dar respuesta a gran parte de ello. Los objetos gestionan los datos estructurados, los formularios se encargan de la recogida de datos, los flujos de trabajo gestionan los pasos de aprobación, y los permisos y las integraciones lo conectan con los sistemas ya existentes, lo que en la práctica constituye una capa de gobernanza en torno a lo que comenzó como un prototipo rápido. Es posible que algunas funcionalidades especializadas sigan requiriendo un desarrollo a medida y su propia revisión, especialmente cuando un equipo necesita añadir características que ninguna funcionalidad estándar cubre o desea tener más control sobre el comportamiento exacto de algo. La cuestión no es que Liferay DXP haya creado el prototipo original. Se trata de elegir la base adecuada una vez que el prototipo se convierte en algo de lo que la empresa depende realmente.

Empieza por la idea que necesitas probar

Empieza con una pregunta bien definida, no con una solicitud genérica para crear una aplicación. Las herramientas de IA gestionan rápidamente el código repetitivo, lo que explica en parte por qué el primer resultado, por muy rudimentario que sea, te ofrece algo sobre lo que reaccionar y que puedes perfeccionar de inmediato. Esa reacción suele ser más útil que el propio prototipo. Compártelo en una publicación rápida para recabar opiniones, o manténlo en privado, lo que te permita obtener una reacción sincera lo antes posible.

El verdadero valor de un ejemplo radica en hacer que una idea sea comprobable, independientemente de si llega a convertirse o no en una aplicación permanente. Si uno de estos experimentos se convierte en un flujo de trabajo que tu organización necesita ejecutar y mantener, explora las capacidades «low-code» de Liferay DXP para ver cómo podría ser una base regulada.

Preguntas frecuentes sobre ejemplos de «vibe coding»

¿De dónde viene el término «vibe coding»?

El investigador en IA Andrej Karpathy popularizó el término en 2025 para describir una forma de crear software partiendo de lo que se quiere conseguir, en lugar de escribir código línea por línea. El nombre se popularizó porque captaba algo real sobre la rapidez con la que una idea puede convertirse en una primera versión funcional.

¿Cuáles son algunos ejemplos sencillos de «vibe coding» para principiantes?

Una maqueta de una página de destino, una calculadora básica, juegos sencillos para el navegador o un panel de control con datos de ejemplo son buenos puntos de partida. Ninguno de ellos requiere conocimientos previos de programación para intentarlo. Cada uno tiene un objetivo concreto y te ofrece algo tangible que revisar y perfeccionar, en lugar de una idea abstracta. Empieza con una sola función en lugar de intentar crear una aplicación completa.

¿Se puede programar de forma intuitiva una herramienta interna de la empresa?

Sí, y a menudo es mejor empezar por ahí, ya que las herramientas internas tienen mayor tolerancia a los detalles sin pulir. Un sistema interno de seguimiento de solicitudes o un panel de control de informes podrían iniciarse fácilmente como un proyecto paralelo o un prototipo creado mediante «vibe coding». Sin embargo, «interno» no significa automáticamente bajo riesgo, una vez que la herramienta maneja datos de la empresa o pasa a formar parte de un flujo de trabajo habitual. El equipo debe revisar el acceso, la fiabilidad y la propiedad antes de depender de ella en el día a día. Cualquier deficiencia que se detecte en la revisión deberá subsanarse.

¿Qué debes incluir en una descripción para la programación intuitiva?

Especifica quién utilizará el proyecto, qué tarea debe facilitar, la información o los datos de muestra que necesita y qué debe suceder cuando los usuarios interactúen con él, todo ello en un lenguaje sencillo en lugar de con detalles técnicos. Incluye reglas importantes o casos extremos cuando sea pertinente. Siempre puedes perfeccionar el resultado mediante instrucciones de seguimiento tras probar la primera versión.

¿Están los ejemplos de código «vibe» listos para utilizarse con datos reales de clientes?

No. El código generado por IA suele requerir una revisión profesional antes de su lanzamiento. Un prototipo funcional no garantiza que su autenticación, permisos, gestión de datos o integraciones estén listos para su uso por parte de los clientes. Empieza con datos sintéticos y, a continuación, realiza una revisión técnica y de seguridad adecuada antes de conectar nada a registros reales.