He creado un producto con IA: cómo mejorarlo sin estropear lo que funciona

Descubre más sobre cómo trabajar con modelos en la documentación de Ailoot.

¿Por qué empieza el trabajo más caro después del lanzamiento?#

Creaste una aplicación en una tarde, publicaste un enlace y se lo enviaste a tus amigos. Funciona. Luego, una semana después, aparece la primera persona real, hace clic donde no debe y la mitad de las funciones deja de funcionar. Le pides a Claude que lo arregle: arregla una cosa y estropea otra. ¿Te suena?

Y ahí surge la pregunta principal: ¿qué haces después de lanzar un producto, una vez pasada la euforia del primer prototipo funcional, cuando todavía tienes que mantenerlo de alguna manera? Podríamos llamar a esto vibe coding para adultos. Crear es emoción y velocidad. El mantenimiento exige tener la cabeza fría: entender qué estás cambiando y mantenerlo bajo control. La mayoría fracasa en esta segunda parte porque nadie les prepara para ella.

Un estudio del sector analizó más de un millón de cambios de código de 2.444 equipos y calculó adónde va realmente el dinero invertido en desarrollo con IA. Este es el panorama:

La guía «El coste oculto del vibe coding» explica estas cifras con más detalle. Allí la pregunta era por qué estás pagando. Aquí la pregunta es distinta: 44 centavos de cada dólar se destinan a corregir errores, y este artículo trata de evitar que esa proporción crezca. El trabajo de mantenerla bajo control se llama mantenimiento.

La diferencia entre quien hace vibe coding para adultos y quien simplemente cuida de una red neuronal se ve después del lanzamiento. La base de código de la primera persona crece, incorpora mejoras y nada se rompe. Un mes después, el producto de la segunda se ha convertido en un cacharro lleno de fugas que da miedo tocar. A continuación, explicaré cómo acabar en el primer grupo.

Qué se rompe de verdad: 5 desastres posteriores al lanzamiento#

Estos son informes públicos posteriores a incidentes de productos reales creados con IA, con cifras y fechas. Piensa en ellos como un mapa de un campo minado: cada mina ya le ha explotado a alguien, y se sabe cómo evitarla.

Los cinco casos tienen la misma causa raíz. De forma predeterminada, la IA hace que las cosas funcionen ahora, no que sean seguras dentro de un mes y bajo carga. No puedes ver la diferencia mientras desarrollas en tu ordenador. Se hace evidente cuando aparece el primer desconocido con malas intenciones.

El problema no es no escribir el código a mano; mucha gente trabaja así. El problema es no preguntar: «¿La base de datos está protegida?». A continuación, te mostraré un prompt que hará esa pregunta por ti.

La primera red de seguridad es Git y volver a «como estaba ayer»#

Cuando Claude rompe algo, necesitas un botón para «dejarlo como estaba ayer». Técnicamente, ese botón se llama Git, y es más sencillo de lo que parece.

Tres términos que una persona no programadora debe entender:

1. Repositorio: la carpeta de tu proyecto guardada en la nube (normalmente en GitHub). Una copia de todo tu código que no está únicamente en tu ordenador.
2. Commit: un punto al que volver. En la práctica, le estás diciendo al código: «guarda este estado». Cada commit es una marca a la que puedes regresar.
3. Deploy: un traslado. El código estaba en local, en tu ordenador, y solo funcionaba para ti. El deploy lo envía a un servidor externo para que funcione para todo el mundo.

Mientras tengas puntos de commit recientes, puedes revertir cualquier rotura con una sola frase. Literalmente.

He roto algo: ayer todo funcionaba, pero hoy ya no. Busca el último commit en el que todo estaba bien, muéstrame qué ha cambiado desde entonces y devuelve el proyecto a ese estado.

Dos reglas que debes aplicar de inmediato, antes de que otras personas vean el producto:

• El repositorio debe ser privado. No público. De lo contrario, cualquiera puede leer tu código y todo lo que contiene.
• Añade el archivo de secretos a la lista de exclusión. Las claves, contraseñas y credenciales de acceso a la base de datos se guardan en un archivo aparte (normalmente .env), que nunca debe entrar en el repositorio. Añade una línea para .env en .gitignore y los secretos se quedarán contigo.

Hay una guía aparte sobre cómo revertir cambios de forma segura en Claude Code: Cómo revertir cambios en Claude Code. Sin puntos de retorno, caminas por la cuerda floja sin red de seguridad y tarde o temprano te caerás.

¿Qué revierte /rewind y qué no?#

Claude Code toma una instantánea del estado antes de cada cambio que hace. El comando /rewind (o pulsar Esc dos veces) devuelve tanto los archivos como la conversación a un punto seleccionado. Es práctico: si rompiste una función hace cinco minutos, puedes volver cinco minutos atrás.

Pero hay una trampa que hace que los principiantes pierdan datos. /rewind no revierte todo:

La propia Anthropic lo dice claramente: las instantáneas son un botón local para «deshacer», mientras que Git es el historial permanente. Las instantáneas complementan el control de versiones, pero no lo sustituyen.

La conclusión práctica para una persona no programadora: /rewind te salvará cuando «Claude acaba de romper una función». Pero si ha conseguido borrar una fila de la base de datos o subir código a la nube, solo Git y una copia de seguridad de la base de datos pueden recuperarla. Así que conserva las dos capas: instantáneas para las reversiones rápidas y commits para el historial permanente del proyecto.

¿Cómo hacer mejoras sin romper lo que ya funciona?#

Una de cada dos personas acaba atrapada en este bucle. Pides a la IA que arregle un pequeño error. Sugiere un cambio razonable. Ese cambio rompe otra cosa. Le pides que arregle el nuevo problema y aparecen dos más. Y así sucesivamente.

El bucle se produce porque el vibe coding es no determinista. El mismo prompt te da un código distinto cada vez. Por eso, cada edición puede cambiar discretamente la lógica cercana: el umbral del descuento pasa del 10 al 12 por ciento o una regla de validación cambia su comportamiento, sin que tú compruebes nada y sin una sola advertencia. Esto se llama deriva lógica y daña silenciosamente justo lo que genera ingresos: los precios, los accesos y los pagos.

Hay una regla para protegerse de esa deriva, tan sencilla que se puede colgar en la pared: no confirmes código que no puedas explicar palabra por palabra a otra persona.

En la práctica, esto se convierte en una plantilla lista para usar antes de modificar cualquier código que ya funciona. Hace que la IA avance en pasos pequeños y te muestre exactamente qué ha cambiado.

Antes de cambiar el código, haz lo siguiente:

Guarda el estado funcional actual como un punto de retorno independiente (commit).

Describe con palabras exactamente qué planeas cambiar y en qué archivos.

Haz el cambio más pequeño posible: solo lo necesario para resolver mi tarea, nada más.

Muéstrame qué ha cambiado y explica cada cambio de manera que yo pueda explicárselo a otra persona.
No toques la lógica de precios, accesos o pagos, a menos que te lo pida.

Otro principio que ahorra semanas es respetar los límites de la tarea. Un punto de dolor, un cambio, una implementación rápida. No le pidas a la IA que reescriba medio proyecto en un solo prompt. A veces, los desarrolladores profesionales empiezan a construir un Uber entero cuando solo necesitaban un botón, y alargan el trabajo durante meses. No necesitas eso.

Todo lo que describo se basa en una sola cosa: gestionar el contexto. Para evitar que la IA rompa la lógica cercana, tiene que recordar las reglas de tu proyecto.

¿Cómo comprobar un cambio antes de publicarlo?#

Entre «funciona en mi ordenador» y «funciona para todo el mundo» hay un paso intermedio que los principiantes se saltan: una copia de prueba. Es una réplica separada de tu entorno de producción donde compruebas los cambios antes de que los vean personas reales. El ciclo de trabajo es el siguiente:

1. Desarrolla y comprueba el cambio por tu cuenta (desarrollo).
2. Despliégalo en staging, una copia de producción sin usuarios reales.
3. Ejecuta los escenarios principales y asegúrate de que nada haya cambiado.
4. Solo entonces despliégalo en producción.

Por qué importa después del lanzamiento: cada publicación conlleva un riesgo. Un pequeño cambio de código puede impedir iniciar sesión. Un ajuste que falta puede hacer caer todo el producto. Staging detecta estos problemas sin consecuencias; en producción pierdes clientes.

Para no tener que comprobarlo todo manualmente cada vez, dale a la IA un prompt para que compare el comportamiento de la nueva versión con el de la anterior en las áreas críticas.

Voy a desplegar un cambio. Recorre los escenarios principales del producto en orden y comprueba que cada uno siga funcionando como antes:

Registro e inicio de sesión de un usuario nuevo.

Pago y concesión del acceso después del pago.

Permisos de acceso: un usuario normal no puede ver los datos de otra persona ni el área de administración.

Las cifras clave de la lógica de negocio (precios, descuentos, límites) no han cambiado.
Si algo se comporta de forma diferente a la versión anterior, detente y muéstrame exactamente qué ha cambiado.

¿Dónde están tus secretos? El mayor agujero para principiantes#

Voy a explicar en detalle la mayor trampa porque acaba con más productos que cualquier otra. Cuando la IA escribe código, lo más fácil es poner una clave donde funcione enseguida: directamente en el código de la página que se abre en el navegador. Durante el desarrollo no notarás la diferencia. Pero cualquiera puede leer todo lo que llega al navegador abriendo las herramientas para desarrolladores.

El fundador cuyos clientes recibieron cargos por $87,500 dijo después que un solo prompt podría haberlo evitado. Al final se revirtieron los cargos, pero las comisiones no reembolsables y la pérdida de tranquilidad permanecieron. Este es el prompt.

Revisa todo el proyecto y asegúrate de que ninguna clave secreta termine en el navegador:

Encuentra todas las claves de la base de datos, el sistema de pago y los servicios externos.

Asegúrate de que cada una esté guardada solo en el servidor, en variables de entorno, y no en el código de la página.

Revisa el historial del proyecto: ¿se ha incluido alguna clave por accidente anteriormente?
Muéstrame una lista de todos los lugares donde encontraste secretos y qué hay que hacer en cada caso.

El siguiente peligro cercano es comprobar los permisos de acceso solo en el navegador. Si tu producto decide en el código de la página si debe «mostrar el área de administración», cualquiera puede saltarse esa decisión. Los permisos de acceso siempre deben comprobarse en el servidor. La base de datos solo debe devolver datos a quienes tengan derecho a ellos: para eso sirve la seguridad a nivel de fila (RLS), que debe activarse en todas las tablas.

Antes de vender accesos o dejar entrar a otras personas, haz una auditoría de seguridad general del producto.

Revisa el proyecto como si fueras un atacante y busca agujeros de seguridad:

¿Hay claves secretas guardadas en código que se envía al navegador o en el historial del proyecto?

¿Está activada la seguridad a nivel de fila (RLS) en todas las tablas de la base de datos y se comprueban los permisos en el servidor, en lugar de hacerlo solo en el navegador?

¿Hay una copia de seguridad automática de la base de datos configurada, y he comprobado alguna vez que puedo restaurarla?

¿Está aislada la base de datos de producción del entorno en el que se ejecuta el agente de IA?
Para cada punto, dime si todo está bien o qué hay que corregir exactamente.

Hay una guía completa aparte sobre seguridad en el vibe coding: Cómo proteger una aplicación creada con vibe coding. La regla es sencilla: considera que todo lo que hace la IA de forma predeterminada no está protegido hasta que compruebes lo contrario.

Dónde alojar tu producto: los niveles de alojamiento#

No hace falta alquilar tu propio servidor y configurarlo manualmente desde el primer momento: al principio es una tarea complicada que te quitará tiempo. Puedes ir subiendo de nivel a medida que crece el producto:

1. Alojamiento gratuito (por ejemplo, Vercel): para ti, pruebas y proyectos pequeños. Funciona si la plataforma está disponible para tu público y no almacenas datos personales.
2. Una plataforma con despliegue en un solo comando (Railway): cuando tengas un backend y una base de datos. Despliegas con un comando y no necesitas configurar un servidor. La barrera de entrada es mínima.
3. Tu propio servidor dedicado: cuando la carga sea alta y necesites control total. Pásate a él más adelante, cuando alcances el límite de la plataforma.

Para alguien que no programa y acaba de lanzar un producto, la opción más sencilla es una plataforma con despliegue en un solo comando, sin configuración manual del servidor. Pásate a tu propio servidor más adelante. Si quieres seguir este camino con un ejemplo concreto, consulta la guía para desplegar un proyecto creado con vibe coding en tu propio servidor con Coolify.

¿Cuándo conviene separar la aplicación, la base de datos y las copias de seguridad?#

Hay tres cosas que no conviene guardar en la misma cesta: la aplicación, la base de datos y las copias de seguridad. Mientras haya pocos usuarios, todo puede estar junto, y no pasa nada. Pero hay una señal clara que indica cuándo conviene separarlos.

• Pon la aplicación y la base de datos en máquinas distintas. La señal: en los picos de carga, la CPU y la memoria se mantienen por encima del 70–80 por ciento, las solicitudes se ralentizan y la aplicación y la base de datos compiten por los mismos recursos. Al separarlas, puedes reforzar la base de datos sin tocar la aplicación, y viceversa.
• Sigue la regla de copias de seguridad 3-2-1. Tres copias de los datos, en dos tipos de soporte distintos, una de ellas fuera de las instalaciones. Esto protege contra fallos de hardware y ransomware. Lo importante es que las copias de seguridad sean automáticas.

La frecuencia de las copias depende de lo costoso que sea perder varias horas de datos. Para un servicio de suscripción en línea donde perder una hora de registros de pagos sea inaceptable, el intervalo debe ser menor de una hora o debes disponer de registros de transacciones y recuperación a un punto en el tiempo (PITR) verificados. Elige el intervalo según la pérdida máxima tolerable y prueba por separado el tiempo necesario para restaurar el servicio. Para un blog, basta con una al día. La lógica es sencilla: decide cuántos datos puedes permitirte perder y configura las copias de seguridad en consecuencia.

Ayúdame a decidir si ha llegado el momento de que mi producto pase a una infraestructura más avanzada. Comprueba cada punto y pregúntame al respecto:

¿Cuál es la carga de la CPU y la memoria en los picos: se mantiene el uso por encima del 70–80 por ciento o no?

¿Están la base de datos y la aplicación en la misma máquina o en máquinas distintas?

¿Hay configurada una copia de seguridad automática de la base de datos y he probado a restaurarla?

¿Hay una copia separada del entorno (staging) para comprobar los cambios antes del despliegue?
En función de los resultados, dame una recomendación clara: qué dejar como está, qué separar primero y por qué.

Hay otra cuestión: ¿base de datos gestionada o propia? Para un equipo pequeño, una gestionada casi siempre es mejor: una propia cuesta menos en hardware, pero consume horas de mantenimiento. Si trabajas por tu cuenta y tu producto no es una infraestructura, esas horas cuestan más que la diferencia de precio del servidor.

¿Cómo automatizar el mantenimiento?#

El mantenimiento manual agota. Puedes quitártelo de encima de dos maneras: con monitorización y con un agente de patrulla.

La monitorización utiliza dos herramientas distintas para dos tareas diferentes:

1. «¿El sitio está en línea?»: un monitor de disponibilidad (por ejemplo, UptimeRobot). Comprueba el producto cada pocos minutos y envía una alerta si deja de funcionar. Tiene un plan gratuito.
2. «¿Qué se ha roto exactamente?»: un rastreador de errores (por ejemplo, Sentry). Recopila errores dentro de la aplicación y muestra dónde y por qué ha fallado algo.

El primero detecta que el producto se ha caído. El segundo muestra qué función falló y por qué. Juntos responden a la pregunta: «¿Me enteraré de un fallo antes de que un cliente escriba al soporte?»

El segundo nivel de automatización es un agente de patrulla. Imagina una inmobiliaria: a las siete de la mañana, un agente de IA lee las consultas de la web, ve que el formulario de reservas está roto, encuentra la causa en el código y te trae una solución lista con una explicación. La revisas y dices «sí»; se despliega. El orden importa: primero resuelve el problema del usuario (concede el acceso, discúlpate) y luego investiga la causa y el dinero.

Una regla más sobre el acceso de la IA a la base de datos de producción: dale un usuario de solo lectura y oculta los datos personales tras una capa intermedia, de modo que el agente vea «nombre» en lugar del nombre real de una persona. Así, aunque cometa un error, no podrá borrar ni corromper físicamente los datos de producción. El incidente de la tabla anterior, donde un agente eliminó la base de datos de producción, trata precisamente de la falta de esta restricción. La guía Qué hacer si la IA ha borrado tu base de datos explica qué hacer si el desastre ya ha ocurrido.

¿Cuándo es hora de cerrar un producto?#

La parte más infravalorada del mantenimiento es saber cuándo dejar de mantener un producto. Quien crea muchas cosas tiene un cementerio de proyectos: creó uno, estuvo trasteando con él y luego lo abandonó. Es normal y no es un fracaso. El fracaso es arrastrar durante meses algo que nadie usa por arrepentirse del tiempo invertido.

Estos son algunos umbrales que puedes usar para decidir:

1. Dos semanas: suficiente para ver si una idea funciona. Si los primeros usuarios reales vuelven, sigue adelante. El silencio también es una respuesta.
2. Tres meses: el límite estricto. Si no ha despegado en tres meses, ciérralo. Con la velocidad del vibe coding, pasar seis meses probando una idea es demasiado.

Cerrar un proyecto es difícil desde el punto de vista psicológico, así que trátalo como una decisión, no como un sentimiento. Dejar un proyecto en el que has invertido es como despedir a un empleado que no puede hacer el trabajo: es desagradable, pero mantenerlo cuesta más que dejarlo ir.

El mantenimiento es el trabajo que se hace para que un producto siga vivo y sea útil para la gente. Todo lo demás —Git, copias de seguridad y monitorización— son solo herramientas que te ayudan a llegar al punto en que el producto empieza a trabajar para ti todos los días.

Crear un producto con IA en una tarde es la mitad del trabajo. Mantenerlo vivo y seguro a medida que crece: eso es lo que significa el vibe coding para adultos.

Para tu siguiente paso: Ailoot.