Static-site and Django CMS generation with Qwen3.5-397B
A six-page static site and Django CMS generated from specifications with Qwen3.5-397B, including manual fixes and an LLM workflow for contract application development.
Two generated systems
I gave Qwen3.5-397B specifications for two systems:
- Dental clinic static site: 6 pages of HTML + Tailwind CSS + Alpine.js in about 18 minutes.
- Django CMS foundation: 8 apps, 20+ models, and Django configuration in one turn.
I wrote the SPEC, then reviewed and manually corrected the output. Few corrections were needed, and cross-file dependencies stayed consistent. I consider the 397B model size a possible contributor.
Prerequisites
Execution Environment
- GPU: NVIDIA RTX PRO 6000 Blackwell Max-Q (96GB VRAM)
- CPU: AMD EPYC 9175F (16C/32T, 512MB L3)
- Runtime: Podman container based on ik_llama-cuda
- Quantization: IQ4_KSS
- Key arguments:
--cpu-moe,--no-mmap,-fa on,-c 262144
Operational constraints
Decode falls to single-digit tok/s on EPYC + 1GPU. I use it for single-turn structure generation or nightly batches rather than interactive work.
Validation 1: Dental Clinic Static Site (One-Shot Generation)
Requirements
- Structure: 6 pages — index, services, doctors, info, visit, access
- Tech constraints: No build step, Tailwind CSS (CDN), Alpine.js (CDN), no external UI libraries
- Required features: Mobile hamburger menu (ESC/focus management), category filtering, FAQ accordion, estimate modal, form validation
- Quality: Semantic HTML5, ARIA attributes, keyboard navigation, responsive design
Results
In about 18 minutes, it generated:
/siteand/assetsdirectories- Page-specific HTML with shared headers and footers
- Semantic HTML5, focus management, and ESC handling
- README.md with setup instructions and limitations
Generated Page Breakdown
| Page | Key Content |
|---|---|
| index.html | Hero, 8 service cards, 6 “Why Choose Us” points, 4 doctor previews, news, hours |
| services.html | 16 treatment cards + Alpine.js category filter (4 categories) + 6-item FAQ accordion |
| doctors.html | 6 doctor profiles + expandable details (specialties, languages, certifications) |
| info.html | Fee table (8 treatments) + modal cost estimates, insurance/payment methods |
| visit.html | 6-step timeline, reservation methods, form with validation states |
| access.html | Contact/hours, map placeholder, direction tabs (car/train/walk) |
Assessment
Markup and Tailwind use were consistent, with responsive and accessibility requirements met. The 6-page prototype could be previewed and deployed without a build step.
Validation 2: Django CMS Foundation (Single-Turn Generation)
Requirements
Input was a detailed technical specification (SPEC) for rebuilding WordPress core concepts in Django:
- Posts / Pages (publish status, scheduled posts, password protection)
- Categories / Tags (unified hierarchical + flat classification)
- Comments, Media Library, Menus / Navigation
- Drafts, scheduled publishing, visibility control
- Revision history
- PostgreSQL-friendly design (JSONField, indexing, full-text search ready)
Generated system structure
The output separated apps by function and shared common models.
Common abstract models (apps/core/models.py)
TimeStampedModel, SoftDeleteModel, and PublishableModel collect repeated behavior.
8-App Architecture:
| App | Responsibility |
|---|---|
| accounts | User and role management |
| core | Site settings, multi-site extensibility point |
| content | Core for posts, pages, and revisions |
| taxonomy | Category (hierarchical) + Tag (flat) classification |
| media | Media library (SHA256 deduplication, Alt/Caption management) |
| comments | Comment functionality |
| navigation | Menu and navigation management |
| seo | SEO metadata management |
WP Concept → Django Implementation Mapping
| WP Concept | Django Implementation | Implemented Features |
|---|---|---|
| Post / Page | content.Post / Page | Publish status, scheduled posts, password protection |
| Taxonomy | taxonomy.Term | Unified category (hierarchical) and tag (flat) |
| Post Meta | content.PostMeta | Dynamic expansion via PostgreSQL JSONField |
| Revision | content.Revision | Snapshot storage and rollback |
| Media | media.MediaAsset | SHA256 deduplication, Alt/Caption management |
Cross-file consistency
I had seen 17B models mismatch names or arguments in links such as SEOEntry to Post. Here, apps/content/models.py QuerySets reused is_public and other properties from apps/core/models.py. python manage.py makemigrations passed after limited manual fixes.
Preparing specifications before generation
Speed and quality
Generation was slow, but the structure was consistent. For this work, preparing the SPEC and sending one turn fit better than repeated conversational debugging.
Differentiation from Smaller Models
- 17B-class (Scout, etc.): Interactive coding assistance, refactoring, single-function generation
- 397B-class (Qwen3.5): Multi-file, multi-model structural generation, architecture-level code production
Operational Pattern
- Human writes the SPEC (requirements + architecture design)
- Single-turn submission to the 397B model
- Review and minor fixes on generated code
- Deploy
As in contract development specifications, the requirements and structure come first, followed by human review of generated code. I consider this a local business application development workflow.
Reproduction Steps
Dental Clinic Site
- Start Qwen3.5-397B (or equivalent coding model)
- Submit the requirements from this article’s “Validation 1 Requirements” section as the prompt
- Open the 6 generated HTML files in a browser to verify
Django CMS Foundation
- Create a WordPress→Django mapping specification (concept definitions for Post/Page/Taxonomy/Media/Revision)
- Specify project structure, design principles, and non-scope items
- Submit to Qwen3.5-397B in a single turn
- Verify consistency with
python manage.py makemigrations - Fix any inconsistencies manually