AI Chipnomics, Open Source Defense and PlatformCon Perspectives

Hey everybody, welcome to the Techstrong gang. It's Friday, happy Friday. The weekend is just about here, but as usual, Fridays they used to be sleepy and now we have all these things to talk about because it seems like lately everybody's announcing something on a Thursday afternoon and things go a little crazy.

I'm kind of missing those old days when things were a little bit soft and easy. But let me welcome our panelists. Jack Palmer, how you doing?

Very good, thank you. Nice to see you. All right.

Tracy Reagan, as always, good to see you. Thank you. Jeff Rich, how you doing, my friend?

Great. Thanks. I'm here to be not easy to follow.

All right. And John, of course, is joining us. And before we jump in, though, we lost a colleague this week and friend of ours, and a lot of us have met him over the years, and probably a lot of you know Om Malik.

John, I know you worked with him at times. I'm going to let you take it from here for a minute. Yeah.

So I met him in New York, so we worked at Forbes together and he was kind of an outsized personality. He was one of the original people, I think, on Twitter to have a million followers. He was a huge figure in tech journalism and also in India, where he was from, and he traveled mostly.

But as Mike can attest, he was a lovely guy. He loved life. He loved life maybe too much at times.

He had a heart attack about 15 years ago, and he recently passed away just a few days ago at 59. And there's a lot of outpouring of grief, but happiness about memories. And he supplied people with a lot of happy memories.

So I don't know if you have anything you want to say, Mike, but we're going to miss him, and he had a nickname, we called him Opie, and he's just a wonderful guy. He just gets a massive amount of credit for creating a lot of work for folks over the years. When you think about how many people at times worked for him or worked on different things that he was a part of or that he led, the industry owes him a lot, both on a personal level and collectively in terms of how he advanced the conversation and everything he touched had some value.

And so it's a big loss to all of us and hopefully there's shoes to be filled. But we're all reaching a certain age, John. It's about- Yeah, that hit home to me.

I had a conversation with somebody earlier who moved from Colorado to New York to be with her father, who's 73, and she talked about how people reach a certain age where their friends start leaving them. And we talked a little bit about that, and it's like life is full of karma and weird things happenings. And then just shortly after that I heard that Om had passed away.

And it strikes hard at home to all of us and just enjoy life while we can. There you go. Because one of us eventually will have to turn out the lights, but hopefully not anytime soon.

All right. Let me jump into the news of the day because, well, things are just rocking and rolling as always. OpenAI says it's going to build its own chip with a little help from Silicon.

I mean, with a little help from Broadcom, sorry. And this thing is called Jalapeno, and what we're after here is apparently to reduce their dependency on Nvidia. And I guess I don't know exactly who the foundry is going to be for this thing, I think Broadcom's going to help them with that part.

But at the same time, Qualcomm was out here in New York this week touting their push into the data center with processors. And they are touting some of their both AI accelerators and CPUs that they're going to be building that can serve as inference engines all the way into 2028. And then they did one better.

They bought a company that has a software stack that competes with Nvidia and CUDA and basically can run on any kind of class of processor. And Qualcomm is saying they're in it for the long haul and don't count them out because from their perspective, it's never too late for Qualcomm to enter any market. And then just to make things a little more interesting, there are reports from TMSC is going to increase prices on processors, and maybe that will push people to go look for other foundries out there and other places to go look for these things.

But John, I put it all together, and I just kind of marvel at this a little bit. I can remember when semis were sleepy and something might have happened every year or so, and now it feels like something's happening every few weeks. But what's your take on what's going on here?

Yeah. It's accelerated. Actually, I won't step on Jack's comments about this because I did talk to him a little bit about this and this higher pricing pressure and this industry you deemed as brittle.

I think you're really right. It's moving faster than ever. And on top of this, we had the Apple Intel news, which in a sense colors this.

But going back to OpenAI and Broadcom and Jalapeno. Yes. It's the hardware pipeline for OpenAI.

They don't want to be as reliant on Nvidia, but they're not alone. They're just the latest to bypass Nvidia's supply constraints and high prices. I think Meta, Amazon, Google, Microsoft have all deployed some sort of proprietary AI processors.

And Anthropic is supposedly doing the same thing. The Qualcomm news, as you mentioned, Mike, and then TSMC. So there was a report out that they want to raise prices across their entire advanced manufacturing portfolio, which would put pressure and squeeze margins for folks like Apple, Nvidia, again, there they are, AMD, Qualcomm, Broadcom, et cetera.

I think was it yesterday, Thursday, Apple announced a price hike across its Mac, iPad, and home device lineups. So you're starting to see the ripple effect, and then that's going to impact ... the consumers, it's dizzying.

And just today there was even more open AI news, but we won't go into that. But in a sense, I think something, Jack, you mentioned to me, which I found really interesting, is that economics are changing in such a way that in this industry, probably for the first time, prices are rising significantly because of supply and demand rather than inflation. I thought that was interesting.

Yeah. Let's go back a little bit. I was actually active in the custom ASIC industry back in the early '90s working for startups designing their own custom silicon, and at that time you had seven, eight different fabs.

I had chips made by NEC, by IBM, you had TSMC was just started, there were a number of Israeli fabs. There were lots of different places people could go to get their custom silicon built, and that has devolved now into a very small group of vendors. Really, if you're doing high-performance computing, let's talk about AI is obviously the big thing.

If you're looking at chips that need to be used, the very smallest of feature, three nanometer, five nanometer, two nanometer processor, choice now is TSMC and now Intel. That Intel is sort of getting back into the fab business. That gives you a duopoly there.

And then if you look at that as a compute system, you need storage to go along with it. You need memory and SSDs, which are really just another form of memory from a silicon perspective, and you have three vendors there, SK Hynix, Samsung, and Micron. Micron being US, SK Hynix and Samsung being South Korea.

So you have a duopoly, triopoly controlling the entire silicon business. Everything else is just design. Nvidia designs chips, Intel designs chips, AMD designs chips, Apple designs chips, but they don't manufacture them.

And because there's this very tight control of the manufacturing system, the supply chain, that gives them incredible pricing power, and they are now starting to rise prices. And it used to be Gordon Moore's famous rule of the computing power doubles every 18 months, and that also came with a cost reduction or your compute power stayed the same. Your compute power doubled, but the cost was relatively stable, and that is now changing.

For the first time, we actually do see supply and demand taking effect in the silicon industry, and I just find that fascinating. Are these costs going to get passed on to our typical IT organization? Because we're talking about silicon here, but Jack, I don't know, what's the ripple effect as you look at this down the line?

Well, we're starting to see it right now in simply not from the vendor side, not from the silicon side, but in the supplies chain side. AI is sucking up so much memory, DRAM, that DRAM is now getting harder to find and therefore more expensive for consumer applications. And this is part of what's driving Apple's going to end up having to raise prices on all of their devices, laptops, the phones, the iPads, because it simply costs so much more to buy a chunk of memory to put in your consumer device.

Now, most consumer devices, you think about TVs and cameras and stuff like that, they don't need high-speed memory, but your laptop and your iPad and your phone probably do. And so that's where you're going to see the price hits come into play. And I think traditionally we've seen, and it'll be interesting July 4th sales, whether we see it or not.

Traditionally, you see a big push at the end of the year in the Black Friday, Thanksgiving, New Year's, sorry, Christmas sales, that prices get pushed down. Everybody wants the big sales and a lot of new announcements. I'm not sure we'll see that this year because this AI is going to continue to suck up as much memory as it can.

And expensive. And it's really gotten expensive. I feel like we're watching the process.

We went from experimenting with AI to industrialization of AI, right? And so these stories are just about the cost of AI infrastructure. It's just no longer about who has the fastest GPU.

It's who controls the full stack, the chip, the software framework, the memory supply, the foundries, and the ultimate cost of running AI at scale. And I think that's why there's new entries into this. And we need to disrupt it, honestly, because we can't afford to use AI in the way it looks today.

At CDCon, there was a really good presentation by an individual from Brazil who works for one of the largest banks, and they were trying to use AI to better manage and secure their CI/CD pipelines. Something you think would be fairly simple, but they had to scrap the project because the tokens were costing too much. So now it's becoming a board discussion, right?

It's a bottom line and board discussion. So we went from experimenting with it to trying to use it, and it's very costly. And that's your ripple effect that you were looking- Yes ...

at talking about. And that results, I believe, in even more downstream effects, because it's certainly, it's supply and demand, but there's also a certain amount of they're raising their price because they can. Because if you think about it, Jack, with what you described, there was no reason, I'm going to use one example, consumer.

I can't see a reason for Apple to raise the price of their current three-year-old Apple TV device. They raised it by what, $270 or something in that under 100. But they're coming out with a new version in October That they are all but ceasing production on the current one, but they're raising the price anyways.

So there's a certain amount of they can, so they will, and they're going to let somebody else be a loss leader and try to make it up in that, I believe. I now, by the way, when I type the word inflation, I capitalize A and I. I add an I in the middle of it.

And that's now how I look at inflation, with a capital A-I in the middle. Yeah. But I think the competition's really good.

The organizations are raising prices now because costs are higher, but because they can. I welcome the competition because, Jack, I would disagree with you. I think retailers still can't resist finding a way to say, "Here's a discount for Black Friday," and everything else around it.

I think there will be that, but I think you're going to find that those discounts are really going to be in... There are certain segments that won't have those discounts, or they won't be nearly as much. Like laptops are not going to be discounted a lot because laptop memory is not cheap anymore.

Right? And if you want your generic $300, $400 laptop, that probably maybe is not affected by it. But if you're talking the higher-end laptops that businesses use or engineers use, those are not going to get discounted nearly as much because the component cost is just so much more this year.

And that will potentially slow down the adoption of AI because it's no longer just about- Yeah ... building a smarter model or a better chip. It's about building cheaper and more controllable infrastructure to run AI, and that's where we've got to get to in order for this to really take off.

And it feels like it's taking off now, but when I hear stories that the tokens are kind of choking people out of using AI, it makes me realize it's time for disruption, right? Well, and something- It's time for a new way to do it. Something you said earlier, which I think is a very astute observation, is we've moved into industrialization of AI.

But one of the things we did is we jumped from prototype to industrialization over the course of months instead of- Literally ... what is typically years. Literally months instead of years.

And that did not allow the entire supply chain to understand and accommodate for, build a supply chain, build in a ramp curve for building the components necessary for AI. So everybody is chasing this and is falling behind, rather than predicting it and building in advance. I remember- I can argue this is a good thing.

" And this is called fundamental economics of IT, so Jeff is what's old, new again here. Absolutely. And you may have missed, I was pointing to there's a processor that comes along with what you're doing that we are using less of, to your point, that we need to use more.

There's some things we can still do ourselves or write a script to do it. And why would you invoke AI when you can write a script? But also when you want to use expensive tools, consider when and how you should be using them rather than buying a token for every single process you're ever going to do.

It doesn't make sense. So I think it's a good thing for two reasons. I think it's going to help us manage how we use the new technology, because it is still new.

And it's also going to, I think, introduce more competitiveness, which in the long run should result in downward pressure on pricing when it's done right. But at the same time, these companies are trying to challenge NVIDIA, they all run into the same reality. Advanced chip manufacturing is scarce, expensive, and heavily concentrated in a few companies.

So we go back to that same problem every time we try to solve this, is the chip manufacturing is a issue. And I think some of the things that this administration has done with allowing more chips to be sold to other countries, let's just put it that way, is going to just increase the problem. Yeah.

So it always goes back to the chips, right? Also, I'm wondering if in a more broadly, the consumers are going to start blaming AI again as a scapegoat for higher prices. It already happened when Apple made its announcement.

Literally within minutes, Bernie Sanders, and I'm not going to go down this road, but he criticized Tim Cook on multiple levels. But again, it's the data center pushback, the infrastructure costs. There's this animus that's towards big tech and AI companies in particular, and now I think there's going to be this blame of affordability and inflationary prices because of AI indirectly.

Yeah. I'll go a step further, John. Let me ask you this.

Hmm. Should we be worried that we're going to have an era here where there's going to be AI haves and AI haves nots, or- I think we live in that era, and it's inescapable wherever we look, Mike. It's like tech, it's a major sporting event.

Like you look at the Knicks games, you look at World Cup games where we have the Marie Antoinette crowd, they can eat cake crowd. I live in the Bay Area, and for last night's Australia-Paraguay game, or actually, I'll even go forward. For the US-Bosnia game here on Wednesday night, the cheapest ticket I saw in the nosebleed was 4,000.

We've kind of reached that stage now, right? With the haves and the have-nots, and it's almost like we're being hit over the head with it. It's not intentional, but we're always around that, and I think the Altmans and the Zuckerbergs of the world, the Bezos, they're just part of this larger picture, right?

Where only a few people can afford really shiny, cool things. Either that or just don't root for teams in the Bay Area because you don't have as many AI people running around. But what do I know?

I know. Are we getting visions of Les Mis coming up here in tech? Wow!

Well, Silicon Valley's always had a reality distortion field- Yeah ... that they would just add to it, so Yeah, exactly. But, it's just this whole kind of notion, and I think AI's become a convenient scapegoat for all the great things it's going to do for us in the long term.

In the short term, we're all fixated, and the politicians with the midterm elections coming up, this is going to be even more pronounced. We're going to blame them for the higher costs for our energy prices, our environment under assault, et cetera. And I'm not saying this is responsible, this chip situation, but it feeds into this larger narrative.

Right. Well, it's convenient for the politicians to have somebody else to blame for the economy or whatever else is going on around affordability, right? That's part of it.

Well, they always love scapegoats. They always love boogeymen. So they've got one here, and they had social media for a while, now they've got AI, and they can pretty much pin the blame for almost everything on it.

And, I'm not saying all of their talking points are invalid, but I think they're using this as a kind of a convenient escape or scapegoat for talking points. There you go. I'm going to leave this here, but as somebody described it to me the other day and said, "The problem with AI is too many people are driving Lamborghinis to Home Depot, and they're not bringing their pickup trucks, and that's what they need.

" All right. Let me shift the gear here to another topic, though, that is something we've been tracking. 0 initiative for remediating open source vulnerabilities.

And I'm not even sure how to pronounce this thing. I think it's called the Acredis project, but they're not the only ones. There's a lot of folks out there that are creating various projects to either help the maintainers, which is what the Linux Foundation is trying to do.

And then there's other initiatives that are designed to help enterprises where they're going to get support from various organizations, and that can be Hero Devs, Chainguard, and a bunch of these other folks. Red Hat and IBM are also in that business as well. Tracy, what's your read on what's going on here with this stuff, and is this the Bullwinkle moment this time for sure, or is this one of many and we're just kind of throwing stuff at the wall and hoping to see what happens with all these vulnerabilities?

Well, I think this first started when MITRE was somewhat defunded, and CISA and NIST went away. The folks and the thought leaders at OpenSSF started getting a little concerned about vulnerability databases and what would happen to them in the future if the government just decided to stop doing it. So that conversation begun, and at the same time, the life cycle of a vulnerability has been compressed with AI.

AI allows attackers to really exploit and weaponize weaknesses much faster than they used to. It used to be 10 days, now it's six hours. So, Acredis kind of is an attempt to create a coordinated response model for critical open source projects before these vulnerabilities become public crisises.

I've been actually asking for a centralized FEMA-like response for years now, so I'm supportive of this effort. But, I do have some concerns about it because it is a separate foundation from the OpenSSF. So there's a kind of a governance issue that shouldn't be ignored, and that's the potential impact on OpenSSF and its premier members.

Because many of the organizations supporting Acredis are so deeply involved in the OpenSSF or already fund some Linux Foundation Security initiative. And OpenSSF has spent the last five years building community trust, best practices, standards, open source projects, around security, right? So if Acredis creates a kind of a parallel structure without a tight alignment to the OpenSSF, then premier members may have to explain why they're paying to be part of multiple Linux Foundation efforts addressing the same broad problem, security.

And, we also have to remember too, and they're not covering this, but vulnerabilities are only one part of the attack chain. The vulnerability may open the door, but credentials and tokens and CI/CD secrets and package publishing rights, those are what allow the attackers to move deeper and escalate privileges and persist. So we still have to address that, too, in open source.

But anyway, those are my thoughts and I'm kind of hoping that there's a recognition that open source security can no longer be handled project by project or company by company and scanners. So the next phase of this software supply chain security has to combine some level of coordination and open source maintainer support, which they don't get a lot of, and kind of a responsible disclosure on how to fix these things fast. And I believe that that's what the Linux Foundation's trying to do.

I just wonder about its impact on OpenSSF. I'll be blunt about it. I've talked to a lot of maintainers recently.

tv about this. They're flat out saying that a lot of the money that goes into these foundations does not find its way to them. And basically, there's too many hands in the middle, and they don't know where that money went and for what, but basically they're sitting there saying, "I got a nickel from somebody to go maintain patches of this stuff.

That's not nearly enough. I'm not getting paid to do this. " So, if you're not going to write me a check to go maintain that, I'm just basically get around to it when I get around to it.

But Jack, I know you follow security close enough. What are you hearing? What are you seeing?

I hear some of that. I also see, and maybe I misinterpreted this, but the one thing I saw that was interesting from the developer perspective about Accredis was for them to become essentially a front-door clearing house for all of the, particularly the AI-generated, vulnerability or bug reports. Right?

" And they get 150, 200, 500 reports that are all variations of the same flavor. And so if I understood what Accredis was going to do, is part of what they were going to do is become a sort of a clearing house for that, and they would score and do CVSS and other scoring and help with that. Which would really take the burden off of the smaller, less well-funded developers to then be able to go and say, "Okay, somebody has looked at this.

'" Now they can put that in their pipeline to go fix. So if I understood that correctly, is that correct, Tracy? It is.

They really want to be a CNA, a numbering authority- Right ... for CVEs. And I think that would help.

" Actually, I wish I were confused on this, but it doesn't make any sense. And I'm not against the effort. It is good.

I think it's better than not having it, and I'll certainly go along with that. My concern is twofold. It pretty much says, boy, the vulnerabilities we need to look at are with open source, and we talked about boogeyman in the earlier segment.

Open source used to be a boogeyman. It's kind of come away from that. I'm concerned it's kind of drifting towards that again because even with Accredis, even with consolidating everything and aggregating it and having numbering, which is good, there's still a whole bunch of holes.

It's a dike with holes. It's not a full dam that's going to block everything. So my concern is there's maybe a false sense of security with, "Oh, I got all the numberings addressed.

I patched it. " And that's not good enough with open source right now. Actually, it's not good enough with proprietary systems either, because we're looking at more than, to Tracy's point, we're looking at more than just vulnerabilities.

So the bigger picture, in my opinion, is not yet being addressed. This is a good baby step forward. It's something that needs to be done, but nowhere near far enough talking about secrets, cache secrets, credentialing, and tokens.

We haven't looked at token compromises, but those are there as well, and you don't see any of that in here, especially associated with AI. Mm-hmm. Jeff, can I ask-- Oh, sorry, Mike.

Jeff, so you've kind of pointed to something that I wanted to ask just in general of whomever wants to answer it. But how do you distinguish this from, say, an initiative like the Athena Coalition or Project Lightwell? Is Accredis- I was going to ask the same question ...

distinguishing itself through scale and backing, or is that what makes it different? To me, they're almost interchangeable, but I'm just trying to wonder if there's something higher. Yeah.

Well, my read on it is the other projects are an effort to basically require the enterprises that use open source software to pay for some level of support for these projects, and whether or not any of that money makes it back to the maintainers is dubious. And then this project is more for the maintainers themselves, who are trying to figure out how to deal with all these requests for fixing vulnerabilities and patches. And a lot of them are not security experts, they're developers, and they didn't really build stuff with a whole lot of thought through about what exactly a vulnerability might be or where it lies.

They were just building some software for their own edification and sometimes joy. And, so it's just kind of trying to split this thing. 5 million invested by cloud service providers who make billions off the back of open source software.

5 million was a joke, and now it seems like the Linux Foundation is now not disclosing how much money is behind this whole program. And when it comes to vulnerabilities and patches, money talks at the end of the day. Tracy, what do you think?

Well, I think that there has been money put into this to solve this issue. But we keep ignoring the fact that we have a dependency forest, and it frustrates me that we see money going into this. So let's take Alpha Omega, for example.

They could have gone out and initiated some research projects on reachability and de-bloating on some of these open source tools. If you look at Java and Python, the number of packages they bring in is over the top And we constantly think about fixing vulnerabilities as opposed to trimming the forest down. We have a forest fire, and what we need to do is clean up the forest We have houses with tons of trees and bushes surrounding them in a high forest area.

So I get frustrated that we're not talking about that as well. There should be funding from the Linux Foundation, and I think IBM's Lightwell is going to try to address this, on reachability and de-bloating, because the fewer things we have in it, the fewer vulnerabilities that developers are going to get. So that's my thoughts.

I think that it's important that what they're doing, but at the same time, they're not having a discussion on how to minimize the amount of packages that we do consume in order to minimize the vulnerabilities that these teams are trying to address. Mm-hmm. And I think, Mike and Tracy, you sort of talked about something, which is, are we talking about helping the producers of the software or the consumers of the software?

And those are two different audiences, right? Mm-hmm. And I think, if the producers of Credence can help reduce the producers of software, that's a very good thing.

The consumers of the software have two problems. One is, as you mentioned, there are a lot of people making a lot of money off open source software and not giving back to that community, and giving back more, I think, would help. The other thing is, vulnerabilities in software and open source, as both Jeff and Tracy pointed out, isn't the problem, or isn't the only problem, right?

And I wrote a column earlier this week about the FortiBleed attack, which was 86,000 Fortinet devices that were compromised or potentially compromised through a leak of passwords, where it's clear that most people aren't deploying MFA, which we know will solve a huge portion of this problem, and are reusing passwords. And in fact, these passwords were involved in previous credential theft and credential dumps, and somebody said, "Oh, my password to my internet router or my internet firewall is open and available to the world. " If we can't get people to change passwords or put in MFA, then software vulnerabilities doesn't matter.

Right? So the consumer of software, guys, there's a lot of attention on vulnerabilities today because of Mythos and because of the Open Source Foundation efforts, but that's not the only thing we have to pay attention to. You know, Jack, you and I have been in security for a while, and I remember a term that I would have to say every day just to make sure I was focused on it, and that was attack surface.

Yes. And Tracy, you just referred to that with bloating. The larger your attack surface, the greater your probability of having an attack be successful against you.

Reduce your attack surface. No one's talking about that. In fact, if anything, to Tracy's point, we're pumping it up.

Yes, we are. AI actually will consume more packages in it than you really need, because it'll put functions in your code that you don't necessarily need to use, because you could write a function that it could itself write a function that's better than calling a package, right? So we are pumping it up.

All right. I'm going to have to move along here, but one of my to-dos for this weekend is to come up with a list of all the things in the world that are bothering me, that I'm spending money on. I'm going to create a foundation for each one of them.

Oh, I think we should have a foundation for reachability and de-bloating, quite honestly. We'll call it GasX for software. All right.

So I'm going to shift the final gear here to Platform Con was held in New York this week, and Jack and I were both there with Alan, who's not here today. But it was a great show, I thought, in the sense that, and Alan wrote a column about this, you should check it out on Platform Engineering, but basically Alan is saying the platform is back, and a lot of this is being driven by the rise of AI. And I'll throw this a little bit Jack's way, at least I took it from this to say that we went through this period where developers were gods, and the gods all wanted their own development environments and their own way of doing things, and they all wanted something uniquely them, which became somewhat unsupportable, and that gave rise to platform engineering.

Now, we're seeing the rise of AI coding tools, and maybe the developers are not gods anymore, and maybe the AI coding tool is going to write a lot of stuff because I will express my intent and eventually it will write something interesting, and it may not be perfect yet, but you can see how it's going to get better in time. But Jack, did you get the sense we're here at some sort of seminal moment here in the history of IT? I don't necessarily know that I'd call it a seminal moment.

I would say that I read Alan's column, and I think he got one thing very spot on, which is it's no longer a question of are platforms a thing or are platforms important? It's well understood that this is the way we're doing things, right? And I think he alluded to the fact that platforms around the world, we've had this in a previous life.

Before AI, we did Kubernetes. Before Kubernetes, we had entire platform environments built on VMware and virtualization, and before that, we had microservices. Before that, we had a client server and then there are a lot of different ways of thinking about how you deliver computing environments.

I think what's happening is the understanding now that everything is operating at speed and scale, that we need to formalize things and not make them Ad hoc, right? " And it's becoming a profession in and of its own. And I had a very interesting conversation with one of the younger attendees, who was not a technical person, who was trying to understand what's a platform engineer and where does that fit with DevOps and whatever.

And I said, "Well, we used to have IT operations. " And then we said, "It doesn't work if they don't talk to each other. " And we created this thing called DevOps, and they're all supposed to be one and the same.

And now we're starting to realize that just because you're DevOps doesn't mean that you don't have primary responsibility in ops or in dev or dev and ops. And now the ops side is becoming less of an art form, more formalized, more of an engineering, and we can understand it, formalize it, think about it in a different way, and talk about it as platform engineering and make things work better and teach the entire younger generation how this goes. And so, I was really impressed with the number of young people who were there that were learning about this and becoming pros at this.

There was a woman I met there who was actually formerly a hairdresser or a hairstylist, and she said she went from being a hairstylist to being an IT help desk person and is now doing platform engineering, and I think that's what this is all about. All right. She's building a beehive.

Is that what you're saying? Tracy, what's your take on what's going on here? Because you've been at the front end of this DevOps thing for a while now and it seems like there's this push-pull, yin-yang conversation that's been going on for a while.

But where are we on this thing? Well, I don't know if it's a seminal moment, but there is definitely a change happening. When I talk to people who are doing DevOps and I talk to people who are doing platform engineering, they do see the world in a different way.

And I don't know if platform engineering and DevOps are really competing positions, but I do know that platform engineers are having to adjust and change faster than DevOps people. They are having now to build these golden paths that are going to support potentially different AI models. They're trying to sort out how to build these golden paths for this new development world, while the DevOps side of the house is sort of just saying, "We have a Jenkins process, and that's what we go through," right?

So, I feel like there is a shift happening on the DevOps side to conform more to what the platform engineers are doing, and I feel like that they are more of the essence of the direction that we need to take DevOps than DevOps is the direction to take platform engineering, and they're all very confident in what they're doing. Right. And they think about security from the very beginning.

I really like these people, to be quite honest. Yes. I like them.

They are thinking about the best option for building out these paths to standardize development, but not enforce them to use particular tools. They want to compare it as to a vending machine where developers get to pick and choose what they want to add to their path, and that's what they build out. And when they do that, they enforce many things that DevOps could never do.

But on the other side, DevOps is delivering the software, and we go back to our old ways. So I'm pushing for DevOps to become more like platform engineers, and it is a moment of change for DevOps. To your point about that, one of the presentations was the head of software engineering for FinServ, and he pointed out that when we pushed into DevOps and we gave all these developers their own independent thing, we did not really account for the impact and the cost that has on the rest of the IT environment.

And he's saying one of the reasons that IT is so highly fragmented and so overly expensive and hard to secure is because we enable every developer to go off and create some new architecture, some new platform, and all that stuff has to be get supported. And we're now choking essentially on the weight of all that. Jack, is that fair?

Yeah, I would agree with that, and I think part of the weight of all of that is, again, it comes back to that security question of, and Jeff used that great phrase, attack surface, is when you have 20 or 30 different developer teams creating 20 or 30 different architectures that they've put in place, you have this giant attack surface that the IT and the security teams have to go figure out how to make secure. And if that can be much more, restricted isn't the right word, standardized, formalized, so that you have less variation across your environment, that makes it easier to secure and makes it less heavy and more lightweight, and it simplifies the world. And I think that's what people want.

Yeah. One last thing that also came up at the conference, and I'd love to get Tracy's thought on this. The deputy CTO for DX was there, and he was talking about, according at least with the metrics that they've been tracking across customers using their engineering intelligence platform, he was saying that the size of the average pull request in the age of AI has doubled and shows no signs of getting smaller.

And you got to wonder, is that sustainable at some point? Because we're also having more pull requests than ever. So is something about to break?

We forgot how to do code reviews. AI is just a software developer. If we think about AI as just being another software developer, we always have done code reviews, right?

And you do your own code review before you create a pull request. And younger, less experienced developers don't read their code, and they don't do code reviews. So you do get really big, fat, multiple, hundreds, thousands of lines of code sometimes on a pull request.

In fact, I was talking to some of the Jenkins contributors, and they were saying they're getting massive pull requests. Tons of new pull requests, and they're huge because it's just AI-generated code. So we have to go back to understanding that, great, AI generated the code, but that doesn't mean we don't still practice the same best practices that we've always done.

And code reviews is something we can't forget, and that's why we're getting those big, fat pull requests. It does happen all the time. I have to be the old guy here because I am.

Because after I did programs on paper tape, I went to Hollerith cards. Google me. " And you don't want to have an error on your second card because you don't get a second run right away.

But one thing that was put in place, if you could bring your deck of cards with one or two elastic bands around it, it was going to very likely be good. If you had your cards in one or more boxes, everyone groaned. And this is exactly what you're talking about because it is so bulky and nothing was modularized, and a review of it becomes untenable because you're just too much to look at at once, and all the internal dependencies aren't always visible.

And Tracy, I think that's what you're getting at. Code reviews are required, but you need to make an environment that can help facilitate them, whether it's using AI or not. And without that, a couple years ago, I had a campaign where every speech I did, I had a reference to crappy code, and that's the biggest security problem we have.

I think we're back there. Yeah. I'm going to end this here, but I'm going to connect a couple of dots.

If I look at what's going on with the AI models and the cost of running all of that, and we need better, smarter AI models, and then if I look at the security issues around vulnerabilities and remediation and automating that process, and then I look at what's going on with platform engineering and maybe the effort to have a little more centralized approach that is, shall we say, more cost-effective and maybe a little easier to manage, all of that comes back to software engineers. We need software engineers more than ever. This notion that somehow or other all this stuff is going to magically manage itself is poppycock.

So anytime you start hearing people talking about how we're going to get rid of developers and all those other things, well, as far as I can tell, there's going to be more developers than ever, and the only people who are going to save us from them are the software engineers. So I'm going to leave it there. Hey, I want to thank everybody for being on the show, sharing their knowledge and insights.

I want you all also to stay tuned for the rerun of the Techstrong TV lineup that's coming up right behind us. Have a great weekend, have a safe weekend, and we'll see you all Monday.