23 Apr, 2026
In this episode of the podcast, CTO Adam Blue talks with Q2 COO Hima Mukkamala about how to move quickly with AI without getting swept up in the market’s hype cycle. They explore what responsible speed looks like in banking, why vibe coding changes who gets to build, and how financial institutions can innovate faster without losing sight of trust, compliance, or real customer value.
Watch
Subscribe
Related Links
"Aeroplane Over the Sea" by Neutral Milk Hotel
Transcript
Adam Blue
Hey everyone, welcome to Cut to Context. Joining me today, Hima Mukkamala. I'm Adam Blue. We're both here from Q2 and today we're going to talk about the AI hype cycle. This is a big topic, so let's just get right into it, Hima. Where do you think we are? Where do you think we are in the hype cycle?
Hima Mukkamala
You know, every hype cycle, I think about it, starts with lot of innovation triggers or one innovation trigger. With the AI hype cycle, it feels like a bunch of hype cycles coming, happening like with a small sequence in between. But there seem to be a lot of innovation triggers starting with the LLM trigger, the Cloud Code trigger, and I'm sure there's a few more to come.
But if I aggregate all of them, I feel like we are starting to taper down from that hyperinflated expectation and getting closer to starting to taper down to that trough of disillusionment before they start like the standard adoption curve. That's what's unique about this cycle.
Maybe it happened even with that internet wave, but I felt like Mosaic as a browser sort of was a peak and the internet just combined and became that trigger in the ’94 to ‘96 timeframe. Here, and that took like five, six years to get through the cycle before being productive usage.
Here I feel like there's more triggers, but I do feel like in a much more compressed way, we quickly come to that peak of people recognizing, resetting their expectations of what is it really going to give them compared to the early, you know, really hyper-inflated expectations.
Adam Blue
Yeah, I think that's an interesting way to think about it. So I remember sitting in a conference room and a guy telling me that his data centers are the best because they had guys with machine guns at the data centers. And I thought, this is probably the end of this. This is probably where it's getting a little crazy. I'm not sure we've hit the guys with machine guns in the data centers moment with AI yet. But it does feel like there's a lot more anti-momentum kind of press right now. Not, “Give up. This is dumb. It's pointless.” But there's just a lot more, “This may not be as easy as we thought it was going to be. It may be more challenging to pull things out, maybe more challenging to get to real value.”
But I agree with you. I think there's an overlap of a bunch of smaller cycles happening. So on any given day, you can go find evidence that AI will be the most fundamental technology ever to impact humankind or that it's a total fraud. And it's unclear, like, which one is really true. So that's been really fun. Super great.
Hima Mukkamala
Yeah, yeah, and especially trying to deliver that software for our industry day in and day out. It's been super fun trying to sort of keep those expectations close, but still operate in that environment: regulated, compliance, your risk and so on. But it is interesting, like I was telling someone, you know, having come from like early ‘96 at a SQL Server kernel company writing assembly C++, how excited I was when the internet wave was starting. I feel that sort of an excitement right now with the opportunities. Like you said, it is a big shift that no one, I don't think we still understand the spectrum of impact it's going to happen.
I do feel like it's an interesting dichotomy. I don't know, Adam, how you think about it. One part of it is like the hype cycle and how it's been overhyped, but the other part of it is we just don't know the end of how much impact it's going to have. And that part of me feels like we probably don't know how big it is.
Adam Blue
I agree. I think the things we have not yet discovered will outpace everything we know already in terms of impact. So it's just we're just so early still. Yeah. So that brings us to the next thought, which is: fast, safe, or can you have both? Where do you come down on that dichotomy?
Hima Mukkamala
It is that innovation challenge, right? How fast you go, but it depends on, I think that not just the industry you play in, but the team you are in. Like it's always a reflection of who you're trying to serve.
Like today I came out of an hour and a half session with a bunch of engineers and product managers who were able to innovate and show that extending an existing feature took an hour and 15 minutes. I don't know how they got that specific, but they were like, man, this is a game changer.
And so I think the cycles that we go through have to be fast so that we understand what's the best way to bring that technology, make our jobs easier, make it give that value to the customer, but also learn how to make it safe, right? We cannot go too slow to try to make it safe. So we’ve got to rev, do those revisions internally as fast as we can. And we're seeing that, right? The technology, like how much, how easy it is.
I just enabled, at last year, and Jira MCP within my cloud code. And it was so straightforward, right? How hard it would have been before MCP came out, OAuth in MCP came out. It would have been so much harder even four weeks back, right? So we have to go fast internally so that we can sort of put those guardrails in place so that we can deliver the safe outcomes. Safety cannot be compromised in ...
And not just our industry. There's a lot of industries that matter: industrial, financial, pharma, medical, and so on. So the opportunity I see is the teams to go fast, but protect the end customers, whether it's the consumers or the businesses to be sold to. And I think that's where some of these … when I say we are still not at that productive in the hype cycle, we're still not there with all the tools to get us that very seamless, high utilization from a production standpoint, because the tools are more on going fast. The environment is not there yet to go make it like, ship it to 28 million consumers. So that is where it takes a little bit more time.
But I think it's just a matter of time when we get there to get that truly safe deployment sort of environment in place. So it is, and I'm curious to what you think about it, having seen this industry for a long time, this is probably one of those moments where we are having to go fast, faster than what we thought. And so then how do the customers react to the pace at which the market is asking. I think they probably have the same challenges versus the longer cycles that were there in the past. So I'm just curious what you think, but it's a place for someone operating a software stack to be in this combination of fast and safe. But that's where I feel like great companies do well.
Adam Blue
Yeah. I think you can operate at one velocity internally and then you can really curate and gate what you ship. And as it gets easier to build things, it's not getting easier to ship them effectively yet. I think it probably will. I think it will. Agree with you on that.
But what I would say is it used to be, and we talked about this in another episode of this podcast. It used to be everything we built had to work and had to land because it was expensive to build. So we'd spend a lot of time figuring out what's exactly the right thing to build. Now we can build three or four things, figure out which one works, is secure, is safe, and then focus on getting that shipped. And then the other things, you retool them, you rethink them, maybe you discard them.
But as it gets cheaper to produce, it becomes more about curation and more about a creative portfolio and less about, man, every feature we deliver has to hit because we can only deliver five of them. What if I can deliver a lot of features and so I can actually pick and choose the ones I really want to ship?
That brings us to the next thing I want to talk about with you a little bit today, which is there's a big difference between using AI and feeling like a super developer, like all of a sudden you're this hero, right, and actually having an impact and getting stuff shipped. And I think some of the tools, and even the LLMs themselves, they're very good at making you feel very smart, and then you find out maybe what you've built is not as impactful. It doesn't deliver as much. And so how are you and the team working on, let's make sure these outcomes are real and we're not just running faster on a treadmill that doesn't go anywhere. That's the sense I get sometimes.
Hima Mukkamala
Yeah. Yeah. And I think what fundamentally has changed, like you've said earlier, we can ship five, we can ship 10, that part of it has become easier. But are these the five that we said are what the customers wanted? Like that they've claimed as, if I could find a better way to do a money transfer or a wire and setting different controls for outbound transfer versus inbound transfer. So the specification of that requirement, have we validated that’s the code that we have shipped?
And if you think back how validation has happened, you have a bunch of maybe an engineer or a quality engineer or a developer writing those acceptance tests and validation tests and so on. So that challenge between the top of the funnel where someone's capturing what that customer’s needs are and translating to something that can be validated. And if you look at the pipeline, that stage of that requirement to some feature that quote unquote implements it, that is the acceleration that has happened. But then has it really, is it really doing that part of what the requirement said, again, has not accelerated as much in a deterministic or mostly deterministic fashion, right?
And so that is where, you know, what we are trying to do is not just … and this is where I feel like the tools still need to be built at the front end of the pipeline. When I say pipeline, there's some of requirements at the tail end of it. You and I have talked a little bit about in the past conversation, how the software engineering pyramid is going to get inverted in terms of there's probably fewer coders and more validators to actually, especially in fields like ours, financial industry, where there's a lot more determinism needed and the models still are not accurate to enough of precision that we need.
And so if the industry needs to get a little bit lopsided in terms of who writes code or agents write code and validation. And so what we are seeing more and more is this middle of the pipeline. It's like, when you field a 4 x 400 meter relay, right? You’ve got to make some intelligent choices on the anchor leg versus the middle legs. And that's the place where we are in. How do we get enough of a speed across all of the legs of the relay?
But, and so some of the things we are thinking about is how do we invest more in sort of the model risk management? How do we accelerate the validation cycle of it? And this is where the human in the loop is still turning out to be as important, especially on the validation side of it, right? Obviously, the tools are giving us a lot more of these, you know, you could do 100% unit testing with Cloud Code, but is that giving us the functional validation that our customers expect to be a safe? It's not yet, right?
And so that tool chain is where I think the production readiness of this entire end-to-end pipeline still needs to come in being able to ship as fast as what we can deliver. I think on the requirement stage, I think that's probably one of the areas where we got to figure out from a customer input standpoint, something we've always done, right? Should we do focus groups every week with customers to get the requirements pipeline fine-tuned?
It's going to take a lot of cycles for that validation from the end customer standpoint. Earlier on, we had a three-month pipeline or roadmap or a six-month roadmap, and there was a longer planning cycle, and it was more easy for the customers to engage. So how do we change the top-of-the-funnel validation of requirements or the bottom of the production or preproduction early access validation?
We're starting to build more tools that actually help the end-to-end life cycle, although the middle is the one that got accelerated over the past few months. And I think that's where, and I don't think it's isolated just for how we deliver the code. If you think about it, any software that's shipped, doesn't matter whether humans write it, whether agents write it, it's gonna have issues, defects. How does it support the supporting ecosystem, customer support deal with the initial increased number of issues that show up, right? Because they can't take a human approach to it.
And so we’ve got to figure out more an agentic approach to, and we are doing some tools internally to go agentically solve the customer support sort of pipeline. So those are the steps that still need to be crystallized more, if you think about the overall software pipeline beyond purely build, define, deliver the code to implementation and the support life cycle. I think that is where, but it'll happen much faster than what we have done in the past. And that's where we are focusing on trying to bridge between these other roles that exist in a software pipeline.
Adam Blue
Yeah, yeah. So as we get better at using agentic approaches to generate code and as the actual typing of the code and debugging it and then validating it in and getting it checked in becomes less and less expensive, right? The whole software development life cycle is built around that thing being really expensive. The way we gather requirements, the way we test, the way we ship, whatever we do, all presupposes that the coding of the thing is the hard part. And we all kind of know it's not. We pretend like it is, but it never really has been.
I wonder, maybe, instead of having one set of people go ask customers what the requirements are and then statically committing them to a document, having another set of people interpret what those are and communicate them to an engineer and then having an engineer translate those, what if an engineer and a customer just got on a Zoom call and just vibe coded a feature? What if you cut out that whole nonsense process loop that's basically designed to slow the process down so that you can control what, you know, developers are working on?
And so I like this idea, why don't we just have a focus group once a week where we sit with customers and build features? And I'm wondering, maybe we get even more radical. Like I'll just throw this out. I, it was probably not possible, but I'll throw it out there. What if we just have two engineers get on the phone with two customers and build the feature that the customer most wants on that day? Do it like doing it maybe faster than talking about doing it. And if you can vibe code it, you know, or agentically code it or whatever the word is this week, why not just do it? And then it was inexpensive. So if you don't like the way it turns out, you just don't use it. You throw it away. It's OK.
Hima Mukkamala
It's funny you mentioned this. You and I are old enough to know paid programming and all the techniques that were used and they were all, they had their time. They went away, but you are describing exactly what we thought, you know, two people sitting together. But the problem was there were two people sitting next to each other for like days at a time to do a small feature. That's no good. But now ...
Adam Blue
Yeah, that's no good.
Hima Mukkamala
Exactly to your point, the time it might take a customer to write down a requirement of what they want from the platform, they could just sit with a pair program or pair agent vibe coding, don't know. We've got to come up with a new term for it and actually do it and show it. I mean, we may not ship it to production, that's, I think at least we could get 90% of the way to make sure it meets the requirement that the customer is looking for. I think that needs that, you know, close conversation with the customers on how do we get those pair focus groups going?
But I think even if you don't get the customer in place, I think something which we're trying to do internally is this life cycle of a product manager and an engineer and a quality person. I think that at least we are trying to do it internally where, you know, how you take a requirement to how you write the code to how do you test it, short-circuiting that probably bridges even if you don't get the customer. But to your point, if you can get the customer to sit on a call with a product lead manager and an engineer and just the three of them, three in a pod, ideate and create the first PRD and that's just generated and show it, man, that would be incredible for the customer and for us. Yeah.
I don't know, Adam, we've got to come up with a name, maybe trademark it. Yeah.
Adam Blue
Yeah, something. Yeah, none of the names for this new thing are any good. I think nobody's really hit on something we like yet.
Hima Mukkamala
I heard that vibe coding is no longer the fun name because I thought I was being cool and kept saying vibe coding and someone said don't use that word and it was just like a month ago.
Adam Blue
I know that's the problem. It's all moving, it's just moving too fast to stay ahead of it. So, yeah, one of the things I've heard you say that I really like is sometimes close enough is good enough. You know, there's this, there's this notion around like perfection or, really polishing something. And I think there's times when that's fantastic, but I also think there's times where I feel like getting the feedback on something incomplete and it takes some courage to do that because you're going to hear about stuff you don't want to hear about. But having the bravery to show something unfinished so that someone can have input into it before you finish feels like it could be really powerful. Do you think that gets easier or more common as we move to more, you know, AI-enabled software engineering?
Hima Mukkamala
Yeah. Yeah. You know, I've also said this, right? Whatever you say works, make it work right. Right? So if you show and if you look back about why customers were hesitant to take 80% of it was because it took them a lot of cycles to get it in place, try it, deal with all the issues, change it. So that life cycle was just a long life cycle.
But I feel like now going back to what you brought up, if the customer and an engineer or a customer product manager and an engineer are sitting together and just getting to 80% of it and showing how it works, customers are going to say it to me now as with the safety and others put in place, which is what the platform brings. And then they'll say, it's not going to take me one more year to get the other 20%, right?
That is the biggest shift that agentic architecture, agentic engineering is bringing to this equation is that, right? The other 20% is not going to take six more months or a year. It's going to come fast follow. I think that is why I believe that shift in how fast customers are going to accept it. But we’ve got to do a lot of education, right? The industry is used to this long software cycle and the risk that comes with faster.
So I think there's some more, and this is probably where that the downward slope on the adoption curve or the hype cycle is going to help us is building that muscle with the customers, especially the first few customers to get that 80%. We're seeing that proof point, and I don't know how much you are surprised, but I'm surprised with the early adopters for like some of the new Q2 Code or the Q2 Assistant we are getting in terms of their willingness to take that 85% of it because they know they're getting that face time with the team and being able to talk to them maybe on a weekly basis or a biweekly basis and giving them that feedback and just in the next week getting an update to it, right?
And so I think we prove it out, but this is what I like a lot about what the agentic world is bringing us in those frequent cycles, but still protected by that safety lens that we have. You know, what do we care as technologists, right? You want to put stuff out as quickly as you can, get customer feedback, get them to use it, real adoption and not just put it on the shelf. And I think this agentic world is just a big accelerator in that. And I'm excited. I'm really excited. Yeah.
Adam Blue
But you know, it's scary too. If you base some significant part of your identity on, like, being good at your job, which as Americans it feels like it's kind of written into the Constitution a little bit. And then you find out the thing that maybe was really important to you or you thought was really good at is a thing other people have access to now, right, in a meaningful way without going through the same training that you did or the same woodshedding, whatever it is. So I can understand some of the challenges people have with it from a, you know, just from the capacity and perspective sort of thing.
It's a little like, you know in “The Matrix” when Neo and Morpheus are going to fight and they download Kung Fu into Neo's brain and Morpheus tells them, “You know in this place the fact that I can beat you has nothing to do with your muscles or how fast you are, how strong you are. It's all just about your will now.” And so when I think about people vibe coding or using these tools to do things it's like, it's very liberating, right? But it's also terrifying because it's so close to kind of the core of the problem and what you do. You can feel very exposed when somebody brings you this new way to work. And so I think the impact on the work and the impact on the employees doing the work is maybe bigger than we're giving it credit for a little bit.
Hima Mukkamala
Yeah.
Adam Blue
And so, like, what are you hearing from people when you kind of push them, like, hey, use more AI, make use of these tools, move faster? What are the kind of things you hear back from people where they maybe don't feel great about it?
Hima Mukkamala
The rush of solving a memory pointer problem in C, like when I went to Java, I lost it. Right? So I was, you know, what am I doing? I don't need to debug that anymore. And so I went through some identity crisis moving through that layer. And then when all the fancy, WYSIWYG editors came in and so on.
But if I look at the trajectory of software engineering as a principle, as a philosophy, it keeps growing because the problems that are there in the world to solve, and this is my fundamental belief, are not shrinking. I think we create as many problems—when I say we, the whole human we, and maybe soon extraterrestrial we—create as many problems as we can solve. So first and foremost, that's my personal view of it.
And just a plug, I think we are hiring a lot of new grads because they are going to have to deal with all these issues. I want them to be ready with the tools and then understand the problems we are trying to solve. To your point, if you asked me the question six weeks back, I mean, there was a lot more concern. What I've seen, and I think late December, something changed in the efficacy of the model, especially Cloud Code.
Adam Blue
OK.
Hima Mukkamala
And I think Codex has come a lot long, that change for Codex maybe in the last four weeks. And so what I hear from engineers is it is actually making my life so much better, right? The challenge is, the concern I hear from them is, I think it depends a lot on the organization, different organizations do differently, how they provide their comfort in terms of what they're going to continue to do as they are not having to write code and showing that our customers rely on us to create that safe, compliant platform that is continuing to grow in the requirements and the needs and so on.
And so what we talk about, and so maybe the first part of it is they didn't see that value come out of it until the tools got rich enough, right? So once they cross that chasm, now they're sort of at a place where, yes, it's adding a lot of value to me, but then now they're wondering about what am I going to do to not so much to fill that time that I'm getting to do more stuff, right?
And as you and I know, I mean, the financial industry, our space, banking has so much to do, right? From a requirement standpoint, we're just getting started on the real-time payments. Just as an example, right? The number of people who are developers, who are extending the platform is not that big. So there is an opportunity when someone can customize.
And what we hear from our customers is equip us to compete with quote unquote, the bigger banks. And now this is, I think you said this, this is truly democratizing and giving the financial institutions that we support the ability to compete with the bigger ones with the technology that they have at their hands, right? They have incredible technology that's neutralizing the advantage that the bigger ones may have had.
And so now we're sort of crossing that chasm of we have the time, what are all the features that need to show up in my pipeline to go make our customers’ journey much better or give them more requirements. So we haven't crossed that. That is the challenge we are currently looking at on how do we, to go back to the beginning of the conversation, we have accelerated the middle of the pipeline. We need to accelerate the front of the pipeline and the later part of the tail end of the pipeline from an SDLC standpoint.
I see the energy within the organization, that they feel like the other thing that I hear and I'm curious to what you're hearing, I mean, I feel like my learning cannot keep up to pace with everything that's coming through now. So that's one big challenge I am hearing from the organization, because we haven't redefined what SDLC is. Like what are the tools that are going to be used? Because there are still new things coming out every day.
And so that's the other challenge, to sum up maybe, how do we get more requirements into the backlog so we could actually iterate faster, to go back to your point. And then the second one is, when are we going to get stable in how we do stuff? And that is probably not there yet, it'll take a little bit more time. I don't have a crystal ball on that one in terms of when the tool chain is going to standardize, stabilize that we have a new way of SDLC.
Adam Blue
Yeah, that may end up being, at least for a couple of years, the strongest differentiator is how well can you evolve your SDLC to take the maximum advantage of the AI tools that are available and the new ones that become available.
Hima Mukkamala
Yeah.
Adam Blue
Because what end users care about is what's the use value of the software, right? I remember once I was going to buy a guitar amplifier so I could play electric guitar badly, but more loudly. And so the guy showed me a guitar amp, and it was very expensive. And he's like, so he showed me underneath and he's like, look, this is all hand wired. That's why this costs so much. And I was like, it's beautiful and it's fantastic. And I'm sure it's very high quality, but when I play it, I don't hear the hand wiring. Like, yeah, it's there, but nobody cares. What they care about is does it sound good? Like, how do I feel when I play it? What does it feel like?
And so at some level I don't know that end users really care whether software is hand coded by humans artisanally in small batches up in Portland, you know, on a farm full of fluffy sheeps. Or if they just, they want the experience what they want. They want you to solve their problem. They want software to feel good to use. Whatever gets you closer to that end user problem, that's the valuable part, right? And so ...
Hima Mukkamala
Yeah. Yeah. Sorry, on that note, I was imagining a world where going back to this world of get on a call for an hour and ideate. I'm like, you don't even need us. Ideate with the prompt and our agentic world will generate what you want, that 80%, because you don't even need to talk to an engineer, right? So if you inject them, and maybe that's what you were saying.
Adam Blue
Yeah.
Hima Mukkamala
They want to be, I think they want to feel part of that, like what they ideate and get it in their hands quicker. And so that's what I was imagining, a world where they talk to the platform. You know, Whisperflow or one of those fancy, you know, voiceover things. And then, you know, if you're writing code by talking to your agent, maybe they can do the same thing with requirements and just generate 80% of the app and show it to them and say, are you good? And then we jump in, right? The safeguards at the end of the pipeline, because they don't really care how we write code. You are absolutely right.
You know, as software engineers, like you said, we put a lot of emphasis on, I mean, it is a craft, but the craft people assume I think it's in the code writing. The craft is in systems thinking, right? That is how, that is the essence of, in my mind, software engineering. And people just think, code is part of it. How systems talk to each other? How are they put together? How do you tell the AI to bind these things together? That is where the craft lies and that is not going to go away.
Adam Blue
I'll take someone who's great at systems thinking and therefore troubleshooting and debugging over somebody who's great at architecture and design any day. Some of it's just my bias to be fair. I'm not advocating for that. I'm just saying that's where my heart lies, is in that piece.
All right. Well, thanks very much, Hima. This was fantastic. Really appreciate you being on the podcast today.
One of the things we do here is we leave everybody with a reference to something they can consume, a piece of art or media or music. so today I'm going to recommend, there is a band called Neutral Milk Hotel who did a fantastic album called “In the Aeroplane Over the Sea” on a label called Elephant Six Records. And it was like this really fascinating distillation of what sounds could be considered music. It's like a very raw album by a fantastic artist. And it changed … like I listened to it and I hated it. And then I listened to it again and I liked it a little bit. And now it's maybe one of my favorite albums.
But it changed what I thought about what could be music in the same way that I think, you know, that AI has changed what I thought software development could ever be. And it was kind of, it's kind of liberating. It's kind of exhilarating to just throw away all the shit I was sure I knew because it's not true anymore. It maybe never was true, but now it's really not true. So “In the Aeroplane Over the Sea” by Neutral Milk Hotel is today's recommended listening to go with the podcast.
And thanks again, Hima Mukkamala for joining, and thanks for joining us on Cut to Context, available wherever your fine, high-quality podcasts can be found.
Hima Mukkamala
Thanks Adam.