Ben

Last CPP con there were several talks about AI and there seemed to be more about it in every conference. And in particular, several of the talks started out by saying, Okay, I'm not going to address any non-technical concerns, we're just going to stick to the technicalities. And, you know, that's a very sort of privileged position to take, and I find myself unable to take that position. Man is a political animal, as Aristotle said. You you you cannot not, you know, inaction is a form of action. And I just sort of look around and I and I ask myself, is this doing the world any good?

Conor

Welcome to ADSP the podcast, episode 289, recorded on May 27th, 2026. My name is Connor, and today with my co-host Ben, we get an update on Ben's thoughts on AI the first since August of 2025.

Ben

I was talking to Jason a couple of months ago at a meetup. Jason Turner for potentially irregular listeners. Yes, but continue. And I was saying to him, like, we were talking about like how should we think about the effects of AI in this area, about the atrophy of skills or whatever. And he made an interesting analogy, which is that, you know, so so to a first approximation, today, one cannot buy good quality furniture. Certainly not in a way that one could buy it a hundred years ago, right? The reason is simply that nobody is making that kind of quality furniture anymore. Now, on the flip side, you know, the average person earning the the median wage can, you know, can go and buy bookcases at IKEA and and have a good life with them, have a better life with them, right? But but what we've given up in terms of quality, we've we've gained back in terms of maybe inching up the median quality of life in that sense. But still, there's a market for high quality furniture, right? Right. It's now it's now a high-end market. And I don't want to turn this into the couch episode, but just to say that. And so, you know, maybe, maybe this is the way that software engineering is going. Maybe these AI tools increase the ability of less experienced people to get what they need done with software, right? But but also maybe they compress or or sort of hyperextend the tail of our ability to actually write good quality software and the number of practitioners who are doing that in future.

Conor

I don't know. It's just a interesting thought. Well, this is great, folks. We've entered what will we title this part two of this conversation? Because I mean, let's uh I I want to hear from you more because the last time we spoke on this, if my memory serves correctly, was like August of last year, which was not a full year ago. This is May, end of May, as well as June. Yeah. But we'll say 10 months. And at the time, I recall you were non-plussed about the tools, and I remember you anecdotally said, I think that you were using some kind of code review tool, and it basically, I can't remember if you were on GitHub or GitLab or some equivalent, but it basically like broke and kind of PRs because they were just you know putting so many comments and non-secu. It was just creating more work, it wasn't helpful. What is the 10 months later? Because in that past 10 months, we passed the December of 2025 where all the m models had a big step up, and you know, alongside that, you know, Claude Code, Claude Cowork, etc. A lot of things have changed in the last 10 months. What's the the update? I mean, we've heard a little bit in the last 10 to 20 minutes. If you're gonna push me to it. I push you to do nothing.

Ben

We can talk about something else if you want, but uh I am very curious as a friend what So again I don't really want to make an argument about AI's lack of ability, because I'm aware that it will get better. But but but I remain mostly finding myself unable to square my ethics with with using these tools.

Conor

Say more, is that from the what it's doing to the code, what it's doing to the industry, or what it's doing to just the world in large, or all of the above? All of the above, right?

Ben

So so like I I think I mentioned when we were talking some time before, like last CPP con there were several talks about AI, and there seemed to be more about it in every conference. And in particular, several of the talks started out by saying, okay, I'm not going to address any non-technical concerns, we're just gonna stick to the technicalities. And, you know, that's a very sort of privileged position to take, and I find myself unable to take that position. Man is a political animal, as Aristotle said. You you you cannot not, you know, inaction is a form of action. And I and I just sort of look around and I and I ask myself, is this doing the world any good? I see and part of it, it's not even really AI, it's just this kind of extreme capitalism society we're now living in, where where wealth is so concentrated that it is, you know, comp people and companies are now outside of the law. Like just just ask yourself what effect AI is currently having on on the for example, the the free software slash open source world that that is the bedrock in many ways of of the technical society we enjoy today. Yeah. And, you know, while I am no fan of the particulars of copyright law, I recognise that copy left exists because of copyright. Right. And at least in the US, the current position, which seems to be clear, if even if we don't agree with it, uh so far, is that if if a human didn't make it, it can't be copyrighted. And from the research I've done, that that includes AI prompting. Prompting's not enough to say a human made it. So, you know, I'm not a lawyer, so I simply can't go any further than that, but but it seems to me that a AI generated code is uncopyrightable. And it's also since it's so easy to copy once you can s once you see once you see the behavior of a system, if you can ask your AI to regenerate it, that means trade secrets are also out the window. That me you know, and and and basically I don't know whether wither intellectual property. Right? I don't know. But but what I do know is that probably every form of open source in the world, every open endeavor, has had to make a decision about where they stand on AI. And to my mind, the the only currently defensible position is to simply not take any AI contributions.

Conor

I d do you actually know what most I I couldn't say. I couldn't say what most doing.

Ben

I listen to a lot of podcasts and I've heard people talk about it, but I don't actually know So that is just talking about sort of the the one form of the legal concerns. Of course, the the other side is that I you know, to ask another question uh a question which m might make people might make people feel uncomfortable, you know. The question that JF Bastion asked in a talk a couple of years ago, have you ever written code that killed someone? Unintentionally? And you know, I work on power management code inside the Intel CPU package. If my code fails, it could kill someone. Or contribute to it. When I was writing in games I didn't have these when I was writing in games I didn't have these concerns, pretty much by and large. When I was working in finance, I had more concerns because while it wouldn't kill someone, it could could, you know, bankrupt them. Now I've moved further into like being actually in part responsible for human life, uh it seems, and so I really do have a moral responsibility.

Conor

That is I mean, I've mentioned when I talk to a few people that as much as people might be excited about AI coding, there's always gonna be, you know, do you really want to be in a self-driving car where all the software was vibe coded? Probably not. Probably you're gonna want that code to be hardened and at a bare minimum, like aggressively tested if you've got some AI system helping contribute like design stuff. Anyway, so that there are if you're vibe coding your own personal link tree website, which I myself have done, you know, that's not gonna hurt anybody. But all software is not like that. There is some software that lives inside of people on embedded devices that are responsible literally for keeping people's hearts beating.

Ben

It's kind of a cliche that, you know, and pe engineers, software engineers, people who know how the sausage is made, oftentimes are much more cherry about the devices in their homes, you know. Like most of us probably wouldn't want to put an electronic lock on our front door, for example. Oh yeah.

Conor

It's the analogy of like the uh CEO of Coke not letting his kids drink Coke because he knows what goes into it. People that design some kind of uh aviation software are like pretty fearful every time they get in a plane. Not I'm not saying that's a true story uh for folks uh to s to scare the people up there. I'm just saying that I've heard stories like that where they're like, oh no, I would never insert do something because yeah, they know how the software works.

Ben

Yeah, it's kind of a cliche to the point of being a joke, right? Almost. But it has some truth to it.

Conor

Yeah. So yeah, so the update is still not a big fan, and also too unlike many d develop or go ahead.

Ben

Yeah, yes, sorry, you're right, I didn't mean to interrupt. But I was gonna say something else. Like, like it it's undoubtedly true that AI is a useful tool in in many areas. One of the places I've seen it being very useful is in diagnostics, right? So finding problems in these systems that we build, which are because there are always problems in shipping systems, right? And sometimes they are they only show up in the fully baked system when it's very hard to trace them back to their source. And and sometimes LLMs can help with those kind of diagnostics. They're quite good at that, it seems. They or at least they can trawl through a lot more possibilities a lot more quickly than a human. They can decrease the time to to root cause an issue. That's true. Like, that's valuable. But in many cases we fail to close the loop, right? Given this very powerful new tool, there is a risk that we say, oh, now we have a new tool for diagnosing these things, great, we'll do that. What we should be saying is how can we prevent those issues from occurring again? Right? And it's sort of uh it's sort of a Conway's law thing as well, right? Which is that for the listeners, the the the technical structure of uh an artifact produced by an organization mirrors the communication structure of that organization. In other words, if you have two teams working on a piece of software, you'll get a piece of software with two very well-defined parts with an interface between them, for example. And so the people who find the issues are on a team, a different team from the people who wrote the code. Right? And so what we need to do is close that loop to say not just okay, finding issues might be easier now, because we can diagnose them more easily, but also actually, how do we how do we work backwards? How do we prevent those from happening in future? This this is just a an AI is just the latest tool in this line, right? This is not this is not this problem is not even AI related. This is a problem of like fundamentally doing good engineering. Once more, Connor will cut that piece out.

Conor

Yeah, Connor just thought for like uh 15 seconds. I mean, yeah, it's it's food for thought.

Ben

I mean Maybe the takeaway is that the fundamental engineering problems haven't changed. Right? That is definitely one takeaway from this conversation, I think.

Conor

Yeah. I mean I c I completely agree with that. And I guess some of the things, I don't know, I'm am I too optimistic. But when I hear, you know, closing the loop, my my thought is is like so you build a diagnostic tool for catching stuff, you know, perfect. Put that in like the CI C D pipeline, and then ideally nothing gets pushed out to production with that set of of bugs.

Ben

Sure, you could do that, but but you're potentially and and and and and that would be good, but it wouldn't be the best option, right, in the long run. Because now you're putting more burden on your CI CD pipeline, maybe and and and you know, CI C D times are always at a premium. We always want CI C D to run faster, right? But now you're you're burdening that you're you're it's the same thing as like testing at the wrong level, right? And this this is another thing, you know, unrelated to even AI, right? This is something I see across multiple industries where where a given company will have a particular strength in a certain area of testing. Like maybe you you're you know your your quality validation engineers are really, really good and they catch tons of things, right? But them being really, really good can mean that the engineers writing the software end up relying on them to find issues which actually should be caught in a unit test before it ever leaves the engineer's machine, right? At a much lower cost in terms of time and and energy, right?

Conor

The analogy here actually that just popped into my head, which probably should have popped in sooner, is my wife's one of my wife's many specialties, but her primary specialty is public health and preventive medicine. And two different types of medical, I don't know what you call them, schools of thought. And the primary one that we live in today is a it's reactive.

Ben

Yeah, reactive, yeah.

Conor

Which to translate means you you have something wrong, you go to your doctor and then you get prescribed, you know, pills or some kind of remedy thing, versus a preventive-based medicine system where you proactively are doing things like trying to exercise and eat healthy and you know, a bunch of things that if globally or even nationally people were to do this, you would end up with orders of magnitude, less illnesses down the road. And it's actually like the better, the more cost efficient, like if you were to invest more in preventative stuff and made sure that people were just healthier, it would be much, much cheaper than the money that gets spent on dealing with disease and illness. But it is from a like a political point of view, and it's also too, it's not the status quo, so that's a whole other issue. It's very hard to get you know institutions to spend money to switch a system from like a reactive to a preventive. Anyways, that's what you're arguing here, which is a great analogy, is that sure, throw some check that you designed to catch this stuff, but that's just solving the symptom. It's not the real problem of like, yes, you know, how about we just train software engineers to have better, you know, software design skills, insert all the other things that software engineers should be better at. And then we won't need to rely on these CI CD systems with, you know, 30 different checks for this thing and that thing, because I mean, it's still good to have those at the end of the day, but you're gonna end up having to you're gonna end up with CI CD passing a lot more, and so the whatever compute or the spend that you have to spend on the CI CD compute will go down, and you're relying on that stuff less because you've got better engineers.

Ben

To bring it back to the engineering realm, again from the medical realm a little bit, it's you know, AI makes things easy, but I'm not interested in easy. I'm interested in simple, right? Same as Rich Hickey is. And AI is really, really good at making things easy. It makes things makes a lot of things m much easier. But it's it's it's not really good at making things simple yet.

Conor

Yeah, I mean I I I have to say I do find it hard, like, in my brain, to square this anecdotally with like a few things that I've done which admittedly I've never looked at the code. So it is probably not great. It's probably bad. There's probably a ton of technical debt. Not to speak of cognitive debt, I I don't understand what it's doing in the first place. So like what is that? 100% cognitive debt? Um. And but the thing is, is like I never built for yourself.

Ben

So not that you I hope these are things you've just built as one-offs for yourself and not things that you are shipping professionally.

Conor

Oh no, definitely not shipping professionally. But I mean the one example that I'm thinking about in my head is my ArrayBox website, which is like a REPL for different array languages. As of today, it's had 2,000 plus unique visitors and 32,000 code evaluations. The little array box server that's sitting on my wife's old laptop downstairs. I think it's been running for, I don't know, 1400 hours straight without crashing. And this, I never had the skill set nor the time to build, but it's something I've always wanted, and it has been like it's it's it's been amazing. Like I always wanted something like this. It brings me so much joy to use it. Is it probably failing all of the metrics and things we just talked about? Absolutely.

Ben

Well, but it's it's horses for courses, right? So uh you you're right, it solved your problem. And and and you are benefiting from the fact that your problem is a small problem with uh with a small number of people, like like it's your solution currently fits your problem space. But if your problem space changes, right, and this is what engineering is about, right? If you suddenly got a million daily visitors, your box would fall over. If you suddenly got attention from hackers and people trying to penetrate the system, you would be well advised to take it down, right? I don't think these are controversial statements. It's a different problem.

Conor

Well, I mean I don't I was I had a few people trying to hack it at the beginning. Like, I mean, uh it's let's let's try and make the box fall over, folks. I mean most of the stuff is server-side, so uh there's nothing you can do.

Ben

But also, like there's not great value in penetrating it, right? You don't get access to, you know, Bitcoin wallets, you don't get access to credentials pretty much, you get to take over one small PC for of an individual. Big whoop, right? It's not a high value target. Which again is like I'm saying, you're living in a problem space that is a different problem space, right? But engineering, if we if we are engineers, we're trying to build these systems that that are robust, reliable, sure they sit in the problem space, but the problem space is much expanded, right? The problem space is often global and it does include all these things. Uh and so it behooves us to do agile engineering. Now, the other thing to touch on, I forget what you said, you said it a minute ago, but it made me think like something else Michael said in a recent talk. If you as a team, as an engineering team, do these good engineering things, if you if you make things simple, if you if you are able to you know not have cognitive debt, not have intent debt, if you're able to become a trusted part of your organization and and fulfill that structural quality and fulfill that functional quality and the process quality, such that you can reliably ship good quality software. What how that shows up is that you don't do heroics, right? You don't have sudden fires to fight, because by doing the engineering you have avoided those things. And so what that looks like from the outside is well, your team is doing things that are easy. Our team that has all these problems, we do much more complicated things than you do, right? This is how people see you. If in fact you do good engineering and avoid the problems, right? You don't you don't you almost never get the benefit because you know other people who are finding their engineering hard because it is complex, not simple, what they are doing is complex, and what you are doing is going for simple, right? What they are doing may be easy, right? Because easy is a relative term. It's what they know how to do. But you know, when you see a team, when your team is struggling with complexity and and you are not recognizing that, and you see a team doing things simple, then the natural the natural thing to think is, well they're they have it easy, right? They never have to fight fires, they never but but that's the wrong thing to take away. The thing to take away is wow, you know, they never have to fight fires. What are they doing to achieve that?

Conor

Yeah, I guess I guess really the the maybe that's why maybe that's why I've been so excited about these tools is because I had a bunch of personal projects. That well I I always wanted to take the microphone. They've been very good for that, it sounds like. Yeah, and I was able to build those. But yeah, I guess what would I what would my take be if I worked at like a medical devices company? Probably I would be a lot less excited because even if it was helping me to do certain tasks faster, there's no way I'd be vibecoding, you know, the next 2.0 device that is gonna go, you know.

Ben

We should interview someone who works at a medical devices company and ask them, perhaps.

Conor

Yeah. Or or it doesn't necessarily need to be medical devices, but and my case is banged from my local meetup.

Ben

I know someone from my local meetup who works in medical devices, and I think she's using AI in some way. Perfect.

Conor

I mean, well, perfect. Perfect if they want to come on. Uh but yeah, maybe next time. Because yeah, even for I think a lot of the stuff people are excited at NVIDIA about using these for, it's also not like what what do you what do you call like critical software? You know, that like lives are dependent on infrastructural engineering? I don't know. Yeah, I don't I don't know what you call it. I'm not to say that GPUs are not used in in that kind of yeah, infrastructural software. But I I think a lot of the things are kernels that are used for machine learning and AI stuff, which at the end of the day, maybe, you know, but kind of feeding itself. Yeah, yeah. It's like this like snake that's eating its own tail. And even if it's not like in the AI loop, you know, a lot of the machine learning stuff, it's for like, you know, the classic example that was used on the team that I used to work for was like, you know, recommendation engines for like, you know, Netflix showing you what you might like next. And like that sounds like, oh, why is that that important? Well, you know, if you have a really good uh like TikToks recommendation engine leads to people being on the app like way more, which, you know, setting aside whether that's good for society or not, is good for the company. Probably not. Be sure to check these show notes either in your podcast app or at adspthepodcast.com for links to anything we mentioned in today's episode, as well as a link to a GitHub discussion where you can leave thoughts, comments, and questions. Thanks for listening. We hope you enjoyed and have a great day. I am the anti brace.

Ben

Um