The Double Left Shift: The Software Engineer After AI

A few years ago, being a software engineer was, in many ways, synonymous with writing code.

You had a problem. You opened your editor. You searched through documentation, tried a few things, fought with an error for two hours, found an old Stack Overflow answer, changed three lines, and somehow got it working.

I know this because I have done it more times than I can count.

Then AI came along.

Today, I can describe a problem in plain English and have an AI generate a solution in seconds. I can ask it to write tests, explain code I don't understand, find a bug, refactor a function, or help me think through an approach.

And honestly, it still feels unreal sometimes.

Because if a machine can do so much of the work that we once considered software engineering, what exactly are we supposed to do?

The obvious answer is that we will write less code.

The more uncomfortable answer is that perhaps we will need fewer people to write that code.

But I don't think that's the most interesting thing happening.

I think something else is happening.

The job of the software engineer is slowly moving to the left.

Not away from engineering, but closer to the beginning of the problem.

And I call this the Double Left Shift.

The Engineer We Thought AI Would Replace

When AI started getting really good at writing code, the conversation around software engineering became surprisingly predictable.

“Developers will be replaced.”

“Why would a company need ten engineers when AI can do the work of ten?”

“Coding is finished.”

I understand why people thought this.

For a long time, writing code was one of the most visible parts of being a software engineer. If you could write good code, debug it, and ship it, you were doing your job.

So naturally, when a machine suddenly became capable of writing that code, it felt like it was coming for the job itself.

But there was a problem with this way of looking at it.

We confused the output of engineering with engineering itself.

Code is the output.

Engineering is everything that happens before, around, and after that code.

Someone still has to figure out what problem is actually worth solving.

Someone has to decide what the system should look like.

Someone has to understand the constraints.

Someone has to decide whether the AI-generated solution is actually a good solution.

And when that solution brings down production at 3 AM, someone has to understand why.

This distinction became much clearer to me as I started using AI in my own work.

The interesting part wasn't simply that AI could write code faster.

It was that it changed where I spent my time.

Tasks that used to take an hour could take ten minutes.

Things I would normally search for could be explained to me.

Ideas that would have remained in my head because they were too tedious to implement could suddenly become prototypes.

And that made me wonder:

If AI keeps making implementation cheaper and faster, where does the engineer's value move?

That is where the idea of the Double Left Shift begins.

First, What Does “Left Shift” Even Mean?

If you've worked in software for a while, you've probably heard the phrase “shift left.”

The basic idea is simple: find problems earlier.

Instead of waiting until the end of the development cycle to test the software, you start testing much earlier.

Instead of discovering a security problem after deployment, you think about security while designing the system.

Instead of finding out that a feature doesn't make sense after spending weeks building it, you try to validate the idea earlier.

The reason is pretty obvious.

The earlier you find a problem, the cheaper it usually is to fix.

If you find a bug in production, you might have an incident, angry users, a rollback, and a long night ahead of you.

If you find the same problem during development, you might just change a few lines of code.

That was the first left shift.

We started moving important engineering activities closer to the beginning of the software development process.

So What Is the Second Left Shift?

AI changes something slightly different.

It doesn't just help us find problems earlier.

It makes the implementation itself much cheaper.

Writing a function, creating a test, generating a Terraform configuration, writing a SQL query, or building a prototype can now happen in minutes rather than hours.

And when implementation becomes cheaper, something interesting happens.

You can afford to spend more time before implementation.

You can explore more ideas.

You can throw away bad approaches earlier.

You can ask, “What is the simplest way to solve this?”

You can prototype an architecture before committing to it.

You can spend more time understanding the problem instead of immediately jumping into the code.

And that is the second left shift I am interested in.

The engineer moves further left — from writing the solution toward defining and shaping the solution.

The code doesn't disappear.

But it becomes less of the bottleneck.

What AI Is Actually Doing

So what has actually changed?

Not as a prediction. Not as a headline.

What has changed when you sit down to do your job?

For me, the biggest change isn't that AI writes code.

It's that the cost of trying something has gone down dramatically.

Imagine you need to solve a problem you've never seen before.

Before AI, you might spend an hour searching through documentation, GitHub issues, blog posts, and Stack Overflow. Then you'd try an approach, hit an error, search again, and slowly piece together a solution.

Now I can have a conversation about the problem.

I can ask:

“What are the possible approaches here?”

“What are the trade-offs?”

“Show me how this would work.”

“What am I missing?”

“Now challenge this approach.”

And only then start writing the actual code.

That's a subtle but important change.

AI has made the feedback loop much shorter.

You can go from an idea → to an implementation → to a critique → to another implementation incredibly quickly.

And this isn't limited to writing application code.

AI can help with tests, documentation, SQL, scripts, configuration, debugging, log analysis, code reviews, and understanding unfamiliar systems.

But there is an important catch.

AI can give you an answer very quickly.

It cannot guarantee that the answer is the right answer for your situation.

That distinction matters.

I can ask an AI to generate a Kubernetes configuration. It can produce perfectly valid YAML. But whether that configuration makes sense for my infrastructure, my reliability requirements, my security model, and my team's operational reality is a different question.

The machine can generate.

I still have to judge.

And this is where I think the role of the engineer starts becoming more interesting.

We're moving from:

“How do I write this?”

toward:

“Should I build this?”

And then:

“What is the right way to build it?”

That might sound like a small change.

I don't think it is.

Is Using AI Bad Engineering?

There is a part of me that sometimes wonders if using AI this much is actually making me a worse engineer.

If AI writes the code, am I really learning?

If AI finds the bug, am I getting better at debugging?

If I ask AI how something works every time I get stuck, will I eventually stop knowing how to figure things out myself?

I think these are legitimate questions.

And I don't think the answer is simply “AI is good” or “AI is bad.”

It depends on how you use it.

There is a difference between using AI to avoid thinking and using AI to think better.

If I give AI a problem, copy whatever it produces, and move on, I've probably saved time.

But I've also learned very little.

Worse, I might now be responsible for code I don't understand.

That's dangerous.

The other way of using AI is very different.

I can ask it to explain an unfamiliar concept.

I can propose my own solution and ask it to find weaknesses.

I can ask for three different approaches and compare their trade-offs.

I can use it to generate the boring parts while spending my time understanding the interesting parts.

I can even deliberately disagree with it.

And sometimes that's the most useful part of the conversation.

For me, the rule is becoming fairly simple:

Don't outsource your understanding. Outsource the work that doesn't require your understanding.

The moment I stop being able to explain why something works, I've probably handed over too much.

AI should make me faster.

It shouldn't make me unnecessary to myself.

How I Actually Use AI as an Engineer

I don't have a perfect system for using AI.

I'm still figuring it out.

But over time, I've noticed that I use it less like a code generator and more like a second pair of eyes.

When I'm working on something unfamiliar, I'll often start by explaining the problem to AI before touching the code.

Not because I expect it to solve the problem for me.

I want to see how it frames the problem.

Sometimes it points out something I hadn't considered. Sometimes it gives me an approach I hadn't thought about. And sometimes it gives me an answer that is completely wrong.

All three can be useful.

If the answer is good, I have another direction to explore.

If it's wrong, I have to figure out why.

That process itself forces me to understand the problem better.

I also use AI for the things that tend to interrupt the flow of engineering:

• explaining unfamiliar code

• generating repetitive code

• writing initial tests

• turning an idea into a quick prototype

• debugging an error

• summarising documentation

• comparing different approaches

• reviewing something I've written

But there is a boundary I try to keep.

I want AI to participate in my reasoning, not replace it.

I'll often go through something like:

Problem → My initial approach → AI's perspective → Challenge both → Experiment → Verify → Implement

Notice what's missing?

“AI → Copy → Commit.”

That's not engineering.

The interesting thing is that this workflow lets me spend less time on the mechanical parts of software development and more time thinking about the problem itself.

And that brings us back to the larger shift.

If this is how an individual engineer can work today, what happens when this becomes normal?

What kind of engineer does that create?

I think the answer is increasingly the T-shaped engineer.

The T-Shaped Engineer Is Becoming More Important

I've started thinking that the engineers who benefit most from AI won't necessarily be the ones who know the most programming languages.

They'll be the ones who can understand a problem from multiple angles while still having enough depth to know when something is wrong.

This is where the idea of the T-shaped engineer becomes interesting.

The vertical part of the T is depth.

You might be deeply familiar with distributed systems, databases, infrastructure, security, backend engineering, or whatever your area happens to be.

That depth still matters.

In fact, I think AI makes it even more important.

If you don't understand the underlying system, how do you know when the AI is confidently giving you the wrong answer?

The horizontal part is breadth.

You understand enough about the surrounding pieces to connect them.

You might not be a security engineer, but you understand enough security to recognise a bad design.

You might not be a product manager, but you understand the user problem you're solving.

You might not be a database specialist, but you understand enough about data, consistency, and performance to make sensible architectural decisions.

AI makes this breadth more accessible.

You can explore a new domain much faster than before.

You can ask questions that would previously have required hours of reading.

You can build a rough prototype without being an expert in every component.

But there's a catch.

Breadth without depth can make you dependent on AI.

You can ask AI about everything and still understand nothing.

That's why I don't think the future is “everyone becomes a generalist.”

I think it's closer to:

Deep expertise + broad curiosity + AI leverage.

The T-shaped engineer doesn't try to know everything.

They know something deeply, understand the surrounding system, and use AI to extend the reach of both.

And that leads to the harder question.

If AI can increasingly handle the implementation, what is the human actually responsible for?

If AI Can Write the Code, What Is Left for Humans?

This is probably the question underneath all of this.

If AI can write the function, generate the tests, explain the documentation, suggest the architecture, and help debug the system...

What exactly do I bring to the table?

I don't think the answer is that humans are somehow inherently better at everything.

We're not.

AI can already do many things faster than I can.

The difference is that software engineering isn't just about producing an answer.

It's about deciding which question is worth answering in the first place.

Imagine someone asks:

“Can we build a system that does X?”

AI can probably help you build it.

But should you build it?

What problem does X actually solve?

Who needs it?

What happens if it fails?

How much should it cost?

What are we giving up by choosing this approach?

Is there a simpler solution?

These aren't questions that disappear because AI got better at writing code.

If anything, they become more important.

And then there is context.

A piece of code can be technically correct and still be completely wrong for your organisation.

Maybe it adds operational complexity.

Maybe it creates a security risk.

Maybe nobody on the team knows how to maintain it.

Maybe the problem could have been solved with ten lines instead of introducing another service.

AI can give you ten technically plausible solutions.

Someone still has to choose one.

And that choice has consequences.

Someone has to explain the decision to the team.

Someone has to defend it six months later.

Someone has to wake up when it breaks.

Someone has to decide whether to roll back or keep going.

That, to me, is engineering.

Not typing the code.

Owning the outcome.

And perhaps this is the part we have underestimated.

As AI gets better at generating things, the value of simply being able to generate things goes down.

The value of knowing what to generate, why to generate it, and whether it should exist at all goes up.

The code may be produced by a machine.

But the responsibility still belongs to someone.

When Code Becomes Cheap, What Becomes Valuable?

There is something interesting happening here.

For decades, learning to program meant learning how to turn an idea into code.

You learned a language.

You learned data structures and algorithms.

You learned frameworks, databases, operating systems, cloud platforms.

And then you got better by writing more code.

But what happens when the cost of turning an idea into code keeps falling?

I think the bottleneck simply moves.

If everyone can generate a working prototype in an afternoon, the prototype itself isn't very special anymore.

If everyone can generate a REST API, that API isn't the advantage.

If everyone can ask AI to write a thousand lines of code, lines of code become an even worse way to measure engineering productivity.

The scarce thing becomes something else.

Good problems.

Good questions.

Good decisions.

And perhaps most importantly, good judgment.

This isn't entirely new.

A senior engineer has never been valuable simply because they can type faster than a junior engineer.

They're valuable because they've seen enough systems fail to recognise problems before they happen.

They know which complexity is necessary and which complexity is self-inflicted.

They know when a simple solution is enough.

They know when a problem deserves a more sophisticated one.

AI doesn't remove the need for those abilities.

It makes them more visible.

Because when everyone has access to roughly the same powerful implementation tool, the difference increasingly comes from what you choose to do with it.

Maybe that's the real shift.

We're moving from an era where the question was:

“Can you build it?”

to one where the more important questions are:

“Should we build it?”

“What should we build?”

“And what happens after we build it?”

Those questions are harder.

But they're also much more interesting.

Why This Might Actually Be a Great Time to Be an Engineer

For all the anxiety around AI and software engineering, there is another side to this that doesn't get talked about enough.

We have never had this much leverage.

Think about what an individual engineer can do today.

You can have an idea in the morning and have a working prototype by the evening.

You can explore a technology you've never used before without spending days just getting started.

You can ask questions while you're working instead of constantly switching between documentation, forums, and search results.

You can automate the boring parts of your job.

You can experiment with ideas that previously weren't worth the time it would take to implement them.

And perhaps most importantly, you can work across boundaries that used to be much harder to cross.

A backend engineer can explore frontend work.

An infrastructure engineer can build a small internal tool.

A developer can understand enough about data, security, or deployment to make better decisions about the system they're building.

You don't suddenly become an expert in all of these things.

But the cost of exploring them has fallen.

And that matters.

I've always liked the idea of being able to build something from scratch.

AI makes that feeling much stronger.

The distance between “I have an idea” and “I have something working” is getting smaller.

Of course, that also means there will be more software.

More experiments.

More mediocre products.

More code nobody understands.

The tool itself doesn't guarantee good outcomes.

But for an engineer who knows what they are trying to accomplish, the leverage is enormous.

And maybe that's the part we should be paying more attention to.

AI doesn't only give companies a way to do more with fewer resources.

It gives individual engineers the ability to do things that previously required much larger teams.

That is not the end of engineering.

It could be the beginning of a very different kind of engineering.

So, What Should We Actually Do?

After thinking about all of this, I don't think the answer is to panic.

And I don't think it's to become an “AI engineer” overnight either.

The technology will keep changing. The tools we use today might look completely different a few years from now.

What probably matters more is building the kind of foundation that gets more valuable when your tools get better.

1. Learn to use AI

This sounds obvious, but there's a difference between occasionally asking ChatGPT a question and actually learning how to work with AI.

Learn how to give it context.

Learn how to break down problems.

Learn how to ask it to challenge your assumptions.

Learn how to verify what it gives you.

Treat it like a tool you are learning to operate—not an oracle you blindly trust.

2. Go deep somewhere

AI makes it easier to know a little about everything.

That makes genuine depth more valuable, not less.

Pick an area and understand it properly.

Understand what happens underneath the abstractions.

Understand the failure modes.

Understand the trade-offs.

Become the person who can look at an AI-generated solution and say:

“This looks fine, but here's what is going to break.”

3. Get better at defining problems

This might become one of the most important engineering skills.

Don't immediately ask:

“How do I implement this?”

Start asking:

“What problem are we actually solving?”

A poorly defined problem plus excellent AI still produces a poor solution.

4. Develop judgment

You don't need to know everything.

But you need to get better at deciding.

Which architecture?

Which trade-off?

Which technology?

Which shortcut is acceptable?

Which shortcut will hurt us six months from now?

AI can give you options.

You need to develop the judgment to choose between them.

5. Learn to own outcomes

This is perhaps the biggest one.

Don't measure yourself only by the code you write.

Think about what happens after the pull request is merged.

Does the system work?

Is it reliable?

Is it secure?

Can someone else maintain it?

Does it actually solve the problem?

If something goes wrong, can you understand it and fix it?

The engineer who owns the outcome will always be doing something different from the person who simply produces code.

And I think that distinction is going to matter more and more.

The Software Engineer After AI

I started this essay with a fairly simple question:

If AI can write the code, what is left for the software engineer?

After thinking about it, I'm less worried about the answer than I was when I started.

I don't think the software engineer disappears.

I think the job changes.

We've spent decades getting better at turning ideas into software. Now we're building tools that can help us do that part faster than ever.

That means we have to move further upstream.

Understand the problem before solving it.

Think about the system before writing the code.

Question our assumptions.

Explore more possibilities.

Use AI to build faster, but use our own judgment to decide what should actually be built.

That is what I mean by the Double Left Shift.

The first shift moved engineering activities like testing and security earlier in the development process.

The second shift goes further.

As AI makes implementation cheaper, the engineer moves closer to the beginning of the problem—toward understanding, designing, deciding, and owning.

And perhaps that's not something to be afraid of.

Perhaps it's what we've been working toward all along.

Because the best engineers were never the ones who could simply write the most code.

They were the ones who could look at a messy problem and figure out what to do next.

AI might make us write less code.

I think that's okay.

Maybe it gives us more time to do the part of engineering that was always the most human:

To think.