rellfy

Can't be worse than an Electron app, can it? lol

You can just build things

Well, I think the author correctly identifies productivity as a vector instead of a scalar.

But perhaps a better title would be "Productivity Isn't (Only) About Going Faster"

I didn’t mean it as fact. “Could turn out that …”

Well, (in our current understanding) yes, but there may be underlying aspects of physics and the universe that we do not understand that could be the reason consciousness kicks in. It could turn out that LLMs do work similarly to how humans think, but as an abstracted system it does not have the low level requirements for consciousness.

Are you implying consciousness is magic? Well, I wouldn't disagree with that really.

This is a great concept. I fully agree with small, focused and composable design. I've been exploring a similar direction at asterai.io but focusing more on the tool layer than agent layer, with portable WASM components you write once in any language and compose together.

I currently use Claude web with an MCP component for my workflows but axe looks like it could be a nicer and quicker way to work with the tools I have.

I don't think AI coding means you stop being a craftsman. It is just a different tool. Manual coding is a hand tool, AI coding is a power tool. You still retain all of the knowledge and as much control over the codebase as you want, same with any tool.

It's a different conversation when we talk about people learning to code now though. I'd probably not recommend going for the power tool until you have a solid understanding of the manual tools.

I've spent my weekend building asterbot: https://github.com/asterai-io/asterbot

Asterbot is a modular AI agent where every capability (such as tools, memory, LLM provider etc.) is a swappable WASM component.

Components are written in any language (Rust, Go, Python, JS), sandboxed via WASI, and pulled from the open asterai registry. Think microkernel architecture for AI agents.

That's a great idea, it makes a lot of sense for dynamic use cases.

I suppose I'm thinking of it as a more elegant way of doing something equivalent to top-down agent routing, where the top agent routes to 2-legged agents.

I'd be interested to hear more about how you handle the provenance tracking in practice, especially when the agent chains multiple data sources together. I think my question would be: what's the practical difference between dynamic attenuation and just statically removing the third leg upfront? Is it "just" a more elegant solution, or are there other advantages that I'm missing?

Yes, I definitely think it's much faster than writing it manually. For a few weeks now, >95% of the code I've authored wasn't written manually.

Sometimes you only care about the high level aspect of it. The requirements and the high-level specification. But writing the implementation code can take hours if you're unfamiliar with a specific library, API or framework.

"review every diff line by line" is maybe not the best way to have described it, I essentially I meant that I review the AI's code as if it were a PR written by a team member, so I'd still care about alignment with the rest of the codebase, overall quality, reasonable performance, etc.

The lethal trifecta is the most important problem to be solved in this space right now.

I can only think of two ways to address it:

1. Gate all sensitive operations (i.e. all external data flows) through a manual confirmation system, such as an OTP code that the human operator needs to manually approve every time, and also review the content being sent out. Cons: decision fatigue over time, can only feasibly be used if the agent only communicates externally infrequently or if the decision is easy to make by reading the data flowing out (wouldn't work if you need to review a 20-page PDF every time).

2. Design around the lethal trifecta: your agent can only have 2 legs instead of all 3. I believe this is the most robust approach for all use cases that support it. For example, agents that are privately accessed, and can work with private data and untrusted content but cannot externally communicate.

I'd be interested to know if you have reached similar conclusions or have a different approach to it?

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.

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.

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.

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

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 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).

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.

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.

By that same logic, humans would not be able to do anything novel either.

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.

[1]: https://component-model.bytecodealliance.org [2]: https://component-model.bytecodealliance.org/design/wit.html

n=3

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.

Thanks!

That's a good question. Currently, there is one way to do it. The client querying the agent receives JSON-encoded values that are returned from plugin function calls made by the agent. These values are received alongside the agent token response stream (via SSE). So plugins can essentially emit events that the client can forward to the UI application, such as to click a button etc. The limitation with this is that there is no built-in way to send a success/error status back, it's one way only. It works well for actions that are infallible such as simple UI actions.

The client here would also need a way to interact with the target program of course, e.g. from a JavaScript browser you can click buttons and manipulate the DOM, or from a VSCode Plugin you can interact with the editor etc.

It's definitely something that can be improved though! I've been thinking about some type of MCP interoperability that could maybe assist with this.

I've been working on https://asterai.io -- a platform for developing, running and managing AI agents.

It lets you create multiple agents, configure them via the web console (such as LLM parameters and system prompts) and manage their plugins and functionality.

The system is fully plugin-based, where each plugin is a WASM program that exposes functions/tools that the agent can call, and can also hook into the query lifecycle. Because plugins are WASM, they can be written in various languages such as Rust, Go, TypeScript etc. Plugins can also act as libraries, which is possible because of WebAssembly Components (a great piece of software!) -- so you can dynamically call functions from other plugins within your agent, and you get type support for your chosen language too (with codegen via WASM Components tooling).

More recently, I've been working on an SSH server for agents. The idea is that you can add public keys to your custom agent and then SSH into it to talk to it easily from terminal.

If this sounds interesting, feel free to join our Discord! The project is still new and feedback is highly appreciated. http://asterai.io/discord

There's nothing wrong with releasing software under a license that allows contributions but disallows commercial use, which is what Cyph was attempting to do:

> We're a small startup with a significant amount of time and money invested into the development of Cyph. We recognize the need for anyone to be able to review the code and verify our production build against it from a security perspective, but at the same time it would be problematic if an unrelated third party could just stand up their own instance of Cyph and directly compete with us at this stage. We would be much more inclined to fully open source Cyph at a later stage of the business.

I disagree with the philosophy of forbidding any contributions just because they are not fully open-source for commercial purposes.

This seems like a very common scenario for software that is almost "open source" except for not allowing commercial deployments. I would be surprised if there is no existing licence to cover this use case, but it will not be fully open source of course. Which again doesn't mean that all contributions need to be forbidden.

There is a difference between a design flaw and an implementation flaw though. It seems like for PDFs, those are mostly design flaws, e.g. doing potentially malicious silent tasks in the background without the user's knowledge. Although it could be argued that the OS should be the component guarding against those types of attacks instead of the PDF implementation.

The way you word it, it's as if they were a bunch of tech bros putting microchips in people's brains and running a remote debugger for fun, in a completely unregulated environment.

The people that accept these kinds of implants during a "prototype phase" are usually in a very bad position, so the risk is worth it for them, as the technology can drastically improve their lives.