Coding agents, context management, Q&A

Key Takeaways

All right, good morning, good afternoon, good evening. Happy 2026. Uh, it's great to be through the holidays. What a wonderful time. Hope you all had some good time to rest and recover, spend time with family or work on side projects, you know, whatever you're into. I wanted to do a stream and talk about what has been on the X Hivemind, the X Zeitgeist lately. And here are some of the things that I think would be very fun to talk through. Um, a lot of people were working on coding agents and related topics over the past couple weeks. Um, there's been some conversations around longunning agents apparently related to the Simpsons. So, we're going to find out about that. Um, I want to talk a little bit about the difference in context management around dynamic and static context. And then I posted a tweet yesterday asking if you had any questions because I was going to go live today. So I'm going to try to make my way through some of those and then also answer questions in the chat live here as we get into things. So before we actually dive into break one for those who are tuning in live, let me know where you're at right now in the world and I'm going to actually tweet that we are live and then we can get started. The weather's kind of gloomy here today, honestly, but that's fine. I'm uh I'm enjoying it still. Okay. Oh, interesting. It didn't change my uh it didn't change my stream title. Let's see if I can get Reream to to change that. People are going to think we're talking about something else. We already talked about how to use cursor with no coding experience. By the way, if you haven't seen that one, you should go check it out. U kind of gave an overview of how to use cursor even if you're not a developer, which will hopefully be interesting. Um so let's see. I'm going to do a tweet that we're live and we can kind of get into this thing and Okay. I actually don't know how to update the broadcast. Oh, I might have to do it manually. Tisk. Tisk. I uh when you when you cross stream on multiple things, it kind of the UI is a little janky honestly. Like sometimes if the titles don't propagate over to other platforms, so I cross stream on X, on LinkedIn, on Twitch, on YouTube, sometimes it gets really funky, which is like kind of annoying, but it's fine. It's it's I think worth the additional benefit to be able to post the same content wherever people want to tune in from because people like to do it in a bunch of different places and yeah, it doesn't make sense to to not do that. So, let me make sure YouTube's live, then we'll get going. Let's see. Where are people tuning in from? The Netherlands, Ireland. Okay, nice. Use Streamyard. Yeah, you know, Streamyard it's okay. I still kind of like OBS to be honest. Um Streamyard is nice if I want to invite guest on I find. But um >> yeah, I don't know. I I'm curious if there's other other things that you all have used. Stream was it's okay. It's not my favorite, I guess. Okay, I think we're good to go. Nice. I don't know why it won't let me scroll that. That's fine. Okay. Hello from Michigan. Nice. Because it was not written in cursor. Nice. Okay. First topic. I want to talk about the current exed zeitgeist. Kind of my interpretation of how people are feeling right now. And maybe you relate, maybe you don't relate. I'll start with uh Kpathy's tweet which you may or may not have seen it where he basically says I have never felt this much behind as a programmer. The profession is being dramatically refactored as the bits contributed by the programmer are increasingly sparse in between and goes on and on to say that there is a new way of working that he is still kind of figuring out. And I feel like this sent a lot of people [laughter] uh into a state of, oh shoot, I really need to figure out what this means so that I don't fall behind, which is kind of what he mentioned towards the end. Roll up your sleeves to not fall behind. Um, and it's interesting because I think a lot of people had been feeling this way. So for someone like Kpopathy to come out and say he was also feeling this way, I think especially him being a a great engineer and a great educator had a lot of people questioning or or having some some doubt, some imposttor syndrome maybe. I know I was feeling that too. So I'd like to talk about it. I think it's pretty interesting. I made a quick video um about how I feel like software is changing in 2026. And really what I was getting at in the video was that in a world where code can be generated pretty easily, the profession of software engineering is shifting quite a bit. And some of the questions I got in response to my post and in asking y'all what questions you had is what does this mean for the job market? What does this mean for those who are learning how to code right now? Should you still learn software engineering? Is it still a good profession? And I feel like in the current state of the tools, they definitely benefit those who have more experience. I think that for experienced programmers, they're getting a lot out of using these tools to multiply their workflows, sometimes quite literally, by running multiple coding agents. It's a little more difficult for those getting started, but I don't think it needs to be bleak. I think it is part of a perception and a mind shift change. I personally do not subscribe to the view that in a world where you have very powerful coding agents for some reason there's just not a need for a software engineer. I think if history has shown anything not only in our field but in other fields that the role will shift and it will evolve and the the way we work will change but there I think will be more demand than ever for creating software and doing it in a way that creates quality software. So if I was a junior engineer, if I was on the job market, if I was wanting to land a dev job right now, in some ways, and again, this is kind of a a mind shift change. In some ways, you have the best resources available that have ever been available for anyone learning how to become a software engineer. Like back, you know, back in my day, I walked up to the hill to school both ways. No, but seriously, it was a lot harder to ask people for advice, to ask people for feedback, to critique your code. Like, you have to sit down and do pair programming with more experienced engineers. You would post something online and like sometimes you would get feedback, other times it wouldn't. You had to spend all these years in industry getting experience so you could understand what great code looked like or you would just build a lot of stuff yourself. And I do feel like if you have the willingness to accept that there is this journey of not being good at something and then growing and being proficient at something, it's going to suck at first. Like you're not going to feel like you're good at what you're doing. And then you see people online who are magnified by AI and are doing amazing things. I totally empathize and can understand that feeling because it feels then like the gap is even bigger. If you go into it with this perception and this mind shift that I can do those things, I can do hard things, I can learn how to use these tools, and in fact, because I don't have years and years and years of experience of outdated patterns that actually aren't relevant anymore, I have the opportunity to go further and faster than those who have came before me. And I think if you have that mentality, I think you will do very well. I've seen plenty of late teens, early 20s people using AI right now who are just insanely talented. So, I feel like there's a lot of opportunity here, but I will not try to sugarcoat that. It is difficult. It is difficult to adjust to a new world where the thing that they're teaching you in school is a little bit or university is like a little bit decoupled from what people are doing in industry and the the real world. I think in some extent it's always been like that but it was the time scale was different. It's very compressed now where there it feels like what you're doing in school unless you're um on one of the bleeding edge places is pretty far removed from like the the bleeding edge of coding with AI. So hopefully with that mind shift said hopefully with that mind shift I hope those who are getting started will be excited by the opportunity. I want to see more software engineers in the world. I want to see more beautiful software. I want to see I mean, think about it. How much crap software do you use every single day? Like, sorry, airline websites. I'm sure there's maybe some of you listening who are trying to make this better, but oh my goodness, they're so bad. Most of them are terrible. Bank websites, not very good. I hope that the rise of AI will help make all of those products better. And that to me is like the true test of if this stuff is actually working. It's not building a CRUD app, even though I love a good CRUD app and as DH8 says, there's a lot of CRUD apps in the world. I just want to see better software exist in the entire world, in every pocket of the economy. Uh, and even government sites, to Jeremy's comment, um, there have there have been a somewhat of a renaissance here with the uh, what's it called? the the United States Office of Design or whatever the thing that Joe Gbby is doing from Airbnb. Um like they're National Design Agency, I think it is. Um I think they're doing a better job and I would like to see that uh trend continue. Um well-designed websites with great UX that function great. Um that's the world that I want to live in. The product comment in here, the product isn't bad because of coding expertise. the process is borked. Yeah, I do feel like the biggest shift here is actually the process of how software is generated. And kind of going back to the video I made, I had a couple messages from people. This this view is kind of trippy, by the way. It's like I'm looking at myself. Uh I had a couple people message me about this and they they pushed back in very nice ways. And they said, "Hey, I like what you were saying. However, I think you missed a few points. And the points that they thought I missed, which I thought were good, is I made a comment that was something along the lines of software is no longer the bottleneck. What I really mean with that is code is no longer the bottleneck in so far as it is going to be easier to create code. That does not mean, however, that code is inherently free. And I think I said something where the cost of code is free. I would like to slightly revise that which is even if you generate a lot of code outside of green field applications aka most of the software that exists in the world. There is a cost to the maintenance of that code there is a cost to the process of developing that code and making that code better and gardening that code and making the software better. And to the comment in the chat um from uh Kanosama the process is borked. So even in a world where you can very quickly generate a lot of code that doesn't actually fix the root process of how great software is developed. So to their point there are a lot of people maybe some of you in the chat who work at companies where the process is borked. You work at companies where you see a lot of innovation happening with AI but it kind of hasn't hit your company. It hasn't really affected the way that you're developing software. It's more of like sprinkling AI on top of the existing stuff, but it's still mostly the same process of how agile software was developed. And I think that's going to be the biggest transformation is how do we as an industry figure out how to change the process and this is a company thing. It's not necessar necessarily an individual engineer thing. If you if you look at the most bleeding edge people are, you know, vibe coding on a VPS and deploying their website live from the VPS running like a terminal like 2e coding agent like companies are probably not going to do that. Maybe in like a couple years maybe, but there's a reason all of those checks and balances are in place and many layers of process which doesn't always have to be a bad thing are in place. And I think that's going to be the big thing to figure out. So to uh the question on LinkedIn, the top tips for entering the job market right now, I feel like I would try to stand out by building interesting things. The hard thing is that because the cost of because it's easier than ever to create things, there are more people who are creating things. So you have to differentiate on quality. You have to differentiate on the amount of effort that you put into the polish. If anybody can generate a resume site that is their resume, but it's just a website. That isn't enough to actually cut through the noise when just like you can use AI to help you expedite the process of building, people are also using expedite the process of applying to tons and tons of jobs. So to stand out, you really need to focus on what good looks like to you, which is different from everyone. You know, you have a view of what you want to exist in the world. Everyone's going to have different tastes that influence their own quality bar. You need to produce and create more of what you want to exist in the world. Instead of scrolling X, even though some of you are here from X right now, so you can stay for a little longer, it's fine. instead of scrolling extra for three hours a day, maybe only scroll for 30 minutes and replace another of the 30 minutes with trying to build something. So, there has to be a healthy balance. I'm a I'm a big fan of consuming content. I like to watch content. You know, I'm not going to I I also use X and YouTube at all socials all the time. So, you know, guilty is charged. However, there is a balance to be had between consuming and creating. and my equilibrium feels off when I am doing too much consumption and not enough creation. That's how I think about it. Yeah. Instead of scrolling X, which you're on right now. There's you need to have space for both. I think going back uh to this whole narrative around software is changing. Another thing that is really interesting is uh this thing called Gas Town. And [laughter] this tweet honestly made me laugh extremely hard. Uh it's it's like a copy paste template format. It's like, "Oh, you're still using cloud code. We're orchestrating agents with beads." Now, you're probably like, "What the heck is beads?" Wait, we just shipped Gas Town. It's like Kubernetes for coding agents. Just kidding. We put Ralph Wiggum in a foral loop. We gave him a phone number and a bank account and asked him to autonomously make a million dollars. So he set up a daycare in Minneapolis. This is like cuts deep on current events. We got everything here. We [laughter] we we sshed into Ralph sandbox from Terminus with tail scale and t-mucks so I could code while pooping. But we hit our limit on the 10th cloud code max plan. So we forked droid structured capaction then stole amps and [laughter] reading this out loud makes me realize how ridiculous it is. [laughter] But it's so funny. We needed a guey for browser use. So we added open code with playrite and reverse engineered cloud code over Christmas. So it [laughter] so it would work with remote browsers. And now it deterministically solves capture from tweet. So Ralph is sending hinge messages for me. It's This is like the best tweet because it's absolutely insane. And it's also like this is what X has been like for the last three weeks. Uh if you're on the, you know, if you're in the Xhive mind, you've been seeing this stuff. You're like, "Wait, what the he like what is Gas Town? [laughter] That sounds like a Call of Duty map. It's not Nuke Town. It's Gas Town." Well, anyways, let's talk about what that is because I think it's kind of interesting. There's kind of been this progression I think of people who maybe just to to spell it out a little bit before any gas town they started with AI assistants. So the co-pilots the cursor tabs of the world you know they were getting assistance while writing most code by hand hand then a lot of those people then moved to primarily talking to a chatbased agent so chat GPT but also then when the the agent got embedded in the actual IDE so in the cursors or the wind surfs or whatever agents of the world um the the kind of full editor view you could not have to go look up docs or not have to go to Stack Overflow. That was like the next progression. Then the third progression was could we just use coding agents only? And what would it look like if we did most of our coding through coding agents? And for some percentage of the population, for some amount of engineers, this approach has worked very well where they can just prompt and just ask for things and they're really not writing code by hand as much anymore. It's not everyone. Going back to my initial monologue about the amount of software being built in the universe, there's a lot and a lot of that is the process, but I think there's something to be said for for looking at how the power users are building things and then working backwards for what that means. So power users, you have all these people running like 20 cloud codes or 20 codeexes or 20 cursor CLIs uh in like 20 different windows or Droid or Open Code or uh AMP or there's so many I just forget about all of them. There's a lot of terminal UI coding agents and the idea was we can parallelize our work across multiple different things and that will hopefully speed us up. What Gas Town is trying to do is like if you live in that world for long enough, you're going to realize that the bottleneck is orchestrating different agents. So, you might have seen people who effectively create these sub agents that have different personalities or different personas. So, I'll actually just take this um I'll open up this post. Welcome to Gas Town. Gas Town is a new take on the IDE, which by the way, IDE is kind of an antiquated term. Like when I think of an IDE, you have a way to view and edit files. You have an agent. You have git or source control or some way to review changes. You have good code search. Like I guess that's an IDE. Um the agent part is increasingly important, but to me that's what IDE means. It's less about like debuggers. I think um I think it's still important but not as important. Gas help gas town helps you with the tedium of running lots of cloud code instances. Stuff gets lost, etc., etc. Cloud code can mean any CLI based coding agent. Oh, here's a couple others I forgot. Amazon Q developer CLI. Um, so what he built was an agent orchestrator on top of that. It's opinionated much like Kubernetes or temporal both of which they resemble. Uh, I will save you the depth of reading this post because it's very long and it's very hilariously worded. Um, I think this diagram pretty much sums it up. like what I was talking about in the top left was where a lot of people started and then eventually they the agent took over more and more of their IDE and then they got into this world where they're trying to run multiple coding agents in parallel and depending on who you are you might think that the future looks like this agent orchestrator thing um and I think there's something here I don't know that anybody has figured out the right UI or the product experience around this so I definitely welcome the more ideas and more attempts to build out what this new thing could look like. And it seems like some people are really liking it so far. Like he said, it's super opinionated. You probably shouldn't try it, but I'm glad to see there's more people trying things. The trend though is extremely longunning agents. And I took some of the screenshots of things that you all sent me in the questions that you had. And this was a topic that was all over X in the last couple weeks. I saw Dex was in the chat uh a little bit earlier. He might have tuned out, but uh I have his tweet in here as well. This has been going on probably for 6 months for those who have been really on the bleeding edge of coding agents. Uh and there's been some conference talks. Um Dex has this post on the human layer website that kind of covers the history of all of these things which we can step through if you want. But the idea, the general idea is if agents are good and they're getting better, what happens if they go from reliably being able to edit a single file or a couple files to modifying the entire codebase? And what if that takes a significantly longer amount of time? What if that runs all night? Can you wake up and can you come back and can it actually be good? six months ago. Some of the early experience uh the early experiments to this were through uh what Jeff was doing here with Ralph Wigum, which is hilariously named after the uh the Simpsons character. And this had been around for some time. The early experiments didn't really work super well where if you let it cook for too long, the agent would just go put a bunch of garbage in your workspace actually. But the idea has actually started to now materialize as the models have had a capability jump. The models are now better at running at running longer and modifying more files at once. And when that happens, now this idea is actually interesting again in a way that's more broadly accessible than what I think people were doing a little bit in the userland power user kind of hacking space. So there were two questions around this longunning agents and Ralph Wigum and actually um there were some folks in the the cursor community who have already built some plugins to cursor or to other um coding agents for how to do this. There's an official um enthropic Ralph Wiggum plugin and I think codeex has one too. Generally the idea here is basically a couple things. All of the coding agents pretty much have hooks that allow you to deterministically trigger some event when the agent finishes doing something. And the hook that cursor and cloud code and others use is like a stop hook. Basically, when the agent stops running, the hook can call out to some script. That script is going to check and see if the work is actually done. If it's not, it's going to tell it to keep going. Like you've probably had this experience where you ask an agent to do something very ambitious and then it just doesn't do it all. It gets lazy. It only runs for, you know, a certain amount of time. What this extremely longunning agent approach is trying to do right now is when we're in this period where the models are getting really good, the harnesses are trying to incorporate some of these ideas, there's three primitives. There's the plan that you provide up front. There's a scratch pad. And then there's the loop. So with a plan, obviously the more context that you provide up front, the better the agent is going to do at completing a very ambitious task. I've been doing this quite a bit in building some of recent projects where I was doing everything with coding agents. really spent a lot of time trying to take the plan and make it as good as possible and critically making sure the plan had verifiable outputs. This is the key to extremely long running agents. The agent has to be able to fix its own problems and know that it's hit the goal that you've defined. This is things why why things like types and tests and lints are super effective and clearly stating what the goal is. So even if you have a plan, what you need is you want the agent to run for multiple turns. And ideally, as models and harnesses get better at selfsumarizing or compacting, they can go for longer and longer. But even the best models and the best harnesses right now get to a spot where they stop and they don't go any further. And what this approach does is when it stops, it triggers a hook. When that hook gets triggered, it checks what's been wrote to the scratch pad. So initial plan and then the scratch pad is like the working memory that's outside of just one context window. So you can think of one context window like RAM, but then when you self-summarize or compact, you're clearing the RAM. The scratchpad is a way of persisting that. It's just a markdown doc. Persisting that outside of just one agent conversation and that just loops forever and ever and ever and ever until you hit your goal. Conceptually pretty simple actually. Um, and this is the type of stuff that will happen in userland that eventually then the models and the harnesses will kind of just do this stuff by default in spirit of you want to run an agent for a very long time to do very ambitious things and hopefully it needs to be have it have a way to be able to verify that the code works as expected. And uh yeah, interesting comment. Like agent orchestrators are kind of like conbons in in some ways. Like if you have a conbon board, you have your to-do task on the left and you just drag them over to the right. I mean, it's kind of like putting this item in practice except instead of having somebody on your team actually go have to pick it up. It's just kind of being kicked off in the background. Um so that's really this whole conversation around extremely longunning agents. A lot of these ideas can be published now as skills. And a skill is just just like you've probably heard of agents.md or rules where you can give instructions that are always included to models. Skills are a way of doing that dynamically, which is what I'll talk about next. But I think this is pretty interesting. I think we'll see a lot more people experimenting with this idea. And at least for right now, still kind of hacky. you know, you're running bash scripts, you're you're extending the agent loops, but I think over time the product experience here will get much better and it will be much easier for people to run agents for, you know, a significantly long amount of time. So that's that. The next thing I want to talk about, dynamic context discovery. So this is something that's really interesting. We have a blog post that we're going to uh ship on this soon, but I want to first talk about uh a few things and then we'll get into the blog post and explain it. So, if you haven't seen skills, um skills are a directory. They are just code. They have a prompt or some instructions. You can include executables. So, any scripts could be anything you want. You can include docs. You can include assets. It is a way of packaging up context that you want to give to a coding agent in a way that is much more extensible than just a markdown file or just text. I mean, if you think about it, this is basically MPM packages for coding agents, which makes sense, right? You're going to want to extend the coding agent loop with additional things. MCPS are useful in some ways. Rules are useful in some ways. I think skills are not necessarily a replacement for all of those things, but they are a pretty good option for a lot of things. So, this is a open standard now that's being created and adopted by pretty much everybody. Like everyone's kind of decided, okay, we're going to align on using skills. Um, and I think that's pretty good. I'm excited to see what this looks like. So, skills is interesting. Specifically, there are some things that were previously modeled as UI that you might be able to model as a skill. So, in cursor, we have debug mode, for example. And I thought this was pretty interesting, which is that if you wanted to, you can use debug mode as a skill. And we've even talked a little bit like maybe this should just be a skill. I'm not really sure yet. There are some nicities that we get through the UI and discoverability and additional features, but the core agent loop of starting a log server, instrumenting the code, reading the log file, fixing it, generating hypotheses, like you can do this with any coding agent. So, I kind of like the idea of where this is headed. And it's kind of prompted me to think um a bit more about what it would look like for skills to be uh more broadly adopted in the cursor ecosystem. I think there's still people are still kind of getting used to skills and trying to figure out what to do with it. But the key thing behind skills in my opinion is that you could install 100 skills and unlike a naive implementation of MCP, it will not bloat your context window which is really really important and that's kind of the key thing that I think would be interesting to talk about here which is this thing I've been talk I've been describing as dynamic context discovery. So, I've got this blog that uh we've been working on which will hopefully go out today or or tomorrow. Um I'm not sure exactly when, but I think it would be pretty interesting to read through this and I think it answers some of these points around the difference between static and dynamic context. And there's actually a parallel here I think to those who are experienced with web development. There's some parallels actually to static and dynamic rendering that I think about. So, I'll try and make that parallel, too. But I'm curious what you all think. Um, I think we should read through this and see uh see what we think. Has anybody used skills in the chat? Let me know if you have. So, I'll start at the top. Coding agents are quickly changing how software is being built. This comes from better models, but also better context engineering to skill them. So, what you're doing in the harness, basically. um cursors harness. So the instructions and the tools that we're providing to the model, we try to optimize this for every single new model that comes out. So whether it's a GPT model or a claude model or an XAI model or a Gemini model or whatever model comes out, we are trying to make the harness and the instructions and the tools tuned as best as possible to that specific model based on our experience working with you know many different um agent providers and agent models. We can also give the models new tools in this environment which I think is pretty interesting. Um however there are context engineering improvements we can make that uh in terms of how we gather context and optimize token usage that apply to all models. So as models are getting better at agents uh we found success by providing fewer details up front and making it easier for the agent to pull relevant context on its own. We're calling this pattern dynamic context discovery in contrast to static context which is always included. So, to answer Chris's question, uh, in the, uh, on the nightly channel of Cursor, you can start using skills. We're rolling this out here in the coming weeks. Um, just been trying to make sure everything is all buttoned up. Um, but yeah, Jordan, uh, if skills are new to you, I think that this post will hopefully, um, talk through some of the reasons why I think why skills are really interesting. Uh, and Nick, the only skills I've used are my own. Yeah, I feel that. Okay. Um, the core kind of thesis of how we've been making the agent harness better inside of cursor, let me just hide this. Um, is that we've been using the file system, which sounds kind of silly, but it actually works really well. So, by dynamically discovering context, which we're going to talk through with skills and what we're doing with MCP, it's way more token efficient because you're only pulling in the necessary data versus static context, which is something like the system prompt or your user message or an agents.md file that's included in every single conversation that's static that has a that has a fixed cost on the context window. So ideally you want to install a bunch of capabilities to your agent. You want to help the agent be better at front end, at backend, at deploying your app, at working with your database. But if all of those things are are giving a cost to the context window, then people are going to be less likely to add those into their agent setups, which is why some people have been kind of stingy about their MCP server usage. So here's some of the things we've been doing on the research and engineering side to make this practical inside of cursor. The first one is that long tool responses get turned into files. So if you think about a tool response like a third-party tool, so calling a shell command or an MCP server, if you call a shell command that like reads or tails a file and it's a massive file, um it could read the entire file instead of just tailing it. Let's say it reads the entire file. That's going to bloat the context in a large way. it's going to return all this information when maybe you didn't actually need all of that stuff anyway. So, what happens today is there's kind of heristics inside of coding agents where they decide, okay, let's just truncate this um because it's too long and we don't want to use up 100% of the context window. The problem is how [snorts] does the coding agent know whether it included the right stuff? So, when you do this, it can lead to data loss, which is not great. Um, what we've done to make this better is instead we're writing the output to a file and then we give the agent the option to read that file. Sounds really simple simple idea but it actually works very well which is that it has this bucket of output of context it can read from if it wants to and then we tell it hey you can just check the end of the file with tail and then if you want you can read more as needed. So, if you prompt like, hey, you know, where was that key that I asked about? You know, there was maybe some key that I wanted to use in a an array or in a dictionary and I needed to go look that up in my chat history. Um, you can do that by just asking the agent and it goes and reads the file. This has helped a lot in just preventing the agent from accidentally compacting or summarizing because you had some super long file. Very related to that is the actual process of summarization which is actually very tricky to do this well. Um there's a delicate balance of you want to give the models as much context as possible like you want them to know about your codebase, you want them to be very intelligent, but also it is very annoying as you get closer to the context limits. The quality of the model will decrease and summarization is a lossy compression. So you're going to lose some things. How do you decide what's the most important to include in that? Again, kind of like truncating tool responses. If you do this lossy compression and you lose really important stuff, that's really frustrating. So what we've been doing in cursor is instead the chat history gets saved as a file and then once the context window is reached or you manually type slummarize or slashcompact in the agent chat we give the agent a reference to the file s same idea reference to the file then the agent knows it has this whole chat history which it can go mention you aren't only operating from the lossy compression of the chat summarization of the compaction Um, this is very powerful. This has very much improved the ability to have a high quality conversation over many, uh, sum self summarizations or on demand summarizations in a chat. So, that's a big one. The third one, uh, skills. I know Jordan and Chris were asking about skills. So the big thing with skills is that you can not only provide instructions, so markdown files. You can also give it dynamic executable things, scripts or assets or other things and you can package those together and you can tell the agent how to perform well on some domain specific task. So maybe you have a front-end skill, you're helping the agent be better at front end. that one you don't necessarily need as much executables or scripts, but the debug mode script uh or the debug mode skill for example is a good example of one where you needed ex uh executable code to actually make that work well. So the way it works is you give the agent a name and a description of the skill and that gets included in the static context. It's the the agent always knows basically the list of skills, but it doesn't have to include all of the skills. It's able to go dynamically discover and pull in the skills as needed. And this is really helpful if you start to build pretty complex skills. I've seen a few people now building this for kind of internal context in their codebase or in their organization, which is very similar to MCP in a lot of ways. And one of the cons previously is those MCP servers if they have many different tools they can get pretty heavy. So this solves that in a really nice way. But we also wanted to make this better for those who are still using MCP. Um because MCP has a lot of benefits. I think the biggest benefit over skills is that you could implement OOTH which again very helpful for internal context enterprise use cases. I think that um if you want to connect to data dog through the data dog MCP works very well for this. Um the problem is the same as the priors which is that if you include every single tool and all of the tool contents in the context window it takes up just a ridiculous amount of space. So ideally you only want to include the tool names and then allow the agent to dynamically discover the context as it finds it. And just to like put a a visual to this, we've been testing this for some time now. And once you strip this away, you only give the agent the tool names and you allow it to dynamically discover which tools you have. This was a massive improvement. Almost 47% fewer tokens used when people are installing multiple MCP servers, which intuitively just makes sense. You install the data dog MCP server, the Slack MCB server, the linear MCP server, they all have tools. all of a sudden you have a hundred tools included in your context window or you're going in like manually togging toggling them on and off. It's just like a huge uh pain and I think this approach is much better. There's been some other uh research like this in the industry which I think is awesome and I would love to see all coding agents do this. And the final one here is again everything is a file. The file system actually works really well here for certain use cases. And just like the chat history can be abstracted to a file. Same thing can happen with terminal sessions where then when you ask the agent, you know, why did my command fail, it can go again and tail the file or semantic search through the file or GP the file and find the specific piece of why the command failed. Um, usually I mean if it failed the errors at the end so a tail would probably work fine. But this works really really well. The combination of these five things um has made a massive impact on the quality of the agent conversations and how long you can kind of stretch a context window. So I'm really excited. We're rolling all these things out in the coming weeks. Um it's not clear though if this is like the only way or the best way. I think there are some there are some notable downsides and trade-offs to files as well, but we've been trying to air on the side of simple and easy primitives to use versus having to build like some complicated thing on top of all of this that we then have to rip out in the future. So, the file system has actually worked very well. We've been able to actually delete a lot of code and using this approach. Um, so yeah, big shout out to everyone on our team who's been working on this. Um, all these folks have been doing an amazing job. Um, Jadia specifically, thanks for helping write the post. Um, so yeah, this is something we're working on. I'm very excited about making agents um, pull in the highest quality minimal context. It's something I've talked quite a bit about actually, which is that context management is so important and ideally the agent harness itself can do a lot of this heavy lifting for you. So, I'm I'm very excited about this. Um, we also have some more rapid fire questions. So, these were some things that people asked online. I'd love to go through. If you have more questions in the chat, too, now is the time. Um, happy to answer questions live. The first one from Aman here was um, what is the best approach for prompts in plan mode? So, I think about plan mode almost as a prompt optimizer. You can be a little bit less specific in your prompts to the plan mode because then it's taking your simple idea and expanding it into a lot more text in a markdown file you can edit. And if you have additional things you want to tweak or change to the plan, you can do follow-ups or you can edit the plan directly. So, I find myself being less descriptive in the prompts that I use for plans. And then how to efficiently use cursors rules. Um hopefully with my long spiel there on static and dynamic context, you have a better understanding of the primitives where since rules are static context, you really don't want to include very many. Like if something is going to graduate to static context, it's going to be in every conversation. It needs to be something that you are comfortable with the agent reading every single time. And there are valid things that need to be in here. when you see the models get something wrong consistently, you should consider putting that into a global rule that static context is included every single time. Um, Nick has a comment. Would it be helpful to maintain a doc about the app's features and the files responsible for those features? Uh, I feel like when this should help when I create a new session. So, one pattern I've seen a lot of people starting to do is they have individual plans for features where they're using plan mode to like make a very detailed plan for that feature, but then they also maintain an architecture doc that is what you've described of a mapping of the codebase to plain English, which is not only good for the human, it's good for the agent. um a way of making sense about kind of the state of progress and the state of open items. There can also be a to-do list in here like a global to-do list. One thing is helpful then is then you can tag that in at the start of new conversations to your point around you know you know I think you said something I feel like this should help when I create a new session. if you can tag in that doc, it provides a lot of um a lot of additional context. And one of the things we're doing with the history change I mentioned is we're bringing back the ability to just atmention past chats. So if you had a really long conversation going and you want that whole transcript included, um you'll be able to do that, which will be really helpful for making sure the agent has all of that context and is included. So I would recommend that. Yeah. Uh question or comment here. I've also observed that being vague is better for sophisticated tasks. Yeah, sometimes the models will surprise you with what they suggest and it might be better than what you thought was going to be the obvious implementation. You could still correct it and say actually I want to do this instead, but when you're vague, you give the model the opportunity in late space to come up with an idea of something that maybe you haven't thought about yet. Yeah, mentioning past chats. It used to exist, but it was kind of buggy and didn't really work super well. So, we wanted to make it much better with this file system based abstraction. So, that will be launching very, very soon. What's the current state of past chat references? Well, there you go. Answer Jordan's questions, too, hopefully. Uh, next question here from Brian. Um, is legacy terminal mode still necessary for Windows? It is not. Um, can you use LMS for automated testing? So in cursor there is an integrated browser which is kind of like an MCP like playrider or Chrome and you can ask the cursor browser to go manually kind of walk through your application and click on things and test things. Um which is pretty nice and pretty fun to do when you're towards the end of building something. This doesn't have to be the integrated browser. It can also be an external Chrome window. But I found this to be very helpful. Although I will say that the best uh the best automated test is something that's still deterministic and in code. So you might do that as kind of like a gut check, but you probably still want to have um you probably still want to have some sort of playright test or um headless test suite that's running uh for the high impact flows. And then last thing, manual get commits or let the agents go crazy. I've been experimenting with allowing coding agents to to write some of the code commits. I will say that I'm a pretty lazy committer in general. So I usually wasn't providing much detail anyway. So the models are already doing much a much better job than I would have done. I will say though that there is a threshold where it's like too much. I open up a PR and I don't want to read 10 paragraphs of AI slop on the feature. So, it kind of depends if the consumer is you or AI. If you're just doing like intermediate commits towards the PR, it doesn't help to use AI to generate those commits. I think once you get to the point where you're asking other people to review the code, uh, I'm not as sold on always using AI code descriptions for PRs. I think they can be helpful to get you started, but I think it's nice to include more context yourself. Uh, I really like linking specific documentation to the large language model. Yeah, I find that I either will include a link or I will say go look it up on the web if I know I'm asking for something that the models likely don't know about. So, I was uh I was looking at diffs, diffs.com, uh which is a diffing library that the folks at Pierre built. Really nice diffing library. I was building something with it on the side just for fun. This is brand new relatively and the models did not have this. So, I kind of copy pasted a link, copy pasted the docs, threw it in there and like did a pretty good job of figuring this stuff out of how to use the APIs. So underrated thing is searching the web. I think it improved the commit messages. Yeah. [clears throat] Yeah. If the commit messages look through the chat history, I think that would help a lot. Will it be possible to watch this playback after? Yes, it will be on X and YouTube and LinkedIn and everywhere else. Um, last question here in the chat and on my thread. Can you explain the optimal setup and workflow? If you want to build a website with cursor, um you want to make context, you want to have special instructions on what to build, and you want to have instructions on how to build it. Um I would recommend just you only really I think you can go really far here just using plan mode. And then when you see either specific design guidance or product requirements that you want to make sure the agent has every single time, you can either abstract that to like a parent doc like we were talking about Nick where you can put that into this longunning architecture dock that persists across the entire project or you can put that into your global agents.mmd cursor rule like the thing that's static context that's included in every single conversation is probably what I would recommend. uh plans on supporting userdeed defined plugins to hook into certain events. Uh yeah, we have um we have cursor hooks which can do a lot of interesting things. Let's see if there's a full list. I think this is the full list. Before a shell command executes, after a shell command executes. after an MCP server executes some tool, after a file edits, um before a file, before tab reads a file, after tab reads a file. Stop is also in here. I think that one's missing from that list. Um this can go pretty far, but I think it would be nice to then take this further with defining userdefined things in Typescript or something. uh versus just the granted like you can build a script that allows you to do userdefined things here but I want to add even more things to the system keys I guess that are available. Uh cursors generated commit message should be a lot better. I agree. I actually find that it doesn't really follow my existing commit style as well as I would like it to. I think we need to make it much better. Um, I'm going to look into that. Um, can we use a local uh AI model on cursor? And you can if you're doing it through kind of a bring your own API key, um, which we do support um, which some people might want to do. I find that if you bring your own API key, I think if if the reason why you're wanting to use a local model is cost, there are a lot of actually very affordable models. uh GLM I think is the most recent one that's pretty pretty good and pretty affordable um that you can use where it doesn't necessarily have to be local but if you're wanting to do local because of privacy then that would be kind of a different ballgame. Uh can you show what's in your rules file? Mine feels like my core programming values like make code modular and such. Yeah, let me see if I can pull up um one of my repos and we'll just take a look and see what is in my rule spot. I've tweeted about one of them. Um but I don't know if I have posted this one on here. So, let's see. Oh, yeah. This will do. Okay, let me share this again. I'll make this a little bit bigger. This is one of the um Yeah, it's fine. This is one of the agents.mmd files that I've been using for my website. And I have tried to just put in some of the rules that I find helpful across things that I use all the time. So coding style guidelines, um, React rules. So I've got React compiler on. So you don't have to put use memo, use callback everywhere. Uh, Tailwind rules. I'm using V4. Next rules, TypeScript rules. Some of these things you can enforce through deterministic things whether it's llinters or formatterers. So you don't necessarily need to have them here. Um but I find this is I try to make this as small and concise of a list that I can use that I find you know still helpful. And I think I also have I also have one for writing where I've just kind of put some writing rules down here which I find kind of helpful. But yeah, those are kind of the the two main ones. I keep it pretty pretty basic actually. Um I don't I don't do a ton of rules or a ton of customization. It only depends on uh if I consistently see the model get something wrong over a long period of time based on my codebased context, I'll add that in. So that's how I how I think about it. But with that, we're going to wrap up for today. Made it through the topics that I wanted to cover. Thank you all for hanging out here live uh in the chat uh across X and and YouTube and and LinkedIn. So let me know for the next stream I want to do another round of questions and topics. Maybe I'll do the same thing where we cover like what's in the zeitgeist right now which I find kind of interesting. But uh yeah, I hope you all have a wonderful week. Thank you for hanging out with me today.