The Addiction of AI, the Economics of Tokens, and Building with Claude

I started with free ChatGPT. Asked it random questions, tested its limits, saw how it could write code and work through problems. No friction. No cost. No thought required.

Then I realized I could actually build with it.

Getting Serious

The shift was immediate and noticeable. Instead of asking questions and getting answers, I was describing ideas and getting implementations. Paste an error, get a fix. Describe a feature, get code. Ask for a refactor, get multiple approaches. The feedback loop changed everything.

Three projects happened this way. MonteMiles is a running training app. TheBa.sh is an AI news aggregator. Sudomoji is a puzzle game. Each started as an idea I sketched out, then turned into working code deployed and live. That's when I understood what people mean by addictive. The output is real. The timeline is compressed. The ability to go from concept to deployed product in hours instead of weeks fundamentally changes how you think about building.

Free tools don't give you this workflow. Neither does any traditional development approach I've used.

The Token Problem

Free ChatGPT has limits. Premium membership extends them. But serious development work burns tokens fast. When you're refactoring across multiple files, debugging edge cases, exploring architectural options, or reading through error logs, the tokens get consumed in a way that's hard to predict.

I hit the limit mid-session three times in the past month. Mid-feature both times. The interruption breaks the workflow.

The first time was surprising. The second time was annoying. By the third time I understood the pattern. Tokens are the constraint now. They're not abstract. They're the functional limit on how long you can think through complex problems. If you want to work at pace, you need tokens. Continuously.

The cost model is the issue. You pay per month for a token limit. Hit the limit, you wait or pay more. This works fine for occasional use. For development workflows, it's a real constraint. For hobby projects it's annoying. For commercial projects it could mean the difference between viability and not.

This matters because the industry is moving. We're not at "AI-powered features" anymore. We're at "AI-driven development workflows." The token economics will matter as much as compute economics mattered ten years ago. Anyone serious about building with these tools needs to budget tokens the way they budget API calls or database queries.

Building with My Daughter

The practical productivity gains are one thing. The other thing was showing my daughter how this works.

She watched me describe features to Claude. Watched me get back working code. Watched me refactor when it wasn't quite right. We built Sudomoji together. I'd sketch out a feature. Claude would implement it. I'd show her the result. She'd play it, ask for changes. We'd iterate.

Five years ago this takes weeks if it happens at all. The overhead is too high. You're blocked on implementation details. The iteration speed was brutal.

Now the bottleneck is ideas, not implementation. That's a different kind of development experience.

Current State

What started as exploration has become infrastructure. Three live projects. A site to track them. A backlog of real projects waiting for time and tokens.

The pattern is obvious. Started with free ChatGPT as a curiosity. Moved to building specific projects with Claude. Now I have a whole ecosystem of tools, infrastructure, and workflows supporting ongoing creation.

Constraints Going Forward

The token limit will shape how I work. I'll batch similar tasks to reduce back-and-forth. I'll plan sessions more carefully. I'll break large problems into smaller pieces. I'll be more intentional about what I ask the AI to do.

What won't change is the pace. The feedback loops are too valuable. The ability to iterate on complex problems with AI assistance is too powerful. It's changed how I think about development.

The next projects are waiting. Tokens will stay expensive. And my daughter is already asking about the next game we can build.

I'm ready for that.