After a spell working on a software project where I'm trying to use prompt-driven development to build something the "right" way, I took a break last week to indulge in pure vibecoding. I set out to build an RSS reader inspired by retro computer terminals and newswire printers. (I've since learned that this retro-terminal aesthetic is having a moment, as called out in John Maeda's Design Report 2025.)
I began by describing my idea to Claude. To really indulge the terminal aesthetic I specified a Python project. I don't know Python very well, so I would really be at the mercy of the LLM.
The core idea came together quickly—a terminal-like interface displaying headlines from various feeds. The vibes were feeling very good.
With the basic version working, I started thinking about enhancements. Claude helpfully added the current time on its own, so how about adding the local weather too? What if I could select articles and see their descriptions? Can we tweak the animation when the feeds refresh so it feels more authentic?
Each of these ideas was just "one more thing" to almost effortlessly add. The project was becoming more ambitious, but still felt manageable.
Then I noticed a problem: the count of total new articles wasn't correct.
"This should be easy to fix," I thought. A straightforward counting issue—the kind of thing that might take one or two rounds of prompting to track down and resolve.
An hour later, I was still wrestling with it.
I tried different models, asking in the IDE, chatting in the web UI... each AI assistant confidently identified different "problems" and offered fixes that didn't work. I tried everything except look at the code.
This is a little embarrassing, but after a couple of hours I remembered that this counter feature wasn't even something I had asked for. When the LLM added it to the app it seemed useful, if I'd even noticed it at all.
Realizing the insignificance of this feature, I had a moment of clarity: Remove it. In my traditional role as a product manager, this decision would be obvious and straightforward—focus on what matters and ruthlessly cut what doesn't.
Reflecting on this project, I see some lessons I'll keep in mind when building with AI tools:
-
Be conscious about roles – consciously switch between user, product manager, designer, developer, and even user perspectives rather than getting stuck in one mindset. (And be cognizant of which role you are asking the AI to play.)
-
Discount AI confidence – recognize that AI's certainty about solutions doesn't necessarily reflect the difficulty or importance of a problem.
-
Practice feature discipline – be especially vigilant about feature creep when AI makes implementation seem easy. Each new feature adds some drag to the future velocity of the project.
-
Focus on outcomes, not solutions – be intentional about the goal of a project or feature, and stay focused on working toward that outcome (even if it means throwing away work).
Technical implementation is getting easier, but in my experience very few software projects fail for purely technical reasons. Strategy, communication, and project management are all more likely to prevent a promising idea from coming to life. The wisdom to discover what's worth building and when to say "enough" remains as relevant as ever.
In the end, I removed the problematic counter. I have my nostalgic terminal news experience with the features that actually mattered to me. Sound interesting? Check it out on Github.
P.S. As an experiement, I asked Claude to refactor the codebase into an iPad app. Believe it or not, it successfully did in less time than it took my M1 Macbook Air to build and launch the app!