Switched to Zed from VS Code. It’s really quite cool, mainly in terms of RAM usage and startup time. For my projects, a single VS Code window consumes around 2 GB of RAM, while the same project in Zed consumes around 90 MB. It really is quite insane. And Zed’s cold-start bootup latency is around 3 seconds (for me), compared to around 10-12 seconds in VS Code (before it’s ready to use). I don’t use a lot of extensions in VS Code.
Bah. I just lost all of the work that I did yesterday. I’ve been using a new text editor over the past few months, which I “vibe-coded” for myself using AI. I never really reviewed its code, and it’s worked fairly well so far. Yes, it is vibe-coded in the full sense of the word, and now the bill has come due. Today, a weird race-condition bug in the editor caused an open file to get deleted (along with my work).
Refactored Puppetry by splitting the monolithic single file (3500 lines) into separate modules. Also added thorough test coverage, which will make it easier to develop new features without breaking existing ones. I tested the new version manually, verified that the automated tests cover all the critical paths, and read through all of the test implementations. I also tested on older versions of bpy. The CI deployment job will also automatically run the tests against a bunch of old and new versions of Blender, before releasing to the users.
the concept of batched run might not make sense anymore in Fabricator, since copilot is moving away from request-based billing to token-based. but many of the other providers still have some concept of subscription billing, and I suspect that we might see subscriptions coming back (since subscriptions are good for business, i.e. negative working capital). once the current financial pressure of inference eases a bit. so maybe I’ll keep the batching code intact, but stop using it for now in Fabricator until it makes sense. I’ll also have to start thinking about cleaning up my inputs, and the reasoning level that’s used (higher produces more intermediate tokens, which may not always be necessary). for now, I don’t think I need to react right away, especially since my AI costs are within my monthly budget. So I can worry about efficiency and optimization later, as necessary, and continue to focus on increasing throughput on my task backlog.
ox proved its worth again today. It was much faster and easier to iterate and develop using ox to preview changes (and click things using the virtual controller). I used a real headset only for final verification, and some minor tweaks (like fixing z-fighting). It’s really cumbersome otherwise to keep donning a real headset on/off for every code change, especially when iterating rapidly on a feature.
Migrated findstarlink.com (and its mobile apps) from the TLE to OMM data format for satellite tracking. TLEs use a 5 digit identifier for satellites, and we’ve basically run out of them. This was a very intrusive change in what’s effectively a legacy codebase for me (most of the code has been untouched for 6 years). Celestrak (the source of satellite info) has long-recommended moving to the OMM format, which supports a larger number of satellites. They stopped publishing new TLE data for satellites last week (i.e. early May, 2026), because we’ve run out of possible TLE identifiers.
Ported a financial market analysis tool (that I wrote for myself many years ago, and ran locally) to Cloudflare Workers and R2. I used a custom data storage format for the time-series data with sharding, to work well as static files on R2 (object store). A relational database wasn’t necessary (and wouldn’t fit in the free tier anyway). A GitHub Actions workflow runs every weekday, and fetches the latest market data and updates the static data on R2. The webpage hosted on Cloudflare Workers works with this data via a worker.
The models powering coding agents currently feel more like fuzzy function calls, or Q&A bots. For more complex tasks, it would be better if they (ironically) behave more like chat, where they refine their understanding (and mine too) with follow-up questions and discussion, rather than being biased towards “answering”/“solving” in the very next reply. For e.g. when talking to a freelancer, we’d expect them to ask follow-up questions and clarify the requirements until we’re both sure that we’ve really understood the task. Or maybe even clarify stuff while implementing. “Plan mode” is an okay approximation (especially if you explicitly ask it to list questions for me). But that’s a workaround - the model is not explicitly post-trained/architected for dialogue. And doesn’t come into play during implementation.
Released Easy Diffusion v4.3 (which updates to sdkit v3.2). This adds support for Ernie Image (and Ernie Turbo), as well as improved support for Anima models. It also includes a bunch of bug fixes in the rendering engine (i.e. stable-diffusion.cpp), and a few community-contributed bug fixes to the UI.
Development update for Easy Diffusion: the beta branch has been merged into main, so this releases v3.5 (webui) and v4 to everyone. This shouldn’t affect existing users who’re on the main branch, i.e. people using the v3 engine will continue doing so. The two engines (v3.5 and v4) are marked as optional, so new users will continue to get and use v3 by default. The main purpose of this update is to merge the two forked codebases that we’ve had for over 1.5 years. Now the main and beta branches are back in sync. This brings back the streamlined release process that we had previously, where new changes would first land in beta, and then get merged into main after testing.