Why Most Software Developers Are About to Become Business Analysts and QA Engineers

Here’s an observation that I think most developers aren’t ready to hear: the job you trained for is becoming two other jobs — and neither of them is writing code.

As AI takes over the act of code generation — and it is, rapidly — the work that remains for human developers looks remarkably like two roles that have existed for decades: the business analyst and the QA engineer. Understanding what to build. Verifying that what was built is correct. The bit in the middle — the actual writing of code — is increasingly handled by AI.

This isn’t a distant prediction. It’s happening right now in every team that uses IDE-based AI tools seriously. And it has profound implications for how developers think about their careers, how companies hire, and how software gets built.

The shrinking middle

Software development has always been a three-phase process:

1. Understand the problem — figure out what needs to be built and why
2. Write the solution — translate that understanding into working code
3. Verify the output — confirm that what was built actually solves the problem correctly

For the last 50 years, phase two consumed the vast majority of a developer’s time and attention. Understanding requirements and verifying correctness were important, sure — but the hard, time-consuming, economically valuable part was the coding itself. That’s where the skill premium lived.

AI is collapsing phase two.

Tools like Cursor, Claude Code, and GitHub Copilot don’t just autocomplete lines. They generate complete features from specifications. They refactor entire codebases. They write comprehensive test suites. They debug their own output. The gap between “here’s what I need” and “here’s working code” is narrowing to the point where the coding phase — the part developers have always considered their core value — is becoming the fastest and least human-dependent part of the process.

What remains? Phases one and three. Understanding the problem. Verifying the solution. Business analysis and quality assurance.

Phase one: the developer as business analyst

The highest-leverage activity in AI-assisted development isn’t writing code. It’s defining, with precision, what needs to be built.

This is business analysis. And most developers are terrible at it — not because they lack intelligence, but because they’ve never had to be good at it. In the old model, a product manager or business analyst would define requirements, and the developer’s job was to translate those requirements into code. The developer could get away with a shallow understanding of the business context because their value was in the technical translation.

That’s no longer sufficient. When AI handles the technical translation, the quality of the input becomes everything. And “the input” is the specification — the precise, unambiguous definition of what the system should do, for whom, under what conditions, with what constraints.

Writing a specification that AI can execute well requires:

Deep understanding of the business domain. Not just “what feature do they want” but “why do they want it, what problem does it solve, how does this fit into their workflow, what happens when it goes wrong, what adjacent systems does it touch.” This is the work that business analysts have always done — mapping the real-world complexity of a business into structured requirements.

Stakeholder communication. Sitting with users, asking the right questions, listening to what they say and what they don’t say, reconciling conflicting requirements, managing expectations. These are soft skills that most developers have actively avoided. They’re about to become essential.

Edge case thinking. AI is remarkably good at handling the happy path — the main flow where everything works as expected. It’s weaker at anticipating the edge cases: what happens when the user enters invalid data, when the network drops mid-transaction, when two processes conflict, when the data model doesn’t fit the real-world scenario. Identifying these edge cases before they become bugs is a fundamentally human skill that requires deep understanding of both the business context and the technical constraints.

Precise, structured communication. A vague requirement produces vague AI output. A precise specification produces precise AI output. The ability to write structured, unambiguous, complete requirements — closer to a legal contract than a Jira ticket — is becoming the single most valuable skill a developer can have.

If this sounds like the job description of a senior business analyst, that’s because it is.

Phase three: the developer as QA engineer

The other end of the AI-assisted development workflow is equally important and equally undervalued: verifying that the output is correct.

AI generates code quickly. It generates a lot of it. And most of it looks right — syntactically correct, logically coherent, seemingly functional. The problem is “most” and “seemingly.” AI-generated code can contain subtle bugs, security vulnerabilities, performance issues, and logical errors that aren’t immediately obvious. It can produce code that passes basic tests but fails under real-world conditions. It can implement something that technically matches the specification but doesn’t actually solve the user’s problem.

Catching these issues requires a skill set that maps directly to quality assurance:

Code review with a critical eye. Not just reading code to understand it, but reading code to find what’s wrong with it. Does this handle null values? Is this SQL query vulnerable to injection? Does this race condition get handled? Will this scale under load? These are the questions that QA-minded developers ask — and they’re the questions that matter most when the code was generated by AI rather than written thoughtfully by a human.

Testing strategy. Knowing what to test, how to test it, and when the testing is sufficient. AI can generate tests — but AI-generated tests often test the implementation rather than the requirement. “Does this function return the right value?” is a different question from “Does this feature solve the user’s problem?” Designing test strategies that verify business outcomes, not just code behaviour, is a deeply human skill.

Regression awareness. When AI modifies code in one part of the system, does it break something elsewhere? AI tools are getting better at maintaining coherence across a codebase, but they still introduce regressions — especially in complex systems with many interdependencies. The future of software development demands people who can think about systems holistically, not just evaluate individual components.

Security and compliance review. AI doesn’t inherently understand your security and governance requirements. It doesn’t know which data is sensitive, which regulations apply, or what your organisation’s risk tolerance is. Reviewing AI-generated code for security implications — and catching the subtle vulnerabilities that AI introduces — requires human judgment with domain-specific knowledge.

Performance evaluation. AI-generated code often works but isn’t optimised. It might make unnecessary database calls, create memory leaks, or implement algorithms that work fine with 100 records but fall over with 100,000. Evaluating performance under realistic conditions is a skill that requires understanding both the technical implementation and the expected usage patterns.

If this sounds like the job description of a senior QA engineer, that’s because it is.

Why developers resist this framing

I’ve shared this perspective with a lot of developers. The pushback is consistent:

“I’m not a BA. I’m not a QA. I’m a software engineer.”

I get it. There’s an identity issue here. Developers have spent years — sometimes decades — building an identity around writing code. It’s what they studied. It’s what they practiced. It’s what they’re proud of. Being told that the core of their identity is being automated feels threatening.

But here’s the thing: the skills that make a great developer have always been more about understanding and judgment than about typing code. The best developers I’ve worked with spend more time thinking than coding. They ask more questions than they answer. They catch more bugs in review than they create in implementation. They’re valued for their judgment, not their keystrokes.

AI isn’t eliminating what makes great developers great. It’s eliminating the mechanical labour that was never the valuable part anyway. The developers who resist this shift are clinging to the assembly-line work while the craftsmanship moves upstream and downstream.

What this means for hiring

If you’re hiring developers today — or in the near future — the implications are clear:

Prioritise domain knowledge. A developer who deeply understands your industry, your customers, and your business processes will extract dramatically more value from AI tools than a technically brilliant developer who doesn’t understand the business context. Domain knowledge is the ingredient that turns a generic AI prompt into a precise specification.

Test for specification writing. In your interview process, ask candidates to take a vague business requirement and turn it into a precise, structured specification. This tests exactly the skill that determines success in AI-assisted development. Can they ask the right clarifying questions? Can they identify edge cases? Can they write requirements that leave no room for misinterpretation?

Test for code review, not code writing. Instead of asking candidates to write code on a whiteboard, show them AI-generated code and ask them to review it. Can they spot the bugs? Can they identify the security issues? Can they evaluate whether the code actually meets the requirement? This is the skill they’ll use every day.

Value breadth alongside depth. Developers who understand product management, business analysis, and quality assurance — in addition to software engineering — are the generalists the future demands. The narrow specialist who only writes code is a declining asset.

What this means for career development

If you’re a developer reading this, the career advice is straightforward:

Learn to talk to humans, not just machines. Stakeholder interviews, requirements workshops, user research — these are skills that compound in value as AI handles more of the technical execution. Take a course in business analysis. Shadow your company’s BA or product manager. Learn to facilitate a requirements session.

Get serious about quality. Learn testing methodologies beyond unit tests. Understand security review. Learn performance profiling. Develop a systematic approach to evaluating AI-generated code. These skills are already differentiating the best AI-augmented developers from the average ones.

Deepen your domain expertise. Don’t just be a developer who works in fintech. Become a developer who understands financial services regulation, payment processing, and risk management deeply enough to write specifications that AI can execute without business context errors. Domain expertise is the moat that AI can’t cross.

Practice specification writing. Every time you use an AI tool, pay attention to the relationship between the quality of your input and the quality of the output. Refine your ability to write specifications that produce excellent AI-generated code on the first pass. This is the highest-leverage skill you can develop right now.

Don’t abandon code — but reframe your relationship with it. You still need to read code, understand code, evaluate code, and debug code. You need to understand architectures, patterns, and trade-offs. What you need less of is the ability to write thousands of lines of code from scratch at speed. Shift your code skills from writing to reading, from generating to evaluating.

The parallel to other industries

This shift isn’t unique to software development. It’s happened — or is happening — in every industry where AI automates the production middle.

Journalism. AI can write articles. The valuable journalism skills are now investigation (understanding what stories matter) and editing (verifying that the output is accurate and well-structured). The BA and QA of media.

Architecture. AI can generate building designs. The valuable architecture skills are now understanding client needs and site constraints (requirements) and ensuring the design is structurally sound and code-compliant (quality assurance). The BA and QA of construction.

Finance. AI can generate financial models and analyses. The valuable finance skills are now understanding the business context (what assumptions matter) and evaluating whether the model’s outputs make sense (quality assurance). The BA and QA of financial services.

The pattern is universal: when AI automates production, the human value migrates to definition and verification.

A practical example

Here’s how this plays out in practice. Say your company needs a new customer onboarding flow.

Old model: A BA writes requirements. A designer creates mockups. A developer spends two weeks writing the code. A QA engineer spends three days testing it. Elapsed time: three to four weeks, involving four people.

New model: A developer — one person — spends two days deeply understanding the business requirements. They interview the customer success team. They map the existing onboarding process. They identify drop-off points and edge cases. They write a detailed specification.

Then they feed that specification to an AI development tool. The code is generated in hours, not weeks.

Then the same developer spends a day rigorously reviewing and testing the output. They check the edge cases they identified earlier. They verify the business logic. They test the security implications. They confirm it handles the real-world scenarios they mapped during requirements gathering.

Elapsed time: three to four days, involving one person.

The developer in the new model did more BA work and more QA work than the developer in the old model. The coding part — the thing the old developer spent two weeks on — took an afternoon.

The bottom line

The developer role isn’t disappearing. It’s bifurcating. The mechanical middle — writing code from requirements — is being automated. What remains is the upstream work of understanding problems and defining solutions (business analysis) and the downstream work of verifying correctness and ensuring quality (QA engineering).

The developers who recognise this shift and invest in those skills will become more valuable, not less. They’ll be the ones who can take a vague business need and turn it into a shipped, correct, high-quality product — faster than ever before, because AI handles the production in between.

The developers who cling to code writing as their core identity will find themselves competing with an AI that writes code faster, cheaper, and increasingly at a level that’s good enough. That’s a competition they won’t win.

The future of the developer isn’t writing code. It’s knowing what to build and whether it’s right.

Frequently Asked Questions

Are developers really becoming business analysts and QA engineers?

Not in title — but in practice, yes. As AI takes over the act of writing code, the work that remains for human developers increasingly resembles what business analysts and QA engineers have always done: understanding requirements deeply, translating business needs into precise specifications, verifying that outputs are correct, and ensuring quality across the system. The developers who thrive will be the ones who embrace these skills rather than clinging to code writing as their primary identity.

Will coding skills become irrelevant?

No, but their relative value is changing. Understanding code remains essential for reviewing AI-generated output, debugging complex issues, making architectural decisions, and knowing what’s possible. What’s becoming less valuable is the ability to write code from scratch at speed — because AI does that faster than any human. Think of it like the shift from handwriting to typing: literacy still matters, but the mechanical skill of beautiful penmanship is no longer the differentiator.

How should developers prepare for this shift?

Invest in the skills that sit upstream and downstream of code writing. Upstream: learn to understand business domains deeply, conduct stakeholder interviews, define requirements precisely, and write specifications that leave no ambiguity. Downstream: develop rigorous quality evaluation skills, learn to review AI-generated code for correctness and security, build expertise in testing strategies, and cultivate the judgment to know when output is good enough to ship. These are the skills that compound as AI gets better at writing code.