# Uber's Rearward Engineers and AI Safety Shifts

**Podcast:** Dev Interrupted
**Published:** 2026-08-14

## Transcript

So Andrew, we've got a new life beyond token maxing story yet again for this week.
I think that's two weeks in a row now.
But it's a different kind of life beyond token maxing story than what we're typically used to.
We're used to people revolting against token maxing and then putting all these restrictions on it.
But here we have Uber, who's back in the news, who's known as one of the organizations that token maxed earlier this year.
There are CTOs out there sharing some new ideas on how they're deploying their agents, their engineers tokens now.
And it's actually a really interesting idea.
They're now sending their engineers out into other teams within the company, within Uber, out to legal, into marketing, into sales.
And they're calling them rearward or rear deployed engineers rather than like a forward deployed engineer, which is kind of interesting.
We used to call it just like inner source.
But yeah, it's a pretty interesting idea of like using your engineers to, you know, you got all these productivity gains coming into your engineering organization.
Why not have them to just help people on other sides of the company capture those gains?
I don't know.
What do you think when you read this story, Andrew?
Well, I just thought that we really needed to workshop rearward deployed engineer maybe before going forward with that one or going backwards with that one in this case.
So this was an interesting turn of events.
You're right that, you know, we've had been a little bit of a.
a streak lately with week after week.
There's been some major company we've talked about or covered here indulging in the token maxing phenomenon and then dramatically shifting course, either reversing it and going for like a very minimizing or cost restrictive approach, or in this case, realizing the more substantial opportunity.
And that is that if you have engineers that are able to access and work with that amount of tokens and deliver that much amount of value, maybe you're still figuring out what that value is.
But if it's clearly there in some form, let's distribute it.
Let's figure out how to bring these gains into other departments that aren't as enabled, that don't have these like technical thinkers.
And frankly, this is the same idea of like hiring an agency to come in and do like your AI transformation, except in this case, you're enlisting your smartest and most like natively.
familiar folks for your ecosystem.
So it's a really smart play.
I think this is how you actually kind of get the organizational gains.
And that's going to be a theme, I think, actually across all the stuff we talk about in today's episode is how do you distribute the gains to work on an organizational level?
And what does that mean?
I think that's the big challenge.
So it's exciting to see a leader like Uber really take to the charge on it.
Yeah.
And speaking of this, I mean, you know, we've heard similar stories from LinearBee customers where they You know, they've been this agentic leader within their organization.
They've enabled the entire engineering organization to leverage agents who move faster than ever before.
And then the first question they get is like, hey, can you go help other teams learn how to do that too outside of engineering?
So, you know, I kind of think that this probably won't be common practice for too long.
I think it's mostly going to be like larger enterprises where you see this sort of behavior pop up or companies that are just really, really far ahead on the agentic curve.
You know, because at the end of the day, eventually people are going to build tools for those other teams to solve their work agentically.
But, you know, like I said, this is a different kind of life after token maxing that I'm totally here for.
And just shameless plug, if you haven't listened to it yet, you know, we had Andrew and I hosted a workshop with Linear B a couple months back where we talked about this concept of token maxing and what it means to get past that and what life looks like once you've.
sort of move beyond just looking at raw adoption and AI usage and start to think about where's that impact actually hitting your organization.
So yeah, cool little story.
But anyways, welcome to the Friday Deploy brought to you by The Near B.
I'm your host, Ben Lloyd Pearson.
And I'm your host, Andrew Ziegler.
And this week, in addition to token maxing, we are covering model updates from Claude and Meta, why open source still matters.
context engineering in your SDLC and some research that answers the question, do personalized skills help coding agents?
So let's just start right at the top with this news from Anthropic.
What's all this about Claude code now being defaulted to auto mode?
All right, so Cloud Code, they're talking about auto mode here.
Auto mode is something that Anthropic has very famously been tinkering with since really Cloud Code hit the scene.
The idea that the model could check its own permissions on commands that it runs on your own machine is a really important guardrail and restriction for working with the tool.
And there's been all different layers in this discussion about where should that guardrail live, who should be in charge of it.
But Anthropic has really taken the mantle here in making these very safe evaluations a premier.
front part experience of using Cloud Code.
So auto mode has been upgraded to being a default permission setting.
Up until now, it was an experimental setting that you had to turn on.
And the idea is that it catches pretty much any kind of red flag command that would typically, you know, be a potentially destructive or harmful one.
I think these are kinds of rewards they've earned out of all of the work they've had to do.
controlling and maintaining like the mythos and fable rollouts around their extreme cyber security abilities they just now have so much intelligence around how to construct and create these boundaries that it makes sense they're going to make this a default.
I mean, folks, like anybody who's already approving their prompts manually in Cloud Code, they approve 97% of them just automatically anyways.
This is actually a better guardrail in many of those cases because it's paying a little bit of a closer attention.
They also worked with some third-party red teams to try and do prompt injection on it, did a whole bunch of testing, and was able to stamp out harmful commands that had popped up in previous...
generations.
So really promising frontier research coming from Anthropic about how to protect a model from harming your system.
Definitely a really critical part of the model hosting infrastructure, especially as you move that stuff onto your own systems.
Yeah, you know, I think overall, this change is probably a net benefit.
Like, you know, I expect there's probably a lot of like pessimists out there that might be looking at the potential downsides to this where.
You know, Anthropic could use this as a way to just route all of your prompts to cheaper models to save them on costs, which is probably true.
That's probably going to happen to some degree.
But I think there's a real upside here, too.
And, you know, Anthropic can also choose when to do things like implement longer thinking horizons or to use reasoning or to maybe use a better model instead of a cheaper model.
You know, and when I'm using Claude, you know, I don't always want to have to be forced to think about whether or not.
I need all of these different capabilities.
And when it actually executes those capabilities, what is it going to be doing it securely?
So, yeah, there's a couple of quotes that I wanted to call out specifically from this article.
The first is about how this tool or this ability routes each tool call through a classifier that targets blocking actions that are irreversible, destructive or aimed outside your environment.
So they have these new safeguards in place that, you know, one of the biggest things that I'm always paranoid about when I'm.
when I try to start giving Claude a little more freedom to take action on my tools is, am I comfortable with the permissions and the changes that it's making to the things that I'm connecting to it?
And as you mentioned, the other thing that stood out, you know, they have data that suggests that manual reviews are just habitual for most users.
You mentioned the number 97%.
So that means 97% of these tool call permissions that Claude Code asks for just get approved, which seems to indicate that, you know, people are just clicking through reflexively rather than reviewing every command.
And I try to be conscious about what permissions I'm giving it.
But, you know, I'm not going to lie.
There are times where I see it saying it's going to make an API request and I only skim what it's doing and don't actually like really investigate and look closely at what it's doing.
But, you know, I've been preaching on this show for a while now that, you know, these foundational AI.
tools need better protections and safeguards like this that help protect us from our AI going rogue.
So I think it's really great to see that, you know, Anthropic is continuing to think about this challenge and is building tooling.
You know, I will say probably my biggest concern and where, you know, I do align a little bit with some of the pessimists out there is that we really do need the ability to turn things like this off when we need to and be able to manually configure as much as possible.
You know, and I keep thinking about this.
Hugging Face open AI hack that just happened.
And it really kind of is the perfect example of how AI safeguards can actually backfire on you.
In this example, Hugging Face was unable to use some of the Mythos class models for responding to the security breach in real time because those models couldn't determine if the people trying to protect themselves were being malicious or not.
Like it actually looked like they could be potential bad actors themselves.
So it would refuse to do things for them.
And, you know, and then the team had to switch to other models that just don't have those safeguards so that they could respond to this security incident.
But yeah, there's a lot of benefits that Anthropic is claiming here.
You know, it supposedly reduces the risk of prompt injection, harmful actions.
So, yeah, I think this is just sort of like the next step in what is likely to be a constant iteration of better safeguards around AI.
Yeah.
All right, let's talk about the latest news from Meta.
This is a pretty cool announcement, I feel like.
Muse Glimmer is an open agentic model that runs on your devices.
What is this, Andrew?
Yeah, this is, like you described, it's a long-running agent coming from the Meta Labs.
So this is an open-source, open-weight model.
If you're familiar with the models that they release, they do so fully open-source because they want a fully collaborative ecosystem.
And this latest one is a 30 billion parameter open-weight model.
under an Apache 2 license, which we've talked about since around April this year, that's becoming the really popular trend ever since we're on Gemma 4 of this type of license, which means that you can fine-tune, train this, make your own custom private model and sell services off of it.
And there's no cloud dependency required either.
The idea is that it can run a local hardware.
It can even be on consumer grade GPUs.
And I myself, I haven't had a chance to tinker with it yet, but I'm definitely very curious to give it a try on some of the machines I have around.
And I do think that owning your inference and having this long running agent is a really powerful and useful tool for folks, especially because this one is more focused on.
doing tasks and is not like a coding agent, right?
So this is a really great candidate for if you have hardware and you want to run a long running agentic assistant, especially one that lives on device or works with sensitive or private data.
This becomes a really great candidate.
for that kind of world.
Of course, if you're using a model like this, you have to bring your own everything, including like your harness and the environment it's going to work in.
And this comes back to what we just talked about a moment ago of things like guardrails.
You know, if you're going to use Muse and you're going to ultimately have it working or operating on tasks, you have to think about the guardrails you have to bring to the system to make sure it operates safely within your environment.
Of course, this is all just baseline stuff for working with any model, but particularly important when you get long running ones that, live on your own device.
Really cool development.
I'm excited to see what people build with it.
What do you think of the latest developments?
Yeah, well, first of all, I'll love to hear what you think after you get it into your lab and dissect it and benchmark it and see what your agents think about it.
But, you know, also I would love to hear, you know, friend of show, Brigida Boeckler.
I would love to hear her opinion on this too, because I know we just recently covered some research she's been doing around the viability of local models.
And at the time, her conclusion was that they still needed some time to develop.
Like they weren't quite it yet.
But there was definitely potential that seems like it's on the immediate horizon.
So that's pretty cool.
I'm really looking forward to it.
I know she's probably out there already thinking about this.
A cool note for this one, too, is that this one was mostly trained via distillation from a larger teacher model.
That's a really important note I want to call out for our listeners because that's the trend for all of these open source models is that you get these loops where they're trained or created from synthetic data that's constructed by a smarter model or by a more frontier model.
So right now, a lot of the benefits we get in the open source world are just coming off of the comet trails.
right of these foundation models in a sense.
Yeah, yeah.
And my impression that this model specifically is sort of part of Meta's goal to attach AI to your desktop work environment.
So, you know, we've been hearing all these stories about how Meta's tracking their employees' computer usage and using it to train some new models.
So I imagine that that's really what this is, what has been used to sort of get this model to where it is today or one of the many things that it used.
So, yeah, I'll point out some things that really stood out to me on the technical front.
So, you know, the first thing I noticed was that in the benchmarks, it scored exceptionally well at this AA LCR benchmark, which measures a model's ability to reason about and to synthesize information from long form documents.
So we're talking like 10 to 100,000 tokens, which is, you know, that's a pretty notable achievement because that is still a thing that a lot of models struggle with, particularly.
other local models.
But then really what's notable is that it only requires 20 gigabytes of memory to run.
It seems like it's exceptionally low.
But then there were some new developments in this that were also just interesting as technological incremental improvements.
They have this concept called speculative decoding.
which is where they have this like super lightweight model that generates the output tokens in larger chunks rather than sequentially, which is how a lot of models do it today.
And then those chunks are sort of validated after the fact by a smarter or bigger model to confirm their validity.
So yeah, lots of just really cool, like incremental innovations out of this that, you know, are really making the local model space really seem like it's starting to heat up.
And I think...
The coming months are going to be like a lot of attention is going to be not just on this, but on all of the developments happening to local models.
I agree.
Yeah.
And speaking of open source, let's talk a bit about why open source matters for AI.
So we got an article here from the O'Reilly Substack from Tim O'Reilly bringing some just really great sage advice for the AI era from somebody who has been around for a lot of major technical.
or technological developments.
And this article argues, you know, how, you know, the open source models, the weightings, the harnesses, the context layers, the data that goes into this, it's really important that we do have effective open source competitors in this space, because there's a lot of risk in relying too heavily on a small number of proprietary firms to provide these types of services.
There's a really great allegory in here to, you know, the early days of the web when you had Netscape and Microsoft who were sort of duking it out and trying to figure out, like, how do we own the entire tech stack of the web?
Like, can we own the servers and the client side and just try to monopolize all of it?
And, you know, for a while, it seemed like that may actually play out.
But then you had something like Apache hit the scene.
that, you know, quickly followed with like the LAMP stack becoming the norm and suddenly everything is open source and nobody fully owns the tech stack of the web.
And, you know, some of the risks that O'Reilly highlights in this article that I think are really worth, you know, just paying attention to is that, you know, if we're increasingly relying on like one or two or three frontier labs to define like things like personality traits and the guardrails that go into these.
There's a risk of everything sort of like going towards the lowest common denominator.
You know, we all start to become the same with the same outputs and the same approaches to solving problems.
And there's a real risk that that sort of stifles a lot of creative innovation, for lack of a better phrase.
When you think about how like engineering teams are tinkering with a lot of AI today, like if you're using the frontier stuff, you're really doing more.
around customizing your harnesses rather than customizing like the weights of the model, for example.
And you may actually like both of those may be important things to focus on.
So yeah, I just really like this as somebody who's been in this industry for a very long time and has been successful.
And he's a big friend.
O'Reilly is a huge friend of open source and long has been.
It's just really great to hear his perspective on how AI is shaping things.
So what did you think about this article, Andrew?
I thought it was really smart how the article calls out that where the, the seams of.
of open source technology is used for models.
It's up until now, there's been a lot of controversy around what open source even means for a model.
Like, oh, you give us the model.
That's great.
But did you give us the training code?
Did you give us the weights?
Did you give us the corpus that was used to train it?
All of those things have their checkboxes and people use them to grade if something's open source.
But in this article from O'Reilly, he's really focusing on how the thing we need to focus on making open source is the modularity of the stack that all of the AI stuff is operating on the inference platforms, all of the tooling that we use to serve and store the data for them, making them as composable and modular and open as possible is actually the keys for letting all of the rest of that thrive.
Because to your exact point, like you, you get in this situation where different large players own really critical parts of just like the baseline experience of using the model.
Like think of what we've covered so far.
We talked about Anthropic really becoming, really having this, you know, a grip on the, on the classifying the dangerous commands and putting guardrails on prompting and stuff like.
If you move into an open source world, you don't have that anymore.
So we have to think about what are the parts that give us the equivalents.
And that's where this really cool AI potluck initiative that he calls out comes from.
The idea of how do you build this very rich ecosystem?
Think Linux foundation level rich ecosystem of all of the parts you need to run a cloud and making it open source.
We need that equivalent for AI.
And that's what the potluck is.
It's a pretty cool initiative.
And we'll link it for folks to check out.
I think that this is a really.
important part that we get right.
And so far, I think we are.
I think of the major tooling and the parts that I use to run my open source models or my harnesses.
And, you know, I feel like I have the parts I need to at least start assembling together.
But that's where I think a lot of the challenges will live is supporting that ecosystem and preventing all of us from fracturing and just writing our own versions with these models.
There's a lot in this article that I really strongly agree with.
It's worth giving a read.
But the tone in it kind of made me feel almost like, and we talked about this before recording, it was almost like a very cautionary and sobering take, you know, almost cold, like viewpoint on this perspective.
I don't want to say pessimism, but it was almost feeling like it was bordering on having a pessimistic take about it.
I really have sort of a very different perspective on it.
You know, I think that, yeah, open source is being very heavily disrupted today because of AI.
And in some ways, it is sort of following the lead of these proprietary companies when it comes to the frontier of AI rather than being what's leading it.
But I also think that we're sort of primed for a bit of like an open source renaissance, actually, because, you know, you mentioned distillation earlier with Meta's new model.
You know, AI has made it easier than ever to replicate and iterate on other people's ideas.
You know, I think open source is just going to continue very closely tracing the capabilities of the frontier model companies, particularly considering, again, how easy it is to distill value out of stuff that exists.
You know, we saw Claude, some of their code and architecture get released or leaked earlier this year.
And immediately everyone's out there with like their own versions of how they've, you know, they've distilled it into something else.
So, you know, it's a very, very exciting time.
But again, a great take from O'Reilly on the...
state of things.
Your SDLC looks more like a software factory every day.
How do you get ahead of that transformation?
And how do you prove what it cost and what it delivered?
On August 27th, DevInterrupted hosts a live roundtable on this very topic, proving AI ROI from software factories.
To learn, we've invited two industry experts and past DevInterrupted guests.
It's Dex Horthy of HumanLayer, who ran a fully automated factory and then shut it down.
and Zach Lloyd of Warp, who publishes frequently about how he measures what his factory pays for itself.
Linear B co-founder Dan Lyons will join them to discuss the power of the context layer that will make all of this possible.
Save your seat on Luma.
All right, let's talk now about your STLC and context engineering.
So here we have an article from our friends over at LeadDev where it really just breaks down how, you know, there's so much context.
scattered across all of your SCLC that really needs to be pulled into your agentic systems for them to make good decisions.
So there's a lot of context that exists in the way that work is specified and how it's reviewed, where and how it's tested and, you know, the realities of it being shipped.
And you really need to be accounting for all of that when you're trying to build an agentic system to contribute code into production.
You need to think about stuff like documenting all the states of your life cycle.
You know, what's the current state of your project?
What's the future plans for your project?
What's permanent and should never change without like a great deal of focus?
And really understanding all of those things and giving them to your agents when they need it within the SD DLC.
And this article, you know, it kind of, it's a very broad article.
It covers a lot of topics.
It's kind of a little bit too much that we can cover in length here.
But, you know, I wanted to bring it up because this idea of a context layer for your SDLC is a topic that we're continuing to see come up like over and over again right now.
And when you really think about it, you know, early agents really just had access to like your code base.
Maybe they had some basic metadata, like your project management tasks or.
PR descriptions.
But I think most of us learned like very early on that that wasn't enough context for most engineering decisions.
There were some places where it was enough, but many places where it was not.
And, you know, there's a lot more that goes into making good engineering decisions.
So, you know, you have to think about like, how well planned is your spec?
You know, what learnings and decisions did you make along the way that modifies your final outputs?
What parts of the code base have risky components that need particular care or review when modifying?
You know, which components get bogged down in reviews the most?
Like these are all questions that you have to wait when you're initiating a project or task because they all impact like the feasibility of completing them.
And, you know, humans, you know, we accumulate answers to these through experience.
But your agent only has as much experience as you feed into it.
Like we covered this concept a while back of where AI agents are like tourists.
It's like the first time they've ever, every time they show up, it's the first time they've ever been there.
And they only have as much context as they deliver, as you deliver to them as they go along their journey.
And then once they're done, they leave forever and go back home.
But that's, you know, that's really like, you know, and this is something that, you know, linear B, like we've really have started to ingrain this into what we're building for our customers.
You know, we're really trying to help understand, like, how do you how do you get that context layer into all of your your agentic decisions?
You know, and that's whether it's humans or agents.
You know, if a human is making decisions, they should have a format of all of this context that works for them as well.
So, yeah, we've we've been doing this a lot with customers recently.
And it's and I just think it's a really fascinating concept that really every engineering leader needs to be solving right now.
So, Andrew, what did you think about it?
You had really great coverage on what this article gave us.
It definitely dove into different parts of what matters for a team working on a code base together.
I think that's a real big focus.
A lot of times in agentic coding, you get these two different groups that are talking to each other.
the vibe coder or someone with a project that they are the only person touching anything on it and they can go really fast and they don't have these kinds of guardrails and you folks that are using it as a team and trying to build a product together and that's like a team sport and so like they need to have a lot more context sharing and a lot of the techniques that give one velocity would just totally you know, wreck another one.
And so that nuance is really important.
And this one gives us that, that secondary path, the idea of like, what does this look like on a team level?
So the article gives us some really great tactics here.
I think your point about, you know, the agents are almost like tourists and they come in and they do their work in their leave.
A lot of this is around how do you turn those agents into more like citizens?
of this code base.
Like they are native to it, fluent in it.
They are, they understand the parts that are needed to operate just as part of their, their, their operations themselves.
And that's what's achieved by having this kinds of layers of context as he's, he describes here.
I will say I wanted to go, you know, like on like a fridge, you get like the word magnets you can rearrange.
I really wanted to do that with the title.
Cause I'm like, your SDLC is your context engineering is.
not saying what this article says to me.
And it's really more about context engineering for your SDLC or how to put a harness on your SDLC because that's really what this is unlocking is it gives you as an operational or a leader person the vantage into this code world that's shared by a bunch of folks.
But then it also gives those folks and their agents the real-time relational context about what the heck is moving around them.
Gosh, we talk about that all day here on Dev Interrupted because that's our story at Linear B.
So really resonated with this article.
Yeah.
And speaking of context for your agents, let's talk about personalized skills and some new research that came across our desk on whether or not they help coding agents.
So this is a new study we read around the concept of personalized skills.
And these are preferences that are learned from an individual developer's past interactions with AI coding agents.
And the research wanted to find out if those were better for coding agents than more generalized skills.
So they ran this test across 13 developers with over 200 real-world developer agent sessions.
So it's a little bit of a limited sample size, but enough to at least get some ideas about what might work.
And there's actually kind of some surprising findings.
While the personalized skills did provide some productivity gains, it was actually kind of marginal, particularly when you looked at the impact of more generic skills that are pooled across many developers.
Those are the ones that produce the largest and the most consistent improvements.
And I feel like there's been an ebb and a flow.
over the last two years or so where people, you know, think that maybe AI needs to, you know, be heavily customized to the individual situation or person or workflow, or does it need to be more broadly, you know, constrained to have like wider practices.
And, you know, this research seems to indicate that particularly when you're trying to look at like what's going to have the biggest impact on an organization, it's probably better to have skills that that help everyone a little bit rather than to help one person a lot in just a few situations.
So yeah, it's really great research to read for anyone that is out there buying or thinking about AI coding tools or building them as a way to sort of prioritize where should you be investing your time for your team.
So what did you think about this research, Andrew?
This was a really great, for me, a revisit back to when we had Karthik Ramkapal, the distinguished engineer from LinkedIn on the show, talking about how to distribute gains across the entire engineering department.
We've had a lot of big leaders on the show, established enterprises, not small engineering teams, managed to get these kinds of operational gains and then also get those gains across.
adjacent departments, marketing and finance and HR and how it all comes down to is having this distribution system, a place where the experiments can live together, a place where learnings like memories and skills can live together, be version controlled and distributed amongst others.
And so that's the really big takeaway from this is that You know, I felt like this article was coming for me a little bit because I have lots of personalized skills based on my own tastes for working with all sorts of stuff.
And frankly, I think a lot of agentic operators do.
You just kind of accrue them over time.
And this article really calls out that maybe the benefits of those are marginal or not as much as you think.
I argue maybe there's a compounding effect of using a lot of those together to create.
do a very domain-specific task, but maybe that argues that there's more for simplification to be done, which I agree with.
But the biggest thing here is that those gains are marginal.
If you distribute those same kinds of...
learnings, but on a general level, and to everybody, the gains and productivity across the board are just substantial, substantially larger than they can be for the individual.
This really speaks to the power of us pulling together what works, especially within an organization.
And it's really promising data that this is a real trend now captured in this research.
It's a really great dive.
I recommend folks check it out when we include it.
But if you haven't thought about how you're distributing skills within your team, whether it's an engineering team or a product team or otherwise, I think that is your immediate next opportunity.
Absolutely.
Absolutely.
Well, Andrew, what are your agents up to this week?
Well, they're being cautious because I'm basically out of tokens.
And they have this concept of throttling themselves when that happens.
So I'm getting caveman talk again, unfortunately.
We're back in caveman days.
But thankfully, I'm only...
a few hours away from a refresh.
So then we'll be back.
I guess they'll be talking like Shakespeare or Homer or whatever they feel like.
What about your agents?
What are they up to?
I feel like you need to get a little bit of sub-agent delegation and model routing into your life.
Well, I just need to take some time to try out the new Glimmer and kick some things over to that.
I will say I burned my tokens doing a lot of really cool stuff this week, like working on a lot of news reading stuff.
I love to read lots of stuff, but as you know, the world's moving way too fast.
So we talked about an article in here recently about like...
There's too much information to consume it all.
Like, how are we reading?
How are we writing?
And it talked about this like layer of, of like understanding what's going around in the world and the curating what matters for you.
So I've been trying to explore that and build that, you know, using a lot of tokens in the process.
What about you?
We just talked about generalized skills.
I've, I, you know, with these mythos class models now all out, you know, we got, we got all of them.
Sonnet, Opus, Fable.
I can kind of pick and choose now.
I've decided to kind of go back and like look at some of the stuff that we've built in the past and how it's, you know, a lot of it hasn't, it needs to be, it needed to be iterated on to keep up with where the models are today.
So yeah, definitely some like generalized skills happening, but then also just like, it's a good time to build, as you mentioned, it's a great time to build new skills because these Mythos class models are, you know, the Opus 5.
Fable five, they are really great at constructing these things.
So, um, yeah, mostly just trying to get toil out of the way, you know, that's really where we're at right now.
It's like, there's so many opportunities to just be like, Hey, that takes too much time.
I'm going to go have AI do it for me now.
Yeah.
Every week it gets a little easier too.
Yeah.
Well, speaking of every week, thanks again to our listeners for joining us again this week for the Friday deploy presented to you by.
Linear B, it's always a pleasure to share our opinions and our learnings on what's happening in the space of AI and agentic development.
So thanks for joining us again today.
Engage with us wherever you find us out on social media.
We're out on LinkedIn.
We're on Substack.
You can see us on YouTube as well.
Leave a comment, a like, a thumbs up, whatever you can do to help us.
It really does just help spread the word of the show.
So thanks for sticking around to the end and we'll see you next week.
See you next time.