when the product owner ships it themselves

A spec instead of a ticket, a coding agent instead of a team, review agents for legal, data protection and security instead of review rounds. What already holds up — and what we learned trying it on our own codebase.

by tokyn studio · 6 min read

When the product owner ships it themselves - Consulting

TL;DR. A product owner describes a feature, a coding agent builds it, review agents for legal, data protection and IT security read the code and give recommendations — real experts are pulled in only where it actually gets stuck. This is no longer a picture of the future; the building blocks have names and products. What is missing is the setup around them. We tried it on a codebase we look after, and learned where the line runs. Last updated: 2026-09.

what is coming together right now

Three developments that are unremarkable on their own and, taken together, shift the division of labour.

The specification becomes the source of truth. "Spec-driven development" is now seen as the successor to vibe coding: the centre is not the code but a versioned specification from which agents generate the rest. The difference to old-style requirements documents matters — the spec does not passively describe the system, it governs it. It is the shared memory of humans and agents.

Coding agents have become everyday tools. Not as autocomplete, but as something that takes on a task, makes a plan, touches files, runs tests and finally puts a proposal on the table.

And there is now a category for the watchers. Gartner calls them guardian agents: agents whose only purpose is to observe and constrain other agents. The first market guide appeared in February 2026, with a forecast of 10 to 15 per cent of the entire agent market by 2030. Three capability areas: traceability of agent behaviour, identity and access, and cross-platform policy enforcement.

How fast this is tipping shows in another Gartner number: by the end of 2026 around 40 per cent of enterprise applications are expected to contain task-specific agents — in early 2025 it was under 5 per cent.

the picture we are talking about

A product owner wants a feature. Instead of writing tickets for a team, they write a specification: what should happen, for whom, under which conditions, and how we will know it works.

A coding agent implements it. Then several review agents read the same code, each with a clear brief:

→ Legal checks contractual references, deadlines and promises made in the interface — does the copy commit to something the contract does not cover?

→ Data protection checks which data is collected, where it is transferred and how long it is kept — and whether the privacy policy still covers that.

→ IT security checks permissions, dependencies, handling of secrets, attack surface.

Each delivers recommendations, not approvals. Where a recommendation carries weight, it goes to a person in the relevant department — not as a meeting, but as a concrete question with a reference to the line in question. The rest passes through.

The promise is not that specialists become unnecessary. It is that their time lands where it has effect: on the three questions that genuinely need a decision, instead of reviewing thirty pages of which 27 are uncontroversial.

what we learned from trying it

We pointed exactly such a setup at a codebase we look after: five review roles, each with its own perspective — technical SEO, accessibility, conversion, performance, and content and law. Read-only, each briefed to evidence findings rather than assert them. Then we implemented.

Three things from that matter more to us than any market forecast.

First: review agents are good at reading and blind to doing. The five roles found 29 issues. Implementing them surfaced ten more — and among those were the two most serious of the whole round. A form handler had been running for months in a data centre on the wrong side of the Atlantic, because no region was configured anywhere. And a single misplaced CSS line rendered half the typographic scale inert: on one page alone, 29 of 38 paragraphs render a different font size than the code specifies. Neither is visible while reading. Both surface the moment you touch something.

Second: agents are confidently wrong. Every consequential claim was verified against the code before we acted on it. That paid off: one role had concluded from a commit message that three images came from a template — they were AI-generated, which changes the labelling obligation entirely. The finding was plausible, well argued and wrong. Without the cross-check it would have gone through.

Third: recommendations only become useful once somebody decides. Two findings we deliberately did not implement, three belong in front of a lawyer, four depend on business decisions. An agent can say "here is a claim your own code contradicts". Whether the claim or the code then changes is not a technical question.

what the setup needs

From that experience, not from a whitepaper:

1. A spec that is binding. If the specification stays mere description, truth migrates back into the code — and the PO loses control of the very thing they wanted to steer. 2. Roles with a brief and a limit. "Recommendation, not approval" has to sit in the role's brief, otherwise the system approves itself. 3. Mandatory cross-checks for consequential claims. Not every claim, but every one that leads to a change. 4. Human-in-the-loop at defined points. Not everywhere — then nothing is gained. But wherever an action is irreversible, costs money or creates a legal obligation. 5. A record that survives an audit. Who decided what, when, on what basis — agent and human alike. 6. And the uncomfortable question: who checks the checkers. Gartner calls it metagovernance. A guardian agent with the wrong rule is more dangerous than none, because it suggests safety.

where we stand

Honestly placed: we follow this development closely, we are building the setup, and we do not have it sitting on a shelf as a finished product. What we have is experience from our own everyday work — including the places where it did not work.

Our thesis: the bottleneck in product development is shifting from "who builds this" to "who answers for this". Teams that set that up cleanly early do not gain a few per cent of speed, they gain a different division of labour.

If you are currently working out how far a product owner should get on their own — and which guardrails have to be in place for that: talk to us. 30 minutes, no pitch deck. We are happy to tell you what went wrong on our side, too.