Plain: El Framework Python para Agentes IA

Plain es un framework web full-stack de código abierto lanzado en 2025 que reimagina Django para la era de agentes IA, incluyendo 30 paquetes integrados, type hints explícitos, y tooling moderno preconfigurado (Python 3.13+, PostgreSQL, htmx, Tailwind). Desarrollado por PullApprove como fork “sin compatibilidad hacia atrás” de Django, Plain propone ser más accesible a lectores de código (humanos y IA) que el Django clásico.

¿Qué es Plain? El framework Python reimaginado para agentes IA

Plain es un framework web full-stack de código abierto desarrollado por PullApprove (licencia BSD-3) que toma los principios de Django pero reescribe todo desde cero para la era de los agentes de IA. No es “Django con cambios cosméticos” — es una reimaginación arquitectónica completa donde cada decisión está orientada a que el código sea explícito, tipado y predecible. Si alguna vez configuraste un proyecto Django y te golpeó la complejidad de las migraciones, la cantidad de imports implícitos y las reglas “mágicas” que nadie documentó, Plain viene a resolver eso de raíz.

La filosofía de Plain se resume en: código que los humanos entienden rápidamente, y que los agentes IA (Claude, GitHub Copilot, etc.) puedan leer sin alucinaciones. Stack base: Python 3.13+, PostgreSQL como base de datos (no SQLite), Jinja2 para templates, htmx para interactividad sin escribir JavaScript, y Tailwind CSS para estilos. Todo pre-elegido, sin análisis paralizante de “¿Flask o FastAPI o Django?”.

Plain vs Django: diferencias clave que debes conocer

Django domina el mercado de frameworks Python con 47% de market share (datos de 2026), y para aplicaciones legacy grandes sigue siendo la opción segura. Pero Plain descartar compatibilidad hacia atrás fue una decisión deliberada — permitió tirar a la basura todo lo “heredado” de Django que no tenía sentido en 2026.

La diferencia no es cosmética — es arquitectónica. Django tiene años de decisiones sedimentadas. Plain nació diciendo “¿qué necesita realmente un proyecto en 2026?” y construyó desde cero. Type hints explícitos en modelos, class-based views mejoradas, CLI tooling integrado en la core, no como afterthought.

30 paquetes integrados: qué viene en la caja sin instalar nada más

Uno de los mayores dolores de cabeza con Django es la pregunta eterna: “¿y ahora instalo qué?” Necesitás autenticación confiable → REST Framework. Background jobs → Celery. Admin mejorado → Django Suit o Grappelli. Y terminas con 47 dependencias de terceros, versiones que no hablan entre sí, y un requirements.txt de 200 líneas.

Plain dice: “todo eso viene adentro, mantenido por nosotros, actualizado en sincronía”. 30 paquetes first-party cubriendo: Ya lo cubrimos antes en integrarlo con modelos LLM modernos.

• Autenticación: session-based, token, OAuth2 — sin instalar extra
• ORM + migraciones: queries tipadas, migraciones automáticas
• Background jobs: colas de trabajo, scheduled tasks — sin Celery
• Admin mejorado: inline editing, batch actions, filters avanzados
• Email: templating, SMTP, transactional — sin django-anymail
• Caching: en memoria, Redis, lógica de invalidación — sin django-cachalot
• Formularios: validación HTML5 nativa, CSRF automático
• Manejo HTTP/CSRF: middleware moderno, sin surpresas
• Logging: estructurado por defecto, no el default confuso de Django
• CLI tools: comandos intuitivos, auto-help
• Asset serving: Tailwind + esbuild integrados
• REST API: generación automática desde modelos, validación de esquema
• Analytics: tracking básico built-in, sin scripts externos

Eso sí, cada paquete es mantenido por el core team de Plain — no es un ecosystem fragmentado como Django, donde cada librería tiene su propia roadmap.

Stack tecnológico de Plain: herramientas modernas pre-elegidas

Plain no te pregunta “¿qué linter usás?” Viene con decisiones tomadas: Python 3.13+ (última versión requerida, no “3.9+”), PostgreSQL en producción (SQLite es solo local development), Jinja2 para templates porque es estándar en la industria.

Frontend: htmx en vez de React/Vue, porque Plain es “server-centric” — renderizás HTML en el servidor, htmx añade interactividad sin JavaScript boilerplate. Tailwind CSS porque es la realidad de 2026 (no pagas tiempo en “tuning” de SCSS), y oxc para procesar CSS/JS con velocidad de compilación nativa (escrito en Rust). Bundler: esbuild (rápido, maduro).

Tooling de código: Plain adopta las herramientas de Astral (la empresa detrás de Ruff): — uv: dependency management ultrarrápido (reemplazo moderno de pip) — ruff: linter + formatter unificado en uno (adiós black + flake8 separados) — Plain integra ambas en el comando `plain fix` — corre linting, formatting y type checking de una patada

Testing: pytest (estándar en la comunidad Python), configurado por defecto sin que necesites agregar plugins raros.

Herramientas para agentes IA: rules, skills y documentación CLI

Acá Plain se pone explícitamente pro-IA, cosa que Django nunca pensó. Dos mecanismos clave:

Rules (.claude/rules/): archivos cortos (~50 líneas máximo) que definen guardrails para agentes IA. Ejemplo: “cuando modifiques un modelo, incluí siempre validación de email”, “no importes librerías externas si la funcionalidad existe en core”. Los agentes (Claude Code, GitHub Copilot) pueden leer estas rules y restringir su propia salida. No es un “pídele al agente que…”, es instrucción explícita que el agente respeta. Más contexto en entender qué modelos puedes usar.

Skills (/comando): workflows activados con slash commands. `/plain-optimize` ejecuta un flujo predefinido que refactoriza un módulo, `/new-model Author` crea una estructura de modelo con all the boilerplate. Los agentes pueden descobrirlas y usarlas sin preguntarte.

Documentación en CLI: `plain dev` te abre un servidor local + documentación interactiva, agnóstica para cualquier agente (Claude Code, Copilot, etc.). No es “leé el README en GitHub” — es “preguntále al framework que te explique”.

¿Por qué esto importa? Porque si usás un agente para escribir código en Django, el agente tiene que aprender 200 packages y patterns implícitos. En Plain, el agente pregunta al framework qué hacer, y Plain le contesta.

Instalación y primeros pasos con Plain en Windows/Linux/Mac

Plain requiere Python 3.13+ (no negocia en eso). Una vez tengas Python:

• Instalá Plain: `pip install plain` (o `uv pip install plain` si usás uv)
• Crear proyecto: `plain new myproject` (te pide nombre, tipo de app)
• Acceder a la carpeta: `cd myproject`
• Crear venv: `python -m venv venv` (Plain lo propone al init pero es opcional si usás uv)
• Instalar dependencias: `plain install` (ejecuta uv install por detrás)
• Correr servidor: `plain dev` — abre servidor en `https://localhost:8000` con auto-reload

La estructura de carpetas es limpia: `apps/` (apps modulares), `templates/`, `static/`, `config.py` (settings), `db.py` (models). Sin “manage.py” misterioso ni docenas de archivos `__init__.py` vacíos.

Crear modelo: escribís en `db.py` con type hints. Plain detecta cambios automáticamente, propone migraciones, no necesitás `makemigrations + migrate` dos comandos separados (eso es Django vintage). Servidor dev toma cambios en tiempo real.

El HTTPS local es automático (Plain genera certificados self-signed), importante si probás services de terceros que requieren HTTPS.

Cuándo elegir Plain: casos de uso ideales en 2026

Plain es ideal para:

Apps full-stack con agentes IA integrados: si vos mismo usás Claude Code para escribir features, Plain te da un entorno donde el agente entiende el código sin alucinaciones. El overhead de magic Django desaparece. Para más detalles técnicos, mirá ejecutar tus propios modelos localmente.

Proyectos nuevos (sin legacy): si es “greenfield” (empezás de cero), Plain no tiene pain. Si tenés 50k líneas de Django antiguo, migrar es trabajo manual que ningún tool automatiza.

Equipos que valoran code clarity: si tu equipo prefiere “explícito es mejor que implícito” (principio Zen de Python), Plain te lo da. Si preferís “magia como sea conveniente”, Django sigue siendo mejor.

Startups que iteran rápido: Plain se recompila/reinicia rápido, el CLI es intuitivo, los errores son claros. No pierdes tiempo debugueando “¿por qué Django no detectó mi cambio?”

No es ideal para: migrar aplicaciones Django legacy grandes (el costo es alto), si necesitás 500+ packages especializados de la comunidad Django (Plain es más pequeño), o si tu equipo está acostumbrado a Django y no quiere cambiar el flujo mental.

Errores comunes al empezar con Plain

Creer que Plain es “Django simplificado”: es una reimaginación. Patrones que funcionaban en Django pueden no tener sentido en Plain. Plain no busca ser familiar, busca ser correcto. Leé la documentación, no presumas que funciona como Django.

Intentar instalar packages Django en Plain: Plain tiene 30 packages first-party, pero no es compatible con el ecosystem de Django. Si necesitás una librería específica de Django, debés reescribir manualmente o buscar equivalente en Plain core. No hay un “pip install django-something && listo”.

Omitir type hints esperando que “funciona igual”: el tooling de Plain (ruff, agentes IA) depende de tipos explícitos. Si escribís `def get_user(id):` sin tipo, Plain y los agentes no entienden qué esperas. Sé explícito, o sufrirás. Esto se conecta con lo que analizamos en orquestar la generación de contenido multimedia.

Usar SQLite en producción: Plain permite SQLite en dev para rapidez, pero la documentación es clara: producción es PostgreSQL. SQLite no escala, no tiene buenas migraciones distribuidas. No “probarás en SQLite y migrarás a PostgreSQL después”.

No leer las rules de tu proyecto: si tu proyecto tiene `.claude/rules/`, los agentes las respetan, pero vos no. Leelas una vez para entender qué restricciones existen.

Preguntas Frecuentes

¿Qué es Plain framework y cómo se diferencia de Django?

Plain es un framework web full-stack de 2025 que descarta compatibilidad backward con Django para ofrecer código más explícito, tipado y amigable para agentes IA. Ambos son full-stack, pero Django carga 20+ años de decisiones históricas; Plain nació sin esa deuda técnica. Type hints obligatorios, 30 paquetes integrados, stack moderno predefinido.

¿Plain framework es mejor que Django para agentes IA?

Para agentes IA específicamente, sí. Plain fue diseñado para que agentes IA lean y modifiquen código sin alucinaciones — type hints explícitos, rules archivos, skills slash commands. Django no fue pensado para eso. Si tu workflow incluye Claude Code o GitHub Copilot escribiendo features en vivo, Plain es mejor. Si tienes aplicación Django legacy, cambiar es costly.

¿Cómo empezar con Plain framework en Python?

Requiere Python 3.13+. Instala: `pip install plain`. Crea proyecto: `plain new myapp`. Accede: `cd myapp`. Corre: `plain dev`. El servidor arranca en localhost:8000 con auto-reload. La documentación está integrada en el CLI (`plain dev` la abre). No necesitas guías externas para la instalación básica.

¿Qué paquetes incluye Plain framework?

30 paquetes first-party: ORM + migraciones, autenticación (session + token), background jobs, admin moderno, email, caching, formularios, REST API, logging estructurado, CLI tools, asset bundling con Tailwind/esbuild, analytics básico, manejo CSRF, todo incluido. No necesitas instalar Django REST Framework, Celery, django-anymail ni otros terceros — vienen incorporados.

¿Es seguro usar Plain en producción en 2026?

Plain lanzó en 2025 pero está mantenido activamente por PullApprove. Es open source (BSD-3), y el stack subyacente (PostgreSQL, Python, Jinja2) es maduro. El riesgo no es “¿si desaparece la librería?”, es “¿confío en que el core team itere rápido si encuentro bugs?” Para proyectos nuevos greenfield, es seguro. Para misión crítica legacy, Django tiene más track record.

Conclusión

Plain es la respuesta de 2026 a una pregunta que Django nunca se hizo claramente: “¿cómo escribimos código que agentes IA puedan leer y modificar sin error?” No es Django ligerado. Es Django reimaginado sin compatibilidad backward, con type hints obligatorios, stack moderno predefinido, y 30 paquetes first-party que evitan el análisis paralizante de “¿qué instalo?”

Si inicias un proyecto hoy, Plain es interesante. Si ya tenés aplicación Django corriendo, migrar no tiene sentido económico — mantené Django. Pero si vos y tu equipo usan agentes IA para escribir código, Plain tira menos errores porque todo es explícito. La curva de aprendizaje es plana porque no hay “magia” que descubrir. El stack viene pre-elegido: no pierdes 2 semanas debatiendo Celery vs RQ, usar Redis vs Memcached. Es una apuesta a que en 2026 preferimos claridad que flexibilidad.

Fuentes

• Plain Framework — Sitio oficial
• Plain Framework — GitHub repository
• Show HN: Plain — Hacker News discussion
• Plain — Python Package Index
• Comparación Django, Flask, FastAPI — JetBrains Blog