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.
Adron Hall (00:00:00):
If you're writing code, you're messing up. You missed the boat at this point. I'm watching some of these orgs where people are still banging away at some code because they can't use an agent or they're locked down or whatever. And I'm like, y'all are so far behind already. I don't even know how to catch you up.
Nicky Pike (00:00:17):
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 making developers 10x more productive, but here's what nobody's saying out loud. We're building a generation of systems on code that developers don't actually understand. Vibe coding sounds cute until your production system crashes at 2:00 AM and nobody on the team can debug it because nobody wrote it. And while we're busy celebrating AI generated PRs, we're quietly watching the shinification of software. Fast fashion development where everything's disposable, nothing's maintainable, and the bill is about to come due. Joining me today is Adron Hall. He's a polyglot principal engineer who's been in the trenches since before AI was cool. Adron runs Composite Thrashing Code. He speaks at conferences like Polyglot Vancouver on the real second order effects of AI acceleration, and he has developed a framework for understanding why AI agents love making the exact wrong types of code changes at exactly the wrong time.
(00:01:18):
So before Adron and I dig in, here's the challenge on the table. Up-level research shows that AI-assisted code contains 41% more bugs than manually written code. Harvard tracked 62 million workers and found that junior employment drops nine to 10% within six quarters of AI adoption while senior employment stays flat. And here's the kicker. 63% of developers have spent more time debugging AI generated code than it would've taken to write it themselves. So how the hell do we build reliable systems when productivity gains are getting eaten by debugging? The junior pipeline is collapsing and AI agents are treating production code bases like sandbox projects. Adron, welcome to The [Dev]olution.
Adron Hall (00:02:00):
That's a lot of question to answer.
Nicky Pike (00:02:04):
Yeah, we dig into it, man. We want to give you the best, the absolute best intro that we can. Yeah,
Adron Hall (00:02:08):
I was going to say, it's almost like you're not sure if you're watching a slow motion train wreck or something else happening when it comes to all of these things, all these pieces and all this data coming together.
Nicky Pike (00:02:17):
Yep.
Adron Hall (00:02:18):
And like I myself, I feel like I have this skewed entry into AI because as you mentioned, I've polyglot programmer. I've been using multiple stacks since before AI made using multiple stacks easy. So as I step into that, it's familiar territory. So when I see it, AI tooling derail things, it's very easy for me to usually step in and pull it back onto the tracks before the big train wreck becomes too much of a catastrophe. But there's a lot of the industry is not in that particular position to be able to do that. They don't have the history or they just haven't been spending as many days as I have in the trenches. So it's always, how do you start to balance that out? How do you pull in people that have been in the trenches and the new people? And right now, as you mentioned, the junior pipeline is kind of imploding on itself and people aren't being funneled into positions.
(00:03:14):
So what do we do about that? And that's a big question that I keep working to answer and the answer kind of keeps changing as we move forward, which I feel like a lot of things in industry right now are changing rapidly. And once we think we have an answer, it changes a week or two later.
Nicky Pike (00:03:31):
Well, and you're looking at all of these tools that are coming out. All the AI tooling comes out. There used to be a time where there was this mode around the IDE. I mean, developers love their IDE. They were very loyal to it, but now we're looking at stuff, all the branches that are coming out of VS code, we're looking at all the AI tooling coming out and people are starting to swap IDEs and AI tooling like socks, man. They're just going through because we are moving so fast that it's impossible for one tool to keep up. So people are starting to switch tools. I mean, when you talk about Polyglot, that's also kind of in a way applying to the AI tooling because people are using different tools for different things because AIs are different at certain things other than others.
Adron Hall (00:04:11):
Yeah. And you have the models and then you have the providers, engines. And kind of as you swap those around, different things change in what you do. As many people have noticed, it was just even November, December timeframe of last year when a lot of these elements became dramatically more effective. A lot of the componentry too around breaking things out to a specific role to implement under, where it pulled in the scope and you're working from the point of view of, are you writing a plan? Are you doing architecture? Are you doing the engineering work? Are you debugging where it starts to like ... By default, it starts to put hooks in there, basically like your console.writelines that you would normally do yourself. And it starts to look at those along with logging and other things. So as those scopes change and are refined to a specific thing, the effectiveness of them has become much better.
(00:05:06):
So I know, like you were mentioning, what was it? 40 something percent more bugs and 60
Nicky Pike (00:05:12):
Something- 41%.
Adron Hall (00:05:13):
Yep. Yeah, more engineers are finding they're spending more time. I'm very curious what those updated numbers are as we reign in the scope. Part of that is because just as answers change, one of the things that I've noticed is if I reign in the scope of what an agent is doing, then I run into less issues because it's staying focused on that particular thing. Just like you want to reign in the scope of your Jira ticket or the scope of whatever feature you're working on to kind of focus on that and make sure that's the thing that you're building out and possibly providing effect for, right? Like that might cause other things to have bugs or whatever. And as you do that, if you refine yourself to that particular feature, you can usually make good headway on that feature at the most rapid rate you're going to be able to.
(00:06:00):
Same thing with the AI tooling and the different models. If you reign in that scope, it tends to focus more effectively on implementing that particular feature or bug fix or plan or whatever it is. And I've even changed my development style to do a plan, read it, review it, get more insight into what it thought it's going to do, then let it pass that to an engineering agent task. And as people are seeing that, I'd be very curious to see how those numbers shift from the 43% more bugs. Is it 43% still or is it starting to drop? Hopefully it's starting to drop. But yeah, a lot of that. And then also just the whole, the ability to kind of be more familiar with what the scoping is, because it kind of matches to what traditional roles have been that have developed over the years in particular engineering teams, right?
(00:06:53):
Like having someone do the architecture and then kind of pass that down to say, all right, you guys figure out how to do the next steps and then maybe introduce product or UX or something like that. And it gives you a little bit more naturally flow through steps to do something versus saying, "Hey, build a website that does this big open-ended thing," which of course kind of leaves you open for a creative rendering of what that is you just asked for. So hopefully the scoping and things like that changes numbers, but I'd be very curious to see how that's starting to change. We almost need like some rapid real time polling on those types of things.
Nicky Pike (00:07:32):
Well, and one of the things, you're bringing this from the perception of someone who's educated in this, someone who is a developer, right? And I do think that one of the things that we're seeing with AI, one of the big advances that we're seeing with AI is that non-developers are coming in and able to write code. And I remember when we were talking, you gave this really great statement around the definition of vibe coding that for me it kind of hit home. Walk me through how you described it and how that translate to what you're seeing in code bases right now.
Adron Hall (00:08:01):
Yeah. One of the interesting things, especially for people new that are kind of going in and saying, "Hey, I want to create this thing and I have this general idea, create a first rendering for it. " And then they get that and they start to move along. And then at some point you get this slow creeping dread of pulling the latest changes as things modify, but the spec isn't clear or whatever, where it kind of feels like someone rearranged your entire kitchen and then just dumped the knives all over the floor.
(00:08:31):
So you're standing there kind of going, "Well, I don't want to move around too much with knives everywhere, but I'm in the kitchen trying to cook something." So it's a little tricky from that point as it removes that barrier for developers or non-developers to get more into the product space, especially where they can say, "Okay, I have an idea. Let's build that initial first stage or first draft." And that's pretty good. However, we're still ending up in a scenario where often people will do that and then they say, "Okay, now I need an engineer." Engineer comes in and goes, "Whoa, okay, hold on. We got to walk it all the way back and kind of almost start from scratch in some scenario. It does X, Y, Z. It seems to be working, but we want to check for security. We want to check for workflow.
(00:09:16):
We want to make sure ... We just want an overview of the app to see where it's at." And I took a look and it had built the thing, but you could tell that the initial ask of the system they used, I don't remember which one they were using, Claude or something like that, but they said, "All right, build a site that does X, Y, Z." And it said, "Okay." And it built kind of an open-ended site to do X, Y, Z. As they went in and refined X, Y, Z, that's not really what they were asking for. They were basically asking for A, B, C, completely opposite end of the spectrum type of flow. So with the first draft of the site had like a very tightly referential integrity database that was done through Prisma and then React and things like that. But what they really needed was kind of a more loosely open database schema because they didn't know what the structure was for some of the mutations that they needed to occur.
(00:10:11):
So they had gotten locked in and what the AI had done, smartly so, kind of based on what it needed to do based on what it already had, because what it already had was kind of the wrong thing, it tried to start using JSON fields as columns, right, to just kind of open in the schema for that stuff that was going into those rows. What they really needed to do was not have a relational structure for the initial thing and have more JSON blobs to begin with. But because of that, the AI was working all of those feature changes around that structure as if it needed to stay de facto that way. So I went in and I just nuked the whole database and kind of restructured how it was going to work. We ended up with two tables. One was basically a time series and one was an active row.
(00:10:59):
And then in that, once I told the AI to do it that way, you could tell that the AI changed all of its reasonings and everything got much more simple around what it was trying to build. So that's one of those scenarios very much where, yes, it gives you the ability to start quickly, very quickly, and have almost no technical knowledge, but at some point you need to really step back and understand what's happening inside of that, right? The AI, if you don't know to ask, it doesn't know to tell you, basically.
Nicky Pike (00:11:29):
And I think you bring up something interesting there, right? When we talk about vibe coding, of course, there's a lot of developers that against it, but let's be honest, it is bringing out this ability for domain experts and other people who are not technical to bring these apps together. And I think there's an argument being made that these aren't production apps, these are maybe automations or there's something that's being used. So there's also this argument on the other side that says, "Hey, this is something that actually helps developers because these domain experts, rather than sitting on backlogs, they can go create this. " And then when they hand it over developers, developers don't have to start from scratch. But what you kind of pointed out right there is, well, is that a help or is it a hurt? Because they may go down this path where they build something with AI because they don't know better.
(00:12:10):
They build basically a huge pile of crap and then they give it over to IT and say, "Okay, now let's make this production ready." And they're having to back a lot of stuff out. Which side of the spectrum do you fall on on that one?
Adron Hall (00:12:20):
I fall on the side of the spectrum that I actually like them to be able to do that for two reasons. However, it only works effectively with a certain type of organizational structure or openness, I should say. So first off, giving them the ability to do that and then being able to step in does some specific things. One of them is it opens up their ability to kind of basically touch and feel the thing that they're going to build, right? So they immediately get into that and they kind of figure out how to run it at least at a rudimentary level. So as soon as they run into problems, they realize some of the implications of what's being done, right? As before, the only way product or even technical product to some degree would run into that scenario is after they've passed something to engineering.
(00:13:09):
Engineering's gone through a whole thing and then said, "Here's what we've come up with. " And they touch it then and they're like, "Well, why does this work this way? Why does this happen? Why does that happen?" And then you have to communicate all that. So you've got all these extra communication cycles that are happening just to proof something out. The other big kicker there is if product and technical product or even UX can kind of go through some of those iterations, they've done that, they've experienced that. And by the time they're handing it off to you, they understand some of the pain points that they've already run into and also they've usually run into enough pain points where they've kind of tried to backtrack a little bit themselves and figure out where the nuances of what they're building needs to shift or change. So already some of those communication cycles that are usually time intensive and you put a lot of energy into those are pushed down and made a bare minimum, right?
(00:14:06):
And all of a sudden you've kind of leapfrogged over to, "Well, here's what we want to implement. Here's some of the things we run into. Where do you want to go from here, engineering?" And engineering can look at that and go, "Oh, okay. We see what you've been trying to do. We have a visual of it and can kind of touch and feel it and see how it's running." And we already know some of the problems. We already know basically what you like that you've done and what you don't like. So a lot of those communication cycles just disappear because you've just leapfrogged past that. Now, the big catches, and this is something that's always been a problem in the industry, is the build the first thing, ship it, and then that becomes the production thing, even if it's never intended to be. You got to have a point where you can say, "Hold on, we have to step all the way back." That opportunity has to be there because you leapfrog so far that it's like you've taken that prototype plus a bunch of cruft on top of it and just like launched it right into almost oblivion.
(00:15:07):
So you have to be able to step back and really do a firm refactor, redesign or rebuild of the architecture if need be. Just like I was talking about before where I went back in, I was just like, "We're going to nuke the database because what it ended up with, with 15 plus tables, with tight coupled referential integrity for stuff that doesn't really need that, that's too much. We're talking about all sorts of limitations that we just don't need to work with. Let's remove that and step back and see what we need at a bare minimum." As long as the company is open to that and as long as a team can work with that in mind, I think getting production or getting product and getting technical product, getting architects, getting ... The people that usually aren't slinging the code in the trenches, getting them to proof it out that way, I think is a huge leapfrog if that other element is in play, right?
Nicky Pike (00:16:01):
So far. Yeah. I think that absolutely lines in with what we've seen with some of the things coming out from different places, right? So there's like, I was reading CodeRabbit, they did an analysis where they found that AI co-authored code had 75% more logic errors and it was about two and 2.75% higher security vulnerabilities. You even kind of talked about this at the Polyglot conference where you predicted that there would be more vibe coded outages. So I guess one of those questions is, how do you even recognize when a system's being built on code that nobody understands? And it feels like what you're saying is this is where the developers actually come in. Go in, vibe code those things out, but before this becomes something production, if that's the end goal, you've got to have that human in the loop. And by the human here, we actually mean a trained developer to look for some of the warning signs.
Adron Hall (00:16:50):
I get the feeling that that's happening because I see a lot of principal dev roles these days that basically kind of define that in a rough sense. And I feel like they're bringing in people to be that educated, experienced gatekeeper of the ship it to prod person. Currently, we don't have as much kind of filters, et cetera, for production for AI. So AI just kind of shunts around the corner and goes, "Boom, there's your stuff shipped." And I feel like people are running into that with AI where they're like, "Oh, we've shipped stuff already and it's sort of running. What do we do now?" So that's one of those scenarios where it's like, yeah, if you want to be careful and you want to make sure you're shipping good stuff, you got to get somebody in there to really kind of take hold of that and watch it as much or more so than like PRs even.
(00:17:39):
You need to have that final gatekeeper of the prod that just keeps an eye on that and everything. A lot of companies aren't set up for that. So they need to figure out what that plan is for having AI push to the next stages of whatever, especially to prod. And I feel like that's going to be one of the key roles is like the prod person and the get it from initial idea to first inception and then prod person. So you probably have like two or three people where you traditionally have like 10 people and maybe a bunch of filtered mechanisms within your get flow or something like that.
Nicky Pike (00:18:15):
Stop, stop, Adron. So are you saying that people should have a plan for how to implement AI development before they start implementing AI development?
Adron Hall (00:18:25):
I mean, YOLO, right?
Nicky Pike (00:18:27):
Right. There's this whole industry around cloud native services, the ability to do exactly what you're talking about, break this stuff up. And what I'm seeing, you've got to be very specific with AI to bring that type of mentality into your application building. But I think that what you're saying is the companies that are going to do this best are the ones that are actually sitting down and saying, "Okay, we know AI's coming, but we need to design for it. " It's not only going to be the infrastructure to support it, but we may have to change our development processes. It may mean a change to the way our developers do some things because this is a different paradigm for us.
Adron Hall (00:19:03):
Oh, very much. I very much see, and I'm sure a lot of people are already seeing this at this point because it's happening already and happening pretty quick and not super clear exactly how it's going to unfold and be shaped, but roles are going to change for sure. How you conceive an idea and actually get it into play is going to change, just like what we've been talking about. And then same with production, getting it out there into a place and then continuing to iterate on that is going to change dramatically. And in some ways, like one of the things I've always done is try to keep teams, especially ones that I'm directly responsible for, I try to keep them super lean where communication is minimized down to the specific things you're actually trying to talk about and shipping is kept to the very core functional elements of what we're trying to ship.
(00:19:55):
So we're not dealing with other peripheral pieces. That's always hard because every company, no matter what size has a lot of thing, moving balls in the air. But by doing so, one of the things I feel particularly positioned well to do in this age is as we start to run multi-agent systems where we're saying, "All right, something's running as engineering, something's running as debugging, something's running as QA." Right now, one of my own little side projects, I have all three of those agent roles running. And I've even gone to the degree just as an aside of like, one's like OpenAI, one's Claude, one's something ... They're all different things from different services just to kind of make it more complicated to deal with. I like to give myself challenges. But as we do that, even though right now we have like planning, engineer, debug, very finitely described things that match to existing roles, I think even that will change at some point and become more seamless in its flow where you're kind of doing one thing and it's just taking you through a workflow instead of roles
(00:21:01):
Because why have roles when it's all one smooth thing that can be transitioned between from an agent, right? The agent can change its persona as it needs to, to shift through those things. And as I watch that, I'm like, it would make sense that as you have those things, it communicates back to you as though you are the leader and the creator of this idea, and you go through a flow versus trying to lead different personas within that, and it just manages that. So that's one of those things where even today, I see the roles starting to shift and it's kind of a struggle to actually map titles to functional work within this paradigm, which is very interesting. And it's just, I feel like they're kind of pulling the carpet out from under you and you're like, "Oh, okay. I'm still standing, but what's the next step?" And that is an ongoing question, is what's the next step?
(00:21:57):
How are we going to shift this next? How do we want to shape it? And as I work and build out more multi-agent systems, that's top of mind all the time. It's like, "Okay, it's doing X, Y, Z. I'm getting this shipped, but do I need this one in here, in this place? Do I need another gatekeeper one over here? Do I need a person watching what it's doing here?" Kind of shifting back and forth and trying to figure out what those roles and those personas really are.
Nicky Pike (00:22:20):
Okay. So let's pop the quirk on that one a little bit because when you're talking about these different roles or this workflow, I know that there's a lot of junior guys out there that are thinking, "Well, that's what I do today. Is AI really going to take that over?" And when we actually look at some of the statistics, especially from the Bureau of Labor, we're seeing a 25% drop from 2023 to 2025 in programmer employment. We're seeing Stanford found that employment for developers between 22 and 25 is down nearly 20% from their peak, and we've got all these stories about companies that are cutting rolls. So spell that out for me. We're watching this change. You've got the prediction that it's going to change the way we work, and it seems like, and a lot of people are taking it that this is going to come at the detriment of junior developers.
(00:23:04):
What does this actually mean in a couple of years when companies realize that, "Hey, all our senior developers are gone. We didn't train, we didn't have any apprentices to come in to know how to work these workflows." What do you think that means for companies coming out?
Adron Hall (00:23:16):
First off, I think one of the big problems is not that people don't want to train, don't want to bring in junior people. They don't know what to do with them because the work is gone. The traditional work of, okay, you get in here and you build this, you try this easy feature and you build it out and we'll look at your code and we'll talk about your code and see how it's shaped and how you're using case statements or if statements or whatever it is, and how complex is it, how efficient is it running? So all those things were kind of in place a couple years ago, et cetera. And we had people coming into the industry left and right, learning that. Slinging individual lines of code is to any modern or super modern group that's progressive about moving forward, that's gone already. If you're writing code, you're messing up.
(00:24:05):
You've missed the boat at this point. I'm watching some of these orgs where people are still banging away at some code because they can't use an agent or they're locked down or whatever. And I'm like, "Y'all are so far behind already. I don't even know how to catch you up." Even if you started using gen AI stuff tomorrow and you started breaking out whole agent farms, your technology has just dragged behind and you're going to have to bring in like whole teams and like overload the whole process to try to get ahead or something. So that's tricky. I haven't thought about how to catch companies up at this point because I keep working with the ones that are building agentic systems and figuring out how to do things.
(00:24:43):
But yeah, as far as that, the traditional junior, I'll say, that role's gone. It's over already. But the way to think systemically about your product, your service, what you're trying to offer someone is where things come together. And especially colleges and places like that, even though they're struggling to kind of reorient around things, they're a good place to learn about the systemic nature of how things work. I would argue that some schools don't do liberal arts so great and you might miss whole parts of the universe, but the idea is to understand more systemically around what you're trying to build. And if you can do that, I think that's the key to being positioned to be able to step into a junior role and start to kind of almost work backwards from there. Come in with an idea, a more systemic idea of what you're trying to work with, the idea that you're going to work across teams, across groups of people, not particularly just go build features or just go design a product feature or this or that, but kind of look at that big picture and try to work backwards from that, I think is going to help juniors so much more than going, "I'm really good at Python and moving data through a pipeline," or whatever it is that has been the last umpteen years that people have focused on.
(00:26:11):
And like I still see a lot of certs around that type of thing. I see a lot of pixel pushing and things like that. And I'm like, "I don't know if you want to do that because you can go into your visual studio code with Copilot or you can go into cursor and you can say, You know what? I want you to create an SVG of a logo that looks like this, then put it into a site, give me an iOS app and give me da, da, da, da. And you're done with your first drafts in like an hour and that's after you've looked at it and decided, yeah, I don't really like the way the SVG looks. Do these changes. But being that they can do all those things, like those little details where people would specialize in SVG formats or whatever, or having placement within logos for where the iOS app is going to work and the whole iOS stack, like that's not super pertinent, all the little moving the little pieces of sand at the beach.
(00:27:02):
You got to get out there and see where the bulldozer is and where the beach is and where the water is and go, all right, we're going to shift whole parts of the beach now to make sure it's nice, right? And that's where I think eventually the junior path is going to kind of pick back up. It's just going to be from a very different vantage point and that vantage point's super fuzzy, which is part of the problem. And I did, speaking of numbers and such, I was looking at a report recently where they said that tech
(00:27:29):
Implementers or tech roles overall has kind of followed the same path with that initial layoff deviation after the shutdowns of the pandemic and all that. There was a ton of hiring then, but it's gone back to its flow of upwards movement that it had for years and years and years before that. So kind of what I'm thinking in my head is that technical people are still needed, but they're needed from a systemic point of view to understand where this technology is going and have ideas on how to build systems around it to harness it and utilize it. As soon as the industry starts to get a firmer idea of how to bring junior people in to think from that perspective, I think that pipeline will just, it'll open up pretty big at that point.
Nicky Pike (00:28:15):
Well, and I see there's a plurality there because we talk about going into, "Hey, the colleges are going to have to teach more systemic thinking." And I do agree with you on that, but when we look at universities today, those universities are, they know they got to teach AI. It's a fact of life now. It's going to be here, but they also pretty much ban it outright. And there's the thought here, well, you've got to know what you're doing, the old adage, before you automate anything, you got to know how it runs. And I think that still applies. But again, going back to what you're saying, the actual typing of code is not going to be a thing anymore. We can do it much faster with AI. So how do you think colleges and universities are going to meet that need to get junior developers ready for this new way of thinking when it comes to development?
Adron Hall (00:28:59):
Yeah, off the top of my head, it's fuzzy for me too. I have trouble these days bringing in junior people for this exact reason. Usually when I've in the past brought in junior people, even regardless of what education level they have, if I see that they have the acumen to tackle problems, I could usually bring them in and get them going in short order no matter what. But at this point, it's fuzzy about what path to set them on once you bring someone in. So it's a little hard to say exactly, but off the top of my mind, and as with the times, I might change my mind in one week or two weeks or three weeks.
Nicky Pike (00:29:40):
It's not allowed. Once you say something, Adron, you can't ever change your mind. We all know that.
Adron Hall (00:29:45):
Yeah, can't change it.
Nicky Pike (00:29:46):
That's right.
Adron Hall (00:29:47):
But yeah, my thinking is, the whole idea with a liberal arts degree is you kind of have a big picture of the world and you're versed in a lot of different things and you kind of go out there with this generalist approach to existence and You tackle whatever you kind of majored in, kind of minored in or whatever. I feel like a little bit of that needs to come back into play. So you don't just go in and just learn how to program or you don't go in and just learn how to do database stuff and database theory. It's nice to get into that niche and specialize. It's good from a learning perspective, but the skill itself isn't particularly going to map to something effectively. So having that generalist approach to problem solving, to understanding and looking out at the world and going, all right, this is the type of problem that I've stepped into that I want to solve.
(00:30:37):
Whether it's an e-commerce site or let's say you're trying to do mapping for drones. There's one that's popped into my head recently that's just been wild. Well, okay, drone tech is one thing. Mapping is another thing, but how well do you understand mapping? What do you want a drone to fly over or not fly over? You got to kind of understand more than just maps, more than just mapping. You have to understand the whole societal nature of how these things move around in the world. And you're not going to do that if you just have very specific training on maps, how to navigate from point A to point B and just drones. You need to have many other skillsets and understandings of the world around you. And I think that's where kind of pulling some of that liberal arts degree knowledge and education back out and focusing on a little bit more would probably help colleges in that degree.
(00:31:32):
Universities at least. Some of the votech and stuff, focus on one or two of the specifics and then get out there. And that's where I think colleges are going to have to really figure out how to kind of focus and bring that together
(00:31:44):
For coursework, for curriculum, et cetera. Instead of a lot of this niche play where they're like, "Oh, this person is real specialized in SQL." All right, but where does that get you today? You know SQL, you can tell, put it on your engineering setting, ask for a basic query for pretty much anything and it's going to go, "Here's your option." And pretty much do it right.
Nicky Pike (00:32:07):
It's been a common statement of mine about where I think AI is going to change. It's going to put engineering back into software engineering. And I think you're saying the same thing here. The college and universities, when we go in, if you're a mechanical engineer, they don't teach you how to build a car engine. They teach you the theory of mechanical engineering and here's the certain principles and physics that apply to that. Now when you get out into the real field, maybe you'll specialize in automotive engineering or jet engineering or something to that effect. But that's not what they teach you in school. And I think that's where we've got to get to is going back to engineering as a principal, here's the theory rather than I'm going to teach you Java or I'm going to teach you React. I'm going to teach you how programming languages should flow.
(00:32:46):
Now take that knowledge and use AI to build whatever you need using those basic principles.
Adron Hall (00:32:52):
Yeah. I'm a hundred percent on board that conversation that's been kind of percolating up in industry around the fact that they're like, "I think computer science needs to be computer science again, not Java 101 repeated five times or whatever." And I feel like a lot of the people too that I see really like taking the charge with a lot of this gen AI stuff are people who I've seen that are very focused on the computer science aspect of things versus the, "I implemented X, Y, Z sort algorithm and Java and I've enhanced that specific thing." They have more of an open approach to how they're going to do things and they try different things with the intention of achieving a particular outcome or goal. I've seen those people specifically popping up on like LinkedIn and other places. The ones who talk about it at least talk about what they're working on and it seems like they're making a lot of headway on those types of things.
(00:33:52):
And I've tried to strike up a few conversations with them and got a few conversations going about like, "What are they doing? What am I doing? Let's trade ideas on the matter." Whereas the people that did focus on a specific language are feeling a little sidelined, I guess, is a good way to put it. They've been stuck on the bench and they're sitting on the bench.
Nicky Pike (00:34:14):
Yep. I got you.
Adron Hall (00:34:16):
Yeah.
Nicky Pike (00:34:16):
Okay. So we've talked about the problem. We've got AI co-authored code that there's potential that people want to understand. We've got the debugging nightmares. We've got the junior pipeline getting cut. When we talked, you'd have developed this framework for why this keeps happening. And I want to kind of jump into that because you have terms like refactor and clean up and fix. And really these are meaningless if you don't understand how those changes affect systems. So break down those six types of code changes for me. And I'm going to name these off, you could tell me if I forget one, but we've got additive, mutative, destructive, transformative, cosmetic, and then the one that you call the silent killer, which is behavioral drift. Walk those through and give me a little bit of a definition for each one of those.
Adron Hall (00:34:57):
It's funny too, because I wrote them all down with the intent to memorize them and they still merge into each other so much. But the general gist of all of them is that as you're working through code, and even as we've done it pre AI doing anything, right, you'd put in a PR around a specific scope of work that you're trying to do. And one of the key things, even with Git or subversion or whatever source control you've used in the past, one of the key goals was to not step on each other, right? You put in your change and then also not have your change functionally affect whatever the app is doing so you don't break other people's changes as they go in. And it's always been a big, big challenge even as we verbally communicate with each other all the time and are trying to get all these changes in.
(00:35:46):
And with AI, that's amplified many times over because if you have more than one person, and even if you have one person and they're doing multiple agents, you're at risk of having the changes that the AI is making, conflict with what's in there, but also implement things that you push it out to prod and all of a sudden you notice something doesn't work and you look at it and you're like, "Oh wait, they've changed the underlying API and the front end is not communicating with that API anymore. It's using different old hooks or paths or whatever." Those things are what we have to really keep. And as we were talking about earlier with the scope, like refining the scope, bringing the scope in for an agent to work on, those are the things that really dictate how we need to refine and pull that scope in more so than roles, right?
(00:36:36):
They've primarily been split out as roles within a lot of IDEs, like I see that digital studio code with kilocode and a bunch of the other ones where they have that architect and engineer and a debugger or whatever, but that's something that we created. But the thing is, is like once you have things run together, you've got to really sort out and define where those scope walls within the actual code itself is going to conflict with the next layer that something is working on. So if you define those scopes and you limit those to those functional implementations, you have a much better chance of not having get commit conflicts, right? Which is usually how that bubbles up from the agents. You have one commit and another commit and all of a sudden your history's broken and your code's merged on top of itself and missing pieces or has pieces implemented that you don't want.
(00:37:27):
So those six things are kind of like the laundry list or the punch list as house builders, et cetera, would say, "What's on your punch list to get done before you're done, done?" And those six things are one of the things you need to look through. And as you have your agents working, you need to continuously refine and manage their scope so that they can work their changes small enough where they're not creating these like overly mutative changes or like the Death Nail one where you get in and it just changed the whole behavior of the app. And you're like, "Well, that's not what I asked at all. " But as it tries to work through and get to an outcome, the outcome could be in direct conflict with your underlying system already. Just like the one that I mentioned earlier where it had 15 tightly coupled, highly referential integrity connection points between all these tables and the database, and then it just tried to work around that.
(00:38:26):
So everything it was implementing was very, very difficult to implement and they were running into one of those scenarios where very, very big behavioral changes. The tooling was trying to do these like 1200 line, 1500 line, 2000 line changes,
(00:38:41):
And that's not doable. Even an agent looking at that PR is like, "Whoa, hold on. I'm going to get ... You got 2000 lines? Well, I got 200 requests for you to change stuff on this one." So looking at those, you got to go through that punch list and really get your agents scoped in so that you're not running these conflicts and it solves a bunch of those other peripheral problems just by doing that.
Nicky Pike (00:39:07):
Well, and on that line, right? So it seems to me that when I'm working with AI, and this is one of those changes that you talked about, it seems like AI is addicted to transformative changes because they are impressive, right? A 2000 line diff looks like you went in and you did a bunch of work, but this is actually really a dangerous instinct. Why does it satisfy the manager brain, but it terrifies anybody that actually needs code when they look at this?
Adron Hall (00:39:34):
I find it interesting. And I think part of it is just the fact that as people have designed AI, because always good to remember, this is all coming from programmers in the first place, but programmers know that getting that big change makes it look like you did do a lot of stuff and you did. A lot of stuff was done. Was it stuff you needed? Probably not, but it's there, right? And to some managers, that's often how you up manage, right? Something happens all the time in the industry, doesn't always get talked about a whole lot, but it is there. Sometimes you need to upmanage. And it seems like in a sense, the AI services by having it so open-ended, partly because of the way the systems work, but partly because they were like, "Let's show off what we can do. " Well, in turn, it's trying to up manage the customer, us, right from the get go.
(00:40:28):
And as we go, "Whoa, whoa, hold on, some of us kind of know how to manage, so let's not go overboard. We just want some specific things. We're trying to hone in the scope and stuff." As we do that, we're getting more and more options to reign in that scope, and that's helping a lot, but we are still getting a lot of the ... There's still a lot of those types of changes that are just too big. And usually if you see those, your spec is probably not clearly defined, you've not worded your request of whatever you're after well, or the underlying system that you have, that you are working on is not understood by the system. It's not been able to introspect for whatever reason. That's another one of the gazillions of big challenges right now is trying to get that introspection of existing projects to get sorted out so that AI will apply reasonable, logical feature changes, mutations, or whatever to it.
(00:41:26):
You got to keep an eye on it to ensure it's not fumbling around and causing you more work, which I'm sure falls into that. Was it 60, 60 something percent of developers said, "It takes some more time now." That's probably one of the scenarios right there.
Nicky Pike (00:41:40):
So I think that comes down to one of the fundamental differences between how AI treats things and how humans do. When we look at AI, AI optimizes for plausible output. It's not looking to be correct, right? It's a pattern recognition and repeat system. Whereas we look at humans, they are looking to kind of minimize the blast radius. They want to do the work that's necessary and only the work that's necessary. And I think that's a fundamental mismatch. When we look at some of the telemetry that's out there on some of the open source projects, we do show that a revert frequency is about 30% higher for the large AI generated commits. So do you think this plays out because people are asking the agent to do something very simple like, simplify this or make it clean rather than doing what you're saying and give it very detailed systematic instructions?
Adron Hall (00:42:26):
As with some of the previous mentions, the scoping comes into play massively. Like what you can control and what it's going to do for itself. For prototyping, it's great if you give it an open-ended statement. You can get past that writer's block moment. Now, the minute you have something to work with though, you've got to manage that scope, you've got to manage the more refined part of what you're working with. If you don't, you're going to end up with that rework. You're going to end up with reverted commits like just, "Oh, throw that whole 2000 line commit away." It took 30 seconds, no sweat, right? Theoretically, it's not what we wanted. We don't know what was asked of it, but it churned that out. Let's give it another go. And you go back at it and figure it out. But that's where you've got to be detailed in your spec, whatever specifics.
(00:43:21):
But yeah, without those core elements, you're going to end up derailing yourself over and over. You're going to be reworking and reverting back a lot endlessly, right? Yep.
(00:43:32):
And I know some people, they kind of fall into that because as engineers, a lot of engineers, they've been handed the thing in some type of arbitrary spec or whatever, and we kind of churn it down to the specific thing that we need to work on. But the idea is that we're always kind of, we have product or we have another element bringing an idea of what to implement to us. And then we either say, "No, it's not possible. We need to do this other thing or whatever." And we kind of shape it at that point. But a lot of engineers are not used to saying, "All right, here's the bigger picture. I'm trying to do this part. How do I refine what that is and put it into actual context that's going to let me specifically build that thing?" And that's what they need to do to hand over the spec to one of the tool systems to start churning out and implementation.
(00:44:25):
And I think that goes back to the education thing too, right? Where, okay, how are we going to get people to learn, to understand and kind of regurgitate that in your brain and put it back together in a structured way so that it's useful? You got to have some type of systemic understanding of the thing you're building and the periphery and the possible blast radius around it to kind of put together that idea effectively to have something generate an implementation. So that's where all those things kind of connect.
Nicky Pike (00:44:58):
Yeah. I think you're onto something there where I think maybe a lot of developers aren't really considering that, that the MVP, when we're going out, we don't know the story we want to tell and we do open-ended, you're going to iterate. Now, I think a lot of people, as they iterate, they think, okay, I'm going to stick with this project. And at the end, I've got this big mess. And that's where we get a lot of the slop stuff, right? We've went through a thousand different iterations. There's still leftover code in there, but that is a work stream in and of its own. Use that work stream to come up with, now I've got my story, once I've got my story, now let me break that down to inspec. And you can use AI to help you break that down into a spec. Once you get that spec, blow everything away, bring only that spec up.
(00:45:36):
And I think you'll find that you get rid of a lot of that slop. You get a lot of the orphan code, but people need to be thinking about, again, this is a tool. I want to get over the writer's block. I'm going to have a whole mess of crap when I'm done figuring out the story I want to tell. But once I do, I can now use that to frame exactly how I'm going to write that story in my next iteration that's completely separate of what I did with the slop. And I think a lot of people forget that.
Adron Hall (00:46:01):
Oh yeah, indeed. Part of that I think too is if we look at the industry now, 99% of the systems are out there in some type of monolithic or even micro services, whatever architecture they're in, there's just layers of cruft and excess and trying to refactor things and reverse engineer things to put things together. So you always end up or have always ended up with anything that gets a little age to it is going to be kind of a big ball of spaghetti and just kind of a little bit of a mess. Even the well designed systems are going to be a little bit of a mess that you're going to have to kind of know and understand and reason around. And especially for people that are new into the industry, the few that are slugging it through that junior stage, et cetera, that are being able to get in, that might be something ... I remember when I was junior, I was like, "Why is everything broken right from the get go?
(00:47:03):
" Well, that's part of what it is. Anything with a little bit of age is going to have all of this different history to it. And kind of understanding systems from that perspective, I think is very important to understand ourselves still, but also as we work with it from that generative AI perspective, like how do we bring reasoning about those systems into play so that we can get effective spec to implement off of? It's pretty easy with greenfield. You start with something, you say, "I want X, Y, Z, help me write the spec for it, churn something together, you get a pretty good spec. You build off of that and you're like, Oh, this does 90% of what I want. Well, then you move into that 10% space, right? All of a sudden your system starts to age past day one. It gets more complicated to reason about.
(00:47:54):
It gets more difficult to have the same core domain concepts or whatever originated that idea. Even in that stage, you eventually get to that point where you have to start to kind of build systems around even understanding the system. And I feel like the fact that we've had to do that in the past needs to be remembered because what did we do? We've written documentation. We've tried to do certain management processes or gatekeeping of certain things before they move to different stages. Those types of things need to be remembered. We still need the agents to have to go through some of those in particular scenarios. And even though they tend to reason differently, as we just pointed out, you do an open-ended thing and you get weird mutations of your implementation in the midst of implementing. Even in those scenarios, we still need to realize where things parallel, we need to do similar mapping, similar functions, because even though it is reasoning different, we are attempting to mimic what we're doing to replace some of the things that we're doing as people in that realm.
(00:49:07):
And I think as long as people either step back to or kind of remember every once in a while it's like, oh wait, what did we do previously? Maybe we need to reapply that type of filter or gatekeeping mechanism to ensure safety or whatever it might be. I think back to some of the, what do they call it, like critical systems engineering, I think is the name of it or something like that, but basically airplane system, stuff like that. And a failure rate of any type is unacceptable type of scenario. And in those situations, like you could have AI build things for you, but you still need to go through that very rigid, heavily audited system for anything to be built. And in the same sense, like if we want good, reliable production systems shipped out to production, it still needs to go through that rigor, whether it's a person doing a step or not, or an agent.
Nicky Pike (00:49:57):
Validation means more here, right? Yeah.
(00:50:00):
And when we say validation, we're not talking necessarily about testing, but validation of what AI writ or wrote, the validation of what AI wrote and making sure that it maintains standards, that it's doing exactly what you want to do, that becomes a very important part. Okay. So AI agents, they're making the wrong types of changes for the wrong reasons if you're not being very specific with them. So what the hell do we actually do about this? I mean, one of the things that you said was treat AI like a junior developer with unlimited confidence. I use the same statement. I like to use all hopped up on Jolt Cola or Mountain Dew, but that's the line that always sticks with me, Adron. Walk me through what that means for how teams should actually do this day to day and get past some of these things that we're talking about.
Adron Hall (00:50:41):
One of the things I've done in the past with junior developers, especially ones that really have a passion for it, are a little bit too giddy sometimes, and they need to burn off some of that energy in whatever they're doing. They often like to propose things at an architectural level that they couldn't possibly really know the ramifications of, but they're trying and that's important. They're probably going to be like some of the top tier talent doing things in short order. And in a sense, they kind of already are because they're being very proactive. However, in those situations where I still need to keep a reign on things getting deployed in an effective high quality way, et cetera, what I would do is set up prototyping scenarios for them. And that's a great situation where you do some open with the generative AI stuff, you do some open-ended prototyping enough so that you kind of bridge a lot of the unknowns and you start to have a iterative cycle of researching, right?
(00:51:38):
And that seems to actually, kind of with generative AI, just like with juniors, it helps people to kind of manage that threshold of jolt COLA consumption and deployment out to production.
Nicky Pike (00:51:51):
Right. I like that. And that gives that exactly what we were talking about back in the training. You're putting that skill into effect. Go out and make, and maybe it's a bullshit MVP, but go out and make this, make the best one that you can. They're going to learn how to work with AI to get that done because if they go out with general statements, they're going to get crap back. But as they learn to iterate through that, I think that's important and I think that's really good. One of the other things that you said that I absolutely ... I want you to walk me through this is DIF discipline is a must here, no mega PR. So you want to see hard limits on diff sizes. What's your actual threshold there and how do you enforce it when you've got an AI that's wanting to restructure five, 10, 18 files for what we consider a simple fix?
Adron Hall (00:52:37):
One of the things that popped up just from the previous statements there was it's kind of a two-way learning thing too, more so for us because we actually do learn and the AI is not technically learning, it's just kind of reorienting what it's going to throw into the auto complete. And in that sense though, we learn kind of its behavior and we know where to put limiters at that point too. So as it builds out prototypes and we're trying to figure out like, what is it going to do if I asked for these things? Is it going to change just slightly if I phrase it differently? Those types of things we need to know when we ask things of it. So it really is kind of a two-way street. It starts to shape how it's going to respond. We learn what that shape looks like and can kind of inform it proactively as we move forward.
(00:53:23):
So that's one of those things where that needs to be part of the process too, is the continuous learning of what we're doing with what the tooling is doing. As I was saying, the answer for a problem might be completely different a week from now at the rate things are going in this
Nicky Pike (00:53:39):
Space.
Adron Hall (00:53:40):
So yeah, that's a big play there, is that two-way part. If we think we're going to get the same results all the time, you've already started with the wrong vantage point with any of this. That's one thing people definitely need to drop and remember, you have to do continuous learning now. It used to be like a nice to have like, oh, the programming language is always going to do the ... The thing the programming language I tell it to do is going to do. Okay, great. And then you can continuously learn about things on the side. Now it's like, nope, you have to continuously learn about what this tooling structure is doing. The language might be doing the same thing if you implement this thing the same way every single time, but none of the gen AI stuff is going to do that. You can literally put in the exact same prompt 10 minutes after you just put it in and it's going to do something different.
(00:54:30):
So that's where continuous learning in this situation has become mandatory. It's not an optional type of scenario.
Nicky Pike (00:54:36):
Okay. So I'm going to call you out a little bit because great answer and I loved everything about the answer, but you didn't answer my actual question, right? There's no mega PRs, you want to see a diff limitation. Is the purpose behind that just to maybe set up the human reviewers so that there's something that they can actually do or is it to limit AI and the changes that it makes that you don't want to see the huge diffs?
Adron Hall (00:55:01):
I mean, really both, right? Because a human's only going to be able to look at so much, right? There's only so much time in the day, so much that you can actually physically read through. And with the AI, probably a higher scope, but still also a limit to what it's going to be able to tokenize and look in its own context window and all that kind of stuff. So you do need to keep those diffs to a particular size to be able to review and get anything effective off of. Case in point, we were just talking about the 2000 line change. That's great. The 2000 lines of stuff. Who's going to review that? When you look at the diff, you see 2000 lines right off. You can look at a little total down there or something and say like, "Oh wow. Oh, it just ripped through nine files, thousands of lines of code." If I start to review this now, it'll be two days from now before I'm actually done looking at it thoroughly.
(00:55:58):
Even if I did it quick, that introduces additional risk and probably still not going to get through it in a reasonable amount of time. Easiest thing to do, throw out the whole thing, all 2,000 lines of code, go back, restart, try to limit the scope and get a diff that's going to be sane like 50 lines. 50 lines is a pretty reasonable amount of code to look at and reason through and make some objective decisions about it like, "Oh, this looks good or this does not look good. It needs a refactor." And then you can just bump in and do a refactor or whatever and you get it cleaned up and have another commit in your PR and boom, you're off to the races, ready to go, you can approve your PR. But yeah, any type of differ that gets excessive in size and a team definitely needs to figure out what that is for them, you might as well just put a hard filter on it, right?
(00:56:49):
If the diff has more than this many lines of code, just fire it back to the AI and say like, "Yo, fire it back to the person that wrote your prompt and say, Hey, I don't know what you're asking me to do here, help me out, rewrite your prompt, give me some clear spec. Because that's what it's going to boil down to usually is the spec's not clear or something got open-ended and it doesn't know how to fix or build out whatever it is.
Nicky Pike (00:57:14):
Makes perfect sense. So along that same lines, are there parts of the code base that you think should never be touched by AI without human supervision? What's your no fly zone list here? What's absolutely off limits for AI development? Is there anything?
Adron Hall (00:57:29):
There is the security paradigm. One of the things I like to make sure of, and this is one of the things that's been a problem for ages and will especially continue to be, if not amplified with AI, is you need to have basic hygiene around your environment variables, your secrets, how you're managing them, and probably even more so now than ever before, because one little leak or issue gets into the code base and then you're not going to know where it's at. These days you might go, "Oh yeah, I know where I put that key. Let me go take that out of that particular file where I was testing it. " Who knows where it put it? It might have put it all through the code base as like a static variable or something. And the next thing you know, you have this key in like 50 falls.
(00:58:16):
It's a horrible notion. And all at the same time, it might be telling you, "This is not a good practice, but I did it because you gave me the key." So one of the things I do not do is I do not give it keys, tokens, passwords, anything like that. I immediately put things into a vault or into a reference point, like environment variables or whatever, where it is only ever going to reference the MV dot whatever,
Nicky Pike (00:58:43):
So
Adron Hall (00:58:43):
Like a property on an object of whatever that infers or has that particular secret value. If I can't do that, I don't even move forward with AI. So basic hygiene there is an absolute no-go with AI. I don't want it to know the secrets. I treat it like a junior developer in that sense. It's going to reason differently, but it's going to make the same mistakes probably at an exponential 10 jolt colla level down some all nighters type of crazy program or binge type of problems.
Nicky Pike (00:59:14):
We've talked about the individual teams, we've talked about workflows, but there's this industry wide reckoning that's coming and I think it goes beyond just the code based. So in my introduction to you, I mentioned the shinification. This is a term that I actually pulled from you, and it's the idea that code generation is being fast, easy, and designed to be disposable. And I want to dig into that because I think I love that idea and we're seeing that in the industry today when we look at like InfoQ, right? They reported that the Tailwind CSS downloads climbed while the documentation traffic for how to use it actually fell by like 40% and that caused a revenue drop. Stack overflow, same thing, man, 25% less activity within six months after AI launch. We have a lot of people on social talking about this It's increase in productivity.
(01:00:01):
And I do believe that's valid. It is true, but there feel like there's cost here that nobody's really pricing in.
Adron Hall (01:00:08):
Let's just look at the brass tacks of it. AI is pretty inefficient at the point of view of how much energy it's using, how much water it uses, because we need data centers that need cooled, all sorts of things like that. We don't have the energy to actually feed the growth of a lot of the processing compute that we need. So it's got compute issues in that regard. So there's a lot of things kind of on the back end that are shielded from a lot of its use.
Nicky Pike (01:00:36):
So
Adron Hall (01:00:37):
We're just using OpenAI or we're using Claude or whatever, but are we really thinking about what a token means? What does a million tokens mean as far as what river is being drained out basically or the water temperatures being shifted and setting fish ecology off the scale? What are we doing in regards to this? We don't have a direct connection to that to see or to know.
(01:01:05):
Hopefully things get more efficient. They need to, they desperately need to because we probably can't build out the way a lot of these talking heads seem to want to talk about this stuff. So we have to figure out that. But also even leaping away from all of that where we got to figure out how to do data centers better, we got to figure out how to do processing better. We got to figure out how to do all of those efficiencies. But we also just need to, we kind of need to streamline what we're doing with it. At this point, everybody's doing kind of everything, trying to figure out what type of ... A lot of people are calling them like AI operating systems.
Nicky Pike (01:01:44):
And
Adron Hall (01:01:44):
I'm like, okay, you're really just trying to do orchestration, so let's figure out what your orchestration is. So everybody is building their own orchestration tier at this point, because it's so not defined that that's what we're in the stage of doing at this point because of the magnitude of what it's enabling us to do. That was just, oh look, we wire up our servers and our networking faster, like exponentially faster. But that's just one part of a thing. Now, we're doing all the things with a prospective 10X on it. We're doing 10X DevOps. We're doing 10X dev. We're doing 10X product. We're doing 10X sales cycles. So how do we even scope that? How do we figure out how that's going to work? And I think that's one of the places where we're going to have to kind of have that match to what we actually have resources for as we figure out how to make things more efficient.
(01:02:41):
And I do think there's a lot of efficiencies to be gained just like, oh, I just spaced the model out of the CCP, out of China where they were just like, "Oh, we did this thing and it's basically as good as OpenAI." Yeah, yeah. There you go. That one where there's like, boom, this works just as well and it's nothing in cost by comparison. Major impact, right?
(01:03:05):
Yep. Even just the implication of it. Let's say it wasn't all that it's cracked up to be, but the implication of it, just being a thing, being a process, being an option, shifted how a lot of things were working. NVIDIA had a little hiccup in its stock price, OpenAI, they had to make a bunch of announcements about how, "Oh, they're not a threat, blah, blah, blah, blah, blah." All this kind of stuff. We still need to spend $40 billion a minute or whatever, whatever it is that they're spending. So those things definitely need a coming to terms and we need to figure out how we're going to manage our finite energy production, our finite actual resources mapped to what AI is doing for us and what we're requesting of it.
Nicky Pike (01:03:52):
Well, and you said something there that I'm going to speak on and it's going to lead me into my next point here, but you talked about how we've got all these different tools and everybody's trying to do an orchestration. And I think that's one of the places where we're sitting. Everybody's trying to make a vertical stack. They want to contain people to use their tools. And there's very few out there that are looking to orchestrate across agents, across LLMs. Now, if you want to be able to plug and play your agent, you want to be able to plug and play. I know a guy, come talk to me. We could talk about how you do this horizontally versus vertically. But I do think that one of the things you brought up there is, there's a comparison, and I think you made this comparison about going to Uber.
(01:04:30):
In AI right now, we are in kind of this VC subsidized phase of AI. We've got these prices that are artificially low, we want to drive adoption, and we're seeing AI native spending is doubling year over year according to the Zilo's 2026 index. But at some point, the subsidies for this, and people are going to get hooked, right? Here's your first case, now you're going to get hooked, and the bill's going to come due. How bad do you think the correction's going to be when the subsidies ends and people really have to start paying for what we're doing here?
Adron Hall (01:05:00):
That is a very good question. We're trillions in the whole on what is considered good state of operations, good state of maintainability on a lot of things. A lot of the bridges are in a place where they're very close to putting a signup that says, "Don't go on the bridge anymore. It's going to fall down any minute." That has been subsidized for decades and decades and decades. I see in other industries that happens and the government and AI has started to put in massive funds. So not only is the market putting in massive capital, the governments of the world are starting to put in massive capital to this AI thing that they don't really understand. They don't have a scoping on it from a national perspective. It's just one of those things to win the CCP, the US, all these governments are doing it. So what happens when they start to pull it?
(01:05:52):
What happens versus the capital drying up? We've seen capital shocks where 01, when the first internet bubble burst, right? That was pretty catastrophic, but there wasn't 40 million people doing programming then. There was like 1.2 and then 50,000 people got laid off and that seemed catastrophic. It wiped out billions and billions and billions of wealth.
(01:06:17):
We're at like a hundred X that just in the tech industry and we've seen some layoffs, but then the capital is being flooded in for AI, a part of tech, not even like the whole tech industry. And the governments are getting into it too. So when one of those starts to dry up or become unmaintainable, what happens then? It feels like there is a hundred X shock waiting to happen that would make like that initial tech bubble burst seem like nothing. And being that so much of the industry is focused on that capital investment from a, where are we making any money at all type of perspective, it is worrisome. I don't know when that's going to play out or how it is because there is that added nation state investment that changes the whole paradigm because they could change money flows and all sorts of things and just make it like a weird, like ongoing state of investment.
(01:07:14):
Almost like roadways and transportation infrastructure have been where you can't just stop investment in that. You have to maintain some type of investment to have modern society operate, period. Well, look
Nicky Pike (01:07:30):
At the prevalence. This is going to be a new infrastructure type. AI is going to be so prevalent in every aspect of our lives that I think we will start seeing nation states treat this as critical infrastructure.
Adron Hall (01:07:40):
Oh yeah. And I think some are, I mean, they have effectively started to look at it that way. I think like for example, the CCP has definitely said like, "This is the thing that we're doing."
Nicky Pike (01:07:51):
And
Adron Hall (01:07:51):
When they say we, it means all of China is going to be invested in this at this point, regardless of what anybody wants. And just by that fact, it kind of pulls along other places, right? They're going to have to invest, but also maintain in some way, best they can, some type of ongoing investment.
(01:08:11):
So just like with the roads, we pay taxes to keep up the roads, we pay taxes to keep up the airline traffic control, et cetera, et cetera, et cetera, all that, we're going to end up with some type of baseline probably tax structure that's going to end up going into these things in the next five, 10 years, something like that. So when the capital dries up and there becomes revenue neutral or at least revenue profitable entities, the revenue profitable entities will probably remain private entities or whatever, but some of those might end up nationalized in certain places, especially in the CCP, since technically anything in that market is sort of already nationalized, but that's where things are going to get real tricky and try to figure out like, do you have your money in something that's going to become that? Because then you probably don't want to have your money there.
(01:09:00):
You'd want to have something in a growth sector of it or something that's going to render some type of profit and be ongoing business of some sort. So
Nicky Pike (01:09:10):
Yeah,
Adron Hall (01:09:10):
There's a lot of avenues there and it's near impossible to figure out like what'll drop out first and where will the balance point come in? And here's the sources that they're available and how they're regionally distributed or however it is,
Nicky Pike (01:09:24):
But
Adron Hall (01:09:24):
They'll set up some type of core baseline thing that they're going to pay for in upkeep and then everything else will just kind of exist off of that.
Nicky Pike (01:09:34):
Well, I've got you for like three more minutes and we've got two more questions. So we round out every one of these with two questions. One's going to be a controversial question and one's going to be a prediction. So I want you first, this is going to be a lightning round, right? So first, let's do something a little controversial. You have stated that you think LLMs will cause a dearth of new innovation. And honestly, when we look at that, it's kind of heresy in today's AI is the future world, but you've also predicted that AI is going to event its own programming language that's optimized for machine communication. It's late 2027, which prediction came true and what are we actually dealing with there?
Adron Hall (01:10:08):
I think it'll be the programming language, yeah, because I feel like to some degree we're close to that already,
(01:10:16):
Just with the starting to really manage scope, really like put variables and specifications and things into place to manage the scope. And once we've done that, we're starting to understand the system we're working with to kind of put some control language context on. We might not do the control language context. We might be able to have AI build it for itself, which is most likely the way we would get it to do that. But I think, yeah, sometime around 2027, we'll probably have a language stack or some type of stack that would be specifically for almost like a DSL,
Nicky Pike (01:10:58):
Specific
Adron Hall (01:10:58):
For AI tooling.
Nicky Pike (01:11:01):
Last, this is the question we ask everybody. So you've been a Polyglot engineer since before AI was cool, and you've worked with everything from Go to Rust to Java, and you've spoken at conferences about this. Now AI is coming up and it's making Polyglot something that is available to everyone. So I'm going to ask you the question that we ask every guest. After all of this, seeing what AI's doing and making all of the stacks accessible, what does it mean to you to be a coder?
Adron Hall (01:11:27):
Oddly enough, I'm enjoying it more these days. I say that with like a weird hesitation because it's not the programming part that I'm enjoying more. I still like to program and I still do ... I'll go do algorithm stuff just for fun just to kind of think through things, stay sharp on that stuff. But what I'm really enjoying right now is the fact that I can sit down and churn out an idea, especially from my experience and my point of view, I can churn out a usable startup idea in like a day and have it deployed somewhere usable in that initial state and be able to iterate off of it. Five years ago, that was a me plus team type of scenario still, right? Yeah,
(01:12:14):
I'll get in there, I'll start working on it, but I'm going to need to grow a team within one to three months, we're going to need to break it out like this, set up the structure, da da da da da, the whole thing. Now, that whole initial three month period where I would grow a team to be able to build out a startup is ... I don't need to start doing that until probably like kind of same horizon as far as like start it three months out, but I don't need that initial team to get that prototype. I can get the whole thing built because all the busy work stuff, infrastructure, et cetera, like because I know what's needed, I can actually get that built out for me without actually needing to bring in a team to do all of that legwork.
Nicky Pike (01:12:55):
So it's bringing the fun, it's bringing the speed back to development for you.
Adron Hall (01:12:58):
Exactly.
Nicky Pike (01:12:59):
That's awesome. I love everything about that. Introducing
Adron Hall (01:13:01):
A new level of speed.
Nicky Pike (01:13:03):
New level of speed.
Adron Hall (01:13:04):
Is what it's doing.
Nicky Pike (01:13:04):
Yeah. And a wealth of possibility, right?
Adron Hall (01:13:07):
Yep.
Nicky Pike (01:13:07):
I love everything about that. So all that considered, Adron, after all of this, can we consider you a full-fledged member of the [Dev]olution?
Adron Hall (01:13:15):
Absolutely.
Nicky Pike (01:13:15):
Absolutely. 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.