samwillis
Joined 18 years ago
Joined 18 years ago
Planetscale (assuming they used a agentic development practice) will have pulled this off, to the level of performance that they have, because they have a team of very highly experienced Postgres developers. Their knowlage of Postgres internals will have given them the insights needed to steer the models to a plan that used the architecture as described in the post. That's not something a model can do on its own*
World experts + LLMs = moving mountains.
(* we're obviously seeing something a little different from inside the research teams in the labs. They are showing that the models, when you burn the level of tokens only they can, are able to do novel things from the models own insights.)
2. Receipts: https://postimg.cc/8sDTTT0W
I think this was a first year project, and a small correction: mine want quite the same aspect ratio.
In a completely clean room environment where a designer had never seen a folding phone, but had all the context of the iPhone and everything Apple had done, they would develop almost exactly the same design and features.
Designers have also been exploring the concept of foldable devices for literal decades, well before any reached the market. I have an industrial design and technology degree, we did a project in 2005 where we explored the designs around this, looking at the UI, the physical interaction, everything. My design had a similar aspect ratio and size, as I am sure half the student did my year and every other year they ran the project. (the iPhone Duo is about thousand times better than my design though!)
Thats not to say the Microsoft designers didn't do an incredible job, they did, but they were building on decades of design ideation from those that had experimented before them.
WASM till recently has had a 32bit address space, to match the limitations of JS numbers. With 64bit WASM you have to use BigInt rather than the floats that are numbers in js to address the memory.
It's only the address space that's affected - old WASM still handled 64bit math fine.
It is very true that there are nuances you have to deal with when using CRDT toolkits like Yjs and Automerge - the merged state is "correct" as a structure, but may not match your scheme. You have to deal with that into your application (Prosemirror does this for you, if you want it, and can live with the invalid nodes being removed)
You can't have your cake and eat it with CRDTs, just as you can't with OT. Both come with compromises and complexities. Your job as a developer is to weigh them for the use case you are designing for.
One area in particular that I feel CRDTs may really shine is in agentic systems. The ability to fork+merge at will is incredibly important for async long running tasks. You can validate the state after an agent has worked, and then decide to merge to main or not. Long running forks are more complex to achieve with OT.
There is some good content in this post, but it's leaning a little too far towards drama creation for my tast.
An ai based development workflow with a concrete oracle works very well. You still need the research and planing to solve things in a scalable way, but it solves the "are the tests correct" issue.
What we've done is pull out failing property tests as a unit tests, makes regression testing during the agentic coding loop much more efficient.
In future everyone will expect to be able to customise an application, if the source is not available they will not chose your application as a base. It's that simple.
The future is highly customisable software, and that is best built on open source. How this looks from a business perspective I think we will have to find out, but it's going to be fun!
Working on sync engines, PGlite, and Tanstack DB at Neon/Databricks. Previously co-founder ElectricSQL (acquired by Databricks).
sam dot willis at gmail dot com
samwillis.co.uk
Twitter: @samwillis