Here’s a claim that sounds obvious but has deeper implications than you might think: in AI-assisted development, requirements are code.
Not metaphorically. Functionally. The requirements you write are the primary input that determines what gets built. Their quality directly controls output quality, at a leverage ratio that’s dramatically higher than when working with human developers.
Understanding this changes how you think about what skills matter—and why PM skills become more valuable, not less, as AI gets better at writing code.
The Old World: Requirements as Suggestions
In traditional software development, requirements were starting points. Important, sure, but somewhat malleable.
You’d write a PRD. An engineer would read it, have questions, make assumptions, fill in gaps. During implementation, they’d discover edge cases the requirements didn’t address and make judgment calls. In code review, another engineer would catch issues and suggest improvements.
The final code was a collaborative output—requirements plus engineering judgment plus review feedback plus whatever the developer discovered along the way.
Mediocre requirements could still produce decent software because humans compensated. A good engineer reading a vague PRD would ask clarifying questions, identify missing pieces, push back on things that didn’t make sense.
The requirements were input to a process that added substantial value.
The New World: Requirements as Specification
With AI-assisted development, the dynamic shifts.
Tell an AI agent: “Build a user authentication system.”
It will build something. Routes, database schema, login forms, password hashing. A complete authentication system.
But is it the right authentication system?
- Email/password or OAuth? Both?
- What password requirements? Minimum length? Complexity rules?
- How do password resets work? Email link? Temporary code?
- Session management—tokens or cookies? Expiry time?
- What happens on failed login? Lockout after N attempts?
- Does it need 2FA? Optional or required?
The AI won’t ask. It will make decisions—often reasonable ones—and produce code. If you didn’t specify, you get whatever the AI assumed.
This is fundamentally different from working with a human engineer who would say: “Wait, you didn’t mention password reset. How should that work?”
AI agents are incredibly literal. They execute what you tell them, including the gaps you leave.
The Leverage Shift
In traditional development:
- Requirements quality: 20% of output quality
- Engineering skill: 50% of output quality
- Process (review, testing): 30% of output quality
(Numbers are illustrative, not scientific.)
In AI-assisted development:
- Requirements quality: 60-70% of output quality
- AI capability: 20-25% of output quality
- Review and iteration: 10-15% of output quality
The leverage has shifted massively toward requirements. The AI is already quite capable at the mechanical work of writing code. What it can’t do is know what you actually want.
Good requirements → good output. Vague requirements → output that technically works but doesn’t match your intent.
What Good Requirements Look Like
This isn’t about longer documents. It’s about the right information, structured correctly.
Specific over general:
Bad: “Users should be able to log in.” Good: “Users can log in with email/password. Passwords require minimum 8 characters with at least one number. Failed logins show ‘Invalid credentials’ (never reveal which field was wrong). After 5 failed attempts in 10 minutes, lock the account for 30 minutes.”
Explicit non-goals:
Bad: [no mention] Good: “Non-goals: We are not building OAuth/social login in this phase. We are not building 2FA (future enhancement). We are not supporting username-based login.”
Non-goals are as important as goals. They prevent the AI from over-building.
Acceptance criteria:
Bad: “Password reset should work.” Good: “Password reset: User clicks ‘Forgot password’ → enters email → receives email with time-limited link (24 hours) → clicks link → enters new password → old password invalidated immediately → user can log in with new password. Edge cases: If user requests multiple resets, only the latest link works. If email doesn’t exist in system, still show ‘Check your email’ (don’t reveal whether account exists).”
Edge case enumeration:
Bad: [handled implicitly] Good: “What if user tries to log in while account is locked? Show: ‘Account locked. Try again in X minutes.’ What if user’s session expires mid-action? Redirect to login, preserve intended destination. What if user navigates directly to /dashboard without logging in? Redirect to login.”
The pattern: be explicit about decisions you’ve made. The AI is excellent at implementation once it knows what to implement. It’s not excellent at mind-reading.
The Requirements-as-Code Mental Model
Start thinking of requirements like you think of code:
Requirements should be testable. “Users should have a good experience” is not testable. “Page load time under 2 seconds” is testable. “Password meets complexity requirements before form can submit” is testable.
Requirements should be unambiguous. In code, if (x > 5) has one meaning. In requirements, “handle errors appropriately” has many interpretations. Specificity in requirements = specificity in output.
Requirements should be complete. If your code is missing a function it calls, you get an error. If your requirements are missing a scenario, you get… AI assumptions. The AI will fill gaps with something. It might not be what you want.
Requirements can be refactored. When you discover something was poorly specified, improve the requirements and re-run. Just like improving code.
A Practical Example
Let me show the difference in practice.
Vague requirement: “Add a feature that lets users export their data.”
What the AI might build:
- CSV export of user profile data
- Triggered by button in settings
- Synchronous download
- No progress indication
What you might have wanted:
- JSON export of all user data including activity history
- Accessible from account page, not just settings
- Async generation with email notification when ready
- Include data deletion option (GDPR compliance)
The AI built an export feature. It just wasn’t your export feature.
Specific requirement: “Add data export feature:
- Export format: JSON, containing user profile, preferences, and activity history
- Location: Account page, prominent button labeled ‘Export My Data’
- Flow: User clicks → confirmation modal explaining what’s included → async job starts → user sees ‘Processing…’ status → email sent when ready with time-limited download link (7 days)
- Include option to export and delete (GDPR ‘right to erasure’)
- File should be named {username}export{timestamp}.json
- Non-goals: CSV format (future), selective export (future)”
The AI builds exactly this. Because you told it exactly what to build.
Why PM Skills Become Essential
This is where the AI-PM thesis clicks into place.
Product managers have been writing requirements for years. It’s a core skill—translating business needs and user needs into specifications that engineering teams can execute.
Most PMs are… okay at it. They can write something that a human engineer will understand, ask questions about, and ultimately build correctly.
But “good enough for a human who will ask clarifying questions” is not the same as “good enough for an AI that will execute literally.”
The PMs who are excellent at requirements—specific, complete, unambiguous, with clear acceptance criteria and enumerated edge cases—those PMs are suddenly in possession of a superpower.
Their requirements can be executed by AI with minimal iteration. They can direct AI agents to build exactly what they have in mind. The gap between “I want this” and “this exists” shrinks to nearly nothing.
The PM skill that was “helpful” in the old world becomes “essential” in the new world.
Leveling Up Your Requirements
If you want to get better at requirements (and you should), here’s what I’ve learned:
1. Enumerate decisions explicitly.
Every requirement implies decisions. “User can log in” implies: with what credentials? what happens on failure? how long does the session last? Be explicit about each decision.
2. State non-goals.
What are you intentionally not building? What scope are you excluding? This prevents AI from over-building and keeps focus tight.
3. Write acceptance criteria.
For each feature, what’s the specific test that proves it works? “User clicks X, sees Y, can do Z” level of detail.
4. Consider edge cases.
What happens when things go wrong? Invalid input, network failures, race conditions, malformed data. List them. Decide how to handle them.
5. Review by execution.
Give your requirements to an AI and see what it builds. The gaps become obvious fast. Iterate.
The Feedback Loop
Here’s a pattern that accelerates learning:
- Write requirements
- Give them to AI
- Review what gets built
- Note where output diverged from intent
- Identify which requirement gaps caused the divergence
- Improve requirements
- Repeat
Each iteration teaches you something about what you failed to specify. Your requirements get sharper. Your ability to direct AI gets stronger.
This is a learnable skill. You get better with practice.
Closing Thought
In a world where AI can write decent code for most common patterns, the bottleneck isn’t coding ability. It’s knowing what to code.
Requirements are the new code. They’re the primary artifact that determines what gets built. Their quality directly controls output quality.
If you’re a PM, this is your moment. The skill you’ve been building—translating intent into specification—is now the highest-leverage skill in software development.
If you’re an engineer, learning to write better requirements isn’t “product work” you should avoid. It’s the skill that will determine how much leverage you get from AI tools.
The people who thrive in AI-assisted development will be the people who can specify clearly what they want. That’s always been a valuable skill. It’s about to become the essential one.
This is Part 7 of a series on AI-assisted software development. Previously: Why Every AI System Needs a Consigliere. Next: The Lean AI Stack.