The Business Analyst in the Age of the Dark Factory. How the BA Role Changes Across Six Levels of Software Engineering Automation
- Yevhen Kliukin
- Aug 26
- 24 min read
In January 2026, Dan Shapiro published an article titled “The Five Levels: From Spicy Autocomplete to the Dark Factory,” describing the evolution of AI use in software engineering — from almost entirely manual coding to an autonomous system capable of turning specifications into working software.
Despite the title, the model actually covers six states, from Level 0 to Level 5. Shapiro explains this by referencing zero-based numbering, borrowed from the classification of autonomous driving levels.
The original article focuses primarily on how the role of the software engineer changes. But it raises an equally important question for the Business Analysis community:
What happens to the Business Analyst when an organization’s engineering function moves to each successive level of automation?
One distinction is worth making at the outset.
This article is not about how actively a Business Analyst uses ChatGPT, Claude, or other AI tools. That could be described through a separate maturity model. Most discussions about AI and Business Analysis focus precisely on how BAs can use AI, while changes in software development itself — and their impact on the BA role — receive far less attention.
This article focuses on a different set of questions:
How is software developed at each level of AI adoption?
How does the software development lifecycle change?
What input context do engineers and agents need?
Who investigates the problem and its environment?
Who conducts discovery?
Who has the authority to make business decisions?
Who ensures the integrity of the specification?
Who evaluates whether the resulting solution is correct and valuable?
And does this operating model still require a dedicated Business Analyst role?
My central argument is that the transformation of the Business Analyst role will not be linear.
At Levels 0–1, the role changes very little. At Level 2, accelerated development can make analysis and business decision-making the new bottleneck. At Level 3, the way a BA interacts with the delivery process begins to change. At Level 4, engineers move into the specification layer, where the responsibilities of Business Analysts, product roles such as Product Owners and Product Managers, and the engineering function begin to overlap. At Level 5, the traditional BA role within delivery may lose a significant share of its responsibilities — even though the need for Business Analysis itself does not disappear.
This is also where Shapiro’s model leaves an important part of the discussion open. It primarily describes the automation of the engineering function, while saying relatively little about how discovery, the formulation of business intent, business decision-making, context management, and outcome validation change alongside it.
At the same time, Shapiro’s levels should not be treated as a formally validated industry standard or as a universal maturity model that every organization must progress through sequentially. Rather, they are a useful heuristic for discussing different states of software engineering automation.
Two Loops: Business Intent and Implementation
To understand the role of the Business Analyst within Shapiro’s model, we can think of software product development as two interconnected loops.
The business intent loop defines what problem needs to be solved, for whom, why it matters, and what an acceptable outcome should look like. It includes research, analysis of stakeholder needs, business rules, solution boundaries, constraints, key decisions, and acceptance criteria.
The implementation loop turns that intent into a working solution through technical design, planning, development, integration, testing, and deployment.
These loops are not sequential phases of a waterfall process. Business and technical decisions are shaped, challenged, and validated through continuous interaction.
Shapiro’s model primarily describes the automation of the implementation loop. But as this loop becomes faster and more autonomous, the demands on the quality of business intent, specification, and context increase significantly.
The Role of Business Analysis in Agentic Development
Business Analysis helps establish a shared understanding of the problem, align stakeholders around key decisions, build a coherent domain model, manage context, and define verifiable criteria for evaluating the outcome.
In traditional software development, teams can compensate for some gaps during implementation. A developer can ask a clarifying question, the team can revisit a specific user story, or an error can be corrected within a relatively small part of the functionality.
In agentic development, the scale of execution changes. Agents can handle increasingly large work packages autonomously — from individual tasks to substantial parts of a product or feature.
As a result, an error in requirements, business rules, or context configuration also scales. The same mistake can propagate simultaneously into architecture, code, tests, integrations, and documentation. Subsequent changes become more complex and expensive, and in extreme cases it may be easier to regenerate a significant part of the solution or rebuild it from scratch.
Faster development therefore raises, rather than lowers, the quality bar for Business Analysis.
The following become critical:
defining the problem and solution boundaries correctly;
aligning requirements and business decisions before initiating a large implementation cycle;
formalizing business rules, constraints, and exceptions;
creating and configuring context for agents;
validating the consistency of the specification;
defining criteria for demonstrating that the resulting solution is correct.
The more agents can implement autonomously, the more important high-quality input context becomes.
From Requirements to an Agent-Ready Specification
As larger parts of implementation are delegated to agents, it becomes increasingly important not only to align individual requirements, but to build a coherent body of context that agents can use to plan and implement the solution.
A set of user stories or a list of functional requirements may no longer be sufficient. Agents also need the business intent, solution scope and boundaries, domain concepts, rules, constraints, scenarios, assumptions, and criteria for determining whether the outcome is correct.
Throughout this article, I will refer to this managed set of interconnected knowledge and decisions as the specification, or spec.
It may include:
the problem, goals, and desired outcomes;
the scope and boundaries of the solution;
the domain model and terminology;
business rules, states, and scenarios;
constraints, assumptions, and agreed decisions;
acceptance and evaluation criteria.
A specification does not have to be a single document. It can be distributed across models, structured descriptions, decision logs, scenarios, contracts, tests, and a knowledge base.
For agentic development, what matters is that this context is consistent, traceable, and sufficiently unambiguous to support planning, implementation, and validation.
This does not mean the specification must be final, or that iterative discovery disappears. It needs to provide enough certainty for a specific implementation cycle while making it explicit what has been confirmed, what remains an assumption, and what still requires a decision.
Levels 0–1 — Manual Development and Isolated AI Tasks
How Development Works
At Level 0, developers build software manually. AI may be used for search or autocomplete, but it does not perform a meaningful share of the implementation work.
At Level 1, engineers delegate individual, localized tasks to AI, such as:
writing a test;
generating a small piece of code;
adding technical documentation;
suggesting a fix;
assisting with a routine technical operation.
The core development process remains under human control. AI is used for isolated tasks, while work decomposition, coordination, integration of the output, and overall control remain the responsibility of the developer.
The BA Role
For a Business Analyst, the difference between Level 0 and Level 1 is barely noticeable.
The BA still:
investigates needs and context;
works with stakeholders;
documents and aligns requirements;
models processes and data;
supports the team during implementation;
contributes to acceptance and outcome evaluation.
The primary consumers of Business Analysis outputs are still people. Because of that, part of the context can remain implicit — in conversations, shared domain knowledge, and informal agreements.
A developer can notice a contradiction, ask a clarifying question, or ask the BA to explain the underlying intent. The team can compensate for some imperfections in requirements directly during implementation.
Level 1 may make development somewhat faster, but from a BA perspective this is still a quantitative change rather than a qualitative one.
The Main Risk
At these levels, it is easy to equate the value of a BA with producing documentation, creating and describing Jira tickets, maintaining the backlog, and transferring information between people.
As long as software delivery remains predominantly human-driven, that model can still work.
At the next levels, however, a significant part of this activity begins to be automated.
Level 2 — AI as a Development Partner
The BA still operates within a traditional delivery process alongside the development team. For the first time, however, a systemic constraint begins to emerge: implementation can accelerate faster than the organization can make and validate business decisions.
AI does more than speed up coding. It can also dramatically accelerate the processing of discovery materials, the creation and maintenance of specifications, gap detection, and consistency checks across artifacts.
It does not, however, automatically accelerate access to stakeholders, cross-functional alignment, prioritization, legal or regulatory decisions, conflict resolution, or understanding of complex domain logic.
At this level, the BA therefore needs to move from occasional AI usage to a repeatable operating model:
from one-off prompts to tested prompts, skills, and project instructions;
from isolated AI-assisted tasks to workflows in which the system consistently processes source materials, extracts rules and decisions, updates artifacts, performs checks, and prepares the next set of questions;
from individual experimentation to standardized team practices.
The real shift is that the entire repeatable cycle — from processing source material to updating the specification and checking its consistency — can now be accelerated and partially automated. Drafting requirements is only one part of that change.
This applies especially to:
preparing and processing discovery materials;
structuring notes and transcripts;
creating and maintaining models, requirements, business rules, and acceptance criteria;
identifying gaps and contradictions;
maintaining traceability;
preparing clarification questions;
synchronizing related artifacts.
At the level of a BA Office or broader Business Analysis function, the next step is no longer simply to recommend individual tools. The function should design, test, and distribute validated workflows, skills, templates, and quality checks.
AI usage should become part of the standard BA operating model rather than a collection of personal techniques used by individual analysts.
In agentic-system terminology, this combination of instructions, skills, workflows, context, and validation mechanisms can be viewed as a harness — the control environment that determines how the model receives context, uses tools, and validates its output.
What Changes Structurally
The BA increasingly helps prevent accelerated development from stalling when context is incomplete or business decisions arrive too late.
This creates growing expectations for the BA to:
identify open questions and dependencies earlier;
escalate required business decisions proactively;
maintain enough implementation-ready context;
decompose work into independent units;
operate in shorter feedback cycles;
automate repeatable analytical activities.
The main risk at Level 2 is that the BA’s operating model may still be designed for a slower development environment.
If analysis and specification preparation remain largely manual, the bottleneck gradually shifts from code production to establishing sufficient clarity around business intent.
Level 3 — Agentic Development with Human Oversight
How Development Works
At Level 3, AI takes over a substantial share of the work previously performed by experienced developers.
Engineers increasingly orchestrate coding agents rather than produce most of the code themselves: they launch agents, supervise their work, and review plans, changes, tests, and final results. Multiple agents can work on substantial parts of the solution in parallel.
The BA Role
The BA now works with a system that can rapidly turn context into code, tests, APIs, integrations, and documentation. Ambiguities and unvalidated assumptions can therefore scale rapidly across multiple parts of the solution.
The BA therefore becomes responsible not only for the overall business logic, but also for critical behavioral details that were previously often clarified during implementation, including:
business rules and exceptions;
states and transitions;
access permissions;
errors and failure scenarios;
partial execution, retries, and timeouts;
system behavior in ambiguous situations;
details that shape the expected user experience;
criteria for determining whether the outcome is correct.
The BA need not define every technical detail, but must ensure that critical business behavior is not left to arbitrary interpretation by agents.
What Changes Structurally
Less Implementation Support, More Context Preparation
Coding agents do not need continuous verbal clarification while they work.
As a result, the BA spends less time supporting each individual implementation step and more time preparing the ground before agents are launched: aligning critical decisions, formalizing rules, identifying gaps, and defining the boundaries of acceptable behavior.
Collaboration with engineering becomes more front-loaded: complex questions, constraints, and risks need to be addressed earlier, before large amounts of functionality are generated from inconsistent interpretations of the same requirement.
Ambiguity Becomes More Expensive
A human developer may notice that a requirement looks strange, ask a question, or rely on domain intuition.
An agentic system, by contrast, can consistently implement the wrong assumption across code, tests, documentation, APIs, and multiple components at the same time.
This is also why my earlier skepticism toward multi-agent systems has evolved. As agentic systems distribute work across multiple steps and agents, inaccuracies can compound. Teams therefore face a practical choice: improve the precision and consistency of the input context, or consciously accept the risks created by gaps and ambiguity.
Not every question must be resolved before implementation begins, but unknown facts, assumptions, open decisions, and the associated risks need to be explicit.
Parallel Work Requires Shared Semantics
Multiple agents may each produce locally correct parts of a solution that are globally inconsistent with one another.
The BA or product lead, together with the engineering team, therefore needs to maintain a shared interpretation of domain concepts, entities, statuses, rules, constraints, and agreed assumptions.
Each agent needs enough context for its own task, but that context must also remain consistent across parallel streams of work.
User Experience Becomes Part of the Context
A functionally correct implementation does not automatically produce the right user experience.
Agents need more than a functional scenario. They also need the expected interaction behavior: what the user sees, what feedback they receive, which actions are available, and what happens during errors, waiting states, or partial execution.
If the team still has a dedicated Product or UX Designer, the BA helps maintain a two-way connection between design and agentic implementation.
Decisions about UX, branding, visual language, and interaction patterns need to become part of the agents’ context, while generated alternatives and implemented behavior need to flow back to the designer for validation.
Validation Becomes More Important
As code production accelerates, the central question begins to shift from: “Can we build this?” to: “How do we prove that the system built what we actually agreed on?”
The BA contributes by defining:
business scenarios;
the boundaries of an acceptable outcome;
negative and alternative cases;
expected consequences;
traceability between agreed decisions, requirements, and implemented behavior;
business validation of the solution.
Agent-Ready Context
At Level 3, describing a single backlog item and its requirements is often no longer enough.
Agents need coherent context that includes the business objective, solution scope and boundaries, domain concepts, rules, states, critical scenarios, constraints, confirmed decisions, explicitly identified assumptions, and criteria for correctness.
This context should pass through defined quality gates:
key terms are defined;
critical rules are confirmed;
contradictions are identified;
the outcome is verifiable;
assumptions are not disguised as facts.
Level 3 does not yet require the full specification that becomes the input interface to an autonomous SDLC at Level 4, but it does require the BA to treat context as a system rather than a collection of separate user stories and documents.
The Main Risk
A BA who measures productivity by the number of user stories written will not keep pace with an agentic system. The value of the role shifts from producing more text to reducing the risk of rapidly building the wrong, inconsistent, or unacceptable solution.
Level 4 — From Developer to Orchestrator
How Development Works
Level 4 is the pivotal point in Shapiro’s model.
Shapiro describes an engineer who is no longer a developer in the traditional sense. Instead, the engineer works with the specification, discusses it with AI, creates or reviews the implementation plan, configures reusable skills, launches the agentic system, and later evaluates the result.
Writing code directly is no longer the engineer’s primary activity. A significant part of the lifecycle — planning, decomposition, implementation, and testing — can be handled autonomously by agents.
The human engineer increasingly focuses on defining what the system should build, the boundaries within which it may operate, and how the resulting solution should be validated.
Shapiro jokingly refers to this person as a PM, deliberately leaving open whether that means Product Manager, Project Manager, or Program Manager.
Why Level 4 Is Critical for Business Analysts
Through Level 3, AI primarily changes how code is produced.
At Level 4, the engineer moves beyond the coding layer and starts working directly with specifications, problem framing, plans, success criteria, and the orchestration of autonomous implementation.
This activity now directly overlaps with areas traditionally associated with Business Analysts, product roles, Solution Architects, and Project Managers.
At Level 4, the central question is not whether requirements are still needed when agents write the code, but who has the authority to make business decisions and who ensures the integrity of the specification that drives autonomous implementation.
These responsibilities do not necessarily belong to the same role.
Business Decisions and Specification Integrity
Formal authority over product direction, priorities, value, acceptable trade-offs, and risk acceptance usually belongs to a product role or an accountable business owner.
The BA can investigate the problem, prepare and evaluate solution options, facilitate decision-making, formulate recommendations, and make specific decisions within a delegated mandate.
What matters is that the organization clearly understands:
who prepares a decision;
who has the authority to approve it;
who owns the associated risk.
A distinct BA responsibility may be maintaining the integrity of the business context and specification, including:
completeness and internal consistency;
shared domain semantics;
traceability of agreed decisions;
explicit separation of facts, assumptions, and open questions;
documented constraints and exceptions;
readiness for implementation and validation.
In other words, the BA does not necessarily need authority over every business decision. But they can ensure that those decisions are sufficiently grounded, correctly represented in the specification, and preserved throughout autonomous implementation.
From Requirements to an Agent-Ready Specification
At Level 4, writing user stories and handing them over to the team is no longer enough.
The specification becomes the input interface to an autonomous development lifecycle. It needs to be structured so that an agentic system can move from business intent to planning and implementation without relying on continuous human clarification to fill gaps.
One practical format for this approach is a structured, version-controlled Markdown-based specification maintained alongside the project. For example:
requirements.md — business intent, solution scope and boundaries, rules, scenarios, constraints, and correctness criteria;
plan.md — the technical implementation plan;
tasks.md — work decomposition;
a project-level context file such as AGENTS.md or CLAUDE.md — persistent rules and instructions for agents.
The specific filenames are not important. What matters is that different layers of context have a clear purpose, ownership, and update rules.
BA and product roles primarily work with business and user context. The engineering team defines the technical plan, architectural decisions, codebase conventions, and technical validation mechanisms.
Where appropriate, the specification can also include machine-verifiable artifacts such as:
OpenAPI contracts;
data schemas;
state models;
test data;
automated acceptance tests.
These artifacts make parts of the specification formally verifiable, but they do not replace the description of business intent, rules, and context.
For autonomous development, the specification must explicitly distinguish between:
confirmed decisions;
assumptions;
open questions;
constraints;
situations that require escalation to a human.
It should also define critical primary, alternative, and negative scenarios, along with clear criteria for determining whether the resulting solution is correct.
The specification does not need to be absolutely complete; it needs to be sufficient for a particular autonomous implementation cycle and free of hidden gaps that agents would otherwise fill with their own assumptions.
At this level, context engineering starts evolving into specification engineering: business and technical context must be organized into a coherent input for planning, decomposition, implementation, and validation by an agentic system.
Context Engineering Becomes a Shared Discipline
The boundary between Business Analysis and engineering becomes less distinct at this level because both work on the context consumed by agents.
BA and product roles shape the business and user context:
the problem;
goals;
domain semantics;
business rules;
decisions;
correctness criteria.
The engineering team shapes the technical context:
architecture;
component boundaries;
the codebase;
APIs;
standards;
tools;
technical constraints.
Agents operate at the intersection of these two layers.
The BA’s Role in Agent-Generated Plans
The BA should not replace the engineer or architect in assessing the technical merits of the plan.
The BA’s expertise lies in evaluating business coverage:
Does the plan cover the agreed scope and solution boundaries?
Are any critical scenarios missing?
Have the domain semantics changed?
Are business dependencies accounted for?
Have any unapproved assumptions appeared?
Are the correctness criteria preserved?
Engineering remains responsible for architecture, technical feasibility, performance, security, maintainability, and other technical qualities of the solution.
Three Organizational Scenarios
Scenario 1 — The BA Owns the Business Side of the Specification
In a complex domain, an engineer may be perfectly capable of managing autonomous implementation while lacking either the domain expertise or the mandate required to define business rules and trade-offs.
In this model:
the BA conducts discovery, structures the business context, and ensures specification integrity;
the product role or accountable business representative sets priorities and approves critical business decisions;
the engineering team defines the technical approach and implementation plan;
agents perform a significant share of implementation and technical validation.
Scenario 2 — The BA and Engineering Team Co-Author the Specification
The boundary between the business need and the way it should be implemented is not always clear-cut.
Business decisions may depend on architectural constraints, data availability, APIs, security, performance, or implementation cost.
The BA and engineering team therefore become co-authors of different layers of the same specification:
the BA focuses on the problem, domain, rules, and correctness criteria;
engineering focuses on feasibility, architecture, technical constraints, and the implementation plan.
For the BA, this means work that is less focused on documentation, more focused on the system as a whole, closer to architecture, and more dependent on technical literacy.
Scenario 3 — BA Responsibilities Are Absorbed by Another Role
A dedicated BA role may no longer be necessary if a Product Manager, founder, business owner, or another role can independently:
conduct discovery;
work with the domain and stakeholders;
formalize rules and constraints;
maintain specification integrity;
evaluate the resulting solution.
This is particularly likely in smaller product teams and simpler domains.
In that case, the Business Analysis function remains, but it is performed by another role.
The Main Risk
At Level 4, there is no guarantee that a dedicated BA role will survive.
If the role’s primary value lies in writing user stories, transferring information into Jira, documenting decisions that have already been made, and maintaining the backlog, a significant share of that work can be automated or absorbed by other roles.
At Level 4, the BA’s strongest position is not document ownership but responsibility for the integrity of business context and the readiness of the specification for agentic implementation. As implementation becomes more autonomous, who wrote the requirements matters less than whether the system received the right business intent, sufficient context, and verifiable boundaries.
Level 5 — The Dark Factory
How Development Works
At Level 5, software development becomes a black box that turns a specification into working software without requiring continuous human involvement in the internal production cycle.
The term Dark Factory does not necessarily imply that the system’s reasoning is opaque. It is an analogy to fully automated manufacturing, where lights are no longer needed because no humans are working inside the factory.
Within the factory, the following activities may be automated:
decomposition;
planning;
selection of agents and tools;
implementation;
integration;
testing;
bug fixing;
failure recovery;
retries;
deployment;
monitoring.
Shapiro does not define the internal architecture of Level 5 in detail. He describes it as “a black box that turns specs into software,” so the distinction I draw below between Levels 4 and 5 is partly my interpretation of where human orchestration ends and fully autonomous execution begins.
The Difference Between Level 4 and Level 5
At Level 4, a human still manages each autonomous implementation cycle: they prepare the specification, discuss it with AI, review the plan, launch the agents, and later review the tests and results.
At Level 5, the human no longer manages the execution of each individual cycle. The specification is handed over to the factory, and the system determines for itself how to organize the work and produce the finished solution.
So the difference is not simply how much code AI writes:
at Level 4, a human manages autonomous implementation;
at Level 5, the autonomous system manages implementation itself.
Humans may still be involved:
before the factory — defining the problem, business intent, and specification;
after the factory — evaluating the correctness, value, and consequences of the result;
above the factory — defining governance rules, policies, acceptable risks, and boundaries of autonomy.
What Happens to the BA
At this level, the traditional BA role within software delivery may lose a substantial part of its responsibilities.
There is no conventional development team inside a Dark Factory that needs a backlog and Jira user stories, backlog refinement sessions, requirement explanations, answers to implementation-level questions, or manual synchronization between requirements, code, and tests.
If the traditional delivery process disappears, the part of the BA role built around supporting that process disappears with it.
But Business Analysis does not automatically disappear.
Before the factory can be launched, someone still needs to define the problem, context, desired outcome, acceptable trade-offs, constraints, and success criteria.
After the result is produced, someone still needs to determine whether the real need has been addressed, whether the expected value has been created, and whether the solution has introduced unacceptable consequences.
At Level 5, the distinction between the Business Analyst as a dedicated delivery role and Business Analysis as a discipline becomes especially important. The role may shrink significantly, while the discipline remains necessary before the factory, after it, and at the governance layer above it.
The following two levels, 5A and 5B, are my own extrapolation of Shapiro’s model. They distinguish between different possible boundaries of autonomy across business intent, specification, and implementation.
Level 5A — Specification-to-Software Factory
This version is closest to Shapiro’s original description.
Humans remain responsible for discovery, stakeholder engagement, business decisions, and producing an approved specification.
The specification is then handed over to the Dark Factory, which autonomously performs the technical planning, implementation, integration, testing, and other engineering activities required to produce a working solution.
In this model, the boundary of autonomy sits between specification and implementation:
before that boundary, humans determine what needs to be built, why, within which constraints, and how the result should be evaluated;
after that boundary, the factory determines how to build the solution technically.
For the BA, this is a fundamental shift: Business Analysis is no longer embedded in the factory as part of a traditional delivery process. Most BA work moves to the stages before the factory is launched — through discovery, business-context management, decision preparation, and specification development — and after the result is produced, when it is validated against the original business intent.
However, autonomous software production does not necessarily mean that interaction between the business and the factory becomes seamless.
Operating in these agentic environments may still require considerable technical literacy. A project sponsor, domain expert, or senior manager may struggle to directly manage specifications, agentic workflows, context files, escalations, and the outputs of individual cycles.
This creates room for a separate orchestration function between the business and the Dark Factory.
That function may:
organize interaction between the business and the agentic system;
translate business-level requests into structured input for the factory;
route questions and escalations to people with the appropriate authority;
ensure that decisions are confirmed in time;
present plans, risks, and outcomes in a form non-technical stakeholders can understand;
maintain traceability between the original intent, the specification, and the resulting solution.
This function may be performed by a BA, a product role, another business-facing role, or even a specialized agent operating under human oversight.
For Business Analysts, this represents one possible path of transformation: instead of remaining a permanent intermediary between the business and a development team, the BA may orchestrate the interaction between the business and an autonomous software factory.
Level 5B — Intent-to-Software Factory
A logical extension of Level 5A is to move the boundary of autonomy further upstream — from implementation toward discovery and Business Analysis itself.
At Level 5A, humans create and approve the specification, and the Dark Factory turns it into a working solution.
At Level 5B, the initial input may no longer be a completed specification at all. It may simply be a business problem, need, or desired outcome.
For example, a business might state:
Reduce insurance claim processing time from several days to a few hours without increasing operational risk or violating regulatory requirements.
Turning such an intent into software requires far more than generating an interface or automating the existing workflow.
The agentic system would need to:
investigate the current process;
identify participants and data sources;
discover business rules, regulatory constraints, and exceptions;
identify the causes of delays;
develop alternative future-state process options;
negotiate acceptable trade-offs;
define success criteria;
produce the specification;
implement and validate the solution.
Some of this work, which is currently performed by Business Analysts, could be taken over by Business Analyst agents.
These agents could:
analyze documents and data;
interact with stakeholders;
ask clarifying questions;
build a domain model;
identify contradictions and gaps;
distinguish facts from assumptions;
progressively construct a specification for agentic development.
In practice, this kind of discovery could be organized as a structured agentic process with defined stages, agent roles, expected artifacts, and checkpoints at which the system either proceeds autonomously according to predefined rules or escalates a decision to a human.
The business representative in this model does not have to be a Product Manager or project sponsor.
It could be:
a Business Analyst embedded in the business;
a domain expert;
a process owner;
or another person with sufficient context and authority to involve the necessary stakeholders.
That person may:
define the problem and desired outcome;
provide domain context;
answer agents’ questions;
confirm facts and assumptions;
involve the owners of critical decisions;
approve the specification;
evaluate the resulting solution.
The critical principle is that an agentic system may prepare decisions, but it should not grant itself business authority.
Priority decisions, risk acceptance, approval of critical trade-offs, and formal approval of organizational change remain the responsibility of authorized human decision-makers.
Who Validates the Output of a Dark Factory?
Even at Level 5, where a sponsor may theoretically no longer need a traditional development team, someone still has to validate what the factory has produced.
The irony is that automating software production does not necessarily make business validation easier.
A factory may generate a substantial software system in a very short time, containing multiple processes, roles, rules, integrations, and scenarios.
A single person is unlikely to have all the expertise or capacity required to validate the entire result independently.
The sponsor or accountable business representative may therefore still need:
domain experts;
user representatives;
owners of individual business processes;
legal, compliance, security, and operations specialists;
a Business Analyst coordinating business validation;
specialized validation agents that evaluate the result against different models, rules, and criteria.
Rather than producing software, this group provides independent validation that the autonomous factory has produced an acceptable solution.
Two Independent Quality Checks
Any agentic system that moves from business intent to working software must undergo two fundamentally different forms of validation.
Intent Correctness
Did the system correctly:
understand the problem?
identify the needs and desired outcome?
capture the relevant business rules and constraints?
involve the right stakeholders?
reflect the decisions that were actually agreed?
avoid turning assumptions into facts?
Implementation Correctness
Did the system correctly:
implement the approved specification?
cover the required scenarios?
respect the relevant constraints and invariants?
achieve the required technical characteristics?
pass the defined validations and tests?
An agentic system can implement the wrong idea perfectly, just as it can understand the need correctly and still implement the solution poorly. Automating engineering therefore makes three capabilities more important: forming the right business intent, obtaining human confirmation for critical decisions, and independently validating that the resulting solution addresses the business need.
BA Capabilities at Each Level
The competencies required at later levels do not replace those needed at earlier ones. A BA operating at Level 4 or 5 still needs to conduct research, work with stakeholders, understand the domain, formalize business rules, and validate outcomes.
What changes as engineering becomes more autonomous is how these competencies are applied:
first, the BA needs to accelerate their own work with AI;
then, turn individual techniques into repeatable workflows;
learn to manage context for agents;
build specifications that can serve as input to an autonomous SDLC;
and eventually orchestrate Business Analysis activities and validate the output of autonomous systems.
Levels 0–1 — Traditional BA with AI Literacy
At these levels, a BA should learn to:
formulate tasks for AI clearly and provide sufficient context;
use AI to structure materials, prepare summaries and drafts, identify gaps, and transform information;
critically evaluate AI-generated output;
distinguish confirmed facts from generated assumptions;
understand which tasks can be delegated to AI and where professional judgment is still required.
Practical goal: choose three recurring BA tasks, establish reliable AI-assisted approaches for each of them, and compare the time and quality of the results against a fully manual approach across several real cases.
Level 2 — AI-Augmented Business Analysis
At this level, the BA should develop the ability to:
create reusable prompts, skills, and project instructions;
design repeatable AI-powered workflows;
automate the processing of discovery materials and artifact updates;
establish checks for completeness, consistency, and contradictions;
standardize AI practices across a BA team or Business Analysis function.
Practical goal: automate one recurring BA process end to end — from receiving source materials to updating artifacts and preparing the next set of questions.
Level 3 — Context Engineering
The next step is learning to manage context as a system.
A BA should be able to:
maintain a shared glossary, domain model, and state models;
distinguish facts, decisions, assumptions, and open questions;
determine what context a specific agent needs for a specific task;
maintain a decision log and preserve the sources of critical business rules;
identify inconsistencies between the outputs of parallel agents;
design mechanisms for validating context consistency.
Practical goal: prepare an agent-ready context pack for a single feature and test whether two independent agents interpret its rules, states, and constraints consistently.
Level 4 — Specification Engineering
At this level, the BA needs to learn how to turn business intent into a specification that can be handed over to a multi-agent development system.
The required skills include:
working with specification-driven development approaches and adapting the level of rigor to the problem;
creating structured, version-controlled specifications, including Markdown-based formats;
formalizing invariants, failure scenarios, edge cases, and conditions for human escalation;
complementing requirements with machine-verifiable contracts, schemas, and acceptance tests;
reviewing agent-generated plans from the perspective of business coverage;
orchestrating the generation, validation, and synchronization of different parts of the specification;
developing sufficient understanding of agentic SDLCs, APIs, data, and integrations to recognize when business intent is lost in the technical plan.
In practice, this also means moving beyond conventional AI assistants toward AI-native environments where the BA can configure skills, project instructions, and their own specification workflow.
Practical goal: prepare a complete specification for one feature, hand it to an agentic system without additional verbal clarification, and verify whether the resulting implementation plan covers all agreed scenarios, business rules, constraints, and correctness criteria without introducing unapproved assumptions.
Level 5 — Beyond Traditional Software Delivery
At Level 5, the BA’s development focus moves beyond requirements writing toward designing and governing systems that perform Business Analysis and produce solutions.
New competencies include:
designing agentic discovery and BA workflows;
defining agent roles, stages, handoffs, and checkpoints;
distinguishing between decisions the system can prepare and decisions that require human authority;
organizing communication between non-technical business stakeholders and the Dark Factory;
defining governance rules, autonomy boundaries, and acceptable levels of risk;
coordinating independent business validation;
involving domain experts, legal, compliance, security, and user representatives in validation;
evaluating not only whether the solution matches the specification, but whether it actually solves the original problem.
The BA may also design skills and methodologies for Business Analyst agents, adapt agentic workflows to the organization’s processes, and govern how the system moves from a business problem to a specification and ultimately to a working solution.
Practical goal: design a small intent-to-specification workflow with defined agent roles, at least one decision point that explicitly requires human authority, and an independent validation step for the final specification.
Conclusion
As the engineering function becomes more autonomous, humans gradually move away from direct software production. For Business Analysts, this means more than simply using AI more extensively or reducing manual work. It changes the point in the delivery process where Business Analysis creates value.
As this happens, BA value shifts away from manually producing requirements artifacts, transferring information between tools, and supporting each implementation step, and toward the ability to:
understand complex business realities;
maintain the integrity of context and specifications;
define the boundaries of system autonomy;
organize decisions and escalations that require human involvement;
verify that the system has produced the right solution to the right problem.
AI may reduce the need for a dedicated Business Analyst role within implementation, especially where the role is limited to preparing and handing over requirements. This does not remove the need for Business Analysis itself; it changes where that capability creates value.
The future of Business Analysis lies less in documenting what people need to build and more in creating the clarity, context, and validation needed for humans or machines to build the right solution.
So where does your IT organization stand today across these levels — and is your Business Analysis function ready for the next one?
About the author
Yevhen Kliukin
Agentic AI Transformation & BA Lead, Geniusee
From the editors:
If you want to deepen your BA skills in using AI, pay attention to
Art of Business Analysis training schedule
News and articles on business analysis:
