An Agent Editor Built to Be Read Twice

Most agent editors are built for a single reader: the person typing. Every design choice flows from that. Collapse the tool calls, auto-apply the edits, keep the momentum going, because the only person who needs to trust the work is the one watching it happen.

An assessment breaks that assumption. Every session in an AlgoArena vibecoding assessment has a second reader, a reviewer who opens the work days later with no candidate in the room to narrate it. Whatever the editor did for speed in the moment has to survive that second reading. A convenience that helps a candidate move faster is only half a feature if it leaves nothing behind for the person deciding what the session means.

That constraint shaped every part of the agent editor we ship inside assessments. Here is how that plays out.

A turn you can read like a story

When an assistant works on a real task, it does several kinds of things in sequence. It thinks. It reads a file. It searches. It edits. It explains. Most chat interfaces flatten that into two piles: prose in a bubble, actions in a collapsed drawer, and one big diff at the end. The order of events, which carries most of the meaning, gets thrown away.

Our timeline keeps the real order. A collapsed "thought for a few seconds" row lands at the point in the reply where the thinking actually happened. A tool step, read this file, searched the workspace, ran the checks, appears between the sentences it interrupted. A diff card shows up at the exact position in the turn where the assistant made that edit, not appended at the bottom. The turn reads as a story: it considered, it looked, it changed something, it explained why.

For the candidate, mid-turn, this kills the wall-of-output problem. You can see where the assistant is and interrupt with a correction while it still matters. For the reviewer, the same ordering is the difference between a log and a narrative. "It searched before it edited" and "it edited before it bothered to look" are different behaviors, and the timeline preserves which one happened.

Every change is a decision

Nothing the assistant proposes mutates the workspace on its own. Each edit arrives as a diff card: added and removed lines with real line numbers on both sides, long unchanged stretches collapsed but one click from expanding, and full hunks, never a summary standing in for the code. Under it, two buttons. Keep. Reject.

It is the same card everywhere the product shows a change, in the chat, in a parallel agent lane, in the recruiter's review. One diff grammar, learned once, read the same way by everyone who ever opens the session.

This is slower than auto-apply, and that is the point. The pause between proposed and kept is where the skill we are measuring lives. A candidate who reads the diff, notices the edge case it fumbles, and rejects it has just produced some of the strongest evidence a session can contain. Auto-apply would have erased that moment before it existed. Shell commands get the same treatment: proposed, shown in full, and approved or declined by the candidate before anything runs.

File operations are events, not side effects

In a daily driver, file operations blur into the background. A file appears, another vanishes, and if you were not watching the tree you would never know. In an assessment, that silence is a hole in the record.

So each operation renders as its own labeled step with a live status. Created a file. Edited a file. Deleted a file. Renamed one. Running, done, or failed, and a failure is a step too, not something swallowed to keep the transcript tidy. A delete is deliberately loud, because a delete should be loud. The rule underneath is simple: the workspace never changes without a visible cause in the transcript. A reviewer can trace any file in the final submission back to the step that created it and the decision that kept it there.

Questions before code

On build tasks the assistant's first move is not code. In plan mode, it opens by describing what is actually in the starter workspace, in plain sentences, so everything that follows is anchored to the files that exist rather than a scaffold it imagined. Then it asks.

The questions are structured, not a vague "any preferences?". Numbered questions, lettered options, single or multi select, always an escape hatch for "something else, let me describe it". When the assistant has a real opinion it marks one option as recommended instead of pretending every choice weighs the same. The candidate answers with a few clicks, adds notes where the options fall short, or skips them entirely and lets the assistant run on defaults. The answers shape the plan, which arrives as its own message, never mixed into the same breath as the questions. Question rounds are bounded, so the flow cannot stall into an interview of its own.

Two people benefit. The candidate gets a plan built on their actual intent instead of a guess. The reviewer gets something rarer: a record of how the candidate handles ambiguity. Which trade-offs they picked, what they wrote in the margins, whether they skipped straight to build. Scoping is a real engineering skill, and plan mode is where it becomes visible.

The preview is evidence, not vibes

For interface work the rendered app is half the deliverable, and "I looked at it and it seemed fine" is not a record anyone can review. So preview validation is structured. A run has a goal and concrete steps: observe, click, type, submit, wait. It can repeat across desktop, tablet, and mobile widths. It records what it found along the way, console errors, rendering problems, snapshots of the page mid-action, rather than reducing everything to a pass or fail.

The whole run is also captured as a scrubbable replay. You watch what actually happened inside the preview, cursor and all, instead of trusting a paragraph about it. The candidate sees the replay immediately after the run. The reviewer sees the same artifact after submission, unchanged.

The most valuable frame is usually the one after the failure. A run that surfaced a broken layout, followed by a targeted fix and a second run that passed, reads completely differently from a single green run nobody inspected. The first is a verification loop. The second is a screenshot of luck.

A small lineup, chosen on purpose

Recruiters sometimes ask why we do not expose every model on the market and let candidates sort it out. The honest answer is that everything above is a contract, and not every assistant honors it. An assistant inside an assessment has to propose diffs instead of overwriting files, wait for command approval, narrate its work in an order the timeline can render, and fail loudly rather than quietly. We verify that behavior before anything joins the lineup.

So the picker holds a small vetted set of assistants with genuinely different strengths, some tuned for fast conversational iteration, some for slower deep reasoning on architecture and debugging. Recruiters choose which of them a given assessment allows. Candidates pick their preferred assistant before the editor opens, and a "no preference, pick for me" option is itself a small piece of signal about how a candidate relates to their tools. Because the whole lineup is vetted against the same contract, whichever assistant a candidate reaches for, the session leaves the same shape of evidence behind.

The same feature, twice

Every section above follows one pattern: build the convenience, then build the reader. The timeline keeps a candidate oriented mid-turn and keeps a reviewer oriented three weeks later. The diff card is a workflow and a receipt. The plan questions produce a better build and a record of judgment. The replay is a debugging aid and a proof.

A daily driver can afford invisible magic, because the only person who has to trust the work is you, tonight. An assessment session is a claim other people will act on: an interview loop, an offer, someone's next job. The evidence is not a tax on the experience. Built right, it is the same feature seen from the other side of the screen.