The Tool Chain

The first version of LifeRunner was built with ChatGPT and a lot of copy and paste. GPT Codex wasn’t available yet, and frankly I wouldn’t have been able to use it at the time if it was.

But talking to ChatGPT in the desktop app was magic enough for me. I described what I wanted, and ChatGPT gave me code.

It became a Streamlit app. Not pretty, but fast to ship and hard to break. For someone ‘building’ their first ‘real thing’, that was exactly the point. Streamlit is forgiving. It’s a supportive gym spotter for bad code.

The early versions were full of tells: random emojis in headers, helpful tooltips explaining obvious buttons to the one person who built the app and the same one person using it. A UI that screams, “A model wrote this and nobody argued.” (something becoming more and more common, but more on that later).

I kept it anyway. It worked. I could click buttons instead of fighting a form, and I had a progress bar that reacted in real time. That small feedback loop mattered more than polish. It even cycled through a series of quotes that I’d kept in some random note for years. A little bit of a personalization already.

The workflow, though, was rough. Every feature was a negotiation. Ask for a change, paste the code, hit an error, paste the error, try again, hit a different error. Progress happened, but it didn’t feel like building. It felt like being the middle person between a model and a codebase that didn’t want to cooperate.

At some point it was clear Gemini’s models had pulled ahead. I was stuck in a context-losing copy-paste war with ChatGPT, and Gemini solved a few issues I’d been circling for days. But the workflow was the same. I was still the intermediary between a model and a codebase, ferrying code back and forth and hoping nothing broke in transit.

It was also never clear when the model lost ‘context’ and would begin forgetting things I’d already told it earlier in the conversation. I slowly got better at recapping sessions, crafting prompts, providing details the model would need, etc.

How else are you supposed to learn other than by using these tools?

The major shift was when a friend walked me through Claude Code, and the whole interaction changed.

Claude Code works inside your project. It reads your files, edits them directly, and runs commands. The first time I used it, I described a feature and watched it appear in my actual codebase. Not as a suggestion, not as a code block, but as real changes in real files.

Suddenly I could stay at the level of intent. “Here’s what I want this screen to do.” That’s a language I already speak. After a decade in tech overseeing customer success teams, I had skills that transfer nicely when your builder is a model.

I started moving faster than my own planning. Features that had been sitting on my list for months went from idea to working in a single session. The bottleneck shifted from “can I do this” to “what’s worth doing next.” Of course, there are disadvantages to shipping every idea that occurs to you, rather than thinking out a holistic vision for how the product should work.

I found myself learning lessons I’d seen occur a million times over working in tech. Except now it was happening to me, on some weird speedrun equivalent powered by these new tools, and without any coding skills.

Fast forward a month or two - LifeRunner’s habit tracker had grown into a gym companion app and rudimentary finance tracker. But it had also outgrown its Streamlit shell. I knew it needed a rewrite.

I just didn’t expect to do it from a pool chair. More on that in Part 3.