The Developer Job Has Moved Up a Layer

I’ve been using AI coding agents heavily enough that something about programming has started to feel different.

I can describe a feature, give the agent the relevant files and constraints, and come back to hundreds of lines of working code. Sometimes I have several agents working on different things at once.

Writing the code is increasingly not the part that takes my time.

Figuring out exactly what I want, giving the agent enough context, and then checking what it did does.

That changes what being a good developer actually means.

Writing Code Is Becoming the Cheap Part

For years, programming ability was relatively easy to recognise.

Give someone a requirement and see how well they could translate it into working code. Experience meant knowing the language, libraries, APIs, patterns and all the strange little things that eventually become instinct.

AI hasn’t made any of that knowledge useless.

It has made producing the first version of the code remarkably cheap.

When an agent can produce an implementation in minutes, the difficult question becomes whether you told it to build the right thing in the first place.

There’s an important distinction here.

All tests passed.

is not necessarily the same as:

This does what I wanted.

AI is very good at confidently satisfying the first condition while completely misunderstanding the second.

Vague Requirements Are Now Expensive

This has become especially obvious to me when working with coding agents.

“Add user permissions” sounds like a perfectly reasonable instruction until the agent starts implementing it.

Which users?

Which permissions?

What happens to existing accounts? Can administrators override them? What happens when permissions conflict? Does this apply through the API as well? What should happen to content owned by a deleted user?

A human developer would eventually have to answer those questions too.

The difference is speed.

AI can turn an incomplete idea into a substantial implementation before you’ve properly thought through the consequences.

That makes being precise considerably more valuable.

The better I define the problem, architecture, constraints and expected behaviour before asking the agent to touch anything, the less time I spend later discovering that it built something perfectly reasonable that I didn’t actually want.

More Code Means More Code to Review

There’s another problem nobody gets particularly excited about.

AI can generate code much faster than I can review it.

That means the bottleneck hasn’t disappeared. It has moved.

Generating a fresh function or isolated feature is one thing. Modifying a mature codebase is something else entirely.

A real project contains years of decisions that aren’t necessarily documented anywhere. Naming conventions, odd workarounds, architectural compromises, dependencies and things that look stupid until you discover the very good reason someone did them eight years ago.

An AI agent doesn’t automatically know any of this.

Someone has to provide that context.

Then someone has to verify the result.

The faster code is generated, the more important review becomes.

The Skills I Value Have Changed

I find myself spending less time thinking about syntax and considerably more time thinking about systems.

Where should this feature live?

What should it be allowed to touch?

What information does the agent need before starting?

What assumptions is it making?

What happens when something fails?

And, perhaps most importantly:

Would I have built it this way?

Giving an AI agent good context makes an enormous difference.

So does recognising bad output.

The valuable skill is no longer just knowing how to implement something. It is knowing what should be implemented, what constraints matter, and where the dangerous assumptions are hiding.

You Still Need to Understand the Code

This is also why I don’t believe AI removes the need to learn programming.

If anything, there’s a rather nasty paradox emerging.

AI makes it possible to produce increasingly sophisticated software with less programming knowledge, while simultaneously making programming knowledge more important when something goes wrong.

The person accepting the pull request still owns it.

If an agent introduces a security vulnerability, corrupts some data or creates a wonderfully elegant abstraction that nobody can maintain six months later, “the AI wrote it” isn’t much of a defence.

My rule has become quite simple:

Don’t ship code you can’t explain.

That doesn’t mean I need to personally write every line.

It means I should understand why it’s there.

The Job Has Moved Up a Layer

We’ve seen versions of this before.

Developers moved from assembly to higher-level languages. Frameworks removed enormous amounts of repetitive application code. Cloud platforms abstracted away infrastructure that once required specialist knowledge.

Each time, some part of the job became easier.

The developer didn’t disappear.

We simply started working one layer higher.

AI coding agents feel like another one of those transitions, albeit a particularly fast one.

I don’t think the best developer over the next few years will be the person capable of producing the most code.

AI has made that a rather pointless competition.

The valuable developer will be the one who knows what should be built, can explain it precisely enough for humans and machines to understand, and can recognise when the resulting software is wrong.

Writing code still matters.

Knowing what code should exist matters more.