Auditoría de Software Vibe-Coded: Qué Se Rompe Antes del Lanzamiento

Llegaste a un software funcional a base de prompts. Registra usuarios, muestra las pantallas correctas, demuestra bien. Y nunca has leído el código que lo hace correr. Para esa situación se hizo una auditoría de vibe-coding. La verdad incómoda pero simple que hay debajo: no puedes confiar en código que nunca has leído. Antes de que dinero real o usuarios reales lo toquen, alguien que lee código para vivir tiene que mirar lo que el modelo escribió de verdad, no lo que parece que hace.

Esto no es un argumento contra construir con IA. Te dio un producto más rápido que cualquier otra vía. Es un argumento a favor de revisar ese producto igual que revisarías cualquier cosa que está a punto de guardar datos de clientes y cobrar pagos.

Qué es una auditoría de vibe-coding?

Una auditoría de vibe-coding es una lectura estructurada del código generado por IA en busca de los riesgos que el modelo se saltó. No es una revisión de funcionalidades. Una revisión de funcionalidades pregunta "hace lo que el usuario quiere". Una auditoría hace las preguntas que el prompt nunca hizo: quién puede leer estos datos, qué pasa cuando esta llamada falla, dónde terminó este secret, qué se rompe con mil usuarios en vez de diez.

La distinción importa porque los fallos aquí son invisibles desde fuera. El producto parece terminado. Los huecos están en las partes que ninguna demo ejercita: el camino donde se cae la red, la petición que llega dos veces, el usuario que edita la URL para leer el registro de otro. Leemos el código para encontrarlos antes de que lo haga un usuario.

Las siete cosas que revisamos primero

Toda auditoría empieza en los mismos sitios, porque el software vibe-coded se rompe en los mismos sitios. Estos son los hallazgos que más sacamos a la luz.

• Seguridad y autorización. El login funciona. La comprobación que impide que el usuario A lea los datos del usuario B falta, o vive en el frontend donde cualquiera puede esquivarla. Es el hallazgo grave más común, y el más caro de pasar por alto.
• Integridad de datos. Escrituras que pueden completarse a medias. Un registro guardado sin el registro del que depende. Estado que la base de datos no puede garantizar de verdad, así que los números se desvían con el tiempo y nadie sabe por qué.
• Secrets filtrados. API keys, URLs de base de datos y tokens hardcodeados en código de cliente o commiteados al repo. El modelo los pega inline porque así corre el ejemplo. Cualquiera que abra el bundle puede leerlos.
• Manejo de errores. El happy path está cubierto. Una llamada fallida, un timeout o un resultado vacío lanza una excepción no manejada y la pantalla se queda en blanco, sin mensaje y sin recuperación.
• Escalabilidad y queries. Una llamada a base de datos metida en bucle dentro de un render, o una tabla entera traída para contar sus filas. Bien con diez registros en la demo, fatal con cien mil en producción.
• Dependencias y licencias. Paquetes desactualizados, abandonados o con vulnerabilidades conocidas, más licencias que prohíben en silencio el uso comercial que estás planeando.
• Cobertura de tests. Normalmente ninguna. No hay nada que impida que el siguiente cambio, escrito por IA o no, rompa en silencio lo que ya funciona.

"El peligro del software vibe-coded no es que el código sea malo. Es que nadie lo ha leído. La confianza es lo único que un modelo no puede darte, y es lo único que decide si puedes lanzar."

Severidad: qué bloquea el lanzamiento frente a qué puede esperar

No todo hallazgo detiene un lanzamiento, y tratarlos como si lo hicieran solo te congela. Ordenamos todo lo que encontramos en tres cubos para que sepas qué arreglar esta noche y qué planificar.

• Blocker. Cualquier cosa que expone datos de clientes, pierde dinero o corrompe estado. Una comprobación de autorización rota o una clave de pago filtrada no espera. El lanzamiento espera por ella.
• Alto. Riesgo real que aún no ha mordido. La query que muere al escalar, el manejo de errores ausente en un camino de pago, la dependencia abandonada con un CVE conocido. Arréglalo antes de crecer hasta él.
• Limpieza. Deuda real pero sobrevivible. Patrones inconsistentes, validación fina en entradas de bajo riesgo, tests ausentes en código estable. Vale la pena, es seguro planificarlo.

El sentido del reparto es la honestidad sobre la urgencia. No disfrazamos un item de limpieza como blocker para inflar el trabajo, y no dejamos que un blocker real se esconda en una lista larga.

Qué obtienes en realidad

El entregable no es un PDF de quejas con las que no puedes hacer nada. Son dos cosas. Primero, un informe de hallazgos: cada problema, su severidad y qué pone en riesgo, escrito para que un founder no técnico pueda decidir qué importa. Segundo, una rama arreglada con tests: los blockers cerrados, los altos atendidos donde el alcance lo permite, y una suite de regresión que mantiene los arreglos en su sitio. Recuperas código que funciona, no una lista de razones por las que está roto. Si quieres la mecánica más profunda de cómo corre esa pasada de hardening, la cubrimos en QA para código generado por IA.

Auditoría frente a QA completo frente a reconstrucción

Son tres decisiones distintas, y la respuesta honesta depende de lo que saque la lectura.

• Auditoría. La decisión correcta cuando el producto funciona en gran medida y necesitas saber qué se esconde antes de escalar o cobrar pagos. Rápida, enfocada, termina en un informe de hallazgos y una rama arreglada.
• QA completo. La decisión correcta una vez el producto es real y continuo. Un proceso permanente de tests, revisiones y hardening que impide que el siguiente cambio deshaga el último. La auditoría suele ser el primer paso hacia él.
• Reconstrucción. A veces la lectura muestra que el núcleo mismo está mal, un modelo de datos que no puede sostener lo que necesitas, o el mismo patrón roto copiado por toda la base de código. Cuando eso pasa, reconstruir el núcleo es más barato que parchearlo para siempre, y lo decimos en la primera llamada en vez de cobrarte por parchear un cimiento que hay que volver a verter.

Coste y plazos

Una auditoría va de unos pocos días a unas dos semanas. El rango es honesto, no evasivo, y dos cosas lo mueven: cuán grande es la base de código y cuánto dinero real o datos sensibles toca. Una herramienta interna de solo lectura cae en el extremo corto. Un producto que cobra pagos y guarda datos personales cae en el extremo largo, porque esas son justo las partes que necesitan la lectura más cercana. Lo dimensionamos tras un primer vistazo, no antes, y te decimos el rango por adelantado en vez de que lo descubras en tu factura. Esto es la entrada a nuestro servicio de QA de software.