Algorithms + Data Structures = Programs - Episode 289: Ben's Updated AI Thoughts

Episode Date: June 5, 2026

In this episode, Conor and Ben chat and Ben gives his updated thoughts about AI.Link to Episode 289 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)SocialsADSP: The Podcast: TwitterConor Hoekstra: LinkTree / BioBen Deane: Twitter | BlueSkyShow NotesDate Recorded: 2026-05-27Date Released: 2026-06-05ADSP Episode 246: Not High on AI?Intro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

Last CPP con, there were several talks about AI, and there seemed to be more about 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 cannot not, you know, inaction is a form of action. and I just sort of look around and I ask myself, is this doing the world any good?

Welcome to ADSP, the podcast, episode 289, recorded on May 27, 2020. 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. I was talking to Jason a couple 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 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 median wage can, you know, can go and buy bookcases at IKEA and have a good life with them, have a better life with them, right? But what we've given up in terms of quality, 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 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 also maybe they compress or sort of hyper extend the tail of our ability to actually write good quality software and a number of practitioners who are doing that in future. I don't know. It's just an 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, 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, this June. But we'll say 10 months. And at the time, I recall, you were nonplussed 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 broke the PRs because they were just, you know, putting so many comments

and nonsense. 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 models had a big step up. And, you know, alongside that, you know, Claude Code, Claude Co-work, et cetera. A lot of things have changed in the last 10 months. What's the update?

I mean, we've heard a little bit in the last 10 to 20 minutes. If you're going to push me to it. I push you to do nothing. We can talk about something else if you want. But I am very curious as a friend. 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 I remain, mostly, finding myself unable to square my ethics with using these tools. 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 and large?

Or all of the above? All of the above, right? So, like 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 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 cannot not, you know, inaction is a form of action. And I just sort of look around 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 wealth is so concentrated that it is, you know, people and companies are now outside of the law. Like just ask yourself what effect AI is currently having on on the, for example, 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 recognize that copy left exists because of copyright. right and at least in the u.s the current position which seems to be clear if even if we don't agree with

it 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 I generated code is uncopyrightable. And it's also, since it's so easy to copy once you can, 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 means, you know, and basically, I don't know with an intellectual property, right?

I don't know. 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 only currently defensible position is to simply not take any AI contributions. Do you actually know what most... I couldn't say. I couldn't say what most are doing. 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 one form of the...

legal concerns. Of course, the other side is that, you know, to ask another question, a question which might make people feel uncomfortable, you know, the question that J.F. 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 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, you know, bankrupt them. Now I've moved further into being actually, in part, responsible for human life, it seems. And so I really do have a moral responsibility.

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 going to 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 going to 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 going to hurt anybody. But all software is not like that. There is some software that lives inside of people on devices that are responsible literally for keeping people's hearts beating. It's kind of a cliche that, you know, engineers, software engineers, people who know how the sausages made, oftentimes are much more chary 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 it's the analogy of like the CEO of Coke not letting his kids drink Coke because he knows what goes into it

people that design some kind of aviation software are like pretty fearful every time they get in a plane not I'm not saying that's a true story for folks to scare the people out there I'm just saying 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 yeah it's kind of a cliche to the point of being a joke right almost but it has some truth to it yeah so yeah so the update is still not a big fan and also to unlike many develop or go ahead

yes sorry you're right I didn't mean to interrupt but I was going to say something else like like it's undoubtedly true that AI is a useful tool 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 only show up in the fully baked system when it's very hard to trace them back to their source. And sometimes LLMs can help with those kind of diagnostics. They're quite good at that, it seems. Or at least, they can troll through a lot more possibilities a lot more quickly than a human.

can decrease the time 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 a It's sort of a Conway's Law thing as well, right? Which is that, for the listeners, the technical structure of 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.

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 work backwards? How do we prevent those from happening in future? This is just, an AI is just the latest tool in this line, right? 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.

Yeah, Connor just thought for like 15 seconds. I mean, yeah, it's food for thought. 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. Yeah. I mean, I completely agree with that. And I guess some of the things, I don't know, am I too optimistic? But when I hear, you know, closing the loop, my thought is like, so you build a diagram,

diagnostic tool for catching stuff, you know, perfect. Put that in like the CICD pipeline. And then ideally, nothing gets pushed out to production with that set of bugs. Sure. You could do that. But you're potentially, 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 CICD pipeline.

maybe and and and you know CICD times are always at a premium we always want CICD 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 across multiple industries where where a given company will have a particular strength in a certain area of testing like maybe you're you know your your quality validation engineers are really, really good, and they catch tons of things, right? But then 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 energy, right? The analogy here actually, I 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 there's 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. Yeah, reactive, yeah.

Which to translate means 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 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 design to catch this stuff.

But that's just solving the symptom. It's not sort of the 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 the CICD 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 going to end up having to, you're going to end up with CICD passing a lot more. And so the whatever, compute or the spend that you have to spend on the CICD compute will go down.

And you're relying on that stuff less because you've got better engineers. 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 a lot of things much easier. But it's not really good at making things simple yet. Yeah. I mean, I have to say, I do find it hard, like, in my brain to square this anecdotal. 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 don't understand what it's doing in the first place so like what is that 100% cognitive debt maybe and but the thing is is like I never have things that you've built for yourself sorry I hope these are things you've just built as one off for yourself and not things that you are shipping professionally well no definitely not shipping professional

But I mean, the one example that I'm thinking about in my head is my array box website, which is like a REPL for different array languages. As of the day, 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, 1,400 hours straight without crashing. And like, 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 been amazing. 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. Well, but it's horses for courses, right. So you're right. It's solved your problem.

And you are benefiting from the fact that your problem is a small problem 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. Well, I mean, I was, I had. a few people trying to hack it at the beginning. Like, I mean, let's try and make the box fall over, folks. I mean, most of the stuff is server side, so there's nothing. 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 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 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 and so it behooves us to do actual engineering now the other things thing to touch on, I forget what you said. You said it in 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 make things simple, 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. 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 they have it easy right they never have to fight fires they know but but that's the wrong thing to take away the thing takeaway is wow you know they never have to fight fires what are they doing to achieve that yeah i guess i guess really 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. Well, I always wanted to do. 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 vibe coding, you know, the next 2.0 device that is going to go, you know. We should interview someone who worked.

at medical devices company and ask them perhaps. Yeah, or it doesn't necessarily need to be medical devices, but, and I mean, I know someone from my local meetup, I know some from my local meetup who works in medical devices, and I think she's using AI in some way. Perfect. I mean, well, perfect. Perfect if they want to come on. But yeah, maybe next time, because, yeah, even for, I think a lot of the stuff people are

excited at Nvidia about using these forms. Or it's also not like, 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 know what you call it. I'm not to say that GPUs are not used in that kind of, yeah, infrastructural software.

But 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 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, like, TikTok's recommendation engine leads to people being on the app, like, way more. Which, you know, setting aside whether that's good for. 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 ADSP thepodcast.com, for links to anything we mentioned in today's episode, as well as a link to a get-up 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.