Your first prompt was "build me a login page," and it worked. Clean, first try, no arguing. Two features later you asked for something small — a filter on a list, a field added to a form — and it broke a page you hadn't touched in three days.
You're standing there now deciding between two explanations. Either the model got dumber, or you did something wrong. I want to give you a third one, because the first two are both asking the wrong question.
The empty folder is not a harder version of this
Day one, your assistant was building into nothing. An empty folder has no opinions. There is no existing function it might contradict, no name already taken, no page that quietly depends on a shape it's about to change. Every decision it made was free, in the specific sense that nothing could object.
That's not the assistant being smarter on day one. That's the task being easier — as easy as a task in this line of work gets. Inventing something from a blank page is the one job where "make something reasonable" and "don't break anything" are the same instruction, because there is nothing yet to break.
What actually changed by feature three
By the time you asked for that small filter, the folder wasn't empty anymore. It had a form that stored its data one particular way. A page somewhere that reads that data and assumes it still looks like that. A name you picked for a field, now typed in four places, only one of which you were looking at when you asked for the change.
None of that is written down anywhere as a rule. It's just how the app happens to work, the way a house that's been lived in for a year has assumptions nobody wrote on the wall — this switch is on that circuit, this pipe run behind that panel, don't sink a screw there. Wire a house that doesn't exist yet and you can run any cable anywhere. Wire a house that's already got someone living in it, and every new run has to route around outlets and switches nobody handed you a diagram of.
The assistant isn't reading your mind about which of those assumptions matter. It's looking at what fits in front of it, matching the shape of your request, and making a call — the same kind of call it made on day one, except day one had nothing standing behind it to knock over.
The task got harder in a specific, nameable way
Here's the actual shift, stated plainly: on day one, the job was "produce something that works." By feature three, the job is "produce something that works, and leave everything you didn't mean to touch exactly as it was." That second clause didn't exist at the start. It arrives the moment there's a first working feature to protect, and it only gets bigger — every feature you add is one more thing the next change is quietly required not to break, whether you said so or not.
That's not a mysterious quality drop. It's an unstated constraint compounding, one feature at a time, on a system that was never told the constraint existed. Nobody typed "and also, everything already here still has to work." You didn't have to — a person reading the code would infer it instantly. An assistant working from your sentence and whatever fits in its view has to infer it too, and inference is exactly where these small breakages come from.
Sure, but — isn't the model just worse now?
I'd take this argument more seriously if the pattern looked like a quality problem instead of a structural one. A model that's actually gotten worse should be inconsistently bad — good on Tuesday, bad on Thursday, unpredictable across people and projects, the way a genuinely degraded tool behaves.
That's not the shape of what I keep hearing described, for what it's worth — and I'll say plainly that "what I keep hearing" is an impression from reading a lot of it, not a count I ran. People tend to place the complaint at roughly the same point: not the first prompt, not random, but around when a project stops being empty and starts being a thing with history. I can't hand you a survey backing that up, so take it as a pattern I've noticed repeated rather than a measured fact — but it's the pattern this piece is trying to explain, and it's the one worth checking against your own experience before you decide the model is what changed.
If that's roughly right, it's not what a broken model looks like. It's what a fixed difficulty curve looks like — the same stair tripping people at the same point, because the stair is real, not because the walker got clumsier.
I'm not saying no model has ever regressed — training changes are real, and I won't pretend every complaint online is this one thing in disguise. But the complaint this piece is answering — great on day one, breaking things by feature three — has an explanation that doesn't require a conspiracy, only a folder that isn't empty anymore. Occam's razor points at the boring one.
The one habit that actually addresses this
Not a tool, not a setting, not a slash command. A change in what you type into the box, and it has two halves — drop either one and you've kept the weaker version.
Change one thing at a time. Don't ask for the filter and the field and the styling tweak in one message because you're in a hurry. Each bundled request is a wider net of things that might quietly depend on each other, and when something breaks, you won't know which of your three asks did it. One change, see that it works, then the next one. Slower per message, faster overall, because you're not spending Thursday evening bisecting three changes to find the one that mattered.
Describe what already exists before you ask for the next thing. Not the whole app — the specific part your change is near. "The signup form stores the email in lowercase, and the login check assumes that" is one sentence, and it turns an assumption that was living silently in your code into something the assistant can actually see and respect. You are doing, on purpose, the thing a teammate does automatically after reading the file: naming the constraint before someone works around it by accident.
Neither half is complicated. Together they're the difference between an assistant guessing at what "existing" means for your app and an assistant being told.
Why this matters
The instinct to blame the model is understandable, because the day-one experience really did feel like magic, and magic that stops feeling like magic reads as broken. But treating every request as if it's still day one is the actual mistake — it's asking a system to protect promises nobody told it about, on a project that's no longer empty, and then being surprised when a promise gets missed. The failure mode this prevents isn't "the AI is bad at coding." It's building an app you can extend forever and can't trust for a week, because nobody — not the assistant, not you, in the rush of typing — ever said out loud what wasn't allowed to change.
Day one only happens once. Every prompt after it is asking the assistant to build something new inside something old, and that's a different, harder job than the one it did first — not a worse assistant doing the same job worse.
Final thought
Before your next prompt, don't open with the request. Open with two sentences: what already works, and what it depends on. Then ask for the one thing you actually want changed — not three things bundled because you're in a hurry. That's the whole habit, and it's the difference between an assistant guessing what "don't break this" means and one you actually told.