reading the repo as a product owner

Defects on a big automotive site arrive the same way every time: a screenshot, a ticket, and a guess about when it started. The guess is usually wrong and nobody checks it. A bug gets called “years old” and lands at the bottom of a backlog; a broken image gets re-authored and breaks again next week; a slow investigation turns into a meeting about the investigation.

In September 2026 I started doing something different with the agents I already build with. Point them at the production codebase and the live endpoints, read both, and come back with a root cause the engineering team can act on. More than eight times in one month, it worked.

The product owner's usual move is to describe the symptom well and hand it over. That's exactly backwards when the person describing the symptom can also read the code. The reframe: a defect is an undated change. Find the change, put a date on it, and the fix path mostly writes itself.

So the loop is fixed. Reproduce it with a recipe anyone can run. Read the source (repo history, templates, authored maps) and the live system (delivery APIs, asset metadata, the page itself) side by side. Date the change. Hand back either a code change for the team or a rule for the authors. The agents do the reading; I do the judging, and I sign the conclusion.

The title swap. Vehicle titles on the inventory site were swapping, and the bug had a reputation as years old. It was four months old. A refactor had moved the data source from the URL to a cookie; I found the commit, wrote a repro recipe, and the fix shipped in the next release. The reputation had been costing more than the bug.

The low price. The configurator's “similar matches” cards understated vehicle prices. A legal-label change had switched the displayed figure to base price plus destination, which quietly dropped the options. Every live listing checked reconciled against that explanation, production exposure was dated to the day, and the module was switched off while the fix went in.

The blank hero. A hero video played everywhere except some iPhones. Sweeping 502 pages and 82 WebM files turned up exactly one AV1-encoded WebM, and Apple only decodes AV1 in hardware on its newer chips. Along the way I predicted how the same codec would behave in an MP4 wrapper, was wrong, and published the correction the same day. An RCA you can't correct in public isn't evidence; it's advocacy.

The image that 404'd with no release. The asset manager's “Replace” action regenerates the asset's ID, so every page pointing at the old one broke without a deploy. The delivery API's metadata dated it. The fix was an authoring rule rather than code: use “Create Version,” never Replace. The content team adopted it.

The smaller ones. A packages filter was trusting an accessory-bundle flag instead of the real package classification, so I named the right source. “Buy Online” links carried a literal {modelKey} whenever a series code was missing from an authored map, which broke every hybrid and plug-in hybrid code. A configurator-to-inventory link bug turned out to be a query-string last-wins rule in a CMS template, not code at all. An iPad crash traced back to 4K WebMs. And when an AI triage bot called a defect Sev 1, the evidence put it at Sev 2. Agents get checked too.

Read-only, both sides. The agents read the repos and call the live APIs; they don't change anything. The output is a document (cause, evidence, date, recipe, fix path) that an engineer can verify in minutes, not a pull request they have to reverse-engineer.

Dates beat theories. Every case above turned on putting a date on something: a commit, an authoring action, the first day a price went wrong. A date ends arguments that a theory only starts.

Not every fix is code. Several ended in an authoring rule, a map entry or a template setting, not a deploy. Knowing which kind of fix you're holding decides who gets the ticket, and that's a product call as much as a technical one.

Each case went from symptom to evidence to fix path in about a day; the fixes shipped, the module came off, or the authoring rule changed, depending on the case. My manager asked me to demo the workflow, and I was booked for the monthly tech team meeting to show how the agents are set up to find root causes.

The larger point is about the job. The space between product and engineering is usually filled with translation: tickets describing symptoms, meetings describing tickets. A product leader who can open the repo removes a layer of that, and the team gets its time back for the fix.