The control system I built so an AI could ship my code

Vamshi Krishna V.

Patient work, woven in public.

This is Thread 05 of Loomwork. New here? Thread 01 explains why this newsletter exists — 2 minutes. Last Sunday I opened up the live product and walked through what's actually shipped; this week is about how it gets built.

When you start a project solo, you make a call about friction.

Early on — no users, nothing in production that matters — I kept the loop fast and light. The way you prototype. An AI coding agent doing the implementation, me directing, minimal ceremony between an idea and it being live. That's a deliberate tradeoff, not an absence of judgment. I've spent years inside regulated environments where every change is gated, reviewed, and logged. I know exactly what that discipline costs and exactly what it buys. On a one-person prototype in its first stretch, I chose to defer most of it on purpose, because the cost of a mistake was near zero and speed was the whole point.

Then the project crossed the line where that tradeoff flips. A real surface. A public site. A second project starting up beside it. The moment the cost of a mistake stops being zero is the moment the friction becomes worth paying for.

So I did what I'd do in any serious environment: I built the control layer. Here's the shape of it, and why this shape and not another.

It's four layers, and each one does a different job.

The first is context. The agent loads the project's current state and rules every single session before it touches anything — what's shipped, what's in flight, what the hard constraints are. No work happens against stale assumptions.

The second is encoded patterns — what the industry calls skills. These teach the agent to write things my way: the house visual system, the way I structure a feature, the rules about what can and can't be exposed before it's ready. The agent generates code that looks like mine, not like generic output.

The third is the part a controls person cares about most: deterministic gates. Automatic checks that run on every save and every push, and that the agent cannot talk its way around. Type-checking. Linting, set to block on warnings, not just errors. A secret scan, so a key never lands in a commit. A UI smoke test that catches a specific class of layout bug I'd hit before. These aren't suggestions the model chooses to follow. They're scripts. They run whether the model or I remembers them or not. That distinction is the whole point: judgment can lapse; a gate cannot.

The fourth is a team of narrow-role agents instead of one that does everything. A planner that maps the work and can't write code. A builder that writes code and can't push or deploy. A reviewer that reads the diff and only comments. A checker that runs the gates. Each one has exactly the access its job requires and nothing more — the same separation-of-duties principle that any regulated system is built on. No single agent can both decide and act unsupervised.

On top of those four, two things that make it feel less like a code tool and more like an operated system.

A human gate before implementation, for anything that matters. When the work is big — touches auth, touches data, creates something new — the agent has to produce the design first: the approach, the tradeoffs, the alternatives it rejected and why. Then it stops and waits for me to approve the design before a line of code gets written. Small things flow through untouched. Big things wait for a human. That's the line I care about: the machine sets up the decision, a person makes it.

And a cost ceiling, because a system of always-on agents can quietly run up a bill. The setup tracks its own usage and stops itself before it crosses a limit I set — the same way you'd put a budget alert on any service you don't want surprising you.

Here's what the system did the first week it was on.

The most useful thing a quality gate does isn't catch a dramatic mistake on day one. It tells you the truth about what you already shipped.

The first time the SEO check ran across the whole app, it flagged that out of thirteen pages, exactly one had its own search-engine title. Every other page was silently inheriting a single generic site-wide title. The app had zero structured data — none of the markup that lets a search engine show a rich result. None of this was a regression. It was quietly true the entire time, invisible, because nothing had ever counted it. Even after I fixed three of them, it's still four of thirteen — because the gate only blocks new pages from shipping bare. The rest is debt the gate makes visible without forcing me to drop everything and fix the past.

That's the real value, and it's an honest one: I built the thing fast, the speed left debt, and the moment I added tooling, the debt became countable.

Why I'm writing this down.

Most of what gets shared about building with AI is about speed. The more interesting question is the boring one underneath: what's the control structure around the speed?

Who reviews? What can't be skipped? Where does a human still hold the last gate — and, just as important, where have you decided one isn't worth the friction?

Because that's the actual judgment. Not "controls everywhere." I run this full setup on Foundry, which is public and the thing I'm writing about. My other project still runs lighter, because the stakes there are different and a heavier process hasn't earned its keep yet. Matching the control to what's actually at risk — that's the decision worth making, and it's the one I'd want anyone on my team making too.

Where this is going.

Most teams are still asking how to review everything an AI writes. I think that's the wrong question, and a losing one — you can't out review a system that generates faster than you can read.

The question I'm building toward is different: how do you design the control structure so the output is trustworthy by construction, so the review happens at the level of decisions and design, not diffs and keystrokes?

That's what the human gate before implementation really is. It isn't me checking the AI's code. It's me approving the thinking before any code exists, and letting the system execute inside a boundary I've already drawn. Review moves upstream — from "is this line right?" to "is this the right thing to build?"

What I've described is the first working version of that. It's early. The agents are simple, the gates are basic, and most of the interesting parts aren't built yet. But the shape is right — and I'd rather be early to the right shape than polished on the wrong one.

Next Sunday: The architecture I'm betting on for the first agent. Where this stops being a tool that helps me build, and starts being one that runs the business while I watch. The master agent, the specialists, and the bet I'm making on how a one-person company gets a chief of staff.

See you then.

— Vamshi

Loomwork is by Vamshi Krishna Veggalam. Building Foundry at mindloomhq.com, with the full archive at loomwork.dev. Find me on LinkedIn.