---
term: 'Vibe Coding'
seoTitle: 'Vibe Coding: Definición, Origen, Riesgos y Guardrails'
headline: '¿Qué es vibe coding?'
slug: vibe-coding
category: ai-modern-stack
shortDefinition: 'Vibe coding es un flujo de trabajo en el que construyes software escribiendo prompts a una IA y aceptando el código generado prácticamente sin revisión.'
relatedTerms:
  - no-ops-development
  - backend-boilerplate-code
  - api-key-security
  - access-control-lists-acl
contrastsWith:
  - ai-agent
aboutTerms:
  - 'Desarrollo Asistido por IA'
  - 'Builders Prompt-to-App'
  - 'Agentic Coding'
faq:
  - question: '¿Qué es vibe coding?'
    answer: 'Es construir software describiéndole a una IA lo que quieres en lenguaje natural y aceptando el código generado prácticamente sin revisión línea por línea — iterando al correr, probar y mandar nuevos prompts, en vez de editar. La parte de no revisar es el rasgo definitorio, en las lecturas más estrictas del término.'
  - question: '¿Quién acuñó el término vibe coding?'
    answer: 'Andrej Karpathy, en un post en X en febrero de 2025 — "fully give in to the vibes, embrace exponentials, and forget that the code even exists", es decir, entregarse a las vibes y olvidar que el código existe. Collins lo eligió Palabra del Año de 2025, y los diccionarios empezaron a rastrearlo como jerga a las pocas semanas de acuñado.'
  - question: '¿Vibe coding es lo mismo que desarrollo asistido por IA?'
    answer: 'No, y la distinción importa. En el vibe coding no revisas ni entiendes por completo el resultado. En la ingeniería asistida por IA el humano conserva el control arquitectónico y lo revisa todo — la regla de Simon Willison: si revisaste, probaste y puedes explicar cada línea, eso no es vibe coding; es desarrollo de software.'
  - question: '¿Vibe coding es programación de verdad?'
    answer: 'Produce software real y funcional — y no es ingeniería. Lo que falta es accountability: revisión, comprensión y la capacidad de razonar sobre las fallas. Para alcances desechables está bien — ese era el encuadre del propio Karpathy; para cualquier cosa con usuarios y datos, las partes que faltan son justamente las estructurales.'
  - question: '¿Quien no sabe programar puede hacer vibe coding?'
    answer: 'Sí — la mayoría de los usuarios de plataformas prompt-to-app no tiene formación en programación, y esas personas realmente publican herramientas que funcionan. Las paredes contra las que chocan son predecibles: autenticación, modelado de datos, seguridad y depuración — exactamente las partes donde no entender el código sale más caro.'
  - question: '¿El software hecho con vibe coding es seguro para producción?'
    answer: 'No sin revisión. Los escaneos de la industria sitúan fallas de seguridad en cerca del 45% del código generado por IA, y el historial de incidentes es concreto: apps publicadas con las reglas de acceso de la base de datos deshabilitadas, autenticación rota dejando a cualquier usuario leer datos ajenos y secretos embebidos en el código del cliente. El patrón en todos los casos: seguridad de backend aceptada sin revisión.'
  - question: '¿El vibe coding va a reemplazar a los desarrolladores?'
    answer: 'El consenso es que no — desplaza el trabajo en vez de eliminarlo: hacia la especificación, la revisión y la arquitectura. Los prototipos vibe-coded que triunfan suelen ser reconstruidos o fuertemente endurecidos por ingenieros antes de escalar, y el propio creador del término hoy distingue el vibe coding casual de la "agentic engineering" seria.'
  - question: '¿Cuáles son las buenas prácticas de vibe coding?'
    answer: 'Prompts pequeños y acotados; una tarea a la vez; checkpoints en el control de versiones antes del "aceptar todo"; pruebas como red de seguridad; revisión humana de todo lo que toque autenticación, datos o dinero; secretos fuera de los prompts y del código del cliente; y un backend gestionado y endurecido debajo del frontend generado.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Andrej Karpathy — el post original (febrero de 2025)'
    url: 'https://x.com/karpathy/status/1886192184808149383'
  - name: 'Not all AI-assisted programming is vibe coding — Simon Willison'
    url: 'https://simonwillison.net/2025/Mar/19/vibe-coding/'
  - name: 'Vibe coding — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Vibe_coding'
  - name: 'The (In)Security of Vibe-Coded Applications — arXiv'
    url: 'https://arxiv.org/abs/2506.23130'
cta:
  title: 'Vibe en el frontend. No en el backend.'
  text: 'Apunta tu app generada por IA a Back4app y las partes estructurales llegan endurecidas: autenticación, ACLs, rate limits y lógica server-side que el código generado no puede deshabilitar — la superficie vibe-coded sigue siendo la de bajo riesgo.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-04'
translationKey: vibe-coding
---

**Vibe coding es un flujo de trabajo en el que construyes software escribiendo prompts a una IA y aceptando el código generado prácticamente sin revisión.** [Andrej Karpathy acuñó el término](https://x.com/karpathy/status/1886192184808149383) en febrero de 2025 — "fully give in to the vibes, embrace exponentials, and forget that the code even exists" (entrégate a las vibes y olvida que el código existe) — describiendo aceptar cambios sin leer los diffs, pegando errores de vuelta hasta que funcionara, en proyectos desechables de fin de semana. En un año el término derivó en atajo para *cualquier* programación con IA; esta entrada conserva el sentido preciso, donde vive el juicio de ingeniería: **el rasgo definitorio no es usar IA — es no revisar lo que la IA escribió.**

## Puntos clave

| Pregunta | Respuesta |
| --- | --- |
| La definición | Prompt → generar → correr → nuevo prompt — sin leer el código |
| El origen | Karpathy, feb/2025 · Palabra del Año de Collins en 2025 |
| La línea | Revisado, probado, entendido = ingeniería asistida por IA, no vibe coding |
| El historial | ~45% del código de IA trae fallas de seguridad; hubo brechas reales |
| La regla | Vibe en la superficie de bajo riesgo; nunca en auth, datos o dinero |

## El loop, y la línea divisoria

El flujo es un loop corto: describe → la IA genera → córrelo → pega los errores de vuelta → repite, tratando la base de código como problema de la IA. [Simon Willison](https://simonwillison.net/2025/Mar/19/vibe-coding/) trazó la línea que mantiene útil el término: si revisaste cada cambio, lo probaste y puedes explicarlo, "eso no es vibe coding — es desarrollo de software". No es gatekeeping; es una etiqueta de riesgo. El mismo loop *con* revisión es ingeniería asistida por IA, y el modo en que estás debería ser una decisión, no un accidente. En la práctica:

**JavaScript:**

```javascript
// JavaScript — Cloud Code (cloud/main.js)
// The guardrail under a vibe-coded frontend: rules the AI can't skip
Parse.Cloud.beforeSave('Note', (req) => {
  // Whatever the generated client sends, ownership is enforced HERE
  if (!req.user) throw 'Sign in required';
  const acl = new Parse.ACL(req.user); // private by default
  req.object.setACL(acl);
});
// Client keys are publishable; the Master Key stays server-side.
// The vibe-coded UI can be rewritten nightly — these rules survive.
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The vibe-coded client can be sloppy — the backend isn't
final note = ParseObject('Note')..set('text', draft);
await note.save();
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The vibe-coded client can be sloppy — the backend isn't
var note = Note()
note.text = draft
_ = try await note.save()
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The vibe-coded client can be sloppy — the backend isn't
val note = ParseObject("Note")
note.put("text", draft)
note.save()
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.
```

## Vibe coding vs. ingeniería asistida por IA vs. desarrollo tradicional

| | Vibe coding | Ingeniería asistida por IA | Tradicional |
| --- | --- | --- | --- |
| Quién escribe el código | La IA | La IA + el humano | El humano |
| Revisión | Saltada — esa es la definición | Cada cambio | Cada cambio |
| El humano es dueño de | El prompt y la vibe | Arquitectura, corrección | Todo |
| Velocidad | La más rápida | Rápida | Línea base |
| Encaje | Desechables, prototipos | Productos reales | Productos reales |
| Modo de falla | Código publicado que nadie entiende | Errores a escala de IA, atrapados por humanos | Errores a escala humana |

## El espectro, y la regla de graduación

```mermaid
flowchart LR
  accTitle: El espectro del vibe coding hasta producción
  accDescr: El software recorre un espectro que va del prototipo vibe-coded desechable, pasando por el desarrollo asistido por IA con revisión, hasta la ingeniería de producción. El código solo se gradúa de una etapa a la siguiente mediante revisión humana y pruebas, y el modo de falla es saltarse la graduación publicando un prototipo directo a los usuarios.
  V["Prototipo vibe-coded<br/>sin revisión, rápido, desechable"] -->|"graduación: revisión<br/>+ pruebas + hardening"| A["Desarrollo asistido por IA<br/>el humano es dueño de la corrección"]
  A -->|"misma puerta, vara más alta"| P["Ingeniería de producción<br/>accountability + operación"]
  V -.->|"el modo de falla:<br/>publicarlo tal cual"| X["Incidente"]
```

El encuadre que resuelve la mayoría de las discusiones sobre vibe coding: es una *etapa*, no una identidad. Los prototipos merecen las vibes — para eso existen los prototipos. La regla que enseña el historial de incidentes: **el código solo se gradúa entre etapas vía revisión y pruebas.** Vale notar que el propio Karpathy siguió adelante dentro del mismo año, distinguiendo el vibe coding casual de la "agentic engineering" para el trabajo serio — el creador del término dándoles la razón a sus críticos sobre el alcance.

## Qué se rompe de verdad: el historial de incidentes

La sección honesta que los explicadores de proveedores suavizan. Los escaneos de la industria sitúan fallas de clase OWASP en cerca del **45% del código generado por IA**, y herramientas independientes de revisión midieron en el código de IA ~1,7× más problemas graves que en líneas base escritas por humanos ([el tratamiento académico](https://arxiv.org/abs/2506.23130) llega a conclusiones parecidas). Los incidentes con nombre comparten una misma anatomía: en 2025, un escaneo de apps construidas en un builder prompt-to-app popular encontró **170 de 1.645 filtrando datos de usuarios** — el stack generado salía con la seguridad a nivel de fila de la base de datos deshabilitada (registrada como CVE); la capa de autenticación de una plataforma prompt-to-app permitía a **cualquier usuario entrar en cualquier app privada** mediante un ID adivinable; y una app de consumo viral fue vulnerada cuando su **base de datos de backend móvil sin proteger** dejó que cualquier usuario autenticado extrajera IDs y mensajes privados de otros usuarios. Ninguno fue un ataque exótico. Todos eran lo básico del backend — reglas de acceso, autenticación, credenciales — generados permisivos y aceptados sin revisión.

## Es en el backend donde muerde

Relee la lista de incidentes y el patrón se nombra solo: el peligro no es que la IA escriba una UI torpe — un botón roto se arregla con un refresh. El peligro se concentra donde viven los *datos*: [autenticación](/glossary/es/autenticacion-vs-autorizacion/), [reglas de acceso](/glossary/es/listas-de-control-de-acceso-acl/), [claves de API](/glossary/es/seguridad-de-claves-de-api/) pegadas en el código del cliente, [rate limits](/glossary/es/rate-limiting-de-api/) ausentes. El código sin revisar es más peligroso exactamente donde la revisión más importa — y esa es la respuesta arquitectónica: **haz que la parte vibe-coded sea la parte de bajo riesgo.** Un frontend generado sobre un backend gestionado invierte el riesgo: la plataforma aporta autenticación endurecida, ACLs de negar-por-defecto impuestas del lado del servidor, claves de cliente publicables con los secretos reales guardados en otro lugar y [funciones server-side](/glossary/es/cloud-code-funciones-serverless/) para la lógica que no debe vivir en código de cliente generado. La IA puede reescribir la UI cada noche; no puede deshabilitar reglas que no controla.

## El checklist de guardrails

1. **Revisa todo lo que toque autenticación, datos o dinero** — la puerta de graduación, innegociable.
2. **Haz checkpoint en el control de versiones antes del "aceptar todo"** — undo barato para sugerencias caras.
3. **Mantén los secretos fuera de los prompts y del código del cliente** — trata a ambos como públicos.
4. **Reglas de acceso de negar-por-defecto** — la app generada recibe los permisos que tú elegiste, no los permisivos que ella sugirió.
5. **Validación server-side para cada invariante** — [hooks que el cliente no puede saltarse](/glossary/es/triggers-de-base-de-datos/).
6. **Pruebas antes que confianza** — el único feedback honesto del loop más allá de "parece que corre".
7. **Alcances pequeños, una tarea por prompt** — los diffs del tamaño de una revisión siguen siendo revisables.
8. **Limita el gasto** — claves de API con cuotas; los loops de agente ya han quemado presupuestos reales.
9. **Aísla los experimentos** — app separada, claves separadas, datos desechables.
10. **Sabe en qué modo estás** — vibe o ingeniería, elegido a propósito.

## Casos de uso comunes

- **Prototipos y MVPs** — el caso de uso fundacional: probar la idea este fin de semana, no este trimestre.
- **Herramientas personales e internas** — audiencia pequeña, usuarios conocidos, radio de daño bajo.
- **Hackathons y demos** — la velocidad es la rúbrica entera.
- **Aprender construyendo** — el loop como tutor, con la salvedad de que el código no leído enseña menos.
- **Iteración de UI sobre un backend estable** — la arquitectura de riesgo invertido: vibes arriba, [contratos](/glossary/es/api/) abajo.

## ¿Deberías hacerlo con vibe coding? Matriz de decisión

| Lo que estás construyendo | Veredicto |
| --- | --- |
| Desechable de fin de semana, demo, experimento | Vibe con libertad — ese es el hábitat |
| Herramienta interna, real pero pequeña | Vibe, y luego revisa las rutas de datos |
| Cualquier cosa con cuentas de usuario | El backend viene de una plataforma endurecida, no del prompt |
| Cualquier cosa que maneje pagos o PII | Revisión completa — esto ya es ingeniería |
| El producto de verdad de una startup | Asistido por IA con ownership; los prototipos se gradúan, nunca se publican tal cual |
| El frontend sobre un backend gestionado | El punto dulce — velocidad donde es seguro |

## Limitaciones y trade-offs

- **Depurar código no leído es arqueología.** Cuando el loop se atasca, alguien debe finalmente leerlo todo de una vez — la revisión que te saltaste, con intereses.
- **La deuda de comprensión se acumula.** Cada cambio aceptado sin leer ensancha la brecha entre lo que hace la app y lo que alguien puede explicar; la brecha es el riesgo.
- **Los defaults de la IA son permisivos.** Las configuraciones generadas privilegian "funciona" sobre "es seguro" — reglas de acceso abiertas, claves embebidas — y el usuario que más necesita notarlo es el menos equipado para hacerlo.
- **El término está derivando.** "Vibe coding" cada vez más significa cualquier programación con IA, lo que lava prácticas de nivel prototipo hasta meterlas en conversaciones de producción; la precisión sobre el modo en que estás es la defensa.
- **La atrofia de habilidades es real, pero está mal encuadrada.** La habilidad que importa migra de escribir código a especificarlo, revisarlo y juzgarlo — la atrofia solo ocurre si la revisión también se salta.

## Vibe coding en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La pareja es la arquitectura de riesgo invertido puesta en práctica: apunta el frontend generado a un backend donde las partes estructurales ya fueron diseñadas por ingenieros — registro, sesiones y [login social](/glossary/es/oauth-2-login-social/) desde la plataforma; [ACLs y permisos de clase](/glossary/es/listas-de-control-de-acceso-acl/) impuestos del lado del servidor en cada solicitud, de negar-por-defecto; claves de cliente publicables con la [master key guardada en el servidor](/glossary/es/seguridad-de-claves-de-api/); y el guard de `beforeSave` de las pestañas de código como el patrón para cada invariante que al cliente escrito por la IA no se le puede confiar. La superficie vibe-coded sigue siendo lo que Karpathy quiso que fuera — rápida, divertida, desechable — mientras las partes que terminan en reportes de incidentes vienen de una plataforma: revisadas una vez, impuestas siempre.