Squashing fix-ups into existing commits - still worthwhile?

It's been a long-standing best practice in my employer's engineering organization to squash (a.k.a. fixup or amend) improvements to commits on a work-in-progress branch -- e.g. following a code review -- into the original commit itself, instead of creating a new branch. 

Here in the 2026+ age of AI coding, it's as-yet not clear to me how much of the time that we previously invested in all of the various ways of keeping our codebase tidy and well-crafted is still worthwhile. Are AI agents (especially as they continue to improve) just as effective adding on to somewhat-messy codebases as they are to clean ones? It remains to be seen!

I think the practice of squashing improvements into existing commits is generally still worth keeping, though, at least for the time being:

• If a developer is in the future investigating some problem with the code, brings up the “blame” report, and looks at the whole commit where a particular line was changed: It makes things easier on them to see the broader view of what was changed, all in the same commit; instead of seeing only the “fix up” changes, and having to dig further back in the commit history to get the full picture. 
• It keeps the repository's commit history more succinct / cleaner. 

Right now, the agents that I use at work -- most typically Claude Sonnet 5.5 and Opus 5.5 -- still "prefer" by default to make fix-up changes on a work-in-progress branch as new commits, rather than amending changes into existing commits. For now, generally, I'm manually telling them to squash such changes into their respective commits.