Django 5 Travel Booking Site Generation Test with Qwen3.5-122B-A10B Local Inference

Overview link

This article documents a test to determine whether a locally-running Qwen3.5-122B-A10B (Q5_K_M quantization) can generate a full-stack Django 5 travel booking site — with zero cloud API calls. Using an MCP (Model Context Protocol) coding agent for file operations, the model handled initial one-shot generation (with manual fixes), followed by two rounds of feature expansion adding Shop, Reviews, Search, and Accounts apps. Each stage required some manual corrections, but the bulk of code generation was completed entirely by local inference.

Cloud-scale models like Claude or GPT-4 can already do this kind of work routinely. The focus here is whether a quantized MoE model running on local hardware can achieve comparable results.

Local Inference Environment link

The key point: all inference ran on local hardware. No external API calls, no token billing. The agent combined multiple MCP servers — serena for symbol operations, filesystem for file I/O, ripgrep for search, ctree for code structure analysis, and pathfinder for path resolution — to incrementally build the Django application.

Motivation link

Why Test Locally Instead of Using Cloud APIs link

Claude Sonnet and GPT-4o can already generate full-stack web applications reliably. But relying on cloud APIs means:

• Token costs accumulate over iterative development
• Proprietary code must be sent to external servers
• API availability and rate limits constrain workflow

If local inference can deliver cloud-comparable results, these constraints disappear. The question was: can a 122B MoE model quantized to Q5_K_M and running on ik_llama.cpp function as a practical coding agent?

One-Shot Generation Approach link

A complete specification was provided upfront to generate all files at once. This ensures:

• Consistency between domain models and views
• Template-form integration matching the specification
• Seed data aligned with model definitions
• Admin configuration consistent with model fields

Specification Design link

Technology Stack link

Initial Domain Models link

The initial specification defined three entities for the core booking flow:

  TravelPackage  1 ──── N  Tour
Tour           1 ──── N  Reservation
  

TravelPackage (travel product):

• Title, slug, region, duration, image URL
• is_published flag for visibility control
• min_price property for dynamic lowest tour price retrieval

Tour (scheduled departure):

• Specific departure/return dates, price, remaining seats
• Status management (available / soldout / cancelled)
• is_reservable property for reservation eligibility

Reservation (booking):

• Customer information (name, email, phone, guests, notes)
• FK relationship to Tour
• No payment processing (DB persistence only)

Business Rules link

The specification explicitly defined the following rules:

1. Only packages with is_published=True appear on the frontend
2. Only tours with status="available" can be reserved
3. Price display shows the lowest tour price within a package (Min aggregation)
4. Reservation flow follows a 3-step pattern: form → confirmation preview → completion
5. Database write occurs only on the confirmation POST (via session storage)

UI Wireframes link

Layouts were defined as ASCII art, enabling the LLM to understand visual structure and apply appropriate Tailwind classes:

  ┌─────────────────────────────────────────────────┐
│  HERO SECTION: bg-gradient-to-r from-blue-600   │
│  [SVG airplane animation flying across]         │
│  "Discover Your Next Adventure"                 │
│  [ Browse All Packages → ]                      │
├─────────────────────────────────────────────────┤
│  FEATURED PACKAGES (card grid)                  │
│  ┌──────┐  ┌──────┐  ┌──────┐                  │
│  │Card 1│  │Card 2│  │Card 3│                   │
│  └──────┘  └──────┘  └──────┘                  │
└─────────────────────────────────────────────────┘
  

Material Design 3 Specifications link

Hover effects: hover:shadow-lg hover:-translate-y-1 transition-all duration-200

Code Generated by Local LLM link

Alpine.js Filtering link

The agent read the Alpine.js specification and generated client-side filtering:

  x-data="{
    region: '',
    maxPrice: ''
}"
  

  x-show="(region === '' || $el.dataset.region === region) &&
        (maxPrice === '' || parseInt($el.dataset.minPrice) <= parseInt(maxPrice))"
  

This server-API-free approach demonstrates that the local model correctly understood Alpine.js reactive patterns.

Session-Based Reservation Flow link

The 3-step reservation flow was generated as specified:

1. Form input (/reserve/<tour_id>/): After validation, data is saved to session
2. Confirmation preview (/reserve/<tour_id>/confirm/): Read from session, display summary
3. Completion (/reserve/success/): Confirmation POST saves to DB, clears session

  # ReservationCreateView: POST saves to session
request.session['reservation_data'] = form.cleaned_data
return redirect('reservation_confirm', tour_id=tour.id)

# ReservationConfirmView: POST saves to DB
data = request.session.pop('reservation_data')
Reservation.objects.create(tour=tour, **data)
return redirect('reservation_success')
  

Django Admin Configuration link

Admin configuration including inline editing was generated consistently with model definitions:

  class TourInline(admin.TabularInline):
    model = Tour
    extra = 1

@admin.register(TravelPackage)
class TravelPackageAdmin(admin.ModelAdmin):
    list_display = ["title", "region", "duration_days", "is_published"]
    list_editable = ["is_published"]
    prepopulated_fields = {"slug": ("title",)}
    inlines = [TourInline]
  

Seed Data link

The seed_demo management command auto-generates 5 packages (14 tours total) across different regions for filter testing.

Agent-Driven Incremental Expansion link

After the initial one-shot generation and manual fixes to stabilize the base, two additional feature expansion requests were made. The agent read existing code and added the following apps (with manual corrections required at each stage):

The agent read existing tours/models.py to verify FK relationships and maintained consistency with new models. However, template quote escaping, some missing imports, and cross-template inconsistencies required manual fixes at each stage. Rather than fully automatic generation, the workflow settled into roughly “80% agent-generated, 20% human-corrected.” Still, the fact that this “read existing code, understand context, then extend” behavior worked on a local MoE model is noteworthy.

Generation Results link

Screenshots link

Initial Generated File Structure link

Verification link

After manual corrections, the following functionality was confirmed:

• Server started after migration
• Seed data populated packages on the frontend
• Alpine.js filtering and sorting functioned correctly
• Reservation flow (input → confirm → complete) completed successfully
• Admin inline editing worked as specified

Key areas requiring manual fixes:

• Django template tag quote escaping on the package detail page ({{ tour.end_date|date:"M j, Y" }} rendered as raw strings)
• Some missing imports and type inconsistencies
• Cross-template consistency during feature expansion

SVG Animation link

The hero section features an airplane flight animation (8-second loop) and floating clouds (15-second loop) generated as SVG with CSS keyframe animations.

Key Learnings link

1. Local MoE Model Coding Capability link

Qwen3.5-122B-A10B (Q5_K_M) generated coherent Django models, views, templates, and admin configuration. Even during incremental expansion using 77K tokens of context, consistency with existing code was maintained. Not quite cloud-model quality, but with clear specifications, the results were practically usable.

2. Specification Detail Determines Local LLM Accuracy link

To get reliable output from a local LLM, specification quality is critical. Particularly important:

• Domain model field definitions (types, constraints, defaults)
• URL pattern to view mapping tables
• UI wireframes (ASCII art format is sufficient)
• Specific Tailwind class designations

Cloud-scale models often produce “good enough” output from vague instructions. Local models translate specification ambiguity directly into output inconsistency.

3. Multi-MCP Server Coordination link

The combination of custom tools (ctree for code symbol analysis, pathfinder for path resolution) and OSS tools (serena for semantic code operations, filesystem for file I/O, ripgrep for search) worked reliably with the local LLM. The agent used serena to search symbols, filesystem to read/write files, and ctree to understand code structure — autonomously coordinating across multiple MCP servers.

4. Template Escaping Issues link

Django template tag quote handling was an area where the local LLM struggled. Filter arguments with quotes like {{ value|date:"M j, Y" }} were sometimes not correctly escaped during generation. This can occur with cloud models too, but was somewhat more frequent with the local model.

Summary link

1. Full web app from local inference only: Qwen3.5-122B-A10B (Q5_K_M) built a full-stack Django site with zero cloud API calls
2. Incremental expansion capability: Extended from 3 initial models to 6 apps while maintaining existing code context
3. MCP agent integration: Local ik_llama.cpp + multiple MCP servers (ctree / pathfinder / serena / filesystem / ripgrep) proved practically functional
4. Specification quality drives local LLM accuracy: Clear specifications matter even more than with cloud models
5. Manual fixes at each stage: Not fully automatic, but an 80/20 agent-to-human ratio proved sufficient to build a full-stack app