alidoes.ai

All writing

Post-mortem

Why does my AI keep rebuilding an app that's already live?

Every new AI session met my live app through a doc that said it didn't exist yet, and billed me to rediscover it. The fix was one rule: state and plans never share a file.

Key findings

  • Every new AI session met a live production app through a build-era checklist that still called it unbuilt, so sessions re-planned and redid finished work.
  • Onboarding docs rot faster than code because nothing fails when a doc lies. Stale code has tests and angry users; a stale doc just gets believed.
  • The fix: a current operating map as the entry document. State docs describe what IS, plans describe what is NEXT, and the two never share a file.

Because its onboarding document still described the app as unbuilt. Every new session read a build-era checklist, believed it, and priced in work that was already finished.

Onboarding docs rot faster than code, because nothing fails when they lie. Code that lies breaks a test or throws an error in front of a user. A doc that lies just gets believed, and an AI session believes harder than any human ever will.

The app here is 918TS, a small web portal I operate. It was live, in production, doing its job. I'll call it "the portal" from here, and the details are generalized to protect the people involved.

What actually happened?

The portal shipped, and its entry document didn't notice. The first file every new AI agent read (an agent is a session that goes off and does the task, not just answers questions) was written during the build. It was a scaffold checklist. A scaffold is the temporary skeleton you stand up before the real structure exists, and this checklist listed everything still to be created.

By launch, that list was fiction. Every fresh session treated it as ground truth anyway, because a fresh session has no other truth available. AI sessions are amnesiacs: each one wakes up knowing nothing about your project beyond what its entry documents say. If the front-door file says "nothing is built yet," then for that session, nothing is built yet. There is no memory of last week's deploy to argue back.

So sessions did the rational thing with false information. They re-derived decisions that were settled. They planned features that were deployed. Some began redoing work that was already serving users. Session after session, I paid in tokens, time, and review effort for the rediscovery of my own finished app.

Why do onboarding docs rot faster than code?

Because stale code has enemies and stale docs have none. Code that drifts from reality hits a failing test, a build error, a user complaint. A checklist claiming a live feature doesn't exist triggers nothing. No check goes red. The doc rotted in total silence, and it rotted in the most expensive direction — backwards, toward the build era.

I'd call this a documentation failure, but that's too kind to me. The real failure was structural. One file was doing two jobs: it was a plan that I kept using as a status report. A plan is a snapshot of the past's guesses about the future, and once the work moves, a plan is history wearing a status costume.

A human contractor walking into a finished house would ignore a punch list that says "pour the foundation." An AI session extends the doc trust it hasn't earned. That isn't the model being stupid. Trusting the onboarding material is exactly what onboarding is for.

What fixed it?

I retired the build-era checklist and replaced it with a current operating map, maintained as the entry document. The map answers one question: what IS, right now? What's live, what runs it, where things actually stand. The ledger is the dated record I keep of what broke and what fixed it. The entry that closed this incident records the result: the swap "stopped every session from paying to rediscover what already existed."

Same new session, two entry documents Same new session, two entry documents WITH THE STALE BUILD-ERA CHECKLIST New session knows nothing yet → Build-era checklist "nothing is built yet" → Re-plans and redoes work that already exists WITH THE CURRENT OPERATING MAP New session same amnesia → Operating map "the app is live, here is what runs" → Starts at the real frontier the next unbuilt thing
The same amnesiac session, routed by its entry document: a stale build-era checklist sends it back to redo finished work; a current operating map starts it at the real frontier. Diagram source: this page; maps 1:1 to the checklist-to-operating-map swap recorded in the incident ledger.

The rule underneath the fix is the part worth stealing. State documents describe what IS. Plan documents describe what is NEXT. The two never share a file. A document holding both has two decay clocks, and the faster one always wins: the plan half goes stale first and drags the status half down with it.

Won't the map just rot the same way?

It rots slower, for two reasons, and neither of them is discipline. First, updating the map is part of finishing a change, the same way updating a test is; "done" now includes "the front door tells the truth." Second, a map of what-is gets contradicted by reality fast. A session told "this feature is live" finds out within minutes if it isn't. A checklist claiming absence is the safer lie — no session stumbles over a thing its doc never mentioned.

I won't pretend this is enforcement. Nothing blocks the map from drifting; the design just makes drift loud instead of silent, which is the same bet the rest of my verification setup makes. Prose doesn't enforce anything. Placement and habit only decide how quickly a lie gets noticed.

The bill for the original failure was unglamorous, which is why it ran so long: no outage to page me, just sessions quietly re-planning finished work until I finally saw the pattern. The cheapest incident I've written up, and the one I'd bet most agent setups are paying for right now without noticing.

So: open the first document a fresh session reads in your setup. Does it describe your system as it is today, or as it was on the day you wrote that file?

Method & data

Method: one live production web portal whose agent entry document lagged reality — the retired build-era checklist, the current operating map that replaced it, and the ledger entry recording the swap
Data: patterns and methods only; no names, dollar figures, addresses, case identifiers, or confidential content · Last checked: 2026-08-14

How this was made

AI-drafted, adversarially checked, human-directed. My AI assistant wrote this from the system's own records — the incident's ledger entry, the retired build-era checklist, and the operating map that replaced it. A separate AI session then tried to break every claim against those records, and automated privacy and readability gates ran before publish. I direct this pipeline, own every boundary in it, and audit published pages on a rolling basis — if you find an error, tell me and it goes in the corrections log, dated, never silent.

I'm Ali — I run real life-and-work admin on AI agents, then check their work in the open. More at /about.

Published under my standards. Found an error? Tell me — corrections go in the corrections log, dated, never silent.

Cite this

@online{ali2026rebuilds,
  author = {Ali},
  title  = {Why does my AI keep rebuilding an app that's already live?},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/ai-rebuilds-what-exists/}
}

Caught something I got wrong? Send it directly. Confirmed corrections go in the corrections log.