From Code Generation to Application Generation, Part 8: If Agents Are Doing the Coding, What Am I Doing?

This article concludes my series on building applications using AI.

The Short Version

If agents are doing more of the coding, the human role does not disappear.

It moves.

It moves toward mission, judgment, validation, integration, accountability, and deciding what should exist in the first place.

That shift can feel threatening if we imagine software work as only typing code into an editor. But if software becomes easier to create, I do not think the world simply needs less software work. I think software work spreads into many more places.

Small businesses, nonprofits, churches, studios, food pantries, clinics, local service companies, and community groups have always had software problems. They just did not always have software budgets.

Application generation changes that.

The Awkward Retro

Imagine a sprint retrospective.

One team member suggests that the team should create story sections for agents. Product likes the idea. The manager likes it too. Someone takes it further:

We should identify stories that can be done purely by agents and push more work in that direction.

Then a bold engineer asks the question everyone is quietly thinking:

If all the work is done by agents, what are we doing?

There is an awkward silence.

Finally the manager says:

We are not there yet. Let’s not worry about that now.

That answer is understandable. It is also incomplete.

Many leaders are now taking up the AI challenge in a very simple form: if coding tools make engineers 10x more productive, then the same team should deliver 10x more output.

That sounds exciting in a slide deck. In practice, it can create tremendous pressure for leaders and engineers. It is also not a very fun way to think about the future of software.

The better question is not:

How do we squeeze 10x more tickets out of the same team?

The better question is:

What becomes possible when software is no longer as scarce?

I Do Not Know Exactly What Happens Next

I want to be honest about this. I do not know exactly where this goes.

Some engineers I know doubt that coding agents will continue in their current form because of cost, energy usage, and business model pressure. They would not be surprised if some companies eventually restrict or reshape agent usage.

At the same time, I hear something different from managers at large companies: token usage is being tracked, but many engineers still do not have strict consumption limits. In some places, heavy AI users are encouraged or rewarded.

The direction is still unstable. But the broader pattern is hard to ignore.

In my earlier series, The End of Software Scarcity, I argued that software has never been this accessible. I keep seeing examples. A marketing specialist without a traditional technology background built a potential donor dashboard for a nonprofit in less than a month. A gym studio owner built an app for his clients to promote his business.

Many readers probably have their own examples by now.

Software is being generated at an unprecedented rate. Eren Bali recently pointed to GitHub activity and summarized the deeper lesson this way: there was always “more demand than supply for code.” He was responding to Kyle Daigle’s note that GitHub platform activity had surged sharply.

That is the part I care about most.

If demand was always larger than supply, then cheaper software creation does not simply eliminate work. It reveals work that was previously unaffordable.

We Have Seen This Pattern Before

This is not the first time a scarce technical layer became more accessible.

When mainframes gave way to personal computers, computing moved from institutions to desks. Accountants got spreadsheets. Writers got word processors. Engineers got CAD.

When websites moved from custom builds to CMS platforms and site builders, every plumber, church, nonprofit, and soccer club could have a website.

When cloud computing arrived, teams no longer needed to buy servers and operate data centers before trying an idea.

When mobile frameworks improved, startups could build apps that previously required much larger budgets.

The pattern is not that work disappears. The pattern is that the boundary moves.

One scarce layer becomes cheaper, and the world starts applying technology to more problems.

What Is Different This Time?

This time the scarce layer is not hardware, hosting, deployment, or distribution.

It is engineering effort.

Historically, custom software followed a familiar path:

Idea
  -> Requirements
  -> Architecture
  -> Months of development
  -> Software

With application generation, the path is starting to look different:

Idea
  -> Mission
  -> Agents
  -> Validation
  -> Software

Implementation cost is collapsing.

That does not mean every application becomes easy. It does mean the economics change.

Large enterprises historically justified custom software because they could spread the development cost across thousands of employees or customers. Small organizations could not.

Take a custom scheduling workflow.

At $250,000, a hospital may say yes and a restaurant says no.

At $8,000, the restaurant starts saying yes.

That is the economic shift behind application generation.

More Accessible Software Can Mean More Software Work

I would be careful with the claim that AI automatically creates more traditional software engineering jobs. It may not.

Some coding tasks will shrink. Some teams will expect more output from fewer people. Some jobs will change faster than people are ready for.

But more accessible software can create more software-shaped work.

When more organizations can afford custom software, they still need people who can:

• understand the real mission
• decide what should and should not be automated
• translate messy workflows into usable systems
• integrate data across tools
• validate whether the generated application actually works
• protect privacy, security, and trust
• train users
• maintain the system as the organization changes

That is not the same as hand-coding every screen.

It is still software work.

In many cases, it may be better software work.

This Is Bigger Than Code Generation

That is why I like the phrase:

From code generation to application generation.

The economic consequence is bigger than the technical one.

The consequence is that personalized software becomes viable.

Not necessarily personalized to one individual. Personalized to a dentist, a church, a food pantry, a welding shop, a realtor, a family, a local clinic, or a nonprofit program.

Each one operates differently.

Historically, they all had to squeeze themselves into QuickBooks, Salesforce, HubSpot, Excel, Google Sheets, or whatever SaaS tool was close enough.

Those tools are useful. But they also force local work into generic shapes.

Application generation makes another possibility more realistic:

Software adapts to the organization, instead of the organization always adapting to the software.

What Am I Doing, Then?

If agents write more code, what is the engineer doing?

I think the answer is:

The engineer becomes more responsible for the mission and the proof.

That is the practical reason I ended up with Mission-Driven Engineering.

The mission becomes the specification.

The agents reduce implementation cost.

Validation preserves quality.

Memory reduces future cost.

The human role moves into the parts that are harder to outsource to a coding agent:

• What problem is worth solving?
• Who is affected if the software is wrong?
• What evidence proves the application works?
• What should the system refuse to do?
• What business or community context would a generic agent miss?
• What tradeoffs are acceptable?
• What does better look like after the first version ships?

That is not less important than coding.

It is a different center of gravity.

Ilam’s Internet Memory

Before returning to the retro meeting, I want to include something a dear friend, Ilam, told me.

He remembers when the internet became widely available. Before that, there were books and articles he wanted to read, but he could not always access or afford them. He still remembers the feeling when knowledge he had been longing for became available.

That memory stayed with me.

I feel something similar with coding agents.

There are projects I never expected to explore because the implementation cost was too high. Some are already implemented. Others are now on a real path to implementation.

I do not think I am alone in that feeling.

When software becomes more accessible, people do not only build more tools. They build tools closer to their own lives, businesses, communities, and frustrations.

That will create new problems too. More software means more maintenance, more quality risk, more security risk, more integration complexity, and more responsibility.

But those are the kinds of problems that appear when a capability becomes widely useful.

Back To The Retro

So what should we say to the engineer in the retrospective?

Not this:

Do not worry. We are not there yet.

That may be true for now, but it avoids the real question.

I would say something closer to this:

If agents can do this work, we should let them. Then we should ask what better work becomes possible because they did.

The weakest reason not to automate a job is:

If we automate this, what will we do?

We should automate it precisely because that question forces us toward better work.

Not easier work.

Not less accountable work.

Better work.

Work closer to the mission. Work closer to the user. Work closer to validation, judgment, trust, and impact.

That is where I think application generation leads.

And that is also where my next series begins: helping small businesses and nonprofits use AI to get software that finally fits the way they actually work.