The Software Factory Works Best After You Know What You're Making

There is a lot of talk right now about agent loops.

And to be clear, I get it.

The pitch is seductive because it is not entirely wrong. You write a great spec for the feature you want to build. You do this with the help of an agent. You ask it to interrogate the shit out of you, then you interrogate the shit out of it, and the two of you bang around ideas until you have a very well-formed markdown plan.

At that point, the promise is that you can drop the plan into the machine.

The agents enter the loop.

Plan the feature. Code the feature. Test the feature. QA the feature. Fix the feature. Review the architecture. Review the security. Review the UI. Repeat until done.

Sometimes there are multiple layers of agents involved. I have heard of people running workflows with dozens of subagents reviewing a feature from different angles. Product review. Architecture review. Test review. Security review. Design review. Code smell review. Documentation review. The whole thing becomes a little software factory humming along in the dark.

And honestly, I believe it works.

It may use a shitload of tokens, but after enough passes through enough thoughtful agents with enough well-written skills, the output can get damn near great. The mistake is assuming that this is now the correct way to build all software.

It isn’t.

It is the correct way to build some software.

And the difference matters.

The loop works best when the shape of the thing is already known. If the architecture is mature, the design system is stable, the product patterns are established, and the work is mostly a matter of producing another well-understood part, the software factory can be incredible.

Need another admin table that follows the existing patterns? Great.

Need to add a new endpoint that behaves like the other endpoints? Perfect.

Need to create another settings page using the same UI kit, same form structure, same validation patterns, same authorization model? Let the machine cook.

This is where agent loops shine. The system has rails. The product has gravity. The design language already exists. The architecture already has opinions. The agents are not inventing the world; they are manufacturing parts that fit into a world that has already been invented.

That is a very different task from figuring out what the product should be.

A lot of my work does not start with a mature system. It starts with a problem, a half-formed product idea, a user who might not know what they need yet, and a bunch of assumptions that are probably wrong in at least three places.

That kind of work is not factory work.

That is product work.

And product work is messy.

It involves UX design, product judgment, technical tradeoffs, deep thinking, timing, sequencing, and a lot of staring at something you thought was going to be great and realizing, ten seconds after seeing it on the screen, that it is actually kind of bad.

This is why I do not personally run long autonomous loops for hours and then come back expecting the thing to be right.

My judgment is needed much earlier than that.

Not because I am smarter than the agent. Not because the agent is useless. Quite the opposite. The agent is moving very fast, and because it is moving very fast, my judgment has to be in the loop more often, not less.

When I am building a product, I am often discovering the UX as I go. I may have a pretty strong idea in my head. I may even be convinced the flow is obvious.

Then I see it.

I click it.

And the whole thing feels off.

The button is wrong. The page is wrong. The form asks too much too early. The workflow I thought was simple is only simple because I have been living inside it for three days.

That moment matters.

And I do not want that moment delayed by six hours of autonomous work.

This is especially true if you are doing CPTO-type work. Product, UX, and engineering are not separate lanes yet. They are tangled together. You are not just implementing a known design. You are finding the product through the implementation.

In the old world, you might have ended that exploration with a Figma file. In this new world, you can end it with a working, shippable product. That is an enormous advantage. But it does not mean the exploration disappeared. It just moved closer to the code.

That is the part I think people miss.

AI did not eliminate the need for deep thinking about the product. It compressed the distance between idea, design, and implementation. Which means you can make more decisions faster than ever before.

That can be exhausting.

Sometimes it feels like the guy in Limitless. Everything is brighter. The world is moving slower. You can see all the connections. You are building at a pace that used to be impossible.

But you are also aging twice as fast.

Because even though the typing is easier, the judgment is not. The judgment may actually be harder now. You are reviewing more possibilities, making more product calls, rejecting more ideas, shaping more flows, and correcting more nearly-right implementations than you ever could before.

The work did not become effortless. The shape of the work changed.

For some software, the hard part used to be raw production. Can we write enough code? Can we get enough tickets done? Can we generate enough test coverage? Can we ship the backlog?

Agent loops are very good at attacking that problem.

But for new products, early features, and UX-heavy work, the hard part is often not production. The hard part is knowing what should exist.

And honestly, I hate when people call that a bottleneck.

“Bottleneck” is a manager’s word. It implies the ideal state is some frictionless conveyor belt where an idea enters one side, implementation comes out the other, and nothing slows down the glorious march toward done.

But real makers know the friction is not the problem.

The friction is the job.

Figuring out the right thing is not some annoying blockage in the system. It is the work. Exploring the space is the work. Spelunking into the dark weird depths of the problem and coming back with something elegant is the work.

That is what you need makers for.

Not just people who can move tickets across a board. Not just people who can turn a spec into code. You need people who can live inside the ambiguity long enough to find the shape of the thing.

This is the part that does not show up cleanly on a Gantt chart. It does not look efficient from a distance. It can look like circling, wandering, revisiting, deleting, renaming, rebuilding, and changing your mind.

But that is not waste.

That is what separates good work from great work.

That is the difference between producing software and making a product.

This is where I think a lot of people get into trouble. They try to use the software factory before they know what the factory is supposed to make.

Factories are incredible when they are producing known parts.

They are much less useful when you are still standing in the woods trying to decide whether you are building a chair, a cabin, or a boat.

That does not mean the agents are not useful in the early phase. They absolutely are. I use them constantly. But I use them more like a collaborator than a factory.

I want the agent to challenge the plan. I want it to generate options. I want it to help me see the edge cases. I want it to code fast, revise fast, and explain tradeoffs. I want it to help me move from idea to working product without the old ceremony.

But I do not want it disappearing into a tunnel for half a day while I go off and do something else. Not only am I out of the loop at that point, I am out of the product. I have exited the flow state. And when the thing comes back, I am no longer shaping it from the inside. I am reacting to it from the outside.

For that kind of work, the loop has to be tighter.

Build a slice. Look at it. Feel it. Change your mind. Rewrite the flow. Move the button. Delete half the fields. Rename the concept. Realize the whole page should not exist. Ask the agent to refactor. Run it again.

That is still a loop.

It is just a human-centered loop.

The human is not a final approver standing at the end of the assembly line. The human is part of the creative process itself. The judgment is not a checkpoint. The judgment is the work.

Once the product matures, the balance changes.

When the patterns settle, the design system hardens, the architecture has proven itself, and the core workflows are known, the software factory becomes much more powerful. At that point, you can hand off bigger chunks. You can trust the agents to follow existing conventions. You can create skills that encode your preferences. You can build review layers that catch mistakes. You can let the system produce more while you supervise less.

That is a great place to get to.

But it is not always where you start.

The mistake is treating every software project like it has already reached that stage.

Some projects need a factory.

Some projects need a studio.

And some projects need the founder, designer, product thinker, and engineer sitting in the same chair, arguing with the machine every twenty minutes until the thing finally feels right.

That is the distinction.

Agent loops and software factories are real. They work. They are going to change how mature software gets built. For stable systems with clear specs, established patterns, and known outcomes, they may become the default way a lot of work gets done.

But when you are still crafting the product, discovering the UX, and deciding what the thing is supposed to be, you cannot fully remove yourself from the loop.

You are the loop.