i was about to build a software factory. even if i ended up using someone else’s, i wanted to understand how one works from the inside. then i stopped, because my thinking about the problem wasn’t clear enough yet.
it’s been almost five years since i got access to github copilot, and about a year since opus 4.5 became the first model i trusted with surgical changes in brownfield projects. since then, agents have written 99.999% of my code, and a few billion tokens later i’m convinced the product development lifecycle has to change if we want to leverage the full potential of ai.
most engineers i know have switched to agentic engineering, but there’s still a lot to figure out. many aren’t much more productive yet, or don’t understand llms well enough to use them effectively. worse, companies keep trying tools and burning tokens while still struggling to get the most out of llms in how they work.
writing is how i find the gaps in my thinking, so what you’re reading is my attempt to clear it up: to work out where ai can bring the largest gains across the product development lifecycle.
i’ll start with a line from Eben Hewitt that i keep coming back to:
we architects have thought we were in the business of making software. But we’re in the business of building a business.
— Eben Hewitt, Technology Strategy Patterns
the goal is to solve customer problems, and building software is how we learned to solve some of them.
how we used to build
the process differed between companies, depending on the industry, the people, the company’s stage, and the system they already had. but it usually looked something like this:
- discovery: understand the problem through interviews, feedback, data, and patterns we’ve seen elsewhere. product managers, designers, and analysts usually lead this, with help from engineering
- planning: decide what to change, how it should work, what result we expect, and how to release it. product, design, and engineering work through the decisions
- building: turn the proposed solution into part of the product. engineers and designers do most of this work
- verification: check that the result meets the requirements, works within the existing system, and addresses the problem. engineering, design, product, and QA each check different parts
- shipping: get it to users and help them use it. this can involve engineering, product, marketing, and customer support
- iteration: use feedback and results to decide whether the solution worked. if it didn’t, return to discovery or planning and try again. product and analytics usually own this, though it often gets skipped
- maintenance: keep the solution useful as the business, users, and system change. this includes code, design, copy, and their relationships with the rest of the product. often left to engineering, though it touches everyone
depending on the team and the system, these steps often happen together. design continues during building, good engineers verify while they build, and sometimes shipping is how we test an idea.
iteration also gets neglected in many teams: they ship something, call it done, and move to the next item without making sure the user’s problem has been solved.
still, this gives us a useful view of the whole process.
most current use of agents in the product development lifecycle focuses on building, and to see why, it helps to remember what building used to involve.
building was one of the hardest and most expensive parts because we had to turn an abstract idea into a change within a living system. it had to solve the problem, work with what was already there, and remain understandable to someone else (or to our future selves).
sometimes we read thousands of lines of code to change twenty. we learned concepts, read documentation, compared approaches, and tried to make sense of why a decision from three years ago still controlled what we could do today.
because building was expensive (and it was usually the bottleneck), we tried to send as little work into it as possible by planning carefully, keeping the scope small, and avoiding mistakes that would require more work later.
in a badly designed system, understanding, implementing, and checking a change could take so long that the requirement changed before the work reached users. a well designed system made the process more successful, but it was still costly.
and because there was always more work waiting, we accepted rough edges, left some problems partly solved, and moved on to the next thing.
what changed
now, a lot of that building work is much easier.
agents can read the documentation, inspect the code, suggest solutions, and implement them. if we can explain the problem and give them enough context, they can work through in minutes decisions that used to take hours of our attention.
they also help with discovery, planning, analysis, and maintenance, but in my experience the improvements in those areas are much smaller compared with building.
which creates a problem: our workflows were built around an expensive step that has become much cheaper.
intentkeeping
now we can build much more. but can we check what we’ve built?
does it do what we intended? did we explain the problem correctly? did we miss something in planning? does the design make sense? can we maintain it? does it break another part of the product?
and, after we ship it to users, does it actually help them?
i call this intentkeeping: continually checking that what we build, ship, and maintain serves its intended purpose; and, questioning that purpose when the evidence no longer supports it. that includes software tests, but also whether we understood each other, made the right design decisions, and carried the company’s priorities through to what users receive.
as agents take on more of the building, intentkeeping should become our main shared activity. humans should own the priorities, make the final judgment, and remain responsible for the result.
the more of our work we can make verifiable, the more of it we can let agents do without constant supervision.
some conditions are clear enough to express in software tests: a calculation must return the correct result, and a user must not be able to access another user’s data. we have tools to check these conditions and make parts of intentkeeping more formal.
other conditions stem from our company’s priorities and strategy. how much speed will we give up for a better design? how much flexibility should a customer have? when is a rough solution good enough, and when does it damage the product?
in my opinion, different companies should answer these questions differently. one competes on speed, another on design, another on distribution, and those differences give customers reasons to choose between them. those differences are what make a market.
the ideal form of intentkeeping checks whether our priorities and strategy survived implementation.
the work after release continues the check. monitoring tells us whether the result holds up in use, while maintenance keeps it working as conditions change. sometimes the evidence tells us to change our priorities.
so intentkeeping is a superset of verification: verification is one step in the list, while intentkeeping runs through the whole process.
why faster building isn’t enough
we can get small, local improvements as each person adds agents to their workflow. engineers can implement faster, designers can explore more ideas, and product managers can work through more proposals, but those gains still have to come together in a product that makes sense.
if we only improve building, unchecked work piles up. we can produce more than our team can check, so either delivery slows down or the company starts shipping work that bypasses intentkeeping.
we get a frankenstein’s monster: features that work on their own but don’t fit together, with different design choices, conflicting behavior, and decisions that pull the product in different directions.
then both our team and our customers have to deal with an incoherent mess stitched together without a clear connection, which no longer reflects our priorities, strategy, or principles.
to achieve exponential improvements, we have to change the conditions around building. in my opinion, this requires two things:
1. improving the environment for agents
the first is to build an environment in which agents can do more work and check more of it themselves. for example:
- reliable, traceable deployments make releases easier to control.
- a design system reduces how many design decisions each change needs; clear boundaries make it easier to understand the effect of a change.
- monitoring and business metrics that agents can easily use let them observe what happens after they implement a change, so they own more than generation.
- skills, rules, and agents with a single responsibility make expectations easier to apply.
- connected internal tools give agents better context and help them work on their tasks for longer without constant direction.
- better test environments help agents work more independently. strongdm’s digital twin universe, for example, uses copies of external service behavior to test integrations and failure cases at a scale that would be difficult against live services, something that wasn’t practical before, because an agent can now build a clone from a third-party service’s docs.
- agents that monitor incidents or repeated user feedback can try to solve the problems they find.
each of these changes moves more work toward a dark factory that can run with little direct supervision.
i think dark factories will fail. differentiation is one of the pillars of every business, and llms, as of now, do not have the best judgment or ability to differentiate a product. this will surely change. in their current state, they are good at making things work, not making them last or making them win. so i believe manual tweaks by humans are still necessary, at least for a while.
the goal is to reduce the manual work intentkeeping requires for each change while making automated checks more useful and reliable, so people can focus on what matters most instead of constantly babysitting and steering agents.
2. rethinking how the team works
the second thing is to completely rethink how the team works.
in the past, we arranged teams so work could flow from discovery through design, building, and release without any one part becoming a bottleneck.
as agents take on more of that work, we need to arrange the team around intentkeeping. people need the context, authority, and tools to judge whether agents are working toward the intended result, help them when they get stuck, and correct their course when they drift away from it.
most discussion around agentic engineering focuses on the first thing: better tools, context, agents, and factories.
the second gets less attention, but our team already holds knowledge about the product, customers, and previous decisions, including things nobody has written down. the team also has ways of thinking and working that can make our business different in our customers’ eyes.
we need to use that knowledge when building the new process, and use agents to help the team achieve much more with it.
someone has to build that environment, decide which rules matter, find what the checks miss, and update them when the business changes, and our team needs time for that work.
if roles, metrics, and delivery pressure stay the same as before agents, the next feature will always beat intentkeeping. we’ll build more software, but not a better business.
part of the team’s work should become making intentkeeping easier across the system. people should define expectations, inspect failures, improve the tools, and decide where human review is still needed.
they also need to decide what kind of work they are asking the agents to do. unless we give them different priorities and quality requirements, they can treat every task as equally important and apply the same standards to all of them. our team needs to be able to change those priorities and standards.
is this an experiment? how much can we spend to learn from it? what can we accept for now? what has to last? which change matters more, and what are we willing to give up for it?
those decisions affect the checks intentkeeping requires and reflect where our company’s priorities and strategy lie. a temporary experiment and a change to the core product should not carry the same expectations.
this doesn’t require changing everything at once; we can move gradually. but a team working well with agents can work very differently from what we’ve learned about effective teams in the past, and that change has to be part of the plan.
what’s the end goal
all of this raises a simpler question: once building gets cheaper, what do we want to do with what we save?
one problem i see is companies treating fewer people as the main goal. i think the smarter strategy is to grow the upside rather than shrink the cost. yes, some roles may disappear and some people may have to leave, but ideally we change the system so our employees can achieve much more and the company can grow with the same team.
there are customer problems we left alone because they were too expensive to address, improvements we never made, and solutions we shipped halfway and never returned to. cheaper building gives us a chance to do that work, while our team’s knowledge helps us decide which problems are worth solving and how to know when we’ve solved them.
to do that, we have to rethink the product development lifecycle as a whole. building more prototypes, improving implementation, or shipping a frankenstein’s monster won’t by themselves achieve the original goal of building a business. we need to understand how people can use agents to make more impact and build the process around helping them do that.
agents can apply many of our rules, check their own work and the work of other agents, and help make our priorities clear enough to act on. people still have to own those priorities and accept responsibility for the result, so the highest level of intentkeeping has to stay with them.
if i build a software factory, i want it to help a team solve more customer problems and keep improving what it has already shipped, with people still responsible for the business they are building. its success should be measured by better outcomes for customers and the business, rather than by how much output it produces.
after all, we’re not in the business of making software. we’re in the business of building a business.