The work is still the same

If you've been writing software for a while, the last couple of years have felt… different.

Tools changed fast. Faster than usual.

Things that used to take effort now take seconds. Things we used to learn deeply are now optional. The editor, the setup, the shortcuts, they're still there, but they're no longer the center of the day.

You can get a lot done without touching the parts of the workflow that used to define it.

And that shift is easy to underestimate at first.

Nothing really breaks. The work still gets done. In many ways, faster. But after a while, it starts raising a more subtle question:

if the way we used to work is no longer the bottleneck, what exactly were we optimizing for all this time?

The subtle identity shift

This isn't a niche concern. It's everywhere.

Every developer I've talked to recently has had some version of this conversation.

Not about whether the tools are useful. That part is already settled.

It's more personal than that.

It's the question that shows up a bit later, once the novelty wears off:

if this isn't the hard part anymore… what was I actually good at?

We spend years learning how to write clean code. Developing an eye for structure. Getting fast, really fast, at navigating a codebase. Going deep into tools. Tweaking setups until they feel just right.

There's a sense of craftsmanship in that. Like shaping something carefully, deliberately.

And now we can just describe what we want, and get something that looks pretty close.

It makes that whole layer feel less important.

I've felt this too.

But that feeling comes from a wrong assumption.

We mistook the surface for the work

Writing code looked like the work.

It's what we spent most of our time doing. It's what others could see. It's what we optimized.

So it became the craft.

But it never really was.

It was just the most visible part.

Now that part got compressed. Not removed, just quieter.

And with less noise, the rest stands out.

What didn't change

We still have to figure out what to build.

That part is still messy. Requirements are vague, incomplete, sometimes just wrong. We still need to ask questions and make sure we actually understand what "done" means.

We still need a clear mental model before starting. Otherwise, we're just getting the wrong result faster.

We still need to break things down. Call it "managing context" if you want, but it's the same discipline. Keep things small enough to reason about and verify.

And we still need to check the result.

It's easy now to get something that runs, passes tests, and still misses the point. The gap between "works" and "is right" didn't go away. It just became more visible.

None of this is new.

It's just harder to ignore now.

Code isn't the point

Code used to feel like the end product.

Now it feels more like a step.

It can be generated, reshaped, replaced. That alone changes how we relate to it.

The value was never the code.

It was solving the problem correctly.

Code was just the medium.

Don't start over

One reaction to all of this is to assume everything changed.

I've caught myself thinking that too.

Like it's time to relearn the job from scratch.

But that's not really what's happening.

The tools changed. The speed changed. The leverage changed.

The process didn't.

If we were good at understanding problems and building systems before, that still applies. More than ever.

If not, the tools won't fix it. They'll just make it visible faster.

The work, stripped down

At the end, it still comes down to the same loop:

Figure out what needs to be built. Make sure we understand it. Break it down. Build it. Check it.

Repeat.

Everything else is just how we get there.