Interestingly, I found the original nano banana also has the best latency/quality trade-off that new versions can't beat. This might be domain/prompt specific though. I wonder if there is some truth in the saying that something is either new or improved by never "new and improved".
Agree that good tool should be invisible. We want essential not accidental complexity in how the tool works.
But good tool should also be fun and makes us feel productive. We can't neglect the emotional aspects of designs. And at the end of the day, if a less productive tool makes us much happier, we will less likely be burned out. That is productivity in the long term.
Maybe only AI Agent doesn't care about the emotional aspects fro tool use, but that's a separate topic.
Also, it's not about steep learning curves. We want low floor, high ceiling tools. Some of the examples the author used are either low floor low ceiling, or high floor high ceiling. Neither is ideal.
(1) The original zig code was probably heavily AI coded with lower quality, hence the bag. There is a chance that a full rewrite in zig might do as well but we will never find out.
(2) The rewrite itself is a massively successful marketing move. It shows what Claude code can do and how little it costs compared to human engineering. But the question remains whether someone else, not knowing zig, rust, and TypeScript can pull this off.
No AI is appealing but there is the cliff problem. If there is one small thing the mini language can't handle, the user would have no chance solving it themselves. They might as well start with an LLM solution first.
One workaround is that when there is syntax error, let user optionally switch to LLM?
Is it possible that the coffee drinkers have more social interaction with the barista and others? It's unclear from the paper if they eliminated the confounding factors around coffee drinking.