Chapter 16: AI Across the SDLC - Requirements, Architecture & Design

Shift AI Left

Most teams bolt AI onto the coding phase and stop there. As Chapter 26 shows, that just moves the bottleneck upstream and downstream. The fix is to apply AI across the entire value stream - and the most neglected, highest-leverage part is everything that happens before a line of code is written. AI is as useful for turning a fuzzy idea into a buildable specification as it is for writing the implementation.

Start With the Problem, Not the Ticket

The most valuable question on a team is also the simplest: what problem are we actually trying to solve? When you stop tossing tasks over the wall and reframe the work as a problem, engineers go from order-takers to problem-solvers - they poke holes in weak ideas, find paths with fewer dependencies, and take real ownership because they are solving, not just shipping. The same reframe is what makes AI useful upstream. Hand an agent a solution wrapped in a vague ticket and it will build the wrong thing quickly; hand it the problem, the constraints, and the context, and it helps you find the right one. So the next time a solution arrives wrapped in a ticket, pause and ask: wait - what problem are we trying to solve?

Requirements as Versioned Context

The single biggest cause of agent rework is a vague requirement. A story that a senior developer could once "figure out" through tribal knowledge will send an agent down the wrong path. The answer is to write requirements as context-first artifacts: versioned markdown with the objective, acceptance criteria, edge cases, and constraints spelled out - the same documents the coding agent consumes downstream. Use AI to draft them at the speed your developers now build: feed it the ticket, the related code, and the product constraints, and have it generate acceptance criteria and enumerate edge cases for a human to refine. Requirements become code, written in a language both humans and agents understand, evolving in source control rather than rotting in a wiki.

AI for Architecture Exploration

Architecture stays human-owned - but AI widens the option set and pressure-tests your thinking. Use a frontier or reasoning model to generate competing approaches, lay out the tradeoffs, and draft an Architecture Decision Record. Then turn it adversarial:

"Here is the design. What are we optimizing for, and what are we
risking? What breaks first under 10x load? Where am I wrong?
Propose two alternatives and the conditions under which each wins."

This is the senior-engineer pattern from Chapter 10 applied at design time. The agent does not make the call; it makes sure you made the call with the failure modes in front of you.

Design-to-Code and Rapid Prototyping

Structured requirements turn into working prototypes fast. Tools like Bolt and Lovable scaffold a deployable app from a spec, which lets product managers and engineers co-prototype to validate an idea before committing real engineering time - then engineering hardens the output for production. The handoff is clean precisely because the spec, not a verbal description, is the source of truth.

Bake In Quality and Security at Design Time

Have AI draft the things teams usually skip until it is too late: a threat model for the new surface area (Chapter 20), non-functional requirements and performance budgets, and a test plan derived from the acceptance criteria. Catching a missing escalation path or an unbounded query at design time costs minutes; catching it in production costs an incident.

Keep the Spec the Source of Truth

This is spec-driven development: the specification generates the task list, the agent implements against it, and review and evals check the result against the same spec. It is the upstream sibling of the intent specification from Chapter 4 - one names what the feature must do; the other names what the agent must achieve and where it must stop. Together they keep intent intact from idea to production.