An AI-Native Build, End to End: Ticket to Shipped

Most writing about agentic engineering stays abstract — patterns, principles, architecture diagrams. This post does the opposite. It follows one ordinary feature from a vague ticket to a deployed, monitored change, exactly as it plays out in a team that has gone AI-native with Claude Code. Nothing here is heroic. That is the point. The value of an AI-native org is not the occasional miracle; it is that the boring middle of software work — the wiring, the tests, the docs — collapses from days to hours, and the human time concentrates on the decisions that actually matter.

Our feature: a SaaS product needs to let customers export their invoice history as a CSV. The ticket reads, in full, "Add invoice export. Customers keep asking for it." That is the real starting condition — underspecified, ambiguous, and handed to an engineer who has never touched the billing module.

From a vague ticket to an executable spec

The first move is not to prompt the agent. It is to think. An experienced AI-native engineer knows that a sloppy spec produces a confident, wrong implementation, so they spend ten minutes turning the one-line ticket into something an agent can execute. They decide the scope: export the authenticated user's own invoices, last twelve months by default, as a streamed CSV so large accounts do not blow up memory. They name the constraints: respect the existing permission model, no PII beyond what the user already sees, must paginate the underlying query. They write the acceptance criteria as a couple of failing tests in their head: a user with three invoices gets three rows plus a header; a user with none gets just a header and a 200, not a 500.

Only now do they open Claude Code. They point it at the repo, confirm the CLAUDE.md already documents the auth helper and the billing data model, and give it the spec — not the ticket. The difference between feeding the agent the ticket and feeding it the spec is the difference between forty minutes of back-and-forth and a clean first draft.

Exploration before implementation

The engineer asks Claude to first explore, not to write. "Map how invoices are queried today, where auth is enforced, and where a new export endpoint would fit — do not write code yet." This explore-then-act split is the single most reliable habit in agentic coding. The model reads the relevant files, reports that invoices already have a paginated repository method and that auth is enforced by a middleware decorator, and proposes adding an endpoint that reuses both. The engineer reads this summary and catches one thing the model missed: there is an existing rate limiter on bulk endpoints that the export must opt into. They add that to the context. Cheap correction, made before a single line was written.

flowchart TD
  A["Vague ticket"] --> B["Engineer writes executable spec"]
  B --> C["Claude explores codebase"]
  C --> D{"Plan correct & complete?"}
  D -->|No| E["Fix spec / add missing context"]
  E --> C
  D -->|Yes| F["Claude implements + writes tests"]
  F --> G["Human review & local run"]
  G --> H["Merge, deploy, instrument"]

The loop back from the plan check is where the real savings live. Catching the missing rate limiter at the planning stage costs one sentence. Catching it in production costs an incident.

Implementation and the tests that gate it

With the plan agreed, the engineer lets Claude implement. It adds the endpoint, wires in the existing auth decorator and rate limiter, streams the CSV using the paginated repository method, and — because the spec demanded it — writes tests for the three-invoice case, the zero-invoice case, and an unauthorized request. The whole change lands in a couple of minutes as a single reviewable diff on a branch.

Now the human does the part that does not delegate: review. They read the diff with active suspicion. The streaming logic is correct. The auth decorator is applied. But the engineer notices the CSV writer does not escape commas inside invoice descriptions — a classic generated-code gap, because the model reached for the simplest writer. They flag it, ask Claude to switch to a proper CSV-encoding library, and the model fixes it and adds a test with a comma-laden description. This exchange takes ninety seconds and is exactly the kind of judgment that justifies the human's presence.

Where the human time actually goes

Add up the wall-clock time. The spec took ten minutes. Exploration and the one correction took five. Implementation was a couple of minutes of model time and a few of review. The CSV-escaping catch and fix took two. The feature that, written by hand against an unfamiliar billing module, might have eaten most of a day was substantially done in under an hour — and crucially, the human spent that hour on the decisions and the review, not on remembering the CSV library's API or hand-writing pagination boilerplate.

This is the honest shape of AI-native productivity. It is not that the agent does everything. It is that the agent absorbs the parts that were never the interesting part of the job, and the human's attention concentrates where it has the most leverage: scoping, judgment, and catching the subtle wrong thing.

Shipping and closing the loop

The change merges. Because this team treats every agent-authored change like any other, it goes out behind the normal deploy pipeline, and the engineer adds one thing the model would not think to: a metric. They want to know how often the export is actually used, partly to validate the ticket's claim that "customers keep asking," and partly because an export endpoint that streams large datasets is exactly the kind of thing that can quietly become a performance problem. A single counter and a latency histogram, prompted in seconds, close the loop.

Two weeks later the metric shows the feature is used heavily by exactly the large accounts whose streaming the engineer worried about — and because the histogram was there from day one, when one enormous account does hit a slow path, it shows up as a graph rather than a support ticket. The discipline of instrumenting at ship time, almost free with an agent, pays off.

What this walkthrough teaches

The lesson is not that Claude wrote the feature. It is that the team's process — spec before prompt, explore before implement, review with suspicion, instrument at ship — is what turned a capable model into reliable shipped software. The agent supplied speed. The humans supplied direction and judgment. Remove either and the result degrades: a great model with a sloppy process ships confident bugs, and a great process with no agent ships slowly. AI-native engineering is the marriage of the two.

Frequently asked questions

Why write a spec instead of just prompting the agent directly?

Because the agent will execute whatever you give it, including ambiguity. A vague prompt yields a confident implementation of the wrong thing, and you pay for that in review cycles. Ten minutes of spec work — scope, constraints, acceptance criteria — routinely saves an hour of back-and-forth and produces a clean first draft.

Is the explore-then-implement split really necessary?

For any change in unfamiliar or non-trivial code, yes. Letting the model survey the codebase and propose a plan before writing code surfaces missing context — like the rate limiter in this example — while corrections are still one sentence cheap. Skipping it means catching those gaps in review or production instead.

What did the human contribute that the agent could not?

Three things: turning a vague ticket into a precise spec, catching the subtle CSV-escaping bug that passed a shallow read, and deciding to instrument the endpoint for a performance risk the model had no reason to anticipate. Speed came from Claude; direction, judgment, and ownership came from the human.

Bringing agentic AI to your phone lines

This end-to-end pattern — spec, act, verify, instrument — is exactly how CallSphere builds voice and chat agents that handle real customer work: answering every call, using tools mid-conversation, and booking jobs 24/7 with humans owning the outcomes. 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.