I mean, at least they dogfood their own product at scale. Even if the result is likely fairly messy, in their position I think I would do something similar. That doesn’t mean everybody should replicate their approach
They believe that the lower cost of code means we should be much more willing than we used to be to accept code and then say "oh never mind it's bad" a week later. I'm not 100% sure I agree but it's a reasonable position.
People upvote, the link goes up. The HN front page has never been based on new insights or something similar, it’s just a reflection of what the audience vote for. In this case it’s likely because people here like simonw, who is a known high quality contributor
> steer Claude away from over-engineering parts of the system in response to hypothetical concerns.
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.
My problem isn't that it can identify such conditions, the record on cybersecurity lately shows these things are quite good at finding real faults. But the annoyance is that they always want to fix it by adding more things that open cracks. It's possible, sort of, to drive it to fix by removing things instead but it's a battle.
Yeah, I had this issue with Claude since the v5, it’s a real pain to get the model to not create its own goals and spend all its time on it. Switching to Deepseek 4.1 flash is so refreshing, it does what I ask for, mostly, even if things take more time and guidance. At least I don't feel I’m wasting all that processing on stuff I do not care about
This also sounds a bit like an underspecified interface. If the class spec clearly states under which conditions it is thread safe then the agent can take that into account, but if it doesn't then the agent has to assume that it should guarantee thread safety in all contexts.
One thing to keep in mind though is that "someone calls your public method" more often could be an agent, and that agent will try to explore the edge cases.
I'm more curious about Antique. Code review is my bottleneck, this meatbag here can't keep up with the agents at all. I either spend too much time and energy on trying to understand the code (not just in terms of review, but to maintain my mental model of the codebase), or just give up and hope for the best.
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.
It's almost impossible to avoid over-engineering these days. I can't make other people generate minimalist code. Before AI, you could reach alignment with your team members and produce high quality, minimal code, but nowadays I find it impossible because:
- 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.
Do this exercise: Take your company's market cap and divide it by the total number of lines of code in the company's repo. You'll discover that don't need that much code to create value. For Google (somewhat publicly somewhat known), this is something like $2000 per line of code. Your company is probably not too different, certainly within an order of magnitude.
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.
Perhaps their latest models have ushered in an era of exponentially increasing productivity.
Perhaps they've lost control of their process.
If they've lost control, the system will reach an ugly complexity steady-state of sorts, where any change to improve things will, on average, result the same amount of regression. You'd have to hope the next, new, more capable model would be able wind things back (and not just let you raise the level of complexity, which really just leaves you in an even deeper mess.
To my mind, taming exponential phenomena is hard to do, and requires very careful planning and preparation. I don't see evidence of that here. So my bet is this is an out-of-control mess.
But it will be interesting to find out. (And I think we will find out -- I think it's already too big that they could hide it if it's blowing up or collapses.)
36 comments
[ 0.20 ms ] story [ 40.8 ms ] threadIf 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
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.
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.
- 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.
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.
Redesigning source control at Anthropic
https://news.ycombinator.com/item?id=50073633
Perhaps their latest models have ushered in an era of exponentially increasing productivity.
Perhaps they've lost control of their process.
If they've lost control, the system will reach an ugly complexity steady-state of sorts, where any change to improve things will, on average, result the same amount of regression. You'd have to hope the next, new, more capable model would be able wind things back (and not just let you raise the level of complexity, which really just leaves you in an even deeper mess.
To my mind, taming exponential phenomena is hard to do, and requires very careful planning and preparation. I don't see evidence of that here. So my bet is this is an out-of-control mess.
But it will be interesting to find out. (And I think we will find out -- I think it's already too big that they could hide it if it's blowing up or collapses.)