Shipping a Feature End-to-End With Claude Agents (Eight Trends Software 2026)

Most writing about agentic development stops at the demo: a single prompt produces a working snippet, everyone claps, and the hard part — turning that into a feature that survives contact with a real codebase, real reviewers, and real users — is left as an exercise. This post does the opposite. It walks one feature from a fuzzy request all the way to production using Claude Code, Model Context Protocol, Agent Skills, and an eval gate, narrating the decisions that actually determine whether agentic work ships or stalls.

The feature is deliberately ordinary: add per-customer rate limiting to a public API that currently has none. It is the kind of task every backend team does, complex enough to be real, small enough to follow end to end.

Step one: turning a request into a specification

The request arrives as one sentence from a product lead: "We're getting abused by a few customers hammering the API; can we rate-limit per account?" That is not a spec — it is a direction. The first and most consequential step is human work: turning it into something an agent can execute against and you can verify.

A good engineer here writes down the decisions the sentence leaves open. What is the limit, and is it the same for every plan tier? Is it a fixed window or a sliding/token-bucket scheme? What HTTP status and headers do rejected requests get? Where does the counter live — in-process, Redis, the database? What happens during a Redis outage: fail open or fail closed? These choices have real consequences, and an agent will pick defaults you may not want if you do not specify them.

I settle on: token bucket, per account, limits driven by plan tier, backed by Redis, returning 429 with a Retry-After header, failing open if Redis is unreachable (availability over strictness for this API). That paragraph is the spec. It is also the acceptance criteria, which matters more than the code.

Step two: giving Claude the context it needs

An agent is only as good as the context it operates in. Before asking Claude Code to write anything, I make sure it can see the relevant parts of the system. Our team maintains an Agent Skill that encodes how this service is structured — middleware conventions, how config is loaded per plan tier, our error-response format, and the Redis client wrapper we standardized on. That skill is the difference between Claude inventing a new pattern and Claude following ours.

flowchart TD
  A["One-line request"] --> B["Human writes spec & acceptance criteria"]
  B --> C["Claude loads service skill & reads codebase"]
  C --> D["Claude calls MCP: Redis schema & plan-tier config"]
  D --> E["Agent drafts middleware + tests on a branch"]
  E --> F{"Eval gate: load test & acceptance checks pass?"}
  F -->|No| G["Refine spec, re-run agent"]
  G --> E
  F -->|Yes| H["Human review & merge"]

I also wire in the tools the agent needs through MCP. An MCP server exposes our infrastructure metadata — the Redis connection details for the dev environment and the plan-tier configuration table — so Claude can read real schema instead of guessing. Model Context Protocol is the open standard that lets Claude connect to these external tools and data sources through dedicated servers; pairing it with the skill means Claude both can reach the tools and knows how to use them within our conventions.

Step three: the agent does the work

Now the prompt is simple, because the context is rich: "Implement the rate-limiting middleware per the spec, on a new branch, with unit tests covering the token-bucket logic, plan-tier differences, and the Redis-outage fail-open path."

Claude Code works on an isolated branch — never on main — and produces the middleware, the config wiring, and a test suite. This is where the plan-then-execute discipline pays off: I have it surface the diff and a short summary of design decisions before I let anything merge. Reading that diff, I catch one thing the spec underspecified — the token-bucket refill happens on a fixed schedule rather than continuously, which would let a burst slightly exceed the intended rate. I tighten the spec, the agent revises, and the second diff is right. This back-and-forth is normal and good; the spec is a living document during execution.

Step four: evals as the gate, not the afterthought

Tests written by the same agent that wrote the code are necessary but not sufficient — they can share the agent's blind spots. So the real gate is a separate set of acceptance checks tied to the spec. For rate limiting, that means an actual load test: hammer the endpoint past the configured limit and assert that excess requests get 429s with a correct Retry-After, that different plan tiers get different ceilings, and that killing Redis mid-test causes requests to pass through rather than error.

That last check is the one that catches the failure that would have hurt in production. The first agent implementation failed open in the happy path but threw an unhandled exception on a specific Redis timeout error rather than connection-refused. The eval surfaced it; without the eval, it would have surfaced as a 3 a.m. page during the next Redis blip. This is the core lesson of agentic shipping: as the cost of producing code falls, the value of independent verification rises, and your evals become the thing that earns trust.

Step five: human review and the handoff to production

With evals green, the change comes to me for review the same way a colleague's pull request would — except I am reviewing more code than I wrote, so I spend my attention deliberately. I scrutinize the parts with real blast radius: the fail-open logic, the header math on Retry-After, and whether the per-account key could collide across tenants. The boilerplate I skim; the consequential 5% I read line by line. That allocation of attention is the actual skill of agentic-era review.

The change merges, deploys behind a feature flag, and we watch the metrics: 429 rates per account, p99 latency added by the middleware (a few milliseconds), and Redis error counts. A day later, with the graphs flat and healthy, we remove the flag. Total elapsed time from one-line request to fully shipped, evaluated, monitored feature: under a day, most of it spent on specification and verification rather than typing. That ratio — little time producing, more time defining and checking — is what agentic development actually looks like when it works.

Frequently asked questions

Why spend so much time on the spec if Claude can just write the code?

Because the spec is what you verify against. An agent will happily produce a confident implementation of the wrong thing if you leave the decisions implicit. Time spent pinning down limits, failure behavior, and acceptance criteria up front is what makes the agent's output trustworthy and reviewable rather than a guess you have to reverse-engineer.

Should the agent write its own tests?

It should write unit tests, but those cannot be your only gate — they can inherit the agent's blind spots. Pair them with independent acceptance checks tied to the spec, like a real load test for rate limiting. The independent evals are what catch the failures the agent did not think to test.

Where does MCP fit in a workflow like this?

Model Context Protocol connects Claude to your real tools and data — here, the Redis metadata and plan-tier config — so the agent reads ground truth instead of hallucinating schema. Paired with an Agent Skill that encodes your conventions, MCP gives the agent both reach and the know-how to use that reach correctly.

How much faster is this than writing it by hand?

The code-production phase is dramatically faster, but the spec, review, and eval phases are not — and that is the point. Net, a task like this lands in a fraction of the time, but the time you do spend shifts toward the high-judgment work that humans are uniquely good at.

Bringing agentic AI to your phone lines

This same spec-build-evaluate loop powers agents that talk to people, not just code. CallSphere ships multi-agent voice and chat assistants that answer every call and message, use tools mid-conversation, and book work 24/7 — built and gated with the same end-to-end discipline. See it live at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.