What Does Productivity Mean in Agentic Coding?
One of the topics I see all the time around AI and agentic coding is the promise of improving "productivity."
I often wonder how many people actually know what productivity is.
What is productivity?
A simple definition is: "Productivity is a ratio that measures how much we produce relative to the resources used to achieve it."
It is usually associated with goods and services produced.
The input is the resource: labour, material, technology, money, etc.
The output is the result: a product, a service, a document, a feature, etc.
output
productivity = --------
input
To produce a chair, for example, you need materials and labour.
If we can optimize a process to produce the same chair faster, using less labour time, the overall cost of the chair will decrease while the resulting chair remains the same.
So, if we produce the same result with fewer resources, we can say that productivity increased.
Resources also mean cost.
If the process time remains the same, but we spend less money on raw materials, we can also say we had a productivity increase.
However, if we buy cheaper material and pay less for labour to get a lower-quality chair, can we really say that productivity increased?
Here is where this definition starts to get tricky.
If we are only considering that we need chairs, then yes, productivity has increased.
But we will likely sell this new chair for less. To keep the same revenue, we may need to produce more chairs to compensate for the lower value. That means more sales effort, more accounting, more inventory space, and more work in other areas.
So individually, it may look like we increased productivity.
For the factory as a whole?
Maybe not.
Busy is not the same as more productive
The chair example is very simple to understand. We may produce more chairs at a lower cost and lower sales price, but that doesn't mean we increased the value generated by the business.
A large factory producing 1,000 chairs per month may look busy, but it may generate the same revenue as another factory producing 100 higher-quality chairs at a higher price.
What really matters in the end is value.
I prefer redefining productivity as:
value
productivity = --------
effort
A history lesson
Let me take a break to revisit one of my favorite lessons from when I was studying Production and Systems Engineering, around 2012.
You've likely heard about Lean Manufacturing before. It's not a type of manufacturing, but a way of thinking. It's a set of principles and tools focused on creating value while reducing waste.
Let's go back to Japan just after World War II.
The country was recovering from the war, and Toyota was trying to compete with much larger and more productive American automakers. Resources were limited, cash was limited, and keeping large amounts of inventory sitting inside a factory was expensive.
The challenge was not only how to build cars faster.
It was how to do more with the resources they had.
Think about everything involved in building a car. A modern car contains tens of thousands of parts. Every component sitting in inventory represents money that has already been spent, or will need to be paid to a supplier, while the final car still hasn't been sold.
Now imagine parts sitting in a warehouse for weeks before they're needed. Then the car waits between production processes. Then the finished car waits to be sold.
There is money tied up throughout the entire process.
So the reasoning becomes interesting.
What if we focus on the activities that are actually adding value to the car and reduce everything else?
Less inventory. Less waiting. Less movement. Shorter production time.
The faster material can move through the process and become a finished product, the less cash is tied up along the way. At the same time, reducing waste helps Toyota produce more efficiently and compete with manufacturers operating at a much larger scale.
One of the principles that became fundamental to the Toyota Production System is called Just-In-Time (JIT).
The basic idea is simple:
Make only what is needed, when it is needed, and in the amount needed.
Instead of holding large amounts of every component in stock, production and material deliveries are synchronized much more closely with actual demand.
Inventory goes down.
Lead time gets shorter.
Less money stays trapped in material waiting to be processed.
Imagine the impact on cash flow!
But now we have another problem.
How do we know where the waste is?
This brings me to my favorite Lean tool: Value Stream Mapping (VSM).
A Value Stream Map helps us analyze the flow of a process and see where time is actually being spent.
A car may take 36 hours from start to finish. But that doesn't mean people are actively working on it for 36 hours.
There are times when the car needs to move between processes, wait for material, or simply wait for its turn to be processed. Maybe only 10 of those 36 hours are actually spent processing the car, while the other 26 hours are spent waiting.
That's the part of Lean Manufacturing I want to bring back to our discussion about software development.
What really matters is how much of our effort is creating value.
Software Development Value
Coding is a bit different from producing a chair or a car. A feature is usually not sold individually, but as part of a larger product or service.
Measuring some of the inputs is easy:
- Infrastructure costs
- Software developer salaries
- Subscriptions, including cloud AI providers
But how can we measure value, and consequently productivity?
First, let's define what should not be used alone as a productivity measure:
- Lines of code
- Quantity of pull requests
- Number of features
- Number of projects
None of these measures necessarily represents value.
We can have 1,000 lines of low-quality code, built through 10 pull requests, toward a feature that customers don't need.
On the other hand, we could have 20 lines of code, built in a single pull request, that add a button customers love.
The tricky part is that value in software is subjective.
A missing feature, a layout change, or a new competitor may cause customer churn. Meanwhile, a small refactor that has nothing directly to do with the customer can improve the onboarding process of your next developer.
An infrastructure change or a change in design patterns can drastically reduce costs while scaling the business.
Does that mean the DevOps engineer or System Architect is more productive than the developer building the frontend?
Absolutely not.
They both create value, but that value is measured differently.
What is coding productivity?
We can compare software with a phone or internet provider.
These are services customers expect to be continuously available.
A chair can be manufactured on demand. A car may follow a production line where a new car is completed every minute.
But if you lose your internet connection for a minute, especially in the middle of something important, that minute feels like an eternity.
We don't see most of the work happening behind these services, but internet and phone providers are constantly maintaining and expanding their networks and equipment.
Does building a newer tower with 5% less steel and better access for maintenance immediately increase the value of the service to the customer?
Not directly.
But it can reduce costs, improve maintainability, or make future expansion easier. That still creates value for the business.
The same happens with software.
We need to keep applications available while improving performance, distribution, security, reliability, and scalability.
Some of that work creates value customers can see immediately. Some creates value indirectly. Some are simply necessary to keep the system working.
So, if lines of code, pull requests, features, and even development time don't tell us enough by themselves, how can we measure software development productivity?
We don't.
At least not with one simple number.
We can compare development time by feature, but we need similar baselines every time.
Imagine two developers building the same feature in parallel.
- One completes the feature in 2 hours with 500 lines of code and gets paid $100 per hour.
- The other completes the feature in 3 hours with 700 lines of code but gets paid $50 per hour.
Who do you consider more efficient?
It depends.
Do you need the feature faster or cheaper?
Now imagine the same scenario where both have an agentic coding environment.
- The first completes the task in 2 hours with 700 lines of code and gets paid $100 per hour.
- The second completes the task in 1 hour with 700 lines of code and gets paid $50 per hour.
It's easy to assume the second is better for the business because it costs less.
But remember, we need to look at value.
The first took longer because the developer spent more time planning, describing the feature, including edge cases, and evaluating the code before committing.
The second completed it much faster because the developer assumed most of the suggested code was right. In the end, this developer didn't really understand the code.
But hey, it works, right?
Productivity is rarely that simple in Software Development
The scenarios above are rare.
How often do you have two developers working on the same feature in parallel so you can compare their time, cost, code quality, and long-term results?
It happens during job interviews.
Rarely again.
All the numbers of hours, lines of code, and costs above are intentionally misleading.
We're tempted to calculate the direct cost of developing that feature and call the result productivity.
But that type of productivity measure is rarely useful by itself.
One developer may be faster, but that becomes irrelevant if this person doesn't understand how the code works.
Or if poorly designed code requires a massive refactor shortly afterward because the business is scaling.
Or worse, if the feature breaks often because the edge cases are more common than initially thought.
Remember the Value Stream Map?
This is where we apply the same way of thinking.
Look at the entire flow of developing and delivering the feature.
Writing the code is part of it.
Describing the feature to AI, listing edge cases, refining context and prompts, reviewing generated code, testing, correcting mistakes, and adjusting the agent harness are also part of that flow.
Some of these activities add value directly.
Some don't add value directly, but are necessary for the work.
And some may simply be waste.
Lean thinking commonly gives us three useful categories:
- Adding value
- Not adding value, but necessary for the work
- Not adding value, and not necessary for the work
We focus on eliminating the third and minimizing the second, creating more room for the first.
Now we can finally go back to AI.
Does AI increase productivity?
The main goal of this post is not to evaluate whether AI makes developers more productive or not.
The goal is to understand productivity concepts so we can stop saying AI makes developers more productive when we don't even know what that means.
Of course AI can make a developer much more productive. But it can also make development much slower.
Being busy is not the same as adding value.
Look at those three categories again.
Agentic coding introduces new activities into the development process: describing tasks, preparing context, configuring agents, reviewing generated code, correcting mistakes, and sometimes repeating the whole process.
Those activities are not free.
If an agent generates a feature in five minutes but I spend an hour preparing the context and another hour reviewing and correcting the result, saying that AI made me more productive because the code was generated in five minutes doesn't mean much.
Maybe a better agent reduces that setup.
Maybe a stronger model reduces the review and correction time.
Maybe a better workflow eliminates unnecessary steps.
Great.
That's productivity improvement.
The goal shouldn't be to generate more code.
The goal should be to reduce the effort required to reliably produce the same or more value.
There is also one very interesting advantage to agentic coding: parallel work.
If I have multiple agents working on different tasks, I can prepare or review the work of one while another is running.
Now we are changing the flow of work.
The waiting time of one process overlaps with useful work somewhere else.
Setup time matters.
If I spend 10 minutes preparing an agent and then wait 20 minutes for it to work, that's one workflow.
If I can use those 20 minutes to prepare another agent, review another result, or do useful development work myself, that's a different workflow.
I didn't make the agent faster.
I made better use of the waiting time.
Does that make me more productive?
Possibly.
Now I need to measure the whole process and see.
But there is one obvious consequence of running multiple agents:
Cost.
Parallel agents mean more model usage and more compute.
Maybe I finish twice as much work.
Maybe my AI bill triples.
Again:
value
productivity = --------
effort
The main lesson today is simple:
Next time someone says they became more productive using AI, ask them how they're measuring their productivity.
If they say lines of code, pull requests, or number of features, you already know what they're measuring.
Output.
And output alone doesn't tell us whether productivity increased.