Describir una idea, pedir a una inteligencia artificial que genere el código y probar el resultado. Si algo falla, devolverle el error y seguir haciendo cambios hasta que funcione. Así puede empezar una herramienta útil, incluso sin conocer en detalle cómo está construida.
Esta forma de desarrollar, conocida como vibe coding, facilita probar nuevas ideas y abre posibilidades a personas con distintos conocimientos técnicos. También plantea una pregunta: ¿qué ocurre cuando lo que hemos creado debe ser fiable, mantenerse y evolucionar?
Repasamos el origen del concepto y sus posibilidades con Roberto Gómez, Head of Frontend en MindDen, que comparte su perspectiva y los límites que pondría a esta práctica.
De dónde viene el vibe coding.
En febrero de 2025, Andrej Karpathy, investigador de inteligencia artificial, acuñó el término vibe coding. Describía una forma de programar en la que dejaba que la IA generara el código, él aceptaba cambios sin revisarlos y le devolvía los errores para que intentara corregirlos. Lo situaba en el terreno de los proyectos de bajo riesgo y la experimentación.
Poco después, el desarrollador Simon Willison, también conocido por ser el co-creador de Django, puso el foco en una distinción: programar con ayuda de IA no equivale necesariamente a hacer vibe coding. Si una persona revisa el código generado, entiende lo que hace y lo prueba de forma rigurosa, está desarrollando software con asistencia de IA. El vibe coding, en su sentido original, supone avanzar sin esa revisión, guiándose principalmente por el resultado visible.
Las herramientas pueden ser las mismas; lo que cambia es cómo trabajamos con ellas y cuánto conocemos lo que producen.
Simon Willison es el creador de Datasette, una herramienta de código abierto para explorar y publicar datos. Actualmente trabaja a tiempo completo desarrollando herramientas de código abierto para el periodismo de datos, basadas en Datasette y SQLite.
Antes de dedicarse al desarrollo independiente de código abierto, Simon fue director de ingeniería en Eventbrite. Se incorporó a Eventbrite tras la adquisición de Lanyrd, una empresa financiada por Y Combinator que él mismo cofundó en 2010.
Además es co-creador del framework web Django y escribe sobre desarrollo web y programación en su blog simonwillison.net desde 2002.
Un ejemplo de vibe coding: el plugin de traducción.
Gómez ha experimentado con este enfoque. Uno de los ejemplos que comparte es un plugin de traducción: consiguió desarrollarlo con ayuda de un agente y ha ido orientando las correcciones a partir del feedback del equipo.
Trabajar con el agente le ha permitido resolver una necesidad de forma rápida y cómoda. Al mismo tiempo, reconoce una limitación en su capacidad para diagnosticar lo que pueda ocurrir.
Al haber generado código de esta manera, no conozco cómo funciona internamente y si hubiera algún problema, seria mucho mas difícil diagnosticarlo y solucionarlo.
Describe el resultado como «rápido y cómodo, pero inestable». La limitación que identifica es concreta. Por una parte, ha conseguido una herramienta útil, pero no conoce en detalle su funcionamiento interno, lo que dificulta diagnosticar posibles problemas y abordar su mantenimiento.
Cuándo usar vibe coding: prototipos y tareas de bajo impacto.
Las pruebas de concepto, los prototipos, las demostraciones y las automatizaciones puntuales ofrecen un contexto para experimentar. Por ejemplo, presentar una idea para que otras personas puedan probarla o crear un pequeño script que ahorre tiempo en una tarea ocasional.
La recomendación para quien quiera empezar es acotar el uso:
Está bien para presentar una idea o probar a ver si tiene sentido. Para automatizar cosas del día a día que no tengan mucha importancia.
El vibe coding también se presenta como una oportunidad para quienes no se dedican al desarrollo, ya que “para perfiles que no son técnicos les puede servir para facilitar sus tareas, con cuidado”.
Ese cuidado implica pensar en las consecuencias de un posible fallo. Una aplicación pequeña puede manejar información sensible o realizar una acción difícil de deshacer. El tamaño del proyecto orienta la decisión, pero su uso y su impacto también importan.
En contextos de bajo riesgo, el vibe coding puede ayudarnos a explorar nuevas ideas y probar soluciones que quizá no llegaríamos a desarrollar de otra manera.
Limitaciones del vibe coding en aplicaciones a escala.
El escenario cambia cuando una herramienta empieza a formar parte de la operativa de una empresa. Debe responder de forma previsible, integrarse con otros sistemas y admitir modificaciones sin que cada cambio comprometa lo que ya funciona.
Aquí se sitúa una de las principales objeciones: Las aplicaciones a escala requieren mucha estabilidad porque con la escala no solo crecen los beneficios, también se multiplican los problemas.
Una ineficiencia apenas perceptible durante una prueba puede convertirse en un coste relevante cuando se repite miles de veces. Nosotros lo ilustramos con una comparación. No es lo mismo que un programa mal optimizado te haga perder céntimos en una prueba de concepto que le haga perder a un cliente miles de euros.
También crecen las dependencias y el número de personas afectadas por un fallo. En este contexto, Gómez cuestiona un enfoque basado en generar código e ir corrigiéndolo hasta que el resultado aparentemente encaje:
El vibe coding se da de bruces con esto, porque su objetivo es no pensar mucho en el código: generar rápido, ver si todo parece encajar y, si no, pues más vibe coding hasta que encaje.
La comparación con el code and fix —escribir código e ir solucionando los problemas conforme aparecen— ayuda a contextualizar esta preocupación. El interés por desarrollar software complejo con métodos más rigurosos tiene una larga historia. La conferencia de la OTAN sobre ingeniería del software de 1968 ya abordaba cuestiones de diseño, producción, pruebas y mantenimiento.
La rapidez para generar código vuelve a poner sobre la mesa una cuestión conocida: cómo asegurar que el software siga siendo comprensible y fiable a medida que evoluciona.
Qué revisar antes de llevar una aplicación a producción.
La fiabilidad requiere trabajar en distintos puntos del proceso. Las aplicaciones necesitan una estructura que facilite su evolución y controles que ayuden a detectar problemas. Según nos explica nuestro Head of Frontend, necesitan estar bien estructuradas, con un código claro y varias capas de protección, como tests, revisión de código y monitorización.
Las pruebas manuales y automáticas permiten comprobar comportamientos. La revisión del código ayuda a detectar problemas de implementación. Los estándares compartidos facilitan que el equipo pueda mantener la solución, mientras que la monitorización permite observar cómo responde cuando está en uso.
A ello se suman controles automáticos de calidad y límites acordados por el equipo. Todo este proceso es una suma de capas en distintas partes del proceso de desarrollo de un software.
Estas medidas deben adaptarse al proyecto y al sector. La participación de QA forma parte de ese trabajo, junto con la responsabilidad de quienes desarrollan y revisan la aplicación. Una prueba satisfactoria aporta información; la confianza requiere varias comprobaciones y un seguimiento continuado.
De una semana a una hora: la transformación del QA en un proyecto
Del experimento a producción: dónde está el límite.
Para quienes quieran empezar a probar el vibe coding, recomendamos elegir una necesidad concreta y de bajo impacto. Su posición sobre hasta dónde llevar este enfoque es clara: Está bien para experimentos, pero no para código de producción.
Esta valoración se refiere al vibe coding entendido como avanzar sin comprender ni revisar suficientemente lo generado. Es compatible con utilizar IA dentro de un proceso profesional que incorpore supervisión, pruebas y los controles que se consideren necesarios.
Nuestra principal advertencia tiene que ver con el esfuerzo total. Obtener una primera versión rápidamente puede trasladar trabajo a las siguientes fases. Pues “esta velocidad” no es gratis, supone un incremento de deuda técnica, que en algún momento habrá que pagar.
El vibe coding puede ser un buen punto de partida para experimentar. Antes de convertir ese prototipo en una herramienta de la que dependan otras personas, conviene hacerse una pregunta: ¿entendemos lo suficiente lo que hemos creado como para mantenerlo y responder cuando falle?
