El prompt de $87,500 que nadie escribió

Un founder construyó su startup entera con Claude Code. Diseñó la interfaz, conectó Stripe, armó la base de datos. Todo funcionaba. Tests pasando. UI limpia. Producto listo para lanzar.

Lo lanzó.

Hackers encontraron las API keys de Stripe sentadas en el código del frontend — visibles para cualquiera que abriera las herramientas de desarrollador del navegador. Cobraron $500 a 175 clientes. $87,500 en fraude. Más $2,500 en comisiones de Stripe que el founder tuvo que absorber.

La corrección fue una línea: “Asegúrate de que las API keys no estén en el frontend.”

El founder, Anton Karbanovich, lo resumió así: “Confié demasiado en la herramienta.”

Lo notable no es que la IA haya fallado. Es que no falló. El código compilaba. La integración con Stripe funcionaba. La app hacía exactamente lo que se le pidió. El problema no fue lo que la IA construyó — fue lo que nadie le pidió que revisara.

Tu MVP se siente más listo de lo que está

El código generado por IA crea una confianza falsa. Compila, corre, la UI se ve profesional, los tests pasan. El founder ve un producto. Un ingeniero con experiencia ve un prototipo.

Alex Turnbull, quien documentó el caso de Karbanovich, describió el patrón que estamos viendo repetirse: el MVP funciona perfecto en pruebas. Llegan usuarios reales con casos reales. Aparecen agujeros de seguridad, fallas de escala, problemas de integración que nadie anticipó. Reconstruir cuesta más que haberlo hecho bien desde el inicio.

En nuestra experiencia en IQ Source, este patrón se aceleró desde que las herramientas de vibe coding maduraron. La brecha entre “funciona en el demo” y “funciona en producción” no se achicó — lo que pasó es que se volvió más difícil de detectar porque los demos mejoraron mucho.

Un MVP generado con IA puede verse indistinguible de un producto profesional. Lo que no ves es lo que importa: cómo maneja errores, qué pasa cuando dos usuarios hacen lo mismo al mismo tiempo, dónde viven los secretos, qué ocurre cuando alguien intenta romperlo.

Esto no se trata de que la IA sea mala. Se trata de confundir velocidad con madurez.

La IA responde lo que preguntas, no lo que falta

La mejor analogía que tenemos: la IA es un pasante brillante sin criterio profesional. Hace exactamente lo que pides, con competencia. Nunca dice “espera, ¿pensaste en…?”

Un ingeniero senior miraría API keys en código frontend y diría “ni se te ocurra.” La IA las pone ahí porque le pediste una integración con Stripe que funcione. Y funciona.

Hay categorías enteras de preguntas que la IA no va a hacer por su cuenta:

Superficie de ataque

¿Dónde están los secretos? ¿Quién puede acceder a qué? ¿Qué pasa si alguien lee el código del lado del cliente? Estas preguntas requieren un modelo mental de amenazas que la IA no construye sola — responde si preguntas, pero no señala lo que olvidaste preguntar.

Modos de falla

¿Qué pasa cuando la API de pagos se cae? ¿Cuando dos usuarios hacen la misma operación al mismo tiempo? ¿Cuando alguien manda datos mal formados? La IA genera el camino feliz a menos que le pidas específicamente los caminos tristes.

Pensamiento adversarial

Un ingeniero con experiencia mira cada endpoint y piensa en cómo lo explotaría un atacante. Esa mentalidad — ponerse en los zapatos de alguien que quiere romper tu sistema — es algo que las herramientas de IA no aplican por defecto. Y se extiende a lo operativo: quién responde a las 3 AM, dónde están los logs, cómo haces rollback. Son preguntas que solo alguien que ha operado sistemas en producción sabe que hay que hacer.

La brecha no está en la capacidad de la IA. Está en la capacidad del founder de hacer las preguntas correctas.

Las preguntas que nadie hizo

No es un checklist genérico. Son preguntas específicas atadas al caso de Karbanovich y patrones similares que hemos visto:

“¿Dónde están las credenciales de Stripe en este código?” — habría encontrado las API keys en el frontend. Una búsqueda de 30 segundos.

“¿Qué puede ver un usuario si abre las herramientas de desarrollador del navegador?” — habría revelado los secretos expuestos. Es la primera pregunta que hace cualquier auditor de seguridad web.

“¿Qué pasa si alguien copia esta API key y hace llamadas desde fuera de nuestra app?” — habría disparado la discusión sobre rate limiting, proxies server-side, y restricciones de dominio.

“¿Qué es lo peor que puede pasar si este código se publica tal cual?” — pensamiento adversarial. La pregunta que la IA no va a hacer sin que se lo pidas.

En nuestra experiencia en IQ Source, las preguntas que previenen incidentes no son conocimiento técnico oscuro. Son los “¿qué pasa si…?” que vienen de haber visto cosas salir mal antes. El valor de un ingeniero senior no está en que escriba mejor código — está en que sabe qué preguntar antes de que el código se publique.

Para un checklist más completo de riesgos en herramientas de vibe coding, escribimos un análisis detallado en IA open-source y vibe coding: riesgos que tu CTO ignora.

La matemática: preguntar antes vs. descubrir después

Los números de Karbanovich son concretos:

• $87,500 en fraude (175 clientes × $500)
• $2,500 en comisiones de Stripe
• Daño reputacional con 175 clientes que probablemente no vuelvan a confiar en la plataforma
• Tiempo invertido en resolución de incidente, comunicación con clientes, disputas con Stripe

¿Cuánto cuesta una revisión de seguridad antes de lanzar? Entre $3,000 y $8,000 USD para una auditoría enfocada en los módulos críticos: autenticación, pagos, datos personales. Lo detallamos en nuestro análisis de seguridad de código con IA.

La asimetría no necesita explicación: $5,000 en revisión vs. $90,000 en pérdidas. Eso sin contar los clientes que no vuelven.

Las auditorías de seguridad son un piso, no un techo. Lo que falta en la mayoría de los MVPs construidos con IA es alguien en el proceso que haga las preguntas que el founder no sabe que tiene que hacer. Puede ser un CTO fraccional, un asesor técnico, o un partner de ingeniería con experiencia. Lo que no puede ser es nadie.

El mejor código generado por IA sigue necesitando ojos humanos que digan: “esto funciona, pero ¿pensaste en esto otro?”

Si nadie lo ha intentado romper, no está listo

Escribimos código, sí. Pero donde realmente hacemos diferencia es sentándonos con un founder antes del lanzamiento y preguntando lo que su IA nunca preguntó.

Hemos revisado MVPs que se veían listos para producción y tenían las credenciales de pago al aire. Ese tipo de problema no se encuentra con más código — se encuentra con alguien que ya sabe dónde buscar.

Para entender la brecha entre prototipo y producción desde otro ángulo, nuestro análisis de recetas de YouTube vs. desarrollo profesional desglosa por qué “funciona en mi máquina” no es lo mismo que “funciona.”

¿Estás por lanzar algo construido con IA?

Si no le has pedido a nadie que lo rompa primero, ese es el momento de hablar. Podemos hacer una revisión enfocada de tu código antes de que llegue a producción — y hacerte las preguntas que tu IA no hizo.

Hablemos antes de que tu código llegue a producción →