Sloppypasta culprits, unpacking MCP’s spotlight, and Anthropic wants your agents to work the graveyard shift

0:05Andrew:Andrew, are you taking advantage of Claude's recommendation to start working nights and weekends now? What do you mean, Ben? You haven't gotten the notification yet. And when you sign in, it's like, hey, we'll give you more tokens if you work late at night because it's cheaper for us.

0:22Ben:Oh, yes. If you distribute your workloads, the time is when not everyone is rushing to slam GitHub with their pull requests. It's 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 going to be, is it going to fall over today? It's like every week now, I'm like betting on my repositories.

0:42Andrew: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 work week before like things sort of flatline, you know.

0:54Ben:It makes me think of like a very kind of apocalyptic future where there's like rolling token blackouts where you're in like a token blackout because the consumptions 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.

1:15Andrew: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 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 bank of tokens when token costs are high.

1:34Ben:Okay, well, somebody get Ben a solar farm and let him get cooking because that sounds fascinating. But it would be just to just get more tokens in general. So I love Claude's idea of distributing folks around. I would just wonder 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 probably always running slash you could just have them run later.

1:56Andrew:So, yeah, what 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 Ziegler. 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 adequate guide. So let's just start at the top with MCP. Andrew, is MCP dead?

2:26Ben: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. I don't know if this was directed at me. I'm just kidding. But 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.

2:59Andrew:And you know why 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.

3:08Ben:Clearly a dev-interrupted reader, clearly disgruntled by our effusive coverage of MCP. And you know what, I don't blame them 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, models were a lot dumber. Their ability to use tools was not as great 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.

3:48Ben:And the benefits of this are numerous and lots of folks talk about them.

3:53Andrew:But what this article calls out is why was MCP in the spotlight in the first place?

3:57Ben:I think it's a great reminder that, you know, we're in a growing pain. We're going to be 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.

4:12Andrew:Yeah. And I want to point out that I kind of thought it was obvious that CLIs are like more of a crutch for AI agents than they are like 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 you're going to have an agent do work, it's going to 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 i would 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 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 mcp-ing 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 but the reality is that there's really like more situations where mcp shouldn't be used and there are actually situations where it should be used it's not like this one size fits all agent connector thing so 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.

5:34Ben: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 widely used API in the hands of a lot of people really quickly and consistently. And while CLIs can certainly be applied in the same way, just MCPs are more portable 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? Yes, so this is an article from ThoughtWorks. 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?

6:21Ben:Would it be disrupting to my work if this chat were to end? And most developers, once they get into 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. 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've had Dexter Orzee on the show have called out rightly that around 50 % it really drops off a cliff.

7:04Ben: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, 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. There's lots of different tools for doing this, but I got to say, this article comes at a really fascinating time when Opus 4.6 is just right now reaching its 1 million context window.

7:46Ben: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 do you think about this article?

8:01Andrew: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. And it's a part of a series called the Patterns for Reducing Friction in AI-Assisted Development. And I really love this term, this phrase context anchoring. And partly because I feel like we're in this era right now of AI where we're coming up with a lot of new terms to describe like phenomenon that we're experiencing within this space. And this is one of those terms that I think is coming out of that. But I really think it's a great term to describe what you and I, Andrew, have really been focusing on in recent weeks with our agents.

8:41Andrew:It's like the more that you can build that context behind everything. We've been talking about context engineering for a while, a little bit. This is sort of like a way to mature that practice. And I want to just like step back for a minute because the article did call out a practice that I think is a very common anti-pattern. And that's when you do things like over-relying on like a long chat thread with your GPTs. Like it kind of illustrates like the challenge that context anchoring can help solve, you know. And on one hand, like I've always tended to work in a much more ephemeral way, like, you know, Browser tabs to me, I open them when I need them and I close them when I'm done.

9:23Andrew:They only exist as long as I need them. Notes that I take are on temporary notepads and then they're deleted after they serve their purpose. Working documents are forgotten once the thing that I'm working on gets published out to the world. And in a sense, that's given me this really strong default approach to LLMs where I'm always treating them as these ephemeral workers. and as a result I've kind of avoided that anti-pattern I was describing where I would have these long-standing chat threads and a big part of that was because I understood that if you want to hand off a repeatable problem to AI you need to keep it as constrained as possible 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.

10:14Andrew: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 the situation. And so now, like, you know, I still kind of like I treat GPTs ephemerally, but the context is, you know, I'm recording and archiving context as much as possible now, because everything is important for helping AI to understand where I am, like not only the problem set that I'm trying to solve, but where I am and how I got to where I am at this moment. So yeah, another just a great article from ThoughtWorks.

10:54Andrew:Everyone should be following the work over there, and I'm sure we'll continue to have awesome information from them to share.

11:00Ben:Yeah, really well said. Really great summary as well. 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. 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 things from every day that maybe would otherwise fleet out of your mind, like I would encourage you to do so.

11:44Ben:It's an amazing mindfulness practice that benefits you and all of these other things that you're working on life. Yeah.

11:51Andrew:Yeah. You know, capturing transcripts into Obsidian notes and having Claude Cowork connected to that is a wild experience, but it is immensely powerful.

12:00Ben: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

12:08Andrew:yeah all right well let's talk about some of the challenges that that that come up when you when you don't have great ai practices particularly around things like context angering anchoring and this article comes from andrew murphy it's titled if you thought the speed of writing code was your 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 assistants, claiming all these increases to output. But the reality is that a lot of them are really just optimizing the wrong bottleneck. A topic we've covered consistently here on Dev Interrupted is that writing code has never really been the constraint.

12:47Andrew:It has sometimes been a bottleneck, but in software delivery, it often is not the thing that slows it down. And if you operate on the theory of constraints, 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 requirements, you know, lengthy review and deployment processes. We talk about code reviews frequently and how that is almost always or very frequently the most, the biggest bottleneck in the typical software engineering organization. Beyond that, you know, fear-based cultures, organizational coordination, these are all things that can create bottlenecks within your teams and that get worse as you add AI on top of them.

13:37Andrew:So if you're, as a team, not mapping that entire SDLC and understanding where those constraints are and, you know, which portions of the cycle, the software cycles are the ones that are slowing you down, then AI is actually, you know, It's an amplifier. It's going to make all of those bottlenecks, all of those problems worse rather than better. So we love this article just because it's just another expert out there agreeing with something that we hear over and over again from our community. So, yeah, what do you think about this, Andrew?

14:09Ben:Great summary. There's not much more that 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 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 of using these tools within your sdlc 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 um 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 situation where like a deluge of something slammed into a wall maybe a cicd check or a flaky test that was not expected.

15:12Ben:And you've probably had a meeting about it, right? So having those kinds of clear requirements is how we can avoid those problems. Yeah, and I'm going to make a shameless plug

15:22Andrew: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. All right, 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.

15:59Andrew: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 an author of this article brings it up how people are just so idealistic. It's like universities and nonprofits will be out there, like populating the web with knowledge. And to an extent that's true, but then you also look at the, the last 20 years or so of the web and it's, it's been more a history of consolidation, commercialization, near monopolistic, and sometimes actual monopolistic behaviors in the market.

16:40Andrew:So this author is highlighting a trend where that original 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. 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 is now proliferating across the web and you can use that to sort of track like the emergence of these websites that's right yeah it's checking it's checking new profiles on kagi i believe

17:13Ben:that's what it was yeah yeah like a personal website repository yeah and and i and i feel

17:19Andrew:like uh our producer adam added this because he just knew i wouldn't be able to help myself but go into a nostalgic trip 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, on our local mom and pop ISP. They just had their like little building across the field from us. You know, as a part of our monthly internet subscription, we had hosting space that they gave us, like literally hosted in our neighborhood, you know, which is pretty wild to think. So I, you know, I built my own HTML, CSS, uh, website, you know, of course optimized for both internet Explorer and Netscape.

17:55Andrew: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?

18:13Ben:I love that very nostalgic trip back down memory lane. I actually too, I'll, I had a local little ISP 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 collection of images somewhere where people could see them.

18:40Andrew:You've been collecting context for your AI since you first started touching a computer. That's