The 10 Patterns in AI-Generated Repos That Break Standard Deployment Pipelines

AI coding tools are remarkably good at writing software. They are not trained on what that software needs to run in production. The code they generate is optimized for local development: it runs, it works, it looks right. Then you try to deploy it.

The failures are not random. There are specific patterns that show up again and again in AI-generated repos, and they break deployments in predictable ways. Here are the ten most common ones.

1. Hardcoded localhost in configuration

AI tools generate configuration for the environment they are solving for, which is your local machine. The result is values like this scattered through config files and environment variable examples:

DATABASE_URL=postgres://localhost:5432/myapp
REDIS_URL=redis://localhost:6379
APP_URL=http://localhost:3000

These are correct locally. On a server, localhost refers to the server itself, not to your development machine. Any service that is not running on the same server as your app will be unreachable, and any URL your app generates will point nowhere useful.

Standard deployment detection tools often do not catch these because the values are syntactically valid. They are only wrong in context.

Jetpacked scans configuration and environment variable examples during analysis and flags localhost references that will not work in production.

2. Missing start command

AI tools often generate a package.json or equivalent with a dev script but no start script, or with a start script that still runs a development server. The build step produces optimized output but no clear instruction for how to actually serve it.

{
  "scripts": {
    "dev": "vite",
    "build": "vite build"
  }
}

A deployment platform needs to know what command to run after the build finishes. Without a start script, it will either guess wrong, run the dev server, or fail entirely.

Jetpacked infers the correct start command from your framework and build output, so a missing start script does not become a failed deployment.

3. No production build step

Some AI-generated apps skip the build step entirely. The source files work fine when served through a dev server that handles transpilation on the fly. Deployed without a build step, the server tries to run raw TypeScript or JSX and fails immediately.

This is common with TypeScript projects where the developer never explicitly told the AI they needed a compiled output. The AI generates working local code and never addresses what happens when it runs on a Node.js process that does not understand TypeScript natively.

4. Dependencies in the wrong section

AI tools frequently put packages in dependencies that belong in devDependencies, and occasionally the reverse. The practical consequence is that production builds either install packages they do not need, or fail because a required package was only installed in development.

A related issue: AI tools sometimes generate code that imports packages that are not listed in package.json at all, because the package was available globally in the development environment and the AI never noticed it was not declared.

Jetpacked validates dependencies against actual imports during analysis and catches unlisted packages before they cause a runtime failure.

5. Environment variable references with no documentation

AI tools generate code that reads from environment variables (process.env.STRIPE_SECRET_KEY, process.env.DATABASE_URL) but rarely generate a complete list of what those variables should contain or where to get them. The .env.example file, if it exists at all, is often incomplete.

When you go to deploy, you are left guessing what the app needs. Anything missing causes a silent failure or a crash that is hard to diagnose if you do not know to look for it.

Jetpacked reads your codebase and builds a complete list of every environment variable your app references, then asks you to provide any that are not already set.

6. Filesystem writes for persistent data

AI tools often generate file upload handlers, log writers, and cache systems that write to the local filesystem. This works in development because files persist between runs. On most deployment platforms, the filesystem is ephemeral: it resets on every deploy, and sometimes between requests.

Uploaded files disappear. Logs written to disk are lost. Cache files that should persist between requests do not.

The pattern is subtle because the code is not wrong. It works fine in development and produces no errors in production. The data just does not survive.

7. Database connections without pooling

AI tools generate database connection code that opens a new connection on every request or creates a single persistent connection with no pool management. In a long-running server that handles many simultaneous requests, this exhausts the database's connection limit and causes failures that look like database errors but are actually connection management errors.

// Common AI-generated pattern
const db = new PrismaClient()
// One client per module - may create multiple connections in serverless

This does not appear in development because local development rarely hits the connection limits that production does under real traffic.

8. Synchronous blocking operations

AI tools sometimes generate synchronous file I/O, synchronous database calls, or blocking computation in request handlers. In development this is invisible: requests are fast and there is only one user. In production, a single slow synchronous operation blocks the entire event loop, causing every other request to queue behind it.

The app appears to work but becomes unresponsive under any meaningful load.

9. Missing health check endpoint

Deployment platforms use health check endpoints to verify that an app is running correctly after startup. If the platform cannot reach a health check endpoint, it marks the deployment as failed and either rolls back or keeps the app in a restart loop.

AI tools almost never generate health check endpoints. The deployment platform makes a request to /health or /healthz, gets a 404, and concludes the app is broken.

Jetpacked detects frameworks that need health check configuration and adds one automatically.

10. Worker processes with no startup configuration

AI tools reach for job queues (BullMQ, Bee-Queue, similar packages) when you describe background work. They write the queue producers and consumers correctly. They do not write the process configuration that tells a deployment platform to run the worker alongside the main app.

The result: the queue fills up and nothing processes. Jobs are created, acknowledged, and then sit. The app appears to work because it does not crash. A whole category of features silently does nothing.

Jetpacked detects queue worker patterns and starts the worker as a separate process alongside your main app. You do not configure this explicitly.

The common thread

None of these patterns represent bad code. They represent code written for the wrong environment. AI tools are solving the development problem: make it work here, now, for one developer. Production is a different problem: make it work on a machine you have never seen, for users you cannot predict, across deploys that happen while people are using it.

The patterns above are predictable. Detecting them is an analysis problem, and Jetpacked runs that analysis on every repository before any deployment goes out.