Inheriting an AI-Built Backend Service: A Field Guide for the Engineer Who Didn’t Write It

You get repo access and a one-line summary: “mostly done, just needs a second pair of eyes.” The service layer looks clean — consistent names, green CI. Ask who owns the payment retry logic and you get a shrug. An agent wrote it, across eleven prompts and three sessions, and the person driving those sessions is on another team now. No witness. Just a git log with nothing behind it.

Why Ownership Is a Different Job Than Review

A PR review asks one question: does this change make sense. Owning a service asks a harder one: can you explain, six months from now, why every part of it exists. A codebase can pass the first question a hundred times and still fail the second completely.

Two mechanics make an agent-built handoff worse than an ordinary one.

There’s no single mind behind it. A service one person wrote badly still has a coherent — if flawed — worldview you can reconstruct. A service assembled across a dozen agent sessions doesn’t. Each session solved its own narrow prompt and moved on, leaving you a patchwork of locally sound decisions with nothing tying them together.

Speed compressed the review that should have caught this. I’ve watched four hundred lines of new concurrency code get approved with a comment about a variable name — not from carelessness, but because nobody had the hours to read at the speed the code arrived.

The Cleaner-Boundaries Myth

Here’s a claim you’ll hear a lot, and it’s only half true: that agent-built services have cleaner module boundaries than old human codebases, so they’re easier to retrofit. Sometimes. On a greenfield service written in one long session, sure — the agent had the whole thing in view and kept it coherent.

But stitch a service together across separate sessions and you get the opposite of clean boundaries. You get implicit coupling that doesn’t show up in any dependency graph, because it isn’t wired through function calls — it’s wired through a shared database table that two modules both quietly assume they own. Session four reimplements a validation rule that session one already wrote, slightly differently, because it never saw session one’s code and had no reason to look for it. Nothing about this shows up as an import. It shows up three weeks later, when one path allows a value the other path rejects, and the discrepancy has been silently corrupting rows since the day both shipped.

Treat “the boundaries look clean” as a hypothesis to test, not a fact you inherit for free. Grep for the same business rule implemented more than once under different names — a discount cap, a status transition, a validation range — before you trust any diagram the repo structure suggests.

Three Failure Patterns a Rushed Review Never Catches

Decisions Nobody Flagged as Decisions

A function does something specific and you can’t tell if it’s a deliberate rule or a plausible guess. I once burned half a day proving a hardcoded 40% discount-stacking cap was a real rule from a deleted spec doc, not an invention. Nothing in the code told me which. Treat every unexplained boundary as unverified until something outside the code confirms it.

Seams Between Sessions That Never Got Reconciled

One session assumes a timestamp is UTC. A different session, weeks later, assumes local time, because the first convention wasn’t in the second prompt’s context at all. Nothing breaks in dev. It breaks once, in production, during a daylight-saving transition, after everyone who could explain either assumption has left.

Errors That Vanish Instead of Surfacing

A catch block that logs and swallows an exception looks identical, in a diff, to one that logs and correctly re-raises it — until the first one starts eating errors that should have paged somebody. This survives a fast read cleanest, because “nothing crashed” reads as success to anyone skimming.

The Blind Spot Almost Everyone Skips: Races and Broken Transactions

Concurrency bugs in application code get talked about constantly. What gets skipped, almost every time, is that the highest-frequency failure agents produce isn’t in your Go or Kotlin — it’s in how they touch the database. Ask an agent to “update the account balance after a withdrawal” and it will very often hand you a read, a calculation, and a write, done as three separate steps with nothing holding them together. That’s not a hypothetical. It’s close to the default output.

-- Before — read-modify-write with no isolation, classic lost-update race
SELECT balance FROM accounts WHERE id = $1;
-- application computes new_balance = balance - amount
UPDATE accounts SET balance = $2 WHERE id = $1;

-- After — atomic at the database level, no race window at all
UPDATE accounts
SET balance = balance - $2
WHERE id = $1 AND balance >= $2;
-- check rows affected; zero means insufficient funds, handled without a race

Two withdrawals hitting that first version within the same few milliseconds will both read the same starting balance and both succeed, and now you’re short money that only shows up in a reconciliation report weeks later. This is invisible to code review because every individual line is correct SQL. It’s invisible to your test suite because a single-threaded test never triggers the race. It only shows up under real concurrent load, which is exactly the condition an agent’s local test run never had.

The second pattern is multi-step business operations with no transaction boundary at all — write an order, then write an inventory decrement, then write a payment record, as three independent statements. An agent asked to “process the order” will happily generate exactly that, because each individual write works and nothing in the prompt said “and if step two fails, undo step one.” Wrap it, or don’t ship it:

BEGIN;
  INSERT INTO orders (...) VALUES (...);
  UPDATE inventory SET quantity = quantity - $1 WHERE sku = $2 AND quantity >= $1;
  INSERT INTO payments (...) VALUES (...);
COMMIT;
-- any failure rolls the whole operation back — no orphaned order, no phantom stock

Audit every multi-table write path in the codebase for a transaction boundary before you audit anything else. This category alone causes more silent data corruption than every goroutine leak and every unsafe block combined, and it’s the one nobody thinks to grep for because it doesn’t look like a concurrency bug in the diff — it looks like three lines of perfectly reasonable SQL.

Where Language-Level Bugs Cluster

Once the data layer is covered, the concurrency bugs that remain are real but smaller in blast radius — and they cluster by language in predictable ways.

Go: Goroutines That Outlive the Request

// Before — no ctx propagation, leaks on timeout
func fetchAll(ids []string) []Result {
    results := make(chan Result, len(ids))
    for _, id := range ids {
        go func(id string) { results <- fetchOne(id) }(id)
    }
    var out []Result
    for range ids { out = append(out, <-results) }
    return out
}

// After — bound to the caller's context, exits cleanly on cancellation
func fetchAll(ctx context.Context, ids []string) ([]Result, error) {
    results := make(chan Result, len(ids))
    for _, id := range ids {
        go func(id string) {
            select {
            case results <- fetchOne(ctx, id):
            case <-ctx.Done():
            }
        }(id)
    }
    var out []Result
    for range ids {
        select {
        case r := <-results:
            out = append(out, r)
        case <-ctx.Done():
            return out, ctx.Err()
        }
    }
    return out, nil
}

Grep for goroutines with no context.Context nearby. Rising memory under sustained load that your request volume doesn’t explain almost always traces back here.

Kotlin: GlobalScope Standing In for Structured Concurrency

// Before — outlives the caller, cancels nothing
fun syncUserData(userId: String) {
    GlobalScope.launch {
        val data = repository.fetch(userId)
        cache.update(userId, data)
    }
}

// After — scoped to the caller, cancels with it
suspend fun syncUserData(userId: String) = coroutineScope {
    val data = repository.fetch(userId)
    cache.update(userId, data)
}

Every GlobalScope hit is a coroutine that survives whatever created it — a slow leak with your name on it now.

Python: async def Wrapping a Blocking Call

# Before — blocks the event loop
async def get_profile(user_id: str):
    response = requests.get(f"https://api.internal/users/{user_id}")
    return response.json()

# After — genuinely non-blocking
async def get_profile(user_id: str):
    async with httpx.AsyncClient() as client:
        response = await client.get(f"https://api.internal/users/{user_id}")
        return response.json()

Works fine at low concurrency, falls over exactly when traffic justifies async in the first place — during a load spike, not during review.

Rust: Escaping the Borrow Checker Instead of Satisfying It

// Before — clones to dodge a lifetime argument
fn process(items: Vec) -> Vec {
    let snapshot = items.clone();
    snapshot.into_iter().filter(|i| i.valid).collect()
}

// After — no clone needed once ownership is threaded correctly
fn process(items: Vec) -> Vec {
    items.into_iter().filter(|i| i.valid).collect()
}

A cluster of unsafe blocks or .clone() calls in a module with no obvious reason to need either means the agent fought the borrow checker and lost, quietly, on your behalf.

Before You Sign Off on Ownership

• Audit every multi-table write path for a missing transaction boundary — do this first, not last
• Grep for the same business rule implemented more than once under different names
• Run the language-specific greps above across the full repository, not just the files you’re touching
• Count how many tests assert an actual outcome versus how many only assert that nothing threw
• Trace error paths for exceptions that get logged and dropped instead of propagated
• Look for timezone, locale, or unit mismatches between modules built in separate sessions
• Identify every module with zero human-reviewed commits and start there, not last

Track the Trend, Not the Snapshot

One audit pass tells you what’s wrong today. Watch three numbers for your first month of ownership instead. Churn — how much of what you touch gets reverted within two weeks; high churn on inherited code means the audit missed something structural. Escape rate — defects reaching a later environment, tracked separately for untouched agent-original modules versus the ones you’ve reworked. Rework ratio — time fixing this service against time shipping anything new in it. Climbing a month in, not flattening, means you’re not done auditing — you’ve just gotten used to the fires.

Retrofit the Parts Actually Worth Saving

The instinct after a rough audit is to propose a rewrite. Resist it as a first move, but don’t oversell the alternative either — retrofit only what genuinely has a defensible boundary once you’ve tested that boundary for the hidden coupling above. Pick the riskiest module, put an interface in front of it, replace what’s behind it in isolation, and shift traffic gradually. That proves the approach on the worst case before you bet the whole service on it. For modules where the audit finds coupling baked into a shared table rather than a clean interface, stop pretending retrofit is cheap — that’s a rewrite candidate, and the sooner you call it, the less time you waste polishing something structurally unfixable.

A Senior Take, From Someone Who’s Been on Both Sides of This

I’ve shipped agent-built services and I’ve inherited them, and the honest take is this: the code isn’t the scary part. Code is legible if you’re willing to sit with it. What’s scary is that an agent will never once tell you it’s unsure — it commits to a read-modify-write race with exactly the same confidence it commits to a correct one, because confidence isn’t a signal it computes at all. A junior engineer eventually learns to say “I’m not sure this is safe under load.” An agent doesn’t have that instinct, and won’t develop one, because it’s not reasoning about your production traffic — it’s predicting plausible text. Own that gap explicitly instead of assuming the tooling closed it, and this stops being a horror story and starts being just another Tuesday.

FAQ

What makes inheriting an AI-built service different from a normal handoff?

There’s no person to ask why a decision was made. A prompt history is rarely preserved anywhere you can reach once the PR has merged, so the reasoning behind non-obvious code simply isn’t recoverable the way it is with a human predecessor.

What’s the most common bug category in AI-generated backend code?

Data-layer races and missing transaction boundaries — read-modify-write sequences with no isolation, and multi-table writes with nothing rolling them back on partial failure. These cause more silent corruption than language-level concurrency bugs and are far less likely to get caught in review because each line of SQL looks correct on its own.

Are AI-generated codebases really easier to retrofit because of cleaner module boundaries?

Only sometimes. A service built in one long session tends to be coherent. A service stitched together across many sessions often has implicit coupling through shared database tables and duplicated business logic that never shows up in a dependency graph. Test the boundary before you trust it.

How do you tell if an inherited AI-built service is actually improving?

Track churn, defect escape rate, and rework ratio across your first few weeks rather than trusting one audit pass. A single review shows today’s problems; the trend shows whether your fixes are holding.

Where should you start when the handoff repo is too large to review in full?

Audit multi-table write paths for missing transactions first, then cross-reference modules with zero human-authored commits against the language-specific patterns for your stack. That combination is almost always where the first real incident originates.