> If you have formulas that actually match reality, what do you need the LLM for?
That's the key question.
I think LLMs allow people with no context or background or know-how to dive into projects and see some results being presented to them, but they don't have the context or skillset to tell what they see before them.
This paves the way to people laying grand claims about achievements because of LLMs. Their claim is that LLMs know best primarily because LLMs knew more than them, not that the output is good or desirable.
> I think in principle you could clone your database in prod and at least test to see if your most difficult + common queries are indeed faster after running through the LLM optimizer?
That is the responsibility of whoever thought it would be a good idea to write this article. It's their responsibility to show that their idea has merit, and that their results are significant. I mean, don't they have a vested interest in manipulating and cherry-picking their results to inflate their relevance?
> I'd say it probably depends on the kind of work you do - if the low level details are exciting then that's totally understandable.
Even those who work with CRUD apps need to know things like computational complexity of standard container types, and how to pick basic data structures or choose which basic algorithms to use. Otherwise you'll end up implementing things that have an unreasonably high computational cost that will rear its head at the wrong time.
> That said, AI will probably saturate most CRUD work first, which doesn't make for great job prospects.
I think so too. Today's AI models excel at makeshift plumbing. The boring CRUD jobs are the first ones to go with a prompt.
> Durable execution looks a bit like a buzzword in general. If your state is defined in the execution graph then it's just an umbrella term for a group of pre-existing algorithms and patterns.
If you first approach a tool because of buzzwords, don't be surprised that you think of the buzzwords instead of the tool.
Durable executions greatly simplify how workflows can be implemented and audited, and they literally allow eternal workflow executions that are not tied to the lifetime of an instance assigned to execute them. Durable executions do not require fancy infrastructure, only a terribly simple database.
If you understand continuations, you understand durable executions. Otherwise, you'll be stuck with the excuse that they are buzzwords.
Well, you have to either capture/eliminate/persist side effects and control the environment tightly, or it's limited in what it can do.
In a distributed or concurrent system, for full granularity, that can require specialized timing or virtualization techniques up to ensuring fully atomic snapshots and deterministic execution environments (and whether or not that properly models the SUT in real environments, or introduces bias/breaks the reproducibility in a way you care about)
Otherwise if you're only running against fixed checkpoints you have something closer to traces that maybe you could re-run or test against, in some cases, if you put in the work to set it up. In distributed systems that can be a lot of work so it's a bit vague if left unspecified. Because it's not enough to merely replay something if things can drift or don't accurately model the real system
> Well, you have to either capture/eliminate/persist side effects and control the environment tightly, or it's limited in what it can do.
You really need to read up on durable executions before commenting. Your comment reads as if you are completely oblivious to them. Their whole point is benefiting from an execution model where your workflow is comprised of idempotent pure functions whose inputs and outputs are tracked by the durable task persistence.
It's a problem I've spent a lot of time on, just not through the products marketed like temporal. I commented on the article because it's about program replay with checkpointing which is similar to what I worked with/mentioned.
I didn't see the article mention idempotency anywhere, and you didn't in the original response to the guy who said it just sounded like a buzzword; atomic snapshotting with deterministic execution is literally how you make a program continuation an idempotent function!
And the article is about solving the problem at the language runtime level so it doesn't even do that. So it would be reasonable to assume it is a buzzword if it does not have the essential property you mentioned and I was referring to. I was not even intending to disagree with you but just add what would make it less of a buzzword in this kind of case.
For the sort of architecture described in the blog post, you're persisting the program rather than a log, so you only need idempotency between any two checkpoints. For a lot of apps that's easy to achieve if write the snapshot into the same transaction the user is using for application data, and if you create/propagate idempotency tokens to other services.
You don't need specialized timing or virtualization techniques.
The last batch of open weight models releases by Chinese companies are on par with the performance of US-based frontier models, even though they are designed to run on pretty unimpressive hardware.
This is very misleading. There is no Chinese model currently that is on par with Fable or Astra. Kimi K3 is pretty good, but it's not that good.
Furthermore the Chinese models in that class are appropriately large. K3, for example, is a 2.8T-parameter model. Qwen 3.8 Max, another comparable model, is 2.4T params. Even with MoE, these are not "designed to run on pretty unimpressive hardware". Stuff like Qwen3.7-27B is, but it is also not even in the same ballpark as Opus, never mind frontier.
> This article doesn’t present much motivation for why you would do this.
For those working with databases, it's easy to come up with a bunch of reasons. ORM is a necessary evil when working with RDBMS, as are things like schema migrations that can easily result in loss of data (I.e., dropping columns or tables).
What if all we need is dumping a big old JSON in a container?
This idea is very enticing. The scale of this whole NoSQL thing is pretty telling.
The blog presents a thought provoking question: what if we don't actually need a full-blown database, and instead we only care about things like unique constraints, transactions, indices, and history tables.
> ORM is a necessary evil when working with RDBMS, as are things like schema migrations that can easily result in loss of data (I.e., dropping columns or tables).
Hmm, neither of those been necessary for me. ORMs is a choice, you can choose not to and still have a proper design and architecture and not suffer from that choice. Requires you have programmers who know how to use SQL, which seems less and less common as the days go by though, so understandable most reach for an ORM.
Schema migrations that can "easily result" in data loss is even easier to avoid though. Don't drop the column/table in the same step you copy data to the new place, or do the migration via application code which gets cleaned up later, to catch most of the stuff before one bigger copy, and then the eventually DB cleanup.
Guess it depends on how careful you want to be, or how careful your agent lets you be, I guess. But it's definitely possible to avoid both of those "necessary evil", which I guess makes them just "evil".
> The blog presents a thought provoking question: what if we don't actually need a full-blown database, and instead we only care about things like unique constraints, transactions, indices, and history tables.
This sound like: what if we dont actually need a table and instead we only care about four legs and a wooden plate.
That's the problem. Hitting a tied up animal until it breaks is clearly a violent affair, similar how hanging puppets in nooses or putting a doll in a guillotine.
I'm sure that there are kids growing up in places where bullfights are common thinking that torturing and killing a bull in a party-like atmosphere is fine.
I mean yeah, absolutely. But a child growing up in a western society is unlikely to encounter either of those. But generally I do see Pokemon as violent and I wouldn't let my 5 year old watch it quite yet. When he's a bit older I hope he enjoys playing through the original games and the OG tv show with me, but I see parents playing the TV show for their 4-5 year olds and I think that's just too young. Same with Spidey and friends and few other shows made "for children" which absolutely promote violence despite the colourful aesthetic.
Not necessarily, in C++ you'd still drop from smart pointers to raw pointers, from virtual dispatch to switches/computed gotos, from std::function to function pointers and so on. These abstractions all come at a cost.
That's the key question.
I think LLMs allow people with no context or background or know-how to dive into projects and see some results being presented to them, but they don't have the context or skillset to tell what they see before them.
This paves the way to people laying grand claims about achievements because of LLMs. Their claim is that LLMs know best primarily because LLMs knew more than them, not that the output is good or desirable.
reply