AI Generated Code in Production: Advantages and Disadvantages

You know that feeling when something seems too good to be true? That was me staring at an AI-generated app a few months ago, thinking "this actually looks decent."

The demo was slick, the features looked useful, and it had that magical "built in minutes, not months" appeal that makes every developer's heart skip a beat.

So instead of being sensible and starting from scratch, I decided to see what it would actually take to turn this prototype into something I'd be comfortable putting in front of real users.

So. Much. Unused. Code.

First red flag: 70% of the codebase did absolutely nothing.

Components that were never imported. API endpoints that led nowhere. Functions that could be replaced with return true and nobody would notice. It was like walking through a ghost town where every building looked important but turned out to be an empty shell.

The real kicker? I couldn't just delete it all. What if something was using it in some weird, non-obvious way? So every change became an archaeological expedition: "Is this function actually called somewhere, or is it just debris?"

AI doesn't need Coding Standards

Imagine five developers who've never met, don't speak the same language, and have completely different opinions about how code should look. Now imagine they all worked on the same project simultaneously and glued them all together in the best way they could at the end.

That's what this codebase felt like.

Everything was typed as any (the hacky TypeScript equivalent of giving up - a huge red flag for any developer). Indentation was... creative. Some functions were 3 lines, others were novels. When I tried to add ESLint, it practically had a nervous breakdown.

The Phantom Menace

This is where things got weird. The AI had confidently written code that referenced things that simply did not exist.

API calls to /api/magic-endpoint? Nope, never created that. Database queries looking for a unicorns table? Not in this universe. Complex conditional logic that somehow always returned true regardless of input? Classic AI confidence.

It was like the AI had built this elaborate fantasy world in its head and just assumed reality would catch up. The really frustrating bit was that these phantom features were scattered throughout the codebase like landmines. Everything would work fine until you clicked the wrong button, then boom – error.

The Documentation Situation

Comments were often hilariously useless or completely absent. My personal favourite: // This function handles user authentication sitting above 200 lines of spaghetti code that seemed to handle everything except user authentication.

Meanwhile, the genuinely complex bits – the stuff you'd actually want explained – had all the documentation of a hastily scribbled shopping list.

Enormous files

And then there was the 6,000-line route file. Yes, you read that right. Six thousand lines. In one file. Handling every single API endpoint. It was like the AI had heard of "separation of concerns" and decided to actively rebel against it.

This is likely to help with AI retaining full context of the API easily, but there are better ways.

Testing? We Don't Need No Tests

Zero tests. Not even a cheeky console.log('it works!') to give me some confidence.

Every change I made was essentially Russian roulette with code. Click save, refresh the browser, and pray to whatever deity watches over developers that I hadn't just broken the login system.

I became a professional button-clicker, manually testing every possible user journey after each tiny change. It was like being a QA tester for AI.

The Great Salvage Operation

After several weeks of wanting to throw my laptop out the window, I was finding a workable pattern:

Operation: Delete Everything came first. Before I could build anything useful, I had to clear out the digital junk drawer. Turns out removing 70% of unused code makes the remaining 30% much easier to understand. Who knew?

Static Analysis was next. Instead of enabling all ESLint rules at once (professional masochist move), I went one rule at a time. Enable, fix errors, commit, repeat. Like going to the gym but for code quality.

Tests became my security blanket. Every single change got a test. It felt slow at first, and call me old fashioned, but nothing beats the confidence of knowing your code actually works before you ship it.

File surgery was surprisingly therapeutic. That monster 6,000-line file? Chopped it into 20 bite-sized pieces that actually made sense, were logically self contained and easy to maintain.

Comments for humans replaced the AI's cryptic messages. Instead of documenting what the code does (I can read, thanks), I explained why it does it that way, so it's a little easier for the next dev.

The Verdict: Would I Do This Again?

Short answer: Differently.

Long answer: I learned a ton from this exercise, and the end result actually works pretty well. But the time I spent untangling AI spaghetti could have built a clean application from scratch based on the prototype features much quicker (especially with Copilot).

Here's the thing though – AI tools like Replit absolutely have their place. They're incredible for:

• Rapid prototyping when you need to test an idea quickly
• Getting stakeholders excited about possibilities (demos are everything)
• Exploring concepts before committing to proper development
• Securing funding with impressive-looking proof-of-concepts

But production applications? That's a different beast entirely.

The real magic happens when you use AI to accelerate human creativity, not replace human judgement. We're finding massive value using these tools at BigByte – but always with a human in the driving seat who understands the difference between "works in demo" and "works in the real world."

The bottom line: AI can help you build faster, but it can't help you build better. That still requires actual humans who know what good code looks like.

Though knowing how fast AI is evolving, I might be eating these words in 6 months. We'll see!