The People Who Built the Old Way

There’s a particular kind of excitement happening in software engineering right now that I don’t think I’ve experienced quite like this before. People (not just engineers)—real, everyday people—are building things at an absurd pace.

Someone has an idea, opens an AI coding agent, starts describing what they want in plain English, and a few hours (or even minutes!) later, has something working. It might not be production-ready or necessarily elegant, and it might possibly be full of problems they don’t know about yet, but it works. Sometimes surprisingly well.

And… it’s fun. Like, really fun.

I’ve watched people get almost visibly high on the possibilities. They start experimenting with one thing, realize they can do something else, and suddenly it’s midnight and they’ve built three applications and are wondering whether they even need a software development team anymore.

The thing is I get it. I get swept up in it too.

There’s something genuinely thrilling about watching the distance between an idea and a functioning thing get smaller. Things that previously required specialized skills, months of effort, or a team of engineers are becoming accessible to people who might never have written a line of code. And I think that’s extraordinary.

But there’s a point in some of these conversations where the excitement starts to turn into something else. Someone says that traditional software engineering is dead. That the old ways of working are obsolete. That software developers are becoming irrelevant, and organizations still employing people to write code are simply refusing to accept the future.

And at this point is where I start getting annoyed. But funny enough, it’s not because I think they’re entirely wrong…

The expertise doesn’t just disappear

I haven’t written code professionally on a daily basis in a few years. My work has gradually moved further away from implementation and toward the people, systems, and decisions surrounding it. So when someone declares that software engineers are obsolete, I’m not particularly worried about my own ability to keep writing code for a living. But I do find myself feeling oddly protective of the people who do.

People who have spent ten, fifteen, twenty years learning a craft—who understand things about software that are difficult to explain to someone who has never had to build and maintain it. People who have spent entire careers learning how systems fail, why seemingly reasonable technical decisions become terrible ones six months later, and what it takes to make something reliable outside the very controlled environment of a demonstration.

And now, someone who discovered AI coding agents three weeks ago can build a surprisingly capable application and announce that all of that expertise is irrelevant.

There’s something a little ridiculous about that.

And it’s not the application because the application might be excellent. It’s the confidence. The assumption that because the barrier to producing software has fallen, the knowledge accumulated by the people who spent their careers producing it must have lost its value too.

Maybe some of it has.

I think we should be willing to admit that. Certain technical skills are probably becoming less economically valuable, and I don’t think pretending otherwise does anyone any favors. But software engineering was never just the act of typing code into a computer. It involved understanding problems, designing systems, making tradeoffs, reasoning through complexity, and anticipating what could go wrong. Some of that work is being automated and some of it is becoming easier. Some of it, however, may become more important precisely because producing code is no longer the hardest part.

If we can generate software faster than we can understand, evaluate, and maintain it, we’ve simply moved the bottleneck. And I wonder whether some of the expertise we’re so quick to declare obsolete is exactly what we’ll need on the other side of that bottleneck.

The two camps

What’s particularly strange is that people working in the same organization, sometimes on the same team, can be experiencing this transformation completely differently.

There’s one group that’s experimenting constantly. They’re adopting AI tools, building agentic workflows, challenging established processes, and discovering that work they once thought would take weeks can sometimes be accomplished in days.

Some of them are truly having the time of their lives. And then there’s another group that’s more hesitant.

Maybe they’re skeptical of the quality of AI-generated software. Maybe they’re concerned about security, maintainability, or the increasingly blurry line between something that works and something that’s actually engineered well. Maybe they’re worried about their careers. And maybe some of them just don’t particularly want to spend every evening experimenting with the technology that might eventually replace parts of their jobs.

I think it’s tempting to divide these people into innovators and resistors. The future and the past. People who get it and people who don’t.

But I don’t think that’s quite right.

Some of the most enthusiastic AI adopters are experienced engineers who understand exactly what the technology is doing and where it falls short. Some of the most cautious people are identifying legitimate problems that everyone else is too excited to notice.

And some people on both sides are probably just being stubborn.

What interests me to no end is how quickly these differences can become cultural. The enthusiastic group starts interpreting caution as resistance. The cautious group starts interpreting enthusiasm as recklessness. People begin questioning not just each other’s technical decisions, but each other’s competence. And suddenly, the disagreement isn’t really about which tools to use anymore. It’s about what it means to be good at your job.

Which is a pretty personal thing to disagree about, especially when the definition of your job is changing underneath you.

I don’t think everyone needs to be excited

There’s an argument I hear regularly, sometimes explicitly and sometimes implied, that people who aren’t keeping up with AI simply need to get with the times.

“The tools are available.”

“The information is everywhere.”

“Nobody is stopping you from experimenting.”

And to an extent, I agree.

I don’t think organizations can afford to wait indefinitely for everyone to become comfortable with a technological shift this significant. I don’t think someone should be guaranteed that their profession will look the same in twenty years because they’ve invested twenty years learning it.

But I also think there’s a strange lack of empathy in expecting everyone to experience the same transformation with the same enthusiasm.

Some people are naturally drawn to uncertainty. They enjoy experimenting with things they don’t fully understand. They see an unfamiliar tool and immediately want to figure out what they can do with it.

I’m often one of those people, too. But not everyone works that way.

Some people want to understand where they’re going before they start moving. Some want evidence that a new approach is actually better. Some have spent years becoming excellent at a particular discipline and aren’t immediately thrilled to hear that the definition of excellence is changing. And some are probably scared, and not irrationally either.

We’re talking about people’s livelihoods. Their careers. And in some cases, a significant part of how they understand their own competence and value.

I don’t think we need to protect everyone from that reality but surely we can be human about it.

What does adapting actually mean?

We talk a lot about the need for people to adapt to AI but I’m not sure we’re always very good at explaining what we’re asking them to adapt to.

Imagine you’ve spent fifteen years becoming a good software engineer. You’ve developed deep technical instincts, learned how to work through difficult problems, and built a career around being someone who knows how to make software work. And now you’re told that AI is fundamentally changing your profession.

Okay.

What are you supposed to do on Monday?

Learn prompting? Start building agents? Stop writing code yourself? Become a systems architect? Spend your time reviewing code generated by a machine? How do you know which parts of your expertise are still valuable, which ones are becoming less relevant, and which entirely new skills you should be developing?

And who’s supposed to tell you?

The people running the organizations employing these engineers are still figuring much of this out themselves.

I certainly don’t have all the answers.

But I wonder whether we’ve been too quick to treat adaptation as an individual responsibility without considering what responsibility organizations have to make that adaptation possible. Not necessarily to guarantee that everyone will succeed or to preserve every job in its current form. But to give people a meaningful opportunity to move with the change. To make the emerging paths visible enough that people can decide whether and how they want to pursue them. Because there’s a difference between someone refusing to change and someone not knowing what changing is supposed to look like. And I suspect we’re sometimes treating those as the same thing.

The uncomfortable part

I should probably acknowledge that this is easier to write about than it is to do.

I’m in a position where I get to think about how engineering organizations should evolve. How teams might become more effective. What work AI can take on, what skills become more important, and whether the structures we’ve relied on for years still make sense.

I find those questions genuinely exciting.

I also know that some of the answers may be uncomfortable for the people working within those structures.

And I don’t get to avoid that discomfort just because I happen to care about the people involved.

There may come a point where the changes I believe are necessary are the same changes someone else experiences as a threat to the career they’ve spent years building. I can try to make that transition more understandable, give people opportunities to adapt, and be thoughtful about how decisions are made. But I can’t promise that everyone will like where we’re going, or that everyone will want to come along. And I don’t know exactly what to do with that yet.

I can be excited about a future in which a small team can build something extraordinary with AI, while also feeling uncomfortable when someone casually dismisses the careers of the people who made that kind of work possible in the first place.

Those positions don’t seem contradictory to me, though I suspect actually leading through that transition will test just how comfortably they coexist.