Karpathy nombró el problema. Yo resuelvo lo que viene después.

Vibe coding es programar dejándote llevar por la IA: vos guiás con prompts y el modelo escribe el código sin que mires mucho qué hace por dentro. El término lo acuñó Andrej Karpathy en febrero de 2025. 4.5 millones de views después, una pila de SaaS que funcionan en demo y se rompen con el cliente número 7.

"There's a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." — Andrej Karpathy, febrero 2025

¿Qué es vibe coding y por qué importa?

Vibe coding es un estilo de programación habilitado por modelos generativos potentes (Claude Code, Cursor, Lovable, Bolt, v0, Replit) donde el humano deja de leer línea por línea y deja que el modelo construya el sistema. El producto sale rápido. Lo que no sale rápido es la parte que no se ve en el demo: la seguridad, el manejo de errores, los webhooks idempotentes, los backups testeados, la observabilidad.

El 91.5% de las apps construidas con vibe coding tiene al menos una vulnerabilidad explotable, según el reporte de CSA Research publicado en 2025. No es un problema de la IA. Es un problema del proceso: el modelo construye lo que le pedís, pero no te pide que valides la parte aburrida.

¿Por qué los SaaS vibe-coded se rompen en producción?

Cada SaaS post-vibe-coding que veo trae al menos uno de estos seis fallos. Generalmente trae cuatro.

• Auth bypaseable. El login funciona en happy path. Las rutas internas no validan sesión en el servidor; confían en el frontend.
• RLS desactivada. La base habla con el cliente sin filtros. Cualquier usuario autenticado puede leer datos de cualquier otro.
• Webhooks de Stripe sin firma. El endpoint acepta cualquier POST que respete el schema. Falso pago, doble pago, replay attack.
• Backups que nadie testeó. Hay snapshots automáticos pero nadie hizo nunca un restore. Cuando hace falta, no sirven.
• Observabilidad cero. Si algo se rompe, te enterás por el cliente, no por un alert.
• CI/CD inexistente. Deploys manuales desde la laptop. Sin rollback. Sin staging.

Los founders que llaman lo hacen casi siempre después del primer susto: un cliente vio datos de otro, un pago fantasma, un downtime de 6 horas sin métricas.

¿Cómo se pasa de vibe-coded a producción real?

Karpathy nombró el problema. Pero la parte de después — la ingeniería real — todavía no tiene quien la haga en español, 1:1, sin tickets de USD 8K. Por eso abrí danielalvarez.tech.

Después de 30 años escribiendo software (empecé antes de que existiera internet) y siendo CTO de FirmaLaboral.net (SaaS argentino con 400+ PyMEs en producción), monté una mentoría 1:1 para founders y devs que armaron su SaaS con IA y se trabaron antes de producción.

El acompañamiento se organiza en cinco formatos según dónde estés parado:

• Auditoría Técnica + Roadmap desde USD 600. 1 semana. Diagnóstico técnico sin tocar tu código. Salís con el mapa del riesgo real y el orden en que hay que arreglarlo.
• Sprint Pre-Producción desde USD 3.500. 1-2 semanas. Auth real, RLS, Stripe con firma e idempotencia, backups testeados, observabilidad y CI/CD. Yo escribo el código junto con vos.
• Mentoría 1:1 · Plan Mensual desde USD 900/mes. Acompañamiento longitudinal: 1 call semanal + acceso async + code reviews.
• Rescate Técnico + Handoff Documentado desde USD 6.000. Cuando ya se rompió. Triage, estabilización, refactor focalizado y handoff documentado. Garantía 90 días.
• CTO Fraccional / Cofundador técnico, por evaluación. Para founders con SaaS de nicho que necesitan un CTO senior por horas o equity. Yo elijo si entro caso por caso.

El después de Karpathy

Karpathy ya no habla de vibes. Ahora habla de agentic engineering: agentes que ejecutan tareas complejas con criterio técnico. El cambio de etiqueta es la pista de que él también ve la limitación del modelo anterior. Vibe coding sirvió para mostrar lo lejos que llega la IA. Agentic engineering es admitir que el código sigue teniendo que estar bien escrito para que la cosa no se rompa con el séptimo cliente.

Para mí no es una sorpresa. Llevo 30 años viendo problemas de producción que la IA aún no resuelve sola: race conditions sutiles, integraciones con sistemas legacy, decisiones de arquitectura que se pagan dos años después. La IA hoy es la herramienta más nueva en una caja que vengo armando hace mucho.