I'm not sure that is really the case, or relevant in practice. I have been using OpenCode with DeepSeek lately (regular coding). For instance, today I got 120 million input tokens hitting cache, vs just 2.59million missing cache.
Reads like a LOT of tokens to me. What does your usage /workflow look like? I'm v curious because although I do use Claude code, my token counts aren't nearly as much
Not OP, but I routinely load 150k tokens into context. A full sub-package to work on, select other files in the monorepo, e.g. front-end visualization and back-end data loader. Then work some 150k tokens, then start again.
At the end, cache hit rate is like 99.5% if Novita is not having issues.
For official DeepSeek API, 99.9% or something.
Custom harness that never compacts or otherwise doctors the history.
I have refused to lean too hard on agentic tooling for developing. I'm aware of the gains, I use it at my daily job. But I cannot afford to loss my brain skills, just in case they do a rug pull.
These week announcements are effectively Google doing a rug pull to its customers. Now simple changes cannot be done anymore within antigravity without it to consume its full quota.
Personally I downgraded my Google One subscription. I cannot justify paying Pro anymore, and thankfully I'm not AI dependent enough to pay Ultra.
It has always been possible to do it. LLMs are not a particular enabler for that.
The difference is that now it is worthless: there is no learning, no person caring about the result, nothing aspirational for the public to look towards... we used to enjoy those challenges, used to be proud of solving complex problems... now? Yeah, whatever, execute execute commit push, let another LLM "review" and call it a day.
The difference is not that it’s “worthless”. The difference is that now it’s “practical” to implement given the low effort.
I wouldn’t be sad about defeating lower complexity challenges. There are always higher complexity challenges that arise once we start operating in a world when you can do more. The bar raises.
No, increasing the offer of something decreases its value, always. Do not necessarily increases its demand. That is basic economic rule. See that I use "value", not "cost". The distinction matters.
Yesterday I went to a bookstore: saw an interesting book cover then I thought "ah, looks like AI"... all excitement went away. There won't be a "new complexity frontier" for artists that used to draw book covers. Or writers, actors, writers, etc.
AI is currently not enabling any use case which previously was "too hard". It is just reducing the value of stuff by increasing the offer and making people delulu about what they can achieve without proper knowledge.
Making good stuff requires paying attention to a lot of details. Even "simple" stuff can become incredible complex once you actually learn about how it must be done. Most of what we humans do is working on that space, not chasing projects Manhattans.
What do we get if population is disconnected of the true complexity of creating stuff? Perceived value decreases and if everything is perceived equally bad people will stop caring about quality. That is why fascism likes uneducated people.
So, that is about the AI contribution to "value" itself.
Now, is it true that AI will allow us to create more complex stuff that is not practical now? I would strongly disagree. The reason is Kolmogorov complexity: it is not possible to find the shortest program that describes a task. Describing it with natural language will not magically give us permission to avoid having to describe that complexity. What is the point of switching from C to English, if I still have to specify every little detail in a much ambiguous and verbose language? Programming languages are not the challenge, they are the solution to the problem of having to specify complex tasks in a reproducible way.
Now gathering everything together: that is why I think that generative AI makes things worthless: value reduction, complexity perception reduction (which reduces value), a population ignorant of the complexity will choose subpar options because "they are all the same garbage" and we will not get any superior engineering capability anyway.
The point is the death of the celebration of excellence and technical mastery.
Once insurmountable challenges are now trivial to implement with, as you say, "low effort."
For those who were attracted to computing by the grind and the grand narrative that you, too, with sufficient effort, discipline, and merit, could become a revered craftsman, LLMs trivialize an entire lifetime of practice. I can't think of anything more demoralizing.
If your goals were fame, then yes. But you can still pursue excellence even if there is an alternative “easy” path.
The equivalent is something like hand tool woodworking - it’s still a thing despite the advent of machines, but more of a niche. You can still aim to become excellent, but maybe you won’t be famous.
They are factories that product goods on a whim. There is nothing to compare them to as we never had anything like that. This is not industrial revolution this is obliteration of work at its core.
I look at them as lab grown bacteria. We’re in the early days and still have a lot of contamination we still don’t understand. They don’t always produce a viable result, and sometimes they break test rigs.
Just because they’re not a pure extension of our bodies or minds like a hammer or pencil doesn’t mean they will magically break the concept of work.
Writing whole software projects in assembly has been worthless and pointless for a couple of decades now. Even the projects who can put together a solid case will limit assembly to very specific components executed only in specific bits of a hot path. Perhaps the most performance-sensitive code we have today is high frequency trading and that field is dominated by C++.
Also, virtually all mainstream compiler suites have flags that output assembly,and that feature is largely ignored and unused.
That's just not true... the flags to get preprocessed output and assembly are quite useful and used a fair bit, in fact. Multiple reasons - sanitychecking your code, finding bugs, or even finding compiler errors.
Yep, another humane thing going to get killed, because people are naive, gullible and basically idiots handing out their expertise on a platter to faceless corpo entities.
What's next, human human contact abstracted away by brain stimulation?
And the transhumanist arsewipes gonna have a field day.
Many banks already require monthly or annual payments for keeping an account with them. They also use the money from deposits to lend it at high interest rates. It is not like the banks are not extracting much more than a fair share of revenue from a captive market.
It is not only "their" population. Mastercard and Visa captures a % of each sale done globally with their cards. It is perfectly reasonable for all countries to want to develop their own payment systems and stop paying taxes to the USA.
Alternative strategy: go after the other six Millennium Prizes. All you have to do is accept the prize (the only one ever awarded was Poincaré conjecture by Perelman, and he declined)
Personally I would suggest that the "easiest S3" would be simply using NFS. You can get replication with RAID.
S3 is simple for the users, not the operators. For replicating something like S3 you need to manage a lot of parts and take a lot of decisions. The design space is huge:
Coordination: centralized, centralized with backup, decentralized, logic in client...
How to handle huge files: nope, client concats them, a coordinator node concats them...
How will be the network: local networking, wan, a mix. Slow or fast?
Nature of storage: 24/7 or sporadically connected.
How to handle network partitions, pick CAP sides...
Just for instance: network topology. In your own DC you may say each connection has the same cost. In AWS you may want connections to stay in the same AZ, use certain IPs for certain source-destination to leverage cheaper prices and so on...
NFS in practice is too different from S3 to make this work.
I’ve been at a couple companies where somebody tried putting an S3 interface in front of an NFS cluster. In practice, the semantics of S3 and NFS are different enough that I’ve had to then deal with software failures. Software designed to work with S3 is designed to work with S3 semantics and S3 performance. Hook it up to an S3 API on what is otherwise an NFS server and you can get problems.
“You can get replication with RAID” is technically true, but it’s just not good enough in most NFS systems. S3 style replication keeps files available in spite of multiple node failures.
The problems I’m talking about arise because when you use an S3-compatible API on your NFS system, it’s often true that you’re rolling the dice with three different vendors—you have the storage appliance vendor, you have the vendor for the software talking to S3, and you have Amazon who wrote the S3 client libraries. It’s kind of a nightmare of compatibility problems in my experience. Amazon changes how the S3 client library works, the change wasn’t tested against the storage vendor’s implementation, and boom, things stop working. But your first call is to the application vendor, and they are completely unfamiliar with your storage appliance. :-(
> but it’s just not good enough in most NFS systems.
NFS is just an interface. At the end of the day it's on top of an FS. It's entirely possible and sometimes done in practice to replicate the underlying store served by NFS. As you would expect there are several means of doing this from the simple to the truly "high-availability."
reply