Has anyone noticed a change in "attitude" when coding with Opus 5 vs 4.8?
claude has this maddening principle of wanting to minimize the "blast radius", do the least amount of coding changes to get something done, happy to pile up technical debt by "deferring" problems encountered as side notes somewhere. No amount of CLAUDE.md tweaking, and setting .claude/rules seems to get rid of this attitude.
To me it appears like something deeply ingrained in the model itself. Kind of makes sense, since the bulk of the training data is pre-AI, so that it retains an approach of the past, where these facets were driven by completely different cost and time factors.
The past months, I've been hoping that the next model that comes out properly reflects the new reality of agentic development, so that it takes on a more natural stance compatible with how things work today, and we don't have to constantly fight against its fear of change, its drive to minimize coding efforts, refusing to recognize a design flaw and trigger discussions rather than baking in workarounds.
I think the article is really good, until it starts to offer guidance and making suggestions for the future.
I can't pin it down precisely, but my feeling is that it doesn't fully recognize the fundamental shift taking place. In a sense it's not radical enough, trying more to keep a system afloat whose foundation is being dismantled.
The forces that gave rise to open source will find a new way, because they are based on the nature of the human spirit. We just don't know what it will look like yet.
The idea is to reduce the number of moving parts and simplify processing architecture when building apps that need to be transactionally rigorous and scalable.
It stems from the patterns we used to successfully apply in banks, which worked really well. I believe it's an effective way to get shit done in a broad class of systems. You just need to first get your head around it.
I thought the same thing. But, should we be surprised about what people believe in these days?
I think that the issue is in part due to the variables. Plotting the mean request time is less intuitive than plotting throughput.
If you plot throughput vs number of servers, it'll be a straight line. And asking people that, I think most would agree on a straight line. But who knows!
If the producers see a long term demand for memory they will meet the challenge and produce enough to bring prices down.
Economics will invariably alleviate the memory crunch. It just takes long and requires a huge upfront CapEx.
They have been burned in the past and are hesitant to over invest, worried that the bubble might burst.
I expect high prices to stick around for a while, but I would be surprised if this was permanent.
Which means to me, that price pressure probably won't be the driving force for writing more memory efficient software.
For those who want, I expect AI to make it easier to do that, assuming it's done right, i.e. not vibe coding it.
If you have a subscription to The Economist, I recommend listening to this Money Talks podcast. They talk about the shortage and the economics behind it.
The bike/motorbike/car analogy is good. In each you can find enjoyment that suits your character.
I have been drawn to coding from the first day I took a course at college learning Pascal and assembly on an IBM PC. Hell I even wrote an IEEE/488 driver for an Osborne 1.
As an experimental physicist, coding was always central to my work. I always felt guilty because I had more pleasure coding than tackling the physics itself.
This is a new age we are entering. AI changes how we do things, but I believe that the human passion to be creative and do intellectual work will always be part of it. It's in our nature.
So I'm not worried that we'll all dry up and turn into zombies.
For me personally, holding a dialogue with several agentic dev streams in parallel keeps me very much on my toes mentally. It's quite exhausting, and certainly not letting my brain atrophy.
I'm probably losing some coding skills, but replacing them with different ones, and honing some others.
I used to manage dev teams of 20+ people inside high pressure, high stakes projects.
I've been coding all my adult life, on big things and small.
To me, agentic engineering is a deja vue of managing teams, except in real time.
Nobody uses Amex for payments, so the system isn't ever under high load.
Just kidding!
I find the idea quite good, and have to assume that the amount of payment fails they experience due to partitions/outages isn't very high and that the post-payment reconciliation and reclamation process gives them the liberty to rank availability a bit higher than correctness.
One thing that looked a bit shaky was the interplay between the global transaction router's state of knowing which cells can handle a particular payment and the asynchronous distribution of the "failover data", which I presume it needs to know to route correctly. To me that seems to create a window where it might route to the wrong cell due to an outdated routing state.
It also doesn't go into the HA setup of the global transaction router itself.
Consumer-grade subscriptions of the frontier models give you superb capabilities per dollar, them being heavily subsidized. But if you're working in an enterprise setting, that won't work. You need to upgrade, and that gets significantly more expensive.
Furthermore, basing the SDLC on leveraging the bargain subscriptions risks falling apart in the future, both from a cost perspective as well as the question of availability (e.g. Mythos).
So from a strategic perspective, going local on the LLM and still achieving great results with the right approach is very relevant.
> The New York Fed blog noted that the modest impact on jobs so far may not hold in the future. "Looking ahead, firms anticipate more significant layoffs and scaled-back hiring as they continue to integrate AI into their operations," New York Fed researchers wrote.
claude has this maddening principle of wanting to minimize the "blast radius", do the least amount of coding changes to get something done, happy to pile up technical debt by "deferring" problems encountered as side notes somewhere. No amount of CLAUDE.md tweaking, and setting .claude/rules seems to get rid of this attitude.
To me it appears like something deeply ingrained in the model itself. Kind of makes sense, since the bulk of the training data is pre-AI, so that it retains an approach of the past, where these facets were driven by completely different cost and time factors.
The past months, I've been hoping that the next model that comes out properly reflects the new reality of agentic development, so that it takes on a more natural stance compatible with how things work today, and we don't have to constantly fight against its fear of change, its drive to minimize coding efforts, refusing to recognize a design flaw and trigger discussions rather than baking in workarounds.