Software Engineering is Back

For the past decade, software engineering slowly stopped being about engineering. The industry moved toward frameworks, tooling, and abstractions that promised to make things simpler but really just made them different. Instead of thinking about systems, we learned to think inside systems someone else designed. Instead of solving problems, we learned to configure solutions. The craft got buried under layers of tooling, and most of us didn't notice because we were too busy keeping up with the next version of the tooling.

Then AI agents showed up. And they changed the equation in a way that I don't think most people have fully processed yet.

Not because they write code for you. That's the surface-level read. What actually changed is deeper: the economic and practical reasons we adopted all those frameworks in the first place are disappearing. The scaffolding we built around the craft is no longer necessary. And what's left, once you strip it away, is the actual work.

The Thinking Didn't Go Anywhere

Most of my work is still there. I still have to deeply think about every important aspect of what I want to build. The architecture, the trade-offs, the product decisions, the edge cases that will bite you at 3am. None of that went anywhere. What's gone is the tearing, exhausting manual labour of typing every single line of code.

The thinking stays. The typing leaves.

This is what people miss when they call it "vibe coding" or dismiss AI-assisted development as a toy. The work didn't get easier. The work got purer. I spend more time now on the decisions that actually matter: system boundaries, data flow, failure modes. Less time on the mechanical act of producing syntax.

An architect who designs a building doesn't pour concrete. But they'd better understand concrete. Years of writing code by hand built the intuition that now lets me direct an agent effectively. The experience isn't wasted. It's leveraged.

The Garbage We Accepted

Let's talk about the thing nobody wants to say out loud.

That adapting layer of garbage we blindly accepted during these years. A huge amount of frameworks and libraries and tooling that has completely polluted software engineering. Especially in web, mobile, and desktop development. Layers upon layers of abstractions that abstract nothing meaningful. Configuration files for configuration files. Dependency trees so deep that a left-pad incident can bring down production.

We told ourselves this was progress. It wasn't. It was the industry optimizing for replaceability over craft.

Frameworks exist for three reasons. The first is simplification. The second is automation. The third is the one nobody talks about.

Simplification is the stated goal, but look at what actually happened. We decided to remove complexity not by sharpening our mental models around the products we build, but by buying a one-size-fits-all design and applying it everywhere. That is not simplification. That is intellectual surrender.

Automation is the legitimate function. Removing boilerplate, handling ORM plumbing, generating scaffolding. Fair enough. But AI agents now do this better, faster, and without locking you into someone else's architecture.

Labour cost reduction is the quiet one. This is the reason that shaped the industry more than anything else. Frameworks standardize the work so companies don't need engineers who think independently. They need people who know the API surface. The job title tells the whole story: you no longer need to hire a software engineer. You hire a React Developer.

Think about what that means. The framework becomes the ceiling. The engineer's judgment, creativity, and architectural instinct become irrelevant, as long as they can navigate the docs. The industry didn't just adopt frameworks. It redefined the job around them.

The Invisible Cost

Every framework carries a cost beyond its bundle size. There is a cost to your design choices. The invisible cost. The one you pay every day without even realizing it, because you've been paying it so long you forgot what freedom felt like.

You can't structure your data layer differently because the ORM doesn't support it. You can't optimize a hot path because the framework's abstraction sits in the way. You can't simplify because simplicity was never the framework's goal. Standardization was.

These constraints compound silently. Over years, teams stop seeing them as constraints at all. They become "best practices." The framework's limitations become the team's mental model. The architecture you can imagine shrinks to the architecture the framework allows.

I've watched this happen on teams I've worked with. Smart engineers, talented people, unable to reason about a problem without first asking "how does the framework want me to do this?" That's not engineering. That's dependency.

What Actually Changed

AI agents didn't just make coding faster. They eliminated the economic reason frameworks exist in the first place.

Need a database migration tool? An agent builds one in minutes, purpose-built for your schema. Need a build pipeline? Describe what you want, get exactly that. No 200-dependency toolchain, no configuration files for features you'll never use. Need a CLI tool for a one-off operation? You have it before you'd finish reading the framework docs.

You're no longer stuck choosing between "build everything from scratch" (too expensive) and "adopt a framework" (too constraining). There's a third option now: build exactly what you need, when you need it. Purpose-built. No baggage.

This changes the calculus entirely. The cost of building a custom component dropped to near zero. Which means the dominant cost is now over-engineering. Building for hypothetical scenarios that never arrive.

Not a Second Before

Here's where I've landed: when things get very complicated, and if they get very complicated, I'll think about it. But only then. Not a second before.

This is engineering.

Real engineering has always been about solving the problem in front of you with the minimum necessary complexity. Civil engineers don't build earthquake-resistant foundations in regions with no seismic activity. Electrical engineers don't add voltage regulators to circuits with stable power supplies. Only in software did we normalize building for every hypothetical scenario on day one.

Frameworks encouraged this. "You might need server-side rendering someday" becomes a day-one architectural decision. "You might need to support multiple databases" becomes an abstraction layer you maintain forever. Each "might" adds weight. The system grows not because requirements demand it, but because the framework's patterns suggest it.

With agents handling implementation, I can afford to start simple and react to real complexity when it shows up. Not before. The cost of adding something later is now trivially low. The cost of carrying unnecessary complexity from day one is not.

The House is New

The tools are here. The models are here. The revolution already happened and most people are still decorating the old house.

The engineers who will thrive are not the ones who know the most framework APIs. They're the ones who understand systems. Who can reason about trade-offs. Who know what to build and, more importantly, what not to build. Who can look at a problem and design a solution from first principles instead of reaching for the nearest npm package.

The framework era trained a generation of developers to be expert consumers of abstractions they didn't design. The AI era rewards the opposite: engineers who think, who design, who make deliberate choices about every layer of their system.

Software engineering, in the truest sense of the word, is back.

Shoutout to Alain Dichiappari who instigated this line of thinking