The Future of Software Development With AI
Coding activity rose 180%. Software releases rose 30%. The gap between those two numbers is the story. A look at the abstraction ladder, the comprehension gap, the verification economy, and why "What should we build?" becomes the harder question.
What Happens When Code Stops Being the Bottleneck?
For most of computing history, software had a stubborn bottleneck:
Humans had to write it.
An idea could be brilliant. A business could desperately need it. Millions of people could benefit from it.
None of that mattered if someone couldn't translate the idea into software.
That translation required scarce skills, expensive engineering teams and enormous amounts of human time.
Artificial intelligence is beginning to loosen that constraint.
Developers can now describe features in ordinary language and watch AI systems create components, inspect repositories, modify files, run commands, write tests, diagnose failures and revise their own work.
The instruction is gradually changing from:
Write this code.
to:
Build this.
That sounds like a productivity story.
It is much bigger than that.
Because when the cost of producing code collapses, something strange happens:
code stops being the scarce resource.
And the bottleneck moves somewhere else.
Software Has Always Been Climbing an Abstraction Ladder
AI did not suddenly make programming easier.
We've been making programming easier since programming began.
Early programmers worked painfully close to the machine.
Instructions were represented as numerical machine code.
Assembly replaced many of those numbers with symbolic instructions.
Languages such as FORTRAN and C let programmers describe increasingly complex operations without thinking constantly about the processor underneath them.
Later came:
libraries,
frameworks,
APIs,
cloud platforms,
managed databases,
software-as-a-service,
low-code tools,
and increasingly sophisticated development environments.
Each layer removed some implementation burden from the human.
Figure 01
The pattern is remarkably consistent.
Humans move upward.
Machines absorb more of the implementation underneath.
AI is unusual because it doesn't merely abstract syntax.
It begins abstracting portions of reasoning itself.
First the Computer Finished Your Sentence
The earliest wave of AI-assisted programming didn't feel revolutionary.
It looked like better autocomplete.
A developer might begin typing:
const calculateTotal =
and the machine would suggest what came next.
Then autocomplete became capable of generating an entire function.
Then multiple functions.
Then documentation.
Then tests.
Tools such as GitHub Copilot turned predictive code generation into a normal part of many development environments.
But the basic relationship remained intact:
The developer drove.
The machine helped.
The programmer still moved through the codebase line by line, accepting, rejecting and modifying suggestions.
Then the interface changed.
Then We Started Asking for the Code
Large language models allowed developers to begin with language instead of syntax.
Instead of figuring out exactly how to implement something first, a programmer could say:
Build a responsive product grid from this API.
Or:
Find out why this route works locally but fails in production.
Or:
Add rate limiting to this endpoint without changing the public API.
That sounds deceptively simple.
It represents a fundamental change in the interface between humans and computers.
For decades, programmers translated ideas into formal instructions before machines could act on them.
AI introduced another layer:
human intention → AI interpretation → software implementation
The machine could participate in the translation.
Suddenly, people who understood a problem but lacked years of programming experience could participate in software creation.
Experienced engineers gained something different:
leverage.
But generation wasn't the endpoint.
The next step was giving the AI tools.
Then the AI Left the Chat Window
A chatbot can tell you how to fix your application.
A coding agent can try to fix it.
Modern agentic coding systems can combine language-model reasoning with direct actions inside development environments.
Depending on the system and permissions available, an agent may:
- inspect an entire repository
- search files
- modify several files
- run terminal commands
- execute tests
- inspect failures
- consult documentation
- interact with APIs
- use version control
- revise its own implementation
- prepare commits or pull requests
Microsoft researchers studying GitHub Copilot traces from June 2026 analyzed activity from 3.2 million users, 13 million agentic sessions and 761 million model calls. Their research describes a fundamentally different computing workload in which language-model reasoning is repeatedly combined with tool execution inside autonomous loops.
That's not autocomplete.
That's delegation.
A developer can increasingly give the machine a goal instead of an individual instruction.
And once that happens, software development encounters a new problem.
The Productivity Explosion
In September 2026, researchers studying more than 100,000 developers documented what happened as increasingly capable coding tools entered real development workflows.
Autocomplete increased coding activity by roughly 40%.
Adding synchronous coding agents increased the cumulative effect to around 140%.
Asynchronous agents, capable of working more independently from a prompt, pushed the increase to roughly:
That number sounds extraordinary.
And it is.
But it wasn't the most interesting number in the study.
Because the 180% increase in coding activity translated into only about a:
50% increase in software projects
and a:
30% increase in software releases.
Figure 02
Something was absorbing most of the productivity gain.
The researchers described the change directly:
the constraint was shifting away from writing code and toward reviewing, integrating and distributing it.
That may be one of the most important changes happening in software engineering.
The Moving Bottleneck
For decades, organizations optimized software development around a simple reality:
writing software was expensive.
Developers were scarce.
Engineering hours were scarce.
Every feature competed for limited programming capacity.
AI begins to change the equation.
Look at that pipeline again.
Something is narrowing the pipe.
The code exists.
But someone still has to:
understand it,
review it,
integrate it,
test it,
secure it,
approve it,
deploy it,
maintain it,
and eventually persuade someone to actually use it.
AI accelerates one stage of the pipeline without automatically accelerating everything downstream.
Software development therefore enters a peculiar new world:
That changes what productivity means.
Code Productivity Is Not Software Productivity
This distinction matters.
Producing more code is easy to measure.
More commits.
More pull requests.
More files.
More functions.
More features generated.
But software exists to solve problems.
A thousand additional functions nobody needs are not productivity.
They're inventory.
The Wharton and MIT research found another remarkable pattern.
Following the rise of coding agents, the number of newly published applications increased sharply across major software marketplaces.
Apple's App Store went from around 30,000 new monthly releases before coding agents arrived in early 2025 to roughly 100,000 per month by April 2026.
Yet overall software usage across the marketplaces studied did not rise with the flood of new applications.
That introduces an even more interesting bottleneck.
Maybe software creation becomes cheap.
Then software distribution becomes scarce.
And after distribution?
Attention.
Trust.
Adoption.
Understanding users.
Iteration.
Finding an actual problem worth solving.
AI may make building software dramatically easier without making people care about the software once it exists.
The Comprehension Gap
There is another bottleneck hiding inside engineering teams.
Humans can now generate software faster than humans can understand it.
Consider what happens when a developer manually writes 500 lines of code.
They may make mistakes.
But the act of constructing the implementation creates understanding.
They know why certain decisions were made.
They remember which alternatives failed.
They understand the strange workaround hidden on line 417.
Now imagine an AI generates 8,000 lines across dozens of files in twenty minutes.
The developer receives the finished structure without necessarily experiencing the reasoning that produced it.
This creates what we can call:
Figure 03
The gap is already visible inside real engineering organizations.
At AI video company Synthesia, adoption of AI coding tools produced a dramatic increase in software output.
According to reporting from IEEE Spectrum, pull requests rose 120% year over year.
Around 95% of those pull requests contained AI-generated code.
Eventually, the amount of code entering review rose tenfold, while review times tripled.
The machine became faster.
The human review system didn't.
The bottleneck moved.
Again.
Welcome to the Verification Economy
AI-generated software introduces a deliciously strange development workflow:
AI writes the code.
↓
Another AI reviews the code.
↓
A human decides whether either AI should be trusted.
That is already becoming an industry.
Developers surveyed by Sonar estimated that AI contributed roughly 42% of the code they added to shared codebases.
Yet 96% did not fully trust AI-generated code to work correctly.
And 38% said AI-generated code required more review effort than code written by colleagues.
That trust gap is creating an entirely new category of tooling.
AI code-review startup CodeRabbit raised $143 million at a $1.5 billion valuation in August 2026, while reporting more than two million code reviews per week across 17,000 customers.
Think about what that represents.
We are building AI systems whose job is increasingly to inspect software produced by other AI systems.
Generation becomes abundant.
Verification becomes valuable.
The economic center of software engineering begins drifting downstream.
Passing the Tests Is Not the Same as Being Correct
The obvious response is automation.
If AI generates too much code for humans to review manually, let AI test it.
And that will certainly happen.
Agents can already:
run tests,
write additional tests,
inspect failures,
perform static analysis,
search for vulnerabilities,
compare implementations against requirements,
and revise code when something breaks.
But tests have a philosophical weakness.
They verify what someone thought to test.
They don't prove that every important behavior is correct.
Berkeley researchers working on formally verified AI-generated software recently framed the problem clearly: an agent reporting that "all tests pass" provides less assurance than it sounds like, because test suites only cover the cases people actually specified.
This points toward another emerging frontier:
formal verification.
Instead of asking only whether software passed a collection of examples, formal methods can attempt to mathematically establish that an implementation satisfies a specification across every case covered by that specification.
If AI dramatically increases code volume, stronger forms of verification may become far more valuable than they were when human engineering time was the primary constraint.
Software abundance changes the economics of correctness too.
AI Can Generate Correct-Looking Wrongness
One of the dangerous properties of AI-generated code is that it often looks reasonable.
Bad human code frequently looks bad.
Names are inconsistent.
Formatting is chaotic.
Structure is awkward.
AI can produce the opposite:
clean,
confident,
well-organized,
professional-looking code...
that contains an incorrect assumption.
A security vulnerability.
A duplicated implementation.
A misunderstood requirement.
An edge case nobody considered.
At Synthesia, engineers reportedly found cases where AI tools independently created as many as 10 versions of the same function, apparently failing to recognize that similar functionality already existed elsewhere in the repository.
This is important because the problem isn't always:
The AI can't write code.
Increasingly, it can.
The harder problem becomes:
Does the AI understand enough of the system to know what code should exist?
That's software engineering.
Not syntax generation.
The Developer Moves Up the Stack
If AI writes more implementation code, what happens to developers?
A simplistic answer says developers disappear.
A more interesting answer is that developers move.
The work shifts upward.
From:
syntax
toward:
systems
From:
implementation
toward:
architecture
From:
typing
toward:
judgment
From:
producing code
toward:
owning outcomes
UC Berkeley Extension summarized this distinction well in 2026: AI can generate implementations, but humans still define problems, evaluate architectural tradeoffs, navigate ambiguous requirements and remain accountable for what gets built.
The developer role may evolve through something like this:
Coder
Writes the implementation.
↓
AI-Assisted Developer
Writes with machine assistance.
↓
System Architect
Defines structures, interfaces and constraints.
↓
Reviewer / Verifier
Determines whether generated systems behave correctly.
↓
Orchestrator
Coordinates models, tools, agents and people.
↓
Owner of the Outcome
And that final step matters more than all the others.
AI can generate the database query.
It cannot accept responsibility for exposing customer data.
AI can choose an architecture.
It doesn't attend the meeting when that architecture creates a million-dollar failure.
AI can suggest a security model.
It doesn't face regulators when the assumptions were wrong.
AI can produce choices.
Humans still own consequences.
That is likely to remain one of the strongest human moats in software engineering.
When Coding Stops Being the Bottleneck
Researchers at Berkeley put the emerging transition even more bluntly in July 2026:
"When Coding Stops Being the Bottleneck."
Their argument is that software engineering itself has historically been organized around a scarce resource: humans capable of writing and reviewing software.
Programming languages, frameworks, development methodologies, testing systems and organizational processes all evolved around that constraint.
Frontier coding agents begin loosening it.
If that continues, software engineering cannot simply become today's workflow operating faster.
The workflow itself has to change.
That's a crucial distinction.
The first response to new technology is usually:
How can this make our existing process faster?
The more important question eventually becomes:
Why are we still using the old process?
AI may do to software workflows what factories did to craft production.
Not simply speed up individual workers.
Reorganize the entire system around a different constraint.
Specifications May Become More Important Than Code
Suppose you tell an AI:
Build a secure customer dashboard.
That sounds like an instruction.
It isn't.
It is a small suitcase stuffed with unanswered questions.
What authentication system?
Which customers?
What permissions?
Which data?
What happens when data is unavailable?
What qualifies as secure?
How fast should the dashboard load?
Which browsers must it support?
What accessibility requirements apply?
What happens if an API fails?
What audit logs are required?
How should administrators differ from ordinary users?
The easier code becomes to generate, the more expensive ambiguity becomes.
That creates a fascinating possibility.
The dominant artifact in future software engineering may not always be the source code.
It may be the specification.
Instead of telling AI:
Build a dashboard.
A team might define:
Purpose Allow customers to monitor active projects.
Roles Customer, manager, administrator.
Permissions Customers may only access projects associated with their organization.
Performance Initial content visible within two seconds under specified network conditions.
Accessibility Keyboard navigation and defined WCAG requirements.
Security Sensitive actions require reauthentication.
Tests Every permission boundary must have automated coverage.
Constraints Use the existing database schema and authentication provider.
Now AI is operating against something more useful than a clever prompt.
It has a contract.
This may eventually make requirements engineering cool again.
Nobody saw that plot twist coming.
Programming May Become Architecture
An architect doesn't manufacture every brick.
That doesn't make architecture easy.
The architect determines:
structure,
purpose,
materials,
constraints,
loads,
relationships,
safety,
and how humans will actually inhabit the result.
Software may be heading toward a similar division.
AI increasingly handles portions of construction.
Developers increasingly define the system being constructed.
That makes some skills more valuable, not less:
Systems thinking
Understanding how one decision affects everything around it.
Architecture
Choosing boundaries, interfaces and data flows.
Product judgment
Understanding what users actually need.
Security reasoning
Knowing where automation should stop.
Verification
Determining whether outputs satisfy requirements.
Debugging
Investigating behavior when reality refuses to match the plan.
Domain expertise
Recognizing when technically valid software is operationally absurd.
Communication
Turning messy human needs into precise technical intent.
Code remains important.
But code may increasingly become evidence of a design decision, rather than the primary location where the design decision happens.
The Junior Developer Problem
This transition creates a problem nobody should wave away.
How do experienced engineers become experienced?
Historically, they spent years doing relatively ordinary work.
Junior developers:
implemented simple features,
fixed bugs,
read unfamiliar code,
wrote repetitive tests,
made architectural mistakes,
broke things,
received painful code reviews,
debugged strange failures,
and slowly developed judgment.
AI is exceptionally good at absorbing many of those tasks.
That's convenient.
It may also remove portions of the apprenticeship.
IEEE's reporting on engineering teams adopting AI highlights exactly this concern: if early-career developers spend less time personally constructing software, organizations have to find new ways for them to learn how to judge systems later.
One engineer summarized the long-term danger perfectly:
That's not an argument against AI.
It is an argument for changing education.
Perhaps juniors spend less time memorizing syntax and more time:
investigating failures,
defending architectural choices,
reviewing generated implementations,
predicting edge cases,
working with users,
and explaining why a solution works.
The apprenticeship doesn't disappear.
It changes shape.
One Developer May Become a Tiny Software Company
Now things get interesting.
Imagine one developer working with several agents:
Planning agent
Turns ideas into requirements.
Architecture agent
Explores system designs.
Implementation agent
Builds features.
Test agent
Attempts to break them.
Security agent
Checks permissions and vulnerabilities.
Documentation agent
Explains the system.
Review agent
Inspects the other agents' work.
The human coordinates the whole system.
That begins to resemble a software organization.
Except there may be one employee.
Historically, sophisticated software required teams partly because each technical capability required human labor.
Frontend.
Backend.
Database engineering.
Testing.
DevOps.
Security.
Documentation.
Project management.
Design.
AI does not magically eliminate those disciplines.
But pieces of each can increasingly become available on demand.
That lowers the minimum economic size of a software company.
Projects that once required twenty people may eventually require five.
Projects that required five may require one.
And software that was previously too expensive to justify may finally get built.
That could produce an enormous expansion in software creation.
Welcome to Software Abundance
For most of computing history:
software was expensive,
so we built software for large groups of people.
One accounting application served thousands of companies.
One CRM served millions of salespeople.
One project manager tried to serve every possible team.
But if producing software becomes cheap enough, another model becomes possible.
Personal software.
Software for one company.
One department.
One workflow.
One project.
Maybe even one person.
Imagine a contractor who creates a custom estimating system specifically for how their business operates.
A scientist creates a temporary application for one experiment.
A teacher generates a learning tool for one semester.
A small warehouse creates software around its peculiar inventory process rather than reshaping the process around generic software.
The economics flip.
Historically:
Humans adapted themselves to software.
The future may increasingly allow:
Software to adapt itself to humans.
Disposable Software
Take the idea one step further.
What if some software isn't intended to survive?
Today we usually treat applications like buildings.
They are designed, launched, maintained and expected to persist.
But cheap generation creates another category:
Disposable software.
An application created for six weeks.
A dashboard for one negotiation.
A workflow tool for one construction project.
An analysis interface for one investigation.
A temporary internal application for a product launch.
Use it.
Modify it.
Discard it.
This is already how many people treat spreadsheets.
AI may extend that mentality to full applications.
That would profoundly change the software industry.
Why purchase a massive platform containing 600 features when an organization can generate exactly the nine it needs?
We are not completely there yet.
But software abundance points in that direction.
Then the Bottleneck Moves Again
Suppose we solve generation.
And review.
And automated verification.
And deployment.
What happens?
The bottleneck moves farther downstream.
The Wharton research offers an early clue.
AI drove a huge increase in application releases.
Usage did not follow.
If millions more applications can be created cheaply, then discovering good applications becomes harder.
The scarce resources become:
Attention
How does anyone discover your product?
Trust
Why should anyone allow your AI-generated application near their data?
Design
Can people actually understand how to use it?
Distribution
How do you reach the right audience?
Differentiation
Why use your application instead of the thousands generated this week?
User understanding
Did you solve a real problem?
Figure 04
This may be the great irony of AI-generated software.
We finally solve the problem of building things.
Then discover that building was never the hardest part of creating something valuable.
The Most Valuable Developers May Know When Not to Generate
Once everyone has powerful AI, merely using AI becomes unremarkable.
Everyone will be able to generate functions.
Everyone will be able to scaffold applications.
Everyone will have agents.
So the competitive advantage moves again.
The valuable engineer might be the person who knows:
what deserves to be automated,
what should remain simple,
which abstraction isn't necessary,
which dependency shouldn't be added,
where an agent needs supervision,
when code should be deleted,
when the specification is wrong,
and when the correct engineering decision is:
Don't build this.
AI dramatically increases our ability to answer:
How can we build it?
Human judgment remains essential for:
Should we?
What Happens to Programming Languages?
If people increasingly describe software in natural language, do programming languages eventually disappear?
Probably not.
Natural language is expressive.
Programming languages are precise.
Consider:
Make the checkout faster.
A person understands the intention.
A computer eventually needs concrete behavior.
What counts as faster?
Which operation?
Which data?
Under what conditions?
What happens when something fails?
Programming languages provide the precision machines ultimately require.
AI may increasingly produce those formal instructions on our behalf.
That doesn't make code disappear.
It changes who sees it.
Most people using websites never think about HTTP.
Most database users never think about B-trees.
Most cloud customers don't think about the physical server handling their request.
Programming languages may become another infrastructure layer:
essential,
powerful,
and increasingly invisible to many people creating software above them.
Natural Language Is Becoming an Interface to Computation
For decades, computers required humans to learn computer interfaces.
Commands.
Menus.
Programming languages.
APIs.
File systems.
Syntax.
AI partially reverses that relationship.
Now machines increasingly learn one of ours:
language.
Instead of learning every tool individually, a person can increasingly express an intention and let an AI determine which tools are required.
The old model:
Human
↓
interface
↓
software
↓
computer
The emerging model:
Human
↓
intent
↓
AI
↓
tools + software + computer
That may ultimately be more important than code generation itself.
AI becomes a translation layer between human goals and computation.
Programming is simply one of the first places where we're watching the transformation happen at scale.
From Programmer to Orchestrator to Owner
The word programmer originally describes the work pretty well.
Someone programs the machine.
But that description becomes fuzzier when the machine can participate in programming itself.
Future developers may orchestrate:
agents,
models,
repositories,
databases,
APIs,
verification systems,
security rules,
deployment infrastructure,
and human requirements.
But "orchestrator" isn't quite enough.
An orchestra conductor coordinates skilled performers.
AI systems are different.
They can hallucinate.
Misunderstand context.
Optimize the wrong objective.
Produce plausible nonsense.
The human does more than coordinate them.
The human remains accountable.
So perhaps the progression ends here:
Owner of the outcome.
That's the role machines cannot quietly inherit just because they got better at generating TypeScript.
AI May Make Programming Easier and Software Engineering Harder
This is the paradox at the center of the whole transition.
AI makes code easier.
But easier code can produce more systems.
More systems create more complexity.
More dependencies.
More integrations.
More security surfaces.
More software to maintain.
More decisions to verify.
More things capable of failing.
Generating a function becomes trivial.
Understanding whether it belongs inside a reliable system remains difficult.
Generating a database schema becomes trivial.
Understanding the business data well enough to model it correctly remains difficult.
Generating authentication logic becomes easier.
Designing the right permission boundaries remains difficult.
Generating tests becomes easier.
Knowing what must be tested remains difficult.
Generating software becomes easier.
Engineering trustworthy software does not.
The Future Probably Won't Arrive With a Headline
There probably won't be a Tuesday morning when programmers wake up and discover programming has disappeared.
The transition will be gradual.
Autocomplete becomes generation.
Generation becomes conversation.
Conversation becomes tool use.
Tool use becomes agency.
Agents handle larger tasks.
Agents begin reviewing agents.
Specifications grow more important.
Verification grows more important.
Developers spend less time typing implementation code.
The bottleneck moves.
Organizations reorganize around it.
Then one day we look backward and realize the profession changed.
Technology often transforms work that way.
Not with a clean replacement.
With a slow redistribution of responsibility.
The Bigger Idea
Software development has always been the process of translating human intention into machine behavior.
For decades, code was the translation layer.
AI introduces something genuinely new.
The translation layer itself can now:
interpret,
reason,
ask questions,
inspect systems,
use tools,
attempt solutions,
observe results,
and revise its work.
We are slowly moving from:
Tell the machine exactly how to do something.
toward:
Tell the machine what you are trying to accomplish.
There is still an enormous gap between those worlds.
AI-generated software can be unreliable.
Agents misunderstand requirements.
Security matters.
Architecture matters.
Verification matters.
Human expertise matters.
But the direction is increasingly difficult to ignore.
For seventy years, programmers learned increasingly powerful ways to speak the language of computers.
Now computers are beginning to learn ours.
That may become the biggest abstraction layer in the history of programming.
One Last Thought
Maybe the future of software development isn't a world where nobody programs.
Maybe it's a world where almost everybody can.
The carpenter who needs a better estimating system.
The scientist who needs an unusual visualization.
The teacher who wants a specialized learning tool.
The small business that cannot justify a six-figure software project.
The teenager with an idea but no engineering team.
The independent developer suddenly capable of building what once required an entire company.
And professional engineers building systems far beyond what one person could reasonably manage before.
If software becomes radically cheaper to create, the result may not be fewer developers.
It may be an explosion of software.
More experiments.
More strange little tools.
More failed ideas.
More useful ones.
More people turning problems into working systems.
Which leaves us with an interesting possibility.
For most of computer history, the hard question was:
How do we build it?
AI is increasingly helping us answer that.
The harder question may become the one humans were supposed to be asking all along:
What should we build?
Build Something Better
Ideas deserve a better home than a generic blog.
WebCraft Labz builds fast, polished websites for businesses and creators who want their ideas to feel premium from the first scroll.
Start a ProjectContinue Reading
