I was tinkering with terminal shells and writing bad code in the 2000s (hey, I was just a kid). I was getting paid to write slightly less bad code in the 2010s. Today I'm a Lead Engineer. The tools look nothing like they did a decade ago, but the job looks the same.

Not on the surface. I mean when you really pull out the microscope and begin mouth breathing over that specimen we call an industry.

Engineering is about solving problems for other people. Always has been. The programming languages matter, sure. So do the frameworks, and now so do the models generating our next AWS.

But that topological feature changes more frequently than we build: legacy applications are proof of that. What doesn't change at that pace is that someone has a problem, and you have to understand it well enough to solve it. The solution also has to keep working after you stop looking at it.

Things Get Easier, but Never Simpler

Let me first address some frequent concerns about LLM coding and engineer obsolescence.

Code has side-effects. Vibe-coded prototypes have side-effects just like human code does. Because you write it faster, you produce more side effects that will go unmanaged and unrecognized unless you make the time to do that. The craft of engineering is not just in writing code: it's writing code that doesn't become the company's emergency at 2am six months later.

Code itself is a side-effect. That's the part no one talks about in this culture of "more". The very thing which we produce faster than before has baked in consequences, indifferent to whether we understand their implications of existing or not. Without planning and understanding: we move faster yes, but in larger circles than we did when we coded poorly by hand because now we code poorly with HAL.

What's Actually Happening

The gap between engineers and subject matter experts is closing. This is real and it's not going away. There are smart people in accounting who are learning to automate their workflows. There are smart people in healthcare building tools for their own teams. This is a good thing. It means more problems are getting solved by the people who actually understand them.

Here's what none of those people are going to want to do: triage the bug tickets. Improve the reliability of the systems they built. Think carefully about what happens when two requests hit the same record at the same time, or when the API they depend on changes its response shape on a Tuesday.

There will be bugs. There will always be bugs. The question is: who will own them? Who will be accountable for them?

The answer is still Software Engineers.

We're just going to have to do it differently.

The Pendulum

We are in an "everything is AI" moment. Every product roadmap has it. Every investor deck leads with it.

I'm not here to tell you it's all hype. Some of it is real and useful and changes how the work gets done. I use these tools every day. But I've also been around long enough to watch a few pendulums swing.

Nothing will recalibrate this ecosystem faster than the infrastructure costs catching up with the promises. Anthropic raises their org pricing 3x and suddenly the fifteen AI features on your roadmap are a budget line item someone has to justify. These things tend to clarify thinking. The metered cost of generating code seems less enticing for the purposes of a hackathon.

If you're an engineer right now and it feels chaotic: it is chaotic. That's not a bug. This is what it looks like when the tooling genuinely shifts underneath a whole industry at once. It happened with the web. It happened with mobile. It's happening again, and it is arguably the most exciting version of it yet.

The engineers who come out the other side are going to be the ones who understood what the tools were for in the first place. Not the ones who were most enthusiastic about the tools.

That's the job. It's the same job it always was. We just have the power to move faster, faster than we can think, which was always the problem to begin with.