The Last One Standing Will Be a Senior Developer
A controversial take on role survival, the Venn diagram nobody draws, and what every non-developer needs to hear right now.
“If a software product team had to survive with exactly one person, that person would always be a senior developer. It’s the only role that sits inside the Venn diagram of every other role.” — A defensible hypothesis
The AI displacement conversation has been stuck in a loop.
We keep asking “which jobs will AI take?” as if the threat is a robot walking through the office door and escorting someone out. But in 2025 and early 2026, the pattern that emerged in tech layoffs told a more nuanced story. Nearly 80,000 tech workers were laid off in Q1 2026 alone, with close to half of those positions attributed directly to AI-driven workflow changes [1]. What nobody is drawing clearly enough is which roles disappeared first, which survived, and why.
Here is the blunt thesis: the last person on a software product team — if forced down to one — is almost always going to be a senior software engineer. Not because of prestige, not because of salary, and not because the industry is biased toward developers (though it sometimes is). But because of geometry.
The senior developer is the only role that sits inside the Venn diagram of every other role on the team.
To be precise about what that claim means: this is not an argument that one person can do all these jobs well. It is an argument about which role has the most surface area when the team shrinks — and why that geometry is not an accident.
Draw the Diagram
Picture a standard software product team. You have a Product Manager defining what gets built. A Business Analyst translating business requirements into specifications. A UX Designer shaping how the product feels. A QA Engineer validating what gets shipped. A DevOps or SRE Engineer keeping the infrastructure running. A Scrum Master or Project Manager facilitating delivery. A Tech Lead or Architect setting direction.
Now draw overlapping circles for each of these roles. Ask yourself: which circles does the senior developer touch?
With the Product Manager: The senior developer participates in roadmap conversations, challenges technical feasibility assumptions, negotiates scope, estimates complexity, and often writes or refines acceptance criteria. They are not the PM — but they carry enough product thinking to operate without one when they have to.
With the Business Analyst: The senior developer reads requirements and asks the same questions a good BA would: “What happens when the user does X?” “Is this a hard rule or a default?” “What does the business lose if we simplify this?” They translate ambiguity into working systems. That is, at its core, what a BA does.
With the UX Designer: In every startup and lean product team, a senior developer collaborates directly with design — flagging what is technically possible, questioning interaction patterns that would be expensive to build, and implementing enough of the front-end to have a real conversation about the user experience.
With the QA Engineer: A senior developer owns unit tests, integration tests, and increasingly end-to-end test coverage. They review test plans, understand edge cases, and with modern AI tooling, generate and maintain test suites without handing off a ticket. They are not a dedicated QA — but the quality of a senior developer’s output overlaps significantly with what QA protects.
With the DevOps/SRE Engineer: Senior developers write Dockerfiles, configure CI/CD pipelines, debug production incidents, monitor service behaviour, and own the observability of their own systems. Infrastructure-as-code has collapsed the barrier between “developer” and “operator” in ways that are now largely irreversible.
With the Scrum Master and Project Manager: Senior developers track their own work, escalate blockers, decompose large features into tasks, and communicate delivery timelines without being managed. A good one makes the Scrum Master’s job easy. An exceptional one makes it optional.
With the Tech Lead and Architect: This is the most obvious overlap — because the senior developer is often on the path to this role or already performing it without the title. They review other people’s code, shape system design, and make daily architectural decisions within their scope.
Now ask the reverse question: does any other single role on this list touch all the others?
A Product Manager cannot write the production code. A QA engineer cannot design the system architecture. A Business Analyst cannot configure the deployment pipeline. A UX designer cannot manage the sprint board and ship the feature and monitor the service after go-live. A Scrum Master cannot write the tests.
The senior developer is the only role with surface area in every other circle. That is not arrogance — that is the geometry of the role.
Why AI Accelerated This, Not Caused It
This is not a new phenomenon. Senior developers have always been latent generalists. What AI tooling did was reduce the activation cost of crossing role boundaries.
Before AI-assisted coding, writing a first-pass test suite was a context switch that took time. Before AI-assisted PR summarisation, documenting a pull request was grunt work that often didn’t happen. Before LLM-assisted story drafting, a developer who wanted to write acceptance criteria without a BA had to do it purely from memory and guesswork.
AI didn’t make the senior developer more powerful. It made the cost of crossing role boundaries cheap enough for their existing judgment to finally move at full speed.
Now those transitions are cheap. A senior developer can draft a story from a Slack conversation using an AI assistant, write the implementation with AI-assisted code completion, generate a test suite and review it for coverage, get a pre-review of the PR before a human reviewer opens the diff, and summarise the change for documentation automatically.
They are not replacing each of those specialists — they are producing a credible first pass across the entire loop. In a lean team, a credible first pass is often enough.
What Other Roles Need to Do to Stay Relevant
If this thesis is correct, it should provoke anxiety in every non-developer reading it. That is not the intent. The intent is to be direct about what it means for each role’s trajectory — and what survival looks like.
The upgrade path exists for every role. The question is whether they take it before the window closes.
Product Managers: The PM’s irreplaceable value is judgment about what to build, grounded in user insight, market context, and business strategy. That judgment cannot be automated. What can be automated is the administrative layer of the PM’s work: writing stories, updating boards, summarising stakeholder calls. PMs who want to remain essential should stop protecting that administrative layer and go deeper into the judgment layer. Learn to read a diff. Understand what technical debt actually costs. Be the person who can look at an engineering decision and reason about its business consequence — not just ask a developer to explain it.
Business Analysts: The BA’s core value is precision: converting fuzzy business intent into testable, unambiguous specifications. AI can generate a first draft of requirements from a meeting transcript. It cannot catch the edge case that only appears when you understand both the business process and the technical implementation. BAs who learn enough SQL to query their own data, enough system design to ask the right questions about integrations, and enough about AI tooling to use it in their own workflow will remain valuable. Those who stay in the document-writing lane will find that lane narrowing.
QA Engineers: The clearest and most urgent evolution. Manual test execution is disappearing. Test case writing from scratch is disappearing. What is not disappearing is the judgment about what matters enough to test, the ownership of quality culture, and the expertise to design a testing strategy that catches what automation misses. QA professionals who learn to code — even at a moderate level — and shift their identity from “tester” to “quality engineer” are positioning themselves correctly. Those who do not will find that senior developers absorb the role faster than any other.
DevOps and SRE Engineers: Platform engineering is the evolution here. The DevOps engineer who stays at the level of managing pipelines and writing YAML will see their work increasingly automated. The one who moves toward developer experience, internal tooling, and infrastructure that scales developer productivity becomes a force multiplier — a role that makes senior developers more effective rather than competing with them.
UX Designers: AI cannot replace the empathy, research, and strategic clarity that a great designer brings. But it can generate wireframes, produce design variations, and write microcopy. Designers who treat AI as a production tool — and spend the freed time on the research and strategy that AI cannot do — will thrive. Those who compete with it on pixel production will not.
Scrum Masters and Project Managers: This is the role under the most pressure, and being direct matters more than being comfortable here. Ceremony facilitation, status reporting, and board hygiene are all automatable. To be fair: the best Scrum Masters are not ceremony runners — they are organisational engineers. They fix the team dynamics, political friction, and communication failures that no sprint board can capture. That work is genuinely hard to automate and genuinely valuable. The ones under pressure are not those people. They are the ones who have not made that evolution yet — the ones who protect the ceremony are protecting the automatable part.
The Question That Matters
None of this means other roles are worthless. Every role on this list, done well by the right person, makes a team faster and better.
But the question was not “which roles add value?” The question was “who is last in the Venn diagram?”
The senior developer is last because they are the only role that cannot be fully absorbed by any other single role on the team — while they can absorb meaningful portions of all of them. That asymmetry matters enormously when headcount gets tight, when startups can only hire one person, or when AI tooling is redistributing what one person can credibly own.
The lesson for every non-developer reading this is not to become a developer. It is to understand why the senior developer’s surface area is so large — and ask honestly whether your own role is building a surface area that is just as hard to compress.
Because if it is not, someone who can code is already quietly absorbing it.
References:
[1] Tom’s Hardware — “Tech industry lays off nearly 80,000 employees in the first quarter of 2026 — almost 50% of affected positions cut due to AI.” https://www.tomshardware.com/tech-industry/tech-industry-lays-off-nearly-80-000-employees-in-the-first-quarter-of-2026-almost-50-percent-of-affected-positions-cut-due-to-ai
[2] Digiteum — “Software Development Team Structure: Developer Roles.” https://www.digiteum.com/software-development-team-structure/
[3] Clockwise Software — “Software Development Team Structure [Roles You Need in 2025].” https://clockwise.software/blog/software-development-team-structure/
[4] Final Round AI — “AI Job Displacement 2025: Which Jobs Are At Risk?” https://www.finalroundai.com/blog/ai-replacing-jobs-2025
[5] LinkedIn / Hazem Ali — “Layoffs & AI: The Impact on Software Engineering (2023–2025).” https://www.linkedin.com/pulse/layoffs-ai-impact-software-engineering-20232025-hazem-ali-b0apf
The Last One Standing Will Be a Senior Developer was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.
