How AI Generated Bad Code for My App — And How I Reduced Latency from 6 Seconds to 1 Second

The Application Overview

On this same platform, Xarwix, I built a small application called Gym Rep Tracker.

The purpose of the app is very simple: track workout progress without unnecessary complexity.

Users can log exercise details such as:

• Muscle Group: Chest
• Exercise: Bench Press
• Set 1: 25 kg × 12 reps (Easy)
• Set 2: 35 kg × 8 reps (Hard)

The idea is straightforward.

When you return to the gym next week, you will most likely forget:

• what exercise you did
• how much weight you lifted
• how difficult the set felt

Most gym-tracking apps I found were overly complicated and packed with unnecessary features. I wanted something extremely simple for my personal use, so I decided to build it myself.

You can check the actual product here:

👉 Gym Rep Tracker

The Problem

I am a senior software engineer with a strong backend background.

Although I know frontend development, I honestly do not enjoy working on frontend. So for smaller frontend-heavy projects, I usually rely heavily on AI.

Since this application was mostly a simple CRUD system, I thought AI could handle both the frontend and backend.

I described the application I wanted, and AI generated most of the code.

Everything worked perfectly in localhost.

I was genuinely excited because I had essentially built a working product in about an hour (with AI assistance, of course).

But the real problem started after deployment.

The application only had:

• a single form submission
• a PostgreSQL database
• a dashboard refresh after submission

Nothing complicated.

Yet every request was taking more than 6 seconds.

No one is going to use an app where a simple action takes 6 seconds.

Finding the Root Cause

At first, I suspected cold starts because the backend was deployed on Railway’s free infrastructure.

To confirm, I tested multiple requests and monitored the browser network tab.

Even after repeated requests, the average response time remained around 5.5 seconds.

So cold starts were clearly not the main issue.

Next, I tested using Postman instead of the browser.

The average response time was still around 4–4.5 seconds.

At this point, I knew the issue existed in both frontend and backend.

So I inspected the business logic.

The Backend Problem: AI Generated an N+1 Query Problem

After reviewing the code, I discovered that the API suffered from a classic N+1 query problem.

The issue was not actually submitting the form.

The real bottleneck was fetching updated data after submission.

The AI-generated implementation fetched workout records one at a time and then combined them before returning the response.

For example:

If a user had 10 exercise records, the application would send:

1 request to get workouts + 10 additional requests to fetch details

In total: 11 database queries.

For such a small application, this was terrible architecture.

I honestly could not believe AI generated code like this.

I refactored the logic.

Instead of multiple requests, I changed it to a single endpoint that fetched everything for the requested user in one query.

I also added pagination to improve scalability later.

The Frontend Problem

The frontend had a performance issue too.

After submitting the form, the application used:

await reload();

This meant the UI waited for fresh data before updating the screen.

Completely unnecessary.

I removed the await keyword so the reload happened in the background.

The result?

The UI instantly felt much faster.

After deploying these changes, latency dropped from 6 seconds to around 2.5 seconds.

A huge improvement — but still not good enough.

The Infrastructure Problem

At this point, I knew the code itself was no longer the main issue.

So I started investigating infrastructure.

The backend was hosted on Railway, while the PostgreSQL database was hosted on Supabase.

That’s when I found the real infrastructure mistake.

My Railway backend was deployed in:

US — California

My Supabase database was deployed in:

Asia Northeast (Seoul)

Meanwhile, I was testing from India.

So the request path looked something like this:

India → California → Seoul → California → India

No wonder latency was still high.

I changed the Railway deployment region to be closer to the database.

After moving the backend region, latency dropped again.

This time:

0.8 to 1 second.

Final Thoughts

AI helped me build this product incredibly fast.

Without AI, I probably would not have built the MVP this quickly.

But this experience also reminded me of an important lesson:

AI can generate working code, but not always good architecture.

The code worked.

But performance, scalability, and system design still required engineering judgment.

In the end, I reduced latency from:

6 seconds → 2.5 seconds → under 1 second

And honestly, debugging and fixing the problem taught me more than generating the app ever did.