I arrived at a very similar conclusion since trying Claude Code with Opus 4.5 (a huge paradigm shift in terms of tech and tools). I've been calling it "zen coding", where you treat the codebase like a zen garden. You maintain a mental map of the codebase, spec everything before prompting for the implementation, and review every diff line by line. The AI is a tool to implement the system design, not the system designer itself (at least not for now...).
The distinction drawn between both concepts matters. The expertise is in knowing what to spec and catching when the output deviates from your design. Though, the tech is so good now that a carefully reviewed spec will be reliably implemented by a state-of-the-art LLM. The same LLM that produces mediocre code for a vague request will produce solid code when guided by someone who understands the system deeply enough to constrain it. This is the difference between vibe coding and zen coding.
Zen coders are masters of their craft; vibe coders are amateurs having fun.
And to be clear, nothing wrong with being an amateur and having fun. I "vibe code" several areas with AI that are not really coding, but other fields where I don't have professional knowledge in. And it's great, because LLMs try to bring you closer to the top of human knowledge on any field, so as an amateur it is incredible to experience it.
If you're this meticulous is it really any faster than writing code manually? I have found that in cases where I do care about the line-by-line it's actually slower to run it through Claude. It's only where I want to shovel it out that it's faster.
I really like the capability enforcement model, it's a great concept. One thing this discussion is missing though is the ecosystem layer. Sandboxing solves execution safety, but there's a parallel problem: how do agents discover and compose tools portably across frameworks? Right now every framework has its own tool format and registry (or none at all). WASM's component model actually solves this — you get typed interfaces (WIT), language interop, and composability for free. I've been building a registry and runtime (also based on wasmtime!) for this: components written in any language, published to a shared registry, runnable locally or in the cloud. Sandboxes like amla-sandbox could be a consumer of these components. https://asterai.io/why
The ecosystem layer is a hard but very important problem to solve. Right now we define tools in Python on the host side, but I see a clear path to WIT-defined components. The registry of portable tools is very compelling.
Shell commands work for individual tools, but you lose composability. If you want to chain components that share a sandboxed environment, say, add a tracing component alongside an OTP confirmation layer that gates sensitive actions, you need a shared runtime and typed interfaces. That's the layer I'm building with asterai: standard substrate so components compose without glue code. Plus, having a central ecosystem lets you add features like the traceability with almost 1 click complexity. Of course, this only wins long term if WASM wins.
How does the AI compose tools? Asking it to write a script in some language that both you and the AI know seems like a pretty natural approach. It helps if there's an ecosystem of common libraries available, and that's not so easy to build.
In my example above I wasn't referring to AI composing the tools, but you as the agent builder composing the tool call workflow. So, I suppose we can call it AI-time composition vs build-time composition.
For example, say you have a shell script to make a bank transfer. This just makes an API call to your bank.
You can't trust the AI to reliably make a call to your traceability tool, and then to your OTP confirmation gate, and only then to proceed with the bank transfer. This will eventually fail and be compromised.
If you're running your agent on a "composable tool runtime", rather than raw shell for tool calls, you can easily make it so the "transfer $500 to Alice" call always goes through the route trace -> confirm OTP -> validate action. This is configured at build time.
Your alternative with raw shell would be to program the tool itself to follow this workflow, but then you'd end up with a lot of duplicate source code if you have the same workflow for different tool calls.
Of course, any AI agent SDK will let you configure these workflows. But they are locked to their own ecosystems, it's not a global ecosystem like you can achieve with WASM, allowing for interop between components written in any language.
I don't think you're being too harsh, but I do think you're missing the point.
OpenClaw is just an idea of what's coming. Of what the future of human-software interface will look like.
People already know what it will look like to some extent. We will no longer have UIs there you have dozens or hundreds of buttons as the norm, instead you will talk to an LLM/agent that will trigger the workflows you need through natural language. AI will eat UI.
Of course, OpenClaw/Moltbot/Clawdbot has lots of security issues. That's not really their fault, the industry has not yet reached consensus on how to fix these issues. But OpenClaw's rapid rise to popularity (fastest growing GH repo by star count ever) shows how people want that future to come ASAP. The security problems do need to be solved. And I believe they will be, soon.
I think the demand comes also from the people wanting an open agent. We don't want the agentic future to be mainly closed behind big tech ecosystems. OpenClaw plants that flag now, setting a boundary that people will have their data stored locally (even if inference happens remotely, though that may not be the status quo forever).
Excellent comment. I do agree - current use cases I've seen online are from either people craving attention ("if you don't use this now you are behind"), or from people who need to automate their lives to an extreme degree.
This tool opens the doors to a path where you control the memory you want the LLM to remember and use - you can edit and sync those files on all your machines and it gives you a sense of control. It's also a very nice way to use crons for your LLMs.
The only solution I can think of at the moment is a human in the loop, authorising every sensitive action. Of course it has the classic tradeoff between convenience and security, but it would work. For it to work properly, the human needs to take a minute or so reviewing the content associated with request before authorising the action.
For most actions that don't have much content, this could work well as a simple phone popup where you authorise or deny.
The annoying parts would be if you want the agent to reply to an email that has a full PDF or a lot of text, you'd have to review to make sure the content does not include prompt injections. I think this can be further mitigated and improved with static analysis tools specifically for this purpose.
But I think it helps to think of it not as a way to prevent LLMs to be prompt injected. I see social engineering as the equivalent of prompt injection but for humans. So if you have a personal assistant, you'd also them to be careful with that and to authorise certain sensitive actions every time they happen. And you would definitely want this for things like making payments, changing subscriptions, etc.
You might be okaying actions hundreds or thousands of times before you encounter an injection attack, at which point you probably aren't reading things before you approve.
I agree, that's the main issue with this approach. Long-term, it should only be used for truly sensitive actions. More mundane things like replying to emails will need a better solution.
I don’t think it’s wrong to see it as Anthropic’s constitution that Claude has to follow. Claude governs over your data/property when you ask it to perform as an agent, similarly to how company directors govern the company which is the shareholders property. I think it’s just semantics.
I think this hasn't been yet achieved because components need to interface with each other easily. This requires a standard that all components implement, from which everything can be assembled together.
From that perspective, the idea of microservices is basically "IKEA for software" relying on (primarily) HTTP as the interface between components. But this doesn't really solve it entirely, or very elegantly, because you still need to write the server boilerplate and deploy it, which will be different depending on the programming language being used. Also, your app may require different protocols, so you'll be relying on different standards for different component interactions, therefore the interface is not constant across your entire application.
I believe there's one way we can achieve this reliably, which is via WebAssembly, specifically via the WASM component model [1].
But we need an ecosystem of components, and building an ecosystem that everyone uses and contributes to will likely be the challenging part. I'm actually working on this right now, the platform I've been building (asterai.io) started out as an agent building platform (using WASM components for tool calls) but is evolving into being mostly a registry and (open source) lightweight runtime for WASM components.
The idea of using WASM to solve for this is very simple in concept. Think about a tool like Docker, but instead of images you have an "environment" which is a file that defines a set of WASM components and ENV vars. That's basically it, you can then run that environment which will run all components that are executable. Components can call each other dynamically, so a component can act as a library as well, or it may be only a library and not an executable. A component can also only define an interface (which other components can implement), rather than contain any implementation code.
This architecture solves the main challenges that stop "IKEA for software" from being a reality:
1. You can write WASM components in any programming language.
2. You can add components to your environment/app with a single click, and interfacing is standardised via WIT [2].
3. Deploying it is the same process for any component or app.
Of course, it still would require significant WASM adoption to become a reality. But I think WASM is the best bet for this.
What problems have you had with joins?
I have this comment in one of my projects:
```
It is required to mark left-joined columns in the query as nullable, otherwise SQLx expects them to not be null even though it is a left join. For more information, see the link below:
https://github.com/launchbadge/sqlx/issues/367#issuecomment-...
```
Did you have other problems beyond this, or are you referring to something different?
The issue above is a bit annoying but not enough that I'd switch to an ORM over it. I think SQLx overall is great.
I've always liked the concept of ECS, but I agree with this, although I have very limited experience with Bevy. If I were to write a game in Rust, I would most likely not choose ECS and Bevy because of two reasons: 1. Bevy will have lots of breaking changes as pointed in the post, and 2. ECS is almost always not required -- you can make performant games without ECS, and if with your own engine then you retain full control over breaking changes and API design compromises.
I think all posts I have seen regarding migrating away from writing a game in Rust were using Bevy, which is interesting. I do think Bevy is awesome and great, but it's a complex project.
The distinction drawn between both concepts matters. The expertise is in knowing what to spec and catching when the output deviates from your design. Though, the tech is so good now that a carefully reviewed spec will be reliably implemented by a state-of-the-art LLM. The same LLM that produces mediocre code for a vague request will produce solid code when guided by someone who understands the system deeply enough to constrain it. This is the difference between vibe coding and zen coding.
Zen coders are masters of their craft; vibe coders are amateurs having fun.
And to be clear, nothing wrong with being an amateur and having fun. I "vibe code" several areas with AI that are not really coding, but other fields where I don't have professional knowledge in. And it's great, because LLMs try to bring you closer to the top of human knowledge on any field, so as an amateur it is incredible to experience it.
reply