Episode #64: Everything is Code - AI, Cloud & The Future of Development

Welcome to The Rack, Resourcive as a Podcast, the show where you'll learn how Resourcive, the premier strategic IT sourcing consultancy, thinks about and delivers technology value creation solutions to the mid-market and enterprise. Your IT spend doesn't have to hold your business back. Learn how leveraging technology to improve EBITDA and enable growth to supercharge your business and career. Welcome to The Wrap, Resourcive as a podcast, Kyle and Kyle, all Kyle podcasts.

I don't know what Josh is calling that these days. It's one of those things. We just chatted. I'm imagining he's going to reorder this stuff.

I don't know. We're going to talk about trends in software development, what you're seeing, everything is code. You got a couple of kind of recent articles we'll reference. We'll chat about it real quick.

And, you know, this is what we like to do. We like to hang out and talk technology and business. So let's go. Which one do you want to start with?

You want to start with the come from the cloud flair side first? Or you want to talk about the trends and new hires and for software developers? Yeah, I mean, I guess I think part of it is framing it up that these two things seem, maybe, and you tell me if I'm wrong, but I would think from an outside perspective, these two things would seem counter to one another, right? That where you've got these, everything is code, this kind of real excitement around what developers can build.

And then you have, you know, what seems to be a decrease in job openings or job postings for developers, right? Yeah, everything's code. Well, I guess we got a bunch of code to write. Yeah.

Yeah. And then it's like, well, why are there not more, like, why don't you need more developers? Because that was a steep chart. I mean, it was a very steep decline in new job postings for software developers domestically in the U.

S. Yep. And I do think there's a couple things happening, you know, for some development. companies have offshored, nearshored, outsourced some of that.

I anticipate that that will be less of the route. I think that's been a heavy reason or route of saying, hey, we need to decrease costs. We're going to offshore or nearshore to cheaper resources to increase our profitability per headcount or lower our production costs, all of those kinds of things, right? With AI, I think that maybe you get some pullback from that for a number of reasons.

Because historically, and what I've seen in a lot of organizations is they're not necessarily outsourcing their engineering team, right? Like they're architects, they're engineers, like the product designers, all of that is still within the company. you know higher end higher paid executive level type resources it's a lot of the doing of like right so you create this this architecture or you create this kind of you know wire diagram or or or kind of you know what you want and then you're saying hey team i need you to build this right that brings up time barriers culture barriers iteration like all of those things that can happen if you're outsourcing that work.

Whereas where I seen and what I found is you can throw that same thing but to an LLM and instantly get a response to iterate on that is as good if not better than what a junior developer that you outsourced is going to bring back Yeah, so basically what I hear you saying is, hey, there is a strong use case for the tactical level of software development. And it seems that not only is there a strong use case for it, people are doing it. This is happening in the market today. And we're seeing actually a lag measure to its effectiveness in a decrease of new software dev roles.

I know one of the kind of in that article, I believe I've got to credit Nick a little bit here. I think he found that and sent it to us. But it talks about it was either that article or one you shared as a follow up. But it talks about essentially like at what level that's happening at.

And it's at the tactical level, right? It's not maybe some at the operational level. But, you know, the strategic level is more important than ever for software developers, the visionaries, the builders, like those people. but people that have enough context to be able to work down to the tactical level, which is really interesting, right?

So that's super interesting. Imagine like building a house, right, where you're a builder and you understand the design of the house, you understand kind of all the different components that go into it, but you can't swing every single hammer. You can't screw every single screw, right? And now that's in the physical world, obviously.

So you need typically tactical level or operational level resources to do those things. But you still have always needed the architect, the engineer to oversee the production of that building, right? Well, AI in the digital world has allowed to like, hey, I can just go basically command or control that tactical level resource instantaneously where, hey, I need you to go build a wall over here. Hey, I want you to build a floor that looks like this.

And then it does it. And it's actually a lot cheaper, right? And if you think about the cost of an AI license per month as opposed to a tactical resource, it's way cheaper to actually do it. And then I can bring some of that stuff back.

Ironically, you actually bring some of that code development back to the engineer versus the tactical level resource, right? Because I'm essentially doing the same thing, right? Normally, what I would do is give that to a team and say, hey, here's what I want. And they're going to go do some type of code.

You know, they're going to write a bunch of code, send it back. And then your engineer is going to go through, do a code review or do some type of testing with it, whatever the case may be. and then push it into, you know, whether we're testing environment, sandbox, or production environment. But it still comes back to that engineer for, you know, review and approval versus now, like, I'm doing that same thing, but with AI.

Got it. All right, well, bridge us over to the Cloudflare piece. So what's going on there? Break that down for me.

Yeah, so Cloudflare, and I haven't used Cloudflare specifically, but AWS has a similar product where you're doing everything is code, right? And so there was an infrastructure is code and now it's become like everything is code where normally you would have some type of segmentation within your team where you've got your developers that focus on the application, the code application. And then you've got like your DevOps team and maybe you have an infrastructure team, you've got a network team and you got all these kind of different teams is specialized in how to essentially deploy this into production And so that a lot of different teams a lot of different skill sets And that takes time right It takes planning of how do I take this code and then get it to a production environment at scale?

And it's like, well, I've got to think about like the networking of it, the security of it, the infrastructure. And now you've got some of these offerings. So AWS is their Amplify Gen 2 products. Cloudflare, I think, came out with Workers is their product.

And it's this idea where you can kind of create what starts off as a boilerplate application, but essentially just using code, define your application, and then push it into whether it's a sandbox or a production environment, but it'd be at essentially a global scale. And so we were chatting just the other day, and I think one of the folks took a picture of me. We were watching the Super Bowl, sitting in Hawaii with nothing but a laptop, and we had a major code release. We had redesigned the database, redesigned some of the front end, redesigned some of the back end, all in code, and did all the code build, code deploy, testing, push to production, can access it, whether I'm here in North Carolina or over there in Hawaii, the same level of latency on a kind of international or global scale with nothing but a laptop and a Wi-Fi connection.

So when you say everything is code, you mean you are also code? Yes. Are you in fact code, Kyle? I think we all are.

We're all in a simulation, you know? Very cool. I think there's probably a whole lot to break down and go into there. But I guess it's the next level up from being able to write, you know, at the infrastructure as code, then platform.

And now it's really full stack as code is really, you know, what you're getting into by the everything as code. Yeah, because I'm designing, you know, normally a database, you would go into, you know, MySQL workbench or, you know, whatever equivalent, and you're sitting there and kind of architecting your database, and then you're going to connect into that. Well, with everything as code is, I actually just define what type of database and structure and schemas that I want in code.

And then when I push it into production, it goes and it builds that thing for me. But then I've got it kind of encapsulated in code to where all I have to do is go into there and make changes, which is what I was doing. It's like, oh, I actually need to change some of my indexes or my kind of index tables. So I did that in that code.

And then when I pushed it, it made actually all the physical changes in our production environment. Cool. Seemed like dangerous. Seemed like risky pushes.

is like, you know, you need to ensure that much more around quality. And I guess that's back to some of the comments around tactical, right? Like you're not outsourcing that. There's a certain level of like, yes, it's very powerful, but there's also the nature, you know, with great power comes great responsibility.

Right? I mean, you're going to push this right into production. Like you need to be very, very, very high fidelity about, you know, what it's doing, the security of it, all of those sort of pieces. Well and the cool thing about everything is code and the ability to you know call it near instantly stand up and tear down infrastructure is you know normally if you in an on or a colo type environment you got to have a whole set of physical resources dedicated to testing that you're just, that you just have all the time.

Right. And, and that's kind of a waste. Whereas, you know, what I was able to do is stand up a sandbox, a virtual, and it's a production, basically the exact same thing that I'm going to have in my production environment in a sandbox environment, in the cloud, running the exact same way, stand it up, do all that testing, but it's, you know, kind of, it's privatized so only I can see it. But once you do it once, because you've done it as code, right?

Once you do it once, you break it down, but you have the code. It's in your repository. Go and do it again. I get it.

That's super powerful. What's the path, though? I mean, we're talking about this. It's exciting.

We're, you know, as far as any of our applications, we're born in the cloud. I mean, this probably sounds nice to some people, but some people are probably like, man, I'm like so far from that. Like, I've got so much legacy here. I've got, you know, whatever it is that their tech stack looks like today.

Like, how do people start to move towards this? Yeah, I mean, I think one of the common approaches is called the, I think it's the strangler fig or strangle fig approach. where in any application, you're going to have a natural iteration or churn. Like, I mean, you're having to work on that code anyways.

And so whatever new thing that you're doing, you're starting with, you know, deploying that in a cloud environment and then, you know, native cloud environment. And then connecting into, you know, your legacy, right? So you're kind of patching those together. And then over time, you just kind of, as those things either get deprecated and pulled out, or you need to revamp whatever feature or piece of that application, you're just like essentially eating it over time into that cloud environment.

So it's definitely not, you know, in most cases, I mean, I'm sure there's some, right? But in most cases, you're not just going to do a full rewrite, you know, like that tends to be pretty daunting and very cost prohibitive. But there's kind of a natural, okay, well. But I mean, it sounds like this would be a program.

I mean, it'd be a program level initiative, possibly with multiple projects underneath. Okay. Yeah. Yeah.

I mean, it's kind of, you've got to manage it as a program. Draw the line. I don't know if you say draw the line in the sand, but you basically make that decision of saying like, hey, all, you know, future feature releases and all kind of future development is going to be done in this new environment. And so we are going to consciously make the decision that as we have to iterate over our legacy environment, we're going to take that opportunity to chunk it over into the new environment.

Cool. Cool. All right. We got to run.

Pibbity, bibbity, bibbity. That's all, folks. I think that's where we started. That was good stuff, though.

I appreciate the education. It's an exciting time to be doing some of the stuff that you've been doing. I think, you know, software development specifically with the approach you're taking, despite that graph, is like an incredibly, you know, encouraging time to be in in that domain. Absolutely.

All right, bro. Great talking to you. Same. That's a wrap.

Thanks for listening to The Wrap. Don't forget to subscribe and check us out on YouTube. or at resources.com.