Roei Sherman can prove that AI made him more productive. He tracks his own work, including time to deliverables and how much he ships in a day, a week, a sprint. The numbers are not subtle. He's doing several times more, in less time, at the same or better quality.
So he came on Mitiga Mic to talk about the part the productivity numbers don't capture. What does all of that actually feel like? His written blog, AI Productivity Tools: The Adoption Journey So Far, lays out the arc. The conversation with host Brian Contos goes to the places a blog post might smooth over.
The productivity benchmark problem
The gains created a strange kind of pressure. "You're torn," Roei said. "I've done so much today. But then — am I doing enough? If I could do that much, maybe I can do much more." There's no ceiling to measure against, no moment where the tools tell you that you've arrived. He's watched people online run five Claude Code windows at once, more on their phone, still more while commuting, and caught himself wondering if he was only doing half of what he should.
His answer isn't a number. It's a direction: be better than yesterday. Block time to look at what worked, borrow what helps from what other people are doing, ignore the rest. Not everything transfers. Some things compound.
"Perfect" was never the bar
The two failure modes he worries about most sit at opposite ends.
One is blind trust. You asked for X, it produces something that looks like X, and you ship it without checking.
The other is the refusal to use the tools at all because they aren't perfect. With both, you're missing the point.
"Nothing is perfect, and no one is," Sherman says. AI is a tool, like the internet or the computer before it. The person who gets the most out of it is the one who already knows the domain well enough to tell good work from plausible work, which is why the expert still verifies.
He reframes the whole thing as managing a team. AI gives him something close to an endless bench of capable helpers. And like any team, they make mistakes, usually because he handed off a vague assignment without telling them what "done" looks like. Give them the goal, the deliverable, and the test for success up front, and they can check their own work before it reaches him.
These AI usage habits made it click
Two practices came up as the difference between frustration and results.
The first is defining success inside the prompt. Not the old "you are a very experienced engineer" opening — Sherman has dropped that entirely — but a plain statement of the goal, the deliverable, and the steps the work has to pass before it's trustworthy. When he asks for research, citations are mandatory. Anything the model can't verify against a third party doesn't make it into the output.
The second he calls "interview mode." Before starting a project or brainstorm, Sherman tells the model to interview him with a default of 20 to 25 questions. The questions pull out all the context he carries in his head and would never think to type into a prompt. By the time the interview's done, the goal and the success criteria are already framed.
When software takes an afternoon
The clearest evidence of the shift was how fast Roei can now turn an idea into a working tool.
He described building GhostType, a small security utility, in a single sitting. It's meant to run on a machine, find where your local AI tools store conversation history, and then it scans those files for credentials that shouldn't be sitting there. It came from a real moment of asking Claude to dig up something from an old conversation, realizing every conversation was saved locally, and wondering how many people had pasted API keys into a chat. He opened a new Claude Code session, described the concept and who'd use it, and let it run. A couple of hours later he had a working version. He posted about it, and within a few hours someone had adapted it for use with Cobalt Strike. Both of them used the same class of tools to do it.
Then there's the app his team basically lives in. Mitiga's research team submits talks to conferences constantly, and everyone used to track their own submissions their own way. Some used the conference portal, some moved to Excel, and yet some more managed the task in Google Sheets. Sherman sat down with Claude Code and, before writing a line, talked through the problem like this. Bring every submission into one place, give each researcher their own tracking, and give team leads a view across the whole team. Then he kept adding more: an LLM that reviews each abstract against the conference and talk length, a seed list of roughly 150 conferences with their CFP windows, Slack notifications when a CFP opens or a deadline approaches, SSO behind all of it, and a full code and security review before it went live. Five to six hours later it was online. His team uses it every day. And Ofer Maor, the CTO, uses it, too.
What made that possible wasn't only that he didn't have to write the code. It's that the thing he built didn't have to be a product. "We would have paid for something like that back in the day," he said. Because it's internal, built to his team's exact requirements, he's comfortable with small rough edges and spends far less time polishing.
Getting a team on board
Sherman leads researchers who are technical by nature, so curiosity wasn't the hard part. Some adopted AI as fast as they could reach it. Others were more cautious.
What moved the cautious ones was exposure and show-and-tell. The team has access to essentially every model and a budget to experiment, and Sherman's standing instruction is to try things and find what works. When someone automates a task or builds a skill, they share how and why. Watching a teammate pull it off is what turns "maybe I could do that" into doing it.
He noticed a pattern in who adopted fast. The quick adopters tended to be juggling many things at once — lots of research threads, lots of tasks, a strong pull to clear the plate. The slower adopters tended to go deep on a small number of problems and couldn't yet see how AI got them there, and they worried more about mistakes. The thing that closed the gap in both cases was hands-on experience: use it, see where it breaks, learn to catch those breaks before they happen, and the confidence to take on parallel work follows.
Takeaways for security leaders
Brian asked the question the audience was waiting for: past buying tools, how should a security leader think about all this?
Roei's answer starts from reality. AI is already adopted, governed or not. People who want to get something done will route around security if they have to. So the wrong instinct is to fixate on "AI writes vulnerable code, now we'll ship more of it." Human developers write vulnerable code too — that's why vulnerabilities exist.
The right move is to govern the tools people actually use, the same way you already govern email. You don't send around a verbal list of do's and don'ts for auto-forwarding rules; you set a policy and enforce it in the tool. AI needs the same treatment. When anyone can spin up a solution, you have to account for a well-meaning employee telling their AI assistant to deploy a dashboard "so I can share it with a client" and quietly standing something up outside the organization. They're not being malicious. They just don't know.
He pointed at the credential problem his own tool addresses: engineers hand API keys to an assistant to get a job done, and the key lingers in the conversation history. It's the modern version of pulling passwords out of a Linux .bash_history file — the keys to the kingdom, sitting where they shouldn't.
The close was the part Brian has made his own over the years: the security function that only says no doesn't last. "The job isn't saying what you can and can't do," Roei said. "It's saying how you can do the thing you want to do" — safely, with the right safeguards, and with technology in place to detect and respond when something slips. Figure out what you're protecting first. Then let people work.
