# MCP Decline, Context Anchoring, and AI Workflow Optimization

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

## Transcript

Andrew, are you taking advantage of Claude's recommendation to start working nights and weekends now?
What do you mean, Ben?
Uh you haven't gotten the notification yet.
And when you sign in, it's like, hey, we'll we'll give you more tokens if you work late at night because it's cheaper for us.
Oh yes.
If you distribute your workloads, the times when not everyone is rushing to slam GitHub with their with their pull requests, definitely getting people off of the morning shakeup on Mondays for sure.
I don't know about you, but like every Monday morning, it's just like, oh, is this gonna be is it gonna fall over today?
It's like every every week now I'm bet I'm like betting on my repositories.
Monday mornings, it's like I feel like almost every AI tool is like barely surviving, just like scraping by, suffering through the like first few hours of the the work week before like things sort of flatline, you know.
It it makes me think of like uh a very kind of apocalyptic future where there's like rolling token blackouts where you're in like a a token blackout because the consumptions are are too high in your area.
And imagine what that would turn off, because it has electricity when it shuts off, you can't turn on a bunch of things.
Maybe when the tokens stop flowing in your area, a lot of things don't work anymore either.
Well, you know, like people get like batteries for their house when they have like solar panels, you know, to collect energy and then like use that battery energy when pri electricity prices are high.
Like I wonder if there's a way for me to just like collect tokens, you know, so that I can leverage my my bank of tokens when when token costs are high.
Okay, well, somebody get Ben a solar farm and let him get cooking, because that sounds fascinating.
But uh it would be nice to just get more tokens in general.
So I love Claude's idea of distributing uh folks around.
I I would just wonder uh who will do it.
Obviously, if you can orchestrate your agents and they're running for you all the time anyways, what's it matter?
It's like they're they're probably always running slash you could just have them run later.
So yeah, which you're saying is all the more pressure to just have our agents constantly working for us when we're not working, I guess.
Yeah, well, and on that note, welcome to the Friday deploy.
I'm your host, Ben Lloyd Pearson.
And I'm your host, Andrew Ziggler.
And in this week we've got MCP, is it dead?
How to anchor context to prevent model compaction, the resurgence of the small web, and an AI etiquate guide.
So let's just start at the top with MCP.
Andrew, is MCP dead?
Okay, well, this spicy article is about how MCP is gone and no MCP is back and MCP is somewhere in the middle.
Yes, I think AI's darling child MCP has certainly ran its course of popularity.
I love how this article calls out the fault of AI hype influencers for making MCP more popular than it needed to be.
Uh, I don't know if this was directed at me, but I'm just kidding.
But if you if you have been listening to Dev Interrupted, especially around this time, about a year ago, you'll know we were talking about MCP on this show a lot.
And I know why the timeline in this article actually almost perfectly lines up when we were hyping MCP.
So I feel like he probably is calling us out directly on this one.
Yes, yes.
Clearly a dev interrupted reader, clearly disgruntled by our effusive coverage of MCP.
And you know what?
I don't blame him.
Because reflecting on it, it was a different problem, a different solution for a different time.
Because around this time a year ago, let's not forget the models were a lot dumber.
Their ability to use tools was not as great as it were as it was today, and MCP was a fundamental day and night change in the ability to get consistent tool usage from LLMs.
It really paved the way for more token optimized and simpler solutions.
You know, we all kind of ended up going back to CLIs in some form or another instead of carrying around massive MCP servers.
And the benefits of this are numerous and lots of folks talk about them.
But what this article calls out is why was MCP in the spotlight in the first place?
And I think it's a great reminder that you know we're in a growing pain.
We're going to be uh embracing and using technology that maybe it's not going to stick around forever.
So you should always be working in a way that expects your tools to be temporary and moving with you, not standing still.
Yeah, and I want to point out that I I kind of thought it was obvious that CLIs are like more of a crutch for AI agents than they are like uh an interface that that they would should be standardized around.
And it's really just because it's like it's just the most common interface, right?
Like it's been it's been around for decades now.
And so if if you're gonna have an agent do work, it's gonna naturally pick up a CLI because what other what other option out there is is there?
But you know, I think if you were to actually ask like your agents, like, how would you design and implement your ideal interface?
Like, uh it wouldn't look nothing like a CLI, even though it's become such a popular tool for AI agents.
But yeah, I really like the just the per pragmatic perspective on MCP in this article.
So, you know, like I said, we probably contributed to this, but MCP was overhyped months ago.
Um, it kind of seemed like everyone was MCPing all the things, like not a week went by that there wasn't half a dozen companies announcing their new MCP product thing that they've attached to their their platform.
Um, but the reality is that there's really like more situations where MCP shouldn't be used than there are actually situations where it should be used.
It's not like this one size fits all agent connector thing.
So if if you're like still trying to understand like what's the difference between a use case where MCP is great and where it's not, like, this is this is some really great reading that I think is super timely.
You know, one last thing I want to end on there is a big thing MCP solves that CLIs still won't is distribution.
MCP is a really great way of getting your tool and your in and of your widely used API in the hands of a lot of people really quickly and consistently.
And while CLIs can certainly be uh applied in the same way, just MCPs are more portable uh just at the end of the day.
And so there is definitely still a use case for them.
Yeah.
All right, let's move on to context anchoring.
What do we have here, Andrew?
Yeah, so this is an article from ThoughtWorks, like it's covering latest research about how AI coding sessions, you know, when they run very long, and after a while, you get to a point where you have to ask yourself, like, would I be stressed out if this chat closed right now?
Would it be disrupting to my work if this chat were to end?
And most developers, uh, once they get in to a few turns with any AI coding tool would answer yes.
And it's because so much of the usefulness of any session gets wrapped up within this temporary window that over time experiences an event we all know as compaction.
And this compaction event is pretty savage.
It degrades what the AI can recall.
Uh, this research shows that the things that go first are the reasoning behind decisions, not the decisions themselves, which creates an even shakier ground the further you go.
With other experts, like we have had Dexter Warsey on the show, have called out rightly that around 50% really drops off a cliff.
And the solution for this becomes a technique known as context anchoring.
I'm a huge proponent of this.
We'll talk about this like a little bit more too.
But the idea is that you capture like a living feature document that externalizes context and decisions.
It's a little different from an architectural decision record.
Those are more formal and exist within a different uh like a different place.
This is more like a substrate where you and the LLM are working together to capture this very temporary bit of knowledge.
Uh, there's lots of different tools for doing this, but I gotta say, this uh article comes at a really fascinating time when Opus 4.6 is just right now reaching its 1 million context window.
I've been using it on a daily basis, and my sessions now just have so much room in them.
It gets really tempting to go for way longer than I would have, even at like a week or two ago.
Ben, what did you think about this article?
Yeah, well, this is part of a series that we've been following for quite some time now from the ThoughtWorks team over on Martin Fowler's blog.
Uh and the, you know, that it's a part of a series called the Patterns for Reducing Friction in AI assisted development.
And I I really love this term, this phrase context anchoring.
And, you know, partly because like I feel like we're in this era right now of AI where we're we're coming up with a lot of new terms to describe like phenomenon that that we're experiencing within this space.
And this is one of those terms that that I think is coming out of that.
Uh and I think it, but I I really think it's a great term to describe what what you and I, Andrew, have really been focusing on in recent weeks with our agents.
It's like the more that you can build that context behind everything, you know, we've we've been talking about context engineering for a while, but uh, this is sort of like a way to mature that practice.
And and I want to just like step back for a minute because um the article did call out a practice that I think is a very common anti-pattern.
Um, and that's when you do things like over-relying on like a long chat thread um with your GPTs.
Like it kind of that kind of illustrates like the challenge that context anchoring can help solve.
You know, and and on one hand, like I've always tended to work in a much more ephemeral way.
Like, you know, browser tabs to me, like I open them when I need them and I close them when I'm done.
They only exist as long as I need them.
Notes that I take are on like temporary notepads and then they're deleted after they serve their purpose.
Working documents are like forgotten once the the thing that I'm working on gets published out to the to the world.
And in a sense, that like that's made that's given me this really strong default approach to LLMs where I'm I'm always treating them as like these ephemeral workers.
Um and as a result, I've kind of avoided that anti-pattern I was describing where I would have these longstanding chat threads.
And and a big part of that was because I understood that if if you want to hand off a repeatable problem to AI, um, you need to keep it as constrained as possible uh to avoid model failure and like those long-running chat history type things.
But this practice breaks down when you need historical context for the model to perform well.
AI needs to know what was decided, why that decision was made, who are the people that were involved in making that decision, what additional context is out there behind, you know, like what sort of external constraints exist on this situation.
And so now, like, you know, I I still kind of like I treat GPTs ephemerally, but the context is uh, you know, I'm I'm recording and archiving context as much as possible now because everything is important for for helping AI to understand where I am, like not only the the problem set that I'm trying to solve, but but where I am and how I got to where I am at this moment.
So yeah, another just a great article from Thoughtworks.
Everyone should be following the work over there, and I'm I'm sure we'll continue to have awesome information from them to share.
Yeah, really well said.
Really great summary as well.
I it's funny you say that you've always worked in a more ephemeral way.
I actually find myself more gravitating towards the opposite.
I've always kind of worked in a very kind of accumulative way.
I think the future belongs to collectors, people who have been curating their own content and knowledge and archives of things.
Um maybe I just love to collect things in folders, but a lot of them are marked down.
And it's just been crazy how future-proof and future compatible that way of thinking was and still continues to be.
So if you're not somebody who is keeping a daily dot journal or is capturing uh things from every day that maybe would otherwise fleet out of your mind, like I would encourage you to do so.
It's an amazing mindfulness practice that benefits you and all of these other things that you're working on life.
Yeah, yeah.
You know, capturing transcripts into obsidian notes and having clawed co-work connected to that is is a wild experience, but uh it is it is immensely powerful.
Or if you just have a big list of coding challenges and a markdown folder that you just love to go back to every once in a while and revisit, that's just fine too.
Yeah, yeah.
All right.
Well, let's talk about some of the challenges that that are the come up when you when you don't have great AI practices, particularly around things like context anchoring anchoring.
Uh, and this article comes from Andrew Murphy.
It's titled, If you thought the speed of writing code was a problem, you have bigger problems.
So, you know, we've got engineering leaders all over the place out there that are rushing to deploy AI coding assistance, claiming all these increases to output.
And but you know, the reality is that a lot of them are really just like optimizing the wrong bottleneck.
A topic we've covered consistently here on Deb Interrupted is that you know, writing code isn't has never really been the constraint.
It it has sometimes been a bottleneck, but in in software delivery, it often is not the thing that slows it down.
Um, and if you you know you operate on the theory of constraints, you know, optimizing something that isn't the bottleneck is just going to make your existing bottlenecks bigger and have more problems build up.
So the real bottlenecks in most organizations is things like unclear uh requirements, you know, lengthy review and deployment processes.
We talk about code reviews frequently and how that is almost always or very frequently uh the most the biggest bottleneck in the typical software engineering organization.
Um beyond that, you know, fear-based cultures, organizational coordination, these are all things that can create bottlenecks uh within your teams and that get worse as you add AI on top of them.
So if you're as a team not mapping that entire SDLC and understanding where those constraints are and and you know, which portions of the cycle, the software cycles are the ones that are slowing you down, um, then AI is actually, you know, it it's an amplifier.
It's it's gonna make all of those bottlenecks, all of those problems worse rather than better.
So we love this article just because it's you know, just another expert out there agreeing with something that that we hear over and over again from from our community.
Uh so yeah, what did you think about this, Andrew?
Great summary.
There's not much more that I would I would call out that you didn't already cover, but in terms of the size of really the scope of this problem and how much we've been attacking on the show.
This is like a pervasive issue that I think every engineering team um is encountering right now.
And if it's lurking and you haven't identified it yet, it's really critical that you do.
The idea of having the AI rollout without tying it to the impact and understanding downstream effects of using these tools within your SDLC, uh, this really calls out how all of the other bottlenecks besides writing the code are what make that possible.
So you have to focus on the whole system, not just one part of it.
Really great, uh, really great article.
I also love that it called out um the reality that it becomes a horror show at 3x, the code output without hardening your other systems.
Um I think that's very much the case.
Everyone, I think at this point has been in a uh situation where like a deluge of something slammed into a wall, maybe a CI CD check or a flaky test that was not expected, and and you've probably had a meeting about it, right?
So having those kinds of uh clear requirements is is how we can avoid those problems.
Yeah, and I'm gonna make a shameless plug just because I can, you know.
Andrew and I, you both work for Linear B.
It's a company that helps engineering leaders solve these problems all the time.
So if you're listening to this and reading this article after this and feel like, man, this is really the experience that I'm going through right now.
Uh, you know, this is a problem that we help engineering leaders solve all the time.
So make sure you go check out Linear B, and we'll get back into the news.
All right, let's move on to the small web, which may actually be bigger than you think.
So the small web, what I'm referring to here are these like non-commercial personal websites that are free of like ads and tracking.
And you know, really what it is is going back to like the mid-90s when everyone is like building their own websites in raw HTML and CSS and and just doing it to share information with the world, you know.
And I remember back then, like uh an author of this article brings it up how people are just so idealistic.
It's like universities and non-profits will will be out there like populating the the web with knowledge, and to an extent that's true, but then you also look at the the the last 20 years or so of the web, and it's it's been more a history of consolidation, commercialization, uh near monopolistic and sometimes actual monopolistic behaviors in the market.
Uh so this art this author is uh highlighting a trend where that original view vision of the web is actually starting to trend back in a positive direction and start to come back.
So there's more of these websites showing up.
Uh and from my understanding, maybe you can correct me, Andrew, but I think this author is basing it on uh some sort of uh like library for building websites or that that uh is now proliferating across the web, and and you can use that to sort of track like the emergence of these websites.
That's right, but yes, it's check it's checking new profiles on Khaggy, I believe is what it was.
Yeah, like per a personal website repository.
Yeah, and and I and I feel like uh our our producer Adam added this because he he just knew I wouldn't be able to help myself but go into a nostalgic trip to to back to my early days of technology because you know it has me thinking back to like the very first website that I built, which was back, you know, in our local mom and pop ISP, they just had their like little building across the field from us.
Uh, you know, as a part of our monthly internet subscription, we had hosting space that they gave us, uh like literally hosted in our neighborhood, you know, which is pretty wild to think.
Uh so I you know, I built my own HTML CSS uh website, you know, of course, optimized for both Internet Explorer and Netscape.
Uh and I remember, you know, doing things like downloading game guides off of these websites from people just like me who just wanted to share something that they thought was cool, you know.
Uh so yeah, I I mean centralization tends to ebb and flow.
Uh maybe we are ebbing back towards decentralization, but what do you think, Andrew?
I I I love that very nostalgic trip back down memory lane.
I actually, too, I'll I had a local little ISV that also too came with a little bit of hosting.
But I originally learned to use a computer so that I could make websites.
And why did I want to make websites?
Because I saw these cool pictures and I wanted to do what?
Save them and collect them in folders.
And so I wanted to make websites so that I could put my my collection of images somewhere where people could see them.
Uh collecting context for your AI since you first started touching a computer.
That's wild.
On yeah, honestly, same year I was writing, I was on a computer.
It's computer's been part of my life my whole life.
But it's funny you say that Adam put this article in here, our producer for you, uh, because he actually definitely put this in here for me because uh I feel like I talk about this part of the internet all the time.
Uh is there's definitely a resurgence of the small web here.
Um, it's a reality called the post-naive internet.
You know, we previously existed an internet where we were all consolidating into massive platforms in the web 2.0 era, which then became apps on our phone, became these ubiquitous huge services.
But with the arrival of things like AI and you know, more invasive practices by these more monopolistic platforms, people are retreating with their personal data, with their time, with their attention, and most of all with their creativity back to the world of creating personal websites that speak to who they are.
And AI is making that easier than ever now for anybody to be able to make their own website.
And I think any developer, especially those who in their like earliest days of development, especially anywhere near the front-end world, probably your first project that you really wanted to do would make a really cool portfolio website for yourself.
And so the idea of having a spot on the web that you own is really universal to just being a participant on it.
I think.
And I say more the merrier.
I have a personal website.
I love growing my personal website and connecting with others.
And I maybe as these larger off-the-shelf experiences shrink or get replaced by something else, I think we'll find ourselves increasingly in a world where software is very customized and more utility-like.
You know, everything becomes a digital and consumption pricing based because all that compute is tokenized underneath because all your experiences are hyper-customized to you and exactly where you want them.
And so maybe instead of paying for a a C or a flat rate or a tier on some SaaS company somewhere, you might just find yourself turning on and off a bunch of really cool inference systems that you pull into your own website or you pull into your own shared space with your friends.
I think the the web is set up for any kind of future that we want it to be.
Yeah.
And to touch on your point uh about, you know, AI encouraging you to build more.
Uh I I do kind of feel like maybe we are on the cusp of a wave of decentralization within the web.
Like we've kind of discussed a little bit here about how it feels like it's probably never gonna be this free again.
Like the way you can just use it for a very low cost and do a huge range of tasks with it.
Um, I'm not sure that that that will continue and things may over time sort of get locked down.
But when you think about the fact that AI makes it so like basically anyone can write code now, or at least code that's good enough for a simple website, um, coupled with the fact that like hosting space for simple websites is incredibly cheap, uh sometimes free, uh, and it is quite plentiful.
And it's very simple to publish your own content to the web now.
So, you know, I could definitely see this creating some level of of like a renaissance for a uh for lack of a better phrase in terms of just digital creation.
And you know, personally, what I'm waiting for, like, let's bring back the free internet arcades.
Like, come on, like those are such a cool era within the the internet era, and like with AI, we should be able to do it so much better now.
Like, am I right, Andrew?
You know, there's a time and a place for it.
I I could see a really great arcade coming back and just really hitting.
I gotta say, every kid had that bookmarked folder of cool arcade websites.
I just think kids these days they just have that bookmarked folder of Roblox experiences and stuff.
Yeah, that's true.
That's true.
All right.
Well, let's close out with a topic that's near and dear to my heart, and that's sloppy pasta and how we're all gonna stop it.
So this article, it it highlights a an an emerging workplace adequate problem that the author refers to as sloppy pasta, where people forward raw AI-generated text without reading it or verifying it.
Uh creating an ace asymmetry where recipients have to do things like fact check and like distill information and and spend effort um understanding the information while the person who sent it spent basically no effort creating it.
Uh and ultimately, this is the kind of thing that erodes trust in the workplace.
Uh Andrew, what what do you think?
Are you have you been a victim or a perpetrator of sloppy pasta?
I certainly try not to be a perpetrator.
You know, as much of even like a huge proponent of voice at text and whisper flow that I am, I don't even really use it to talk to people in Slack.
I just use it for for code.
You know, I'm actually uh really, really diligent about the time that I put into messages I send to people and my emails.
You know, if you're listening to this, if you've ever received an email from me, you'll know that it has this certain flavor on unhinged, and those are all written by me.
And so uh yeah, I I definitely think that like uh I take a lot of care about the stuff I write.
So because of that, I do in some way kind of expect that from others, especially since we're a human-to-human interaction.
It doesn't ever really feel good to feel like you're just getting a copy paste out of someone's like chat GPT session.
Uh, I've definitely been on the receiving end of this.
And if you do it, the other folks and you don't think that they notice, I promise you that they do.
What about you, Ben?
Are you do you find yourself perpetratoring or being perpetrated?
Yeah, so so first of all, I'll explain there's there's a couple of categories of sloppy pasta perpetrators that are outlined here.
So the first is the eager beaver.
So that's somebody who who wants to contribute to the topic at hand.
Uh so they go and ask their chatbot and just share whatever that chatbot shares with them.
You know, the intention's good, not necessarily helpful.
Uh then the second category is the oracle.
Uh, and to be clear, I feel like I have at least seen all three of these.
Now I'll get into the one that I think that that I may be on occasion.
Uh so the oracle, this is someone who asks a question and then somebody else just takes that question and goes and pastes it into to their a AI and brings it back into the chat.
Uh sometimes this is valid though.
I will point out there are there have been times where I I kind of wish I had the um the AI version or the AI equivalent of let me Google that for you.
It's like you could have just taken that to chat GPT before you brought it to me, but but that's besides the point.
That's a different situation.
All right, and then the last category, which is the one that I think I do occasionally fall into, and that is the ghostwriter.
Uh, and this is where the sender shares AI output as their own work.
And but you know what?
And I've gotten this this feedback directly from you, Andrew.
You once told me this is this is uh I don't remember the exact words, but it was a like a two or three page document that was purely AI generated, and you're like, this is the best kind of AI slob, and I was like, of course it is.
Well, the the AI slob that you serve, Ben, is great.
It's just you know, maybe smells a little bit of AI, but you know, the ghostwriter thing, I will say, you know, I think everybody who worked does knowledge work stuff does the ghostwriting thing to an extent.
I read the ghostwriting thing, and it's like, oh, that's like uh oh, my like my agents do that, but it's and re are not like saying to other people, but produce artifacts just like this that are like my outputs, right?
So it's just more about like properly addressing where the content's coming from, set framing expectation, being like if this was AI generated or part of a workflow, I think it's helpful to disclose that a lot of times systems are implied to be that way now, though, so it just depends.
Uh I I definitely fall in the trap of perhaps being the eager beaver, but I will say that it's just really uh it speaks to the ability to have like instant finger uh tips on your the information that you need.
And so if you're a really eager beaver and you're not well attuned to what you're grabbing, then that is uh a very much a detriment to your team.
But if you're an eager beaver and able to spot and be calibrated to the right thing, the right information, the signal, you know, I I think that's less of an eager beaver and more of like a uh like a dog, right?
Like you're gonna go out like find what what needs to be found.
It's like a could be intentional.
So all of these have a positive side as well.
Yeah, and and there's some great tips in this article too that uh if you think you might be in one of those three categories, or you you want to help somebody who who is and you know, articulate how to get better.
Uh, there's some great tips.
Uh, there was a couple that resonated with me that I I have definitely incorporated into my daily work.
Um, and the for like first of all, your first pass of anything that comes out of AI, you should effectively like judiciously delete things out of it.
Like uh, you know, models like Claude in particular are incredibly verbose.
I found that like potentially like 20% of what it outputs just off the bat, just get rid of it.
It's not relevant, like it it it just went a little too far because it can.
Yeah, and you know, and that helps like distill like you're trying to distill down to like the important stuff and just get get rid of all this stuff that doesn't really add value.
Um, and then the second one that is I think it it's it's perhaps more critical than the first is you have to validate every single factual claim and then fix spots where AI missed context.
So sometimes AI will just get the facts wrong, um which you need to go validate and figure out.
Um sometimes it will add context to a fact that it it comes up with that the fact may be true, but the context is out of place.
There's a lot of assumptions that LLMs make that you know you just need to use your your human expertise to validate.
So and there are other tips in this article.
I I feel like the the problems that that these three categories of of perpetrator create, they're all solvable.
You know, it's just a matter of rigor in how you work.
I agree.
All right, Andrew, what are your agents up to this weekend?
Uh well, I guess they're gonna be uh trying to work between the rolling token out of this that are gonna be hitting the nation.
That's right.
Uh, but uh probably not probably not all too much, to be honest, because I find myself more and more the more capable that they get.
It's more again about the communication and the alignment for what we need at any given moment.
You know, I don't exist within a massive churning enterprise system, at least not right now.
And so I don't have this constant hunk like output demand from a huge array of tools and services that I manage or maintain.
Instead, all of the knowledge work I do requires a lot of thinking.
And so what I find is my agents free me up a lot of time to really get aligned on what exactly needs to get done.
And then when the coding happens, it's actually so surgically fast because my harness is so well tuned from everything that I learned here from our experts on the show that I actually don't spend too much time there at all.
But what about you, Ben?
So I I just got a new laptop, which has been it's been fun setting it up in the the like agent first era, you know.
Most work every day, like I'm starting with working with my agents first.
Like it's like what do I have to build with my agents to solve the things that I've put on my to-do list today?
Uh and it's a it's a it's a pretty wild way to work.
You know, I'll I'll answer one better.
It's not that my agents will be making anything.
I will be spending a lot of time creating the right environment for my agents to know what to do.
All of the agents and and and what they need to do are effectively pretty efficient for me.
But what I spend a lot of time doing now is curating their environment, making sure the right information's available, the right tools are at their fingertips, and they can communicate with the right other agents and becomes like a whole other practice.
It's almost like tending a garden, you know?
Very much feels like everyone for joining us for this segment of the the Friday deploy.
Uh give us a rating on wherever you're listening to us right now, a thumbs up, you know, anything you can do to just helps us in drive engagement and get get our reach out there.
So thanks for joining us this week, and thanks, Andrew, and we'll see you next week.
See you next time.
AI is everywhere in software engineering, but most teams still can't prove its impact.
That's where the Apex framework comes in.
Apex is a new operating model for engineering productivity, designed to measure AI where it actually matters at the pull request level.
It connects AI activity to delivery outcomes, not just tool usage.
Apex is built on four pillars with AI leverage, predictability, efficiency, and developer experience.
Apex helps you increase throughput without sacrificing delivery confidence or burning out your team.
Because speed without predictability creates chaos, and faster coding often shifts bottlenecks downstream.
If you want to operationalize AI the right way, linear B and Apex gives you the system and the cadence to do it.
Download the guide and start measuring what matters.