I’ve written a few posts on AI and how it changes the flow of value, looking at it using my Theory of Constraints glasses, you can find them here, if you want:
- What is throughput in our domain
- Theory of constrains in an AI world
- AI as robots - haven’t I been here before?
But I had a few more things that I wanted to get out of my system. The first is the fact that with automation, such as robots, the workers moved up in the value chain. This is happening again now, as AI is being used to do much of the writing, creation and generation.
But are we really moving up in the value chain or is it actually deskilling and we end up baby-sitting an AI robot?
Moving up the stream
When a robot is doing the welding, the worker now is managing the work that the robot does. (Which is what management is. Managing resources and machines - leadership is for humans, sorry I couldn’t resist). Each step up in the value chain, typically means less physical work, more oversight (management) and exception handling etc.
We see the same changes for software developers (for example) where the agent write the code, using our instructions. We then review the code (?) and orchestrate the work, even fleets of agents.
Each step up the ladder means that our influence on the finished output is greater for hours put in, but also that we have less control of details.
Sidebar with a negative spin… read at your own discretion
I’ve always felt sorry for managers. Because the things that bubbles up to them is just about always problems and exceptions for them to handle. And they need to make those decisions with little (or at least less that the person asking) knowledge about the situation on the floor - but they have the over-arching view.
As a developer with AI agents we have all become managers.
Anyways, we have become the tender or guardian of throughput rather than the producer of the throughput. This also means that we stand a risk of becoming the constraint or bottleneck of the flow of value. Make no mistake - the agent can produce much more than any human can specify, review or validate.
Managed in the wrong way the tools lifting can easily pile up a bunch of unfinished work in our processes.
Manufacturing vs development
It should be said that the analogy has some breakage; factories manufactures things. The name of the game is to do as many as possible with as little variation as possible. It’s easy to know what Done is - the lorry is built, the engine works or the knob for the cupboard is done to specification (I played euphonium with a guy that did that for a living…)
Digital Product Development is the opposite. It’s more R&D where we are experimenting to produce one version that helps us to reach another goal. Done is typically harder to agree on? I suggest when a user is using the feature as definition of done, but I know that this will be contested.
Also knowing if something is good or not is harder, in digital product development. Typically we need to let people try it out before we can know if it solved their problem or not. There are many stories about a crappy feature having a big impact and being loved by users, and features we thought would be amazing that no-one uses. I.e. are useless.
This is the reason we do A/B tests and also the reason we want the flow to be fast; to quickly validate our assumption for real, rather than by gut feeling and hunches. Read about the first time I tried A/B testing and the total disregard of the result here
Here’s the kicker. In a factory a bad part is visible — it jams the line, the gauge goes red, you catch it now and cheaply. In digital product development a bad PR can sail straight through looking perfectly fine, then sit quietly in production for weeks before anyone notices the damage. The human isn’t just a bottleneck — they’re a bottleneck guarding a door where the mistakes are invisible and the cost of missing one keeps growing the longer it hides.
That makes the human-as-constraint problem worse in software than in the factory, not merely similar: the reviewer is under more pressure and an escaped defect is more expensive. Which is exactly why flooding that reviewer with ten agents’ worth of output is such a bad trade.
Breaking a machine, on purpose (i.e. by having a process where it happens), is expensive. Breaking a human, on purpose, is inhuman and evil.
Elevation or deskilling
“Moving up in the value chain” sounds like the proper move right. And I think that in many regards it is and will be. Hey - it’s what career promotions is all about, isn’t it?
But in factories, it has historically been deskilling dressed up as elevation;
- lost craft - the welder is now inspecting weldings, but rarely do them
- lost autonomy - your job could become to feed the machine
- slave to the numbers - early management methods optimized the steps in the chain and you were held accountable to the numbers
So for product development - are we heading the same way? Will our craft be lost and we are just shoveling specs into the agent furnace to keep the machine churning out more features?
There are some signals that this is already happening, with AI agents burning developers out faster, we become AI zombies and worries about not using tokens properly.
Let’s leave the gloom, because I think happier times than those bleak scenarios are ahead of us. But it will depend on where in the value chain we involve the humans. If we use the human powers (judgement, validation, deciding what is worth building, in short: taste and integrity) in the real constraint - moving higher up in the value chain will feel like elevation and the promise of productivity gains can be realized.
If we instead move the human constraint to feed the agents faster we are heading to the 1980s deskilling with better tooling.
We should use each capacity for what it is best at and use tools around the capacity to help the work to flow better. The validation and review is hugely alleviated with the help of AI tools, for example. Remember the five focusing steps where we first identify the bottleneck, the utilize it to just do proper bottleneck work. Having a human developer going through the simple parts of code review (linting and coding standard adherence on the top of my head) might not be the best use of the bottleneck resource.
In short
As much of the detailed work is left to automation humans move up in the value chain. This can, and often is, elevation and empowerment of our efforts. But not always, and ensuring that we spend human effort where it makes most impact is essential to ensure a sustainable future work place.
The human taste and integrity paired with the notion that development involves rapid experimentation and a tight feedback loop that creates learning is where the future digital product development will thrive.