AI Coding Agent Artifacts: What Counts as Evidence

Coding agents no longer hand back a bare diff. A cloud agent now returns a pull request with a bundle of material attached: screenshots of the changed screen, a recorded video of the agent clicking through the feature, a session log of every tool it called, test output, and in some products a signed commit that GitHub marks as "Verified". Each item looks like evidence. Very few of them prove the same thing, and some prove nothing about whether the task was done at all.

The trust gap is already measured. In the Stack Overflow Developer Survey 2025, more developers actively distrust the accuracy of AI tools (46%) than trust it (33%), and only 3% report highly trusting the output. Experienced developers, defined in the survey as those with 10 or more years of work experience, are the most cautious, with a 20% "highly distrust" rate. That distrust is rational, and the answer to it is not more artefacts. It is knowing which artefact answers which question, and who produced it. The same principle runs through our DATS methodology for every AI system we place inside an enterprise.

This guide is written for the engineering lead who has to accept or reject agent work. It holds one altitude: a cross-vendor grading of the artefacts that Cursor, GitHub Copilot, OpenAI Codex and Devin produce, by what each proves and who wrote it. It cedes what a full proof package contains to our proof of done guide, what to attach before review and how the merge gate splits from the done gate to our coding agent review queue guide, and who should do the verifying to our AI agent task verification guide.

This guide is shipped by the team behind Cognibl, the work-management platform where a task reaches done only once a proof version is attached. Or see DATS, our five-stage AI consulting system for placing AI inside enterprise operations.

What counts as an AI coding agent artefact?

An AI coding agent artefact is any record the agent produces alongside its code change to show what it did: screenshots, screen recordings, session logs, terminal output, test results and signed commits. Cursor, GitHub Copilot, OpenAI Codex and Devin each attach a different mix. An artefact counts as evidence only when it answers a specific question a reviewer has about the task, not simply because the agent attached it.

The vendor documentation, retrieved on 1 November 2026, shows how varied the mix has become. Cursor's cloud agents documentation says cloud agents "produce merge-ready PRs with artifacts to demo their changes", and that agents produce screenshots, videos and logs so a reviewer can see what changed and how the agent verified its work. GitHub describes Copilot's cloud agent editing files and running tests and linters in a cloud development environment, the setting our cloud agent isolation guide examines, with session logs showing the work and the tools used. At its launch in May 2025, OpenAI described Codex citing terminal logs and test outputs for each step. Devin tests the application end to end after opening a pull request and sends a video recording of the run.

Read those descriptions carefully and a pattern appears. Every vendor frames its artefacts around the reviewer's convenience: see the change without checking out the branch, follow the session without rerunning it. That is genuinely useful. It is also a different job from proving that a task met its definition of done, which is the question an engineering delivery function is ultimately accountable for, and the question at the centre of any agent task verification decision.

Which artefacts prove a change works, and which only show activity?

Coding agent artefacts fall into three grades. Activity artefacts, such as session logs and reasoning traces, show that the agent worked. Output artefacts, such as the diff, commits and screenshots, show what it produced. Outcome artefacts, such as test results tied to the definition of done, show whether the change does what the task asked. Only the third grade proves a change works, and only when the test encodes the task.

The grading matters because the three are easy to confuse when they arrive together. A long session log feels thorough, and it is: it records effort. It does not say whether the effort reached the right place. A screenshot of the new settings page proves the page renders; it cannot prove the setting persists, that the old behaviour is preserved for existing accounts, or that nothing outside the scope was touched. A green test run is the first artefact that can say something about behaviour, and even then only about the behaviour the tests exercise. That is why our approach to placing AI starts from the test rather than the tool.

This is why the grading has to be anchored to the brief rather than to the artefact. When we run an AI placement diagnostic for an engineering organisation, the first question is not which agent to buy but what each team counts as done today. A team that cannot state its definition of done for human work will not be able to grade an agent's evidence against it either, and the risk is that it accepts whatever looks most complete. The evaluation harness discipline applies here: the test is the specification, and evidence is only as strong as the specification it was checked against.

What does a signed "Verified" commit actually prove?

A signed "Verified" commit shows that a commit came from a signed, trusted source. It says nothing about whether the code is correct or whether the task is complete. GitHub's own documentation frames signature verification as confidence that changes come from a trusted source. For a coding agent's commit, that is a provenance guarantee, which is valuable for audit, but it is not a quality guarantee.

The naming is the trap. GitHub documents that commits from the Copilot cloud agent are authored by Copilot, list the person who started the task as co-author, include a link to the session logs in each commit message, and "are signed and appear as "Verified" on GitHub", according to GitHub's guide to managing agent sessions. In GitHub's explanation of commit signature verification, signed commits are marked as verified so other people can be confident the changes come from a trusted source. A reviewer skimming a pull request sees a "Verified" label next to agent work and can read it as "checked". It means "signed", which is one reason our review queue guidance keeps authorship and acceptance apart.

What the signature does give an engineering lead is traceability, and that is worth keeping. A commit that links back to its session log lets a reviewer, or an auditor months later, see why a change was made. That turns the commit into a durable pointer from the codebase to the activity record. The commit's content is output evidence; the signature and the session-log link are provenance metadata about that output, which the section on who produced the evidence below treats as a second axis. Neither belongs in the outcome column. An AI operating model that defines review roles should say so explicitly, so that nobody on the team treats the badge as a review.

How much should a reviewer trust a video recording from a coding agent?

A reviewer should trust a coding agent's video recording as proof that the path the agent chose works on one run. Devin's documentation says its test planning identifies the single most important end-to-end flow that proves the feature works. By default that is one flow, selected by the party whose work is being checked, so it is strong demonstration evidence and weak coverage evidence.

The recordings themselves are well made. According to Devin's testing and recordings documentation, Devin sets up the environment, writes a short test plan grounded in the code, records the screen while it executes that plan in a browser, annotates key moments, and sends the video as an attachment once CI is green and review comments are addressed. Further flows are added only for a genuinely critical edge case. There is also a Pre-approve testing setting, so the run happens without anyone asking for it. Cursor's agents likewise produce videos, and a person can take control of the agent's remote desktop to test the software without checking out the branch locally. Deciding in advance which flows deserve a recording is the kind of question an AI placement diagnostic settles before rollout.

Three questions turn a recording from a demo into usable evidence. First, does the flow in the video match the acceptance criterion in the task, or a neighbouring one that was easier to show? Second, what failure paths were not recorded: the invalid input, the expired session, the second user? Third, can the run be reproduced by someone other than the agent? A recording answers none of these on its own. Treated as an output artefact that shows the happy path, it saves a reviewer real time. Treated as proof of done, it hands the coverage decision to the agent. A governed AI execution office is the natural place to write that distinction into the review checklist before the first agent pull request lands.

Are terminal logs and test outputs stronger evidence than screenshots?

Terminal logs and test outputs are stronger evidence than screenshots when the tests encode the task's acceptance criteria and were not written by the agent to fit its own change. A test result is reproducible and can be re-run by someone else, which a screenshot cannot. A green suite of tests the agent wrote alongside its code, however, mostly confirms that the code agrees with itself.

OpenAI made test output central to Codex at launch. In the Introducing Codex announcement of 16 May 2025, OpenAI said that "Codex provides verifiable evidence of its actions through citations of terminal logs and test outputs, allowing you to trace each step taken during task completion." The same post notes that Codex can be guided by AGENTS.md files that tell it which commands to run for testing. That last detail is the important one for a reviewer. When the team, not the agent, decides which tests count, which is the core idea of an evaluation harness, the test output becomes an outcome artefact. When the agent decides, it is closer to an output artefact with a pass mark attached.

The practical checks are short. Did the tests that passed exist before the agent started, or were they added in the same change? Do any of them exercise the acceptance criterion directly? Was a coverage report produced, and does it show the changed lines being run? A terminal log that cites a passing command is traceable, which is better than an assertion, but traceable is not the same as sufficient. This is the same verification-first thinking our developer productivity work applies when an engineering team scales agent output faster than its review capacity.

Why does it matter who produced the evidence?

Who produced a piece of evidence decides its weight. An artefact the agent generated and reported about itself is a claim. An artefact written by the platform the agent runs through, outside the agent's control, is a record. An artefact a second party can re-run independently is a check. Every artefact named in this guide comes from the agent or its vendor's platform, not from an independent party, which is why GitHub tells reviewers to keep reviewing.

GitHub says this plainly. Its documentation for the Copilot coding agent states: "Logs do not replace your own review and testing." The same page warns that Copilot can produce incorrect or suboptimal code, including code that contains security vulnerabilities, and tells teams to review and test the output before using it in production, as set out in GitHub's overview of the Copilot coding agent. That is the honest position, and developer trust data points the same way.

Provenance is also where the work layer earns its place, and where agent work management differs from a tracker that records whatever an integration reports. In Cognibl, from DILR.AI, the record of what happened is written by the gateway, append-only and hash-chained, rather than reported by the agent, and agents reach tools through an MCP gateway that is deny by default. That moves the tool-call trace from the claim column to the record column. Applied to the four vendors, a Cursor screenshot, a Devin recording and a Codex citation are produced by the agent during its own run. GitHub's documentation says Copilot's commits are signed and that its session logs show the agent's reasoning and the tools it used, so those are hosted by the platform but still describe the agent's own account of its work. None of them is a check that a second party ran against the outcome. The same reasoning shaped how we described running agents inside an isolated cloud environment: isolation limits what an agent can reach, and an independent record shows what it actually did. Neither replaces a person checking the outcome.

How should an engineering lead weigh vendor artefacts before accepting work?

An engineering lead should weigh each vendor artefact by asking three things: which reviewer question it answers, who produced it, and whether it stays fixed after it is filed. Artefacts that answer an outcome question, come from a source outside the agent and are stable earn the most weight. The decision to call the task done should rest on those, with activity and output artefacts as supporting context.

Stability is the property that is easiest to overlook. Evidence held only in a vendor's session history, a log store with its own retention rules, or a chat thread sits outside the team's control, and may not be there in the same form when someone audits the work. Evidence that supports a done decision has to be pinned to the task, the premise set out in our overview of what Cognibl is. In Cognibl, a task reaches a done status only once a proof version is attached, and the database refuses the move without one. The proof is a CSV describing the run, referencing the artefact, screenshots and hashes, plus a coverage report where tests are part of the claim. Proof versions are immutable, so the evidence a reviewer accepted is the evidence an auditor later sees. On dilr.ai/cognibl the rule is described from the reviewer's side: a hash fixes the exact files, and editing proof creates the next version.

That gives a simple routing rule for vendor artefacts. Cursor screenshots and Devin recordings go into the proof as referenced documents, graded as output evidence. Copilot session logs stay linked as activity evidence, and commit signatures as provenance. Test output and a coverage report carry the outcome claim, and the same rule applies to a person and to an agent, so contested work cannot be routed to whichever author faces the lighter bar. The two AI flows in Cognibl, proof validation and project status, summarise and flag but never decide. The detail of what a full proof contains lives in our guide to proof of done, and the scheduling case is covered in recurring agent tasks with proof.

What is the best way to evaluate AI coding agent evidence in 2026?

The best way to evaluate AI coding agent evidence in 2026 is to grade every artefact as activity, output or outcome, accept a task as done only on outcome evidence tied to its definition of done, and pin that evidence to the task so it cannot change later. Vendor artefacts from Cursor, Copilot, Codex and Devin make review faster, but they do not decide completion on their own.

The criteria behind that verdict are the ones above: question answered, provenance and stability. On those criteria, a done-gate on the board is the strongest arrangement, because it forces outcome evidence before the status moves and keeps it fixed. That is what Cognibl is built to enforce, for agents working alongside a team on the same board.

There are real cases where a lighter arrangement wins. A small team where every agent pull request already gets a careful human review, branch protection requires that review before merge, and the CI suite was written by people before the agent arrived may get most of the value from vendor artefacts plus discipline, with no extra tool. A team that tracks agent work in Linear, Jira, Asana or ClickUp may also prefer to keep its tracker and tighten its review checklist first, a trade-off we set out in our Linear alternative comparison. The gap opens as agent volume grows and the person accepting the work is no longer the person who read the diff, which is the point where a defined operating model and a governed AI execution office start to pay for themselves.

Frequently asked questions

Is Agent Merge the same as a task being done?

Agent Merge is not the same as a task being done. GitHub describes Agent Merge as Copilot watching a pull request and working on the blockers a person selects: failed GitHub Actions workflows, merge conflicts, or both. Clearing those blockers removes obstacles to merging. Whether the change meets the task's definition of done is a separate question that still needs outcome evidence and a person's decision.

A mergeable pull request is a precondition, not a conclusion. Our review queue guide covers how the merge decision and the done decision divide between people.

Can a screenshot be the proof that a coding task is done in Cognibl?

A screenshot on its own cannot prove a coding task is done in Cognibl. Cognibl, from DILR.AI, refuses a done status until a proof version is attached: a CSV describing the run that references the artefact, screenshots and hashes, plus a coverage report where tests are part of the claim. A screenshot is supporting output evidence inside that proof, not the proof itself.

For a wider view of how the proof rule fits the product, see what Cognibl is, or compare it with a framework-first approach in our LangGraph work layer guide.

Want to see the proof rule on a real board? Explore Cognibl work management, book an AI placement diagnostic, see our DATS methodology, or read about our approach to placing AI inside engineering teams. More strategy guides sit in our AI strategy library, including how a SaaS team builds an AI feature governance harness.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.