Engineering Is The New Design
Meet the new boss, same as the old boss.
For decades we software engineers were the elect, the sorcerers, the speakers of mysteries. MBAs might plot the course of our companies; Product and Design defined what customers might do and how they interacted; but only we understood the magic behind it all … and we treated the ‘non-technical’ with suspicion and - all too often - barely disguised contempt.
No more. The proverbial shoe has switched feet. Now, on one side, managers and designers have entered our once-inviolable sanctuary, prototyping their own apps overnight, saying of engineering delays “I could Claude Code this in a weekend!” like a Hacker News commenter. Worse yet, sometimes they aren’t even wrong.
On the other side, if if you work at a company with a modeling team, you know that they are now the high priests and priestesses, speaking in riddles, casually detonating delays with that’s-just-the-way-it-is shrugs, consuming the lion’s share of time and money and attention, working their new magic with the coupled stress and swagger of corporate main-character syndrome … tinged with a certain reflexive dismissiveness of those outside their temple, one which seems awkwardly familiar to us engineers. And they aren’t wrong either. Our church has been usurped. Ours are the old gods now; not gone, but no longer especially relevant.
So what will happen to us? Well. Design might be an illuminating metaphor.
1. Everyone Will Have An Opinion (And A Contribution)
I’ve worked on hundreds of software projects (I used to be CTO of HappyFunCorp, which had dozens on the go at any given moment) and I have long felt great sympathy for the designers who worked on them, because while clients and managers knew they didn’t know anything about engineering, and thus let us engineers handle it, everyone thinks they know something about design, so it is always a negotiation.
I think we can expect that for engineering too. Previously, if you proposed a GraphQL API, almost all managers and product people would simply shrug and acquiesce. Going forward we can expect them to say “Wait … my prototype just used a REST API, and ChatGPT says GraphQL is more complex and less performant, why are you proposing that?” Expect many more architectural conversations - and many many more “oh, I had Claude make a little tweak” from everyone else in the company.
Designers have long found this infuriating. We will too. But it isn’t bad! Some of it will come from a place of ignorance: in the same way that most people don’t understand accessibility concerns, or color theory, most people won’t understand “separation of concerns” or “encapsulation over inheritance” (and we certainly can’t really on agentic code to be elegant, at least yet.) But some of it will come from a place of wisdom … and more importantly, the objective is to ship a product that people will use, not one that is perfectly designed or perfectly engineered.
2. There Will Be Fewer Of Us, Doing More
I’m not saying there will necessarily be fewer full stop; the Jevons paradox vs. “we just automated ourselves out of a profession” debate isn’t settled yet. (I’m a centrist.) But for a given volume of products, there will be fewer engineers, each responsible for more products. For some people that is already incredibly obvious, but I’m not sure everyone’s internalized it yet.
Traditionally, if you were building a startup-sized product you would have a team of engineers and one designer, or, often, a fractional designer. In practice you might have a small design team with fractional collaborations across all projects, so you’d get e.g. 3/8 of one designer’s time and 1/8 of another, so if one went away you’d still have some coverage.
I think we can expect the same of engineering. If your job is now mostly oversight and refactoring of agentic code, you don’t need to be one of five engineers any more; rather, you will split your time between multiple projects. For larger projects you’ll still have teams, but they’ll be much reduced in size.
3. Expertise Still Matters
The hard truth is that, above a certain baseline level of comprehensibility, software quality mostly doesn’t matter that much. I’m sorry. I wish it did too. But nope. There are still a few subgenres where it does - security being the most prominent - but does it actually affect the ultimate success of your product? Only very rarely. If quality did matter, then presumably language would matter, but…
Until recently software quality mattered because it determined the speed at which you could move, not because it actually mattered the success of your product. (I have been making this point for ten years.) But agents can work so quickly now, and more importantly are getting better so fast, that they, not the elegance of your code, determine how fast you move now … again, as long as your code remains vaguely comprehensible.
And that’s where expertise still matters. Anyone who’s done serious agentic coding knows how, without guardrails, they can easily code their way into a swamp where their own code exceeds their own context or complexity capacity, and suddenly you find yourself stuck in the software equivalent of quicksand. As the agents get better, their dry-land territory grows, and the border of the swamp recedes … but it’s still out there, and they still seem oddly drawn to it.
Much of your job, now and for the foreseeable future, is to use your expertise to keep them out of the swamp. And that’s one thing the weekend Claude Coders still can’t do; in fact they can’t even see the swamp, until they’re in it.
4. We’re Here To Solve Problems, Not Write Code
This was always the case. It’s just unignorable now. Carmack again:
You, too, are a designer now. You’re just working in a different medium.