Why I've Stopped Building Apps and Started Building Instruments

Personal Paradigm Shift

As a perpetual hobbyist coder, I’ve always loved the program while hating the actual experience of programming. Attempts at coding my first Java-Android app games in my teens were thwarted when I realized all my friends had iPhones. Woe to walled gardens. Brute-forcing my way through C# and C++ for Unity and Unreal Engine looked like copy-pasting tutorial code and trial-and-error changing things line by line to figure out how they worked (mainly by breaking things). I could never shake the feeling that frameworks meant there was some platonic ideal way to code any problem, and I just didn’t have the stomach for the rote memorization required to git gud. I quickly decided in college that I would prefer to ideate and lean into design rather than be the one engineering projects.

Of course, this made me the ideal subject to be swept away with agentic coding euphoria. A few hours with Claude turned into Shopify project ideas, 3D modeling assistance, and tons of useless software. I then realized that my gaming PC rig and more importantly my RTX 5090 could run local AI, and from there I found myself addicted to figuring out the ideal agentic workflow; landing on having frontier models like GPT Sol and Claude Opus 5.5 ideate and plan while Qwen 3.8 27B NVFP4 burned tokens locally through NInfer.

Originally I thought my lifelong dabbling and couple of college courses in programming were a boon for my work with agentic programming. Quickly though, I realized I was carrying mostly bad or dated habits with me. Despite my best efforts I was making something worse than AI slop: I was somehow making outdated slop. What I needed in order to make this hobby continue to be worthwhile was a paradigm shift on how I thought about what agents should be doing. Part of that was to stop focusing on the programming and focus instead on the program itself. The other part was to get out of the way of coding agents, and trust them the way I would trust an engineer I paid.

Vibe-Coded DNF

A prime example of my outmoded thinking is the first iteration of a partnered reading app I vibe-coded entirely with Claude Code in VS Code (even my workflow I used in the spring feels outdated already). I had spent 2026 enamored with apps that used my Apple Watch to keep me on track with my health and fitness: Nike Run Club, Apple Fitness+, Strava, etc. I was addicted to closing rings, getting notifications from friends about mutual goal completion and sharing my runs. I wanted to transfer that gamification of life to my reading habits, as I had unfortunately traded a productive 2025 reading year to a 2026 fitness year, with reading being totally sacrificed in that trade. I figured I could parallel the fitness apps, and the best way to do so was to make it a partnered reading app from jump.

Coming from dabbling in programming in the 2010s, I did a quick sketch of the app on my reMarkable, shared the mockups with Claude and immediately directed it to start prototyping. Of course Claude talked me out of a purely personal project and instead directed me to make it a SaaS product: a standalone, multiplatform app that I would share with the world. We worked through screens, databases, auth, and Expo testing. I spent a lot of time reading about habit tracking, accountability, and ideating with Claude about whether the partnered aspect of the app truly improved reading retention. I used local image models to generate all of the app’s art, which turned out wildly inconsistent due to constant idea switching on my end and weak prompting.

Based on my prior experience with app dev, I felt like I was going at warp speed, but now I realize how many tokens I was wasting retreading ground and worrying about everything but the MVP. By the time I got to the store launch step, I lost steam when I realized deployment meant privacy policy, support, billing, etc. and honestly I refused to add another vibe-coded project to the waste pile formerly known as the App Store. It kinda knocked me out of my vibe coding euphoria, as I realized I had spent the better part of a week after work sending prompts just to have a final product that not only looked exclusively like a Claude vibe-coded app, but also was only like 80% to MVP.

I shelved it and moved on. Instead of wasting tokens on building slop, I spent a good amount of time in the trenches researching and personally testing the capabilities of local models and what good (or at least better) frameworks and prompting looked like.

Beautiful Computers

After spending some time wandering the virtual desert, I made the important decision to revive an old gaming laptop while I waited for my Framework 13 Pro pre-order to be fulfilled. My old MSI still has decent specs, but Windows 11 had bloated and wrecked the thing so the OS SSD was suffocating and I couldn’t get programs to run right as overflow caches etc. would tank performance. I had always heard that Linux could breathe life into machines, and right around this time I had seen a bunch of Omarchy Quattro hype, so I hopped on the train.

Not only did I fall in love with the OS, but I fell in love with the design philosophy. I adore that the OS feels like a living repo, with great ideas and design being layered on top of an exposed ecosystem that I can point my agents at and upgrade. Notice how I say upgrade and not fix, a huge improvement to my prior Linux or frankly PC experience overall. The longer I was off Windows and Mac machines and spent time around an agent-native environment, including one that had multiple workspaces easily baked into the UX, the more I revamped my thought process re: development using agents.

I not only wanted to control the ideation phase with my agents by steering them towards efficiency and beauty in design, but I also realized I needed to steer them away from outdated dev patterns; i.e., developing for Web 2.0.

Perhaps I’m tainted by my time playing around in Urbit, but I couldn’t shake this feeling that we had hit a point of gross stagnation in computing and the internet generally, and I had developed a hatred towards SaaS products. Instead of phones becoming more powerful and the web promoting sovereignty, we got digital serfdom, and all dev got dumbed down for the mobile interface. Programs became apps instead of capable products that solved problems. Even if they were web apps, they still had this specific feel, and I feel like most vibe-coding leads to this samey SaaS product, complete with generic website copy promoting it.

The goal going forward then was to approach agentic coding with this philosophy:

1. Only sink time into developing things that solve problems; otherwise that time is better spent finding existing open source software and tinkering with that.
2. Anything I made with agents should be with the best possible software stack for that problem, done efficiently, and designed beautifully, which includes being agent-forward both internally and externally.
3. If I was using agents for developing, then the work should be done in public repos, with open source and open licensing so others could jump in, provide feedback, and solve the same problem better.

Instrument Building

Thus, the personal paradigm shift in how I approach vibe-coding. Something I’ve thrown into the SOUL.md file of my agents is this notion that when developing, we are no longer trying to make apps. “Plug-ins” felt too temporary and inelegant. So I landed on instruments to describe the product my agentic software development created following my philosophy above.

One of my first steps then was to re-attack the paired reading app, but instead of making it a standalone phone app SaaS product, it instead would be a reading-instrument. I would build it in layers, first for personal testing with agents, then as an Omarchy plug-in, then as a general agentic project to be used with Hermes, Meta Muse, etc., and finally a normie version with easier setup and more hand-holding for the agentic integration.

Instead of the software living entirely in the app, the data instead belonged to the user, and the instrument empowered agents to act as the app. A core issue I was having with the standalone app was that of ingestion — not only was the act of tracking reading brutal, but there wasn’t a convenient sensor like the Apple Watch for fitness. How to keep track of physical books, ebooks, audiobooks, etc. was an engineering problem Claude had originally declared defeat on, and it weakened my project scope.

Zooming out to thinking of the project as an instrument to be used with an agent (agnostic on which agent as well), suddenly the ingestion issue seemed trivial, as conversational prompting and cell phone tools like camera and voice became accessible with the agent as the body and skill and tool calling being the function of the instrument; with visual components being more restrained yet more useful, as they lived in the environment users already interface with. Whether they daily drive ChatGPT, Codex, Claude, Hermes, Meta Muse, or Omarchy OS on their computer, the instrument would work.

Obviously, I still have to build it, but you can follow along with the repo here and feel free to use, provide feedback etc. once it is done: reading-instrument on GitHub.

I’ll report back once I’ve completed and tested the project, but I wanted to share how energized I am once again by this scene. Here’s to beautiful, collaborative software.