I pivoted out of on-prem once. I'm getting the same feeling again.

I started my career managing on-prem data centers. Not from a dashboard, either. There was a real one, physically inside the office building I worked in, and for a few years part of my job was keeping it alive. I've been thinking about that room a lot lately, because what happened to it is starting to look a great deal like what's happening to software engineering.

The room in the building

Back at the start of my career, the companies I was working for ran their own data centers inside the building or at the colo. Racks of servers we had purchased ourselves, a network we had designed, storage we had sized by guessing at next year's growth, all of it humming behind a badge-locked door with its own air-conditioning budget. When something broke, a person walked in there. Sometimes that person was me, which is why there's a photo of a much younger version of me with both arms inside a rack.

Keeping it running took a team. Network engineers for the switches and firewalls. Systems engineers for the servers. A group of sysadmins who did the patching, the backups, and the 2am pages. That wasn't unusual. It was the default. Every software company of any size ran some version of the same room and hired some version of the same team, because there was no other way to get compute. If you zoomed out, the demand for those roles was really just every company in the industry duplicating the same infrastructure.

The tell

Somewhere in the early 2010s the conversation changed. Cloud, DevOps, infrastructure as code. At first it sounded like tooling talk, the kind of thing that comes and goes. Then I noticed the shape of it. Provisioning a server was turning into a line in a file instead of a purchase order and a week of racking. If that was true, then most of what my team did every day was about to become something a script did once.

It's worth being precise about what actually drove the shift, because it wasn't the infrastructure people deciding to retire themselves. Developers fell in love with the services. Managed databases, queues, object storage, a load balancer you could have in thirty seconds instead of thirty days. Once a developer had tasted that, they did not want to think about physical hardware ever again, and they certainly didn't want to wait on a ticket to my team to get a box racked. The demand side moved first. The infrastructure side was pulled along behind it, whether it liked it or not.

I want to be honest about how unclear that felt at the time. AWS existed, but plenty of serious people were sure that regulated companies would never put their data on someone else's hardware. Leaving a skill set I'd spent years building, to go learn development and this DevOps thing, looked to some of my colleagues like walking away from a solid job for a fashion. I did it anyway, mostly because I couldn't shake the math. Once infrastructure became software, the people who wrote the software were going to matter more than the people who touched the hardware. So I leaned all the way in: development skills, automation, the whole stack that was replacing the room I used to badge into.

Where it landed

Fifteen years on, that bet looks obvious, which is the trap with every good pivot in hindsight. Today you'd be hard pressed to find a software company that still runs its own hardware. Even Salesforce, which built its business on proprietary data centers, announced in late 2020 that it was re-platforming onto public cloud and has spent the years since migrating region by region, a project it said up front would take years. The direction of travel isn't in dispute.

The part people miss is what happened to the jobs. They didn't vanish one for one. They consolidated. The hyperscalers employ large infrastructure organizations, so it was never literally a handful of people. But measured against the capacity they serve, it's a small fraction of the headcount the old model needed, because the work now happens once, centrally and automated, instead of being redone inside every company. Thousands of firms that each used to staff a data center now share the output of a few teams. The seats that survived were fewer and far higher leverage, and they went to the people who understood the new abstraction rather than the old hardware.

I'll add the honest footnote. There is a newer trend of companies moving certain workloads back on-prem, and AI is a big part of it, because owning your own GPUs can beat paying per token once the usage is large and predictable enough. It's real, and I don't dismiss it. But it's mostly bigger companies with steady load and the staff to run a room. Young companies, by and large, don't even want to entertain the idea of buying their own hardware. The default flipped, and it stayed flipped.

The same feeling, again

I'm having that urge again. The same one. Only this time the room I'm looking at is traditional software engineering, and the thing on the horizon is AI.

Here's my read, and I'll label it as a read rather than a forecast, because anyone selling certainty about this is guessing too. Writing code by hand is starting to look like racking servers by hand. The work still matters. What changes is how many people it takes: a smaller number, operating a much more powerful abstraction, will produce what large teams used to, and demand for the old version of the role will fall to match. The signals rhyme with 2011 almost note for note. New tooling that most people dismiss as hype. Early adopters getting results that don't make sense on paper. A widening gap between what a team of ten did last year and what two people with the right setup can do now.

I could be wrong about the timing. I don't think I'm wrong about the direction, and direction is what you pivot on.

What moving toward the new abstraction looks like

In 2011 the move was concrete: stop being the person who touches the hardware and become the person who writes the code that provisions it. The AI version is just as concrete, even if the vocabulary is newer.

Treat specification as the job, because when building is nearly free, describing the right thing is the work. Learn to verify and own code you didn't type, since that's what most of your diffs are about to be. Build evals, because you can't safely automate something you can't measure. And understand the harness around the model, the loop of tools, permissions, and checks, because that's where the engineering lives now, the same way infrastructure as code was where it lived by 2013. None of this is exotic. It's the same fundamentals pointed at a new target, and every piece of it is learnable in months rather than years.

That's why I built learn.curry.io. When I made my first pivot there wasn't much written for people in the middle of one, just vendor marketing on one side and doom on the other. If you're feeling the same urge I'm describing, the pivot guide is where I'd start.

Hats off

One more thing, and I mean it. The on-prem engineers, the sysadmins who carried pagers, the network people who could read a packet capture by eye, the ones who knew which rack ran hot in August: hats off. The entire industry runs on abstractions you built by hand first. We wouldn't be here without you, and I suspect that in another fifteen years someone will be saying the same thing about the engineers who wrote every line themselves.

If you used to work in one of those rooms, I'd genuinely like to hear about it.