Brandon (00:01.205)
Joining me today is Arjun Ayer, CEO and co-founder of Cygnadot. Arjun, welcome to the show.

Arjun Iyer (00:07.628)
Super excited to be here, Brandon.

Brandon (00:09.833)
All right, we're gonna have a fun discussion about a bunch of different things, developer life cycles, you know, some agentic development and plenty of other stuff. But before we get into that, we always like to learn a bit about our our guests. So can you kind of tell us about yourself and how you got into tech?

Arjun Iyer (00:24.654)
Absolutely. you know, I'm I grew back up back in India. that was where I had my high schooling and did my undergrad there. So always been interested in math and sort of like the sciencey part of the things, less less so with linguistics and things. So got into a good college there. and I got a scholarship to come to the US to do my masters. and

Actually my undergrad was in mechanical engineering and so I got a scholarship to come and study mechanical engineering here at the University of Illinois at

Brandon (01:02.569)
Like everyone and now you now you use none of that every day. So that's funny. Go on. Mm Mm-hmm.

Arjun Iyer (01:05.503)
Yeah, exactly. Yeah. and so I came here to do my masters and I I fell in love with computer science, right? You know, I was I took a few courses here at the University of Illinois. and I'm like, okay, this is what I wanna do, right? Like so I I ca actually I have two double masters from the university. So one in mechanical engineering and one in computer science. And that led me to the Silicon Valley and you know, I've been here since. So yeah, that's kind of my

story and I've been love I just love it. Like it that's kind of my I realized it late in my career but yeah I've just been it's been great. Yeah.

Brandon (01:44.139)
That's right. You made it just in time, right? You know, get that last master's and then get into technology. So that's good. Well, listen, one of the things you did a bunch of stuff interesting in your career, but one thing I wanted to talk about was your experience at AppD, right? So application dynamics and you know, I don't know, it's one of these companies and products that's been around for a long time. So a couple things, why don't you tell us like what you did there? Because I think that'll lead into a little bit about what's going on Cygna Dot. And then of course, I gotta hear the story. If you were there for it, you know, there's a story about like you're gonna go public and then Cisco.

bought you at the last minute. So so tell us that story for everyone that maybe hasn't heard that before.

Arjun Iyer (02:17.835)
No, absolutely. That that was roller coaster for sure. so yeah, I I wa I was hired in App Dynamics specifically to build out the next generation sort of like cloud native backend for App Dynamics and the product was called analytics internally, but then it was rebranded as business IQ because we were ingesting like terabytes of data, right? Like from all these applications that we we were monitoring.

And we wanted a way to allow our users to really like slice and dice the data in real time. So basically like query that huge amount of real-time data that's coming to our back end and be able to create dashboards and an analysis. And even like we at the later stage we also did machine learning on that data and things like that. So so that was the team I actually bootstrapped from scratch. So I hired the engineering team.

all the way from zero to like we were at one point more than eighty people in my team. and then we launched the product in the market and it was one of the fastest growing products in within App Dynamics. And that caught the I would I would I know I may be biased but I I think it had something to do with the Cisco acquisition as well. they were actually very interested in the analytics aspect of our solution and yeah and so

At that time, you know, Jyoti was the CEO and you know, and founder of App Dynamics. I used to report to Jyoti directly and, you know, he hired me personally to take this, take this to fruition. And then of course the the Cisco acquisition was such a it was a roller coaster, it was a kind of a bittersweet moment for us. because prior to that, like we had some really aggressive goals, like we were going to

shoot for like a billion dollar in revenue as our sort of goal. That was what we were all excited about. And we already, you know, filed for the IPO and everything. And we had the whole roadshow going on and everything was like teed up, right? And just one day before the before we are gonna go IPO, there comes an offer from Cisco. you know, like I think it was like close to four billion or something like that. And

Arjun Iyer (04:35.917)
We accepted that offer and and everybody was like, What? Like it was such a you know, roller coaster ride. it was bittersweet because you know at one on one side, you know, there was liquidation event, so you know, people were happy. you know, people got liquidity out of that event, and so it was very a good good event. But on the other side, you know, we were going for like a one billion in revenue a year, right? So that would have

been a much bigger valuation if we had had it on our own. but of course there was you know, there were risks on both sides. Yeah. You never know. Yeah.

Brandon (05:08.5)
Yeah, you never know, right? You to I mean, at the end, it's like I don't know, you know, you don't go broke taking the money as we talk about on the show all the time. So, you know, who knows? Maybe you could have been worth, you know, a hundred billion, maybe you would have gone to business. You know, you just don't know. So I just remember at the time, I just felt like it was like I don't know, you correct me if I'm wrong. I just remember it was like New Relic and AppD were like locked in this fight. That's how I remember it. And like New Relic was going public and then Ap D was gonna go public and then right at the last minute, Cisco swooped in and bought you. And then it's funny, like, you to hear the numbers, it's like

Arjun Iyer (05:14.615)
Yeah.

Brandon (05:38.143)
They were so big at the time, but now it's like, you know, now we're talking about like hundreds of billions, trillion dollar companies. So it seems I don't know. I guess I guess things just change, right? You know, over time. So yeah, I mean, just just a crazy time. Well, that's good. Well, that sounds like a fun experience. And so obviously you spent some time doing that and spent some time at Cisco. But okay, so let's let's flash forward, then. So, you know, you obviously had a good experience and you've been doing lots of stuff. So you decided to go out on your own here, start Cygna Dot. So so tell us a story. What you know, it's like kind of like

Arjun Iyer (05:44.439)
Yeah. It's yeah, that's tech for you. Yeah.

Brandon (06:07.73)
Most of the time it's like, did you find a technology that you just had felt like need to apply something? Do you see some customer problems that need to be solved? Like what what's your origin story here?

Arjun Iyer (06:17.441)
Yeah, I mean it's like I think intrinsically I'm a developer at heart. Like even though I've I've sort of like, you know, managed large teams and things like that. and I always I felt that development is more like it's more an artistic endeavor. Like it's more like

you know, painting and like you know, sort of like creating something like movies or or like music. it always felt to me like it's it's more of the artistic pursuit. however, the way I used to see software development being run, it seemed like a factory automation, right? Like it's sort of like you know, it just so always intrinsically I felt like this is not how software development should be done. It should be like give the creative freedom back to developers

And don't involve them in the minutiae of like, you know, running CI CD pipelines and like all like, you know, all these things that interrupt your flow. And that's kind of like really what unlocked the vision for SignalArt for me was how do I give the creative freedom back to developers, especially when you're building like a reasonably sophisticated like software, right? I I'm not talking about like simple apps, but like cloud native apps where you have a a reasonable amount of complexity.

How do you give that creative freedom back to developers? And how do you make it so easy to take the code that you've just written all the way to production in the fastest possible way? Because that's kind of what what developers love is to see that code that they have written be actually used by some real user, right? And and sort of get some value out of it. So that was my sort of high level sort of vision that I had. And then we started to work on okay, like.

What exactly are the problems? Like why is the software delivery more like a factory rather than a creative pursuit, right? And and then we realize that it's all these kind of like what happens between code that's generated and code that's deployed is all like validation. Like you're just trying to validate this code in different ways and shapes and forms. and you're trying to do like, you know, code reviews and

Arjun Iyer (08:32.107)
You know, end-to-end tests and security tests and performance tests and all kinds of stuff happens. It's all trying to answer that single question, can I deplore this code to production? Right? You know, or will production fall over? Right. so that's kind of the the the the light bulb moment that I had is if I can give developers a easy way to sort of like, you know, validate that code and make it so simple that they don't have to worry about it, it just like runs on autopilot.

Brandon (08:44.115)
Absolutely. Mm-hmm.

Arjun Iyer (09:01.205)
And they focus more on the coding part. Like they focus more on the design and the architecture and experimentation. you know, write a few different versions of this code and see which works better or design it in a different way and see like A B test two versions of the code. That's where I see the the really like what I would have loved to do, right? Like if I had the infrastructure to do that. but I I was saying like my team was spending like

Almost forty percent or more of their time on all these other other tasks, right? Like, you know, debugging production issues, like, you know, like working with staging is broken. So let's go and fix that. Like, you know, CI C D is broken, like tests are failing. like all these things are not not creative tasks. they are just like me you know, it's like it's basically menial work, right? Like it just it just fills up your day, right? And it's just sort of like

That's where I felt like, okay, there needs to be a better way. And that sort of led led to the birth of Cygnadot. So yeah. So what we have built is Cygnadot in in short is it's basically a validation infrastructure for cloud native applications, right? Like that's kind of what what we have built. And with this agentic disruption going on right now, it's just like, you know, the demand is just sky skyrocketing, right? So

Brandon (10:22.185)
So let's kind of delve into a little bit about because I mean I think you kind of hit what I think all developers like to say. Let's just call it like sometimes on the show we call it developer toil, just like all the, you know, all the stuff you have to do. And you know, and there's a bunch of surveys I know we've reviewed on the show many times. Like developers really only spend like 10, 20% of their time coding. Like, you know, all these other things get involved. So so kind of let's, you know, when you kind of get inside the development lifecycle, right? And this is where I think, you know, you're really trying to make it faster. So maybe we should start with just like your simple observ observation, sort of like

Arjun Iyer (10:29.122)
Yeah, doil.

Brandon (10:51.495)
What did you notice about like just getting a pull request merge? Like what was the thing that stood out to you? You're like, man, I just I I don't want the developers to have to be doing this anymore. I want to fix this problem. What what jumps out at you?

Arjun Iyer (11:03.744)
it's the rework. If I were to summarize it's the rework of code that gets merged. that's the killer issue that I noticed is you know, you can merge

Brandon (11:11.561)
Mm-hmm. So say more about like when you say when you say rework, like say more about that. Is that like I get some feedback in my code review and I gotta like edit it or like what what's causing that rework?

Arjun Iyer (11:21.964)
Yeah, it's so this so if you look at software development lifecycle, it's all loops, right? It's all feedback loops, right? Like so right from this time I start developing on my IDE or the local development model, it's kinda I'm getting feedback from my IDE to begin with, and then I get feedback from CI, you know, then I get feedback from staging and then I get feedback from production, right? Like it's all feedback loops, right? And so the later the later the

Brandon (11:44.211)
Mm-hmm. Yep.

Like, should we call those bugs or issues? Well, you say feedback, I thought so funny, like to I I think you're right, but it's sort of like it's basically like you've deployed it but it's not doing what you want, right? Is that is is okay. Go so okay, so go on. Mm-hmm.

Arjun Iyer (11:58.305)
It's not doing a monitor. Exactly. Yeah. Yeah. Yeah. So yeah. So it's and it's continuously that's what is happening, right? Like, you know, in my in my IDE, the code doesn't compile, so I get a feedback loop and I fix that, right? In production, something is breaking and now I have a production issue. And that's a feedback cycle which is very long and tedious. So what we realized is that the later you get the later in the stage that the feedback cycle happens, the longer and tedious it is.

Brandon (12:13.161)
Mm-hmm. Mm-hmm.

Arjun Iyer (12:27.436)
Right. And so the whole idea is how to minimize the feedback loop that happened in later stages and really get as much feedback in the earlier stages. Right. Like that's kind of the core idea here is really shifting left. And and people call it shifting left in different contexts. But what we are talking about here is like shifting left in terms of getting that validation very early and getting all sorts of validation, not just like basic unit tests passing.

you know, all kinds of validations happening as early as possible. Like that's kind of the real unlock for me that I realized is okay, this is how I want to develop.

Brandon (13:04.977)
Okay. And so this seems to like it seems like your insight here is this idea of ephemeral environments, right? Or and maybe two things here. One, just define what that means to everybody. And then where in the loop, right, are you trying to insert these environments?

Arjun Iyer (13:21.218)
Yeah, and when I talk about feedback loops, the way the feedback loop works is you run the code that you've written, see how it behaves, and then you see how it works. And if it doesn't work properly, you come and fix the code, right? That that's kind of the feedback loop. And to run the code, you need an environment where the code runs, right? And so so what we realized was especially in the in the cloud native sort of context where you're having so many different runtime dependencies, the environment becomes a huge bottleneck.

Right. And that's what organizations struggle with is either you're stuck to your local laptop, which is resource constrained all the time, or you're stuck with this kind of like a staging environment, which is a beast, and it's it's shared, right? So so you're stuck between a rock and a hard place where you know, like locally I can't do much. you know, I can barely run a few services locally and I can't really do holistic testing.

or validation and then on staging I'm always it's always contended, right? This very high contention because everybody is trying to use it. And so it's always in a broken state. Right. So so that's kind of the where the idea of ephemeral environments comes in is where you actually create or enable creation of these lightweight environments that have some very specific properties that allow it to scale. The scalability part is the most important one here because

Every developer and now increasingly every agent needs an environment, right? So if you actually go the brute force way, which has been done traditionally, is you just kind of like you know duplicate your staging environment or you know you duplicate this environment, that environment. But it does not scale. It's like it's it's very expensive to duplicate these environments, especially in a a cloud native context, and it's operationally horribly hard to maintain, right? You gotta maintain all these environments now.

It just becomes like impossible to scale that system. So so our approach to FML environments is that it's a more virtualized approach where we take an existing environment that you have, like a staging or some kind of pre-production environment, and we introduce multi-tenancy in that environment. So you essentially you have one physical like you know Kubernetes environment where you install our solution and then you can get like thousands of these lightweight environments called sandboxes.

Arjun Iyer (15:45.507)
Right. So that's kind of the idea here. And we'll get into sort of how how it works. But the high-level idea is really introduce multi-tenancy in an existing environment. So and it has isolation built in. So agents and developers can spin up one in seconds and be able to run whatever validations that they need to run as soon as they write code. Right. That's the real key part. And you talked about you asked me about where it fits in. So it fits in two space two phases.

One is the local development or the inner loop phase, which we call it as, and the other one is the PR phase, right? So everything happens pre-merge. And that's kind of the real unlock that I talked about earlier, which is shift left as much of the validations because the cycles are very fast here in these two phases. So if something fails, you know

Brandon (16:31.026)
So inner loop, just to make sure we everyone's following. So inner loop is really like, you know, your local development process. Like what when you say inner loop, what what exactly is inside the inner loop?

Arjun Iyer (16:41.474)
Yeah, the inner loop is yeah, most like it's most commonly associated with the local development process, but now that is changing with agents coming in a little bit, but but essentially it is the it's optimized for speed, right? It's optimized for speed where again it's about that feedback cycle speed that I was talking about earlier. so you have this inner loop where agents or developers are coding and they want that feedback right away. Like, you know, they want the feedback, does my code work?

And the outer loop is typically like the CI loop, right? Like where you actually push a PR and then you might want to run a more extensive set of tests there because that's optimized for comprehensiveness, right? Whereas the inner loop is optimized for speed. Whereas the outer loop, which is the CI loop, is optimized for, hey, did I break anything else? Like did I run all my regression suite there? because that typically I don't want to run in my inner loop.

Brandon (17:34.696)
Yep. Makes sense. So now what about the environments you're replicating and and so maybe give people a sense? Like, you know, there's everything from like the mainframe, there's Kubernetes, there's VMware, there's virtual machines. So what like how like within this vast world of you know endless amount of environments, what are the environments that you can, if you will, build a ephemeral environment for?

Arjun Iyer (17:54.733)
right now our solution is fairly Kubernetes native. so we do cater to engineering teams that are running on Kubernetes, but it's not completely limited to Kubernetes. You could have a hybrid environment where you know, like many of our customers do, like some of the larger ones, they have Kubernetes, they have ECS, they have other VMs and other traditional modes of deployment. So we work with that as well. But but we do need Kubernetes as a place to install Kubernetes.

Our operator, and that's kind of the sort of the foundational layer of the solution, which creates these sandboxes.

Brandon (18:31.068)
Okay, so let's maybe kind of like contrast, like, you know, I'll I'll just take the the my more naive developer approach. Like I'm a developer, I'm like working on my machine. Probably what I do is I get like I get all the you know container containerized other services I need that are I'm dependent on. And I just like I just try to get them all running to either I run out of memory on my computer or you know, or I or I just do my best, right? Or maybe I like hop cobble together like a another VM. And so

Obviously there's lots of limitations to that. One, I have to maintain up all. Two, there's just like usually some upper limit. Like there's usually like some database. And I was like, I can't run this on my machine. It's like requires too much, right? So in that kind of situation, like what like what does the developer do? Like how does how do they take advantage of your environment so that they're not bottlenecked with kind of the constraints I just mentioned?

Arjun Iyer (19:20.876)
Yeah, so essentially our solution blends the the local development or the PR development context with a remote Kubernetes cluster, right? So essentially what you what this enables you to do is a developer can be developing some part of the overall application locally on their laptop or on on a remote environment, like a cloud development environment. and

Brandon (19:31.996)
Okay.

Arjun Iyer (19:49.444)
They don't need the whole stack running there. They only need the services that they're changing running there. And we transparently bridge these two worlds, like the local environment and the Kubernetes environment, such that you can actually leverage the remote environment to do like an end-to-end system test. Right. So we bridge those two environments so that it almost feels like I'm in that sort of Kubernetes cluster for all practical purposes, but actually I'm developing locally, right?

so that's kind of the the idea here is to blend both of the worlds so that and that comes back to the concept of sandboxes, which is think of that as an environment slice, right? So it's an environment slice that only has the services that I've changed, but it plays well with the rest of the dependencies. So I have access to the entire environment, and so that's kind of the r reason it enables like end-to-end testing, performance testing, security, runtime security testing.

Brandon (20:30.184)
Okay.

Brandon (20:37.938)
Gotcha.

Arjun Iyer (20:48.013)
you can do all kinds of like I mean it's a whole long tail of validations that you can now run without having to duplicate that stack on my local machine, nor do I need to duplicate that stack in another staging environment.

Brandon (21:01.736)
Okay. That all makes sense. So then how does it work when I so when I'm, if you will, you know, deploying your solution for the first time? Am I is it something like that's maybe being purchased by like the engineering management or the CIO? And do I am I basically looking for like, hey, we want to use this new thing and I need I need this Kubernetes cluster set up so I can run Cygna Dot on it? Like how does that whole part how does that part work?

Arjun Iyer (21:25.621)
so usually it's like the it'll be like a platform engineering lead or somebody from the platform engineering team, that usually tries the solution themselves to begin with, right? Or it could be like a very senior, like a staff engineer or a principal engineer that

Brandon (21:31.729)
Okay.

Brandon (21:39.944)
So I assume like is are they coming to you because like, man, like the this development team's all over us or like our staging is like a mess and we can't is that kind of like the pain that they're coming to you with and like we want something simpler? Like like how do they how do they figure out that they want to use CygnaDot?

Arjun Iyer (21:56.226)
because the software delivery is sort of like bottlenecked for them, right? So they yeah, so it's not so code is being produced at a very high volume, but nothing is going to production. Like it's all like choked, right? So so that's kind of the symptom that we see over and over again is like, I'm getting like all my developers producing 10x more code now because of all these coding agents. but none of it is making it to production as fast. And

Brandon (22:00.238)
Okay.

Brandon (22:04.677)
Yep. Okay, gotcha, right? Okay.

Brandon (22:12.998)
Okay.

Arjun Iyer (22:24.833)
It's getting clogged up in different phases. Like, you know, we're getting c clogged up in code reviews. it's getting my staging environment is always down. I'm not able to test there, I'm not able to validate. So all of this is just like choking up. Yeah.

Brandon (22:34.171)
Got it. Good. So it's like low velocity, low throughput, whatever whatever you however you want to say it. And then you're the bottom okay. So I get it. So they they come to you like, you gotta get rid of this bottleneck for us. Okay. So then now take it from there. What do they do? They're like, I'm sold. How do I set this thing up?

Arjun Iyer (22:47.757)
Yeah. So first they will install the signal. So it could be any pre production environment. So that's the first step. And then we have our CLI, which is the main sort of interface to our system. and that works on like in the local development scenario where you just just use our CLI to create these sandboxes. and it also works in the CI scenario. Like so you integrate

Brandon (22:56.006)
Okay.

Brandon (23:13.563)
Okay. Got it.

Arjun Iyer (23:14.447)
The CLI with the like a CI system, like you know, GitHub Actions or Jenkins or something like that. and again, there you automatically create the sandboxes for every PR, right? And and because these sandboxes are so lightweight and they spin up in seconds, you can do now the granularity of an environment is hugely expanded. I mean, hugely like it's basically you can have one environment per code change.

Right? which was unthinkable before, right? You could you can't afford to have like you know environment per code change. Like at the most you can have it per team or something. but now you can have it like for every code change, like you can have like one developer spinning up like five b agents, right? like cursor or clot code or something, and each of those agents can have a sandbox where where it actually r validates the code that they're written, and so it becomes like

Brandon (23:44.561)
Got it.

Brandon (24:03.761)
Gotcha.

Arjun Iyer (24:10.009)
Possible now to actually realize the the dream of true continuous delivery. Right? Yeah.

Brandon (24:16.773)
Yeah, that makes sense. So now so got kind of going back. So like we'll get in the agents side in a second, because I can see where that makes a lot of sense, right? Because you have so many things coming at you. But like so, so if I'm a developer, it's like this has been deployed. Does does like the platform engineer go back to the team and say, Okay, everyone, we've got this new tool. Here's the CLI. And then is there like a little training for them so that they kind of back to your inner loop, right? So you kind of tell developers like listen, you can here's how you can do the inner loop testing faster.

Arjun Iyer (24:21.283)
Yeah. Yeah.

Brandon (24:44.603)
And then what does that training look like? And then because like this all comes back to like developer adoption, right? Back to your requirement about velocity. It's like if they're like this is too complicated, you know, it's no good, right? You know that. So so it's like, how does that part work? How do you win over the developer? How much do they have to learn? How do you get them like excited about like using this?

Arjun Iyer (24:49.838)
Yeah.

Arjun Iyer (24:54.371)
Yeah, yeah.

Arjun Iyer (25:02.201)
Yeah. yeah, no, that's that's that has evolved quite a bit. you know, yeah earlier, yes, they would have to have downloaded the CLI and there's some training needed. Now with agents, that training has really drastically reduced because the agents know how to how to create sandboxes, right? So through our MCP server. So now developers just work in their IDE, like which is basically coding agents, and they just talk to it in plain English, right? So they just say

Brandon (25:20.527)
Okay. Right?

Brandon (25:30.215)
Okay.

Arjun Iyer (25:31.19)
I'm coding this up, and obviously the the agent knows what it's coding up. And so it the age the developer just has to tell it, hey, create a sandbox for this, and it knows how to do it because they don't have to worry about learning our CLI commands and syntax and everything because the agent just knows how to create a sandbox for them. So it becomes like super simple. That's the local the inner loop case.

Brandon (25:54.607)
Mm-hmm. Gotcha?

Arjun Iyer (25:56.79)
the the the CI case, the platform engineer will automate that using the CI automation. Right. So whenever the PR comes in, you a small workflow runs that builds the image for the branch and then creates a sandbox from that image.

Brandon (26:02.577)
Gotcha. Yep.

Brandon (26:12.177)
Gotcha. So what what is and I like that. I mean, I like the idea of the MCPA, you're speaking my language now. It's like, yeah, just build me a sandbox. I love that. But kind of just to give everyone a flavor of like like, you know, what is a sandbox? Like and how do I define it? Am I like sort of like is there's like some YAML file or something, like some configuration thing that say like I want an environment that looks like this, and then your environment like creates the containers and the the various endpoints that I need. Like how does that work? How what does that sandbox look like?

Arjun Iyer (26:39.651)
Yeah, exactly. It's a YAML file. and the the key thing about that YAML file is it's relative. It's relative to the baseline. So it's not like I'm I'm deploying the whole stack in the sandbox, right? So let's say for example I have 50 microservices or 50 services running in my staging environment that represents production. And let's say I'm changing let's say two or three of the services for my feature. then so what I will do in my YAML file is I will say I'm changing service A, B, and C.

Brandon (26:47.313)
Okay.

Brandon (27:10.023)
Okay.

Arjun Iyer (27:10.129)
and that gets included in the sandbox and then the rest of it is leveraged from that shared staging environment, right? And we have mechanisms to blend the sandbox duplicated services with the rest of the environment.

Brandon (27:12.54)
Got it.

Brandon (27:17.733)
Okay.

Brandon (27:28.133)
Okay, that makes total sense. So basically I say I'm changing these things, use these local things, and then everything else go go d magic. Go make it all work for me. Okay. And then where do people like deplo do I guess you can probably deploy it anywhere you can deploy Kubernetes, but are people like setting up this in like a cloud environment? Are they setting up like a local like on premises staging environment? Like how how does the what's the best practice when I'm setting setting up Cigna Dot?

Arjun Iyer (27:33.155)
Yes. It's from the cluster. Yes. Yeah.

Arjun Iyer (27:56.532)
we work no matter where the cluster is running, as long as we have a Kubernetes cluster, it can be in the cloud, it can be on prem, it can be on bare metal. we don't really care, right? So it just works as long as you have Kubernetes because it's a it's a Kubernetes operator that you install using Helm.

Brandon (28:04.817)
Okay.

Brandon (28:13.477)
Okay. So it's really up to the platform engineering team. I just say, I need a Kubernetes. You give them the operator. They know what to do. Get it deployed. We're up and running. And then is there any like I don't know, I just I it feels like a little bit like, you know, like it, you know, I I just feel like you'd hear the objection, like my application's like unique. It's like you know, you're something along those lines, like you've never seen a a system like us. And of course we all know that's false. They but is it is there anything tricky about like like well, any I don't know, for lack of a better question here is like

Well, anything that's running on Kubernetes, can you sort of sandbox anything or are there some like some things I need to watch out for?

Arjun Iyer (28:47.959)
Yeah, so we have a fairly extensible solution. So the way we sandbox and it depends on what components you're actually sandboxing as well. So like for example, stateless services that you have in Kubernetes, the way we provide isolation is through request routing. So we kind of have the ability to in the cluster because our operator installed there, so it has the ability to route requests based on headers that propagate through the request call chain.

So that's the mechanism that we use for services. For let's say message queues, we have a slightly different approach because it's not a synchronous call that's happening. It's more asynchronous fetching of messages. So there it's basically message based routing. So there the header of the the the routing key which is used in the synchronous case, in this case it it gets injected into the Kafka message or the or any message queue message itself.

And then the consumer will decide on which messages to consume based on the header value, right? So there's that routing happening on the Kafka on the message queue side. for databases we have a different mechanism. Like, for example, we have this concept of resource plugins that allow you to spin up a temporary database if you need one. Like, so for example, if you're making like a schema changes in your database as part of your PR.

Brandon (29:52.241)
Okay.

Arjun Iyer (30:13.319)
You don't want to do that in the shared staging environment, right? Because everybody else is using that. So in that case, you would create like a temporary ephemeral database using our resource plugin infrastructure, which is very extensible. So resource plugins are the key extensibility mechanisms we have because that allows you to even like bring up things outside Kubernetes. Like you can bring up like VMs and other things that you need that basically constitute your sandbox.

Brandon (30:42.406)
Okay. And so do I make my own resource plugins or do you have like a catalogue of them that I can use to like, you know, replicate, you know, things that are common? Like how does that work?

Arjun Iyer (30:52.057)
Yeah. So what we what we saw is that the resource plugins tend to be quite bespoke between companies. And so we have examples of various kinds of resource plugins in our GitHub repository. but typically our customers write their own. It it's very quick to write. and now with the coding tools, they can write one for you like within a few seconds a few few minutes. and so you write these resource plugins because the way you like for example, think of a database, like the way you spin up a ephemeral database and

Brandon (31:07.579)
Okay.

Arjun Iyer (31:21.207)
The way you seed that data tends to be highly bespoke. Like every customer does it differently. Like some read through from a snapshot, some take that live data on staging, some do like they feed seed data in a different way. So so we're giving them like a sort of a framework by which they can write these resource plugins. and then we the operator basically manages the lifecycle of that alongside the lifecycle of sandboxes.

Brandon (31:48.347)
Got it. Got So it's really so when I'm kind of back to the deployment. So I'm the platform engineer. I'm bringing your solution on. I get my Kubernetes clusters set up. I use your operator. I deploy it. Then I sit down and I gotta figure out what resources I may need to build out. And that's where I'm gonna look at your resource plugin framework. And I'm gonna probably today I'll probably use like Claude or some other agent and be like build me something. And then at that point, that's now I've got the ability to sandbox anything, right? I guess if once I have all the plugins, I can sandbox anything. All right.

Arjun Iyer (32:15.509)
Exactly. Yeah. Yeah. Yeah.

Brandon (32:18.19)
Okay, so it all makes sense. So it's good. So it sounds like very good for developers. Makes a lot of sense. But I can see where this becomes almost like more mandatory for agents. So so of course, you know, this is a a tech podcast. We have to talk about agents. That's our our everyone's job now. So why don't we why don't we start a little bit just kind of a quick side conversation here because I always think it's interesting to like before we kind of get into how you got you agents, your solution can help that. Like, how about you just talk about because everyone wants to know this? What are you doing at Cygnadot?

when you know, you have all these agents, like what have you seen and what are your developers n now doing? And are you all at the the point where like no one's really writing code, everything's agent generated? Like how has your adoption happened?

Arjun Iyer (33:01.359)
Yeah, no, it's it that's a fascinating story actually. because like I distinctly remember like, you know, we we we like our team is like very senior people. Like, you we we are writing like all these Kubernetes operators and you know, like very like back end distributed systems kind of code. And I remember last year, my engineering team really didn't believe in agents, right? Like they were like, Okay, this produces some code, I don't trust it. this was like back in like would say mid

2025, right? So, like, you know, some of the some of the front end front end code was fine, like it was more effective there, but my back end developers wouldn't touch it, right? Like, you know, so they were like, I would I would rather hand code this. but something happened like after I I believe it was Opus 4.5 that came out in October, November, something like that last year. And everything just changed, right? Like it's just like

Brandon (33:30.224)
Right. Yeah.

Brandon (33:49.766)
Yeah. Mm-hmm.

Arjun Iyer (33:55.322)
There was a flip that went off. I'm like, whoa, like it's writing pretty good code now. and so like yeah, it's it's even the the staunch de factors have now been have have converted to using these coding tools now. So you know pretty much all the entire engineering team uses them right now. and yeah, and it's been and so we we obviously we don't

completely just run it let it run wild and push it to production. Like our software has very high demands on reliability and sort of scalability and things like that. So there's always a human element to the reviews and everything. But I would say like, you know, seventy percent of the code is now written by agents, right? Like so it's quite a large percentage right now.

Brandon (34:38.65)
Yeah. Well, one thing I think, you know, we're talking about all the time with listeners on the show and at trade shows is just sort of like can anybody like can you still review like can you can a person like actually review all the code? 'Cause I mean it can be generated so quickly. So how have you guys figured 'cause that's like kind of the that's like what I think and I don't think there's a right answer here. Like I think everyone's kind of doing something differently. Sometimes like people have the one agent write the code and another agent review the code. And then sometimes people are like, No, no.

I review like this subsystem is super important. That's always manually reviewed. And maybe like I don't know, the colors on the UI, like you don't you're not as worried about. So like how do you guys like navigate that that challenge?

Arjun Iyer (35:21.185)
Yeah, so we actually dock food Cygnadot itself, which is excellent for that use case. so for our PRs, like of course we have these agents review the PRs, like we they go through the first round of reviews there, which is you know very useful. but then we also run sandboxes on our own code, right? Like so we actually run sandboxes on our own PRs and run the whole end-to-end like verification suite and the results of which are posted on the PR itself. So

Brandon (35:24.934)
Mm-hmm.

Brandon (35:39.993)
Okay.

Brandon (35:49.893)
Okay.

Arjun Iyer (35:51.342)
So yeah, I think over time I'm seeing lesser and lesser need to review the code line by line. and and also it's also a psychol what we realized is it's also a psychological thing for developers. because if the developers know that this is agent generated, they don't want to review that code too much. It's kind of funny, yeah. They don't. They they feel like, yeah, they they're like, this is bot generated, why should I

Brandon (36:12.525)
Really? Okay. They yeah, that I'm surprised, huh?

Arjun Iyer (36:18.787)
waste my time reviewing this code. Like it's just like it's not the ideal thing. I don't want to encourage that, but that's what is happening. Like that's what I see in my team. which is like you know so so I'm like, why should I go up against the tide, right? I would rather make it easier to do other things. Like, you know, maybe use sandboxes more and sort of like get that validation thing done automatically rather than have my developers go and review line by line of code. Right. So I think it's more

Brandon (36:26.564)
Interesting.

Arjun Iyer (36:48.885)
Shifting towards can I see a preview? Can I see what are the validation tests that were run on this PR rather than me reviewing like line by line, right? So yeah, exactly. Yeah. So that's kind of where I see, yeah.

Brandon (36:57.242)
Right.

Yeah, so it's more about looking at the tests, right? Like making sure the tests are actually okay, it makes sense. All right, well, that's cool. That's Yeah, well that's that's interesting. I think that's a really interesting observation about like not wrong. I kind of see it though. So well let's get back to kind of you know, the Cigna Dot story here because now it kind of makes total sense, right? Okay, so now I'm a developer. I'm using my favorite coding agent. You know, for me that'd be Claude. So I I sit down in the morning, I do my I I set Claude off and it's doing the work. So

Do and you mentioned this earlier, but let's maybe kind of revisit it. So you said there's like an C P server. I guess there's an C P server for Cygnadot. Are there skills for Cygna dot? So like what is the A how do you how's the integration between a coding agent and a Cigna dot and Cygna dot different? How does that all work?

Arjun Iyer (37:43.608)
Yeah, so we have both. we have the MCP server as well as skills that tell the coding agents how to use Cygnadar, basically, right? So it's a very slam-dunk thing. you just install that MCP server configuration in whatever coding tools you're using, and we support all of them. and then you install our skill, which is a standard skill that all the agents support now. so that tells the agent.

How to you know how to use the CLI, and how to even download the CLI, how to use it, how to create all the commands that the CLI exposes, how to create sandboxes. we also, by the way, apart from sandboxes, we also have validation infrastructure that is built on top of sandboxes. So this allows like agents to we call it we just released it calling it's called Signorot plans.

And what that does is it teaches an agent how to write a small mini workflow that validates the code that it's written, right? So a a quick s a simple workflow would be like I've written some code, write a playwright test that will test exercise this code all the way from the front end, right? So you know, like a front end running on staging. and and then we take care of the routing to the local box and everything, right? So that it just works out of the box. So

Brandon (38:58.147)
Okay.

Arjun Iyer (39:07.725)
The superpower the agents get now is that they can close the loop. Like remember I said software development is all about loops, right? Like it's all feedback loops. Now the same loops apply to agents, right? And the more faster the loops are for the agent, they can actually run autonomously for a longer period of time. So imagine a cursor agent or a cloud core agent that not only writes that code, but also runs like a whole bunch of validations before a developer has to even take a look at it.

Brandon (39:14.49)
Yep, yep.

Arjun Iyer (39:37.912)
Right. So now it's running like you know previously it would have said, I ran my unit test, it works fine, I'm done. Right. now it runs for longer and it runs end-to-end tests. It could run based on the code changes, it can also decide what tests to run. So that's where the intelligence comes in. because the plans have some metadata about when it's relevant, like when should you run this plan or this test.

Brandon (39:44.505)
Yeah. Mm-hmm.

Arjun Iyer (40:04.555)
so the agents can be smart about it. Like based on the code changes that I made, I have a suite of like say thousand plans in my repository, but I only want to run 50 of them. Right? For this code change. So the agent is doing all of that. It's running end-to-end tests, it's running plans, it's running a security test potentially. If it finds that there's some security impact of the code change, it may it can also run performance tests, it can run other kinds of tests, and then it says.

These are the tests I ran and it tells the developer, okay, I'm done now. And these are the all the things that I ran to make sure that this is like verified code. It's not just like code that I generated, but it's verified against the realistic environment. And now I'm ready to push a PR.

Brandon (40:40.889)
Right.

Brandon (40:49.561)
Got it. Got it. Okay. So that's really interesting. So how I guess you know, it 'cause you said long running, and I think that's like become like a bigger and bigger question is like how long and how autonomous how this kind of funny question. How autonomous is an autonomous agent? So so in your situation, I could see it as sort of like, you know, you start with like a requirement and then you tell it to like do the thing. And then it's like, are you getting to the point of like it'll like do the inner loop, basically it would test it locally, then d and then on its own, can it then say, okay.

Now I want to do I now I'm ready to actually, you know, stage this and do the kind of start to do some of the outer loop stuff. And then if it finds an error, is it actually able to like open open its own request, fix its request, and then go through the cycle? I guess I I guess that's the question I'm asking is like how many loops will you let this thing do on its own versus like you know, the developer has to come back and be like, okay, I'm I I gotta get back involved here. Like how does that all work?

Arjun Iyer (41:42.937)
Yeah. Yeah, that's a very good question. And and it's all depends on the goal, right? Like so a developer can like you said, you mentioned spec driven, so you write a spec of what I want it to do, right? And there I can say do this until all these tests pass. Right? So it'll keep iterating. When the test fails, it'll debug why it failed.

Brandon (41:47.813)
Mm-hmm.

Brandon (41:53.444)
Yeah.

Brandon (41:59.949)
Okay. Mm-hmm.

Arjun Iyer (42:06.626)
Because it can look at logs and it can look at like, you know, it has all the information through Signadot. Like it can look at logs of the sandbox, it can look at logs of the other services. it has all of that to at its disposal. So it can actually debug why the test failed and then go back to again fixing the code and then rerunning the test. And it continues to do this in a loop until all the tests pass.

Brandon (42:06.937)
Right.

Brandon (42:29.775)
Okay. Okay. So it's really I guess it's your willingness when you guys like, you know, what is it like when you run Claude, like you have to give it the extra like dangerously, you know, like keep going. Like don't don't keep asking me to go. So you so is that kind of the way you is that how your developers are doing or how you see people doing is like, okay, you know, give it a a good spec, you know, give it the permissions it needs and like let it go for a couple hours. Like I don't I or even let me a better question is like, how long do you see these agents actually running autonomously?

Arjun Iyer (42:37.592)
Yeah.

Middle.

Arjun Iyer (42:59.916)
Yeah, I mean, right now it's you know, we haven't pushed it to hours, but I definitely think it can go there. Especially especially if the feature is a fairly meaty piece of functionality, right? Like if it's a a major feature that's landing or something like that, I can definitely see it happening. because and that's kind of comes back to the original point of the inner and outer loop, Brandon, where

Brandon (43:26.938)
Right.

Arjun Iyer (43:28.898)
This blurs the lines a little bit, right? So that's what I see happening. because now I'm not so sure like what is inner and outer anymore. Because it's all agents, right? Like I I'm not in even involved. Like, so I don't care. Like, you know, as long as it runs whatever it needs to run, and then finally I get a PR, I'm good with it, right? Like so and so that's sort of blurring as well. Like, you know, what is inner and what is outer. And and that hand in goes hand in hand with how autonomously these agents run. Because

Brandon (43:36.867)
Right. Yeah.

Arjun Iyer (43:58.232)
If I if it can run for hours, it might as well do all the regression tests as well, which are typically done in the outer loop. Right? So the agent itself can be smart enough to decide on what how it sequences the test or the validations. Because initially it might do like the faster test because it just wants to see, does the code work? Right? It's more functional, right? and once it passes there, it can now start to see like, okay.

I need to now make sure that I this hasn't regressed anything. So now I start to run the regression suites, which may take like maybe even hours. Like I don't know. It depends on the complexity of your software, right?

Brandon (44:35.042)
Okay. Yeah. No, it makes sense. No, I I really like I mean my in my head or I'm just thinking to myself, it's it's like the metaphors like, okay, agent, I gave you I told you what to do. Here's here's how you can create all your virtual environments or sandboxes, sorry. Here's how you can create all the sandboxes. It's like go do your work and like call me when it's done. Right. It's like I don't, you know, I don't I don't care. Like you just do what you need to do. And if you yeah, either call me when you're done or call me when you're like you're out of ideas and you just like you're you're stuck, right? So okay. So we'll let's walk through like

Arjun Iyer (44:52.588)
Exactly.

Arjun Iyer (44:59.47)
Yeah.

Exactly.

Brandon (45:03.576)
You know, just pick any anyone that you think is interesting. Like who's a good case study? You know, what did they do? Like what, you know, kind of the classic, what'd they do? What kind of value did they see? What's a good one, just a good story that people should hear?

Arjun Iyer (45:18.183)
yeah, I think Brex is a pretty good story. I think they represent, you know, a fairly forward looking team that is very proficient and you know very sort of like they really prioritize shipping fast, right? That's kind of the whole thing is is about being agile and being being very fast with software development. And previously, like before you know, Cygnadot.

they were actually again they ran into this environment bottleneck problem, right? So, okay, I'm having like they have like hundreds of microservices, right? Like it it's it's a fairly complicated fintech solution. And so they started to actually create like the full stack environment model where they they would spin up like a whole environment in Kubernetes, like a whole namespace with all the components in it for every PR, right? And it got to a extent where

Brandon (46:13.252)
Okay.

Arjun Iyer (46:15.713)
It became insanely expensive, it became insanely slow, and developers stopped using it, right? Because it's just so too slow. They'll bypass that and go directly to staging. So so that didn't work for them. So then once I implemented Signadart, it was a massive improvement for them because not only were they able to save amazing amount of cost because they saved like more than two million and in just cloud spend per year, right?

Brandon (46:24.782)
Right. Mm-hmm.

Arjun Iyer (46:45.275)
but they were also able to completely bootstrap or sorry completely supercharge the developer cycle. Like you know, now they can have code that's sitting locally go to production like within literally within minutes, right? So so that was the real unlock for them. Is not only there was a concrete ROI on infra cost savings, but also the developer productivity change that they saw.

was the real kicker, right? Like that was the real kicker for them because they were so honed in on that. And generally what we see is an engineer can save like between five to ten hours a week by using our solution. Which is which is pretty huge, right? Like so yeah. Yeah.

Brandon (47:26.914)
Okay. That makes sense. Yeah, and well it's definitely compounded that. So it's really it's kind of what you said before. It's the more pain you are in having velocity and the more pain that that's coming from like not being able to basically run in an environment that's accessible is is that's that's the customer that should be coming to you, right? That's the person that that they're really gonna do it. So let's talk a little bit about, you know, everyone wants to know a little bit of licensing and pricing and and deployment. So just give us a quick overview, like how much does this cost? How does it work? What do I

What do I need if I'm interested, what sh what kind of budget should I be thinking about?

Arjun Iyer (47:59.78)
Yeah, and so we have two tiers. One is the like we have three tiers. One is a free tier, so anybody can come in and sign up and start using Cygnadot without any cost and it's free forever. It's not like a free trial period or something. So there's a free tier. it caps the number of sandboxes you can create, but it's free. You can just come in and start using it. And that's what I would encourage everybody to start at. you know, just come in, sign up on our website and start using the solution and

The pricing is based not on users, because we don't have seatbed pricing, is based on usage, right? So the number of so it's very aligned with the value you're deriving. So you can have like hundreds of developers sign up and start using on day one. it's it's not charged based on users. we charge based on the number of sandboxes you create per month, right? So that's kind of the usage metric, is the key metric. We also have a few other dimensions of pricing, which is like for example for the local

Brandon (48:35.94)
Okay.

Brandon (48:49.71)
Okay.

Arjun Iyer (48:58.525)
development use case, we call them dev boxes. So wherever the agent is running, that becomes a dev box. And so we price based on total number of max concurrent dev boxes that are connected to Signadot. So that is the pricing on the dev boxes side. And the third one is the test executions. Like I mentioned like plans and we have jobs also as another way to package the tests that you have. So these are charged based on the number of runs.

that you have and these all run within your Kubernetes environment, right? So so we have three dimensions of pricing. Not all of them are required to be to use Signadart. some people use only sandboxes, some people use sandboxes and dev boxes, some people use all three. Right. So it's sort of you can pick and choose.

Brandon (49:44.194)
Yeah. Well, it makes sense. I mean, I like the idea of sandbox pricing because it's just directly related to like if you use it a lot, you know, there's value. And if you don't, then it's like, okay, well, you know, it's not you're not paying. So what's great? Okay. So I'm definitely going to include links to CygnaDot and the the the for the trial so people can sign up for that. but if people were interested in maybe talking to you personally or talking to CygnaDot personally, like where should they go? How can they find you online?

Arjun Iyer (49:50.67)
Yeah.

Arjun Iyer (50:08.771)
Yeah, I'm on LinkedIn. so you can hit me up on LinkedIn. I'm on X and as well. So, you know, LinkedIn and X are the best places to hit me up. or you can send me an email, Arjun at Signadot.com. you know, I'm happy to receive emails and I'm super excited to engage with folks that are interested in this. e irrespective of whether you want to buy the solution or not. Would love to have conversation if you're passionate about this domain.

Brandon (50:37.048)
Well, fantastic. All Well, I've learned a lot. I feel like I now get it. I know I I know where to get my sandboxes when I'm deploying. Actually when my agents are deploying. I shouldn't I shouldn't say when I'm deploying, when my agents are doing. So Arjun, thanks a lot for coming on the show today. I really appreciate it.

Arjun Iyer (50:51.947)
super excited. Yeah. Thanks for having me.

Brandon (50:52.184)
And

And for everyone else, if this is your first time listening to Software Defined Talk, then welcome. You can probably subscribe right now in your podcast player. Go to software defined talk.com. There you can join our Slack. You can follow us on social media. And if you want a software defined talk sticker, just send me your postal address to stickers at software defined talk.com. I will be happy to send you one anywhere in the world. And with that, thanks for listening and we will talk to you next time.