While I agree with the post in its entirety, I think it would have been worth mentioning DeepSeek V4 Flash as well, which, in my view, had already reached a sufficient, if not high-level of agentic coding before GLM 5.2 (see DwarfStar).
Clearly, Kubernetes wasn’t the right solution for your case, and I also agree that using it for smaller architectures is overkill. That said, it’s the standard for large-scale production platforms that need reproducibility and high availability. As of today I don’t see many *truly* viable alternatives and honestly I haven't even seen them.
> Discord is used by a bunch of closeted users having pseudos, who wouldn't do the same activities on it if everyone had their names.
Exactly. I am sure they won't share their face or ID and will move somewhere else. Big opportunity for other platforms to stand up and grow their user base.
I just run a local microVM. I built a small CLI that wraps lima to make my life easier. With a few commands I have a VM running locally with all batteries included (CC/Codex, ssh, packages I need, ...). With this I'm not saying Deno or Docker sandboxes are useless.
Probably an ideal compromise solution for you would be to install the official Claude Code extension for VS Code, so you have an IDE for navigating large, complex codebases while still having CC integration.
> That said, if vibe coding is the process of producing software without much understanding of what is going on [...], automatic programming is the process of producing software that attempts to be high quality and strictly following the producer's vision of the software [...], with the help of AI assistance.
He is absolutely right here, and I think in this article he has "shaped" the direction of future software engineering (which is already happening actually): we are moving closer and closer to a new way of writing code. But this time, for real. I mean that it will increasingly become the standard. Just as in the past an architect used to draw every detail by hand, while today much of the operational work is delegated to parametric software, CAD, BIM, and so on. The architect does not "draw less" because they know less, but because the value of their work has shifted. This is a concept we've repeated often in recent months, with the advent of Opus 4.5 and 5.2-Codex. But I think that here antirez has given it the right shape and also did well to distinguish it from mere vibecoding, which, as far as I'm concerned, are two radically different approaches.
I had the same idea, forcing the agent to execute code inside a WASM instance, and I've developed a few proof of concepts over the past few weeks. The latest solution I adopted was to provide a WASM instance as a sandbox and use MCP to supply the tool calls to the agent. However, it hasn't seemed flexible enough for all use cases to me. On top of that, there's also the issue of supporting the various possible runtimes.
In any case, what would be the problem? The page you mentioned simply illustrates how the product can be used in a specific domain; it doesn't seem forced to me.
How slow? In some contexts, the trade-off might be acceptable. From what I've seen in pizlonator's tweets, in some cases the difference in speed didn't seem drastic to me.
> When anyone can vibe code, it is the ones with "good taste" in the design of systems that will thrive. Anyone can use an agent and code fast; few will be able to do it fast and well and build systems that do not eventually collapse under the weight of their own tangled mess.