--- title: "Vibe coding: cómo empezar bien | CommitCycle" description: "Qué es el vibe coding, dónde funciona de verdad, dónde deja de funcionar y las respuestas a lo que la gente pregunta antes de su primer intento serio." url: https://commitcycle.com/es/insights/vibe-coding-first-steps/ language: es --- # Vibe coding, y la primera semana que no acaba en un desastre > Qué es el vibe coding, dónde funciona de verdad, dónde deja de funcionar y las respuestas a lo que la gente pregunta antes de su primer intento serio. 14 de agosto de 2026 · actualizado 18 de agosto de 2026 [Paulo L.](https://commitcycle.com/es/about/) AI Growth Hacker El vibe coding consiste en construir describiendo lo que quieres y aceptando lo que el modelo escribe sin leerlo todo. Funciona cuando equivocarse cuesta poco y el feedback es inmediato — prototipos, scripts, herramientas desechables. Deja de funcionar cuando el código sobrevive a la sesión, porque lo que te saltaste es justo lo que después hay que entender. El vibe coding consiste en construir describiendo lo que quieres y aceptando lo que el modelo escribe sin leerlo todo. El término es de Andrej Karpathy, y lo que lo distingue no es que la IA escribiera el código — eso ya es lo normal — sino que **nadie lo revisó línea a línea**. Eso es un intercambio, no un error. Que sea un buen intercambio depende por completo de una pregunta: ¿cuánto tiempo tiene que vivir este código? ## ¿Dónde funciona de verdad el vibe coding? **Prototipos que piensas borrar.** El coste de equivocarte es que lo tiras, que es lo que ibas a hacer de todos modos. **Scripts y herramientas de un solo uso.** Algo que reordena un CSV, siembra una base de datos, hace scraping de una página una vez. Si produce la salida correcta has terminado; nadie va a mantenerlo. **Aprender la forma de algo que no conoces.** Conseguir un ejemplo funcionando de una biblioteca que no has usado nunca es más rápido así que leerte antes la documentación, y puedes leer la documentación después con algo concreto delante. **Cualquier cosa donde el feedback sea inmediato y total.** Si funciona, funciona, y te enteras en diez segundos. El hilo común es que **equivocarse es barato y evidente**. Ésa es la condición. No el tamaño del proyecto, ni el lenguaje, ni si es «real» — sólo si un error aparece de inmediato y cuesta poco. ## ¿Cuándo deja de funcionar? En el momento en que el código sobrevive a la sesión que lo produjo. Esto no es un juicio moral. Es aritmética: compraste velocidad saltándote la comprensión, y la factura llega cuando alguien tiene que cambiar código que nadie entendió cuando se escribió. Si nadie lo cambia nunca, la factura no llega nunca y la velocidad te salió gratis. Ése es un resultado real y ocurre mucho. Lo que hace que salga mal es no saber en cuál de los dos casos estás. Casi todas las malas experiencias empiezan como un prototipo que se volvió crítico en silencio, sin que nadie decidiera nada. ## ¿Cómo sé en qué caso estoy? Tres preguntas, y van sobre la situación más que sobre el código: | Pregunta | El vibe coding vale cuando | Deja de valer cuando | | --------------------------------------------------- | --------------------------------- | --------------------------------------- | | **¿Con qué rapidez me entero de que me equivoqué?** | En segundos. Lo ejecutas y lo ves | En semanas, a través de un cliente | | **¿Qué cuesta equivocarse?** | Lo borras y empiezas otra vez | Dinero, datos o la confianza de alguien | | **¿Quién más depende de esto?** | Nadie | Cualquiera que no seas tú | Las tres apuntando en la misma dirección es el caso para el que se hizo esto. Las tres apuntando en la otra y no estás haciendo vibe coding, estás apostando con pasos extra. Lo útil es que **esto se decide por pieza de trabajo, no por proyecto**. La misma tarde puede contener un script desechable que no lees nunca y un cambio de permisos que lees dos veces. Tratar un repositorio entero como un único ajuste es lo que produce los dos errores habituales: leerlo todo en un prototipo, y no leer nada en la parte que muerde. ## ¿Qué no debería hacer nunca con vibe coding? Una lista corta, y el motivo es el mismo en todos los puntos: - **Autenticación y permisos.** Equivocarse aquí no lanza un error. Deja entrar en silencio a quien no debe, y te enteras por otra persona. - **Dinero.** Precios, cargos, devoluciones, divisas. Un off-by-one en un bucle es un bug; un off-by-one en céntimos es un chargeback y un correo que no quieres escribir. - **Cualquier cosa que borre.** Los borrados en cascada sobre todo. La prueba para esta categoría es si existe un deshacer. - **Migraciones de base de datos.** Se ejecutan una vez, contra datos reales, y el fallo se descubre cuando los datos ya no están. - **Todo lo que maneje datos personales de otros.** Equivocarse aquí lleva un regulador incorporado. Fíjate en lo que _no_ es el criterio: la dificultad. Algunas de éstas son código fácil. La propiedad que comparten es que **equivocarse no se anuncia solo** — que es exactamente el supuesto sobre el que corre el vibe coding. Esto no es «escríbelo tú». Es «lee éste». Deja que el modelo lo escriba, después lee de verdad lo que escribió, y pídele que te explique las partes que no puedas seguir. La lectura es todo el coste, y en estas cinco merece la pena pagarlo. ## La primera semana **Mantén las sesiones cortas, y termina cada una en algo que funcione.** Éste es el hábito de mayor rendimiento y no va sobre la IA en absoluto. Una sesión larga acumula decisiones que nadie escribió, y cuando por fin algo va mal no hay ningún punto al que volver. Sesiones cortas con un commit que funciona al final te dan un sitio al que regresar. **Lee las partes caras.** No todo — eso echaría a perder el propósito. Lee todo lo que toque dinero, autenticación, borrado de datos, o código en el que también trabaja otra persona. El resto, ojéalo. La habilidad que se construye aquí es el triage, y es una habilidad real: saber dónde equivocarse sale caro es la mayor parte de lo que sabe un ingeniero senior. **Di lo que no debe hacer.** Casi todo el mundo describe lo que quiere y se para ahí. La instrucción que más tiempo ahorra es la que descarta cosas — _no toques el módulo de auth, no añadas dependencias, no cambies el schema de la base de datos_. Los modelos son complacientes y harán encantados algo útil que tú no querías. **Ejecútalo antes de creértelo.** Código generado que parece correcto y no arranca es el fallo suelto más común, y el más barato de detectar. **Date cuenta de cuándo el prototipo dejó de ser un prototipo.** Suele haber un momento concreto: alguien más lo abre, o se pone delante de un usuario, o lo despliegas. Ése es el momento en que el intercambio cambia, y la respuesta honesta es volver atrás y leerlo bien. ## Cómo es una buena sesión, de principio a fin En concreto, porque «mantén las sesiones cortas» es un consejo con el que puedes estar de acuerdo y aun así no aplicar: 1. **Empieza desde un commit.** No desde un repositorio ordenado: desde uno con commit. Éste es el punto de guardado, y cuesta diez segundos. 2. **Di el objetivo y el límite en el mismo mensaje.** Lo que quieres, y lo que está prohibido. La segunda mitad es la que la gente se salta. 3. **Déjalo trabajar sin interrumpir.** Corregir el rumbo a mitad de vuelo produce un cambio que es medio de un plan y medio de otro, y eso es más difícil de leer que cualquiera de los dos. 4. **Lee el diff, no el código base.** Cuántos ficheros, cuáles, y si se ha borrado algo que no pediste borrar. 5. **Ejecútalo.** Antes de creerte nada. 6. **Haz commit, o tira la sesión entera.** Los dos son resultados aceptables. El que no lo es: arrastrar un estado a medias hasta la siguiente sesión. Alrededor de una hora es donde esto suele caer para la mayoría, y el número importa menos que la forma: **la sesión es la unidad que puedes tirar.** En cuanto una sesión lleva tanto tiempo que descartarla resulta impensable, has perdido la propiedad que hacía segura toda la aproximación — y eso pasa de forma gradual, que es justo por lo que vale la pena vigilarlo. ## Las preguntas que la gente hace de verdad ### «¿Sigo siendo un desarrollador de verdad si hago esto?» La pregunta de debajo es si estás construyendo una habilidad o esquivándola. Estás construyendo una — triage, especificación, saber dónde vive el riesgo — y no es la misma habilidad que escribir tú la sintaxis. Las dos son reales. Ninguna se basta sola. ### «¿Cómo evito que invente bibliotecas que no existen?» Ejecuta el código. Los imports alucinados fallan de inmediato, lo que convierte a éste en el tipo de error menos peligroso. Preocúpate más por los que sí arrancan. ### «Ha reescrito algo que no le pedí que tocara.» Muy común, y el arreglo normal es decir qué está prohibido antes de empezar. En un repositorio en el que trabaja más gente, esto deja de ser una molestia y pasa a ser el problema de verdad — que tiene [su propio post](https://commitcycle.com/es/insights/vibe-coding-shared-repository/). ### «¿Debería hacer commit de código que no he leído?» En algo desechable, sí. En algo compartido, le estás entregando a tus compañeros un diff sobre el que no puedes responder preguntas, y eso es un problema social antes que técnico. ### «¿Así es como trabajan ahora los equipos profesionales?» En parte, y honestamente la respuesta todavía se está moviendo. Lo que sí está claro es que la restricción se ha desplazado de _con qué rapidez se puede escribir esto_ a _con cuánta confianza se puede cambiar después_, y los equipos que van bien son los que tratan eso como el eje del diseño. ## Hacia dónde va esto, y qué hacemos nosotros Todo lo anterior funciona para una persona sola en su máquina. Los fallos interesantes empiezan cuando el repositorio es compartido — cuando el código generado es localmente razonable y globalmente equivocado porque el modelo no podía ver una convención que vive en la cabeza de alguien. Ése es el problema en el que trabaja CommitCycle: cada agente recibe un grant atado a una task y a una rama que caduca por sí solo, los paths que harían daño llevan un owner, y cada task cierra con un registro de lo que declaró frente a lo que tocó. Siendo claros sobre dónde está eso: el plugin instala hoy el enforcement, y el paquete `commitcycle` de npm instala la CLI — el proceso sin el muro. El board alojado es sólo por invitación mientras esto es pequeño. Y nada de eso es lo que necesitas en tu primera semana de vibe coding — en tu primera semana necesitas sesiones cortas y el hábito de leer las partes caras. La semana siguiente, cuando ya hayas decidido que la cosa va a existir más allá del viernes, la pregunta pasa de hábitos a setup: [qué tener montado antes del primer prompt](https://commitcycle.com/es/insights/vibe-coding-setup/), y por qué está ahí cada pieza. ## Preguntas que responde esta página ### ¿Qué es el vibe coding? Construir describiendo lo que quieres y aceptando lo que el modelo escribe sin leerlo todo. El término lo acuñó Andrej Karpathy. Lo que lo distingue no es que la IA escribiera el código, es que nadie lo revisó línea a línea — que es un intercambio deliberado, no un accidente. ### ¿El vibe coding es mala práctica? No por naturaleza. Es un intercambio: velocidad ahora a cambio de comprensión después. En un prototipo que borrarás el viernes ese intercambio sale gratis, y rechazarlo sólo te hace ir más lento. En código que seguirá funcionando dentro de seis meses, estás pidiendo prestado contra una deuda que alguien tendrá que pagar. ### ¿Cuándo deja de funcionar el vibe coding? Cuando el código sobrevive a la sesión que lo produjo. En el momento en que alguien tiene que cambiar código que nadie entendió cuando se escribió, la velocidad que compraste está gastada y empiezan los intereses. ### ¿Tengo que leer el código que escribe el modelo? No todo, y ése es el sentido. Lee las partes donde equivocarse sale caro: todo lo que toque dinero, auth, borrado de datos o el código de otro equipo. El resto, ojéalo. La habilidad está en saber qué es qué, no en leerlo todo ni en no leer nada. ### ¿Cuál es el error más común de la primera semana? Dejar que una sesión se alargue demasiado. Las sesiones largas acumulan decisiones que nadie escribió, y cuando algo va mal ya no hay ningún punto al que volver. Sesiones cortas con un commit que funciona al final de cada una son el hábito de mayor rendimiento que existe. ### ¿Puedo hacer vibe coding sobre una base de código en producción? Puedes, y es de donde sale la mayoría de las quejas. El fallo rara vez es código malo: es código localmente razonable y globalmente equivocado, porque el modelo no podía ver una convención que vive en la cabeza de alguien y no en el repositorio. ### ¿Cómo sé si el vibe coding es seguro para lo que estoy construyendo? Lo deciden tres preguntas: con qué rapidez te enteras de que te equivocaste, qué cuesta cuando pasa, y si alguien más depende de ese código. Feedback rápido, más un error barato, más nadie más tocándolo es el caso para el que se hizo el vibe coding. Cambia cualquiera de los tres y el intercambio se mueve. ### ¿Qué no debería hacer nunca con vibe coding? Todo aquello cuyo fallo es silencioso, tardío o lo paga otra persona: autenticación y permisos, dinero, cualquier cosa que borre, migraciones de base de datos, y todo lo que maneje datos personales de otros. La propiedad común no es la dificultad, es que equivocarse no se anuncia solo. ### ¿Cómo es una buena sesión de vibe coding? Empieza desde un estado con commit, di lo que quieres y lo que está prohibido, déjalo trabajar, lee el diff en vez de todo el código, ejecútalo, y haz commit antes de empezar lo siguiente. El commit en cada extremo es lo que convierte la sesión en una unidad que puedes tirar.