Language models are now part of most people’s workflow. The useful question is no longer whether to use them, but which parts of an engagement they improve and which parts they degrade. Having used them across roughly two years of assessment work, here is where I’ve landed.
Where they genuinely help
1. Tool output that nobody wants to read.
Parsing a 400 MB nmap XML export, correlating Nuclei findings against a scope list, or reshaping Zeek logs into something a client can read — this is where the time savings are real and immediate. The model is doing transformation, not reasoning, and transformation is what it’s best at.
# Ask for a script that turns findings into a deduplicated table
# Result: ~20 lines, correct on first run, done in a minute
2. Boilerplate for unfamiliar APIs.
Writing a client for an API you’ve never touched is exactly the kind of task where a model saves an hour of documentation reading. It will get the shape right, and you correct the details. This is faster than reading the docs cold.
3. Report drafting.
Turning raw notes into structured prose is the single highest-value use I’ve found. The model does not need to understand the vulnerability to write it up clearly; it needs your notes about the vulnerability.
A workflow that works well: keep notes in a consistent format during testing, then ask for a draft per section. You edit for technical accuracy. The mechanical writing disappears.
4. Rubber duck for hypotheses.
Explaining what you just observed and asking what else would produce that result occasionally surfaces a possibility you’d ruled out too early. Not reliable, but the cost of trying is near zero.
Where they actively hurt
1. Anything requiring current facts.
Training cutoffs and confident hallucination make models unreliable for “is this CVE exploitable” or “what is the current patch level”. I have had a model produce a plausible, entirely fictional advisory identifier. Checking every factual claim costs more than looking it up yourself.
2. Novel exploit logic.
Models are good at recombining known patterns. Real vulnerability research is mostly the part that isn’t a known pattern. Asking for the exploit for a bug you’ve just found, in a codebase the model has never seen, produces confident nonsense.
3. Interpreting ambiguous evidence.
A log line that could mean three things is exactly the situation where you need someone who understands the system. A model will pick one interpretation and present it without the hedging it deserves.
4. Anything that touches client data.
This is the one that ends engagements if you get it wrong. Pasting client source code, credentials, or internal hostnames into a hosted model is a data disclosure, full stop. Where a client’s contract permits AI assistance at all, it permits it on a local or explicitly approved deployment.
The workflow that has held up
The pattern that works is using the model as a transform and draft layer, never as the reasoning layer:
| Task | Model does | I do |
|---|---|---|
| Recon triage | Normalise, dedupe, group | Decide what’s in scope |
| Tooling | Write the boilerplate | Verify against the real API |
| Exploitation | Nothing | Everything |
| Reporting | Draft from my notes | Verify every technical claim |
| Fact-checking | Nothing | Look it up |
The critical property is that every model output is treated as a draft from a fast, confident, occasionally wrong junior. That framing has kept me out of trouble.
The thing worth being honest about
The productivity gain is real but narrower than the marketing suggests. The tasks that improved are the ones that were already mechanical — parsing, boilerplate, and prose. The tasks that define the job, which are deciding what to test, understanding what you found, and knowing what it means for the client, are unchanged.
What has changed is that the mechanical work no longer consumes the time it used to. Whether that translates into better assessments depends entirely on what you do with the reclaimed hours. Doing the same work faster is the least interesting outcome; doing more thorough testing with the same budget is the one worth aiming for.
And there is a real risk on the other side. A model that produces plausible output will produce plausible findings if you let it — a vulnerability report with a well-written, incorrect finding is worse than no finding at all. The verification burden sits entirely with you, and it does not get smaller because the draft arrived quickly.