I Asked AI to Build It. Here's What I Had to Fix.
AI is fast, but it is not flawless. I let an AI agent write a critical feature for my app, and this is the story of the hidden bugs, connection leaks, and useless tests I had to fix before production.
By Jitendra Suthar · · 4 min read
Over this six-part series, we have covered how I think, design, and ship systems. I have praised AI as a massive force multiplier for speed.
But I want to end this journey with a story about reality.
Working code is not the same as correct code. To prove it, I gave an AI a critical backend problem. It produced something that "worked" on the first try. Then, I had to fix almost all of it.
Here is what real engineering judgment actually looks like.
The Setup: The Sync Queue
While building thekedaar, our contractor management application, I needed a background sync worker. When site managers come back online after being off-grid, the mobile app sends a massive batch of offline attendance logs to the Node.js backend.
I prompted my AI coding assistant:
"Write a Node.js function using PostgreSQL to loop through an array of attendance logs, insert them into the database, and update the worker's shift status. Use transactions."
In five seconds, the AI generated 40 lines of pristine async/await code. It looked perfect. I ran my local tests, and they passed immediately.
Then I reviewed the code like a senior engineer.
The Illusion of "It Works"
At first glance, the AI's output was clean. But research shows that logic and correctness errors are 75% more common in AI-generated pull requests. The bugs AI writes are subtle, and my generated code was full of them.
Here is what I found hiding in the syntax:
- The Silent Connection Leak
The AI successfully opened a database transaction (pool.connect()) and ran the queries. But it missed a fatal detail. If any query threw a constraint violation or a timeout, the function would error out, and client.release() would never execute. Error handling gaps are nearly twice as frequent in AI-generated code. If this went to production, every failed sync would permanently leak a database connection, eventually bringing down the entire cluster.
- The "Happy Path" Bias
The code assumed every piece of data coming from the mobile app was perfectly formatted. AI models optimize heavily for the happy path and miss implicit conventions. In reality, semantic errors—like failing to handle boundary conditions or empty arrays—make up over 60% of faults in AI-generated code. If a contractor accidentally submitted an empty sync payload, the AI's logic would throw an unhandled exception.
- The Useless Test Suite
I asked the AI to write unit tests for the function. It gave me tests that passed instantly. However, AI agents frequently write tests that mirror the implementation exactly. The tests just fed mock data into the function and checked if the mock database received it. It validated the mocking framework, not the actual business behavior.
How I Fixed It (The Real Engineering)
Here is how I transformed the AI's draft into production-ready architecture:
- ☐ Wrapped everything in a strict
finallyblock: I ensured the database connection always releases, regardless of what crashes inside thetry/catchblock. - ☐ Added schema validation at the boundary: I wrote strict validation schemas to aggressively sanitize the incoming offline payload before the database even sees it.
- ☐ Shifted to behavioral testing: I deleted the AI's unit tests and wrote integration tests that actually hit a test database to verify concurrency and idempotency.
💡 The Lesson: AI generated the boilerplate in seconds, saving me typing time. But it was my domain knowledge that prevented a production outage.
The Final Takeaway
This brings us to the end of the series. If you look at the journey, it perfectly maps to how I view software development today:
- How I Think: Product clarity comes before code.
- How I Design: Boundaries and data flow define the architecture.
- How I Ship: Building for failure is the only way to survive reality.
- How I Use AI: It is an assistant that accelerates typing, not a replacement for judgment.
The next time an AI writes a feature for you, remember: it doesn't know your users, it doesn't know your business constraints, and it won't be the one waking up to an alert at 2 AM.
That is still your job.
Thank you for reading the series! You can explore more of my work, projects, and architectural deep dives at jeetlabs.in.