AI Isn't Redefining Software Engineering. It's Unveiling It.

Mistaking the Entry Point for the Destination

For years, I thought learning to code was the same as learning software engineering.

I consumed tutorials. I built projects. I practiced until I could write clean functions and wire up endpoints without much friction. And to be fair, that was the visible entry point into the industry — it's what almost everyone, myself included, equated with "becoming a software engineer." It was measurable. You could see the progress: a broken component that finally rendered, an API that finally returned the right shape of data.

But over the last year, as large language models have become genuinely good at generating code, something has shifted. The conversation is no longer centered on how to write code. It's moving back toward what actually makes software engineering _engineering_: designing systems, weighing trade-offs, understanding architecture, and building structures that don't just work today but hold up as they grow.

The Word Always Meant More Than This

The word "engineering" always suggested planning, structure, and design — not just construction. Yet many of us focused almost entirely on the construction part, because that's where the tutorials were. That's where the bootcamps aimed their firehose. Frameworks, syntax, and feature-building are teachable at scale in a way that architectural judgment isn't, so naturally that's what the content economy optimized for.

I felt this gap directly while building the backend for Internverse before I had any framework opinions of my own. I could write a working Express server. What I couldn't do yet was structure it in a way that survived past fifty files without a rewrite. That's not a coding skill gap — I could write every individual function correctly. It was an architecture gap, and nothing in my early learning had actually addressed it, because architecture was treated as something you'd absorb later, informally, through pain.

Now we're returning to the foundation.

Who's Actually Leading the Return

What surprised me is who's leading that return. When the shift toward architecture started accelerating, I assumed the loudest voices would be the same people who taught us to code — the tutorial-era names with the biggest audiences. Instead, much of the most thoughtful education around software architecture today is coming from people who were never the headline names of the coding-tutorial era: engineers who spent years quietly studying systems, design, and the decisions that make software last, without ever needing a viral "build a clone of X in 20 minutes" video to prove it.

That's a meaningful signal. It suggests the skills that scale an audience and the skills that scale a system were never quite the same skills, even though the industry spent a decade treating them as interchangeable.

An Uncomfortable Question

It raises an uncomfortable question: did we mistake learning how to write code for learning software engineering? Maybe we treated architecture as something reserved for "senior engineers," something you'd figure out later, when in truth it should have been part of the foundation from the start.

I don't think this is really AI's doing, even though AI is the thing making it visible. Software engineering isn't being redefined by AI. It's being unveiled. AI is simply exposing the difference between producing code and engineering software — a difference that was always there, just easier to ignore when producing code was the bottleneck.

Writing code is a skill. Engineering software is a discipline. And I think we're finally paying attention to the part that should have always been at the center.

I'm curious — do you believe architecture should be treated as a foundational skill from day one, not just a senior-level concern? What's one architectural concept you wish you'd learned earlier in your career?