Is your project real, or AI bloat? A founder's checklist

There’s a new failure mode in software, and I keep getting called in to clean it up. It’s not the old “the agency disappeared” story. It’s subtler: you paid for something, it looks impressive, there’s a lot of it — and underneath, it’s padding. AI-generated bulk that no human fully understands, wrapped around a thin core that barely works.

I call it AI bloat, and you don’t need to be technical to spot it. Here’s what to look for and what to ask.

What AI bloat actually is

Used well, AI is a force multiplier for a good engineer. Used to replace judgment, it produces code with a specific signature: enormous surface area, low substance. Lots of files, lots of abstractions, lots of “enterprise-looking” structure — protecting a feature set that a focused developer could have built in a fraction of the size, and understood completely.

The danger isn’t that it’s ugly. It’s that nobody can safely change it. When every part was generated and no one reasoned through it, the first real bug or new requirement turns into a demolition job.

Signs you might be looking at bloat

Huge line counts for a simple product. A basic CRUD app with 80,000 lines of code is a red flag, not a sign of value.
The developer can’t explain their own decisions. Ask “why did you build it this way?” A real engineer has reasons. A bloat build gets vague answers, or “that’s the best-practice pattern.”
Tons of code, almost no tests. Generated features rarely come with meaningful tests, because the person shipping them couldn’t specify what “correct” means.
Abstractions with one user. Layers, factories, and wrappers that exist for flexibility the product will never need.
It breaks in ways nobody can trace. A bug appears and the fix is “regenerate that whole section” rather than a targeted change.
Dependencies for everything. A long list of libraries pulled in to do things a few lines would handle — each one a future security and maintenance liability.
Documentation that describes nothing real. Pages of generated README that don’t match how the thing actually behaves.

Questions you can ask without being technical

You don’t need to read code to pressure-test a build. Ask your developer or agency:

“Walk me through what happens when a user does X.” Fluent, specific answers = good. Hand-waving = worry.
“What happens if this fails — payment declines, network drops, two users act at once?” Silence here is the tell.
“How is this tested, and can you show me a test failing then passing?” Real work has this. Bloat rarely does.
“If I asked you to change this feature next month, how hard is it, and why?” Confident, concrete = healthy. “We’d have to redo a lot” = fragile.
“How much of this did you write versus generate, and do you understand all of it?” The honest answer to this one tells you almost everything.

The cheap way to know for sure

You can’t fully self-diagnose a codebase, and that’s fine — you shouldn’t have to. But you can get a second opinion cheaply before you sink more money in. A short, independent audit by a senior engineer will tell you, in plain English: what you actually have, what’s solid, what’s padding, what’s a risk, and what it would take to make it healthy.

That’s a few days of someone’s time against a build you might otherwise pour months of runway into. If there’s one thing I’d tell every non-technical founder: the second opinion is the cheapest insurance you’ll ever buy.