The Tech Job Exodus Isn't New: When Opening the File Stopped Being Enough

A lot of people I respect are scared right now. Some have been laid off, and some are watching job postings ask for things they've never done. The common feeling is that the floor moved and nobody announced it.

I understand that feeling, because I've been through a version of it. It wasn't as fast or as loud as this one, but for people who made websites in the early 2010s, a similar floor moved. Being able to open the file stopped being enough. You had to be able to build the thing.

This isn't a "learn to code" lecture. It's what I remember from that shift, what I think is genuinely different about this one, and what I'd tell someone in the middle of it.

The operator era#

For a long stretch of the web's history, a lot of web work was tool operation. A designer laid out pages in Photoshop and sliced them into images. Someone assembled pages in Dreamweaver, a visual editor that started at Macromedia and became part of Adobe's suite when Adobe bought Macromedia in 2005. Interactive work often meant Flash. Templates came from a theme marketplace or a CMS, and you changed the colors.

I don't say that dismissively. Those were real skills, and people built careers and good work on them. But the value lived in knowing the application: where the menus were, which export settings worked, how to wrangle a template. If you could open the file and make it do what the client wanted, you had a job.

What changed in 2012 and 2013#

No single event caused it. A handful of well-documented changes stacked up over a few years:

• Phones broke the fixed page. Ethan Marcotte named "responsive web design" in a 2010 article in A List Apart. A page was no longer one size, so a sliced Photoshop comp no longer described the product. Someone had to decide how it behaved, in code.
• Flash lost the platform war. Apple published "Thoughts on Flash" in April 2010, and the iPhone and iPad never supported it. A whole category of interactive work had to move to HTML, CSS and JavaScript.
• Front-end frameworks went mainstream. Backbone.js and AngularJS arrived in 2010. Twitter open-sourced Bootstrap in 2011. Facebook open-sourced React in 2013. The browser became an application platform, and that called for engineers, not page assemblers.
• Flat design arrived on the biggest stage. Apple introduced the flat redesign of iOS 7 in June 2013. Interfaces were less about rendered textures and more about systems: type, spacing, color and motion that had to work at every size.
• The tools themselves changed business models. In May 2013, Adobe announced that the Creative Suite would move to subscription-only Creative Cloud. That one wasn't about skills, but it was a sign that the old tool-centric world was being reorganized.
• "Learn to code" became a public movement. Codecademy's Code Year campaign launched in January 2012, and coding bootcamps started appearing around the same time.

Put together, the job changed shape. The most valued people were no longer the ones who knew the tools best. They could hold a design idea and build it, and they understood that a product is a system rather than a set of pictures.

What it looked like from the inside#

My own GitHub account is a small fossil record of that shift. Most of what I forked in 2012 is a list of things I was teaching myself: a REST server for a PHP framework, a Backbone.js tutorial app, bare-bones HTML5 WordPress starter themes, a few jQuery plugins for custom form controls and CSS transforms, and a telephony API's PHP library. None of that is impressive on its own. Together it's someone deciding to understand the machine underneath the pictures.

In 2013 I joined Pandora as an Interaction Designer/Developer. The title says it all. The role covered both halves: deciding how something should feel, then writing the code that made it feel that way. A few years earlier, that would have been two jobs held by two people who handed files to each other.

The pattern I'd expect, and the one this shift seems to reward, is that talent alone wasn't the deciding factor. What mattered was whether someone waited for the tool to adapt to them, or adapted to the work.

Why today rhymes#

The AI shift has a familiar shape:

• The tool is starting to do the operating. Writing a standard CRUD screen, a migration or a test scaffold is increasingly something an agent does. That's the 2026 version of slicing a comp.
• Value is moving to judgment. Knowing what to build, how the pieces fit, what "good" looks like and where the risk sits. That's the 2013 version of "can you hold the design and build it."
• The middle is getting squeezed. Work that was mostly translation, from ticket to code or from comp to page, is under the most pressure.

I spend most of my days building agentic infrastructure, so I see this up close. My agents write a lot of code. What they don't do well, and what I'd argue is the job now, is decide what the task is, write the contract, set the quality gates, and know when a result is wrong even though it looks right.

Why today is different#

Pretending this is a rerun would be dishonest. A few things really are different:

• Speed. The 2010s shift played out over years. This one moves in months, and the tools change under you while you're learning them.
• Breadth. Last time, the pressure landed mostly on web production roles. This time it reaches writing, analysis, support, design and engineering all at once.
• The ladder is changing. Junior work was how people learned. If agents do much of the junior work, teams have to invent new ways to grow people. I don't think the industry has solved that yet, and I don't have a tidy answer either.

What I'd do now#

If I were in the middle of this, here's what I'd do, roughly in order.

Move one layer down. In 2012 that meant learning the HTML, CSS and JavaScript underneath the design tools. Today it means understanding how models, context and agents actually behave. You don't need to train models. You do need to know why an agent gets something wrong.

Become the person who writes the contract. Practice turning a fuzzy request into a precise task: inputs, outputs, acceptance checks, and what's out of scope. That's the most valuable skill in an agent-assisted team, and it was always the most valuable skill in a human one.

Own a loop end to end. Pick something small and ship it all the way: design, build, deploy and run it. People who can carry a thing from idea to running system have survived every shift I've seen.

Learn to judge, not just produce. Review agent output the way a senior engineer reviews a junior's work. Know where it's usually wrong. Taste and skepticism are durable.

Keep your craft. The designers who thrived after 2013 didn't stop caring about design. They added building to it. Whatever you're good at, keep it and add the new layer.

Don't wait for permission. Nobody hired me in 2012 to fork a Backbone tutorial. Start small, start badly if you have to, and start now.

For leaders#

If you run a team, this part is on you, not on the people you lead.

• Give people time and real projects to learn on, not just a course link.
• Rewrite roles around outcomes and judgment rather than tool fluency.
• Keep a path for junior people. If agents take the entry-level work, you have to design new ways for people to learn.
• Be honest about what's changing. Uncertainty is easier to carry than spin.

I care a lot about building teams where nobody has to carry everything alone. During a shift like this, that matters more, not less.

The takeaway#

The floor has moved before. It moved for people who made the web in the early 2010s, and the ones who came through it weren't the best tool operators. They were the people who learned what the tools were standing on and decided they could build it themselves.

It's moving again, faster. The advice is the same: go one layer down, own something end to end, and keep the craft that made you good in the first place.