The Manual Review Argument
The case for manual code review as an AI security control goes roughly like this: require developers to review the code they are about to send to an AI tool, strip any proprietary identifiers, and paste only sanitized code into prompts.
This approach has two things going for it. It requires zero tooling investment. And it theoretically works for disciplined developers.
In practice, it breaks down at team scale.
Where Manual Review Falls Short
Coverage
A developer reviewing 200 lines of code before pasting it into a Claude prompt is looking for obvious identifiers: the function named after the company's proprietary trading strategy, the class named after the internal product. They are skimming for the obvious cases, far from systematically scanning every variable name, every parameter name, every return type.
Studies of manual code review for sensitive data detection consistently find 40-60% false negative rates. Half of the proprietary identifiers that should be caught slip through.
With Pretense, full coverage comes by construction. Every identifier in the code block is evaluated. The human attention cost is zero.
Speed
Manual review of a code block for AI submission takes 2-5 minutes for a careful developer. Multiply that by the frequency of AI tool use (industry average: 15-20 AI prompts per developer per day for active Copilot/Claude users) and you get 30-100 minutes per developer per day spent on manual review.
That is the productivity cost the manual review approach imposes. It partially offsets the productivity gains that made AI coding tools worth adopting.
Pretense adds 2-8ms per request. The developer stays in flow.
Consistency
Manual review quality varies by developer, by time of day, by workload. A developer under deadline pressure at 4pm reviews prompts less carefully than the same developer on a focused morning. A senior developer with deep domain knowledge spots proprietary identifiers a junior developer would miss.
Pretense applies the same mutation algorithm to every prompt, regardless of who sent it or when.
Side-by-Side Comparison
| Factor | Manual Review | Pretense |
|---|---|---|
| Coverage rate | 40-60% | Every identifier in code blocks |
| Review time per prompt | 2-5 minutes | 2-8ms |
| Consistency | Variable (by developer, context) | Identical across all requests |
| Audit trail | Absent | Complete log per request |
| Scales with team growth | Linearly more expensive | Flat cost per seat |
| Enforceability | Policy only | Technical control |
| SOC2 evidence | Developer attestation | Machine-generated log |
The Enforceability Problem
Manual review is an advisory control, while Pretense is a technical control. You can write a policy that says developers must review code before submitting to AI tools. Enforcing it technically is a different matter.
A developer who forgets, rushes, or disagrees with the policy will skip the review. You will find out only after an incident.
Pretense is a technical control. It runs in the request path. Bypassing it requires changing the environment configuration, an action that generates an audit event.
What This Means for SOC2
SOC2 auditors evaluate the operating effectiveness of controls over a 12-month period. They ask for evidence that the control was applied consistently.
For manual review, the evidence is: a policy document, developer training records, and an attestation that developers followed the policy. Auditors know these are weak controls.
For Pretense, the evidence is: proxy logs showing every AI API call for the audit period, mutation records for each call, and statistics on secrets swapped for stand-ins. These are strong controls.
The difference matters for audit outcomes and for the enterprise sales cycle alike. When a CISO at a prospect company asks "what controls do you have over AI coding tool usage?", a machine-generated audit log is a materially better answer than "we train developers on the policy."
The Scaling Problem
Manual review costs scale linearly with team size and AI tool usage. Every new developer hired adds proportionally to the manual review burden. As developers use AI tools more frequently (the trend is upward), review time increases.
Pretense pricing is per seat. Operational cost stays flat as usage frequency grows.
A 10-person team doing 15 prompts per day each: 150 prompts, 5-12 hours of manual review per day across the team. Or $990/month for Pretense and zero manual review time.
At 50 developers: 750 prompts per day, 25-60 hours of manual review. Or $4,950/month.
The ROI calculation improves as the team grows.
Where Manual Review Still Has Value
Manual review still earns its place. There are cases where a developer should slow down and think carefully about what they are about to send to an AI tool: novel prompting strategies, unusual data structures, edge cases that automated scanning might miss.
The right model combines both: Pretense as the baseline technical control, with manual review reserved for the high-stakes cases where developer judgment adds value beyond what automation can provide.
How I run Pretense on my own code
I build Pretense with Claude Code, and my sessions run through it. Here is the setup I give a new engineer, in order.
- -Run the agent through the proxy. Type
pretense run claudewhere you would typeclaude. It starts a local proxy on port 9339, points Claude Code at it and stops the proxy when the session ends. Detected secrets and PII leave the laptop as stand-in tokens. - -Put hooks on every repo.
pretense installadds a pre-commit and a pre-push hook. A key that never lands in git is a key an agent never reads. - -Scan before an agent reads the repo.
pretense scan path .lists what it finds. In CI,pretense scan ciexits 0 when clean, 2 on findings and 3 when it examined nothing. Treat 3 as a failure. - -Preview the swap.
pretense review .shows what would be mutated.pretense mutate <file> --previewprints one file mutated and leaves the file on disk as it was. - -Round-trip a file you need to share.
pretense mutate <file> --map <map>swaps the secrets in place.pretense reverse <file> --map <map>turns it back into the original, byte for byte, from the encrypted map on your machine. We run that round trip on real files before every CLI release and compare sha256 hashes.
One thing I learned the hard way: inside a session the agent sees stand-ins, so a file the agent writes can hold a stand-in where you expected a real value. Grep what the agent wrote before you ship it.
What Pretense will not do is put a secret back into the model's answer. Code identifiers come back byte-exact. Secrets and PII stay as stand-ins in the response. That is deliberate: a prompt-injected model can echo a token into a link, and reversing it there would hand over the real key.
What this means if you buy security
The outcome: your engineers keep their AI coding tools, and detected secrets and PII leave each laptop as stand-in tokens.
- -The control sits on the endpoint. The swap runs on the developer's machine before the request leaves. No shared gateway holds every team's keys.
- -You get evidence, not a memo.
pretense audit --format csvexports every mutation event. Add--framework SOC2to keep only the events that map to that framework. - -Check it on your own code. Detection is pattern and entropy based, and coverage varies by data type. Run
pretense review .on a real repo and read what it catches before you sign off. - -Start with one team. One repo,
pretense run claude, one week. Then read the audit log with the team lead.
Try it on your own repo: create a free account, then run npm i -g @pretense/cli and pretense run claude. If you need a security review first, talk to me.