# Strategic AI Model Selection and Agentic Governance

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

## Transcript

So Kelly, have you heard the news?
I'm sure it's impossible to avoid it that Fable has come back into our world.
Fable is back in our lives again.
Yes, it was a bit of a I say it's a bit of whiplash, but like I didn't actually get a chance to use it that much before.
And I haven't really gotten a lot of time to actually use it this time around.
But I can confirm that Fable does recognize that there are three R's in strawberry.
Wow, incredible.
So you were able to get to the bottom of it with the latest model.
Yes, I cannot wait for like my analysis of like how I've used the different models.
And it's like, you spend how much on this query?
It's like the strawberry benchmark is really where you go to first.
It's incredible.
And, you know, I think it's funny that you comment on like having a chance to try it again.
I remember when it came out and then it got taken away.
Remember, I was in your DMs on LinkedIn and I said, I was like, Kelly, did you try Fable?
And then you said no with a little sad emoji, I think.
So sad.
Yeah.
Yeah.
You're not alone.
There were a lot of folks who I DMed on LinkedIn.
I was like, did you try it?
And a lot of people were like, no, like I didn't.
It was actually staggering to see the number of folks who had like they didn't get a chance to.
So to have it come back and they get to try it is really great.
We do only get this one limited week of it being on our.
subscription to your pricing.
So what actually I think this talks about more than ever, and we'll dive into in a moment, is the importance of choosing the right model for the task.
Because I think Fable is going to be one of the first of many of these flagship models getting really, really expensive for highly specialized stuff.
So what do we need to be learning from it?
And that's what we're going to be talking about today.
And to those listening, welcome to the Friday Deploy brought to you by Linear B.
I'm your host, Andrew Ziegler.
And Ben is out this week enjoying the great outdoors.
whatever that is, but don't worry because it does feel nice to go and touch grass.
But, you know, here on Dev Interrupted, we touch keyboards and we chat with friends.
And so don't worry, we have a past guest and in fact, your favorite engineering manager's favorite engineering manager returning to the show, Kelly Vaughn.
Kelly, it's amazing as always to have you here.
I'm so excited to run through this week's news with you.
I am so excited to be back again.
You know, I love doing this.
I love hanging out with you and I love talking whatever tech news is on the plate for the week.
Exactly.
And it's good to gossip about it out here in the open instead of in our DMs on LinkedIn.
So let's get to the bottom of it because this week there's been a lot of interesting stuff going on, obviously.
Anthropics control over a fable and releasing it to the market has changed.
And we're going to talk about what that means.
We're also going to talk about things around agent identity and how you should be thinking about that in combinations with your workflows.
We're going to be diving into a data science benchmark from past guest Brian Bischoff.
You might remember the data science America's Next Top Modeler that I participated in back in October.
We got a post-retro on that that's really fascinating.
We're going to learn some stuff.
And we're going to talk a little more on the interpersonal side, because as we all know, creating software is a deeply communicative sport, right?
It requires a lot of communication, team building, collaboration, and understanding the perspectives of others and how you're working together.
So we're going to be talking about why arguing isn't necessarily the best way to get about proving your point and avoiding some villain bond leadership.
based on some advice from our favorite charity majors as well.
So Kelly, I'm really excited to dive into some of the things today, but I just wanted to start by revisiting just for a moment the fable getting brought back out into the world because...
One, I think this represents a really interesting change in how models are going to be released moving forward.
I think you're going to see more interference from organizations and entities in the models coming to market, at least in the West, which is starting to have more restrictions around the capabilities and concerns around things like internal cybersecurity and stuff.
But also, too, on a practitioner side.
Having the model come out and then I tried it, you know, we talked about this extensively in our new segment.
I use like all of my tokens, writing the dragon, the fable, basically.
And I couldn't stop talking about how helpful it was.
But the fable has come back.
It actually has a lot of model routing capabilities underneath.
It'll actually send things like.
coding requests in many cases off to an opus model underneath.
It'll use things like Sonnet, the new Sonnet 5 that came out along with Fable 5 to do a lot of things like writing.
So it kind of begs the question of like, what is Fable?
And what is Fable doing?
And I think it has to do with like this organizational intelligence of how work gets done.
And it represents the new kinds of models that we might have moving forward.
And that these models might get really expensive.
But, you know, Kelly, what were your thoughts on this thing coming back to market?
Yeah, I think we're going to be seeing a lot more of this.
I think the big splash of this model is not going to be something we continue to see in the future.
I think we're going to see even more interference.
And it's a weird time to be in this phase.
I would say it is probably predictable that we would have ended up here to begin with because we fear things that we don't understand.
as humans.
And we understand that we don't really understand what we're doing yet.
This is a very fun exploratory period.
But as these models get smarter, we don't know what we don't know yet.
So I do understand that I don't love the national security piece to only release it to certain very special customers that aren't Zapier, unfortunately.
Otherwise, I would love to be in on early.
But I tend to see more and more of this.
But one thing I do kind of want to touch back on is the choice of model.
The model routing, I think, is actually a really smart thing to do here because I think we also have a tendency of overestimating how difficult something might be.
And so we're going to be immediately default to like, oh, I need to use the smartest model for this, the most expensive model for this.
And if I'm foreshadowing for anything, I apologize in advance here.
I think it's important that, you know, we all want to kind of play with the new stuff.
But if we default to using whatever's newest, we're going to run out of money really fast.
Oh, yeah, I think that's really great advice.
The whole idea of being aware of what model you pick up and which ones you're using for what task is only going to become more critical as these models, I think, become more specialized.
Up until now, we've been seeing these like step level changes and foundation level capabilities.
But and you're still going to see those, you know, at an obviously slower rate moving forward.
And Kelly, I think you're really smart to call out that you're probably not going to see the big splash of releases anymore, because now I think the name of the game is going to be how.
can I get the intelligence out the door day by day?
How do I, I guess, like, you know, continuously deliver the intelligence and not ship these big models?
That way you would sidestep this whole, oh, now there's a curtain falling on security and interference.
And I think that might be a strategy we see where like you just now see a latent increase in capabilities.
But on top of that, I think you're also going to see them split into.
highly specialized domain-specific models where you have that really smart flagship model or you have a open-source way alternative.
There's a lot of them now that are open-source.
Apache 2 that you can build a business on top of.
And you take them and you fine-tune them on your domain expertise, on synthetic and real data from something you're infinitely knowledgeable about.
And you build a highly specialized intelligence for handling things in that domain.
That becomes the new frontier.
If you trained that, then it's like, yes, sure, over here, maybe the step level capabilities keep going up, but none of them will ever be as good at that specific domain task as this one that was trained off of this one.
And then if we ever want to move it along with it, then as open source gets better, we train along with it because the data set is modular.
So these become the new strategies I think people turn to.
I think Fable is going to be an event that causes folks to really wake up to that reality.
Speaking of waking up to the reality, our producer, Adam, who's not here today, he was on the ground this week at AI Engineers World Fair, recording some really cool stuff, capturing some things on the scene, but also hearing from Human Layer co-founder Dex Horthy, who's also a past guest on Dev Interrupted.
And Dex, you know, he made a lot of news and folks were talking about his presentation, about how, you know, teams are over-relying on poorly trained models and they're having a fast throughput.
of code that maybe goes through some facsimile of a review and delivery process, but then, you know, days or weeks or months later when there's incidents, when there's outages, when there's critical flaws in the software, being unable to turn back to the work that was done and understand the legacy of how you got there.
What were the decisions?
What were the artifacts?
What was the code and the tests?
And, you know, that level of auditability, observability is different for everybody.
But, you know, he's really calling out here the importance of putting the human back in that loop of being cognitively aware of what is happening at stages of this process.
That way it doesn't take months for these AI-generated flaws to surface in your product and what you're delivering to customers.
And really, he was...
Attacking to the idea that, oh, just optimizing your harness is everything, that just getting the loop is everything.
You know, getting the loop and getting really good skills is one element of being a really effective agentic worker.
But sharing context and aligning with others and their agents is actually the differentiator for teams that are delivering durable software.
Yeah, I love this topic because it's something that I firmly believe as well.
I am a strong proponent of, you know, multi-threaded agentic engineering.
I think there's a lot more that we can do at the same time, but that doesn't mean that every task is one size fits all.
I have seen product teams ship a whole new product in, let's say, four weeks, four months, whatever.
And what they're capable of doing now is amazing.
But I've also seen what happens when those incidents arise and we're like, okay, we're now using...
AI to diagnose a problem that AI wrote and AI reviewed and AI shipped.
We are the humans in this conversation.
And it is, you know, there's a reason why I'm also a big fan of, you know, making sure engineers stay employed.
Engineers serve a very important role in engineering.
Like we are the ones who do hold the context and nuance and really being able to understand the systems that we're building is what keeps us in engineering.
And so I love this whole take.
And I, of course, was not at the presentation, but I'm bummed that I did not get to see it in real time.
I know.
I'm excited to dig into more.
Everything from Dex, I think he's really spot on with how folks should be thinking about their engineering practice.
So more to come always from Dex.
I recommend folks follow him on LinkedIn if you're not already.
And our next topic is getting a little more granular around some of the problems of having agents roaming around without where all your code is in the first place.
And this is a really interesting article that dove into different ways that teams are giving their agents identity.
The idea of the identity being.
borrowed from the human user or being something distinct and token-like to the workflow or being something cohesive and durable cross-sessions like an agent identity.
These are all different ways that folks are tackling the idea of how do I understand who did what and under whose authority and with whose permissions, which I think is one of the biggest dangers right now lurking with AI inside of large enterprise organizations, especially those that are still.
figuring out how do we share these durable AI practices across the team.
And also, too, what I love about this article, we'll share it because it gets technical in terms of the level of ways that you'd go about instrumenting and actually applying these three different things.
But critically, at the end, it does a really great job at comparing when would you pick up one over the other?
We know these three exist.
Why do some orgs fall into bucket three where they have to build a very complex agent identity system?
where everything has an ID that goes back to an agent.
For me, it makes me think of like, oh, yes, because like huge, large, sprawling enterprises, there were times where they all had glowing eyes for building microservices or like, let's just be on Kubernetes.
And it's like, why are we on Kubernetes?
We have 500 users.
So it's like, and so like these kinds of, that's what it makes me think of when I look at the agent identity thing of, is this an over-engineering?
Is this wanting to hit?
Is this, you know, wanting to hit the hammer with a nail or whatever the metaphor is?
I feel like that's kind of what it starts to feel like.
You know, Kelly, what do you think about how, even within your own team, you have a lot of folks and work that happens underneath you and the permissions and scopes that they have are all varied.
How do you think about it as an engineering manager?
Yeah, I mean, the governance piece of this is critical.
And, you know, we've, at Zapier, this has always been a conversation.
You think about automations running.
Automations have, like applications, like integrations connected to it, who is like, who owns that ZAP versus who owns that, that integration, it could be different.
And you're like, the governance piece is always a question that has to be answered.
And so like, I'm just seeing the same thing in a different flavor.
And, you know, when I'm thinking about attribution for who is working on what and who is responsible for this, if everything goes through an agent's ID, and there's no actual human tied to that, that becomes, you know, worrisome for me because I don't know who to talk to.
And like my, like the other EMs that I work with are seeing the same thing.
You know, given these three, like, as you were saying, the possibility of like over-engineering this, I completely agree.
One of the things that kind of stuck out for me is this, or with this was that it very much feels like it should be like a step letter.
in a way, or like you should, you should work through the rungs.
And when you start feeling pains, explore the next option, as opposed to immediately being like, well, you know, one day we're going to need this, this massive, massive thing.
So we're going to go ahead and build it now.
Good luck.
Like having to support that in the near term, like we all have a tendency of over engineering.
And I know it's exciting to think through like the, the wide, the broader widespread like agent identities, but like, it's okay to start small.
You should start small.
Yeah, you should scope it.
And by scoping it, they say, you know, step one, start by borrowing the user's credentials and their permissions and be scoped about it and have auditing and logs, which you should already have for every agent to call.
Anyways.
And so, yeah.
And so it's like, we're just talking about baseline instrumentation to achieve the identity.
And then the rest of this becomes things that we're already familiar with, like API tokens, which at this point, everyone just assumes are compromised the moment that they're generated.
And so really, it's like.
When you dive into this article, you'll see this thing about Spiffy and Spire and all these different systems for setting it up.
And I will say that my engineering brain was like, ooh, fascinating problem.
And I could definitely hear the cogs turning.
But that was the danger for me is I was like, I could spend a long time trying to build this answer.
And I don't think anyone has the real answer yet.
But treating it as rungs in the ladder, it's a really smart strategy so you don't overextend, I think, in the meantime.
Totally, totally.
So our next story is a recap from a hackathon that happened last year.
This is America's Next Top Modeler.
Yes, it's an incredible name.
This is hosted by Brian Bischoff.
He's the head of AI at Theory Ventures and friend of the show.
Most recently was with him at AI Council where I presented.
He was also a guest on the show.
And he had this hackathon, America's Next Top Modeler.
And he really was kind of like this.
crazed villain running this hackathon.
And for those of you who've been listening since last year, you might remember the premise was that he brought 150 engineers together and one real analyst at like an analyst company to be given like a huge dump of...
enterprise data that was made up for a shipping company had all these products.
It was like SQL tables and system logs and like literally like 800,000 PDFs.
There was even a physical dusty binder that represented a binder sitting in a warehouse somewhere for the shipping company.
Like he went through all means of being like information is messy and it lives in a bunch of places and it's not, wasn't ever created with the intention of an AI built using and doing stuff with it.
He challenged us to, as you know, nascent data scientists, AI.
engineers to build a system or a practice that would be able to answer this set of eval questions.
So you've got like an eval system.
And really what this article is, is it's a benchmarking and diving deep on how that process unfolded from the person who designed it.
I personally found this very fascinating because I spent six hours maddeningly like turning my brain over in cursor trying to get, you know, the right results for the different eval questions.
And there were folks that were doing all sorts of different brute force methods of trying to actually get the right answer, including someone who was running like 30 Claude code sessions in parallel.
And at one point his computer froze.
And so it was just, everyone was doing something and it was.
Really, really, really fascinating.
So this article dives in on some of the things that stand out for data scientists that are pitfalls in AI.
Like data science is often a matter of sequencing together operations and changes and data to get your final transformation that you're looking for.
And each of those are very susceptible to having the wrong parameter or the wrong kind of keyword.
And suddenly your end result is wrong.
And so it can become much messier and harder for the agent to backstep and understand it.
So they even created this really cool.
grid where commonalities of agents and their approaches would break down when trying to do these joins and sequences.
Really interesting data deep dive for anyone who has tried to throw an agent at data.
And I'm wondering, Kelly, is that you?
Have you ever tried to use an agent to roll over lots of data?
To some degree.
I mean, with the amount of data that we have in Databricks, for sure, I've tried to parse through a lot and try to create a story out of that.
with medium success, mostly because, and I think this is important for like one of the takeaways from this is like, what big goal are you actually translating into something to be really precise and verifiable and step-by-step?
And that is an interesting takeaway for like the sake of this study, like this hackathon, but this is a takeaway that should apply across the board.
You know, it's the same thing of like throwing a very vague like JIRA ticket at an agent and saying, do the thing.
If it's vague and if it's...
Exactly.
Yes.
And so I think this is an interesting takeaway.
I'm glad you participated in this.
Amazing name, for sure.
I think the takeaways are just, they're so applicable across all different facets of engineering beyond just EIE Bells.
I even think of the Andrew who was sitting in the chair in October doing that hackathon and what his engineering practice looked like.
And I don't even recognize that person.
So it also speaks to how fast.
Because I'm like, oh, wow, if I did, I read, I'm reading this article.
I'm like, oh, wow, I could do this again today.
It'd be a piece of cake.
And I know I'm still wrong, but it's just crazy how much that cognitive stuff has grown since then.
Andrew and I, we just wrapped up this really great session on token maxing.
And we had a lot of fun, you know, running through it.
We got a lot of feedback, a lot of questions.
from the audience.
And it's very clear that this topic is really hitting a nerve right now.
And I think it really has to do with the fact that executive conversations all over the place right now around AI has really shifted from this, let's get everyone using it to now everyone's wondering how much are we spending?
And is it actually worth what we're spending?
So if you missed the live stream, we have the full replay on demand over at linearbeat.io.
And, you know, the reality is that your CFO, they aren't looking at adoption rates or token counts anymore.
They want to see what all of that generated code is actually delivering for the business.
So in this session, we map out exactly where AI is shifting bottlenecks in your pipeline and how the Linear B's Apex framework helps you measure what is really valuable to your business.
So we'll share a link in the show notes, but you can also head over to LinearB.io to check out the full session.
But, you know, I want to jump into our next article, which is a really interesting reflection on a reality of anyone that's in a workplace, which is most of us listening to this is, you know, you're in a classic conundrum where you and someone else, maybe it's a close co-worker, maybe someone you don't work with very closely at all, you disagree.
And it could be a fundamental disagreement on something related to the product or direction or alignment.
And it could be something where there's a lot of ego and skin in the game, maybe like also.
some costs as well.
And so all of that attributes to, you know, sometimes when there are disagreements, we can be prone to arguing about those disagreements as opposed to working together to find the real solution.
And something that's really smart for anyone who's ever dealt with this problem of like someone's disagreeing with me and the more I try to prove them wrong, the more they dig in.
How do I actually go about proving my point or being correct?
And this article is really great.
tells you, reminds you that you're not, the point isn't to be correct.
The point is to find the right way forward with what the right solution is for you and that person and what y'all are working on together.
And in today's day and age, one of the amazing things you can do is that if you feel so right and so convicted and so aligned with what needs to happen, okay, say that to your agent, make a spec.
Build it out from top to bottom.
It doesn't have to be an argument anymore.
Now you don't have to get in the argument with the product manager or the team lead about what the team is going to prioritize or that this isn't important enough to be on the roadmap or whatever the case may be.
Because you can just do it over.
If you have that idea so firmly from top to bottom, you could spec it out.
You could get it built.
You could build it yourself.
You could show them the art of the possible.
And you can just get people on your side by showing the right way to be done.
improving it.
I thought it was really just like obvious, but also to like really great advice for folks.
Yeah, no, I completely agree.
You know, reading the topic, I was just going to be like, oh, no, that's a horrible idea.
Because if you stop arguing and just accept whatever.
You know, I know they were like, I just shrink into the I just give up on the thing.
No, that's the opposite.
So you don't want you don't want to argue either.
It becomes like you damned if you do damned if you don't kind of situation.
There's actually a there is the happy medium.
And I think that this one strikes a happy medium.
Exactly.
And, you know, we all know when it comes to a disagreement, data drives the agreement.
Yeah.
The more you can bring data into a conversation, the easier that conversation becomes, you know, in in in my role.
One of the most important things that I see is I, you know, I have escalations brought to me.
I raise escalations is we have to disagree and commit at some point.
And I think I think it's mentioned in the article somewhere of like, it's OK to just let something ride out.
And if it doesn't work, it doesn't work.
This is one of those things I often see, especially with new managers, for example, who are like very prescriptive about how they want something to be built and they don't agree with what one of their ICs is.
recommending they do.
I'm like, let them build it that way.
If it doesn't work, it's a learning opportunity.
So I want to 100% agree with this.
Like there is some healthy disagreement, but understanding where that healthy disagreement turns into arguing for correctness is probably the most important line that you need to identify in yourself.
Right, exactly.
Before, that would have been you or someone in that position of being like, oh, I don't even have to work to prove myself right because they will prove myself right by going down this wrong path and discovering this is not the right way.
Now, you can just immediately illuminate the right path that you see, and they are still allowed to follow down that path.
In fact, in many environments.
they should be encouraged to.
You should figure out maybe you're wrong and we should figure out which one is the right path forward.
I think that's the benefit of just like being able to iterate quickly and that the work just has to be based on like alignment.
We just need to understand what has to happen.
And speaking of alignment and knowing what has to happen, you know, who can say it better than Charity Majors, the CTO of Honeycomb, who has now an advice column on Stack Overflow.
Which I hope she has for all time because I want to read advice columns from Charity for the rest of my life.
Charity has been a guest on the show many times in the past, is a good friend of Dev Interrupted.
And in this advice column, she answers somebody who's asking about the real problem-plaguing engineering leaders around almost becoming...
bond villains in a way.
This problem that happens where our culture of success in particular tends to have a survivorship bias of praising and putting those who do make it to the end or have a certain accreditation or have a really big accomplishment, putting them on a pedestal and being like, they worked really hard, they did that, they achieved that.
And in some cases, not acknowledging all of the work that came to that point, the ups and downs.
in their journey because it wasn't always rosy and starry the whole way, but then also all of the people and efforts that make it possible.
And I myself am really passionate around this topic.
I don't know if for those of you who know, I don't have a software engineering background from college.
I have a humanities degree and I studied classics.
And actually I wrote my thesis on hero cults.
And so the idea of people...
getting all of this glommed up attention from people who attribute their success and their organizations and their outputs and everything underneath them to that one singular human is something that has actually been chronically affecting just humanity since we've existed.
It's a fundamental part of society.
It's what's driven the creation and fall of every major civilization that we've ever written in a history book.
And that's really fascinating to me because you see the same microcosm play out even in industries, even now with.
within like places like tech where, for example, the CEO of a huge tech company, you get this like singular idea where all of the success of Meta is Mark Zuckerberg, right?
They become inseparable in terms of their identity.
And so Charity here, she gives us some amazing advice for how to navigate that reality within our industry and ultimately explains how that phenomenon comes to be.
But that also gives some really amazing strategies for folks on how they can be.
more empathetic leaders, how they can lean away from that natural inclination within human nature to fall into those ways of thinking about our leaders and the companies we work within.
And then she gave some really solid advice on trying to move up the ladder to become a director as well.
And so this is a really heartfelt article from Charity.
Charity has this amazing ability to write something, and it feels like she's sitting down right next to you, having a really good heart-to-heart, and you're getting the best advice that's specific to you.
And this article delivers the same.
for me.
What did you think of this one, Kelly?
Yeah, I absolutely love this article.
And I also like, I don't want to paraphrase this.
I think it's just worth reading the article itself.
Because I've always loved Charity's writing.
I always love how like, just open and honest and like experienced she is.
Like, she's very trustworthy in what she brings because it's backed by experience.
And at risk of sounding like I'm...
doing the same thing for her, lifting her up.
There's a difference because she brings so much humanity into it.
And I have worked at enough companies with enough leadership to see the other side of the coin, to understand especially the survivorship bias and how that kind of changes the way somebody is viewed.
And as somebody who takes pride in being able to read right through that, you know, similar, you have a very different...
background.
I don't know if I told you, I'm going back for my fourth degree.
I know you're very educated.
None of which are also in engineering.
You know, it's social work, it's public health and two sides.
I'm about to get my second psychology degree, like very much same thing.
And so like the human, the human side of this is so incredibly important for being successful in a way that doesn't feel like you're like becoming just that authoritative figure and losing, losing sight of what it means to be a leader within an organization.
Totally.
And the really powerful takeaway here, I think, from Charity too, is that she hits on a powerful thing, which is, you know, at the end of the day, you still can't sidestep.
being a good business person.
You have to be good at business.
You can have a big empathetic heart and know how to lead a whole team and get people aligned around a vision and do so with just the hugest amount of empathy.
But then if you're just a formal business operator or you're not strategic or you aren't able to take your team through those opportunities and those downfalls and all of the things that are going to affect your company, then It doesn't matter how good those morals are.
It'll be really hard for you to weather that storm because the reality is, is that like 90% of, you know, VC funded, you know.
startups, they don't succeed.
That's the survivorship bias at work.
But also I think this becomes a powerful rally for folks where it's like, this is your call to action of if like you are a business person and you're like, but I don't want to be that tech CEO.
I don't want to be that.
Is that you can be something better.
You can be your own thing.
You can be like charity majors.
And so there's a lot of role models out there.
And this is a good place to start.
And speaking of role models, you know, Kelly, you're here on the show and you're one of my role models.
And you dropped us a really great article recently about the backlog.
And this is a really cool blend of understanding like how your team works, but then also the realities of agentic engineering and how the teams are having throughput these days.
I want to hand it over to you.
Why don't you tell us a little bit about this article and what came into writing it?
Yeah, yeah.
So I have been spending a lot of time thinking about how.
how productivity has been shifting within an organization, like within my engineering org, for example, and how my engineers are adopting AI to change the way they work in very different ways.
But there's one common thread here, and I've heard it in multiple conversations, where if I'm doing multi-threaded agentic engineering, as in I'm working on multiple things at once, as in my agents are working on multiple things at once.
I am going to run out of work in the backlog.
And that would be such a beautiful thing for you to come to me and be like, we have run out of work.
What do we do next?
Never going to happen.
But we can focus our backlog on things that actually need to be done.
And that's why I'm talking about the backlog is finally getting its moment here.
Because over time.
We constantly have new issues come in.
We have technical debt we accrue.
We have package upgrades that we need to have done.
We have paper cuts that come in.
We have projects we've scoped out very, very beautifully.
We deliver the MVP and we're like, all right, we're going to fast follow with these things.
Oh, wait, there's a new thing we need to build.
And that just continues to build up the backlog.
And we never really spend enough time cleaning up that backlog and making sure we can.
keep things moving along.
It's become even more important now to be able to do that because what I tend to see working as far as multi-threaded engineering goes is like you have one big thing that you're spending a lot more time on, but you have the little wins along the way as well.
It's funny because like that's the same way I model my to-do list too.
I have one major thing.
Like if I get this one thing done today, it's been a good day.
I've got my two things below that that are like cool, great.
And then my three like very, very tidy tasks respond to this email kind of thing.
We're kind of seeing the same thing in engineering, but I have to have enough things on my to-do list to keep up with those tiny tasks.
It's much more important to keep up with that list when you're thinking about an engineering team because they can move a whole lot faster when an agent is able to take a very well-described customer bug.
just run with it and fix it.
And you've got the proper AI tools in place in your CI pipeline to be able to check for, you know, do all the linting and automatically make the adjustments that you may have missed a test that's failing or something, you know, there's so much that you can do now that we just really need to make sure that we're nailing the backlog at this point.
Yeah, this idea of...
It's smart how you split out the capacities of work and the idea that you can have these big things on your plate and then you have all these smaller things, these throughput things where if they were well aligned and well specced and we had a really durable delivery system that we can trust for reviews and getting things out the door, then this should just be a matter of figuring out exactly what we need and staging it up somewhere.
And then this becomes a matter of engineer focuses.
And this is why I like the diagram you gave us.
Engineer focuses on the big...
the big rock task of the week or whatever their main focus is.
And then in the side channels, their review or like, you know, things are coming to them for review, things that they're not really doing anything, any cognitive time on other than maybe initiating or being pestered to put their eyes on it at the very end.
And then just acknowledging that those are two different lanes of capacity.
And you can't like, you can't maybe like overfill that big lane of the big stuff and expect them to be super successful and agentic across really big things simultaneously because that's a lot for an operator to keep in their mind.
But you could certainly think of a world where if all of the cognitive work was already done making the ticket.
then it should be relatively straightforward for you and your professional capacity to do these almost like micro reviews.
But you have to be really smart, make it really small, make it really bite-sized for folks.
But obviously, it becomes like a really good opportunity, too, for you to harden your SDLC, because I think most folks aren't even going to be able to trust everything downstream necessarily to be able to go that fast.
Sounds like you all have like a durable practice around understanding when the AI generated code is created, what happens to it and where it goes.
And we're continuing to invest in these tools because it's such a critical part.
Like the SDLC is so much more than the humans involved in it.
And we really need to be investing in tools that support the human side of the development process because we can't expect humans to double, triple their output without assistance.
Yeah, amazing.
And that's exactly what we always talk about here at DevEntrupted and Linear B is that exact problem of just being able to have a grasp on your PRs and your agents and what are they doing and touching, but then also too, what's getting delivered?
And then when it's getting delivered, is it getting reworked?
Is it causing...
incidents, how fast are we going?
And then specifically being able to granularly understand this on a per team basis.
If you look at AI on aggregates, you get nowhere.
AI normalizes itself really well when you try to like just do an org wide view.
But then you zoom in on a team or a department or one particular end of your SDLC and you get a picture painted if you're able to have that data on hand.
And that's something that we're really passionate.
about, you know, if you're listening to this and you're definitely somebody who's trying to get a grasp on how your engineering organization is actually being successful with AI and if you're building a durable practice with sustainable code.
And how do you take things that work really well for one team and bring it into another?
That's what we focus on at Linear B.
We're an engineering productivity platform.
Definitely recommend that our listeners check it out.
But as for today's Friday Deploy episode, that's it for today's Newsweek lineup.
If you enjoyed everything that we talked about today, please be sure to give us a like and subscribe wherever that may be happening, as well as dropping us a comment on LinkedIn.
Kelly and I would love to hear from you on LinkedIn.
please come pester us.
We love hearing from folks who hear us gab.
And I'm sure you'll be hearing more of us later this year as well.
And so thanks again, Kelly, for joining us today on the show.
Yeah, as always, thanks for having me.
Thanks so much.