Your app was built with AI. What is actually under the hood?

I use AI tools every day. Large parts of Altrady and Coinray started that way: an idea, a few prompts, and something running within a day. That is not nothing, and I am not going to be cynical about it. But I know from experience what happens next, because I then had to do serious cleanup work on that code to keep it readable, fast and maintainable.

That is the part you never see in a demo. The app works. The buttons do what they are supposed to do. And still, underneath that surface, there is something that will decide in six months whether you can keep moving forward.

Working and healthy are not the same thing

If you are not a developer, working software is your only yardstick. That makes sense. You click through it, it does what you had in mind, done.

But that says very little about how it was built. Software that works can internally be one file of two thousand lines where everything runs into everything else. That runs fine. Until you want to change something. Then somebody has to understand that entire file before touching a single line, and that is exactly the moment when small changes suddenly start taking days.

I prefer to build with Lego. Separate blocks you can reuse, each with one clear job. A button is a block. A form is a block. Fetching data is a block. When you want to change something later, you pick up one block and leave the rest alone. AI tools do not choose that structure by themselves. They write whatever gets to a working result fastest, and that is almost always one long stretch of code.

What I look for when I open that kind of code

Readability comes first. Can I follow what is happening without anyone explaining it to me? Not because pretty code is a goal in itself, but because every developer who steps in after you asks the same question, and you pay for the time it takes them to find the answer.

Then I look at variables. How things are named tells you whether somebody thought about what they mean. After that, helper functions: are they there but never used anywhere? That happens more often than you would think. A tidy solution gets written, and ten lines further down the same logic is spelled out by hand anyway.

And then duplication. The same calculation in four places means that every change has to find four places. Find three of them and you have a bug that surfaces weeks later.

None of this is arcane craftsmanship. These are the four things that determine what your next change costs.

What a check-up involves

I take a day to read the code. I click through the application the way a user would, so I know what should be sitting behind each screen. And I put my own AI tooling to work to find the rough spots quickly, because a machine simply finds duplication and oversized files faster than I do.

That initial verification starts at 500 euro. After it you get a worked-out plan: what is solid, what is going wrong, what it costs to move forward, and in what order.

So far I have not repaired anyone else’s app. What I have done is take my own AI-built code and make it production ready, and that is exactly the same exercise.

Fix it or build it again

This is the question everybody asks first, and the honest answer is that it depends.

You do not throw away something that is technically fixable. But technically fixable is not an argument on its own either. The only yardstick that counts is which route is cheaper. If rebuilding that part is less work than pulling apart and reassembling what is there, you rebuild. If it falls the other way, you refactor.

I am level headed about this. There is plenty of code that is not the finest thing I have ever seen and that you can work with perfectly well. I leave it alone. Every hour you spend cleaning up something that already works is an hour you are not spending on your customers.

What AI does and does not do for you

AI tools are tools. No more, no less. As a non-developer you can get to a first prototype with them reasonably well, and that is genuinely valuable. You can show an idea instead of explaining it.

Where it goes wrong is the assumption that a working prototype is the same as a product. To judge what has actually been built, you need years of code review experience. I led teams the old-fashioned way: juniors and seniors presenting their code, and that code was sometimes good and sometimes bad. You build that judgement by doing it hundreds of times.

Knowing when something is good enough, what to skip and what to include, that is where the real value of AI sits. The tool writes the lines. You, or somebody you hire for it, decides which lines stay.

To close

If you had an app built and you notice that changes take longer than you expected, that is not a sign you did something foolish. It is the normal course of software that came together quickly. The only question is whether you know now what you have, or whether you find out in a year when it has become more expensive.

A day of reading costs 500 euro and gives you a plan. If you want to know where you stand, send me a message and we will look at it together.