The Software Factory EngineerCodebase Design, Verification Loops, System One Models, Agent Swarms, Software Factories

Let’s talk about what actually changed when agents started writing all the code, and why the hard part of your job didn’t go away. It moved.

Here’s the honest version. Generation is solved. Not perfect, but solved in the way that matters: the agent writes the change, runs the tests and opens the PR before your coffee break is over.

What isn’t solved is knowing that what came back is right. And right now, that job is yours. Code got cheap. You can run ten agents at once. Your attention is a few good hours a day, and no model release gives you more hours. If anything, every release makes the gap wider: the agents get faster, and you stay almost the same speed.

Which is good news, honestly. This is why engineers still matter. Agents are fast, but they have no idea what “correct” means for your product. You do. That judgement is the job now. But most of our hours go on checking the agent’s work by hand, not on deciding what “correct” should be.

And if this year feels like starting over, that’s the job. Software pays the way it does because it keeps changing, and the engineers who learn the new way first are the ones it rewards.

If you just sit down and start shipping with agents, you end up spending your attention in the wrong places. You turn into one of three people:

• The Proofreader. You read every diff. Four hundred lines, then nine hundred. An hour in, you’re skimming. Two hours in, you’re approving things you’d struggle to explain, and it still feels like checking.
• The Human Test Suite. The agent says “done, all tests pass.” You don’t quite believe it, so you click through it yourself. Often you’re right: every test was green and the page wouldn’t load. That’s the problem. Nothing in the loop was looking at the real app except you, and you don’t scale.
• The Last to Know. Nobody is watching production. Not the error logs, not the failed payments, not the customer who hit a broken page and left without saying anything. You find out days later, if at all.

Not to mention the waste. Hours spent reading code that turns out to be fine, while the one bug that mattered slips through anyway.

But none of this is a character flaw. It’s a budget problem, and budget problems have engineering answers.

Stop building the app. Build the thing that builds it.

Here’s the shift that changed how I work. Your job isn’t the application any more. Your job is the system that builds the application: the agents, the checks, the gates, the rules they all follow. You build that. It builds everything else.

When you fix a bug in an app, you’ve fixed one bug in one app.

When you fix it in the system, as a lint rule, a verifier, a new way to attack a change, every app it builds gets that fix. Today, tomorrow, and on code that hasn’t been written yet.

Work on the app is spent the moment you do it. Work on the system keeps paying dividends.

Where my day actually went

For about a year, I was the Proofreader. I read every diff my agents wrote, and I told myself that was being careful.

Every problem I caught, I caught by hand, and the next day the agent made it again somewhere else. None of that care compounded. And all of it happened before the merge. After the merge, nobody was looking at all.

So I stopped fixing apps and started fixing the system. Spending tokens instead of afternoons. Once that was running, it turned out I could:

• Hand off a task and come back to a change that has already been proven against the real app
• Read the few diffs that can actually hurt, and skip the rest with a clear conscience
• Run agent swarms to bug bash while I do something else, because compute scales and I don’t
• Hear about a broken flow from an agent before a customer emails me
• Turn every bug I find into a check, so the same mistake can’t come back anywhere

And not on a toy project. On real codebases that are years old, with companies that depend on them, with a token budget, where other people’s work is landing at the same time as mine.

A software factory that runs production

Agents pick up a ticket, write the code, open the PR. That part works. But most factories stop at the merge button. The ticket closes, the code goes out into the world, and nobody is watching it.

The one I’m going to teach you keeps going. It checks the work against reality, holds the risky changes for you, and keeps watching after it ships. It’s built from parts you’ll make yourself:

• Codebase design, so agents find one way to do each thing instead of inventing a fourth.
• Picking and designing verifiers, so every kind of change has a way to be proven.
• Verification loops, where one agent builds the change and a different model checks it against the real app, the real database and a real browser, until it passes.
• System one models, small fast models that judge every step and enforce the rules a linter can’t.
• Agent swarms that bug bash the same change from every side at once, so you spend tokens instead of afternoons.
• Gates and watchers: the gate holds the risky changes for you, and the watchers keep an eye on production after it ships.

This is the part that feels like cheating. Before a big change gets anywhere near you, the system sends a swarm at it. One agent clicks through it like a new user. One feeds it garbage input to see what falls over. One plays the attacker and tries to break it on purpose, and it’s built not to just agree with the code it’s attacking.

So go back to those three people from earlier. Here’s what changes for each.

What doesn’t fix it

Waiting for a better model. A better model writes faster. That widens the gap, it doesn’t close it.

More rules in CLAUDE.md. You wrote the rule, the agent ignored it on Thursday, and you wrote it again in capitals. An instruction is hope. A check that runs and fails doesn’t need to be remembered, and it never stops working.

Reading harder. You can’t out-read a machine. Skimming just feels like checking, and nothing you read today makes tomorrow’s reading any shorter.

The answer isn’t a setting or a plugin. It’s a system you design, the same way you’d design any other part of your product. And designing systems is still the job.

That’s what the next two weeks are for. You’ll build that system, one part at a time, and leave with it running.

The cohort

It runs for two weeks, starting Mon 26 October. Week 1 goes from intake to a running loop. Week 2 goes from verification to the software factory. The lessons are recorded so you can watch them when it suits you, with live office hours on Tuesdays and Thursdays, each run twice for two time zones.

Almost all the attention goes before the merge. After the merge, the code meets real users and real data, and that’s where it actually breaks. The system you build here watches that side too, and when something does break, it doesn’t just tell you. It learns from it. The bug becomes a regression check, the mistake becomes an invariant or a decision record the agents read next time, and the verifiers that went quiet get re-graded before you trust them again.

Here’s what a normal day looks like once it’s running. You hand work off in the morning. You look at what the gate held for you. You hear about the one thing that broke from an agent, not a customer. And by the evening, the system is a little better than it was this morning, which means so is everything it builds tomorrow.

Here’s everything we’ll cover.