Is Your Codebase AI-Ready? A CTO Checklist

Before you hand your codebase to an AI pair-programmer (or hire a team that builds with AI) it is worth doing an honest audit. Not of the AI tools, but of the codebase itself. Weak foundations amplify AI mistakes as efficiently as they amplify human ones.

This is the checklist we run before we touch a new codebase. It is not exhaustive, but every item on it has surfaced a real problem on a real project.

The checklist

1. Is the test coverage meaningful?

Not the percentage. The intent. Unit tests that only assert happy paths give AI nothing to learn from and nothing to catch regressions with. Look for tests that cover edge cases, error states, and the business rules that actually matter. If coverage is mostly greenfield assertions, plan for the AI to silently break things the tests never checked.

2. Is the schema documented and stable?

AI tools generate code from context. If your database schema is undocumented, implied by migration files, or actively diverging from the models layer, the AI will guess, and it will guess wrong in quiet, non-crashing ways. A typed schema with a clear source of truth (Prisma, TypeSpec, OpenAPI) is table stakes.

3. Is there a local development environment that actually runs?

A codebase an AI can run locally is a codebase it can evaluate. If local setup requires tribal knowledge, manual seed steps, or environment variables that live in someone's head, AI agents cannot self-verify their changes. Document the runbook. Make docker compose up actually work.

4. Are the boundaries between modules explicit?

AI tools are good at working within a module and bad at knowing which modules they should not cross. If your codebase is a ball of mud (where auth logic lives in the payment module and business logic leaks into the router) expect the AI to make those same mistakes, at higher speed. Explicit interfaces and clear ownership matter here.

5. Is secrets management clean?

AI tools log context, and many services upload context for fine-tuning. If API keys, credentials, or personal data appear in source files, .env.example files, or comments, audit them before any AI tool touches the repository. This is also a basic hygiene question independent of AI. But AI raises the stakes.

6. Are the dependencies audited and up to date?

Outdated dependencies are a compounding risk with AI tooling: the AI will generate code for the version it was trained on, not the version you're running. A gap of two major versions in a core library (Next.js, Rails, Django) means the AI produces plausible-looking code that silently breaks at runtime. Run npm audit or bundle audit and address the critical findings before starting.

7. Is error handling consistent and observable?

If your codebase swallows errors silently, or if logging is inconsistent, AI-generated changes will inherit the same behaviour. You need observability (structured logging, error tracking, meaningful exception messages) to diagnose what the AI did wrong after the fact. Without it, debugging AI-introduced bugs is nearly impossible.

8. Is the CI pipeline fast and blocking?

A CI pipeline that takes 40 minutes and is routinely bypassed is not a safety net. AI tools iterate fast, and the feedback loop they rely on is the test suite. If CI is broken or slow, AI agents will ship untested changes. Aim for a pipeline under 10 minutes that blocks merges on failure.

9. Is there a clear separation between configuration and code?

Hardcoded environment assumptions, feature flags buried in conditionals, or configuration that only exists in production deployments. All of these mean AI tools cannot reason about how the code will actually behave. Use environment variables, feature-flag infrastructure, or a config layer the AI can read and modify predictably.

10. Is the git history clean and descriptive?

AI tools use git history for context: who changed what, why, and when. A history of fix, stuff, and wip commits is not a history the AI can learn from. This is less about AI readiness and more about engineering culture. But it surfaces when AI tools try to reason about intent and cannot.

11. Are the deployment and rollback steps documented?

If deployment requires a senior engineer on a call and rollback is "delete the database and restore a snapshot from last Tuesday," the blast radius of an AI mistake is significantly higher. Documented deployment, automated rollback, and feature-flag kills reduce the risk of AI-introduced regressions to something manageable.

12. Is there a human review step that is actually enforced?

AI tools are fast. That is their value. But speed without review is the specific failure mode that ships broken code to production. Pull request reviews, required approvals, and a culture where "the AI wrote it" does not substitute for "a senior engineer checked it" are not optional when the throughput of change increases.

---

What to do with the results

If you answered "no" to more than four of these, the codebase is not AI-ready, not because AI tools are dangerous, but because the codebase does not have the foundations that make any fast iteration safe. Fix the foundations first.

If you are preparing to work with an external team that uses AI tooling, the same checklist applies. We run a technical audit as a standalone engagement for exactly this reason: to give you an honest read before the build starts.

If you are generally curious about what AI-native engineering looks like in practice, the Basetool Labs blog has more on how we think about it.

---

This checklist reflects our current practice at Basetool Labs. It will change as tooling matures.