Functional testing asks: does it work? Load testing asks: does it work under pressure?
AI-generated code has a specific pattern of performance issues. CodeRabbit found excessive I/O operations were approximately 8x more common in AI-authored PRs. The code works fine with 10 users. It collapses with 1,000.
This creates a dangerous blind spot. Functional tests pass. The feature ships. Traffic scales. The database query that took 50ms with 100 rows now takes 5 seconds with 100,000 rows. The API endpoint that handled 10 concurrent requests times out at 100.
Why AI Code Performs Differently at Scale
AI coding tools optimize for correctness on small inputs, not for efficiency at scale. Common patterns:
N+1 queries: the AI fetches related data in a loop instead of a join
Unbounded queries: no pagination or limit on database results
Synchronous processing: operations that should be queued run inline
Memory accumulation: large datasets loaded into memory instead of streamed
These patterns work in development and fail in production. Functional tests don't catch them because they test with small, fast datasets.
The Testing Combination That Works
TestSprite's functional testing catches behavioral bugs: incorrect logic, security vulnerabilities, auth failures, and edge cases. It runs on every PR in under five minutes.
For load testing, dedicated tools like k6, Artillery, or Locust simulate concurrent users and measure response times under stress. These should run periodically (not on every PR) against staging environments.
The combination: TestSprite for every-PR functional verification, plus periodic load testing for performance validation. Together, they cover both "does it work" and "does it work at scale."