Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 471, recorded March 2nd, 2026.
It just still sounds weird.
And I am Brian Okken.
I am Michael Kennedy.
And this episode is sponsored by all of you guys and us.
So everybody that helps send some money our way through taking a course at Talk Python Training or a pytest course at pythontest.com or reads one of our books.
We're also Patreon supporters.
Thank you, Patreon supporters.
If you would like to send out, we get a lot of, we do a lot of research ourselves, but we also get a lot of tips from other people.
So if you'd like to have feedback, if you disagree with something or want to add to the conversation, go ahead and connect with us on BlueSky, Mastodon.
I think that's it.
Or just at pythonbytes.fm.
There's a contact form there.
You can also subscribe to the, actually one of the best ways is you can go over to pythonbytes.fm and subscribe to the email list.
And when you get an email, then you'll know our email address and then you can just send us stuff through there.
That gets to us.
Also, if you'd like to join the show live, that's fun.
Go ahead over to pythonbytes.fm/live and you can find out how to get, watch the show live.
With that, let's kick it off with the first topic, Michael.
Let's do it.
So this first topic is an article that I wrote, more of a design pattern that I would like to advocate for.
Okay.
Now, you see, Brian, I have this friend.
His name is Claude.
He's really good at writing code, but he gets super distracted.
Claude code.
So I've been thinking a lot about what does agentic programming and people leveraging these tools mean for like design patterns and architecture.
I'm a big fan of thinking about architecture and so on.
So I wrote this up.
It got super popular on Reddit and I thought I would share it here as well.
You know, popular in the sense that like lots of comments, lots of upvotes, but also a lot of like mean comments because it's Reddit.
So that's how it goes.
But good comments too.
First of all, I want to put this out as a disclaimer.
As you think about this, don't try to adjudicate whether or not people should be using AI for coding.
Don't try to adjudicate whether AI coding should exist, whether it is bad or good.
It exists.
People are using it.
If that's true, what should we do as an industry?
How should we consider, how should we move forward?
How should we think about this, right?
Are there things that would make that better or worse, right?
You yourself can decide you're not using it.
But as an industry, I think it's pretty clear that it's being highly adopted.
So that's kind of the goal that I had when I wrote this article.
Yeah.
And so the title is Raw Plus DC.
So as in Raw Database Queries and DC is in Data Classes.
And the subtitle is The ORM Pattern of 2026?
And I'm putting that out there because I think this is a pattern that is much,
much more aligned to the way AI coding works.
Why do people like ORMs?
And technically for this, I use what's called an ODM, an Object Document Mapper,
because I was using the example I extracted it from was written against MongoDB.
But whatever, like it's immaterial, whether it's Mongo or Postgres, okay?
Or SQLite.
People, developers love ORMs and ODMs because they provide type safety,
especially with like document databases.
They constrain what can and cannot go into the database, right?
You got to match the class and then the class goes in the database.
You don't just stick dictionaries in there, which is otherwise the case.
They prevent SQL injection or Mongo query injection because they always,
by the way they work, use parameterized queries.
They're a nice abstraction.
Also for developers, they provide really good IDE auto-completion.
So I have a function.
I give it a type or even the type is just discovered through type inference that it returns this class.
When I get one back and I say thing from the database dot,
it gives me a list of all the stuff I can do in the database.
All these things are awesome, right?
Yeah.
But here's the thing.
I ran to this literally this morning working on this project that I've not yet released,
but we'll talk about pretty soon.
These AI tools are trained so much more on raw queries than they are on any particular ORM.
So for example, I was using Beanie on this project.
Beanie is downloaded 1.4 million times a month, which actually is really impressive.
So Beanie is the ODM for talking to MongoDB.
The underlying library that lets you talk in the native query syntax is downloaded 74 million times per month.
That's 53 times more.
And there's other libraries for talking directly to Mongo as well, right?
So there's like 50, 75 times more bits of code out there that are actually just talking directly to the database than using this particular ORM.
Okay.
And that's true for SQL as well.
Like for just sticking with Mongo, right?
PyMongo is the Python version of this, but there's also people doing the native query syntax in Node, Deno, Bun, PHP, .NET, whatever, right?
Like all these other languages.
So if you actually do that sort of cross product, it's probably a thousand times more that AIs see raw database queries than they see any particular ORM, even if that ORM is popular, right?
Because it's for a technology and then it's sliced down into who uses that ORM rather than across all programming.
The other thing is, so these ORMs go unmaintained, right?
I mean, Django ORM probably won't go unmaintained, but they come and they go in sort of their popularity.
So for example, Beanie, it had only like three releases in the entire year of 2025.
Its last release was four months ago to close some minor issue.
And it's got a bunch, like almost a hundred open issues, even though it's downloaded over a million times a month, it's kind of gone unmaintained.
And before that I was using Mongo engine, which is way more unmaintained than Beanie.
Like Beanie was the exciting new one, right?
And so what do I have to do if this changes?
If I decide that it's too unmaintained, I have to completely rewrite it in a different ORM.
But if it was written in a regular, just straight query syntax, that doesn't change, right?
That's been identical for SQL since the databases came out, identical for Mongo since Mongo came out.
I mean, they add to it a little bit, right?
Like if they add a feature or something.
But generally, it's going to be the same.
So I don't have to worry about it.
These things are going on the same.
Go ahead.
I want to interject a little bit.
You threw out Django.
I was going to comment that Django might be an outlier there in that a lot of, I know there are people that use other ORMs or raw SQL with Django.
But I think it's probably a lion's share of the Django users that use the Django ORM.
And I don't think that's going away anytime soon.
I totally 100% agree with you.
But what if you decide you want to change your project to a different web framework?
Well, I would probably say the same argument is that you could probably switch to this raw SQL plus data classes from Django, the Django ORM, because there's a ton of Django stuff out there.
I'm pretty sure that the models are trained on lots of Django.
Yeah, they were pretty well trained.
So this maintained argument is not go for everything.
But it's definitely another angle, right?
Yeah, and also, I think that you probably touched on this already, but just one less dependency is one less thing you have to keep up on.
Yes, absolutely.
And it's not usually just one dependency, right?
It's like this thing depends on four others, which depend on three.
And now there's a CVE in one of them.
You're like, ah, man.
Okay, so let's – but there's reasons people like these ORMs.
I am a huge fan of ORMs because they give you back classes that are great.
So my proposed way of working is create a nice data access layer, put functions in there that are very clear, like create user, update password, whatever.
And then inside, let it be raw queries.
Let Claude write however Claude wants.
But when stuff comes out of there, it has to return some kind of class.
So I propose data classes, okay?
And I think data classes are pretty interesting here for a couple reasons.
One, they're typed, right?
They look like – you can tell them use slots.
That's just good for memory and performance.
They're typed just like if you use Pydantic or if you use any ORM generally.
So that's really good.
They're also built in, so no dependencies, as you pointed out.
And they're very, very lightweight, which is great.
Now, they have type safety in the terms of like type checking type safety.
But they don't have runtime type safety like, say, Pydantic, right?
Yeah.
So if you want – another very reasonable option would be to do a Pydantic plus raw queries.
I didn't use Pydantic because this means every query that comes back from the database gets validated.
And there's a whole bunch of machinery that runs when you're reading from the database.
But if the data in the database is wrong, it's already too late.
It doesn't matter if your class says it's too bad.
It's like, no, it's saved.
It's too bad.
It's too late.
And so maybe on the outside layer, you could use Pydantic, but in the data access layer, you could use something lighter.
That was my – that's my take.
When I posted this on Reddit, people probably like 50 times like, well, why aren't you just using Pydantic?
It's like, well, Pydantic is great.
It doesn't have to be used for everything.
So anyway, I'm going to follow up with one more thing that's pretty cool around that.
But yeah, so if you look at the performance really quick here as well, I did a nice graph of a bunch of different things.
What's like 1,000 reads look like?
What does 1,000 writes and so on?
And this graph is based on doing just raw queries without any class component because that's really the foundational – like they all have to do that, right?
So how much overhead does each style add?
And it's not exactly perfect because this raw data class style can't be faster than writing itself.
In a lot of places, it's literally the same code.
So it's just like fluctuations in the machine.
But if you look at, say, Beanie, which is based on Pydantic, so this is more or less just Pydantic.
What would Pydantic look like in this model?
It's a lot of times pretty close, but sometimes it's like five times slower.
If you look at Mongo Engine, which is another one, 15 times slower, 10 times slower, it's a big difference.
It's quite a big difference.
So this style is actually almost native speed.
There's just a few times where the serialization maybe doubles the time to read, say, 1,000 or 100 orders or something like that, but barely.
Anyway, I think it's pretty interesting.
What do you think?
Yeah, I think that one of the reasons to go with an ORM was speed of development because a lot of people don't know SQL queries that well.
But a good SQL query is not that hard to read.
Well, it can be.
But generally, they can be decent to read.
Trying to figure out how to write it might be tricky.
So that's where I think your argument of around using agents and stuff to help with this, they're going to know how to write a decent one.
And you can probably, even if it's ugly, you might be able to say, can you clean that up so it's easier to read?
Yeah, or explain it to me.
Yeah.
But anyway, I think it's valid.
It's definitely valid.
I think it's more valid now than it has been in the last couple decades.
So, yeah.
Yeah, just this morning, I asked Claude to do this thing with Beanie.
I said, oh, it would be way better if I just used a projection.
And for projections in Beanie, you have to create a subclass or a different class and then use that.
And it's like, oh, I could just use dictionaries.
Then it crashed.
Oh, I don't think I can do that.
Let me try the aggregation pipeline through Beanie.
And that didn't work.
I'm just like, could you just do it directly?
And it's like, oh, yeah, that works.
It's just, you know, it's kind of a little bit clunky.
One other thing that was really popular in the conversation about this article was what Kiva Birb is asking is, what about migrations?
Not relevant to ODMs, but certainly relevant to ORMs.
You do what everyone else does if you write straight SQL.
You write your migrations yourself.
But the thing is, like, my assumption is this pattern is most adapted to agentic coding.
If you're just doing raw straight coding yourself, stick with ORMs.
That'll handle it.
But if you're doing agentic, like, Claude Code can write a heck of a migration.
It doesn't care.
It's going to be great at that.
Yeah.
I guess I've just sort of leaned on migrations a lot.
And I actually don't really know what they do under the hood.
Yeah, I mean, what are migrations?
They are basically, they are a statically generated, like, pre-generated SQL script that says, add this field, change this field, change this type, copy these things.
It's a set of SQL steps for transforming the schema of the database.
And typically the way migrations work is it looks at the old version of the class and the new version of the class and goes, what do I got to do to write the SQL to make one go from one to the other?
You can just ask Cloud to do that.
I also really like the comment about have a data access layer, because I think that that's a good idea, even if you are using an ORM.
Yeah, thanks.
All right.
Well, that is plenty on that.
I mean, you should definitely test your code if you're going to take on this way of programming.
Yeah.
Nice transition.
I've been spending some time in the last week cleaning up, giving some love to pytestCheck.
So pytestCheck is a little plugin I wrote a really long time ago, many, many years ago.
But the last release before recently was in November, I think.
So yeah, October, November, something like that.
So I've decided to spend some time getting it back up to date.
And I did, I like all the stuff on GitHub, the activity, pulse activities thing.
So there's been three merged pull requests.
Sorry to everybody for taking so long, but it was only, I guess I only annoyed three people.
And there is, yeah, I closed a bunch of issues, eight closed issues.
Now, I did get to the point where I had only one enhancement request and no actual issues and no pull requests.
That, you know, that doesn't last very long for projects that are being used.
And I hadn't checked the little stats thing recently.
And it's used by almost 1.3-ish thousand projects.
That's fun.
Anyway, I just wanted to bring it up that that's still in the live project.
And I'm going to keep it up.
I'm still having fun with it.
I still use it every day.
So that's one of the reasons.
The changes, there's not a lot of extra features.
There was a support for raises parameter when you're doing xfail.
That works now, which that's really kind of a bug fix, but it was extra feature.
So that was a pull request.
So thank you.
But some documentation things that I've been noticing this at work, too.
If you have a new feature and you don't document it, it's like invisible work.
Why did you do that work?
So I added some documentation things.
But a lot of it was around my Pi because a lot of people are using my type checkers and
using Pi test check.
So I updated a lot of stuff.
But I guess I have got a question or kind of an open thing.
I was going to try to make it like strict compatible, but I don't think I like it.
So with strict compatible, you have to do things like return none and have a lot of extra decorations.
It's a test.
We know that Pi test tests return none.
They have to.
I think this is overkill most of the time.
So for most of I think it's cleaner just to not show that.
These are supposed to be examples of how to use it, how to use a tool.
I think it's fine to not have a lot of that stuff.
So I still do type checking on the examples, but I'm not doing strict.
So anyway, that was my two cents on that, I guess.
I think it's fine to not have type safe or type clean types, clean strict type checking results on example code.
I think it can be too much.
I think it has certainly a value, but there's plenty of times where it's just too much.
And these type checkers can definitely get out of control.
Like I had something similar with Flask where I had a Flask view method and I had a custom decorator.
And the custom decorator didn't declare its types in a way that it was identical to this really complicated, you know, app at app dot get sort of signature.
And I got these huge crazy warnings saying this function has a mismatch on the signature.
I'm like, it's called by Flask.
No one calls this function.
I don't care about expressing what its signature.
It works fine.
Just leave it alone.
You know what I mean?
Yeah.
It can go way too far.
There's some things that I need to also things I need to look at.
Because like for an example, for a test, doing something like assert one equals two makes sense.
You know that's going to fail.
That's a great example, I think.
But like the mypyth says that that's an error.
And because what, int constants aren't comparable?
I can't remember the error, but it's weird.
Interesting.
Yeah.
It can be over that last one or two percent is just, it's folly.
That's what I say.
So anyway, thanks to everybody.
And yeah, if you don't, this isn't a dead project.
Yay.
Cool.
Yeah.
It looks awesome.
And over a thousand projects using it.
That's pretty good.
Yeah.
And some of those have lots of stars.
So.
Nice.
Transitive stars are piling up.
Feel it.
Anyway.
Okay.
What you got next?
What I got next is I want to talk about what, something I learned through that whole discussion
around that raw plus DC design pattern that I talked about.
Somebody, somebody said, look, you are so close, but where's your validation?
I'm like, you know what?
I'm not really sure I need runtime validation when I'm reading from the database.
Maybe writing to it.
Maybe.
But anyway, I learned about a couple of really cool tools that you can use.
So for data classes, there's this thing called the data class wizard.
Ooh, a wizard has a cool wizard hat.
It's simple, elegant wizarding tools for Python's data classes.
So this is actually a super neat project here.
So, and fun docs, behold the power of data class wizard.
So what you can do, there's different ways you can use it.
You can use it through what are called mixins, which are like, they add some functionality,
you know, through inheritance.
Okay.
You know, maybe like a from JSON function, something like that.
But also lets you specify other interesting things.
Like, I didn't even know you could do this in the class definition, but basically pass
configuration values to a class, the class constructor for the type, I guess.
Anyway, you can say, hey, I have a regular data class.
But in fact, I would like it to be unconcerned with the case of the inbound data.
So somebody doesn't say C# and they write Pascal case things, right?
Like lowercase and then uppercase second bit or, you know, camel case type of things like
we do for classes for their fields.
But I want to express them as, you know, snake case is active Tupa with underscores and not
capital A, capital T sort of thing.
You can just say, oh, that doesn't matter.
And if I ever dump it out, put it back out in camel case, because that's what the people
who are working with this API want.
So this data class wizard is like a, it's like data classes, but it adds that type of functionality
to it.
Right?
Cool.
Which is super cool because my example, I said, oh, well, you just got to write a from
JSON function that like turns it into, they're like, why would you write that?
You could use the wizard.
Like, cause I didn't know about the wizard.
Tell me about this thing.
But there's other ways to use it as well.
You can have just a regular data class and mix in the JSON wizard mix in.
So then you get to and from JSON, kind of like I just described.
This is super cool.
You can have a, an env wizard.
So I can then have a data class that derives from env wizard.
And then it reads as you just instantiate it.
It reads from the environment variables.
That's neat, right?
Yeah.
So you just have a config file and has all these variables and you just say, guess what?
Those come out of my environment or doctor variables or whatever.
And yeah, pretty neat.
They've got the JSON wizard, the list wizard.
Cause sometimes you get a set of JSON and it starts as a list instead of curly braces.
And then it's hard to parse.
So, files, Toml, Toml and YAML.
You can also get ones that'll read and write Toml and YAML data classes that basically naturally
know that type.
And if you just keep going, it says you don't have to use inheritance either.
You can just create standard data classes, even hierarchical data classes.
Like here has an A class, which has a list of B types.
And those are also data classes.
And then you can just use the from dict from data class wizard.
Say it's this type and here's the dictionary.
And then boom, it's like a little factory method sort of thing.
Oh, that's especially great if the classes come from somebody else.
Exactly.
And it also does really interesting parsing.
I can't remember where it is in their documentation, but it does, coercion or of types.
I don't know exactly how they refer to it there.
But if I've got, say I have a list of integers like Pydantic, it does, or at least used to
do like one.
And then the quote two is the second entry it'll, and it knows it's supposed to be an
end.
It'll turn that into an end and stuff.
So it kind of brings a lot of what Pydantic offers to data classes, but only when you want
them.
Cool.
You're like in this place, I want to parse it and validate it, but not other times,
you know what I mean?
Stuff like that.
So anyway, I present to you the data class wizard.
It's pretty cool.
Yeah.
And hopefully it stays maintained.
Okay.
That's a good question.
Let's go.
Let's, let's go to the GitHub.
It says 3.14, I think tested at least.
Yeah.
Okay.
Two months ago it had an update.
It only has two open pull requests.
So that's pretty good.
It doesn't have 200.
Yeah.
Anyway.
Yeah.
Pretty neat.
I'm liking it.
I haven't really had a chance to use it because I just learned about it, but I like the idea
of it a lot.
Yeah.
That looks fun.
I have got a, another project that is in a similar boat that I haven't, I haven't really
tried it that much.
I downloaded it and installed it.
and what it is, is SQL light.
Oh, SQL, IDO, SQL.
SQL IDO.
I think it's gotta be SQL IDO.
That's the fun.
SQL IDO.
So this is, this is a new little toy from, Adam Hill.
And, I noticed, I can't remember what, I think I saw a social media post on it or
something.
Anyway, it's a macOS SQL light browser built for normal people, apparently.
so, but it looks good.
It looks in with the little, all the emojis.
I'm thinking, wow, I think he used, maybe some agents to help build it.
And that's kind of what I want to talk about.
But, but I do like, it, it does look good.
the, the, oops, error loading page.
I don't know.
Can't, I can't look at the over the overview pictures that much more, but, it looks
like a very nice, interface to, you know, look at your SQL light databases on Mac.
So that's cool.
so why am I bringing this up?
I'm bringing it up kind of because, there was a caveat with installing it and it said,
um, it's a, it's a, it's, you could download the DMG and then you drag that to your app
folder or just double click it and then you start querying, but there is, it's not verified.
So it's not through the app store.
it's, it doesn't have a developer certificate yet.
so why, why am I okay with like trying this out?
Well, I think it trust is a big thing.
I trust Adam Hill.
I've seen a lot of his work.
I've seen him comment on stuff.
He works on open source projects.
and so there's some inherent trust there.
If you don't know who Adam Hill is, you don't have that of course.
but there's, there's other things I was looking at.
So I was looking at the source code a little bit and he's openly saying there's agents there.
there's an eight.
Well, cause there's an agent's file or something talking about.
Yeah.
Interesting.
It looks like it was built with Gemini.
Okay.
There's not a Claude.md, but there's a Gemini.md.
Yeah.
And that's just pointing to the agent, his agent at MD file.
and then there's, there's like some other stuff on, like there's a directory with
some to-do list ideas and stuff.
And I think, I think just being like not hiding it, I think is good.
And also another thing I checked out is the contributor because there's, I don't, so all
the contributors are him.
So I, I, I'm thinking that even if like there's a bunch of code written by agents, he's
at least looking at it enough.
And I don't know.
I'm still on the fence.
I don't know how I feel about people giving agents control of, commits, on a project
or not.
I think I'm not here for it.
You're not.
No.
So, but like what I would, if I would was, what, what would I be okay with?
having somebody, do this stuff and then commit themselves because you would
assume that they're looking at it.
But what if you just do that on a branch?
If you had, if you had the agent working on a branch committing stuff, you could always
just throw it away.
And if you're happy with it, you can merge it.
I don't know how it's different.
so.
I, I hear you.
I hear you.
I certainly think your branch makes it better.
A feature branch, some exploration branch.
But it would still show up as a contributor in the history.
so that's, I guess that's where I'm going with that.
Yeah.
By default, if you ask Claude to create a GitHub, a Git message, it'll put, or PR,
it'll put co-contributor at Claude.
Yeah.
So I still, I'm not, I'm still not sure how I feel about all that, but, but I do,
there's, there's just, there's other things.
So I'm thinking, I trust the developer.
I trust that I look, I look at the contributor list and I look at some of the commits.
what else am I looking at?
I'm looking to make sure that there's tests, even though, I can't read a Swift test very
well.
I don't know.
I mean, there's at least some testing going on.
so, so that, that, I guess that's, that's where I'm, I'm at with, some of
these things.
I, and I bring this up partly because I review a lot of projects, you know, for this, for
this, podcast looking at projects.
And if it looks like there are signs like a bunch of emojis, that's not necessarily bad,
but it's a sign that somebody had agents help them with it.
And actually a lot of people are really bad at writing read me.
So I'm okay with people having help writing read me.
but I'm looking for tests.
I'm looking for what the contributor things I'm looking for a lot of stuff, and trusting
the developers a big thing still, I think.
So yeah, a hundred percent with a command book, my app for managing like long running
terminal like commands.
Yeah.
I had to go through the same thing, had to get it digitally signed.
Both the app bundle itself is digitally signed.
And then you have to go through a separate process to sign digitally sign the DMG as well,
which is an utter pain for sure.
So it is a hassle, but if you have an Apple developer account, it's not too bad.
It's way less bad than iOS and app store review and those kinds of things.
It's just running it through like a series of tools.
So if Adam Hill, if you're out there listening and you want, a quick bit of help, happy
to help you get over that last hump there.
Okay, cool.
it doesn't say yet.
So I think he's planning on it.
So I know it's just, it's brutal, but like, here's another thing.
I like, I ask, I ask Claude, I'm like, all right, Claude, you got to help me.
I I'm lost here.
I do not know how to notarize this thing.
It's which is what it's called.
And then like, do I have to notarize the DMG as well?
And how do I pack it?
And I'm like, okay, here's a big long list of steps I got to set up.
And I got like, it was pretty helpful actually.
And that another thing, I guess a little bit of a tangent, right away from the trust thing.
I think this seems like a tool that Adam wanted.
And because of agents, he found time in his schedule to build it.
and we wouldn't, without it, we probably wouldn't have this tool as something we can
look at.
now trying to get people to stay maintaining projects that they can open source in a few
hours, over the time is a different story.
But anyway, I guess enough on that.
I guess I do think we're entering an entirely different era of highly personalized software.
I made this for me because I could do it in an hour and exactly it solves my problem.
maybe it's interested in you, but it's not built to be general.
It's built for me.
Yeah.
There's going to be some of that, but why open source it at that point?
yeah, fair.
Anyway.
Well, that would be extra work, wouldn't it?
Yeah.
Do we have any extras?
I do.
Do you got any while your screen's up?
Yeah, sure.
I'll do.
and it's all on the same sort of topic.
So, an article on, htmx.org blog, called yes.
And from Carson gross, this says, I teach computer science at Montana university,
Montana state university, and father of three sons.
And he gets the question given AI, should I still consider being a computer programmer?
Or I would translate that is into is a CS degree still worth it?
and his response is yes.
And, and I do, I, it's a great article.
enjoy reading it.
the, the top level thing is, programming is fundamentally problem solving using computers
and learning to control complexity while solving this problems.
I would say that that's, that's computer science.
but that's, and then a bunch of other stuff.
I think it's experience helps even, and, and background knowledge helps even if you're
using AI to help, then that's the same kind of a similar sentiment over on, Simon
Willison's blog, hoard the things, you know, how to do.
one of his recommendations here is, a big part of a big part of the skill building
softwares understanding what is possible and what isn't, and having at least a rough idea
of how those things can be accomplished.
And this helps with directing agents.
You wouldn't ask it to do things that, you know, is going to be a completely ridiculous,
um, I mean, an agent might go off and do something dumb, but if you ask it to, you just,
you do have to have experience to know what dumb is and what it possible is, I guess.
So, yeah, I agree with Carson that yes.
And I think I basically the short version is I believe Jevon's paradox is real and that
we're going to have more software rather than no software developers.
And we need people to oversee and guide and make decisions and trade-offs about that.
Right.
It's very hard for AI to make proper trade-offs.
Like, yes, I know I could, yes, I know I could make this an app, but my company doesn't have
a culture of putting apps out.
And we actually have this other backend system we want to, you know what I mean?
There's just like all this information that it doesn't know, or like in our industry,
here's how we do this.
And there's just a bunch of stuff that humans can bring plus the ability to break it down
into smaller problems and then give that to an AI.
You're way more likely to be successful than just like, Hey, guess what?
I need a CRM build that.
I'll be back by lunch.
Like you're going to get some form of something, but it's again, it's not highly personalized.
It's just super generic.
And if that's all you want, just go get a CMS from like some SAS and you're done.
I think one of the really interesting things is like, why do we build software at all?
You know, there's this term software engineer, right?
How well it applies.
I don't know, but a lot of times, especially in the early days of like talking about architecture
and engineering, it was all tied back to like, well, how do civil engineers do it?
And they have all these, these formalities of how they work.
And maybe that should be brought into computer engineering and programming and software engineering
and so on.
There's a really big difference.
Civil engineers built a bridge 50 times because there are 50 places the bridge need to be built.
If you build a piece of software that solves the same problem once, like you just run it again,
you copy it and run it, you build new software because you're solving a problem that in some
way has never been solved before.
So there's a difference.
There's like this, this, the part where it's never been solved before.
That's where the human brings in the stuff to the AI and the AI goes, well, there's all
these Lego blocks that we already know.
Like, all right, put those together.
But for this, I think that's what software engineering is going to become.
Yeah.
I mean, I think it has become that already.
And electrical engineering has been that way for a long time.
So, yeah.
I mean, already with like packages on PyPI and things like that, it's kind of like that.
But like with AI, it's instead of, I need an auth library so I can build a login page.
It's like, I make a login page.
Now click that together with it.
You know, it's just like another level up.
But that doesn't mean that people necessarily go away.
I hope not.
At least for another 20 years.
Yeah.
Give it, give it till, till Brian and I retire then.
All right, I got some fun extras as well.
Okay.
So, first of all, how would you like to unplug your Python and get a bit of an MTV vibe?
But it's PyTV.
Yeah, it's so fun.
So, our friends at JetBrains and a bunch of our friends who are speaking at this conference,
but are not necessarily at JetBrains, are putting on a free online Python conference,
the best Python, straight into your living room.
I feel like Max Headroom should kick off the keynote, honestly, don't you?
I love Max Headroom, yeah.
I know I did too.
But there's a bunch of great people speaking here.
Carol Willing, Sarah Boyce, Marlene, Gina, Carlton, a lot of folks we know.
And so, yeah, check this out.
It's a free online conference.
And is it this week?
When is it?
Let me look.
It must have a date, surely.
I know.
I think it is this week.
Yeah, March 4th.
So, we're recording on March 2nd.
That would be Wednesday.
So, everybody be on top of your listening to the show or miss out.
Okay.
So, that's one.
Quick shout out to that.
Next is, is AI a fad and a bubble?
Or is it an actual thing with real value that's going to change the world?
Yes.
So, remember we talked about the Sasspocalypse where like some of the legal companies and
other stuff where like their stock went way down because Anthropic published 13 markdown
files.
Well, IBM, IBM, big blue stock crashes 11% because Anthropic released some kind of markdown file
that helps convert Cobalt.
Because Anthropic threatens the Cobalt empire.
I think there's a lot of interesting stuff here.
I think Cobalt is a very interesting analogy for like pre and post agentic written code.
I can see in 20 years are like, that's some pre AI code.
We need some humans that know how to type still to come in here and look at this.
Right.
I think there's going to be that kind of like difference as we go on.
And so, I don't know.
I just wanted to throw that out there.
It's an interesting read for folks.
Yeah.
The language stuff is an interesting thing.
With things like Anthropic around, I am less scared of looking at code bases like Swift
or Cobalt.
I haven't looked at Cobalt, but I wouldn't be afraid now.
I might be able to just.
A hundred percent.
Yeah.
You need like 20% the capability you used to need to get something done or to get like,
I don't understand this.
Explain it to me.
Like, okay, now it makes sense.
Whereas before, I was just like, I don't understand it.
Well, especially if you write a test for it.
So, you write it like maybe there's a bug in some Cobalt code and you say, and you write
a test for it.
And now the agent, you can kind of trust the agent to fix it.
It'll do good review, of course.
But yeah.
Yeah.
Okay.
Quick update.
I'm absolutely in love with my 40 inch curved monitor that I told people about for.
When I first got it, I was a little wigged out by how big and rappy around it is.
It took some getting used to, but this like 5k monitor that is so giant is absolutely perfect
for all the type of work we do these days.
Next up, update est, update est, not ist.
I tried to search for it.
Update ist, I-S-T.
No, it's E-S-T.
So here's a really cool macOS bit of software.
And what you do is you just install it and it looks for all different kinds of apps that
are out of date on your system.
It looks for auto updating apps.
It looks for stuff from the app store.
It looks at homebrew.
It looks at CLI tools and it manages all of them.
So you go, oh, look, this thing's actually, that was been depending on.
It's actually out of date.
Let me push the button.
And super cool.
It's got a really nice UI.
It costs, it has money, but very little.
It costs $13 once for your entire life.
So anyway, it's pretty, seems pretty fair to me.
So very cool app.
Also Swift UI app, I believe.
I like Adam Hills.
Wait, how do you update it though?
Oh my God.
I believe it does auto update.
Okay.
If it doesn't, that would be deeply bad.
I think it uses the same thing that Command Book uses, which is called Sparkle, which is one of the most common ways to do it.
And actually it looks at all the Sparkle update feeds of all the apps installed on your system too, which is cool.
Okay.
People may have heard of Bartender, which is another Mac app.
That's cool.
Like compresses all the little widget thingies you got at the top on the right by the clock.
I love all those things.
So I go way overboard and I needed something to manage it, especially on small like recording screens.
So I had Bartender, they got bought in like a sort of underhanded way.
Like they got sold, but then nobody said they were sold for like months.
It was like, they wouldn't announce.
Anyway, it was weird.
So a lot of people moved to open source stuff.
So there's a one called Ice for the Mac menu bar, but it had its last updates like six months ago and it's clearly abandoned.
So you got ice.
Well, what if it gets stuck and frozen?
You got to thaw it out.
So now there's a popular one called Thaw, a fork of ice, the menu bar manager.
So anyway, here's a free open source menu bar manager for Mac.
That's pretty cool.
Following that weird chain of events over the last couple of years.
I don't even remember what I have.
On this computer, I still have ice running because I haven't had a chance to update it.
I just learned about this week, but it's getting thaw.
It's getting thawed out when I get done with this recording.
Getting thawed.
Yeah.
I have something that minimizes it, but I can't remember what it is.
I don't know.
Yeah.
Okay.
Well, shall we make a joke?
Yeah.
Something funny.
I know you got kids.
I have kids.
Anyone out there who has kids, well, maybe roommates as well, but especially kids.
Like they're so messy.
This joke will appreciate.
This is like a programmer take on that situation.
And the title of the joke is The House is Read Only.
Okay.
The House is Read Only.
So here's a woman named Kelly on X that posted.
It says, I have cleaned the house.
The house is now read only.
Please do not edit the house.
Yes.
Kids.
I just put the dishes in the dishwasher.
Why is the sink full of dishes again?
I just went up to the back to clean up the other stuff.
I came back in and now it's messy again.
I can't take it anymore.
The house is read only.
It's so good.
I need this for my mother-in-law.
Yeah.
If you don't pay the mortgage, you don't get to put holes in the walls.
Just saying.
Houses read only.
Please do not edit the house.
Nice.
That's funny.
Yeah.
It's been a crazy week outside of programming.
So I'm trying to concentrate on programming.
Escape to the well-known world of structured text.
Let's go.
Anyway.
It was a fun episode.
Thanks everybody for showing up and we'll see you all next week.
Yeah.
Thank you.
Bye.