Shipping a Claude Code Project to Production

Projects built with a terminal agent arrive in much better shape than projects built in a hosted builder. There is a real repository, real commits, a real package manifest, and a stack somebody could have chosen deliberately. Nothing has to be extracted from anywhere.

That head start hides a different problem. The output volume is high enough that nobody read most of it. Six weeks of enthusiastic agent work can produce more code than a two-person team writes in a quarter, and it all got merged because it ran.

The gap between a Claude Code project and a production system is therefore not a translation problem. It is a review problem, an invariants problem, and an operations problem — in that order.

Use the git history, because you have one

This is the advantage agent-built repos have over builder-built ones, and almost nobody uses it.

Run a diff summary across the last month and look at which files changed most. The hotspots are where the agent kept re-attempting something, and re-attempted code is where the bugs live. Look at commit sizes: a 4,000-line commit is one nobody reviewed, and that is where to start reading. Look at commits that touch a migration and application code together — those are the ones that will not roll back cleanly.

Ten minutes of history archaeology tells you where to spend the next three days. A hosted builder gives you none of this.

Failure mode one: volume outran review

An agent that can implement a feature in eleven minutes will implement eleven features before anyone asks whether the third one was necessary. The result is a codebase larger than the product justifies, with utilities nothing imports, abstractions with one caller, and two half-finished attempts at the same subsystem.

The fix is subtraction before addition. Find dead exports and unreferenced files and delete them. Delete the abandoned first attempt at the thing that got rewritten. Every file you remove is a file nobody has to read, secure, or keep working — and in an inherited codebase that is the highest-leverage hour you will spend. Refactoring AI-generated code without breaking it covers doing this safely.

Failure mode two: a test suite that cannot fail

Agents are excellent at producing tests. They are much less good at producing tests that would notice a bug.

The pattern is consistent: the dependency under test is mocked, the mock returns exactly what the assertion expects, and the test verifies that the mock was called. It passes. It will pass after you delete the function's body. A suite full of these is worse than no suite, because it produces confidence in proportion to its uselessness.

Audit it with one crude technique: break something on purpose. Comment out a validation check, change a comparison operator, return null from a service call. If the suite stays green, you have documentation, not tests. Then rebuild coverage where it matters — auth decisions, money, and data integrity — as described in adding tests to a codebase you did not write.

Failure mode three: three ways to do the same thing

Each session starts with whatever context it can gather. Across dozens of sessions over weeks, that produces divergence that no single diff reveals.

You end up with three HTTP clients, two date libraries, error handling that throws in some modules and returns result objects in others, and two competing notions of what a User is. Every one of those decisions looked reasonable in the session that made it.

Pick the winner for each and converge. Write the convention down in the repository — an agent instructions file, a short conventions document, whatever your tool reads — because that file is the only mechanism by which future sessions inherit your decisions. Left undocumented, the drift resumes the next time you open the terminal.

What to check, and where

The secrets row deserves emphasis. GitGuardian counted 28.65 million new hardcoded secrets in public GitHub commits during 2025, up 34% year over year, with AI-assisted commits leaking at roughly 3.2% versus a 1.5% baseline. Deleting a key from the current file does nothing — it is still in the history, and rotation is the only real remedy. Finding every secret an AI left in your repo covers scanning and rotation properly.

The dependency row matters too: the Cloud Security Alliance found roughly 19.7% of 2.23 million AI-generated code samples referenced package names that do not exist, which is precisely the gap slopsquatters aim at. Read the lock file diff like a changelog and verify anything you do not recognise, using auditing the dependencies an AI chose for you as the procedure.

The hardening pass, in order

1. Rotate and scan. Every credential the repo ever held. Do this first because it is the only irreversible risk.
2. Establish the authorization boundary. One place that answers "may this caller do this to this record", called by every mutation. Not the UI.
3. Validate input at the server edge. Parse with a schema; do not trust TypeScript types, which vanish at runtime.
4. Put constraints in the database. Unique keys, not-null, foreign keys, checks. Application-level validation alone will not survive the first concurrent request.
5. Make failure visible. Structured logs with request identifiers, error tracking, and alerts on the two or three things that mean the product is down. Logging you can actually search at 2am is the standard to hit.
6. Build a pipeline. Tests, type check, and lint on every pull request, deploying to staging before production. Once that exists, agent-written changes can be merged with a real gate in front of them, which is the whole idea behind a code review workflow for teams shipping AI-written code.

Keep the agent, change the rules

None of this argues for writing everything by hand. Roughly 46% of new code shipped in 2026 is AI-generated, and refusing that is a productivity decision, not a safety one.

What changes is the frame around it. Small scoped tasks instead of "build the billing system". Branches and pull requests instead of commits straight to main. A test suite the agent must not weaken to make green. Conventions written into the repository so each session starts from your decisions rather than its own. The agent is a fast, tireless implementer with no memory and no stake in the outcome — the guard rails are your contribution. Agentic IDEs fail differently than app builders covers why this class of tool needs a different kind of supervision, and Cursor versus Claude Code compares the two workflows.

Frequently asked questions

Is agent-written code worse than hand-written code? Not line by line — it is usually cleaner and more consistently formatted than what a rushed human produces. The difference is what is absent. Agents optimise for the task in front of them, so the invariants nobody asked about, the failure paths nobody described, and the abuse cases nobody mentioned simply do not appear.

How much of the codebase do I need to read before launching? Not all of it. Read every path that touches authentication, authorization, payments, and personal data, in full. Skim the rest by module and check that each has an owner-shaped story. That is typically 15% of the code and it covers the failures that end companies.

Can I have the agent do the hardening pass? For the mechanical parts, yes — adding validation schemas, converting console logs to structured logging, writing migrations. What it cannot do is decide what your invariants are or notice what it never considered. Direct it item by item from a list a human produced, and review each change. An agent auditing its own output reliably reports that everything is fine.

---

You have a large repository, real momentum, and no idea which parts have been read by a human. SprintX reviews and hardens agent-built codebases — authorization, tests that can fail, and a deploy pipeline — without slowing your build loop down. Send us your repo and we will tell you what stands between it and production.