Vibe coding: crear tu propia herramienta sin saber programar

Hay un momento reconocible: llevas cuarenta minutos peleándote con una hoja de cálculo que hace algo que no debería hacer una hoja de cálculo, y piensas «esto debería ser un botón». Antes, ese pensamiento moría ahí. Ahora describes el botón en un chat y, veinte minutos después, existe.

Esta guía va de esa distancia entre «existe» y «puedo confiar en ello», que es donde está todo lo interesante.

Qué es y de dónde sale el nombre

El término lo acuñó Andrej Karpathy a principios de 2025 para describir, medio en broma, una forma de programar en la que aceptas el código sin leerlo: le cuentas al modelo la sensación de lo que quieres, pruebas, dices «no, así no» y vuelves a probar. El chiste cuajó, el Collins Dictionary lo nombró palabra del año 2025 y hoy describe algo bastante concreto: construir software sin leer el código que lo hace funcionar.

Conviene separar dos cosas que se confunden todo el rato:

• Programar con ayuda de IA. Alguien que sabe leer código lo revisa, lo corrige y decide. La IA escribe más rápido, pero el criterio sigue siendo humano. De eso va la comparativa entre Claude Code y Cursor.
• Vibe coding de verdad. Nadie lee el código. El único criterio es si al probarlo hace lo que querías. Es lo que hace la mayoría de la gente sin perfil técnico, y es de lo que va esta guía.

La segunda funciona sorprendentemente bien dentro de unos límites muy concretos, y falla de formas que no se ven hasta que es tarde. Saber dónde está esa frontera es la mitad del trabajo.

Qué sale bien y qué no, por tipo de herramienta

No es una cuestión de dificultad técnica, sino de qué pasa cuando se rompe. Ordenado de más a menos rentable:

La línea está clara: mientras los datos no sean de otras personas y el fallo lo pagues tú, construye sin miedo. En cuanto aparece un tercero —un compañero, un cliente, un dato personal— cambia la conversación, y no por purismo técnico sino porque cambian tus obligaciones. Esa parte la cubre la guía sobre datos de clientes.

Un buen primer proyecto para perder el miedo, aunque no sea una herramienta de trabajo, es un juego sencillo: se rompe sin consecuencias y enseña el mismo método de pedir, probar y corregir. Lo contamos en crear un videojuego con IA.

Con qué se hace: tres niveles

Consejo poco intuitivo: empieza por el primero aunque quieras llegar al segundo. Quien arranca en un constructor de apps acaba con un proyecto de siete pantallas que no entiende y que no sabe arreglar. Quien arranca pidiéndole al chat un script de veinte líneas aprende lo que de verdad importa —cómo describir bien lo que quiere y cómo comprobar el resultado— sobre algo que cabe en la cabeza.

Si el salto al tercer nivel te interesa, la guía de instalación de Claude Code asume que no eres desarrollador.

Tu primera tarde, paso a paso

Elige una tarea repetitiva que hagas a mano y que no toque datos de nadie. Después:

1. Describe el resultado, no la solución. «Tengo una carpeta con facturas en PDF y necesito una hoja con fecha, proveedor e importe de cada una» funciona mucho mejor que «hazme un script en Python con pdfplumber». Tú sabes el problema; deja que elija las piezas.
2. Da un ejemplo real. Una factura de muestra, tres filas de tu hoja, una captura del documento. Un ejemplo concreto ahorra cuatro rondas de correcciones, y esto vale para cualquier prompt, no solo para código: lo desarrolla la guía de prompts efectivos.
3. Pide instrucciones de instalación para alguien que no programa. Explícitamente. Si no lo pides, dará por supuesto medio entorno de desarrollo.
4. Pruébalo con un caso que sabes de memoria. Una factura cuyo importe conoces. Si ese sale bien, prueba el caso raro: la que tiene dos páginas, la que está escaneada torcida, la que viene en otro idioma.
5. Cuando falle, pega el error entero. Sin resumirlo ni pedir perdón. El texto rojo que asusta es exactamente la información que necesita el modelo.
6. Guarda el prompt que funcionó. Es más valioso que el código: con él puedes reconstruirlo, adaptarlo o pasárselo a otra persona. Guardarlo como skill o proyecto es lo que convierte el experimento en algo reutilizable.

Una tarde honesta son dos o tres horas. Si a la segunda hora sigues sin nada que funcione, casi siempre es porque el objetivo era demasiado grande, no porque no sepas hacerlo.

El muro del 80 %

Esto es lo que nadie enseña en los vídeos: las primeras dos horas son eufóricas y las siguientes veinte son otra cosa. El patrón se repite tanto que conviene esperarlo.

Llegas rápido a algo que hace lo principal. Y entonces empiezan los casos que no habías contado: el archivo vacío, el nombre con tilde, el usuario que pulsa dos veces, el mes que tiene 28 días. Cada arreglo es fácil. El problema es que arreglar el séptimo rompe el tercero, y como no lees el código no tienes forma de saberlo hasta que alguien te lo dice.

Tres cosas que sí ayudan:

• Apunta tus casos de prueba en una lista y repásalos enteros después de cada cambio. Cinco minutos. Es la única red de seguridad que tienes sin leer código.
• Guarda una copia de la versión que funcionaba antes de pedir el siguiente cambio. Una carpeta con la fecha basta. La mitad de los desastres se arreglan volviendo atrás.
• Empieza conversación nueva cuando la cosa se vuelva tonta. A partir de cierto punto el modelo olvida decisiones de hace veinte mensajes y reintroduce fallos que ya habíais arreglado. No es impresión tuya: le pasa a todos los modelos y lo explica la guía sobre la ventana de contexto. Abre un chat limpio, pega el código actual y describe solo el cambio que quieres.

Lo que la IA no te avisa de que ha hecho mal

El código generado por IA funciona y es inseguro con una frecuencia incómoda. Los análisis públicos de los últimos dos años coinciden en el orden de magnitud: cerca de la mitad del código generado no pasa comprobaciones básicas de seguridad, y los repositorios públicos registraron en 2025 el mayor salto interanual de credenciales filtradas del que hay registro.

No hace falta entender de seguridad para evitar lo peor. Cuatro preguntas, formuladas tal cual al modelo, cubren la mayor parte:

Y una regla que no admite matices: si la herramienta va a estar accesible desde internet y guarda datos de personas, que la mire alguien con criterio técnico antes. Una hora de revisión cuesta menos que cualquiera de las alternativas.

Cuándo no deberías construirlo tú

Cuatro señales de que la respuesta correcta es comprar, contratar o no hacerlo:

• Ya existe y cuesta 15 € al mes. Construir la versión mala de algo que ya está resuelto es el error más caro, porque el coste aparece después, cuando eres tú quien tiene que mantenerlo.
• El problema real es que tus herramientas no se hablan. Eso es automatización, no software nuevo, y se resuelve más rápido y con menos superficie de fallo: n8n, Make y Zapier.
• Va a tocar dinero, nóminas o datos de salud. No por la dificultad, sino por lo que pasa cuando se equivoca en el caso número 300.
• Alguien más va a depender de ello dentro de seis meses. Todo lo que un equipo usa a diario necesita alguien que lo arregle cuando se rompa. Si ese alguien eres tú y no lees el código, acabas de crearte un trabajo que no querías.

Dicho todo lo anterior: la mayoría de lo que la gente necesita en su día a día son scripts pequeños y calculadoras internas que no llegan a ninguna de estas cuatro líneas. Ahí el vibe coding no es un experimento, es la forma más rápida de resolverlo. Y si quieres saber si de verdad te está ahorrando tiempo, mídelo antes de contarlo como victoria. Si lo que necesitas es una web para tu negocio y no una herramienta, sigue con crear una página web con IA.