# Open Source AI Models and Engineering Productivity

**Podcast:** Dev Interrupted
**Published:** 2026-07-10

## Transcript

You know, Andrew, I feel like week after week on this show, we're just, we spend so much time thinking about like all the bottlenecks that are being created, like with, with AI and, you know, all the processes we have at different companies and the tech stacks we have.
But, you know, after reading some of the articles we had for this week, I came to the realization that we don't always talk about the biological bottlenecks.
So I don't know, Andrew, after this article we read this week on how the bottleneck for your team might be the error in your room and specifically how much CO2 is in the air, are you walking around with a CO2 monitor now?
Because I'm kind of thinking about doing it.
No, I've kind of wanted to put one of those in my home assistant.
I won't lie.
I loved reading this article about sometimes the biggest enemy in a meeting is the fact that you've been locked in a closed room with a whole bunch of people with poor airflow.
I, as someone who has unfortunately suffered through office work before, I think this is a totally real phenomenon.
You know, air quality in the workplace is a big deal, but it also points to like everyone needs different levels of air quality as well for their health.
And it's good to be in an environment like...
In my case, working from home, where if I want to monitor my CO2 levels, I could maybe install something easily.
And frankly, there's less people breathing the air with me right now in my living room.
Yeah.
Yeah.
And we'll include a link to this article in the show notes.
But, you know, the TLDR is that there's some new research out that says that, you know, if CO2, it actually doesn't take much for CO2 levels to rise to a level that negatively impacts your cognition.
So if you're sitting in a long meeting.
in a room with other people, or even if you're sitting in your home office, just working by yourself, it's actually not that uncommon for you to be in an environment where the CO2 is actually causing you to have brain fog or to just make poor decisions.
So yeah, it was a really great read, something to be conscious of, I think.
And just add it to the list of reasons that I need to go out and buy one of these CO2 monitors.
Because I've thought about this a lot of times over the years, and I think it would actually be nice to get some data on it.
Okay, well, I'm going to hold you to it.
Yeah.
All right.
Well, maybe next episode you'll see one behind me.
But yeah, welcome to the Friday Deploy brought to you by Linear B.
I'm your host, Ben Lloyd Pearson.
And I'm your host, Andrew Ziegler.
And this week we're covering some open source AI models, the limits of local AI, the weakened feature that spooked Facebook's C-suite, and when AI erodes deep reading.
Excuse me, I'm not Adam.
Adam's helping us record this.
Andrew, let's talk about these open source models because this is, I'm excited about this actually, like what we're seeing here.
So what do we have with GLM 5.2?
Okay, GLM 5.2, open source model, recently hit the scene under an MIT license.
And many folks that have been trying out the different open source models that have been coming out in the last few months, there's been a number of them, have started the circle around this one as, oh yes, this one feels right in the coding harness.
And it's the first of an open-weight type of its kind to be performing at the levels that we're seeing on benchmarks against foundation models.
But also, too, it just has a healthy respect for balancing things.
thinking, action, and tool calls in a way that other open source models have up until now kind of been experimenting with getting right.
And this also points to just the significant foothold that open source models have gained.
In the last few months, we've been seeing a number of really huge high profile releases that are competing with very large and expensive foundation models that we see as like the leading ones on the market.
And so it's really interesting when on these targeted benchmarks, you start to see these smaller open source players really start to rank up.
Yeah.
You know, Andrew, you and I go back and forth on this.
Like I told you so debate around AI costs like.
Fable comes back out last week and you win because AI costs are just getting higher and more expensive than ever.
But I think this article and this development is actually a win for me.
It's proving that there is still that downward pressure on AI costs.
So I don't know, Andrew, what do you think?
Do I deserve a victory lap on this one?
You do deserve a bit of a victory lap.
I will say that I am not happy that I'm correct.
The API, AI token costs have gone up.
But the reality is, is that model routing is only going to get more important.
You're right.
Fable coming back on the scene just reintroduces a huge.
a gradient of intelligence that you can be working with on the tasks and the importance of choosing the right model at the right cost for the task at hand.
I think that becomes the new levers that we're all playing with.
And, you know, we've been experimenting with how to do this for a while in the show, been talking about open source models being a key component of how even huge companies are transforming their internal workflows and reducing their bill, which is allowing them to reinvest into their engineering.
And, you know, one thing that I think was really important that was pointed out in this article was how many of these low cost and open source models are about six to nine months behind the frontier models in terms of the capabilities that they're developing, which kind of sounds like eternity in this day and age.
But I think that's actually really what makes this so exciting, because if you remember back to where we were at the end of last year, you know, about seven, eight months ago.
You know, we were covering the emergence of like the Ralph Wiggum loop and beads and how these new technologies were changing the nature of agentic coding.
And that was the point in time where, you know, the frontier models got good enough for high degrees of autonomous coding.
And that practice started to go mainstream as a result of it.
So now we're reaching that same point with open source models and the options that we have for high capability models.
is now exploding while the costs are also declining as well.
And, you know, as you mentioned, model routing, I mean, it's really the thing that we're missing.
I feel like it's the biggest gap in terms of agentic infrastructure right now is having some sort of layer that automatically knows which model is best suited for the task.
Because like today, I feel like everyone is just sort of taking their own approach.
Like they're building these like homegrown custom solutions for it that are even like sometimes all the way down to like the use case level.
It really feels like we're in the experimentation phase of those model routers in a way that reminds me of where we were about a year ago with just agentic coding in general.
And we're seeing how models like Fable, we brought that up already, they're getting really good at delegating tasks to sub-agents, but we also need these services to choose the model for all of those sub-agents as well.
to reduce the cost whenever possible.
And, you know, and I don't know that Anthropic is really like incentivized to do that, right?
Because they kind of want you to use more of Fable because it makes them a lot of money.
But, you know, we've been covering, and this model writing, I think that is the next big unlock within the agentic coding space.
And we've been covering, you know, token maxing a lot here at DI.
We just had a workshop at Linear B on this topic and how to be efficient with your AI usage.
And I feel like, AI token costs really are top of mind for every engineering organization who's rolled out new AI tools over the past year or two.
And token maxing, it really kind of stinks when your costs are spiraling out of control.
But it can actually be kind of an amazing force if you do it while minimizing costs and ensure that that velocity is actually translating to actual productivity gains.
And this is stuff we talk to engineering leaders every single week about, which we really love.
But yeah, you'll have to tell me what your agents think about GLM 5.2 once you've had the chance to dissect it in your lab.
So let me know how that goes.
And in the meantime, I'm expecting this pressure from low-cost models to continue building for companies like Anthropic and OpenAI, particularly how quickly their advancements can be replicated in these other models.
Completely agree with the pressure, and folks are going to be pressured and needed to experiment on this.
And I have already poked around on the model.
It's pretty capable, and I think that it's going to have some really promising stuff for us in the future.
And one other thing I want to point out as well, just in defense of Anthropic a moment ago, you said about obviously they want to incentivize us to use more of Fable and the expensive model.
And that's totally true, but Fable is actually a first-in-class of its kind that has this kind of model routing built.
into the intelligence because it will reach out to Opus for some kinds of security flagged coding requests.
It will go out to CODIS instead of doing it itself to avoid potentially being used in an incorrect manner.
And in the same way, it will delegate writing things out to Sonic 5.
So it does think of itself as like, I have these agents that I reach out to.
Anthropik's been making a number of strives towards this because ultimately routing is a matter of of intelligence itself.
You can't fully deterministically route everything you need in intelligence to route the intelligence.
And so it becomes a question of like, you know, who routes the router?
And it turns out that maybe that's going to be like the anthropics of the world.
Just routers all the way down.
And speaking of routers all the way down, let's talk about the viability of local models for coding as a model to delegate your sub-agents to.
So this article comes from friend of show Brigida Boeckler at ThoughtWorks.
She spent about four weeks testing some locally run AI models for coding tasks and found that while the experience has improved pretty significantly in recent months, it's still too messy for most developers to adopt without some serious effort.
She did a whole bunch of scenarios and tested performance and model output.
She pointed out that RAM is one of the core constraints that all of this faces right now.
But she also tested out tool calling, you know, those sorts of things.
And there were some surprising findings in this that I'll get into in a moment.
But, you know, it's always wonderful to read what Brigida has been up.
She has a very robust way of analyzing the frontier of agentic coding.
And she really is affirming what I just said about.
Us being in this experimentation phase of local sub-agent delegation.
So before I get into some of the things that stood out, I'm curious what you think about this, Andrew.
Yeah, we love exploring the ThoughtWorks memos here on the show.
We've covered a number of them in the past year with these really great breakthroughs.
I, like you, really love this lexicon that Brigida gives us for understanding the different...
components of what makes a good local coding model and the experience of using it.
And it's a very complex challenge.
Folks often just stop at the model.
What model am I going to use?
But there's a huge amount of decision making that has to go into allowing it to operate efficiently.
And that's actually something we take for granted a lot.
When we use off-the-shelf harnesses like Cloud Code that have so much of this baked in, when you start to roll your own, you have to think about that piping yourself.
And so Brigida does a really great job.
of giving us a roadmap of what are going to be the fastest constraints that you hit.
RAM is absolutely the right thing to call out.
You know, just a moment ago, we talked about GLM 5.2.
One of my biggest barriers in experimenting with it is just in the RAM that I would want available to it, right?
And so you definitely have to think about all of these different constraints when you start to build with these tools.
Yeah, and there was one finding in particular that really stood out to me, and that was around reasoning.
You know, a lot of people, they like to turn on all the capabilities with their models and get them to do everything because they kind of think, oh, that surely must make it smarter and able to make better decisions.
But actually, the reverse may be true in some situations.
So if you have a reasoning model operating in a situation where the decisions aren't as clear as they need to be, it can actually get stuck in logic loops that will consume tokens and degrade the overall performance.
You know, there's a lot of just like nitty gritty details like that, where if you're someone out there who's listening to this and you're like ahead of the curve on experimenting with different models, because maybe your job is to find the best model for your product that you're building or for your internal processes.
There's a lot of really great insights in this article that can help you like understand how you need to approach the challenge.
And there's also like, I think, a very clear warning about this.
And that is that she really struggled to adequately measure and compare the success of most models beyond like basic performance data, you know, things like time to response.
So, you know, I'm going to keep beating this drum for a bit.
Like sub-agent delegation is this next big technical leap that we all need to go through.
And I love this article so much because I think it really gets into the details of why.
Why is it still such a big challenge using local models as sort of the lens for it?
Yeah, the reality is, is exactly that, Ben, that oftentimes it can be so hard to compare or use them in a daily fashion once you do get them set up for the exact reasons that you said.
so used to, like I said a moment ago about using Cloud Code and having these high-capability foundation models and these super souped-up Corsair-style coding harnesses, right?
But when you start rolling your own and bringing your own components to play, simple things like just having too many tools available, having too much thought constraints on the actual model inference can just completely blow out its context window and just leave you spitting when you're trying to use it.
Not to mention...
all of the finickiness of how different models will emit their tool calls and their thinking in the different ways that your harnesses have to handle it.
And I haven't even begun to scratch the surface of prompt caching, token caching, which is really the underlying mechanic that keeps your Anthropic and OpenAI Bill from being...
100x what it is, and you need that too.
And so it only gets more complex.
Be sure to check out Brigida's wall of death that she gets from the LLM at one point.
I cracked up at that because she follows this with a second memo.
And it's at one point, you know, the local model just completely starts filling the screen with the same word over and over again.
And if you used ChatGPT like 2.5, that experience is very understandable and relatable.
Amazing.
Amazing.
All right.
Let's talk about how AI erodes a legacy of reading.
Now, Andrew, I have to admit, I just barely skimmed this article.
So you're going to have to tell me what it's about.
Oh, no.
I only barely skimmed it, too.
What's this saying about us, Ben?
I love that this article.
No, I'm joking.
I did actually read it.
I did actually read it end to end.
Oh, OK, OK, OK.
Well, maybe I'm just joking, too.
But why don't you take the lead?
Yeah.
So this article is about the author.
Arguing that AI-generated content and AI-augmented content has sort of accelerated the death of deep word-for-word reading.
When was the last time you had text put in front of you that you really considered every single word in that text?
But the argument really is not just that there's more text than ever.
We've also had this phenomenon of like an eroded trust in authorship that makes people less willing to invest attention in any given piece because the moment they think that maybe AI generated it, well, they think, well, the author didn't spend that much effort writing this.
So why should I spend my effort reading it?
And I think one of the big takeaways for here, and this extends beyond software engineering, it's really more focused on just all knowledge workers as a whole.
As content volume becomes unmanageable and increases over time, summarization tools feel necessary to stay current and on top of things.
But the author wants to warn us that this creates a feedback loop that further degrades the quality of engagement with ideas.
There's a lot of nostalgia, some contrarian opinions that I liked throughout all of this.
He also acknowledges that skimming is a very rational behavior given the volume that we're all dealing with.
today, especially if you're trying to make like value-based decisions, you know.
But I think it's worth discussing for, you know, for all knowledge workers, but for engineering leaders as well.
You know, teams are already navigating this trade-off with internal docs, proliferating spec-driven development, all these async communications.
It can be healthy to question from time to time whether AI summaries help teams move faster or just quietly degrading like a shared understanding.
So Andrew, what did you pick up from skimming it or reading it end to end?
I don't know.
There are a few key points of this that really resonated with me.
And one of them was the idea that you have to have a summarization system these days to even keep up and to be reading things.
And I couldn't agree with that more.
I unfortunately have created all of these huge nets.
especially in the news world, that catch things and percolate them down.
And I have things that matter to me that look for stuff.
And so this method of...
gathering all of the noise in the world and compacting it and summarizing it down is something that's been really important for me to keep up with.
But then with that comes the temptation to only skim, to only read the digest, to only kind of skim across the surface.
And this is what does cause the collapse of the conversation that this rightly called out.
That, you know, then the folks that are putting out the content aren't getting the engagement or aren't getting the critiques and like the head-to-head conversations and the rebuttals and stuff.
And, you know, maybe this was a trend of older times where people would have their blogs and they'd be writing like reply blogs to each other and arguing about like all sorts of foundational things.
Whereas now we just typically have our own silos where everyone's just throwing things out into the world and you pick out what is interesting to you.
Another part of this that was really fascinating was the idea of author trust and understanding where the content that you're reading even comes from.
And this goes hand in hand with what you were saying about summaries and things like AI-generated notes and stuff.
Are they just piling things on top?
Are they actually helping us understand the...
ownership, the authorship of what we're trying to do here together.
That's a big question, I think, that comes into play with everything we read now.
As somebody who studied Latin and Greek in college, I spent a lot of time reading really old stuff where the authorship and even the accuracy of the letters in front of you are questions and debated across time.
And so you always have to approach what you're reading with this lens of where did it come from?
How much was this translated?
What was...
the legacy of it?
How much of it even survived?
And that, I think, the historicity of understanding where this stuff came from was fascinating.
And we're seeing the same stuff play out now with AI-generated content, I think, especially when you get them feeding into each other and they're making noise and maybe nobody's paying attention.
But I will say, like, one tactic that you can use, you mentioned beginning, like, when's the last time you read something, it really stared at every sentence, is, you know, to slow down.
I think that's the biggest recommendation I can make.
It's okay to not read everything.
If you create these systems that can capture and can digest things that matter to you, then that buys you the privilege to slow down and to read because the things that you do want to go learn and find out can always just go be a hop, skip away.
Yeah.
And I completely understand the author's perspective in this article, but...
I think really what they're describing is an effect that has been at play basically since humanity invented words to begin with.
Originally, only a very small group of people had the ability to read and write, and they were effectively the gatekeepers of all information.
Very few words at that time were created, and each word proportionately had a much bigger impact on people.
And as literacy has become normalized...
More words are created.
And eventually we had the printing press, which just ratcheted up a whole order of magnitude.
And now we have effectively an automated or an autonomous printing press with all of these AI tools.
So again, generating words is easier than ever.
And naturally, word generation has increased yet another order of magnitude.
But then along with this comes like this proliferation of knowledge.
You know, it's one of the big benefits of having language in words.
Back when you only had access to a few books, and we were talking hundreds of years ago, it was really easy to memorize everything that was inside the books that you had access to because you had, again, proportionally more time to dedicate to studying the words in those books.
But as we generate more knowledge, it really is impossible for humans to keep up with all of it.
So naturally, just like AI has to compact its knowledge, we have to compact our memories and our knowledge.
You know, with that said, you know, we shouldn't always operate that way.
Sometimes you have to for velocity or other reasons.
But I do think there is a massive payoff to from time to time just being very intentional and spending that time to go deep on something and build your first brain, so to speak, rather than focusing on recycling knowledge into your second brain, into the AI systems that you have.
And yeah, I was joking.
I did actually read this end to end every word and I slowed down to read it a bit to respect the point of the article.
And yeah, and it's sometimes.
So yeah, sometimes don't outsource all your thought to AI.
I guess that's the point I want to make.
I think it's really critical to keeping a sharp mind.
All right.
I wanted to cover this last article about Facebook because, you know.
I feel like it's been so easy for us to throw shade at meta.
It is from time to time fun to also just look at some of the cool things that have happened there over the years.
And this story comes from an engineer that worked there.
It's titled, I shipped a Facebook feature so fast that Sheryl Sandberg called an emergency meeting to stop me.
And this comes from, again, from a former Facebook engineer where they recounted, it's a wonderfully written article where they recounted shipping a file upload feature.
for Facebook groups over a single weekend.
And this resulted in basically an emergency meeting that involved Mark Zuckerberg, Sheryl Sandberg, and the CTO of the company.
Basically, three very expensive executives all showing up on this engineer's calendar out of the blue.
And the article really is just about how...
Meta has historically had an aura about it of having a really good...
engineering excellence culture, you know, giving a lot of autonomy to their teams and letting them just take big shots at building new capabilities.
And it was really just the, you know, the culture that fed into that.
But yeah, it was a great, great story of how everyone thought it was going to take months.
The engineer produced it in days and suddenly everyone's panicking about how quickly they can produce it.
Again, I don't always want to throw shade at Meta, so it's nice to have an article that kind of harkens back to some of the great engineering culture that it has fostered over the years.
What do you think about it, Andrew?
You know, this kind of story about suddenly on your calendar, a whole bunch of executives dropping a meeting and you're just an engineer somewhere writing your code and shipping features for people.
That's definitely enough to scare the daylights out of you.
And so this idea that the article explores about you know, there's this great deal of ownership at Meta about the features that they did build and what they shipped and how this did lead to so many breakthrough pieces of technology, which, you know, undeniably we can credit Meta and their engineers to bringing into the world.
And so that kind of engineering culture is definitely something people strive for, but there is an element of like a survivorship.
biased to this story that I definitely pick up because I think in many cases, this is actually a reminder that as you do get more abstracted from these in the weeds, technical shipping, delivering, write that 10,000 codes, do it in eight hours kind of deal, you need to one, maintain really deep awareness of what your agents are doing, but then you need to still be able to have the ownership of understanding what they're putting out the door.
Because ultimately, if you have a bunch of agents running wild and writing codes and shipping things and knocking out features like this.
A story like this would play out today, and maybe that feature would have skipped around a security requirement, or it wouldn't have used this very specific kind of library, right?
There's all sorts of nuance that we have to be responsible for as engineers to put into these systems.
And so ultimately, this is a reminder to not short-circuit the systems in place within your engineering or to get code out the door.
I think as an engineer, if you're hitting a constant barrier with your...
agents and trying to get things delivered, then that requires that that then should be something we all bring attention to as a team.
Why is this now an obstacle?
Because there are new bottlenecks places and we're constantly hunting down those bottlenecks now as engineering leaders.
So yeah, well said.
So Andrew, what have your agents been up to this week?
Okay, well, besides the digest and the reading thing and then getting to hang out with Fable again, which was an unexpected surprise, I am now creeping up on the very end of my usage window.
But some amazing things that we managed to get out the door this week, one of them was a web app for my phone.
I can have on the home screen of my phone that actually lets me peer into all of my beads that I use to do with my tracking.
I can also see if any of my sessions are stuck because I've kind of fallen really deep into the loop engineering world.
So I have a bunch of loops that are pushing stuff along all the time.
And I typically just pop in there to see if any of them have gotten stuck.
What about you?
What about your agents?
Yeah, I feel like the mobile development is very quickly just becoming a cultural norm, I think.
I've had a lot of fun.
I read this recent article from Simon Willison about how he just kind of creates random iOS widgets for things now because it's just so easy to write like a Swift app that's native to your Mac.
And I was like, wait, that's genius.
So now I just have like a bunch of Swift UI kit things that just pop out every once in a while.
And then I throw them away.
Well, yeah, I mean, our listeners may know that I was out last week touching grass, which unfortunately grass does not have the latest Fable models installed upon it yet.
You know, so I can confirm that.
But since I've been back, I've I've actually been focusing more on my first brain this week.
So, you know, I've got some big projects that are getting kicked off and it's like I really want to develop the ideas.
Very like getting really robust before I go kick off a whole bunch of agents to spin off a whole bunch of work from it.
Yeah, it's, you know, I am kind of taking the article we covered to heart a little bit this week and being a little slower, being intentional and building that first brain so that my second brain can operate a little better.
All right.
Well, that's it for this week's episode.
If you enjoyed it, remember that everything we discuss comes back to one major challenge.
And that is that engineering teams everywhere are wrestling with AI right now.
Wrestling, I tell you.
It's writing code faster than ever.
And your SDLC probably struggling to keep up because I know ours often is.
Linear B is the engineering productivity platform that shows you exactly where AI speeds up delivery and where it stalls.
And we automate the bottlenecks that your team can ship faster with total confidence.
See how Linear B can help your engineering organization by checking out LinearB.io.
Thank you for sticking all the way to the end of this show.
If you're still listening.
engage with us somewhere, you know, give us a thumbs up, give us a like, leave a comment wherever you're watching this, or just reach out to us on social media.
We always love to interact with the community.
And of course that all helps us grow the show.
So thanks for listening and we'll see you next week.
See you next time.