Yes, that's true, but in the post, they even mention that building the spec is the scarce resource.
For that to work, the swarm has to actually follow the spec, which is what much of this post is about. We gave the swarm 835 pages of prose and it came back with a database. What was scarce in this experiment, and what we expect to be scarce in software engineering going forward, is the right description of intent.
We're rediscovering the "architect" job role a decade or so after switching to agile processes and staff engineers largely replaced it. God help us when they rediscover UML for agents.
Easily the biggest delta between a good one and a bad one I've ever encountered. It's so easy to test too. Just ask a product manager if they can give a talk on <some product they own> in 2 hours. If they respond by slacking all of the engineers that work under them to stop what they're doing and give them the info to give that talk, fire them. If they are ready to talk right now then give them a raise.
I mean, how long are these pages? Assuming 40 or so lines per page, that would be 33400 lines of spec turned into 200,000 lines of Rust, or about 6 lines of code per line of spec. That's a very detailed spec, much more than any software specification I have ever written in my career. It's not obvious to me that writing this spec would meaningfully save work over incrementally building individual features, especially when you think about what it would take for human beings to meaningfully review whether those 835 pages contain the right intent.
not only that, but what all of this misses is the fact that the specification that they used was a product of writing the software, not the other way round. It would be much, much more difficult to first write a correct specification than to first write a correct program, because programs are formal systems that can be executed to observe their correctness. You can’t do that with a specification.
Yeah, agreed. It makes everything else look pretty bad. I still like to manage my work in a more structured form, but Codex can just rip on a goal end to end in the same thread.
Probably all of them? On modern versions, Gatekeeper still adds a bunch of milliseconds and possibly a RTT network request to Apple before the first launch of many apps; although I think Apple's binary checking is cached for 24 hrs or something.
A few of us built nearly the exact same thing for a Hackathon which was fun. This definitely can work. There are a couple of other approaches too that are interesting like
- xata - https://xata.io/blog/xatastor-zfs-nvme-of-for-millions-of-postgres-databases
- neon - which has a more sophisticated architecture that builds abstractions at the Postgres layer
But separating compute and storage sucks and the performance you get out of EBS and friends is mediocre. The elasticity is nice, but if you have High Availability and can move instances around, you can still expand your cluster relatively easily, just not easily in an emergency scenario.
Because you mentioned Xata (I'm the author of that blog post, thanks for mentioning it), this is pretty similar to what we do at the high level, but we built our own storage system rather than relying on Ceph. The reason is scalability to many volumes and to lesser degree performance.
I'd say Homescale is closer to Xata than Planetscale, tbh :)
oh yeah, sorry, I should've started my comment with "this is awesome" because it is, you did a great job explaining all the layers and the interactions within. I love stuff like this even if it's not necessarily prod ready by default!
This is really pretty, but I'm surprised it doesn't have a microphone. I know it's just rebranding the existing work louder creator keyboard, but a mic would really, really help with this product. Especially one that is really effective at Wispr Flow-type speaking.
it typically offers better video processing and upscaling, more accurate color reproduction, cleaner gradients, and superior HDR handling (including dynamic tone mapping on some models). Many also support Dolby Vision from UHD Blu rays, which the PS5 does not.
It won't show on a bad screen that much, but a dedicated player will squeeze out more of the disc.
No upscaling as it's not necessary. (But better players have better 1080p to 4k upscaling too, as the algorithms are more sophisticated, e.g. edge-adaptive scaling, temporal filtering, etc.)
First, the player performs MPEG-4 HEVC decoding, reconstructing full video frames from heavily compressed data.
Once decoded, the signal is still not in a display-ready format.
UHD Blu-rays are almost always encoded in 4:2:0 chroma subsampling, meaning luma (brightness) has full resolution, but chroma (color) is spatially reduced. so one of the first steps in the pipeline is chroma upsampling (chroma reconstruction). After that, the player applies color space conversion and output formatting, usually converting to a HDMI-friendly format like YCbCr 4:2:2 or 4:4:4.
HDR handling is sometimes done on the player.
The tv is doing a last stage processing that is fine tuned for it's display like contrast enhancement.
There's a bit of misinformation here. At the end of the day, a blu-ray player is reading information from the disc and passing it onto the TV digitally - one player or another are going to do that identically. One can't have 'better color' or anything like that.
HOWEVER, there is an exception: Feature support. For example, not all blu-ray players support 4K blu rays. Not all players support Dolby Vision.
If you try to play a 4K blu ray disc in a non-4K blu ray player, it won't function at all (won't read). If you try to play a disc using Dolby Vision in a player that doesn't support it, it will fall back to HDR10.
But assuming 2 players both support the features a disc uses, the end output will be identical.
There's also upscaling, which some players can do differently.
The other commenter is spot-on. A blu-ray player is a computer decoding a compressed file on the fly as it sends the image to the TV, rather than just a passive pipe for digital bits.
Accordingly, different brands use different video processing hardware and software to rebuild that compressed data. This absolutely results in color accuracy variation, shadow detail, and overall picture differences.
the final output is not guaranteed to be visually identical because parts of the processing pipeline (chroma reconstruction, tone mapping, scaling, and output formatting) are implementation-dependent. There is a spec, but multiple processing stages are not strictly defined to be identical. Higher end players also use a HDR Optimizer and the ps5 does not, which is visually noticeable.
I would say one thing I've enjoyed about the latest frontier models from US labs is that you just work at a higher level of abstraction. You can talk about the end goal and it'll just rip. You'll add scaffolding to constrain the patterns etc, but I do way less baby sitting than I expected on 5.6 vs 5.4 vs Deepseek v4 Pro.
I wouldn't call this minor. The 2 big features seem to be integrated memory + ambient proactiveness. This requires pretty intense tuning to not be annoying.
reply