Software Engineering Is Becoming Engineering
The hazing ritual is over!
Every conference, every group chat, every dinner with engineer friends circles back to the same panic: “AI is causing huge layoffs. AI replaces new grads. Everyone is getting automated.” Let’s cut through the noise. The Layoffs are from over hiring. I’ll show you the numbers. It’s simple. But what’s interesting is what happens to software engineering.
Software engineering isn’t ending. It’s becoming like every other engineering discipline.
It’s not AI it’s over hiring
Regarding layoffs: tech companies went on a ZIRP bender from 2020 to 2022, growing headcount 30, 40, sometimes 100 percent in two years. Interest rates went from zero to five. The free money disappeared. Now they’re correcting, and “AI transformation” is the press release that sounds better than “we over-hired and mismanaged capital.” The World Economic Forum’s own managing director said it plainly: companies are using AI as an excuse. IBM’s CEO called it a “natural correction.” A Conference Board survey of 250 HR leaders found that only 6% of recent layoffs were primarily driven by AI. The rest? Restructuring and financial pressure. Same forces that have driven corporate downsizing for decades. Block’s stock jumped 22% the day after Dorsey announced cutting 40% of the company. Wall Street doesn’t reward AI innovation. It rewards headcount cuts.
It’s almost like interest rates, or the price of capital, is important signaling information that, when distorted, causes the business cycle. Weird.
The architect doesn’t weld the I-beams
What is engineering, actually?
If you’re an architect, you don’t design the skyscraper and then go weld the I-beams. You don’t pour the concrete, bend the rebar, or wire the electrical. You design the system, specify the constraints, and review the work. If you’re a civil engineer, same thing. The structural engineer’s job isn’t to weld. It’s to create a system where welding happens safely within well-defined boundaries.
For decades, software engineers did all of it. We designed, and built, and tested, and deployed. We were the architect and the welder and the electrician and the building inspector. No other engineering discipline works that way. Ours did because there was no construction crew to delegate to. A civil engineer hands blueprints to a general contractor. A software engineer was the general contractor. The only way to get from “I know what this should do” to “it works” was to write every line yourself.
AI is stripping away the construction part. And what’s left is what the structural engineer actually does all day: he reviews the welder’s work, catches the stress points the welder can’t see from ground level, and signs off that the whole thing won’t fall down. He doesn’t weld better than the welder. He sees the system the welder can’t. That’s what working with agents looks like now. You review their output, catch the second-order effects they miss, and own the outcome. The construction crew got better. That’s it.
While reviewing this post, a CMU professor named Christopher Meiklejohn gave a guest lecture in April making exactly this analogy. Software engineering is becoming civil engineering. He arrived at it independently. That’s how you know an idea is real: when people who haven’t talked to each other keep saying the same thing.
The 10% that mattered was never the typing
There’s an old saying that software engineering is only 1-10% coding and the rest is understanding the problem, planning the solution, discussing with other engineers, talking to users, designing systems, arguing about tradeoffs, and so on. AI does almost all of the coding and is a good co-pilot for the rest, but it doesn’t work well on its own.
Generating code was never the bottleneck. The bottleneck was knowing what code to generate. The hard part was always taste. The ability to look at ten possible solutions and know which one is right for this system, this user, this moment. Not just “does it work” but “is this the right thing to build, and is this the right way to build it?”
Taste is the word the industry is converging on because it captures something “judgment” doesn’t. Judgment sounds like a courtroom. Taste sounds like a person who’s spent years developing an instinct for what good looks like. In code, in product, in architecture. When execution is cheap, taste is the only thing that matters. It’s what AI is worst at.
Worklike activities
Here’s an uncomfortable truth the industry doesn’t want to hear: a lot of developers were never doing engineering in the first place.
They were shoveling shit around. Business Insider interviewed 30+ people inside Big Tech and found a culture of “fake work” driven by lazy management and empire building. Stanford studied 50,000 engineers and found 9.5% do virtually nothing. Chainguard surveyed 1,200 engineers and found they spend 84% of their time not coding. Full salaries. Meetings about meetings. Billions of dollars a year. And look, most of them probably didn’t know. They weren’t scheming. They showed up, sat in the meetings, moved the tickets across the board, went home thinking they’d worked. The system let them believe that for years.
Good news: I think this gets solved with AI reviewers. I cover this more here:
tl;dr - AI is a better performance review than any manager ever was because it can qualitatively assess every line of code you write, every contribution in every meeting and chat, and so on. Folks that are 1x engineers can be guided and entrained to more productive behaviors.
Stewart Butterfield, the guy who cofounded Slack, has a name for this: “hyper-realistic worklike activities.” (i.e. World of Warcraft) It looks exactly like work. You’re in a conference room, something’s being projected on the wall, everyone’s talking about it. It is work, right? Except it’s a pre-meeting to preview the deck for the actual meeting. And even the CEOs do it. Even the board members. The further you get from the actual product, the easier it is to fill your entire week with sophisticated performances of productivity.
For more examples of “hyper-realistic worklie activities” in action, search for “minecraft builds” or “redstone computer”. People spend months or years designing and building computers within minecraft. We are wired for this, so it’s very hard to fight against.
Meanwhile, the real debates in our industry sound like medieval scholars arguing about how many angels can fit on the head of a pin. Tabs versus spaces. Vim versus Emacs. Rebase versus merge. Whether 10x engineers are real. Someone actually ran 90 AI model debates across 15 languages on tabs versus spaces. Stack Overflow found that spaces developers make 8% more money than tabs developers, and people took it seriously. There’s a 1957 management theory called Parkinson’s Law of Triviality that explains exactly this: a committee will spend almost no time on the nuclear reactor design (too complex for most to have an opinion) and argue for hours about the color of the bicycle shed. That’s our industry. We bikeshed while the product rots.
And the 10x engineer debate? Please. The research on this is as conclusive as anything in software engineering. Sackman, Erickson, and Grant found it in 1968. Curtis confirmed it in 1981. DeMarco and Lister in 1985. Boehm in 1988. The Carnegie Mellon SEI replicated it again in 2020. Across sixty years and hundreds of professional programmers: 5:1 to 25:1 differences in productivity. No study has ever contradicted the finding. The fact that the industry is still arguing about whether they exist tells you everything about how confused people are about what actually matters.
The 10x engineers aren’t 10x because they type faster. They’re 10x because they have taste. They know what questions to ask. They know what quality looks like and what bad code smells like.
Elon Musk fired 80% of Twitter and the site stayed up. Not “barely survived.” They consolidated the recommendation system from 700,000 lines of code to 70,000, cut cloud costs by 60%, and started shipping features faster than the old Twitter ever did. Everyone predicted catastrophe. What actually happened was a leaner team doing more with less. The company had 7,500 employees. Most of them were managing the people who managed the people who were building things. You don’t need to love Musk to look at that and ask: what were those people doing? Damn.
The specification problem
There’s a certain type of engineer I think of as an “assembly line” engineer. These are the folks that are super locked in all the time, they know the code base, they know the stack, they have institutional memory, they pull tickets from the queue and get stuff done. These folks were the backbone of medium+ sized companies, and they’re increasingly being automated. Writing good code in complex systems is very hard, and in a world of all-hand-written code, someone could be highly specialized in just the technical wizardry. But agents are very good at understanding, explaining, and writing code, even really complex code if you give them the tools to inspect and debug (telemetry, debuggers, etc). This type of engineer is increasingly not as valuable unless they can learn to start using agents to do more.
As AI models and harnesses improve, knowing what to build matters more than knowing how. A designer who used to hand off static mockups can work directly in the codebase. A product manager who’s spent years defining what success looks like can ship features in a day instead of filing a ticket and waiting two sprints. The people closest to the customer were always locked out by the implementation step. That lock is breaking.
We’re seeing this at Delphos Labs. Our business lead has been shipping full-stack engineering work: frontend changes, design decisions, submitted PRs. Because she understands the problem and the customers deeply. The technical coding layer was the only thing in her way. When that step got cheaper, the value of her taste became obvious.
What happens next
The profession doesn’t shrink. Not yet, anyway. nervous laugh It splits. The engineers who were 10x before become 50x. The ones who were shuffling code around get revealed.
And if you’re just getting started? You might be the luckiest generation of engineers in history. I spent decades mastering recondite syntax, jargon, and APIs. You won’t have to. Before AI, the punishment for being wrong about a design was extremely painful tech debt that took months or years to pay. Now, you can have an idea and build a prototype in a day or two. If it doesn’t work, scrap it and build something else. Just think of all the brilliant, creative minds that had great ideas for software but couldn’t force themselves to sit still for 10 years and study the “how”. Now, we’re living in a world where anyone with a cool idea can manifest it. This is going to be fun!