The PM's Guide to Working with AI Engineering Teams
For product managers whose dev teams use AI coding tools — how to write specs that translate well and stay in the loop.
If your engineering team has started using AI coding tools like Cursor, Copilot, or Claude Code, your role as a product manager has not become less important. It has become more important. The reason is counterintuitive: AI makes it faster to build the wrong thing.
When a developer can scaffold an entire feature in an afternoon instead of a week, the cost of building the wrong feature drops. But the cost of misalignment stays the same. You still lose the sprint. You still have to rework it. You still burn trust with stakeholders. The difference now is that misalignment happens faster and more frequently because the feedback loop between "PM describes feature" and "developer ships code" has compressed from days to hours.
This means the quality of your specs matters more than ever. Not because developers cannot figure things out, but because the AI tools they use are literal-minded translators that build exactly what they are told. If the spec is vague, the output is vague. If the spec is wrong, the output is wrong. And it arrives much faster than anyone can catch it.
How AI Changes the PM-Dev Dynamic
In a traditional workflow, the PM writes a ticket, the developer reads it, asks clarifying questions over a day or two, then starts building. The clarification phase is informal but important: it catches ambiguity, fills gaps, and aligns understanding.
With AI tools, that phase often gets compressed or skipped entirely. A developer reads the ticket, feeds it (or something close to it) into an AI tool, and gets working code back in minutes. If the ticket was clear, the code is good. If the ticket was ambiguous, the developer might not even realize the AI interpreted it differently than what the PM intended. The code works. It just does the wrong thing.
This is not the developer's fault. It is a workflow gap. The solution is not to slow down. It is to make the input, your specs, precise enough that the fast path produces the right output.
What PMs Need to Know About AI Coding Tools
You do not need to understand how large language models work. But you do need to understand a few practical things about how your developers use them.
AI tools work from context. The developer provides a prompt plus context (code files, specs, documentation), and the AI generates code that fits that context. The more specific and structured the context, the better the output.
AI tools are literal. If your spec says "show user info," the AI might render a name and email. If your spec says "display the user's full name, email address, role, and last active date in a summary card," the AI builds exactly that. Precision is not pedantry here. It is a direct input to code quality.
AI tools do not infer intent well. A human developer reads "we want to reduce churn" and thinks about the bigger picture. An AI tool reads that same line and does nothing with it because it is not actionable. AI tools need concrete requirements: what to build, what data to use, what behavior to produce.
AI tools can scaffold fast but cannot validate. They can generate a feature in minutes but cannot tell you whether the feature is what users actually need. That validation is your job.
Why Spec Quality Matters More Than Ever
Consider two versions of the same feature request.
Version A: Loose spec
As a user, I want to see my recent activity so I can track what I've been doing.
Version B: Structured spec
## Feature: Recent Activity Feed
### User Story
As a logged-in user, I want to see a chronological feed of my
recent actions so I can quickly recall what I worked on.
### Requirements
- Show the 20 most recent activities, sorted newest first
- Each activity shows: action type, target name, timestamp (relative)
- Action types: created_spec, updated_spec, added_comment,
published_docs, invited_member
- Include a "Load more" button that fetches the next 20
- Empty state: "No recent activity" with illustration
### Data
- Source: GET /api/v1/users/me/activity
- Response: array of { action, target_name, target_id, created_at }
### Acceptance Criteria
- [ ] Feed loads within 2 seconds
- [ ] Relative timestamps update without page refresh
- [ ] Activity feed reflects actions from the current session
Version A gives the developer (and their AI tool) almost nothing to work with. Version B gives them everything: exact fields, exact endpoint, exact behavior, exact edge cases. The AI tool reading Version B will produce code that is close to correct on the first pass. The AI tool reading Version A will produce something generic that needs significant rework.
The time you spend making Version B instead of Version A is time you save the team in rework, clarification, and back-and-forth.
Writing Specs That AI Tools Understand
Here are specific practices that make your specs more effective when developers feed them to AI tools.
Be Explicit About Data Fields
Do not write "show user information." Write out the exact fields.
### User Profile Card
Display:
- Full name (first_name + last_name)
- Email address
- Role (one of: owner, admin, member, viewer)
- Avatar (fall back to initials if no avatar_url)
- Member since date (formatted as "Month Year")
Define Enums and States
Whenever a field has a fixed set of values, list them. AI tools frequently invent enum values that do not exist in your system.
### Spec Status Values
- `draft` — Initial state, editable by author
- `in_review` — Submitted for review, read-only for author
- `approved` — Accepted, locked for editing
- `archived` — Soft-deleted, hidden from default views
Specify Error States and Edge Cases
AI tools generate the happy path well. The unhappy paths, empty states, error messages, loading states, are where they fall short. Spell these out.
### Edge Cases
- No projects exist: Show empty state with "Create your first project" CTA
- API returns 500: Show error banner "Something went wrong. Try refreshing."
- User has no permission: Redirect to /unauthorized
- List exceeds 100 items: Paginate with 25 items per page
Include Visual References When Possible
If you have a wireframe, mockup, or reference to an existing page, include it. "Match the layout of the Settings page" is more useful to both the developer and the AI than a paragraph describing a two-column layout.
Use Consistent Naming
If your system calls it project_id in the database and API, do not call it "project identifier" or "project ID" or "the project" in your spec. Consistent naming reduces the chance of the AI generating code with the wrong field name.
Staying in the Loop with Implementation Tracking
AI tools accelerate implementation, which means features can go from spec to code to PR faster than the typical review cycle. If you are used to checking in on progress every few days, you might miss entire features being completed.
A few approaches that help:
Connect specs to implementation status. Tools like Intent can track which parts of a spec have been implemented and which are still pending. This gives you a live view of progress without having to ask.
Review PRs early. When a developer submits a PR for an AI-generated feature, review it promptly. AI-generated code is often structurally complete but subtly wrong in business logic. Catching a wrong status transition or missing validation rule is easier in review than in production.
Use acceptance criteria as a checklist. If your spec has explicit acceptance criteria (and it should), use those criteria as the review checklist. Does the implementation meet each one? This is faster and more reliable than reading through all the generated code.
Set up automated checks where possible. If you can verify behavior with E2E tests, do it. AI tools can generate the code and the tests, but someone needs to confirm the tests are checking the right things.
The New PM Workflow
Here is what a healthy PM workflow looks like when working with AI-assisted engineering teams.
1. Design
You define the feature: what problem it solves, who it is for, and what success looks like. This part does not change.
2. Spec
You write a structured spec with explicit requirements, data definitions, acceptance criteria, and edge cases. This part takes more time than before, but it pays for itself many times over.
## Feature: Team Invitation Flow
### Overview
Allow project owners to invite new members via email.
### Requirements
- Owner enters email address in invite form
- System sends invitation email with unique link
- Link expires after 7 days
- Invitee clicks link → creates account or links existing account
- Invitee is added to project with "member" role
### API
- POST /api/v1/projects/{id}/invitations { email: string }
- GET /api/v1/invitations/{token} (public, validates token)
- POST /api/v1/invitations/{token}/accept
### Acceptance Criteria
- [ ] Valid email required (show inline validation error)
- [ ] Duplicate invite to same email shows warning, not error
- [ ] Expired link shows "This invitation has expired" page
- [ ] Accepting invitation while logged in links to current account
- [ ] Accepting invitation while logged out prompts account creation
3. AI Builds
The developer feeds this spec to their AI tool. Because the spec is specific, the generated code is close to correct. The developer reviews, adjusts, and submits a PR.
4. Verify
You review the implementation against your acceptance criteria. You test the edge cases you defined. You confirm the feature does what you specified.
This workflow is faster than the traditional one because step 3 takes hours instead of days. But the total quality depends entirely on the quality of step 2.
Common Pitfalls and How to Avoid Them
Pitfall: Writing specs at the same level of detail as before. If your specs worked fine with human developers who asked clarifying questions, they probably do not work with AI tools that do not. Increase your level of detail for data fields, states, and edge cases.
Pitfall: Assuming the developer reviewed every line of AI output. AI tools can generate hundreds of lines in seconds. It is not realistic to expect the developer to audit every line with the same rigor as hand-written code. Your acceptance criteria serve as a safety net. Make them specific.
Pitfall: Not defining what should not happen. AI tools build what you ask for. They rarely consider what the feature should not do. If there are security constraints, permission boundaries, or business rules that limit behavior, state them explicitly.
### Constraints
- Only project owners can send invitations (admins cannot)
- Maximum 50 pending invitations per project
- Cannot invite users who are already project members
Pitfall: Treating AI speed as a reason to skip review. The fact that a feature was built in two hours instead of two days does not mean it needs less review. If anything, it needs more, because the developer spent less time internalizing the logic.
Pitfall: Losing the clarification conversation. In the old workflow, clarification happened naturally as the developer built the feature over several days. In the new workflow, there is less time for questions to surface. Compensate by front-loading clarity in the spec and scheduling a brief kickoff conversation before implementation starts.
The Bottom Line
AI coding tools have not made the PM role less important. They have made the artifacts you produce, specifically your specs, the most critical input in the development process. A well-structured spec is the difference between AI generating the right feature quickly and AI generating the wrong feature quickly.
The teams that get the most value from AI-assisted development are the ones where PMs write specs that are specific, structured, and unambiguous. Not because the developers need hand-holding, but because the tools they are using respond directly to the quality of the input they receive.
Your specs are now code input. Treat them accordingly.