AI Memory News: LLMs Editing Weights, OpenAI's Git Push and Conductor Joins Meta

In episode 10 of AI News with Dosu, Taylor Dolezal, Devin Stein and Michael Mangus go through a week of agent and developer-tooling news. The conversation covers an MIT CSAIL post on LLMs that read and write neural network weights, OpenAI scaling Git and acquiring Pierre, Conductor joining Meta, DeepSeek's open-source harness, Patrick Collison's "improvements" feature and Linear CEO Karri Saarinen's call to retire the word "context." For the previous news episode, see AI Memory News: Muse Wonder, Haiku 5.5 and Decision Models. This transcript has been edited for length and clarity.

Transcript

Intro

Taylor Dolezal, Head of Ecosystem, Dosu: Well, it's another whirlwind of AI news. Just about every week that I take a look at my feed, I hope that it slows down, and it just tends to speed up. Even with the help of AI, it's hard for me to keep track of everything going on. So I'm very happy to have Michael and Devin here this week to go through some of the more interesting things that we've seen.

LLMs that read and write model weights

Taylor: Kicking things off this week, an interesting blog post about an LLM editing another model's weights directly. I believe this was GPT-6 Astra directly editing model weights to get some better mathematical results. I think that was shared by you, Michael, if you have some more details on this one.

Michael Mangus, Head of Product, Dosu: I think this is somehow a revolution in explainability, both for better and for worse. It's pretty incredible to see a model reasoning about the function of a specific weight, or about the way that two layers work together to accomplish a functional goal. That ability, I think, is very much superhuman. That's also what scares me somewhat about it. It's something that I don't feel like I will ever be equipped to have an opinion on, or to meaningfully review or give input on: rewriting the weights of models.

It's definitely very impressive. It makes me think about how, in agriculture, we made the transition from selective breeding to directly genetically modifying organisms. That has a really strong economic incentive behind it. Its ecological impact, I think, is much more questionable. And I actually think we might feel the same way about weight-space programming eventually. It definitely takes a step, qualitatively, in the direction of humans just specifying behavioral outcomes and having even less influence than we already have on mechanism.

Taylor: I wonder how this is going to compare to just directly editing things in the database. That's the initial feel that I got when reading through this article. But it seems like some things can be fixed and some can't. The improved mathematical results seem to be meaningful, but I think it was more the semantic types of responses, because you don't have to retrain the model when you're editing it this way. I'm curious to see if anything new or interesting comes out of this space, or if we see more models or fine-tuning happen on this front.

Michael: I think there's some debate about the extent to which it's actually creating new capabilities. With the Qwen math result, some people have reasonably pushed back on some of the fanfare, insofar as it seems like what it's really doing is fixing a pathological behavior in the model more so than enabling qualitatively new capabilities. But there's also no reason to think this won't continue to evolve to the point that it can directly create capabilities.

Something that I think is scary is they suggest you might be able to use a technique like this in place of evaluation. You could just have a model look at the weights and say, this is a good model or a bad model. Yeah, you probably can, but how do I trust that? How do I audit that? Really difficult question.

Devin Stein, Founder and CEO, Dosu: Another interesting thing I saw related to this was that it's actually an emergent behavior in the most recent generation of models. Something happening around model size, or intelligence in the training data, is now enabling it to do this. I think it's very interesting to see this new emergent behavior, and it also means their ability to do this is likely to keep increasing as models progress.

I also think it's very interesting for what the future of distillation or small models looks like, because there is a lot of friction to fine-tuning models. But if I could just say, hey, GPT-6, make this model really good at this one task for me, and it's very efficient, that opens up a lot of doors for smaller models.

OpenAI scales Git and acquires Pierre

Taylor: Speaking about smaller models and fine-tuning things for your users, OpenAI seems to be on a shopping spree well ahead of Black Friday here in the States. They bought Pierre. So they both rebuilt Git for their agents and then bought a Git startup, effectively. We've also seen stories from Anthropic about their Scion platform, and there seems to be no shortage of people trying to rethink the pull request, or just Git hosting in general. I know that we at Dosu have been working not on making our own Git system, but on figuring out some new workflows for how we do work on that front. Lots to unpack here, but we'd love to go to you on that, Devin, and get your take: thoughts about this acquisition, thoughts on Git in general, and how we're shaping it here at Dosu.

Devin: We might be seeing the end of GitHub, which is kind of crazy as a developer. I've been using GitHub almost on a daily basis for my entire career, for close to a decade, maybe over. And I never could imagine what would replace it. But it's clearly breaking under the weight of models, not just from a reliability perspective, where it's had a lot of reliability issues, but also because the way software is being developed is changing. A lot of the way software is developed with humans has been centered around this Git-based model.

So I think it's really interesting that they've not only been investing in scaling Git internally, but now they're also acquiring a startup in this space. I wouldn't be surprised if we see them offer a product related to Git hosting and scaling Git for agents in the near future.

Michael: Like you identified, Taylor, I think this is clearly part of a trend. GitHub's struggles have been widely noted. I saw an estimate that their push traffic was up something like five times over the course of one year, roughly. Actually, I'm surprised it's not more than that. But I think what it shows, which Devin is also alluding to, is that the assumptions we've made in the requirements for systems based on human pace aren't necessarily going to hold up when it comes to the pace of agents.

It's worth remembering, though, and I'm old enough that I do remember when Git was a new thing and SVN was the incumbent, that Git itself was also created for performance reasons. Among other things, there were some licensing issues and so on, but it was also in part because Linux kernel development needed faster patch times. So, to everything there is a season. There will be new technology for version control in the future, I'm sure, and I think it will be largely around the ergonomics of agents.

One thing that seems to be in common in what we're seeing from OpenAI, from Anthropic and from other competitors when it comes to Git replacements is that the assumption that I need a full offline copy of the repo on my machine isn't really that relevant anymore. A lot of the optimization they've been doing is on slicing up smaller and smaller bits of the codebase, or of the history of the codebase, to send essentially on demand to agents, with the assumption that they always have an online connection to source control. Assumptions change, and so software changes. Nothing new there.

Taylor: I liked what you'd said yesterday, Michael, about the amount of data that is coming in, too. That just wasn't what Git was initially designed for. We're seeing Git commits absolutely full of, we could call it context here, just information, whether helpful or not. I agree with you. I think that's one huge problem as far as GitHub's reliability and just staying online.

And then I saw a funny tweet from someone that said they're calling this the new SCM: SCM is source code mafia. They're talking about Zed's Delta, Pando from OpenAI, Scion from Anthropic and even Cursor Origin, things of that nature. It is interesting to see how different companies or efforts are focused on different things. Even Pierre seems to be more on the hosting side of things rather than a one-to-one GitHub replacement or comparison. But yeah, another day, another season, and I'm sure not the end of another source control type of solution for us.

Conductor joins Meta

Taylor: A friend of the show, Conductor: Charlie and team ended up joining Meta, which was wild news to see yesterday. I think we had multiple team members post that in our Slack. We'd love to throw it to you, Devin, on this one. I think you're probably the most avid Conductor user on the team. I've learned the most from you, admittedly.

Devin: Definitely a power Conductor user. I felt mixed feelings when I saw this. Yesterday was like national acquisition day for tech, it seems. There were so many acquisitions, and even today there are more coming out. But I have been a power Conductor user for a long time and a big fan of the team, and I'm very interested to see what comes out of their work at MSL. They've teased that there's going to be a new paradigm, and my experience with Conductor is that there is a need for a new paradigm. They were pioneers in how one person manages many, many agents, and I think their UX is still the best at that.

What I think is needed, and what they didn't quite crack, and I'm curious to see if they do this at MSL, is what it looks like for a team to manage a software factory, or teams of agents. In that collaboration and team-oriented aspect, I think there's a lot of room for innovation.

Michael: That's still a huge open space, I think: how do we reconfigure our work around cloud agents, really. I think that's the main thing that's actively shifting right now. I do think there's a really strong incentive, if you're OpenAI or if you're Anthropic, to also own that piece of the stack. So I'm curious, in the long run, how much adoption there is for Muse, and how many people are willing to either adopt that ecosystem wholesale or adopt just the Conductor piece of that ecosystem. I guess that remains to be seen, but clearly a huge opportunity is available.

Teams, cloud agents and session logs

Taylor: A question to both of you, but I want to ask Michael first. When it comes to some of these collaborative features, Devin was talking about working with a team in something like Conductor. Personally, I haven't seen anyone figure that out meaningfully, or where the focus should be. Is it in the pull request? Is it in the file? Is it in the effort or ticket that you're kicking things off with? I think the most meaningful thing we've seen thus far is Dosu being able to kick things off in Slack, where you get the progress report. Everyone can see that, and it seems to be more focused on the work itself, not a file or a pull request necessarily. Curious if you have any thoughts on that front: how do you prefer to work, and what do you think the future is going to be like?

Michael: What I love about cloud agents as a way of working is obviously the versatility of it. It's really nice to be able to do something from any computer or my phone. But the other piece of it is that all of those session logs are available. Something I know we've spoken to in the past: it's really helpful sometimes to be able to trace back to the exact wording of a specific decision somebody made. Or I'm investigating some problem and I want to trace back to where we went wrong in this implementation. What assumption was incorrect, or what information was not available that led us down this path?

That is available now in a way that it was never available in the past. You got the final output as the substance of your commit. You didn't really get that much of the path that arrived at that output, other than through human-to-human information exchange. That's totally different now. I think that's going to unlock a lot of ways of working, both some that we've thought about already and probably some we haven't thought about yet. As a company, we're really interested in taking advantage of the availability of session information.

DeepSeek open-sources its agent harness

Taylor: DeepSeek open sourced their coding agent harness, I believe it was, and I think it's supposed to focus on some self-learning things. I haven't gotten a chance to play around with it just yet. My head's been spinning with things like OpenCode and Pi and everything else. But I'm curious about your thoughts on this one, Devin, and anything you're looking to try out or that looked interesting from the DeepSeek harness.

Devin: It was interesting to see this from DeepSeek. I think this follows another trend we've been seeing in terms of the next evolution of agents, which is the paradigm we have with Cursor, Claude Projects and Claude Tag in Slack as well, where you have a main agent that is almost the orchestrator. It starts seeing work come in, messages in Slack or notifications or alerts, and then its job is to delegate that to sub-agents or other agents and report back their status. This was a neat, open-source implementation of a pattern we've been seeing recur.

I think it's interesting to see how this scales across a company. It's something we've thought about and heard from customers: do you have one super agent for your entire company? Do you have one per Slack channel, one per project? How do they communicate with each other? I think we haven't gotten to one agent or one pattern that makes sense for an entire company, but for teams or a specific topic, this pattern works really, really well.

Taylor: I can't wait to see what we build on this front. It just seems like we keep getting more options as far as our harnesses, whether batteries are included or not.

Patrick Collison's "improvements" feature

Taylor: Patrick Collison of Stripe lets anyone change his apps by typing a request. I believe we've seen this feature in Conductor in the past, where people could submit things and potentially get them merged in if it was a good idea to add to the product. When I read this, it was interesting to see that these were more minor changes, not load-bearing walls or infrastructure: change this button here, add this checkbox, modify this color. I think it's also interesting given what we talked about with GitHub and these other options, and collaboration and features in general. I would love to know both of your reactions to this. We could start with Devin on this one.

Devin: I love this feature. I was so excited when I saw Conductor add it. Not necessarily from a practicality perspective, but I think it speaks to the future of software, or products, in a lot of ways. One is something we've talked a lot about internally: agents are really good at giving you feedback. Unlike humans, who are maybe too lazy to report bugs or complain, agents are very willing if you ask them or give them the tools to do it. So I think this pattern of agents giving feedback as part of your product is going to become a standard paradigm.

Then the next part of that is actually suggesting improvements and modifying software. I like this approach, where people suggest improvements and then you can try to auto-generate the PR and maybe merge it in. I think that's really cool. I could see it being taken to another level at some point in the future, where you can think, hey, I can almost fork the product. You preview my fork and then maybe make the decision to merge it into main. We're not there yet, but I could see a future where software becomes more malleable by default, especially for power users.

Michael: Like Devin was saying, agents are great bug reporters. They have a lot of background knowledge about how things work. They're really good at reading your documentation and describing steps to reproduce and all that. I think the real question is, if you want to do this in the context of commercial software, how do you build a loop that actually takes this feedback and, like Devin was saying, runs it through some validation and some triage, and makes sure there's no malicious intent or prompt injection or anything like that trying to happen through these mechanisms? And then can we just release some of this stuff?

Or is there even a future, and I think a lot of people believe this, where software is more tailored for individuals? I'm a little bit skeptical of this sort of individually generated UI and UX, just because I think sometimes it's nice for software to work one way, so that we can communicate with each other about it and have a shared understanding of it. But I don't know. It makes me wonder where things are going to go. Kind of like what Devin's saying: will I have my own custom blend of all of my open source tools in the future? Maybe. It feels really wasteful to me, unfortunately. I'm not sure that's necessarily that useful a thing to do compared to the cost of doing it, but I guess we'll find out. Maybe, as the cost of inference goes down, it becomes viable for us to each have our own bespoke implementation of software that does exactly what we want. I think the hard problem is the aggregation: how do I build something that is useful to everybody, given all the individual feedback I'm going to get?

Taylor: I'm reminded of the early World Wide Web days, trying to figure things out with CSS and JavaScript. You could wildly style up your browser, even up to the address bar, and make it blue, pink, green, and install custom scripts or bookmarks to really customize things. I don't see a lot of people do that, though, but that possibility is there. And I agree with you, Michael: so long as we have an API or some kind of structure that isn't constantly changing, I think that's more helpful and a little bit less wasteful, too. If we can write Lua or JavaScript or CSS, something like that, it keeps that implementation meaningful and helpful to us. I've recently seen some people, with the help of AI, completely redo their home Sonos speaker setup because they didn't like the user experience or the interface itself. It's wild times to be living in on that front.

Linear's CEO on retiring "context"

Taylor: And to round us off, Linear's CEO wants to retire the word "context." I don't know if he'll be successful in that effort, but the core of this post, reading through it, was that having the information somewhere doesn't mean anyone understands it. There's a lot to explore here. This definitely felt like more of a thought piece about how work is done and what we call context as it pertains to coding agents. But I think there are a lot of topics for us to focus on here: what is your agent able to do with said context? For an outcome, are you looking for information? I'm curious about your reaction to this one, Devin.

Devin: I thought this was pretty funny when I saw it, because I actually have a little bit of a story with context. When I was first becoming a software engineer, in our codebase at DocuSign, context was used everywhere. There was a variable named context that was a way of just sharing information throughout the entire product. Especially not yet being an engineer, context doesn't mean anything, and I was like, this is a terrible variable name. I will never use the word context. I vowed that as I grew more senior, I wouldn't be naming things context. Lo and behold, a few years later, I, like every other engineer, use context, because it kind of makes sense once you learn what it is.

I think the Linear CEO is getting at something similar here: context means a lot of things, and it means very different things to agents in different settings. So we should be more specific about what we mean by context, and what types of information are in your organizational context layer. What is that? It isn't descriptive, just straight up. So I didn't quite resonate with the post, but I agree with the sentiment.

Michael: I don't think it's even an indictment of the idea of context so much as an indication that nobody has succeeded in solving it with a single product that meets every high-level need. I think that's consistent both with what we've seen in our own research and what we see in external research as well. There's no good one-size-fits-all solution to how to gather context. I think we all understand that agents need information that's particular to a task and particular to a certain organization, but getting them to seek it, and having it available, is an unsolved problem in the general case. Maybe there are some solutions in particular cases for particular kinds of context. I guess that's the spirit in which I took this argument.

Wrap-up

Taylor: I'm glad that both of you had subtext on the context about the context post. Well, that is all the news that we have for you this week. If you see something, say something to us. We're always monitoring everything as closely as possible, but we'd love to hear from you as well. Thank you so much, Michael and Devin. We'll see you again soon. Have a good one, everybody.

Michael: Thanks, all.

Devin: Thanks, everyone.