A growing part of my experimentation has been about what happens after an AI produces an answer. A document, a review or a little application can look promising in a conversation and still be awkward for anyone else to use.
Claude Code is part of this work: implementing websites and applications, developing reusable publishing and document skills, and turning briefs into something that can be inspected. Alongside that are generated documents and interactive review prototypes. Some of this sits within Measurelab's wider team work; these are my notes on the questions it raises.
What I've been trying
One direction is to turn a review into an interface: keep the passage being discussed next to the observation and recommendation, let someone move between them, and provide an output they can take into their own workflow.
I've also been briefing Claude Code to make visual explanations and hosted artefacts, with sources, clear distinctions and a way for someone else to navigate the material. A brief is the start of that work; it doesn't establish that the finished output has been tested with its audience.
Another is the publishing step itself. A useful artefact needs somewhere to live, an appropriate audience and a way to be updated. The work around access, links and handover becomes part of making the thing.
The Claude work also includes reusable skills for editing documents and preparing outputs. Keeping the instructions, references and validation together makes a useful approach easier to revisit.
This site is a small public example. Reworking the MarkOS material meant more than rewriting the prose. It needed dates, a clear archive status, navigation and working old links, so a visitor could understand what they were looking at without the conversation that produced it.
What seems worth keeping
The form of an output affects how well someone can judge it. A recommendation is easier to assess when the relevant source is close by. A labelled prototype is easier to interpret than a polished page that leaves its status unstated.
Exporting matters for the same reason. People already have ways of working. An interactive view can be useful, while a document remains the thing they need to review, circulate or keep.
I'm finding it helpful to ask a second set of questions after “does it work?” Can the intended person open it? Can they tell which version they have? Do they know what is still uncertain and who to come back to?
What still needs testing
A successful build or publish doesn't tell me whether someone else found the result useful. Review prototypes still need comparison with human reviews. Publishing workflows still need practical checks of access, updating and recovery.
I'm not attaching time-saving claims to this yet. The next useful evidence is another person completing a real task with the output, including the points where they get stuck. That's where a promising demonstration starts to earn its place.