ryannewso.me - The Cognitive Shift How AI Changed What I Think About as a Solo Dev

I’ve been building Notevision — a piano sight-reading iOS app — for over ten years. For most of that decade, my brain was split between two jobs: figuring out what to build, and figuring out how to build it. I spent most of my time focusing on implementation details to the point where I would neglect thinking about the product itself.

That has changed this year with the adoption of AI as a development resource.

The Old Loop

Here is how I used to work

1. Decide on a new feature
2. Context-switch into the codebase and re-learn the code I will need to change
3. Spend hours focused on implementation details
4. Forget what I was originally trying to accomplish
5. Eventually ship something
6. Support the release with any follow ups
7. Context switch out of developer to more product focused

The bottleneck was never ideas. It was the cognitive tax of implementation.

The New Loop

Now my process looks different:

1. Have an idea
2. Stay in product-thinking mode
3. Work with AI to handle the implementation friction
4. Keep thinking about the product while the code takes shape
5. Spend most of my time QA testing what is written which allows me to continue to stay focused on the product
6. Incrementally ship while always working on the next feature.

The key insight isn’t that AI writes code for me. It’s that AI absorbs the cognitive load that used to knock me out of product-thinking mode. I don’t lose an hour re-learning my own codebase every time I sit down. I don’t get derailed by boilerplate. I stay in the headspace where I’m asking “what should this product be?” instead of “why is this crashing?”

What This Actually Looks Like

Let me give you real examples from the past two weeks.

Cleaning Up a Decade of Debt

Notevision’s codebase had accumulated ten years of dead code. Abandoned view controllers. An entire audio library (ObjectAL) that nothing referenced anymore. A data model from 2014 that was still in the project but hadn’t been used in years. A “delete history” button that silently did nothing.

I knew all of this existed. I’d been stepping around it for years, the way you stop noticing a pile of boxes in your garage. The cleanup was always “someday” work because manually auditing 10 years of Objective-C and Swift code is brutally tedious.

With AI, I did the full audit and cleanup in a day. ~70 files removed. ~20,000 lines of dead code gone. The audio library, six orphaned view controllers, dead methods scattered across the codebase — all identified, verified safe to remove, and deleted in one focused session. I also found that the “Erase History” feature had been silently broken (calling a function that no longer did anything) and fixed it.

That’s not a speed improvement. That’s a category change. “Someday” work became “today” work because the cognitive cost collapsed.

Building a Feature System, Then Open-Sourcing It

I built an XP and leveling system for Notevision — experience points for practicing, daily streaks, level progression. The kind of gamification loop that keeps people coming back.

The engine itself needed to handle accuracy bonuses, speed bonuses, streak multipliers, daily goals, retroactive XP for existing users, and a leveling curve that felt right. I also needed crash hardening across the entire codebase (28 fixes across 17 files) because adding a new system to a 10-year-old app means stress-testing everything it touches.

Here’s the part that surprised me: after building the XP engine inside Notevision, I extracted it into a standalone open-source Swift package. Wrote 56 tests. Published it as PracticeXP on GitHub with an MIT license.

In the old world, open-sourcing a module from your production app is a luxury project. You have to untangle the dependencies, write a clean API, add comprehensive tests, write documentation — that’s days of work that don’t directly help your users. I’d never have prioritized it because there are so many features I want to add. But with AI handling the extraction grunt work, the cost dropped low enough that the strategic value easily justified it. Hopefully it can help others in a similar situation.

Redesigning the Lesson System

Right now I’m rebuilding Notevision’s entire guided lesson curriculum from scratch. New pedagogical sequence. MusicXML-based exercises instead of the old random approach. Landmark note methodology. Proper scaffolding from single notes up through intervals and beyond.

This is a big project. But what’s different is how I’m spending my time on it. I’m thinking about curriculum design — which concepts should come first, what range of notes is appropriate for beginners, how to scaffold difficulty. I’m making pedagogical decisions, not fighting with file formats and build systems.

When a corrupted project file broke the new lessons, the debugging that would’ve cost me an afternoon was resolved in minutes. When I needed self-sizing table cells and smoother scroll animations, that UI polish happened in passing instead of becoming its own task.

The friction that used to slow everything down just… isn’t there the same way.

What AI Doesn’t Change

I want to be honest about what hasn’t changed, because the hype machine around AI coding tools tends to skip this part.

Architecture decisions are still hard. AI can help implement a pattern, but deciding which pattern — or whether to refactor versus rebuild versus live with the mess — that’s still entirely on me.

Product instincts are still yours. Should Notevision add streaks? What should the leveling curve feel like? Should lessons use MusicXML or a custom format? These are judgment calls built on ten years of watching how people use my app. AI has no opinion here, and shouldn’t.

Taste still matters. AI will happily generate code that works but feels wrong. Over-engineered. Under-considered. You still need to know what good looks like in your codebase.

The hard parts of solo development — deciding what to build, prioritizing ruthlessly, understanding your users, maintaining quality — are exactly as hard as they’ve always been. AI didn’t touch those. What it did was clear the path so I spend more of my day on those hard parts instead of on the mechanical ones.

The Real Shift

Before AI, I was a solo developer who spent maybe 10% of my time on product decisions and 90% on implementation. Now those numbers are closer to flipped.

I’m not shipping faster in a “10x developer” sense. I’m shipping differently. Things that were too tedious to justify now get done. Cleanup happens. Polish happens. Side quests like open-sourcing a module actually happen. And through all of it, I stay in the headspace of “what should this product be?” instead of constantly dropping into “how do I make this code work?”

For a solo developer, that’s everything. You don’t have a product manager thinking about the product while you code. You don’t have a team to parallelize the work. It’s just you, and your time is split between thinking and doing. AI compressed the “doing” so there’s more room for “thinking.”

Ten years in, I’m building faster than I ever have. Not because the code writes itself — but because I finally have the headspace to focus on what matters.

---

I’m Ryan, and I’ve been building Notevision — a piano sight-reading training app — for over 10 years. Follow the journey on X/Twitter.