The promises of AI-powered development are intoxicating: ship features in hours instead of weeks, prototype entire applications in a single afternoon, turn ideas into working code with a conversation. Tools like Cursor, GitHub Copilot, v0, and Claude are transforming how we build software, and the results can be genuinely impressive.

But here's the uncomfortable truth that organizations are discovering: AI excels at generating code that works, but it's inconsistent at generating code that's production-ready.

The AI Development Paradox

In early 2026, we're seeing a pattern emerge across engineering teams:

• The Good: AI tools can scaffold a full-stack Next.js app with authentication, database integration, and a polished UI in hours
• The Problem: That same app often ships with disabled RLS policies, missing error boundaries, no rate limiting, implicit caching bugs, and security vulnerabilities the AI didn't even know existed

AI coding assistants are trained on vast amounts of code, but they don't inherently understand:

• Which security practices are non-negotiable vs. nice-to-have
• How recent framework changes (like Next.js 16's caching overhaul) affect existing patterns
• The difference between "demo-quality" and "handles-10,000-concurrent-users" quality
• Your organization's specific compliance, scalability, or reliability requirements

What This Means for Organizations

If your team is using AI to accelerate development (and you should be), you're likely experiencing one of two scenarios:

Scenario 1: The Velocity Trap Your team is shipping features faster than ever. Stakeholders are thrilled. Then production incidents start: a user accesses another user's data (RLS was never enabled), your database gets hammered with N+1 queries, your caching strategy creates stale data bugs, or you discover a critical CVE that AI-generated code is vulnerable to.

Scenario 2: The Over-Correction Your team becomes paranoid about AI-generated code and institutes such heavy review processes that you've negated all the velocity gains. You're essentially using AI as an expensive autocomplete.

The Solution: Structured Quality Gates

The answer isn't to stop using AI—it's to implement systematic checks that validate AI output against production requirements. Think of it like this:

• AI is your accelerant (5-10x faster code generation)
• This checklist is your quality gate (ensures production-readiness)
• Together, they give you both speed and confidence

Why This Checklist Exists

This checklist was purpose-built for the AI era. It's specifically designed to catch the categories of issues that AI tools commonly miss or deprioritize:

1. Security Gaps: AI might generate authentication flows but skip RLS policies, rate limiting, or input sanitization
2. Framework Version Mismatches: AI training data lags behind latest releases (Next.js 16 changed caching fundamentally—does your AI know?)
3. Production vs. Prototype Patterns: AI defaults to "make it work" not "make it scalable and maintainable"
4. Multi-tenant Architecture: AI often generates single-tenant patterns even when you need isolation
5. Error Handling & Observability: AI focuses on happy paths, not production resilience
6. Compliance Requirements: GDPR, SOC2, HIPAA—AI doesn't know your regulatory context

How to Use This Checklist with AI Development

Before AI Coding: Share relevant sections with your AI assistant as context

"Here are the security requirements from our production checklist. Ensure the code you generate follows these patterns."

During Development: Use as validation criteria in prompts

"Generate a Supabase query for user data. Ensure RLS is enabled, queries are parameterized, and errors are handled per our checklist."

Before Deployment: Systematic review by a human who understands the "why" behind each requirement

Even if AI generated the code, a human must verify it meets production standards.

Post-Incident: Update the checklist with lessons learned

Found a production issue in AI-generated code? Add a check so it doesn't happen again.

The Bottom Line

AI coding tools are not going away—they're getting more powerful. The organizations that will thrive in this new era aren't the ones that resist AI or blindly trust it. They're the ones that pair AI's velocity with human judgment and systematic quality controls.

This checklist represents thousands of hours of production incidents, security audits, performance optimizations, and hard-won lessons. Use it to ensure your AI-accelerated development maintains the standards your users and business depend on.

Remember : AI can write code in seconds. But it takes human expertise to know what production-ready actually means.

Version: 2.0
Last Updated: February 2026
Optimized for: Next.js 16.1.1, React 19.2.1, TypeScript 5, Vitest 2.0, Tailwind CSS 4, ESLint 9, Zod 4.3.5

🏗️ Architecture & Setup

Next.js 16 Configuration

• Using Next.js 16.1.1+ with App Router (not Pages Router)
• Turbopack is the default bundler (no --turbopack flag needed)
• next.config.ts or next.config.js properly configured with strict mode enabled
• Using native TypeScript for next.config.ts (no compilation step needed in Next.js 16)
• Output set to appropriate target (standalone for containerized deployments)
• Environment variables properly configured via .env.local (dev) and deployment platform (prod)
• No sensitive keys exposed in client-side code (no NEXT_PUBLIC_ prefix on sensitive data)
• Proper TypeScript configuration (strict: true in tsconfig.json)
• Path aliases configured (@/ for cleaner imports)

Project Structure

• Clear separation of concerns: /app, /components, /lib, /types, /utils
• Server components are default; Client components explicitly marked with 'use client'
• Shared types in /types directory with proper exports
• Database types generated from Supabase (supabase gen types typescript)
• Utilities properly organized and reusable

Dependencies

• All dependencies up to date (check for security vulnerabilities)
• No unused dependencies in package.json
• Dev dependencies properly separated from production dependencies
• Lock file (package-lock.json or pnpm-lock.yaml) committed to repo

Next.js 16 Specific Features

• Using "use cache" directive for explicit caching (not implicit caching)
• Using updateTag() for read-your-writes semantics (immediate cache updates)
• Using revalidateTag() for background cache updates (when delay is acceptable)
• Middleware renamed from middleware.ts to proxy.ts (Next.js 16 convention)
• Proxy file kept lightweight (redirect/routing logic only, not heavy business logic)
• React 19.2 features utilized where appropriate (<Activity>, useEffectEvent)
• Async route params, cookies(), and headers() accessors handled correctly

🔐 Authentication & Authorization

Supabase Auth Setup

• Supabase Auth properly initialized with correct environment variables
• Using @supabase/ssr package for server-side auth (not deprecated @supabase/auth-helpers)
• Server-side Supabase client created using cookies (createServerClient)
• Client-side Supabase client created with proper browser configuration
• Middleware configured to refresh auth tokens on every request
• Route protection implemented via middleware for protected routes

Authentication Flow

• Sign up flow implemented with email verification (if required)
• Sign in flow with proper error handling
• Sign out functionality properly clears session and redirects
• Password reset flow implemented
• OAuth providers configured (if applicable)
• Auth state properly persisted across page refreshes
• Redirect URLs properly configured in Supabase dashboard

Authorization & Multi-tenancy

• Row Level Security (RLS) enabled on ALL Supabase tables
• RLS policies created for each table (SELECT, INSERT, UPDATE, DELETE)
• Tenant isolation enforced via RLS policies (e.g., tenant_id = auth.uid() or team-based)
• Multi-tenant architecture clearly defined (per-user, per-organization, etc.)
• Tenant context properly maintained throughout the application
• Users cannot access data from other tenants (tested!)
• Admin/owner roles properly implemented with appropriate permissions
• API routes check authorization before data access

Session Management

• Session timeout configured appropriately
• Refresh token rotation enabled
• Session properly validated on server components
• Protected routes redirect to login when session expires
• No auth state stored in localStorage (use Supabase session management)

🗄️ Database & Data Management

Supabase Database

• Database schema properly designed with appropriate relationships
• Foreign keys defined with proper CASCADE/RESTRICT behavior
• Indexes created on frequently queried columns
• created_at and updated_at timestamps on all relevant tables
• Soft deletes implemented where appropriate (vs hard deletes)
• Migration files committed to version control
• Database functions used for complex operations (not in application code)

Multi-tenant Data Model

• Tenant identifier column on all multi-tenant tables (tenant_id, org_id, user_id)
• Default values set for tenant columns (e.g., auth.uid())
• Tenant foreign keys reference correct user/org tables
• Composite indexes include tenant identifier for query performance
• RLS policies explicitly filter by tenant identifier
• Test data created for multiple tenants to verify isolation

Data Validation (Zod 4)

• Zod 4 schemas defined for all data models
• Server-side validation using Zod for ALL mutations
• Using unified error parameter (not deprecated message, invalid_type_error, required_error)
• Proper error messages returned from validation failures
• Type safety between database types and Zod schemas
• Validation applied to form inputs, API routes, and server actions
• SQL injection prevention (parameterized queries via Supabase client)
• Using @zod/mini for client-side bundles where bundle size matters (tree-shakable)
• File validation using z.file() with size and MIME type checks (if handling uploads)
• Custom metadata on schemas using .meta() where needed (e.g., for form generation)
• Using z.interface() for recursive types instead of z.lazy()
• JSON Schema export/import using .toJSONSchema() / .fromJSONSchema() (if integrating with OpenAPI)

Data Fetching

• Data fetching done on server components by default
• Client-side fetching only when necessary (real-time, user interactions)
• No data over-fetching (select only needed columns)
• Proper pagination implemented for large datasets
• Efficient query patterns (avoid N+1 queries)
• Real-time subscriptions cleaned up on unmount
• Optimistic updates implemented where appropriate

🔒 Security

API Security

• All API routes validate authentication
• API routes validate authorization (user permissions)
• Input validation on all API routes using Zod
• CSRF protection enabled (Next.js default)
• Rate limiting implemented on sensitive endpoints
• No sensitive data in URL parameters (use POST body)
• Proper HTTP status codes returned (401, 403, 404, 500, etc.)

Environment Variables

• All secrets stored in environment variables (never hardcoded)
• .env.local in .gitignore
• Separate env vars for development and production
• NEXT_PUBLIC_ prefix only on truly public variables
• No accidental logging of environment variables
• Environment variables validated on startup (using Zod or similar)

Headers & Configuration

• Security headers configured (X-Frame-Options, X-Content-Type-Options, etc.)
• Content Security Policy (CSP) configured if needed
• CORS properly configured for API routes
• Cookies set with httpOnly, secure, sameSite attributes
• No sensitive information in cookies beyond session identifiers

Code Security

• No use of dangerouslySetInnerHTML without sanitization
• User input sanitized before rendering
• File uploads properly validated (type, size, content)
• No eval() or similar dynamic code execution
• Dependencies scanned for vulnerabilities (npm audit)

⚡ Performance

Rendering Strategy

• Server Components used by default
• Client Components only where necessary (interactivity, hooks, browser APIs)
• Static rendering used where possible (for public pages)
• Dynamic rendering only when needed (user-specific data)
• ISR or on-demand revalidation configured for semi-static content
• Streaming used for pages with slow data fetching

Code Optimization

• Code splitting implemented (automatic with App Router)
• Dynamic imports for heavy components (next/dynamic)
• Tree shaking enabled (automatic with production builds)
• Bundle size analyzed (@next/bundle-analyzer)
• No unused code or large dependencies
• Shared components properly memoized (React.memo) if needed

Image & Asset Optimization

• Using next/image for all images
• Images optimized and properly sized
• Lazy loading enabled for below-fold images
• Appropriate image formats used (WebP with fallbacks)
• Static assets in /public folder
• Fonts optimized using next/font

Database Performance

• Database queries optimized (explain analyze checked)
• Appropriate indexes on filtered/sorted columns
• Connection pooling configured (Supabase handles this)
• No queries in loops (batch operations)
• Caching strategy for frequently accessed data

Caching (Next.js 16 Explicit Model)

• Using "use cache" directive for explicit caching (opt-in model in Next.js 16)
• No reliance on implicit caching (Next.js 16 changed to explicit-only)
• Cache keys automatically generated by compiler where "use cache" is used
• Using updateTag() for immediate cache invalidation (read-your-writes semantics)
• Using revalidateTag() for background revalidation (when delay is acceptable)
• React cache() used for deduplicating requests within same render
• Static pages properly cached at build time
• Dynamic pages using appropriate cache strategies

🐛 Error Handling

Error Boundaries

• Error boundary components implemented
• Global error.tsx for route-level errors
• Specific error handling for critical sections
• User-friendly error messages (no stack traces in production)
• Errors logged to monitoring service

API Error Handling

• Try-catch blocks around all async operations
• Consistent error response format
• Proper error status codes
• Meaningful error messages
• Validation errors clearly communicated
• Supabase errors properly handled and translated

Form Handling

• Client-side validation for immediate feedback
• Server-side validation as source of truth
• Loading states during submission
• Error states clearly displayed
• Success confirmations shown
• Form reset after successful submission

Fallbacks

• Loading.tsx for suspense boundaries
• Not-found.tsx for 404 errors
• Appropriate fallback UI for error states
• Graceful degradation when features fail

🧪 Testing

Test Coverage (Vitest 2.0+)

• Unit tests for utility functions using Vitest
• Integration tests for API routes
• Component tests using @testing-library/react 16.0
• End-to-end tests for critical user flows
• Test coverage above 70% for business logic
• Using Vitest's default forks pool (child_process instead of Worker threads)
• coverage.ignoreEmptyLines enabled (default in Vitest 2.0)
• Browser mode tests if testing client-side functionality
• Module mocking working in browser mode (if used)
• Using expect.poll for async assertions
• Blob reporter for CI/CD pipeline test result aggregation

Multi-tenant Testing

• Tests verify tenant isolation (User A cannot access User B's data)
• Tests verify tenant switching (if applicable)
• Tests verify RLS policies work correctly
• Tests verify admin/owner permissions
• Tests use separate test tenants/users
• Database seeded with multi-tenant test data

Authentication Testing

• Tests verify protected routes redirect unauthenticated users
• Tests verify authenticated users can access protected routes
• Tests verify unauthorized users cannot perform admin actions
• Tests verify session persistence
• Tests verify logout functionality

Data Validation Testing

• Tests verify Zod schemas reject invalid data
• Tests verify API routes validate inputs
• Tests verify database constraints
• Tests verify error messages are helpful

📝 Code Quality

TypeScript

• Strict mode enabled
• No any types (or properly justified)
• Proper type definitions for all functions
• Types imported from generated Supabase types
• No TypeScript errors or warnings

ESLint 9 (Flat Config)

• Using eslint.config.js (or .mjs/.cjs) not .eslintrc.*
• Flat config array format with proper ES module imports
• Using defineConfig() helper from eslint/config
• Using globalIgnores() for global ignore patterns (not implicit ignores)
• Plugins imported as JavaScript objects (not string-based)
• languageOptions.globals configured (not env property)
• All plugins compatible with ESLint 9 flat config
• No ESLint errors or warnings in production code
• React hooks rules configured (eslint-plugin-react-hooks)

Code Style

• Prettier 3.8.1+ configured for consistent formatting
• Pre-commit hooks configured (husky + lint-staged)
• Consistent naming conventions
• No commented-out code
• No console.logs in production code (use proper logging)

Documentation

• README with setup instructions
• Environment variable documentation
• Complex functions have JSDoc comments
• Architecture decisions documented
• API routes documented (if external-facing)

Accessibility

• Semantic HTML used
• ARIA labels on interactive elements
• Keyboard navigation works
• Color contrast meets WCAG standards
• Forms have proper labels and error associations

Tailwind CSS 4

• Using @import "tailwindcss" in CSS (not @tailwind directives)
• CSS-first configuration with @theme directive (no tailwind.config.js unless needed)
• Automatic content detection working (no manual content array unless overriding)
• OKLCH colors used for custom colors (better color uniformity)
• Native cascade layers utilized (@layer)
• No CSS preprocessors (Sass/Less/Stylus) - incompatible with Tailwind CSS 4
• Using size-* utility for width+height shortcuts
• Container queries used where appropriate
• Text shadow and mask utilities used if needed
• Browser compatibility: targets Safari 16.4+, Chrome 111+, Firefox 128+

React 19.2 Features (if applicable)

• Using <Activity> component for managing hidden/visible UI sections (better than conditional rendering)
• Using useEffectEvent for stable event handlers in effects (avoids unnecessary re-runs)
• View Transitions supported with proper view-transition-name CSS
• React Compiler enabled if using React Compiler 1.0+
• Performance Tracks in Chrome DevTools used for profiling (Scheduler and Components tracks)

🚀 Deployment Readiness

Build Process

• Production build succeeds (npm run build)
• No build warnings (or properly investigated)
• Build output size is reasonable
• Environment variables set in deployment platform
• Build cache configured for faster deployments

Environment Configuration

• Production environment variables configured
• Database connection string points to production
• Supabase project URL and anon key for production
• API keys for third-party services configured
• BASE_URL or NEXT_PUBLIC_APP_URL set correctly

Database Migrations

• All migrations tested in staging environment
• Migration rollback plan documented
• Data migration scripts tested with production-like data
• No breaking changes without proper migration strategy

Deployment Platform

• Hosting platform selected (Vercel, Netlify, etc.)
• Custom domain configured
• SSL certificate active
• DNS properly configured
• CDN configured for static assets
• Auto-deployment from main branch configured

Monitoring Setup

• Error tracking configured (Sentry, LogRocket, etc.)
• Performance monitoring enabled
• Logging solution configured
• Uptime monitoring configured
• Alerts configured for critical errors

📊 Monitoring & Observability

Logging

• Structured logging implemented
• Log levels appropriately set (error, warn, info, debug)
• No sensitive data in logs
• Logs aggregated in centralized system
• Server actions log important events

Analytics

• Analytics tool configured (if needed)
• Key user events tracked
• Privacy policy updated for tracking
• Cookie consent implemented (if required)

Performance Metrics

• Core Web Vitals tracked
• API response times monitored
• Database query performance monitored
• Bundle size tracked over time

Alerting

• Alerts for error rate spikes
• Alerts for performance degradation
• Alerts for downtime
• On-call rotation defined (if team size warrants)

🔄 Additional Best Practices

Server Actions

• Server actions used for mutations instead of API routes (where appropriate)
• Server actions properly validated with Zod
• Server actions handle errors gracefully
• Server actions revalidate relevant paths/tags after mutations
• Progressive enhancement considered (works without JS if possible)

Server Components

• No useState, useEffect, or browser APIs in Server Components
• Data fetching done directly in Server Components
• Async Server Components used for data fetching
• Props passed to Client Components are serializable

Supabase Best Practices

• Using Supabase client helpers correctly (createServerClient, createBrowserClient)
• Not exposing service role key to client
• RLS policies tested in Supabase SQL editor
• Database functions used for complex operations
• Realtime subscriptions properly managed

SEO (if applicable)

• Metadata properly configured in layout.tsx and page.tsx
• Open Graph tags configured
• Sitemap generated
• Robots.txt configured
• Canonical URLs set

✅ Final Checklist Before Production

• All above sections reviewed and checked
• Staging environment tested thoroughly
• Load testing performed (if high traffic expected)
• Security audit completed
• Legal requirements met (privacy policy, terms of service, GDPR, etc.)
• Backup and disaster recovery plan documented
• Rollback plan documented
• Team trained on production systems
• Documentation up to date
• Post-deployment monitoring plan ready

🔧 Build & Test Tools

Build System: Next.js 16+ uses Turbopack by default (no configuration needed)

• Turbopack is stable and enabled for both next dev and next build
• File system caching enabled by default for faster restarts
• Bundle analyzer available: @next/bundle-analyzer (works with Turbopack)

Test Runner: Vitest 2.0+ (using Vite for unit/integration tests)

• Vitest configuration in vitest.config.ts
• Using forks pool by default (more stable than threads)
• Browser mode available for component tests
• Coverage tracking with Istanbul or V8

TypeScript: Native TypeScript 5 support

• No compilation step needed for next.config.ts
• Strict mode enabled for maximum type safety

⚠️ Version-Specific Security & Breaking Changes

React 19.2 Critical Note

• Ensure React version is 19.2.3+ (CVE-2025-55182 fixed)
• If using Next.js, check Next.js version bundles safe React version
• Critical RCE vulnerability affected React 19.0.0 - 19.2.2 in RSC

Next.js 16 Breaking Changes

• Route params, cookies(), headers() are now async - must be awaited
• middleware.ts renamed to proxy.ts
• Default caching changed from implicit to explicit ("use cache" directive)
• AMP support removed
• Runtime config options removed

Tailwind CSS 4 Breaking Changes

• No support for CSS preprocessors (Sass, Less, Stylus)
• Requires Safari 16.4+, Chrome 111+, Firefox 128+ (no older browser support)
• Must use @import "tailwindcss" not @tailwind directives
• border utility no longer defaults to gray-200 (uses currentColor)

ESLint 9 Breaking Changes

• Flat config is the default (no .eslintrc.* support by default)
• Node.js < v18.18.0 not supported
• Must import plugins as JavaScript objects, not strings
• --quiet behavior changed (prevents rules from executing)

Zod 4 Breaking Changes

• Error customization unified under error parameter
• message, invalid_type_error, required_error parameters deprecated
• .nonempty() now behaves like .min(1) (type inference changed)
• Some enum properties removed (.Enum, .Values - use .enum instead)

🤖 Implementing This Checklist in AI-Powered Development Workflows

For Engineering Leaders

1. Make the Checklist Part of Your AI Context

• Add relevant sections to your team's AI prompt libraries
• Include in project kickoff templates shared with AI tools
• Reference specific checklist items when requesting code generation

2. Define "Definition of Done" for AI-Generated Code

• Junior AI-generated code: Requires full checklist review
• Senior-reviewed AI code: Can skip obvious items, focus on security/architecture
• Critical path features: 100% checklist coverage regardless of who/what generated it

3. Create Review Tiers

Tier 1 - Pre-commit (Developer): - Runs locally, catches obvious issues - Validates: Tests pass, types check, linter clean Tier 2 - Pre-PR (Developer): - Security & architecture review using checklist - Focus: Auth, RLS, validation, error handling Tier 3 - Pre-merge (Senior Dev/Lead): - Production readiness review - Focus: Performance, observability, edge cases Tier 4 - Pre-deploy (Tech Lead): - Final production gate - Focus: Deployment config, monitoring, rollback plan

4. Measure AI Code Quality Over Time Track metrics like:

• Production incidents per 1,000 lines of AI-generated code
• Time from AI generation to production-ready
• Checklist items most commonly missed by AI
• AI-generated code that passes checklist on first review vs. requiring rework

For Individual Developers

Using This Checklist with AI Tools:

Phase 1: Setup (Share Context)

When starting a new feature: "I'm building [feature] using Next.js 16 + Supabase. Here are our production requirements: [paste relevant checklist sections] Ensure all code you generate follows these standards."

Phase 2: Development (Validate As You Go)

After AI generates code: "Review the code you just generated against our security checklist: - Is RLS enabled? - Are queries parameterized? - Is input validated with Zod 4? - Are errors handled properly?"

Phase 3: Pre-Commit (Self-Review)

Before committing: "Act as a senior engineer reviewing this code for production. Check it against our checklist and identify any gaps in: 1. Security 2. Error handling 3. Performance 4. Testing"

Phase 4: PR Description

Include in PR: ✅ Checklist items verified: [list relevant items] ⚠️ Checklist exceptions: [if any, with justification] 🤖 AI-generated: [percentage, which parts]

For AI Tool Users (Cursor, Copilot, etc.)

Create a .cursorrules or CONVENTIONS.md file in your repo:

markdown

# Production Standards for AI-Generated Code When generating code for this project, ALWAYS: ## Security - Enable Row Level Security on all Supabase tables - Use Zod 4 for all input validation (unified `error` parameter) - Parameterize all database queries - Implement rate limiting on API routes ## Next.js 16 Specific - Use "use cache" directive explicitly (no implicit caching) - Use updateTag() for immediate cache updates - Use proxy.ts not middleware.ts - Await params, cookies(), and headers() (they're async) ## Architecture - Server components by default - Client components only when needed ('use client') - Multi-tenant: Include tenant_id in all relevant queries - Error boundaries around critical sections ## Testing - Vitest 2.0 for unit/integration tests - Test multi-tenant isolation - Test error cases, not just happy paths Refer to: /docs/production-checklist.md for complete requirements

Common AI Code Smells to Watch For

🚩 Missing RLS Policies

• AI generates database schemas but forgets RLS
• Manual check: view /supabase/policies.sql should have policies for every table

🚩 Incomplete Error Handling

• AI generates happy path, ignores errors
• Manual check: Every async call should have try-catch or .catch()

🚩 No Input Validation

• AI trusts user input
• Manual check: Every API route and Server Action should use Zod validation

🚩 N+1 Query Patterns

• AI generates simple queries without considering performance
• Manual check: Review any loops that make database calls

🚩 Missing Multi-tenant Isolation

• AI generates single-tenant patterns
• Manual check: Every query should filter by tenant_id/user_id

🚩 Outdated Patterns

• AI uses deprecated APIs or old Next.js patterns
• Manual check: Ensure using Next.js 16 patterns (async params, "use cache", etc.)

Success Metrics

Organizations successfully using AI + this checklist typically see:

• Velocity: 5-10x faster initial code generation
• Quality: 80%+ reduction in production incidents from AI code after 3 months
• Time to Production: 50% reduction in review/rework cycles
• Developer Satisfaction: High (AI handles boilerplate, humans focus on architecture)

Anti-Patterns to Avoid

❌ Blind Trust: "AI generated it, must be good" ❌ Paranoid Review: Reviewing AI code more strictly than human code ❌ Checklist Theater: Checking boxes without understanding why ❌ Static Checklist: Never updating based on production learnings ❌ Solo AI: Using AI without human review on production code

Getting Started

1. Week 1: Use checklist to audit one existing AI-generated feature
2. Week 2: Implement checklist in PR template for new AI code
3. Week 3: Add checklist items to your AI context/prompts
4. Week 4: Review checklist coverage and update based on findings
5. Ongoing: Add production incidents to checklist as they occur

📚 Additional Resources

• Next.js 16 Documentation
• Supabase RLS Best Practices
• Zod 4 Documentation
• React 19.2 Release Notes
• Tailwind CSS 4 Migration Guide
• ESLint 9 Flat Config Guide
• Vitest Documentation

🙏 Contributing

Found a production issue that should be on this checklist? Have a better practice for AI-generated code?

This checklist is a living document. As frameworks evolve and we learn from production incidents, it should evolve too. The goal is to help teams ship faster and safer with AI-powered development.

Remember: The best code review is the one that catches issues before users do.

This checklist is maintained by developers who have shipped AI-generated code to production and learned the hard way what matters. Use it, adapt it, and share what you learn.