New Era of Software Engineering

The Code Got Cheaper. The Decisions Didn't.

Software engineering was always a craft. Its beauty was that it sat right at the edge of science — structured enough to reason about, yet never fully reducible to a formula. Building a product was always this blend: part discipline, part judgment call.

For as long as I can remember, engineers and architects took real care to design and build systems properly. The phases were familiar: architecture, design, code, test, deploy.

In practice, architecture and design usually got comparatively little time, while code and test consumed most of it.

When you looked closely at where the real difficulty lived, that balance never quite made sense to me.

Architecture and design are among the hardest and most consequential parts of software engineering. That's where you make decisions that can stay with a system for years. Decisions shaped by business constraints, trade-offs, existing systems, organizational politics, people, budgets, and a dozen other things pulling in different directions.

It's also the work that's most expensive to get wrong and often the most expensive to change later.

So, in theory, it should have deserved the most careful attention.

In practice, it was usually the part of the job that took the least time.

Code was the fun part.

Choosing algorithms, naming variables, figuring out why something wasn't working, chasing down bugs — engineers liked this. At least I did. It's a big part of what many of us signed up for.

That balance held for a long time.

Then autumn 2025 arrived, and things changed quickly.

We're Still Living Through the Shift

We all know the headline version of this story by now:

"Software engineering will be dead. AI will do everything."

I'm living through this shift myself, and my experience has been different from that headline. It's more complicated. In some ways it's better. In some ways it's much more exhausting.

It's been close to a year since I last spent any meaningful amount of my working day writing production code by hand.

That doesn't mean I stopped engineering.

What changed for me wasn't that engineering became easy. It's that the phases started collapsing.

Code and much of the mechanical testing work — the parts we used to spend most of our time on — are largely gone from my day-to-day work.

What's left is architecture and design.

Except architecture and design are no longer occasional, high-leverage activities that happen before implementation.

They are happening constantly.

And that's the part I didn't expect.

The Fun Part Left, and What Remains Is Heavier

Here's the part I think is genuinely underdiscussed:

The most complex work in software engineering has become the most routine work.

Not because it became easier.

Because it became continuous.

AI can produce the implementation incredibly quickly. So you reach the next decision much faster.

Should this be a separate service?

Should this live in the existing service?

Do we use an event or a synchronous API?

Where should the state live?

What's the boundary between these two components?

What happens if this fails halfway through?

How should this behave when the requirement changes six months from now?

Previously, you might spend a significant amount of time implementing something before you encountered the next set of architectural questions.

Now the implementation can be produced almost immediately.

So the questions arrive immediately too.

In practice, this often means having multiple AI sessions open at once, each one working on something different, each one surfacing decisions that need a human call.

There are ways to run these systems in a much more autonomous "auto mode" with guardrails. I think that works reasonably well once you're in a stable maintenance phase — when the architecture is already established, the system's "constitution" is clear, and changes are relatively small and contained.

During active development, I'm not convinced we're there yet.

Every session can become a new set of trade-offs.

And that's where the cognitive load comes from.

It's not necessarily the amount of code being written.

It's the number of decisions being made.

The Decision Loop

I think this is the biggest change AI has brought to software engineering.

The unit of work used to be something like:

Understand → design → code → test → review.

Now it increasingly looks like:

Decide → delegate → evaluate → correct → decide again.

The implementation part has become cheap.

The decision part hasn't.

In fact, because implementation is so cheap, we're making decisions at a much higher velocity.

And I don't think our brains, teams, or engineering processes have really caught up with that yet.

This is also where I think the experience gap becomes interesting.

If you're early in your career, you may suddenly be expected to make decisions that historically came much later in your career.

A junior engineer could previously spend years writing code, debugging it, seeing how systems behaved in production, dealing with bad abstractions, refactoring things, and slowly building the intuition needed to make better architectural decisions.

Now AI can give you an architecture before you've developed the ability to judge whether that architecture is actually good.

That's a real risk.

The problem isn't that AI gives inexperienced engineers answers.

The problem is that it can give them answers before they've developed the ability to evaluate those answers.

If you're experienced, the problem is different.

You can usually spot the bad decisions.

But that means you're spending your day reading AI-generated output, evaluating it, making a decision, switching to another session, evaluating something else, and repeating that cycle dozens of times.

It's a different kind of tiring than writing code.

It's more like constant context switching under evaluation pressure.

And, in my experience, it can make the job less enjoyable rather than more.

The Maintenance Problem Became the Development Problem

There's another irony here.

Many software engineers, in my experience, have historically preferred building something new to maintaining something that already exists.

Maintenance meant understanding somebody else's code, fixing things you didn't design, dealing with edge cases, and making small changes without breaking something else.

Now AI has made the development phase start to feel a little like that.

You're constantly reviewing generated code.

You're constantly checking what somebody — or something — else decided.

You're constantly asking whether the implementation actually matches the intent.

Except now the volume and speed are much higher.

A codebase that once required months of implementation effort can now be generated, modified, or substantially expanded in days.

But the cost of understanding and governing that code hasn't disappeared.

And this is where I think we're going to run into problems.

The speed of generation has outpaced our ability to validate, understand, and evolve what's being generated.

I don't think that gap is necessarily permanent.

But right now, it's real.

The Obvious Counterargument

The fair pushback here is:

Isn't this just a skill issue?

Maybe we simply need better prompting discipline, better review practices, better testing, better context management, and better guardrails around AI-generated changes.

I think there's a lot of truth in that.

I'm sure tooling will get better at managing multiple AI sessions. I'm sure we'll get better at defining boundaries around what agents are allowed to change. Organizations will probably develop clearer processes around ownership and review.

And engineers are pretty good at solving exactly this kind of problem once we've identified it.

There's also a stronger counterargument.

Maybe this is simply what software engineering was always supposed to become.

Why should highly paid engineers spend most of their time typing boilerplate code if machines can do it?

Maybe moving engineers up the abstraction ladder is exactly the point.

I actually agree with that.

I don't want to go back to spending my day writing boilerplate code just because it feels more like "real engineering."

But I think there's a difference between moving up the abstraction ladder and accelerating the ladder itself.

AI hasn't just removed implementation work.

It has increased the speed at which we encounter engineering decisions.

And when the highest-stakes decisions in the discipline also become the highest-frequency decisions, the cognitive load changes.

That's not something better prompting alone can completely solve.

It probably needs better tools, better processes, and perhaps even a different way of organizing software teams.

Where I Think This Goes

I'll be honest: this is a personal read on a moving situation, not a settled conclusion.

I could be completely wrong about parts of this.

Maybe the tooling will get dramatically better over the next year. Maybe autonomous development will become much more reliable. Maybe we'll develop completely new ways of managing AI-driven engineering that make today's workflow look primitive.

I actually expect a lot of that to happen.

Engineers are historically pretty good at fixing exactly the kind of problems I'm describing.

But I don't think the transition is going to be painless.

For a while, I expect software engineering to be less fun for some people, more cognitively demanding, and possibly frustrating in ways we haven't fully understood yet.

And I think there is a real possibility that some people will move away from engineering because the part they enjoyed most — actually building things — has changed so dramatically.

Maybe that's temporary.

Maybe it's not.

I'm going to mark this post and come back to it in exactly a year.

By then, we'll have a better idea whether this was just an awkward transition period or the beginning of a fundamentally different way of doing software engineering.