What “AI-supported” actually means here.
Every product CV mentions AI, which makes the claim close to worthless unless you know how someone is actually using it. So here is the specific version: the problem it solves, what gets delegated, where I step in, and what came out at the end.
The problem it solves
One product person cannot hold a regulated domain in their head. At Climatise I was the sole product function for a carbon accounting and sustainability reporting platform, working across ESOS Phase 4, SECR, CBAM, UK SRS, ISO 14064 and ISO 50001, from discovery through specification and prototype to build and QA.
Six months produced over 100,000 lines of specification, QA and research documentation across some 360 documents, including 60+ PRDs. The core of it was one sequential compliance system rather than a pile of separate features: an eleven-page assessment wizard whose output pre-populates a twelve-step site audit wizard, which in turn feeds extrapolation, a compliance summary, and finally the submission to the Environment Agency. Those two specifications alone run to around 6,000 lines, and the 225 fields passing between them are catalogued in a dependency register the frontend builds against.
Work at that volume normally rots. A definition moves in one place and not the other, acceptance criteria start contradicting the flow they describe, and engineers quietly stop trusting the specification. Length is not the achievement here — the regulation is genuinely that intricate, and a shorter specification would simply have pushed the ambiguity onto whoever had to build it. AI is how one person keeps a body of work that size accurate and consistent with itself.
Where it does the work.
- First drafts from source material
- Regulation, call transcripts and engineering threads become a structured specification I then rewrite. The draft is scaffolding, never the deliverable.
- Consistency across the whole set
- Automated passes that catch terminology drift, stale cross-references and acceptance criteria contradicting the flow they sit in — the errors a human reader stops seeing after the third read.
- Specifications and tickets kept in step
- The spec in the repository and the ticket stakeholders read stay synchronised, so nobody builds against a version that has moved on.
- Repeatable QA
- An eight-stage pipeline model became a 120+ row scenario manifest and 25+ scenario specifications, now feeding an automated Playwright suite.
- Research at pace
- A six-competitor analysis producing a pricing recommendation and build sequence, regulatory briefs with qualification criteria and gap analysis, and prompting research for document ingestion.
- The process itself
- The PRD format, the bug format and the route from specification through prototype and development into QA are written down as rules that apply every time, rather than conventions somebody has to remember.
Where I step in
The list opposite is the part that scales. This is the part that does not, and it is what makes the rest worth trusting.
There is only so much context you can give a model, so the real work is choosing what goes into it — and then answering for what comes out.
- Deciding what it sees
- Knowing which paragraph of a regulation, which line of a customer call and which platform constraint actually bear on a decision. The model only sees what I judged worth showing it, and everything downstream depends on that being right.
- The commercial call
- What to build, in what order, and what to trade away is a question about customers, cost and timing. That sits with the product lead and does not move.
- Compliance interpretation
- A confident wrong answer about ESOS or CBAM is far more expensive than a slow right one, so interpretations get checked against the source regulation rather than accepted.
- QA that carries risk
- Automation covers what is repeatable and low risk, which is most of it. Where getting it wrong would break compliance, the testing is manual and the responsibility is mine.
- Every line that goes out
- The standard is the one Clay set in its internal writing policy: you have to be able to stand behind any individual sentence you send, and “the model wrote it” is not an answer anyone should accept.
You can feed a model context. You cannot feed it accountability.
What a team is actually buying is someone who will answer for the document. The volume only counts because one person stays answerable for all of it. In practice that means the documentation layer keeps pace with delivery instead of falling permanently behind it, the rules for how work gets written down are set once and applied every time, and a product function can be held by one person for far longer than would otherwise be reasonable.