You gave an AI a plain-English description, and minutes later you had a working app. Now something is broken, you go back to the same tool, and it can't fix it. It gives you a confident answer that doesn't work, you paste the error, it apologizes and tries again, and the next version is worse. You start to wonder if the tool got dumber, or if it's stalling, or if you did something wrong.
None of those are the real problem. The AI never actually held your whole app in its head the way you assumed it did. Fixing a bug isn't a magic problem, it's a re-briefing problem. Once you understand what the tool can and can't remember, you can hand it the missing pieces on purpose, and it becomes useful again.
In Plain English: the AI was never remembering your whole app
Imagine you hired a very fast, very well-read contractor who has a strange condition: they forget everything the moment they walk out of the room. Every time you call them back in, they only know what you tell them in that conversation, plus whatever you hand them on paper.
When you first built your app, that worked beautifully. You described what you wanted, the contractor built it right there while you watched, and everything they needed was in the room at that moment. It felt like they "knew" your app.
But a week later, your app is bigger. There are more files, more moving parts, more decisions that got made along the way. When you call the contractor back in and say "fix the login bug," they don't remember any of it. They're not being lazy or stubborn. They genuinely walked in with an empty notebook. If you don't hand them the current plans, they'll guess, and a confident guess that's wrong is exactly what you've been getting.
That's the whole idea. The rest of this post explains why this happens and, more usefully, how to hand the AI the right pages so it can actually help.
What a context window is and why yours overflows as the app grows
Every AI tool has a limit on how much it can "hold in the room" at once. That working memory is called a context window: the total amount of text, including your app's code and your instructions, that the model can consider in a single conversation. Think of it as the size of the desk. Anything that fits on the desk, the AI can look at. Anything that doesn't fit gets left on the floor where the AI can't see it.
When your app was small, everything fit on the desk. Your whole project, your request, and the AI's answer all sat there together. As your app grows, the code no longer fits. The tool either shows the AI only part of your app, or it silently trims older parts of the conversation to make room. Either way, the AI is now reasoning about your app with pieces missing, and it usually doesn't announce which pieces.
This is why the same tool can feel brilliant on day one and unreliable later: the task now exceeds the context the tool can use effectively. Context limits and retrieval behavior vary by model and product version, so test the current tool on a representative codebase instead of relying on a universal number.
A few practical signs your context is overflowing:
- The AI "forgets" a decision you clearly made earlier in the same chat.
- It refers to files, buttons, or fields that don't exist in your app.
- It re-suggests a fix you already told it didn't work.
- Its answers get vaguer as the conversation gets longer.
Context drift: how each edit quietly loses the thread
There's a second problem that's easy to miss. Even when things fit, the AI's picture of your app slowly goes out of date. This is context drift: the gap between what the AI thinks your app looks like and what it actually looks like right now, which widens with every change.
Here's how it creeps in. You ask for a change. The AI writes new code based on its picture of your app. You accept some of it, tweak part by hand, undo one thing, and accept another suggestion an hour later in a different chat. Meanwhile the AI is still reasoning from an earlier snapshot. Each small edit that the AI doesn't see moves the real app a little further from the version in its head.
After enough of these, the AI is confidently editing an app that no longer exists. It "fixes" a function that you already changed. It reintroduces a bug you removed. It assumes a setting is on when you turned it off. From your side it looks like the tool is going in circles, but really it's answering questions about a slightly different app than the one on your screen.
Drift is worse across separate chats. Opening a fresh conversation feels like a clean slate, and sometimes that helps. But a fresh chat that starts from the AI's assumptions instead of your current code is not a clean slate, it's a confident stranger who has never seen your app guessing at how it works. That is often worse than continuing a messy chat, because at least the messy chat had some real context in it.
Why the AI sounds confident while being wrong
This part throws people off the most. The wronger the answer, the more sure the AI often sounds. That combination feels almost dishonest, so it helps to know why it happens.
These tools are built to produce fluent, plausible, well-structured writing. Confidence is the default style, not a signal that the answer is correct. The AI doesn't have a separate little voice that says "I'm not sure about this one." It fills the gaps in what it knows with reasonable-sounding guesses and presents them in the same steady tone as the parts it got right.
So when your app's real code isn't on the desk, the AI doesn't stop and say "I can't see enough to answer." It reconstructs a likely-looking version of your app from patterns it has seen before and fixes that imaginary app instead. The fix is often internally sensible. It just doesn't match your actual code, which is why it doesn't work when you run it.
The takeaway isn't that the AI is lying. It's that confident tone carries no information about correctness. You have to judge answers by whether they work in your app, not by how sure they sound. And the most reliable way to make the answers actually match your app is to stop letting the AI guess, and start handing it the real thing.
How to re-brief the AI: give it the current code, the goal, and the guardrails
Almost every "the AI can't fix it" situation improves the moment you stop describing your app from memory and start showing it. Your job is to walk into the room and put the right pages on the desk. Three things belong on that desk, every time.
1. The current, relevant code. Not your memory of it, not the version from three chats ago. Copy the actual code for the part that's broken, as it exists right now, and paste it in. This single habit fixes more problems than any clever wording, because it erases drift: the AI is now looking at the real app instead of an imagined one.
You don't need to paste your entire project, and you usually shouldn't, because that just fills the desk with clutter. Assemble the minimum useful context:
- The specific file or section where the problem shows up.
- Any code it directly connects to (the button that triggers it, the function it calls).
- The exact error message, copied in full, not paraphrased.
- What you already tried that didn't work, so it doesn't loop back to it.
2. The exact desired outcome. Say what "fixed" looks like in concrete terms. "When a logged-out person clicks Save, send them to the login page instead of showing a blank screen" gives the AI a target it can aim at. "The login is broken" does not. Describe the behavior you want, the behavior you're getting, and where you see it.
3. The guardrails. Tell it what not to touch. Non-technical builders get burned when a small fix quietly rewrites three other things. A line like "change only the Save button behavior, don't modify anything else, and show me exactly what you changed" keeps the blast radius small. This is the heart of the AI change-request template that prevents regressions, and it's worth making a habit.
Put together, a good re-brief reads like a work order, not a vent. Here's the shape:
| Part of the brief | Weak version | Strong version |
|---|---|---|
| Code | "It's in the login part somewhere" | Pastes the actual current login code |
| Goal | "Make it work" | "Logged-out click on Save goes to /login" |
| Current behavior | "It's broken" | "Clicking Save shows a blank white screen" |
| Error | "There's an error" | Pastes the full error text |
| Guardrails | (none) | "Change only this function; list what you changed" |
If you want the fuller routine for making changes safely, the safe-change workflow walks through doing this one small, reversible step at a time so a fix can't quietly take down something else. And for the bigger picture of steering the tool through edits and additions, see how to direct, review, and extend AI-generated code.
Set your expectations honestly
Better context genuinely helps, and it will get you unstuck more often than not. But it is not a guarantee. A bigger, cleaner brief raises your odds of a correct fix, it doesn't promise one.
Some problems sit outside what re-briefing can solve:
- The bug lives in how several parts connect, and no single chunk of code shows it.
- The issue is in a service, account, or setting the AI can't see at all.
- The "fix" keeps trading one break for another, which usually means the underlying design needs a rethink, not another patch.
- Money, logins, or personal data are involved and a wrong guess has real consequences.
That last one deserves a hard line. If the broken thing touches payments, account passwords, or anyone's personal information, that's the point to slow down and bring in a qualified professional rather than trading fixes with an AI. A confident wrong answer about a display bug wastes an afternoon. A confident wrong answer about a payment flow or a login can expose real people to real harm. This is general education, not legal or security advice, and for those areas you should verify with a professional for your specific situation.
Knowing when to hand off is part of owning your app, not a failure. The goal isn't to make the AI do everything. It's to get clear, working help from it on the many things it can do, and to recognize the few it can't.
In Plain English
What this means: The AI that built your app never kept a full memory of it. It works within a limited window of "current attention," and its picture of your app drifts out of date as you make changes. When it can't fix a bug, it's usually missing context, not misbehaving. Fixing is a re-briefing problem: hand it the current code, a concrete goal, and clear guardrails.
Who this helps: Solo founders, indie hackers, and non-technical builders who shipped something with AI or no-code tools and are now stuck in a loop of confident, wrong answers.
When to use it: The moment the same tool that built your app starts going in circles, contradicting itself, or making things worse with each try.
What to do next: Stop describing your app from memory. Paste the actual current code for the broken part, state exactly what "fixed" looks like, name the one thing to change, and tell it to leave everything else alone. If the problem touches payments, logins, or personal data, or if fixes keep trading one break for another, that's your signal to bring in a professional.
If you want the calm, full playbook for what to do the moment something breaks, start with the calm first-response guide when your app breaks. You can also browse the Debug hub for related fixes, or spend time in the Direct AI Well hub to get steadier results from your tool overall.
Next step: grab the change-request templates so you can re-brief the AI with the current code, the goal, and the guardrails in place, and get it back on track without it going off the rails.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.