The Builder's Era
Something is changing in how people who make software describe themselves. The word I keep hearing is builder.
March 2026
Something is changing in how people who make software describe themselves. A few years ago, everyone wanted to be called an engineer. A senior engineer. A staff engineer. Now the word I keep hearing is builder.
This isn't just a branding thing. Something real is shifting in what it means to make software, and I think most people in tech are underestimating how big the shift is.
Here's what changed. For the last thirty years, the bottleneck in making software was writing code. You could see the future — you could feel the product you wanted to exist — but between your vision and reality stood months of implementation. Hiring. Sprints. Debugging. Deploys. The gap between having an idea and holding the thing in your hand was enormous, and it was almost entirely an engineering gap.
LLMs collapsed that gap. Not all the way, not yet. But enough that something fundamental broke in the old model.
When you can go from idea to working prototype in an afternoon, the hard part isn't writing the code anymore. The hard part is knowing what to write.
And that changes who matters.
For a long time, the technology industry was really the engineering industry. We even organized our companies to reflect this. Product people wrote specs. Designers made mockups. Engineers did the "real work" of building. The implicit hierarchy was clear: the closer you were to the code, the more you mattered.
This made sense when implementation was the scarce resource. If it takes six engineers three months to build a feature, then engineering capacity is your bottleneck, and you organize everything around it. You build project management processes to protect engineering time. You hire PMs whose main job is to translate business needs into technical specs. You create prioritization rituals whose real purpose is to ration the one resource everyone's competing for.
But when the implementation bottleneck loosens — when a single person with good judgment can build in a weekend what used to take a team a quarter — that whole apparatus starts to look like overhead. And the skills it was optimized around start to look like the wrong skills.
I saw this happen recently. A designer at a fintech company had been watching merchants struggle with something for months. These small-business owners would get a payment notification, and then — because the app's transaction history was hard to parse — they'd spend several minutes figuring out who paid them and for what. The designer knew exactly what the fix should look like. She'd mocked it up twice. Both times it went into the backlog and sat there, because the engineering team had higher priorities.
So one weekend she built it herself. Not a mockup. Not a prototype in Figma. A working feature — a real-time payment feed that surfaced the customer name, amount, and context in a single glance. The code, by engineering standards, was probably a mess. But the product was extraordinary. She'd seen the problem up close, she knew what good looked like, and she closed the gap without waiting for permission.
When the team saw it on Monday, the reaction wasn't "that code needs to be rewritten" (though it did). It was "why didn't we ship this six months ago?" The answer, of course, was that the old model didn't have a way for someone with her insight to act on it directly. The new model does.
Let me be precise about what I mean, because I'm not saying engineering doesn't matter. It obviously does. Prototyping something over a weekend and running it in production at scale are very different things, and the gap between them still requires deep technical skill. The weekend prototype still needs an engineer to harden it — but the builder is the one who decides it's worth hardening.
What I'm saying is that engineering is getting absorbed into something larger.
Think about literacy. There was a time when the ability to read and write was a specialized professional skill. Scribes were important people. Then literacy became universal, and it stopped being a career. It didn't become less important — it became more important. But it was no longer a differentiator. It was an ingredient.
Code is becoming like literacy. You still need to understand it. You might still need to write it sometimes. But the ability to write code, by itself, is no longer the thing that makes you valuable. It's becoming one ingredient in a larger skill, and that larger skill is what I'd call building.
So what is building, exactly? And how is it different from engineering?
An engineer, in the traditional sense, takes a well-defined problem and implements a solution. Give them a spec and they'll ship it. The better the engineer, the faster and more elegantly they ship it. This is a real and valuable skill. But it's a reactive skill. It starts with someone else deciding what to make.
A builder starts further upstream. A builder looks at the world and sees what's missing. They talk to people and feel their frustrations. They have taste — not an innate gift, but a sensitivity trained by spending time with real users and caring about their experience. And then they make the thing. The whole thing. Not just the backend or the frontend or the database schema, but the experience.
The best founders have always been builders. They never cleanly separated "product thinking" from "engineering." They held the user's problem and the implementation together, and they refused to let go of either until the product was right. The product was the engineering, and the engineering was the product. There was no handoff because there was no gap.
What's happening now is that this way of working — which used to be rare and usually found only in exceptional founders — is becoming accessible to a much larger group of people. You no longer need to be a mass of engineering talent to work this way. You need to be curious, opinionated, and willing to build.
This explains something I've been puzzling over. The people who are using LLMs most effectively aren't necessarily the strongest engineers. They're the people with the strongest opinions about what should exist. They have a clear picture of the problem. They know what good looks like. They can evaluate whether what they just built actually solves the problem or just sort of waves in its direction.
In other words, they have taste.
Taste in software is the ability to know the difference between something that works and something that's good.
It's knowing that a payment flow that takes seven taps should take three. It's sensing that an error message is technically correct but emotionally wrong. It's the feeling that tells you this feature is unnecessary even though the data says people are clicking on it.
You can't automate taste. You can't prompt your way to it. It comes from watching real people use real software and caring enough to feel their frustration as your own. Taste feels like instinct — the best designers and product people seem to just know — but it's actually the residue of accumulated attention. It's what you get when you watch a thousand people struggle with a settings screen and let that experience change how you see the world. And it's about to become the most valuable skill in tech.
I want to be careful here, because there's a lazy version of this argument that goes: "Engineers are dead, everyone's a PM now." That's wrong, and it misunderstands what I'm saying.
The builder isn't a product manager who can't code. The builder is someone who refuses to separate thinking from making.
They don't write a ten-page spec and toss it over a wall. They think by building. They prototype to discover what they think. The artifact isn't the document — it's the working software.
This is actually closer to how the best engineers have always worked. The engineers I admire most were never pure implementers. They pushed back on bad specs. They redesigned features while building them because they could see, in the act of making, that the original plan was wrong. They spent time with users even though nobody asked them to. They cared about the product, not just the system.
Those engineers are going to be fine. More than fine — they're about to become the most sought-after people in the industry. Because they were already builders. The rest of the world is just catching up to their way of working.
The people who should be worried are the ones who built their career on the gap between ideas and implementation. If your value was that you could turn specs into code, and that translation was hard enough to command a high salary, then yes — your position is eroding. Not because you're bad at what you do, but because the thing you do is getting easier.
This isn't unfair. It's just what happens when technology advances. The question isn't whether to be upset about it. The question is what to do next.
And the answer, I think, is to get closer to the problem. Stop waiting for someone to hand you a spec. Go talk to the people who use what you build. Develop opinions about what good software feels like — not just opinions about system architecture, but opinions about experiences. The designer who built that payment feed over a weekend wasn't working from a spec. She was working from months of watching merchants fumble through a screen she knew was broken.
In short, become a builder.
This is their era. And the people who thrive in it won't be the ones with the most elegant code or the most detailed specs. They'll be the ones who saw what was missing and couldn't stop themselves from making it exist.