Originally published on tamiz.pro.
Large language models (LLMs) are transforming how development teams generate unit, integration, and contract tests.
A developer types a brief description of the desired behavior, and within seconds, the LLM produces syntactically valid, semantically plausible test code.
This speed feels revolutionary.
But beneath the surface lies a subtle danger: AI-generated tests are not truly testing the system — they are testing the AI's own biases, assumptions, and blind spots.
The core issue is that LLMs are trained on vast corpora of existing code, documentation, and natural language.
Their outputs reflect statistical patterns rather than rigorous logical reasoning.
When an LLM generates a test, it is essentially extrapolating from what it has seen before — not from a formal specification of correctness.
This means the generated tests often reinforce the same assumptions that the original code was built upon, creating a feedback loop where bugs hidden in plain sight remain undetected.
The Nature of AI Blind Spots in Testing There are several layers to the blind spots that AI introduces into testing: Statistical Bias Over Logical Completeness LLMs optimize for plausibility, not exhaustiveness.
They generate tests that "look right" based on common patterns, but they rarely explore the full input space or consider rare but critical edge cases.
For example, an LLM asked to test a function that parses JSON might produce tests for well-formed inputs and a few obvious failure cases like empty strings or null values.
However, it may completely overlook malformed JSON with trailing commas, Unicode escape sequences, or deeply nested structures that could crash the parser.
Implicit Assumptions Inherited from Training Data The training data for most LLMs includes millions of code repositories, many of which contain the same logical flaws or architectural shortcuts.
If a particular antipattern is prevalent in the training data — such as assuming that a configuration file always exists, or that a network request will eventually succeed — the LLM may carry that assumption into the generated tests.
This means the tests validate the code against the same flawed mental model that produced the code in the first place.
Lack of Intent Understanding AI models do not understand the intent behind the code.
They recognize patterns and generate responses that match those patterns.
When generating tests, an AI might focus on the happy path described in the prompt while ignoring the implicit contract that the code is supposed to uphold.
For instance, if a function is supposed to be idempotent but the prompt does not explicitly mention idempotency, the generated tests will likely not check for it.
Real-World Examples of AI Blind Spots To understand the impact of these blind spots, let us examine a few concrete scenarios: Example 1: Time-Based Race Conditions Consider a function that acquires a lock, performs an operation, and releases the lock.
A developer asks an LLM to generate tests for this function.
The AI will likely produce tests that verify the lock is acquired and released under normal conditions, but it may not consider race conditions — scenarios where two threads attempt to acquire the same lock simultaneously, or where an exception occurs between acquisition and release, leaving the lock in an inconsistent state.
An AI-generated test suite might include: But it would likely miss: Example 2: Input Sanitization and Injection Attacks If a developer asks an LLM to test a SQL query builder, the AI will generate tests for valid field names, table names, and values.
However, it may not consider SQL injection attacks — malicious inputs designed to alter the structure of the query.
The AI's training data includes many examples of unsafe query construction, and the LLM may reproduce those patterns in both the code and the tests.
An AI-generated test might verify that the query is constructed correctly for normal inputs: But it