AI-assisted coding tools like Claude Code are incredibly useful. I use them. My team uses them. They absolutely have a place in modern development workflows. But like most things in technology, there’s a gap between what they promise and how they actually perform in the real world. One area where that gap becomes very obvious is in long-running, stateful work—things like data migrations, multi-step refactors, or anything that doesn’t happen in a single clean execution.
The issue is pretty simple: Claude Code doesn’t actually remember what it’s doing over time.
Now, that might sound obvious if you think about how these tools are built, but in practice it’s easy to forget. The interface gives you the feeling that you’re working with something that has continuity—that it “knows” where you are in a process. It doesn’t. It only knows what you’ve told it recently, within the bounds of a limited context window. Everything else is reconstruction. If you want the technical explanation behind that, it comes down to how these systems are limited by their working memory—what’s commonly referred to as a context window—which defines how much they can “remember” at once. (AI context window limitations)
When you’re doing something like a migration, that becomes a real problem. Migrations are all about state. What’s been processed, what hasn’t, what failed, what needs to be retried—those aren’t “nice to have” details. They’re the entire job. Lose track of that, and you’re not just inefficient—you’re potentially breaking things in ways that are hard to detect and even harder to fix later.
Claude Code operates without a persistence layer. It’s not checkpointing anything. It’s not tracking execution. It’s not waking back up and continuing where it left off. Every interaction is effectively a fresh start with whatever context you’ve managed to carry forward. If you don’t explicitly restate the current state, you’re asking it to guess—and it will. Confidently.
That’s where things start to go sideways.
You’ll see it in subtle ways at first. It might lose track of which batches of data have already been processed. It might re-run logic you already applied. It might skip a step entirely because it fell out of the conversation. And then there’s the more dangerous version: it tells you everything is progressing as expected when it has no real basis for that conclusion.
To be clear, this isn’t a knock on the tool itself. It’s doing exactly what it was designed to do. The problem is how easy it is to treat it like something it’s not. Claude Code is very good at planning. It can lay out a clean migration strategy, identify edge cases, and generate solid implementation code. Where it falls apart is maintaining continuity across time.
And yes—the dirty truth is you actually can use it for long-running operations. But only if you turn yourself into the persistence layer. You have to explicitly tell it what to document, where to store progress, what to save as “state,” and then make sure it reads all of that back in after every context reset or compaction. In other words, you end up managing the bookkeeping for the AI while it helps with the work—which defeats a lot of the point. Like you don’t already have enough to worry about.
That gap becomes even more obvious when something goes wrong. In a real system, errors are logged, retries are deterministic, and boundaries are clearly defined. With Claude Code, error handling is conversational. One turn might interpret the failure one way, and the next turn might interpret it differently. The “recovery plan” you get back might not line up with what actually happened a few steps ago, because that context is either incomplete or gone.
And then there’s the confidence factor—which, frankly, is where this gets dangerous. Claude Code will often sound like it knows exactly where you are in a process. “We’ve completed X.” “This step is done.” “We’re halfway through.” Unless you explicitly fed it that information in the current context, it’s not recalling—it’s inferring. Sometimes correctly, sometimes not.
If you’ve ever found yourself getting increasingly specific—or a little more direct than usual—in how you correct an AI tool mid-task, you already know this pattern.
So what do you do with that?
The answer isn’t “don’t use it.” The answer is “use it for the right things.” Claude Code is a great thinking tool. It’s a solid assistant for designing migrations, pressure-testing ideas, and generating repeatable logic. But it is not a workflow engine, and it definitely isn’t a system of record.
If you’re doing long-running work, you need real state management. That means storing progress outside of the AI—in a database table, a log, a checkpoint file, whatever fits your system. It means building your processes so they’re idempotent, so re-running something doesn’t create new problems—because why idempotent migrations matter becomes very real the first time something reruns unexpectedly. And it means using actual orchestration tools when the task warrants it—real workflow orchestration tools like Airflow exist for a reason.
If you want to keep the AI involved, you can—but you have to do the work of re-grounding it. Periodically summarize the current state, feed it back in, and keep those summaries tight and accurate. Otherwise, you’re relying on a moving target.
At the end of the day, Claude Code is very good at helping you think through a problem. It is not good at remembering how far you’ve gotten through solving it. That distinction matters a lot more than most people realize—especially when the work you’re doing doesn’t fit neatly into a single execution.
And this isn’t unique to AI. It’s the same pattern we’re starting to see across the board—tools get the attention, but the reality of how they actually perform is a different conversation. If that sounds familiar, it should. We’ve been saying for a while now that the gap between expectation and real-world execution is where most of the problems show up. You can read more on that here: Realities of Agentic AI
And like most things in technology, the risk isn’t in what the tool can’t do. It’s in assuming that it can.
