What to look for when hiring a developer to fix AI-generated code

Your AI-built app works but it’s fragile. Things break when you add features, the database is a mess, and you’re scared to touch it. So you want to hire a developer to clean it up. The trouble is you can’t tell a good one from a bad one, and the wrong hire will either rewrite the whole thing from scratch (expensive, slow) or paper over the problems and leave you worse off.

Here’s how to vet someone when you can’t read the code yourself.

First, decide what you’re actually hiring for

There are three different jobs, and they need different people. Be clear which one you have before you post anything.

• Fix a specific bug. Something’s broken and you need it working. Short engagement, clear success test.
• Make it production-ready. The app works in the demo but isn’t safe for real users: no backups, exposed keys, no error handling. Medium engagement, checklist-driven.
• Take over ongoing development. You want a person who owns the code from here on. Long relationship, and the vetting bar is highest.

If you describe the job as “just fix it” but you actually want the third one, you’ll hire the wrong person. Say which it is.

The red flag that outweighs the rest

“I’d just rebuild it from scratch.” Sometimes that’s the right call, but a developer who reaches for it in the first conversation, before reading your code, is telling you they don’t want to understand what you have. A rewrite is the most expensive, slowest, riskiest option. A good developer treats it as a last resort and can explain, in specifics, why your particular app needs one. If they can’t, they’re just avoiding the harder work of reading someone else’s code.

Vetting questions that actually reveal skill

You don’t need to understand the answers in full. You need to hear whether the person is specific and calm, or vague and dramatic. Ask these.

“How would you figure out what this app does before changing anything?” Good answer: they’d read the code, run it locally, look at the database schema, check what’s deployed. They start by understanding, not typing. A weak answer jumps straight to rewriting.

“How do you make sure your fix doesn’t break something else?” Good answer mentions testing the change, making a backup or a branch first, and being able to roll back. If money or customer data is involved, they should mention a regression test. If they say “I just test it manually and push,” that’s a risk with a live app.

“The app has API keys in the code. Walk me through what you’d do.” Good answer: rotate the exposed keys immediately, move them to environment variables, check whether they leaked publicly (git history, the browser bundle). This is a basic security instinct. If they shrug, they’ll leave you exposed. Our 5-minute exposed-key check covers what a competent answer looks like.

“There are no backups. What’s your first move?” Good answer: set up a real backup and test a restore before touching anything. A developer who starts editing a production database with no backup is dangerous, full stop.

“Have you worked with code from Lovable, Cursor, or similar tools?” AI-generated code has patterns: repeated logic, thin error handling, odd file structure. Someone who’s seen it knows what to expect and won’t be shocked. Someone who’s only worked on hand-written codebases may underestimate the cleanup.

“How would you bill this, and what happens if it takes longer than expected?” You want honesty about uncertainty, not a suspiciously precise fixed quote for a codebase they haven’t read. A fair answer: a small paid discovery first (a few hours to read the code and scope the work), then an estimate. Anyone who quotes a firm price before seeing the code is guessing.

What to ask them to do before you commit

Don’t hire on a conversation alone. Give a small paid trial task, two to four hours, that mirrors the real work.

• A paid code review. Ask them to read your app and write up, in plain language, the three biggest risks and how they’d fix them. A good developer produces something you can actually understand. A weak one hands you jargon or “it’s fine.”
• One real bug fix. Pick a small, contained bug. Watch how they work: do they make a backup, test the fix, explain what they changed? The habits show up on a small job before they cost you on a big one.

You learn more from four paid hours than from four interviews.

Green flags worth paying more for

• Asks about your backups and access before asking about the code.
• Talks in terms of risk and rollback, not just features.
• Comfortable reading code they didn’t write, without judging it.
• Explains things to you in plain language instead of hiding behind terms.
• Documents what they change so the next person (maybe you) can follow it.

Or, we do it for you

If you’d rather not manage a freelancer at all, the “make it production-ready” job is exactly what we do: backups, secrets, a real database, monitoring, and a named human on call. Start with a free Stackbastion audit and you’ll get the same plain-language risk report you’d want a good developer to write, before you spend a euro on hiring.

FAQ

How do I know if the code even needs fixing, or if I’m overreacting?

Two questions settle it. Is there a tested backup you could restore from if the database got wiped today? Are there any API keys or passwords sitting in the code? If the answer to the first is no or the second is yes, it needs work regardless of how well the app appears to run. A free audit will tell you the real state in an afternoon.

Should I hire a freelancer or an agency?

For a specific bug or a one-time production hardening, a good freelancer is cheaper and faster. For ongoing ownership where you need coverage when someone’s on holiday, an agency or a managed service reduces the single-person risk. Match the choice to the job: don’t pay agency rates for a two-hour bug fix, and don’t lean on one freelancer for something your business depends on.

What’s a fair rate to fix AI-generated code?

It varies by region and seniority, so the rate matters less than the structure. Avoid a firm fixed price for a codebase nobody has read yet. A fair setup is a small paid discovery to scope the work, then an estimate with a range and a plan for what happens if it runs long. Honesty about uncertainty is worth more than a confident number that turns out wrong.

Can’t I just ask the AI tool to fix its own code?

Sometimes, for small things. But the AI doesn’t know your backups don’t exist, that a key leaked, or that a change will break checkout. It generates plausible code without owning the consequences. For anything a business depends on, you want a human who thinks about risk and rollback, not just another prompt.