The Software Factory Starts Before the First Agent Runs
AI gives us more ways to build software. We still need to choose worthwhile problems, set limits, and check that what we ship helps someone.
We want AI to help us turn real problems into working software sooner. That's a useful starting point for the conversation about software factories. How much code an agent can produce tells us only part of the story.
The questions that shape my approach to software still come first: Who needs this? What's failing today? What would make things better? How much is that improvement worth spending?
As engineers, we have more ways to try a solution now. We still have to decide whether it's worth building.
That's what interested me in Tenex’s account of its AI-native SDLC. Its MetaHarness connects project context, plans, agent workflows, and evidence that work is complete. There's useful engineering here, especially in how it carries understanding from one session to the next.
To put that machinery to work, we need to decide what enters it and what a good result looks like.
Start with the problem and the budget
The way I think about building software follows a loop:
Frame → Research → Shape → Commit → Build → Verify → Ship → Learn.
We start by understanding the problem and who it affects. Then we look at the system, work through a solution, and decide how much to invest. These steps don't need to become a set of meetings. They give us questions to answer before we spend heavily on implementation.
Shape Up calls that investment an appetite:
“Estimates start with a design and end with a number. Appetites start with a number and end with a design.”
Ryan Singer, Shape Up: Set Boundaries
An appetite asks how much an outcome is worth. It helps us choose a solution before we become attached to every feature it could include.
With AI, that budget needs to cover compute, review, integration, and the cost of running what we ship. Another implementation might be cheap to generate. Deciding whether it belongs in production can still take considerable work.
Atlassian’s explanation of the iron triangle describes the tradeoff: time, resources, and scope affect one another. A practical default is to limit time and resources, then adjust optional scope. If the essential work won't fit, we need to revisit the commitment.
A good-looking plan can still be wrong
A clear plan helps. We also need to know what investigation went into it.
Ryan Singer puts this plainly:
“Shaping is not filling in a template. It’s not a document.”
An agent can produce a convincing specification in minutes. A dependency, data model, or interaction can still make that plan unworkable.
Before we commit, can we explain how the parts connect? Have we inspected the relevant code? Which assumptions could force us to start over? What are we leaving out?
Take a hypothetical request to automate refunds. Writing the endpoint might be straightforward. Deciding who can authorize a refund, what happens on a retry, and how to reconcile partial failures could change the entire design. We should work through those questions before handing out implementation tasks.
HumanLayer’s research, plan, implement workflow fits this approach. We carry the useful findings from research into planning and implementation, giving the agent enough context to work from checked assumptions.
Help the next session pick up the work
Tenex separates current state, future intent, and history in a shared project record. It also prepares context for new agent sessions and versions reusable skills. Those are useful places to start.
When a new session begins, it should be clear which decisions are implemented and which are still proposals. The reason for a constraint should be easy to find. Open questions should stay visible.
We don't need to load every document into every session to do that. A useful handoff explains the goal, relevant code, constraints, acceptance criteria, and the reasoning behind decisions that matter to the next step.
Progress needs the same care. A scope with an unresolved design question is different from one where we understand the remaining work. Shape Up’s approach to showing progress makes that distinction useful: a shrinking task list can still hide uncertainty.
Five completed tasks don't settle the assumption the sixth depends on.
Leave room to stop
Tenex uses the amount of work scoped ahead as one signal of planning health. That can help coordinate delivery. We should be careful about turning it into a target.
Keeping every agent busy isn't the goal. Sometimes we need to watch how a release performs or find out whether someone actually needs the next feature. Available implementation capacity doesn't answer either question.
For substantial work, we should know what we're willing to spend, what we've left out, and when we'll reconsider the approach. Another attempt should teach us something. If repeated attempts only produce more code, it's time to pause and understand why.
Agree on what done means
One sentence in the Tenex article captures the responsibility that stays with us:
“The system multiplies judgment, it does not supply it.”
Tenex, Building an AI-Native SDLC
A linked PR shows that a change exists. Passing tests tell us about the conditions those tests covered. We still have to check whether the change solves the user's problem.
That means looking at evidence for the version and environment we're actually releasing, being clear about limitations, and checking what happened after it shipped. What improved for the user? How much work did it take to build, review, repair, and run?
Those questions give us a better way to judge a software factory than code volume alone.
Tenex's article describes a process. It doesn't offer a controlled demonstration of productivity gains. We can borrow its useful mechanisms and test whether they help us deliver reliable software at a cost that makes sense.
Faster implementation gives us more options. Our job is to use them well: choose a worthwhile problem, work through the hard questions, and keep checking that what we're building deserves to ship.