The constraint in software delivery used to be developer capacity. Everything built around that assumption: sprints sized to what a team could ship, standups optimized to keep engineers unblocked, roadmaps negotiated against build cost. The processes made sense because code was the scarce resource.
Generative AI removed that constraint. Code is no longer scarce. A well-specified feature that used to take two weeks of engineering time can now be assembled in hours. The bottleneck has moved, and it has moved squarely to the product manager.
Not because PMs are slow. Because spec is now code. The quality of what gets built is determined almost entirely by the quality of what gets specified — and specification is a function of context. How complete is your understanding of the problem? How current is your knowledge of the client's technical environment? How precisely have you defined the boundaries of what you're building?
When code was hard to write, a vague spec could still produce useful software. Engineers filled in the gaps with judgment, asked clarifying questions, negotiated scope in real time. That negotiation was inefficient, but it was also a form of context repair. AI doesn't repair context. It amplifies whatever you give it.
The constraint has shifted. Engineering execution is no longer the pinch point — context engineering is.
Most teams learned the wrong lesson from the first generation of AI tools. The early bottleneck looked like prompting. Write a better prompt, get a better result. That observation was accurate for a while, and it produced an entire industry of prompt engineering advice.
The problem is that IDEs, coding assistants, and chat interfaces have largely solved the prompting problem. Meta-prompting, structured templates, and tool-specific optimizations handle most of what used to require manual craft. If your team's AI results are still inconsistent, the gap is not in how you phrase requests. It is in what you bring to the request before you write a single word.
That problem has a name: context engineering.
The stack
Context for a product is not a single thing. It is a stack, and each layer does different work.
At the base is problem definition: what are you actually trying to solve, for whom, and under what constraints? This is the PM's oldest and most fundamental job. It has not changed. But it has become more consequential, because an AI working from a shallow problem definition will produce a shallow solution at speed.
Above that sits operational and execution context: how this product is built, deployed, and maintained. The architectural patterns in use, the deployment constraints, the technical debt that can't be touched. AI-generated code that ignores this layer produces technically correct outputs that break in the specific environment where they need to run.
Then client context: not just what the client wants, but what their technical environment looks like. Their existing systems, their integration constraints, their team's capabilities. A recommendation that is correct in the abstract may be unusable for this client specifically.
Domain context is the accumulated knowledge of the industry or problem space: how this category of product behaves, what failures look like, what patterns have been tried and abandoned. This is the layer that separates an experienced PM from someone reading the same documentation for the first time.
Above that: technical industry standards — the current state of the relevant discipline. Security patterns, accessibility requirements, performance norms. These change. A context layer that was accurate six months ago may now be stale.
And at the top: legal and compliance constraints. The rules that cannot be negotiated in code. These must be present before any spec is written, because discovering them afterward means rewriting code that AI generated in minutes but that a legal review will now block for weeks.
Each of these layers is a tier in the stack. Together, they form the complete context for building something real.
Six layers. Each must be current. A stale layer is the same as a missing layer.
The unit of work
Here is where the mental model for daily work comes in.
A unit of AI-assisted work is not a feature. It is a slice through the stack. You are addressing a specific part of the problem layer — one capability, one user flow, one component — while drawing on the relevant supporting layers beneath it. The problem definition layer names what you are solving. The client context layer constrains how. The domain layer informs what good looks like. The compliance layer sets the floor.
Think of it as cutting a slice from the cake. Each slice contains all the layers. The ratio shifts depending on what you're building — a compliance-heavy feature pulls more from the legal layer, a new integration pulls hard from the client technical layer — but the slice is never complete without all of them present.
Every unit of AI-assisted work is a slice. Each slice must contain all relevant layers — or the output will be built on an incomplete picture.
If a layer is missing, the slice fails. Not visibly, at first. AI will generate something. It will look like a working answer. But it will be optimized for an incomplete problem, running on assumptions about context that were never provided. The failure surfaces later, in the gap between what was built and what was needed.
The PM's job is to maintain the stack and to be deliberate about which layers are in scope for each unit of work.
Where the work now lives
This is not a new responsibility. PMs have always managed this context. What has changed is the cost of getting it wrong.
When code was expensive to write, a context gap produced a clarifying conversation. When code is cheap to generate, the same gap produces a completed feature that solves the wrong problem. The output arrives faster, looks more finished, and requires more effort to unwind.
The PM as constraint is not a critique. It is a description of where the work now lives. The teams that will build well with AI are the ones that invest in the context stack before they start generating. The teams that won't are the ones still optimizing prompts.
Spec is code. Treat context accordingly.