Redesigning Source Control at Anthropic(simonwillison.net) |
Redesigning Source Control at Anthropic(simonwillison.net) |
This is my biggest problem with opus 5.5.
It's absolutely incredible in many ways, but it has no sense of "good enough".
It will go around in circles polishing something so to resolve edge-cases on edge-cases.
"Someone could create a class that calls your public method in such a way, that under 3 other race-condition properties, there might be stale data read".
It has no sense that it isn't appropriate to add a half dozen classes just to close that kind of hole, especially when there isn't even such a caller or possible conditions at present.
silly as it sounds but its often much faster for me to skim the code and understand it then to read it's summary of the code
Of course, the second you start interacting with the real world and with humans, that doesn't really apply anymore and you have to get to 'good enough' much earlier than a generator would be able to predict.
Even if you steer a model to a very specific goal with an easy to validate end state, it will do things that within the scope and context of the goal a human would not really do. In theory if you put the context of the entirety of a human into a model, you might be able to get much closer, but we don't even have enough power generation on the planet to process that (unless someone has a secret ten orders of magnitude more efficient way of doing that).
100%
And I have a nasty idea that it is by design. "Use me, use me more!"
The over-engineering is definitely a concern too. It's not that how Fable/Opus architect code is bad, far from it, but the projects I'm working with are not always at a scale where it matters as much, and simpler more readable abstractions might be a better trade-off.
If a module lifespan before it's replaced/refactored is less than a week, then it wasn't a good module to begin with.
This is just hiding all the spaghetti mees that they must have in the back
So let's assume 1 line of correct code is approximately 10 tokens and $1000 of value. If you could theoretically write the correct code, $10 per 1M output tokens should get you $100K worth of value, or 10000x return! Obviously, thought experiment, very theoretical limit no one can achieve, doesn't include thinking tokens, etc, but it's worth thinking about how much your code is actually moving the needle.
Maybe I'm doing things wrong, but I don't need that much code and I don't spend that much time producing code (maybe 1000 lines in a productive day), because the bulk of my time is spent researching, testing, evaluating, thinking, etc to find out how to write only very valuable code. 1000 lines is laughable compared to what tokenmaxxers do, but over the course of a month that's a 200-300K codebase and anyone who has worked on something of that size knows it can support a sizeable business.
- People believe they will be able to maintain code just as easily as they can generate it and it's hard to explain the asymmetry to people who haven't experienced it themselves.
- People don't feel like coding is a craft anymore so they don't care about how the code looks. They just want it to appear like it's working and don't care about anything else. As a team leader, you can't get people to overcome this deep sense of apathy they feel towards the code.
Maybe it's all capacity, but I've certainly seen an improvement in uptime.