HN user

mootoday

87 karma
Posts12
Comments53
View on HN

You don't need a vendor-locked solution for AI agents to work in their own isolated environments :-).

- https://sprites.dev - https://mise.jdx.dev - https://fnox.jdx.dev

Develop a small API that accepts a prompt, starts a sprite sandbox, and then you wait for the AI agent to open a pull request.

I developed that in less than a week and now my client owns the code, can customize it to their needs, and if they want to use a different compute environment, they can with minimal code changes needed.

I built something similar after reading the blog post, based on sprites.dev.

A day of work to get the prototype working and a few hours the next day to allow multiple users to authenticate.

It's surprisingly simple.

After reading the article, I built a tool like that with sprites.dev. There's a websocket to communicate stdout and stderr to the client.

Web app submits the prompt, a sandbox starts on sprites.dev and any Claude output in the sandbox gets piped to the web app for display.

Not sure I can open source it as it's something I built for a client, but ask if you have any questions.

Yeah, I've noticed similar things with my projects. Hard to avoid these days I think.

Awesome, thanks for being an early adopter!

I got some great feedback already, so I'll continue building it out.

Roadmap: - Release binaries for Intel Mac, Linux, Windows - Add / test support for more database engines - Wrap up the LLM integration

Holidays are coming up, it may be a productive time haha

I'm sure everyone has their own tolerance for what is and isn't maintainable :). For me, not knowing what code exists, where it is, how it fits together, and stuffing it all in one main file feels like a recipe for trouble down the road. Sure, I could probably tell the LLM to split the main file into modules and ask it to refactor code etc.

However, from personal experience I'm a lot more efficient when I use LLMs to help with tedious, boilerplate-like code writing but I remain in control over structuring the project so it's maintainable by more than machines only.

I use LLMs every day to write tests for example, it's a massive time saving and I wouldn't want to write tests manually ever again.

Hey, I did not. As mcbetz mentioned, I tried vibe-coding and anything you see is generated by LLMs. He linked to my blog post where I summarized the journey.

ZenQuery looks nice, I like the focus on supporting regular files.

It was frictionless to get everything up and running.

Communication between the frontend and backend is via an `invoke` method, easy as pie :).

It's not open source, but once I get the Apple developer stuff all done, I'll add an auto-update feature and open source it.

A database desktop client, built with Tauri & SvelteKit.

"But there are many already!" I hear the crowd exclaim.

I respond, "Yes, but..."

It's really something I want for myself. Lightweight, as fast as humanly possible, extensible via plugins (in fact the entire app is mostly plugins, with a small core to glue it together), and a tiny bit of LLM (call it AI if you wish) integration to ask questions about the database or generate/review queries.

That's how I feel about most visual database clients I've used over the years...

It's something I hear from many others too, hence my interest in trying to build an incredibly fast and lightweight product.

Thank you, I appreciate the in-depth opinion! I think Tauri with SvelteKit is going to be my first prototype, likely followed by gpui because I'm impressed by Zed which is built with gpui.

Also, TIL about PopOS, thank you!

I recently started to get an interest in writing a GUI with Rust. In particular, a database GUI.

Initially, I thought Tauri with Svelte. Then I learned about gpui (https://www.gpui.rs/) and I'm intrigued.

TIL about iced, which seems to have been around for a while.

Before I embark on building a prototype UI for my app with all three libraries, does anyone have hands-on experience they can share?

Electron vs. Tauri 8 months ago

My personal favorite to keep an eye on is https://www.gpui.rs/.

It's what Zed(.dev) is based on. While not quite ready for prime time from what I understand, if Zed is the reference implementation, I'm sold!

I ended up reading the entire article and what SvelteKit does isn't exactly the same, you can't edit the site.

The use case for a single html file for me is to provide a local dev experience for my customers that mirrors production.

`my-cli dev` spins up the services needed for my platform, including the SvelteKit web app.

I'm heads down building a workflow pipeline builder that executes Wasm Components as part of individual nodes within the pipeline.

Think Zapier or n8n, but you either use existing processing nodes or upload your own code, written of course in any language that compiles to Wasm Components.

It's week 2 but it works and it's live at https://pipestack.dev

What I get is isolation, so I can run untrusted customer code as a Wasm component knowing it runs in a secure sandbox.

Also, scaling across clouds, edge, on-prem with minimal effort.

Another benefit I enjoy now is changing links between components at runtime. I can for example deploy v2.0.0 of a component and send traffic to it by simply updating a link - and reverse it should things break.

All that comes at a much lighter cost in terms of actual $, but also size (kilobytes/megabytes vs megabytes/gigabytes with Docker containers)

I hadn't really been interested in WebAssembly until I read about the component model and the fact that I can run Wasm components on the server.

That led me to wasmCloud[1]. As the article says, Wasm on the server isn't a winner yet, but it has a chance.

[1] https://wasmcloud.com