In this third article on how AI is affecting IT functions, I consider the role of Business Analysts (BA’s) in IT departments and how quickly, and how much, the ground is starting to shift.

For a long time, the BA role sat in a fairly familiar place. Understand the business need, work with stakeholders, capture requirements and develop test cases (not an easy task). Then help translate those requirements for delivery teams, support testing, change, and implementation.

All of the above work is still needed but the boundary around it is changing. Agentic coding, structured vibe coding, AI-assisted requirements tools, and AI-enabled delivery platforms are starting to compress the distance between idea, requirement, prototype, test case, and working software - which raises a very practical question.

What happens to the BA role when describing the thing increasingly starts to create the thing?

What is it?

This is not about Business Analysts becoming full-time developers and it is not about AI replacing the need for stakeholder engagement, judgement, context, or accountability. It is about the BA role moving closer to the point where business intent becomes executable.

In the past, a requirement was often a document, a user story, a process model, a backlog item, maybe a partially actionable wireframe or a set of acceptance criteria. Those artefacts still matter, but they are becoming more active, they can now be used by AI tools to generate draft user stories, test cases, process models, UI mock-ups, code, release notes, and even working prototypes (which I think the major change and process compression that is going to happen).

We are also seeing GenAI change the tools that BA’s use. Many BA and requirements platforms have already added GenAI capabilities such as requirements drafting, summarisation, natural language querying, ambiguity checking, overlapping requirements, test generation, process modelling, INCOSE requirements assessment and traceability support. Tools such as Atlassian Jira and Confluence (Atlassian announced AI generated test cases as far back as Dec 2024), IBM DOORS Next, Jama Software Connect, Siemens Polarion and PTC Codebeamer are all moving in this direction, although at very different levels of maturity.

Some of these tools are still mostly assistive, they help draft, summarise, search, or reformat content. Some are becoming more analytical, they check requirement quality, identify ambiguity, suggest missing test cases, or detect inconsistencies. Some are starting to become agentic (see Jama Software MCP capability). They can support action across tools, update items, orchestrate workflows, and support multi-step work with human oversight.

Business Analysis is no longer only about producing better documentation, it seems to be becoming about shaping the operating instructions for AI-enabled delivery.

I tend to think about the shift in stages (using the AI4 Enterprise Maturity Framework and an additional Prototype step).

• Assist: AI helps the BA draft, summarise, clean up, and search. This is the most common starting point.
• Augment: AI improves the quality of BA work by checking requirements, finding ambiguity or overlap, suggesting acceptance criteria, or generating test cases.
• Advise: AI starts supporting multi-step analysis, such as impact assessment, traceability review, risk identification, or stakeholder preparation.

Prototype: BAs begin using agentic coding tools to help turn requirements into working prototypes, not just wireframes or static mockups. The important caveat is that this should happen within constraints defined by development teams, such as approved frameworks, architecture patterns, coding standards, security requirements, integration boundaries, and repository guidance. Think of something like a CLAUDE.md file that tells the coding agent how to behave inside that environment.

• Act: Agents begin taking delegated actions, such as creating backlog items, updating records, generating documents, or moving work through a workflow.
• Automate: AI systems operate with more autonomy, within defined controls, to manage routine analysis, documentation, or coordination work.

This prototype step is important. It gives BAs a way to move stakeholder conversations from “does this requirement read correctly?” to “is this how the workflow should actually behave?” That can be extremely useful, especially for internal tools, process automation, data-entry workflows, service portals, and decision-support applications.

But it also changes the risk because a working prototype feels much more real than a wireframe. So the BA needs to be clear that the prototype is there to validate understanding, not to bypass architecture, security, privacy, testing, support, or production engineering. The better mental model is not “BA’s become developers”, it is “BA’s can help create better validated requirements by using working software as part of the discovery process”.

What does it mean from a business perspective?

The practical business issue is not whether BA teams use AI, some (if not all) already do. The useful question is whether organisations know how the work is changing and whether they are managing that change deliberately.

• Business value is created when AI improves the flow from need to outcome. A tool that drafts user stories faster is useful, but the bigger value comes when the organisation can move from stakeholder conversation to validated requirement, to prototype, to test, to decision more quickly and with less rework.
• Effort savings and duration savings are different things. A BA may save hours drafting requirements or preparing meeting notes, but that does not automatically mean the project finishes earlier. Duration savings come when decisions are made faster, ambiguity is removed earlier, rework is reduced, and stakeholders can react to something concrete sooner.
• The role moves closer to facilitation and validation. If AI can generate a draft process model or user story in seconds, the BA’s value is not typing the first version. The value is knowing whether it is right, whether it reflects the business reality, whether it misses a policy constraint, whether it creates operational risk, and whether the stakeholders actually agree.
• Structured vibe coding makes this even more interesting. When a BA can work with AI tools to generate a prototype or a working internal tool (using corporate coding conventions), the conversation with stakeholders changes - people do not only review words on a page, they can react to something that behaves, even if it is rough.
• Quality control becomes a design issue. It is not enough to say “a human will review it.” Organisations need to decide what must be reviewed, by whom, at what point, against what standard, and with what evidence left behind.
• Procurement and vendor management also become part of the BA tool conversation. Vendors are using different models, deployment approaches, APIs, and governance options and are different levels of maturity. If a BA platform can generate requirements, test cases, summaries, trace links, and workflow actions, then the organisation needs to understand where the data goes.

The BA role also starts to overlap more with product ownership, architecture, service design, data governance, and change management. That does not mean one person owns all of it, it does mean the handoffs need to become clearer and the edges of roles need to be understood.

What do I do with it?

The practical starting point is not to redesign the BA function overnight, start by understanding where the work is already changing.

• Map where AI is being used today. (This is a common theme in these articles.) Start with reality, not aspiration. Are BAs using Copilot, ChatGPT, Claude, Jira AI, Confluence AI, requirements tools, meeting assistants, or code generation tools? What are they using them for? Drafting? Summarising? Analysis? Prototyping? Test generation? Stakeholder preparation?
• Separate assistance from action. (Another common theme.) Treat AI that helps someone think, draft, summarise, or analyse differently from AI that changes records, creates work items, updates workflows, generates test cases, or interacts with production systems. The level of governance should increase as the AI gets closer to operational action.
• Reframe requirements as inputs to execution. In an AI-enabled delivery environment, vague requirements are not just annoying. They can produce misleading outputs quickly. Good BA practice becomes more important because AI amplifies whatever it is given when the requirement drive code generation directly.
• Build structured vibe coding into discovery carefully. Used well, prototypes can help stakeholders clarify what they really mean. Used badly, they can create shadow systems, unsupported tools, or unrealistic expectations. Keep the distinction clear between prototype, pilot, and production. Develop a path for the development teams to onboard structured vibe coded PoC’s (or at least have a policy and process for dealing with the artifacts).
• Develop BA literacy in AI-enabled delivery. BAs do not all need to become software engineers, but they do need to understand prompts, context, data sensitivity, model limits, hallucination risk, agent behaviour, workflow automation, and the difference between a useful demo and an operable system.
• Involve architecture, security, privacy, and support earlier. If a BA is using AI to move from requirement to prototype, those conversations cannot wait until the end. The earlier AI creates something that looks like software, the earlier the organisation needs to think about how it would actually be operated.
• Measure value in operational terms. Look at reduced rework, faster triage, better stakeholder alignment, improved requirement quality, better test coverage, reduced backlog, better knowledge reuse, and clearer compliance evidence. Time saved on drafting is useful, but it is only one part of the story.
• Keep human accountability explicit. AI may draft the requirement, suggest the test case, or generate the process model. A person still needs to own the decision. That ownership should be visible in the workflow, not assumed in the background.

The point here is not that the BA role is disappearing, more that it’s changing, moving upstream with tighter stakeholder alignment and moving downstream into prototyping. It’s also becoming more important at the boundary between business intent and automated execution.

The BA of the future may spend less time producing the first draft of a document and more time shaping the quality of what AI-enabled delivery produces.