#558: Hyper-Personal Software with Python

0:00Michael Kennedy:Every company has one. The little internal tool that Jane built back in 2021, and then Jane left. Nobody understands it. Nobody touches it. There are two unwritten rules around this internal software. First, if it's working, don't change it. Second, if you break it, you bought it. That's Dark Matter Enterprise software. For every app that you can actually see, there are tens of these sitting in the shadows, frozen. Michael Booth thinks that just changed.

0:29Michael Kennedy:He read my article on hyper-personal software and ran with it, writing about hyper-team software. Small teams inside big companies finally building the tools that were never going to get built, or modernizing the ones trapped in the 90s. We cover where this works, where it quietly goes wrong, and the guardrails that keep it from turning into a mess. Let's get into it. This is Talk Python To Me, episode 558, recorded July 15, 2026. Welcome to Talk Python To Me, the number one Python podcast for developers and data scientists.

1:16Michael Kennedy:This is your host, Michael Kennedy. I'm a PSF fellow who's been coding for over 25 years. Let's connect on social media. You'll find me and Talk Python on Mastodon, BlueSky, and X. The social links are all in your show notes. You can find over 10 years of past episodes at talkpython.fm. And if you want to be part of the show, you can join our recording live streams. That's right. We live stream the raw uncut version of each episode on YouTube. Just visit talkpython.fm/youtube to see the schedule of upcoming events.

1:46Michael Kennedy:Be sure to subscribe there and press the bell so you'll get notified anytime we're recording. This episode is sponsored by Sentry's Seer. If you're tired of debugging in the dark, give Seer a try. There are plenty of AI tools that help you write code, but Sentry's Seer is built to help you fix it when it breaks. Visit talkpython.fm/sentry and use the code talkpython26, all one word, no spaces, for $100 in Sentry credits. Talk Python and Python Bytes both now have MCP servers.

2:14Michael Kennedy:Point your AI at 10 plus years of Python episodes, transcripts, and show notes. Free. click mcp in the nav at talkpython.fm and at pythonbytes.fm Michael welcome to Talk Python To Me great to have you here it's a great name I think this is the the Michael square there's a lot of things we can do with this is going to be really fun I think Michael squared is the most I don't think I've ever had a Michael cubed on the show with three Michaels but yeah it's Michaels across the board or it could be Michaels all the way down like turtles yeah it's going to be fun whatever it is and thanks for having me you know what I saw your article. And I thought, oh, we got to talk. So you wrote an article called Hyper Team Software.

2:53Michael Kennedy:And right before that, I wrote a blog post, an article called Hyper Personal Software. And we were both, I could tell we were both thinking kind of in the same ways and your article riffed off of mine. And so I thought, well, let me try to do a little bit of like technical jujitsu here. You wrote an article off of mine and I'm going to have you on the show to

3:13Michael Booth:talk about your article and like I said Michael's all the way down. Your article really resonated when I had a look at it the first time. Yeah well thanks. We're going to talk about we've got a

3:23Michael Kennedy:couple of names here so mine was hyper personal software because I wrote this for me. Yours is hyper team software because the same concept applied to the enterprise honestly is way more powerful than anything that I'm doing although I'll talk about some of the things I'm doing and people can decide that but the potential for what you can do to make companies better and teams work better is tremendous. And I honestly feel like it's an opportunity squandered for a lot of folks. So hopefully you can inspire them to, you know, crack the door open a little bit and see what they can

3:54Michael Booth:do. Coding assistants are changing the world pretty quickly, right? So in good ways and bad.

3:59Michael Kennedy:In good ways and bad and over and over again, right? For example, six months ago to today could be a totally different experience of what's, how things work or how well they work or what's possible and so on. So yeah, it's just, I don't know. It's a weird time, Michael. It's a weird

4:15Michael Booth:time. It is a weird time, especially when you've been doing it for a while. It's very weird.

4:19Michael Kennedy:Exactly. I mean, I've been programmed for over 25 years in tech and I feel like you must be in a similar time journey there. And I don't know, weird. Just so many times I've seen technology come up that, oh, this is the thing that's going to kill programming. This is going to be the end of programmers, UML, drag and drop, visual basic, low code, no code, et cetera. And all those things are fine, but they're absolutely not the end of software. I don't think coding agents are either, but they're certainly the biggest dent that they can put into software is anything that's come along

4:53Michael Booth:before it. Yeah. The speed and scale is sort of interesting, but sometimes you can just do a lot

4:57Michael Kennedy:of bad things much faster. Yeah. I mean, that's a big debate, right? Is it, is, is our agentic coding tools. Are these amplifiers or are they skilled little separate things that do their own work? I think there's a case to be made for amplification to a large degree. Before we get into all that, let's just hear a little bit of background about you. Tell us about yourself.

5:15Michael Booth:I started off sort of academic life as doing a PhD in computational chemistry. I've worked in quantitative finance for a long, long time. More recently, I started the data booth consultancy things. So just the brand for me working as a single consultant and I've been doing that sort of coming out of COVID, I decided to do something different. So yeah, about the last five years,

5:39Michael Kennedy:I've been doing that. Computational chemistry, huh? Are you familiar with a program called

5:43Michael Booth:HyperChem? I think I am actually, that's pretty old. We're talking 90s. I mean, I think we're talking 90s. Yes, definitely 90s. So I finished my PhD in late 90s. I vaguely remember the tool, But I vaguely remember chemistry now as well.

5:57Michael Kennedy:I studied a lot of chemistry and I loved organic chemistry. And I found this program called HyperChem and it was just so incredible. It was like the Google Earth equivalent of complex chemistry. And wow, was it a neat thing to play with. And I figured maybe it's like right around a similar time frame.

6:14Michael Booth:Yeah, I do remember it now that you mentioned it. Organic chemistry was my most unfavorite element of chemistry. That's why I did theoretical because experiments are much easier to control on a computer than real life. And organic chemistry smells bad.

6:28Michael Kennedy:It does. Honestly, I would tell you that probably is the reason that I didn't work in chemistry is like I'd get headaches all the time from like the super volatile chemicals and stuff. I'm like, if I did this every day, I don't know what this would do to me, but it wouldn't be good. So let's go do math. Math doesn't hurt physically.

6:44Michael Booth:Yeah, I did math and computing in a chemistry school.

6:47Michael Kennedy:Give us a bit of information about Data Booth. You've got some nice articles there. You've got some consulting. Yeah, just tell us about DataBooth before we move on.

6:55Michael Booth:As I said, coming out of COVID, I decided to do something different. I've been working for others for a long time. So I thought, and I'd also directly before this been reviewing a lot of models and things that are used in finance. So I thought it'd be nice to actually build some things again. I sort of identified data science as a place to hang out. I did a boot camp in Oakland, actually, in 2017, and just decided this was sort of a growth area. I think that conclusion was correct, as it turns out.

7:24Michael Booth:Working as a single consultant can not always be easy. Being seen are tricky at times. I still wanted to just have a go. It's the first time I've done something on my own. And I've had a chance to do some interesting things. So I worked with a lady who does experiments with horses, for example. And she trying to understand when a horse is stressed, for example. So she had a Raspberry Pi based experiment. I wrote code to control the experiment and then I wrote the code to analyze the results.

7:53Michael Booth:So I guess being small, you can make choices to do small projects. And for me, that was helping out somebody doing fundamental research. And I guess it got me back to my roots a bit. So I've been able to do something like that. And then I've been able to do stuff in finance. Again, I worked for a small media company at one point as well, helping them do some analysis. So it's been fun, but it's also, as I say, it can be hard to be seen when you're small.

8:20Michael Booth:I'm fortunate I have a wife who is happy to give me some flexibility around those things. So yeah, shout out to her as being a great support. I think the connection's a little bit up and down.

8:32Michael Kennedy:I think it's super important to have a spouse who is understanding of those kinds of things, because it lets you do really, really interesting things. Like I can say the same thing for my family as well in a slightly different way. What a cool story about the horse. You know, it's mixing biology and IoT and tech. And that's the kind of stuff that you learn a whole bunch in a real short period of time. But also you can make a big difference, you know.

8:55Michael Booth:I learned a heap. I'd never worked with a Raspberry Pi, for example. So it's quite interesting when you don't play in a space, you don't realize just how far certain things have advanced. So it's pretty cool what you can do on very small devices these days.

9:09Michael Kennedy:That's Data Booth. Very cool. People can check that out. Let's take it out a bit and talk about sort of internal company software. There's a lot of people listen to this show who are not what you would call enterprise developers, right? They are students. They're maybe data scientists kind of on their own or they work at a research or they work at a startup. So give us a sense of what internal software, like these bigger companies, looks like today and like maybe before the AI world and so on.

9:39Michael Booth:Every company is different. And I'm sure you've experienced that as well. Lots of different operating models. But I guess enterprises always need to make sure that things are orderly to some degree. So when I work on my MacBook as a solo practitioner, I can make decisions about what software I want to use, how I want to use it. Ideally, when I'm working with data, you've got to make sure that you've got certain controls in place. But within companies, those things really matter, right?

10:07Michael Booth:So you do need to make sure that things are secured appropriately, that people only have access to the things that you want them to. So I think in that context, there's always going to be sort of overheads and friction on developing any sort of software. So you've just got to be aware that you need to allow for those things. So I think the idea that we'll talk about coming up is the sense that when you're actually working within a team, within an enterprise, maybe there's certain things that you can do that don't need to impact too many other people.

10:39Michael Booth:And therefore, you can achieve a greater degree of autonomy. There's certainly the things that you need to be thinking about within the enterprise. So it's not choose your own adventure. It's a work within the constraints which are appropriately there. And particularly between industries, you can have some industries which have little regulation. And then in other industries, they're highly regulated for very good reasons. But again, that can provide an additional layer of complexity as you start to think about how you develop and what you develop.

11:10Michael Kennedy:I've not spent a ton of time working at large companies. I worked at a company for maybe six months that had 1,200 people. And I got there by being acquired from a company that had 10 full-time employees. So it was a little bit of a shift, but I did do professional software training for a long time. So I taught week-long courses over a hundred different companies. And, you know, you just, you get a look inside these places. You're like, wow, this is, this one is really different.

11:37Michael Kennedy:This is like really unique in this way or that. But the, one of the, I mean, maybe not with the tech companies, but maybe even so, but like for many of the companies, I would say there's, there's two golden rules of a lot of this kind of stuff. One of them is don't change it. It's working. Just don't change it. You know what I mean?

11:55Michael Booth:And there's something to that, right? If it is working, why would you fix it? It can be very expensive to change things, right?

12:01Michael Kennedy:Yeah. So maybe we'll call that the principle of least touching. Like, just don't touch it. It's just leave it. It's over there. Just don't touch it. And that leads to like you're talking about on your MacBook. Like, oh, I could use like Python 3.14 and we could pick, oh, let's try FastAPI. And they're like, that's cute. We use Python 2. You're like, huh, really? Okay. You don't want to change it. No. Principle of least touching. We don't touch this.

12:21Michael Kennedy:It works.

12:21Michael Booth:When I was in a previous company, they were using 3.7, for example. I'm like, yeah, but it's out of support. It's end of life. Aren't you going to upgrade things? And people just stared at me. It was like, why would we? So, yeah, I guess it's the what you should do on paper versus what you do in reality.

12:39Michael Kennedy:Both of those ways are right, I think. Like, you maybe don't want to mess it up because it is working. But at the same time, we had things like Log4J and other stuff where, like, there are really big problems. And it's just because people didn't want to update their software. So the other core principle, I think, is you break it, you bought it. And that's like, if you do touch it and it was working and now it's not working, this is now your problem.

13:03Michael Kennedy:And maybe the person who knows how it works doesn't even work here anymore.

13:07Michael Booth:The person that did it almost certainly does not work there anymore, right? If you look at the stats, I think sort of typical tenure, at least these days, is less than two years. So the likelihood that you're going to find anybody in the team that knows anything is, can be just very, very small, right?

13:24Michael Kennedy:It could be very small. And so that leads to just some interesting gaps or in a more half glass, half full way, like opportunities. There's so much of these little tools and these little connectors and these things or just software that was never built because you don't want to take it on if you build it. and they're just sitting there inside these huge companies that have so much internal software, but they just, they're either really outdated or they're just really ugly and they work clunky, but people just like the person who built it left and no one else can even build it.

13:54Michael Kennedy:So like, be thankful it works, not that it's hard to use, you know? So there's just so much opportunity for this concept of hyper team software, I think.

14:02Michael Booth:Yeah, no, I think there's lots of opportunities out there, but I think like any problem, you want to think through a solution maybe before you start changing anything. I think it's very tempting just to jump in. And I think, yeah, taking a few steps back. And again, just understanding the scope of the problem that you're trying to solve. So like most of life, if you choose a smaller problem to start with, maybe you learn something from it and it helps you as you start to tackle bigger problems.

14:28Michael Kennedy:I think it's also just, you know, as an aside for people who are looking to advance their career, If you can improve these tools and make life better for everybody at the company, that's a really high visibility thing to do. It used to be all the data scientists had this super annoying thing that they had to do. And then you spent two weeks on it. And all of a sudden, everybody's happier at work. And they know that it was because of you. Like that shines a pretty good halo on you.

14:53Michael Booth:No, like there's great opportunities to like make a real impact, I think. And for me, coming out of a sort of science background, and I try and see everything as an experiment in life. And I try and put all of my experiments orderly in GitHub, for example. You can move quickly and you can experiment and you can identify the paths not to go down so that you can actually work out the paths that are worth pursuing. And to your point, yeah, there are opportunities to be seen.

15:23Michael Booth:And you can move from that. I just wanted to draw a diagram on a piece of paper and convince you that this was a good idea to, well, here's the working prototype or proof of concept. And we actually now can talk about, have a real discussion rather than a hypothetical one.

15:38Michael Kennedy:That's so interesting that you bring that up. Because one of the things that I found really challenging working at bigger companies, even not huge companies, so just in general, is you can describe something and people go, oh, maybe that's nice. You can tell them you can do it. And they're like, yeah, probably you can. But then you just take a little bit of time and you show them like, no, look, it's not I could do this. It took me two hours to do this.

16:02Michael Kennedy:If we keep going on it, it'll be really nice. Look, wait, you already kind of did this? Like, this is actually really amazing. I really think that makes a huge difference in how much trust and sort of adoption you get for like your ideas.

16:16Michael Booth:Absolutely. Like in a previous employer, you sort of had the business analysts go, okay, let's draw up wireframes and whatnot. And then we can prove out this and do that. Like, no, we're not using wireframes. We're just building it because it doesn't take very long. And then people can see it, see the real thing. That's not a critique of the sort of BAs at all. It's just the world's changed, I think, from when you used to work like that.

16:42Michael Kennedy:This portion of Talk Python To Me is brought to you by Sentry and Sear AI. There are plenty of AI tools that help you write code, but Sentry Seer is built to help you fix it when it breaks. The difference is context. Seer isn't just guessing based on syntax. It's analyzing your actual Sentry data, your stack traces, logs, and failure patterns. Because it has the full context, it can A, spot buggy code in review and help prevent issues before they happen, and B, identify the root cause of production errors.

17:12Michael Kennedy:It can even draft a fix and hand the work off to an agent-like cursor to open a PR for you. Seer turns Sentry into a complete loop. You have your traces, errors, logs, and replays to see the problem, and now AI to help solve it. Join millions of devs at companies like Claude, Disney+, and even Talk Python, who use Sentry to move faster. Check them out at talkpython.fm/sentry and use code talkpython26, all one word, for $100 in Sentry credits. Thank you to Sentry for supporting Talk Python.

17:44Michael Kennedy:This like, I think leads into where we're going. There's, we're going to build software in a manner that a bank could run on it because that's our company philosophy and our culture way of working. We build solid software. That's no frills that works versus, yeah, but do you need to do that for the log parsing thing? That's just going to help us see if the server's up. Like, no, you probably don't, but don't, you know what I mean? Like it's, it's, I think it's hard for some of these groups to kind of break away from treating everything as like mission critical and i think that's pretty germane to this conversation you know yeah like i think you

18:18Michael Booth:need to work out what mission critical actually means right and whether certain things particularly within teams actually are mission critical because that will sort of help guide maybe how you develop things and who should be developing them maybe just picking up on the logging comment there if i understood it correctly the argument used to be that putting in sort of baseline good practices was expensive and i think that's also changed so the effort to put logging into a piece of software is like almost trivial these days right so i think there's a whole bunch of things where people go oh we couldn't possibly do that or maybe that isn't warranted but if it doesn't really cost you anything why wouldn't you put it in like if it's a point pointless piece of functionality then fair enough right we don't want we don't want animated gifs in everything but um yeah the there's just basics of good software engineering that i think you should put into sort of any tool that you're

19:11Michael Kennedy:developing that's a good point it used to be you'd build software and you might have some kind of team lead review it for security or run bandit against it or something like that and hope that it's kind of okay i mean you don't call this function wrong like um print s print f or something or, you know, the unsafe version of YAML load, whatever, right? Those are the kinds of things that you should get checked. But now, I mean, we basically have Mythos as a co-worker.

19:39Michael Kennedy:You know, if we subscribe to Claude Code or the new ChatGPT stuff or Codex, and you can just say, look, do a security review on this. And what used to take like two weeks and a $20,000 pen testing engagement is now like an hour or less.

19:52Michael Booth:It's pretty crazy. I think you, of course, still need qualified experts to review the results, right? So you don't want to outsource your thinking, I would say, to a machine that's very good at multiplying and adding matrices together very quickly. The machines bring a lot to the table, right? But yeah, even if you're doing those sort of reviews, you want to leverage the machine's capability and not just completely rely on it. And I think that's one of the things that we talked about good and bad at the start.

20:19Michael Booth:I think that's one of the things where I get slightly concerned when people seem to be

20:24Michael Kennedy:outsourcing their thinking that's not across the board. Turn off their critical thinking.

20:29Michael Booth:Yeah, 100%. It is interesting. I noticed the University of Washington teaches a course now on critical thinking, which is somewhat interesting, right? Why would you need to teach people critical thought? Like clearly, clearly you get taught critical thought through a whole bunch of experiences and courses in life. But I think it speaks somewhat to the age that you'd actually have an official course on that. I guess that's what experience brings.

20:52Michael Kennedy:Right, right. And the more you can sort of shortcut your way through literature and philosophy and math and so on, then you kind of, I guess, need to make it up somewhere else.

21:01Michael Booth:I think experience plays into this a lot, right? So the longer you've been around, just the more things that you've seen them gone wrong, right? And that's not unexpected in life, I don't think, because we all like to take shortcuts. But I think, as I often say to people, Just choose the right shortcuts.

21:17Michael Kennedy:This one, I had to come in the middle of the night because the server went down. We don't want to do this anymore. Or the car broke down on the side of the road because of this. We're not doing that anymore. You learn the lessons over time, I suppose.

21:28Michael Booth:Hopefully you learn the lessons over time. That's the goal, I think. As I say, everything's an experiment. The question is, will you learn from the experiment? Maybe you'll learn.

21:36Michael Kennedy:Not 100%. There's no guarantees. Before we jump into the details of your article, I do want to put one more concept out there for people that I think can sometimes get lost in the fray as well. And that's the concept of competing against non-consumption. So for, put it in context for my example of like, oh, we have a pen tester now that can work on this thing. You would hire a pen tester for the most important part of your software, but your little tiny, like expense tracking tool that Jane from 2021 wrote and left the company, you're probably not going to hire a pen tester for that. But now these days with these tools, you can, quote, hire a pen tester for it, and it takes half an hour.

22:17Michael Kennedy:And it's not that, ah, you probably should have hired, you probably should really use like a real person. Like there was never going to be a pen test of that at all. And now there can. Like there will be for the real software, maybe, but not for like these little internal tool things that like, I think we're going to talk about. So I think this concept of competing against non-consumption is worth keeping in mind.

22:37Michael Booth:Good point. I guess the question still is, would you, is there a case to actually use the machine for that? If it's sort of free, then I guess, why not? But there's still lots of other things that you might investigate, right? So do you actually want to spend some of your token budget on that even? So I think, again, it's thinking well about problems and going, what are the actual pros and cons here? Or what are the risks that we're trying to mitigate? Okay, let's jump into Hyper

23:01Michael Kennedy:team software and we're going to talk through your excellent essay from hyper personal software to hyper team software small team built ai assisted tools inside the enterprise because i like i said i think there's just a gold mine of opportunity here to solve some of these principle of least touching and you break it as yours sort of type like things that are a hassle for everyone and just no one's going to go near it and no one understands it i think there's a huge possibility there. So, but since you said, you know, this is, this is based on my concept of hyper-personal, let me just give people a really quick, definite, like a starting point from there. So I said like, look, I think there's a lot of people that say, if this AI stuff is so good, why don't we see an explosion of software? And my article said, I think there is an explosion of the software, but so much of it is like dark matter in a sense. Like you can't see it because it's not worth bringing out into a great big flash. It's just a bunch of these little things that solve or polish a bunch of stuff. So for my example was I was using the start page search engine and they'd

24:04Michael Kennedy:started putting ads that would fill like two pages before you even got to the first search result. Like I don't mind having an ad. I want to support you, but two pages, this is ridiculous, right? Yeah. So I said, I just had Claude build me an extension that would just remove, remove the ads just for me. I have no intention of ever shipping it. I just thought, here's a problem I have. I bet in 20 minutes I can make it go away, you know? So that sets the stage.

24:28Michael Booth:tell us about this concept here like tell us about your idea apologies for the name first of all because i don't think it's particularly the right name but i just wanted to riff off your name so that was the initial thinking behind it and also apology for the length of my articles i try not to write so much but sometimes that's just what happens so yeah i guess as i reflected on your article and thought well if michael can build stuff that solves his problem surely people in smaller teams within companies actually have plenty of problems to solve and you don't want to be necessarily starting up a capital p project and having lots and lots of people involved which is sort of a typical model because of the way companies are structured but if you can just yeah solve a small problem and it doesn't involve any sort of other people outside your team or any great infrastructure so you're not trying to set up a client server database necessarily to solve it you're not trying to include sort of authentication because the security of it doesn't really really matter in this case you're just solving a small problem within your team then why not take a

25:37Michael Kennedy:similar approach like i've already beat to death i think there's tons of opportunity here but you know give me your sense of this at my limited experience i would say for everything that you look at a company and you see oh here is their product here's their software or at least the software that powers their product like if they were a car company maybe it's like their website ordering i don't know there's 10 times as many hidden little small somewhat unpolished things that would fall into this category that that are critical to making everything work as we've

26:05Michael Booth:discussed offline like there's nothing new here people have always been building little widgets to solve problems i guess the game changer here is that you can do this incredibly quickly so you can build a lot of good things quickly or you can potentially build a lot of bad things quickly so having some sort of vision around how to do it with some degree of discipline I think matters but there's always been those solutions out there and I think again with this theme of make everything an experiment if you can do experiments quickly then you can work out well is this does this actually fly is it actually solving a real problem and well maybe in the past I could do it at the 90% level, but nowadays I can build the 99%, still do it 10 times faster than the 90%

26:48Michael Kennedy:solution. Yeah. It really takes away some of the limitations. You know, you're like, yeah, everyone hates this. It's a hassle or it could be smoother, could automate more, but it's going to take four weeks and it just doesn't justify someone working on it for four weeks. But if it's going to take four hours, you know what? It might be worth four hours, right? There's that unproductive afternoon anyway that you had the big meeting in the morning and you can't focus it's just you

27:12Michael Booth:could build it then you know yes and the implication here is that you have requisite skills to build it so of course everybody can build software these days and I think that's a great piece of democratization that has occurred I would argue that not everybody can build good software or sufficient software and that's not a critique of anything other than I think experience matters and some degree of training matters still so that you can actually shape things that work together or have thought through some of the problems that are coming next. So it's not just about building a solution that works for today, although in some cases that may be warranted, but it's also thinking about, well, how might this fit in a broader ecosystem? I think we should put the

27:53Michael Kennedy:whole sort of vibe coding stuff as like, all right, not that. I could use AI to try to do computational chemistry, but I'm highly unqualified to do so, like highly unqualified, even though I studied it long ago so it's not a knock on me that i'm dumb it's just i don't know chemistry that well right i don't i don't already do that so i think it's fair to say like look you have these companies full of people who are already programmers and they have i think a really important part is the domain name domain knowledge to like understand and solve these problems like not just from like writing code but this is actually what we want to accomplish here not just this is how the code works make the code better yeah it's always just about making the code better

28:31Michael Booth:But I think, and this hope comes out in the article, is that if you actually have skills and you're embedded more so within a business, then you can understand the business problems by definition much better. And I think combining that domain knowledge with if you're bringing the software engineering skills, I think that then becomes a really potent force. I'm not saying that like within sort of more technology focused parts of businesses that you don't have people who can now build things much faster and probably better and pen testing and other things.

29:05Michael Booth:But I think my focus here is really just if I'm, if I have the requisite skill, if I can do my computational chemistry in my small team, as it were, what can I, how can I then sort of leverage those skills to really build software that matters for my team and solves, solve those sort of problems, which probably never would have got off the ground before. Or if they did, as I say, they're only getting sort of maybe 90% of the way there and not really nailing the problem.

29:33Michael Kennedy:Let's talk through some of the main points of your article. So top one here is what this looks like in practice. And you give a bunch of good examples. So maybe you could talk through each one of these. So the first one is onboarding accelerators. Tell us about that. In most teams,

29:48Michael Booth:onboarding can be a little bit painful. How much of your budget as it were, do you want to spend on fixing that problem? So some of it can just be fixed by you have a buddy system and people talk to each other better, right? In other ways, it may be technical setup. And if you can actually develop a script, which runs for more than one person on one day, so you can build in that robustness where a script might have used to have failed, you can now sort of, yeah, just accelerate that onboarding. And everybody then is on hopefully a very similar footing, which helps as well. So you don't have the, it works on my machine only problem. This is great. And it's such low hanging

30:24Michael Kennedy:fruit. And I'm sure people can tell that I'm excited about this idea. But as you describe that, I'm like, okay, and we could do this and this and this. So for example, I imagine a typical onboarding is here is a wiki, go read the setting up your machine, select Mac or Linux or Windows or whatever you're doing. I think go down the script, right? You're like, okay, well do that. And then we'll see you at lunch. That's one way. But with some of these AI tools, you could build like cool little scripts that will go along and do a lot of it, but also do things like check and make sure that you have the right service pack because we're not going to allow you to run this old version of Windows and then install this connection to our database, potentially even if it is Q&A or whatever.

31:04Michael Kennedy:And beyond just the setting up, maybe something about the way things are set up changes. So you could write a little program that says, here's the things we want set up. When it changes, I want you to go look at the machine again and tell me if it's still good or if we need to evolve it right. Like that's really hard to do. Say like you set it up two years ago, is it still good?

31:24Michael Booth:And I think the other thing is you can actually document it, right? So you can easily point the machine at the script that you've just written and make sure that the documentation is in sync because some users are not going to be able to like read shell, for example, if it's that sort of thing. But if you have the documentation which is tightly synced with it, then you've, I think, hopefully got the best of both worlds.

31:45Michael Kennedy:This portion of Talk Python To Me is brought to you by our AI tools. You know that thing where you ask an AI something about Python and it confidently tells you about the library version from 18 months ago? Well, we fixed that, at least for our shows. Talk Python and Python Bytes both have MCP servers now. Connect Talk Python and your AI can search over 550 episodes, full transcripts, every guest, and the entire course catalog of Talk Python courses.

32:13Michael Kennedy:Connect Python Bytes, and it gets almost 500 episodes of Python news going back to 2016, including every link we've ever put in the show notes. This means you can say things like, ask Talk Python what astral joining OpenAI means for uv, or what has Python Bytes said about Locust, and get a real answer with real links, not a hallucination. Name one of our shows in your prompt, and your AI knows exactly where to look. And if you live in the terminal, Talk Python now has a CLI too.

32:44Michael Kennedy:One line, uvtoolinstalltalk-python-cli. Then search the episodes, transcripts, guests, and courses without ever even opening a browser. It's open source and it outputs text, JSON, or Markdown. So it also feeds AI tools that don't speak MCP. And here's the real reason I built it. Both shows cover around 10 years of Python history. The people, the decisions, the packages that took over, and the ones that quietly didn't. This enhanced access to all of our information is free.

33:15Michael Kennedy:No account, no API keys, nothing to buy. That history contained in these shows should be there for all of us. So visit talkpython.fm and PythonByte.fm and click the MCP link in the nav bar. Connect them right now to your agents so that they will be accessible anytime they're needed in the future. Hope you all enjoy the access. Okay, the next one I'm also super excited about, Internal tool, user experience, polish. For somebody like me, I tend to write Python and SQL, right?

33:43Michael Booth:I'll spin up Streamlit if I want a UI for something as an example. But I typically think that CSS and similar are sort of dark arts, right? However, this sort of opens up possibilities with dashboards and whatnot where they were sort of okay, but actually with a little bit of polish, they'll become much more usable. And for somebody like me, yeah, I don't want to have that specific set of skills, But with a little bit of work with the machine, I can probably get it.

34:10Michael Booth:Not to the point of a graphic designer's sort of capability, but maybe a bit better than it was. And people respond to interfaces, right? If you have an interface which is perfectly functional but looks rubbish, people don't trust it.

34:24Michael Kennedy:Back in the day when it was more desktop apps, a lot of Visual Basic type of stuff, people would describe these kind of tools as battleship gray. Like technically they have a color. They just don't care about how they look. They're just gray backgrounds with black and white bits, you know, like maybe a green button if you go crazy. Who knows? You know what I mean? And they were just uninspiring.

34:47Michael Booth:No, absolutely. I, throughout my career, have done a lot in Excel, right? And one can argue the merits of that. And I think there's lots of reasons not to like Excel. However, lots of people use it. So I think if you're working with end users who do have to use it, then even in Excel, you can make a UI, which looks not too bad, or you can have one which is just completely horrible. So I think it doesn't matter what you're developing the tool in. If you can polish the interface, you can get some much better usability.

35:15Michael Kennedy:And it's simple things like you've got to enter all this stuff in an order, but if you enter it in the wrong order, it's really hard to change it. But hey, Claude, could you make this drag and drop reorderable? Sure. Now a drag and drop reorder. Like, oh, we have to use to delete it and start over if we entered it in the wrong order. Now we just reorder it. That's incredible, right? That kind of stuff is just so good.

35:37Michael Booth:Claude, you're an expert UX designer, and you need to allow for appropriate accessibility features. Can you draw on your best practice knowledge to create a beautiful UX, potentially? I haven't done that experiment, but I suspect it probably works.

35:53Michael Kennedy:It would work fantastically. You could say, like, look, I think we wrote this website, and I don't necessarily think it's accessible to blind people. Could you go through and just look and see what's not great and just fix that for me. Or if you need help, ask me, but probably you can fix 95% of it. Like that kind of stuff would be great.

36:10Michael Booth:Yeah, again, I didn't think this is a call out to get rid of all UX designers. I think it's to say to the existing UX designers, how do you work with the machine? And rather than you only had time to polish one dashboard or whatever it was, now you can polish a whole heap of them and get consistency where it's appropriate and things like that. So people are nervous, right, around the AI is going to take my job stuff, right? And I feel that and I see that as I sort of go around places.

36:38Michael Booth:But I think that's the wrong mindset. And I'm trying to get the view out there that you can work with the tools to get really good results. But you can't not do that. You can't say, I want to live five years ago because that world's gone.

36:49Michael Kennedy:Again, this is a case of like potentially competing against non, what did I, I forgot the term I was using, non-consumption. It could be this is a tool that was just never was going to get somebody who knew about accessibility review it. And now since it's basically free to ask, you might as well ask, like, could you just make that a little bit better? Because we do have some folks in our company who would really benefit from that, right? Yeah. Because the people who work on the accessibility, they're working on the real website and the real tools, you know what I mean? Again, it opens up opportunities for

37:18Michael Booth:inclusion, right? So yeah, I think that's very exciting. Absolutely. There's so many cool things like that. All right. Decision pack generators. Typically, you've always got packs going to decision makers and governance forums and cut and paste and all those sort of awful things can both introduce errors and just be time consuming so i think the ability to pull those sort of materials together in a automated way which you probably would never have done because the cost of that was just far too high compared to the effort and result you're after so i think again whether it's a script which is automating some sort of powerpoint thing again avoid PowerPoint at all costs if you can. But yeah, anything to pull together packs, which make it accessible to people that have relevant linkages to other documents and stuff. There's just a lot of opportunities there. I think that's a huge opportunity, actually. Hyperteam databases. So

38:10Michael Kennedy:before you jump into this, I think one of the big areas that is not solved with AI very well, maybe almost at all, is operational stuff like DevOps. I need to make sure that this server is up and running and that we have backups for this and that they run and we can, you know, like just this managing multiple machines is not, it's just not really where the AI works that well. I know you can make it do these things, but generally it's on local files and chats and stuff, right? So this concept of hyper team databases ties into like basically avoiding that, right? Yes and no, I'd say.

38:43Michael Booth:Okay. I'm not a DevOps expert at all. I have very limited expertise, in fact. So that's something I I wouldn't talk to. But in terms of, I guess, the thrust of this is really, so databases sort of used to be hard, maybe, or harder. I guess, yeah, one of the things I do is use tools like DuckDB or SQLite. So I don't have to have the whole client server database thing set up. So if I just want to capture data within my team, and it's just my team sharing it, then there's a lot of options here, I think. And although DuckDB, that being said, has just released an extension called Quack, which opens up sort of client server model.

39:22Michael Booth:But yeah, so I think that's really the idea here. How do you allow for just a really lightweight place where you can capture data as part of your application or something like that? Or you can shove your logs in there or whatever it is. Because I think as soon as you sort of side point, but related is as soon as you have observability data, you can start to ask questions about, well, how are people actually using this software and can we learn from that?

39:47Michael Kennedy:Right, like time series type stuff and so on. Or user flow, they went here, then here, and then they did this.

39:52Michael Booth:And traditionally, it just would have been expensive to do that. And nowadays, I try not to use the trivial word too much because it understates the amazing capability of these packages to actually deliver functionality.

40:05Michael Kennedy:I think some interesting ways that this recommendation is really powerful is so many of these internal tools that people have, even in a company of 1,000 people, there might be six people that need to use this little internal web app. They're all the ones who approve expenses. And it's about scanning and approving expenses. Do you need replica failover Postgres for that? Probably not. I mean, maybe. But if it's really a small thing, it could just be a SQLite file.

40:35Michael Kennedy:And then the deployment and management of it and backup of it becomes so simple. I think there's a lot to do with this.

40:41Michael Booth:Yeah, through late 2018, 2019, three or four years there, this whole push was to sell a whole bunch of infrastructure. And I think people spent way more than they needed to. And I think you'll see that in the DuckDB sort of materials and mother duck and things like that, where they've just called out the fact that most people don't have big data. And I feel you're probably overpaying for infrastructure. Again, depends on your industry, right? some industries have mandated requirements how they handle their data but i think again depending on the nature of your business and your team if you've just got a backup of the database

41:18Michael Kennedy:that might be good enough it's not just paying for the infrastructure you know like we now have like a huge spark cluster that does whatever yeah you now need somebody who understands what a spark cluster is how to run it what happens if it goes down someone's getting called whereas sqlite is just it's a file if the app is running the sqlite quote database is also running in process you're

41:42Michael Booth:good to go that really like fits a lot of these apps well yeah but i think the marketing arms of some of these uh big data infrasers just it's i don't know whether it's they're selling fomo or what but um i think you see a lot of suboptimal decisions in that space i 100 agree with you i

41:58Michael Kennedy:think what they're selling is the ability to like dream big like when we get a petabyte of data we're going to need to be able to ask questions about it. Like, yes, maybe, but you just launched the site and you don't really have any users yet. So later, when you get there, that'd be a great idea, but like, don't kill yourself with that kind of stuff early, right? So anyway, that's, I think that's neat. All right. Template app patterns. This one is, I didn't expect this one. Tell us about this.

42:25Michael Booth:Yeah. So this was just as I played with some things, it occurred to me that maybe it would work okay so it doesn't have to be toml yaml whatever your favorite language is there for config depending on what you're doing you might find that there's just repeatable patterns and so rather than having to build 10 different little applications you may just be able to again extract the relevant things out into config and have a whole suite of applications which are pretty much the same architecture do very very similar things and you're just tweaking the config you know a lot

43:00Michael Kennedy:big internal companies they're like you have to talk to this single sign-on thing that we have and you have to log to this thing that every app log you know there's just like this repetitive stuff and it seems like it's pretty valuable to document that yeah and again depends on your

43:15Michael Booth:industry depends on internal policies and stuff like that and those policies can be well very well founded right but if you're not doing that why would you invest the money because it all comes down to money, right? There's costs, there's real costs to all this stuff. So if you don't need the bulletproof solution, then go with the one that gives you 99% uptime as it were. Absolutely. And

43:36Michael Kennedy:that someone who is not an expert can continue to manage. So let's talk about upside, risk and unicorns. So what's the upside here, you think? We talked about some already, but give it, give it a

43:48Michael Booth:rundown. I think you can just move faster. Everything's an experiment. You learn quickly, you fail quickly you refine and you decide yeah do we do we move forward or is this just an experiment which taught us that this is not something that we want to do or as we did it we discovered that the team down the road has actually solved this problem and we'll just borrow what they've done so but i think sometimes getting away from that piece of paper we drew a diagram which nobody can quite decipher to well here's what we're thinking about and the people can react to it and go yep we've already done that or no that's a great idea and you guys should pursue that the autonomy thing i think matters i think autonomy isn't a bad word i think it can be viewed that way at times but i think taking charge of your own team's productivity is not a bad

44:35Michael Kennedy:thing yeah a lot of times it would be well we're not really the developers that mess with the api or the database we just consume that stuff so if we want any of these features we've got to get them on board. Whereas here, it's like, actually, we can just build enough of our own stuff. Or maybe it's, yeah, but that part of the application is written in Swift. No one here knows how to write Swift. Well, you know what? You could bring Cloud in. Cloud could help you work through that portion, right? Get that integrated or whatever. So I think there's a lot of power to the autonomy.

45:04Michael Booth:Yeah. And something's that critical within an app, right? So if the UI is sort of good enough, maybe it doesn't matter about having that skill. But if you have the skill for the sort of internal engine bit, maybe you can work well enough. I think another one to throw in here

45:18Michael Kennedy:on the upside is the getting over the fear of you touch it, you break it, you bought it kind of thing. Because if you're not the one who wrote it and the person who wrote it left, there's a lot of unknown. But one thing that Claude and those other Agenic tools are good at is just study this application, tell me what it does and what parts are involved in trying to add feature X. It's all are like no one understands it too well no one's worked on it but this looks pretty straightforward

45:48Michael Booth:and here's all we got to do you know yeah no the explain functionality is quite amazing isn't it but equally if you're going to explain it why not document it yeah keep your document in sync with your code right and again the excuse that oh we don't have time to document it's like well really if the machine can sort of get you 95 of the way there and you actually review it and just tweak it

46:09Michael Kennedy:feels like a win-win to me. 100%. It's like, if I can just kick off Clutter Codex and say, spend all the time you need to document it, and here's the format where it goes, and then I switch another tab and just go do something else, like, you should have documentation.

46:22Michael Booth:I always, as part of the readme or whatever, do the, what are we doing? Why are we doing it? And how are we doing it? Because I think that framing is quite often missing from technical descriptions of things. So the why is pretty important, I would say. It absolutely is. All right,

46:37Michael Kennedy:Not all perfect, though. Hidden risk. What are we talking about here?

46:40Michael Booth:Any sort of software developed by end users within organizations is, if not done appropriately well, can just introduce a bunch of risks. Unknown dependencies, I guess, is just the idea that, yeah, you don't necessarily, I'm not talking about Python dependencies here. I'm talking about you just don't understand how things interact. So I think if your tool is, there's dependencies there between tools and stuff, you just want to make sure that they're well understood.

47:08Michael Booth:And that may not be immediately obvious. Ownership sort of matters, right, in terms of you do want somebody to own a tool. Can you have a team owning a tool? Well, maybe you can, but I think you still want that sort of clear ownership. So typically teams don't own things, like they might in principle, but you still need a real person. And again, depending on what the solution is and depending on your organizational requirements and if you've got regulatory obligations.

47:36Michael Booth:Yeah. Do you have appropriate controls in place? And it may be that you just don't really understand that at all. If you're an end user, you may not appreciate what data controls you have to have in place or security controls and things like that. Although to your point, maybe just get the machine to help some of that stuff.

47:52Michael Kennedy:For sure. But it's not easy. Like, for example, like, oh, it's so great. We can just use SQLite now and that's our database. And then somebody's, well, the way we back that up is we just copy the.sqlite file. And it has all this PII and HIPAA violations by copying that file to the wrong place. And like, it could be bad.

48:08Michael Booth:Data really matters, right? And again, on industry, there are some very, very strict requirements on that stuff, as there should be. As an end user, you may not have appropriate understanding or visibility of those things. So there are certainly applications where you need to have sufficient knowledge, right?

48:24Michael Kennedy:I would add another hidden risk is supply chain badness. Yep. That's actually been in the news so much lately, right? Like with npm and PyPI to a lesser degree, but not to a zero degree. But I mean, there's light, it was LiteLLM was pretty bad. I was only out for a couple hours, but, and what these agents love to do is they love to grab a package off of npm and install it and then, you know, get it. Then either maybe there's no checks to make sure that they get installed.

48:52Michael Kennedy:Okay. Right. that they don't have a CVE in them, or if they do later, who knows to patch it? Because who knows even where it was used, right? There's none of that stuff.

49:01Michael Booth:Yeah, so typically enterprises will have solutions in place to sort of have internal mirrors of those sort of things. But again, you've got to make sure that you're governing those well, otherwise you can easily miss stuff.

49:11Michael Kennedy:Right, but does your AI know to use them? Because if you're in the far, the more you go toward the vibe side, you just say, just make it. I want it to look like Instagram or whatever, right? It's like, well, Instagram uses this, so we're going to grab it. You need some discipline around this stuff. And then the unicorns. I like this idea. I'm on board with you.

49:28Michael Booth:What is this? Sorry about the name. Can be a bit pretentious, right? The unicorn is just somebody with a pole in the head, right? I think the idea is though, if you've, as I sort of flagged before, if you've got somebody who has capability around software engineering, but also who has deep domain expertise, they bring a lot to the table, right? So every person in team brings something to the table. I'm a great believer that you try and create environments where people can do their best work, but you do have people who quite often have done different things in their careers and therefore bring a unique set of skills in terms of just that depth in both software engineering and domain.

50:08Michael Booth:And those people can really, I think, bring a lot to the table in a team, which you don't necessarily see a lot of. A lot of people like to stick to a particular single domain. So that's not a critique, It's just my observation.

50:21Michael Kennedy:Yeah, I think having either somebody who has a lot of domain knowledge and programming skills or data science skills, depending on what you're trying to do, that's really, that would be ideal. But those people are hard to come by. So maybe you create a pair, like this person really understands the problem and has a little bit of skill in programming. And this person is really good at programming and they know a little bit of what's going on. You know what I mean?

50:42Michael Kennedy:Like that would be a really powerful combination, I think.

50:45Michael Booth:Those sort of buddy-pair type relationships, yeah, can certainly be another model there. And having people talk to each other in teams in general is quite powerful, right? And you can get some really good results. So, yeah, I don't think you necessarily need maybe the unicorn person, but the unicorn team.

51:03Michael Kennedy:I imagine this will be companies and teams who adopt this. It will probably feel a little bit like if you've never used a linter on your program, rough black, something like that, that says you're doing all these things wrong. And you run it the first time you're like, there's a thousand and seven problems. You're like, oh my, we can't hire somebody for each one of those problems. You know what I mean? Like if those represent sort of these apps that could really be improved. But I think with the velocity you can get with a couple of people and Claude or Codex on them, you know, you could do this week, we're going to modernize these two apps. The next week we're going to modernize those. And after a couple months, six months, depending on how big your company is, you'll have a lot of apps that are in good shape and don't need much attention.

51:46Michael Kennedy:They've been running without being touched forever. Now they just run better.

51:50Michael Booth:And you would like to think that as you do each of these experiments, you learn stuff, right? So I'm probably going to use Ruff, for example. But you build up best practices, right? So there's no way I let a coding assistant run without locking it down severely, right? And I think using your roughs and your TYs and mypyes and all that sort of stuff allows you to constrain the machine so that you're building a much better product each time. And I think as you take those learnings out of the process, I think you can uplift the quality of the software that you're building, having really good tests there.

52:28Michael Booth:So just all those what I would consider very basic software disciplines enables you to move both faster and better.

52:34Michael Kennedy:Yeah, that's really cool. I totally agree. think you should tell your agent it can't move on until rough passes it can't move on until ty or pyrefly or whatever you chose to pick and you set up the config files to like this is how we work in our organization we format it like this we do this and so on and then it has to write code that conforms to what you're supposed to be doing right because the tool will tell that no you're not done

52:57Michael Booth:like rough returned code one instead of zero try again with those disciplines which move you away from maybe your vibe coding to the view of the world. It really does allow for some pretty good software to be built. But like most things, if you're not scrutinizing it appropriately, you're not applying your critical thinking skills, then you sort of are asking for a few problems, I would say.

53:18Michael Kennedy:All right, you put a little decision tree down here. Talk us through where you think this is a good idea and where people should maybe not do it or so on. Like walk us through this.

53:28Michael Booth:Big mermaid fan. So the diagram is down below. But yeah, like if you're not solving, I used to have a boss who said, if you're going to solve a problem more than twice, then you should automate it. We can argue the merits of that, but there's something to it in terms of just thinking about a problem. So in this case, yeah, are you solving something that's causing some friction, right? So why would you solve a problem that is frictionless? Sort of as I flagged before, yeah, do you have an owner?

53:55Michael Booth:Like does somebody, is somebody going to care about this problem to the degree that they will actually take ownership of it? Because if you can't find an owner, then maybe nobody cares about it.

54:04Michael Kennedy:AKA, if it stops working, will they make it work again?

54:07Michael Booth:Can we explain what it does in two sentences? Well, again, the machine can help you with that. But if you can't articulate things to your stakeholders, then why should they care? And if you're, I think it's in the Unix world, you sort of have the philosophy of a tool. The command line tool sort of does one thing well. I think, again, similarly here, you're trying to make sure that whatever tool you're building is very, very explainable. Do we know how to disable it quickly?

54:32Michael Booth:Yeah, can we turn it off? So I guess most of the tools that I'm thinking about here are deterministic. So I'm not talking about tools that are necessarily generative AI powered or something like that, because you definitely want to kill switch for those. But yeah, just if you turn it off, is anybody going to notice? And or if people do notice, can you turn it off and quarantine it appropriately?

54:53Michael Kennedy:Yeah, I think sort of along the same lines here as a parallel would be, could you get it back to the way it was before?

54:59Michael Booth:Absolutely. And again, I think documentation can be a good control around some of those things. You're just not writing the documentation for, quote unquote, the tool, but maybe making sure the process and the problem that you're solving is well articulated. And the other one there, maybe the other one's in the article. I can't remember exactly where, but just, yeah, does it require that database thing? And do you need to do some sort of authentication?

55:23Michael Booth:Because by the time you're doing authentication, it feels to me like in the enterprise that somebody probably should be taking a look at things more closely. It's not impossible that you may not want an authenticated tool within your team, but you sort of got to talk to people in other teams typically if you're doing authentication anyway. So that may be a sign that you're getting outside of, not that the tool necessarily is a bad tool, but it's time to talk to others.

55:48Michael Kennedy:It might be a software project, not just an afternoon project. Absolutely. Michael, we're pretty short on time at this point. I mean, there's a lot more we could talk about. You can see I have many tabs. There are many tabs on my...

55:59Michael Booth:I'll say hi again now.

56:01Michael Kennedy:Yes, exactly. The internet's stable. Good, yeah. It seems like it's been better. So this has been really interesting. And I think it's going to give a lot of people a lot to think about. Give us your thoughts about if there's a company or a decision maker at the company, really is probably the right way to, like this will envision, like manifest. If there's somebody who's like, no AI at our company. I feel like they're missing a big opportunity and it's not a huge risk.

56:25Michael Kennedy:But what would you tell that person?

56:27Michael Booth:Yes, it'd be interesting to put the statistics on how many companies have not embraced AI to some degree. So maybe it's a little bit of a straw person hypothetical now. But yeah, I have great enough visibility to know the numbers. But you've heard me say the experiment word a lot, right? So I guess it's experimenting within your risk tolerances. Just try some things within the boundaries that you're comfortable with, right? Do some experiments. I think for a lot of people, if you haven't used an LLM firsthand, you tend not to believe it's true.

56:58Michael Booth:When I first use one, I'm like, oh, wow, I can write a menu plan for a week with the help of a machine. Or I can plan a holiday. And I think I was talking to a mate actually during the week about this because he literally has not played with them. And I'm like, just do an experiment. Go and say, what should I do for my kid's school holiday plan? Right. Because I think, yeah, until you've done it, you don't sort of believe it. So I sort of started with the autocomplete and I'd do pd.readcsv and amazingly it would autocomplete and it's like, wow, this is crazy.

57:30Michael Booth:And then I started to use perplexity for the first time a couple of years ago. I'm like, you've got to be kidding me. This can't be real. And I think as you start to work with the machine and get that comfort, you start to go, I think there's a whole bunch of problems that we could solve. So I would say, yeah, experiment and then maybe partner with someone that is looking to help you solve your business problems and be a trusted partner, not somebody who's just trying to extract some money out of your company.

57:58Michael Kennedy:Yeah, there's so much of that right now. It's such a, the whole industry is full of grifters, like selling you like the next best thing. Like I get probably 10 emails a day. Like, have you considered using AI to accelerate your company? Like, yeah, I've considered it. Go away. I don't want to talk. I mean, it's so bad.

58:12Michael Booth:I apologize for those emails. I won't send any more.

58:16Michael Kennedy:I'll add a couple of things here. These little internal apps, and this is why I was so excited about your article, is they offer an opportunity to experiment in the smallest, lowest risk rung of working with the stuff in your company. You might have a thousand people and a million customers, but here's the app that only three people in your company use. And it could make their life better. Try it there, right? That would be amazing. And the other one is I would say, this is an engineering skill, like writing code, like object-oriented programming, like memory management, and so on.

58:48Michael Kennedy:And if you treat it like a casual conversation with a buddy or whatever, you're not going to get the right results. So there is engineering around here. It's very weird and it's very different. But if you apply it, you get good outcomes.

59:01Michael Booth:I have a close friend who's a lawyer, for example. And I say to her, yeah, just experiment, right? Because like if you run the same problem through the same machine multiple times, you do get different answers, right? So you've got to understand what LLMs are good at and things like that. But as you develop confidence in what's actually being produced and that trust builds, I think you'll actually start to solve some interesting problems. But if you don't experiment, you won't know.

59:26Michael Booth:There are many levels.

59:27Michael Kennedy:There are many levels of which this can be employed and are awesome. And you can just start easy, start low. And then like I said, experiment, try it out, be careful. Yeah, it'll be fun. All right. So last, here's the final word. I'll give you the final word. People getting started, what advice do you have for them?

59:42Michael Booth:Yeah, so there's lots of hype out there. Ignore the hype and just try something. In enterprises, most people will have access to like a Microsoft Copilot, or maybe if you're on the more tech side, GitHub Copilot or Claude Code. I don't think it matters what the tool is. Give it a go. I use a thing called warp.dev at home, and I tend to use Claude quite often as well. Again, you learn stuff by using different tools, right? And no tool is perfect. No human is either.

1:00:11Michael Booth:So good to try different things.

1:00:13Michael Kennedy:Yeah, it absolutely is. So I'm a fan of warp. Good recommendation. And yeah, Michael, thanks for being on the show. It's been great to chat with you. Thanks for having me.

1:00:21Michael Booth:I really enjoyed it.

1:00:22Michael Kennedy:Yeah, you bet. Bye. Bye-bye. This has been another episode of Talk Python To Me. Thank you to our sponsors. Be sure to check out what they're offering. It really helps support the show. This episode is sponsored by Sentry's Seer. If you're tired of debugging in the dark, give Seer a try. There are plenty of AI tools that help you write code, but Sentry's Seer is built to help you fix it when it breaks. Visit talkpython.fm/sentry and use the code talkpython26, all one word, no spaces, for $100 in Sentry credits.

1:00:51Michael Kennedy:Talk Python and Python Bytes both now have MCP servers. Point your AI at 10 plus years of Python episodes, transcripts, and show notes. Free. Click MCP in the nav at talkpython.fm and at pythonbytes.fm. If you or your team needs to learn Python, we have over 270 hours of beginner and advanced courses on topics ranging from complete beginners to async code, Flask, Django, HTMX, and even LLMs. Best of all, there's no subscription in sight. Browse the catalog at talkpython.fm.

1:01:23Michael Kennedy:And if you're not already subscribed to the show on your favorite podcast player, what are you waiting for? Just search for Python in your podcast player. We should be right at the top. If you enjoyed that geeky rap song, you can download the full track. The link is actually in your podcast blog or share notes. This is your host, Michael Kennedy. Thank you so much for listening. I really appreciate it. I'll see you next time. of getting whole. We tapped into that modern vibe over to each storm.

1:02:07Talk Python To Me. async is the norm.