UX Collective: Your AI agent knows the codebase but not the product

“Your AI agent can read your codebase. It doesn’t know your product,” published in UX Collective in April 2026, addresses a gap that is becoming common as AI coding agents enter design and product workflows. Author Gregory Muryn-Mukha makes a distinction that is easy to overlook: an agent can scan a codebase, recognize its patterns, and generate technically consistent output — but it cannot infer the reasons those decisions were made, the user problems they address, or the constraints of the people who will actually use the product.

Technical context is readable from code. Product context is not.

The article draws on framing from Martin Fowler’s team, which identified “context engineering” — deciding what an agent should know before it executes anything — as what the author describes as the defining AI skill for teams shipping with coding agents. This requires proactively providing the agent with product documentation, user research, design decisions, known trade-offs, and scope constraints before it starts work. Without this, the agent defaults to technically plausible output that solves the wrong problem.

For designers and product managers, the practical implication is that adopting AI agents in a product environment requires creating explicit documentation of decisions that currently live only in institutional memory. This means writing down not just what the design does but why specific choices were made — what was explored and rejected, what user scenario drove a given interface decision, what constraints were non-negotiable and why. Work that was previously implicit in team knowledge needs to become machine-readable input.

The article is directly useful for any team moving from using AI for individual tasks to integrating AI agents into a sustained product workflow. It makes a specific argument: the quality of agent output is a function of the quality of the context you provide, which means context preparation becomes as important as prompt writing. For designers who are often the people most familiar with the user needs and design rationale behind a product, this puts a new kind of documentation responsibility in their scope.