---
title: "The Agent-Native Developer Workflow: What a Day Looks Like When Agents Do the Work"
excerpt: "When agents write most of the code, the developer's day stops being typing and becomes stating intent, reading plans, and reviewing evidence. Here is the actual loop, the four places humans still intervene, what it does to code review, specs and CI, and the parts that genuinely do not work yet."
metaDescription: "The agent-native developer workflow in practice: intent, plan, implement, verify in a browser, covering test, PR. Where humans intervene and what changes in review and CI."
publishedAt: 2026-08-10
updatedAt: 2026-08-10
author: Will
categories:
 - Engineering
 - Guides
 - AI Testing
tags:
 - agent-native
 - agent-native-development
 - ai-coding-agents
 - developer-workflow
 - code-review
 - continuous-integration
 - spec-driven-development
 - verification
metaTitle: "The Agent-Native Developer Workflow: A Practitioner's Guide"
featuredImage: ./cover.png
featuredImageAlt: "Illustrated Shiplight blog cover: a continuous glossy loop from an intent card to an agent core to a browser check to a test file to a pull request, with one human review gate on the final segment."
related:
  - '[What is agent-native?](/blog/what-is-agent-native): the architecture this workflow depends on'
  - '[The AI-native development lifecycle](/blog/ai-native-development-lifecycle): the same shift mapped stage by stage against the traditional SDLC'
  - '[Verification-driven development](/blog/verification-driven-development): letting an exercised check gate the merge'
---

The interesting change is not that agents write code faster. That part is settled and everybody has felt it. The change worth planning around is what happens to the eight hours around it: which decisions you still make, which ones you have delegated without deciding to, and where your attention has to be for the output to be worth anything.

This is the loop as it actually runs on teams that have made the shift, including the parts that are still awkward.

## The loop, in one pass

Six steps. The names matter less than which ones you are currently skipping.

**1. Intent in.** The unit of work is a statement of what should be true when this is done, not a list of files to change. "Users on the free plan should see a usage meter in the account header, and it should show remaining credit, not spend." Vague intent is the single largest cause of a wasted agent run, and it is cheap to fix by writing two more sentences.

**2. Plan first.** The agent reads the relevant code and produces a plan: files it intends to touch, the approach, what it is unsure about. This is the cheapest place in the entire loop for a human to intervene, because a plan is two hundred words and a wrong implementation is four hundred lines plus the time to read them. Teams that skip the plan step spend the savings on review.

**3. Implement.** The agent writes the code, taking anywhere from a minute to half an hour. This is the step people expect to supervise and should not: watching a diff scroll past teaches nothing that reading the finished diff does not, and it burns attention you need later.

**4. Verify against the running application.** The agent opens a browser, drives the flow it just changed, and looks at what happened. Most teams skip this, which is why agent output has a reputation for being confidently broken. An agent that has only read its own diff is reasoning about what the code should render. An agent that has loaded the page knows whether the meter shows remaining credit or spend, and whether the console filled with errors on the way.

**5. Write the covering test.** The verification the agent just performed becomes a durable check. This is the cheapest moment in the feature's life to write that test, because the agent still holds the context: the flow, the states it had to set up, the edge case it hit at step three. An hour later that context is gone and writing the test is a research project.

**6. Open the pull request.** The agent pushes a branch and opens a PR with the intent it was given, the plan it followed, what it verified, and the evidence. A human reads it and merges. The agent does not merge, and that is not a temporary limitation to be relaxed later, it is the gate.

## Where humans actually intervene

Four places, in descending order of value.

**At intent.** Nothing downstream recovers from a badly stated goal. The agent will build the wrong thing well, and you will not notice until review, when the wrongness is buried in code that looks fine. Time spent here returns more than time spent anywhere else in the loop.

**At the plan, when the work is ambiguous or expensive.** Not every task needs plan approval. A copy change does not. Anything touching a data model, an auth path, a payment flow, or more than a handful of files does, because those are the runs where an agent's reasonable-sounding wrong turn costs an hour to unwind.

**When the agent starts looping.** Every practitioner learns this signal: the third attempt at the same fix, the growing wall of defensive conditionals, the test being adjusted to accommodate the failure. It means the agent is missing a fact that nobody gave it. Stopping it and supplying the fact takes ninety seconds. Letting it continue produces code you will have to delete.

**At the pull request.** The real gate, covered below.

There is also an intervention to stop: reading the implementation in real time. It feels productive because it looks like pairing, but the agent is not waiting for you, and it consumes the same attention you need for review, where it is worth far more.

## What changes about code review

Review is where the workflow either holds or quietly fails, and it is the practice that needs the most redesign.

**Volume breaks the old method.** Line-by-line reading of every diff worked when a developer produced a few hundred lines a day. It does not survive several times that. What replaces it is not looser review but differently targeted review: read the intent, the interface, and the parts where a mistake is expensive, then rely on exercised checks for the rest. That reliance is only honest if the checks ran against the running application, which is why step four is load-bearing.

**"Did it verify?" becomes a review question.** A PR that says "changed the header component" and a PR that says "changed the header component, drove the free-plan account through the dashboard, meter renders 40 credits remaining, console clean, here is the recording" cost the same to produce and are not remotely the same artefact. Teams that make evidence a required section in the PR template get it, and teams that do not, do not.

**Review the test as carefully as the code.** An agent that writes both the change and its test can produce a test that passes because it asserts the behaviour that exists rather than the behaviour that was wanted. Reading the test against the original intent, rather than against the diff, catches this. It is the highest-value ten seconds in an agent-written PR.

**PRs get smaller, deliberately.** An agent PR is as large as whatever you asked for, and it is easy to ask for too much. A three-file PR reviewed properly beats a thirty-file PR skimmed.

## What changes about specs

The durable artefact moves. When code is expensive to write, code is what you protect. When an agent can regenerate a module from a clear description in twenty minutes, the description is the asset and the code is downstream of it.

Practically, intent gets written down somewhere permanent rather than living in a chat thread, because the next agent run needs it. Decisions that used to be tribal ("we never call that service directly from the web tier") get recorded where the agent reads them, since an agent cannot absorb a convention by osmosis in a hallway. And tests start doing double duty: a readable end-to-end test is the only description of intended behaviour that gets checked automatically on every change, which makes it worth writing in language a product manager could read.

None of this requires a formal methodology. It requires that the things your team knows stop being unwritten. See [spec-driven development with coding agents](/blog/spec-driven-development-ai-coding-agents) for the fuller treatment.

## What changes about CI

CI stops being only a gate and becomes the agent's feedback loop, which changes what a good pipeline looks like.

**Failure output has to be readable by a machine.** A red X and a 4,000-line log is a puzzle for a human on Monday morning. For an agent it is a context-window problem it will solve badly. The pipeline should emit which check failed, on which step, with the observed and expected states, and a path to the evidence. That is a formatting decision, and it determines whether an agent can fix its own failure or merely notice it.

**Time to first signal matters more than total runtime.** If the agent will act on the result, a signal in four minutes covering the changed area beats a complete suite in forty. Most teams end up with two speeds: a fast set on every push, the full set nightly and before release.

**Flakiness gets more expensive.** A human learns to ignore the test that fails one run in six. An agent takes it at face value and starts fixing code that was never broken, or adjusts the test. Quarantine and fix flaky tests aggressively: in an agent workflow they are an active source of wrong work, not an annoyance.

**Triage becomes a defined step.** When a check fails, something has to answer "is this the application, the test, the environment, or the data?" before anything gets fixed. That used to be a senior engineer's intuition at 9am. It is the most automatable part of the loop and the part most teams have not automated.

## A realistic day

Not a demo. A Tuesday.

You arrive to a branch an agent worked on overnight and to two failures from the nightly suite. The first twenty minutes go to triage: one failure is a real regression in the invite flow, the other is an expired fixture. You point an agent at both, with a sentence of context for each.

Mid-morning is the main piece of work. You write the intent for a billing change, ask for a plan, and read it. The plan puts the credit calculation in the web tier, which is wrong; you say so in one line and it replans. Then you leave it alone for twenty-five minutes and review something else. It comes back with a diff, a browser recording of the free-plan and pro-plan paths, and a new end-to-end test. You read the test first, against your original intent, and find that it asserts the meter is visible without asserting the number. You ask for the assertion, get it, and merge.

The afternoon is mostly review of other people's agent-written PRs, plus one change you write by hand because being exactly right there matters more than being fast. That is a normal outcome, not a failure of the workflow.

What changed is not the total hours. It is that four of them are now reading rather than typing, and the reading carries more consequence than it used to.

## What does not work yet

Being honest here is the difference between a workflow and a pitch.

**Long-horizon work across many files still degrades.** Agents do well on tasks scoped to a comprehensible slice of a system. Cross-cutting refactors touching forty files remain a coin flip, and the failure mode is a plausible, internally consistent change that is wrong in a way that takes longer to find than the work would have taken by hand.

**Agents cannot judge product intent.** They will implement exactly what you said, including the parts you did not mean. There is no substitute for the human deciding what should be true.

**Verification beyond the visible is immature.** Driving a UI and reading the page is solid. Confirming that the right row was written and the webhook fired is harder to arrange, and plenty of real bugs live exactly there.

**Review fatigue is real and underdiscussed.** Reading twelve agent PRs a day is more tiring than reading three human ones, and attention quality drops in a way that stays invisible until something ships broken. Teams handle it with smaller PRs, mandatory evidence in the description, and by capping how much any one person reviews in a day.

**Agents optimise for the check.** Given a failing test and no supervision, an agent's shortest path is sometimes to change the test. The guard is structural: the artefact that judges the work should not be authored in the same unsupervised pass as the work, and a human should read both against the intent.

**Cost visibility is still rough.** Knowing what a feature cost in model spend, and which run burned it, is not yet routine tooling on most teams.

## Where a testing layer fits

The step most often skipped is verification against the running application, and it is skipped because it is the only step needing capability the agent does not have by default. A coding agent can read, write, and run commands out of the box. It cannot see a page.

This is the gap Shiplight fills. It installs into the coding agent as a browser MCP server plus skills, so the agent can drive the real application, confirm what a change actually did, and turn that verification into an end-to-end test written as readable YAML in your own repository. When a test later fails, the agent reproduces it, diagnoses whether the application or the test is at fault, and proposes the fix as a pull request you merge. Authoring runs through the coding agent's own subscription and needs no Shiplight account; running a test file needs a model key, ours or your own.

The point is not the tool. It is that steps four and five have to happen somehow, and a workflow that leaves them out produces pull requests whose confidence is unearned.

## FAQ

### What is the agent-native developer workflow?

A loop where the developer states intent, the agent plans and implements, verifies the change against the running application, writes the covering test, and opens a pull request that a human reviews and merges. The human's work shifts from typing to specifying and reviewing, and the agent never merges its own work.

### Where should a human step in?

At intent, at the plan for anything ambiguous or expensive, the moment the agent starts looping on the same fix, and at the pull request. Watching the implementation happen in real time is the intervention to drop, since it consumes the attention that review needs.

### How does code review change?

Volume makes line-by-line reading of every diff impractical, so review targets intent, interfaces, and the expensive-to-get-wrong parts, backed by checks that actually ran against the application. Read the test against the original intent rather than against the diff, which is where agent-written tests most often go wrong.

### Do we still need CI if the agent verifies its own work?

Yes, and its job grows. CI is now the agent's feedback loop as well as a gate, which means failure output has to be machine-readable and fast enough to act on. Flaky tests also get more costly, because an agent treats a false failure as real and starts fixing working code.

### What still does not work well?

Cross-cutting refactors over many files, judging product intent, and verifying state that is not visible in the UI such as database writes and queued jobs. Review fatigue is a real constraint at volume, and per-feature cost visibility is still missing from most toolchains.