Static analysis is dead.
Your CI runs PMD, SonarQube, or Clayton. You feel safe. Then a SOQL-in-a-loop ships — and Production hits 127 queries against a limit of 100.
The fundamental problem.
Static analysis tools scan your source code as text. They parse the AST, apply pattern-matching rules, and flag violations. Excellent for catching style and security issues — incomplete for runtime safety.
- Unused variables and dead code paths
- Security vulnerabilities like SOQL injection
- Naming convention violations
- Cyclomatic complexity thresholds
But static analysis cannotpredict runtime behavior because it doesn't execute your code. It doesn't know:
- How many records are in your production org
- What other triggers fire when you update a record
- How long your nested loops will actually take
- Whether your DML operations conflict with Setup objects
A concrete example.
// This code passes static analysis
// It crashes in production
public void processAccounts(List<Id> accountIds) {
for (Id accId : accountIds) {
// Static analysis: "SOQL in loop - potential issue"
// Runtime profiling: "127 queries executed, limit is 100"
List<Contact> contacts = [
SELECT Id, Name, Email
FROM Contact
WHERE AccountId = :accId
];
for (Contact c : contacts) {
c.Email = c.Email.toLowerCase();
}
update contacts;
}
}Static analysis says:"SOQL inside for loop — potential issue."
Runtime profiling says:"127 SOQL queries executed against a limit of 100. Transaction will fail in production."
Static vs runtime.
The solution.
Runtime profiling executes your code in an isolated environment with production-scale data. It measures what actually happens — SOQL, DML, CPU, heap — then blocks the PR when thresholds are breached.
Static analysis isn't dead — it's incomplete. Keep PMD, Clayton, and SonarQube for code quality. Add Jataka for Governor Limit safety. Use both.
Catch what static analysis misses.
Book a demo and watch Jataka block real runtime breaches before merge.