There’s an episode in the last season of Mad Men where the office gets its first computer. It arrives in pieces, takes over an entire room, and immediately becomes the source of quiet panic among the staff. The writers are convinced it’s going to write the copy. The account men think it’s going to run the numbers and make them redundant. Nobody really knows what it does, but everyone is certain it’s coming for their job.
It doesn’t, of course. It becomes a tool. An expensive, room-sized tool that someone still has to operate, interpret, and explain to the people upstairs.
I thought about that episode the last time I read another loud think piece about AI replacing software engineers. The discourse has a familiar shape. A new capability appears, someone publishes a benchmark, and within 48 hours half of the internet is either eulogizing the profession or writing a contrarian take about why nothing will change. The engineers in the middle, the ones actually using these tools day to day, are mostly just getting on with it. The fear, as usual, arrives before the understanding does.
This isn’t the first time. Computers would replace accountants. Spreadsheets would replace analysts. Google would replace researchers. Stack Overflow would replace knowing anything. Each time, the role didn’t disappear. It shifted. The accountant learned the software. The analyst started asking better questions. The researcher got faster.
The tools we have now are genuinely impressive. A well-prompted model can scaffold a feature, write tests, explain an unfamiliar codebase, and catch things a tired reviewer might miss. That’s real. It’s also exactly what a good junior developer does, and nobody was worried that junior developers were going to replace senior engineers.
The work that’s hard to automate is the same work that’s always been hard to automate. Understanding what the product actually needs. Navigating a codebase that grew organically over six years with three different architectural opinions baked in. Knowing when the technically correct solution is the wrong one for this team at this moment. Sitting in a room with a stakeholder who doesn’t know what they want yet and helping them figure it out. None of that is in the benchmark.
he writers kept writing. The account men kept lunching. The work that required judgment, relationships, and taste turned out to be pretty resistant to a machine that was very good at processing punch cards. That room is now someone’s standing desk, probably with a laptop on it running a model that writes boilerplate faster than any human ever could.
The software engineers who are hardest to replace aren’t the ones who implement features fastest. They’re the ones who know which features are worth implementing. That skill has survived every wave of automation so far, and I don’t expect this one to be any different.
They’re still writing the copy themselves. We’ll still be writing the code ourselves. The computation just gets lighter, smarter, faster.