How AI is changing not just how fast I build, but what I build, and why that matters for everyone who’s ever had a small idea.
TL;DR
AI coding tools don’t just make developers faster. They lower the bar for which ideas are worth building. That means more niche, personal, and practical software gets made. Here’s how that shift looks in practice, and why it matters.
Intro
The biggest change AI has brought to how I build software is not that it makes me faster at writing code.
It changes which ideas are worth building at all.
I’m a professional software developer, so turning an idea into code was never the hard part. The real constraint was whether I cared enough to spend the time. Countless small ideas never made it past that filter. Not because they were bad, but because they weren’t important enough to justify the setup cost, implementation work, and mental overhead of yet another side project.
That’s what feels different now.
There’s a whole category of apps I used to mentally discard: useful, narrow, personal tools that solve one annoying problem, but not enough to earn a weekend of focused work. Those ideas died in the gap between “this would be nice to have” and “I’m actually willing to build it.”
With AI coding tools, that gap is much smaller, and shrinking.
Now, I can take an idea that would have stayed a note in my head, bootstrap it in a couple of hours, iterate quickly, and decide after seeing a working version whether it deserves more attention. The economics of building have changed. The threshold for trying something new has dropped.
That doesn’t mean the work disappears. I still need to decide what I want, review what gets produced, test it, and cut scope aggressively. But the cost of getting from vague idea to usable prototype is now low enough that many more ideas make it through.
What actually changed for me
The biggest shift is how quickly I can get real feedback on an idea. Instead of investing hours just to see if something is worth building, I can reach a working prototype fast and judge its value right away. This means I spend less time on setup and boilerplate, and more on deciding what’s actually useful, trimming scope, and testing if the result feels right.
It’s still engineering work, just more focused on product judgment than manual construction. And because the cost of trying is so low, I’m more willing to treat ideas as experiments. If something’s useful, I keep refining it. If not, I’ve only lost a couple of hours supervising the AI, not a whole weekend of coding (or worse).
One recent example
TapLog is a simple Android app for logging recurring events with almost no friction. You create custom event types and place them on the main screen as large buttons. Tap once, and the app records the event with a timestamp. Long-press, and you can add a note. Later, you can review everything in a logbook, edit entries, export the data, or back it up locally.
It solves a very ordinary problem: I wanted to track missed bus rides during my commute. That’s exactly the kind of problem I mean. Real enough to be annoying, useful enough that data would help, but not obviously important enough to justify building a custom mobile app the old way.
With AI in the loop, it became easy to just make the thing.
What matters here isn’t that TapLog is technically impressive. It’s that it crossed the threshold from “I wish I had a tool for this” to “I have a tool for this” fast enough that the idea survived.
This app was built with Claude Code (Opus 4.6 1M context in plan mode), and that’s exactly why it exists. Without that workflow, I probably wouldn’t have given it the time.
Why this matters
This shift changes more than just developer velocity.
It changes what gets built.
When the cost of trying an idea drops, more niche, personal, and practical software gets made. More small tools exist because someone can justify building them now. That seems good to me. A lot of useful software doesn’t need to become a startup or a platform. Sometimes it just needs to solve one problem well enough to be worth keeping around.
And this matters beyond professional developers. I have the advantage of knowing how to evaluate tradeoffs, inspect code, and recognize when something is wrong. That still helps a lot. But the broader point stands: it’s much easier now for people to build software for problems they care about, even if they aren’t strong coders.
They still need judgment. They still need persistence. They still need to test what they build. But the barrier between having an idea and having a first working version is lower than it used to be. The hard part shifts away from typing every line yourself and toward knowing what to ask for, what to keep, and what to throw away.
Of course, there are tradeoffs. Lowering the bar means more experiments, but also more half-baked or disposable tools. Not every AI-generated app will be good, secure, or maintainable. And it’s easy to get caught up in building for the sake of building. But on balance, I think the benefits outweigh the risks, especially for personal projects.
Conclusion
AI coding tools are changing not just how fast I build, but what I build. They make it easier to turn small, personal ideas into real software. That’s a big deal for anyone who’s ever had a useful idea that wasn’t quite worth the effort of building before. Now, more of those ideas can see the light of day, and that’s exciting to me.
Top comments (0)