Guides

What breaks when AI-generated apps go to production

AI-generated apps usually break in production in the parts a demo never exercises: security, error handling and visibility into failures. When Astro scanned 103,653 public GitHub repositories that look AI-generated, 93% of the 53,588 that could be scored had no logging, 91% had no timeouts on external HTTP calls, and 86% were missing API auth guards.

Only 1% scored as production ready. The interface usually works; what is missing is everything around it.

The free scan this guide points to works on JavaScript and TypeScript projects. On another stack, use the production readiness checklist and check each item by hand.

What the scan found

Percentages are shares of the 53,588 repositories that had enough code to score. Each line is a gap that is invisible in a demo and expensive in production.

  1. 93% had no logging or observability

    When something fails, nothing records it. You find out from a user, or not at all, and you have nothing to debug with.

  2. 91% had no timeouts on external HTTP calls

    Apps built with AI lean on outside services: AI models, payments, email. Without a timeout, a slow vendor holds every request open and the whole app stalls.

  3. 86% were missing API auth guards

    The interface asks users to sign in, but the API routes behind it do not check. Anyone who finds the endpoint can read or change data.

  4. 85% had no error boundaries

    One failing component takes down the whole screen, and the user sees a blank page instead of a message.

  5. 75% had hardcoded secrets or no environment separation

    API keys sit in the code, or development and production share the same settings. A leaked key or a test run against live data becomes a real incident.

  6. 64% had no CI/CD

    Changes go out without any automatic checks, so each release is a gamble.

  7. 60% had no tests

    Nothing confirms that sign up, payment or the core feature still work after the next change.

How the scores were spread

Each repository received a score from 0 to 100 based on 22 checks. The average was 53. Only 1% scored 86 to 100, the production ready band. 83% scored 0 to 65, which means critical or significant gaps.

None of these gaps are exotic. AI coding builds what you ask for, and in a demo nobody asks for timeouts, auth checks on every route, or logs. Those are the parts that go missing.

What to do with this

  1. Scan your own repo

    These are averages across tens of thousands of projects. Your app may be better or worse. Astro Score runs the same 22 checks on your repo for free.

  2. Fix the gaps in order of risk

    Start with anything that exposes data or money, then make failures visible, then make change safe. The production readiness checklist lays out the order.

  3. Decide whether to harden or start fresh

    Most of these gaps can be added to an existing app. If yours sit in the foundations, read Harden or rebuild your AI-built app?

Common questions

How many AI-generated apps are production ready?
Very few. In Astro's April 2026 scan, 1% of the 53,588 scored repositories reached the production ready band (86 to 100). 83% scored 0 to 65, which means critical or significant gaps. The average score was 53 out of 100.
What is the most common gap?
Missing logging and observability. 93% of the scored repositories had none, so failures in production would go unseen until a user reported them.
Where does this data come from?
Astro scanned 103,653 public GitHub repositories with strong signals of being AI-generated in April 2026. 53,588 had enough code to be scored with the same 22 checks that Astro Score runs.

About this data

In April 2026, Astro scanned 103,653 public GitHub repositories with strong signals of being AI-generated. 53,588 of them had enough JavaScript or TypeScript code to be scored, and every percentage on this page is a share of those 53,588. Each repository went through the same 22 automated checks that Astro Score runs.

The checks read the code; they do not run the app. A check passes when the safeguard is present in the code, which is not the same as proving it works. Public repositories are not a random sample of every app in production, so treat the numbers as a strong pattern rather than a census.