Rethinking “The Developer”: Builders, Modernizers, Orchestrators
Developer Experience isn’t one size fits all: startup builders need focus, modernizers need safety, orchestrators need control. Treating them as one persona misses what each must protect.
I spend my days working with engineering leaders and teams as a customer success manager at Swarmia. I hear how work really feels: what’s slowing teams down, what’s burning them out, and what leaders are actually measured on.
I listened to this podcast: First Time Founders with Ed Elson - This Physicist Is Building AI Droids… and it hits a nerve (in the best possible way).
We keep saying “the developer” like it’s one person. It’s not.
A founder shipping features alone in a co-working space at midnight is not living the same reality as an engineer inside a 10,000-developer company who’s refactoring a 15-year-old codebase without breaking compliance. Treating them like the same “user” is a failure of empathy, and it’s exactly why so many “developer experience” strategies end up being a miss.
The podcast episode makes this painfully clear through Factory’s AI “Droids.” These aren’t pitched as fun assistants for shiny new features. They’re positioned to take on the slow, compliance-constrained, low-autonomy work that large organizations struggle to prioritize or sustain. It’s not about speeding up the exciting parts. It’s about absorbing the work that quietly erodes morale if left unaddressed.
I want to unpack the empathy gaps I see all the time and that the episode surfaces really well.
Why “developer” isn’t one persona
Gap #1: New-feature work vs. legacy transformation
In a startup, you’re mostly creating new things. The mission is: get something live that proves the company deserves to exist. You do the idea, the design, the code, the testing, the deploy, and sometimes the 1:13am fix. You’ll accept tactical shortcuts if they reduce time-to-learning.
In an enterprise, that’s not the job.
The work is often migration, refactoring, hardening, auditing. You’re asked to move a massive legacy service to a new standard without breaking regulated workflows or exposing the company. It’s careful demolition. It’s archaeology. It’s modernizing the early 2000’s plane mid-flight without affecting safety or services levels, and of course, the plane doesn’t crash.
That work is long, high-stakes, and rarely celebrated. Research links unplanned, interrupt-driven, low-autonomy “toil” to higher burnout and lower morale; DORA’s 2022 report notes the teams burdened with unplanned work also report the highest burnout, and Google’s SRE book characterizes toil as interrupt-driven work that organizations must minimize to protect efficiency and morale. SPACE also treats well-being and flow as core to productivity.
Here’s the disconnect: advice calibrated for startups imagines “a developer” as a creator, inventing new product. But in many large orgs, the job is controlled teardown of old systems under scrutiny.
So when you pitch “We’ll help you ship features 10× faster,” you may be solving the wrong pain. It’s offering an energy drink when the ask is for body armor.
Gap #2: Autonomy vs. accountable, auditable change
In a startup, autonomy is the culture. If production goes down, you fix it. If you need a tool, you install it. The question is, “Does this help me move faster right now?”
In a large company, accountability is the culture.
You don’t just roll in a new AI agent because it looked cool on a conference slide. You prove auditability. You show compliance. Security, architecture, and sometimes legal need to bless it. You need to know you can pause it, inspect it, and roll it back.
Speed resonates in large orgs after auditability, rollback, and explainability are in place. The message that lands isn’t “move fast”; it’s “modernize safely with human-in-the-loop control.”
Gap #3: The creator vs. the orchestrator
In a startup, “the developer” is the product engine. They talk to users, design flows, write the code, ship to prod, and directly feel the market impact.
In a large organization, “the developer” could be any of these:
A platform engineer keeping critical internal services alive.
A feature engineer responsible for exactly one slice of a giant product.
A modernization/migration engineer doing the work no team wants to own.
An architect coordinating across multiple teams and guarding standards.
A tech lead who writes less code but defines constraints, rules, acceptance criteria, and safety boundaries for systems (human and AI) that will actually do the work.
That last one matters.
Many senior engineers now specify intent, constraints, and acceptance criteria, then supervise human and AI execution. If your product only targets the person typing in an editor, you’re speaking past the budget holder. They’re not optimizing for autocomplete; they’re optimizing for controllable collaborative execution.
Same craft, different constraints
This is the part we almost never say out loud in sales decks, onboarding flows, or roadmap meetings but we should.
These differences matter, because leaders (especially buyers) often tend to hear the highlight reel of success from one environment and then try to apply it to the other. That’s how you end up with mismatched tools: like handing a seed-stage startup a massive governance platform they’ll never actually use, or telling an enterprise modernization team “just move fast.”
Developers in the Age of AI: what each group protects
If AI is going to be part of “developer experience,” start with what different developers are actually trying to protect.
For early-stage teams, AI should create focus. Win: fewer interruptions, less repetitive setup/cleanup, and more time in flow so they can ship value before the money runs out. They don’t want ceremony; they want momentum.
For large organizations, AI should create safety. Win: help with high-risk, unglamorous work like migrations, refactors, and compliance changes all in a way that is reviewable, auditable, and stoppable. Speed matters, but control matters more.
For orchestrators (senior leads, architects, staff+), AI should make intent executable. Win: define outcomes and guardrails, constrain blast radius, and get trustworthy execution they can direct and explain.
If we treat all of these people as “the same developer,” we miss what AI is supposed to do for them:
Builders: remove distraction.
Modernizers: reduce risk and toil.
Orchestrators: enable controllable execution.
That’s the mental model shift. Developer experience isn’t “make coding nicer.” It’s: understand which kind of developer you’re serving, what pressure they’re under, and how AI can responsibly absorb the work that’s wearing them down without taking away their judgment or their ownership.
Operating principles (what respectful support looks like)
Don’t reduce success to output. Shipping more lines of code is not the point.
Name the business reality. Early teams care about runway. Large orgs care about not breaking production or policy.
Speed with guardrails. Claims of “we generate code faster” miss the mark unless auditability, rollback, and explainability are covered.
Honor the unglamorous work. Much of the frustration teams report comes from repetitive, cross-team, compliance-sensitive work. AI that safely takes on that work isn’t “replacing developers”; it’s protecting them.
Include orchestrators. Architects, leads, staff engineers, and even PMs increasingly act as mission planners. If you ignore them because they’re not typing code, you’re already behind.
Assume different definitions of “good.”
Startup good: we shipped something that unblocked learning or increased revenue.
Enterprise good: we modernized a legacy system and passed audit without an incident.
A simple checklist
You can use this as a gut check for tools, process, policy, onboarding, roadmap or anything you’re calling “developer experience” or “AI for developers.”
Who is this actually for? (early builder / modernization team / orchestrator)
What are they afraid of losing? (time, focus, safety, credibility, control)
Does this reduce their mental load, or add one more thing to watch?
Does this respect how they’re measured?
Can they explain why they trust it? (observability, reviewability, rollback)
“Developer” is not one identity.
A seed-stage team trying to survive the next quarter and a 10,000-person org trying not to detonate its own legacy systems are not living the same story. A growing third group of orchestrators: senior engineers, architects, and technical leaders who are no longer expected to write every line of code themselves, they’re expected to guide AI, define intent, and prove safety.
If we talk about all of them like they’re one persona, we erase their reality and trust erodes. When we acknowledge the differences, we can build AI and process in a way that protects focus, reduces risk, and respects intent so that teams can do their best work.