Summary: An OpenAI customer story published September 11, 2026 describes Cognition using GPT-6 Astra across Devin, CLI, and desktop tools to test an agent’s own work. The example returns a simulator recording of Otter Run plus a report showing which checks passed and what was untested. The article says this produces review evidence but still requires validation of the tests themselves.
Writing the code is seldom where agentic coding gets stuck. Review is. Once a team turns out more changes than anyone can read line by line, the question stops being “did the agent write this?” and turns into “what proof do we have that it works?”
OpenAI published a customer story on September 11, 2026, describing how Cognition puts GPT-6 Astra to work across its products — Devin, its CLI, and its desktop tools. Raw code generation is not the notable part. What stands out is that the agent gets pointed back at its own output and asked to show that the output runs.
Testing belongs in the agent’s job description
Proof is the lens Cognition co-founder Walden Yan uses for the improvement: Astra can test its own work and show that it behaves as expected. In the published example, Devin takes Astra to Otter Run, an iPhone game, and hands back two things — a recording of the game running in a simulator, and a report that lists which checks passed alongside the areas nobody tested.
The pairing is the point. Behavior comes from the recording; scope comes from the report. A reviewer ends up holding two distinct kinds of evidence: what happened, and what was never examined. That second kind is normally the harder one to pull out of an agent, and it is also the more useful one when the call is whether to trust a change.
A bug report can come back as a screenshot
Customer-reported issues get a faster loop too, according to Cognition. Handed a screenshot of a bug by a customer, the team can pass it to Devin with Astra; the issue gets fixed, and a screenshot showing the result comes back. Yan says the team is able to get back to customers much quicker this way.
The pattern holds across both examples. What the agent delivers is a patch plus something a human can inspect, rather than a patch alone. Anyone building agent workflows can copy that design choice with no new model at all: make the evidence a required companion to the change, and treat it as part of the review surface instead of an afterthought.
What happens to the review queue
Reducing manual code review is how Yan frames the goal: over time, engineers ought to look at less code by hand and ship more. That is a statement about direction rather than a measured outcome, and the material provided carries no figures on review time, defect rates, or how often the agent’s own tests are wrong.
That gap deserves to be named. Until a person or an independent check validates the test itself, an agent testing its own work is grading its own homework. The recording and the report make that validation cheaper; they do not remove it. A team adopting this pattern should settle up front which artifacts count as sufficient evidence, and which changes still need a human to reproduce the result.
Where this sits in a wider trend
Moving from “agent writes code” to “agent demonstrates code” is a concern that runs through review tooling more generally: a reviewer needs a trustworthy loop of diff, execution, and observed output, not a wall of text. That is the thread running through Copilot’s diff, terminal, and browser panels, and it holds just as much when the author is an autonomous agent.
The practical takeaway for builders is narrow, and it can be tested. Choose one workflow where an agent currently hands you a diff and nothing more. Add a requirement that it also produce a runnable demonstration and an explicit list of what it did not verify. Then watch two things — whether review actually takes less time, and whether that untested list turns out to be honest.