Stephan Miller

Posted on Sep 15 • Originally published at stephanmiller.com on Sep 15

The Great Vibe Coding Experiment - How I Built 15 Projects with AI in My Spare Time

#vibecoding

I started this whole thing wanting to test Claude Desktop with MCPs. Just one little experiment. You know how that goes.

Six months later, I’ve got 15 projects in various states of “done” and a GitHub commit chart that doesn’t look too crazy until you realize that most days I only have a couple of hours to experiment with this, when I do have time.

Welcome to “vibe coding”: building shit because it feels right and letting AI do most of the heavy lifting. It’s not agile development. It’s not waterfall. And as I’ve done more of it, it has become let chaotic and more stuctured. Most nights I work on two projects simultaneously.

When Vibe Coding Becomes Automated Spec-Driven Development
The Obsidian Plugin Empire
The Bigger Fish: Apps That Do Real Shit
Tool Whose Name Shall Not Be Spoken
How These Projects Work Together
What I Learned About AI-Assisted Development
What’s Next: The AI Development Army
Conclusion: Embrace the Chaos

When Vibe Coding Becomes Automated Spec-Driven Development

Vibe coding is when you have an idea, fire up an AI coding assistant, and see what happens. No detailed specs. No project management software. Just “hey AI, build me a thing that does X” and then iterating until it works or you get distracted by building something else.

But there was a reason I abandoned my first vibe coding project. I just added random features to an idea that I can up with on the fly and thought maybe ten minutes about. I just wanted to see what it could do. But the second project, I knew I needed some kind of rails.

The next step was to get out of this loop:

Tell the AI tool to create the feature
Test the result and tell the AI tool to fix the errors and failed tests
Maybe do that again or a few more times, copying and pasting errors
Ask the AI tool how to prevent this from happening with a better prompt

And realize it could be a self-optimizing process of:

Actor: Have an agent write the code
Auditor: Have an agent review the code and run the tests (multiple types of auditor) and either pass or fail and send back to Actor
Process Improver: Have an agent examine the steps that caused the failed process and update the commands, agent definitions, or other project docs to prevent them in the future

All because you can trust AI to do what you thought you told it to do. And this trail of projects documents my journey towards that goal.

The Obsidian Plugin Empire

Apple Books Highlights Plugin: Hacking SQLite

I built this plugin with Claude Desktop and MCPs, documented the whole process in this vibe coding post. The plugin actually works. I use it daily. It extracts annotations from the macOS Books SQLite database and creates formatted markdown notes.

Joplin Portal: My First Test of Kiro

I had all these notes in Joplin that I wanted to access from Obsidian. So I fired up Kiro AI and told it to build me https://github.com/eristoddle/joplin-portal. Kiro did most of the work.

The surprising thing about letting AI write plugins is that they actually follow best practices better than I do. Kiro created proper TypeScript interfaces, handled errors gracefully, and even added settings panels I didn’t ask for.

Daily Note Prompts: An Extension I Am Using

Another Kiro collaboration. This one adds customizable prompts to daily notes. I actually use this, which is more than I can say for many of the plugins I’ve tried.

It still needs some work, but it works for me for now. I’m just keeping a running list of changes I want to make to it and bugs I’ve run into and one of these days, I’ll put the list in one of these AI coding tools and set it to work.

Tag Explorer 3D: Testing a Shiny New Tool

I started this project the day after making my list of existing projects. Why? Because I wanted to test a new AI tool (can’t name it yet) and needed something to build.

Tag Explorer 3D visualizes your Obsidian tags and notes with those tags in 3D space. Is it necessary? Probably not. Is it cool? Absolutely. Sometimes you build things because they’re interesting, not because they solve real problems.

Attachment Cleaner: Simple But Necessary

Really simple plugin built with the same unnamed AI tool. It finds and removes unused attachments from your vault. I keep blog posts drafts there and paste images in, which gets stored there and they get forgotten when I move the draft.

I need to test it more, but the code looks solid. It’s often better at the simple, boring stuff than the complex, interesting stuff if you want AI coding to work. And I may turn it into a general clean up tool, because I am also tired of tracking down conflicted files.

The Bigger Fish: Apps That Do Real Shit

Plugins are fun, but eventually you want to build something more substantial. That’s where things got interesting.

Gatsby Site with Scraper: The Abandoned First Project

This was my first attempt at vibe coding. I wanted to build a Gatsby site with an integrated scraper using Claude Desktop and MCPs.

I abandoned it. Not because it didn’t work, but because I realized I was building it the wrong way. Sometimes the most important decision is knowing when to stop.

GitWrite: When Jules Met Agentic Project Manager

GitWrite is an abstraction over git for writers, editors, and beta readers. I built it with Jules AI, used an Agentic Project Manager to coordinate, and finished it up with Qoder. Well, it said it was finished and I am still working my way around to testing it’s full functionality. Just made the mistake of finishing it before I needed it.

It exists to support EmberText and other writing tools I’m building. I am really, really, really tired of being required to use things like “Suggesting” in Word and Google Docs. Who thought this thing up? Satan? I like Git better but it needed dumbed down in some places and tweaked in others to do what I needed.

EmberText: My First Claude Code Experiment

EmberText was my first serious relationship with Claude Code. I built an Electron app for writers, rolling my own context and project management system.

Claude Code has quirks. It’s opinionated about project structure. It sometimes goes off on tangents. But when it works, it does pretty well. EmberText is a fully functional app that I am testing, but I also need to refactor it to use some of the services I am building, so it is probably the last of these project that will be finished.

MDQuery: Fed Up with Proprietary Tools

I got tired of proprietary MCPs and tools to search systems that essentially consist of markdown files: Obsidian, Joplin, Jekyll, Log Seq, and on and on. So I built a universal tool with Kiro and Qoder.

MDQuery provides SQL-like syntax for searching and analyzing markdown files across different note-taking systems and static site generators. Because fuck trying custom MCPs that don’t work the way you want for each and every markdown based platform.

And I already had a job lined up for the tool. I had been collecting everything interesting around vibe coding and spec-driven development in my Obsidian vault under a specific tag. Developers were going in so many directions that I wanted to categorize and get an overview. We’re all blind developers describing different parts of this elephant. Maybe if we categorize what we’re all doing, I can be a little less blind. I recently found this post on Claude Code framework wars that does just that.

So I attached the MCP to Claude desktop and prompted it to analyze all of my Obsidian notes, using the prompts the AI tools had put in the documentation. And it spit out an 80 page document.

AutoVibe: The Meta Project

AutoVibe is the most recursive project I’ve ever built. I’m using Claude Code, AI Studio, and Backlog.md to build a tool that will make the vibe coding process smoother.

It’s infrastructure for building infrastructure. Custom commands and agents to coordinate AI tools. The future of development might be less about writing code and more about conducting orchestras of AI agents. At least, that’s what I think it is. But it’s like a box of chocolates.

AutoVibe Template: The Stop-Gap Solution

While AutoVibe has bugs to work out, I needed something that worked now. So I built a template with a set of Claude commands and agents that, when used with Backlog.md and Claude Code, makes developing projects more bullet-resistant.

I used Claude Desktop to help develop it since the template is full of AI instruction files that other tools would try to execute. But then I sort of got stuck testing its usage in the next project. So now the priority is getting AutoVibe to work and keep the simple template.

ShopBoth: Testing the Template (and Learning Hard Lessons)

I used Claude Code with my Backlog.md template to build ShopBoth, a React Native app for testing and tweaking the template. Why did I choose React Native for testing? Because I’m an idiot.

I also discovered that “generic” automated QA doesn’t exist. QA needs to be specific to the platform, the framework, the use case. There ain’t no such thing as universal testing, and I learned that the hard way.

Tool Whose Name Shall Not Be Spoken

I’ve built three more apps with an AI tool I can tell you about in a couple of weeks. They add to the ecosystem:

BookForge transforms markdown files into professional ebooks. It supports EmberText and GitWrite, completing the writing workflow.
PromptOS stores and provides prompts for EmberText, AutoVibe, and everything else. Because managing prompts across 15 projects gets complicated fast.
Site Factory brings me full circle to that abandoned Gatsby project, but with actual research this time.

These aren’t random projects. They’re pieces of a larger system for AI-assisted content creation and development.

Update: I actually built one more project while I was writing this. It’s a platform to provide dynamic services for static sites.

How These Projects Work Together

This isn’t just a collection of random tools. There’s method to the madness:

EmberText handles writing → GitWrite manages collaboration → BookForge generates ebooks
PromptOS supports everything with prompt management
Obsidian plugins feed the writing process with research and notes
MDQuery searches across all the markdown files these tools create
AutoVibe coordinates the development of new tools

It’s an actual ecosystem, not just 15 disconnected projects. Each piece makes the others more useful.

What I Learned About AI-Assisted Development

Each AI Tool Has Its Own Personality

Claude Desktop: Great for planning and architecture, terrible for actually writing code. It’s the project manager that never writes any code. Mainly because chat lengths are limited. As soon as you get somewhere, you have to start a new chat and lose the context. I do use it to develop git templates for AI-driven coding projects, because it will ignore the instruction files I have it tweak.
Claude Code: I am not sure if it is still the best after using Qoder and the new tool I have. I still use it almost daily to work on projects and it’s my goto tool, but the limit comes up quicker now and it seems like it has dropped some IQ points. Not sure about it status in my workflow right now.
Kiro: The reliable workhorse. Give it a clear task and it delivers solid, working code. Perfect for plugins and smaller projects. After seeing how the new tool I found works, I wonder if it breaks things down into too many tasks. To create an Obsidian plugin, it broke it down into 16 tasks I had to click to get through and it took a few hours. The new tool just decided it would build a plugin for me in 15 minutes.
Jules: I still use it for small things, like fixing bugs, because I still get 15 free chats a day. I actually built most of GitWrite with it.
Qoder: Set it loose on a complex project and come back in a few hours to find it’s built everything you asked for and more. The wikis it build are useful but I think would eat up a lot of tokens in large codebases.
Unnamed Tool: The new experiment. Still figuring out its personality. But it’s fast. It finished the two Obsidian plugins in less than an hour, both of them. It built the other full projects in one day, all of them.

The Process That Emerged

Start with an actual need, not cool technology. I tried building technology first and it never worked.
Let AI handle the boilerplate and focus on the interesting problems. AI is great at CRUD operations and terrible at creative problem-solving.
Build infrastructure projects to support main projects. GitWrite exists so EmberText can focus on writing, not version control. Also, hoping less scope mean less context an AI tool needs
Test new AI tools with real projects, not demos. You learn more building something you’ll actually use.

Why 15 Projects Makes Sense (Sort Of)

Each project taught me something new about working with different AI tools.
Building an ecosystem requires multiple pieces. You can’t do everything with one app.
Some projects exist only to support other projects. That’s fine.
Abandoning projects is part of the process. That abandoned Gatsby site taught me what not to build.
The commit chart tells the story. Bursts of activity when testing new tools. Long gaps when focusing on one complex project.

What’s Next: The AI Development Army

AutoVibe is getting closer to making this process smoother. The template approach gives consistent results. The unnamed AI tool projects will add new capabilities.

I’m building a sustainable vibe coding workflow that lets me maintain 15+ projects without losing my mind. The future of development might be more like conducting an orchestra than playing a solo instrument.

Conclusion: Embrace the Chaos

I started wanting to try Claude Desktop with MCPs. I ended up with 15 projects, a completely new development process, and insights into how AI-assisted development actually works.

The learning process matters more than perfect planning. AI tools are getting good enough to enable this kind of scattered productivity. You can afford to be curious, to follow tangents, to build infrastructure for projects that don’t exist yet.

Vibe coding and spec-driven development isn’t for everyone. But if you’re comfortable with chaos (Yes, even in spec-driven development), if you like building things just to see what happens, if you want to push the boundaries of what one person can build with AI assistance, give it a try.

Just don’t blame me when you end up with 15 projects and a commit chart that looks like madness. That’s the price you pay. And while I was finishing this up, I started another project. I had to give my new tool something to work on before the free ride runs out.

DEV Community