Frontier SDLC: How I Learned to Stop Babysitting and Love the Factory

Does your agent build software while you sleep?

If yes, you have a software factory. You can skip this article.

If not, you’re still babysitting. A few months ago I crossed that line, and what changed was simple: I stopped scaling with my own attention and started scaling without limit.

Here’s the loop I’ll assume you and your team run today:

1. Brainstorm features
2. Write specifications
3. Review specifications
4. Generate technical implementation plans
5. Ask the agent to implement
6. Monitor until the agent finishes
7. Unblock or steer when the work stalls or drifts
8. Test for completeness
9. Test for quality
10. Review code
11. Deploy to production

Steps 3 through 10 are babysitting. The factory doesn’t delete them; it takes you out of the middle of them.

The run that changed my mind

I’d been trying to make my agents run longer, with nothing to show for it. I decided to try once more, this time building a CLI module for Mindlap.

The first session was a back-and-forth design discussion, about thirty minutes. The second was implementation, about two and a half hours. Tests came first, working backward from success criteria I’d defined before the agent started. I steered lightly, a nudge here and there. I never stopped the session, and the agent never stopped itself. The result was a working CLI application that did exactly what the spec said.

It worked. More than a good run, it was the perfect lap. Things flowed so smoothly, it almost felt like magic.

Part of the difference was the model. Opus 4.5 followed instructions closely and didn’t wander. But the model wasn’t the whole factory, and here’s how I know.

I tried to repeat the success. Those runs failed. So I dug in, and I eventually learned to run a factory even with models far weaker than Opus 4.5.

Four conditions that lined up by accident

The next runs were a disaster. If the model were the only variable, my results should have matched. If size were the problem, smaller tasks should have been easier. Neither held.

The lucky lap stayed out of reach, so I went looking for the cause. The CLI module had succeeded because four things were true at once. They’d lined up by accident, which is why I hadn’t noticed them:

1. Well defined. I knew exactly what I wanted before the agent started. The design session guaranteed it.
2. Contained. The agent touched nothing it didn’t need. It never reached into unrelated code.
3. Testable. The agent could verify its own work locally and root-cause issues as they came up.
4. Clear passing criteria. The agent could tell on its own when it was done.

Every feature that failed afterward was missing one or more of these.

A better model doesn’t save you

A faithful, instruction-following model isn’t a safety net. If anything, it’s the opposite of one: it removes the drift that used to force you to watch.

The models still need scaffolding. They’re still bound by context rot, task size, and the tools you give them. Your setup is still the thing standing between a clean lap and a wasted run.

This is also why babysitting used to be the right call. Earlier models drifted, so disciplined setup didn’t reliably pay off, and sitting there to course-correct was rational. Today’s models hold the line long enough that good setup converts into autonomous output.

Once I knew the four conditions, the obvious move was to guarantee them every time. So I did. And that’s when I found the real problem.

I was doing the same work at the start of every session: defining the task, writing the success criteria, setting up the tests, wiring the agent to its tools, giving the same steering I’d given a dozen times. None of it was hard. All of it was repetitive. And all of it was on me, every run.

That’s not a workflow. That’s a person standing in one spot, doing the same thing forever, and calling it work.

If the four conditions are what every task needs, then something other than me should put them in place.

A factory is nothing more than a machine that guarantees those conditions on every task, instead of leaving them to chance.

Letting go of the code is hard

When the factory runs, my job per lap is small. I brainstorm. I define features and what success looks like. That’s most of it. Everything after, whether it is implementation, verification, or unblocking, runs without me.

Every time I stepped in mid-run unprompted, I was reasserting the exact habit I was trying to escape.

This is the trap for anyone who can code: intervention feels like diligence. It isn’t. Once the conditions are guaranteed and the agent can verify itself, your reflex to grab the wheel becomes the single biggest risk to the run.

At the volume we now produce code, reviewing all of it is impossible. But letting go of the code doesn’t mean compromising on quality. It means you’ve built a system that ensures quality before you ever look.

That’s what it means to stop babysitting. The work doesn’t disappear. You spend most of the time defining the input and the output of the factory, and you trust the factory to carry the rest.

The frontier will move: run laps, not sprints

For our whole team, the unit of work became the lap, not the sprint. We pushed to run more laps in parallel, not to be wasteful, but to do far more.

Each lap is well defined and self-contained. It carries passing criteria written from the user’s point of view, not ours. It can be verified and deployed with proof of work before we test it ourselves. In the babysitting phase, nothing was real until I’d checked it. In the factory, the work proves itself first, and my check confirms rather than discovers.

The shape of a lap differs for every codebase I’ve touched. I rebuild the harness for each repo. But the conditions are constant. They’re best practices that were true before any AI agents.

I call this Frontier SDLC because the frontier is exactly what won’t hold still. Over three years it has moved, a lot. People expect the model to keep swallowing the scaffolding around it until one day the scaffolding is gone. I don’t think that’s what happens. The factory stays. What grows is our ambition. Every time you reach the frontier, it feels closer, so you point the factory at something bigger and messier than you’d have dared before.

That’s the loop worth being in. Define the work, contain it, make it verifiable, set the bar for done, and then guarantee all four every time, not by hand but by design. The model will keep changing. The discipline is what’s up to you.