The New Development Loop: Spec, Agent, Review, Evaluate

A practical operating model for building software with coding agents while keeping product intent, review, and evidence under human control.

The classic development loop is familiar:

  1. Understand the ticket.
  2. Write code.
  3. Run tests.
  4. Open a pull request.
  5. Review and ship.

Coding agents do not eliminate that loop. They change its center of gravity.

When an agent can inspect a repository, edit many files, run commands, and iterate on failures, implementation becomes cheaper and faster. The scarce work moves toward specifying the outcome, controlling context, reviewing decisions, and evaluating behavior.

The loop I now find most useful is:

spec → agent → review → evaluate → release → observe

This is not a waterfall process. It is a short cycle that repeats at different scales—from one bug fix to an entire feature.

1. Spec: Define the Change Before the Code

“Build an onboarding flow” is a direction, not a specification.

An implementation-ready spec answers the questions that would materially change the solution:

  • Who is the user and what are they trying to achieve?
  • What is the current behavior?
  • What should be true afterward?
  • Which states and edge cases matter?
  • What is explicitly out of scope?
  • Which interfaces or data contracts may change?
  • What evidence will prove the work is complete?

The spec should describe intent and constraints without dictating every line. If it is too vague, the agent must guess. If it is a transcript of the desired diff, you lose the value of repository exploration.

For example:

Allow a workspace owner to archive a project. Archived projects remain readable through existing links but cannot be edited. They disappear from the default project list and can be restored from an archive view. Existing permissions remain unchanged. Add coverage for archive, read-only access, restore, and unauthorized attempts.

That is enough for an agent to explore data ownership and propose an approach. It also gives reviewers a stable definition of success.

2. Agent: Execute Inside Clear Boundaries

The agent’s job begins with discovery.

It should identify the relevant routes, components, types, schema, tests, and conventions before editing. In a mature repository, the correct solution is often shaped by patterns already present. A new abstraction may be less appropriate than extending an existing one.

Then the agent can plan and implement:

  • update the smallest correct set of interfaces;
  • preserve unrelated behavior;
  • add validation and failure handling;
  • write or update tests;
  • run targeted checks during iteration;
  • and run broader verification when the change stabilizes.

Boundaries matter. The agent should know whether it may install dependencies, change schemas, run migrations, access the network, or touch external systems. These are not details to improvise after work begins.

A strong execution prompt makes “done” observable:

Implement the approved plan. Preserve current public behavior outside the archive flow. Add tests for the acceptance scenarios, run type checking and the relevant test suite, then review the diff for unrelated changes. Stop and report if the schema requires a destructive migration.

The agent now has both autonomy and a fence.

3. Review: Inspect the Decisions, Not the Typing

Agent-generated code can look polished even when the underlying decision is wrong. Review therefore needs to begin above the line level.

Product review

Does the behavior match the spec? Are empty, loading, unauthorized, error, and recovery states appropriate? Did the implementation quietly add or omit product behavior?

Architecture review

Is the decision implemented in the correct layer? Does it reuse existing patterns? Did the change introduce duplicated state or a new abstraction the codebase does not need?

Contract review

Check API shapes, schemas, events, permissions, caching, and compatibility. A tiny type change can affect more consumers than a large internal refactor.

Risk review

Look for data loss, authorization gaps, race conditions, unsafe external actions, and failure behavior. Ask what happens halfway through the operation, not only when everything succeeds.

Diff review

Finally inspect the code: clarity, naming, duplication, error handling, test quality, and unrelated churn.

This order matters. Perfectly formatted code implementing the wrong behavior is still wrong.

4. Evaluate: Prove the Result at the Right Layer

Evaluation is broader than running unit tests.

For deterministic software, evidence can include:

  • unit and integration tests;
  • type checking;
  • linting;
  • a production build;
  • migration validation;
  • performance checks;
  • visual inspection;
  • and manual acceptance scenarios.

For AI features, add behavioral evaluations:

  • representative datasets;
  • groundedness or correctness rubrics;
  • tool-use assertions;
  • human review;
  • latency, token, and cost budgets;
  • and regression cases from production traces.

The evidence should match the risk. A CSS spacing change needs a visual check, not a new distributed test environment. An authorization change needs negative tests. A prompt change needs more than a screenshot of one good answer.

“Tests passed” is only useful when the tests cover the contract we care about.

5. Release: Make the Change Identifiable and Reversible

A good implementation can still fail during rollout.

Before releasing, decide how the change will be identified in production and what would trigger a rollback. For an application feature, that may mean a feature flag, release version, or controlled migration. For an AI feature, record the prompt, model, evaluator, and experiment versions on each trace.

Reversibility changes how safely a team can move. A prompt version that can be rolled back independently is easier to release than one embedded in an unrelated application deployment. A schema migration with a tested backward path is safer than an irreversible transformation bundled with UI work.

Not every change needs a staged rollout. The process should be proportional, not ceremonial. But high-impact changes should not rely on “we can probably fix it quickly.”

6. Observe: Let Production Improve the Next Spec

The loop does not end at deployment.

Observe the signals that correspond to the intended outcome. If the goal was reducing onboarding abandonment, watch completion and error paths—not only server uptime. If the goal was improving an AI assistant’s groundedness, evaluate production traces by prompt version and user cohort.

When reality reveals a missed case, feed it back:

  1. Preserve the failure with the context required to understand it.
  2. Decide whether the problem is in the spec, implementation, or evaluation.
  3. Add a regression test or eval.
  4. Update durable repository guidance if the mistake is likely to repeat.
  5. Begin the next small cycle.

This turns production from a place where surprises happen into a source of better specifications.

Humans Own the Irreversible Decisions

The agent can propose architecture, create migrations, run tests, and analyze a diff. Human attention should concentrate where context, accountability, and consequences are greatest.

That includes:

  • product tradeoffs;
  • public API and data-model decisions;
  • privacy and security boundaries;
  • destructive operations;
  • production releases;
  • and acceptance of known risk.

This is not because agents are incapable of useful reasoning. It is because these decisions depend on organizational intent and accountability that cannot be inferred from the repository alone.

The clean division is not “humans think, agents type.” Agents can reason and humans can code. The division is that humans own intent and consequence, while agents can accelerate exploration, implementation, and verification inside that intent.

The Repository Becomes an Agent Interface

Agentic development rewards repositories that explain themselves.

Useful ingredients include:

  • a concise AGENTS.md with commands, conventions, and boundaries;
  • fast, reliable tests;
  • clear types and schemas;
  • local setup that actually works;
  • architectural documentation near the code it describes;
  • representative fixtures;
  • and observable production behavior.

These practices already help human developers. Agents make their value more obvious because missing context immediately turns into wrong assumptions or extra review work.

When the repository captures how the team works, every prompt can focus on the unique part of the task.

Avoid the Two Extremes

One extreme treats the agent as autocomplete: tightly prescribe every edit, then manually perform most of the workflow. This leaves much of the leverage unused.

The other extreme treats the agent as an unaccountable replacement team: give it a vague goal, broad permissions, and accept whatever passes a shallow check. This creates velocity without control.

The useful middle is constrained autonomy:

  • a clear outcome;
  • enough context to explore;
  • explicit boundaries;
  • permission to iterate;
  • and evidence-based review.

The agent gets room to solve the problem. The team retains control over what problem is being solved and what proof is required.

A Better Measure of Productivity

Lines of code were never a good measure of engineering productivity. Agent-generated lines make that even clearer.

The output that matters is a verified improvement in the product: a bug that no longer reproduces, a workflow users can complete, a safer authorization boundary, a faster system, or an AI response that performs better on real cases.

The new development loop optimizes for that unit:

specify the outcome, let the agent execute, review the decisions, evaluate the evidence, release reversibly, and learn from production.

The code is part of the work. It is no longer the whole shape of the work.