¿Django Ninja o FastAPI? Qué elegiría yo para rehacer el backend de una app hecha con IA

Casi todos los backends en Python escritos por un agente que llegan a mi mesa son FastAPI. No porque lo eligiera el fundador: Claude Code y Cursor tiran de él cuando nadie dice lo contrario, y para un prototipo de fin de semana es un reflejo razonable. Luego llegan los primeros clientes, entra un ingeniero sénior o se contrata uno por unos meses, y lo primero que dice es «esto habría que pasarlo a Django». Y entonces el fundador me escribe para preguntarme quién tiene razón.

Escribo desde el asiento de quien rehace estos backends. En Conectia llevamos a producción apps construidas con Claude Code, Cursor, Lovable y compañía, y cuando el veredicto sobre el backend es rehacer, Python es el lenguaje en el que lo rehacemos con más frecuencia, porque es lo que dejó el agente y lo que el equipo sabe leer. He puesto los dos frameworks en producción y no tengo intereses en ninguno. Lo que tengo es un patrón: la pregunta por el framework es una pregunta disfrazada; la de verdad es qué módulos fallaron primero y qué trae cada framework para exactamente esos módulos.

Los módulos que fallaron son los que FastAPI te deja a ti

FastAPI es Starlette más Pydantic: enrutado, validación de peticiones, inyección de dependencias y un documento OpenAPI gratis. Eso es todo, por diseño, y su autor nunca ha dicho otra cosa. El resto lo eliges y lo conectas tú: el ORM (SQLAlchemy 2.0 en la mayoría de casos), las migraciones (Alembic), la autenticación, las sesiones, los permisos, un admin, los trabajos en segundo plano, el arnés de tests. Un equipo con experiencia monta todo eso en una semana y queda satisfecho con el resultado.

Un agente también lo monta, en minutos, y ahí empieza el problema. Cuando leo un backend FastAPI hecho con IA, los fallos coinciden con los ocho síntomas que ya describí, y se concentran en las partes que FastAPI no incluye:

• La autenticación es una dependencia get_current_user que decodifica un token y se lo cree; el refresco, la revocación, el restablecimiento de contraseña y la verificación de correo existen en la medida en que alguien se los pidió al agente.
• El aislamiento por tenant es un WHERE organization_id = … que el agente se acordó de añadir en casi todas las consultas. La que falta es la brecha de datos.
• Las migraciones no existen, o se generaron una vez y no volvieron a ejecutarse; el esquema es lo que produjo create_all() en el primer arranque.
• Los permisos son un if user.role == "admin" repartido por los routers.
• El admin no existe, así que el soporte se hace desde una consola SQL contra producción.

Nada de esto es culpa de FastAPI. Son los módulos que un framework o bien incluye o bien te pide que construyas, y un agente que los construye desde cero produce algo que parece terminado y no lo está.

Django trae los módulos que se rompieron, y Ninja elimina el motivo por el que la gente lo evitaba

Django Ninja es una capa de API fina sobre Django que toma el tipado y la validación de Pydantic. El código de peticiones y respuestas se parece al de FastAPI: anotaciones de tipos, esquemas, OpenAPI automático, vistas asíncronas si las quieres. Debajo tienes Django, y eso significa que lo que el agente improvisó ahora viene de un framework con veinte años de producción a la espalda: el ORM, migraciones que forman parte del flujo de trabajo y no de una ocurrencia posterior, django.contrib.auth con hash de contraseñas, sesiones y comprobaciones de permisos auditadas durante dos décadas, el admin, los comandos de gestión y un runner de tests que entiende de transacciones y fixtures. Django 5.2 es una versión de soporte extendido, con mantenimiento hasta abril de 2028, que es una frase que a un departamento de compras le gusta leer.

Para los módulos que se rompieron, esta es la diferencia entre escribir y configurar. La autenticación pasa a ser la elección de un backend y un bloque de settings. El aislamiento por tenant pasa a ser un manager de modelo que filtra por organización y un middleware que la fija, con un test que comprueba que todos los modelos llevan el campo. Los permisos pasan a ser declaraciones. El admin existe el mismo día que existen los modelos, y el soporte deja de tocar producción a mano. El motivo por el que se evitaba Django para productos de API era la ceremonia de los serializers de Django REST Framework; Ninja quita eso y conserva el resto.

Reconozco el contraargumento que tiene fundamento. La historia asíncrona de Django está a medias: aget, asave y compañía existen, pero la capa de base de datos sigue entregando la consulta a un driver síncrono en un hilo. Si tu backend son doce endpoints que llaman a un modelo, emiten tokens por SSE y mantienen websockets abiertos, el peso de Django no te aporta nada y el bucle de eventos de FastAPI te aporta mucho. Y si el código FastAPI que escribió el agente funciona, no guarda datos de clientes y no tiene un segundo tenant, reescribirlo por cuestión de marca es el mismo error que la reescritura contra la que argumento en el primer post de esta serie. La elección del framework va después del veredicto, nunca por delante.

La decisión cabe en una tabla

Esta es la regla que aplico cuando el veredicto sobre el módulo de backend dice rehacer.

La tercera fila es en la que acabo con más frecuencia. La capa de IA que el agente escribió en FastAPI suele ser la mejor parte del código, porque es sobre lo que el fundador iteró; el núcleo de negocio que la rodea es lo que nadie leyó. Conservar la primera y rehacer el segundo sobre Django Ninja cuesta menos que cualquiera de los dos extremos, y encaja con lo que recomiendo para monolitos y servicios en fase de MVP: un desplegable por cada motivo, no por cada moda.

Rehacer en el orden que mantiene el producto en marcha

La reconstrucción que funciona no es un universo paralelo en el que un backend nuevo aparece a los tres meses y se cambia de la noche a la mañana. Es una secuencia, y la secuencia empieza por lo que no va a cambiar.

1. La base de datos se queda. Postgres es el activo. Apunta Django al esquema existente, genera los modelos con inspectdb y después límpialos a mano hasta que digan lo que el negocio quiere decir. La primera migración es la que deja constancia de lo que ya existe.
2. Migraciones bajo control de versiones desde el primer día. A partir de aquí, cada cambio de esquema es un fichero en el repositorio que la CI aplica sobre una base de datos de staging antes de que nadie despliegue. Este único hábito elimina el síntoma dos, la base de datos que cada semana va más lenta, porque un índice pasa a ser un cambio revisado.
3. Autenticación y aislamiento por tenant antes que cualquier endpoint. Elige la fuente de autenticación (la propia de Django, o el proveedor externo que la app ya usa, verificado en el borde), escribe el manager de organización y el middleware, y escribe el test que falla cuando un modelo olvida el campo de tenant. No se porta nada más hasta que ese test está en verde.
4. Congela el contrato con la API antigua. FastAPI y Ninja emiten OpenAPI los dos. Guarda una instantánea del documento del agente y haz que cada endpoint portado pase un test de contrato contra ella. El frontend ni se entera de que el backend ha cambiado.
5. Porta por módulos, en el orden del go/no-go. Primero los pagos y todo lo que toque datos personales, porque ahí está el riesgo; al final los informes y lo accesorio. Cada módulo se mueve detrás de una ruta en el gateway, de modo que los dos backends conviven durante semanas.
6. Dale a la capa de IA su conjunto de evaluación. Se quede en FastAPI o se mueva, las funciones basadas en modelo reciben un conjunto de evaluación y una métrica antes de cambiar. Esa suite es lo que hace seguro el siguiente retoque de prompt.
7. CI, staging y un rollback ensayado. Despliega el núcleo nuevo a staging en cada merge, ejecuta los tests de contrato y las evaluaciones, y solo entonces mueve tráfico de producción módulo a módulo. El rollback es un cambio de ruta, no una restauración.

Para un producto en fase seed con unos miles de usuarios, esto son de ocho a diez semanas de un ingeniero de backend sénior con un arquitecto que revisa el diseño unas horas a la semana. Más que un fin de semana, bastante menos que el trimestre que cuesta una reescritura desde cero, y el producto sigue sacando funcionalidades todo el tiempo.

Qué haría yo este mes si el backend fuera mío

1. Lee el veredicto antes que el framework. Si nadie ha puesto nombre a los módulos que fallaron, con la medición al lado de cada uno, ese es el trabajo de dos semanas que va primero. Un debate de frameworks sin veredicto es una cuestión de gustos.
2. Haz la lista de lo que el agente improvisó. Autenticación, aislamiento por tenant, migraciones, permisos, admin, trabajos en segundo plano. Para cada uno, anota si existe, si está probado y si algún framework lo trae de serie.
3. Decide con la tabla de arriba y deja la decisión por escrito con su motivo, para que el siguiente ingeniero no la reabra.
4. Conserva el esquema de Postgres y el documento OpenAPI como los dos puntos fijos. Todo lo demás puede moverse; esos dos son el contrato con tus datos y con tu frontend.
5. Escribe el CLAUDE.md o el AGENTS.md antes del primer endpoint portado. El manager de tenant, la prohibición de SQL en crudo, el flujo de migraciones, el comando de tests. El agente que escribió la versión uno escribirá partes de la versión dos, y construye dentro de las convenciones que puede leer.
6. Pon a una segunda persona a revisar autenticación y aislamiento por tenant. En esos dos módulos la reconstrucción o se paga sola o repite el error original con mejores anotaciones de tipos.

El framework es la respuesta a una pregunta que hay que hacer antes

«¿Django Ninja o FastAPI?» es una buena pregunta con una respuesta corta en cuanto sabes qué módulos fallaron y qué le debe tu producto a su segundo cliente. Hazla antes del veredicto y tendrás una guerra de religión; hazla después y la tabla de arriba la zanja en una reunión.

Ese veredicto es el primer paso de cómo llevamos a producción una app hecha con IA, y cuando el backend hay que rehacerlo, es el orden de arriba, ejecutado con nosotros, con tu propia contratación o con el agente que escribió la primera versión. Si quieres la foto de antes, dejé por escrito qué se rompe primero en un MVP hecho con IA y en qué se diferencia una app de Lovable sobre Supabase, donde la pregunta del backend tiene otra forma.