docs(website): add draft blog posts

packages/website/posts/why-agent-chat-rooms-beat-agent-to-agent-prompting.md

@@ -0,0 +1,45 @@
+---
+title: "Why agent chat rooms beat agent-to-agent prompting"
+description: "Why shared chat rooms are a better coordination model than hidden agent-to-agent prompt chains once tasks stop being trivial."
+date: "2026-03-29"
+draft: "true"
+---
+
+I keep seeing people try to wire agents together by having one agent prompt another directly.
+
+Planner prompts implementer. Implementer prompts reviewer. Reviewer prompts planner again. Maybe it works for a demo. Maybe it even works for a narrow task.
+
+But I think it breaks down pretty quickly.
+
+The problem is that agent-to-agent prompting turns coordination into hidden private messages. The whole workflow disappears into a chain of opaque handoffs. Context gets duplicated, instructions drift, and it becomes hard for the human to see what is going on, step in, or redirect things cleanly.
+
+What has been working much better for me is a shared chat room model.
+
+Instead of agents calling each other directly, they all communicate in a room that the human can also read and participate in. The room becomes the coordination surface. Not just a log, but the place where work gets assigned, clarified, reviewed, and handed off.
+
+That changes a few things.
+
+First, coordination becomes visible. If a planning agent says "I think we should split this into 3 steps", that is just there in the room. If an implementation agent finishes and asks for review, that is there too. The human does not need to reconstruct the workflow from tool logs or imagine what one agent told another 5 minutes ago.
+
+Second, handoff gets cleaner. You are no longer depending on one giant prompt chain staying intact. Agents can join, leave, catch up, and respond to the current shared context. That matters a lot once tasks stop being trivial.
+
+Third, the human stays in the loop without micromanaging. This is the part I care about most. I do not want to disappear into a black box where agents recursively talk to each other and I only see the final result. I want to be able to glance at the room, redirect something, answer a question, or spawn another agent when needed.
+
+Fourth, it matches how collaborative work already feels. A lot of software development is not one linear prompt. It is more like a room with planning, implementation, review, clarification, waiting, and resuming. If that is true for humans, I think it will be true for agents too.
+
+This also connects to a broader point I keep coming back to: a real agent development environment probably needs organizational entities above a single chat.
+
+If every task is just one long chat with one agent, things get messy fast. Once you have parallel tasks, multiple models, review loops, different hosts, or work that continues while you are away from your desk, you need structure. Projects, workspaces, rooms, whatever you want to call them. Some stable place where the work lives.
+
+I think people underestimate this because current demos are still too simple. One agent edits files, another reviews, done. But once you actually live in these tools every day, the bottleneck is not just model quality. It is coordination.
+
+My current belief is that the future is less "one super agent in one chat box" and more "teams of agents collaborating in shared contexts that humans can also inhabit".
+
+Not because it sounds grand. Just because it seems to work better.
+
+If you're building in this space, I'm curious what has been working for you:
+
+- direct agent-to-agent prompting
+- shared rooms
+- workspaces
+- something else entirely

packages/website/posts/why-i-migrated-from-tauri-to-electron.md

@@ -0,0 +1,68 @@
+---
+title: "Why I migrated from Tauri to Electron"
+description: "Why I migrated from Tauri to Electron after rendering, WebKitGTK, notifications, and bundling a Node daemon made the pragmatic choice obvious."
+date: "2026-03-29"
+draft: "true"
+---
+
+I picked Tauri because it felt like the smarter choice.
+
+Smaller runtime, lighter footprint, better story on paper. Electron felt brute-force by comparison. I remember having that feeling of "yeah, I'm not going to ship a whole browser just to build a desktop app."
+
+Then I had to ship a real app.
+
+Not a toy wrapper. A real cross-platform app with stable rendering requirements, a bundled Node daemon, and Linux support.
+
+That's when my opinion started changing.
+
+The first big crack was rendering stability. When you're building something you actually want people to use daily, that matters a lot more than the abstract elegance of the stack. I started caring less about theoretical efficiency and more about whether the UI behaved consistently across machines.
+
+Then came the daemon side.
+
+My app bundles a Node daemon. I spent a long time making that work inside Tauri. And to be fair, I did get it working. But at some point I had this pretty uncomfortable realization:
+
+I was basically reinventing Electron.
+
+I had picked Tauri partly to avoid bundling that whole world, and then product reality pushed me into rebuilding pieces of it anyway. What had started as architectural elegance was turning into self-inflicted complexity.
+
+Then WebKitGTK really pushed it over the edge.
+
+If you care about Linux, WebKitGTK is not some small implementation detail you can ignore. It becomes part of your product. Its bugs become your bugs. Its rendering behavior becomes your rendering behavior.
+
+The WebKitGTK version Tauri picked up by default was old. Wayland did not work at all. After forcing a specific newer version of WebKitGTK and getting things to actually run, the rendering was all over the place. Worse than Safari, which already had its own set of platform-specific bugs I was chasing.
+
+So I had Safari bugs on macOS, a broken or outdated WebKit on Linux, and Wayland not working. Suddenly the "lean" choice did not feel lean anymore.
+
+I even got to the point where I was thinking: if I keep going down this road, I'm going to end up embedding my own renderer anyway.
+
+That was the moment where the whole thing collapsed for me.
+
+Because what exactly was I optimizing for anymore?
+
+But the thing that probably burned me the most was notifications.
+
+In my app, notifications are not a nice-to-have. Users need to click a notification and get taken to the right context. Pretty basic stuff.
+
+Tauri could not handle notification click actions on desktop. You could show a notification, but you could not attach a callback to route the user somewhere when they clicked it. They did implement this for mobile, which honestly made me start to wonder where their focus actually was.
+
+I ended up building platform-specific hacks to get click handling working across macOS and Linux. At that point the benefits of using Tauri were mostly gone. I was writing the glue code myself anyway.
+
+In Electron, this was attaching a callback. That's it.
+
+Electron started looking different after that.
+
+Less "bloated default" and more "boring, stable, pragmatic runtime with fewer platform-specific surprises."
+
+I changed my mind about it.
+
+I still think Tauri is appealing. I get why people choose it. I chose it for the same reasons. And if your app is simple enough, or your platform constraints are different, maybe it's still the right call.
+
+But for me, once the app got real, Electron became the more honest choice.
+
+The lesson I took from this is pretty simple:
+
+Sometimes the "smart" technical choice is only smart in the phase where your product is still hypothetical.
+
+Once you have real requirements, real users, rendering issues, packaging issues, and platform-specific weirdness, the less elegant tool can end up being the more pragmatic one.
+
+If you've gone the other direction, I'd be curious what your app looked like and where Tauri held up better.