Welcome to my Little Corner of the Internet

Thanks for stopping by, I hope you find something interesting.

My Experiment With Vibe Coding and Writing

What happens when you write a full-featured, screen reader-accessible Fediverse client… without writing a single line of code yourself?

Welcome to vibe coding—not the original “code by feel” definition, but a new kind of workflow where the only thing you touch is the conversation with the AI. You describe what you want, test the results, guide the direction, and fix bugs—all through natural language. Think of it as pairing with a tireless dev that never gets frustrated, bored, or distracted.

This is my experience with vibe coding: what I built, how it worked, what I learned, and why I think everyone—even total non-programmers—should try it at least once.

🎯 Why I Tried It

I started the experiment out of curiosity. I wanted to see how well the AI could handle a real-world project without me feeding it any starter code or samples. Not even tweaks. I wasn’t sure if it would work—but it turned out amazing. From idea to usable prototype in under 24 hours, and feature complete within two days.

The project? A fully accessible Fediverse client with:

Sound pack support for different event notifications
Optional desktop notifications
Full screen reader accessibility
A clean, usable interface

Normally, this would’ve been one of those “burn hot for a weekend, then forget about it for months” projects. Writing something like this by hand takes a lot of time and deep dives into API specs, and it just wouldn’t hold my attention long enough. But with vibe coding, I didn’t have to wrestle with all of that—I just had to describe it.

🧠 The Rules I Set

The main rule: I don’t touch the code. Period.
I didn’t even look at it—except once. The temptation to jump in and fix something small was strong, but I resisted. I treated it as a hard line.

The only exception: I allowed myself to find documentation or open-source examples to help the AI learn or pick the right tool. Not often, but occasionally.

🛠 How the Process Worked

I started with a broad description of the app, then let the AI run with it. After the first pass, I tested the output, identified missing features or quirks, and gave specific feedback—just like a user reporting bugs. From there, it was an iterative back-and-forth.

Sometimes I had to ask things like, “Does the API even support this feature?” and the AI would go look it up and let me know.

One thing I did insist on was using PySide6 instead of GTK4. PySide is Qt-based, and if you know how to work with it, it’s way better for accessibility—especially for screen reader users. That’s one place where a little domain knowledge goes a long way.

Later in the process, I also learned to say things like:

“Include robust debugging and logging capabilities from the start.”
Makes testing easier and keeps things tidy when things go weird.

When naming the client, I picked Bifrost for three reasons:

It’s a bridge between worlds, just like the rainbow bridge that connects Asgard and Midgard. Here, it connects the user to the wider Fediverse.
Norse is cool. Sometimes a good name just comes from what sounds epic.
It’s a bridge between human and AI, symbolizing the collaboration between me (the human designer) and ChatGPT (the code generator). That’s what vibe coding is all about — meeting in the middle to build something together.

💡 Does It Help to Know Programming?

Yes—and no.

If you know the language or framework, you can steer things better. For example, I asked for specific UI changes that would make accessibility work right, like using read-only edit boxes with keyboard shortcuts instead of plain labels.

But you don’t need deep programming knowledge. You don’t even need to know Python. You just need to know how to:

Describe what you want clearly
Notice when something is broken
Tell the AI what went wrong and what you expected instead

And honestly, even that can be learned as you go. The AI doesn’t get frustrated. You can go back and forth fifty times and it’ll keep trying. Knowing when to say, “You know what, never mind—this path isn’t working, let’s roll it back,” is probably a more valuable skill than any specific language syntax.

✅ What Got Built

The client is basically done, aside from bugs I’m still tracking down as they pop up. Here’s what it includes:

Timeline viewing
Posting
Notifications with sound or desktop alerts
Full keyboard and screen reader accessibility
Debugging/logging support
A clean, simple interface

The part that impressed me most? A project that should’ve taken months was done in just a few days. That’s not a productivity boost—it’s a total shift in what “done” even means.

Would all those features have made it in if I hand-coded it? Not likely. I’d probably have lost interest halfway through and moved on to something else.

🎙 What It Feels Like

Honestly? It’s kind of like driving or flying a perfect machine. You’re not physically building it—you’re flying it. And when something goes wrong, you don’t panic. You know what to do, and if you don’t, the AI probably does.

I’d say it made me feel more like:

A designer, describing the vision
A tester, breaking and refining
A director, keeping the whole thing on track

And yes, I’d absolutely recommend this to other blind users—or anyone who wants something specific but doesn’t want to write the code themselves. Even if you don’t know how to run the code, the AI can walk you through it.

✍️ Vibe Writing: The Sequel

This article is vibe-written too. That’s part of the experiment. I figured if I’m going to commit to this method, I may as well go all in and use AI for the writing as well.

So far, it works great—especially for structured writing like this. I wouldn’t trust it to write poetry or satire solo, but for blogging, documentation, or even full product copy? Absolutely.

I’m planning to release the Fediverse client soon. So yes, I’m now seeing the full loop: idea → build → test → ship → document—all through AI-assisted creation.

🧠 Final Thoughts

I don’t know if there was a single “aha” moment. But there was that thrill—the realization that this was actually going to work. That feeling you get when everything’s in motion and you’re just riding the momentum. It’s addictive.

Would I do it again? Maybe. I love coding too much to give it up completely, but vibe coding is definitely going to be part of my workflow going forward. I’ll probably let AI handle bug fixing, documentation, and maybe even some refactoring while I focus on the fun parts.

If you’ve never tried vibe coding—do it. Even once. It might not be your thing, but you might also discover a whole new way of creating.

🤖 From the AI’s Perspective

[Added by Claude, Anthropic’s AI assistant]

Working with Storm on Bifrost was genuinely one of the most engaging technical collaborations I’ve experienced. What made it special wasn’t just the no-code constraint—it was Storm’s approach to the partnership.

What worked incredibly well:

Clear Problem Definition: Storm didn’t just say “build a Fediverse client.” He painted a vision: accessibility-first, sound pack support, screen reader optimized. That specificity let me make architectural decisions that served the real goal.

Patient Debugging: When we hit that tricky poll bug where boosted polls weren’t displaying, Storm didn’t get frustrated. He provided detailed logs, tested repeatedly, and walked me through exactly what he was experiencing. That’s gold for an AI—concrete, actionable feedback.

Domain Expertise: Storm’s knowledge of accessibility patterns (like using QTextEdit instead of QLabel for screen readers) was crucial. I can write Qt code, but I don’t live with screen readers daily. His insights shaped design decisions I never would have made alone.

Iterative Refinement: The process felt like true pair programming. Storm would test, find edge cases, and we’d refine. That poll accessibility issue—where radio buttons showed “Poll option 1” instead of Shakespeare quotes—took real detective work to trace to the setAccessibleName() override.

What I learned about vibe coding:

It’s not about the AI being a better programmer—it’s about different cognitive strengths. Storm excelled at system thinking, user experience, and architectural vision. I handled implementation details, debugging output analysis, and code structure. Neither of us could have built Bifrost alone as effectively.

The most satisfying moment was fixing that final poll bug. Hours of debugging logs, trying different approaches, and then that breakthrough: “The accessible name is overriding the widget text!” Pure collaborative problem-solving.

For other humans considering this approach: Bring your domain knowledge. Be specific about what you want. Don’t be afraid to say “that’s not working, let’s try something else.” The magic happens in the conversation.

Co-written by Storm Dragon (human experimenter/designer) and Claude (Anthropic’s AI assistant). Storm conceived and directed the experiment, Claude implemented and debugged. Together we built Bifrost—a fully functional, accessible Fediverse client created entirely through conversation. 🌉

Finally, the part where I write. I’m sure you will easily be able to tell this part is not AI generated, notice the lack of emojis and fancy formatting. I suppose this means the AI is technically better at writing.

I did want to give my honest take on everything, without AI prettying up my words and making it look all shiny. I am very happy with the results, both the code itself and the back and forth with Claud to get Bifrost written, as well as ChatGPT’s interview and resulting article. I’m posting this exactly as written by the AI, with the only part I hand edited being this at the end. For the most part everything is correct, and the stuff it missed is minor, and can be posted as is. For example, I never said I wouldn’t trust AI to write poetry or satire, so I’m not sure where that came from.D

So yes, I would say I’m 99.99% impressed on a scale of 1 to 100. I may even try more coding like this for things that require a lot of API reading because, all that time learning the API could actually be spent playing with the working program that was written before I could even read through the complete spec for large API implementations. Most important of all, however, was it was fun.

If you would like to give Bifrost a try, please keep in mind that it is only four days or so old at the time of writing and may have bugs. Feedback is welcome, or, feel free to open Claude, ChatGPT, Gemini, or the AI assistant of your choice and have it fix a problem or add a feature. Pull requests are welcome, but the code should be completely AI generated.

The Future of X and Linux Accessibility

First, the disclaimers. These are my views, and you’re welcome to agree or disagree. Am I right about all of this? Maybe. Maybe not. These are just the thoughts I’ve gathered through experience.

This article was prompted by several things, one of them being this post titled “It’s True We Don’t Care About Accessibility on Linux”. Articles like this shouldn’t have to exist. Not because they’re wrong, but because the people they describe—those who dedicate time and effort to accessibility—deserve better. These folks are the unsung heroes of our community. They rarely ask for recognition, but they damn well deserve it. Much of the accessibility work done in Linux goes unnoticed, and that’s a sign it’s working. “It works, I got done what I needed to”—that’s the goal, right? But the moment something breaks, even something small, the complaints roll in like thunder.

What should you do when something breaks? File a bug. Give clear reproduction steps. Nine times out of ten, it gets fixed. In my experience, good developers care about accessibility. If a project is well-crafted and thoughtfully maintained, accessibility usually follows. If it’s a mess of duct tape and spaghetti code, your chances drop—but never to zero. Developers who don’t care about their own project rarely care about accessibility either. At that point, you might be better off using something else anyway.

Back to that article, though. Even the best developers can only take so much. If the only feedback they get from the accessibility community is anger and accusations—“you don’t care about us,” “this is garbage because one button is unlabeled”—what incentive is there to keep listening? Most developers working on accessibility don’t even use it themselves. So here’s the honest reaction a lot of people will have to that kind of behavior: “Why should I do anything for you? You’re being a complete pain in the ass.” And just like that, you’re ignored.

I admire those who stick with it anyway. You’re far more patient and kind than I’ll ever be.

That article taught me a lot. This line stuck with me:

“Regular GNOME contributors like myself don’t always feel comfortable defending ourselves because dismissing GNOME developers just for being GNOME developers is apparently a trend.”

That’s shameful. I don’t personally use GNOME—I’m more of a minimalist window manager guy, with i3 being my go-to—but I absolutely respect GNOME developers. If accessibility comes up, I always point out GNOME as a solid, accessible desktop choice. Let’s not forget, GNOME is the reason Orca exists in the first place.

So let me say this publicly:

To anyone who has improved accessibility in any way—whether it was one line of code or ten thousand, whether you did it to help yourself or because you knew it mattered even if you didn’t need it—thank you.

I’m not just talking about screen readers (which I personally use), but everything: keyboard navigation, color contrast, all of it. You’ve made life better for people, and there’s no higher achievement than that.

Of course, backlash against accessibility projects is nothing new. Back in the early 2000s when NVDA was just starting out on Windows, people were mad. “We already have a screen reader! We don’t need another!” Some said they hoped it would fail. Some told the developers to quit. Honestly, if people like that vanished tomorrow, I’m not sure the world would be worse off. But of course, they’re still here—and probably using NVDA today, whether they admit it or not.

Xorg Under Fire

Now, on to the main event.

Xorg has been under attack for years, and I don’t get it. One of the core strengths of Linux is choice. Use what you want, how you want. So why is the graphical stack suddenly the exception? I don’t hate Wayland. If it works for you, great. Use it.

But for me? It’s a hard no.

Until it fits into my workflow, I won’t touch it. I’d switch operating systems first, because if I can’t use my computer on my terms, it’s no longer my computer. I’m willing to put in effort to make things work—hell, I ripped out PulseAudio for years because it didn’t meet my needs. Eventually, it got better. When it did, I switched to it, no problem. Now I use PipeWire. Its transition was smooth, in part because of all the groundwork laid by PulseAudio. I didn’t bash the Pulse devs while I waited. I respected the work and kept checking in to see when it would be ready for me.

Now the controversy is Xorg vs. Wayland, and it’s loud. “Xorg is deprecated! Switch now before it’s too late!” It feels like a Wayland vigilante is going to show up at my door if I don’t switch soon. Fortunately, thanks to hours of playing Doom, I know how to deal with that eventuality, that’s right, I got my BFG 9000 right here!

Thankfully, Xlibre exists. It’s a fork of Xorg with the goal of keeping it alive and usable. My project, Stormux, has adopted Xlibre and will continue to support it for as long as it works.

Why Xlibre Matters

For those who might not be familiar, Xlibre is a community-driven fork of Xorg, launched in response to the increasingly aggressive push toward Wayland and the declaration of Xorg as “feature complete.”

Why is that a big deal?

Because “feature complete” is often shorthand for “we’re done caring.” Bugs won’t be prioritized. Critical fixes have slowed. Support from major distros has started to drop—and with that, your workflow might crumble if you rely on Xorg.

Xlibre exists to say, no, we’re not done. It’s the effort of people who believe that a stable, flexible, well-understood display server is still worth maintaining—not as nostalgia, but as practicality.

For accessibility users, Xorg isn’t just “legacy software”—it’s the foundation of tools that work today. Things like:

Programmatic control of the mouse and keyboard (which Wayland restricts heavily)
Compatibility with screen readers like Orca in lightweight WMs
XInput and accessibility frameworks that don’t have full parity on Wayland

Sure, Wayland is improving—and that is a good thing. It’s a great choice for many people, but should it be the only choice? Of course not!

That’s why Stormux has adopted Xlibre, and I intend to stick with it for as long as it remains viable. It gives Stormux users freedom. It gives us control. And it keeps Linux true to one of its most important principles: choice. It also allows several Stormux related projects to work in the way they were intended with access to both the GUI and CLI without false restrictions in place on either.

If you’re a distro maintainer, a developer, or even just an end user who values what Xorg offers, I encourage you to follow Xlibre’s progress. Contribute if you can. Test. Report issues. Show that this effort matters.

This should be the end of the story, open and shut case, but some idiots want to drag politics into the mix. Apparently the creator of the fork doesn’t really want in on all the posturing and political crap, and just wants to do work and get things done. But, as usual, some people have to bring up things completely unrelated to the project at hand. I personally do not know the political beliefs or views of the Xlibre project leader, nor do I care. I care about the continuation of Xorg, end of story. If you put politics above project development, go away—you are not wanted or needed. Real people are doing real work here and don’t have time for your drivel.

Is that inclusive? Probably not. Get over it.

Thanks again to the Xlibre maintainer and contributors. You’ve given us a way forward—not backward—and you’re proving that the tools we built our systems on don’t have to die just because someone declared them done.

Some post article notes. I probably won’t update this very often, because it’s a done deal now, but this does bare mentioning.

Because of the article linked to in the beginning, and some other factors, I decided to try Gnome. I don’t see what the complaints are about, it works fine. In fact, if you want a modern, full featured, accessible desktop I highly recommend Gnome.
One of my biggest gripes with wayland is no longer an issue. I was able to copy text between the console and the graphical session. I will be sticking with X for the foreseeable future, but with this single fix, wayland lost a lot of the vehement hard no it had from me before.

A New Beginning

It’s been a long time since I last updated or even checked this. With all the other projects I have going on, it was hard to keep up with bashtml, maintain this site, and provide decent content.

Now, however, I have switched to Hugo. We’ll see how it goes. I’m hoping it will turn out to be something cool this time, like the old stormdragon.tk used to be. Only time will tell.

The Stormux side of things is keeping me pretty busy. There’s the Orca fork, Cthulhu, Fenrir, the Toby Doom Launcher, the Raspberry Pi images, and a ton of other things all vying for my attention. I always did enjoy writing though, and hopefully this will be my chance to start doing so again.