Coding is solved. The factory isn't.

Highly opinionated, based on my personal experience. Not a prescription —

just notes from what I keep figuring out while dogfooding my own setup. I'm

scratching the surface, with a lot left to learn.

I'm building a multi-repo personal code factory. I don't spec it up front: I dogfood it day by day — using it, and asking for improvements or fixes when something breaks. The architectural decisions still can't be made blindly by the models, so daily use is how the system finds its shape. Two qualifiers about scope, then four claims.

Personal means local — for better and worse. I call this a personal code factory because it has no business running anywhere but on my laptop. There's no auth layer, no audit log, no sandbox between the agent and my git remotes. It has my GitHub tokens, my GitLab tokens, my Slack credentials, my pass store.

The other side of that coin is that local makes it stealth. I can use it without bothering anyone in the company. I don't have to ask DevOps for anything, there's no IT-security review to clear, no team-practice committee to harmonize with, no central infra to wait on — it just automates things I would otherwise do by hand. That removes every external bottleneck, and it's what lets me experiment fast.

The downside is the same thing said the other way: because it's mine, it doesn't help anyone else, and it's nowhere near as efficient as something that would run on GitLab or Slack directly. This is a POC. If it turns out to work, the right move is to promote it to actual company infrastructure.

Multi-repo means a particular kind of hard. I run it on multi-repo because that's what my work looks like. If your code lives in a single repo, a lot of what I describe in this series either disappears or shows up differently. I'm not claiming the multi-repo case is the interesting one — just that it's the one I have.

1. Coding is solved

Coding is solved — Cherny's phrase, and I think he's right. It took four things, and they're not the same thing.

The model: capable enough to write the code.

The harness: what lets the model act instead of just emitting text — read the repo, run the tests, iterate, fix. (Mine is Claude Code, but the principle isn't tied to it.)

A layer of deterministic constraints: checks that keep the output converging toward quality instead of tech debt. I work in Python, so for me that's , , plus most of it already runs without me. One orchestrator with the big picture, not a swarm — it arbitrates and hands the actual work to sub-agents. What still needs me is basically troubleshooting and steering, and I assume that the loop can't be fully closed as long as the behavioral evals are missing.

What the rest of the series is

I'll try to publish roughly one post a week. Each one is the thing I keep getting wrong and trying to get less wrong:

• 
  Part 1 — Software engineering became software architecture. Deterministic constraints solve code quality. Nothing solves whether the architecture is right — that's what's left for a human, and there is no gate for it.


• 
  Part 2 — Suppose the skill is never followed. Why I treat prose guidance as decorative and everything that matters as a hook, why I had to invent memory because skills aren't reliably read, and how I'm starting to write evals — a test suite that checks whether the agent actually behaved as planned — so I catch a skill being ignored before a hook has to.


• 
  Part 3 — Make yourself an optional reviewer. The closed-loop part, including the surprisingly hard subproblem of letting the system merge PRs without my approval without it feeling reckless.


• 
  Part 4 — One orchestrator, many loops. Why I run a single session with many sub-agents instead of many sessions, what that costs, and the honest ceiling I think it has.


• 
  Part 5 — FSM in the database. How concurrency, leaks, and crashes stopped being terrifying once the workflow state lived in a table instead of in memory — and how the same substrate carries resilience and a distributed improvement mechanism across multiple repos.

I'll change my mind about some of this between now and the last post. That's the point.