El sesgo del framework

Por qué elegir tecnología basándote en modas está matando tus proyectos

Introducción: El debate que no debería existir

Si buscas en internet "qué framework elegir para mi proyecto", encontrarás miles de artículos. Todos siguen el mismo patrón:

1. El autor presenta su framework favorito.
2. Enumera sus ventajas (reales o inventadas).
3. Señala las supuestas carencias de los demás.
4. Concluye que el suyo es el mejor.

Este tipo de contenido es cómodo para escribir y fácil de consumir, pero es peligroso para quien tiene que tomar decisiones reales con dinero y tiempo de por medio.

Hace unos días mantuve un debate con un profesional que defendía Drupal con argumentos sólidos. Yo, como muchos, tenía ideas preconcebidas sobre sus limitaciones. Él me las desmontó una por una y me hizo darme cuenta de que había caído en el mismo sesgo que critico.

Esa conversación no me llevó a pensar "Drupal es mejor", sino a una conclusión mucho más importante:

La elección del framework adecuado no es una decisión técnica, es una decisión estratégica sobre cómo gestionas el riesgo a largo plazo.

Y en el contexto actual, con un mercado laboral roto y la IA generando código a velocidades insostenibles, esa decisión nunca había sido tan crítica.

El problema de fondo: El mercado laboral está roto

Empecemos por el principio. No es un secreto: encontrar buenos desarrolladores es cada vez más difícil.

• Los bootcamps producen perfiles juniors sin base sólida.
• La demanda de desarrolladores senior supera ampliamente la oferta.
• Los sueldos se han disparado, haciendo inviable mantener equipos grandes.
• El desarrollador estrella que te hizo el proyecto se va a los 18 meses por una oferta mejor.

Pero hay un factor nuevo que está empeorando todo: la IA generativa.

Herramientas como GitHub Copilot, Cursor o Windsurf permiten generar código a una velocidad nunca vista. Y eso es maravilloso... en manos de un experto.

En manos de un desarrollador mediocre, la IA es una máquina de generar deuda técnica. Produce código que funciona, que pasa los tests, pero que:

• Nadie entiende del todo.
• No sigue patrones coherentes.
• Duplica lógica sin necesidad.
• Ignora la arquitectura del sistema.
• Es prácticamente imposible de mantener.

El resultado es que tenemos proyectos que se construyen en 3 meses y se mantienen (con sufrimiento) durante 5 años.

El falso debate: ¿Framework X o Framework Y?

Cuando preguntas a un desarrollador qué framework elegir, su respuesta casi siempre está sesgada por:

• Lo que usa actualmente.
• Lo que conoce bien.
• Lo que le resulta cómodo.

Y eso es humano. Pero no es buena estrategia.

La elección del framework no debería responder a "¿cuál es mejor?" sino a "¿cuál protege mejor mi inversión ante los escenarios adversos que sé que van a ocurrir?"

Y los escenarios adversos que sabemos con certeza que van a ocurrir son:

1. El equipo va a cambiar (y probablemente empeorar).
2. Se va a generar deuda técnica (por prisas o por malas prácticas).
3. La IA va a producir código que alguien tendrá que revisar.
4. El proyecto va a necesitar actualizaciones de seguridad y mantenimiento.

La pregunta entonces es: ¿qué tecnología pone más límites a la creatividad destructiva? 

El espectro: De la flexibilidad total a la estructura rígida

Todos los frameworks se sitúan en un espectro que va desde la máxima libertad hasta la estructura más firme. Vamos a situar algunos de los más conocidos:

Flexibilidad total (Mucha libertad, poca estructura impuesta)

Son frameworks que te permiten hacer lo que quieras. No imponen una arquitectura rígida. Son ideales para experimentar y pivotar rápido, pero peligrosos en manos inexpertas.

Ejemplos: Express.js (Node), Flask (Python), Laravel (PHP), React, Vue.

En el frontend: React te da el renderizado y poco más. La organización del estado, el manejo de efectos y la arquitectura general dependen completamente de ti. Vue es similar, con algo más de estructura, pero sigue siendo muy flexible.

Equilibrio (Estructura suficiente, flexibilidad controlada)

Ofrecen un buen equilibrio: te dan un andamiaje claro sin encorsetarte demasiado.

Ejemplos: Django (Python), Ruby on Rails, Angular (TypeScript).

Django es el "baterías incluidas" por excelencia. Impone una estructura clara (MVT, ORM, migraciones, admin) pero permite personalizar casi todo. Rails tiene una filosofía similar: convención sobre configuración. Angular es el más estructurado de los frameworks frontend, obligando a usar TypeScript, inyección de dependencias, módulos, etc.

Estructura fuerte (El framework impone su arquitectura)

Son frameworks que te obligan a seguir unas convenciones estrictas. La curva de aprendizaje es más empinada, pero una vez interiorizada, la productividad es muy estable y el código es predecible.

Ejemplos: Spring Boot (Java/Kotlin), Drupal (PHP), Rust (con frameworks como Axum o Actix).

Spring Boot es el rey de la estructura empresarial. Inyección de dependencias, AOP, capas bien definidas, configuración basada en anotaciones. No puedes "inventarte" una arquitectura porque Spring ya la tiene definida. Drupal, aunque menos popular, tiene una arquitectura basada en entidades, hooks, plugins y eventos que obliga a organizar el código de una manera muy concreta. Rust, aunque no es un framework, impone una disciplina de programación que pocos lenguajes tienen.

¿Qué framework elegir entonces?

No hay una respuesta única. Depende del contexto de tu proyecto. Pero podemos establecer criterios claros:

Elige un framework flexible (Express, Flask, Laravel, React) si:

• Tienes un equipo estable de desarrolladores senior que llevan años trabajando juntos.
• El proyecto necesita pivotar constantemente o experimentar con nuevas funcionalidades.
• Tienes una cultura de código fuerte, con revisiones exhaustivas y estándares claros.
• El equipo está comprometido a largo plazo con el proyecto.
• Valoras la velocidad inicial por encima de la consistencia a largo plazo.

Elige un framework equilibrado (Django, Rails, Angular) si:

• Quieres un punto medio entre estructura y flexibilidad.
• El equipo tiene experiencia media y necesitas un andamiaje que les guíe.
• El proyecto tiene necesidades de administración y gestión de contenido importantes.
• Buscas productividad sin renunciar al control total.

Elige un framework estructurado (Spring Boot, Drupal, Rust) si:

• El mercado laboral es incierto y sabes que el equipo va a cambiar.
• El proyecto necesita estabilidad y mantenimiento a largo plazo (5+ años).
• No puedes permitirte que la deuda técnica se acumule.
• Quieres que el propio framework te ayude a mantener la calidad.
• Trabajas en un entorno empresarial donde la gobernanza y la estandarización son clave.

El factor IA: Lo que nadie está diciendo

Hay un elefante en la habitación que pocos están abordando: la IA va a generar mucho código mediocre.

Los equipos que usen IA para acelerar el desarrollo van a producir más líneas de código que nunca. Y cada línea de código generada por IA, en manos de un desarrollador sin criterio, es potencial deuda técnica.

Aquí es donde los frameworks con estructura fuerte marcan la diferencia.

Porque la IA, por muy avanzada que esté, no puede "saltarse" las convenciones del framework:

• Si Spring Boot te obliga a definir tus servicios con anotaciones @Service y a inyectar dependencias con @Autowired, la IA generará código que sigue esa estructura.
• Si Django te obliga a definir tus modelos en models.py y tus vistas en views.py, la IA generará código que respeta esa organización.
• Si Rust te obliga a gestionar la memoria y los ownerships, la IA generará código que (probablemente) sea más seguro.

En cambio, si Express te permite poner toda la lógica en un solo archivo app.js de 3.000 líneas, la IA generará un archivo de 3.000 líneas.

La estructura fuerte protege a la IA de sí misma.

Un caso práctico: El mismo proyecto en dos frameworks

Imaginemos que estamos desarrollando una API para una red social de empleo (el proyecto que motivó este artículo).

Opción A: Con Express.js (flexible)

• El desarrollador estrella construye una API limpia, con separación de capas, middlewares bien definidos y tests.
• A los 18 meses, se va.
• El nuevo equipo (con IA) añade funcionalidades. Como Express no impone nada, la IA empieza a generar código en el archivo routes.js que mezcla lógica de negocio con respuestas HTTP.
• En 6 meses, el proyecto es un caos. Nadie sabe qué hace cada archivo.

Opción B: Con Spring Boot (estructurado)

• El desarrollador estrella construye la misma API usando las convenciones de Spring: Controladores, Servicios, Repositorios, DTOs.
• A los 18 meses, se va.
• El nuevo equipo (con IA) añade funcionalidades. Spring obliga a seguir la estructura: los controladores solo manejan peticiones, los servicios contienen la lógica, los repositorios acceden a la base de datos.
• La IA genera código que, aunque pueda ser mejorable, respeta la arquitectura. El proyecto sigue siendo mantenible.

¿Cuál de los dos proyectos crees que estará vivo y siendo productivo en 5 años?

Conclusión: La decisión estratégica

Vuelvo al principio. Este artículo no es para decirte qué framework elegir. Es para que entiendas que la decisión no es técnica, es estratégica.

La pregunta correcta no es "¿cuál es mejor?" sino "¿cuál de ellos va a proteger mejor mi inversión en el escenario real que voy a tener?"

Y ese escenario real, en 2025 y adelante, es:

• Equipos que cambian cada 18-24 meses.
• Desarrolladores con formaciones muy diversas.
• IA generando código a velocidad de vértigo.
• Presión para entregar rápido y asumir deuda técnica.

En ese contexto, elegir un framework con estructura fuerte (Spring Boot, Django, Angular) puede ser el mejor seguro de vida para tu proyecto.

Pero ojo: esto no es un ataque a frameworks flexibles como Express, Flask o Laravel. Son herramientas magníficas, probablemente las mejores en manos de un equipo excelente y estable.

El problema no es la herramienta, es el contexto.

Y el contexto actual es el que es: incierto, cambiante y lleno de ruido. Elegir bien es más importante que nunca.

Reflexión final para decisores

Si estás leyendo esto y eres responsable de elegir la tecnología para tu próximo proyecto, te dejo tres preguntas que deberías hacerte:

1. ¿Qué garantías tengo de que el equipo que empieza el proyecto va a ser el mismo que lo mantiene dentro de 3 años? Si la respuesta es "ninguna", prioriza estructura sobre libertad.
2. ¿Qué herramientas tengo para asegurar la calidad del código generado por IA? Si la respuesta es "las mismas revisiones de siempre", estás subestimando el problema. La IA es un multiplicador: multiplica el acierto del experto y el error del novato.
3. ¿Estoy eligiendo el framework porque es lo que conozco o porque es lo que mi proyecto necesita? Sé honesto. La respuesta puede doler, pero es mejor saberlo ahora que dentro de dos años.
4. ¿Cuánto tiempo va a estar vivo este proyecto? Si es un MVP para probar un mercado, usa lo que te haga más rápido (Express, Flask). Si es el core de tu negocio para los próximos 10 años, piensa en Spring Boot, Django o incluso Rust.

No hay tecnología mala, solo decisiones mal tomadas para el contexto equivocado.