DEV Community: Nikita Makarov

If AI Makes Work Cheaper, Who Gets Richer?

Nikita Makarov — Mon, 14 Sep 2026 12:50:01 +0000

AI could grow the economy while more of the gains go to owners of businesses and other assets. That finding in Anthropic's economic scenarios made me ask: what could I build and own?

In the substantial scenario, there are fewer jobs in knowledge work, including programming and analysis. Pay stays roughly flat, although the economy grows at about twice its normal rate.

In the extreme scenario, these jobs fall much further. Pay for knowledge workers drops by more than 10% by 2030 compared with an economy without AI.

Capital owners get a larger share of income in both scenarios. In the extreme case, workers' total income barely changes by 2030, so most of the extra income goes to capital.

These are possible futures, not predictions. They depend on AI's abilities and how widely it is used.

This makes ownership more interesting to me. The same AI that reduces the cost of intellectual work could also help me build a product or business of my own.

Cheaper code makes customers and trust more important

I think a booking tool for repair shops is a useful example. Suppose AI cuts the time needed for the first version from months to weeks.

The developer still needs to understand how shops handle bookings, find an owner willing to try the tool, move their records, and support them when something breaks.

Another developer could use AI to build similar features. They would still need to earn customers' trust.

As software gets cheaper to build, I expect more value to come from:

Customer access: knowing how to reach shop owners who need the tool.
Trust: a record of keeping bookings safe and fixing problems.
Useful data: information that takes time to collect and keep current.
Market knowledge: understanding details such as repair delays and parts availability.

That is the part of ownership I find interesting: a share of the value that the product and those relationships create over time.

An asset can serve more customers without repeating all the work

By an asset, I mean something I could own that keeps creating economic value after the first version is built. Examples include:

Subscription software: a booking or reporting tool with a monthly fee.
A mobile app: a tool with paid features or a subscription.
An API: a service that converts files or cleans data, charging by usage.
A browser extension: a tool that saves time on a repeated task.
A library or plugin: software that teams pay to use under a license.
A database: information customers pay to access, with regular updates.
A course, book, or guide: material that can sell many times.
A newsletter or media business: content funded by readers, sponsors, or product sales.
A share in a business: ownership of part of a company's future value.

The same library can serve hundreds of teams. The same booking tool can serve many shops. Neither needs to be rebuilt for each customer.

A brand and an audience can help too. Customers who trust one product may try another from the same owner.

These assets need updates, support, and money to run. Their value can grow faster than the owner's working hours, but that is not guaranteed.

AI can help a small team test a business

AI can help write code and tests, draft documentation, and prepare support replies. A developer still needs to check the results, but may need less help to launch a first version.

That creates room to test a business before hiring a full team.

For example, one developer could build the booking tool while a partner finds repair shops willing to test it. They could start with bookings and reminders, then add features based on what paying customers need.

A business run by two people serving one market is a model I find interesting. I would care more about whether customers stay and income covers the costs than about the size of the team.

A side project needs demand to become a business asset

It would be easy to call ten side projects ten assets. But ten unused apps could just mean ten things to maintain.

They can still be useful for learning. For a business, I would look for other signs:

Users return.
Customers pay.
The business can afford the cost of finding new customers.
Income covers hosting, AI usage, support, and other expenses.
Each new customer does not require hours of manual work.

A paid extension with returning customers shows demand. A large codebase alone does not.

That would change what I count as progress. A conversation about why someone stopped using the product could matter more than another feature.

I see another path alongside engineering

The usual engineering path is:

Junior → Mid-level → Senior → Staff → Principal

The path I am thinking about looks like this:

Engineer → Builder using AI → Software business owner → Owner of several assets

It brings up questions that writing code alone cannot answer:

Product: what problem would people pay to solve?
Distribution: where would the first hundred customers come from?
Sales: how would I explain the value and ask for payment?
Business economics: what would it cost to find and serve a customer, and what would be left?

I see this as another direction my engineering skills could take me. Even one product would give me plenty to learn about running a business.

I would want to test the business idea early

If I tried this, I would start with a problem in a market I understand. I would want to know how people solve it today and whether the problem costs them enough to pay for a different solution.

For the booking tool, my first question would be whether shop owners would move their bookings or pay for reminders. A small test could answer more than months spent building features.

This is where AI seems most useful to me: reducing the time and money needed to find out whether an idea works.

If one product found customers, it might also reveal another problem in the same market. That is how I imagine several assets could grow from one business, rather than from a list of unrelated app ideas.

The question I am left with

Anthropic's scenarios made me think about who benefits when intellectual work gets cheaper. More of the gains could go to owners, while AI also makes it easier for a developer to become one.

I do not know which scenario will happen. But it has changed the question I ask about my skills.

Alongside “what can I build?”, there is now another one:

What would I want to own?

AI scaled my work. But not my brain.

Nikita Makarov — Thu, 10 Sep 2026 07:19:41 +0000

Over the last year, I noticed something about the way I work with AI.

I get much more done, but I also feel much more tired. Not “I need some coffee” tired. I mean completely mentally drained at the end of the workday, especially by the end of the week.

The strange part is that I am not working more hours. AI lets me do in one hour what could easily take half a day before.

That hour is just much more intense than it used to be.

A normal developer workday was never eight hours of nonstop hard thinking. You wrote code, read docs, waited for a build, got stuck on a problem, went for coffee, came back, talked to someone, tried something else.

The mental load was naturally spread across the day.

With AI, this structure starts to disappear.

You can have Claude Code open while another agent is refactoring something, a third one is working on tests, and a fourth one is researching a problem. While one is working, you start another.

Then the first one comes back with a result. You need to read it, understand it, check it, make a decision, and give the next prompt. While you are doing that, the second one finishes. Then the third.

You are no longer just writing code. You are running a small factory of mental work.

And the factory scales much better than the person running it.

Humans have usage limits too

I like the comparison with Claude Code limits.

Claude has a five-hour usage window. This does not mean “five hours of tokens” in a literal sense. Usage depends on the length and difficulty of requests, the model, tools, and other things.

If I start more work in parallel, I do not get endless compute. I can simply burn through the available budget faster.

Parallel subagents = faster AI budget consumption.

I think humans work in a similar way.

We do not have a real token counter in our heads, but we do have limits. Attention and working memory are limited. So is our ability to make difficult decisions well, switch between several complex problems, and keep a large system in our head at the same time.

Parallel tasks = faster cognitive energy consumption.

AI does not increase this resource. It increases how fast we can spend it.

Before AI, I could spread a lot of difficult thinking across an eight-hour workday. Now I can burn a large part of that mental budget in two or three very intense hours with several agents.

I got more compute around my brain.

But I did not get another brain.

AI removed the waiting, not the thinking

This is the part I think we miss when we talk about AI productivity.

AI removes many slow parts of software development: writing boilerplate, searching docs, trying basic implementations, refactoring repetitive code, or manually working through simple tasks.

That sounds like it should make the workday easier.

But it also removes a lot of natural low-intensity time.

Before, there were gaps. Now the next piece of work can arrive almost immediately.

Finished?

Here is another result.

Checked it?

Here is the next one.

Made a decision?

Start three more agents.

The machine does not get mentally tired. So if you let it, it can keep feeding work into the human bottleneck all day.

There is already research pointing in this direction.

A 2026 Harvard Business Review article is literally called “AI Doesn’t Reduce Work—It Intensifies It”.

Researchers from UC Berkeley followed employees at a tech company for eight months. Instead of simply finishing the same work faster and getting more free time, people started working faster, taking on more tasks, and spreading work across more of the day.

Often, this happened without direct pressure from managers.

AI created more room for work, and work filled it.

Software development is shifting from creation to verification

A 2026 study about software engineers found something similar: The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study.

The authors found a shift from creation to verification.

82% of participants said they spent less time directly writing code. But another type of work grew. The authors called it supervisory engineering work: giving tasks to AI, checking its output, fixing mistakes, and deciding what should happen next.

84% of developers said their productivity improved. At the same time, among matched participants, the share of people who reported a worse developer experience in at least one area grew from 14% to 27%.

The problems included flow state and cognitive load.

This describes what I see pretty well.

AI removes some of the work needed to create the result, but it creates much more work around checking the result.

And checking also uses your brain.

Sometimes it is harder than writing the code yourself, because you need to understand enough to know when the AI is wrong.

AI brain fry

In March 2026, HBR published another article: When Using AI Leads to “Brain Fry”.

It was based on research involving 1,488 workers. The study connects heavy AI oversight and higher workload with problems focusing, slower decisions, mental fatigue, headaches, decision fatigue, and a higher chance of mistakes.

So we have reached a strange point.

AI can produce work faster than a human can properly process it.

The eight-hour workday starts to look strange

Most office work is still measured in time.

You have an eight-hour contract. But eight hours of being at work and eight hours of hard reasoning are completely different things.

A person can physically sit at a computer for eight hours. That does not mean they can spend eight hours making good architecture decisions, keeping several complex contexts in their head, and checking the results of five agents.

Before AI, a workday naturally had different levels of intensity. Some parts were hard. Some were routine. Some were waiting.

AI can compress much more difficult work into the same block of time.

And this is where the eight-hour model starts to look strange.

If I can spend most of my mental energy by early afternoon, the clock may say I still have five hours left.

My brain does not care.

Who gets the extra productivity?

This is the part I find uncomfortable.

My contract still buys roughly the same amount of my time. My salary does not automatically grow because Claude Code can now help me produce much more inside that time.

But the amount of work that can fit into those hours grows.

So who gets the extra productivity?

We built technology that could reduce part of the mental work people have to do.

Then we did the most predictable thing possible.

We filled the new free capacity with more work.

Not:

Finish the same work faster and stop earlier.

But:

You can do more now, so do more.

After a while, the higher output stops looking exceptional.

It becomes the baseline.

The takeaway

I am not against AI coding tools. Quite the opposite. I do not want to go back to software development without them.

But productivity and human capacity are two different things.

If AI lets me spend in two hours the mental energy that used to be spread across eight hours, the answer cannot be to keep the same level of intensity for another six.

We understand this perfectly when the limit belongs to a machine.

Claude has usage limits. APIs have token limits. CPUs have thermal limits.

Run more work in parallel and you hit those limits faster.

But when the limit belongs to a human, we still look at the clock and say:

You have six hours left.

That makes less and less sense to me.

AI scales execution. It scales parallel work. It scales output.

It does not scale the human brain.

Otherwise, the great AI productivity revolution may end up doing something much simpler:

teaching us how to burn through a full day of human cognitive energy before lunch.