Earlier quoted context omitted.
It can be especially bad if the architecture is layered with each one having its own invariant. Like in a music player, you may have the concept of a queue in the domain layer, but in the UI layer you may have additional constraints that does not relate to that. Then the agent decide to fix a bug in the UI layer because the description is a UI bug, while it’s in fact a queue bug
Shit like this is why you really have to read the plans instead of blindly accepting them. The bots are naturally lazy and will take short cuts whenever they think you won't notice.
Slop is not necessarily the future
511–512 of 512 posts
Re: Slop is not necessarily the future
#512Earlier quoted context omitted.
> Code evolvability is almost entirely subjective Explain how? Code evolvability is one of the extrinsic quality markers ( https://www.pathsensitive.com/2023/07/the-11-aspects-of-good... ). If it's easy to add new features without creating bugs, the code is evolvable. Else, it's not. Does not seem very subjective.
Let's take two code bases. A 40 year old legacy Cobol monstrosity being maintained by a staff of well trained engineers that are engaged. The second an idiomatic Haskell application written simply and to the highest standards, but with a staff of junior engineers that specialize in imperative programming. The Cobol code base is much more evolvable. The staff can effectively make changes because they deeply know the p…
To use a simple analogy: you could argue that a modern Macbook is easier to maintain than an old Dell desktop, if the Macbook is owned by a certified Apple technician who knows how to microsolder, and the old Dell desktop is owned by someone who doesn't know how to use a screwdriver. But that doesn't change that, to change a hard drive, one needs much more skill and fancier tools than the other.