(Project Brief)
An agency contact of mine reached out asking me to help launch an app. I was excited at first, since app development projects like this usually come with a sizable paycheck, but it turned out the budget was way too low for building an entire app. I was ready to turn it down entirely. Then she told me it wasn't a build from scratch — the app already existed and only needed some fixes. Since I was strapped for cash, I took the job.
And the app turned out to be a Vibe Coding project she had built herself.
"I made this app with Vibe Coding."
So the functionality was all there, thanks to Vibe Coding, but the app kept getting rejected because of code quality issues and other problems. She needed someone to clean up the code.
She has always paid fairly for past work, and since this wasn't a full build from the ground up, I spent about a week on it for the sake of the relationship.
The screen above is the front-end service. Personally I find it a bit too AI-looking for my taste, but she argued that "people are so used to AI now that this is actually the new normal."
I agreed on a fixed fee contingent on passing the iOS review, then went through the code that FABLE 5.1 and Astra 6.0 had generated. Either way, I got everything through.
Let me write down a few things I noticed while fixing it.
1. Error handling was completely inconsistent.
Normally you centralize error handling, define an error policy, and unify the format according to error type. None of that existed in the AI-generated code. Some errors used throw, others used return. From the caller's perspective, the behavior was completely unpredictable.
Fix: I banned direct res.status() calls inside routes and defined explicit error types to work with.
2. Failure to separate concerns in a single server.js file
Routes, SQL, file I/O, and shutdown code were all crammed into one Server.js file.
On top of that, branching actions under /api/auth is bad REST API design. The standard approach is to split into POST /signup and POST /login, but even that basic separation wasn't done.
Fix: I applied layered architecture (Separation of Concerns).
3. Declaration order was dictating error handling.
This was a hoisting trap. Because wrap was declared as a const arrow function, the 8 routes registered before the declaration (at line :330) couldn't use wrap and each had its own inline try/catch.
Fix: I resolved this by declaring all middleware before registering any routes.
4. There was a lot of boilerplate code.
Even though a helper function existed, the same check was repeated inline about 18 times.
A guard helper is supposed to be reused by design, but if it runs inline, all 18 instances have to match exactly. This makes testing impossible.
Fix: I consolidated everything into one.
5. There was a lot of duplicate code.
The hashPassword mismatch was particularly serious: passwords hashed with SHA-256 on the client side were incompatible with passwords hashed with scrypt on the server side.
Fix: I standardized on the server-side implementation.
Even FABLE 5.1 and Astra 6.0, widely regarded as the most capable AI models available, were making mistakes like these.
There were plenty of other issues as well.
She said she couldn't understand what the problem was, since registration worked and the AI API call was generating images just fine. I tried to explain a few of the technical issues at first, but she told me to just say whether it passes or not and skip the details, so I stopped explaining.
Regardless, this job was a pretty significant mental shock for me.
Even a simple CRUD app had issues like these, and I was caught off guard seeing problems that never came up when I used AI myself.
The AI I use generates code that I sometimes can't even fully follow and does it fast — so how is it possible that it also produces something this sloppy?
That was the truly shocking part. It made me wonder whether my own code might have the same problems if I never validate what the AI produces.
Feature implementation is visible — you can see it working. But separate from that, if mistakes like these exist in an area I know well, can I really trust AI?
The first few sections were genuinely well written, but from the moment I stopped watching closely, whether the AI actually maintained the code quality I saw at the beginning is an entirely different question.
There were other issues too, like the absence of a staging server, and plenty more problems besides, but she was absolutely thrilled.
"Don't you think this is going to be a success?"
The concept was good, but the quality was so rough that I started to say "I don't think so," but she was so excited that I held back.
There are bigger problems I haven't addressed, and it would be hard to say I fixed everything. In the end, though, I fixed as much as I could and got it through both the iOS and Google Play reviews.
From where I sit, problems are still scattered throughout. Testing is difficult without a staging server, and validation is missing from many features.
That said, the app is up and running, and critically, the client is thrilled with it, so I didn't want to hold her back.
At a minimum, I put out the most urgent fire by attaching tests to the payment-related functionality so that payments and refunds wouldn't fail. That was my bare minimum of professional conscience. Even so, I'm uneasy knowing it hasn't gone through sufficient testing.
But maybe that unease is just my own anxiety.
This might be the new normal. I just wonder how long my definition of "common sense" will stay relevant.
And what hit me hardest this time was that my trust in the AI I had relied on was shaken.