How exactly would it help to have a commit that introduces a problem and then another one that fixes it? How does leaving in a bad refactor, failed attempt, or typo help the AI tool with anything?

I recently had it go off the rails on some greenfield work where I was clearly using MySQL with Python and in the middle of the session it started generating Postgres code using the Postgres driver and doing Postgres style upserts.

`raw_anon_1111` nailed it with the context rot reference. After working with LLMs daily for the past year, I've found that garbage in = garbage out, consistently. It's like working with that brilliant junior dev who can't see the big picture through all the implementation details.

You wouldn't dump your entire git history into a code review, would you? So why would you feed it to an LLM? `ManlyBread`'s "poison the context" is exactly right. Every token spent on explaining dead ends or reverted commits is a token wasted.

The solution isn't more data - it's better data. What we need are tools that create concise, high-signal context packages. Architecture diagrams, clean code, and clear requirements. Not the messy sausage-making that got us there.

This isn't just theory - I cut API costs by 40% when I started curating prompts instead of just dumping everything into context. The attention window is precious - use it wisely.