Eliminar de forma segura funcionalidades fantasma de repositorios generados por IA

Qué son las funcionalidades fantasma (y por qué dañan)

Las funcionalidades fantasma son partes de una base de código que parecen trabajo de producto real, pero nunca fueron requisitos reales. En repositorios generados por IA suelen aparecer como pantallas adicionales, rutas, endpoints de API o tablas de base de datos que la herramienta añadió porque supuso lo que una “app completa” debería incluir.

En la práctica esto puede ser una página de "Settings" pulida a la que nadie puede llegar, una API de "admin" que nunca se llama, o una tabla de "subscriptions" a la que nunca escribe nada. Todo compila, pero la funcionalidad no está conectada a necesidades de usuarios reales ni a flujos que funcionen.

El costo no es solo desorden. Cada página, endpoint y tabla de más aumenta la superficie de la app. Eso significa más lugares donde pueden aparecer bugs, más formas de filtrar secretos y más rutas confusas para quien mantenga el proyecto más adelante.

Las funcionalidades fantasma elevan riesgo y costo porque:

• Añaden ruido durante la depuración y ocultan el problema real.
• Amplían la exposición de seguridad mediante endpoints extra, verificaciones de auth incompletas y valores por defecto inseguros.
• Frenan los cambios porque da miedo romper dependencias desconocidas.
• Desorientan decisiones de producto porque el repo sugiere capacidades que en realidad no tienes.
• Aumentan el trabajo de mantenimiento (tests, migraciones, refactors) por cosas que nadie usa.

Estas características suelen venir de scaffolds de IA que generan módulos “estándar”, fragmentos de plantilla copiados o hilos de prompts donde se empezó una funcionalidad y nunca se terminó. A veces la idea era razonable; simplemente nunca se conectó a un recorrido de usuario real.

El objetivo es simple: conservar lo que soporta a usuarios reales y eliminar lo que no, sin romper flujos críticos. Un escenario común es un MVP generado por IA con tres pantallas diferentes de login, dos dashboards de admin y un esquema de facturación que no hace nada. Limpiar eso facilita securizar la app y reduce el coste de cambiarla.

Los tres tipos principales: páginas muertas, APIs sin usar, tablas de marcador de posición

Al eliminar funcionalidades fantasma, la mayor parte del riesgo se concentra en tres lugares. Están quietas en el repo, pero aumentan la superficie de ataque, la confusión y el trabajo de mantenimiento futuro.

1) Páginas muertas (rutas inalcanzables)

Las páginas muertas son pantallas que existen en el enrutador, pero los usuarios reales nunca las alcanzan. Suelen aparecer como flujos abandonados como "Team Settings", "Billing" o "Admin" que se generaron al inicio y luego se olvidaron.

Importan porque usuarios curiosos las pueden descubrir, compartir, indexar o abrir directamente. Incluso una página a medio hacer puede filtrar datos internos, lanzar errores ruidosos o exponer flags y pistas de entorno.

2) APIs sin usar (endpoints sin llamadores reales)

Las APIs sin usar son rutas del servidor que no tienen llamadores reales desde el frontend, o solo las toca una página de prueba o un script de ejemplo. Estos endpoints se despliegan por accidente con facilidad, sobre todo cuando todo vive bajo una carpeta genérica api.

El peligro no es solo código de más. Los endpoints sin uso suelen omitir comprobaciones de auth, aceptar entradas demasiado amplias o devolver más datos de los necesarios. Eso los convierte en un blanco blando.

3) Tablas de marcador de posición (estructura falsa en la base de datos)

Las tablas de marcador de posición parecen progreso, pero muchas veces son cascarones vacíos: columnas genéricas, sin constraints, sin índices y sin lecturas ni escrituras reales desde la app.

También engañan el trabajo futuro. Alguien ve la tabla y asume que la funcionalidad existe, y luego construye encima. Así los esquemas “temporales” se convierten en deuda permanente.

Otras señales comunes de funcionalidades fantasma incluyen módulos que son mayormente TODOs, pantallas de admin solo demo que omiten permisos, autenticación simulada que acepta cualquier email y archivos de configuración para servicios que no usas.

Antes de eliminar: decide qué significa “seguro” para tu app

Eliminar código es seguro solo si estáis de acuerdo en lo que no debe cambiar.

Empieza por los flujos clave, no por archivos. Para la mayoría de apps eso incluye signup, login, restablecimiento de contraseña, logout y cualquier acción relacionada con dinero o datos como checkout, creación de un registro, exportar o invitar a un compañero. Si tu equipo depende de una pantalla de admin interna a diario, inclúyela.

Luego sé honesto sobre quién usa la app hoy. Los usuarios que pagan requieren más cautela. Una demo interna usada por dos personas puede tolerar más cambios. Si nadie la usa aún, “seguro” podría significar simplemente: mantener la demo funcionando mientras cortas todo lo que aumenta el riesgo.

Una regla de decisión simple ayuda a evitar debates largos:

• Eliminar ahora: ningún usuario, sin referencias, claro placeholder o riesgo.
• Archivar: podría volver más tarde, pero no debe ejecutarse en producción.
• Conservar pero marcar: se usa hoy, pero necesita un responsable o reescritura.

Tu regla de aceptación puede ser llana: “No cambio de comportamiento en los flujos clave.” Los mismos botones hacen lo mismo, las mismas páginas cargan y los mismos datos acaban en el mismo lugar. Si el comportamiento debe cambiar, no estás eliminando: estás rediseñando.

Antes de tocar nada, prepara rollback. Conserva un commit conocido bueno, confirma cómo redeployarlo y decide quién puede aprobar un rollback si algo se rompe.

Cómo encontrar páginas muertas y rutas huérfanas

Las páginas muertas son pantallas que existen en el repo pero no en el producto. Las rutas huérfanas son URLs que técnicamente funcionan, pero nada en la app apunta a ellas.

Empieza por lo que un usuario puede realmente clicar. Abre cada menú de navegación, header, footer, barra lateral y dropdown de perfil, y lista las URLs destino. Compáralas con tu configuración de rutas (archivos de router, carpetas pages, arrays de rutas). Todo lo que esté en rutas pero no sea alcanzable desde la navegación es candidato.

Lugares rápidos para buscar:

• Rutas que nunca referencia un componente de menú.
• Páginas/componentes que solo aparecen en comentarios, JSON de ejemplo o datos de seed.
• Rutas “temporales” como /admin, /debug, /test, /demo, /old, /v2, /settings-2.
• Rutas condicionadas por flags que nunca se dan (un flag siempre false, un rol que nunca se asigna).

Si tienes analytics o logs del servidor, úsalos como comprobación de la realidad. Una ruta con cero visitas durante semanas es una señal fuerte, especialmente si no forma parte de un flujo de admin. Sin logs, haz un rastreo manual: sigue los flujos principales y luego prueba algunas URLs probables directamente.

Ejemplo: un MVP generado por IA puede incluir /team/invite y /billing/upgrade porque el prompt mencionó “SaaS”. Si esas páginas no tienen enlaces, no tienen tests y no están cableadas al backend, suelen ser seguras para eliminar o poner en cuarentena.

Cómo encontrar endpoints API sin usar o riesgosos

Los repos generados por IA a menudo vienen con endpoints que sonaban útiles en el prototipo pero nunca se integraron en el producto. Empieza construyendo un inventario y luego prueba qué llama a cada endpoint.

Primero, lista cada endpoint del backend (archivos de router, controllers, funciones serverless y cualquier carpeta api). También escanea la config por rewrites que puedan exponer handlers.

Luego traza llamadores. Busca en el frontend fetch o axios, revisa jobs y colas, y busca handlers de webhooks que terceros puedan golpear. Si tienes logs, busca rutas de endpoint en los últimos 7 a 30 días. La ausencia de tráfico no es prueba perfecta, pero es un indicio fuerte.

Antes de borrar nada, marca endpoints riesgosos. Señales comunes: rutas de debug accesibles en producción, bypasses de auth (tokens admin hardcodeados, userId en query params), CORS amplio en rutas sensibles, falta de validación y endpoints que devuelven secretos o errores internos detallados.

Para cada endpoint elige un resultado: eliminarlo, aislarlo (quitarlo del routing público, restringir acceso) o conservarlo y arreglarlo con auth, validación y límites de tasa.

Cómo detectar tablas de marcador de posición y estructura falsa

Los repos generados por IA a veces incluyen una base de datos que parece completa pero es parcialmente imaginaria. Las tablas de marcador de posición confunden a los desarrolladores, ocultan bugs reales y aumentan el riesgo cuando esquemas “temporales” empiezan a contener datos reales.

Empieza listando cada tabla y columna, y luego traza qué las toca realmente. Una tabla suele ser real si la app la lee, la escribe y tiene relaciones claras con tablas núcleo (users, orders, projects). Si solo aparece en una migración y en ningún otro lugar, trátala como sospechosa.

Señales de que una tabla probablemente es un placeholder

Algunas señales confiables:

• Nombres como sample_*, demo_*, temp_*, test_*, mock_*, staging_*, placeholder_*.
• Sin claves foráneas ni índices, aunque debería relacionarse con otras tablas.
• Columnas genéricas como data JSON, value TEXT, meta TEXT, notes TEXT con significado poco claro.
• Datos falsos (lorem ipsum, emails falsos, IDs fijos como user_id = 1).
• Duplicados (dos versiones de “subscriptions”, “payments” o “profiles”).

También inspecciona migraciones por experimentos abandonados: una migración crea una tabla, otra crea una versión diferente y nada limpia la antigua. Si múltiples tablas representan el mismo concepto, frena y verifica cuál esquema espera la app en producción.

Cuando decidas qué hacer, elige un camino: eliminarla, fusionarla o reconstruirla correctamente. Eliminar es lo más seguro solo después de confirmar que no hay lecturas, escrituras ni jobs/reportes que la usen.

Paso a paso: eliminar funcionalidades fantasma sin romper la app

Eliminar lo incorrecto puede romper login, permisos o facturación. Trata cada funcionalidad sospechosa como una pequeña petición de cambio, incluso si estás seguro de que es falsa.

Para cada página muerta, endpoint sin uso o tabla placeholder, anota tres cosas: qué debe ocurrir tras la eliminación, cómo verificarás que nada importante dependía de ello y quién puede aprobar la decisión.

Un orden de operaciones de bajo riesgo:

• Elimina páginas ocultas y UI sin uso primero.
• Elimina handlers de API sin uso después (más los helpers que solo existen para esa funcionalidad).
• Limpia la base de datos al final (migraciones, modelos ORM, jobs cron).

Después de cada eliminación, compila la app, ejecuta tests si los tienes y recorre los flujos clave manualmente. Vuelve a escanear los límites de autenticación también. Es posible eliminar código de forma que se omita middleware o se cambie una comprobación de permisos accidentalmente.

Errores comunes que causan roturas o problemas de seguridad

Las roturas suelen ocurrir cuando el repo parece limpio en el navegador, pero partes ocultas siguen ejecutándose en producción. Piensa en lo que puede llamarse sin clicar nada: jobs, webhooks, tareas cron y solicitudes HTTP directas.

Una trampa común es borrar una página o botón pero dejar el API detrás. La pantalla de admin puede desaparecer, pero el endpoint sigue aceptando peticiones. Si la autenticación es débil, ese endpoint se vuelve un objetivo fácil.

Otro error es asumir que un endpoint no se usa porque no está enlazado en la UI. Workers en segundo plano, tareas programadas e integraciones de terceros pueden seguir llamándolo. Ejemplo: borras /api/email/weekly-summary porque no aparece en ninguna página, pero un job nocturno aún lo invoca, empieza a fallar y genera reintentos y logs ruidosos.

La limpieza de la base de datos es donde la gente pierde datos. Borrar tablas “placeholder” sin revisar backups, el orden de migraciones y el uso en producción puede romper despliegues o borrar registros que luego se reutilizaron.

Antes de borrar algo, comprueba:

• Has eliminado acceso, no solo la UI (rutas/controllers no son accesibles públicamente).
• Has buscado uso en jobs/workers y llamadas de terceros.
• Has validado backups y el orden de migraciones.
• Has eliminado rutas de debug, claves de prueba y accesos admin temporales en producción.

Lista rápida de comprobaciones antes de eliminar

Antes de borrar código, confirma que no estás quitando algo que mantiene un flujo.

Empieza por la alcanzabilidad. Si un usuario normal no puede llegar a una página con clicks normales (no escribiendo una URL oculta), es un candidato fuerte. Aun así, confirma que no estás cortando un camino lateral como onboarding, restablecimiento de contraseña o configuración de admin.

Comprobaciones rápidas:

• ¿Puede un usuario normal acceder sin URLs especiales, cuentas de prueba o toggles de dev?
• Si es un endpoint API, ¿está protegido (auth) y guardado (validación básica, limites de tasa) o está abierto?
• Si toca datos, ¿puedes encontrar una ruta real de código que lea o escriba esa tabla en producción?
• ¿Al eliminarlo cambias roles, permisos, invitaciones, acceso a facturación o pasos de onboarding?
• ¿Has eliminado secretos, claves de ejemplo y configuraciones sólo para pruebas que vinieron con ello?

Planifica un rollback rápido. Incluso eliminaciones cuidadosas pueden romper builds, migraciones o jobs. Taggea una release, limpia commits y asegúrate de poder redeployar la versión previa con rapidez.

Ejemplo: limpiar un MVP generado por IA con funciones extra

Un fundador lanza un MVP generado por IA. Funciona para el flujo central (signup, crear un proyecto, subir un archivo), pero el repo también contiene “Teams” y “Billing”. Nadie las pidió y nadie las usa, pero siguen añadiendo rutas, endpoints y tablas que pueden romper más adelante.

El primer paso es probar que son fantasma, no solo ocultas. Busca evidencia de uso real:

• Ningún enlace o botón lleva a las páginas (solo funciona la URL directa).
• Los logs del backend no muestran llamadas a los endpoints relacionados en sesiones reales.
• El frontend nunca llama a las APIs.
• Las tablas de la base de datos están vacías o solo contienen datos de seed.
• El código está lleno de copy como "TODO", "Coming soon" o planes falsos.

Una vez seguro, elimina la superficie en orden seguro: UI primero, API segundo, esquema al final. Si no estás listo para borrar todo, deja un stub claramente etiquetado (por ejemplo, una página inofensiva que diga "Billing no está disponible aún") y evita dejar endpoints a medio hacer o escrituras en la base de datos.

El resultado es inmediato: menos partes móviles, menor superficie de ataque, revisiones de código más rápidas y una hoja de ruta más clara de lo que la app hace realmente.

Próximos pasos: mantiene el repo limpio y reduce riesgo con el tiempo

Eliminar funcionalidades fantasma es un triunfo. Evitar que vuelvan es la recompensa mayor.

Mantén un pequeño backlog de limpieza para todo lo que no borraste aún. Anota por qué se quedó ("podría usarse más tarde", "necesita decisión de producto", "bloqueado por falta de tests") y añade una acción clara siguiente. Eso evita que scaffolding temporal se convierta en riesgo permanente.

Algunas reglas ligeras que ayudan:

• Fallar CI por placeholders obvios (rutas TODO, claves de ejemplo, flags de demo).
• Exigir que cada nueva página y endpoint tenga una nota de uso o un test.
• Revisar rutas/endpoints sin uso en staging con regularidad.
• Mantener una allowlist corta de tablas y migraciones reales, y marcar lo que esté fuera.

Si el repo está desordenado, no empieces borrando archivos al azar. Mapea primero lo que es alcanzable en la UI, lo que es alcanzable en la red y qué datos se usan realmente. Ese mapa evita el fallo clásico donde eliminas una funcionalidad “muerta” que en realidad soportaba auth, facturación u onboarding.

Si heredaste un prototipo generado por IA y quieres un plan estructurado de desmantelamiento, FixMyMess (fixmymess.ai) se centra en diagnosticar y reparar bases de código creadas por IA, incluyendo identificar páginas muertas, endpoints riesgosos y esquemas de marcador de posición antes de recortar nada.