Pybites Podcast

#194: Evolution, not extinction: why developers still matter in the age of AI

• Julian Sequeira & Bob Belderbos • Episode 194

Share episode

In this episode, we dive into AI’s impact on software development with Matt Makai, VP of Developer Relations at DigitalOcean and creator of Full Stack Python. 

We explore how AI tools are changing coding workflows—from elite devs like Miguel Grinberg and Armin Ronacher to Matt’s own work on the AI-powered PlushCap app. While some see friction, others embrace AI as a co-pilot. Matt shares why staying hands-on with code is key for tech leaders, and why, despite the hype, AI won’t replace developers—it’ll just reshape how we work. 

Connect with Matt on socials:

X: https://x.com/fullstackpython

Github: https://github.com/mattmakai

LinkedIn: https://www.linkedin.com/in/matthewmakai/


Matt's projects:

Plushcap: https://www.plushcap.com/

Full Stack Python: https://www.fullstackpython.com/

DigitalOcean: https://www.digitalocean.com/

YouTube: https://www.youtube.com/digitalocean

___

Blogs mentioned:

https://blog.miguelgrinberg.com/post/why-generative-ai-coding-tools-and-agents-do-not-work-for-me

https://lucumr.pocoo.org/2025/6/12/agentic-coding/ 

___

💡🧑‍💻Level up your Python skills in just 6 weeks with our hands-on, mentor-led cohort program. Build and ship real apps while gaining confidence and accountability in a supportive community. Join an upcoming Pybites Developer Cohort today! 🌟✅

___

If you found this podcast helpful, please consider following us!

Start Here with Pybites: https://pybit.es

Developer Mindset Newsletter: https://pybit.es/newsletter 💡

Pybites Books: https://pybitesbooks.com/

Bob LinkedIn: https://www.linkedin.com/in/bbelderbos/

Julian LinkedIn: https://www.linkedin.com/in/juliansequeira/

Twitter: https://x.com/pybites

Apple Podcasts: https://podcasts.apple.com/us/podcast/pybites-podcast/id1545551340

Spotify: https://open.spotify.com/show/1sJnriPKKVgPIX7UU9PIN1

Matt:

You look at the history of what has happened with software development, oh, cobol was going to make software developers go away. Visual Basic was going to make software developers go away. Low-code, no-code more recently, was going to make software developers go away. My guess is that we end up with a new equilibrium at five years from now, where we recognize you still need something called a software developer. You need those people to actually get things done, something called a software developer.

Julian:

You need those people to actually get things done. Hello and welcome to the PyBytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian.

Bob:

Sequeira, and I am Bob Beldebos. If you're looking to improve your Python, your career and learn the mindset for success, this is the podcast for you. Let's get started. Welcome back, everybody to the PyBytes podcast. This is Bob Velderbos, and I'm here with Matt McKay. Matt, welcome to the show. Thanks for having me. Yeah, I'm glad you finally made it to our show, because we go back, I think, pycon 2017.

Julian:

Oh, my God, almost 10 years.

Bob:

Yeah, that's like, yeah, almost 10 years so, and we're coming up with almost episode 200. And, yeah, glad you're finally here. So, yeah, for people that don't know you yet, do you want to do a quick intro?

Matt:

Yeah, absolutely, my name is Matt McKay. Well, we know each other from back when I was at Twilio for almost 10 years running developer evangelism, developer content. Before that, I was a software developer. Now I'm at DigitalOcean as our VP of developer relations, building a really great team around a lot of the things that I've done in the past developer content, developer evangelism, developer advocacy, social media, that sort of thing. So, and then for the Python community, a lot of people know me from my work on FullStackPython, fullstackp, stack pythoncom, which sadly, I have not worked on as much over the past couple of years, but still very close to my heart.

Bob:

Awesome. So now you moved a little bit more into DevRel. Are you still coding every day, or how has that shifted?

Matt:

Yeah, well, I do code every single day. I think my workflows have changed slightly. So I've been using Vim and Tmux for gosh like I don't know 15 plus years now. Before that, I did a lot of software development and IDEs, but I've started using a lot of the AI coding tools, particularly cloud code on the command line. So I do code every single day, like I think it's important. And actually one of my big things is, like, if you're going to lead technical teams, I still think you should code every day. I think otherwise your empathy for what your folks are working on is it's just a lot harder. So that's that's my big thing. If I'm going to lead technical teams, like like DevRel, technical content teams, then I do code every single day.

Bob:

Nice, I'm a I'm happy to share a Vim user as well. Oh, yeah.

Matt:

Yeah, yeah. So, uh, why did you pick finn? Uh, so I was doing j2e development in like you know eclipse, super heavy. So this is back in like 2007, 2008, j2e day job, uh, and writing you know code, eight, nine hours a day, and then I would go home and I'd relax by coding, of course, as a software developer, and I just found like I was so much more productive in like one hour working on a side project in Vim and using Python than I was in my entire day job and I was like this is just, it just works for me, and I don't think that it's necessarily always that some tools are definitely more productive. I think sometimes it's like does it match your the way that your brain thinks about solving problems? So I just picked up them because I was like I don't want to constantly switch over to the mouse and kind of have to get used to the ide changes. Like I want something that is consistent, that just is muscle memory that I can always, um, basically have under my control as a software developer.

Bob:

Fast, ergonomic and stood the test of time right.

Matt:

Yeah, and plus, like every time you you know there's no, there's no upgrades, that suddenly you know it starts crashing on you or something like that. It's always just consistent and stable. And I just, if you only have a couple hours a day to code, or even less than that because it's not a hundred percent of your day job, then you need a workflow that is just consistent over time. That's not going to like make you demoralized when a new update comes out and you don't know what. What's going on.

Bob:

Yeah, I had this discussion in a cohort this week.

Matt:

and IDs, they're nice, but they're also getting more bloated and yeah it's just that they upgrade and they add more stuff and then it actually slows down the program, right? So, yeah, yeah, and I think it's important to try the new ones. But just like when, uh, when Adam came out, and even with VS code, I just have not found it to be as performant, um and so for me it's just a huge leap to go from something that I know is going to work to something that just feels sluggish and I'm just getting like frustrated with it.

Bob:

Yeah, yeah, cool. So tell me a bit about DigitalOcean. We use Heroku a lot ease of deployment. But understand, with DigitalOcean you get SSH and you get the whole box and it feels like you have more control. But there's also they are making it easier with one click deployments and stuff, right. So yeah, do you for people, because there are so many options these days. So what sets DigitalOcean apart?

Matt:

DigitalOcean is just infrastructure that scales for whatever you're doing as a software developer. Certainly, we started out with what are called droplets. Those are essentially virtual private servers. Like you said, you can SSH in. That is a lot of what I've used. I've been a DigitalOcean customer myself before I joined for like 10 plus years because it was just the easiest thing to deploy your application and, granted, I was using Ansible playbooks and I had my own scaffolding for being able to deploy applications. Not everybody has that, so we do have what's called App Platform, which enables the one click deploy, and now a lot of what we're working on is just making that even easier.

Matt:

So I think the workflows may change for developers, like what tools you're using, but I think it's always important to just like what is that shortest path to get your application up and running in a way?

Matt:

That is the two things. One, truly scalable, like if you get featured on the front page of Hacker News, it's not just going to fall over. And two, you have some level of cost control, right, because the worst case scenario is you're successful or your side project gets in front of millions of people and gets people excited, but then you wake up to a hundred thousand dollar bill because you just configured something wrong, right. So I think that's just a huge component of digital ocean, is just a feeling as a developer like you are in control of your infrastructure, as opposed to your infrastructure being in control of you, which, uh, having used many of the other platforms, is often is often how I feel when I'm like, should I use this, this service, cause it seems like if my application scales, then I'm going to have a really big bill out the other side yeah, that's definitely important.

Bob:

And the other providers where that's pretty sneaky, where things still run in the background and it's not that transparent. So, yeah, ease of deployment but also transparency with the cost, I think are two important things. Yeah, so you have the full stack Python block still. I think are two important things. So you have the full-stack Python block still. I mean, back in the day we always went there right, and as this heavy focus on production, code and deployment kind of makes sense where you are now but lately you're not too active there, but that's because of some cool project you're running right.

Matt:

Yes, well, yeah. So I worked on full-st stack Python for over 10 years, from 2012 through 2022. I had written a book with it as well, to do deployments, did some videos with Michael Kennedy of TalkPython, and so I was just really deep in the Python ecosystem. Then Then, around 2022, I had an idea for a side project and I personally find it really challenging to have more than one side project at a time and I've worked on full stack Python for a while. I still love the project, but I kind of set it aside for a little bit, said I think I want to work on this new thing, and that's what turned into PlushCap, which is available at plushcapcom.

Matt:

And the idea was when I was running developer relations, developer content in particular at Twilio, I create all these spreadsheets to track all the things that we were doing.

Matt:

Yet most of those things were public, they were public blog posts, they were public talks, they were videos, and so I was like I can actually create a tool that not only would track this for Twilio but could track it for kind of any developer focused company that has a public facing motion.

Matt:

And so, without you know, not to get too deep into, like the business stuff. My hypothesis was that any developer tool company with a self-service motion had to primarily work in public because otherwise you can't scale up your cost of customer, you can't have a low enough cost to customer acquisition to make the business worth it. So you know, some companies are like talk to sales, like like kind of the Salesforce motion, but most developer tools companies that have a self-service motion you need really low cost way of acquiring developers as your customers. And so that's what I built Plush Cap for was just to see what, across hundreds of these types of companies, what they were doing, just so that things would pop out to me that might be interesting. And then I could just go talk to them and see like, oh, is this approach working, is this tactic working for you? And I can learn from it? Hey, you.

Julian:

And I can learn from it. Hey, everyone, a quick break from the episode to introduce you to our brand new coaching program, the PyBytes Developer Cohorts. Now, these are cohort programs, typical of a bootcamp style interface, of working together with a group of other people, except it's got that unique PyBytes twist on it, where you are going to be building all day, every day. There is very little material that you will be consuming, so you won't be stuck in that tutorial paralysis. The point here is that you will be building from day one and alongside other people also building the same app in their own repositories. You can all talk, you can all share, you can all grow together and, of course, you'll have a PyBytes coach supporting you the whole way. So if you are interested, just check it out, click the link below. It is pybytescoachingcom and we will see you in the next cohort.

Bob:

Yeah, that's awesome. I like that story of how you did it for one company and it became very spreadsheet-like and then you basically automate it and streamline it and then you make it replicatable for for any other company some of the best application ideas are just like what is a spreadsheet I can take and I can make it a little bit more uh, reasonable in the architecture and then build from there.

Matt:

So that was. It was exactly the idea. So that's um, and. And plush cap is a python application django uh, deployed on digital ocean. It's been deployed on digital ocean set for for several years, before I even worked at the company um, and it's just like something that I can build a feature for every single day, or I can add a company, or I can just do something that'll be in the code every single day. So I just have no excuses for just like getting getting something done.

Bob:

Yeah, nice, I like that you picked django.

Matt:

Workhorse been using django since uh 20, uh to 2007, which is kind of wild. Uh, never would have never would have thought that that would be, uh, the thing that I've used for almost 20 years in the web web applications, but it's just that good of a framework but I mean, yeah, but it is a battery included thing, right, like with flask, it's all plug and play.

Bob:

But yeah, what was your motivation to use Django over Flask or even FastAPI?

Matt:

They're both great frameworks, all of them. I think mostly, it's just that with Django, for me, there's typically a right way to do something, whereas, like with Flask or FastAPI, I kind of have to like evaluate a few different extensions. Or do I want to write it myself, or how do I want to approach this? Since I am working on things as a side project, I just don't have the time to do that. I'm like what is the one way I should create this like API that is so that I can access the data? Oh, I'll just use. I already have Django REST framework set up. I'm just going to use that.

Matt:

And and I'm just like I'm good, because when you're working on a side project, you have very limited time to ship a feature you don't want to be worried about. Oh, how do I deploy this or how do I architect it? It's like I know how to do it. I'm going to create it, write some tests around it, deploy it and it's live, and it's not hanging there creating a potential for procrastination before you finish it. Like, just work on it, ship it, it's done. You feel good that you actually shipped some code that day, and so I just find that Django is just easier. But part of that might be, again, my own mental framework. I've used Django for so long. I've certainly used Flask a lot as well, but I tend to use it for more example applications. Just again my personal opinion on this. I wouldn't say that it necessarily holds true for for everybody.

Bob:

Yeah, I agree, like having a migration system and yeah we can talk a lot about Django, but I find the design patterns and decisions very sound, yeah, so what are some technical challenges building this?

Matt:

Yeah. So one of the big ones was actually I wanted to have use large language models to summarize the data that I have so that I could more easily digest it. So one of the features I have is I scrape all the blog posts that a company has and I have some metadata like author and date and then I take all the text. So there's this fantastic Python library called Trafalitura and it will just suck out the text from the like. You kind of throw it some HTML. So I use beautiful soup to get the HTML, or requests beautiful soup get the HTML, get you know individual pieces from that extract, do some web scraping and then I use Trafaletura. I just throw it some raw HTML. It gives me back the text like the main text from that blog post and then I use. This was to your architectural question.

Matt:

I use Olam with all sorts of different open source, open weighted LLMs in order to just do summarization and ask different questions of all the different content and the blog posts across companies. So the easiest thing is or the easiest kind of way that I've used this is I have pages that just have summaries of every blog post. So whenever I'm looking at a company, either to work with them or I've done interviews with them or whatever it is. I will just read, like the last two, three, four years of all the blog posts that they published and it's just a summary, right, it's like a one to two sentence summary and I can get a really great context for, like what that company has been focused on and working on for the past few years. So I can go into any conversation with them understanding, kind of like putting myself in their shoes what have they been shipping, what have they been working on? So that's one thing, and then the other thing is just patterns and trends over content over time. So, like I have almost 100,000 blog posts that I've scraped and so to be able to just aggregate that data and see what the patterns and trends are like, when did AI agents become like a thing that companies were starting to write about? What are the new terms that are coming out that the companies are writing about, just to stay on top of all?

Matt:

That is actually really useful and but architecturally it's actually really difficult because so this is just to finalize like the answer to your question is like, when you have a hundred thousand blog posts, I originally was using an open weighted model that worked really well. There's like 70 billion parameters and I was running it. It was like it would take like 20 to 25 seconds to like summarize and like answer some questions about a blog post. When you do the math on that, if you want to do that across a hundred thousand blog posts, all of a sudden it's going to take you weeks of processing time in order to like run on everything. So the optimization around like oh, what can I use a 7 billion or a 3 billion parameter model for versus a 70 billion?

Matt:

Or is there a way that I can, you know, maybe split it up? I'll send some. I'll send the really large blog posts that have like a large, that need a larger context window, to like an API, and then I'll use a 3 billion parameter model to summarize like a really short one. So that's been like some of the fun from architectural stuff is just like how do I process all this data in a way that is not going to take me like a month to get results out? The other side oh cool.

Matt:

So you actually went slicing and seeing where the time the execution uh took longest and then kind of split it apart exactly, exactly cues and and yeah, yeah, and sometimes you can just brute force it, right, you're like I'm gonna just go process a thousand of these blog posts, let me see how long it will actually take to get results from the LLMs. And then you realize like, okay, if I do the math, if I scale this up a hundred X, yeah, it's not going to be feasible for me to just continue to brute force this. I got to take a different approach.

Bob:

So Right, and the most latency was just by the fact that you needed to use the models. There was not any Python code you could optimize necessarily.

Matt:

Right, exactly, it's almost purely just text into an LLM and so it's just a question of like, how fast can that LLM get me the result out the other side? So I do think that this is where there are advantages to just whether you're using an API, because if you're using an API, you can often call, you know you can do, you can parallelize a lot of requests versus I run a lot of large language models on my local system, which I have, you know, amazing MacBook. To run this, I use a llama. It's a fantastic tool, but I can only run so many models at the same time. So that's where there are some advantages just to using you know kind of LLMs in the cloud, versus trying to do everything locally.

Bob:

Right, but the thing uses a local LLM, right. So you kind of well not say own it, but you don't have that third-party cost. Correct, that is what I am.

Matt:

Yes, I am trying to avoid like too much, too much cost. So that's also another architectural decision, right? Like if I can run 70% of it on my local system and just use my own hardware, then then I only need to worry about that 30% and then how many tokens are in that 30%. So it just makes it a little bit easier to say like, okay, I'm going to calculate number of tokens. If I can get this number of tokens down to a reasonable number, then I can just calculate the cost of just like setting that off to Anthropic or OpenAI or whatever.

Bob:

Yeah, cool, that sounds like a really valuable tool being able to already for yourself, right, if you can read all these summaries, you get up to speed with a company in hours, right? Instead of days, exactly.

Matt:

Exactly, exactly so and honestly, what I use it for is I I talked to a lot of like founders and they're trying to figure out how to do of dev tools, um, startups, and they're trying to figure out, like, how do I engage with developers? So I just will show them in the data. Uh, through plush cap, I'm like here, here's five different companies you should look at and they can see like, oh, okay, I see where they're focusing. They can also get up to speed on these companies. And then I have, like Hacker News data in there.

Matt:

I have YouTube data, blog post data, all the company you know, website data. And so you start to get a complete not I wouldn't say it's a complete picture, but a reasonably comprehensive picture of how different dev tools companies have scaled over time, because you have the historic data as well. So you can go back and see like, oh, how is twilio approaching things in like 2014, when it was still a relatively small company, versus trying to look at what a large company is doing today and trying to backtrack that to your own startup. So you want to do a lot of like benchmarking against similar companies and see what they're doing well yeah, that's really cool.

Bob:

And uh, how did you come up with the plush cap?

Matt:

uh, I had gotten the domain like a long time ago and I so plush cap is like this bird with a really colorful um like, uh, really colorful head, and so they it's like almost like it looks like it has a cap on um, and so I just thought I came across it like years ago. I was like I got the domain. It's like one of those things where you're like I don't know what I'm gonna use this domain for, but when I have a nice side project I'm just gonna make it work. So sometimes people are like it doesn't. The name doesn't necessarily match the project, but I mean, that's true of a lot of projects, so who cares? It's a good, memorable domain name, yeah and BERTs kind of work.

Bob:

I think isn't Astra also using BERTs? I mean, they did a type check of prototypes in the Red Knot or something like that.

Julian:

Yeah, A quick break from the episode to talk about a product that we've had going for years now. This is the PyBytes platform. Bob, what's it all about?

Bob:

Now with AI, I think there's a bit of a sentiment that we're eroding our skills because AI writes so much code for us. But actually I went back to the platform the other day, solved 10 bytes and I'm still secure of my skills because it's good to be limited in your resources. You really have to write the code. It really makes you think about the code. It's really helpful.

Julian:

Definitely helpful, as long as you don't use AI to solve the problems. If you do, you're just cheating, but in reality, this is an amazing tool to help you keep fresh with Python, keep your skills strong, keep you sharp so that when you are on a live stream, like Bob over here, you can solve exercises live with however many people watching you code at the exact same time. So please check out pybytesplatformcom. It is the coding platform that beats all other coding platforms and will keep you sharper than you could ever have imagined. Check it out now, pybytesplatformcom. And back to the episode.

Bob:

Cool. Well, talking about AI, the other thing we wanted to discuss today was those two articles that came out recently. Miguel Grinberg was saying that, yeah, gen AI is not really working for him, right. And then the other side we have, and that article I did read, but before starting recording, you mentioned Armin Roeniger's agentic coding and I'm not sure if he's more progressive with the tools, but I will have you kick off the discussion. We need more progressive with the tools, so I will have you kick off the discussion. We need to talk about AI tools. There are different camps or different opinions. You have your own experience, I have my experience and, of course, a lot of people in the audience are wondering should I use them more or less? They can lie or well, hallucinate. How do I manage this? All, yeah, or well hallucinate.

Matt:

How do I manage this all? Yeah, so yeah, miguel's position in his article why generative AI coding tools and agents do not work for me. So, first off, miguel does the research, like he uses the tools and sees what is possible and what's not, and that's what. So Miguel and I worked together at Twilio. He's absolutely brilliant, worked so hard and that's the thing is like he does his research before he and actually uses things before he will actually write about them. And he wrote a really great paper on, or a blog article on on LLMs and how they work from the perspective of a software developer, and that was like it's kind of like most things that Miguel writes are like hacker news social hits because they're just so in depth and he writes with just such clarity. So this article he wrote about why gender and coding tools and agents don't work for him. So he just generally finds that it takes longer to do the coding, the review on on the code that it puts out. The other side and I think this is actually like a really big point is the code that LLMs are producing is not exactly like what a human would produce, and so it takes even longer to review the code, because your assumptions about how that code may be written are not often aligned with how it comes out on the other side, and so I think his overall argument is just not faster for him. And again, like he's writing from his experience, right, I do think that, like Miguel represents like one of the like elite software developers, and so it's really hard to say that this can be applied to a lot of software developers. I actually find that I do get some benefits from LLM coding tools. At the same time, I'm also coding on side projects a lot of times, and I'm doing them explicitly to keep up my coding skills, to keep my coding skills sharp. So I think a lot of this comes down to what your perspective is, and so my rough take is Miguel being such an elite software developer, a lot of these tools are going to fall short of his own speed and execution, and this is a big point of his.

Matt:

A lot of times when he's writing code, he doesn't know exactly what he's trying to create. The coding is the problem solving for him, and that I have very much found problem solving for him, and that I have very much found If I'm sitting in front of Cloud Code and it's asking me what it should do. I have to spend the time to figure out what I actually want to build beforehand, and so his point is he would rather just be in the code figuring that out versus in front of a prompt trying to figure it out on your own, and I can totally see how that would be applicable. I think that's a really great point. So Armin Roeniker, creator of Flask, and he just wrapped up about 10 years at Sentry. He's working on a bunch of things on his own, and one of the things that he wrote this article on agentic coding recommendations. He is, I think, more on the side of like he was really enjoying having a bunch of different instances of cloud code that are all running at the same time and he can just tell them what to do and he can come back to it. He can go read a book. He can do other things, he can answer emails while they're spun up and doing their own things.

Matt:

I also think that when I read the two articles, it highlighted to me that I think Armin is working on things that are a little bit more prototype like, as opposed to production code or what I would define as like sort of code libraries that need to be fundamentally solid, and so I do wonder if maybe that's a part of the perspective. I have found that when I write code myself and I write the tests and everything, I have a lot more confidence in it and maybe that is false confidence versus using an LLM or using an agentic AI coding tool, where I'm just going to have to spend a lot of time trying to figure out. Are there edge cases that I'm not seeing here or I need to run it through? I need that run that code through a bunch of other agents and LLMs to see what the gaps are, which I actually think is a really big advantage of LLMs. They can identify gaps in code, and so I think that it might be. It might also come down to like what's the workflow look like? If you're combining a bunch of these together, then you might see that what comes out the other side after running it through a bunch of different agents is actually much higher quality than what you could do solo. So I don't know. I thought it was. I just think this is like representative of a much larger discussion that software developers are having, and so the question is is, like you know, are junior developers more enabled? Are humans going to be taken out of the loop? The answer is probably like yes to a lot of these things.

Matt:

But depending on whether a company is writing mission critical cannot fail systems versus you're just prototyping and trying to stand up a bootstrap a company, you have a lot more tolerance for the edge case bugs that are out there. I mean, even for me with writing plush cap. There's definitely bugs in plush cap. I just don't have time to fix them. That's okay. Like it's not. No one's paying for the software, it's all a public website. So my tolerance for issues is just a lot. As long as they're not like security vulnerabilities where you can gain access to the server Like my, my tolerance is a lot higher.

Bob:

Yeah, those are great points. Yeah, it's very contextual right. Production code versus build your own kind of side gig thing where you're the only maintainer or maybe two people, versus an open source library where you really have to think through how to make this code very malleable and accessible for any number of developers.

Matt:

Yeah, the one other thing I'll say is like I think it also just speaks to how silly people are that are like I mean honestly, even a lot of folks from like big companies that are CEOs that have never written a line of code themselves and they're like all software developers are going to go away and it's like number one. You were never a software developer. You have no idea. You have no legitimacy in even claiming that. Number two is very opposite of what I'm actually seeing. I actually think that some of the people that are the most productive with these tools are the most senior, and yet I also think that there's a lot of junior developers who are really productive with these tools. So there's a whole landscape of potential outcomes. I think software developers going away is not one that I'm actually seeing in any real reasonable capacity. And you could argue oh well, I'm biased because I am a software developer, but my career and my job don't actually entirely hinge on being on writing software. So I would say, like I don't know, there's there's a landscape of outcomes.

Matt:

I think it is extremely naive to think that, like the complexity of things go away. And if you look at the history of what has happened with software development? Oh, cobol was going to make software developers go away. You know low code like Visual Basic was going to make software developers go away. You know low code like Visual Basic was going to make software developers go away. Low code, no code more recently, was going to make software developers go away. My guess is that we end up with a new equilibrium at five years from now, where we recognize you still need something called a software developer to manage the agents and the processes and make sure particularly in environments where the software absolutely has to work or else you're going to lose money you need those people to actually get things done.

Bob:

I see so much for humans. I mean the whole requirements gathering and pushing back on requirements. That's all humans and soft skills. Then's lms really do only a part, right, they, they might give you some boilerplate, but then you have to do a lot of iteration, um, but miguel's also referring to, to really get it to a production level, right, um, yeah, it might be good at at helping you find a bug, but, again, you're still iterating together with, like a sparring partner, right? So, yeah, it only fills in these gaps in a sense, but there's so much experience, experience required to even make sense of it and and to be able to, and that's that's why I think the more senior developers get the most use out of those tools, because they have better prompting and they they manage the context better, right, so, yeah, as long as they especially if they keep their sort of like professional egos in check, like I think.

Matt:

So much of this is about staying humble and staying really curious and and I think actually both Armin and Miguel to tie back to articles have done that. They just have different perspectives on whether it's making them more productive, whether it's something that actually makes sense for the projects that they're working on them more productive, whether it's something that actually makes sense for the projects that they're working on. So, yeah, I agree, I think a lot of the senior software developers are getting a lot out of this stuff and I don't think that that is going to make them suddenly vanish. The human in the loop, at least right now, is completely possible that there's something that is developed in the next five, 10 years, which means that human in the loop is actually less effective than human out of the loop. I'm open to that possibility, but, as of today's technology and even projecting out a linear, you know growth or or quality out of the LLMs, there's no way that this would lead to an outcome in which software developers are like not employed anymore.

Bob:

I agree, yeah, cool, so we'll link to two articles and then people should join our community to further discuss it, cause, yeah, that gives you a good perspective for two perspectives, and I think it's what we really need to read and think about and discuss it. Yeah.

Matt:

And actually just on the education side, like I think my own personal experience was that, uh, I, I studied computer science, uh, in college. I also was fortunate to have several years of computer science uh classes in high school. People told me that I was crazy in high school to go to college for computer science. So, like, all that stuff is going to be outsourced. This was like back when, like the world is flat, uh, you know, all that stuff will be just done in Asia, type of thing, and I was like I, I, this is really what I enjoy. I think this is like still really valuable.

Matt:

And actually I came out when I graduated from college there were so many less people that had been in computer science so my skills were so much more valuable to employers because there was such. You know, it was all supply and demand thing way less supply, way more demand for that. I could see us being in a similar situation five years from now, where some so many people who were turned basically turned away from going to computer science, going, studying programming and went into other fields instead science going, studying programming and went into other fields instead. And so there's huge demand for these skills but just not enough supply of it. And that only takes a few years, because someone in high school today will be graduating only a few years from now. So I wouldn't be surprised to see the pattern repeat itself, especially because right now we're in such a lull of needing. I think companies are still absorbing all the software that was created during COVID, and then there will be more that is built on top of that.

Bob:

All right. Yeah, Great point. So we're coming up on time. I have two more questions. Um so what are you reading?

Matt:

What am I reading? Honestly, I have not been doing as much reading lately and more watching YouTube videos, all on quad code I have.

Bob:

I have found that there in the background oh yes, I do have a.

Matt:

I do have a bunch of books that I read read for fun, outside of professional stuff. So this is very random. But I am going page by page through Isaac Asimov's history of human invention, which is like 800 pages and it just goes year by year of when was I don't know when were vaccines discovered? Back in the late 1800s, and it's just fascinating to kind of see which inventions happen in which year and then a lot of times it'll disconnect you from like I. Sometimes. You see something was invented in the 1600s and you're like, oh, I didn't, I thought that was like an 1800s invention. So it kind of like sets a timeline that is a lot more clear for you. I also have a book back there on about Blizzard and and creating games.

Matt:

I tend to like read a little bit more of the like nonfiction books, but that have, I would argue, like some level of maybe embellishment. So like Masters of Doom is like one that people bring up about, you know, creating Wolfenstein 3D and Doom and its software. You know it was supposed to be nonfiction but you could tell there were likely some liberties taken with the storyline to make it even more interesting. So that tends to be the types of books that I read. I also just, I also really like reading books about like different cities and things like that. So, yeah, I kind of have a few different books at the same time.

Bob:

Yeah, nice, cool and uh, how do you disconnect from work? Because these days you know is uh and doing your day job, plus the side project, plus phones and notification. How do you disconnect? How do you balance work?

Matt:

honestly, I, I. This is a terrible answer. I, I tend to not um, it is just what I do. That answer that's um, um, you know, I, I will set um, I, I will answer messages at any any time Like, uh, I and you, I, you know, you just have to like kind of figure out what works for you. Um, I think it's.

Matt:

I do think that it's unfortunate that you kind of always have to be plugged in now, especially like I work for a remote company. I've been running remote teams for a long time. As the company scales, it tends to just have more and more that you have to pay attention to. But I don't know, I've just found, like, rather than trying to like fight against that or disconnect from that, I will just pay attention all the time time. That said, I will do two things.

Matt:

I will put up Slack messages. For example, I'm out to dinner with my family. I will not be responding to Slack for the next three hours. That gives me the freedom to basically say I'm not looking at Slack. You can literally see my Slack status as I'm not responding right now. The other thing I try to do is take longer vacations Around the holidays, and the other thing I try to do is take longer vacations. So around the holidays, take a solid two weeks and really try to not look at any of that stuff. So rather than try to take a weekend here or there, um, try to take the longer periods of time and then in the shorter windows where I can't respond to people, just make that really apparent yeah, I I find that uh great advice.

Bob:

Uh especially like having these windows because you can be turned on like 7 24. You know like, there's yeah the phone, there's, it's always there, right, there's always apps yeah and some apps I have removed but some don't. I don't like, for example, example, our community um or signal whatsapp. Right, that's inevitable um, but yeah, just like. For example, when I wake up I do my coffee and reading and I try to not go to to these apps, at least till you know 8 am.

Matt:

That's really smart yeah, and and to be fair, like that's also a little bit what I do I try not to look at things first thing in the morning when I wake up, because that tends to be when my mind is so tempting yeah, it is very tempting, but then you know you give yourself an hour to wake up, go for a walk, something like that, then tap into it, as opposed to just looking at it immediately when you're, like, just starting to get out of bed.

Bob:

Yeah, yeah, thanks. I had to put that in because we're always like Python is nice and the developer stuff AI, but we're also all about work and life balance, or trying to find a balance. Yeah, it can be difficult, all right, cool. Well, thanks for joining and sharing all this gold and good stuff. And yeah, hopefully we have you back another time. And yeah, so it was great. Thanks, sounds great, thank you.

Julian:

Hey everyone. Thanks for tuning into the PyBytes podcast. I really hope you enjoyed it. A quick message from me and Bob before you go To get the most out of your experience with PyBytes including learning more Python, engaging with other developers, learning about our guests, discussing these podcast episodes, and much, much more please join our community at pybytescircleso. The link is on the screen if you're watching this on YouTube and it's in the show notes for everyone else. When you join, make sure you introduce yourself, engage with myself and Bob and the many other developers in the community. It's one of the greatest things you can do to expand your knowledge and reach and network as a Python developer. We'll see you in the next episode and we will see you in the community.