Imagine a junior developer joining a software company in 2016.

On the first day, they are given a bug.

Nothing complicated.

A null reference somewhere inside an old service.

They open the code.

Set a breakpoint.

Run the application.

Inspect variables.

Read the stack trace.

Follow the execution.

Search the documentation.

Try something.

Fail.

Try again.

Eventually, after two hours, they discover the problem.

A tiny condition was wrong.

They fix it.

The pull request contains three changed lines.

Those two painful hours taught them something.

Not just how to fix that bug.

They learned how the application behaved.

How the debugger worked.

How objects moved through memory.

How exceptions propagated.

How to search.

How to form a hypothesis.

How to prove themselves wrong.

Now imagine the same developer entering the industry today.

The bug appears.

They copy the exception into an AI coding assistant.

Fix this.

Seconds later:

I found the issue.

The problem occurs because...

A patch appears.

The tests pass.

The developer accepts it.

Ticket closed.

Twenty minutes instead of two hours.

Progress?

Absolutely.

But something uncomfortable has happened.

The first developer spent two hours building a mental model.

The second spent twenty minutes obtaining a solution.

And software engineering is beginning to ask a strange question:

If AI increasingly writes the code, who is learning how the code actually works?

---

Then Came "Vibe Coding"

In 2025, Andrej Karpathy popularized a wonderfully provocative phrase:

vibe coding.

The idea was almost absurdly simple.

Stop obsessing over every line.

Describe what you want.

Let the AI generate it.

Run it.

See what happens.

If something breaks, paste the error back into the AI.

Ask it to fix the problem.

Repeat.

Eventually the software works.

For prototypes and personal projects, this can feel like magic.

A person who previously could not build a web application can suddenly say:

Create a dashboard.

Add authentication.

Connect PostgreSQL.

Make a customer page.

Add filtering.

Fix that error.

Make it prettier.

And something appears.

The distance between an idea and working software has collapsed.

That is extraordinary.

It may be one of the biggest changes programming has experienced since high-level languages replaced assembly.

But there is a difference between:

software that appears to work

and:

software someone understands well enough to maintain.

That difference is where the story becomes interesting.

---

The New Developer Has a Superpower

Consider what an AI-assisted programmer can accomplish today.

Need a Dockerfile?

Ask.

Need a React component?

Ask.

Need an EF Core query?

Ask.

Need a Redis implementation?

Ask.

Need a Kubernetes manifest?

Ask.

Need an unfamiliar cryptography library?

Ask.

Need a regex nobody wants to write?

Definitely ask.

Modern coding assistants can remove enormous amounts of repetitive work.

Developers clearly see value in them. Stack Overflow's 2025 Developer Survey found AI development tools had become mainstream, although confidence in their output remained considerably weaker than adoption. (Stack Overflow Developer Survey)

This is not going away.

Nor should it.

Few programmers today would voluntarily abandon:

IntelliSense
debuggers
Git
package managers
IDEs
high-level languages

because previous generations had to work without them.

AI is another tool in that long progression.

The problem is not that programmers are using AI.

The problem begins when:

the tool performs work the programmer could no longer perform without it.

---

When "Generate" Replaces "Understand"

Imagine AI generates this:

public async Task ProcessOrderAsync(Order order)
{
    // 120 lines...
}

It compiles.

Tests pass.

The developer looks quickly through it.

Seems reasonable.

Merge.

Six months later, production behaves strangely.

Orders are occasionally processed twice.

Someone asks:

"Why does this happen?"

The engineer who generated the code opens it.

Then stares.

Because there is a huge difference between:

recognizing code

and:

understanding code.

You can read a locking mechanism and think:

Yes, that makes sense.

But could you have designed it?

Could you explain the race condition?

Could you predict what happens when two pods execute simultaneously?

Could you prove that retries are safe?

Could you recognize the failure mode when Redis disappears?

AI can produce sophisticated-looking code extremely quickly.

That means developers can now create complexity faster than they can necessarily understand it.

---

Senior Developers Enter the Story

Picture a pull request.

+2,700 lines

The feature took a junior developer one afternoon.

AI generated:

repository
service
DTOs
tests
caching
retry logic
background processing
validation

On the surface, productivity looks incredible.

Then a senior developer begins reviewing it.

Why is this transaction here?

Why is this service registered as singleton?

This retry isn't idempotent.

This query loads the whole table.

This token is never cancelled.

These two classes duplicate the same business rule.

That exception is swallowed.

This test isn't testing what its name says.

This abstraction is unnecessary.

The junior developer produced 2,700 lines quickly.

The senior developer now spends hours determining which lines are safe.

This concern is not purely hypothetical. Research has begun examining whether AI-assisted development can shift more review and rework onto experienced maintainers. One 2025 study of open-source development found increased rework following Copilot adoption and a larger review burden on experienced core developers. (arXiv)

Suddenly we have a strange productivity equation:

Junior saves 4 hours.

Senior spends 5 hours verifying the result.

The company generated more code.

Did it become more productive?

That is a different question.

---

The Verification Tax

AI changes the economics of programming in a fascinating way.

Historically, writing code was expensive.

Reviewing it was usually cheaper.

Now generating code can be nearly free.

That means verification becomes the expensive part.

The Stack Overflow 2025 survey found more developers distrusted AI tool accuracy than trusted it, with experienced developers especially cautious. (Stack Overflow Developer Survey)

This makes sense.

An experienced developer does not merely ask:

Does this compile?

They ask:

What happens under concurrency?

What happens under failure?

What happens with 10 million rows?

What happens when this request retries?

What happens when the user is malicious?

What happens when the network disappears?

What happens six months from now?

AI can generate a plausible implementation.

Engineering begins after plausibility.

---

The Strange METR Experiment

In 2025, METR ran an interesting randomized study.

Experienced open-source developers worked on real tasks in repositories they already knew well.

Some tasks allowed AI tools.

Others did not.

The surprising result was that, with early-2025 AI tools, the experienced developers took about 19% longer when using AI—even though they expected AI to make them faster. (Metr)

That does not mean AI coding makes everyone slower.

The study had specific developers, projects, and tools.

And the technology has continued evolving rapidly; METR's 2026 follow-up described newer results that were less negative and potentially moving toward speedups, though with substantial uncertainty. (Metr)

But the original result revealed something important.

Generating code is not the whole job.

Developers also spent time:

prompting
waiting
reading
correcting
reviewing
rejecting
understanding

The AI produced work.

Humans still had to determine whether that work belonged in the system.

---

The Apprentice Problem

There is an older model of becoming a programmer.

You begin with simple work.

You make mistakes.

Senior developers review them.

You learn.

Eventually the patterns become intuition.

This is similar to apprenticeships in other professions.

A young mechanic begins with basic jobs.

A junior accountant learns simple accounts.

A medical trainee learns progressively under supervision.

Programming worked similarly.

Junior developers often learned through tasks that were repetitive:

CRUD endpoints
simple queries
validation
unit tests
small bug fixes
refactoring

But those are exactly the tasks AI handles extremely well.

So we may be creating a strange problem.

AI removes the boring work.

Wonderful.

But some of the boring work was also training.

How does someone become a senior developer if they never struggle through the problems that created today's senior developers?

---

"I Know What the Code Does"

Ask someone what a generated function does.

They read it.

Then explain:

It validates the request, queries the database, processes the results, and returns the response.

Good.

Now delete it.

Ask them to recreate it without AI.

Suddenly the difference between understanding and familiarity becomes visible.

This is not unique to AI.

Developers have always copied from Stack Overflow.

They have always used libraries they only partially understood.

They have always inherited code from colleagues.

But AI changes the scale.

Stack Overflow usually gave you 15 lines.

AI can generate an entire architecture.

That means the amount of software a person can own without deeply understanding it has increased dramatically.

---

The Dangerous Phrase: "It Works"

A vibe-coded application runs.

The page loads.

The button works.

Data appears.

Excellent.

But production engineering asks a crueler set of questions.

Is it secure?

Is it observable?

Is it transactional?

Is it idempotent?

Does it leak resources?

Does it handle cancellation?

What happens during partial failure?

Will it survive concurrency?

Can someone debug it at 3 AM?

Can the company modify it three years later?

These questions rarely appear in a demo.

They appear after customers arrive.

And this is why "working code" and "production software" have always been different things.

AI has made working code extremely cheap.

It has not made production complexity disappear.

---

But Senior Developers Are Vibe Coding Too

This story would be misleading if we pretended vibe coding belonged only to juniors.

Experienced engineers use AI heavily too.

The difference is often in how they interact with it.

A senior developer might say:

Implement this using optimistic concurrency.

Do not hold the transaction during the external call.

Make the operation idempotent.

Use cancellation tokens throughout.

Do not materialize the IQueryable before filtering.

Add tests for concurrent execution.

AI writes the code.

But notice where the intelligence came from.

The developer already knew:

optimistic concurrency
transactions
idempotency
cancellation
query execution
race conditions

AI accelerated implementation.

It did not replace understanding.

This may become one of the defining differences between strong and weak AI-assisted programmers.

One asks:

Build this.

The other says:

Build this under these constraints, because I understand the failure modes.

Both are using AI.

Only one is delegating from a position of knowledge.

---

AI Is an Amplifier

Google's 2025 DORA research described AI's effect on software organizations as more like an amplifier than a universal cure: it can magnify the strengths of effective engineering systems as well as the weaknesses of poorly functioning ones. (Dora)

That framing fits programming surprisingly well.

Give AI to an experienced engineer.

They can generate:

experiments
tests
boilerplate
migrations
documentation
refactoring candidates

at extraordinary speed.

They recognize bad output quickly.

They know where to inspect carefully.

They understand when the AI is hallucinating.

Give the same tool to someone with almost no fundamentals.

They may generate even more code.

But they have fewer tools for determining whether it is correct.

AI amplifies both capability and ignorance.

---

The Skill May Be Moving Upward

Perhaps programming is not disappearing.

Perhaps the abstraction level is moving again.

Once programmers wrote machine instructions.

Then assembly.

Then C.

Then garbage-collected languages.

Then frameworks.

Then cloud platforms.

At every transition someone could reasonably say:

Developers don't understand what the machine is doing anymore.

And they were partly right.

Most web developers today cannot manually manage CPU registers.

They do not need to.

We traded low-level knowledge for the ability to build much larger systems.

AI may be another abstraction layer.

Instead of:

foreach (var customer in customers)
{
    ...
}

perhaps tomorrow we increasingly express:

Find customers whose purchasing activity has declined
by more than 20% over the last quarter and produce
a retention report.

The machine handles implementation.

The human handles intention.

That could be progress.

---

But Every Abstraction Needs Someone Who Understands Below It

Most developers do not understand CPU microarchitecture.

But somebody does.

Most developers do not implement TCP.

But somebody understands TCP.

Most developers do not write database engines.

But database engineers exist.

Abstraction works because knowledge does not disappear.

It becomes specialized.

The danger with AI would be different.

Imagine an industry where:

almost everyone can generate software

but:

almost nobody can explain why it works.

Then when the abstraction fails, who goes underneath?

Who debugs the generated distributed system?

Who identifies the deadlock?

Who understands the query planner?

Who recognizes the memory corruption?

Who notices that the architecture itself is wrong?

We still need people capable of descending through the abstraction layers.

Perhaps fewer people.

But probably more valuable ones.

---

The Last Generation?

So are today's developers the last generation who truly know how to code?

Probably not.

But we may be among the last generations for whom manually writing most implementation code was the default way to become a programmer.

That distinction matters.

Tomorrow's programmer may spend less time typing:

for
if
class
SELECT

and more time:

designing
reviewing
testing
modeling
specifying
debugging
verifying

The job may move from producing code toward controlling the production of code.

That could make software engineering more powerful.

But only if we preserve the knowledge required to judge the output.

---

The Senior Developer of 2035

Imagine a developer ten years from now.

They open an empty repository.

Instead of writing code, they describe a system.

AI agents begin working.

One builds the API.

Another creates the frontend.

Another writes migrations.

Another generates tests.

Thousands of lines appear.

The developer watches.

Then stops one agent.

No. That boundary is wrong.

Another.

This operation cannot be retried safely.

Another.

You're coupling the domain to the storage model.

Another.

This query will collapse at our expected scale.

They may personally write almost nothing.

Yet they understand everything important.

Are they still a programmer?

I would argue:

Yes.

Perhaps more than ever.

Because programming was never fundamentally about typing syntax.

It was about constructing precise mental models of systems.

---

Don't Stop Learning to Code Yet

AI should write code for us.

Let it generate boilerplate.

Let it explain unfamiliar libraries.

Let it build prototypes.

Let it produce tests.

Let it eliminate hours of repetitive work.

But there is one dangerous habit worth resisting:

AI wrote it.
Tests passed.
Therefore I don't need to understand it.

That is where engineering starts turning into gambling.

Use AI aggressively.

But read the generated code.

Debug it.

Question it.

Ask why.

Learn what the solution is doing.

Occasionally solve difficult problems without it.

Keep the muscles alive.

Because someday the AI will produce something that looks perfectly reasonable...

and is completely wrong.

At that moment, the most valuable person in the room will not be the person who can write the best prompt.

It will be the person who can look beneath the generated code and say:

"I know what's happening."

Maybe vibe coding really is taking over.

Maybe future developers will rarely begin with an empty editor.

Maybe thousands of lines will increasingly arrive before anyone manually writes the first one.

That future is not necessarily frightening.

It could be extraordinary.

But only if we remember one thing.

The goal was never to know how to type code.

The goal was to know how software works.

If we lose the first skill, technology has evolved.

If we lose the second...

then eventually someone will have to clean up the mess.