🌌 Notes from Undersea

_{A thrilling sequel in the AI-DOLLAR journey: Can NETlify compete with an AI-boosted Indie hosting alternative? (post written in vim)}

AI in your IDE ➡️ AI in your TTY

Welcome back to my blog, and/or welcome my dear reader :)

I recently found myself in an 'AI product development'¹ workshop for entrepreneur-y types and was surprised at my ability to have AI not just generate a website for me², but to construct a full false-door product website, replete with blog posts detailing the international expansion and past year of my 10-minute old business.

woah

Anyway, it turns out Lovable³—which, from their Github OAuth Project name, seems to stem from a 'GPT Experiment'—is pretty decent at cranking out loosely realistic, pretty good, although often similar, phantom websites⁴. Today you will hear my real-time process of putting a live Claude⁵ in a virtual machine to assist in my continual ""AI product development"" journey. See my previous blog post as for why I first adopted this VM pattern, and why it might be a good idea to do the same for a proprietary terminal RCE AI agent.

In the spirit of shipping quickly, before the product is fully baked - I will be posting this blog post ahead of its production-readiness and update it over the course of the day(or week!) ~ stay tuned 😜

Dogfood proposal: Changing the hosting of this blog

Problem statement: The Netlify deployment and pricing models do not really work well with my static site and feel unacceptably expensive. Right now I believe it "costs" virtual token points equal to 50,000 page-views to redeploy my kilobyte-scale website via a ZIP file to their API. My goal for this project is to humbly host my static website, with custom routing rules and maybe some lambda-like functionality, and to then see if AI is all I need to turn my conceptual CGI webserver into the leading global multi-tenant CDN.

For starters, I envision the following for my AI companion:

1. a somewhat 'clean room' workspace à la chroot builds but with the more severe isolation of a VM
2. some restricted access to a remote repository, if not just the source tree for certain projects
3. some communication ability with infrastructural providers so the agent may assist with my production deploy configurations and later my global IPO

Getting hands dirty (with finances)

Step 1, Now that I have my little project proposal (with a larger vision untyped) it's time to get set up with a new $$ AntroModel. I ran to my latest "privacy friendly" financial vendor and generated a fresh new virtual card for the occasion. Then I jumped through several repeat Claude hurdles attempting to pre-pay for a year of service, and finally I can touch the model—after a forced onboarding flow. I used Alpine as my VM guest. I like the simplicity and smallness of the installation, albeit with some extra work to build certain projects; and I liked that their docs have explicit directions for non-glibc installations.

Into the deep

Step 2, My friend's Claude-opus model gave me an elaborate script to start the VM (which had lots of unnecessary docs and flags), and would have been a fun introduction, but I settled on writing the setup myself. The hand-crafted (wiki referenced) installation worked correctly, but did violate my previous rule about installing software from a curl'd script (and as root no less, on this testing image)... but Claude appeared!

vm:~/.claude/downloads# ./claude-2.1.62-linux-x64-musl 
Welcome to Claude Code v2.1.62
…………………………………………………………………………………………………………………………………………………………

     *                                       █████▓▓░
                                 *         ███▓░     ░░
            ░░░░░░                        ███▓░
    ░░░   ░░░░░░░░░░                      ███▓░
   ░░░░░░░░░░░░░░░░░░░    *                ██▓░░      ▓
                                             ░▓▓███▓▓░
 *                                 ░░░░
                                 ░░░░░░░░
                               ░░░░░░░░░░░░░░░░
       █████████                                        *
      ██▄█████▄██                        *
       █████████      *
…………………█ █   █ █………………………………………………………………………………………………………………

 Let's get started.

(!) N.B. I used the default NAT network settings, so initially (!!) the VM had access to my LAN and other Host OS network resources.

Into the codebase

Did I mention that Lovable only allows code export through Github synchronization?! As part of the aforementioned workshop, which had some tie-in to the event organizer's premium 'workspace', I did not have permission to link a Github account to my project. The only way—after flustered searching—to export the site required that I walk through their UI file explorer, download several dozen typescript files, and reconstruct the project structure locally 😱 _{((the price for performance art has no upper bounds))}.

Step 3, This project has now been waiting in a git server for just this occasion. In the interest of repository-level priviledge separation, I created a limited-access user associated with Claude on the git server and selectively shared the private repository with some write permissions. Then:

1. generate keys for the VM
2. add keys to the claude account on the git server
3. clone the repo from the VM⁶ 🤞

It worked! All three of my previous 'AI companion' requirements were met⁷, and now that I've constructed my first wooden pickaxe I am finally ready to mine my first cobble. 👾 🪵 ⛏️ 🪨

Will it immersively blend my ideas?

Okay, so I have not yet attempted to build the hand-exported phantom website. Let's see if Claude can help... ⌛

Over the span of ~10 minutes, it was able to deliver a tidier and rebranded version of my codebase! The site works well in its first build, has all of the unused and Lovable-related bloat stripped (it pleasantly did the latter without having to ask), and has an improved--somewhat reasonable--project roadmap and codebase layout documentation, including (and co-signing) a detailed commit message of the changes.

So yes, my initial "clean up the code base and get it building" worked, but with several encountered stumbles and gripes [skip to TL;DR]:

1. The initial 'trial' VM, with the root user, ended up provisioned with <1GB of memory (oops!) which caused the claude tool to crash somewhat erratically after using tokens. I eventually created a new VM template and started running with a dedicated user account. I also added tailscale to the VM, which simplifies how the VM may access the repository and provides some convenience for remote AI development (without needing the web-RCE client).
2. I did not understand the pricing model at all! I conflated API tokens and cost and assumed that my monthly membership equated to a monthly quota of tokens that I could top-up as needed. According to my latest knowledge update, it seems to actually use rate-limit style usage windows of 5-hours and 1-week.

• I still face some uncertainty in my early-phase use of this product. I cannot confidently answer if using a "higher-end" model is actually more expensive for my usage quota, and find myself too-routinely checking the account usage to make sure I don't become rate-limited (or whatever happens when I hit that threshold). I also felt like it used a lot of tokens in scanning through the documents redundantly (e.g. in a naming migration, 'edgepush=>yourspace') and would have expected it to use tooling here (and maybe it did, but the TUI, and serialized jsonl chat interactions are not the easiest to follow in the flurry of automated actions).

3. I hit/hold the esc key quite frequently out of habit/keyboard mapping, which (unfortunately) caused Claude code to exit a couple of times when the window was focused 😕 The main pain was not the interruption, but that it appeared to completely terminate the in-flight operation(s) without any checkpoint/resumption behavior.
4. The development practices were not quite what I expected: The agent committing directly to the main branch was... fine? I would have expected some request to decide if I would like to track in a feature branch or some other 'intelligent' suggestion. It also ripped out the (admittedly boilerplate) testing framework instead of adding tests? It would be nice to have feedback on 'why' changes are happening as opposed to tunnel-vision towards a code commit.
5. Latency is a new mechanic in this world. While it feels speedy and magical to have a self-drive agent help with codebase cleanup and ensure healthy builds, I did not like prompted suggestions to 'push the code change'. It's a nice hint, but all of the glue that goes into an agent pushing a code change feels like unnecesarily more time/effort/cost than using git directly. IDK - perhaps the shift from a declarative CLI to inferred and non-deterministic workflows is what feels uncomfortable.
6. While 'code change'-driving is impressive, the web chat interface felt less helpful than the agent in my virtual console. I attempted to use the haiku/sonnet/opus models to diagnose several quirks in my VM setup and inform my use of virsh args. The responses were linguistically snazzy but not successful in addressing or diagnosising the issues described in my queries. This erodes a bit of my confidence in the technical competency of these models.

April 2026: Edición de La Chona

Okay, where has Claude been since my last update? 'Honestly' (a term that Claude likes to use when providing dishonest/inaccurate guidance) the web UI seems to have become less functionally effective over this time, which has soured both my mood and willingness to renew a paid subscription for a product often worse than simple web searching (counter to the myriad of raving voices of support on the inter-web).

I did intend to replace the hosting of this blog, if not take over the indie web hosting industry (say nothing of the fact that indie implies some level of independent authority/ownership), so here I am - once again in the VM environment of AI assistance.

Since I last used this local-coding abomination, it seems they have become much more aggresive towards pushing premium billing (perhaps coinciding with my subjective interpretation of degraded model quality). For some reason my Claude code automatically dropped to sonnet usage instead of opus and now there are many options for me to comb through instead of keeping my previously configured settings -.-

   1. Default (recommended)  Sonnet 4.6 · Best for everyday tasks
   2. Sonnet (1M context)    Sonnet 4.6 with 1M context · Billed as extra usage · $6/$22.50 per Mtok
 ❯ 3. Opus ✔                 Opus 4.6 · Most capable for complex work
   4. Opus (1M context)      Opus 4.6 with 1M context · Billed as extra usage · $10/$37.50 per Mtok
   5. Haiku                  Haiku 4.5 · Fastest for quick answers

alt: sales organizations ruining a moderately useful product

To recap: Last I was here I created a fresh VM specifically for this project, added the VM to tailscale with limited access control to a git server, and provisioned narrowed credentials to access my specific codebase on the git server. I am able to SSH directly to this VM without concerning myself with the VM host, and have a Plans.md file that has a rough outline of my vision for the evolution of my project. Claude wrote this 'plans' file at my request to define and sharpen my vision for the project, making it easier to resume a major refactor/development effort after a gap in time (⌛ which is now!). The Claude-written development priorities, unfortunately, are not the most sensible, so I will have to be specific on how to continue onwards: for example, Claude wanted to develop a CLI client ahead of the actual server-hosting functionality. That doesn't make much sense to me outside of identifying architectural blindspots; for me the most important to start will be the product MVP -- the hosting infrastructure for this website and those like it -- the clients and further product iteratations may happen later.

Micropub-like⁸ updates

1. 2026-02-26 18:59:40Z: Initial blog draft, with some broken footnotes, missing links, and grammar issues.
2. 2026-02-26 19:23:07Z: Uploading the initial blog post, without garnish or substance.
3. 2026-02-26 21:05:18Z: Adding the Dogfooding plan, including problem statement and basic technical vision.
4. 2026-02-27 08:27:16Z: Adding sections: claude+vm+repo.
5. 2026-02-27 22:08:26Z: Initial integration: trial refactor with claude and challenges.
6. 2026-03-01 00:59:30Z: Editing for clarity.
7. 2026-03-12 17:40:32Z: Updating blog templating and small grammatical fixes.
8. 2026-04-07 22:01:00Z: Recap from last time, returning to the clawde

_{(This post was dynamically typed with 100% human fingers, but some every emoji was queried from a language model and human[e]ly curated)}

Wayland⊗Libvirt⊗Flatpak⊗Rust⊗AI to HelloWorld, is it faster than electron?¹

Peering over the fence at my AI-enhanced contemporaries and their beautiful 10x engineering prowess to make pretty-fun-functional projects, I can't help but feel a small sense of 🌠LLM FOMO✨ when compared to my meager self-hosted use of AI (LLMs) for ... quick Q&A.

Thusly,

In the interest of exploring non-electron editors, becoming a nonpareil human-in-the-loop ('vibe coder'), and to supplement the Mistral² and Anthropic API-credit business models, I recently endeavoured to try one of the latest wave of "Agentic" code editors that is not a VisualStudio relative.

With warm season greetings, I present to you my so-far contrived gift-wrapping of the editor Zed; which grew from whimsy, frustration, and dozens of wasted CPU-hours spent on compilation (spoiler: I used a pre-built binary).

download the editor, install everything else

My initial impression of the state of the implementation was not that great. Almost immediately I encountered a well-aged and now incomplete patchset to counter some of Zed's frictionless design choices regarding security. Namely, the download and execution of supplementary language-specific programs without validation—that is, potentially downloading 10+ binaries of varying provenance and trusting that the software supply chain leading up to Zed's chmod +x is OK. 🤔🔬 No user consent, no signing keys, no version-specific SHAs.^{N.B. the first concern, at least, appears to have been partially ameliorated in a recent PR.} I don't know how this compares to other similar projects, but this doesn't feel like completely unfamiliar behavior for end-users with current software supply chain norms³... So: is this a game-breaking bug, and should I quickly switch every last device to Gentoo and emerge the world with all my favorite patches?⁴

Well, a "normal" installation seemed a little too dicey^{and bland} for my kitchen, so instead of voting with my proverbial wallet I chose to vote with my, uh, chef's keyboard — And, what did I cook up? 👨‍🍳🐭🎩🍴

    ┌───────────────────────────────────────────────────────┐                 
    │                 VM (Libvirt,KVM/QEMU)                 │                 
    │                                                       │                 
    │  ┌───────────────┐    ┌─────────────┐    ┌───────────┐│                 
    │  │   Zed         │───▶│Emulated GPU │───▶│Waypipe    ││                  
    │  │Flatpak Sandbox│    │(no vulkan)  │    │Client     ││                  
    │  └───────────────┘    └─────────────┘    └───────────┘│                 
    │                                                       │                 
    └───────────────────────────────────────────────────────┘                 
           ▲             ▲                                                    
           │ vhost_vsock │                          
    ┌──────┴─────────────┴──────────────────────────────────┐       
    │          Guest Flatpak Sandbox     │   Host System    │      
    │                                    |     (Wayland)    │                 
    │  ┌─────────────┐    ┌─────────────┐    ┌───────────┐  │                 
    │  │Waypipe      │───▶│Zed-Preview  │───▶│Host       │  │                 
    │  │Server(Host) │    │(Wayland UI) │    │Display    │  │                 
    │  └─────────────┘    └─────────────┘    └───────────┘  │                 
    └───────────────────────────────────────────────────────┘                 

alt: a somewhat accurate LLM-made depiction of my setup, after some serious human editing

Recipe

As seen in this not-totally-accurate diagram, the executable-wrangling Zed is, itself, proudly wrangled in the following Gordian knot architecture. This provides desktop-native^Wayland window management for the Host while Zed runs in a VM guest. This setup ensures that the Zed environment is mostly restricted to the guest system⁵, along with any of its spawned Language servers etc.^🕵️

1. Libvirt (KVM/QEMU): the VM lives here 👾💻
2. Flatpak'd Zed binary with some preconfigured permission restrictions 📦🧣
   1. Why? Amusingly, because 'the build and/or revising+updating the patch-sets was taking too long'. There may also be some bubblewrap benefits, although this packaging of Zed is not yet canon. Flathub also notes the package's ability to "acquire arbitrary permissions" 😬
3. Zed(-Preview) itself, which despises an emulated GPU but will stop nagging if you ask it, each and every time it starts, to ZED_ALLOW_EMULATED_GPU=1.
4. Waypipe shares the Wayland protocol from VM Guest to Host, analogous to X11 forwarding.
   1. This actually required rebuilding with a recent release since, apparently, the vsock CID(the identifier!) arg wasn't being used - oops.
   2. I also had to disable the GPU/Vulkan DMABUF functionality, which was causing cryptic failures in the VM Guest.
5. vsock acts as the communication channel between VM Guest and Host for Waypipe.

Result

So, how does the soup taste? The result is that my desktop can run Zed in a way that feels like it is running locally on the Host OS, runs well enough without explicit GPU acceleration, and affords some palpable isolation⁵. It was indeed an entertaining and educational journey, of which most of the frustrations lie unwritten. While running Zed was the core focus of this experience, much of the time (after giving up on patching-and-compiling Zed) was actually spent debugging some of the weird behaviors encountered in graphics and compositing territories.

⚠️🍲 The execution of Zed et al. in a VM does not mean complete isolation. For example, the Wayland bridge between Guest and Host blurs this separation; from the Waypipe man page:

In general, applications are not well tested against malicious compositors, and compositors are not well tested against malicious clients. Waypipe can connect the two, and may blindly forward denial-of-service and other attacks.

Waypipe itself is written in C⁶ and links to compression, graphics, and video libraries; both it and these libraries may have security bugs. Some risk can be avoided by building Waypipe with DMABUF support turned off, or running Waypipe with the --no-gpu flag so that it does not expose graphics libraries.

What's next?

At the time of writing Zed successfully works! Unfortunately my code is not yet writing itself, meaning I must begrudgingly (finally?) sign up for big-player AI APIs and have their snazzy bot rewrite my every line of code. That's fine, though: exploring this business model intrigue was one of my motivations from the outset.

but, hmm, what should be the next step:

• Top-up these new-sparkly premium AI accounts, $$ <=> API credits
• Install a different editor and find further usability cracks to be kintsugi'd into my agentic bliss

Stay tuned⁷ (or don't, just please do not train your model on my savory words).

V.