Here is a question I have been sitting with lately, and the more I think about it, the more I think it is one of the most important questions in the BA profession right now.
When you write a requirements document or a feature spec, who is your audience?
For most of BA history, requirements existed to communicate what needed to be built to the people who would build it. Business stakeholders validated requirements, but the primary reader the BA was writing for was a human developer.
That answer is no longer complete. And the new answer is not as simple as “write for AI development agents instead.” It is messier than that, and more interesting, and it raises questions that I am not sure anyone in the profession has fully resolved yet.
So let us think through it together.
The Old Answer Is Broken
The idea that requirements are written “for developers” was always a simplification. Testers need to understand them. Business stakeholders need to validate them. Product managers need to prioritize based on them. Operations teams need to prepare for what gets built. Compliance teams need to review them.
But the developer was the primary executor, the person whose work would most directly depend on understanding the requirements correctly. Writing for developers meant writing with enough technical specificity to support implementation decisions, while also being accessible enough for business stakeholders to review and confirm intent.
BAs developed a lot of craft around threading that needle. Use cases, user stories, acceptance criteria in Given/When/Then format, process models, wireframes, all of these are tools that emerged in part because different audiences needed different representations of the same underlying requirements.
Now there is a new kind of executor in the picture, and it changes everything about how that needle needs to be threaded.
AI development agents are not reading requirements the way a human developer does. They are not bringing years of industry experience, organizational context, or the ability to pick up the phone and ask a clarifying question. They are parsing what is written, making inferences based on patterns in their training, and generating code from that interpretation. When the requirements are ambiguous, the AI does not get confused the way a human would. It gets confident in the wrong direction, and keeps going.
So do we now write requirements for AI agents? And if we do, what happens to all the other audiences who have always needed to understand them?
The Tension Is Real
Here is where it gets genuinely complicated. If we are building deterministic code (like we have for years), it’s different than writing requirements for AI Agents building AI Agents and AI solutions, where probabilistic functions come into play. Let’s stick with requirements for AI Coding Agents who build deterministic code.
Requirements that are optimized for AI development agents tend to be structured, precise, explicit, and detailed in ways that can feel clinical and hard to read for business stakeholders. Machine-readable specs want consistent formats, quantified thresholds, enumerated conditions, and no room for interpretive latitude. That is not how most business stakeholders think or communicate.
Requirements that are written to make business stakeholders feel comfortable and confident often include narrative context, explanatory prose, real-world examples, and the kind of language that helps non-technical readers understand and validate what is being built. That is enormously valuable. It is also not what an AI development agent needs to execute accurately.
So you have a real tension. Write for machine readability and you risk losing the business. Write for business accessibility and you risk feeding incomplete or ambiguous specifications to AI agents that will execute on them literally, gaps and all.
Some teams are trying to solve this by producing two separate artifacts: a business-facing requirements document and a technical spec that is formatted for AI consumption. I understand the logic, but I am not convinced this is the right answer, at least not as a general solution. Maintaining two parallel artifacts doubles the documentation burden and introduces a new risk: the two documents drift out of alignment, and nobody catches it until something has been built wrong.
There is a better way to think about this, and it starts with asking a different question.
What If the Tension Is Pointing to Something We Should Have Fixed a Long Time Ago?
The requirement that business stakeholders could not understand was always a problem. We just had workarounds. Human developers could ask for clarification. Review sessions could surface misalignment. Iteration cycles could correct course after the fact.
The discipline of writing for AI readers is, in many ways, the discipline of finally writing good requirements. Clear. Explicit. Structured. Unambiguous. Complete enough that the executor, whether human or AI, can work from them without needing to fill gaps with assumptions.
That does not resolve the tension with business accessibility entirely. But it reframes it. The goal is not to choose between machine-readable and human-readable. The goal is to build requirements that are precise enough for AI execution and clear enough for human understanding. That is a higher bar than either alone. It is also achievable, and it is what the best BAs have been doing and are going to be doing.
Tip 1: Stop Thinking About One Audience and Start Thinking in Layers
The most useful reframe I have found is to stop treating a requirements document as a single artifact with a single audience, and start thinking about it as a layered structure that serves multiple readers at different levels.
The first layer is business context: the problem being solved, the user need being addressed, the strategic objective being served, the constraints that shape the solution. This layer is written for business stakeholders, in accessible language, with real-world framing. Its job is to ensure that everyone involved in the project, including the BA, the business sponsor, and the development team, has a shared understanding of why this work is being done.
The second layer is behavioral specification: the specific conditions, actions, and outcomes that define the system’s required behavior. This layer is written with the structure and precision that AI development agents need. User Stories and Given/When/Then for behavioral requirements. Enumerated conditions for business rules. Quantified thresholds for performance and quality requirements. This layer should be clear enough for a human developer to implement and structured enough for an AI agent to parse and execute.
One document, two layers, multiple audiences getting what they actually need. The discipline is in making each layer do its job without sacrificing the others.
Tip 2: Write Business Context for Humans, Behavioral Specs for Machines
Within that layered structure, it helps to be very intentional about which writing mode you are in at any given moment.
When you are writing the business context layer, write for a smart, non-technical business stakeholder who is seeing this document for the first time. Use plain language. Use examples. Explain the “why” before the “what.” Help the reader understand what problem this solves and for whom. This is relationship-building through documentation. It builds trust with business stakeholders and gives everyone, including AI agents, the context they need to interpret the rest of the document correctly.
When you shift to the behavioral specification layer, shift your writing mode completely. You are now writing for an executor, one that will interpret what you write literally and act on it. Be consistent in your format. Eliminate adjectives that require judgment to evaluate. Make every condition explicit. Do not assume shared context that is not written in the document. If a business rule has exceptions, list the exceptions. If a behavior depends on a specific state or condition, specify that condition precisely.
The mental shift between these two modes is something BAs need to practice deliberately. Most of us default to one or the other. Either we write in comfortable, accessible prose throughout, which serves human readers and leaves AI agents guessing, or we produce tightly structured specification formats that are accurate but alienating for the business stakeholders who need to validate them.
Building the ability to move fluently between modes, knowing when you are writing to build shared understanding and when you are writing to specify executable behavior, is one of the core skills of the next generation of BA practice.
Tip 3: Let Business Stakeholders Validate the “Why,” Let AI Execute the “What”
The third shift is about roles, not just writing style.
Some business stakeholders have always struggled to validate detailed behavioral requirements, and some love it. Having both layers helps both groups navigate appropriately.
The business context layer of your requirements document is what business stakeholders should be validating. Does this accurately describe the problem? Does the solution approach make sense given our strategic goals? Are the expected outcomes aligned with what we actually need?
The behavioral specification layer, the part that AI development agents will execute on, and business SMEs likely need to validate by tying to user scenarios that are relevant to their operations. These should be validated by people who understand the domain deeply and can evaluate whether the specified behavior will actually produce the desired outcomes. That might still include some business stakeholders with deep domain expertise. But it also includes the BA, technical leads, and increasingly, AI agents themselves that can review specs for completeness and flag gaps.
This is not just an accommodation of new technology. It is a more honest and effective approach to requirements validation than the traditional “all-hands requirements review” that many teams still use, where business stakeholders nod along to acceptance criteria they do not fully understand and technical reviewers tune out during the narrative context sections that feel obvious to them.
The Question Is Not Settled, and That Is Okay
I want to be honest about something. The question of who requirements are written for in an AI-assisted development world does not have a fully settled answer yet. The tools are evolving. The practices are evolving. The norms around how AI development agents are used in software delivery are still being established.
The emergence of AI development agents as a real and significant reader of requirements documentation is forcing that clarity. And the discipline that emerges from it will make BA practice better, not just for AI-assisted development, but for all of it.
The BAs who engage with these questions now, who think seriously about layered requirements structures, who practice writing in both accessible and machine-readable modes, who redesign their review processes to match different audiences to different layers, those are the BAs who will be ready when AI-assisted development is simply how software gets built.
That moment is closer than most people think.