Think about a food truck at lunchtime in any downtown. Two people work inside it. One of them cooks. The other takes orders on a tablet, remembers the regulars' names, and answers messages on the truck's Instagram between customers. Before the lunch rush, one of them bought the ingredients, and one of them renewed the health permit last spring. Between the two of them, they run a whole business: the product, the operations, the marketing, the money and the paperwork. Nobody calls them engineers.
Now picture a second truck parking across the street. It sells the same tacos for a dollar less. Its owners copied the menu in a week, and they could have copied the Instagram account in an afternoon. They can't copy the line of people waiting at the first truck. That line took years to form.
I've been thinking about both trucks since I made a prediction about where software work is going. I think it's right, and the second truck shows where it breaks.
The prediction
Software engineering plus product management produced product engineering. People who write the code also decide what to build and why, and the best product teams stopped handing work across that line a long time ago. With language models and agents, I think the role will consolidate again, into business engineering. A business engineer is a person, or a very small team of smart people, who designs, builds and maintains an entire business. AI does the routine work in every function. They'll build products that compete with today's companies, and they'll start new businesses at the speed we now build products.
The food truck crew is already a two-person business engineering team, for a small business. My claim is that agents will let that same small team run a much bigger one.
Key point: Product engineering merged the people who build with the people who decide what to build. Business engineering adds operations, finance, marketing and support, because agents can now do the routine work in each of them.
Why "engineering" is the right word
Billy Vaughn Koen spent a career asking what engineers actually do. In his 1985 monograph for the American Society for Engineering Education, he defined the engineering method as "the use of engineering heuristics to cause the best change in a poorly understood situation within the available resources." A heuristic, for Koen, is a rule of thumb. It helps, it can't be proven, and it can fail.
That definition describes starting a company better than it describes building a bridge. A founder wants to change something, wants the best change available, understands the situation only partly, and has limited money and time. Koen noticed this himself. He asked what human hasn't been in that position, and he concluded, "To be human is to be an engineer."
Economics points the same way. Ronald Coase argued in 1937 that firms exist because coordinating work inside a company can be cheaper than contracting for every piece of it in the market. A firm grows until coordinating one more task inside costs as much as buying it outside. Agents change that math. They do much of the work that used to take more people. They also make it cheaper to buy the rest from outside. So a company needs fewer people to do the same job, and a tiny team can compete with a much bigger one.
Where the prediction breaks
The prediction has a weak spot. Building gets faster. A business doesn't get faster at the same rate, because much of a business was never about building.
Robin Hogarth split the places where people learn into two kinds. In a kind environment, feedback comes fast and clear, and experience makes you better. In a wicked one, feedback is slow, late or misleading, and experience can teach you the wrong lesson. Daniel Kahneman and Gary Klein reached the same place in 2009 from opposite starting points. Intuition earns trust only where the environment is regular enough to learn and the feedback is quick and clear.
Building a product is usually a kind problem. The code compiles or it doesn't, and the test passes or fails. Users click or they leave. Running a business is a wicked problem. Its feedback comes from customers, markets, regulators and time, and none of those speed up because your build did. You can ship a competitor in a week, but you can't earn a market's trust in a week.
Goldratt explains what happens next. Every system has one constraint, and effort spent anywhere else is waste. (Our bike shop simulator lets you watch a constraint move.) When agents make building cheap, building stops being the constraint, and the constraint moves to whatever doesn't speed up:
- Distribution and attention. Customers have to hear about you, and they are already hearing about everyone else.
- Trust and relationships. People buy from people they know, and knowing takes time.
- Capital, licenses and liability. Banks, regulators and insurers move at their own pace.
- Anything with atoms in it. Trucks, kitchens, warehouses and shipping don't compile.
That is the second truck's mistake. It treated the menu as the moat, when the moat was the line.
Speed versus trust
The contradiction looks like this: agents give you speed, and customers give you trust, and trust takes time you don't have. Quimby's matrix shows four ways to answer it.
Principles of Disruptive Innovation
Every truly disruptive innovation ultimately solves a contradiction.
Every solved contradiction was once an un-solved contradiction.
When you solve a contradiction, express the contradiction that you solved — as a contradiction.
Matrix Morphology framework from David Quimby & Innovation Radiation Associates.
Most of the new speed will go into Q2, the Clone. It's the obvious move, because agents make copying cheap, and it fails for the same reason the second truck fails. Q3, the Old Line, is safe for now, because its customers stay. Its risk comes from Q4.
Q4, the Business Engineer, resolves the contradiction by starting where trust has already been earned. Picture a cook who leaves a popular restaurant to open a truck, and whose regulars walk two blocks to find the new window. The cook brings the line along instead of earning a new one. Agents now let that person build the rest of the business around the line faster than anyone could before.
Key point: The business engineer who wins builds at agent speed and starts inside relationships the team already holds. The human hours go to the slow things, because those are what can't be copied.
Two things the speed hides
Maintenance. The prediction says design, build and maintain, and maintenance is the verb most likely to be dropped. Guru Madhavan, in Wicked Problems, argues that efficiency without maintenance and resilience breaks. Every night the food truck crew cleans the grill and fixes the generator before it fails. A business built in a month by agents still needs someone to notice when a supplier changes terms, a payment integration drifts, or a customer promise quietly stops being kept.
Accountability. Koen also wrote a Rule of Judgment: judge an engineer against the best practice of the time the design was made. That rule assumes there is an engineer to judge. When two people and their agents run payroll, hold customer data and make promises, someone answers for what happens. Law and insurance will decide how fast business engineering becomes an ordinary job, probably more than the tools will.
This has been tried before
Business engineering isn't a new phrase. In the early 1990s, Michael Hammer and James Champy's Reengineering the Corporation set out to redesign companies around their processes. In Switzerland, Hubert Österle's school at St. Gallen taught business engineering as the joint design of strategy, process and information systems. Hammer and Champy themselves offered what they called an "unscientific estimate" that 50 to 70 percent of reengineering efforts fell short of the dramatic results they aimed for.
Those efforts treated the firm as a machine to redesign, and a firm is full of people and habits that don't change on schedule. The difference now is that agents can do the work, not just draw the new process. What hasn't changed is that customers, partners and regulators are still people, and they move at human speed.
What I think happens next
The business engineer is coming, and the direction of the prediction holds. The speed part holds only for the fast parts of a business. The people who do well will build products at software speed and build trust at human speed, and they'll know which part is which.
Go back to the first truck. Its two owners are good at cooking and good at running a small business, but the thing nobody can copy is their judgment about what to change and when. They added a vegetarian taco because the regulars kept asking. They stayed off Saturdays because the downtown empties out.
So the question I'd put to anyone who wants to be a business engineer is this: is the scarce skill building the thing, or choosing which change is worth making? Koen's answer, I think, would be choosing. His Rule of Engineering asks each engineer to do what they think represents best practice at the time they must decide. Everyone will have the agents. The judgment about what's best, and the relationships that make people trust it, are what stay scarce.
The open research question for us at Netrii is what the rules of thumb of business engineering are. Product engineering has decades of them. Business engineering, in Koen's terms, has a very small state of the art, because its feedback is slow. The first people to collect and share those rules of thumb will help everyone else build faster, which is how useful knowledge has always spread.
This post comes from a conversation in the netrii Wisdom Library. Arun Batchu put forward the prediction and tested it against the strongest counterarguments, on 2026-09-18. The engineering-method background is in the Engineering Method session.
