An engineering team adopts agentic coding and can suddenly generate thousands of lines of code. The pull requests get bigger, and there are far more of them. The same people are still reviewing every one.
Writing code got faster. Nothing after it did.
Sunita Verma, CTO of Ironclad, has watched that happen at companies that changed how they write code without changing how they review it. "It's still human beings reviewing the code, they are just overwhelmed at this point," she says. That's where AI developer productivity stalls. Speeding up one step just moves the bottleneck to the next.
Sunita has spent nearly two decades building AI, including at Google and Character AI, and now leads AI strategy at Ironclad, the legal tech company whose platform X-Team also uses. Her fix starts well before the first line of code gets generated.
AI Developer Productivity Depends on How Work Gets Handed Off
Sunita separates two ways of working with AI. In the first, an engineer brainstorms with a model and then delegates the task, which means "the engineer is outta the loop." Their attention goes to other work. In the second, the engineer stays in a constant back-and-forth with the tool.
Different tasks call for different modes. Trouble starts when a team uses the back-and-forth mode for writing code, because then "you basically created additional work for your engineering team." An engineer who never leaves the loop hasn't gained any time.
Delegation only works when the handoff is complete. Sunita's standard is a detailed specification written up front, covering the guardrails and "what the AI should not do." Behavior set by an underspecified first prompt, she says, is hard to correct later.
Plan the Whole Pipeline Before You Speed Up One Step
"Don't just think about the coding side," Sunita says. Her advice to leaders bringing AI into software development is to plan every stage from the beginning, including code reviews, merges, deployments and production readiness. If you speed up the first stage without touching the ones after it, the extra volume lands on whoever is next in line.
Ask what each downstream stage will receive once output climbs, then redesign that stage before turning up the volume. A review process sized for human-paced output will buckle when agents start producing code.
That makes review capacity the constraint worth planning around. Judging AI-generated code quickly takes engineers who already know the codebase well. That context takes time to build, and it walks out the door every time an engineer rotates off the team.
Make the Gains Spread Past Your Early Adopters
Even a well-planned pipeline underdelivers if only a handful of engineers know how to get the most out of it. Ironclad paired its most AI-forward engineers with teammates further behind the curve. Sunita says seeing how a colleague works with AI is what helps other engineers pick it up.
Ironclad also built a marketplace of skills that comes bundled into every development environment. As a result, "every developer basically gets the same set of skills" from day one.
For where to begin, Sunita points to "a small, well-defined problem," with scaling coming once something works. Pairing habits and shared environments keep those gains on the team after early adopters move on.
Writing code got faster. The measure that matters is how fast work reaches production, and that's where AI developer productivity gets won or lost. The teams that come out ahead will be the ones whose reviewers, pipelines and habits were ready for the volume AI creates. The review queue clears when someone plans for what happens after the commit.
Transcript
Sunita Verma:
The technology can feel really easy on a very surface level basis because natural language interface sort of gives people the confidence that they know the technology. But the behavior of the technology, the underlying behavior of the technology can be very unexpected for a lot of people. And that's why educating your teams is an important part, both for them to get comfortable with the technology, but also for everyone to develop a common language that they can use to sort of, you know, align around the technology.
Gemma Versace:
Hey everyone, and welcome to Keep Moving Forward, the podcast from X-Team for tech professionals who are passionate about growth, leadership, and innovation.
I'm your host, Gemma Versace, Chief Client Officer at X-Team.
AI adoption has moved well past the experimentation phase. It's showing up in daily workflows and decision loops now, including in regulated industries like legal, where the margin for error is thin and the expectations are high. The hard part isn't building the technology anymore. It's building it responsibly, at scale, and in a way that holds up under real business pressure.
Today I'm joined by Sunita Verma, Chief Technology Officer at Ironclad. Sunita has spent nearly two decades building AI, before it was even called that. She's moved through the eras of machine learning, deep learning, and now generative AI. Her path runs through Google Core and Core Labs, then Character AI, before landing at Ironclad, where she leads AI strategy in one of the most regulated corners of enterprise software. Full disclosure: X-Team is a happy Ironclad customer ourselves, so this conversation carries a little extra weight for us.
In this conversation, Sunita walks through what she learned building responsible AI systems at Google, and why she believes AI burnout has less to do with the technology and more to do with how teams deploy it. We talk about the false choice between top-down mandates and bottom-up experimentation. We get into why delegating a task to AI is fundamentally different from using it as an always-on assistant, and why the guardrails that matter most get built into the first specification, not bolted on later.
Sunita also shares how Ironclad governs its own agentic rollout, what she's learned from pairing AI-forward engineers with the rest of the team, and how distributed organizations can build a shared vocabulary around AI instead of a fragmented one.
Welcome, Sunita. We are absolutely thrilled to have you as a podcast guest today.
Sunita Verma:
Very excited to be here. Excited to talk to you, Gemma, and really love the direction you take with your podcast.
Gemma Versace:
Oh, thank you. That's absolutely wonderful feedback to hear. We'll get straight into it. You've spent nearly two decades building AI at Google Core Labs, then at Character AI, and now as CTO of Ironclad. Walk us through that arc and really what it taught you about deploying AI responsibly.
Sunita Verma:
One of the things I tell people is I've been working in AI before it was called AI, so I have seen different arcs of the technology, starting from machine learning to deep learning to generative and the AI era that we are in now. And having built the technology, or having worked in the technology for so many years, has given me a very unique perspective on how to deploy it responsibly, how to deploy it for solving problems.
And one of the examples I wanna give is a product that I had built when I was at Google, and it was basically about automatically generating text ads. I was in running Google's ads business at that time, automatically generating text ads using AI. But one of the things we were very, very cognizant of, and we built systems around, is making sure that the generated content is responsible, aligns to the policy guidelines, make sure that, you know, align both policy guidelines of the company, but also policy guidelines of the customers that we were doing it on behalf.
So I think just how to do things, something like this at scale with responsibility built from the beginning, is something I learned at Google and is what we are applying at Ironclad. And legal space, which we are in right now, actually is even more sort of, it's regulated. It's also more constrained in the space you have to be, right? So this is something that we built into our product right from the beginning.
Gemma Versace:
Yeah. Thank you for sharing that. I was going to mention that, you know, the financial services as industry, but also very much the legal industry with AI, the heavily regulated environment would mean that there's just a lot more stricter requirements and expectations in those industries.
So I can imagine that there would be lots for you and your teams to be mindful of. Of course. You've argued that AI burnout isn't caused by the technology, but it's caused by how teams deploy it. What's the mistake that you have seen most, and how can companies and leaders that are listening today, how can they learn to avoid it?
Sunita Verma:
Yeah. So, few things. One, I think rather than trying to sort of spray the technology across each and every part of your problem space and/or business area, I would suggest starting with a small, well defined problem. Second thing I would say is I think education of your workforce is a very important criteria while rolling out this technology.
And what I mean by that is the technology can feel really easy on a very surface level basis because natural language interface sort of gives people the confidence that they know the technology. But the behavior of the technology, the underlying behavior of the technology can be very unexpected for a lot of people. And that's why educating your teams is an important part, both for them to get comfortable with the technology, but also for everyone to develop a common language that they can use to sort of, you know, align around the technology.
And third thing I would say, one of the third mistake that I see people making, is they're using AI as a drop-in replacement in their existing processes, and that is where you will not get the best ROI from the technology. You really have to rethink how you do certain parts of the work as well, and that's when you start seeing the bigger gains from AI. So I think these three things are probably the most important things to focus on as you're starting to deploy AI in your environment.
Gemma Versace:
Thank you so much, some really great insight and recommendations for our listeners today. If you don't mind me asking, it is a little bit of a pivot question, but at the businesses that you have led, have you taken an approach of, let your engineers play with AI and then kind of identify AI platforms or systems that they're wanting to incorporate within the business, or have you taken more of a kind of top-down mandated approach?
What do you believe is the best way to be able to get the appropriate buy-in across the teams? But how do you also motivate your teams around really engaging with and taking on the business strategic direction around incorporating AI into your everyday work.
Sunita Verma:
Yeah, so I think it has to be both, and this is what I have practiced all throughout my career, whether it is AI or any other technology, in the following sense. Senior people at the senior level, one, they need to themselves be very familiar with the technology, and this is a very different era compared to previous eras of technology where, you know, executives themselves could be high level and still sort of give right guidance, or enough guidance, to their teams. They really need to have deep understanding of this technology, and given that they have the broader picture in their heads, like because of obviously all the access and observation, they tend to have.
Their perspective is important, but I think I also very strongly believe that getting your engineering teams leaned in, enabling their creativity, is an equally important part, especially at a time when things are changing so quickly, it's very hard to keep pace for any single person.
So one of the things we did at Ironclad specifically is we actually had a group of engineers, starting maybe around nine months back, who were basically tasked with, hey, you evaluate different pieces of technology that we need to bring in as part of our development processes. So we basically said three things. We said AI in the product, AI in how we build the product, AI as part of our operations.
So, AI in how we build the product, we basically had a group of engineers who evaluated different parts of the technologies at that time and suggested a way to roll it out to the rest of the engineering and development team, basically. And then there is a continuous process of continuing to reevaluate, because think about it, one day it is Claude Code, the other day it is Codex, the other day it is someone else, kind of thing. So things are changing really fast. So just TLDR, it has to be both sides engaged in the process.
Gemma Versace:
Perfect. I love that answer. Yeah. It's very important to be able to have both in play, really, across your businesses. You draw a sharp line between using AI to replace tasks, like writing or coding, and using it as an always-on assistant. What does that distinction actually look like day to day?
Sunita Verma:
So the way to think about, or the way we have at least thought about in our environment, is AI, and it relates to the previous question that we were talking about, like how to use AI effectively and maybe not get burnt out. If you deploy AI in a way, which is where systems come in, where you have to constantly be interacting, if you're doing basically more of a synchronous, bidirectional interaction with the technology. That makes it, that sort of creates, and if you use the same interaction model for writing code, you basically created additional work for your engineering team.
The way we work, we have started working on, on the engineering team side, is there is an initial brainstorming that is done with AI, but after that there is delegation to AI, which means the engineer is outta the loop. They can basically take their cognitive bandwidth at that time and focus it on something else. While in an assistant world, there is a constant interaction, that's more of a back-and-forth approach. So that back-and-forth approach, again, depending on the task that you are working on, a different approach might be needed versus, you know, using the same mode of interaction across different parts of the task.
And that's what I meant when I said, you know, think about all these interaction modes differently.
Gemma Versace:
Yeah, thank you. You believe that the guardrails, things like observability, escalation thresholds, delegation boundaries, should be engineered into the system, not applied through manual review. How do you build that into Ironclad's agent architecture, processes, or even, you know, work culture?
Sunita Verma:
Yeah, Gemma, one part, again, going back to why this technology is different, is through the natural language interaction that we have with the technology, we are able to steer the behavior of the models. And one of the challenges, this is not a challenge at Ironclad, I'm saying broadly that I see, and there is a lot of academic literature that is being built around this as well, is under-specification of the steering commands or prompts to the model.
And one of the things we do is, and I would encourage people to think about, is building a very detailed specification when interacting with these models. So that specification needs to include the observability, the guardrails of what the AI should do and, equally important, what the AI should not do. And all that needs to go in while you are actually building the first specification, interaction specification, or you can call it prompt, basically, with the model.
And when you do that, you have already sort of established a behavior with the model, or you established basically an instruction behavior with the model, which becomes really hard to influence later on by trying to do it manually. So I think the thing to think about it is, how can our specification that we are giving to the model, right in the beginning, is as detailed and comprehensive as possible.
Gemma Versace:
Yeah, really good advice that you kind of need to start as you mean to finish when building that and rolling it out across your teams in your business. Since joining Ironclad, you've driven a major expansion of agentic capabilities, so intake, redlining, conversational search, and now the Ironclad Assistant. What did AI done right look like in practice as you built that out?
Sunita Verma:
Yeah. First of all, I'm very proud of our team that came along on this journey, or that sort of, you know, invested in this journey alongside me. And as I said earlier on, one of the things we were very clear when building AI into our product is it has to be integrated. It won't be a bolt-on, it'll be an integral part of our product.
And what I mean by that is, we didn't want people to have to go to a different interface to access an assistant, or we didn't want customers to figure out what agent they need to call when they are in a specific part of their contracting workflow. So all these design principles, AI has to support the customer. AI has to be integrated. AI has to be easy to use. AI has to have all the guardrails that are needed.
And last but not the least, especially when we are thinking about agent capabilities, one of the things we also said is we built actually a very risk-based framework, similar to how you have an autonomous driving of human in the loop.
So more complex, more risky workflows, there'll be a human in the loop, but more standard, more less risky workflows, there could be an autonomous execution of those things, like standard NDAs and so on. So setting those principles at the outset helped our teams actually, you know, align to those principles.
But everybody knew what's the framework within which they are working, and hence we are able to actually move much faster.
Gemma Versace:
Yeah. Amazing. We at X-Team are a very happy user of Ironclad, and we are very grateful for all of the wonderful work that you and your team do, because even people like myself can easily navigate, and very UI-friendly as well as user-friendly for those of us that aren't necessarily super savvy.
So yeah, a very happy user here. You've laid out concrete tactics, one tool at a time, and things like piloting with small groups or tool-free work blocks, they're aimed at protecting teams from AI overload. How should distributed engineering teams apply that? What advice do you have those leaders listening that have quite distributed teams?
Sunita Verma:
There is, maybe, a different part of challenge that distributed teams tend to have. And by the way, we do have quite a distributed team ourselves. So, which is basically building team cohesion, building team camaraderie, and having a common view that everybody shares. And it goes back to what I said just a moment back, which is, one, defining a framework. Framework of what problem are we solving for? How are we going to solve it? What are the guardrails we are going to put in place? Starting with that framework, and making sure everyone that is distributed, everyone has an understanding of that framework. Second, align, building a common language across the team, and by building that language can happen through education.
One of the things we did was, we last year, in the November, December timeframe, we actually ran a 20-day AI program for all our team across all different locations. And my goal was specifically to build a very common language, vocabulary, across everyone on the team. So when people are talking about evals, people are talking about data sets, everybody knows what is being talked about. And we saw huge, basically, gains out of that.
At the other side of it, we've done a hackathon right after that 20-day AI program. And we got like amazing sort of prototypes built by the teams, many of which have already been translated into product value. So building a common vocabulary, building a common framework, starting with a small problem and then scaling it out to the whole team, especially when you have a distributed team, is going to be hugely valuable.
Gemma Versace:
That's some really great advice for how people can go about kind of bringing together what that strategy would look like for their distributed teams. So thanks for sharing that, Sunita. What can a distributed, engineering-heavy organization learn from, you know, how an enterprise SaaS platform like Ironclad, how you govern AI adoption? What are some, you know, recommendations or ideas that you would share with leaders listening?
Sunita Verma:
Yeah. And one of the things we have also pivoted to with AI, and I think most companies would become, we are very specialized AI company, because we specialize in legal tech. One thing I would say is, think about, especially when you're thinking about the software development process, or incorporating AI into the software development process, think about the entirety of your process. Don't just think about the coding side. You have to think right from the beginning about coding, code reviews, code merges, deployments, and production readiness.
And the reason for that is, think about, like, and this is something we were very cognizant of right from the beginning, if you accelerate one part of the process, because now machines are going to be doing a large part of the process work in that start part of the process, you are going to create sort of bottlenecks in downstream part of the processes if you have not thought about how to change the next step. As an example, many companies have adopted agent coding, but they didn't think about changing their review process. So now you can generate thousands and thousands of lines of code, but it's still human beings reviewing the code, they are just overwhelmed at this point. Like, they're just the size of PRs, the amount of basically pull requests that are getting generated is just tremendous. So it's not as if you have basically accelerated the whole process. You've just accelerated one step in the process while the bottleneck has shifted somewhere else.
So one thing I would say is think about the overall process end to end. Second is, at least this is something we made a very intentional investment in, is we've paired our very AI-forward engineers with people who were basically a little bit further behind on the curve, and we saw huge gains from that. So, basically, partnering people and embedding some of your AI-forward people into different parts of your organization, because seeing someone else, how they leverage AI to get that, whatever, two to three times kind of gain, really helps engineers, basically seeing other engineers how they work.
And last but not the least, I would say is very consistent development environment. And what I mean by that is, so what we've done is we've created a marketplace of skills, for engineers, for product managers, for designers. And when you create your workspace, when you create your development environment in engineering, those skills come bundled with that development environment.
So every developer basically gets the same set of skills and has the same level of boost, in some sense, to their productivity that most AI-forward engineers would have. So just thinking through some of these things at the beginning, before you start applying these things, can, mm-hmm, I would say, can prevent some pains down the line.
Gemma Versace:
Yeah, that's such great advice, and I think the commitment and investment in continuous development for the teams is just so critical as well. One last question before we wrap up, I was reading earlier this week about how a technology leader was talking about how important it is, just as you have suggested, to maintain a level of professional development, but also development in general when it comes to AI adoption with the developers.
That there is also a need and value for, also putting that level of coaching and mentoring back into your AI systems or AI agents. Is that something that you guys have implemented at Ironclad, or what are your thoughts on that in general?
Sunita Verma:
There are two different types of AI that is going to become prevalent in an enterprise environment. One is personal productivity agents, you know, and I'll give you an example of how things have started shifting already in our environment, in our company.
And this is not just engineering, this is across the board. People are using either Claude Cowork or ChatGPT Work or one of those enterprise chatbots, and they have connected their MCP servers basically for different parts. So, think about, we all use, you know, an email service. Most companies have a Slack for communication. There is drive notifications that you're receiving all the time. There's just so many different interfaces that I have to log in, basically, in order to stay updated with the information.
But through MCP connection, through a single interface, if I connect all the MCPs to of these services to a single interface and create very clear guidelines for my personal productivity agent on what is it that I care about, that I want to see, I can actually filter out quite a bit of noise that comes from all these channels and get a very crisp, concise view of how things, what is happening, that I need to be aware of. So that's one type.
And the second type of agents are basically the workflow agents and companies, operations agents. We built some, many of those in the commercial legal space. So I think those are the two different type of AI that are going to come in that environment, especially with respect to our, your personal productivity agent.
One of the things you have to keep doing is keep tuning it from time to time. For example, if a new Slack channel gets created for something that is important that I need to pay attention to, I need to tell my agent, hey, pay attention to that Slack channel as well in addition to what you were already doing.
So there is a need for continuously sort of tuning or steering your personal productivity agents. On the product side, what we actually do have sort of affordances built in the product for product to learn from the customer feedback and the customer signal on a continuous basis. So as customers give us feedback, hey, really liked how you thought about this, or, no, this was not the right example, or this was not the right extraction, our system learns from that and tries to correct its behavior based on that.
Gemma Versace:
I love that idea. That's such a smart and very intelligent way to be able to also have that constant feedback loop going somewhere and being a lot more meaningful and genuine than in how the customer's feedback is then relayed internally for, you know, enhancements or recommendations.
That's fabulous, and thank you for sharing that detailed answer. Lastly, we do ask all of our podcast guests, what keeps you moving forward? What gets you up in the morning? Sunita, what's exciting you about life at the moment?
Sunita Verma:
Yeah. So I always describe myself as a technology optimist, and what I mean by that is I have believed in the power of technology, or potential of technology, to solve problems, and that's what I keep driving towards. So, problem-solving and curiosity. And I'm also a very curious person by nature. I need to understand, you know, things a little bit better. I need to understand how dots connect with each other.
So both the problem-solving and curiosity, and especially at a time like this where I have worked in this technology, or I built this technology for so many years, and the moment just seems right for the technology, is just keeping my curiosity and problem-solving aspects like, you know, very right for me.
Gemma Versace:
Oh, I love that. Thank you so very much, Sunita. I have learnt a lot, and also some amazing ideas and recommendations for our listeners to take away from today's episode. So thank you so much for joining us. I really had a great time.
Sunita Verma:
Thank you for having me. Yeah. Thank you for all the questions.
Gemma Versace:
Specification is where responsible AI actually gets decided. Once a model's behavior gets established through an underspecified prompt, it becomes exceptionally hard to walk back later. Governance isn't a phase you bolt on after deployment. It's a decision you make before you write the first line of the prompt.
That same discipline shows up in how Sunita draws the line between delegation and assistance. Handing a task to AI and stepping out of the loop is a completely different mode of work than staying in constant back-and-forth with it. Teams that apply the same interaction model to every task end up creating work instead of removing it. Knowing which mode fits which task is becoming its own kind of literacy.
None of this is really about the technology itself. It's about the discipline leaders bring to rolling it out. Starting with a small, well-defined problem. Building a shared vocabulary before scaling. Thinking about the entire process end to end, so accelerating one step doesn't just shift the bottleneck downstream to the next one.
The teams that get the most out of AI aren't the ones moving the fastest. They're the ones who decided, on day one, exactly what "fast" was supposed to mean.
Join us next time for more conversations with technology leaders who inspire us to grow, lead, and innovate. You can find us on Apple Podcasts, Spotify, or YouTube. If you enjoyed this episode, please share it with your network.
We'll see you next time.