¿Qué es 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 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

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 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 — 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 — 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.

// 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.

// 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

El espectro, y la regla de graduación

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 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, reglas de acceso, claves de API pegadas en el código del cliente, rate limits 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 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.
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 abajo.

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

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 desde la plataforma; ACLs y permisos de clase impuestos del lado del servidor en cada solicitud, de negar-por-defecto; claves de cliente publicables con la master key guardada en el servidor; 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.