I'm surprised I haven't seen this called out more directly and more often. This is a frequent error state.

And not just backwards compatibility, but migration scripts and all of the testing and machinery around it. I'll literally add feature A, merge it, then add feature B and it is like "oh no, we'll have to fix up and migrate all of the users using feature A".

The other problem is anchoring on an old implementation. I was working with Fable on a change to a core system and it pointed out a difficult failure edge case. It is something that can go wrong in extremely unlikely scenarios but the consequence would be short-term data loss (basically a non-durable intermediate cache being overwritten in a race before a flush to durable storage). It is very hard in these circumstances to get Fable to switch from "how to patch this given the existing implementation" to "how to prevent this with a more robust implementation".

These are both cases where the model seems to over-index on what is already there instead of considering what a first-principles approach would look like. A good engineer does both and then costs them side by side, because a first-principles approach can often be less work than patching what is already there.

This is why I have a PROJECT.md in all my repos, which specifically reiterates that this is a greenfield single user project that never leaves my LAN.

It tends to relax some of the insane things LLMs tend to do.

"Plus rigorously ensuring backwards compatibility for a project that is 2 hours old and has zero users."

That is exactly how the slop accretes and you get a pile of crap. Claude somehow assumes that said 2 hour old userless app is some dusty enterprise app with millions of users and billions of dollars at stake for a 1 second outage.

I have to constantly have these things "take a deep breath, step back and look at the entire thing and do this change holistically. please restate what i'm asking you to do and why it's important"