The distinct roles we’ve organised software development around—Product Owner, Business Analyst, Developer, QA, DevOps—are collapsing into each other. Not eventually. Right now. I’m watching development teams of five or six people reduced to one or two, and most Business Analysts haven’t even grasped what’s happening yet.
I’m writing as directly as I can about this because the BA community is lagging badly. Your software engineering colleagues already see it. They’re either adapting or they’re quietly worried. Meanwhile, BAs are still having the same conversations about stakeholder management and requirements elicitation that we had five years ago, as if the ground hasn’t shifted beneath us.
It has. Completely.
What I’m Doing Right Now
My current engagement has me building a distributed fault-tolerant network, integrating cryptographic routines, managing multiple Docker containers and MongoDB instances, writing modules in Go, and scripting an entire integration test framework in Bash. All of this within a WSL2 Linux environment on my Windows laptop. I’m working directly with the business owner—no intermediaries, no handoffs.
I spent the last 20 years specialising in C# .NET and SQL. I’ve never formally trained in Go, Bash, Docker, or distributed systems architecture. I call myself a “technical BA” for ATS purposes, but that description is increasingly meaningless.
What’s changed isn’t that I suddenly became a polyglot programmer. It’s that advanced AI tools like Claude Code have removed the technical barriers that once enforced role boundaries. I can now look for patterns, recognise clean code, ask agents to refactor to established patterns, extract helper methods, and write documentation without needing to read “Bash Scripting for Dummies” or spend months learning Go idioms.
The technical friction that kept BAs in their lane has evaporated. And with it, the justification for having separate people doing requirements, development, testing, and deployment.
The Five Roles Are Becoming One
I can see this clearly now: PO, BA, DEV, QA, DevOps. These were always somewhat artificial distinctions, but they were enforced by real technical barriers. Product Owners couldn’t write code. BAs couldn’t build test frameworks. Developers didn’t have time to gather requirements properly. QA couldn’t configure deployment pipelines.
Those barriers are gone. Anyone with pattern recognition, domain knowledge, and the ability to effectively direct and review AI-generated work can now operate across all five roles. Not perfectly, and not without genuine expertise, but competently enough that organisations are questioning why they need five separate people.
This isn’t about AI making you faster at writing requirements documents. This is about the “business requirements specialist” becoming obsolete now the person who understands the problem can also build and test the solution in the same afternoon.
Why This Demands More Expertise, Not Less
Here’s what surprised me most: I’m levelling up my analysis and development skills after 20 years in the industry like never before. The expertise demands have intensified, not diminished.
I have a swarm of agents now—planning agents, test-driven development agents, coding agents, refactoring agents, documentation agents. None of them are fully trustworthy despite their overconfidence. The planning agent looked like magic at first, but it can’t decide which architectural patterns are appropriate for a given context. It simply cannot make those judgment calls. The transition from a well-structured codebase to an unmaintainable mess is only a few autonomous commits away.
I need to be a deeper expert now in all areas of the SDLC just to keep the swarm from becoming unwieldy. A few rounds of conversation with the planning agent will iron things out, but I’m still the one deciding, informed by years of actually building systems. What would happen if an entry-level developer or a non-technical BA faced my agent swarm? It wouldn’t be pretty.
This is the expertise paradox. The “democratisation of coding” narrative is wrong. What’s actually happening is that the bar for effective orchestration has gone up dramatically. You need to know what good looks like across multiple domains, or you’ll confidently build garbage at scale.
Domain knowledge matters desperately in this new model. My whole career arc proves this—from a disaster of trying to analyse a Chartered Surveyor’s business with zero domain knowledge, to my current specialised position in financial services software. The “generalist BA” was always mostly fiction. Now it’s completely untenable.
The Enterprise Isn’t Ready For This
The problem isn’t just that individual roles are changing. The problem is that role collapse is fundamentally at odds with how enterprises plan, resource, and manage their staff.
Budgets are allocated by role and headcount. Career progression is role-based. Teams are structured around specialised functions. Hiring happens through role-specific job descriptions. Performance management assumes stable role definitions. Salary bands are tied to role categories.
I’m describing a reality where one person does what five specialised roles used to do, where roles become fluid and situational, where value comes from judgement and orchestration rather than execution. This breaks every HR system, every budgeting model, every organisational structure that enterprises depend on.
The gap between what’s technically possible and what’s organisationally feasible is widening fast. And most organisations are choosing to ignore the technical reality because acknowledging it would mean dismantling their entire operating model.
What Happens to Everyone Else?
I keep coming back to the same uncomfortable question: what happens to the four or five displaced people in every team, in every company?
We already have massive welfare bills, people out of work, and post-pandemic impacts still unfolding. “Get a trade” isn’t a realistic option for most people. Apprenticeships cost thousands and take years, and there isn’t a mass shortage of qualified tradespeople anyway. Even construction is moving toward prefab and automation.
I’m afraid of where this is headed. I might be one of those five displaced people. Perhaps consulting will be automated. Perhaps I won’t be able to acquire a trade. I don’t know whether to feel elated or depressed about what I can do now, and that internal conflict isn’t going away.
I’m not trying to fear monger or spread panic—I’m reporting what I’m seeing from inside the transformation. And it’s uncomfortable, really uncomfortable.
What BAs Need to Do Now
The honest answer is that I don’t have a neat list of action items. Anyone offering you five bullet points to “AI-proof your BA career” is either deluding themselves or trying to sell you something.
What I do know: if you’re a BA without technical depth, without real domain expertise, without the ability to evaluate code quality or system architecture, you’re in serious trouble. The value proposition of the “pure process BA” has collapsed.
If you’re a technical BA who understands systems, who has deep domain knowledge, who can stripe across multiple roles effectively—you’re potentially in a stronger position than ever. But you need to be building things, not just documenting what others should build.
The shift is from describing to doing. Many of my earlier posts were observational. Recent posts are “here’s what I built.” That progression isn’t optional anymore.
Start small. Pick one problem that actually bothers you. Build an agent to solve it. Not “write better requirements”—that’s too vague. Something specific. Let the first agent teach you how to build the next one. Work with the tools until you understand both their capabilities and their profound limitations.
Because here’s the thing: whether you engage with this or not, the collapse is happening. Development teams are getting smaller. Role boundaries are dissolving. The technical barriers are gone.
The question isn’t whether the BA role is changing. The question is whether you’re changing with it fast enough to remain relevant.
I’m lucky enough to be around to see this transformation, even if I’m genuinely unsure where it leads. For BAs still having the old conversations about stakeholder management and requirements templates, I’d suggest the ground has shifted from underneath you. The only question now is whether you notice in time to adapt.