What Are Code Review Artifacts? Screenshots, Video, HTML, and AI Evidence

A code review artifact is reviewable evidence attached to a proposed change that the code diff cannot communicate well by itself. It might be a screenshot, screen recording, HTML prototype, Markdown report, test result, architecture diagram, or benchmark visualization. Last reviewed July 18, 2026. Maintained by the Plannotator project. The code diff shows what changed. Artifacts help show what the change does, why it was made, and how it was validated.

​

A pull request is becoming more than a patch

Consider a pull request that changes a checkout flow. The author or coding agent might provide:

• a before-and-after screenshot;
• a short recording of the updated interaction;
• an HTML prototype showing the possible states;
• a Markdown explanation of the implementation;
• a browser-test report or failure trace from CI.

None of these files replaces the code. They answer questions that are difficult to settle by reading the patch alone:

• Does the new layout work at mobile widths?
• What happens between clicking Pay and seeing confirmation?
• Does the loading state match the intended design?
• Which paths did the automated test exercise?
• What tradeoff did the author make and why?

The reviewer needs both the patch and the evidence required to evaluate it.

​

Why is the word “artifact” confusing?

Software teams already use artifact in several ways. AI products have added another meaning. Our broader guide to AI artifacts explains how documents, images, applications, media, and other agent outputs become reusable objects beyond a chat. In code review, the artifact has a narrower job: it helps a reviewer understand or validate a proposed change. Anthropic did not invent the general software term. Its Artifacts product made a particular form of AI output more visible: a standalone document, application, diagram, visualization, or interactive page that can be inspected separately from the chat that produced it. For code review, the useful definition is broader and more practical:

If a reviewer needs to inspect it to understand, validate, or approve the change, it is part of the review evidence.

​

What can GitHub already do?

GitHub already lets people attach a wide range of files to pull requests. You can drag a file into a pull request description or comment, and GitHub uploads it immediately and inserts an anonymized URL into the Markdown text. GitHub supports common media such as PNG, GIF, JPEG, SVG, MP4, MOV, and WebM. Pull request comments also accept HTML, Markdown, PDFs, office documents, JSON, logs, notebooks, patches, archives, audio, and many development-file formats. See GitHub’s current file attachment documentation. GitHub applies the repository’s visibility to uploaded files:

• files uploaded to public repositories can be accessed without authentication;
• files uploaded to private or internal repositories require repository access.

This is already enough for a small evidence set. An author can put two screenshots in the description and a reviewer can discuss them in a comment. The workflow becomes harder when evidence arrives at different times and in different places. A screenshot may be in the description, a recording in a later comment, an HTML explainer in a review reply, and a coverage report under a workflow run. A reviewer has to discover the evidence before evaluating it. That is the distinction: GitHub provides the file transport. A dedicated artifact surface organizes the evidence as something to review.

​

Are GitHub Actions artifacts the same thing?

Not exactly. GitHub defines a workflow artifact as a file or collection of files produced during a workflow run and retained after the job completes. GitHub’s examples include:

• log files and core dumps;
• test results and failure screenshots;
• compiled binaries and archives;
• stress-test output and code-coverage reports.

Those files are artifacts of the build or test process. They become code review artifacts when a reviewer needs them as evidence for the pull request. The distinction matters operationally. Workflow artifacts live under the workflow run, require repository read access to download, and expire according to GitHub’s retention settings. GitHub currently keeps build logs and workflow artifacts for 90 days by default. A screenshot uploaded into the pull request conversation has a different location and lifecycle.

​

Why are AI coding agents making artifacts more important?

Coding agents produce more than source code. They can run browsers, reproduce bugs, execute tests, inspect logs, create diagrams, compare designs, and explain the work they performed. GitHub Copilot coding agent, for example, can use a browser to validate a web application and include captured screenshots in its pull request. GitHub also preserves agent session logs and links agent-authored commits back to those logs so reviewers and auditors can trace how a change was produced. Claude Code now treats PR walkthroughs, system explainers, dashboards, incident timelines, and release checklists as shareable session artifacts. These pages can combine codebase context, connected tools, test output, and the agent’s explanation in one visual surface. The practical consequence is simple:

Agents create more code and more evidence about the code. Human review has to evaluate both.

This can reduce the burden of understanding a large agent-created change when the evidence is trustworthy and easy to inspect. A polished explanation can also be wrong, stale, or selectively reassuring. The artifact should help a reviewer interrogate the change, not persuade the reviewer to stop reading the code.

​

Why is HTML becoming a common AI artifact format?

Markdown remains useful for durable, text-first documents. HTML becomes attractive when the explanation needs visual hierarchy, spatial layout, or interaction. In “The unreasonable effectiveness of HTML,” Claude Code engineer Thariq Shihipar describes using HTML for dense technical outputs that people are more likely to read and understand. A single HTML file can combine:

• tables and side-by-side comparisons;
• rendered code and annotated diffs;
• SVG diagrams and architecture maps;
• screenshots and visual states;
• tabs, filters, sliders, or small purpose-built controls;
• responsive layouts for large reports.

His code-review example is direct: create an HTML artifact that explains a pull request, renders the actual diff, adds margin annotations, and color-codes findings by severity. That makes HTML more than a document format. It can be a temporary inspection interface built for one change. Reviewers should also know whether an HTML artifact is a static explanation, an interactive prototype, or a live page backed by changing data. A visually convincing page is not automatically reproducible evidence.

​

What makes an attachment genuinely reviewable?

Uploading a file is the beginning, not the complete review workflow. Useful code review artifacts need several properties.

​

Discoverability

The reviewer should be able to see the relevant evidence set without searching a long conversation or opening unrelated workflow runs.

​

Provenance

The artifact should show who or what produced it, where it came from, and when it entered the review. Agent-generated evidence should retain the agent identity and the human who initiated the work.

​

Safe, format-aware inspection

Different evidence needs different treatment. Images need spatial inspection. Video needs playback and timestamps. Markdown needs readable rendering and text selection. HTML needs isolation.

​

Anchored discussion

Comments should be able to refer to a point, region, timestamp, quotation, or whole artifact. “The flicker around 00:14” is more useful when the comment is actually attached to 00:14.

​

A relationship to the code revision

Reviewers need to know which version of the code the evidence demonstrates. A screenshot captured before three later pushes may no longer describe the current pull request.

​

Access, retention, and deletion

Artifact visibility should follow the review’s access rules. Teams should also know how long the bytes remain, whether an external link can expire, and what happens to the discussion when an attachment is deleted.

​

An auditable decision

For consequential changes, the durable record includes the file, its origin, the comments it received, which concerns were resolved, and the human review decision that followed.

​

How does Plannotator handle code review artifacts?

The open-source Plannotator code-review app gathers supported images, GIFs, video, HTML, and Markdown referenced in a hosted GitHub pull request or GitLab merge request into one Artifacts view beside the diff. The review behavior follows the format:

• images and GIFs can receive point or whole-artifact comments;
• video can receive timestamped or whole-video comments;
• Markdown can receive quoted-text or whole-document comments;
• HTML can receive selected-text or whole-page comments and is rendered inside a restricted sandbox.

The source remains visible, so a reviewer can tell whether an artifact came from the change-request description, a comment, a review, or a review thread. Plannotator preserves the author, timestamp when available, and a link to the original conversation. Reviewers can hide evidence they have already inspected and restore it later. Artifact notes join the ordinary review draft. They can be posted to the GitHub or GitLab review with links back to the original evidence, or sent directly to the local coding agent. This is deliberately not a claim that every hosted upload becomes a Plannotator artifact. The current focused set is images, GIFs, video, HTML, and Markdown found in the hosted conversation. GitHub Actions artifacts are not automatically imported. Local diff reviews do not have an artifact gallery because they do not have a hosted PR or MR conversation to collect from. Artifacts are currently associated with the review rather than pinned to a particular Git revision. GitHub or GitLab remains the system of record for the change request. Plannotator provides a focused surface for inspecting and discussing supported evidence beside the code. See how to review pull request artifacts in Plannotator for the released workflow.

​

Common failure modes

Artifacts improve review only when reviewers understand their limits.

• Stale evidence: the artifact demonstrates an earlier revision of the code.
• Broken or expired links: externally hosted evidence disappears or its access rules change.
• Unsafe active content: HTML or SVG is rendered with more authority than it should receive.
• Missing provenance: the reviewer cannot tell whether a person, agent, or workflow created the output.
• Presentation bias: a polished walkthrough makes the change feel safer than the underlying implementation is.
• Incomplete validation: a successful screenshot or test report demonstrates one path, not every relevant behavior.
• Evidence overload: a large pile of generated reports increases review work instead of directing attention.

A good artifact reduces uncertainty. It should not bury the reviewer in output.

​

Frequently asked questions

​

Are code review artifacts the same as build artifacts?

No. A build artifact is output produced by a build or workflow. It becomes a code review artifact only when a reviewer needs to inspect it as evidence for the proposed change.

​

Does GitHub support code review artifacts?

GitHub supports many file attachments in pull request descriptions and comments, and GitHub Actions retains workflow artifacts. Those capabilities provide the underlying files. A dedicated review-artifact surface adds organization, format-aware inspection, provenance, and anchored discussion.

​

Do artifacts replace the code diff?

No. The code diff remains the proposed implementation. Artifacts make its behavior, validation, and surrounding reasoning easier to inspect.

​

Can an AI agent create review artifacts?

Yes. Agents can create screenshots, recordings, diagrams, reports, HTML explainers, and test output. Reviewers should still verify the evidence, preserve its provenance, and make the final review decision themselves.

​

Is it safe to review an HTML artifact?

Only when the hosting or review system treats it as untrusted active content. Arbitrary HTML should be isolated with browser sandboxing and restrictive content policies. External HTML should not inherit access to the review application.

​

Should every pull request include artifacts?

No. A small backend change may be completely understandable from its tests and diff. Artifacts are useful when behavior, design, validation, or system context cannot be reviewed efficiently from code alone.

​

In one sentence

A code review artifact is evidence used to make the review decision:

Show me what this change does, how it was validated, and the context I need to judge the code responsibly.

As coding agents take on larger engineering tasks, that evidence will become a larger part of human review. The goal is not to generate more material. It is to make the right evidence inspectable. Next: Learn how revision diffs show what changed since a reviewer’s last look.