A few years ago, AI in software development meant autocomplete.
You wrote a function, and AI suggested the next few lines.
Then it started generating entire functions.
Then components.
Then tests.
Then features.
Now coding agents can explore repositories, modify multiple files, execute commands, run tests, investigate bugs, review pull requests, and work on tasks for extended periods.
That raises a much bigger question than:
“Will AI replace developers?”
The better question is:
What does software development become when writing the code is no longer the biggest bottleneck?
I think we are beginning to see the answer.
And it may change our job more than autocomplete ever did.
1. We Are Moving From AI Assistance to AI Delegation
The first generation of developer AI mostly assisted you.
You were still doing the work.
Developer
↓
Writes code
↓
AI suggests code
↓
Developer continues
The emerging workflow looks different.
Developer
↓
Defines the problem
↓
Provides context + constraints
↓
AI agent implements
↓
Agent runs tests
↓
Developer reviews
↓
Ship / reject / iterate
That difference is enormous.
The developer is no longer necessarily asking:
"How do I write this function?"
They are increasingly saying:
"Here is the issue. Investigate it, find the root cause, implement the smallest fix, run the tests, and prepare it for review."
That is delegation, not autocomplete.
OpenAI has described the same transition in its research on agentic work: agents are moving from short interactions toward longer tasks involving tools, environments, and multiple steps.
And developer adoption is moving quickly.
JetBrains' 2026 Developer Ecosystem Survey, covering more than 15,000 professional developers, reported that 90% were using AI coding agents at work at least weekly, with 68% using them daily during the May–July survey period.
So this isn't really a discussion about whether developers will use AI.
For many developers, that transition has already happened.
2. Writing More Code Doesn't Automatically Mean Shipping More Software
Here is where things become interesting.
If AI makes us dramatically faster at producing code, shouldn't companies suddenly be shipping software dramatically faster too?
Not necessarily.
A 2026 NBER working paper analyzed data from more than 500,000 GitHub developers.
It found increasingly large increases in coding activity as developers moved from autocomplete to interactive and autonomous coding agents.
But those improvements became much smaller further down the software-production pipeline.
The researchers found a large increase in commits from autonomous coding agents, but a much smaller increase in projects—and an even smaller increase in actual releases.
That exposes something important:
Writing code was never the entire software-development process.
Imagine AI generates a feature in ten minutes.
Great.
But somebody still needs to answer:
- Is this actually what the customer requested?
- Does it fit our architecture?
- Does it break another workflow?
- Are the tests meaningful?
- Is there a security problem?
- What happens under load?
- Does it handle failure correctly?
- Can we maintain it?
- Should this feature exist at all?
AI can help with many of those things too.
But ultimately, software needs to move through a system of decisions, constraints and verification before reaching a real customer.
That system is becoming the new bottleneck.
3. The Developer's Job Moves Up a Level
For decades, programming skill was heavily associated with implementation.
Someone gives you a requirement.
You translate it into code.
But imagine that implementation becomes dramatically cheaper.
The valuable skill moves up the abstraction ladder.
Instead of spending most of the day thinking:
How do I implement this?
more of our time may be spent asking:
What exactly should be implemented?
What constraints must it satisfy?
What context does the agent need?
How should the system be structured?
How do I know the result is correct?
What could fail?
What shouldn't the agent be allowed to change?
This isn't hypothetical anymore.
OpenAI documented an internal experiment where a team built a software product while deliberately writing zero lines of application code manually.
Agents produced the application logic, tests, CI configuration, documentation, observability and internal tooling.
The interesting part wasn't that AI generated the code.
It was what the humans did instead.
OpenAI summarized the model as:
“Humans steer. Agents execute.”
The engineers focused on designing environments, specifying intent and creating feedback loops that allowed agents to work reliably.
That may be one of the clearest previews of where parts of professional software engineering are heading.
4. Context May Become More Important Than Prompts
Developers spent the last few years learning prompt engineering.
I suspect something else will matter much more:
context engineering.
Imagine giving an AI agent this instruction:
Add subscription cancellation.
The agent can probably generate something.
But should it?
A real production system may have:
- billing rules
- refund policies
- database conventions
- API standards
- entitlement logic
- analytics events
- email workflows
- App Store requirements
- authorization boundaries
- existing architecture decisions
Without that context, AI might generate perfectly reasonable code that is completely wrong for your system.
The future AI-friendly repository may therefore need more than clean source code.
It may need machine-readable context around:
Architecture
Business rules
Coding standards
Security constraints
API contracts
Testing expectations
Infrastructure
Product requirements
Historical decisions
We're already seeing this direction in current tooling.
GitHub's Copilot code review, for example, can use repository-specific agent skills and external context through MCP connections to incorporate organizational tools and standards into reviews.
That suggests an important future skill:
Great developers won't just write code clearly for humans. They'll structure systems so both humans and AI can understand them.
5. Verification Becomes a First-Class Engineering Skill
Here is the dangerous part of AI-generated software.
AI can produce code that looks excellent.
The naming looks professional.
The architecture looks reasonable.
There are tests.
There is documentation.
Everything feels finished.
And it can still be wrong.
Google's DORA research found an interesting tension: AI can accelerate initial development, but some of the time saved during creation gets moved into auditing and verification.
DORA also reported that higher AI adoption was associated with both greater delivery throughput and greater delivery instability.
That changes the meaning of developer productivity.
Previously:
Productivity ≈ How efficiently can I implement this?
Increasingly:
Productivity ≈ How effectively can I turn intent
into verified, maintainable production software?
Those are not the same thing.
6. “AI Generated Tests” Is Not Enough
One workflow worries me:
AI writes implementation
↓
AI writes tests
↓
Tests pass
↓
Developer approves
It looks efficient.
But think about it carefully.
If the same misunderstood requirement influences both the implementation and the tests, you can end up with:
Wrong assumption
↓
Wrong implementation
↓
Tests designed around the same assumption
↓
✅ Everything passes
A green test suite doesn't automatically mean the product behaves correctly.
Developers still need independent ways to verify behavior.
That might include:
- acceptance criteria written before implementation
- integration tests
- property-based tests
- security testing
- performance testing
- staging environments
- observability
- real-world user feedback
- independent review
The more code AI can generate, the more important these feedback loops become.
7. We May Write Less Code — But Review Much More of It
There is another simple consequence of AI productivity that doesn't get discussed enough.
Suppose one developer previously produced:
500 lines worth of meaningful changes
during a certain period.
Now that developer can orchestrate several agents that collectively produce:
5,000 lines worth of changes
That's not necessarily a win.
Somebody has to understand those changes.
Somebody has to review them.
Somebody eventually has to debug them.
GitHub says Copilot code review has already handled tens of millions of reviews and represents a significant portion of code reviews on its platform.
GitHub is now pushing that system further with shell-based validation and ensembles of agents that analyze changes.
So we're heading toward an interesting situation:
AI writes code.
AI writes tests.
AI reviews code.
AI investigates failures.
AI suggests the fix.
Which creates a critical engineering question:
Where does independent human judgment enter the loop?
That may become one of the defining software-engineering problems of the AI era.
8. Security Gets Harder When AI Can Act
A chatbot giving you incorrect code is one kind of risk.
An agent with access to:
terminal
filesystem
GitHub
cloud infrastructure
databases
internal documentation
third-party APIs
is something completely different.
The AI is no longer simply generating text.
It can take actions.
Anthropic describes this as a new governance challenge: agents can write and execute code, manage files and operate across applications with less continuous human supervision.
The company also highlights risks such as agents misunderstanding intent and prompt-injection attacks manipulating agents into taking unwanted actions.
That means AI-era engineering needs a security principle we've already learned elsewhere:
Give systems only the permissions they actually need.
For coding agents, that could mean:
Read-only when possible
↓
Sandboxed environment
↓
Limited credentials
↓
Explicit write permissions
↓
Human approval for sensitive actions
↓
Audit logs
↓
Production access only when necessary
The more autonomous development becomes, the more important boundaries become.
9. Architecture Actually Becomes More Important
There's a tempting argument:
"If AI can generate code, architecture doesn't matter as much."
I think the opposite may happen.
If generating another 20,000 lines of code becomes cheap, poorly designed systems can grow incredibly fast.
AI can accelerate good architecture.
It can also accelerate technical debt.
DORA's broader research makes a similar point: AI acts as an amplifier of the engineering environment around it.
Strong systems can become faster.
Weak systems can generate problems faster.
Think of two teams.
Team A
Clear architecture
Good tests
Small modules
Documented APIs
Strong CI/CD
Observability
Clear ownership
Team B
Huge coupled modules
Weak tests
Unknown dependencies
Little documentation
Inconsistent patterns
No clear boundaries
Give both teams a powerful coding agent.
Which one can safely move faster?
Probably Team A.
The AI model might be identical.
The engineering environment isn't.
10. Junior Developers Face a Difficult Question
This transition creates a problem we shouldn't ignore.
How do you become senior if AI performs many of the tasks through which developers traditionally became experienced?
Junior developers learned by:
- implementing small features
- fixing bugs
- reading unfamiliar code
- writing tests
- making mistakes
- receiving code-review feedback
- debugging production issues
If companies automate too much of that work, we risk removing part of the learning ladder.
The answer cannot be:
"Juniors don't need to understand code anymore. Just use AI."
That's dangerous.
You can't reliably review something you don't understand.
Instead, junior developers may need to become good at AI-assisted engineering without outsourcing understanding.
Use the agent.
But ask:
Why did it choose this architecture?
What happens if this API fails?
What database query does this generate?
Where is authorization checked?
Which edge cases are missing?
Could I debug this without the agent?
AI should compress the feedback loop.
It shouldn't eliminate learning.
11. What Should Developers Learn Now?
If I were preparing for the next several years of software development, I wouldn't stop learning programming.
I would broaden what being good at programming means.
1. Learn system design
Understand:
- boundaries
- APIs
- databases
- caching
- queues
- distributed systems
- scalability
- failure modes
AI can propose architecture.
You still need to judge the tradeoffs.
2. Become excellent at debugging
When everything works, generated code looks amazing.
Your value appears when:
"It works locally."
becomes
"Why is production failing for 2% of users?"
3. Learn how to test behavior, not implementations
Don't only ask:
"Did the generated tests pass?"
Ask:
"Do these tests prove the behavior we actually need?"
4. Learn security
Understand authentication, authorization, secrets, injection attacks, dependency risks and privilege boundaries.
AI increases the amount of code we can produce.
Security needs to scale with it.
5. Learn to read code
Writing every line manually may become less common.
Reading unfamiliar code becomes even more important.
6. Understand products and users
AI can build exactly what you request.
Unfortunately, users often don't need what you originally requested.
Understanding the problem becomes more valuable when implementing a proposed solution becomes cheap.
7. Learn to work with agents
Don't just learn clever prompts.
Learn:
Task decomposition
Context management
Agent instructions
Tool permissions
Acceptance criteria
Feedback loops
Parallel delegation
Verification
Those look increasingly like engineering skills.
12. The Future Developer May Look More Like an Engineering Lead
Imagine one developer working with multiple specialized agents.
Developer
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Architecture Feature Agent Test Agent
Agent
│ │ │
└─────────────┼─────────────┘
↓
Review Agent
↓
Human Verification
↓
Production
That developer may spend less time typing implementation code.
But they are not necessarily doing less engineering.
They are:
- breaking problems into tasks
- providing context
- coordinating implementation
- evaluating tradeoffs
- inspecting outputs
- resolving ambiguity
- managing risk
- deciding what ships
In other words, one developer may increasingly operate more like the technical lead of a tiny team—
except some members of that team are AI agents.
13. But Don't Believe the “Developers Are Finished” Narrative Yet
There's another side to this story.
AI development tools aren't universally faster for every developer or every task.
A well-known METR randomized study of experienced open-source developers in 2025 found that developers using the AI tools tested in that experiment actually took 19% longer on their tasks, despite believing AI had made them faster.
Meanwhile, newer 2026 research covering much larger populations reports substantial productivity gains from newer generations of coding agents.
These results aren't necessarily contradictory.
They tell us something useful:
“Does AI make developers faster?” is probably the wrong question.
The answer depends on the model, task, developer, codebase, workflow and how much verification is required.
And these tools are changing incredibly quickly.
14. So What Comes Next?
I don't think the future looks like this:
AI arrives → Developers disappear
And I don't think it looks like this either:
AI is just another autocomplete tool → Nothing really changes
The reality looks more interesting.
We may be moving from:
Humans writing software
with help from AI
toward:
Humans designing systems
and directing AI that produces
larger parts of the implementation
That changes where engineering value lives.
The scarce resource becomes less about typing code quickly and more about:
Judgment
Context
Architecture
Verification
Security
Product understanding
Debugging
Decision-making
Responsibility
Code isn't becoming irrelevant.
Code generation is becoming cheaper.
There's a huge difference.
The Real Skill Shift
For years, developers competed partly on:
“How well can I write this?”
The AI era increasingly asks:
“How well can I define what should be built, guide the system building it, and prove that the result deserves to reach users?”
That is a harder engineering problem than generating code.
And perhaps that's where software development is heading.
Not toward a world with no developers.
But toward a world where the definition of developer changes.
What do you think?
Five years from now, will professional developers still spend most of their time writing code—or will we spend more time directing, reviewing and verifying what AI builds?
Top comments (0)