AI Could Build My Client’s App in a Week. Making It Reliable Took Me 3 Months.

AI can generate software frighteningly fast.

That is both its greatest advantage and one of the easiest traps to fall into.

Earlier this year, I started working on a fairly complex client project. What began as an Excel spreadsheet gradually became a production platform with around 20 interconnected modules.

I used AI heavily throughout development.

Claude Sonnet and Opus helped with design and implementation. Codex Terra and Sol became my second pair of eyes for architecture, planning, and code review.

The amount of code we could produce was incredible.

At some points, it genuinely felt like the entire application could have been built in a week.

Three months later, I understood why that would have been a terrible idea.

The First Version Is the Easy Part

There is something addictive about building software with AI.

You describe a feature.

AI understands it.

A few minutes later, you have hundreds of lines of working code.

You test it.

It works.

Then you move on to the next feature.

And the next.

And the next.

For a small project, that workflow can be incredibly productive.

But complexity compounds.

By the time my project had grown into a large interconnected system, implementing a feature was no longer the difficult part.

The difficult question became:

What did this feature accidentally break?

A Feature Worked. Something Else Broke.

This became one of the most frustrating patterns during development.

I would implement a new feature and test it.

Perfect.

Then I would discover that something seemingly unrelated had stopped working.

Sometimes a change interfered with the application's Content Security Policy.

Sometimes functionality elsewhere in the platform regressed.

Sometimes the generated implementation duplicated logic that already existed somewhere else.

AI was extremely good at solving the problem directly in front of it.

But production software isn't a collection of isolated problems.

Everything lives in a system.

And once that system becomes sufficiently complex, local correctness isn't enough.

Then I Found a 20,000-Line File

This was one of those moments where you look at your codebase and realize you have allowed something to go much too far.

One file had grown to roughly 20,000 lines of code.

AI didn't particularly care.

It could keep reading the file, finding the relevant section, inserting another method, and continuing with its business.

Technically, development could continue.

Architecturally, it was becoming ridiculous.

So I stopped generating features and dealt with the structure myself.

I created the folders and files I wanted.

I defined clearer responsibilities.

Then I had AI help split the existing implementation across that structure.

That experience changed how I use AI.

I stopped asking only:

"Does this work?"

I started asking:

"Where does this belong?"

Those are very different questions.

The Scariest Problem Wasn't Messy Code

Messy architecture is annoying.

Data loss is different.

At one point, I encountered a race condition that could result in data being lost.

AI investigated it.

A fix was implemented.

The reasoning sounded convincing.

The problem appeared solved.

Except it wasn't.

Eventually, I had to follow the execution path through myself, identify what was actually happening, and correct the underlying problem.

That incident hammered home something important for me:

Confidence is not evidence.

AI can articulate an explanation beautifully while still being wrong.

When you're building a toy project, that might cost you an afternoon.

When you're building software for a client, that changes the equation.

Someone else's business can depend on the code you're shipping.

AI Also Doesn't Care If Your Product Slowly Loses Its Identity

Another problem was subtler.

Design inconsistency.

When you're generating pages individually, each page can look perfectly acceptable.

But put 15 or 20 of them together and suddenly:

Buttons don't quite match.

Spacing changes.

Forms behave slightly differently.

Modals follow different patterns.

One section feels like it belongs to another application.

No individual page looks terrible.

The product looks inconsistent.

So my role increasingly became less about typing code and more about monitoring the whole system.

I had to catch discrepancies, regressions, security vulnerabilities, architectural problems, and UX inconsistencies.

AI was doing more implementation.

I was doing more supervision.

I Eventually Split the Responsibilities Between AI Models

Instead of asking one AI to do everything, I developed a workflow that worked much better for me.

Codex became the planner and reviewer.

I used it to inspect architecture, challenge implementations, identify risks, and review changes.

Claude became the designer and implementer.

Sonnet and Opus handled much of the actual feature development and UI work.

Then came testing.

Automated tests.

Manual tests.

Browser testing.

And, importantly, me actually using the application rather than assuming passing tests meant everything was fine.

This slowed development down.

That was a good thing.

The goal was no longer to produce the most code possible.

The goal was to confidently ship software.

AI Didn't Replace the Developer. It Changed the Developer's Job.

This is probably my biggest takeaway from the entire project.

I wrote dramatically less code manually than I would have a few years ago.

But I didn't have dramatically less responsibility.

In some ways, I had more.

I needed to understand enough about the system to notice when AI was heading in the wrong direction.

I needed to be assertive about architecture instead of letting generated code accumulate wherever convenient.

I needed to recognize security regressions.

I needed to test assumptions.

I needed to reconsider my position when an implementation that looked elegant turned out to be fragile.

And when something broke in production, I couldn't tell the client:

"The AI said it was fixed."

The responsibility was still mine.

Could AI Have Built It in a Week?

Possibly.

At least something that looked like the finished application.

That distinction matters.

Generating 20 modules isn't the same thing as building a dependable 20-module system.

You can move incredibly fast with AI.

But if every new feature creates two regressions, you're borrowing time from your future self.

Eventually, you pay it back through debugging, refactoring, client complaints, longer working hours, and trying to identify which seemingly harmless change caused the latest problem.

Speed is valuable.

Controlled speed is much more valuable.

Three Months Later

The project eventually reached the point where I was genuinely comfortable with it.

It became a large production system with interconnected workflows, financial data, document generation, external sharing, contact management, reporting, and a substantial amount of business logic.

More importantly, the development process itself became disciplined.

AI remained heavily involved.

I didn't respond to the problems by abandoning AI.

I learned to use it differently.

That's the part of AI-assisted development I think gets overlooked.

The interesting question isn't:

"Can AI build an app?"

Of course it can.

The more useful question is:

"Can you manage what AI builds when the application becomes complicated?"

That's where software engineering starts to matter again.

I Documented the Full Experience

I ended up turning the experience into a short case study covering the architecture problems, regressions, security issues, race condition, data loss, testing process, and the workflow I eventually developed between Claude, Codex, and myself.

It's called I Built a 20-Module Business Valuation System With AI.

The title reveals more about the project than I wanted to discuss publicly here, while the case study goes much deeper into what actually happened during those three months.

If you're using AI to build your own product or client software, you can read the full case study here:

I Built a 20-Module Business Valuation System With AI

I used AI to help turn an Excel spreadsheet into a complete 20-module business valuation system.It looked like AI could make the project ridiculously fast.Then the real problems started.New features caused regressions. Security policies broke. Unrelated parts of the platform stopped working. Designs became inconsistent. One file grew to more than 20,000 lines. A race condition eventually caused data loss, even after AI confidently suggested the problem had been fixed.This case study explains what happened and how I changed my workflow to get the project under control.I cover how I used Claude for design and implementation, Codex for architecture and review, and automated tests, manual testing, and browser testing to catch problems before they reached the client.The finished system handles business sellability, financial analysis, valuation workflows, CIM and BLI generation, and controlled sharing with sellers, buyers, bankers, and other relevant contacts.It took around three months to reach a result I was comfortable shipping.This is not a prompt collection or a guide promising that AI will build your SaaS overnight.It is my experience building a complex client system with AI, including the mistakes, regressions, architectural problems, security issues, and lessons that came with it.Written by Ayman Atif, software developer.

yaman95.gumroad.com

I'm Ayman Atif, a software developer who has spent years building business software. AI has changed how I work considerably.

It hasn't taken responsibility out of the equation.

If anything, it has made knowing when to intervene more important than ever.