I Think a New Role Is Emerging in Tech
It doesn't have a name yet, but it's already reshaping how teams build software.
Every major shift in developer tooling has eventually changed how teams get organized. Not immediately, and rarely in the ways people predict.
The full-stack developer is probably the best example. Front-end and back-end are legitimately different disciplines. The mental models don’t overlap much, the tooling is different, and the failure modes look nothing alike. But frameworks, shared languages, and better tooling created a layer that let one person operate across both sides of the stack. Not as deep as a pure specialist in either, but deep enough to hold the full picture of a feature from database to browser. For enough companies and enough products, the tradeoff was worth it, and the role stuck.
I think AI is creating the same kind of abstraction, but in a different direction. Not vertical, across the tech stack. Horizontal, across the org chart.
Software teams have been organized around specialization for a couple of decades now. Building software is complex enough that we split the work across product managers, engineers, and developer relations. Each role reflects a genuine body of knowledge that takes years to develop.
But that split came with coordination overhead we mostly stopped noticing because it became so normal. The spec that’s outdated by the time engineering reads it. The roadmap review where three teams discover they’ve been building against different assumptions. The feedback from users that takes two weeks (when lucky) to travel from the DevRel team through product and into a Jira ticket an engineer might see next quarter. The work of keeping the machine aligned sometimes dwarfing the work the machine was supposed to do.
AI is compressing that overhead faster than most org charts can adapt.
A product manager can now spin up a working prototype in Cursor or Lovable in a few hours, put it in front of users, and generate real feedback before engineering writes a line of production code. That’s not the PM “learning to code.” That’s an abstraction layer that lets someone with product judgment operate in engineering’s territory well enough to validate an idea. An engineer can take a feature they just built and generate documentation, draft user-facing copy, think through how this change should be communicated to the developer community. Not because they suddenly became a technical writer, but because AI handles enough of the execution that their understanding of the system (which was always the hard part) can flow directly into outputs that used to require a different team.
LinkedIn’s chief economic opportunity officer recently described what he called the “full stack builder” who compresses what used to take days across design, product, and engineering into a single person with AI tools. Walmart now has dedicated agent builder roles that didn’t exist a year ago, filled internally by employees who crossed traditional role boundaries. And some companies have taken it further than a new title. Boris Cherny, creator of Claude Code, mentioned on the Pragmatic Engineer podcast that everyone at Anthropic carries the same title: Member of Technical Staff. Engineers do research. Researchers write code. People move across what would be departmental boundaries anywhere else. Flat titles aren’t new, but AI has made the structure more viable by collapsing the distance between functions enough that one person, with the right tools and the right depth, can operate fluidly across them. When the horizontal abstraction layer is thick enough, the case for separate titles gets hard to make.
The word “builder” is catching on as shorthand for all of this. But I think it flattens something more interesting.
What’s actually emerging is a role whose shape is determined by the product, not by the org chart.
A company building developer infrastructure needs someone whose core is engineering architecture. Someone at the staff or principal level who understands system design deeply enough that when AI extends their reach into product decisions and developer experience, they can evaluate whether the output is actually good. AI can draft a product spec, but knowing whether that spec addresses the right problem for the right user takes judgment formed by years of building and operating these systems.
A consumer-facing product might need the inverse: someone whose depth is user research and product instinct, with AI extending them into implementation. They can prototype and ship features in ways they couldn’t before. But the anchor is that they’ve watched enough users abandon a flow or misunderstand a feature that they can feel when a prototype is solving the right problem versus just looking like it does. AI handles execution. The product instinct tells it where to aim.
The horizontal abstraction layer is the same in both cases. The anchor point is different. And the anchor point is determined by what the product needs, not by which department someone sits in.
The full-stack analogy cuts both ways, though, and the uncomfortable part matters. Full-stack developers were controversial for a reason: you often got mediocre work in both domains. The same criticism will show up here. “You’ll get someone who’s a mediocre PM and a mediocre engineer, all in one convenient package.” It’s a fair concern. The difference is that AI changes the math. When the full-stack developer emerged, you still had to write the CSS and design the database schema yourself. The abstraction layer was thin. With AI, the gap between “I understand this domain well enough to direct the work” and “I can produce professional-level output” has narrowed enough to change how teams get structured. Not to zero. But enough.
And the people best positioned to take advantage of that are the ones who’ve been deep enough in at least one domain to know what good looks like across the others. A senior engineer can tell when AI-generated code is architecturally sound or just syntactically correct. A seasoned PM can see through a prototype that looks impressive in a demo but isn’t testing a real hypothesis. You don’t develop that instinct from AI fluency. You develop it from years of doing the work without shortcuts, which raises a real question about where the next generation of senior builders comes from when the junior roles that used to build that depth are exactly the ones getting compressed. I don’t have a clean answer for that. I’m not sure anyone does yet.
The career model most of us internalized, pick a specialization, go deep, move up the ladder inside that lane, is getting harder to map onto what’s actually happening. The lanes are merging. The question that matters now isn’t “what title do I want next?” It’s “what product or problem am I deep enough to own end-to-end?”
The full-stack developer proved that one person could work across the stack if the tooling was good enough. The tooling just got a lot better. And the stack just got a lot wider.
I’m navigating this shift in real time, the same as you. If you want to follow along as I figure out what this new landscape looks like from the inside, with 20+ years of context and zero pretense of having all the answers, subscribe to The Long Commit. I write weekly about developer careers, AI, and the long game in engineering.