The best spec for your next app is work you've already done

When someone who doesn't write code builds a tool that works, the story usually ends up being about the tool, and I think that misses the interesting part. In the best examples I've read lately the cleverness wasn't in the tool at all... what made it work was the input, which was work someone had already done and then handed over.

Anthropic wrote up how its legal team cut review times, and the person at the center of it is Mark Pike, a product lawyer who says plainly, "I am not the one coding." The article is even more direct ("He doesn't know how to code"), which is why I like it as an example.

What he built is a self-review tool for marketing. Marketers paste in their content, Claude checks it against a skill, which is a file with the legal team's historical guidance and review framework, and it flags issues as low, medium or high risk. According to the article, turnaround dropped from two to three days down to 24 hours. That didn't come from a clever prompt -- it came from answers the legal team had already written down and the framework they already used to judge risk, so the tool is mostly that guidance put in front of the people who need it instead of sitting in a lawyer's queue.

His second trick is smaller, and honestly it's the one I like more. He had Claude analyze ten of his recent memos to learn his formatting preferences, so now he can upload a product roadmap into a Claude project, invoke that skill, and get a first draft in his voice. None of those ten was a style guide written for the purpose... they were just memos he'd already signed.

The same pattern at other desks

Aakash Gupta wrote about Mike Bal, Head of Product and AI at David's Bridal, whose move is to pull the Confluence requirements and a Figma frame link into one Claude Code session and ask, "what did I miss?" Gupta puts it at 30 seconds vs. 1-2 hours of manual comparison, and in his example Mike caught that onboarding data wasn't showing on the vision board. That requirements doc had been the spec all along -- Mike just started treating it like one.

In finance, a CFO Connect recap of a live session led by Christian Sanford of QuantFi describes a demo built on a shared services invoice across four entities in three currencies. The output was a complete journal entry upload sheet with entities, GL accounts, debits and credits by currency, allocation methodology notes, and a checking tab. The line I'd underline is about that checking tab, which the recap says "is what makes controller review fast and trustworthy."

So that's a lawyer, a product lead and a finance team, and none of them started with a blank page. Each one began with something that already existed -- past guidance, a requirements doc, a real invoice -- and each had a person on hand who already knew what a good answer looks like, which matters as much as the documents do.

How to collect your ten

If you want to try this, I'd spend the first hour away from any AI tool just finding your examples, because that's where most of the value is. I want recent work first, since your process six months ago may not be your process now, and Mark used his recent memos, not his oldest ones. I want representative work too, the ordinary cases and not the one you're proudest of, because those are what the tool will see all day. Then include one you got wrong, a decision you'd reverse or a review that missed something, with a line about why... that's often the most useful page in the pile, because it shows the tool where the edge is.

After that, find the framework you already use. Most experts have one even if it only lives in their head or a half-finished checklist, so write it down plainly... low, medium and high is enough to start. Finally keep the real inputs, so a real invoice, a real requirements doc or a real piece of marketing copy, because made-up examples tend to be cleaner than the work ever is. Then you build, and that part is usually easier than you'd expect because the thinking is already on paper.

There's a quieter benefit too, because when the tool is built from your own past work you're the person best placed to tell when it's off... you wrote the guidance and you know the memo voice, so you're also the one who'll notice when an allocation comes out wrong.

That matches how these teams describe their setups. The Anthropic piece says Mark's workflows "route to lawyers for approval, not around them," and warns that AI can still hallucinate, while the CFO Connect recap says "Human sign-off before any output touches the ledger is essential." In both cases the expert's documents become the spec and the expert stays the reviewer, so quality stays with the person who already owned it.

One caveat is that the legal example is Anthropic writing about its own team using its own product, so I'd treat it as a pattern worth copying rather than proof your numbers will match. The other two come from people outside Anthropic describing the same move, which is why I think the pattern holds up.

At Workbricks, the documents behind a workflow are part of the app itself, so that's where past guidance and memos like these would live. You don't need us to get started though. You need ten good documents and the person who wrote them.