Introduction
It all started with an ordinary parenting problem. My son — he's nine — constantly wanted more screen time for games and YouTube, and every conversation about it ended in an argument. After a lot of thinking and experimenting with the help of Claude Opus, I arrived at the idea of StarTrack — an app where a kid earns stars for completed tasks and spends them on rewards like screen time. And while working on it, I realized just how dramatically AI has changed the process of building prototypes and MVPs.
The Road to a Solution
My wife and I spent a long time figuring out how to set up a system of control that would be painless both for us and for our son. First we came up with restrictions and rules on our own. That didn't work. Then I discussed the problem with Claude, and it suggested a different approach: don't restrict — reward. A prize for every completed task. It sounded reasonable, and as a bonus, it nudges kids toward chores they'd otherwise put off. The only problem was tracking: both the completed tasks and the rewards. And I thought — why not build an app that takes over tracking progress and awarding points?
Using AI lets you jump straight into testing any hypothesis that comes to mind and might solve your problem. One prompt — and 10–15 minutes later you have a working version that handles the core task. With capabilities like that, the only real constraint is the choice itself: what to build, what to pick, and where the line of "good enough for now" sits. Sure, the code quality won't be perfect, but I've come to like the Pareto principle — 20% of the effort gives you 80% of the result. What if we apply it to writing code, with AI doing the writing? There's no need to burn energy polishing the code and its structure to a shine when a little effort is enough to get a good result. Not excellent, not perfect — good. The kind that works and bears fruit.
And that's when I noticed the bottleneck had shifted: the question is no longer how to build, but what to build.
The Shift in Approach
As you keep working on and improving your product, you want to understand which direction to take next — there can be several paths and solutions. I asked Claude to sketch out three design variants for the main screen. No, they're not perfect, but perfection isn't the goal here and now.
Right there in the chat, you can try out three completely different variants. All it took was context and plain human language. If none of them fit, you can say right there what you like or what you'd want to see — a couple of minutes, and you have new options.
In the end, having picked variant A and prepared a prompt based on its description, Claude Code can implement it right away. Of course, the result will differ visually, but after uploading the mockup and pointing out the flaws, the AI brings the implementation in line with the mockup you're aiming for. All of this takes a couple of clicks and keystrokes — no explanations, no handoffs from one person to another. The design → handoff → code gap disappears.
You can also test not just the visuals but the mechanics themselves. For example, at some point an idea came up: lock the rewards store until the kid finishes the mandatory tasks. It sounded logical — chores first, spending stars later. Instead of arguing about it in theory, I quickly described the mechanic in the chat and got an interactive mockup. And almost immediately it became clear the idea was bad: it freezes stars the kid has already earned, duplicates the existing bonus-unlock mechanic, and breaks if the parent hasn't confirmed a task yet. Fifteen minutes — and the hypothesis was discarded, without a single line of code in the actual app. In the past, I most likely would have coded that idea, discovered the problems in production, and rolled it back.
Running two parallel processes — Claude Code and the Claude web chat — lets you first express a rough idea, discuss it, refine and rework it, and then get a ready prompt or a ready document/mockup to implement in the Claude console. This kind of workflow transforms your role as a developer: you're now the conductor, not the performer of every part. A good chunk of the routine work goes away, letting you focus on what actually matters.
Where It Breaks Down
The human doesn't disappear from this process. You can't fully hand development over to AI yet: you need to understand what's happening in the code and correct course in time. Taste remains a human thing — it's the human who decides which color works better, what the app feels like to use, and what others will get out of it.
AI introduces bugs, implements something other than what you expected, or forgets certain requirements. What helps here is breaking large tasks into smaller ones and using the vertical slices approach: you take each piece of functionality to a state where you can launch it and test it right away, and fix any bugs or deviations from the spec on the spot. I learned this the hard way: at first I quickly implemented several features at once, and after launch discovered that some of them didn't work — the QR invite would sometimes hang during scanning and never notified either side whether the operation succeeded. After that, I started taking every feature to a "launched and verified" state before moving on to the next one.
There's also a code problem: tech debt piles up, quality declines, and you have to stop, look at the structure and content, and decide whether it's time to refactor. Working on the app, I noticed how badly the files had started to balloon — some of them already held 5–10 functions each, and the line count had passed 2,000. It couldn't go on like that: code quality would only drop with every iteration. So before moving forward, I decided to adopt the FSD (Feature-Sliced Design) architecture and split the code into separate folders and files, improving readability and quality.
Conclusion
It's already hard to imagine a modern engineer without an AI tool. It looks like the next turn of the same evolution: assembly → high-level languages → natural language.
I didn't start with an app — I started with the wish that my kid would do his chores without fights. And I ended up understanding how much the very process of making things has changed. AI didn't write the product for me — it removed the expensive part of production and left me the part that matters most now: deciding what to build, feeling what the app should be, and saying in time, "this is it — and this isn't." Code has become cheap. Taste hasn't. And it seems that's exactly what the developer's new job is.
Top comments (2)
The testing point is the strongest part here. AI prototyping is useful when it turns vague ideas into something testable sooner, but the team still needs a decision rule for what counts as a good test result.
100% agree