How I AI: Alex Finn's Local AI Fleet and Automated Software Factory

Alex Finn has turned his office into a small local AI datacenter. In this episode of How I AI, he walks through a setup built around three 512 GB Mac Studios, an Nvidia DGX Spark, and a custom RTX 5090 machine that continuously run research, security review, coding, and software delivery jobs.

The interesting part is not the hardware flex. Alex’s argument is that local capacity changes what kinds of workflows are economically practical. He keeps models running all day on recurring jobs that would become painfully expensive if every scan, review, and background task hit a frontier API.

His system has three layers working together: machines chosen for different memory and speed tradeoffs, agents that manage those machines through a private network, and review loops that turn raw model output into work a stronger model or a human can approve.

Build a local AI fleet around specific workloads

Alex approaches hardware as a scheduling problem more than a specs competition. Large reasoning models need memory. Interactive coding work needs bandwidth and speed. Background jobs can be slower if they run continuously in the background.

Match the machine to the model behavior

After months of experimentation, Alex now treats each category of machine as good at a different class of work instead of searching for one perfect box.

1. Mac Studio: high memory, lower speed. Unified memory lets a 512 GB Mac Studio load extremely large models that would not fit on a typical GPU setup. Alex demonstrated GLM 5.2 and described the intelligence level as surprisingly close to frontier models, but with major latency tradeoffs. A single response could take roughly five minutes, which makes it impractical for fast interactive use but acceptable for long-running background scans.
2. DGX Spark: the practical middle ground. The system combines 128 GB of unified memory with Nvidia’s CUDA stack, giving Alex more speed than the Mac Studio while still supporting larger models. He uses it for midsize coding and research models including Qwen 3.6 and more recently Ornith 1.0 35B, which he found faster and stronger for coding workloads.
3. Custom RTX 5090 build: lower memory, much higher speed. The 5090 only provides 32 GB of VRAM, which limits the size of models it can run locally, but the responsiveness is much closer to a cloud API experience. Alex treats this category as the high-bandwidth workstation for tasks where waiting several minutes per response would break the workflow.

Use agents to manage the infrastructure

One of the more useful parts of Alex’s setup is that he no longer manually configures every machine. He uses agents to inspect hardware, choose appropriate local models, install them, and coordinate workloads across the fleet. That removes much of the traditional setup friction, although it also means the agents receive broad system access and need the same caution you would apply to any infrastructure administrator. You can follow the full implementation in How to Assemble a Multi-Machine Local AI Fleet. See How to Assemble a Multi-Machine Local AI Fleet.

Two tools make the system workable day to day:

• Tailscale creates the private network connecting the machines. Alex recommends it even for a single development computer because it makes local apps accessible from authorized devices for testing. In practice, it becomes the connective layer that lets agents move between machines as if they were on one internal network.
• OpenClaw or Hermes acts as the operator. Alex can point the agent at a new machine, ask it to inspect the available memory and hardware, select a compatible model, install dependencies, and add the system to the fleet without manually handling every configuration step.

"It will jump between all your devices, no technical knowledge needed, and load up and run anything you want."

Run recurring AI jobs instead of one-off prompts

Alex built a Fleet Control dashboard to monitor which models are running and what jobs they are processing. He describes the approach as ambient AI: instead of waiting for a human to issue prompts, models continuously perform scheduled work throughout the day.

Use local models for discovery and frontier models for judgment

One recurring pattern in Alex’s workflows is separating cheap discovery from expensive evaluation. He compares it to a BDR handing qualified leads to a closer. The local model does broad scanning work continuously, then a stronger model reviews only the findings worth attention.

1. The scout: every 30 minutes to an hour, a local model selects an API endpoint or section of the Henry Intelligent Machines codebase and scans it for possible security issues. Separate recurring jobs also review code quality and look for opportunities to simplify or optimize implementations.
2. The report: instead of taking direct action, the local model writes its findings into Markdown reports with code snippets, explanations, and references to the relevant files. One report shown during this episode of How I AI listed 374 findings, which Alex stressed were candidate issues rather than confirmed vulnerabilities.
3. The closer: once per day, a Claude Code loop reads the latest report, inspects the referenced code directly, decides which findings are legitimate, and determines what should actually be fixed. The expensive frontier reasoning only happens after the local models narrow the search space.

That division of labor is the core design principle behind the setup. Local models handle repetitive, high-volume scanning that would be expensive to run continuously through APIs. Frontier models and humans still make the higher-stakes decisions. Alex is explicit that he does not trust local models to operate as a fully autonomous security system.

Turn local models into a continuous research team

Alex uses a faster local model on the DGX Spark to monitor X, Reddit, Product Hunt, and Hacker News for recurring complaints, requests, and product ideas. The model is not making product decisions on its own. Its job is to surface signals and place them into a queue for later review. He treats the workflow more like continuous lead generation than autonomous strategy. See How to Set Up a Continuous Code Security Scan Using a Hybrid AI Workflow.

Build a software delivery loop with human approval

The most developed workflow in the episode is Alex’s "software factory" for Henry Intelligent Machines. The system links planning, implementation, review, testing, preview deployment, and merge approval into one mostly automated pipeline. The automation is extensive, but Alex still manually tests previews before shipping changes. See How to Build an Automated Software Factory with AI Agents.

Start with a morning planning conversation

Alex begins the day in Claude using a "morning build" command. Claude asks what he is thinking about, what product changes he wants, and what priorities matter that day. The conversation is then converted into a structured task list for Henry Intelligent Machines.

Separate implementation from quality control

Alex runs two independent Claude Code loops against the task queue so that building and reviewing are handled by different agents:

• The build loop continuously pulls tasks from the morning brief and implements them one by one throughout the day.
• The review loop independently checks completed work, inspects the generated code, fixes issues where possible, and validates the result before notifying Alex.

Approve merges from preview deployments

When a task finishes review, Slack sends Alex a summary of what changed, instructions for testing the feature, and a link to a dedicated Vercel preview deployment.

Alex manually tests the preview environment before approving anything. If the feature looks ready, he reacts to the Slack message with a rocket emoji.

That emoji triggers the Henry Loop to merge the reviewed change into the main branch automatically. The key detail is that the emoji is only the final approval step after human inspection, not blind autonomous deployment.

The operating model

Across security review, market research, and software delivery, Alex follows the same operating pattern: use local models for constant low-cost throughput, then escalate narrower decisions to stronger models or humans. The local systems generate options, reports, and drafts. Approval and interpretation still happen higher in the stack.

What is worth copying here is not necessarily the exact hardware stack. Most teams do not need three 512 GB Mac Studios heating up the office. The more transferable idea is the workflow structure: assign narrow recurring jobs to cheaper local models, save outputs in reviewable formats, and create explicit approval handoffs before anything important ships. This works especially well for monitoring, scanning, research collection, and repetitive engineering tasks where volume matters more than instant answers. Human judgment still matters most at the validation layer, particularly for security decisions, production deployments, and deciding which signals are actually meaningful.