Last month we kicked off a blog series designed to document SafeBreach’s journey to become an AI-First development team. In my first post, I explained how we came to define what AI-First actually means at SafeBreach and what best practices we used to navigate this “do-or-die” shift. In my second post, I outlined the operational workflow we implemented to evolve our AI usage from ad-hoc prompting into a rigorous engineering methodology.

In this installment, I’ll focus on one core element of this methodology: the product requirements document (PRD). Below, I’ll discuss how it became the primary leverage point in our AI-First development process and how we structure it to maximize agent performance.

The Unexpected Comeback of the PRD

When I joined Microsoft in 2000, every engineering effort began with a document. Before writing a single line of code, engineers would spend weeks producing detailed design specifications in Word. These documents described the proposed architecture, implementation phases, testing strategies, risks, and integration considerations. Once written, they would circulate for review—often for several more weeks—before the first commit was made.

The process was slow. It was expensive. And, to be honest, it wasn’t much fun. Writing the document was painful. Reviewing someone else’s 25-page document was even worse.

Over time, the software industry moved away from this model. Agile practices, rapid iteration philosophies, and “code as documentation” approaches emerged partly as a reaction to the perceived overhead of heavy upfront planning.

Architecture documents shrank. Design documents disappeared. In many teams, they became short Confluence pages and, in some cases, just comments inside the code. And for a while, that seemed like progress.

But AI-First development is quietly bringing these practices back. The difference today is that we are no longer writing these documents alone. Modern AI agents can research alternatives, surface design considerations, guide engineers through the specification process, and eventually capture it all in a lightweight markdown file. 

What once required hours of writing can now emerge from a brief interactive exchange—often a structured conversation where the agent asks 10–20 targeted, pre-defined questions and the engineer simply provides answers like “Yes,” “No,” “Tell me more about option C,” or “I prefer option A…”. 

Suddenly the return on investment looks very different. Walking the walk is not so hard anymore.

Spoiler alert: another old-school practice is quietly making a comeback for similar reasons: test-driven development. We’ll talk about that in a future post.

The Real Purpose of the PRD

If AI-assisted development is bringing back detailed specifications, the obvious question becomes: What problem is the PRD actually solving? From our experience at SafeBreach, the PRD serves three critical purposes in an AI-First workflow.

Eliminates Ambiguity

Large language models are probabilistic systems. When requirements are vague, the model has to infer intent.

Humans are fairly good at resolving ambiguity through experience and context. AI systems are not. When instructions leave room for interpretation, the agent may produce implementations that are technically valid but not what the engineer had in mind.

A good PRD removes that ambiguity.

Prevents Random Implementation Decisions

Without architectural guidance, a coding agent will often choose patterns based on what it has most frequently seen during training. That may introduce libraries you don’t use, abstractions that don’t fit your architecture, or design patterns that conflict with existing system conventions.

A structured PRD constrains those choices by explicitly defining architecture, interfaces, and expected behaviors.

Reduces “Hallucinations”

In many cases, what developers call hallucinations are simply the model filling gaps in underspecified instructions. When the specification is vague, the model does what any engineer would do—it guesses. The difference is that it guesses with great confidence.

The PRD closes those gaps. It becomes the control surface for the coding agent.

As these agents continue to improve, the mean time between code refactoring decreases and source code becomes increasingly fluid. The PRD enables that as it captures the intent of the system: the requirements, constraints, interfaces and architectural decisions that define what the system should do.

In traditional software development, code was the primary artifact. In AI-First development, the specification that generates the code becomes the primary artifact.

It is becoming common to hear engineers say: “The PRD is the new code.”

How Coding Agents Use the PRD

Coding agents operate within a finite context window—the amount of information the model can actively reason about at any moment.

As development progresses through the implementation phases, conversations grow, code evolves, and the agent runs tests, inspects debug logs, and iterates on the implementation. Very quickly the full history of the task exceeds what the model can keep in active context.

To cope with this, coding agents continuously perform context compaction, summarizing earlier reasoning so the work can continue within the available context. This works surprisingly well — but it introduces a risk: context drift.

Architectural constraints may fade, earlier design decisions may lose detail, and edge cases discussed earlier may disappear from the active reasoning space. In other words, the agent starts to forget things, which is not entirely different from what happens to humans after a long debugging session.

This is where the PRD becomes essential. Instead of relying on the full conversation history, the agent can return to the PRD as the canonical description of the mission. The PRD contains the information needed to reconstruct context and importantly, it records the current state of the implementation—what has already been completed and what still needs to happen.

The Structure of an Effective PRD

At SafeBreach, we don’t leave PRD structure to individual preference. We use an internally developed Claude skill that generates PRDs in a consistent and AI-friendly format. If the PRD is the control surface for the coding agent, then consistency in structure becomes important.

Our current skill defines 14 sections, expanding on earlier templates to support AI-driven workflows like lifecycle tracking and resumability. The PRD therefore becomes more than a planning document—it also acts as a resumable execution artifact.

The structure includes the following sections:

• Overview: The mission and business context. If the work item type is bug, then this will include repro steps, expected behavior vs actual, and customer impact.
• Document Status: Lifecycle state and current implementation phase.
• Solution Description: Chosen approach, alternatives considered, and justification.
• Core Feature Components: Decomposition of the feature. If it is a bug, this has to also address patching the gaps in existing coverage.
• API Endpoints and Integration: Information on consumed APIs in the form of cURL or postman captures.
• Example Customer Flow: User journey and edge cases. Ensures we understand the user impact and repro steps.
• Non-Functional Requirements: Details regarding performance, security, and scalability.
• Definition of Done: Measurable completion criteria.
• Testing Strategy & Results: Explicit matching of expectations with regards to what will be covered by automation and what’s expected from the developer to manually sign-off on and how. This forces the agent to document the actual test automation results for the record.
• Implementation Phases: The actual deliverables and their order, whether to apply test-driven development (TDD), and how each phase will be signed off.
• Risks & Assumptions: Keeps a record of identified risks and the assumed mitigations. For example: The API endpoint for component ABC is not in our control and can return error 429 upon repeating retries. We’re assuming this will not be a real world issue, as our scheduler works in 10-minute intervals with a maximum of three iterations per minute and three retries per iteration.
• Future Enhancements: Ideas intentionally left out of scope.
• Executive Summary: This section is to be populated right before submitting the pull request. Often a reviewer of the pull request would start here.
• Implementation State and Change Log: Progress tracking and audit trail.

Naturally, different sections carry different weight when it comes to different types of work items (e.g., user story, dev task, bug, test automation). Other sections exist specifically because of AI-assisted development—particularly lifecycle tracking and execution phases.

The PRD is no longer just documentation. It becomes a living, structured artifact that guides the implementation process.

Developer Responsibility

Because the PRD is a living document, maintaining its accuracy remains the developer’s responsibility through the entire lifecycle of the work.

Initial Planning

During planning, the developer ensures the PRD captures the intended design, including user flows, architecture, integrations, scalability considerations, and testing expectations.

When working with AI agents, this often becomes an interview-style interaction where the agent asks clarifying questions. Before implementation begins, we’ve found it useful to explicitly confirm readiness with a prompt such as:

“Do you have any more questions or clarifications required?”

Once the agent confirms it has sufficient information, the PRD should be committed to the repository. Some teams even advocate sending the PRD as its own pull request before any code is written.

Phase-by-Phase Implementation

Implementation should proceed phase by phase, not as a single multi-phase execution. Attempting to implement a multi-phase PRD in one shot is a great way to create new bugs.

Since insights picked during the work on one phase often affect the next, the developer should ask the agent to update the PRD after each phase with the decisions made and the current implementation status.

We also advise checking readiness before moving forward with a prompt like:

“Are there any questions or clarifications required before we proceed to the next phase?”

The developer should ensure the updated PRD is committed alongside the code before continuing to the next phase.

Final PRD Reconciliation

Once implementation is complete, the PRD should be updated one final time to reflect what was actually delivered. This typically becomes the final commit before opening the pull request.

At this point, we typically ask the agent again:

“Did we complete all the implementation phases and meet their exit criteria?

Did we leave anything open?”

If the PRD is the control surface for the coding agent, keeping it accurate is part of the developer’s job.

How Long Should a PRD Really Be?

The length of a PRD is closely related to how an AI-First task should be scoped. At SafeBreach, we’ve found that the most effective unit of work is something a human-agent pair can complete in roughly six hours of focused effort. In practice, that usually corresponds to about one working day.

This boundary exists because of both context and cognitive limits. As tasks grow larger, it becomes harder for both the agent and the engineer to maintain alignment between the plan and the implementation. Keeping missions small keeps the work manageable.

Typical ranges we see:

• Bug fix PRDs: 150–600 lines
• Medium-to-large feature PRDs: 250–1100 lines

These are not strict limits, but they are useful signals. If a PRD grows significantly beyond 1000 lines, it is often worth reconsidering whether the task should be split into multiple missions.

The right length is not determined by documentation standards. It’s determined by the largest scope that allows a human and an AI agent to stay aligned from planning through implementation.

Who Approves the PRD?

Traditionally, the artifact that receives formal review is the code. AI-First development challenges that assumption.

If the PRD defines the system and the code increasingly becomes generated implementation, the most impactful review logically happens before implementation begins. Some within our team advocate for submitting the PRD as a Pull Request before the first line of code is written, while the final code changes may require little human intervention.

This model is still somewhat avant-garde, even at SafeBreach. In practice today, the developer owning the mission still approves the PRD, and peer review usually happens only when the final Pull Request is opened.

However, the direction of change is becoming clear. The earlier design decisions are reviewed, the greater the influence reviewers can have. Once the implementation is generated, many architectural choices are already baked into the system.

AI-First development does not remove engineering judgment. If anything, it increases its importance. The coding agent may implement the system, but the engineer remains responsible for the design and the decisions that shape it.

Closing

AI-First development does not eliminate engineering discipline. If anything, it raises the bar. When code can be generated quickly, the quality of the system increasingly depends on the clarity of the specification that guides the agent. The PRD becomes the place where architectural thinking, implementation planning, and engineering judgment converge.

Or, put more simply: The better the PRD, the better the system the agent can build.

In the next post, we’ll explore another practice that is quietly making a comeback for the exact same reasons: Test-Driven Development.