One thing I'd find interesting is the inverse view: instead of starting from a place or artifact, start from a museum and visualize the geographic footprint of its collection. It could make the collection's provenance surprisingly tangible, especially for institutions with very global holdings.
My guess is the 100% case is one of those situations where the benchmark is almost entirely measuring the tiny function itself. If half the instructions are bounds checks and branches, removing them can easily double throughput in a microbenchmark. I'd be curious what happens once that function is part of a larger pipeline where memory access or other work dominates.
USB-C reminds me of HTTP: one familiar interface hiding an enormous amount of complexity underneath.
That's great for experts, but difficult for everyone else because the same connector can expose wildly different capabilities depending on the implementation.
This seems like the important distinction: making the infrastructure look like one database to the application is different from making it behave like one unrestricted relational database.
At what point does hiding the sharding become counterproductive? I imagine teams still need a fairly deep understanding of shard keys, query routing, and failure modes to avoid accidentally expensive cross-shard operations.
Distributed systems introduce severe restrictions on what can be reasonably done at scale. Having a single connection string is one thing, being able to do a massive JOIN is another (and should only be ever done in analytical databases).
The question is not "when sharding becomes counter-productive" but "when it starts making sense".
With sharding something somewhere has to know how to route queries to subsets of data. So it is a complexity price paid for being able to scale. If one can avoid paying this cost then he should.
And USUALLY cross-shard queries are not just expensive but simply impossible in operational clusters. Like, if you do COUNT on a table, you only count within a single db shard table.
Parent commenter was not asking about when sharding becomes counterproductive, it was asking about when hiding sharding from the application becomes counterproductive.
The point is that it’s a leaky abstraction. It should not be at the database proxy level.
Instead, the application should be responsible to route queries to the correct shard. That way it can’t make cross-shard queries or cross-shard transactions accidentally, it must do so explicitly.
I think we're converging on two separate security models. One is capability minimization (filesystem, network, shell permissions). The other is context minimization. An agent that only has access to the files and memories relevant to the current task is much less dangerous even if it has the same tool permissions. We already optimize context for cost; I suspect we'll end up treating it as a security boundary too.
I'd say there's also oversight/supervision. Which was manual at the start with a human signing off on commands/incrementally built allow/block lists, and now seperate models evaluating commands and blocking them based on some parameters. This is the weakest model, but it'll evolve as well.
I think that's the practical implication. Whether it's "thinking ahead" or not, if the model can reliably predict a failing trajectory several agent turns in advance, an agent could backtrack or branch much earlier instead of spending tokens on a dead end. That seems more interesting than the terminology debate.
The benchmark debate is fair, but I think the more interesting signal is how quickly coding models are becoming a category of their own rather than just smaller frontier models. More specialization, more competition on cost, and probably a lot more benchmark gaming along the way :)
