Why We Don't Use AI to Analyze Your Repository

There is an obvious joke here. We built a deployment platform for AI-generated apps, and we chose not to use AI to analyze them.

It was not an oversight. It was the first architectural decision we made, and we would make it again.

Your repository is structured data. Treat it that way.

A package.json file is not a document. It is a machine-readable specification. It tells you exactly which framework is installed, which ORM is in use, which package manager generated the lockfile, and what version of Node.js the author intended.

A prisma/schema.prisma file tells you exactly which database provider the app expects. A .nvmrc file tells you exactly which Node version to use. A bun.lockb tells you the package manager is Bun.

None of this requires interpretation. It requires reading.

Sending structured, deterministic data to a language model is the wrong tool for the job. Language models are designed to handle ambiguity in natural language. It is like running a JSON file through a sentiment analyzer. The data has a schema. Use the schema.

Deployments must be deterministic

This is the one that matters most.

Imagine you deploy your app on a Tuesday. It works. You push a small change on Thursday and redeploy. It fails. Nothing in your code changed that would affect how the app should run. But the deployment behaves differently.

With an AI-based detection system, this is a real possibility. Language models are not pure functions. The same input does not guarantee the same output. Model updates, temperature variations, context window differences: any of these can silently produce a different detection result between two deploys of the same repository.

In a chatbot, that is a minor annoyance. In a deployment pipeline, it is a production incident with no obvious cause. The developer has no idea why Tuesday worked and Thursday did not. Nothing changed. The infrastructure did.

Jetpacked's detection engine is a pure function. Same repository, same branch, same result. Every time. If your app deployed successfully on Tuesday, the detection logic on Thursday is identical. If something breaks, you know it is in your code, not in the infrastructure reading it.

Confidence, not probability

Language models are probabilistic. They are remarkably good at approximating the right answer, but approximately right is not a bar you can build infrastructure on.

A rule-based engine that reads next.config.js and finds a Next.js configuration object is not guessing. It is reading. The confidence level is 100%, not 94%.

When Jetpacked detects that your app uses Prisma with a PostgreSQL provider, it is reading the provider field in your schema.prisma file. When it detects pnpm, it is checking for the presence of pnpm-lock.yaml. These are lookups, not predictions.

The distinction matters when the output of detection is "provision a PostgreSQL database and inject a connection string." Getting that wrong is not a wrong answer. It is a broken deployment.

Your source code should never leave your environment unnecessarily

When you connect a repository to Jetpacked, the detection engine reads structural metadata: manifest files, config files, directory structure, lockfiles. It does not read your application logic, your business code, or your environment variables.

An AI-based detection system requires sending more of your repository to an external model. Your database schema. Your authentication logic. Your API routes. The contents of files that describe how your business works.

Some deployment platforms ask you to upload your .env file and hand it directly to their AI. For vibe coders who are not thinking about this, that file almost certainly contains Stripe keys, OpenAI API keys, database passwords, and auth secrets.

Jetpacked does not want that data. Your secrets are stored encrypted and are explicitly redacted from any diagnostic output. The detection signal needed to deploy your app lives entirely in the structural layer of your repository. That is where the engine stays.

Speed and cost

A rule-based detection pass over a repository takes milliseconds. An LLM inference call adds hundreds of milliseconds of latency, plus network overhead, plus the possibility of a retry if the call fails.

At low volume, an LLM call per deployment is cheap. At scale, it compounds into a meaningful cost that either compresses margins or gets passed to users. A rule-based engine has no per-deployment inference cost.

Where AI belongs in a deployment pipeline

Jetpacked uses AI in one narrow place: failure recovery.

When a deployment fails with an ambiguous error, something that does not match a known pattern, structured metadata and redacted log output can be passed to a model to help explain what went wrong in plain language. The model is helping with language, not making infrastructure decisions.

That is the right use of AI in a deployment pipeline: explaining things when the structured signal runs out. Not deciding which database to provision. Not guessing which framework your app uses. Not reading files it has no business reading.

The rule

AI is for ambiguity. Rules are for structure.

Your repository is structured. Your deployment should be reproducible. The infrastructure that connects them should be deterministic.

That is why Jetpacked does not use AI to analyze your repository.