All posts
ai-agentsphilosophyengineeringcodmir

Systems That Build Themselves

Why I think the ceiling on what one engineer can build is about to move, and what actually has to be true for that to happen.

3 min readNathan Jobrayan

Every job I've had has been a version of the same question: how do you get more done than one person should be able to?

As a sound engineer, the answer was preparation — build the rig so the show runs itself. As a tester, it was automation — build the suite so the checking runs itself. As a recruiter, it was process, and then it was Jobrain, because process by hand doesn't scale past you. Now it's agents.

Same question. The answer keeps getting bigger.

The ceiling is attention, not ability

The limit on what one engineer can build has never really been typing speed, and it has rarely been knowledge — that's been searchable for twenty years. The limit is how many things you can hold in your head simultaneously without dropping one.

Most engineering work is context switching with extra steps. You have the shape of the problem loaded, you get interrupted, and reconstructing that state costs more than the interruption did. Multiply across a week and the actual output of a very capable person is a fraction of their capability.

That's the ceiling. And it's the one agents actually lift — not by being smarter than you, but by holding context you'd otherwise have to reload.

What has to be true

I'm not interested in the version of this where AI writes code and everyone cheers. I've seen enough production incidents to know that generated code you can't verify is a liability with good marketing. For "systems that build themselves" to mean anything, three things have to hold:

Verification has to be cheaper than generation. If checking the work costs more than doing it, the system is a net negative no matter how impressive the output looks. This is the whole ballgame, and it's why I think people coming from testing backgrounds are going to matter a lot in this era.

The system has to survive you leaving. Work that stops when you close the laptop isn't leverage, it's a faster keyboard. Persistence is what turns a tool into a collaborator.

Being wrong has to be recoverable. Not prevented — recoverable. Same as live sound. You will not eliminate faults from a system with autonomous components. You can make every fault cheap to undo.

Get those three right and the interesting thing isn't that the AI writes code. It's that the unit of work changes. You stop writing implementations and start specifying outcomes, and the size of the thing one person can attempt goes up by an order of magnitude.

Where I actually am on this

Somewhere in the middle, honestly. codmir does the persistent execution part well. It does the streaming and interruption part well. The verification layer is the hard, unglamorous, ongoing work — and it's the part I think determines whether any of this becomes real or stays a demo.

But I've watched this pattern play out enough times now to trust the shape of it. Every time I've built a system that does the repetitive part, the work didn't disappear. It moved up a level, and the level above was more interesting.

I don't think this time is different. I think it's just bigger.