I have fixed the same bug four times. Not four similar bugs. The same bug. In the same application. And each time, I didn't introduce it - the AI did.
Modals in TestPlan kept appearing on the left side of the screen instead of centred. That's it. That's the bug. A CSS issue so basic that any junior developer could fix it in thirty seconds. And yet it haunted me across multiple development sessions like some sort of malicious ghost that exclusively targets the modal-dialog class.
The First Time
The first time I noticed it, I figured it was a one-off. I was working on a new feature in TestPlan and popped open a modal to check something. It slid in from the left side of the screen and sat there, stubbornly off-centre, looking wrong.
"Modals appear on the left for some reason?" I told Claude. Simple fix, right? And it was. Claude adjusted the CSS, the modal centred itself, everything looked correct. I moved on with my life.
The Second Time
A few sessions later - different day, different feature, fresh context window - I opened another modal. Left side. Again.
"Another modal that's stuck left - can you make it so ALL modals are centred. Not through adding classes, but fixing the modal-dialog class."
I was specific that time. I didn't want a targeted fix on one modal. I wanted the base class sorted so every modal would centre by default. Claude agreed this was the right approach, fixed the modal-dialog CSS, and confirmed all modals would now centre correctly.
You can probably see where this is going.
The Third Time
New session. New feature. New modal. Left side of the screen.
I was less polite about it this time: "Right - modals should be centred left and right, as well as vertically."
Claude fixed it. Again. With no memory that we'd had this exact conversation twice before. As far as it was concerned, this was a brand new observation about a CSS issue it had never encountered.
The Fourth Time (And My Epiphany)
When it happened a fourth time, I stopped being frustrated and started being curious. Why does this keep happening?
The answer is both obvious and deeply instructive. Every AI session starts with a blank slate. Claude doesn't remember that we fixed this bug last Tuesday. It doesn't know that modal-dialog has been a recurring problem. It doesn't carry forward any of the "institutional knowledge" that a human developer would accumulate over time.
So when it writes or modifies CSS in a new session, it falls back on its training data patterns. And those patterns, apparently, don't always centre modals correctly - or more precisely, the AI's edits to other CSS sometimes inadvertently break the modal positioning that was fixed in a previous session.
It's the AI equivalent of a developer who fixes a bug on Friday and then reverts their own fix on Monday because they forgot they'd made it.
The Wrong File Problem
The modal bug was the most repetitive example, but there was another pattern that drove me equally mad: changes not taking effect because Claude was editing the wrong file.
In a Blazor project with multiple CSS files - global styles, component-scoped styles, shared styles, vendor overrides - it's not always obvious which file a particular style lives in. Claude would confidently make a CSS change, I'd refresh the page, and nothing would be different. Because the change had been made to a file that was either not being loaded or was being overridden by another stylesheet.
This is a problem a human developer would solve once and then remember. "Oh right, the modal styles live in shared-components.css, not site.css." That knowledge persists. With AI, you have to rediscover it every session.
The combination of these two problems - re-introducing fixed bugs and editing the wrong files - creates a peculiar kind of frustration. It's not that the AI can't do the work. It absolutely can. The fix, when applied correctly to the correct file, works perfectly every time. The problem is that it can't remember doing the work.
Why This Matters More Than You'd Think
I'll be honest with you - at first I thought this was just an annoyance. A minor inefficiency. The cost of a few minutes per session re-fixing something that should have stayed fixed.
But the more I thought about it, the more I realised this is actually one of the most fundamental challenges of AI-assisted development. And it scales badly.
Consider a project with dozens of these "lessons learned" moments. CSS architecture decisions. Naming conventions that were agreed upon after debate. Workarounds for framework quirks. Performance optimisations that were discovered through profiling. Each of these represents hard-won knowledge that, with a human team, would persist in people's heads and in code review discussions and in team documentation.
With AI, none of it persists unless you explicitly capture it. Every session is day one. Every hard-won lesson is forgotten overnight. The AI doesn't get better at your project over time. You get better at instructing the AI.
That's a fundamentally different development model than what most of us are used to.
The Workarounds That Actually Work
After the fourth modal incident, I got serious about preventing this class of problem. Here's what actually made a difference:
CSS architecture decisions in the project context document. I added a section to the CLAUDE.md file that explicitly states where different types of styles live: "Modal styles are in shared-components.css. Layout styles are in layout.css. Component-specific styles use Blazor CSS isolation." This prevents the "wrong file" problem almost entirely.
A "known issues and fixes" section. This felt silly at first - documenting bugs we'd already fixed? But it works. "Modal centering has been a recurring issue. The fix is in modal-dialog base class. Do not override with component-level styles." When Claude reads this at the start of a session, it knows not to touch that particular CSS in a way that would break it.
Explicit "do not change" markers in the context. For CSS rules that had been carefully tuned and should not be modified, I added explicit notes: "The modal positioning CSS is intentionally set to use flexbox centering. Do not change this to transform-based centering." It sounds heavy-handed, but it prevents the AI from "improving" code that was specifically written to fix a recurring problem.
Smaller, focused sessions. The bug re-introduction was worse in long sessions that touched many files. Keeping sessions focused on specific features, with explicit notes about what not to touch, reduced the incidence of collateral damage to previously-fixed code.
The Honest Assessment
Nobody writes about this part of AI-assisted development. The blog posts and conference talks are about the incredible productivity gains, the features shipped in record time, the "I built an app in a weekend" stories. And those stories are true - I've lived them myself.
But there's an unglamorous flip side: the maintenance tax. The repeated fixes. The knowledge that doesn't persist. The slow, grinding frustration of solving the same problem for the fourth time because the tool that helps you build amazing things can't remember what it built yesterday.
This isn't a dealbreaker. The net productivity gain from AI development is still overwhelmingly positive. I ship more, faster, with fewer bugs overall. But the "fewer bugs overall" comes with an asterisk: assuming you account for the bugs the AI will re-introduce because it doesn't remember fixing them.
The solution isn't to stop using AI. The solution is to build systems - context documents, project memory, explicit architecture notes - that compensate for its lack of persistent memory. Treat your context documents as seriously as you'd treat your codebase. Update them as rigorously as you'd update your tests. Because they're the only thing standing between you and fixing that modal bug a fifth time.
And yes, the modals are centred now. I've checked. Twice.
