Vibe coding: cuándo funciona y cuándo es un riesgo para tu producto

A principios de 2025, Andrej Karpathy acuñó el término "vibe coding" para describir una forma de programar que se popularizó con Cursor, Claude Code y otras herramientas: describir lo que quieres en lenguaje natural, dejar que el modelo escriba el código, aceptarlo sin leerlo a profundidad y seguir adelante. La idea es controvertida porque mezcla dos verdades incómodas. La primera: vibe coding ha permitido construir prototipos en una tarde que antes tomaban semanas. La segunda: también está dejando una estela de bugs sutiles, problemas de seguridad y deuda técnica que aparecen tres meses después en producción.

En ALCA hemos visto las dos caras en clientes y en equipos propios. Este artículo es nuestro marco práctico para decidir cuándo vibe coding es la herramienta correcta y cuándo es un riesgo serio para tu producto.

Qué es exactamente vibe coding

Vibe coding no es "usar IA para programar". Eso es asistencia con IA y casi todo equipo serio lo hace ya. Vibe coding es algo más específico: delegar la generación de código sin revisar a fondo lo que se generó, confiando en que si la app corre, está bien.

En la práctica, eso se ve así:

• Pides al modelo que cree un endpoint, un componente, una integración.
• Aceptas la sugerencia completa.
• Pruebas que funcione el "happy path".
• Si pasa, sigues con la siguiente tarea.
• Repites cientos de veces hasta tener un producto.

La velocidad es real. El riesgo, también.

Por qué funciona (cuando funciona)

Vibe coding tiene ventajas reales que sería deshonesto negar:

• Velocidad de prototipado: un MVP que tomaba 6 semanas hoy se hace en 1.
• Exploración barata: puedes probar 5 ideas distintas y desechar 4 sin culpa.
• Reducción de fricción cognitiva: quien tiene la idea de negocio puede ejecutar sin pasar por el filtro completo de un equipo de ingeniería.
• Acceso para perfiles no técnicos: founders, PMs, diseñadores construyen cosas reales.
• Aprendizaje acelerado: ver código generado a partir de tus descripciones enseña patrones rápido.

Es razonable adoptarlo en contextos correctos. El error es asumir que esos contextos incluyen producción crítica.

Los riesgos reales que estamos viendo

Tras meses observando equipos que adoptaron vibe coding sin disciplina, los patrones de problemas que se repiten:

Arquitectura no pensada

El modelo resuelve la tarea inmediata, no la arquitectura del sistema. Después de 3 meses de vibe coding, terminas con: lógica duplicada en 5 lugares, capas que no se respetan, dependencias circulares, una función que crece a 800 líneas porque el modelo "le agregó" cosas en cada iteración.

Seguridad débil por default

El código generado rara vez maneja bien validación de inputs, sanitización, autenticación, autorización fina, manejo de secretos, prevención de SQL injection o XSS. Funciona en el happy path; revienta o se exhibe en el adversarial path.

Código no testeable

Los modelos generan código que pasa pruebas, pero no necesariamente código que sea fácil de probar. Sin tests, los siguientes cambios introducen regresiones que aparecen en producción.

Dependencia de un humano que no entiende

El líder técnico no sabe cómo funciona el módulo que el modelo escribió. Cuando aparece un bug en producción, no hay nadie con modelo mental claro para diagnosticar. La IA puede ayudar a investigar, pero sin supervisión humana competente, el ciclo se vuelve eterno.

Deuda técnica oculta

El código compila, pasa pruebas básicas, hace lo que tiene que hacer. Pero si lo abres y lo lees, está mal estructurado, mal nombrado, mal documentado. No vas a refactorizarlo porque "ya funciona", hasta que un cambio crítico te obliga y descubres que tomar 3 días lo que debería tomar 3 horas.

Costos en cómputo y APIs por descuido

Código generado sin pensar en eficiencia hace consultas innecesarias a la base de datos, repite llamadas a APIs costosas, no cachea, no pagina. La factura llega.

Cuándo vibe coding es una elección legítima

Hay contextos donde el balance riesgo/beneficio favorece a vibe coding:

• Prototipos para validar hipótesis (no para vender al cliente todavía).
• Demos que se van a tirar al final de la presentación.
• Scripts internos de un solo uso (procesar un dataset, migrar archivos).
• Hackathons donde la velocidad importa más que la calidad.
• Experimentación personal o para aprender.
• Capas de UI no críticas (dashboards internos, herramientas administrativas de uso esporádico).

En todos estos casos, si algo sale mal, el costo es bajo. Vibe coding es la herramienta correcta.

Cuándo es claramente peligroso

En estos contextos, vibe coding sin supervisión es asumir riesgos que no compensan:

• Cualquier código en producción que vea usuarios externos.
• Manejo de datos personales sensibles (sujetos a LFPDPPP).
• Integraciones con sistemas financieros, médicos o legales.
• Lógica de negocio que mueve dinero, calcula impuestos o aplica reglas regulatorias.
• Código que va a vivir más de 3 meses sin reemplazo planeado.
• Sistemas con SLA o disponibilidad comprometida con cliente.

Aquí no se trata de no usar IA, se trata de no delegar la responsabilidad de entender el código a la IA.

Marco para tu equipo: vibe coding con guardrails

La pregunta correcta no es "permitimos vibe coding sí o no". Es: ¿bajo qué condiciones? Lo que recomendamos definir por escrito:

1. Categorización del código

Clasifica los componentes de tu producto en tres niveles:

• Crítico: producción, datos sensibles, lógica de negocio, integraciones de pago. Code review humano profundo obligatorio, sin excepciones.
• Importante: funcionalidades de producto que ven usuarios pero no son críticas. Code review obligatorio, IA puede generar pero el humano valida.
• Auxiliar: scripts, herramientas internas, prototipos. Vibe coding aceptable con responsable claro.

2. Pruebas no negociables

Cualquier código de nivel crítico o importante debe tener pruebas escritas (o al menos validadas) por humanos. El modelo puede sugerir las pruebas; el humano las firma.

3. Revisión de seguridad obligatoria

Para código que toca datos sensibles, autenticación, pagos o integraciones externas: revisión por alguien con criterio de seguridad antes de merge. Idealmente con apoyo de herramientas de SAST.

4. Documentación mínima

Cada módulo generado debe tener al menos un README corto explicando: qué hace, qué entradas espera, qué salidas produce, cuáles son sus dependencias críticas. Esto obliga al humano a entender lo que pegó.

5. Revisión de arquitectura periódica

Cada 4-6 semanas, alguien con visión de sistema revisa lo que se construyó: ¿hay duplicación? ¿estamos respetando las capas? ¿necesitamos refactorizar antes de seguir? Sin esta cadencia, la entropía gana.

6. Criterio "puedo defenderlo en una entrevista"

Regla simple para el desarrollador: si no podrías explicar cómo funciona este código en una entrevista técnica, no lo merguees a producción. Sigue iterando con la IA hasta que sí lo entiendas.

La pregunta de fondo

Vibe coding no es bueno ni malo en sí mismo. Es una herramienta que invierte la relación tradicional entre velocidad y calidad: maximiza velocidad asumiendo deuda. Como toda deuda, sirve cuando el rendimiento esperado de moverte rápido supera el costo de pagarla después.

En prototipos, sirve casi siempre. En producción para clientes, casi nunca. En el rango intermedio, depende de tu disciplina para ponerle guardrails.

Las empresas que están ganando con IA no son las que delegan todo el código. Son las que construyen procesos donde la IA acelera y los humanos siguen siendo responsables de entender, validar y operar. Esa es la combinación que escala sin reventar.

---

En ALCA ayudamos a equipos de ingeniería a definir su política de uso de IA en código. ¿Quieres definir guardrails de AI coding para tu equipo? Te ayudamos. Conversemos 30 minutos sin costo.