Code Inflation: I'm More Productive. Am I More Valuable?

AI has made code easier to produce than ever. The real question isn't whether the code is good; it's who keeps the gains from this abundance.

Picture a Monday morning. Three PRs are waiting for you, 140 files in total. On each one, the AI reviewer has left 30–40 comments, and to be honest, most of them are spot on: a race condition, a missing index, an edge case you would probably have missed. The fixes are in, the tests are green. You check the critical parts and approve.

Then you stop and think: I didn't write this code. I didn't read all of it. But I own it.

The unease doesn't come from the tool being bad. The tool does its job well. It comes from how your relationship with your own work changes while the tool does its job well. And underneath that change, I think, sits a question the AI debate rarely asks:

AI makes me more productive. Does that also make me more valuable?

What I mean by code inflation#

By "code inflation" I don't mean a literal counterpart of economic inflation. What I mean is that producing code keeps getting easier, while it is becoming less clear how the resulting economic gains are shared.

When work that once seemed valuable because it was difficult becomes easier, it doesn't become unnecessary. But it can change what we're able to ask in return for being able to do it.

That's the kind of abundance we're entering in code. AI-generated code is real code; it's often clean, well tested, and sometimes cleaner than what we would have written ourselves. Expanding the scope of a solution may no longer require a proportional amount of human effort. Solving the same customer problem with less effort doesn't reduce the value of the solution to the customer. What may shrink is the amount of labor needed to produce it. How that translates into the price of labor is a separate question, and for engineers it's the real one.

Code can create value, but keeping that value has a cost. Code that's written has to be understood, updated and, when necessary, removed. The effort of writing code used to be a natural brake on producing more code than we needed. AI has largely removed that brake.

But AI doesn't only make writing code easier; it makes maintaining it easier too. In the opening scene, the review was done by AI as well. So equating more code with more maintenance burden isn't enough. The real question is how the balance between production and maintenance is shifting. Is the cost of producing code falling faster than the cost of understanding it, or are both falling at a similar pace? The answer will shape how software teams work in the years ahead.

Output is not a decision#

Picture a team. The product manager uses AI to produce a 12-page requirements document in five minutes. Nobody reads all 12 pages, but the document exists. The engineer hands it to an agent, which implements every item flawlessly. QA generates 80 test scenarios from the same document. They all pass.

A flawless process on paper. But nobody stopped to ask which of those requirements were actually worth building. Everyone produced; nobody decided.

I don't think this happens because AI can't decide. Give it the product goals, the costs and the customer requests and ask "should we build this?", and it will most likely give a sensible answer; it might even say "let's not." The problem isn't capability, it's process. In this example, the process is built around asking AI for more output. There's no step that uses the same capacity to shrink the scope.

And that leads somewhere uncomfortable. If AI can make decisions too, what's left for the human?

What's valuable today may not stay valuable tomorrow#

It's easy to list what's scarce today: attention, the capacity to decide, knowing a system's "why" and not just its "what", signing off on a change and owning the outcome. These are genuinely valuable right now.

But selling them as permanent safe zones that AI can never reach wouldn't be honest.

The "why" lives with people today because it's buried in customer calls, Slack threads and decisions nobody wrote down. But once that knowledge is documented and made accessible to AI, which good teams should be doing anyway, AI can work with it too. Its being in human heads isn't a law of nature; it's a question of access.

The same goes for accountability. When a customer asks "why is my invoice wrong?", someone has to answer; "the AI wrote it that way" is not an answer. But the need for someone to be accountable doesn't mean the same number of engineers will be needed. The responsibility ten people share today could rest with two tomorrow. Accountability staying with humans is no guarantee that employment will stay the same.

We shouldn't assume that the skills that are valuable today will keep the same value tomorrow.

Who keeps the gains?#

This is the real question of this piece.

Say I can now finish a job far faster than before. That means my abilities have expanded. It doesn't mean my work will be rewarded more.

A purely hypothetical example: say I finish a three-day job in one day with AI's help.

• If I bill the client by the day, I bill less for the same work.
• If I agreed on a fixed fee for the job, the time saved works in my favor, as long as other costs don't change.
• If I'm on a salary, my pay may stay the same while I'm expected to deliver more.

Same tool, same speed-up. But where the gain goes isn't decided by technical skill alone; it's decided by the terms under which the work is done.

At a larger scale, the same speed-up tells three different parties three different things:

• To me: "You can now build a product on your own."
• To my employer: "You can do the same work with a smaller team."
• To my competitor: "You can sell the same product for less."

All three can be true at once. The value an engineer creates and the share of it they receive are not the same thing. I may be creating more value; how that shows up in my pay, my working conditions or my independence is a separate matter.

That's why we can't dismiss engineers' unease as "resistance to change." A person can feel more powerful than ever and, at the same time, more uncertain than ever about what their work is worth in the market. The anxiety comes precisely from the tool being good.

And the joy?#

Many engineers chose this profession because they loved writing code. For some, AI cuts the time they spend writing code while raising how much they're expected to deliver. For others, it makes possible projects they could never have taken on alone; a single engineer with a few agents can build what would have required an entire team just a few years ago. The same change can feel like freedom to one person and loss to another. Telling someone who feels the loss to "adapt to the new reality" would be unfair.

What can we do?#

I don't have a ready-made recipe. But given this picture, a few approaches make sense to me:

• Talk about what the speed is worth. We need to ask what the time we save with AI turns into: more deliveries, higher income, fewer hours? That efficiency gain shouldn't only turn into new delivery targets; it should also be part of conversations about pay, workload and roles. The outcome isn't guaranteed. But quietly accepting the speed-up as the new normal is not the same as negotiating what it's worth.
• Know where value is created. Know which customer problem your code solves and where the company makes its money. That knowledge strengthens both your work and those conversations.
• You can use the speed-up in your own favor too. If AI allows your employer to do the same work with a smaller team, it also gives you the ability to build your own product or side project. But not everyone needs to be an entrepreneur; being able to build a product more easily doesn't make it equally easy to make money from it.
• Learn to evaluate solutions. Being able to pick the right solution out of three may be a more valuable skill today than producing a single one.

The message for those starting out is similar. Let the measure of learning be not how many lines you wrote by hand, but whether you can explain, test and change the system you built with AI. Learn the product, the customer and where value is created. Read AI's code review comments as you would a mentor's feedback. And above all, realize early that as your skills grow, what you get in return may not grow at the same rate.

Final word#

Being excited about using AI and being anxious about the future of your profession aren't mutually exclusive. The same tool that expands what we can do can also make it less clear how we'll be paid for what we do.

So the issue isn't only writing better code, shipping faster or building bigger systems. It's how much of the value those things create we actually get to keep.

Having better tools is not the same as having a stronger bargaining position.