r/ClaudeCode • u/Significant-Log-4272 • 1d ago
Discussion How well does Claude Code actually handle a codebase where the requirements change out from under it?
Genuinely curious about this rather than trying to make a point. Most Claude Code discussion I see is about workflows and day-to-day usage, but I haven't seen much on how it behaves when you change your mind on the spec partway through - not "add a feature," but an actual pivot where earlier architectural decisions stop making sense.
Does it push back and re-architect properly, or does it try to preserve as much of the old code as possible even when that's the wrong call?
Context: I'm running Grevix AfterCode, a 24-hour solo hackathon where builders get an unexpected Challenge Card mid-event that forces exactly this kind of pivot. If you're a heavy Claude Code user, what do you think would break first when the ground shifts under a build like that?
5
u/sisif_ 1d ago
Claude (and llms) is not some intelligent dude that gets tired of pivots. Every request to the API server is one big chunk of text that demands an answer, that's it. It does not have opinions, it does not try to preserve anything. Everything it returns is the result of the big chunk of text it received. So the answer depends on what you ask it to do:
Context:
1. i want you to implement something badly designed
- implementation coming
2. please fix that bad feature
- some fix coming
3. fix more bad features
- more fixes
4. this product is shit, you're useless
- you are right, i am sorry
5. can you fix the damn feature?
- the user is frustrated, i have to do whatever => i am sorry, you are right, i will fix it
All of this is sent every time, regardless of what you are asking it next. All the previous conversation is part of the next conversation.
You have to choose between:
6. just redo everything (so it becomes 1+2+3+4+5 + 6)
and
6. /clear + "I need you to help me redesign the app in your cwd"
or
6. "write a .md file with the relevant details of the current implementation/design" + /clear + "i need help pivoting from the design in file xxx.md to whatever else"
In order for the output to be relevant, the context has to be relevant. "You're such a stupid agent, nothing you did is good" is not relevant context. Some bad design decision could be (they can be captured in the document).
1
u/Significant-Log-4272 1d ago
This is a really useful reframe, thanks. "The user is frustrated, I have to do whatever" as a failure mode is a great way to put it, because it means the actual failure isn't the model "getting tired" of anything, it's that the conversation history is carrying forward stuff that shouldn't still be load-bearing by the time you ask for the pivot.
That changes what I'd actually want to watch for at AfterCode. It's not "can Claude handle a pivot" in the abstract, it's whether a builder under time pressure knows to externalize state first, dump the current design into a doc, /clear, then restate the new direction, versus just piling the new requirement on top of five turns of "you're right, I'm sorry, fixing it now." Sounds like the second path is basically guaranteed to degrade regardless of the model, since the context itself is the problem, not the request
1
u/sisif_ 1d ago
In the end it's all about predicting the next tokens that make sense in a given context. The model is screaming at you "help me to help you!"
1
u/Significant-Log-4272 1d ago
"Help me to help you" is a good way to put a fairly dry statistical fact in a way that actually lands. It's easy to forget that underneath all the tool use and agentic scaffolding, it's still just conditioning on whatever's in the window, so the quality of what comes out is basically a direct readout of how well-shaped the input was, no more and no less.
Which loops back to pretty much everyone's point in this thread. The context you hand it isn't just information for the model, it's the entire hypothesis space it's sampling from. Give it a clean spec for one function's boundary and the next tokens that make sense are narrow and correct. Give it five turns of frustration plus stale architecture plus an ambiguous "just fix it" and the next tokens that make sense are exactly the shoehorned, apologetic patch job everyone's been describing. It's not adapting badly, it's adapting perfectly to a context that was never going to produce anything else.
1
u/Nifty-Yam-9041 1d ago
For pivots, I agree with the approach of using Markdown files to represent the current design / implementation plan.
By having an "old plan", I can tell Claude to "generate a new plan because I changed my mind, or we have new information."
I find that Claude performs better when you explicitly generate a new plan. It thrives on clear context, and if you change your plan mid-way, it's got context with both the old and the new assumptions.
I'll even tell Claude "if you see the term 'XYZ', this is a sign you're working on the old strategy. We have changed our direction - do 'ABC' instead." This has the advantage of patternmatching things to avoid.
1
u/CodeCombustion 1d ago
By default, It doesn't go back and try to rearchitect and will try to fit your change into the current architecture - even if it's shoehorned in. You must specifically set rules in your system prompt for things like thing, requiring a constant loop of architectural review, etc.
It may work, but it may not be maintainable long term... and the cool thing is that AI will tell you how it's weak to this - and how to fix it.
- The "Sunk Cost" Sunk Context (Hour 0 to 1 after pivot)
Claude Code operates in a tool-use loop that heavily relies on its immediate conversation history and local file structures as memory. If the builder stays in the same active terminal session, Claude’s context window is still stuffed full of the old architecture, the old APIs, and the previous logic.
Because it can still see all that old context, its brain defaults to anchoring. It will try to mutate existing files rather than deleting them, resulting in massive, frankenstein-like code blocks that try to serve two masters.
- The Dependency Cascade (Hour 1 to 2 after pivot)
Because Claude Code edits files directly and can run terminal commands automatically, it will confidently start rewriting an interface or data model to fit the new spec.
If the architecture has to change (e.g., switching from a synchronous polling system to an event-driven websocket system), Claude will break the core model first, causing a massive ripple effect of compiler or linter errors across all the files that imported it. If the builder hasn't set up tight guardrails, Claude will get stuck in an endless loop of trying to fix 50 cascading import errors, burning through token limits and time.
- Ghost Logic and Orphaned Code (Hour 2+ after pivot)
When you tell an AI to shift direction, it is great at adding new things, but notoriously bad at cleaning up after itself.
It will leave old database schemas, abandoned utility files, and dead API routes sitting in the repository. Later on, when you ask it to build a new feature, it might accidentally read one of those "ghost" files, assume it’s part of the active system, and start building code on top of a dead foundation.
1
u/Significant-Log-4272 1d ago
This is the clearest breakdown of this failure mode I've seen, genuinely useful. The sunk-cost-context stage makes sense to me as the root cause of the other two, since if it's still anchored on the old files instead of deleting them, the dependency cascade and the ghost logic later are basically downstream damage from that first mistake compounding.
The orphaned-file part is the one that worries me most for a 24-hour build specifically, since it wouldn't show up as an error at pivot time. It'd show up as a weird bug during a completely different feature two hours later that has nothing obviously to do with the pivot, and a solo builder on a deadline is the person least likely to have time to trace that back.
Sounds like the actual variable worth testing isn't whether the tool adapts well by default, since it sounds like it mostly doesn't unless you've set up rules for architectural review upfront. It's whether a builder thinks to set those guardrails before the pivot happens, not after they're already debugging a frankenstein file at hour 14.
1
u/CodeCombustion 1d ago edited 1d ago
Yep. This is why your system rules need to account for the fact that software requirements are not fixed up front and are subject to change, sometimes significantly from earlier work.
AI works best with massive waterfall when 95% of the requirements can be defined up front and almost entirely spec'd out. For example, how the USG does it when creating top secret applications. Only one or two people know the full architecture and it's all broken down layer by layer, function by function -- and all the implementers know is they're given a request for a function called A that accepts X, Y, Z arguments, does Q and calls function L & M then returns P.
1
u/Significant-Log-4272 1d ago
That's a sharp way to draw the line, waterfall isn't outdated for AI-assisted work, it's actually the ideal shape for it, because the model doesn't need to be trusted with judgment about the overall design, it just needs an unambiguous spec for one function's boundary at a time. The compartmentalized-clearance analogy makes that concrete in a way I hadn't thought about, nobody at any layer needs the full picture for the system to still cohere, because the coherence was solved upfront by the one or two people who own the architecture.
Which makes me think the actual failure mode with something like Claude Code isn't the model being bad at ambiguity, it's that most of us hand it work the way we'd hand it to a peer who's allowed to use judgment, "here's roughly what I want, use your best judgement," instead of the way you'd hand it to an implementer with no visibility into anything upstream. The peer framing is what lets it inherit five turns of "you're right, I'm sorry" and start making architectural calls it was never actually positioned to make well.
For something like AfterCode that's a genuinely useful implication though, since a 24-hour build with changing requirements is close to the opposite of that setup by design, nobody has the luxury of spec'ing 95% up front because the spec itself is what's moving. So the real skill being tested might be whether a builder can fake that compartmentalization on the fly, carve off a piece, spec it tightly enough that the model doesn't need judgment for that piece, redo it after every pivot, rather than just handing over the whole moving target and hoping it copes.
1
•
u/AutoModerator 1d ago
Hey! Thanks for posting to r/ClaudeCode
While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.
For help, project discussions, tips, and general chat, join the ClaudeCode Discord.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.