The Illusion of Progress: AI Coding and Feature Creep

AI has made building software fast. The harder question is whether all that speed is producing progress, or just the feeling of it.

With a new, faster model arriving almost every week, features that once took weeks now take days, sometimes hours. That’s a real gain. But it has a side effect that’s easy to miss until someone points it out, and I didn’t see it in my own work until I was well inside it.

When every feature felt like progress

At the start of any product, each new feature adds real value. An ERP that gets a supplier module becomes a more complete ERP, and the struggle to build it is what earns the reward.

With AI writing much of the code, that struggle shrinks to a few hours of back-and-forth prompting. The reward stays the same size, but it arrives far more often. Build a feature, feel productive. Build the next one, feel productive again.

For a developer, it feels like a dream. The product you imagined is becoming real, one feature after another.

The goal posts move

But when have people ever said “that’s enough”? When building is cheap, prioritisation loosens. The original goal shifts and the scope grows. Features with little impact, or features nobody asked for, suddenly make the list, because adding them no longer costs much.

If you started developing after AI tools arrived, this may simply look like how building works. It isn’t wrong, but it changes what you need to watch for.

The comfort loop

The part that gets overlooked is the reward cycle itself. Each finished feature delivers a small hit of satisfaction. The to-do list, which has probably grown longer, keeps getting ticked, so it feels like work is getting done.

Meanwhile, the question that matters most goes unasked: what is this product achieving in sales? The most sophisticated software with no users is just a folder sitting on your PC.

Breaking out is hard because features have become the comfort zone. Distribution, finding and convincing real users, is uncomfortable by comparison. So the building continues. It feels productive, but the results exist only in your own world.

A simple test for every feature

At some point, a new feature brings very little value. Nobody asked for it and nobody needs it; it’s being added because someone, someday, might. That’s the moment to stop and ask one question: does this feature satisfy an existing client, or bring in a potential one?

If the answer is no, stop adding features and put that time into getting the product in front of people.

Who this is for

Founders who are also developers are especially exposed, and I include myself. At some point it became easier to add features than to sell, and the activity looked good from the outside: a new poster every week, a new demo video, a system that kept growing. The honest question was whether any of it was bringing in new clients.

So I’ve changed my focus. Unless a client makes a specific request, I’m no longer adding features to One Click POS. The time goes into distribution: getting the system to more businesses.

Students building final-year projects face a quieter version of the same trap. Adding one more screen feels safer than putting the system in front of a real user. It’s worth resisting for the same reason.

Have you caught yourself in this loop? I’d like to hear how you broke out of it.