Your keyboard is the real bottleneck | Wispr’s Sahaj Garg

[MUSIC] Today, we're exploring the way engineers are relearning how to build software from scratch with a hedge card, co-founder and CTO of a Whisper Flow. And Whisper is a company that's been on everyone's lips lately and for good reason. They're at the center of a shift that many teams are feeling, moving from voice to text, from never worked to a possible workflow that people now use every day, all day. And this change in the bottleneck going from different parts of the process to actually being your keyboard has led many leaders and senior engineers to discover that they can express their context, taste and intent faster and to help their teams move quicker with voice. Because what if the limiting factor in your organization isn't actually like a context window, but how quickly you can get the right context out of someone's head. So today, we're going to be talking about shared context as being a valuable currency. And all of the different changes that this introduces to how people can communicate with software. And we're going to get really practical about that as well. So it's a hedge welcome to Dev Interrupted. >> Thank you, Andrew. It's fantastic to be here. Really excited for this conversation. >> Me too. And I want to start at the top by just mentioning a little bit about using Whisper. I've been using Whisper Flow very recently and I've totally fallen in love with type of software that it is. It's a true delight to use. And I can see why it's dismantling the way that engineers have traditionally approached working with code on their keyboard. I myself have definitely written like a whole novel at this point. And Whisper even tells me as much. And so I'm actually so blown away by how much I can trust this technology to express what I'm trying to say. And that's what I really want to explore today because I know me and our listeners too, we've all been burned in the past by bad transcripts or that voice attacks didn't really capture what I said or that voice note had a crazy typo with it. Those little tiny burns they add up over time and people walk away from the technology. But we're seeing a shift now where you're rebuilding trust in a technology that many had dismissed. So what has that been like for you at Whisper and how did you approach that challenge? Yeah, it's a fantastic question. And it's actually one of the reasons why we almost never built the product that we did. Because in some ways I actually thought using voice for communication, for typing, for interaction in a computer was like a fundamentally doomed thing after 20 years of being disappointed by every product that was in the market. And I think the thing that we learned as we built it, and especially the first version was like, oh my god, when this works, it's magical. And that is the thing that we have so consistently heard from people who use a product over time, even now, which is when it works, it's magical. And all the work that we try to do here is to expand the settings and the context and the places in which you just get it right, but first try. Because like, as a user of what I want to system that just gets me intuitively, like, I don't have to explain myself a bunch of times, it should know like if I'm talking a cloud code and I'm talking about a.n file, well, that actually means, right, not show up in a completely nonsensical way. I'd say like the biggest framing for us of this problem, right, is we want to build you a voice interaction where you never have to go back and fix the mistake. For us, we call this zero edit rate, right, something where you have to fix no mistakes with what you're doing. And that means both getting everything you said, right, and figuring out what you actually meant to convey, so that we can help you fix that up on your behalf in a way that sounds just like you and that you can actually use downstream. So really, it's like a two-par equation because you have like the traditional layer of like, oh, yes, we can turn this voice into the words it is. But then there's also this contextual layer of understanding what are you operating in? What are the words around you? And what have you said recently? What are the things that matter to you as the user? And combining those two is like the formula I think that whispers is getting right. And it's what's letting people work very quickly with it. So I'm curious in how when you solve the problem of like rebuilding trust and doing it in this two-part way, and acknowledging that it's a nuanced engineering problem. And so you're approaching this with your teams and you know, we're now in a green field because we've acknowledged that there's a lot more nuance than how we solve this. So what assumptions there in that world? Do you throw away to ultimately arrive at an application or a system that's a delight that gets that zero-edit rate? You know, I'm curious like what becomes the secret levers? Yeah, yeah, yeah. There's a bunch of different ones. I think the first one is this idea of like, don't treat speech models as dumb things. Like right now speech models are mostly dumb. They just take an audio, they just produce text. And it's kind of like listening to like a three-second voicemail from somebody who you don't know. It's like very hard to actually figure out what a person saying. And so the really fundamental assumption to break down is like speech models actually need the kinds of things that people use to make sense of each other, which is that context, that memory, that understanding of the other person, which helps make sense of some much more. And so there's this part of it. And then there's like, how do we actually build products like this? And I think products in general right now is there's two types of things that we do. There's one type of work where we do where we just really, really care about precision and scale. Right? So this is like, build the world's best speech models and spend and pour all of our energy into making it better and better and better. And this is like a monumentally difficult effort in terms of how we actually approach it and requires very sustained persistence. It's not the kind of thing where you can like vibe code in a day and have the thing work. And like it's going to solve all the problems. It's very much, you know, use the coding agents to build out all the infrastructure to train these models to create a self-reinforcing feedback loop to make it better and better. Like that's one half of our work. And the other half is the user experience. Right? How do we help people bubble this habit? How do we make it really good? And that's where we actually do a lot of experimentation. Build a version of a way you can handhold the user to learn how to do this and ship that every two hours. Right? Because with being able to go from we built a thing to we saw what happened. Now we learned something to now I can express that idea of what I think we should do next. And to a coding agent, it completely changes the feedback loop of how we build a product like this. Right? So much of that is experiment to learn experiment as quickly as possible and then get that to to be something that, you know, billions of people use. Exactly. And you're calling on something that's really smart that actually a recent guest. We had an engineering lead from codex at OpenAI talk about by capturing the effects of research and using that to drive downstream engineering decisions and then feed that back into the research to create this really amazing feedback loop. And we recently talked at Jeffrey Hauntley who talked about with the Ralph loop, it's all about capturing the back pressure of working and finding the outputs that are most useful for that next input. So what you've described here is fascinating because it's like a you identified and created that compression event. You are doing the the iterative work that persistence you said, which I love for on the model level, which is necessary. But then you're approaching the UX level with the level of experimentation and rapid iteration that's needed to really survive and be like effective as like a user tool. And those two things are a constant probably balance. And it's a new kind of engineering dynamic that I think a lot of product leaders are still kind of wrapping their head around. So I think you've painted a really clear picture of how those things work together. The way I think about it is like what's the hat to be wearing right now? Is this the kind of thing where we know a certain approach is going to work and we just have to hammer away at it to figure out how to make it work? This is what we call like no brainer beds or scaling here internally or is it an experiment? Because if you treat an experiment the same way that you treat the no brainer beds like you're going to get nowhere. You're going to get nowhere at all. And so like the thing that I always ask myself is like, hey put on the right hat. What's the hat to be wearing right now? And what's the right way of working to like accomplish that? Absolutely. So I want to dive into a bit how this shifts like the technology itself. I want to talk a little bit about Whisper has something that now it's been created in this back in this like a compression chamber capturing event that's taking all of the best of research, all of the best of UX experimentation and combining it into what we know is Whisper Flow that's transforming how people work. And if we take that one step further into the downstream effects for how teams are now communicating and sharing their context and engineering both like in an IDE or with an agent along with what you've built. And I want to frame that actually in a really fascinating way ties back to an article. I just recently read from Steve Yage about how the economics of the software era are changing. And the types of software that are useful and survive now in this new era are just fundamentally solving a problem of cognitive burden and couldn't possibly be replaced. And voices like that, like conveying your thoughts and being able to do so effectively and accurately. Most people are not going to have the throughput or the energy to solve that problem. So there you discover your moat in this new AI era. So for folks that are now using these types of tools, like how do you think they would utilize your tool compared to someone who wouldn't to get further ahead and to share their context best. Like when you model your users and your downstream engineers, for example, what does that look like for you? >> Yeah. So let's talk maybe high level about how things are changing and then for different types of people, what this means. So in terms of how things are changing, right? The better and better AI gets, the more of the work it's doing. But the one thing it can't do is figure out like what's in my head, what's in your head, and the unique things that we observe in the world, right? And so that's the one core thing where we want to help amplify people's voice. We want to amplify the thing that they can get into communicating with an AI or into communicating with other people, the two types of places where people are going to be communicating right now. There's a lot of different ways in which it amplifies different people. So if you're a developer and you're building software, the most important thing to actually get these tools to build a software that you want is to express with clarity what you actually want to achieve and to go back and forth on brainstorming with it. If you don't do that, then you're not able to actually build the right thing, then build the right plan, and actually go and execute on that plan. And so fundamentally, right, that system is bottlenecked by like your ability as a person to express the things that are on your mind and to the tool. The other like really powerful thing about voice is even if you don't have your thought fully formed, you can still express it into the tool because it'll help you think through what you haven't fully understood yet. Right. So that's an example for developers where it's like, you vibe code the wrong thing debugging it and fixing it takes weeks, right? But if you get it right on the first try because you give it all the context up front, it like saves you all of that downstream pain. The other example is kind of managers and leaders. Like a lot of what managers and leaders do is they have context across an entire company or entire organization. That's one of the unique vantage points they have. They know a lot of different dots in the team that they're leading. And a lot of their work is connecting those dots and connecting those dots often means just getting the right information to the right person at the company at the right time. And so if you can do that faster, right? Because you can get a message and instinctively just say the reply instead of having a meeting, right? Avoiding the meeting when you don't need to and avoiding the pile up of like 100 messages in your Slack becomes an extremely strong amplifying force, right? Because then one leader can help unblock people so much faster and keep doing more. So there's like two examples. There's plenty more for people who communicate with external clients or customers or at legal industries and so on and so forth. But I think those two kind of give a sense of what it looks like totally. And so for engineers doing them, for example, async engineering work, where does voice meaningfully improve that? Like things like around reasoning and exploring your code and architecture. And where does it possibly introduce ambiguity? Because there's obviously lag and communication between teams and people and kinds of async and remote coding environments. I'm curious to I've seen the really cool posts of people like in their engineering offices with the Gooseneck microphone. You know, everyone's whispering in the engineering room. I love that. Like I want to be there and I want to be like it's so quiet too is what I hear. So like I love that story. But then there's also the engineers, plenty of us who like me are working our living room. And so how does exploring and molding with voice in this way? Like what are things they should keep in mind versus in person? I actually think they're the if you work remotely or in the hybrid capacity. It's like the easiest to adopt tools like this because when you're not around other people, it's so easy to just beat your computer all day. And it's really delightful too, right? And so there's like that aspect of doing it. And there's that aspect of using it to kind of catch up on on async quicker when it comes to communication and so on. The one pitfall is I've seen times where people on our team are both using flow back and forth to each other, DMing each other back and forth in a slack thread. And it's like I'm speaking to you, you're speaking to me, but like we're both using a tool to turn it into text back and forth in real time. And that's not like at that point, you should hop on a call, right? And I think it's really easy, especially in hybrid and remote environments to accidentally fall on that trap sometimes. So that's the one thing to kind of caution against when you start using tools like this is, hey, what's the way in which it can impede really important life and productive conversation. But outside of that, it's like I use the tool definitely the most like between 10 PM and midnight when I'm just able to work at home and really get in my flow state. Yeah. And I think it's funny to the talk about these communication anti patterns that kind of emerge. I think I don't know about you, but I've definitely at some point in my life been at the receiving end of like a stream of consciousness voice note from somebody and you're trying to follow and trying to understand. And now it's like we're in a world where like that could be a slack message that comes to your cross from somebody, maybe even your boss and they're trying to get you to do something. So it's more important than ever that like these tools don't act as obstacles. They don't make work for the recipient. You talk about a zero edit rate, but also like a zero work rate for the recipient. If they are on a receiving end of one of those to understand because like we talked a little bit about like the obviously talking to your computer total delight, but being voiced attacks it can be used in a whole bunch of ways. So you have to think about a really wide user span, right? As like a as a press pretty big challenge, especially as like a CC like how do you how do you you know bucket and understand that it goes beyond and just like you know when you go to onboarding flow and you're like I'm a code or I do engineering work like it there's actually more to that. So like so how do you tackle that problem? It's actually tremendously, tremendously nuanced. So there's two parts of it, right? So I think about is okay right now we're a tool to amplify our communication. Eventually it will be a tool that also takes actions for you, but let's just talk about communication right now, right? The way we think about the products back for our language models that are going from what you said to what you want to communicate is there's two tasks, right? One is to make it something that represents what you said in a way that's true to you and true to the communication you want to convey. And the second is to make sure it's intelligible as the person receiving it, right? Because I don't know about you, but like I've never spoken for a two-minute straight and like been able to produce a perfectly coherent email or when I speak, but the recipient of like this kind of a conversation like you'll understand me when I speak for two minutes, right? People listening here will understand a two-minute dialogue. And so there's definitely a way to satisfy both of these constraints. And where it gets even more kind of the challenging is like the way that this should happen depends so much on who's communicating with who. Like when I text, by co-founder, some of the employees on my team, my wife, and my parents, it's all going to look pretty different. And the shared understanding, the shared context, they're super, super, super different. And so what we really try to do is basically build ways to automatically infer and learn your intent, understand what you're trying to do right now, give you as a user control, right? So if you want it to be more like, verbatim to what you said or if you want to be more interpretive on your behalf, give you that control, and then learn your preference kind of automatically over time, right? Because the way that I see it is like, hey, you fix a mistake that we produce, we should learn that and not do it again, right? Why should you have to tell us multiple times? We should be able to learn all those things about how you might want it in different settings, like different from how somebody else does. And so the maybe the biggest challenge from like an actual engineering and tactical perspective is not trying to do everything for everyone all at once. Because if we do that, very hard to actually tackle all these problems, but like really methodically working through it in a way that's both specific and then over time, like generalizable so that we can make it work actually for everyone. Right. And in thinking about the two, you know, and thinking about your wide breadth of users and the different contexts that they find themselves within, then even within that, there's a level of granularity of the type of handoff that it is because there's, you know, in cases where it's a human talking to their agent, and then of course, like hearing something back from the agent and then working with it versus working with a coworker, right? But in the world we live in right now, all of that text swims together. And so it's a fascinating kind of problem to solve for. But I'm curious to know too, like when, like you are able to pull the context out of people's head, what form do you think it should best live in? Because obviously when we capture those thoughts and then they become markdown documents and these things accumulate, right? How do you as somebody who's, oh, I'm capturing my thoughts and working with them, not create like garbage or instead of creating useful artifacts? There's a great question. And I think there's like garbage and two ways that you can create, right? One is the stream of consciousness that goes to somebody, which is that's really dangerous, as you said. And then there's this stream of consciousness that you output into your notes app. And I think everybody everywhere has never had a great experience with finding a way to like dump all the crap that's going on up here into something that is useful over time, right? And so I think one of the unique things about voice is the thing it's best for is frictionless capture of the jumble of ideas in your brain. It's so much better than anything else for that kind of problem. And then the question for us will become, hey, how do we help you like organize that information for yourself? How do we help you proactively make sense of that kind of information for yourself? And those are two problems that we're very actively like exploring right now and prototyping different installation. 'cause, you know, this idea of being able to offload my thoughts into a second brain is something that people have, I'd say tried quite a bit and never really found a way to make it stick. And like a voice is that interface to which we can do that. And yet today, like our best tools kind of just tack on some AI after the fact to like try and help you maybe do something, which is not really what people ultimately need or want to solve that problem. Which is why going back to perhaps what you alluded to, the idea that you solve this problem now for voice and an understanding that context and then the, you know, the idea of what someone's invoking, you can then go one step further and solve the action problem too. And but 'cause you understand the context in which they're operating in in a much more intimate way because of that's the benefit of voice. So is that where you see this type of technology evolving where, you know, I could today, of course, talk to any sort of type of tool to operate things for me. But do you think that maybe even that collapses one level, one level further? - I think it does, right? If I think about five years from now, what does computing look like, right? I'm probably just gonna be either expressing my intention to my computer, it responds to a decision that it asked me to make or like spontaneously 'cause there's something that I wanna put into it. And like the things that I want to happen will actually happen, right? That's the magic that technology is supposed to promise us and unfortunately we're now in a world where we're like twiddling away tiny thumbs on a tiny screen, far, far from that part of that promise, right? But that's what I expect it to be. And I think the biggest things that are missing right now on that path are a thing that actually gets what your intent was and what you were asking on the first try, 'cause like, if you have to go and fix that up all the time, it's not gonna be a tool that you ever trust as a primary interaction, right? And the other thing is like the right user experience and workflows around this. Like lots of people have built voice interfaces that try at actions and a lot of people don't use them besides for setting timers and it's not due to a lack of trying to use it for more. And I think it's because we haven't come up with the right interaction patterns and interaction paradigms with the right quality of underlying technology for anybody to be able to trust it and do stuff with it. I'm never gonna remember the 200 different commands I could execute with my voice. Like that's the reason why we have you eyes. And so, you know, a lot of the work that we're doing, there's both just improving dictation and making it better and better and better, but also thinking about, hey, what's the right user experience for me to express my intent into my computer and for it to just get what I want and help me do it. - Exactly. And I love how you brought us here too to kind of like this lack of, you know, we currently don't have these workflows, these realities, these supporting structures that help teams operate in this way and in the way that they need to. And that's ultimately a burden that falls on, you know, the leader. So I really wanna talk about the leader's role in all of this and how they can take things like getting unblocked by communication is just one small step but then also understanding the compounding factors of technology like voice the texts that allow them to amplify the work that they can do. And how it is their responsibility, right? As a technology leader within their own company to create these pathways, these highways, between their teams and how they work for this context to not pile up and for it to be useful and for people to feel supportive with amplifying their work in this way. So I'm curious how would you equip a technology leader right now to get fired up and turn back to their engineering team and get them to start operating in these new ways? What are some of the first things that you would tell them? - Yeah, I think about this as like getting AI enabled across the board, like not just with Whisperer, right? But with lots of different tools that are part of the stack. I think the beauty right now is it comes down as simply to people just trying and using it. It's so easy to talk about it and to theorize about it and it's like kind of useless to do those things. So it's like, well, these ideas are promises right and what actually matters is what happens when people deliver on that promise and they're degree to which they do, right? And so if I were kind of an engineer leader and I am with Whisperer, like the biggest thing I'd be doing is making sure that not only I am trying all of the new tools but that everybody on our teams are proactively trying all those new tools and just sharing what they learn on a daily basis. 'Cause if it's just you as the leader who's pushing the charge, it's actually gonna move way slower than if everybody on the team is pushing the charge and you can create a system for actually amplifying the people who are really, really keen to figure out these new ways of working. That's the biggest thing that I'd notice is a way to kind of scale AI adoption 'cause like if it comes top down, not much is gonna happen, right? But if it comes like from everybody being like, oh my God, I feel lighter, work feels easier, I can have more impact, this is fun. I get to do all the things that I just wanted to do but felt like I was stuck 'cause I just couldn't get all my thoughts out or couldn't turn my creative idea into code fast enough. Like that's the kind of thing that really unlocks it. And then your job as a leader is to basically synthesize, synthesize all of those different ways of working, develop some yourself, right? Based on the kind of work that you are doing and like spread that knowledge and teach others. We're very early in this transformation and anybody who's doing that's gonna have a huge, huge impact. - I love the picture you painted and I think it aligns with what a lot of experts like yourself in the last year of "Come On The Show" and kind of painted about how that experimentation should look, what you should measure, obviously elevating your champions and making everybody drive the effort. But now it's fast forward and it's 2026, right? And a lot of teams have been doing that now for a year and you've accumulated maybe a huge buffet of AI tools and everyone kinda has picking their own poison and everyone has their favorite things. And so now as a leader, how do you look for the high signal tools, the ones that are most useful? And like what are the maybe kind of even metrics that you would advise a leader in the situation to use the narrow down the effective ones? - Yeah, that's a great question. I think actually the funny thing about this is experiments that were run three months ago in some ways, probably should just be completely discarded today because the conditions of all of this has changed. And so like the best way to do a thing today might just look nothing like what it was like three months ago and there are just a lot of intermediate stepping stones along the way, which aren't necessary, right? But I think the first and kind of funny thing is like, don't attach yourself to anything that was a specific thing that you learned at some point, right? If it's like, oh, okay, great, like the compaction window once you cross a certain amount, it's gonna be bad. So make sure like everything that you do is about avoiding that. That's important today, that'll be important for a month, maybe two, and then like nobody will care. Like there's no way that that's gonna be the problem that persists for like six months in AI tooling. And so if something feels like a blip along the way or a way of doing a work around to a thing that's gonna improve, like my general perspective is look for the simplest possible solution that solves the problem at hand. The simplest, most elegant possible solution that solves the problem at hand. Quantitatively, it's super hard to know whether like Claude Coder, a cursor works better, but like, at least for me, one of them is simpler for one task, which is a gender development. And the other is simpler for like opening a file and inspecting it and interacting with it. You can probably guess which is which right now. But like, that's how I think about like, what's the simplest thing that gets that job done? What is the gap there? What are things that were assumptions that were made three months ago that I should basically toss out the window 'cause three months ago I wasn't writing 95% of my code of AI today, like I write a single line of code once in a while by hand and it's just a crazy how fast that shifts. - I love that how really you're calling it on more like a, you know, you should call some of these experiments or we're definitely reevaluate what they were doing in the first place. Like I'd be nulleting that we're, you know, we're stepping on the LiliPads, not islands, like they're temporary and we're getting somewhere. And the way I keep thinking about it is I'm building things but then I'm picking them up and I'm running with the stuff that I'm building as I'm building it. Like I'm not digging a mode, I'm not throwing down anchors, I'm not like putting anything I'm running, right? So I think that's a really important call to action for folks if you find yourself with a bunch of like workflows like maybe reevaluate if they were crutches, if there's a better way to solve it today and go for simplicity. I think in the world of SaaS software and people just vibe coding a replacement to something instead of renewing a vendor, I'd much rather in that world be something like GREP or Git. Like something that is so simple and solves such an effective problem that you, it can't be replaced effectively or efficiently or it would cost you too much in your time efforts, tokens, compute, whatever, right? So that's what I think leaders should optimize for in their workflows too. And I like that you think about it that way. - I'll give you one example for us, which is actually on the customer's side. and customer support and customer success side. So I think a lot of the prevailing wisdom is like buy, not build for some of these kinds of things. And we've tried a lot of different solutions. And actually, what we've kind of come back to is the models have gotten so good now that the most important thing is us as a company defining the kind of customer experience we want our users to have. And so much of that is actually about figuring out how to give these systems all of the context that when anybody runs into any kind of problem, we know exactly what to suggest them to do first to try. And also, can automatically have that bug hooked up into not just a linear ticket, but actually just kick off a PR. Like that's actually a possible workflow now. And the hard parts of that are actually, from everything we've tried, less the tooling and less everything around it, but more so, defining what you want your 11 star customer experience to look like and how you get there and how you deliver founder level customer support at scale. And that's an example of I tried building this four months ago as well when I was frustrated that the solutions that I bought weren't good enough and didn't really work. And today, it most definitely has started working, most definitely. And we're investing very heavily into improving that internally because it relies on things that are unique to our core competence as a company, right? Understanding these kind of challenges. >> Getting aligned on what the decision should be, you're right to call out that all of the work now turns inward, just in the same way that like the proliferation of AI generated code exposed all of the problems in the SDLC as what they were, which is the communication and context lagging and baggage. And you get, so you get like this bottleneck to phenomenon, right? And in that same way, when leaders don't operate with the technology, or rather, I guess what I'm trying to say is that if people don't acknowledge that they need to understand the problem they're solving as a business leader before approaching the build by scenario, then they're going to be much better equipped if they can make that realization. Because a lot of times historically, what software leaders have had to do is go out and shop and buy and get the closest to what they need and then conform it to what the company's goals are. And it's almost like a backwards process. So now people have to flip that around and really understand from the top to bottom level, what am I solving with this piece of software? That's what the software needs to do is solve something. And we can be really precise. I'm experiencing the same thing with models too, where like if you know exactly what you want, you can get there in a surprisingly short amount of time and energy. So definitely changes the unit economics too of how people buy. One thing that I often say to people is like, Silicon Valley talks a lot about high agency. And I think the first step of high agency is actually just knowing what you want and knowing what problem you want to solve. And people often skip that step. They start with step two, which is actually solving a thing without really, really clearly identifying, hey, what is it that I actually want and how do we get there? And this is more and more important right now, right? Because if a leader or an engineer or anybody can correctly and precisely articulate what they want a system to do, it's like so much easier to solve that, right? Just like you said, than ever before. This has been such an insightful conversation, so hedge, but I want to ask before we kind of wrap things up to that leader who does want to operate that way. Any final advice that you would give them because we're in a rapidly transforming industry, and everyone is throwing away expectations and working with technology in a new way. Is there any kind of advice that you think is kind of pointing you forward for 2026? Is we kind of start to figure out these new challenges? For me in 2026, it's about reinventing yourself every three months, like properly and truly reinventing yourself in your organization every three months. And that's deeply uncomfortable and deeply unsettling because it is very hard for people to change at that speed. Super hard, super, like literally uncomfortable to actually go through change at that pace. But things that don't work today will work tomorrow in a way and speed that is like hard to kind of fathom because of right around the inflection point where we are. And so like maybe some things that I think about is like nobody knows the answers right now. We're all kind of learning very, very quickly to figure out what the playbooks ought to look like. And so like not being scared of that and holding on to what's uniquely you, which is the ideas in your head and the way that you express them into the world, right? That's why also we're building what we're building out here at Whisperer. That's amazing. I can't agree more that it's about embracing and building your taste and like you've called out very rightly in this conversation, tearing down the barriers between you and expressing your taste. And if you're listening to this and you're still using that dusty old thing called a keyboard, this is definitely your call to action to try out some voice-to-text technology. This is something that I have been using for well over a year, especially in combination with agentic coding. I've tried a lot of tools. And I think Whisperer is something that's a truly delight to use. And this is not at all a sponsored podcast. I just definitely wanted to throw that in there for people just because I can't get enough of this tool. So if you're a software leader, I really encourage you to pick up a simple but delightful tools like this and figure out how they're going to take your team into the future. And so, hedge, just before we wrap, work in our audience, go to learn more about you and the cult of Whisperer. Yeah. You can head over to Whispererflow.ai. And the best thing that you can honestly do is just download the product and use it. Like, people have been told for 20 years that this kind of stuff works. And the only time you're ever going to believe that it actually does and that it actually is delightful to use is by actually trying it out. So you can head over to our website, give the product a try, read some of our research and engineering blogs to learn more. Amazing. So we'll include those notes in the show notes. So please also be sure, if you've listened, especially this far, to come check us out on LinkedIn and Substack or the full newsletter along with this podcast is distributed. As well as reach out to us, we would love to hear your thoughts on our conversation today. Pick up and continue anything that we've talked about here. And thanks for joining us again. That's it for this week's Devon Terrupted and SoHedge. Thanks again for chatting with me today. It's been a blast. Thank you so much for having me on the show. (upbeat music) - AI helps your developers write more code faster. Here's the problem. Your review process hasn't sped up. The queue grows, reviewers get burnt out, cycle time stalls. LinearB changes that. R-A-I reviews every PR the moment it's created. Catching bugs, security gaps, and performance issues before humans get involved. It even writes the PR description automatically. Your reviewers spend less time on first pass problems and more time on architecture and business logic. Break the bottleneck, see how LinearB accelerates your workflow.