El vibe coding consiste en construir software conversando con una IA y guiándola a partir del resultado que ves. En lugar de escribir cada línea, describes lo que necesitas, pruebas la respuesta y pides cambios. Eso reduce la barrera para crear un prototipo, pero no elimina la necesidad de entender el problema ni de comprobar que la solución funciona.
En mi video del 26 de febrero de 2026 exploré esta idea desde mi experiencia como cofundador: tener claro qué quieres construir y depender de otra persona para convertirlo en software. Lo que me interesa de la programación asistida por IA es poder participar directamente en esa construcción.
La parte que permanece vigente no es una promesa de hacer cualquier aplicación sin esfuerzo. Es una forma distinta de trabajar: expresar mejor la intención, dar contexto al agente y revisar el resultado con criterios concretos.
Qué cambia cuando puedes programar conversando
Una parte de construir software consiste en convertir una necesidad humana en instrucciones precisas. Quieres conservar una lectura, ordenar una lista o mostrar un dato cuando ocurre algo. Para lograrlo, alguien tiene que decidir qué información se guarda, qué regla se aplica y cómo se comporta la interfaz.
Con un agente de programación puedes expresar esa necesidad en lenguaje natural. El agente revisa los archivos disponibles y propone o ejecuta cambios. Tu trabajo se desplaza: pasas menos tiempo escribiendo sintaxis y más tiempo definiendo el resultado esperado y comprobándolo.
Eso abre posibilidades para quienes conocen bien un negocio o un proceso aunque no programen de manera profesional. Puedes llevar una idea a una primera versión que se pueda usar y discutir. También puedes descubrir que la idea estaba incompleta: al verla funcionar aparecen decisiones que no habías considerado.
Esas decisiones siguen siendo trabajo. Una instrucción ambigua no se vuelve precisa porque la reciba una IA. El agente puede completar los huecos con supuestos razonables para él y equivocados para ti.
El origen de la conversación sobre vibe coding
En el video tomo como punto de partida la publicación de Andrej Karpathy que popularizó la expresión vibe coding. La idea describía una experiencia de programación muy guiada por lenguaje natural y por lo que el usuario observaba al ejecutar el resultado. Puedes consultar la publicación original de Karpathy en X.
Para aplicar esa idea conviene distinguir dos situaciones. Una es explorar un prototipo que puedes descartar. Otra es mantener un sistema que guarda información de otras personas, recibe pagos o sostiene una operación diaria. La facilidad para generar una primera versión no hace que ambas situaciones tengan las mismas exigencias.
Mi lectura es que la capacidad de crear se amplía. Eso no convierte la revisión del código, el diseño de la arquitectura o las pruebas en actividades innecesarias. Cuanto más importante sea el sistema, más necesitas saber qué hace y cómo se comporta cuando algo falla.
Mi ejemplo: explicar un problema de caché
En la demostración describo un problema concreto: unas lecturas se estaban borrando cuando debían conservarse durante el día. En vez de pedir «arregla la aplicación», expliqué qué comportamiento estaba fallando y qué debía pasar con esos datos.
La diferencia parece pequeña, pero cambia la tarea. «Arregla la aplicación» obliga al agente a adivinar. «Conserva las lecturas durante el día y evita que una nueva escritura borre las anteriores» describe una condición que luego puedes comprobar.
A partir de ese caso, esta sería una manera más completa de preparar una solicitud. Es un ejemplo editorial para mostrar el nivel de precisión, no una transcripción literal de mi prompt:
Las lecturas guardadas durante el día se están perdiendo.
Resultado esperado:
- Mantener las lecturas anteriores al guardar una nueva.
- Conservarlas al recargar la página.
- Explicar qué ocurre al cambiar de día.
Primero revisa dónde se guardan y qué operación las reemplaza.
Después propone el cambio y una forma de comprobarlo.
Todavía falta definir la zona horaria, qué significa «durante el día» y si distintos usuarios comparten esos datos. Son preguntas del producto. El agente puede ayudarte a encontrarlas, pero alguien tiene que resolverlas.
Para qué sirve CLAUDE.md en este proceso
En el video aparece un archivo CLAUDE.md. Ahí se puede describir el proyecto, indicar cómo se organiza y dejar instrucciones que no quieres repetir en cada conversación.
La documentación de Claude Code presenta estos archivos como contexto persistente escrito por el usuario. No son una barrera técnica que impida acciones: orientan al modelo. Esa distinción importa cuando decides qué reglas deben estar en instrucciones y cuáles necesitan controles reales. Documentación de CLAUDE.md.
En un proyecto pequeño, empezaría por dejar claras cuatro cosas:
- Qué problema resuelve y para quién.
- Qué carpetas o archivos contienen las partes importantes.
- Cómo ejecutar el proyecto y comprobar los cambios.
- Qué decisiones debe consultar antes de modificar algo.
No necesitas escribir un manual enorme. Necesitas que la información ayude al agente a trabajar en ese proyecto específico. Una regla que contradice otra o describe una versión anterior puede añadir confusión en vez de resolverla.
Un ciclo práctico para trabajar con criterio
Mi recomendación es dividir el trabajo en cambios que puedas observar. Si pides una plataforma entera de una vez, resulta más difícil saber qué parte cumple lo que querías y cuál está sosteniéndose sobre un supuesto equivocado.
Primero, describe el problema con un ejemplo. Cuenta qué haces, qué ocurre y qué debería ocurrir. Si tienes una captura o un error, úsalo como evidencia.
Después, entrega el contexto necesario. Indica el proyecto correcto y los archivos relevantes. Si el agente no tiene acceso a un sistema, no interpretes una explicación convincente como si lo hubiera inspeccionado.
Pide un cambio acotado. Resolver un comportamiento permite revisar con más claridad que una lista de veinte mejoras mezcladas.
Comprueba el resultado. En el caso de las lecturas, guarda varias, recarga y revisa si siguen ahí. Después prueba el cambio de día y los demás casos que hayas definido. Que desaparezca el mensaje de error no demuestra por sí solo que los datos se conservan.
Deja registro de lo que funcionó. Guarda una versión recuperable y documenta las decisiones que deberían mantenerse. Eso permite seguir construyendo sin depender de recordar una conversación larga.
Dónde conviene poner el límite
El entusiasmo por construir rápido puede hacer que confundamos una demostración con un producto terminado. Una pantalla que se ve bien puede tener problemas detrás: datos que no persisten, permisos demasiado amplios o errores que solo aparecen con una segunda persona usando el sistema.
Por eso separaría una prueba personal de un despliegue con usuarios reales. Antes de entregar ese segundo caso, hace falta revisar datos, permisos, recuperación ante errores y mantenimiento. Si no puedes evaluar una parte crítica, incorpora a alguien que sí pueda hacerlo.
El criterio no significa saber todas las respuestas. Significa reconocer cuáles faltan, pedir evidencia y no dar por terminado algo solo porque la IA respondió con seguridad.
Video completo y siguiente paso
Puedes ver la explicación y el ejemplo original en mi video sobre el origen del vibe coding. Si quieres continuar una sesión de Claude Code desde el teléfono, también tienes la guía de Remote Control.
En Imperio Agéntico trabajamos sobre esa transición: pasar de explorar herramientas a implementar sistemas con un problema y un resultado definidos.
El punto de partida puede ser pequeño. Elige una tarea que conoces bien, describe cómo reconocerás una solución correcta y construye una primera versión que puedas comprobar.
Preguntas frecuentes
¿Qué significa vibe coding en esta guía?
Es construir una primera versión de software conversando con una IA, observar lo que hace y pedir cambios a partir del resultado. La guía parte de la publicación de Andrej Karpathy que popularizó la expresión y la aplica a un ciclo de trabajo con contexto, cambios acotados y comprobaciones.
¿Puedo hacer vibe coding si no sé programar?
Puedes empezar describiendo un problema que conoces bien y explorando un prototipo. Para decidir si la solución está terminada, necesitas comprobar su comportamiento. Si maneja datos, permisos o procesos que no puedes evaluar, incorpora a alguien que pueda revisar esas partes antes de entregarlo a otras personas.
¿Qué debería poner en CLAUDE.md?
Incluye el propósito del proyecto, su organización, cómo ejecutarlo y cómo comprobar los cambios. Escribe instrucciones concretas que eviten repetir contexto. Según la documentación de Claude Code, CLAUDE.md orienta al modelo; no sustituye los controles que deben bloquear una acción independientemente de lo que decida la IA.
¿Cómo le pido a la IA que arregle un error sin darle una instrucción demasiado vaga?
Describe qué hiciste, qué ocurrió y qué esperabas. En el ejemplo del artículo, las lecturas debían conservarse al guardar una nueva y al recargar. Añade condiciones que puedan comprobarse y pide localizar la causa antes de cambiar el código. Una captura ayuda a mostrar el problema, pero no demuestra que quedó resuelto.
¿Cómo sé si un prototipo creado con IA está listo para publicarse?
Define pruebas del comportamiento que prometes y compruébalas con datos de prueba. Revisa también qué sucede al recargar, ante un error y con distintos usuarios cuando corresponda. Conserva una versión recuperable y resuelve las dudas sobre datos, permisos y mantenimiento. Una interfaz que se ve terminada no demuestra por sí sola que el sistema funciona.