I used to think this but then improved and found that it was a matter of tooling. Using beads[1] and getting the AI to write its own tickets and wiki articles using GitHub's wiki feature on repos, it can keep track of long horizon projects pretty easily. Then you curate some of the tickets or read through them and have them update the beads or adjust them as they work them. When they want to retain some important piece of knowledge you have them add it to the GitHub repo wiki.
Modern AI programming looks an awful lot like traditional product owner or product management roles.
I started a Janet project [1] with the express purpose of doing everything manually for fun, but I ended up using the agent for a lot of stuff pretty quickly anyway. Functions I wanted to be part of the library as a matter of completion, but that were not fun to write. Docs as well. Stuff I probably wouldn't have written in the first place if AI didn't exist.
It reinforced in my head this idea that hobby programming is entering its "sports" or "running" era.
Consider the modern jogging enthusiast. They buy Nike shoes that make it really easy to run long distances, specialized clothing, fancy water bottles. They find spots to drive to and park at before getting out and running downhill for a few miles, getting picked up at the bottom by one of their friends. Stuff that makes for a great social media post.
They do the hard part of running, but curated to just the parts that they enjoy. They drive the rest of the time and when they do run, it looks nothing like the first marathon run of ancient Greece.
It sounds nice and all to talk about "I'm going to code anyway," but when I did this I found that there are always parts of the coding that I really really never did want to do and that I'm happy to just outsource to my agent like the jogger outsources getting to the top with their car. Testing, writing docs, making the readme logo. Stuff that probably wouldn't have happened without the AI but that I'm glad exists.
Fresh reader here. I am very interested to learn more about your sentence
> We spent a lot of money finding out that a lock is more performant.
I want to hear about that journey.
> Besides, it's a btree.
I guess it's not a hash table, but I think the point of Vincent's post is still worth exploring. You and he both say that essentially a key/value store is mutexed, and the user's code runs inside that mutex. That is fascinating. Why would that be better? Clearly it is, or you wouldn't have spent the money. What controls did you put in place to ensure user code didn't blow up the performance, or did you even feel the need for such controls? Is WASM VM execution fast enough for this? Is there even a market for that? Who pays to put their code inside that mutex and why? I want to know more.
I don't have the whole story for you, but the key is that SpacetimeDB transactions are not interactive. The TigerBeetle team talks about this a lot as well.
The TL;DR is that because you're not holding locks across the network (as is the case in Postgres), your server code can complete transactions in single digit microseconds, rather than milliseconds. And the practical effect is you can do many more transactions per second as a result.
Would it be correct to say that this is an example of the “Actually Serial Execution” strategy for implementing serializable transactions in the terminology of “Designing Data Intensive Applications”?
(I mention this mainly as a keyword that people can look up for more information)
This feels ai generated, and doesn't get to the promised point of "what does it mean for us" forecasting in Europe or much more than a few sentences for the US.
Reminds me of Rich Hickey's clojure data structures. Yes, they're technically log_32(n) complexity, but it turns out log 32 is basically flat on any normal machine, thus "practically constant".
