Estaba pensando en los vibe coders y el mantenimiento. Luego revisé mis propias apps.

He estado trabajando con muchos vibe coders en mi trabajo, y eso me hizo pensar en el mantenimiento. El software necesita cuidados después de lanzarlo, los paquetes se quedan viejos y se descubren vulnerabilidades, y cuando empiezas a construir con IA es fácil no pensar en nada de esto.

Entonces me di cuenta de que debía aplicar el mismo razonamiento a mis propios proyectos, así que revisé su historial de git. Encontré bastante, aunque no lo que esperaba, y una de las cosas seguía abierta el día que miré.

Así que este ya no es un artículo sobre lo que olvidan los demás. Es sobre mí.

Un aviso, tres apps

El 14 de octubre, Next.js publicó correcciones para dos vulnerabilidades críticas y una de severidad alta. "Crítica" aquí significa ejecución remota de código, es decir, que bajo ciertas condiciones un desconocido en internet podría ejecutar su propio código en tu servidor sin iniciar sesión. La corrección llegó en la versión 16.4.1.

Tengo tres apps en Next.js, todas construidas con herramientas de programación con IA y todas con la misma persona responsable, que soy yo. Esto fue lo que pasó:

App	Cuándo pasó su código a una versión con parche	Tiempo tras el aviso	En producción
chandlernguyen.com	18 de octubre	4 días	18 de octubre
DIALØGUE	29 de octubre	15 días	29 de octubre
Prova	3 de noviembre	20 días	3 de noviembre

Cuando miré el 3 de noviembre, Prova seguía fijado en Next.js 16.2.6, la versión que usaba desde mayo, y eso era lo que corría en producción. Al ejecutar pnpm audit --prod aparecieron 5 avisos críticos, todos en Next.js.

Esa cifra suena peor que lo que encontré, así que quiero ser justo. Cuando los revisé uno por uno con mis herramientas de IA, la mayoría de los críticos no se aplicaban a Prova. No tiene funciones use cache, no corre en Windows y no encontré ninguna entrada controlada por un atacante que llegue al código de next/og. Los de optimización de imágenes probablemente tampoco se aplican en Vercel, aunque eso es una inferencia a partir de cómo se comporta la plataforma, ya que no encontré ninguna declaración de Vercel que lo diga. Lo que sí se aplicaba claramente era un problema de denegación de servicio de severidad alta en Server Actions, lo que significa que alguien podría haber interrumpido la app, y eso siguió activo hasta el parche.

Pasé producción a Next.js 16.4.5 ese mismo día. La auditoría bajó de 5 críticos a 0, y también desapareció la mayoría de los de severidad alta. Lo que queda está fuera de Next.js y todavía tengo que resolverlo, así que esto está mejor, pero no limpio.

No puedo llamar a nada de eso buen mantenimiento. Los peores avisos no afectaron a Prova sobre todo por cómo resulta estar construido, no porque alguien lo hubiera revisado. Eso es suerte, y solo lo sé porque por fin miré.

Tampoco puedo atribuirme mucho mérito por la primera fila. El commit de mi sitio del 18 de octubre fue una actualización general de herramientas, desde Next.js 16.1.6, y su mensaje no menciona el aviso. Puede que simplemente haya caído en el momento justo.

Por qué estar ocupado no ayudó

La explicación fácil sería que Prova estaba descuidado, y hay algo de verdad en eso. Tuvo un intervalo de 41 días entre commits en agosto y septiembre.

Sin embargo, esa explicación se cae en octubre. Prova tuvo 175 commits ese mes. Lancé correcciones para iOS, facturación, correo y traducciones, y la versión de Next.js no se movió. El 30 de octubre incluso escribí un plan de mantenimiento de dependencias. Su línea de estado dice: "planificado; implementación sin empezar".

Así que la actividad no es mantenimiento, y creo que esto es lo que más importa para cualquiera que construya con IA. Cuando creas una función, recibes respuesta de inmediato. Puedes ver el botón, hacer clic y ver cómo funciona. Cuando se anuncia una vulnerabilidad en un paquete que instalaste hace cinco meses, no recibes nada. La app sigue sirviendo páginas, las pruebas siguen en verde y el build pasa. Nada está roto, y justo por eso nadie mira.

Sería como un detector de humo que solo suena si vas y le preguntas. Las herramientas de IA hacen mucho más barato construir la casa. No instalan el detector.

Esto también me pasó antes. DIALØGUE no tuvo commits entre el 6 de octubre de 2025 y el 11 de enero de 2026. React2Shell, una vulnerabilidad crítica de Next.js y React, se hizo pública a principios de diciembre. Mi commit con el parche es del 11 de enero, más de cinco semanas después, y el registro de despliegue de producción más antiguo que todavía puedo ver es del 18 de enero, así que no puedo decirte exactamente qué estaba corriendo en diciembre. Lo que probablemente más me ayudó no tuvo nada que ver conmigo: Vercel dice que desplegó reglas de firewall para todos sus clientes, aunque también dice claramente que no hay que confiar en ellas en lugar de aplicar el parche.

Quiero dejar clara una cosa, porque la expresión "vibe coder" puede sonar a insulto. Aprendí a programar con cursos estructurados, incluido un certificado de ciberseguridad, estos repositorios tienen pruebas y controles de revisión, y aun así pasó. Por eso no creo que sea un problema de principiantes. Creo que es lo que ocurre por defecto cuando crear software sale barato y nadie tiene asignado vigilarlo.

Cómo es el detector

La buena noticia es que una revisión muy pequeña cambia mucho esto.

El 27 de octubre añadí pnpm audit --prod a la CI de mi sitio, que es simplemente el conjunto automático de revisiones que se ejecuta cuando se sube código. El 28 de octubre falló por un aviso en una biblioteca de renderizado de correos que mi sitio incluía pero nunca usaba, y el 29 de octubre eliminé esa biblioteca. Llevó dos días y no tuve que acordarme de nada.

Nada de eso fue ingenioso. Simplemente hay que decirle a alguien, o a algo, que mire.

Actualizar paquetes no me habría salvado

Si este artículo terminara aquí, te daría una falsa tranquilidad, porque algunas de las correcciones más incómodas que hice en octubre no tenían nada que ver con paquetes desactualizados. Eran errores en mi propio producto.

En DIALØGUE, por ejemplo:

• Se podían llamar funciones privilegiadas de la base de datos con solo la clave pública, y un usuario con sesión iniciada podía llegar a funciones pensadas solo para mi backend.
• Un podcast reembolsado podía reactivarse y completarse sin que se volviera a cobrar, y en un pequeño número de podcasts eso ocurrió.

En Prova, los roles públicos de la base de datos habían heredado permisos que nadie eligió, como TRUNCATE, porque venían de un valor predeterminado de la plataforma. Ninguna ruta de la app los usaba, pero estaban ahí.

Ninguna actualización de versión arregla nada de esto. Estas apps funcionaban con estos problemas, y tampoco ahí falló nada. Solo salieron a la luz porque una revisión de seguridad fue a buscarlos, y yo había hecho revisiones de seguridad anteriores en estos productos que no los detectaron todos.

¿Se abusó de algo de esto? No lo sé, y no puedo averiguarlo del todo. Mis registros de base de datos solo llegan a unos 90 días atrás, y algunos de estos problemas son más antiguos. En el periodo que puedo ver, no encontré llamadas externas a esas funciones. Eso cubre una ventana limitada y no demuestra que no pasara nada. Tampoco puedo saber quién o qué reinició esos podcasts reembolsados, aunque un reintento en mi propio código es mi mejor hipótesis.

Esta tampoco es una lista completa. Sigo trabajando en otros problemas y no los describiré mientras estén abiertos.

La cuestión de los modelos no es la que yo creía

Esperaba escribir que los modelos de IA antiguos te cuestan más dinero. No puedo respaldarlo. Lo busqué, y no tengo una comparación de costos de antes y después en ninguno de estos repositorios, así que sería solo una suposición.

Lo que encontré es más extraño. Los modelos de borrador de guion y de revisión de DIALØGUE estaban configurados en gemini-3.5-flash hasta el 12 de octubre. La documentación de Google ahora dice que ese endpoint no se va a apagar y que redirige automáticamente las solicitudes a gemini-3.6-flash. No sé cuándo empezó esa redirección, así que no puedo decirte qué modelo respondía ni durante cuánto tiempo. Un nombre de modelo en tu configuración no congela el modelo.

Los precios también se mueven. Gemini 3.8 Flash, al que pasé Prova y DIALØGUE en octubre, aparece a $0.75 por millón de tokens de entrada y $3.75 por millón de tokens de salida hasta el 31 de diciembre. Desde el 1 de enero de 2027 se duplica a $1.50 y $7.50. Me cambié apenas el mes pasado, y todavía tengo que calcular qué significa eso para mis costos.

Actualizar tampoco está libre de riesgo, y no quiero fingir que lo está:

• Poco después de pasar Ask Sydney a DeepSeek Flash, al menos una pregunta falló en producción porque el modelo quería más rondas de búsqueda de las que permitía mi código.
• Cuando migré los embeddings de Prova, las primeras ejecuciones fallaron después de que se vaciara la tabla de la base de conocimiento, así que la recuperación quedó degradada hasta que la restauré.
• Esa misma migración sacó a la luz un ajuste de producción que habría enviado un nombre de modelo de Claude a la API de Google.

Lo que hizo confiable la migración de Prova fue algo aburrido. Tenía una evaluación registrada de antes del cambio, 22 de 24 decisiones de revisión de sprint correctas, y obtuve la misma puntuación después. Sin eso, solo habría estado esperando que saliera bien.

¿Deberías mantenerlo siquiera?

La pregunta más difícil es la que casi dejo fuera. Cada app que lanzas es una pequeña suscripción que tienes que seguir pagando con tu atención, y la IA ha hecho muy fácil apuntarse a más.

Con STRAŦUM tomé la otra decisión. Lo retiré y publiqué la v1 como implementación de referencia. El repositorio dice que no se mantiene como servicio de producción, y su archivo de seguridad enumera los avisos que conozco, incluidos problemas de dependencias de tiempo de build sin corrección disponible, que evalúa como de bajo riesgo práctico. Me parece un resultado perfectamente honesto. La versión deshonesta es una app que sigue aceptando nuevos usuarios mientras nadie la vigila.

Lo que haría el lunes

Si has lanzado algo con IA y hay gente usándolo, esta es la lista con la que empezaría. Nada de esto tiene que ser perfecto.

1. Ejecuta la auditoría una vez, hoy. npm audit --omit=dev o pnpm audit --prod, en cada repositorio que esté en producción. Luego pregúntale a tu herramienta de IA cuáles de los resultados se aplican a cómo está construida tu app, porque no se aplicarán todos.
2. Haz que esa revisión sea automática. Añádela a la CI para que pueda fallar sin que tengas que acordarte. Para una app que tocas poco, usa también una ejecución programada, porque una revisión que solo corre al subir código no ayuda en un mes tranquilo.
3. Lee tus permisos, no solo tus paquetes. Pregúntate qué puede hacer alguien con solo tu clave pública y sin cuenta. Luego pruébalo en una copia local en lugar de suponerlo.
4. Busca secretos en tu historial. Si alguna vez se hizo commit de una clave real, revócala. Borrar la línea no basta.
5. Averigua hasta dónde llegan tus registros antes de necesitarlos. De eso depende que alguna vez puedas responder si se abusó de algo.
6. Mantén una pequeña evaluación para cada función de IA. Incluso 20 ejemplos reales con buenas respuestas conocidas te dirán si un cambio de modelo empeoró las cosas.
7. Revisa con regularidad las páginas de retirada de modelos y de precios de tu proveedor de IA. Ponlo en tu calendario. Si usas Gemini 3.8 Flash, el 1 de enero ya es una buena fecha para empezar.
8. Decide conservar o retirar cada app. Si no vas a vigilarla, retírala o dilo.

Todavía estoy averiguando qué parte de esto se puede dejar en manos de un agente de forma programada. Lo que sí sé es que escribir el plan el 30 de octubre no aplicó ningún parche.

Si estás construyendo con IA, ¿cuándo revisaste por última vez algo que ya habías lanzado, y qué encontraste? Me gustaría mucho saberlo, sobre todo si tienes un detector mejor que el mío.