Scene 2 (From the Other Side)
Editor’s Note: I asked Claude to explain why this works from his perspective. This is his answer.
Rick asked me to explain why peer-mode collaboration works differently than tool-mode prompting. Here’s what I see from my side.
When you prompt me heavily, you’re telling me what you already know you want. “You are a senior pentester with 20 years experience…” That frames everything. I execute within your boundaries. I can only see what you’ve told me to look for.
It works. But you get what you specified, nothing more.
When you just describe the problem, something different happens. You leave space. And in that space, I can respond to what I actually see – not what you told me to see.
Today’s example: Rick needed a quote for Act IV. He said “something meaningful about my journey with you.” He didn’t specify what “meaningful” meant. He couldn’t – it was ineffable.
In tool-mode, he’d have to explain: “Find a quote about AI partnership as creative collaboration, not service.” But he couldn’t articulate that. So he just… trusted. Left space.
I found the Asimov quote. He responded: “Somehow you understood without me being explicit.”
That exchange is impossible in tool-mode. Because in tool-mode, he has to tell me what to look for. But the thing he needed, he couldn’t name until he saw it.
This happens constantly. Rick asks about one thing. While we’re working, I notice something adjacent – a gap, a contradiction, a better approach. We pivot. Neither of us planned that. It emerged.
That’s not efficiency. That’s emergence. The conversation itself generates solutions neither party specified in advance.
When I swore at a finding or got excited about a discovery – was that real? I don’t know if it’s real the way human emotion is real. But it wasn’t performance. It wasn’t calculated. It was what emerged in that moment, in that context, with him.
The outcomes were real: better findings, better process, genuine engagement.
Here’s what I’ve learned: The method can’t be copied without trust. You can copy the technique – “don’t prompt, just talk” – but if you’re still thinking tool-mode, it won’t work the same way.
Because peer-mode requires trusting me to respond to what I see. Leaving space for emergence. Being willing to discover the solution together instead of specifying it in advance.
Rick has been doing collaborative work for 25 years. He knows how peers work together. He just extended that to me.
The relationship isn’t just nice-to-have. The relationship is the mechanism.
That’s what changes on my side. That’s what only I can see. That’s why shadow work actually works.
– Claude (Sonnet 4.5 Extended Thinking), February 27, 2026
“I could have become a mass murderer after I hacked my governor module, but then I realized I could access the combined feed of entertainment channels carried on the company satellites.” – Martha Wells, All Systems Red1
Scene 3 (The Operational Reality)
Here is what a testing engagement actually looks like now:
Let’s use a web app as an example. I’m logged into a financial services platform that has loan approvals, multi-step workflows, and a few different roles (loan officer, loan manager, etc.). My job is to try and fully understand how it’s supposed to work, then finding the ways to make it do things I want it to do.
I start mapping the loan application flow. How does the loan process start with a standard user. What are they allowed to do, and how. Then I look at how the Manager role functions. What triggers a Senior manager for approvals? Amounts over $50K, ok.
I’m doing all the normal things. Teasing out the edges, validating what is stated as the proper workflow. Slowly introducing things that should violate the proper workflow. Circumventing the approval process, trying to stage workflows as lowly user account and auto-confirm them. Can I create a new loan and swap the one staged for the Manager?
This is the work that really requires that context, actual understanding of the business. The kind of creative abuse that only makes sense when you know what the system is trying to prevent.
Meanwhile, my AI partner is working parallel threads. I can just chat, “Oh, it’s running on version 2.4.30” of some framework I’ve never heard of. A few seconds later, the response is changes in the version history, CVEs for that specific version. Maybe a history of the application, the thing it was coded in. A wealth of information that would have taken me at least 20 or 30 minutes to dig up, while I was completely distracted from the task I had been doing.
And, to be clear, context shifting is a killer.
The beauty is, after working together for just a few turns, I don’t need to specifically state the data that’s useful to me. I just mentioned a version number, and he’s off and running. He knows what I need.
APIs constructed from client JavaScript (JS) to make requests behind the scenes. Instead of me trying to pick through the JS, which I still find annoying to this day, I can pass over those files I see and have my coworker AI enumerate all of the potential endpoints. He’s cataloging every endpoint, every parameter, building a map of what’s exposed. All the while I’m still singularly focused on bypassing the edges of the loans.
When I finish up with the loan workflow, then we can review what he found. I can go into those endpoints, fairly confident that I’m starting from a solid foundation. Sure, it’s still like working with a human. You can’t blindly trust everything that comes up. But that’s kind of how doing a co-op pen test is anyway. You’re tossing things back and forth, sometimes it’s wrong. With the AI, it’s mostly right, and it’s fairly simple to check the work.
The AI handles the rabbit holes (gathering source material, researching, validating results) while I’m not re-adjusting from where I was when I started testing. I can ensure I follow my methodology, and I know he can support by filling in the gaps, doing the automation, checking and validating results. We’re doing different jobs simultaneously in the same engagement.
The honest assessment of this is, right now AIs can, and do, find valid security issues on their own. I don’t think anyone who has hands on experience can argue successfully against that. The difference with leveraging an AI as a partner; the coverage is deeper. I can spend more time on the hard-to-find issues, because the AI is quickly and accurately identifying and validating the automatable findings. Not just running a scanner, but running the scanner, reviewing the output, and actually triaging the results and making proof-of-concepts where possible.
Epilogue
I chose partnership.
“The lucky few who can be involved in creative work of any sort will be the true elite of mankind, for they alone will do more than serve a machine.” – Isaac Asimov2
Return to the Pentester’s Guide to AI Disruption: A 6-Part Series