How I’ve been using AI on a side project as a playground

A side project with mobile app built in Flutter with a companion website. I try to keep it simple with some resources hosted in S3. Nothing too unusual. But for the past few weeks I’ve been using it as a playground to explore AI-assisted development – not just using AI, but really leaning into it to see how far it goes.

I’m not writing any code at all. I simply communicate with the agent in broken English. I don’t even try to be specific or technical – I just describe what I want to see in a sentence. The results are mindblowing.

The Setup

The project has two parts: a static website and a Flutter mobile app. Both are being built entirely through AI. I’m not touching the codebase directly. My job is to describe what I want and then see what comes back.

A side project is the right place for this kind of exploration. There’s no deadline, no stakeholder. That freedom lets you push things further than you would on a client project or at work – you can try things that might not work, follow a direction just to see where it leads, and throw away the result without consequence. It becomes less about shipping and more about understanding what’s actually possible.

I have different agents set up for different kinds of work. A marketing agent, a content agent. In practice this means each agent has its own context – its own understanding of the project’s tone, goals and constraints. The marketing agent knows how the product should be positioned. The content agent knows the subject matter and the format lessons should follow. When you mix all of that into a single context, things get blurry. The model starts making compromises between concerns that should stay separate. Splitting them out keeps each one focused.

This also connects to one of the more useful things Claude supports: persistent context. You can save a file – a CLAUDE.md in the project root – that Claude reads at the start of every conversation. It’s not magic, it’s just a text file. But it means you don’t have to re-explain the basics every time. The design system, the brand tone, the tech stack, the conventions – write them down once and they’re always there. Claude walks into each session already knowing the ground rules. For a project you return to in short bursts, this makes a real difference.

The Tools I’ve Used

Before landing on my current setup I used Copilot, Cursor, and others. They’re all useful in different ways.

Cursor has a similar feel in terms of the interface – clean, accessible, low friction. These tools make the interaction comfortable, which matters more than people admit.

JetBrains Junie gets overlooked because people assume it’s a lesser alternative. But here’s the thing – it’s integrated directly into JetBrains IDEs. If you’re already working in IntelliJ or any other JetBrains product, Junie adds nothing new to your stack. It’s just there. Same interface, same shortcuts, same mental model. For day-to-day tasks, that convenience is real. It doesn’t ask you to change how you work. At the same time, I use this one less since I reserve it for real work, not the playground. I mentally prepare to use it only for selected, simple tasks where I know it will excel without risk.

Why Claude Code Is Different

Claude Code in the console is a different beast.

I’m currently paying for Claude, Junie, and Cursor – deliberately, so I can compare them. I want to know what each one actually does. And after going through that comparison, Claude Code is the one that surprised me most.

The results are consistently good. Not “good for AI.” Just good. I write in broken English, I give vague instructions and I still get results that work. I don’t always give specific design direction because this is a side project and I want to be surprised. Half the time I don’t know what I want until I see what comes back. That dynamic works well with Claude. It doesn’t get confused by ambiguity – it makes reasonable choices and you can react to them.

It’s a different way of working. I built a professional-looking website and a full mobile app in a matter of hours, using nothing but sentences. I didn’t touch the code once. Both work. Both look good. Both match what I had in my head – and sometimes exceed it. I know someone might say “sure, but it’s not shipped” and fair enough. But I have the technical skills to build this myself and it would have taken me months of tireless work to get to the same place. That’s not an exaggeration. This beast is fast and powerful.

The app might only be useful to me right now. It’s not in production, not distributed. But the result is genuinely good. And I want to be honest – this is a simple project, simple UI. But it’s still more complicated than plenty of things I’ve shipped or used over the years. Will this work for a complex system with critical business logic, edge cases, and hard reliability requirements? Probably not, or at least not yet. But not every business need is rocket science. A lot of what gets built professionally is straightforward – another internal tool, another marketing site, another informational landing page. For that kind of work this is remarkable. If you need to deliver yet another info website, the idea that you can go from nothing to something professional in an afternoon is genuinely hard to process until it happens to you.

And here’s the part I find most interesting: I deliberately give vague design instructions. I want to see what Claude produces before I impose my own ideas. Most of the time, what comes back is better than what I had in mind. I’m not saying this to be dramatic – it just keeps happening. You describe an intention and something better than your intention shows up on screen. That’s the part that’s hard to explain until you’ve seen it for yourself.

What This Actually Looks Like

I describe something. Claude builds it. Sometimes I redirect, sometimes I just accept what it made. For a side project that’s also a playground, this is the right mode. I’m not trying to control every pixel. I’m trying to learn what these tools can do when you actually trust them.

The Flutter side of things, the website, the content pipeline – all of it is moving faster than it would if I were writing the code myself. Not because I can’t write code, but because the iteration loop is shorter when you’re working at the level of intent rather than implementation.

If you’re still watching AI coding tools from the sidelines, waiting to see if they’re real, stop waiting. Claude Code through the CLI is the real deal. It’s not a novelty. It’s a different way of working.

Junie is underrated for teams already in JetBrains – it costs nothing in terms of workflow disruption. Cursor is polished and approachable. But if you want to understand where this is all going, you need to spend time in Claude Code.

And the rabbit hole goes further than you’d expect. Claude Code runs in the terminal, which means you can SSH into your laptop from your phone and interact with it from anywhere. I’ve also experimented with the Claude API directly – sending it real, non-sensitive production data and asking it to process or reason over it via API requests. It’s more expensive than the standard subscription, but it opens up a completely different set of
possibilities. You’re not just chatting with an AI anymore, you’re wiring it into actual workflows.

The people who start exploring this now are the ones who will have a meaningful advantage later. That’s not a prediction. This is a gamechanger now. Late adopters, like me, will need to catch up.