Your AI Agent Reads Your Code. It Doesn't Know Your Product.

TV
Thiago Victorino
6 min read
Your AI Agent Reads Your Code. It Doesn't Know Your Product.
Listen to this article

A designer at UX Collective recently put a sentence on the page that every engineering leader should sit with for a minute:

AI coding agents can read codebases but produce generic results because they lack the product’s design context — behavior, principles, voice, identity — which mostly exists outside the code.

That is the whole problem in one line. The agent reads your repository fluently. It still produces work that feels like someone else’s product. Not because the model is weak. Because the context is missing.

When teams hit this wall, they usually reach for the wrong tool. They write longer prompts. They add more examples. They blame the model. What they are actually experiencing is a governance gap they never noticed, because for twenty years the gap did not matter. Humans filled it by osmosis.

Agents cannot absorb osmosis.

Code Is Syntax. Product Is Judgment.

Every product has two layers. The first is the codebase: structure, dependencies, tests, the surface an agent can crawl in seconds. The second is the judgment layer: why this component behaves this way and not another, why we rejected the obvious flow three quarters ago, why our error messages never apologize, why this button is blue and will never be green.

The first layer is a repository. The second layer lives in Figma version history, Slack threads, customer interview notes, slide decks from an offsite two years ago, and the head of a senior designer who joined in 2022.

An agent can read the first. It cannot read the second. And the second is where almost every decision that matters actually lives.

This is the same argument we made in Codifying Institutional Intelligence: the valuable knowledge in any organization is trapped in formats machines cannot consume. The TLDR DESIGN article is a concrete instance of that general claim, narrowed to the product surface. And it points at the same governance conclusion: the problem is not the model, it is the organizational data layer.

The Measurable Question

Here is a more useful frame than “the agent doesn’t know our product.”

How much of your product’s judgment exists in a form the agent can consume?

Not “do we have documentation.” Documentation is almost always stage-two work: prose written for humans, which agents can technically read but cannot reliably act on. The question is sharper than that. It is about structured, versioned, queryable artifacts.

Run the audit on your own team. For each of the categories below, ask whether an agent joining your product today could retrieve a machine-readable answer without asking a human.

  • Voice and tone. Not a brand deck PDF. A structured set of rules with examples and counter-examples.
  • Error and empty states. Patterns, not screenshots. Why we show this message, when, in which tone.
  • Interaction principles. The decisions your senior designer makes without thinking: what gets a modal, what gets inline validation, what gets a confirmation step.
  • Rejected options. The designs you tried and abandoned. The features you chose not to ship. Without this, every agent will re-propose the obvious bad idea your team already killed.
  • Customer segmentation logic. Which user gets which experience, and why.
  • Accessibility and failure-mode standards. What must never ship, independent of pressure.

Most teams, honestly assessed, get a machine-readable answer for one or two of these. The rest is tribal memory dressed up as “company culture.”

That is your context gap. It is quantifiable. And closing it is a governance project, not a prompt-engineering project.

Why This Is Governance, Not Prompting

A prompt is a retrieval request at run time. It answers: what do I paste into the agent’s window for this specific task? That is necessary plumbing. But it is not a durable system. The prompt for today’s ticket will be rewritten tomorrow by a different engineer under time pressure.

Governance is authored, versioned, reviewed context that outlives any single request. In Company as Code: The Governance Layer we argued that organizational structure must become machine-readable because a growing share of your workforce literally cannot perceive it otherwise. Product context is the same argument inside the product surface. Voice, principles, customer segmentation, and rejected alternatives must become queryable assets, not tribal memory, because agents cannot pick them up by hanging around the design review.

Prompts retrieve context. Governance produces the context there is to retrieve. If the second does not exist, the first is cosplay.

Two Caveats Before Anyone Overreaches

Product context is not static; snapshots rot. A voice document written in January and unmaintained by October is worse than no document, because the agent will cite it with confidence while the team has quietly moved on. Any serious product-context system needs the same hygiene as a codebase: ownership, review cadence, deprecation policy, a CI equivalent that flags staleness. Meta’s DrP platform, which we covered in the codification essay, solved this by backtesting analyzers against new incidents. The product-context equivalent is backtesting: does this principle still match what we actually shipped last quarter?

Not everything should be codified. Values, ethical trade-offs, and the hardest taste calls should remain human-owned. Codifying them turns judgment into a rulebook and produces a product that feels like it was written by a committee, because it was. The goal is not a fully specified product machine. It is the opposite: codify the 70% that is actually rule-like, so your senior designers can spend their judgment on the 30% that still deserves it.

The teams that get this wrong pick either extreme. They either try to codify nothing and wonder why their agents produce generic work. Or they try to codify everything and end up with a product that cannot make a decision its rulebook has not anticipated.

The Starting Move

You do not need a platform. You need one artifact.

Pick a single product decision your team made in the last quarter that you are proud of. Something non-obvious. A choice where the first-draft answer was wrong and the team did the harder thing. Write it down as a structured document: what we decided, what we rejected, why, who decided, what principle it expresses. Put it in version control. Link it from the component it governs.

That is your first real product-context artifact. Not a style guide. A decision record an agent can read.

Then do it again next week. And the week after. The teams that operate AI effectively will not be the ones with the best prompts. They will be the ones who, a year from now, have a versioned library of product judgment that anyone, human or agent, can query before they ship.

The agent already reads your code. The question is whether it will ever get to read your product.


This analysis synthesizes “Your AI Agent Can Read Your Codebase. It Doesn’t Know Your Product” (TLDR DESIGN / UX Collective, April 2026).

Victorino Group helps teams close the context gap between code and product judgment. Let’s talk.

All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →

If this resonates, let's talk

We help companies implement AI without losing control.

Schedule a Conversation