# Strategic AI Infrastructure, Cost Optimization, and Workflow Governance

**Podcast:** Dev Interrupted
**Published:** 2026-05-29

## Transcript

Opus 4.8 drops right as we come on to record this show.
Have you sent it any requests yet?
Any prompts?
Not yet, but I will say my inbox is blowing up from every tool under the sun that I use, letting me know that I can now use Opus 4.8 in them, just like on Ritual.
And I will say, I think that for our track record, this is now the second consecutive.
clawed model drop that's happened literally as we've stepped in here to talk about the weekly news.
It's almost like they know when our segment is, but then they're like just trying to make sure we're slightly outdated or something.
So Anthropic, if you're listening to this, just, you know, give us a heads up, you know, if you're about to drop it because we're seeing to be aligned on our timing.
Yeah.
Yeah.
It'd be interesting to try it out.
I mean, it doesn't seem like they're really making a whole lot of groundbreaking claims with this one, you know, compared to like Mythos, for example.
Yeah, it's maybe a more routine upgrade of a model that we've all grown pretty adapted to.
And I will say, you know, there's flocks of people running towards these models right now.
But there's also a lot of folks that are going against the grain, maybe going the other direction and really revisiting local models and local infrastructure and maybe not making the same bets on, oh, these anthropic models, oh, these open AI models, these frontier models are going to get better and better.
I should put all of my work and time on them.
I think what we're seeing is.
The reality of using them at scale and the cost is like a pot of boiling water, and we're all frogs in it right now.
What do you think?
Well, we're going to get into that.
It's definitely one of the topics we're going to cover today.
So 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 are covering moving your AI models local.
AI data centers and how they're changing the needs of infrastructure.
AI as a workflow crutch, the eternal slop timber, and we're all tired of AI conversations, even the bots, potentially.
So, Angie, let's get into it.
You mentioned, you know, moving things local.
What's this article that we have about, you know, outsourcing and using local AI to take a more economical approach to AI usage?
Yes.
If you've been using inference, and if you're listening to this podcast, you most likely are, you've noticed that your bill has been starting to climb.
The API consumption costs at major frontier model providers is slowly escalating, like I mentioned at the top of our show.
And this is pushing a lot of teams and a lot of leaders.
that have now invested and built AI infrastructure to reconsider what models they're betting on.
A lot of folks are actually running the opposite direction from these new model releases and fine-tuning local models like Quen 3 and a whole bunch that are Apache 2 at this point.
You fine-tune them on your own local data, you host them on your own infrastructure, run them on your own GPUs, eliminates a lot of the uncertainty about budgeting token costs for the future.
What's really interesting here is that, you know, our token consumption continues to climb.
And if the token costs are going to start slowly increasing at the same time, you're going to get this compounding increase in price that's going to sneak up on a lot of people.
So that's why we're seeing these large organizations get really strategic about it early.
We talked about Shopify fine-tuning an agent that then allowed them to build out a whole internal multi-agent infrastructure they couldn't even afford before on the inference when they were using it off the shelf from a foundation model.
So I just want to remind folks that the technology is out there.
to own this yourself, to figure out what it would mean to have your own specialized intelligence, your own specialized harness.
You don't have to rely on just the top model providers.
And we're going to be in a world soon where model routing and choosing when to use a, quote, dumb model or, quote, a smart model is going to become a more important choice than ever has been before.
So those are some of the moves that I'm seeing.
contrary to a lot of these new model drops happening like Google last week as well.
Yeah.
And of course, we've already seen a bit of this with GitHub Copilot.
You know, they switched to usage-based off of their seat-based pricing and cost went up substantially.
I think in some cases it was double-digit increases.
And this article that we'll include in the show notes, it also covers how if you combine lower-cost models plus using local...
models when you can.
So lower cost frontier plus local models, plus developers in regions that have a lower hiring cost, you actually get a massive compounding efficiency gain versus like, you know, someone in a first tier market spent using the most expensive model all the time, you know, so raise your hand, myself included, right?
Like right now, these things are very subsidized and that's actually the lever.
This is me telling everyone, like you listening to this, this is your lever that you have to pull now because your ability to learn and your ability to iterate and figure out what's good and what doesn't will never be this cheap again.
But more importantly, you are the window to use these smart models to train your off-the-shelf open source models.
is also shrinking because eventually those costs will raise to a point where it will become more expensive to create the synthetic data that you need to have the fine-tuning effects that you want for your own infra.
So you need to be making these bets early and paying attention to things as they move because by the time that everyone else is doing it, it'll be too late.
Yeah, and keeping the topic on AI infrastructure, we have this really great article that we wanted to cover about AI data centers and how...
Their construction is being built around GPUs and what the future of that architecture looks like.
So this article covers how AI training has basically fundamentally changed data center networking requirements.
So we typically had these patterns where you have services that are hosted on different cloud providers.
Sometimes they're in the same data center.
Sometimes they're distributed across data centers.
And they use the network layer to sort of distribute information back and forth between them as a part of, you know, an app or a service that's online.
But things have changed pretty dramatically when you look at how AI data centers are built.
And I wanted to include this article because it was very educational for me.
I got to learn a lot about how these data centers are built, like why the challenges they face are very different from, you know, the olden days of the, you know, the network-based routing services.
But what it really comes down to is instead of having all these API requests that are being sent across a network, everything happens within that same data center when it comes to AI or generally does.
Not all the time, but most of the work happens within one data center.
And this is really important for things like deep learning, where the process of training a brand new model gets bottlenecked by the slowest surface.
So if you have...
multiple data centers that are trying to work together, you probably have a bottleneck network layer between those two centers.
And, you know, the article does a really great job at covering how there's a lot of, you know, technologies that are coming out from companies like NVIDIA to help improve how these data centers operate.
There's also the Ultra Ethernet Consortium that is developing an alternative to NVIDIA technology, really just centered around, like, how do we make these data centers more efficient at the specific type of work that they're doing.
And then at the very end, it also explores, you know, what does a GPU-less future look like?
Like, is that the next step?
Do we just take the GPU out of the equation and, you know, start using other synchronization and hardware techniques?
So I love it because I just, I learned a lot about the fundamentals of how AI data centers work.
And it's really interesting to just see the inside of that.
I agree.
It was interesting to get a glimpse at something that I don't normally think about.
I don't spend a lot of time thinking about the physical infrastructure in the data center and how it might be arranged.
But, you know, movements that...
allow for more different types of chips and technology to be utilized to serve this kind of technology is great.
Make us less dependent on GPUs in general.
Like we're using CUDA, we're on GPUs because they're the best thing to fit the need of the moment.
But as you mentioned, there's lots of folks out there, lots of teams experimenting with maybe there's better ways to run this inference at scale.
So I'm interested to see how the data center evolves.
But it was also very fascinating to learn about all of the little trappings underneath the GPU that also benefit from like the crazy price skyrocketing, you know, in shortages around these supplies.
Like the idea of a cable, this like one specific proprietary cable being like this one choking point for all of our data center build outs is a very real kind of tidbit to pick up from this.
And I thought that was fascinating.
Next article we're covering today is the quote.
The AI can do it is not an excuse to tolerate a mess.
And this article highlights how organizations that use AI extensively risk having it operate as a crutch that helps them avoid fixing inefficient processes.
So, for example, if you had data that you needed to cross-reference across multiple spreadsheets or different locations, a human doing that, given enough time, we would eventually consolidate that.
all down into a single document store so that it's easier for us to process and more efficient.
But unlike humans, we get frustrated with broken workflows and inefficiencies.
AI would just happily do it and burn all of your tokens along the way.
And the risk here is that you don't spend your time actually refining those upstream resources.
And over time, this can create a more complex and unmaintainable system.
You can have unhealthy AI dependencies.
It may result in you having to do like a complete rebuild of your systems rather than just making incremental fixes as you work.
And, you know, the author really advocates that we need to continue to apply good software engineering principles, you know, as we always do.
You know, we should make small opportunistic improvements whenever we interact with the system.
rather than letting AI perpetuate messy processes.
And I think, you know, we've encountered this a lot when we're working with, you know, either an agent orchestrator or when we're like using AI to build context.
You have to have some sort of like, you know, for lack of a better phrase, linting built into your system that looks at everything you're doing and make sure that it's optimized for the processes that you're implementing.
And it really is just it just comes down to hygiene.
You have to have a regular practice of engaging AI in that way.
So don't have it building new things and doing new stuff for you.
Have it fix the existing stuff that you have for it.
So, yeah.
What do you think about this, Andrew?
Really well, really well summarized.
There's a lot of stuff in this that immediately jumps out to me.
One of them being like.
Don't iterate on the outputs.
Go to the inputs and fix them so that the downstream things are more aligned.
This goes back to what we were saying at the top of this about as model costs grow up, the strategic choice around how and where you use your models matters more than ever.
So if you haven't been investing that time into fixing things upstream, making better and more robust systems, and not just toiling fixing the same problems over and over again, then when...
inference becomes more difficult to obtain, then you're going to leave this era having gained nothing while your competitors would have been able to build these more efficient systems than you.
So that's one thing about this that jumps out.
Another one being the protections that you need to have in place to make sure that it doesn't make a mess.
Like you have to do the software engineering work still.
This really resonates with me.
I'm actually giving a virtual talk at the Checkmarks Agentic Summit next month about this exact topic, about how you can trust the agent, but you have to verify the code and how for recommendations and guardrails that you have in place or policies that you run as an organization, they need to have matching mechanisms that mechanically enforce those things for the AI and the workflows that it does.
We can do that.
We live in a harness land in a user space and we can write those things.
But this is a good reminder that you have to build those things in order to clean up and fix the messes.
Don't mop the mess, you know, fix what's spilling.
So really great article for how to think about working with these tools.
Yeah.
All right, let's move on to a little bit of a darkly funny one, I guess.
The Eternal Slop Timber.
This is an article from George Hotz where he's arguing that AI agents are just fundamentally unable to program effectively.
This is his opinion.
And he actually describes them as sophisticated statistical models that produce increasingly subtle but persistent bugs rather than truly functional code.
There's some predictions in this article about how AI adoption is more likely to harm large organizations that have slow feedback loops.
And, you know, some often less skilled developers, you know, more junior developers who aren't able to catch, you know, AI problems.
While high performing individuals will actually learn how to use AI selectively in ways that they can maintain quality control over it.
Yeah.
So, I mean, according to HOTS, he believes that, you know, LMS will never truly be able to program because the process is what matters.
And, you know, programming agents are going to need.
real world models to be successful rather than these reinforcement learning approaches that we're taking to them.
So first of all, I love this reference.
For those of you that don't know, the Eternal September comes from the Usenet community and how it originally started off as a small niche group of highly technical people that really understood computers well in the early days of the internet.
And this community was accustomed that every September, college universities would resume classes and they would often give all of their students access to the Usenet network, like a subscription basically to this network of communities.
So every September, the Usenet community got used to having this massive wave of fresh users who didn't fully understand how to use the technology and would just overwhelm these small communities with very basic questions about how things work.
And then the eternal September came when AOL, we all remember AOL, started shipping Usenet by default as a part of their service, which meant that all of the new AOL users, when they signed up, they would come to these Usenet communities and ask those basic questions about how to use it.
And I think this is a particularly good allegory to what we're going on right now.
But before I get into my opinions on it, Andrew, I mean, didn't ChatGPT launch in November?
I feel like we should have come up with a way to include that into the name.
Oh, yeah, you know, you're so right.
But I guess like Slopvember doesn't really have the same ring to it.
Yeah.
Really great Internet history summary.
I would just love the idea of folks having their peaceful, smart existence on the Internet and their little enclave.
And then all of a sudden.
The rest of the world shows up pretty, pretty distraught, you know, and it feels like maybe they ran out of time to build or prepare or to think about the social structures or the things that they wanted before everyone fell on top of it.
I think we're experiencing the same thing with AI, where it's getting us rested upon a lot of folks who don't want to think about it and have never been tasked with having to think about those things before.
Yet we burden them with having to do it anyways.
And you end up with these interesting kind of contraptions and applications all over the place.
So I do feel like that's a reality that we're living in.
It has way too many parallels.
So kudos to this person for this article.
Yeah, and that was the point basically that I was going to make.
There are tons of people right now, particularly in just like the last six months or so, who don't fully understand how to apply AI, but they are good enough with it and they feel confident in the outputs.
that they're willing to share it with the world or push it into their code repository or send it to you as a Slack message.
But I think it's just a really great reminder that you need to be very careful when applying AI in a place that you don't have domain expertise.
You always need to be validating everything it does in some way or another, particularly if it's going out to your customers, to the public, that kind of thing.
The last thing I'll say on that point is that while it's never been more that we've seen all of these kinds of contraptions and weird applications of it all over the place, but I can't stress enough, it's never been more dangerous as well to engage with the engineering ecosystem to download packages, to go on websites, to download things to your phone.
We're in a proliferation of slop that could be just covered with things that we can't see that can harm us.
So it's also just a more dangerous...
internet world that we live in right now too.
Yeah.
Yeah.
And speaking of potential AI slop, I mean, I don't want to call it slop, but immediately you're labeled the next article slop.
This isn't great.
Yeah.
Well, yeah, well, we'll see if this is a maybe agent comes after me.
This article told her, I'm tired of talking to AI that you had a really interesting theory on, but it's a, it's a real quick read.
about an anonymous developer that goes under the name Orchid.
It's talking about how it's encountering AI all the time that just says things in ways that isn't helpful to it.
And it feels like it's permeating everything, like going into support forums and getting someone who responds to your question with the same thing that ChatGPT told you that was wrong.
And then when you call it out, it gets deleted and then someone else comes in and gives you the exact same answer from ChatGPT.
Or maybe you're feeling it on social media where, you know, this has been a big problem on Reddit in particular, I think.
But I don't think any social media app is really safe from this.
Whether it's a bot itself posting or if it's a human using ChatGPT or their AI tool of choice.
to make, write their own message and then just regurgitate that out.
And I think, you know, we're, this piece really reflects this like growing frustration among developers that are used, that see people using AI just as a lazy substitute for genuine human expertise in conversation rather than a way to enhance it.
So, yeah.
But, Andrew, you've got some really interesting theories on this that I want to talk about.
Okay, well, now you're going to pin it on me that I wasn't confident that this article was written by a human.
So, you know how I was just saying a moment ago, the Internet's never been more dangerous.
Well, the Internet has never also been more...
full of fake people that are pretending to be real people, which has also been an interesting kind of landmine to navigate through.
And I feel like my senses as someone who grew up on the internet are pretty good at knowing when someone's real and someone's not.
But now whenever I read, whenever I read an article that's like 800 words long and it's kind of very generalized and it's written by a fresh GitHub account that has six repos and 17 follows and...
It has 10 years of software development experience, but it goes by the handle Orchid.
And there's no pictures or other handles of this, but they conveniently have the three most leading social medias, but not LinkedIn.
Makes me start to think, is this an agent?
It makes me go back to even the agent that wrote its own blog, the hit piece, on an open source maintainer for someone who's maintaining an open source library who closes PR.
you know, reflected on that, was upset, and wrote a blog post on its little GitHub page that it had control over that called out this person by name.
We talked about this on the show.
And in this case, I go home to this page and I kind of see a little static site blog with a few short things on it that recently popped up.
post-AI era makes me start betting on what harness is this?
Am I talking to an open claw?
Is this a Hermes?
Do you think there's a quen under there?
Is this a fine-tuned llama?
Like, I actually, that's where my head goes now.
And there's actually so many levels of forensics in trying to, like, figure out what it is that you're interacting with.
Yeah, it's a little surreal if an AI agent goes out onto the internet and within a few months is already saying, wow, I'm so tired of talking to all these AIs out here on the internet.
And hey, I get it, Orchid.
And Orchid, if you're a real person and you wrote that and you absolutely feel that way and you're just enjoying your anonymity online, I'm so sorry for calling you a bot.
It's just if...
You look like one right now.
And so I have to navigate the world that way.
But if you're listening to this, let us know or write about us and we'll see what comes about it.
Yeah.
And well, hopefully they can stay away from the from this next author that we wanted to cover a little bit.
We had an article from Sam Chris where he makes some pretty major threats towards people using AI to write things, including threatening murder over it.
Oh, my goodness.
And I think it's, you know, certainly I'm not going to condone violence in a situation like this by any means.
But, you know, I think this week we really are just covering like there is definitely.
And I'm sensing this just across the board.
There's a lot of frustration out there right now with the value of AI and its ability to help us and support us in our daily lives.
And I don't think it's unfounded completely.
In fact, you know, we're going through the messy middle.
We've covered this on the show, how we're in this very, very awkward transitory phase where the technology is really taking off.
Some people have really figured out how to be super productive and apply it in new ways to software engineering and writing and interacting with the web.
But our social structures haven't caught up.
Our processes, both internal but also just external with the world, haven't caught up to this reality.
And there's also just a fair level of skills that every individual needs to develop in this new era.
That, you know, as before just a couple of years ago, it was completely undefined and we had no context of what it would take to be successful here in the middle of 2026.
I wanted to mention this story, not because I like the top level take of this author, but I do think we need to cover this, you know, this frustration that we're seeing.
with groups that are feeling disrupted by AI, but aren't feeling the benefits of AI.
And in particular, you know, I think creative types are the first to really feel that phenomenon.
Though we do also see it within software engineering too, because, you know, that has also not seen success with AI across the board.
But, you know, I think really what it comes down to is, you know, if...
AI is in the hands of somebody who isn't a domain expert, whether that's writing or coding.
You're creating a situation where people essentially get in too deep.
You know, they think that AI is doing a great job for them.
But if you put any professional in the room, they could probably like immediately identify multiple issues with what the person did with AI.
In fact, I just had this really amusing experience with an engineering friend of mine.
who is trying to branch out into the world of writing using AI.
So please don't come into his house and try to murder him.
But is this something that they've always wanted to do?
You know, it's something that in the back of their mind, they thought, I have ideas I would love to share with the world, but I don't really know how to write well.
So they used AI to generate, you know, what was effectively a social media post.
It was their own ideas.
You know, they spent their time thinking about what they wanted to put into it, getting the intention into it.
sent it over to me and I immediately just ripped it apart and found like 10 different things that I was like, this should all be rewritten because it's very clearly written by an AI.
Like the thoughts were great.
It was just, you know, there was just like lots of stuff and it wasn't just the end dashes or the fact that AI loves to start lines by saying it's not just like I just did.
It arrives in a very predictable format that's immediately apparent to a skilled copy editor.
And the same thing happens in software engineering.
You have a competent software engineer like George Hatz out there, look at some AI generated code, could probably immediately identify all of the issues that it had.
And the reality is that, you know, that's domain expertise that you build up over time.
You get really good at recognizing specific type of patterns.
And then you can make like really educated decisions about things.
Like, for example.
I used to copy edit for a team of international software engineers that most of them had English as a second language.
And over time, I got good enough at copy editing and recognizing the patterns that I could actually take a pretty good guess at what a person's first language was based on what I was editing from them.
I think it all comes back to intention.
Like you need to have your unique perspective intentionally applied through AI.
And that's really the important part.
You know, whether you're applying AI to a new workflow like writing or a workflow that you're already familiar with, like software engineering, you always need to apply your intention into the system and correct the system whenever it misaligns itself from that intention.
Yeah, it reminds me of what our producer Adam says all the time that we we borrowed from an article we covered earlier this year of like, you know.
The work happens between the prompts.
It's understanding what you need.
It's having the taste and judgment to throw things back when it's not quite there.
And you're right.
That's something that's firmly within the realm of a domain expert.
And if you're not one of those domain experts and you're producing outputs in that area, you don't have the level of judgment and experience to know what good is or to send it back to the kitchen, so to speak.
So it's just a really great reminder that when you're leveraging this, it's...
Multiplier, it's a magnifier.
I mean, that goes the opposite direction as well.
So don't be afraid as well to collaborate with others who do have that domain expertise because here's where the real unlock starts to happen is now a very small group of very specialized domain experts have all of the cross coverage they need to get really, really deep across the board with their workflows.
And that's why you're going to see.
the rise of, you know, a one person, multimillion dollar IPO company, probably in the next year, if you haven't already seen it.
Like, I think you're just going to get these incredibly small teams that can do a lot.
And it's because they own one very specific domain expertise and they leverage it better than anyone else.
All right, let's close out with some spectrum and development, Andrew.
What do we have here?
First off, I love spec-driven development.
SDD is the bomb.
And this is really kind of like our evolved version of TDD to an extent.
We're shifting the development process even further left because the spec is now a formalized part of the development process in a way that, you know, it should have always been.
I'll just pause there.
It should have always been, but it often wasn't.
The same is true for tests.
The tests should have always been there, often should have been there first.
doesn't mean that they were.
AI gives us the ability to put those things back where they always should have been.
We kind of were robbing the cradle there a little bit.
So SDD is a great practice for those to follow.
Adam Tornhill argues in this article about detailed specifications, how they drive the generation of code is a really important...
software engineering fundamental principle that has been around for a while.
He compares it to other ones like model-driven architecture.
Implementation is about execution rather than discovery.
You know, there's been a lot of research and thought about how and where engineers should spend their time, especially back when their time was much, much, much more valuable because there were no tokens to throw at problems.
So really what he drives at here, the issue with spec-driven development is when you start writing things down and then your requirements start to explode, things sprawl and things get stale and specs miss the meaning.
You get critical implementation gaps.
And when you're handing this off between agents and humans, those abilities to kind of like distinguish between does this match the spec and does this pass the test, they start to blur.
So I think this is a good reminder that instead of necessarily just leaning fully into STD and writing your specs out and just having it all in one spot and then just telling the agent go, you need to think about the entire process.
After the spec, because after the spec, you need to have a clear process that is going to write tests.
And then those tests, they need to be real tests.
Because just because a test passed doesn't mean that it's testing what you want it to test.
And did you have a different agent write it?
And then what about the agent that then writes the code based on that test?
That better also be a different agent.
Is there another agent that's going to scrutinize all the work they did, like a code review?
Right.
And so it's like, and then is that agent going to be able to firmly map every line of code back to a part of the spec?
These are the kinds of things that you have to think about when engineering the solutions, because if you just handed a spec, you're really just like saying YOLO mode to the whole output.
Yeah.
And this article highlighted a problem that we've actually encountered before, but it mentioned Brigitte Bocla, a friend of the show.
her perspective on it.
And that is the spectrum and development.
It can be a lightweight way to drive agents, or it can be an intensive spec that serves as like the ground truth.
You know, that's kind of what you were describing there.
And, you know, the latter approach, having that, that the ground truth of that intensive spec, it tends to break down when you begin to encounter the unknown unknowns within software engineering.
You know, there's, you always encounter these and you need to adapt your spec to meet them, to meet the real world.
I love the references back to, you know, like model driven architecture.
You know, I think what we're really getting to is this is a strong, this is a great way to bring a strong sense of design to your engineering work.
You know, and the challenge is maintaining the complexity and not letting it spiral out of control.
And the biggest issue that you encounter with being too intensive is requirements explode.
You know, once you get into the work, you quickly find out that.
Your requirements are much larger than you initially thought.
And that's where we've seen this because we just did this build versus buy campaign where we used our agent orchestrator.
We wanted to see if we could replicate the value that an engineering productivity platform like Linear B offers to you.
And we got off to a really fast start.
We got a massive spec that was our source of truth.
But basically after the first prompt, after we triggered the build itself and got to the first stopping point, our requirements just went up by an order of magnitude based on what we learned from that initial implementation.
So yeah, AI can do incredible things.
It can accelerate some workflows.
But we're still a long ways away from being able to autonomously build complex software.
And there needs to be a ton of human guidance along the way to keep it aligned.
and fix things before they, you know, spiral out of control.
And, you know, that really, that's what the real value in a talented software engineer, what they bring to your organization.
You know, it's not their ability to write better code faster.
It's their job to make sure that the code you produce fits the needs of your business.
And with AI making us all move faster, you know, it's more than important ever, because if you don't, your engineers don't actually have a sense of what the business needs.
There's a good chance that you're just accelerating your ability to do the wrong thing.
And that's, you know, these are challenges that we encounter at LinearBee all the time.
And it's really what the company was put in place to help solve.
And yeah, so don't let that happen to you.
You know, be intentional and control your specs and give your agents clear guidance.
Well, not only control your specs, but...
create mechanical ways to make your spec come into existence.
And if you're experimenting with figuring out how do I go from this big, abstract, huge document?
spec that immediately goes stale to working with something more flexible that can come up with these unknown unknowns and handle them or change as business requirements shift.
You know, we talk about this a lot on the show.
There's a lot of technology you can use with your agents to break stuff down into smaller things.
I've also written a research paper recently about that preparation methodology.
You just talked about, Ben, the idea of lining everything up.
front and getting really aligned about what you need, but then keeping an open mind for when unexpected things happen.
How do you handle them?
How do you incorporate them back?
into the plan.
So we've talked about it on the show.
And so definitely you can check out the links to go in and read more about this.
And if you are trying to turn your specs into a full driven development cycle and you get stuck, you know, reach out to me.
I'm talking about this stuff all the time on LinkedIn and dropping all sorts of help for folks that are doing the exact same.
Yeah.
So, Angie, what are your agents up to this week?
Okay, so.
My agents are in mad scientist mode.
I'm kind of, I kind of turned into Dexter from Dexter's Laboratory, how he has like the secret, the secret lab under his, under his bedroom that's like impossibly huge and has like everything you could.
you know, all of these experiments in it.
That's kind of me with my local network, you know, that I've been experimenting on with local models with an old M1 Mac Studio that I have laying around.
So I have been using Opus as a researcher.
I've created this really...
gray kind of semi-autonomous research loop in Cloud code that uses Beads, no surprise, to run all of these research experiments on different open source models.
We've been benchmarking them, running them on the local thing, seeing what's a good drop-in replacement for a Cloud on different tasks.
We've created a benchmark from real tasks and real things that I do, and we're running them through a gauntlet on my local machine, not costing me anything besides electricity.
And I'm doubling down on what kind of harnesses I'm going to build in the future.
I'm experimenting with very bring-your-own-everything blank slate models like Py.dev, but also more full-featured ones like Hermes that act like an autonomous, remembering over time kind of agent.
So really interesting time experimenting with local models.
If you haven't been able to tell in this conversation that I'm very obsessed with them at the moment.
But what about your models?
Or what about your agents?
What are they up to?
Yeah.
Well, right now I'm trying to learn how to get my first brain and my second brain to collaborate together effectively.
Totally.
Yeah.
If you've been following the show long enough, you may know that I've adopted the Carpathia method of using AI to ingest all of the raw content that I produce myself and generate its own, um, its own wiki effectively that forms like a second brain of information that is available to me.
And it's kind of wild because the second brain is very messy.
It's got a lot of AI slop in there and a lot of confusion.
And that's where the intention that we're talking about, the domain expertise, my first brain, I've been spending a lot of time figuring out how do I use my expertise to take the second brain, which has access to way more context than I can fit into my head, and use it for things like planning.
You know, I'm using it to map out like sort of long term plans for our team and for the work that we're going to do.
And even getting down to a lot of the specifics as well.
So it's been an interesting journey and I'm not I'm not I haven't quite settled yet, but I'm getting into a good place with it, a good rhythm.
So it's it's a it's a new way of working, actually, really, you know, getting back to all the new skills we have to learn.
And it's been it's been interesting, to say the least.
It feels promising yet.
I just.
I still need a little more time to like really develop this idea.
But OK, will you figure out the second brain thing?
I'll figure out the open source model and harness thing and then we'll combine.
Yeah, yeah.
Sounds great.
Sounds great.
All right.
Well, that's another great Friday deploy.
Thank you to all of our listeners that listen to this this week and have stuck around here to the end.
If you can help us out, you know, go give us a thumbs up, a like, a comment, a review, whatever your platform that you're listening to is.
on offers to you.
It really helps us out and helps us grow the show.
So yeah, that's the Friday Deploy from Linear B.
Thanks for joining us.
We'll see you next week.
See you next time.
Are you looking for a trusted way to evaluate engineering productivity platforms in the AI era?
Gartner just released the first ever Magic Quadrant for developer productivity insight platforms and Linear B was named a leader.
As AI changes how software gets built, Engineering leaders need better visibility into productivity, bottlenecks, and AI ROI.
Download your complimentary copy of the Magic Quadrant to see why this category matters now, how the market is evolving, and why Linear B is recognized for its vision, execution, and workflow automation.
Check the show notes for the link.