What you're showing here seems to be a suboptimal choice being propagated, but with likely no practical impact at all if you kept the lookup.
1,403 karma · joined May 25, 2026
If the test suite takes too long, it can easily be cleaned up later rather than spending extra time judging test cases in every new MR.
Maintenance of test cases has also become trivial, even with thousands of them. When the pipeline goes red on master I click the new chat button and run /check-pipeline, where I put some concise instructions, and the failure gets investigated and resolved in short order.
Is having a simpler and more robust implementation worth the time to review, understand, and improve it? I'd put that at easily 5-10x the effort.
If in the future performance was found inadequate, you could still have the agent revisit the slow function.
That's what I mean with the optimization being premature.
In the beginning I was using GPT-5.4 in April.
I can't speak to what other devs are building, and there's certainly no lack of people pushing out slop made in a weekend.
Companies and teams with code review are not adapting at the same speed.
I figure it will take a few additional months for the benefits to become more noticeable to end users.
As someone working on the frontier, so to say, I believe I have a better picture.
Because by my estimation we did build our products in such a way and have that experience, while you presumably did not.
As for Claude Code, they recently delivered a significant upgrade to the desktop app where some commented that it felt like they upgraded Opus 5.5 to 5.6.
It's in fact working great, and the days where it was buggy are in my view in the past.
With GPT-5.4 or GPT-5.5, or of course also by writing the code by hand if we want to go all the way, it was well possible to build nice frontends to our liking.
I still don't want to go back when I can do it better and faster with Opus 5.5.
While I don't know your specific use cases, when interpreted generally, this seems trivially disproven by putting eg. websites made by Opus 5.5 and the local model side by side.
Optimizing performance is one of the tasks best suited to AI, since the outcome is measurable.
I can't comment on complex algorithms specifically, but it's not at all the case that this works only for basic apps or cannot handle complex, performance critical work.
I don't think I commented on performance tests at all.
Maybe I lack imagination here, yes, but generally I go by experience rather than talking about imagined issues. That is precisely what many here seem to do when it comes to explaining why AI couldn't work for them, and why reviewing the code remains necessary.
When I looked at a benchmark, it suggested Sonnet 5.5 wasn't much cheaper than Opus 5.5 at Low to Medium effort for similar performance. That might not be representative of real world use though.
Between Opus 5.5 + GPT-6.1 Sol reviewer, most issues and unhandled edge cases are caught during implementation.
Then you QA test and provide the feedback.
I guarantee that this is enough to produce not only a working product, but is well capable of building apps much better than what is out there, without ever looking at the code.
Depending on your product and risk tolerance you may disagree. I believe that for the vast majority of use cases the approach I described, combined with extensive manual testing, is entirely adequate.
"Perceived productivity gain" is a baseless conclusion. At this point it's abundantly clear that the productivity gain is real and massive.
Where I see the incoherence is in that people see too much value in code review and optimizations.
I believe many of the optimizations are premature. If you did not spot the problem in your QA testing, chances are it was not that important in the first place.
If the architecture wasn't perfect, it is now extremely cheap to change it later, as you realize real deficiencies. The agent will do it for you in a matter of hours, and largely on its own.
You will have to budget a lot of QA effort for verifying the significant changes before going to production, but I don't think it's a deal breaker.
First of all, it sounds unlikely to me that such an implementation was made with Opus 5.5 while it never mentioned the workaround.
Secondly, if the performance was indeed inadequate, that's something I would have caught during QA testing and simply have had the agent fix it.
The differences in our opinion seem to come from different beliefs about capitalism, environmental impact of data centers, and in general the usefulness of AI and how it should be applied.
I finished optimization A. Optimizations B and C that we planned look super promising. Shall we continue?
<Stop here> <Implement B>
50 minutes ago
The outputs are still often verbose and the language always is convoluted Claude-speak.
Even for typical day-to-day software engineering work, there is still much room for improvement.
This would check out with the fact that there aren't many software products or platforms made in Germany, compared to say the US or China.
This raises questions about how sustainable this situation is and if it might further increase the gap in income of software engineers in the US compared to Germany.
Even the best benefits do arguably not make up for receiving $2500 net at the end of the month compared to $8k in the US.
And I get what you are saying about work life balance and so on, but if one cannot even be bothered to try a $20 AI subscription at home, there must be about zero passion for the craft.
To a lesser degree also Sonnet and Luna.
And when I say extensively I mean 500h+ on a side project in addition to my full-time job.
Even the difference between 5.6 Sol, which is miles ahead of local Qwen 3.8 27B, and Opus 5.5 is immediately obvious in the quality of the results.
Having been stuck on 5.6 Sol at my job while Opus 5.5 was available at home, I can say with full confidence that the difference is significant, even if I weren't looking at the output at all.
The way it understands my requests, forms a hypothesis, verifies the result and finishes the change is night and day different. This happens while 5.6 Sol is still flailing around somewhere in the monorepo struggling with even locating the relevant code.
If your employer is so cheap as to spend a $100 or less per month per engineer, while being large enough not to have access to the subscription plans, a move to self hosted or cheap providers does make sense in my view.
It created a 130 KB file with the prompt for the task of identifying the game + the weights.
I pasted that into Claude on the web and asked it to perform the task without using tools.
The other day I was thinking about the definition of AGI.
I was asking myself the question that when there is no form of data that I can think of throwing into Claude Code and have it not come up with some sort of intelligent answer about it, is that already general intelligence?
That's also matching what I see when I work with Opus 5.5 to optimize models. It seems to understand what individual layers are for, and can thus sometimes suggest optimizations, where I as a layman would be completely clueless.
The latest models are performing amazingly. Because of this, I disagree with popular comments saying that eg. DeepSeek is good enough, AI-assisted development was where the real value was at, etc.
We see huge progress at the frontier, while the open competition is around GPT-5.5's level, and that model was released in April. Let's see how things develop in the future.
In my view their interest, which aligns with that of all other major owners of crypto, is to acquire as much real currency as possible.
Acquiring more crypto by decreasing its valuation is not furthering that.
Maintaining a high valuation and positive sentiment in order to convert buyer's real currency into profit to cash out is what I believe their strategy is.
Crypto at it's current price has a market cap around $2.6T. Obviously the liquidity is questionable, and since crypto isn't connected to any mention worthy real economic activity, a change in sentiment can quickly crash the price and liquidate leveraged positions.
While that's of course true for other assets also, crypto not being connected to production of real value, combined with the comparative lack of regulation, makes it much easier to manipulate.
Binance obviously has influence on crypto prices, potentially affecting a liability denominated in crypto.
I understand Binance alone accounts for a third of the market, and their ability to coordinate with other exchanges is hardly restricted to the participants we know were in that specific group chat.
I think the point stands that a liability in eg. USD is much different from one denominated in crypto.