Business Analysts and AI
What Business Analysts Do Differently
AI coding assistants make business analysts more important, not less. The BA's job moves from writing requirements documents to structuring the business context that AI tools build from, keeping that context current, and checking that what the AI built matches what the business meant.
There is a persistent misconception that AI coding assistants will make business analysts obsolete. The logic goes like this: if AI can generate code from natural language descriptions, and if product managers already know what they want, then who needs a BA between intent and implementation? This reasoning sounds plausible and is almost entirely wrong.
The BA becomes the steward of business context, and context is now a production input: the raw material AI tools consume to generate output. When context is thin, ambiguous or wrong, AI produces code that is confidently incorrect. When context is structured and precise, AI produces code that solves the business problem. The quality of BA work has always mattered. With AI, it matters faster and more visibly.
Why Ambiguity Costs More Now
In a traditional development workflow, ambiguity in requirements was expensive but survivable. A developer who hit a vague requirement would ask a question, wait for an answer, or make a reasonable assumption based on experience. The feedback loop from requirement to implementation to review took days or weeks, and ambiguities surfaced gradually during development and testing.
AI collapses that timeline. When a developer uses an AI coding assistant to implement a feature, the tool generates code in minutes. If the requirements are ambiguous, the AI doesn't pause to ask clarifying questions. It makes choices silently, confidently and sometimes incorrectly. The developer reviewing the output may not catch the misalignment, because the code works, the tests pass and the feature behaves reasonably for the common case. The business-critical edge case that was never specified doesn't surface until a user hits it in production.
Every ambiguity in a business requirement now compounds faster. What used to be a slow leak becomes a burst pipe. A BA who doesn't specify how the system should handle a partial refund, a mid-cycle plan change or a timezone boundary doesn't just create a future bug. They create an immediate one, deployed at AI speed. The chapter on writing requirements for AI-assisted development covers how to close those gaps before work starts.
From Writing Requirements to Structuring Context
The traditional BA artifact was a requirements document: a narrative description of what the system should do, usually written in business language and translated by developers into technical specifications. It served as a communication bridge between business stakeholders and the development team.
AI changes the purpose and form of BA output. The requirements document still matters, but it is no longer enough. BAs now have to produce structured context that both human developers and the AI tools those developers use can consume.
Structured context means business workflows translated into explicit rules, examples, state transitions and exception paths. It means a domain glossary that defines terms precisely: not "customer" in the colloquial sense, but "customer" as a specific entity with defined attributes, lifecycle states and relationships to other entities. It means process maps that show every branch, decision point and error condition, not just the happy path. It means data rules that specify validation constraints, transformation logic and referential integrity requirements.
Consider an insurance claims workflow. A traditional requirements document might state: "The system should allow adjusters to approve claims within their authority level." A structured BA artifact would define the authority levels (with dollar thresholds), the escalation path when a claim exceeds authority, the documentation required at each level, the notification rules for each state transition, the handling of claims that cross authority boundaries mid-review, and the audit trail requirements. This level of detail was always valuable. Now it is essential, because the AI coding assistant will implement exactly what it is told, no more and no less.
AI-Ready Artifacts
Business analysts should organize their deliverables around artifacts that do double duty: readable by stakeholders for review, and structured enough to feed into AI-assisted development. Together these artifacts form the context layer that developers bring into their AI tools.
A domain glossary defines the bounded vocabulary of the system. It removes the ambiguity that arises when stakeholders use the same term to mean different things: when "order" means one thing in sales and another in fulfillment, or when "active" means "currently logged in" to support and "subscription not expired" to billing. A precise glossary is not pedantic. It stops an AI coding assistant from implementing a feature that technically works but operates on the wrong definition of a core concept.
Process maps capture the full shape of business workflows, including exception paths stakeholders rarely mention because they seem obvious. The adjuster who always knows to call legal when a claim involves a minor holds tacit knowledge that has to be written down, because AI tools have no tacit knowledge. Every implicit rule that lives in a team member's head is a potential defect in AI-generated code.
Data rules specify the constraints, validations and transformations that govern business data. Not just "email must be valid" but "email must be valid, unique within the tenant, not from a disposable email provider, and verified within 72 hours of account creation or the account enters a suspended state." Expressed this precisely, rules translate directly into validation logic.
Permission matrices define who can do what under which conditions. Role-based access is the obvious case. The real complexity is in conditional permissions: an approver who can approve up to a threshold, a manager who can view reports for their region but not others, a support agent who can issue refunds only for orders placed within the last 30 days. These conditional rules are where AI-generated code most often diverges from business intent, because they depend on domain knowledge the AI does not have.
Acceptance criteria and UAT scenarios complete the set. They should be testable statements, not aspirational descriptions of behavior: concrete conditions that can be verified against running software. UAT scenarios in particular should cover the cases that matter most to the business, including edge cases that are easy to overlook and expensive to miss.
Living Documentation
Static documents decay. A requirements document written in January is partly obsolete by March, mostly obsolete by June, and actively misleading by December. That has always been a problem, and AI amplifies it. When developers feed stale documentation into AI tools as context, they get implementations that reflect outdated business rules. The code is technically correct against the documented requirements and functionally wrong against the current business.
Business analysts have to shift from producing documents to maintaining living documentation: artifacts that are updated continuously to reflect current business rules, workflows and constraints. Agile methods have argued for this for two decades. AI adds a concrete, immediate incentive: current documentation directly improves the quality of AI-generated code, and stale documentation directly degrades it.
In practice, BA time shifts. Less time writing comprehensive upfront specifications, more time maintaining a smaller set of high-value artifacts. Less time in requirements workshops that produce documents nobody revisits, more time working with developers who need current context for their AI-assisted work.
Some teams already store BA artifacts in formats AI tools can consume directly: structured Markdown in repositories, machine-readable rule definitions, or dedicated context files that developers include in their prompts. The practice is not yet standardized, but BA output is moving into the codebase context instead of living as a separate document in a separate system.
The Azumo SDLC, our way of working with coding agents, is built on this idea:
- Business analysts write down what they know as skills (how to do a step) and rubrics (what good looks like), so that knowledge lives in the shared kit agents work from, not in one person's head.
- Context lives with the project, not in one chat. Handoffs and decisions are saved to shared project memory, so the next session starts from the current rules.
- Agents propose; people approve.
Validating AI Implementations Against Business Intent
The most significant shift in the BA role may be the move from pre-implementation work to post-implementation validation. Traditionally, BAs did most of their heavy lifting before development began: eliciting requirements, analyzing workflows, documenting specifications. Once development started, their involvement often shrank to answering occasional questions and taking part in UAT.
AI-assisted development inverts this pattern. Implementation happens quickly, often on the same day requirements are defined. The BA's critical contribution shifts toward validating that the AI-generated implementation matches business intent. That is harder than it sounds, because AI-generated code is often subtly wrong in ways that take deep domain knowledge to detect.
An AI might implement a discount calculation that applies discounts sequentially instead of on the original price, producing slightly different totals. It might implement a date range filter with inclusive boundaries on both ends when the business expects an exclusive end boundary. It might implement notifications that send an email on every state change instead of only the changes the business considers meaningful. Automated tests that verify the code works won't see these discrepancies. Only someone who understands what the business needs will.
Business analysts are well placed for this work. They know the domain well enough to recognize when an implementation is technically correct but functionally wrong. That makes the BA's post-implementation review a quality gate: not a code review in the technical sense, but a business logic review that checks what was built against what was intended. It is also why UAT matters more with AI, not less.
The Automation Horizon
Research from McKinsey and Forrester suggests that most routine BA tasks, such as requirements templating, data flow documentation and standard report generation, will become AI-assisted or AI-automated. This changes the BA role rather than threatening it.
The routine work that fills much of a BA's week, such as formatting documents, maintaining traceability matrices, generating standard reports and updating Jira tickets with requirements details, is the structured, repetitive work AI handles well. As it is automated, BA time goes to work that requires business judgment: resolving conflicting stakeholder priorities, identifying unstated assumptions, recognizing when a proposed solution conflicts with regulatory requirements, and validating that AI-generated implementations match how the business actually operates.
This shift demands new skills. BAs need to be comfortable working with AI tools, not as developers, but as domain experts who can evaluate AI output against business reality. They need to translate between business language and the structured formats AI tools consume most effectively. And they need the judgment to recognize when AI-generated analysis is trustworthy and when it is plausible-sounding nonsense.
The Context Economy
Business context has become a first-class production input, as important as code, tests or infrastructure configuration. The team with the best-structured business context gets the best results from AI coding assistants. The team with vague, outdated or contradictory context gets code that is confidently wrong.
Business analysts are the natural owners of this context layer. They understand the domain, they translate between stakeholder language and developer language, and they have the analytical skills to turn complex workflows into precise, testable rules. A BA who takes on this role, as steward of business context, validator of AI-generated implementations and maintainer of living documentation, contributes more in an AI-assisted team than in a traditional one.
A BA who stays with the old model, writing long requirements documents, maintaining static specifications and stopping at pre-implementation artifacts, will find more of that work automated and their contribution increasingly questioned. The role moves from document author to context architect.
How Azumo Works With Business Analysts
When we take on custom application development, business analysts sit inside the delivery team, and their domain knowledge shapes the context developers and coding agents work from: domain glossaries, exception paths and testable acceptance criteria. In the Azumo SDLC feature workflow (clarify, spec, plan, build, validate, review, deliver), the agent stops for a person's approval after the spec and after the plan. Those stops are where our BAs check the business rules before code is written, and they review the built feature against business intent before it ships.