But it is how I feel and it feels like the right word for the job. Because as you say, good code projects start out with good decisions.
It's like when you see a CAD design with a sequence of features that exist only to fix problems caused by starting from the wrong principles or the wrong baseline.
Sure the resulting part may end up identical as a solid for that specific need, but it could have been done in a way that was more robust, simple, easier to understand and modify, and where the design doesn't break in an unexpected way due to a small change of an early measurement.
(CAD has made my instincts much more visible to me)
LLM will take stuff at face value. If you tell it it's good, it'll gladly abide. Similarly if say it's crap it'll so the complete opposite.
My latest experience was towards a C++ to Rust migration and it failed miserably because the existing codebase enforced patterns I didn't want.
It's important to do a first pass cleaning up and preparing code before unleashing agents onto it, similar to how Working Effectively with Legacy Code advocates approaching consolidated codebases. After that the agent will actually pick up the new pattern and start propagating that to the rest of the code.
> It's important to do a first pass cleaning up and preparing code before unleashing agents onto it
That’s a good idea in general, but the whole point of the rewrite was that Fable wasn’t capable enough of fixing the old codebase which we were using as a reference.
Another problem I had in another project was with having “sample” code purely written for testing being used as the architectural guidance, despite comments and repeated memories asking not to.
In the end, by the way, the solution was to simply blocking access to specific files, in the Claude settings.json.
But still Claude tried to cheat by running ‘cat file.cpp` a few times, so…