26 puntos por spilist2 2025-04-23 | 7 comentarios | Compartir por WhatsApp

En las últimas semanas hice entre cinco y seis apps sencillas junto con conocidos no desarrolladores (abogados, marketers, PM, etc.) usando vibe coding

Organicé ese proceso y armé una “guía de iniciación al vibe coding para personas no desarrolladoras” en 5 pasos

  1. Entender, a grandes rasgos, hasta dónde puede llegar la IA hoy en día
  2. Definir con claridad el problema que quieres resolver y el producto que quieres crear
  3. Verificar rápida y frecuentemente con tus propios ojos cómo funciona el resultado
  4. Interactuar con la IA mediante prompts para que pueda programar bien
  5. Detectar comportamientos anómalos y puntos de mejora, corregirlos y cerrar el trabajo

1) Entender, a grandes rasgos, hasta dónde puede llegar la IA hoy en día

A quienes son no desarrolladores y están teniendo su primer contacto con el vibe coding, les recomiendo empezar con actividades como estas

  • Probar por cuenta propia que se puede crear algo funcional con un prompt corto en un LLM o en un servicio de prototipado con IA para ganar confianza en lo que esto puede hacer
  • Suscribirse a algunas cuentas de redes sociales y newsletters que recopilan y explican novedades de IA
  • Dejar de lado la ambición de absorber toda la información y todas las herramientas de IA, y mejor explorar solo herramientas relacionadas con temas específicos que te interesen

2) Definir con claridad el problema que quieres resolver y el producto que quieres crear

  • Aunque ya entiendas de lo que es capaz la IA, si la definición del problema no es clara, no podrás crear un producto
  • Por eso primero tengo que volverme más lúcido haciéndome preguntas que eleven mi metacognición
  • Usar una app de metacognición creada con vibe coding
    1. ¿Qué quiero crear?
    2. ¿Por qué quiero crearlo? ¿Qué problema estoy intentando resolver?
    3. ¿Quién tiene ese problema?
    4. ¿En qué situación aparece ese problema para esas personas?
    5. ¿Qué solución temporal o alternativa usan ahora en esa situación?
    6. ¿Cómo puedo comprobar que la opción 1 resuelve mejor el problema que la opción 5?
    7. ¿Qué tendría que hacer para que esas personas quieran usar la opción 1 en lugar de la 5?
  • Una vez que queda claro qué quiero crear, tomé el “prompt para generar PRD” creado por esa app y se lo pasé a un LLM para que generara el PRD

3) Verificar rápida y frecuentemente con tus propios ojos cómo funciona el resultado

  • El mayor punto fuerte del vibe coding es poder tener una “app funcional” en una etapa muy temprana. También es algo muy importante para motivar a personas no desarrolladoras
  • En ese sentido, no recomiendo mucho que una persona no desarrolladora empiece su vibe coding con Cursor. Creo que hay demasiados obstáculos grandes y pequeños antes de llegar a ejecutar la app
  • En cambio, me parecen un mejor punto de partida servicios como Lovable, donde al darles un PRD aparece un prototipo funcional. Además generan enseguida un enlace público, lo que facilita mostrárselo a conocidos y recibir feedback
  • Eso sí, si la app que quieres crear no está basada en web, la cosa se complica un poco más, porque las herramientas de prototipado suelen crear web apps
  • En ese caso hace falta tomar decisiones técnicas y configurar el entorno de ejecución, y para eso tanto la IA como yo tenemos que volvernos más inteligentes

4) Interactuar con la IA mediante prompts para que pueda programar bien

  • Yo me vuelvo más inteligente <-> diseño mejores prompts <-> los resultados salen más rápido y mejor <-> la IA también se vuelve más inteligente
  • Cuanto mejor diseñas los prompts, menos intercambios de ida y vuelta (= tiempo y dinero) hacen falta para lograr el objetivo
  • Si revisas distintas guías de prompt engineering, casi todas coinciden en que dentro del prompt hay que definir bien el rol (Role), el contexto (Context) y la tarea (Task)

Rol, contexto y tarea

  • En vibe coding, el “rol” no es tan importante
    • Porque los agentes de programación ya suelen tener definido un rol adecuado y meter otro puede enredar las cosas
    • Y quizá porque programar es un benchmark importante, incluso los LLM suelen programar bien sin necesidad de asignarles un rol
    • Claro, si la app que quiero crear es especial, también puede ser buena idea asignar un rol apropiado
  • Con el “contexto” basta con haber construido bien el PRD
  • La “tarea” consiste en definir bien el objetivo y los criterios de finalización. Esos criterios pueden
    • Estar explícitos dentro del prompt (como en few-shot prompting)
    • Estar definidos en archivos externos o en el código (TODOs.md o tests)
    • Estar solo en mi cabeza (y ese estilo no es nada bonito)
  • El objetivo final del vibe coding es darle instrucciones a la IA para que programe bien y crear rápidamente una app que funcione según el PRD. Para eso conviene fijar 3 metas intermedias
    • Yo me vuelvo más inteligente
    • La IA se vuelve más inteligente
    • La funcionalidad opera según la especificación

¿Yo me vuelvo más inteligente?

  • Si no eres desarrollador, si el dominio te resulta desconocido o si el stack tecnológico te es ajeno, te costará dar instrucciones con terminología precisa
  • En ese caso basta con reconocer ante el LLM lo que no sabes y aprender de él
    • “(Le doy una captura) ¿Con qué se suelen hacer juegos como este?”
    • “Quiero crear algo así, ¿cómo crees tú que conseguirías los datos?”
    • “Si quisiera comprobar lo más rápido posible el funcionamiento clave de una app nativa, ¿qué tecnología debería usar?”
  • A través de este tipo de preguntas, conviene observar si estás cambiando de esta manera
    • Palabras clave técnicas: ya estoy usando correctamente los términos técnicos y del dominio
    • Flujo de datos: puedo explicar cómo se obtienen, procesan y muestran los datos necesarios para la funcionalidad principal de mi app
    • Entorno de ejecución: ya preparé un entorno en el que puedo correr el código generado por la IA y comprobar con mis propios ojos si funciona
  • Idealmente, lo mejor sería despejar todos los unknown unknowns antes de escribir el PRD y empezar a programar, pero no es obligatorio
  • También se aprende mucho una vez que ya entras a programar y, si algo sale mal, siempre puedes volver a construir desde cero. (Incluso puede ser más rápido que corregir algo ya existente)

¿La IA se vuelve más inteligente?

  • Significa darle a la IA, por ejemplo como system prompt (Cursor Rules, etc.), las palabras clave técnicas o el flujo de datos que ya identificaste
  • Para reducir la cantidad de veces que tengo que intervenir y hacer que el código de la IA me guste más, hacen falta sobre todo dos cosas: restricciones y pautas de documentación
  • Las pautas de restricciones ayudan a que la IA escriba código más consistente. Por ejemplo:
    • Stack tecnológico: usa NextJS app router, estiliza con Tailwind y ShadCN, usa solo íconos de Lucid, usa Stripe para pagos, etc.
    • Estructura y patrones: organiza las carpetas así, nombra los archivos de esta manera, dale al UI un estilo tipo Material, etc.
    • Formato de salida (según el entorno de ejecución): voy a usar Electron Fiddle, así que dame 4 archivos acordes a eso; voy a usar CodePen, así que dame un HTML, un CSS y un JS, etc.
  • Las pautas de documentación ayudan a mejorar la concentración y la memoria de la IA. Hubo dos ideas especialmente útiles
    • Memory Bank de Cline: definir un flujo de trabajo donde se registran en archivos las tareas hechas y las pendientes
    • Prompt Context de Kang Dong-yoon: en vez de dejar instrucciones largas sobre todo el proyecto en la carpeta raíz, crear instrucciones por carpeta
  • Como con Memory Bank es más fácil observar y aprender qué está pasando en cada momento, lo recomiendo especialmente para personas no desarrolladoras

¿La funcionalidad opera según la especificación?

  • Esta ya es una estrategia de prompting a nivel de chat (dentro del agente de programación), no del proyecto completo
  • Creo que la mejor estrategia para lograr que una funcionalidad opere según la especificación es si pasa los tests, se hace commit
    • “Implementa X. Escribe primero los tests, luego programa, después ejecútalos y sigue corrigiendo el código hasta que todos pasen.”
  • Esto es posible porque el agente de programación tiene permisos y capacidad para escribir tests, ejecutarlos en la terminal y leer los resultados
  • Una vez que los tests pasan, puedes pedir una propuesta de mensaje de commit y hacer commit del código funcional junto con el código de prueba. Yo hago los commits manualmente, pero el agente también puede hacer commit automático
  • No solo tests unitarios: la IA también puede escribir tests de integración y E2E, ejecutarlos y corregir por sí sola lo necesario (referencia: automatización de tests con Cursor + Playwright)
  • Todo esto es una estrategia para que tanto quien hace vibe coding como la IA puedan comprobar más fácilmente si cada funcionalidad está implementada según la especificación y si la app completa funciona según el PRD

5) Detectar comportamientos anómalos y puntos de mejora, corregirlos y cerrar el trabajo

  • El vibe coding, tal como yo lo veo, está muy lejos de ser algo de “un clic” y requiere aprender muchas cosas
  • Entre todo eso, hay 3 capacidades que considero esenciales para pasar de “mi pequeño prototipo personal” a una app con nivel de producto comercial como fundador en solitario: capacidad de observación, capacidad de programación y capacidad de product engineering

Capacidad de observación

  • Detectar con sensibilidad las pantallas o funciones que operan distinto a lo que dice el PRD (o a mi intención original)
  • Si esto te falta, se vuelve muy difícil encontrar los errores de la IA y pedirle que los corrija
    • Los “tests” del paso 4 no solo reducen desde el inicio los errores de la IA, también ayudan a fortalecer mis propias capacidades
    • Porque al leer cómo la IA transforma la especificación en código de prueba, puedes aprender no solo “esta función hace falta”, sino “para completar esta función hacen falta estas condiciones”
  • Pero “la app está implementada según la especificación” y “la app es buena” no son lo mismo. Por eso es importante el “product sense” para encontrar mejoras (para más detalle, ver la newsletter de Lenny enlazada)

Capacidad de programación

  • Al menos por ahora, por muy bien que dividas el trabajo y se lo delegues a la IA, siempre queda alrededor de un 5% que hay que tocar a mano para poder cerrar el producto
    • En redes sociales sobran las apps que se quedan en un 80% y nunca salen, precisamente porque sus creadores no pudieron hacer esa parte
  • Claro, ese porcentaje puede variar según la app que quieras construir, y tampoco es imposible implementarla hasta el final solo con IA, pero sería demasiado ineficiente
  • Más que abandonarte por completo al vibe, recomiendo estudiar también la programación observando la documentación que genera la IA (Memory Bank, tests, etc.). Incluso recibir coaching de desarrolladores
  • En particular, aprender sobre backend, que suele ser menos visible (autenticación de usuarios, integración con APIs externas, entrada y salida de datos, pagos, etc.), y sobre estrategia de despliegue (rama principal y ramas de feature, manejo de variables de entorno, etc.) puede tener un impacto muy grande

Capacidad de product engineering

  • Lanzar una app no es el final, sino el comienzo. Si quieres hacerlo bien, necesitas entender todo el ciclo de vida del desarrollo de producto
    • Identificación del problema, ideación de soluciones, planificación, diseño, implementación, testing, despliegue, promoción, monitoreo de errores, recolección de feedback, operación...
  • Aunque no profundices a fondo en todas estas etapas, por lo menos conviene saber qué se hace en cada una y qué palabras clave se usan
  • Solo así podrás aprender lo que no sabes y reconocer las capacidades de los colegas con quienes podrías colaborar cuando no te alcance hacerlo solo

Para cerrar

  • Convertir una app hecha con vibe coding en un producto de nivel comercial no es nada fácil. Pero nadie puede negar que “empezar” es hoy más fácil que nunca
  • Ver a conocidos emocionarse al contemplar cómo una pequeña idea suya cobra vida (“¡Wow, no puedo creer que yo esté programando!”) también me hizo muy feliz
  • A otras personas no desarrolladoras que lean este texto, también les recomiendo aprovechar esta oportunidad para convertirse alegremente en “makers”
  • Si aprovechan su propia experiencia de dominio para crear (con vibe coding) herramientas pequeñas, rápidas y útiles que resuelvan de forma sobresaliente un problema específico, creo que también podrán ser muy competitivos en la era de la IA

7 comentarios

 
jk34011 2025-04-25

Vaya~ pensaba que el vibe coding era pura ilusión.
Hace tiempo que no veía un texto escrito con este nivel de profesionalismo.
Lo leí con mucho gusto.

 
spilist2 2025-04-25

¡Gracias! Veo un gran potencial, jaja.

 
jk34011 2025-04-25

Ah;; ahora que lo veo, mi comentario sí quedó medio raro.
Más que decir que es una ilusión, creo que la sensación es que todavía le falta bastante.
Al final siento que el vibe coding tiene límites y que sin conocimientos de desarrollo se vuelve difícil.
Claro, también creo que a medida que la IA avance, después va a mejorar muchísimo.

Me pareció que mi comentario podía sentirse como si estuviera diciendo que el vibe coding no tiene sentido, así que vengo a responder de nuevo y a explicar un poco más.
Yo también uso mucho el vibe coding jaja

 
spilist2 2025-04-26

Ah, no, para nada jaja. Yo también entendí el matiz que mencionaste.

Así que, como escribí en el texto, el "vibe coding" del que hablo está lejos de ser solo hacer clic y ya, y creo que si quieres llevarlo a un nivel más alto, el ingeniero tiene que esforzarse mucho.

 
bbulbum 2025-04-23

Siempre lo leo con mucha atención.

 
spilist2 2025-04-23

¡Gracias!

 
spilist2 2025-04-23

También hice un video para YouTube jaja https://www.youtube.com/watch?v=ecY5VBpruOA