Interviews
Natasha Mohanty, SVP of Engineering at Doppel – Interview Series

Natasha Mohanty, Senior Vice President of Engineering at Doppel, is a seasoned technology leader with deep experience across AI, payments, media, and consumer platforms. Before joining Doppel, she led engineering for Stripe’s Optimized Checkout Suite and Link, scaling the organization from 30 to 200 engineers while helping drive major adoption across Stripe’s checkout products and consumer wallet. Previously, she served as VP of Engineering at Nielsen after its acquisition of Prizma.ai, the AI-powered video engagement and media analytics company she co-founded and led as CTO. Earlier in her career, she spent more than seven years at Google, working across Search Quality, Google News, and Google+ personalization.
Doppel is an AI-native social engineering defense company focused on protecting organizations, executives, brands, and customers from AI-powered impersonation, phishing, fraud, and broader digital risk. Its platform combines digital risk protection, executive and brand protection, email security, human risk management, simulations, and security awareness training, using AI and real-time threat intelligence to detect, correlate, and disrupt attacker infrastructure across channels such as domains, social media, messaging apps, ads, and the dark web. The company has positioned itself around the rising threat of generative AI-enabled social engineering, helping security teams respond to increasingly sophisticated attacks across the modern digital threat landscape.
You’ve led engineering organizations at companies including Stripe, Google, Nielsen, and now Doppel. Across that journey, how has your view of the software engineer’s role evolved from writing systems directly to orchestrating increasingly autonomous AI-driven workflows?
The software engineer workflow has changed dramatically, but the accountability required of engineers hasn’t. When I started my career at Google two decades ago, engineers spent most of their time writing and reviewing code themselves. Today, AI can handle the majority of code generation, but engineers are still responsible for defining goals, validating outputs, establishing guardrails, reviewing code, and ensuring systems remain reliable over the long term. In many ways, AI has expanded the scope of engineering responsibility rather than reduced it.
What’s evolved is where engineers create value. As AI takes on more of the mechanics of coding, the role becomes increasingly centered on taste and judgment, understanding the problem, making architectural decisions, evaluating tradeoffs, and ensuring outcomes align with user and business needs. The best engineers do more than just write software. They’ll orchestrate cohesive systems of humans and AI, applying the context and accountability that machines still lack. It’s similar to the shift from individual contributor to manager.
You’ve argued that AI doesn’t reduce engineering responsibility, it expands it. What are the biggest misconceptions executives still have about what AI coding agents can realistically handle without human oversight?
The biggest misconception is that AI is going to eliminate the need for strong engineers. The reality is AI raises the ceiling on what a small, skilled team can build, which makes engineering judgment more valuable, not less.
What’s changing is the surface area engineers are responsible for. They are not just writing code anymore. They are defining what gets built, validating that agents are doing what they intended, and owning the outcome when they do not.
If anything, the problem space has gotten more compelling. Attackers have access to the same AI tools we do, which means the challenge of staying ahead of them is genuinely harder, and more interesting, than it has ever been. There is no shortage of hard problems to solve, and Doppel is hiring across engineering for people who are excited by this kind of work.
As engineering teams begin coordinating multiple AI agents across coding, testing, debugging, and documentation, what does an effective “agent management” workflow actually look like in practice?
Engineers are increasingly acting as managers of autonomous systems, not just contributors to them. The best engineers can hold significant context across multiple parallel workflows while knowing exactly what context to share with each agent. In practice, that means writing well-defined acceptance criteria, setting clear guardrails for privacy and security, and asking agents to explain their reasoning and assumptions as a validation step. If an agent cannot articulate what it is doing and why, you cannot fully trust the output.
At Doppel, we’re building agentic systems that investigate threats, continuously adapt detection policies, and explain their decisions in plain language. Effective agent management also requires system-level infrastructure, including staging environments, automated testing pipelines, security tooling with defined permissions and oversight, and evaluation frameworks that continuously assess whether agents and the broader system are operating as expected.
What are the biggest operational or security risks that emerge when AI agents are given access to internal tools, production systems, or sensitive workflows without strong guardrails?
The risk is not just that AI agents make mistakes. It is that they can make them at a scale that is hard to catch in real time. The more specific danger is agents acting outside their intended scope, whether that means accessing systems they were not designed to touch or handle data they should not retain.
In our email security product, for example, agents process data that is inherently sensitive. We have gone to significant lengths to ensure those agents have strictly restricted access, cannot accidentally expose sensitive personal information downstream, and do not retain confidential information, while still having the context needed to make the right decision.
At what point does relying heavily on AI-generated code start introducing long-term technical debt, and how should engineering leaders think about balancing velocity versus maintainability?
The risk is prioritizing short-term velocity over the foundations that allow systems to scale and evolve. One of the biggest lessons from my time at Stripe was that not all decisions are equal. Some are trapdoors: hard to reverse and likely to have long-term consequences, while others can be changed more easily.
With AI, the discipline is knowing which decisions still carry long-term consequences, putting stronger guardrails around those, and moving quickly on the rest. At Doppel, that means using evaluation systems and current documentation to ensure agents continue operating as intended as systems evolve. The goal is not to slow down, but to make sure speed does not quietly erode the foundations you are building on.
During your time scaling engineering organizations at Stripe, what lessons about reliability, trust, and systems design now feel especially relevant in the era of autonomous AI agents?
At Stripe, reliability was everything, especially because the financial industry is so regulated and it could be catastrophic for businesses if their payment portals went down. If a system didn’t work as intended, there was a direct impact on customers, and that created a strong culture of ownership and accountability at the company.
One of the things that drew me to Doppel was a similar level of customer obsession. The teams here are deeply focused on understanding the challenges customers face and taking ownership of solving them.
Now that I’m at Doppel, those lessons feel especially relevant. We’re building AI-native systems to help organizations defend against increasingly sophisticated social engineering attacks. And similar to Stripe, where you cannot afford to have payment processing systems go down, it’s catastrophic for businesses to not have a strong cybersecurity posture. They are both very high stakes, but for different reasons.
How do you expect engineering hiring to change over the next few years as companies increasingly prioritize AI fluency, systems thinking, and adaptability over narrower technical specialization?
I think we’ll see a growing emphasis on hiring engineers who can operate with autonomy, strong judgment, and the ability to learn fast. Those are traits I’ve always hired for, but they matter more now, not less. Throughout my career, the engineers who have had the biggest impact weren’t necessarily the ones with the narrowest specialization. They were the ones who could adapt quickly, navigate ambiguity, and continuously learn as technology evolved.
But the bar has shifted. At Doppel, the problems we’re solving are not neatly defined. We are constantly working to stay ahead of attackers who are also leveraging AI, which means building systems like threat intelligence agents that proactively explore the web to discover threats. There is no established playbook for that kind of work, so it takes grit and a willingness to push the boundary of what’s possible.
AI will only continue to change how work gets done, but companies will still need people who can work across systems and take responsibility for the full lifecycle of what they build. The engineers who thrive will be the ones who are constantly reinventing what they are capable of as the AI landscape evolves around them.
You’ve worked extensively on personalization, recommendation systems, and machine learning-powered platforms throughout your career. How does that experience shape the way you think about human-AI collaboration inside engineering organizations today?
One thing I learned from working on personalization and machine learning systems is that the quality of the output is only as good as the quality of the inputs, including training data, evaluation frameworks, and a clear definition of what “good” actually looks like. Models are great at processing information at scale, but people bring judgment, context, and an understanding of what matters most.
I think the same principle applies to engineering organizations operating today. AI can help teams move faster, but the best teams will be deliberate about the context and ground truth they give AI, as well as how AI-driven systems integrate into the broader engineering ecosystem. Engineers still need to make decisions, evaluate tradeoffs, and ultimately own the outcome.
Many companies are racing to maximize developer productivity with AI tools. Do you think the competitive advantage will ultimately come from faster coding, or from building organizations that know how to govern and coordinate AI systems effectively?
Speed matters, especially in cybersecurity, where falling behind attackers is not an option. But speed without guardrails is just a faster way to create exploitable gaps. Governance of AI systems should be the baseline for every company building with AI, not an afterthought. It’s essential to ensure quality, reliability, and accountability in software engineering workflows. In the cybersecurity industry in particular, governance is essential because attackers will find and exploit any gap you leave. That is why we’ve built out our agent platform at Doppel, we have led with privacy guardrails and a clear audit trail built in from the start.
Looking ahead five years, what do you think the modern software engineering team will look like once AI agents become deeply embedded into everyday development workflows?
Five years is difficult to predict with confidence because the world is moving so quickly. What I can say with more confidence is that within the next 18 months to three years, AI agents will likely handle the bulk of code generation, testing, and first-pass debugging.
What engineers will own is product judgment: the spec, the taste, the architecture, and the accountability when something breaks. Teams may get smaller, but the role will get harder. The engineers who thrive will not necessarily be the ones who produce the most code, but the ones who can direct, evaluate, and course-correct autonomous systems effectively.
Having worked through previous technology shifts, one thing I’ve learned is that innovation rarely follows a straight line. The teams that succeed will be the ones that stay curious, adapt quickly, and evolve their workflows as the technology changes.
Thank you for the great interview, readers who wish to learn more should visit Doppel.












