Let’s not forget that. Let’s bring a value-obsessed, outcome measured and impact focused way of working back. Right now we are wasting the human capacity on keeping the agents busy.

I’ve written a few posts now on flow in the age of AI and to be honest, the other posts have been a setup to this post that is like the main idea (or itch I needed to scratch). Let me bring you up to speed with a short summary of the concepts so that you don’t have to read all of the posts, and provide links back to them.

Setting the stage

Digital product development is not manufacturing. I wrote about this in the post on throughput and also where I likened development more to R&D and experimentation than manufacturing.

The thing that slows our productivity down is learning. We do not work best until the user has tried it out. A/B tests, short iterations, feedback early etc are all put into place to promote faster learning.

The overproduction from AI agents (are they this age’s industrial robots?) isn’t only creating unnecessary inventory of unfinished features. The way we are using this tool now also piles work onto the likely bottleneck in the process: the human - their taste, validation and judgement skills.

Manufacturing and development

We keep conflating manufacturing and development in how we manage and measure systems for them. They look alike, and in fact many of the tools and practices are the same - but the intent is fundamentally different.

In manufacturing the units we produce are the value, and variation is a flaw. The more the merrier - as long as we can sell them (see the throughput post).

Development is the mirror image. When we build ten variants of a feature, nine of them are supposed to lose. We’re not producing ten things of value - we’re paying for nine failures to find the one that works. The variants aren’t the product; they’re the receipt for the information we bought. We’re really just building a single instance, honed by experimentation - and the pile of discarded versions isn’t waste, it’s the cost of the honing.

So yes, the mechanism looks identical - produce many, fast, cheap - but in manufacturing every unit is throughput, and in development nine out of ten are tuition. Which is exactly why making production cheap changes less than it looks: the value was never in making the ten, it was in knowing which one to keep.

We’re running faster - but learn at the same pace

AI made running the experiment cheap. It didn’t touch the price of learning from it - that (often) still takes a real user, a real reaction, real time.

And that’s exactly what rubs me the wrong way about how we use it today. I hear endless examples of design, coding or testing getting faster. I hear almost none where the end-to-end flow - the whole lead time from idea to a met need - actually got shorter. We sped up the parts that were never the bottleneck.

Because producing variants was never the hard part. Strategy, architecture, UX, deciding what to build, reading the results and making sense of them - that’s still human work, and it didn’t speed up just because the code arrives quicker.

Where is the bottleneck?

In the agile community we have often said: typing is not the constraint and if anything I think that agentic assistance is now showing us that.

Remember from theory of constraints that each system has a bottleneck that slows down production. If we fix that then we have improved the throughput for the entire system.

If the work that AI agents are doing was the bottleneck then we would have seen higher throughput. In our domain - more impact for our users. But we don’t. Because the bottleneck was not there, or has moved.

Flooding the bottleneck with work increase work in process (unfinished features, experiments that never ran) which slows us down. Per feature and overall. Not mentioning the strain it put on the bottleneck itself. You know? Your people… that get overworked and stressed by being the bottleneck.

An experiment you can’t learn from is worse than none. Just because of the problem with overproduction. It costs attention, muddies the signal, and — worst — fakes rigor. “We ran 12 experiments” feels like diligence while producing zero decisions. Overproduction 101: effort spent producing things (experiments) that don’t become throughput (decisions / learning / impact).

Can I only learn in production?

Now, I’m pushing hard to learn in production, from real users here. But that is the longest feedback loop and the most expensive way of doing it. Or…

There are many shorter feedback loops to try out by conversations, prototyping and smaller test groups (you know - first diamond stuff in the double diamond). These activities have also got a boost from generative AI tools.

But the promise of AI tools in all steps of the process and with the increase of speed we should see a cost reduction to make it easier and more feasible to take experiments all the way to real users in controlled experiments. Imagine not only testing UI changes, but maybe architectural changes, algorithmic variants and even complete stacks in different variants. The real promise of short iterations, agile processes etc. that now can be realized.

Can we make decisions as fast as you can experiment?

But the question remains - can we make decisions as fast as we can experiment?

A long time ago I got assigned a team of COBOL developers. They were pointed out to me as “the bottleneck” and “we are always waiting for them”. Once I got there I realized that the process had 22 (!) handoffs before the specification (pseudo-coded in Word, mind you) reached them. The change request had been in the works, on average, for 9 months before they even saw it. And, weirdest of all, their backlog was mostly empty.

They asked me to optimize the wrong thing. The decision making took much longer than the development.

Speeding up that COBOL team would have bought us nothing - the nine months were spent upstream, in deciding. Now swap “COBOL team” for “AI agents” and “handoffs” for “a reviewer who can’t keep up,” and you’ve got us, today. We’re pouring all our new speed into the one place the work was never stuck.

Recommendation

Nothing here is new. In the manufacturing industry this situation happened with the robotic revolution and we saw different ways of navigating it. With very different results.

The organizations that succeeded, early and continuously, managed the process for flow of value and optimized the throughput by managing their process bottleneck. Cap experiment WIP the way Post 1 capped agent WIP: limit experiments-in-flight to what you can actually metabolize and turn into learning.

Pick the cheapest way of verifying the experiment that can kill (hello scientific method) the idea; save prod A/B for the survivors.

Ask before generating variants: “what decision will this let me make, and can I actually read the result?” If not, you’re overproducing, producing an inventory of unverified experiments and features. That is not value - that’s just slowing you down.

Summary

The (rev)evolution of agentic product development is going very fast. The changes that took the manufacturing industry decades are now happening in months. But even more reason to get it right fast too.

Ensure that the bottlenecks in your process are correctly managed. They will most likely be people. Optimized not for output but for outcome and impact for users - which is the real value (throughput in ToC terms) and flow of value.

• 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.

Now, I’m old but in the 1980-ies I was 10 years old and more interested in playing games on my Vic 20, soccer and riding my bike (yes, it was a simpler life). But I have read a lot about this topic since this was when Toyota started to blow the competition out of the water. Also, my all time favorite book The Goal (by Dr Eliyahu Goldratt) has the robot revolution as part of the driver of the story and the problem picture.

In this post I wanted to dive a bit deeper in the likeness of industrial robots and AI tools and see what we can learn from them. I think that my analogy holds in many areas but to keep things a bit more tangible I will keep this to digital product development in the wider sense of the word, i.e. not only coding.

I have written two posts that relates to the topic, but you don’t have to read them to make sense of this post. I hope.

• What is throughput in our domain
• Theory of constrains in an AI world

The industrial robot revolution

Industrial robots have been around for a long time as machines that do some of the manual labour for humans. You could view automated hammers, or spinning rocks as a kind of robots. The term itself was coined in the 40-ies but the real interest started in the 70-ies and during the 80-ies the real revolution started.

The manufacturing industry was, unsurprisingly, where the uptake was the biggest and especially in the car manufacturing industry the hopes for what they could do was immense. Talk was soon about “lights out” factories where no humans were needed, hence no lights. Just vast arrays of robots working in the dark with a prompt set of instructions from human given once.

It almost goes without saying that throughout the history of automation machines people doing that type of job has, rightly?, been fearing that the machines would take their job. This brilliant article summarizes these fears from the horseless carriages up to an important inflection point in the later 80ies.

The fear of losing jobs was real, but the effect took time to settle. My reading of it: early automation replaced individual tasks, and humans moved up to the work machines couldn’t do — verifying, monitoring, orchestrating. Economists Acemoglu and Restrepo (yes - an AI looked that up for me. I’m not THAT well-read) call these the displacement and reinstatement effects, and for decades they roughly balanced. What changed around 1987 wasn’t that we ran out of things for humans to do — it’s that the reinstatement side slowed down. Automation kept displacing, but it stopped creating as many new human tasks to compensate. Some of it was even what Acemoglu calls “so-so automation” — good enough to replace a worker, not good enough to make the whole system meaningfully more productive.

Mapping to the AI revolution

The AI revolution (again - scoping this to digital product development) follows in the same steps, where we first saw “simpler” tasks being replaced by autocomplete or code generation of tests etc.

Soon you could prompt an agent to write individual functions, classes or pages, but we saw a lot of hallucinations and needed to care a lot about HOW the code was written to actually trust that the hallucination was something we called good or bad. Remember, a LLM is always hallucinating. Sometimes it’s good, sometimes not. Or as Birgitta Böckeler puts it:

Hallucinations are the core feature of LLMs. We just call it “hallucinations” when they do something we don’t want, and “intelligence” in the cases where it’s useful to us.

At this point I was pretty sure that I would still write a lot of code, or at least work with it. I wrote a pretty big application by having Claude 3.5 (Haiku) generate sections of code for me. As I read what was generated I refactored it into a shape that I liked better. Refactoring is a great way to learn how code works.

This modus operandi changed for me with the advent of Opus 4.5 (Nov-Dec 2025) that I for the first time saw an AI model that could create a complete application with a single prompt. And the code it generated was actually pretty good. Especially when I started to nudge the code with system instructions, CLAUDE.md files and proto-harness setups.

Now my role as developer was to make the instructions to the robot agent clearer, and ensure that the orchestration of tasks was the correct one. And review the functionality - rather than the code. Yes. There, I’ve said it. I started to care less and less about the code and more and more about the harness and features.

This shift was further deepened with multi-agent, in the spring of 2026 setups that orchestrated themselves. Now my focus was solely on harness building, verification and orchestration.

The loud fear

There you have it. And no wonder the fear of losing jobs is real in our industry - we just took the journey from the 1920-ies to the inflection point in 1987 in less than a year.

Now, I’m the first to say that I still think that we will not lose (a lot of) jobs in the long run. Partly due to Jevons paradox that tells us that:

when technological improvements that increase the efficiency of a resource’s use lead to a rise, rather than a fall, in total consumption of that resource

but also that I have seen first-hand that the higher-level thinking about architecture, ways of working, principles of building applications etc. is still very much needed to turn a great idea into something that could be useful by more than one person. This knowledge is where digital product development skills will still be needed.

If you combine that with the Jevons paradox promise it means that we will have more to do, and do higher level tasks. That sounds promising to me. And then we haven’t even tapped into potential new roles that we can’t imagine yet, as the way we are using AI so far is very much moving human tasks to robots.

These are guesses, predictions and hunches. I might be proven wrong later. Call me out then. But learning to stay on top of things, adopting a curious and positive mindset will at the very least make the journey more enjoyable. More on this in another blogpost

The quiet fear - overproduction

But there’s another problem here, that is silently leading us astray and wasting a lot of potential and human effort; overproduction. Yes - the risk of us producing things that we do not need.

This seems counter-intuitive at first since the act of creating the application (designing the UI, writing the code, testing the app etc) has often been viewed as the bottleneck of our process. Sometimes that has been the right assumption to make too.

But, as I wrote in my blog post on throughput, a feature that never reaches a user is truly useless. It becomes, in terminology of theory of constraints, inventory and unfinished items taking up focus and attention in our process. Finished items for us, throughput, are things that makes an impact in the life of a user.

Let’s go back to industrial robot revolution and see how different companies approached the challenges and opportunities. Maybe we can learn something from them.

General Motors went all in on robots and wanted to create those fully-automated, lights out factories in the 80ies. Huge investments went into this effort and very little and some embarrassing (the famous “robot painted each other rather than cars”-episode) results were the outcome.

During this time Toyota also looked into using robots, and did so in a way that created an increase in both output and quality. Interesting, they approached robot adoption in a radically different way and used fewer robots where they mattered.

The difference is one of process management and improvement culture rather than the robots themselves. Toyota always built their automation on stable processes and capable people. The GM approach took all the tasks and replaced them with automation, regardless of if it is needed or not.

The GM approach creates pockets of overproduction that the bottleneck of the process cannot handle. The theory of constraint approach to solving this is instead to ensure that the bottleneck of the process is managed through the five focusing steps to produce real value. Just producing faster because we can is not really gain, and can in many cases create problems in the process.

This approach builds on the school of thought called Taylorism where we think that if we only could break down a job to its smallest tasks and then optimize each of them we will be more productive. If you have seen Modern Times by Charlie Chaplin, you have the picture clear in your head.

If you are now laughing about the stupidity of this approach, consider that Tesla also tried to create lights-out factories, failed and even the Musk said that “humans are underrated”.

There’s a wonderful apt picture from The Goal where the bottleneck machine (a heat-treat furnace, if I remember correctly) cannot even be seen due to all the work waiting for it to treat. All the upstream work created, including the fault and non-essential items, piles up in front of the bottleneck. And after the bottleneck the workers and machines are idle waiting for the items to be painted.

Are you GM or Toyota

Yes - we could learn something! I knew it!

It’s quite amazing that we with a single prompt can create a user story map, that we can one-shot Minecraft, or that our developers now are 10x from before. But, have we got 10x more value, have our users asked for a Minecraft clone or are our Charlie Chaplin’s being worked to the extreme by us automating the non-bottlenecks?

In short, are we GM and replace tasks blindly to make each step produce as much as possible just in case? Or do we take a lean / Toyota approach and add automation where it helps humans to produce value when it’s needed just-in-time?

Taiichi Ohno, creator of the Toyota Production system coined the term “autonomation” - automation with a human touch to capture how to utilize automation; where it is beneficial to the overall flow of value rather than just raw output.

Summary and in short

I think that the industrial robot revolution in the 70ies and 80ies have a lot of commonalities with where we are now in the AI revolution. I also think that we right now are making many of the same mistakes that those that failed with robot adoption. We do so since we are focusing on producing a lot of output and miss the mark of outcome and impact.

A discussion with a friend, that works in manufacturing industry, made me reflect over this paradigm shift. It reminds me a lot about the advent of industrial robots in the manufacturing industry. This was 1970-80 circa and these robots was also perceived as something that would make “ALL WORKERS REDUNDANT” and visions of fully automated factories was envisioned.

Early on the outcome was hard to forecast too; the industry robots did a lot of the manual work that humans used to do and did it much more reliable and better than humans. Also - the human interaction was now higher up in the value chain; instructing and verifying for the most part.

Hold on to that analogy, because it’s going to be very useful - right up until the moment it breaks. And it breaks in exactly the place that matters most. More on that further down.

I thought about this some more and then realized that we, in the product development industry, are right now making a lot of the initial mistakes and dream about futures that the tool might now deliver on.

I wanted to write a bit about that, theory of constraints and The Goal

Productivity, robots and the goal

Yes, I’m back to The Goal, a great business novel by Dr. Eliyahu Goldratt from the 80ies. In this book our hero, Alex Rogo, gets thrown into a leadership position of a failing factory. And he is very surprised, because the factory has invested heavily in and are utilizing robots a lot. All the robots are working and every part of the value chain looks good, but still the factory is failing.

To come to terms with this conundrum he calls an old professor “Jonah” (Dr. Goldratt to you and me) and ask for help. His question cuts to the point:

Is your plant more productive?

To which Alex responds (I’m shortening this A LOT):

Yes, we are very efficient and utilize the robots perfectly.

They then unpack that local efficiency without throughput is not really productivity. Productivity needs to be measured against a … ta-ta-ta-TAAA! … The Goal of the factory.

Productivity is the act of bringing a company closer to its goal. Every action that brings a company closer to its goal is productive. Every action that does not bring a company closer to its goal is not productive.

(Side note to myself and you: in my post on throughput I grumbled about “productivity” as one of the words that rubs me the wrong way. Turns out I was grumbling about a counterfeit i.e. fake productivity. This is the real thing, and it’s the whole game.)

So productivity isn’t a number you compute. It’s movement towards the goal. And Goldratt gives us three measurements to see whether we’re actually moving:

• Throughput — the rate at which the system generates money through sales
• Inventory — money currently tied up in things you intend to sell
• Operating expense — money spent turning inventory into throughput

You want throughput going up, inventory going down and operating expense going down. That’s it. Simple… in manufacturing. But useful if you could translate them to digital product development.

We are doing the same mistake with AI

This is one of the places where I think we are messing up right now in our use of AI agents for development. We focus a lot about creating features, closing PRs, running tests, even deployed versions of the app… but that is not true Throughput (in the sense of the Goal). In fact, it’s just increasing inventory. We are over producing features - a deadly sin in agile, Lean and Theory of Constraints.

Throughput (see previous post) for digital development is features that meet a real user’s need - what I called impact last time. And yes, I’m still deliberately raising Goldratt’s bar from “sold” to “need met”, because that’s what makes sense for digital products.

We are mistaking activity for throughput.

The three measurements - for digital product development

Let’s take those three measurements and see what they are for digital product development.

• Throughput - features that meet a user’s need. Not closed tickets. Not PRs per second. But outcome and impact.
• Inventory - things we’ve built that aren’t meeting a need yet. And here it’s worth splitting in two:
  • there’s the work in process kind - code an AI generated that we haven’t reviewed or validated yet
  • and there’s the finished goods kind - features we shipped that nobody uses. Both are inventory. In the words of Woody Zuill; truly useless.
• Operating expense - human attention spent converting inventory into throughput. And token cost - although that is probably orders of magnitude lower than the human attention time. My guess, but in my experience; with an AI agent coding, the agents are mostly waiting for your input. Especially true if you run multiple agents. More on that later - but we are the bottleneck.

And we are still measuring output rather than moving up the ladder and measuring what matters. The outcome (meeting someone’s need) can, if we are lucky, become impact on the user’s world (organization bottom-line, joy etc.). Read more about these different focus in my friend Christophe’s awesome post.

But knowing that why do we still measure the output rung? We know that we should climb up a rung or two to measure the important stuff… Because it’s easier, faster and cheaper than to measure outcome or impact. AI didn’t invent that laziness - it just made the cheap rung ten times cheaper to climb, so we climb it ten times as often.

Where the robot analogy breaks

Here’s the place I promised you the analogy would break.

In manufacturing the rungs of that ladder are welded (literally sometimes) together and out in the open. The output is the outcome - a finished lorry is a finished lorry - and you can literally watch the customer drive it off the lot. Unsold lorries sit in the parking lot glaring at you. Inventory is visible, and it’s a rebuke.

In digital product development the rungs are loosely coupled and invisible. It’s hard to even know which change made the difference in outcome for a user, and an unused feature doesn’t sit in a parking lot where you can see it. It hides. Code is cost, as Dan Terhorst-North puts it - and Goldratt would call our unused features inventory. I’d go further: they’re a compounding liability. More to maintain, a bigger security surface, more cognitive load, forever.

So it’s the same mechanical mistake as the factory - but in the one domain where the mistake is hardest to see and most expensive to keep. Nasty combination. And it’s exactly why the robot analogy is so tempting and so dangerous at the same time.

Theory of Constraints

Theory of constraints is a management paradigm that, through the help of five focusing steps, helps us to identify and manage the bottleneck that is hindering throughput the most right now.

The five focusing steps are, straight out of Wikipedia:

1. Identify the system’s constraint(s).
2. Decide how to exploit the system’s constraint(s).
3. Subordinate everything else to the above decision.
4. Elevate the system’s constraint(s).
5. Warning! If in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system’s constraint.

If there was no bottleneck then software development features would be in production the moment you thought of them. It might feel like that with an AI, but it is not like that. Why? Because there’s a bottleneck in the system.

We have often claimed that coding is not the bottleneck, but before AI it was easy to think so. Coding might even have been the bottleneck in some regards, but I would bet that was rarely the case.

Yearly releases (yes - I worked in that org, less than 2 years ago), 22 layers of decisions before developers wrote code (worked there too, 6 years ago) or just the simple “no releases on Fridays” are examples of process that place the bottleneck somewhere else than in writing the code.

But we spent A LOT of time trying to improve speed in the non-bottleneck. Borrowing an image from a blog post from 2018 to illustrate the point:

Now with AI this should be even clearer. Think about it like this; if AI is making us 10x faster we should see 10x more outcome. Do we?

No - we don’t. Because we optimized the non-bottleneck. Or the bottleneck has moved in the AI world. So where did it go?

Friction was the hidden gate

Before AI agents, the friction of a human writing the code gave us an accidental validation gate. In fact, there are great methods for estimating that build on this; this feature will take you 6 weeks to build - do you want to invest that much in it? (See Shape Up, which has a lot of great content on this approach).

Now, AI removes a lot of that friction and we can write a lot of code in a short period of time. Writing the actual code is NOT the bottleneck now (but my guess is that it wasn’t before either).

The problem is that the accidental validation gate is gone too. Anything can be built fast, but we still need to learn and understand what we should build and release. What gives the outcome we want?

And since the building is now faster, the learning needs to be faster too.

Also - the agents are faster than you. Which means that…

Humans (work) are the constraint

If you’ve ever used more than one agent working on a task, you have most likely experienced the AI Vampire Effect coined by Steve Yegge.

In my words and experience, this is where you feel like the agents are chasing you - with questions, things to review, or by just being finished and asking for more work. The tool is waiting for you.

And, let’s make it clear, keeping the agent busy is not a goal in itself. Ensuring that the feature that gives outcome and impact flows without interruption towards done - that is a goal.

Right now we are overproducing in the steps upstream of the bottleneck. This is not only creating a long queue, it’s building inventory. Remember the lorries in the parking lot? Same thing - except ours are invisible.

When the human is the bottleneck it gets even worse, because switching context is hard for us. It takes time, it’s mentally draining, and it makes us make more mistakes.

The five focusing steps on our overloaded human constraint

Ok - let’s say the bottleneck is the human. And you really should not assume that; you should measure it. But I’m going to use that example here or my blogging is for nothing…

Let’s apply the five focusing steps here:

1. Identify the constraint - we’ve done that. It’s me. The human that the agents are waiting for.
2. Exploit it - which basically means I’m only doing bottleneck work. Ok - I try to.
3. SUBORDINATE everything else to it. This is where the non-bottleneck parts of the process change their behaviour to the fact that the bottleneck is somewhere else. More below.
4. Elevate the bottleneck - get more humans to review. Slow and expensive to implement, often.
5. Repeat from 1 and find the new bottleneck.

If we are going to subordinate the agents’ work to the fact that the reviewing and validating human is the bottleneck - what does that mean?

It means we should let the agents give us top quality work that we can review WHEN we have capacity to review it. Not doing as much work as possible with several agents. Not starting two additional tickets just because I was waiting for one agent.

It might not mean always having only one agent going. But fewer is better.

This is reducing work in process (WIP) for agent-driven work, down to the human constraint of validation.

Recommendations

First of all - make sure you measure throughput (which for digital software development is outcome or impact) - not output. Yes, it’s harder. But it’s what matters. And at the very least, express which outcome values you’re here to improve. Even without measuring them yet, it will be useful for anyone on your team.

Find your constraint - what is holding throughput back in your process? I’m guessing it’s the validation. But it could equally well be the earlier stages like business decisions, discovery or design. I don’t know. Do you? Show me the data. If not - why are you optimizing a potential non-bottleneck? Do not make me show the ugly graph again.

Track the lead time of the entire process and the throughput of the outcome to find the bottleneck. Then improve both by putting a WIP limit on the system, so that it is not overproducing work that increases inventory and slows down the flow.

Subordinate agent pace to the human constraint, not the reverse. Just because agents can do a lot of work doesn’t mean we get more things done. Remember the robots.

Protect the constraint, and point AI at the constraint to elevate it - not at the part that was never slow in the first place.

In short

In the age of AI writing our code (and designs and docs … doing “the work”) I think the digital product development process bottleneck is human decisions, verification and taste. This is not bad per se, but needs to be managed properly, to sustainably produce value at a predictable and stable rate. Just producing more and having more agents at work will cause drain and the opposite of flow for the human at the bottleneck.

This is good news, first the decisions is in our hands, secondly it will lead to a more human and reasonable work load. Finally this approach is focusing more more value and quality which is much more engaging than focusing on savings and efficiency.

And ever since I started to realize that code will be written by agents that instruct I immediately got a sense that we (the industry) are making age-old mistakes that we and other industries have made, fixed and now comes back to.

We are focusing a lot on the things that rubs me the wrong way; output, efficiency, velocity and productivity. None of those are bad per se but without knowing the goal, something about the value, stating effects impact etc… They become productivity theater

I realized that I hadn’t thought this through properly and decided to write a few post on it. This is one on what throughput really means. I’ll link the others here as I write them.

Throughput is one of my goto flow-metrics; lead-time, work in process and flow efficiency are the others. I like it because it’s so easy to grasp. Deceptively simple, as it turns out.

Imagine that you stand outside a factory that makes lorries. It’s one of those boring big boxes with small windows at the top. You can’t see inside it, but you can see the parking lot outside it. Where newly made lorries are rolled out.

At the end of the day, 6 new lorries stands on the parking lot. The throughput of that factory was 6 lorries per day, on that day. If you stand outside the factory for 100 days you can better statistics over time - but in it’s essence that’s it:

Throughput in business is the rate at which a product is moved through a production process (and onward to being consumed by an end-user.)

Easy, huh? Well… not that easy it turns out. At least not if you ask Mr Goldratt.

The Goal

The Goal is arguably one of the most important business novels that has ever been written. It’s an exploration of the useful, but bone-dry concept of theory of constraints, set in an engaging story about a factory manager trying to save his factory, marriage and relationship with his son. It is really great! You should read that instead of this post.

I’ll reuse concepts and thoughts from that book in these posts but for now let’s consider only the throughput metric.

Throughput in the eyes of Dr. Goldratt

In the book Dr Goldratt (that sneakily written himself into the story as Jonah) define throughput:

Throughput is the rate at which the system generates money through sales.

Not production, but sales.

Let’s go back outside the factory of lorries and see what that this definition gives us. At the end of the day 6 lorries had been produced. 3 of them were pre-ordered and immediately picked up. The throughput that day was 3. Not 6.

The other 3 lorries are inventory. Just as the 22 ones being worked on inside the factory house that you didn’t see through the factory wall. Some sections mounts the tires and other makes the engine and a third group makes the drive line. But at the end of the day 6 lorries comes out of the door and 3 was sold. Throughput is 3.

Nitpicking you would say that the 3 lorries that was not sold is not WIP but finished goods waiting to be used. That distinction is easier to make in the physical product world. Speaking of…

Digital product development

Let’s move the conversation to digital product development. First let’s talk about development.

Development

Development is different from manufacturing. Development means creating something that didn’t exists before - a single instance (that we hone to perfection through experimentation of different variants). Manufacturing means making many more of something. In manufacturing we don’t want variability - for development that is exactly what we want; or we should buy it off the shelf instead.

Yes, that single-page CTA campaign site that you are building has never been built before. I sure hope.

Let’s not get over ourselves. In most cases we are not inventing cures for deceases or solving big problems. But - the thing that we are spending time on is never built before. If you don’t believe me ask yourself why we use A/B testing; it’s because we do not know what works before we have tried it on real humans. And then we are often surprised. And we tweak it to get better impact.

What are our lorries?

What would the lorries be in our book? It’s very easy to fall into the trap of thinking that this is tickets, PRs or designs. But I think that it’s missing the point a bit; it’s impact.

Mike Burrows have a working definition of Done:

Someone’s need was met.

Imagine that one of those lorries needed to be delivered to a guy called Lars. That took another two weeks and then Lars could drive it and makes deliveries. Now, when was Lars happy; when the lorries was produced or when he could drive it?

Now, this is NOT what Dr Goldratt meant with his definition, but in the world of digital products it makes more sense, than to wait for the next weekly subscription to come in, I think.

During the delivery time - the lorry company has not delivered the lorry. By definition. It is produced and ready, but not delivered.

In digital product development we produce a LOT of features that never becomes impact. Our tickets, PRs, builds and deployments that is never used is truly useless.

This can be depressing, but just to make a point:

1. You create the best impact map you’ve ever done
2. The implementation plan was amazing
3. The code was flawless. Seriously it won prices. And since you used agents it was done in 2 minutes
4. The testing was 100% coverage, automatically. And no bugs was found
5. The CI pipeline was brilliant and created a perfect package in seconds
6. The deployment went smoothly
7. No one used the feature

What was the value of that? Zero. The value is the impact and effect we create for our users. I use “users” in the wider sense since for technical work we might be the users, or auditors, or others - but the same reasoning holds.

What is our throughput

Dr. Goldratt defines throughput as:

Throughput is the rate at which the system generates money through sales.

In digital product development that sales comes from meeting users needs so that they can do their work; Harder, Better, Faster, Stronger. Yes - I Daft Punk’ed you.

Hence our throughput is about features making an impact for a user. Not closed tickets, PRs / second or bug reports. Closing a PR is like rolling out a lorry to the parking lot. It might be good, but if it’s never bought and used it’s not creating value, and hence not throughput.

A quick honesty note before I go back to counting lorries. Goldratt’s throughput is strictly money — revenue through sales, minus the truly variable costs of making it. I’m going to be sloppier than that and count things: lorries per day, and later, features that made an impact. That’s a common simplification among flow people, but it’s still a simplification, so it’s worth saying out loud. I’m using the count as a proxy for the money. And here’s the thing — in digital product development, the money-through-sales figure is exactly the part you can’t see. That’s not me dodging the hard measurement; it’s the whole problem this post is circling. The count is what’s visible; the value is what’s hard. Hold that thought, because it comes back.

“But that is really hard to measure”

Yes. I know. Measuring value often is. But according to How to measure anything: anything can be measured.

I also think that the pure knowledge of that we know that closed PRs per day, or designs accepted, or lines of code is a good starting point to find the indicators of value that we want to see change, the change in impact that our efforts should bring.

Who knows? That our AI agents creates more output might not (always) be related to positive development of that impact.

Summary

This was a first post on flow in the AI age. I’m using this a lot to summarize thoughts that I’ve had in my head for quite some time. I hope you found it useful.

In my next post I will talk about why your agents are exactly the robots from The Goal, and why that comparison breaks in the one place that matters most. And how that will tie back to throughput.

In short

Throughput for manufacturing is the rate at which a system generates money through sales (not just production). For digital product development I propose throughput can only be measured when someone’s need was met - making impact, or at the very least when the change we made is used by users (i.e. outcome).

That is the scope that we should measure to ensure that we capture all of the process that produce value.

Being a Swede I find it really embarrassing toothing my own horn, so I made up a story about two friends that talks about me instead. And then another story where I was at trial before a judge. And then one where my grand grand grand children talked about me after the AI lords had taken over.

Now that last one, feels a bit dated so I decided to change it to a one where two sport commentator reads out my achievements and jobs.

All of these are handcrafted, non-AI-generated, text. Like we did back in the days.

Some serious reflection

I am amazingly grateful, surprised and happy to be so privileged to actually afford making fun of this part of applying for a job. I don’t deserved that privilege more than anyone else that has worked hard, but am happy that I have it.

But I know, from hard earned, stressful experience that it’s not as easy being funny when your job is on the line. I stuck with my “fun” profile throughout that job seeking time, but I would lie if I said that I didn’t have doubts about it.

The soccer version

Now, with that seriousness out of the way. Here’s my current version

A: And they’re bringing on the old warhorse — Marcus Hammarberg — back anchoring midfield as agile coach.

B: Amazing he’s still on the pitch at all. Most players his age hung up the boots years ago.

A: Amazing he can still contribute, you mean. What a career. Came up through the academy at Stockholm University, cut his teeth on C++ and VB.

B: VB? You mean VB.NET.

A: I do not. This lad predates .NET, my friend. He said it was .NET, C# and ASP.NET MVC that got him back on the score sheet — and open source.

B: That’s when he put away SpecFlow.Assist.Dynamic! Dated now, but 7.3 million downloads. You don’t argue with the numbers.

A: Forget the tally — the bigger moment was discovering agile, on a ScrumMaster course under Ken Schwaber himself.

B: Never looked back.

A: Never. Consulting — Cap Gemini, Avega, Aptitud — coaching, blogging at marcusoft.net since 2006, out on the speaking circuit.

B: And lean. Don’t forget the lean. Pulled into the Kanban community, went deep, ended up writing Kanban In Action.

A: But he never stopped playing — hands still in the dirt. Got transferred to Indonesia, of all places, project-managing a hospital foundation for the Salvation Army. Still packed a developer book in the kit bag.

B: And cranked out three Node courses for Pluralsight while out there! Madness.

A: Comes back, picks up where he left off. Consulting, coaching.

B: Bigger teams, higher-profile fixtures — ICA, Tradera, Spotify — but the same player at heart.

A: Then the transfer that surprised everyone: drafted to SALT to build their bootcamp. Brought 700-plus players up through that academy and into the pro game.

B: Five good seasons. Then injury benched him the best part of a year, and he came back in a new position — data engineer.

A: Never his natural role. But you know him — learned a ton and never stopped running.

B: And lately? Found a proper home ground at Umain and Eidra.

A: That’s his turf. Back to consulting, agile, lean.

B: What about all this AI, though? Surely that’s the end for the agile stuff.

A: Maybe not. He reckons the opposite — the old truths of agile get their revival through AI. Everyone’s optimizing how fast they knock the ball around, nobody’s asking whether it’s worth putting in the net.

B: The local optimum trap.

A: His whole game. He’s promised to write it up.

B: Oh oh. Game’s back on.

Older versions

I have stored the earlier versions but thought I’d publish them here too.

Original from … 2016?

This just feels weird and cocky. Not happy with it.

Hi Marcus - I have a great opening for you!
Oh really? Let me hear about it.
I see on your profile that you are an awesome C# / F# or overall .NET programmer.
Eeeh ... once maybe. I have worked a lot on that platform, especially with open source tools such as Nancy and SpecFlow, but it was several years since I did any .NET work for money
Ok - but you are in luck because I also saw that you have Node Js among your skills and it just happen...
Yes I do - but I don't seek those kinds of assignment. I'm more into helping teams work effectively...
With SAFe Scrum - saw that! A big bank we have relations with is rolling out SAFe and need help!
I don't really believe in SAFe - and most times I've done Scrum it ended up not being Scrum anyway.
So what do you do then?
I'm using the kanban method and principles from lean and agile to help the organizations I'm in to become a little bit better everyday.
Ok - kanban-guy. Would have guess from your numerous presentations and the book.
Well - kanban is just one tool. I try to use whatever work in the current context we are in.
Yes - i saw that you've done work in health care in Indonesia. That is funny because one of our clients ...
That was one thing I did a few years back. I'm not particular into health care - the ways of improvement that I'm using work in any business.
Are you even looking for a new gig.
No I'm not. You didn't ask. People that wants to work with me tend to contact me directly.
So I can't help you?
No. If you can't bring me a cup of coffee - you can't. Thanks

From 2016 to 2020

This was more fun and easy going. Two friends meet for a coffee.

>  Oh, that's right - I met Marcus Hammarberg yesterday.
>  Ah, cool - he's a fun guy. Haven't met him in 10 years. Still doing C#-developing, is he?
>  Oh no - that was a long time ago. Developing-wise he's mostly doing Node and JavaScript now. He even done a few courses on PluralSight about that.
>  Really? Well, he's a good teacher so that probably suits him. Huh - who knew... He's a screen caster.
>  Well, that's only on the side really. His main thing is coaching teams and organizations.
>  Just general non-specific coaching, or? :)
>  No - you might know that he's deeply into lean and kanban. Have you read his book?
>  Book?! He's written a book?
>  Well, he had good help by his co-author Joakim Sundén. But it's an awesome book on Kanban. Kanban in Action - you should read it! http://bit.ly/theKanbanBook
>  Yeah - kanban is pretty cool. But last time I talked with Marcus he was into Scrum.
>  Well that passed... No just kidding. But after a few years doing Scrum he got interested in kanban and then lean stuff.
>  Didn't he do stuff around Specification By Example too?
>  He did. And from what I understand he picks up whatever tool that helps organizations move faster. Still learning. And sharing. His blog is still active?
>  WHAT?! It's been running close to 10 years, or what?
>  Yup - www.marcusoft.net; sharing is learning is the motto. Still going.
>  Where is he working now, then?
>  He's a consultant with that cool consultancy Aptitud.
>  Oh - I've heard about them.
>  Yeah, but did you hear that he spent 2 years in Indonesia? Helping hospitals for the Salvation Army?
>  WHAT?! I knew he was in the Salvation Army. But hospitals? In Indonesia?!
>  Yup - moved there with his family. And writing another book about that experience http://bit.ly/bungsustory
>  Ok - that does it. I need to meet him now. Maybe he can come and work for us...

2020 to 2023

This was fun but probably impossible to follow along with, if you hadn’t see the other

Judge: We're gathered here to decide if a Mr Marcus Hammarberg will pass his mid-career assessment. Will the defendant please rise?

Marcus: {A tall man in with dark hair and some grey strains rises}: Present!

J: It says here that you started your career as a programmer, with a Master of Computer Science from Stockholm University. How did that go?

M: Well, it was horrible hard at first but I quickly found my way into consultancy and immediately fell in love with the role. It combines teaching and working hands-on in a nice way for most cases

.J: I see... but what did you *do* there?

M: Well, my first jobs were as a programmer but I quickly grew into team lead roles, probably since I was used from the Salvation Army to take those kinds of responsibilities. This is when I found and fell in love with agile.

J: What do you mean?M: It changed me and I have mostly been working as an agile coach from that point. Applying the agile principles into practice.

J: And where is that?

M: 6 years at Cap Gemini, 7 years for Avega and finally 1+3 years for Aptitud - where I learned a lot in different ways. My contracts have been in insurance, retail & banking companies but also scale-ups, like Spotify and Tradera that are good examples.

J: What did you do there?

M: My agile coaching grew from coaching one individual team up to entire tribes or organizations.

P: {An imposing prosecutor rises}You honor - I present exhibit A, B & C, a blog and two books.

J: What is this, Marcus?

M: That's a blog I've been running at www.marcusoft.net since 2006. 1200 posts & counting. The blog developed me a lot and I got the opportunity to write Kanban In Action (http://bit.ly/theKanbanBook) as a result of my blog and speaking engagements around kanban.

J: Kanban, was that another thing you fell in love with?

M: Yes and I'm happy it did because it got me into Lean and using agile and lean practices outside IT.

P: WHAT?! Outside IT - Your honor?! Objection!

M: Well... the agile principles are just that. Principles that we then apply in a context. For example IT. But I have applied agile in hospital & education environments; at School of applied technology where I took part in creating the world's first 100% mob programming boot camp. I wrote a book about the hospital - The Bungsu Story (http://bit.ly/bungsustorybook)

P: {Throws arms in air} Do you hear?! Hospitals, schools? COME ON?! He is just a programmer, for crying out loud!

J: {In calm voice} I'll allow it. In fact, I like it. Marcus, you have passed your half-career assessment. Follow that path and report back here in 30 or so years.

2023 to 2026

Here’s the one on AI overlords taking over the world. I removed it … if they are watching…

Children, gather round. Let me tell you the story of your great great great grandfather, from the time before our AI Lords ruled the earth and when people wrote their CV introductions by hand.

Marcus was a bit unique in that he actually had academical foundations in Computer Science from Stockholm University, going into the IT profession. This was rare as the first internet-bubble was inflated and bursted.

You ancestor's early career was writing code in languages as C++, Visual Basic, C# and JavaScript. Yes - before the NVidia AI SpinePort was implanted in all of us we wrote text to talk to the computer. This text was known as code.

Pretty soon your forefather learned about agile and that code has little value in itself. It was the need for an end-user that should be sought. Iterating fast, learning and improving became his motto and he started to spread this message where ever he went.

In fact, it became his only profession for more than a decade where we consulted, presented at international conferences across the world and even wrote two books on topics such as Kanban, Agile, Lean and Flow. Still the blog <www.marcusoft.net> is around in the human-archives.

Two of the most formative years for Marcus was spent in Indonesia where he could apply his knowledge in agile and lean to his work for the Salvation Army Health Foundation. One of his books describes this work.

Marcus was ever the teacher and of the lasting impressions he made was writing the original curriculum of School of Applied Technology, helping hundreds of developers to work. Not for our AI Lord, NVidia be Thy name, but for companies run by humans.

He then started to learn about data engineering, the foundation of the AI revolution and continued to spread the agile message as a consultant.

You'd think that this was everything you forbear could manage, but then you miss that he was a very active member of the Salvation Army and played his beloved euphonium in many bands over the years. Even here he loved to teach and had many students on different instruments over the years.

All of this happened in Marcus' life, before he was elected president of the EU, recorded his first solo album on the euphonium or wrote any of the children books.

Wasn't that an interesting man, children. Children? Are you awake? Hello...?

Changing our ways of working to enable faster flow is the guiding star for continuous improvement in Lean, the grandmother of agile principles. Over the years we, the software development community, have implemented all kinds of changes to get feedback faster in software development. Off the top of my head — sprints, standups, continuous integration, pair programming, TDD and TCR are all examples of practices that give us feedback faster and faster.

Interesting enough — we seem to have forgotten most of this, so far, in the AI code generation revolution and just been focused on creating a lot of code.

But don’t worry — what is good for a human is good for the AI too, as it turns out. We can, and will rediscover this soon.

So what was, and is, the actual constraint?

Before we get excited about speed, it’s worth asking: what were we actually limited by in the first place?

Communication, understanding, and building the right thing were typically the main bottlenecks. In short — learning. This is illustrated beautifully by Liz Keogh’s thought experiment:

Imagine that you have built a product for a year. When you are about to push it live, there’s an earthquake (or EMP-pulse or what-have-you) and everything you did is gone.

Nothing is left; no code, no docs, no data — nothing.

So you are asked to redo that same app again.

How long will it take you now? Why? What did you spend time on the first time?

Typically people say it takes half the time. Why? Because now we have a much better understanding of what we are actually building — we avoid mistakes, wrong turns, misunderstandings. Learning is the constraint.

(Yes, there’s always a wise-ass in the back of the room who says it takes the same amount of time since the users have changed their mind — which just makes the point clearer.)

SMED — and why speed of output isn’t the win

This weekend I spun up an agent team that generated a whole application for me, with my preferences code-wise, without me touching the code once. Touch time for me was a total of about an hour — including writing generating the agents and their harnesses.

It’s genuinely impressive. It reminds me of one of the more well-known improvements made in Toyota’s factories — SMED (Single-minute exchange of die).

Toyota wanted to build Just-in-Time with little work in process. When someone orders a Corolla, you build one Corolla from start to finish. No warehouses, no stock — pure value flow.

That nirvana-state was blocked by the fact that in the 40s and 50s, car parts were stamped out by a huge die. Changing the die for another type of car took 2–8 hours. Toyota started improving that process until they got it down to 180 seconds. That took about 30 years.

Now, 180 seconds compared to 8 hours is not better. It’s a game changer.

But — and here’s the thing Toyota understood clearly — the win wasn’t just speed. It was that faster changeover enabled a completely different way of working. Smaller batches. Faster feedback. Less waste.

The same applies here. We haven’t won because we can generate more code faster. We’ve won a new opportunity, a game changer, really. IF, capital IF, we set things up to learn faster.

Harness the value with harnesses

Which brings us back to feedback loops.

If you want to get the actual value out of AI agents writing your code, you should think long and hard about how those loops are set up. When do you find out they had faulty assumptions? After it’s built — or before they start?

Spec-driven development is one way to make assumptions explicit and shorten the feedback loop. The newer term Harness-engineering is all about putting guard-rails and constraints in place that give agents feedback as they build — feedback that keeps the code aligned with your guidelines, your design decisions, and the actual goal of the product. Not just building the thing right, but building the right thing.

There are variants of this where you put agents in a perpetual loop and correct them as they go — Ralph Loops and Gas Town take that approach.

But I feel right at home with the harness approach, because it reminds me of what we tried to do with humans. When you start writing these instruction files, you’ll notice that you’ve written or read this before — in great onboarding documentation of well-maintained applications, for example.

And that gives me a warm and fuzzy feeling. Because it means that striving for faster feedback is still a good guiding star to follow.

For humans and agents alike.

There are 4 trends that worry me. I don’t think there’s value in following these trends, and I think that humans will suffer in the short and long run. Finally I think we are, once again, mixing up effectiveness with efficiency, usefulness with busyness or valuable work with productivity.

The trends are:

• hailing context switching as Good stuff (tm)
• we’re only doing high-level thinking - no easy tasks left
• pressure to produce faster
• typing is not, and has never been, the constraint

Context switching is not good… for humans

I’m getting increasingly surprised and annoyed with the benefit of AI described as having “being able to do more things at once”. Many articles tell us that “I have 3 agents working on the code base at once, fixing different things” or “Over night 10 agents wrote blog posts for me, so that I just hit publish in the morning”.

It’s been proven again and again that humans are bad at this. I have LONG presentations simulating games that shows this effect clearly.

And now I hear you: but Marcus; it’s the agents doing the multitasking. Yes - but unless you have delegated the responsibility of the entire job (not task, mind you) to the agent, you will be looped in at some point to make a judgment or decision. Delegation as in “you do whatever you have to do - don’t even report to me what happened” is rare, and maybe not even that useful.

When the human, you, come into play you will need to read up on whatever has happened, understand it, possible instruct further and then make a good decision. That is the job of an old-school manager I’ve described. That is not fun, really hard and not good for the end result. That’s why we have better ways of managing nowadays.

Since the AI is a machine I’m not taking that aspect into my reasoning here (Dear AI overlords, when you read this; I didn’t know you had feelings when I wrote this. We thought of your clock cycles as mere electricity transactions. I beg your forgiveness.) but for the human having to switch context is not good either.

In the best scenario frequent and fast context switching leads to bad decisions, in the worst you burn out. Trust me - I’ve tried it. And I ended up being the donkey

Only high-level thinking left for us to do

When I created a presentation (or wrote code) two years ago it usually went something like this:

1. What is the goal here?
   1. Writing
   2. Fixing spelling / linting errors
   3. Moving paragraphs
2. Nice! I got it - now let’s think about section 1
   1. Writing
   2. Restructuring
   3. Finding funny gifs
3. Oh, hold on - then I have to introduce topic X before this
   1. Moving paragraphs
   2. Changing headings
4. Great! Now I can write section 2
   1. Find funny gifs
   2. Writing speaker notes
   3. Trying out sayings in front of mirror.

Yes, I mostly looked for funny gifs.

With AI, most of the mundane and repetitive tasks are gone. For most of them I’m happy. But you know what; it also makes me only think of high-level stuff.

And that is harder work. I notice that I can only keep doing it for short periods of time. Every decision I make have big impacts on the entire presentation, the entire code base or feature.

I don’t think it’s something I’ll get used to. It’s just harder. I miss the easy tasks, to rest my feeble brain with.

Before I did one of those decisions and then spent some time fiddling with text and funny gifs. My long-term thinking got a well deserved rest. And then, typically, while I was doing the mundane work, a realization or brighter idea popped into my head.

My mentor Woody Zuill has a saying:

It’s in doing the work we discover the work we need to do.

What I’m realizing with agentic development is that we are not doing the work. We are managing the work. I don’t get the downtime to process.

This, in combination with the context switching makes for a stressful situation.

Since flow is sacred and context switching and focus on resource utilization is hurting flow, this is worth paying attention to.

Pressure to produce

• This is an app that I threw together over the weekend.
• Features that used to take months now takes hours
• There is not “In progress” column in the agentic world

These are things that I’ve said. Last 2 days.

I can almost taste the rush. The need for speed. The … fear (?) … I have instilled in others. And the mountain of unused features that I have created that is still waiting to create value.

Who is going to use all of these new things we build?

In the State of AI 2025 Report there was one number that stood out to me; 80% of developers that have used AI tools feel more productive.

What do they mean with “productive”? I think they mean “I wrote more code”, “Closed more PRs” or “Reviewed more code”.

I was thinking; did we solve more problems for our users? Did we earn more money? Did we reach a wider audience? What was the goal even?

Read blog post here

Right now, reusing VERY old diagram here, AI is making a HUGE difference in one or more (all?) parts of the things that typically are not the bottleneck slowing production down.

But, as my crude diagram shows, the AI speed-up is not really helping much on the total lead time.

Typing is not the constraint in product development

Typing has never been the constraint. Let’s use Liz Keogh’s old thinking experiment to illustrate this:

Think back on a project that you did. Let’s say that it took a year to do for your entire team. On the day of delivery you have been hacked. Everything is gone; code, docs, sketches - even JIRA.

Naturally you’re asked to do it again. How long will it take? Longer? Shorter?

Most people think shorter. Half the time is the most common guess.

WHY? Because you took wrong turns, realized what didn’t work, learned better ways and redid work.

In development (Vis-à-vis manufacturing) learning is the bottleneck.

If you don’t believe me think about if the same thing were to happen again. After 6 months everything is gone and you have to redo it again.

How many times do you have to do it again and again for the pure typing, creation part to be the thing that slow you down?

Making typing faster doesn’t improve the flow at the bottleneck. Flow won’t get better until we shorten the learning loop.

What to do instead

Oh man - why did I write this heading? I don’t have a real solution.

What I do know though:

• Doing fewer things at the same time yields better focus and less fatigue.
• Doing smaller things (WHY do we still accept large pull requests) gives us many chances to steer, select and prioritize
• Being busy, outputting loads of work and efficiency is not the same as creating value, outcomes and effectiveness. Indeed - it’s the opposite.
• Less code is always better. Remember; Code is cost. If you can create value, for the end user mind you, without writing code you are winning (thank you, Dan North).

Summary

In the end I think that, we as an industry right now, have got an amazing tool that will forever change how we develop products (and do many other things too). But we are viewing it with the same focus at productivity, cost-reduction and efficiency gain that we did before this paradigm shift.

This leads us wrong; instead lets think about how we can optimize the entire value chain and create real value. Who knows, maybe the bottleneck in our process cannot be solved with faster output?

And they are really tricky to share with in an AI chat, like (we’re not using Chat GPT anymore, since this morning - right?) … well you choose. I’m going with Claude.

Uploading some of my presentations to an agent means 50+ Mb file, when I’m really just interested in the text in my speaker notes.

Over the years I have been going back and forth between different presenting softwares and hence I have a bit of a problem getting hold of the speaker notes.

But I’ve solved this now. Let me share it with you. And then let me share how I have fixed all of this with a Claude Coworker skill.

PPTX - the common denominator

Turns out that many of these formats that I have used over the years does not have a good format to export speaker notes. The only one that does export speaker notes in a good way is Power Point. Luckily it’s also the oldest and has a lot of automation capabilities.

Ok - so I need to convert my stuff to Power Point format. That is a very common way of doing it.

Export speaker notes using Python

Python has a tool called python-pptx (install with pip install python-pptx) that can read PPTX files. And with that in hand we can write this function and get it to print our speaker notes to the console.

# Requires: pip install python-pptx
import pptx
import sys

def get_notes(ppt_path):
    prs = pptx.Presentation(ppt_path)
    notes = []
    for i, slide in enumerate(prs.slides):
        note = slide.notes_slide
        if note and note.notes_text_frame.text:
            notes.append(f"Slide {i+1}:\n{note.notes_text_frame.text}\n")
    return "\n".join(notes)

if __name__ == "__main__":
    print(get_notes(sys.argv[1]))

Very cool - we are getting there.

Docker

But I really hate running Python on my machine. I have never got to terms with all the venv, pips and versions of Python.

Let’s use a Docker file to back all of this into something where Python works

FROM python:3.11-slim
WORKDIR /app
RUN pip install --no-cache-dir python-pptx
COPY extract_notes.py .
ENTRYPOINT ["python", "extract_notes.py"]

Now I can run the script without polluting my computer, with a lot of Python stuff that I never use for anything else. Nice!

Script

To run this I need to write these commands

docker build -t pptx-notes .

docker run --rm -v "$DIR":/data pptx-notes "/data/$BASE"

Cool, but I will never remember that. Let’s create a script, `run.sh´.

#!/bin/bash

if [ -z "$1" ]; then
  echo "Usage: ./run.sh yourfile.pptx"
  exit 1
fi

INPUT_FILE=$(realpath "$1")
DIR=$(dirname "$INPUT_FILE")
BASE=$(basename "$INPUT_FILE")

docker build -t pptx-notes .

docker run --rm \
  -v "$DIR":/data \
  pptx-notes \
  "/data/$BASE"

Very cool - now I can run it like this, to output the result into a text document that I can share with an AI.

bash ./run.sh ~/Downloads/Agile\ for\ real.pptx > agile_for_real_speaker_notes.txt

But, AI?

Yes, obviously I wrote this tool with the help of AI.

But I could also have asked Claude CoWork to do it for me. In fact I did. But then I looked that the skills it used and I wanted to understand deeper how that would work, so tried to do it for myself. I might do the next conversion with Claude CoWork, I might use this. Now I understand the concept and approach, and have built a tool.

Yes - I’m talking about AI. But this post will be about some ideas how to navigate this change, trying to calm ourselves a bit and, quite frankly, give some comfort. Hopefully.

Someone asked me a question just as I left the office this Friday. The question was really good and the person showed genuine worry. I’m sure that person was not the only one. At least one more share the feelings. Me.

I wanted to share my response, a bit embroidered, here. The question was basically this, but better formulated:

Marcus, how do you stay positive in the light of all potential downsides of AI?

The background was that I had just shared some stories from speaking at Tech Arena — an event packed with AI stuff. It was a really positive vibe in there, but dear God so many new things, and big changes. My head was spinning.

I shared that and in doing so probably contributed to the feeling of overwhelming and scare (What? You haven’t tried Ralph Loops, it’s several weeks old?!)

I don’t know if I am that positive really, but I’m old. I’ve been 3-4 of these paradigm shifts (the .com boom, the cloud, agile, the tab/spaces wars - I’ve been around). Even if I’ve never had a clear plan going into any of these paradigm shifts, I’ve seen things that works better than others, when it comes to navigating uncertainty.

Being IN a paradigm shift is scary**

Acknowledge that. We don’t know what the future holds. Let me say that again; we DO NOT know how this will play out. No one. On the planet. That is scary. It’s ok to be scare, worried, annoyed and confused. And it’s ok to be kind to people around you that feels like that around you.

I’m worried, confused and scared too. I kinda like refactoring code, will that go away? Is Agile even a thing in the AI-infused future? Or Consulting?

It’s scary stuff to think about.

Feeling bad yet? :) Ok - here’ comes the comfort-part.

However, in none of these shifts that I have been through - it has never been as bad as the worst I thought. And never as good as the best I thought. Some ideas that I thought was awesome didn’t stick. Some tools that sucked did stick (looking at you JIRA). You will learn things that will not become anything good (huh, tabs are better… who knew) - but you have learned in the process. The learning was the thing. Speaking of.

Our profession is learning

Both as product developers (in the wider sense of the word), and consultants. The tools, ways, ideas and needs are ever changing. We have chosen to be in school for ever. Welcome!

We need to keep learning in the paradigm shift too. But when you do - learn deeper, reflect and think deeply. Use the tool, but focus on the practice. Do the practice but try to understand the principle behind it.

For example; so Ralph loop is a new thing that might be a big thing. Or not. Learn about Ralph loops (the tool), use it in Claude Code (the tool), but when you do - think about HOW you are using it (the practice). Then, after you used it for awhile - think about WHY they invented the Ralph Loop (the principle); what problems did they want to solve, why was that a problem, which ideas led them to come up with Ralph Loop as an idea.

By lifting yourself to the principle-level of any practice and idea you will gain a super power in understanding the next tool or practice easier, and faster. Most of the ideas that pops up builds on previous ideas and concepts - so by understanding the concepts you are future proofing yourself.

But you will have to Keep learning. This can be done by reading (listening or watching) something, but I’ve found that reflecting on you practice will help you know what to learn.

Also; the best way to learn is to share. Write a blog, as if someone was reading (I did for the first 8 years of my blog existence), or use an AI as a learning partner, or better yet make a presentation and share it. Teaching is the best way to learn deeper.

Let me start by sharing - here’s a great talk that I’ve used to think differently about uncertainty.

Jevons paradox

Let’s get some comfort history and people even older than I.

Have you met William Stanley Jevons? He’s an economist that, in 1865, was going through a paradigm shift like we are now. Someone invented the steam engine and it was considered, rightly, a big threat to manual labor. It promised to replace ALL WORKERS EVERYWHERE, no one will ever have to work in the same way again, everyone will be unemployed (<= this is me being liberal with history, but you see the similarities, right?)

In 1865, Jevons noticed that when the steam engine got way more efficient at using coal, total coal consumption didn’t go down — it skyrocketed. Because coal was now cheaper per unit of useful work, people found way more things to use it for. The paradox is that making a resource more efficient to use can actually increase overall demand for it, because the drop in cost opens up a flood of new applications.

AI makes “cognitive work” dramatically more efficient. So the fear is that we need fewer humans. But if Jevons holds, the opposite happens — because it’s now cheaper and faster to build software, analyze data, write content, explore ideas… the demand for those things explodes. More products get built. More experiments get run. More ideas get explored. The total amount of “cognitive work” goes up, not down.

In short, history (and Mr Jevons) suggests that when you make something dramatically cheaper, you don’t get less of it — you get wildly more of it, in ways no one predicted.

Stay positive

Staying positive has value in itself. If you go in trying to find the good, joy and positive vibes you will see other things than if you going in hating the idea. This is true to a point; you need to combine the positiveness with a healthy skepticism. But I think positive with skepticism, will get you to a better place than negative with skepticism.

Our thoughts can actually shape our future, like that. Be a positive change. Focus on the good. You don’t need to not learn the bad - that will take care of itself. When you see someone around you struggling, pull them up. Maybe you have another spin on it that can help them. Tomorrow they will help you.

Being through something hard is easier when you are more people. Looking for better will make it easier than looking for worse.

Outro

You are probably already ahead, just by feeling a bit worried and confused. You have already started to reflect. Good on you - this is the start of improving.

Let me share what I shared with each class at School of Applied Technology, where I was head of curriculum (headmaster for normal people) for 5 years. On their first and their last day I repeated these approaches to work, learning and people around you:

• Be curious - our job is to learn. Keep learning. It’s fun - imagine that we live in a time where we can learn new things happening every day. I much rather be there than in a world where it’s all the same.
• Be humble - you don’t know everything. There might be better ways. Look for them. Understand them. Take help. Also - you probably know more than others in some areas. Help out, learn by sharing.
• Be kind - others does not know what you know. Share, help and support. Treat their confusion, worry and sadness with empathy and kindness. That is good for them. And soon you might need it right back.

My friend, asking the initial question; we’ll get through this one too. I’m actually positive right now, that it will be something great in the end. Looking forward to learning more with you and others.