I mean, it feels hard not to laugh at this type of blog post. My cynical interpretation is that this is a type of passing the buck to engineers in enterprise settings ("Stop spending tokens. Did you read the value maximization blog post? It is your fault.")
Oh yes, Claude will do all sorts of different things -- it depends on how you use it! You should totally learn all of these little finicky things ... because now completing your tasks cost money. It's not "free" anymore haha like when you used your old text editor, what are you a grandpa?
Oh, and those things will definitely change, as we (the priests of Claude) are vibe coding the system you use to do your little "tasks" ... right, you can't see how it works ... the code is not available. It's all good, just trust us -- we're totally looking out for you.
I mean it is utterly ridiculous to talk around this model of development. There are so many walls between you and doing the thing you want to do.
Agents are great, but the notion of "best tricks" for how to best use an opaque costful tool which will, by all odds, be completely different in a few months time is quite funny.
You know what won't change? A fucking text editor. Or your pi config, or a local model you run and trust.
Not sure how this level of cynicism is even remotely warranted. The post helps people who don't understand LLMs very well get the most out of Claude. Your incentives here are actually aligned with Anthropics since both of you want fewer tokens inputted and outputted per task completed.
Perhaps my enterprise cynicism is not warranted, but my other comments refer to accurate descriptions of reality: Anthropic wants to place their opaque system between you and any computational task that you wish to perform. Do you contest this or think it is not accurate?
Why do you think that Anthropic wants fewer tokens inputted and outputted?
Because they sell subscriptions and tokens cost them compute, and their margin lives in the difference between what your subscription pays in and what you cost them in compute.
They have also been supply constrained on compute and if users cost them less in compute they can more subscriptions and less customer frustration.
I agree they want you to have a subscription. That doesn't mean they aren't aligned with their subscribers.
Subscriptions are a very small part of their overall revenue (estimates have been between 5% and 20% based on financial reporting). Enterprise users are charged per-token, and maximal input/output tokens nets them maximal revenue.
They still want you to hit the cache because their margin is higher on cache hits. That's actual compute they don't have to pay for and they don't have to have capacity for because they are supply limited on the compute side.
And the unit economics need to be there because there are competitors in the space. They can't just skin you on tokens or you'll jump ship.
1000% warranted. not sure what level of peak echo bubble you live in where this level of critiscism feels like you need to defend a ONE TRILLION DOLLAH company.
seriously... priorities yeah?
Through my weekend experiments, I've found I can get way better outcomes, and an order of magnitude less cost with my slapped together sandboxed omp setup plus ZDR openrouter models (DeepSeek, Kimi, etc) than I've ever seen from Claude Code at work.
Everything is version pinned and a deliberate choice to change, and a git revert away from changing back.
TBF the models may change underneath me to some extent still, but the cost benefit of running them myself doesn't pan out yet (for agentic coding at least, don't have enough local vram to get a usable context window and generation speed, self hosting on runpod or similar isn't economically sensible for my current consumption though I have tinkered with it)
I fully agree. All these blog posts are basically features they should be implementing. They advertise they are replacing software development, but then these tools require a massive amount of overhead akin to having to train new hires. But these tools never actually learn and are not trainable, and Anthropic releases a blog post every six months about how to re-invent your workflow. Even the author of Claude Code just told everyone they should delete all their `CLAUDE.md` and skills every six months.
It's wildly lazy.
dude, if you try to do harness development yourself you will realize that most things said in this blogpost is shared with any ${sufficiently_advanced_harness}. this is not really claude-specific, this is just how this class of tools, OSS or not, works
That's not my complaint. I know well the concerns of agent harnesses. My complaint is that this is a low-dimensional projection of a system which I have no insight into, and therefore, I cannot evaluate the tips myself against their source.
Am I to believe the creators, knowing full well that the source will, as Boris Cherny put it in a recent interview, be deleted and rewritten from scratch at the release of the next big model?
Further: I'm responding to content in the blog post itself:
> Until pretty recently, the tools you wrote code with were a flat fee (or free). Your editor cost the same whether you fixed one test or fifty that afternoon, so an individual task didn't really have a price of its own.
I find this type of prose ridiculous. It conveys "this is the way things are now, get used to it".
Does that make sense?
> which I have no insight into
i guess you do? claude code is the commercial closed sourced version provides by ant. reading a mini version of vllm or sglang and then read codex source code or grok build source code will teach you all things taught by this article, fully in the open
it is like saying that you have no insights into some $commercial_db_system which is kinda true but imagine if the article is to teach you indices, query normalization, etc..
> I find this type of prose ridiculous. It conveys "this is the way things are now, get used to it".
This is absolutely what AI companies and AI lovers want you to believe
I'm trying to understand your point of view, but it kind of just sounds like you're against learning how to use tools efficiently?
I mean, agentic coding software is hardly the first tool to exist where learning some idiosyncrasies of how to use it well can result in more efficiency and cost savings.
It's very easy to understand:
- I'm happy to learn how to use tools efficiently
- I like to be able to inspect my tools
- I'm against tools changing underneath me
Are you against any of these points?
what specifically has changed about Claude Code?
https://cchistory.mariozechner.at
and as is normal for hosted models, almost everything... based on load flucation they may even send your prompt to a quantised model
I think I'm happy about the first two. The third I suppose I care less about, just because I've kind of become used to it from decades working on the internet where many businesses/tools/apps are more like services and less like physical tools that never change.
> The third I suppose I care less about, just because I've kind of become used to it
I've never become used to it. My impression is that the constant churn has accelerated. Plausible drivers are (1) normalize novelty as desirable (like fast fashion), (2) product developer/designer incentive structures that reward revolutionary change over progressive refinement. The global switch to subscription models and continuous deployment didn't help.
> more like services and less like physical tools that never change.
I'm not sure that constant change is a characteristic feature of services, especially not professional services.
It used to be that you bought a piece of software and used that version until you decided it was worth upgrading, like a particular physical tool. The software still evolved, just like the design of physical tools can, in principle, evolve.
All that said, agentic AI tooling is evolving so rapidly I'm not sure an expectation of stability is realistic.
> It used to be that you bought a piece of software and used that version until you decided it was worth upgrading, like a particular physical tool.
But Claude is running on someone else's computer, not yours, so it's not Photoshop so much as AWS. Or a rented server farm, if AWS is too new school for you. Of course there's an ongoing cost! And if you configure the server to use more electricity, you get billed more.
If you want to do agentic tooling locally, you can do that—the models aren't quite as good, but they're not bad either. But be warned, for the large models you're going to have to acquire some serious hardware, to the point where you may wish you'd chosen to just rent it instead!
I agree that the third seems to be implied by industry, but I'd argue that it's not clear that it is necessary -- and it is subtle whether or not it is beneficial?
My contention is that we should be building towards less churn, not more. I'm aware that some churn is the cost of engaging in any sort of enterprise, but I'm deeply suspicious of an AI company inserting themselves between me, and the tasks I wish to do with my device -- with a completely opaque system that I can't really "learn".
I'm curious if you also laugh at articles about how to reduce your AWS bill, or how to add indices to Postgres such that you can run it on cheaper hardware.
You can generally understand your AWS cloud usage, and waste can be self evident with their existing tools. Not at all with llms.
A postgres index post is unlikely to reach front page. It's already part if the docs, and should include more context to be read worthy.
They are not equal comparison.
This before the fact that there is no guarantee that a model follows your agent instructions (plenty of easy to reach for research on it), and you also get suggestions by devs at these companies to wipe parts of your model's instructions because the model is better now tm.
If cloud providers change their billing quasi monthly, and if you'd need to fiddle with your indexes every couple of days. I'm not sure we'd be using them as much.
There is interesting information about the inference pipeline, but almost too late to the party (by at least a year), and for which audience? Techies understand in broad strokes the tech if they are interested, normies will definitely not read it.
All that to say, that yes, it's worth having a laugh. If for nothing else, as a release valve for all the problems they create in the real non-VC world.
Anthropic is IPOing in October according to news, you might be interested in investing.
I thought that software engineers were supposed to do, you know, engineering - solving hard problems, dealing with uncertainty.
But you might be right, engineering around the difficult LLM primitive might be a task which is just too hard for your typical software engineer, as you said, they want predictability, hand holding, determinism, most are unable to deal with the real world which is not a spherical cow in a vacuum. So I guess they can stick to simple very well understood primitives like EC2 or Postgres and leave dealing with LLMs for others.
I think you're conflating two different things here. I am not aware of any DB optimization articles that say "trust me bro, throw your data, don't build indices, it'll Just Work™!"