# One thing I keep noticing with AI-assisted development is that building “something that works” has become surprisingly fast.

You describe the idea, generate some screens, connect a few workflows, fix a couple of bugs, and suddenly you have a usable prototype. That part is amazing. It still feels a little unreal compared to how software was built before.

But there is a trap in this.

Simple software is not simple because there are only a few features. Simple software is simple because someone has made a lot of decisions about what the user should *not* have to think about.

The easy part is adding another field, another setting, another button, another view, another exception, another role, another report. With AI tools, adding those things is faster than ever.

The hard part is knowing when not to add them.

Every new feature can feel reasonable in isolation. One customer might need it. One edge case might justify it. One workflow might be “nice to have.” But after a while, the product starts to become a collection of possibilities instead of a clear tool for doing work.

That is where vibe coding can get dangerous.

You can move very fast, but you can also move very fast in the wrong direction. A messy architecture, unclear data model, confusing permissions, duplicated logic, and overloaded screens do not always appear immediately. At first everything still looks fine, because the demo works.

Then the real world arrives.

Users do things in the wrong order. Data is incomplete. Someone needs to undo something. Reports need to match invoices. Permissions matter. Integrations fail. A workflow that looked simple in a demo suddenly needs rules, defaults, validation, error handling, logging, and support.

This is why I think “simple” is not the starting point. Simple is the result of organizing complexity.

AI can help a lot with building. It can help with refactoring, testing, reviewing, documenting, and exploring options. But it does not automatically know which complexity belongs inside the system and which complexity should be hidden from the user.

That still needs judgment.

For me, the best software is not the one with the most features. It is the one where the user can do real work without needing to understand all the complexity underneath.

And that is much harder to build than the first prototype. [fleksi.io](http://fleksi.io)

Why simple software is hard to build