HCI OBSERVATORY / INDEPENDENT STUDY
Codex: making agent work legible
Source review and interface reading · revision 2 · draftThe most useful question about an AI coding interface is whether a person can understand where work is happening, what changed, and what to do next. This article combines an official demonstration, another author’s account and related research to examine task review.
Version boundary. The screenshot is a historical baseline, not a verified image of today’s latest build. The model name shown inside it is not the desktop application’s version. Current OpenAI documentation is used separately to check concepts; the review and worktree pages now sit within the ChatGPT desktop documentation. That does not establish that the historical layout remains unchanged. Screenshot source, current review documentation.
A task worth evaluating
Imagine a student asking the agent to add a Chinese homepage to an existing website. Success means finding the correct project, explaining the intended change, inspecting its output, and recovering if an unrelated page was changed. Producing files alone does not complete this task.
The walkthrough to test is: choose project → specify scope → understand execution location → inspect changes → check the page → keep or recover the work. This is a proposed test scenario, not a report of a completed user test.
What the screenshot actually shows
- Persistent task context. A left sidebar separates projects and recent threads. The central area names the selected project.
- Execution choices. Local, Worktree and Cloud appear beneath the composer. They are consequential choices presented in visually quiet text.
- Change-oriented controls. Open, Commit and a change count appear in the upper toolbar. They connect conversation with concrete work, but a count alone does not explain a change.
What other authors and studies add
Author’s account Janine Heinrichs’ dated walkthrough follows a landing-page task through planning and inspection. The screenshot below belongs to her account, not to a user experiment conducted here. Original review.
Related papers Grounded Copilot distinguishes acceleration from exploration; RECAP links conversation with code changes. These inform how a task might be documented. Copilot paper · RECAP. They study Copilot and research tooling, not the current Codex desktop.
Our follow-up: can the interface connect intent, action and verification? The two Codex images differ in date and environment, so layout differences cannot be attributed solely to version changes. Five readings and their scope.
What works well
Interpretation The sidebar gives continuing work a visible home. A returning user can recognise a project or thread instead of rebuilding the context from memory. This supports a useful transition from a one-off prompt to an ongoing task.
The central composer establishes a clear starting action. Its nearby suggested tasks may help a newcomer understand the kinds of requests the tool accepts. Meanwhile, the upper toolbar acknowledges that coding work has an inspectable result outside the conversation.
Current documentation describes worktrees as separate checkouts for independent work, and describes local change review and comparison workflows. These are valuable ingredients for recovery and human inspection. Their existence does not prove that beginners can discover them unaided. Worktrees, code review.
Where the interaction may become difficult
Mode comprehension. A novice may understand the words “local” and “cloud” without understanding which files a choice affects. The screenshot gives the execution choices relatively little visual weight. My hypothesis is that some users could submit a task without being able to explain its destination. This requires testing; it is not evidence of an observed error rate.
Activity versus completion. A busy conversation can show that the agent did many things while leaving the human to reconstruct whether the requested behavior now works. The start screen cannot tell us how well subsequent states communicate progress. A later walkthrough must inspect running, failed, waiting and completed states, not infer them from this image.
Review cost. Change counts invite inspection, but the student’s actual question is more specific: did the Chinese homepage work, and did unrelated pages remain intact? The interface should make it easy to connect a requirement with a changed file and relevant evidence. This is a design criterion, not a claim that current Codex lacks such links.
These judgements draw on visibility of status, recognition, error prevention and user control from Nielsen’s usability heuristics. A compressed promotional screenshot cannot establish keyboard accessibility, focus order or contrast compliance.
A concrete redesign to explore
Add an expandable task review strip beside the composer and result. It would surface the working location, agreed scope, files touched and checks still outstanding. Keep advanced details available on demand so the strip does not compete with the main task.
PROPOSED INTERFACE / ILLUSTRATIVE CONTENT, NOT A PRODUCT SCREENSHOT
Add a Chinese homepage
ScopeImplementationReview
Working location: a separate project checkout
Scope: homepage and navigation translation
Checks: preview and language-switch verification still needed
Inspect changed filesOpen previewView recovery options
The recovery option must explain what it can restore and what it cannot. Stopping an agent, reverting file changes and undoing an external action are different operations. An interface should make that distinction visible before a user relies on it.
How the judgement could be tested
Recruit a small exploratory sample of novice and experienced users; report the actual sample when a study happens. Give each the same prepared website and task. Compare the existing flow with the proposed strip, counterbalancing order and resetting the project between tasks.
Record whether participants identify the execution location correctly, find an unintended change, complete the required homepage change, and recover the prepared file state. Measure time in seconds from task presentation to each milestone; record wrong turns and assistance. A faster submission would not count as an improvement if review or recovery became less reliable.
Current conclusion: the demonstrated structure supports continuing project work and exposes code-oriented actions. The central question for further testing is how clearly it turns agent activity into a result that the human can verify.
Research record
- Revision 1 · 3 October 2026: official screenshot baseline, source checks and heuristic critique added.
- Revision 2 · 3 October 2026: author’s original screenshot, related papers and illustrated readings added; source findings distinguished from our questions.
- Next: inspect a named installed desktop build, capture running/review/recovery states, and record real walkthrough observations.
This AI-assisted draft awaits personal review. Other authors’ research and experiences are credited, not presented as my own testing. Illustrated readings · Study method · Claude study.