Subscribe
Share
Share
Embed
The development world is cluttered with buzzwords and distractions. Speed, focus, and freedom? Gone.
I’m Nicky Pike. And it’s time for a reset.
[Dev]olution is here to help you get back to what matters: creating, solving, and making an impact. No trend chasing, just asking better questions.
What do devs really want?
How can platform teams drive flow, not friction?
How does AI actually help?
Join me every two weeks for straight talk with the people shaping the future of dev.
This is the [Dev]olution.
DaShaun Carter (00:00):
Great companies aren't always built on the best technology. They're not always built on the best idea. The best idea rarely wins. It takes more than just an idea and takes more than even the execution of an idea. You got to have the whole package.
Nicky Pike (00:16):
This is [Dev]olution, bringing development back to speed, back to focus, back to freedom. I'm Nicky Pike. Okay, so everyone's talking about AI shipping features. Agents are writing code. Agents are opening PRs. Agents are replacing junior devs. But the one thing that nobody's really talking about that much is that the most valuable thing an agent can do for you isn't writing your next feature. It's quietly patching your CVEs at 2 AM while you sleep. The real coworker isn't the one that's shipping flashy demos. It's the one that's doing the work that nobody wants to do. With me today is DaShaun Carter. He's a Spring Advocate at Broadcom, co-host of Spring Office Hours, and he's a guy that I owe a real personal debt to. When Nick Koon and I were first sitting on the idea of Cloud Foundry Weekly, we were overthinking it. We were planning it to death.
(01:04):
DaShaun got on his laptop and he burked our first live episode for the following week. His exact line was, "Just jump in, you'll figure it out and you'll get better as you go. If you try to plan too much, you never actually get off the ground. He wasn't wrong. He was one of my favorite humans in the world. He lives what he calls the N‑minus‑zero life and he runs a 104‑Raspberry‑Pi cluster on tour and he has very strong opinions on continuous patching more than anyone else I know and we're about to find out why. So before DaShaun and I jump into this, here's the challenge on the table. Meantime to remediate a critical vulnerability in complex enterprise apps is over five months. Of the CVEs that got exploited in Q1 of last year, more than a quarter of those were weaponized within 24 hours of disclosure.
(01:49):
And then we had things like the Shai Hulud worm that just spawned 25,000 malicious repositories across 500 developer accounts in a single weekend. We are losing this race by years and our answer so far has been patch faster. So what if we're asking the wrong question this whole time? What if the answer isn't just a faster human, it's an agent that never stops working and that's where we're going. DaShaun, welcome to The [Dev]olution, my friend.
DaShaun Carter (02:13):
That was a great introduction.This is cool. I'm going to meet this DaShaun guy. He sounds like it's pretty fun, but everything that you talked about, those are my favorite topics. If I was to say, "Hey, what do I want to talk about today?" Boom. There's the five favorite topics. Patching, what are agents doing? How can you use agents the right way? How do we handle all the things that are happening in the ecosystem right now?This is exactly it and my Raspberry Pis.
Nicky Pike (02:37):
You got to talk
DaShaun Carter (02:38):
About the Raspberry Pi
Nicky Pike (02:39):
Army.
DaShaun Carter (02:39):
The passionate hobby side project where I learn a lot there. So yeah, it's a great day.
Nicky Pike (02:45):
It is always a great day, especially when you're getting to talk with DaShaun. And for everybody that's watching, I know a lot of people are going to know DaShaun, but he is the most charismatic person I know. But before we get into that, I want to give you a chance to tell the audience exactly who you are. You have this path from where you started to Spring advocate at Broadcom and you get to, I want you to explain this whole N‑by‑zero life thing because that is the most DaShaun phrase that I've ever heard and I think people need to know what it means.
DaShaun Carter (03:11):
I started a web hosting company. When HTML was a thing, I was in school and I started making webpages for local school clubs and stuff onsite at campus. But then I had a couple of commercial customers. I started that company when I was in college and yeah, eventually I think it was maybe 2000 I got hacked for the first time. I found out about the Red Hat Package Manager and how to patch things automatically because that's the whole thing. I left something unpatched and yeah, lo and behold, one of my co-located servers got hacked. But I started this company and it was kind of always a side project up until about 2008 when the whole dot‑com collapse or the financial collapse happened. But at one point I was hosting 20,000 domains in my basement. But this is on top of my day job doing cool things and I've worked at ad agencies like boutique web shops, security focused companies.
(04:07):
And then even I worked at Garmin for six years, worked on Garmin Connect, learned a lot there about like kind of enterprise Fortune 500 global scale. Yeah. And then from there I went to a startup. I was the VP of engineering and in that role I cared about everything. In the small startup, you wear many hats, but I had to wear the infrastructure hat, make sure that apps had a place to go, make sure my developers had a path. And I also had to worry about the apps. So it was everything from the apps to the infrastructure that was all kind of under my umbrella. And from there, I went to a company called Pivotal. I was a happy customer at that point in a role that I was very uncomfortable in. I'd never been in sales before and I was kind of in that spot.
(04:49):
I learned a lot. That's where the growth happens is when you're uncomfortable. And I learned a lot in that 845 days at Pivotal about learning how to learn, being uncomfortable and kind of thriving in it, getting the best out of it. From there, I went to Redis telling the data story, which was fun. And then I came back. I came back to VMware, which got acquired by Broadcom and that's where I've been for like 150, 70 or 80 days. And it's been fun. Every single day has been fun. Yeah, it's kind of a dream job. I never would've thought that I'd get to do the things that I'm doing right now, but yeah, it's fun. So Spring has been a part of the story the entire time. These Raspberry Pis became part of the story in like 2017, 2018. Yeah, my Dell R710s, all of the big enterprise grade infrastructure, that's kind of disappeared.
(05:39):
And now it's being replaced by Raspberry Pis and NUC‑style boxes. And yeah, I love what I do.
Nicky Pike (05:47):
A couple things there. So first, I love the fact that you measure where you're at in days. Most people say, "I've been there for four years." You're saying I've been there 1,500 days, whatever that may be. I think that's great. The other thing is, you talked about Pivotal. I think with Pivotal, everybody talks about the seven degrees of separation from Kevin Bacon. We're starting to see that there's a seven degrees of separation for Pivotal companies. It was so influential on platform engineering and cloud services. I find that very interesting. Now the one thing that I want to try to embarrass you about a litle bit here is you left out, you kind of carried the headline on one of the things when you were in college and I want to see if I can embarrass you because nobody has ever left a speaking engagement that had DaShaun talking and left not jazzed.
(06:32):
I think that comes from, because when college, you were a cheerleader, you helped change cheerleader. Did that influence the ability for you to jump in and be this charismatic or is that just a natural thing that you did because of your personality?
DaShaun Carter (06:43):
So I think my personality is I'm still introvert. I'm still awkward in social situations, but I've figured out how to turn it on for cheerleading. I have fun. It wasn't work to go out and have fun, to go out and yell for the team and to throw the girls around. That was fun. So it wasn't really work. And I think that's the part. I don't know that there was a whole lot of skill or training on getting in front of big audiences. It's the stuff that I do, the stuff that I present about, I'm lucky in that I get to present about the stuff that I love. So yeah, maybe the cheerleading helped, but I think it's just that I'm lucky to be doing the stuff that I'm passionate about and that's the way cheerleading was for like 20 years of my life and now my kids are doing it.
(07:28):
So yeah, it might have something to do with it, but I'm passionate about what I do and I do say I am jazzed to be here. I'm lucky I get to hang out with you. This is part of my day.
Nicky Pike (07:40):
Yeah. And we're going to make sure that we link to your website because I believe you're still tracking all your talking events. If nobody has ever got to see DaShaun talk, if you've never got to see him see a demo, you are missing out. So we want to link to your website so that people can look and see where you're talking more. And I think on that line, we're going to go ahead and jump into the questions now. But you ran a live demo recently where you upgrade a project and you check the CVEs afterwards. Now normally you go from like 290 CVEs down to zero, but on your most recent run, you got to four. You said it was the first time that you ever didn't land at zero. Walk me through the moment. What did that one demo tell you about where the industry is actually headed right now?
DaShaun Carter (08:20):
It's wild. My demos are about Spring. Spring just comes out with new releases all the time. And that demo, maybe it was two weeks ago on a Thursday I do these upgrades and I never really know where it's going. And some of the times, actually several times over the years, while I was doing an upgrade in front of an audience, I realized, oh, there's a new Springbook version. I didn't see it from the blog. I didn't see it from the announcement on Twitter. It was because I was doing these upgrades and because I do these upgrades so often, that's how I find out about the new versions. And what's interesting there is the way that the Spring team or most open source, they actually usually release the patch before they release the announcement and that's what I was finding. I was getting Spring Boot 4.0.6, latest version.
(09:07):
I was getting it before the blog posts got released. That's awesome. So I was. There was no other way for me to find it, but my automation found it because I was doing it so often. Now doing it in front of a customer and expecting to see a zero and seeing a four instead, that's a little bit unnerving, but it's happened more since then. I had to explain like, "Hey, here's the difference. What are those four CDs? What are they? How new are they? " Well, of course they're brand new. They were days old and you get the explanation that they weren't part of Springs issues. They were the third party libraries that Spring rings in. And with software today, a lot of it is we're gluing things together. We're depending on, we don't want to rewrite everything. We want to leverage so we can get to production faster.
(09:52):
So that's why we have this massive ecosystem. Java's ecosystem is amazing because there's pretty much something for everyone to do and you just have to understand. But what's interesting, I'll say in the last two months where some customers were comfortable saying, "Oh yep, it's under the Spring umbrella. We'll get it in the next release." If it's high importance, it'll come out faster, but some groups were comfortable waiting for the next Spring boot release. Some are not. Some groups said, "No, I want to go and grab the patch of that third party dependency. I want to pull it into my dependency tree and when Spring Boot fixes it, when Spring pulls in that version, then I'll re-update." And that's wild. I understand things are moving so fast. You talked about the worm. I've been talking about Copyfail this week. The scale at which we're getting these kind of mission critical, high risk issues is never going to slow down.
(10:50):
The bad actors have access to just as much compute and power as everybody else and they want to eat too. So now that things are out in the wild and we have all this compute and all this technology to go and poke holes, it's being used. So the days where we could say, "Oh, we'll patch it in 15 days or 60 days," those are dawned. You will not survive. If you're today thinking, "Oh, I'll patch it in 15 days." It doesn't matter if it's a one or a seven. If you're waiting 60 days to patch, you're not going to survive because the bad actors are putting together that one CVSS score with this three CVSS score, they're putting part of the payload here and the rest of the payload over there and it's going undetected. That's the big change is like you can't say, "Oh, it's just a three.
(11:36):
We're not at risk."That's not an option anymore.
Nicky Pike (11:40):
It's not how CVEs work.
DaShaun Carter (11:43):
It's not. It's not. So yeah, low risk.
Nicky Pike (11:46):
I mean, I want to sit on that number with you for a little bit. So five months and 10 days when we look at the averages, that's the average that it takes an enterprise to remediate a critical CVE in an app, five months and 10 days. But we're seeing some of these CVEs, they're weaponizing these within a day, within 24 hours. For enterprises, that math doesn't math for them. And to your point, you can't wait that long. Where's the breakdown happening there and the fact that is it just people saying, "Oh, that's a three. We're not going to worry about it. " And then they find themselves on the front page of the news or is there complexity there that is causing people to take that five months and 10 days to try to patch something on average?
DaShaun Carter (12:24):
I don't know what those conversations are like or what they've been in the past. I know that's the way we've always done it. If you're as old as some of us and you've been doing things since the 90s, yeah, that was actually pretty good. If you're patching things in five months, you're probably ahead of the curve. We did the whole uptime thing. How long have we been up? And that now is an inverse, right? Your uptime is a bad signal. So the change is we're having to repave, rotate things a little bit faster and it's continuous. It's not a, we're going to set a time, set aside some resources and amount of time for this sprint to do tech debt and to do patching. That's not the way it works. That can't be the way it works because you'll never have enough people to handle it and there's only going to be more software going to production today.
(13:21):
The amount of software that we're delivering, I've been stuck on this and I'm still a big believer in it. Somebody said in 2026, in the year 2026, we're going to have more software delivered created than all the years combined before across the world. We're going to have more new software in 2026 than all the 80 years before. And I tend to believe it. If I look at GitHub, I look at GitLab and I see all the new repositories and I can watch just even my feed, the people that I'm watching, how much new software is being delivered. It's wild. And if you think you're going to set aside time once a quarter or once a sprint to go and handle that, whatever number you had before needs to be quadrupled. However much time you're assigning to that needs to be quadrupled and it's not enough.
(14:15):
If you got impacted by one of these supply chain attacks or the Linux kernel issue, the bigger your company, the more work you have to do, the more software you're building on top of, the more work you have to do. So it has to be continuous and that's the big change. So I don't know what the conversation is like right now, what those teams are saying, but I do kind of hear the trickle down to where we love it, just like you said in the intro. We love that we've got something that's continuously patching, giving us a pull request to say, "Hey, here we can fix this thing. We've handled it for you. " Not a CVE to say, "Go fix this, but here's the patch."
Nicky Pike (14:53):
Well, on that same lines, I mean, we looked like Shai Hulud, that was something that came out here recently and that wasn't caught by traditional security tooling because it was doing things, it looked exactly like an NPM package doing what an MPM package would do, right? It had pre-install scripts, it was ex- filling credentials to public GitHub repos. So paint me the picture of what that fundamentally has to change about how packages are getting pulled into a build because clearly what we're doing isn't working.This resulted in like a $4.5 million theft. It disrupted the internet for a while, but security tooling wouldn't catch it. It's not something that I think just patching would have fixed. What are your thoughts on that?
DaShaun Carter (15:34):
Maybe not like the most positive. I feel like the security ecosystem is ready for a change. It's been ready for a change. There's a lot of tools that do a lot of the same thing and they do it part of the way, not all the way like scanners. A lot of the scanners that you buy, they're scanning OSS, but they're not doing the same type of scanning for the stuff that you build. A lot of the companies, customers that I work with, they have built more software in‑house than what they buy off the shelf or what they're pulling down. The amount of code, probably 25 to 75, but there's a big footprint of code that they have built. It's their IP, it's their stuff that is not giving any of that scrutiny. But for the vendoring side, for the OSS side, things are changing and there's been some movements about how we handle things.
(16:26):
Some of it was hiccups in some of the trusted infrastructure. They're not all the same, but I think that that's going to change. That's my take. It's things are changing. If you're using an NPM, that's been kind of a hotbed attack surface for a while. This isn't new, but yeah, we're figuring it out. We're also now having to figure out, are they human or are they agents? We're also having to figure out ... Because now some of these attacks aren't one person doing a bad thing. They are coordinated. They're month long like, "Hey, we're going to go attack this one project. I'm going to be fake persona over here, fake persona over here." And they're doing these coordinated attacks. It's not trivial. It's not something that just something off the shelf is going to be able to figure out. Everything that we do is going to have to change.
(17:13):
The level of scrutiny that we provide or that we use is going to have to change. And some of the good things that I see are like signing, right? Even the Spring team made it easier for developers to contribute. So that's a big thing, but having the checks and balances, having that off and that providence trail, that's important. So things like signing your packages, signing your commits, all of that stuff is kind of trending in the right direction. I don't know what it's going to look like, but also in the Java ecosystem, not as much risk. We have for several reasons there's not as much risk. The way that things are being published to places like Maven Central and there's other repositories that I'm pulling in that don't have the same scrutiny, but yeah, the ecosystem for whatever reason has done a little bit maybe better job of self-governance, but still in today's day and age with agents doing what they're supposed to be doing, things are going to change, they're going to have to change.
Nicky Pike (18:12):
So I've been hearing this kind of quiet rumbling because of AI. So to your point, you said it earlier, we don't want to have to rewrite certain things. We've got libraries, we got dependencies, but those are now, that's a supply chain that you've got to keep up with because when you look at a Spring project or Node, right? Node is another one of those where you build a Node project, you're bringing in a whole bunch of dependencies as part of that and you've now got a supply chain concern on what you're seeing. I'm starting to hear these kind of quiet rumblings that some developers are looking back and saying, "Well, with AI, I don't really care about the fact that I need to type these dependencies out again. I can type a hundred times faster than I used to. AI is going to know about what some of these dependencies are.
(18:53):
So why not just bring that in a source code rather than packages and I can kind of skirt that dependency tree that we've got and maybe skirt some of these supply chain concerns." What is your feeling on that? Because I see a benefit there, but I also see a whole lot of risk when it comes to that.
DaShaun Carter (19:09):
I'm going to say I'm a lazy developer and I want to get to production. I want to be maintainable. I'm going to say that the number one most important thing for software today from my perspective is it's maintainability. So if you're a developer saying, "Oh, I'm not going to include that package. I'm going to grab the source code. I'm going to put it into my repository and I'm going to maintain that on top of everything else," that's a red flag. You're not going to do anything. How many packages are you pulling in? How many things are you now going to maintain? Those frameworks are there for a reason. They're there to make your life easier. And part of the open source ecosystem, part of what we're doing is teamwork makes the dream work, right? When I have a bunch of people using the same framework, we're all worried about its security and getting.
(19:55):
So we all want to contribute and fix things and make it better so that we don't have to maintain it ourselves. We can all take advantage of that win, that shared community win, like hashtag Spring. That's a big benefit. So for me, this idea of, "Oh, I'm just going to pull it in or I'll write my own." I've seen it, I've seen it fail and that's part of the just experience of living with this over time. You don't want to be rewriting everybody else's software, whether that's open source software or vendor software, right? You want to buy something or pull something off the shelf so that you can do what's important to your business and your business value faster. That's the main thing saying that, "Hey, I'm taking care of the security for all these things." I look at that kind of the same way as I do Docker files, not to poke fun at anybody, but I don't want to be messing with my own Docker File, even though that's what I'm doing today.
(20:44):
I don't want to be dealing with Docker files. I like BuildPacks. I like to know, like for this Copyfail thing, I like to know that I can just go and rebuild my BuildPack, restage my app and I've got the latest patched Linux kernel. That's a big benefit to me. But if I've got a bunch of Docker files that I've got to manage, I've got to go and catch those because that's not adding anything to my business value and that's an important piece.
Nicky Pike (21:07):
So you're describing friction at scale at that point, right? If you've got to go in and patch Docker files, if you're using AI to rewrite instead of bringing independencies, you're talking about friction at scale. Now I've just increased my friction. I have to keep up with when vulnerabilities are coming in rather than letting somebody else. So in your take, if I'm hearing you right, using package managers, bringing in those dependencies, the juice is kind of worth the squeeze on that. When it allows your lazy developer, it allows somebody else to keep up with that. Yeah, you still got to pay attention, but it goes back to your N-minus zero, right? Lifestyle. We want to patch everything. Yep.
DaShaun Carter (21:40):
That's the thing. So in Spring, I kind of have a cadence. I know when to look, but when you're in the Node world, NPM packages, those are happening all the time. The release cadence is a bit different, but I still ... And even with all the things that have happened in supply chain management, I still want to take the latest version. I don't want to sit on N-minus two or N-minus three and know that it's exposed. I want to be on the last and greatest. I want to be in the news. A, if there's a risk, I'm on the last and greatest, I want to know if I'm at risk. I got to be paying attention to all of those vectors, if you will, but I want to be patched, not just for the security, but also for the performance. I'm part of this open source community as well.
(22:22):
I want to use the ladies and greatest to come up to you and say, "Hey, I love that thing that you made four years ago. I know you've made a new version, but I'm using the one from four years ago. I love it. It's great. Can you backport something to this version that I used four years ago?" Nobody wants to do that. Part of being a good consumer, a good member of this open source community is using the latest and greatest, giving your feedback on the latest and greatest. That's valuable. And if we're all paying attention to the security and we're all trying to drive business value, if we could all just kind of spend the same amount of scrutiny that we do on the open source that we do on our internal stuff, like do run it through the works, run it through your tests, run it through your scanners, run it through your security focused LLM and find the holes.
(23:06):
And when you do find the whole, yeah, report it, but do it the right way. Be nice about it. Don't say, "Hey, go fix all these things." Yeah, show your evidence, do your examples, your repeatable example and then submit it.
Nicky Pike (23:19):
Well, and on the security side, I heard you say something the other day that I kind of laughed at. You were talking about you always used to make fun of banks because they wouldn't let their developers have code on their laptop and now you're like, "No, I absolutely want my bank keeping code off my developer
DaShaun Carter (23:34):
Laptop." Yes, I
Nicky Pike (23:35):
Do. What changed? What changed
DaShaun Carter (23:37):
For you?
(23:39):
2024, 2025, all of it. I understand I'm a developer and I like having use on my laptop. I travel. I bring my laptop everywhere. I'm doing things, but I work at Broadcom. I don't carry my work laptop. All those secrets that Broadcom has, any of the IP that I've got there, I'm not taking that onto the public. That stays very secure, that's under lock and key and I get it, right? I don't want to be the person that puts Broadcom at risk, but I don't want any of the developer friends that I work with to do that either. But the banks that I'm using, double, right? Everything that I've done up to this point, it's in your hands. I love the idea that developers have this secure place to do the work. I don't have to worry about code being taken to the park and being left on a laptop and somebody taken off.
(24:28):
I don't have to worry about that. For those banks, for those enterprises that are doing that mode, that makes me feel really good. On the other side, when there's a company and I learn that their practices aren't maybe at the level they should be, I can't name names, but I definitely, I stopped spending my money at those places. I want them until they get better, I haul back. And I often joke, right? And this goes for any developer. If you're a publicly traded company and they shared how you're doing development with the street, if the street knew how developer at Global 2000 company was doing work, would the street want to invest more money in your company or less? And just that alone is something that I think developers don't realize. It's the thing that I wish I could get developers to understand earlier in their career.
(25:34):
Marcin from Spring Team, he was Spring Cloud, he said it in one of his great tutorials. He would always say like, "Look, you have been hired to add value to the company. You have a job is to deliver value. That's our job is to deliver value. Anything else about resume driven or whatever else you're trying to do, your job is to deliver value to the company." And the way he said it, it really changed my perspective back in 2017, I'll say. And I wish I could get everybody to understand that because that is a focus. If you can be the developer that says, "I saved the company this much money, my time from CVE published to CVE patched is this. My average VM age is this. " If you can have those kind of metrics that are showing the value of the work that you're doing, everything else takes care of itself.
(26:33):
That is the biggest thing. So if you can be a developer and you could just sit and think, am I delivering value? Am I delivering value in a safe way? If the street saw what I was doing right now, would they want to invest more in this company or less? That goes for whether you're enterprise or a startup, those things matter.
Nicky Pike (26:52):
Yep. I couldn't agree more. Yep. We have defined the problem here, DaShaun, right? We've got CVEs that are coming out at a rapid pace. We've got companies that aren't patching them. That is against your belief. We've got code on laptops. So we've set the stage on the problem here. So let's start talking about solutions. And one of those phrases, one of the phrases that I've heard you say that I love so much is that you're a big advocate of shifting down, not shifting left and that's where you've landed and you get pretty fired up about this. So we've got most of the industry out there, they're still saying shift left like that's the gospel. Why is that dead? Why does shift down actually mean and practice to you?
DaShaun Carter (27:32):
So had tip to Richard Seroter, former pivot, now he's over at Google and he coined that term, the shift down, or he's the one where I'm quoting when I say it. Shift left, I liked that idea. When I was a developer, I was like, "Oh yeah, I can handle VMs. I can manage Docker containers. I can do that. Yeah, gift to me. If it's mine, I'll run it. I'll take care of it. " I think that came from Netflix, that culture of responsibility where they kind of manage their own stuff. They know how long it's going to take to upgrade, how much it costs the company if it goes down and I got it and I was cool, but not every developer is like me and I'm comfortable having all the things. I grab my Raspberry Pis and I deploy all the things, but there's a line in how much are you going to shift to the developers and still expect them to deliver value to your company because there's a diminishing return.
(28:23):
You grab a tool, you buy a thing from a vendor. If all of your developers aren't using it optimally, you're probably losing out and there's a lot of software that gets sat on the shelf, gets purchased and like, "Oh yeah, we'll have the developers do it, " but the developers don't have time to use it. There's tons of software that would, if it was used properly, it would add tons of value. Save tons of time. I believe it, but you've got to use it the right way. If you're not able to use it, if you're not able to use it and get your code to production, if you're not able to deliver that business value, what good is it? So the big shift is you've got to be able to use it at scale. Developers want to not mean time to remediation, developers want mean time to dopamine.
(29:14):
Developers want to be able to close things and know it's done and it's ready and it's gone and it's in production. I want to work on the next thing, but they need that loop and that's what they're driving. In order to keep a developer happy, they've got to be delivering. I think that's fundamental. I haven't done a scientific study on it, but that's from where I sit, that's the thing that keeps developers moving forward. And if they can use the last and greatest, that's fantastic too. If you can't do that, then they probably.
Nicky Pike (29:40):
Well, and it makes you wonder, was it the shift left movement that caused AI to be such a force that it is right now? People are looking to put time back in their day. Maybe it was the shift left and given developers way more responsibilities than what they really were intended. I know that a lot of developers are control freaks. They want to be able to have everything ... Thing the way they want it. But it may have been that whole ideal there that made AI become a thing and where people started looking for more productivity because they were taking on way too much work.
DaShaun Carter (30:09):
Absolutely. Here's the problem. In a nutshell, a lot of orgs, not saying everybody, but a lot of orgs, they shifted so much responsibility to the developer that they can't get out more than one ticket, one feature per sprint because there's so much work that they have to do. And you've multiplied that by all of your developers, that's a problem. You've shifted left to the developer and guess what? You've got a bunch of compute that if you had centralized some of those things, if you had made it easier for developers to actually deliver code and not worry about all the other things, if you could shift some of the work that you shifted to developers, if you could shift it someplace else. I say down to the platform, quoting Richard Seroter, I love Cloud Foundry, but all these things to the automation. And when I say platform, I'm saying all the things in between git commit and production.
(30:58):
That's all the platform when I say platform.
Nicky Pike (31:00):
Can it comprise multiple things, right? It could be not only that path to production, but also the development environment. If you can shift that down, if you can make not having to make the developers worry about what dependency versions are we approved to use, what is the OS? What is the stack that we need to use? If you can make that easy, and again, this is an old pivot statement, right? Make the safe thing the easy thing to do, that also counts. And those are things that we should be looking at when we're talking about productivity. If we can do those things and we bring AI on top of it, then we're all better for it.
DaShaun Carter (31:33):
The other thing that I've been saying is even if it's an agent, the happy path, the goal and path, if you will, for a human developer should be the exact same as a happy path for an agent. Those lines are going to be blurry. At least today, those lines are blurry. So my perspective, what I'm trying to do actively is I'm trying to move the amount of work that I'm doing on my laptop, the amount of code that I have on my laptop, even though myself is all OSS and public, I want to reduce the amount of actual code snippets, projects that I'm doing on my laptop and I'm trying to move that to the platform. I'm trying to think of like, "Hey, if I was an agent, how would I be doing this? " And that's I think kind of the hotspot. I don't know that everybody's here, but I've heard enough rumors about the developers that have five agents running all the time working on their stuff and they're just kind of like managing agents.
(32:26):
I'm getting there. I'm approaching that. But until I've got a place for my agents to run safely where I can be like, "Oh yeah, they're fine. They're Sandbox good enough and I can sleep. They're using the right versions. Until I've got that, I'm not going to be comfortable. That's what I'm driving for. " And I think enterprise down to startup, I think that's where things are going. I think this idea of having a nice place for agents to run, a nice place for agents to have the connectivity that they need and only the connectivity that they need to be able to communicate back and forth, I think that's where things are going. This coordinated swarm, if you will, it seems powerful. Even just me doing my side project, it seems like it's doable. And I've heard enough stories. I don't know how much I'm going to invest into the stories, but I've heard enough where it's interesting in what I see on that curve, what I can see from here is it's possible and yeah, I think it's worth pursuing.
Nicky Pike (33:23):
Yeah. Well, and that's another thing that I think is also very interesting is a lot of teams when they're looking at agents today, they imagine that the win for them is the agents writing the code, it's the agents writing the fixes. You kind of look at this a little bit differently. I mean, you take a completely different approach where you're saying, "No, the agents should be doing the things that I don't want to do. " Agents, rather than going out and making the fix, agents should be writing recipes for the fix. Fix a thousand repos at once. Use open rewrite, for example, as a force multiplier. Why do you think that's the right mental model and where do you se teams are getting that kind of backwards?
DaShaun Carter (33:59):
This is a very, very popular conversation. I get asked a lot like, "Hey, I've got these recipes that do all these things for me. I've got these agents and my agent is really just kind of a loop that goes and checks the repository. Are there any CVEs? Are there any patches for it to do? If there are, patch it. If there's any other work, I need to build a map or something, open the issue." So I've got an agent that's doing that across hundreds of repositories all the time. It works, but there's no real AI involved in it. It's just do the work, do the things that need it to be done. And because it's using open or rewrite, it's deterministic. I know exactly what I'm going to get across the hundreds of repositories, I get the same results. So when iteration two happens, I'm building off of a known baseline, right?
(34:44):
They all got patched the same way. When you're using AI to do your patching, one might do it this way, one might do it that way. You lose the determinism, you lose the maintainability at scale. Alibaba did a nice report on that and there's been several others since that where if you let AI do the upgrades, first of all, you're burning tokens. If you've got a hundred engineers, how many tokens are you burning just doing an upgrade? When you could just burn the tokens once to write a recipe to do it for everybody. Do that same upgrade the same way all the time and you don't even have to take it to production. You have access to all those repositories. So write a recipe, validate that it works across a hundred repositories before you push it. You can go and grab all the repositories and find, "Hey, does this recipe work?" If it does, great.
(35:30):
Then push it. Say, "Hey everybody, this works for all your repositories. Go." And that's efficiency at scale.
(35:36):
That's the efficiency at scale, but it's not just about the apps. I first saw the Azure SRE agent. This thing that's going to go through and look at your, what's their construct called? The resource group. Look at everything that's there, make sure everything's connected, make sure. Take a peek at the logs, take a peek at your metrics, to see that everything's working. Could I resize things? Doing that at scale. And now there's a project called OpenSRE, which is an agent that does the same thing, but not just for Azure. Go look at the logs. That's step two. I've got Cloud Foundry. It's got a nice API. I've even got Korifi, which also has a nice API where I can say, "Hey, agent, go look at these things. Go look at my logs, make sure my certs are valid, renew certs if I have to. Go look at my apps that are patched." Those are the two types of agents that are just running, that should be running all the time.
(36:22):
And because I have these LLMs available, I can do things like look through a bunch of logs, compact a bunch of logs, look for the deltas and analyze like, "Hey, am I being attacked? Are there any things coming through the hole?" This is where we should be. There's definitely people that are going to take care of that or they're taking care of it today. They're going to automate this stuff. And what's really interesting is what's next? What's the level above all the things that we've been doing in the past? What's the next tier going to look like? And for me, again, kind of straddling that app infra role, I want to make sure that my value line is going in the right direction. I have a sense that not a lot of people are getting more budget for bigger, more stuff most of the time.
(37:08):
I know we're having the data center conversation, but most developers are asked to do more with the same or less. Like, "Hey, I need you to add all these new features and I want you to add these new things, but I'm not going to give you any more infrastructure. Nope, you don't get any more cloud spend. You got to do it in the same amount, same budget we gave you last year. Is that okay? Cool." That's more common than not. So that's where I want to be. These are the kind of things that I want to say. Not only can I deliver this feature value, customer facing value, but I can do it for this much money. And that is going back to the, how am I going to deliver value? That's what I want. That's what I think the next tier is going to be.
(37:46):
Can I deliver value? How do I deliver value, not code value.
Nicky Pike (37:52):
Well, when you're looking at a lot of developers when they're looking at delivering value and they're starting to bring AI, AI is a thing. Everybody's starting to use it in some way, shape or form, some more than others. But I feel like there's a whole lot of reinventing the wheel here, DaShaun. I mean, people are going out and it's like they're discovering things that have existed, but they're discovering from the first time. A good example, Spring AI has had token tracing since the early snapshots back in 2024. So I mean, for these, people are going out and they're trying to figure out how to do this stuff. I know your answer is, we've got this in Spring AI, but tell people, what does that actually buy them versus just what most people are doing now where they're bolting AI into an existing setup?
DaShaun Carter (38:31):
So the whole recreating things with AI, I don't know if I said this already, but this week there was one startup that was doing things. They're burning a million tokens a day and they're okay with it. They're funded, they're going. And they realized like, "Hey, we could hire a human to do these types of things so that we could save on tokens." They realized that for some things a human is actually better than AI and they didn't just realize it like, "Oh, I got to ... " They posted about it on the social media. "Look what we've figured out. We figured out that humans don't cost as much as AI at scale. What is this? This is crazy.
(39:14):
"Oh, somebody discovered an employee. They discovered that you could have a conversation with somebody and humans can understand humans. It's amazing. So yeah, that reinventing is wild. The traceability, some things a lot of people are trying to plant their flag and like, " Hey, I've done this cool thing. "A lot of people are just trying to recreate somebody else's idea and a lot of people are creating new stuff. There's vibe coders everywhere. You've got a Claude or a Codex, you could do a lot of crazy things, but it all comes back to, hey, if you put that out into the world, you've got a domain and you put it out. Is anybody going to come? Great companies aren't always built on the best technology. They're not always built on the best idea. The best idea rarely wins. It takes more than just an idea and it tastes more than even the execution of an idea.
(40:06):
You got to have the whole package. If you can't market it and sell it and do it, your great idea is not going anywhere. So that's a big thing. And there's lots of people, " Oh, I got this great idea and this thing worked for me and I bet it could work for everybody else. If you can't sell it, then good luck.
Nicky Pike (40:20):
"Right.
DaShaun Carter (40:20):
Have fun. Well,
Nicky Pike (40:21):
And who would've ever guessed that human developers would be the bell-bottom jeans coming back into fashion and it's happening so fast. We're watching these iterations where it was just six months ago where we were having people, everybody's got to turn to AI. It's the only way to do things. Now we're seeing, well, hold on. Humans still do a better job. They don't cost as much. And I think that's one of the things that a lot of people are kind of ignoring right now in this fear. We've got FOMO, we've got to jump out, we've got to get this AI rolling because if we're don't, we're going to get left behind. But a lot of people aren't talking about money. I had a customer that, same thing. They had a million dollar agent bill because they had a loop that they didn't know about and they didn't see it until the invoice come in.
(41:02):
And you told a story about a developer who ran an agent from Friday to Monday and next thing they know they have a hundred K bill coming
DaShaun Carter (41:11):
In. One task over the weekend. Yep.
Nicky Pike (41:13):
Yeah. I mean, this is backed up by data. This is research. This isn't just people coming in and making these statements. Stevens Institute says that a reasoning loop running 10 cycles will consume 50 times the tokens of a single pass. It makes you wonder, are enterprises, when they're doing this, if they're not putting real thought around their AI strategy, are they kind of just lighting money on fire if they're not coming in with a good direction and strategy of how they want to utilize AI?
DaShaun Carter (41:42):
There's a big difference. I don't want to offend anybody, but like a lot of companies made this move to the cloud. We're just going to use their resources and hey, that's cool. And as we move and as we navigate, we have the ability to move fast. We can do things fast, but is fast, always necessary. What we've learned, what we've both seen is you go to the cloud for its agility. Sometimes it's scale. There's reasons for you to go to the cloud, but if it's money, that's not where you want to be. If you're trying to save money, you're not doing it in the cloud. I don't care how many years advance you do and how big of a discount it is. If you're trying to save money, it's not happening in the cloud. You bring those workloads back. The ones that don't need to scale to 20 regions across the globe, the ones that aren't doing rapid development and removing, pivoting every other week, when you've got something that you've built your enterprise on top of, that needs to be in a data center where it's affordable and your margins improve AI, I'm looking at it very similar.
(42:39):
Like, hey, if you're trying to do something fast, yes, use their stuff. Use your GPUs, you're going to get better tokens per second, but know what you're doing, know why you're doing it. For me, I don't have cloud money. I've got Raspberry Pi money. I'm going to use the agent. I do have a 50, 90. I'm going to use my stuff here. And if I'm running on the loop twenty four seven, good. My Raspberry Pis, they only cost like 10 cents to run twenty four seven for the month. 2.3 watts per hour or whatever it is. It's minimal, but I can use that 50 90 and I can do these loops and I don't have a $100,000 tile bill. My electric bill has gone up like $3 since getting that 50 90 and I'm okay with that. I can afford that. And I'm now constantly working.
(43:26):
I want to take advantage of that skill. I want to take advantage of the fact that the LLM's not going to get tired. If I, do it again, don't make any mistakes. Do it again, don't make a mistake. If I just tell us to do that, it doesn't care. It's not emotional. It's not trying to get to bed. It'll work. And I want to take advantage of that. I want to look at the value line. I'm trying to make it so that I can deliver as much value with the compute that I have. I want to deliver as much value as possible. All
Nicky Pike (43:52):
Right. But I see a litle bit of a contradiction to what you just said earlier we talked about. I do not want code on the local laptop, especially for my banks, but now you're explicitly saying, "Hey, I choose local compute over cloud. I've got my MacBook, my M4 with 128 gigs of memory, or I've got my Pi Army or a 5090 in a desktop." You're wanting to burn tokens on the hardware you own. So that seems like a contradiction to me. Make the case for why that's a real strategy and it's not a hobbyist flex.
DaShaun Carter (44:23):
I'm going to tell you because of the tokens, but at the same time, hey, I don't want it on my laptop. I want it on my compute. I want it isolated, secure. I want it to be running in a platform. I think that's me personally as Sean or as the next startup or whatever. I want these things to happen. I want to be able to take advantage of the compute that I have to the maximum potential and this token economy, that seems like a lose. I don't know that I can take advantage of the token economy at scale unless I'm one of the frontier models.
Nicky Pike (44:57):
And you're right, man, are becoming a token economy. That's one of the main things that we're hearing from the field when we're talking with customers is, one, how do we govern AI? But two, how do we really keep track of what we're spending? We can't budget on the fact of, well, we got to wait and see what the bill comes in. We've got to be able to put quotas and limits. Everything's being focused around tokens and we're even starting to see developer metrics come in to say, "Okay, what was the token spin to get this feature out or to get this fixed out? " That token economy is very real.
DaShaun Carter (45:28):
It is very real. So I'm trying to shift it for me. I don't want to worry about, I've been able to turn off my subscriptions. I keep one, maybe I have two, but my default, my first pass is my local stuff and I'm trying to deliver that experience for the developers that are working in a bank where they've got all of their work is sitting on a VDI or a VM or other development space, then they are connecting to, sometimes they're connecting to local hardware. If I've got hundreds of developers, do I give them a million dollars of token a year or do I give them a $10,000 GPU that the team can share and call that good because yeah, even since our last conversation, understanding the difference between a single Ollama model and something like Docker Model Runner that allows me to scale or VLM that allows me to have more than one agent running against the same LLM with speed, with low latency, that's a huge difference.
(46:32):
So for me, that's a big game changer, but I still have different LLMs for different tasks. It's not a one size fits all. And 50 tokens on whatever Opus 47 versus Sonic 45, those have different prices. You shouldn't be sending all of your workload to the same model. I did this exercise where I think I started doing this workshop, the Spring AI workshop with Gemma 4, my workshops. I like everything to be ran locally, but the audience that I had, I didn't expect that they all had Mac and 4s. So I changed the model to Qwen 2.5 Coder with the 1.5 billion parameters, a small model that's less than a gigabyte to download, but that's the model that I ran the workshop with. And guess what? The workshop worked the exact same way with Qwen 2.5 Coder from 2023 as it did with Gemma 4. The things that I was trying to teach the models, even the older models, they still had tool calling, those models can still do the work and that's a big deal.
(47:31):
Understanding that was a game changer because some of those models can run on a CPU. You don't need a GPU to run.
Nicky Pike (47:38):
So let's go, I want to dive into that and then we're coming up on time, but I want to dive into that. So one, you're taking your Raspberry Pi Army. I think you said you got like 104 of those that you're taking on tour to kind of demo all this out. The point being in what you're trying to put out there is if you can do this on pies, then an enterprise can sell it. What is the message that you want a platform engineer from say a Fortune 500 or Fortune 100 to walk away with when they see what you're doing with Pi?
DaShaun Carter (48:03):
So I'm just trying to kind of read the tea leaves. If I'm doing something cool, I want developers to be able to use LLMs, be able to use this GenAII craze for not just adding features to production, but also there's two other buckets, code assistance, right? What you have in your IDE, the things that are helping you looking over your shoulders, "Oh, did you mean this? " Or, "Here's a better way." Those kind of things, but there's also the productivity bucket, the digital assistant other bucket that I see a lot of developers leaning into and that actually might be providing more value to the business than the code assistant side. The things that are organizing your calendar, the things that are organized my calendar so we could do this, right? Those kind of things, the big flex, the things that I want to see for developers as a developer advocate are I want developers to have three hour blocks of time to just focus on what's next, not jumping from meeting to meeting, not having to do context switching eight times a day because you're in eight different meetings.
(49:05):
And I don't think that's too much to ask a three hour block of time every day to focus on what's next, just flow. That's what I want for developers. And if I can give developers a place for their agents to do the busy work, coordinating backlogs, do commit messages, summarize all the work that we did in the last release. If I can get agents to do that and I can do it in a safe, secure place, I think that I can get developers to have some more time to focus. And I'm borrowing from Sam Altman's conversations and Jensen Huang, like the things that they're saying, "What does the future look like? " I think the developers are going to change. They're going to flex different muscles. It's not going to be code. It's going to be business value, but it's going to be a developer mindset.
(49:54):
It's going to be this engineering, check the boxes, do your testing all the way through, but their focus isn't going to be about features. It's going to be about business value. It's going to be at a higher level, not on a feature by feature, but on a month by month or a quarter by quarter value to the business.
Nicky Pike (50:11):
100%.
DaShaun Carter (50:12):
And that's what I see. Having a platform, again, broad term, having a place where developers can push that type of work, not on their laptop. I don't want it on their laptop. If it's running on a bunch of coder instances on a bunch of Raspberry Pis, fantastic.That's the thing is I want developers to have a place to run their agents. If it needs to connect to the enterprise data, then yeah, push it to someplace that's connected to the enterprise data tonight platform. But this idea of having these agents running, that's what I see as kind of like this next iteration of development teams. As a platform engineer, I want to provide that. It's no longer providing services. They got the whole cloud menu, they got the CF marketplace. It's about where else, where can I give developers to run their agents safely? So not just coding assistant agents, but also the calendar management, all the other things.
(51:11):
That's going to be kind of the next big wave. And I think I got an idea and you pointed me in a good direction.
Nicky Pike (51:16):
I love the idea. Start thinking about value and outcomes and that should be out at the forefront of all of our buyings, whether we're bringing in AI, whether we're not. Value and outcomes is where it sits and we've got two more questions. I want you to hit these very quickly. Don't think too much about them. First is going to be the hot seat. So of every enterprise that's currently trying to roll out agents at scale right now, what percentage do you think are actually going to pull it off without torching their budgets, their code base, or becoming the next headline on LinkedIn or in the news? Give me a number, be direct about it. Don't sugarcoat it.
DaShaun Carter (51:48):
I can think of five companies that I work with already that are using Spring AI. They have agents that are autonomous creating code, doing code reviews, creating new issues. I can think of five companies off the top of my head that are doing it and they're doing it well. There's a big gap though between the companies that are doing it and the companies that are not. I'm willing to bet we're going to have another company by the end of May make the front page of the news because their agent destroyed something production, destroyed a production database, destroying the backups. We will see another big splash of that in May guaranteed. I put a lot of money on that.
Nicky Pike (52:23):
Yep. I hate to see it happen, but you know what? We learn every time somebody does that. We learn what we shouldn't be doing, which is a way to learn, I guess. But hopefully we start paying a litle bit more attention to the governance side of this and how you can actually guardrail and sandbox the agents to prevent those types of things. But it comes back to, again, looking for value and coming in with a plan. All right, buddy. Last question we ask this is everyone after everything that you've built, every pie that you've stacked, every CVE that you've patched, every recipe that you've written, what does it mean to DaShaun Carter to be a coder?
DaShaun Carter (52:57):
I think the most meantime to dopamine is the thing that I said earlier. This idea I enjoy. I enjoy fixing things, solving things. If you're a person that likes solving puzzles and yeah, problem solving, that's what I get. That's what it means to be a coder is solve problems. If it's at the code level, great. If it's at a higher level, that's great too. I like solving problems and that's what I consider being a coder. That's what it means. Problem solver.
Nicky Pike (53:25):
Love it. Love everything about it. I hope more people take from that. DaShaun, I want to thank you for taking the time to be with us today. It's always a huge pleasure to talk to you, man. You bring so much energy. We got to do it again sometime.
DaShaun Carter (53:38):
We absolutely have to do it again. Thank you so much for the invite.This is awesome. I love what you're doing. And from our last conversation, I've got a thread, I got a backlog item where I'm going down that path. So yeah, I would be thrilled to come back and kind of tell you what I learned on the journey.
Nicky Pike (53:53):
That sounds great. And you know you can always reach out. Very last question. Can we consider you a full-fledged member of the [Dev]olution now?
DaShaun Carter (53:59):
Absolutely.
Nicky Pike (54:01):
Yeah.
DaShaun Carter (54:01):
Yes. Do I got to jump through a hoops? No. I'm in? No. I'm in. I'm all about it. Even the T-shirts got to get your tattoos. Bumper sticker. There we go. Tattoos. Done. Done.
Nicky Pike (54:11):
All right sounds good. Well, thanks again for joining and man, we will talk to you soon. It's always a pleasure to shine. Thank you, Nicky. Thank you for listening to [Dev]olution. If you've got something for us to decode, let me know. You can message me, Nicky Pike on LinkedIn or join our Discord community and drop it there. And seriously, don't forget to subscribe. You do not want to miss what's next.