Lattice is an internal web platform I designed and built for Rea Magnet Wire Co. to consolidate the patchwork of one-off scripts, spreadsheets, and aging utilities that IT and manufacturing relied on day-to-day. It has grown into the central hub for facility mapping, cable management, label printing, procedure checklists, monitoring, documentation, consumable inventory, manufacturing die tracking, dynamic forms, and a growing list of other modules.

What sets Lattice apart from past projects of mine is how it was built. Lattice is the product of a deliberate AI-augmented development workflow, where I act as the architect, reviewer, and decision-maker while leveraging multiple large language models and agentic tooling to compress what would otherwise be months of solo engineering into weeks.

Why Lattice Exists

Before Lattice, operational knowledge and tooling at Rea were scattered. Cable IDs lived in shared spreadsheets. Facility maps were static PDFs. Printer label templates were trapped inside Zebra’s native software. Monitoring data lived in PRTG dashboards that no one outside IT could read. Procedures were Word documents emailed around. Every new request meant another ad-hoc script or another shared drive folder.

I wanted a single, authenticated, well-structured platform where any of these tools could live, with SSO, role-based access, audit logging, and a consistent UI, so that adding the next module was an afternoon’s work instead of a new project.

The Technology Stack

Lattice is built on a stack chosen for stability, maintainability, and the ability to move quickly.

• Django 5 (Python) as the application framework. Class-based views, ORM, migrations, and a strong opinionated structure that makes the codebase easy to navigate as it grows.
• SQLite as the database, in both development and production. The deployment is single-node and the workload is well within SQLite’s comfort zone, which eliminated an entire class of operational overhead.
• Microsoft Entra ID SSO via django-allauth, with local accounts available as a fallback. Authentication is enforced globally by middleware.
• Custom RBAC layer built on Django groups and a Role model with per-module access levels (none, user, admin), plus a master netops-admin flag that bypasses module checks. Every view enforces access through a small set of helpers on the user model.
• Bootstrap 5.3 with light and dark theming, Leaflet 1.9 with ExtraMarkers for interactive facility maps, Font Awesome 6.5 for iconography, and a small set of bespoke JavaScript modules for search and navigation.
• Gunicorn behind Nginx on bare-metal Ubuntu, managed by systemd. The production deployment is intentionally simple so it can be maintained by a single person.
• A pluggable module architecture where each module owns its own models, views, templates, URLs, admin, and context file. New modules slot in without touching the core.

A High-Level Tour of the Features

Lattice is now a dozen-plus modules under one roof. A few highlights:

• Facility Maps. Interactive Leaflet maps of every Rea facility, with custom MBTiles tile pyramids, marker CRUD, and overlays for cables, switches, printers, and other assets.
• Cable Management. Generates and tracks structured cable IDs, decodes labels, manages cable locations, and supports CSV import and export. Replaces the spreadsheet that used to track thousands of runs.
• Zebra Label Printing. Centralized templates for switch labels, die labels, and operational signage, with print history and ZPLII generation. Builds on lessons from an earlier WPF tool I wrote.
• Procedure Checklists. Reusable templates and runtime “runs” with image attachments, so technicians can document work as they go.
• Monitoring. PRTG push sensors for MSA storage, network probes, Windows hosts, Veeam backups, and Aruba Insights RF telemetry, all reporting into a single dashboard.
• Documentation and Compendium. Two doc surfaces: an internal one for IT runbooks and a public-to-employees Compendium. Both sync from Git and from FreshService’s knowledge base, with a full-text search index.
• Consumable Inventory. Catalog, stock levels, reorder alerts, transaction log, and audit trail for IT supplies.
• Manufacturing Dies and Edge Rolls. Tooling inventory for the wire-drawing process, including label printing and CSV import and export.
• Kind Codes. Encoder and decoder for Rea’s 5-digit product code system, replacing tribal knowledge with a queryable lookup table.
• Dynamic Forms. A form builder for ad-hoc data collection, with email notifications and PDF rendering.
• Relay Service. API middleware that brokers requests between internal tools and external systems like Asset Essentials and FreshService, using bearer tokens.
• Analytics and Roadmap. Page-view analytics for admins and a public-to-staff roadmap where users can vote on and request features.

Each module is self-contained, follows the same conventions, and ships with its own context file so future AI-assisted work has the information it needs.

The AI Development Harness

This is the part of the project I’m most proud of, because it changed how I work.

Lattice was not “vibe-coded.” It was built using a structured, multi-model AI harness in which I am unambiguously the engineer in the loop, making architectural decisions, reviewing every diff, verifying every change in the running app, and rejecting suggestions that don’t fit the codebase’s conventions.

Claude as the Primary Collaborator

The core of the workflow is Claude Code (Anthropic’s CLI) running against the latest Claude Opus and Claude Sonnet models. Claude is responsible for the majority of the production code in Lattice. I drive it through:

• A repository-wide context file that encodes project conventions, architecture, authentication patterns, RBAC rules, and the do-and-do-not list. It is loaded into every Claude session automatically.
• Per-module context files that give Claude module-specific information (models, design notes, management commands) without bloating the global context window.
• Session notes and changelogs kept in the repo, so each session builds on the last and the history of decisions is preserved.
• A persistent memory system outside the repo where Claude records user preferences, project facts, and lessons learned across sessions.
• The Claude Agent SDK and sub-agent workflows for tasks where parallel exploration, adversarial verification, or scoped delegation produces better results than a single linear conversation.

Multiple Models for Multiple Strengths

Different models are good at different things, and the harness leans on that.

• Claude Opus for architecture, refactors, code review, and anything that needs careful reasoning over a large surface area.
• Claude Sonnet for fast iterative editing, tests, and well-scoped feature work where speed matters more than depth.
• OpenAI and Google models as second opinions on tricky design questions or when a diverse perspective helps catch blind spots. Used sparingly. The bulk of the work is Claude.
• Specialized sub-agents (explore, plan, code-review, verify) invoked for specific phases of a task rather than asking one general agent to do everything.

Guardrails That Make It Work

The harness is only as good as the rules around it. A few that matter:

• Every change is verified in the running app, not by static checks alone. The project’s instructions explicitly require running the dev server for any UI-touching work.
• Bug fixes don’t get cleanup-by-default. Surrounding refactors are separate decisions, made by me.
• No comments unless the “why” is non-obvious. No backwards-compatibility shims for code that isn’t shipped yet. No premature abstractions.
• Reuse before rewriting. Every change asks whether an existing utility, pattern, or definition already does the job.
• Risky actions (destructive git operations, force pushes, anything affecting shared state) require explicit confirmation.

These rules are encoded in the repo’s context files so every AI session inherits them.

What This Approach Has Made Possible

The harness has let me ship Lattice as a single developer at a pace that would otherwise require a small team. It lets me focus on the parts of the work that need human judgment, such as architecture, prioritization, stakeholder conversations, and the messy organizational details, while delegating the mechanical parts of implementation to AI agents I trust because I built the trust deliberately.

The result is a platform that is well-structured, consistently styled, thoroughly logged, version-controlled, and actively in use across the company. It is also a platform I can hand to the next engineer without apology. The conventions are documented, the modules are uniform, and the AI context files mean the next person (or the next AI) can get productive in a single session.

Reflection

Lattice is the project where I stopped thinking of AI as autocomplete and started thinking of it as a development environment. The shift was not about writing more code faster. It was about being able to take on a larger problem space than a single developer could otherwise hold in their head, while still being accountable for every decision and every line that shipped.

For a hiring manager or recruiter reading this, Lattice is evidence that I can architect non-trivial systems end-to-end, that I have practical, current experience driving multi-model AI workflows in production engineering work, and that I care about the discipline (conventions, documentation, RBAC, audit trails, deployment) that separates a side project from something an organization actually depends on.