This is a transcript of a Leaders of Code episode recorded at Snowflake Summit in San Francisco. Leaders of Code is a segment on the Stack Overflow podcast featuring senior engineering leaders discussing team building, process, and the biggest challenges in software today. Vivek Raghunathan is SVP of Engineering at Snowflake. Connect with him on LinkedIn.
Eira May: Hi, and welcome to Leaders of Code. We are recording this episode at Snowflake Summit here in San Francisco. If this is your first time tuning in, Leaders of Code is a segment on the Stack Overflow podcast where we get senior engineering leaders in the room and ask them about the work they’re doing, how they go about building great teams, and the biggest challenges that they find themselves staring down right now. My name is Eira May. I’m the B2B editor at Stack Overflow, and I’m here with Vivek Raghunathan, who is the SVP of Engineering at Snowflake. Welcome to the show.
Vivek Raghunathan: Thank you for having me.
Eira May: How’s the week been going for you so far?
Vivek Raghunathan: It’s been incredibly exciting. This is the time of the year where we get to show everyone what we’ve been up to over the last year. It’s just an incredible experience seeing customers interact with and experience the things we’ve been building. This week gives me great energy going into the rest of the year, knowing that we are on the right track. We are building things that will add incredible value to our customers, and they share our vision of the future.
Eira May: Speaking about vision of the future, one thing that we’ve been hearing a ton about this week is how engineering leadership is shifting. With the cost of code generation approaching zero, the bottleneck is less about writing code and starts to shift toward managing and orchestrating teams, defining intent, thinking about what you can do strategically to deliver real business impact. In your role at Snowflake, have you thought differently about what engineering leadership looks like in light of all these changes?
Vivek Raghunathan: I think the more interesting question in my mind is also how the business of producing software is changing by itself. Because at some level, roles and what people do is an outward metric of how software is actually being produced. We have taken a fairly methodical approach to this over the last 12, 18, 24 months, and I’m happy to go through it in great detail.
The Inner Loop and Outer Loop of Software
The way I think of this is: code gets worked in an engineer’s head, then on their workstation or in a cloud workspace of some form, and it goes through a bunch of steps before it makes its way into main or master. I’ll call that the inner loop of software.
There’s also the outer loop of software — once code is in main, it has to get released into production. And there’s what I’d call the second outer loop: bugs are found in production, they make their way back into the system as support tickets, incidents, or anomaly detection, and fixes in response to those bugs have to make their way back into main.
Beyond those loops, there’s the question you asked: how do roles and responsibilities look in this new world? How is the act of building software itself changing? And how do you structure your organization in response? I break it up into those five vectors. We’re making methodical progress on each of them, building up to the last one, which is the org structure question.
Eira May: I’d love to start at the beginning if you could unpack it for us.
Vivek Raghunathan: Happy to. The inner loop is at some level the easiest because, at its core, coding agents make it easy for you to write more code and better code faster.
Let Chaos Reign — Then Rein It In
We started with an approach Andy Grove once described: in any platform shift, you need to let chaos reign before you rein in the chaos. So the approach we took initially was to just let chaos reign. Habit formation is hard. Habit breaking is hard. We encouraged people to use coding agents. We measured adoption — not lines of code, not PR count, not any of the easily gameable metrics. We just measured: do you use this twice a day? Does 95% of the org use it weekly?
We encouraged people to use it to write code, review code, understand code, write design docs — everything. We gave them every possible tool and said no to nothing. That’s step one.
Now you have chaos reigning. A bunch of people are using coding agents. Ninety-five, maybe 97 percent of our engineers use them on a weekly active basis. But are all of them equally effective? That’s the second question. There’s a difference between using a coding agent to save yourself 20 minutes a day and using it to do 80% of your job.
14 AI Design Patterns
I’d argue the difference between using coding agents and truly mastering them comes down to 14 AI design patterns. I use that word deliberately. Design patterns — for those of us in the software engineering industry, think of the Gang of Four book with the factory pattern, the command pattern, and so on. That book created a shared language for thinking about how to write software more effectively. Something similar is happening with coding agents.
We’ve discovered about 14 patterns so far. I number them starting from zero. They represent what our most fearless explorers — our AI czars, the people at the cutting edge — have found to be effective ways of working with coding agents. A few examples:
Pattern 1 — Plan in English. First plan. Use plan mode in your coding agent. Figure out the plan in Markdown before you write a single line of code.
Pattern 4 — Fence Your Robots. You can run a single agent, but it’s slow. You can run a bunch of agents working together and get chaos. Or you can use git-worktrees that run agents independently, each in its own sandbox. That isolation dramatically improves productivity.
Pattern 8 — The TLF Agents Pattern. Your orchestrator — the master agent you’re talking to — never holds a lot of context directly. It delegates work to an agent team that does the actual execution. This keeps the orchestrator’s “brain” free to communicate with you.
Patterns 12 and 13 — Continued Learning. These patterns recognize that you can mine memory from past sessions and promote it into skills overnight, making the system get better as you use it. When the whole team does this in a multiplayer way, you start to harness tribal knowledge across the engineering org.
We have XKCD-style comics for each of these 14 patterns, which makes them easy to disseminate across the organization. These patterns give us a shared language for upskilling and reskilling engineers — and that language is what enables the next step: reining in the chaos.
Focus Weeks: Creating Space to Level Up
One of the most effective techniques we’ve found for spreading these patterns across the org is simple: create space and time for people to learn them. We call these “focus weeks.” We run them regularly. For one week, everyone in the org steps back from the normal sprint and takes the time to figure things out.
Focus weeks serve two purposes, because the org has two very different types of engineers when it comes to AI adoption.
About 95% of the organization are what I call exploiters — and the term sounds spicy, but it just means they want the paved paths. They want to know what works, and they want to use it. They don’t want to do the exploratory learning. They’re too busy. Focus weeks give them protected time to actually absorb the best practices and get up to speed.
The other 5% are what I call fearless explorers. These are the people paving the paths and creating the best practices. They’ll find the time on their own — evenings, weekends, whenever. What they need from focus weeks is permission and space to go deeper, to push the frontier further and bring back new patterns for everyone else.
The Pioneers, Settlers, and Skeptics Framework
Not every engineer responds to AI adoption the same way, and it’s important to meet people where they are. We think about the engineering org in terms of three groups: pioneers, settlers, and skeptics.
Pioneers are your fearless explorers. They run toward new tools and capabilities. Settlers follow once there’s a clear path — they want proven patterns and guardrails before they commit. Skeptics are more resistant, and honestly, the shift to AI-forward development can trigger something resembling the stages of grief for some engineers. Acknowledging that and meeting people at their current stage, rather than demanding uniform adoption, is critical to making progress across the whole org.
The Yegge Scale: Measuring Progress Along the Continuum
Internally, we use what we call the Yegge scale to measure how far engineers have progressed along the inner-loop continuum — from using a coding agent for simple autocomplete all the way to having it drive the majority of the implementation while the engineer focuses on intent, review, and judgment. Tracking where engineers sit on that scale helps us target support, focus weeks, and pattern education where it’s most needed.
The Outer Loop: Cutting Release Validation from 15 Days to 1
Moving to the outer loop, one of the most concrete results we’ve achieved is cutting our release validation time from 15 days down to a single day. That improvement came from applying coding agents and automation systematically to the release pipeline — not just to writing code, but to the testing, validation, and verification steps that happen after code lands in main.
Importantly, more automated testing has not come at the cost of production stability. If anything, the increased coverage and speed of the validation cycle has improved confidence in releases.
A 40x Improvement on the Query Compiler
One concrete example of what this looks like at the product level: a three-person team used coding agents to deliver a 40x improvement on Snowflake’s query compiler. That’s the kind of result that wouldn’t have been achievable on that timeline or with that team size without agents taking on a significant portion of the implementation work.
The Second Outer Loop: On-Call and Incident Response
The second outer loop — how bugs and incidents in production make their way back through the system and get resolved — is where we’re now building a four-step maturity model.
Right now, agents assist with on-call triage and help engineers navigate runbooks and past incidents faster. As the model matures, agents take on more of the diagnostic and remediation work. The endpoint of that maturity model is agents taking primary on-call duty, with human engineers serving as escalation and oversight rather than first responders. We’re not there yet, but the path is clear, and each step is a concrete improvement in mean time to resolution and a reduction in on-call toil.
What This Means for Engineering Leadership
All five of these vectors — the inner loop, the outer loop, the second outer loop, how the act of building software changes, and how you structure your organization — are interconnected. The patterns, the focus weeks, the maturity models: they’re all building toward an engineering org where humans are focused on intent, judgment, and creativity, and agents are handling the mechanical execution across the full software lifecycle.
The leaders who will do this well are the ones who take a methodical approach — letting chaos reign long enough to learn what works, then codifying those lessons into shared language and paved paths that the whole org can walk.
