A couple weeks ago I wrote about my hybrid LLM setup. At the time, the division seemed simple enough: cloud models for writing code, and a local server in my house for family life, privacy, and experiments.
That split was always a temporary checkpoint.
I spend a lot of my spare time building BrandCast. It’s a large monorepo with thousands of moving parts. Over the past year, I’ve poured a huge amount of effort into dialing in its AI harness. I use Claude Code as my primary pair programmer, backed by custom skills, system prompts, and my Root development framework.
At this point, the harness is predictable. If my input context is clean, I can predict the quality of the output with high confidence.
The problem isn’t the code generation anymore. The problem is the friction around it.
Sitting in front of a terminal hitting enter every few minutes gets old fast. I don’t want an interactive copilot glued to my face all evening. I want an autonomous software factory.
The Nuance: The Wrong Way to Split Hybrid
Most conversations about AI agents suffer from binary thinking.
One camp insists on running everything locally. They imagine an 8B or 32B model refactoring hundreds of files across a massive monorepo with zero external API calls. I love my local hardware, but that’s fantasy today. When the cost of a wrong edit is high, you pay for the frontier model. Local models don’t have the context coherence or reasoning depth to navigate deep monorepo migrations without going off the rails.
The other camp hands their credit card over to cloud agents for every tiny step. They spin up autonomous swarms that burn millions of frontier tokens just reading GitHub issues, hallucinating roadmaps, and doing basic ticket triage.
The reality is more nuanced.
Frontier models are expensive and rate-limited. You don’t use a master craftsman to sweep the workshop floor or sort tickets into neat piles. You use them to build the intricate mechanisms.
Local models, on the other hand, are fast, private, and practically free once the server is paid for. They aren’t ready to rewrite my backend, but they are fantastic at classification, evaluation, and triage.
The logical step isn’t choosing between local and cloud. It’s chaining them together.
Taking the Harness Off My Laptop
Before I could automate the factory floor, I had to fix where it lived.
For months, I ran my entire development harness directly on my MacBook. If you’ve ever run continuous agent loops, multiple git worktrees, Docker test containers, and local build tools on your primary laptop, you know the pain. The fans spin up. The battery melts. Your terminal history turns into an unreadable blur of agent output. Worst of all, your working git tree is constantly in flux.
So I moved the bulk of my BrandCast development off my laptop entirely.
I set up a dedicated Intel NUC with 32GB of RAM. It sits quietly on my network, always powered on, running the dev harness and the background agents.
That hardware separation changed how I think about my time:
- Research is still mine to own. I use my laptop for high-leverage work: exploratory coding, architectural spikes, deep customer work, and reviewing diffs. My laptop stays fast, quiet, and responsive.
- The chopping wood and carrying water moves to the NUC. The repetitive mechanics of software engineering: triaging bug tickets, spinning up branches, writing boilerplate, running tests, fixing regressions: all move to the factory floor.
- Let git merging do what it’s good for. I can work on an experimental feature on my laptop while Factory runs an automated queue on the NUC. When the NUC finishes a ticket, it pushes a PR. When I finish an experiment, I push a branch. Git and GitHub Actions handle the merging and the validation. Distributed version control was built for asynchronous collaboration. It works just as well when your collaborator is an autonomous box in the closet.
Enter Factory
With the harness running on the NUC, I built a small web UI to manage the flow. I call it Factory.
It sits between my GitHub issue backlog and my coding harness.

Here’s what is happening behind that screen:
- Intake: Issues land in GitHub. Some are written by me by hand. Others come out of agentic brainstorming sessions when I’m exploring new features.
- Local Evaluation: Factory pulls down all open issues and sends them to my local LLM server (the Infplane Hilbert box sitting in my house).
- Scoring and Rationale: The local model inspects the title, description, and acceptance criteria. It scores each issue by complexity, impact, and feasibility. In the screenshot, you can see issue #4156 scored an 8.1, accompanied by a clean summary: “Critical security fix with clear scope, acceptance criteria, and mechanical implementation path.”
- Queue Presentation: Factory sorts the candidates and shows me the top 15 ready-to-run items.
Instead of staring at a sprawling backlog and wondering what to tackle next, I have a prioritized queue scored by a model that didn’t cost me a penny in API tokens.
The Architecture
Here’s how the entire topology fits together across the laptop, the NUC, the local inference box, and the cloud:

Notice how each machine has a dedicated responsibility:
- Developer Laptop: Where I do research, plan architecture, and run targeted one-off experiments.
- Infplane Hilbert: Dedicated local AI inference box running AMD Ryzen AI hardware with 128GB of RAM. It handles high-speed, zero-cost backlog evaluation.
- Dedicated NUC: The factory floor with 32GB of RAM. It hosts the Factory service, SQLite state DB, and background Claude Code sessions in isolated git worktrees.
- Cloud & Frontier Tier: GitHub hosts the repository and Actions CI/CD. The Anthropic API delivers deep frontier reasoning on the Claude 20x Max plan.
Two Workflows: One-Off vs. Auto
Factory gives me two execution modes depending on how involved I want to be.
1. One-Off Execution
Sometimes I want specific control over what runs. I open Factory, look through the top 15 ranked issues, find the one I care about, and click run.
Factory immediately launches a backgrounded Claude Code session on the NUC. It provisions an isolated git worktree so the main repository tree isn’t touched. The session boots with my full configuration: project-specific MCP servers, custom system prompts, and the Root dev workflow.
The agent reads the issue, writes the plan, edits the code, runs the tests, and pushes a PR. I can monitor it if I want, or go back to whatever else I was doing on my laptop.
2. Auto Queue Processing
This is where the setup becomes genuinely autonomous.
I click run at the top of the queue and let Factory take the wheel.
Factory grabs the top-ranked issue and kicks off the background session. While Claude Code works through the Root workflow, Factory continuously polls GitHub Actions to monitor build and test progress.
When the pull request passes CI and merges into main, Factory runs its teardown routine:
- It removes the isolated git worktree (in the screenshot, you can see
cleaned /home/jduncan/Code/bc-4377). - It cleans up dangling agent processes and deleted branches.
- It logs the execution stats to a local SQLite database (issue #4377 took 151 minutes and 26 seconds).
- It marks the ticket complete, picks the next highest issue from the queue, and starts the cycle again.
Eating My Own Dogfood
If you’ve heard me speak at Google Cloud recently, you’ve heard this exact talk track.
Enterprises are wrestling with the exact same challenge. Everyone knows how to hook up an LLM to an IDE. The real question is how to scale agentic development without burning out your developers, draining your API budget on trivial tasks, or letting unvetted code run wild.
The answer is division of labor.
Use the frontier model for what it does best: large-scale, complex reasoning and code modifications in a massive codebase. Augment it with a local LLM to automate your supervisory duties away. Offload the heavy execution to a dedicated machine so your primary workstation stays free for creative thought.
This is me eating my own dogfood. I have a Claude 20x Max plan. Let’s see how well it holds up when a local factory keeps feeding it work around the clock.
So What?
If you’re looking at your own development workflow and wondering how to take the next step toward autonomy, keep these principles in mind:
- Match model cost to task complexity. Don’t spend frontier tokens to sort a list or summarize an issue. Use cheap, local models for classification and routing. Save the frontier power for code execution.
- Get the harness off your primary machine. If an agent is running for two hours in the background, it shouldn’t hold your personal laptop hostage. A cheap, dedicated box with plenty of RAM gives you the freedom to step away.
- Your harness is your safety net. Factory only works because the Root framework enforces strict testing and verification steps before any code gets committed. Autonomous loops without rigid harness constraints just create technical debt faster.
- Isolate your environments. Never let an autonomous agent work directly in your dirty working tree. Use git worktrees and clean teardown scripts so failed runs can be pruned instantly without leaving collateral damage.
- Keep research human. The goal isn’t to remove yourself from software engineering. The goal is to own the architecture and the research, while delegating the chopping wood and carrying water to the factory.
Hybrid AI isn’t just about where your data lives. It’s about how your models collaborate across your hardware. And right now, the factory floor is humming.