What to actually check in a technical due diligence of an AI codebase

AI now writes a serious share of new code. GitHub has put Copilot's contribution past 40% in files where it's turned on. Most technical due diligence checklists were written for a world where a person typed every line, and it shows.

The worst one I've reviewed looked completely finished. The app worked, the demo was clean, the founder was proud of it. It was built on Base44, and his whole know-how, the prompts, the logic, the thing he thought he was selling, sat in the frontend. No backend at all. Just a React app with Supabase as storage. Anyone who opened the browser dev tools could copy the entire product in an afternoon. That is what I mean when I say an AI-built codebase can look finished and still be hollow.

I run these reviews for founders before a raise, and for investors and acquirers before they wire the money. Here is what I look for, and the findings that move the price.

Where the value lives

Start with where the value sits, because that is what you are paying for. On that Base44 app it sat in the browser, which is to say nowhere safe. Secret keys that belonged on a server were shipped to the client. The business logic was there for anyone to read. When the product is the know-how and the know-how is public, the moat is gone, and the number on the deal has to follow.

So I open the network tab before I open the code. What gets sent to the browser? What does the backend enforce, and what is just a button hidden in the UI? More than once the honest answer was nothing. Every screen trusted whatever the client handed it.

Authorization is the usual hole

AI-built apps rarely get access control right. That same codebase had no shared authorization at all. Every module reinvented it from scratch, so every module got it a little wrong. Check that the server decides who sees what, that row-level access is real, and that changing an id in a URL doesn't hand you a stranger's record. It often does.

This is where a good pattern beats a good model. Give AI a solid example and it will copy it everywhere, which is its strength. Give it nothing to follow and the quality falls off a cliff. A codebase with no auth pattern is one where auth is wrong in twenty places at once.

Clean-looking code that reuses nothing

The most common structural problem I see in fresh AI projects is duplication. The model starts each task with no memory of the rest of the code, so instead of reusing the button that already exists, it builds a new one, with its own colour and its own copy of logic you already had. A developer catches that and stops it. A non-technical founder does not, and here is the trap. The model then reads its own duplication as the house style and repeats it harder. By the time anyone looks, the same thing is done ten different ways.

So I am not impressed that the code reads cleanly. AI code usually does. What I want to know is whether there is one way to do a thing, or fifteen. Fifteen is slow and dangerous to change, however tidy each copy looks on its own.

Tests, structure, the parts that bite later

Are there tests, and do they assert anything? AI loves to write tests that check nothing, which is worse than none, because it looks like coverage. Is there a migration history, or is the schema edited by hand against production? Could a new developer find their way around in a day? And ask who understands it, because if the founder can't explain how the core works, you are buying a maintenance bill, not a product.

Can you even take it with you

Lock-in is real and easy to miss. That Base44 backend cannot be exported, so leaving the platform means rebuilding it from nothing, which is exactly what we are doing for that client now. A smaller case was built on Lovable, a good-looking React site with no server rendering, so no SEO and a layout that came apart on real phones. It had to be rewritten too. Pretty is cheap. Portable and correct is not.

Red flags that move the number

A short list, because some things are just bad signs.

• Secret keys or business logic shipped to the frontend.
• No real authorization, or auth rebuilt screen by screen.
• Tests that assert nothing.
• The same logic pasted in ten places.
• A backend you cannot export off the platform.
• "It only runs on the founder's laptop."

What you get from me

A short report in plain language, ranked by risk, with a rough cost to fix the serious items. No 200-page tool dump nobody reads. Often the verdict is not "walk away", it is "this is fixable, here is the order to do it". Decide to fix it, and my team at Fingoweb does the work.