Prove1 rating, average withheld366 artifacts built
The Build Factory: see what your coding agents actually shipped
Run coding agents like a factory you can see into: a proof page on every pull request, a changelog every day, both read on a phone.
Azim AhmedFounder
- Published
- Updated
- Reading time
- 6 min read
A build factory is a way of running coding agents where every unit of work comes out with evidence you can read in a minute: a page of pictures for each pull request, and a page of plain-words changes for each day. You stop asking an agent what it did. You open a link.
This is the first part of a series about running agents that way. It covers the two pages that make the work visible, how they compare, and the prompt that sets them up.
What is a build factory?
It is an agent setup with two outputs besides the code. Each pull request publishes a proof page: screenshots, a short recording or a diagram of the change, with one line of caption each. Each day publishes a changelog page: what shipped, written for the people who use the product.
Both are artifacts on Super Artifacts, built from marketplace templates. The agent fills the template's document and publishes it over MCP; the platform renders it and hands back a private link. Nothing about the factory needs a new tool on your machine. The agent you already use does the work.
Why can't you see what your agents are doing?
Because the default evidence an agent produces is written for another program. A pull request description says "updated the retry logic and added tests". A terminal log says 214 passed. Neither tells you what a person will now see on the screen, and neither fits on a phone.
So review turns into one of two things. You either trust the summary, or you check out the branch and run it yourself. The first lets mistakes through. The second makes you the bottleneck for every change, which defeats the reason you handed the work to an agent.
I review every pull request in this repository from my phone. That only works because every pull request arrives with a page made for exactly that screen.
What goes on a proof page?
Pictures first. The pr-proof template is a phone-first review page for one pull request, in two layers:
- The pictures are the proof: before and after screenshots, a short recording of a flow, a diagram for a change that has no screen. Each carries one caption, and a tap opens it full screen.
- Under the hood, folded beneath the pictures, is the technical layer: a plain-words story of what changed and why, review notes marked breaking, risky or safe, the file map, and the few hunks of the real diff that carry the change, each annotated.
The slug is pr-proof- followed by the pull request's number. Publishing again lands as a new version of the same artifact, so the link in the pull request keeps showing the newest set. A project rule that matches every slug starting with pr-proof- gathers them in one place, and the project's own audience decides who else can open them.
Tip
A change with no screen, such as a migration or a background job, still gets a picture: a diagram of before and after. It never needs to be a pasted test run.
How does the daily changelog work?
The changelog template turns merged work into a release page somebody outside the team can read. Releases run newest first, each with a version, a date, a headline and entries grouped as added, changed, deprecated, removed, fixed or security. A release that makes the reader change something carries a callout with the upgrade steps.
In the setup below, an agent drafts the day's entries from the pull requests that merged, rewrites each one for the reader, and publishes a page for review. A person reads it, picks what goes out, and approves. Each new day is prepended to the same document and published as a new version of the same artifact, so there is one address for the whole history.
How do the proof page and the changelog compare?
They answer different people's questions, at different moments, from the same work.
For a change that is best told as a narrated walkthrough, the pr-video-overview template is a player for one: a strip of key changes, each its own short recording with chapters, and a comment box that stamps every note with the moment on screen. For evidence that mixes video with screenshots and diagrams, pr-proof is the better fit.
How do you set it up?
Connect your agent
Add the Super Artifacts MCP server to the agent you already use and approve its sign-in once. The connection stays until you revoke it.
Give it the two standing instructions
Paste the prompt below into the instructions your agent reads at the start of every session, such as a project instruction file.
Open one pull request and read the link
The agent publishes the proof page, sets it private and puts the link in the pull request. Open it on your phone and check the pictures match the change.
Approve the first changelog
At the end of the day the agent publishes the changelog page for review. Read it, cut anything nobody outside the team would notice, and publish.
Run my agents as a build factory
What does this not do?
It does not judge the change for you. A proof page makes the evidence quick to read; deciding whether the evidence is right is still the reviewer's job, and a page of confident pictures about the wrong thing is worse than none. Keep the agent's proof about the change in front of you, not a tour of the whole product.
It also does not replace your tests. The pictures show what a person sees; the tests still decide whether the code holds.
Questions
- You can, and the proof page carries the hunks that matter, annotated, folded under the pictures. Most of the time the pictures and the plain-words story are enough to decide whether to look closer.
Try these templates
Running agents like this? Talk to us.
Tell us what your agents ship and who reviews it. A person on the team reads every message and replies.
Or write straight to support@superartifacts.app.
Azim AhmedFounder
Builds Super Artifacts, and reviews every pull request its agents open from a phone.