How We Work: Source Code Management in Agentic Engineering
Ryan Snodgrass
This is Part 5 of our How We Work series — short reflections from the SageOx team on the tools, techniques, and mental models behind our workflows.
Source Code Management in Agentic Engineering
Transcript
Milkana: Can you talk about any strategies or thoughts you have around branch management, or even repos, that have evolved in this agentic world when things move at such incredible speed and when you have a lot of parallel work happening?
Ryan: Yeah, I mean certainly our philosophy has changed. Ajit and I used to get in a little bit of argument sometimes about what's the right size for a PR, how many commits. We — he wanted to see a lot less, because initially we're coming from that BC, "before Claude" era, where you do things like git bisect and git log and you can make sense of the codebase and the stream of work that's coming in, because it's at human pace.
But I think we both realized at some point that just no longer makes sense. And in fact, it's actually bad for the agents when you have a PR that's like 10,000 lines with changes all over the codebase that are completely unrelated, just to make it look like a nice clean commit history. The reason is, if you want agents to go back and look at previous commits, it's very hard for them to reason about what the heck was this change for, because it's touching a little bit of everything.
So smaller commits, much higher volume, very focused and targeted is better. There's a balance there. I mean, sometimes I still have way too big commits just because you're in the flow and you're working in one work tree and you're just like, "I don't want to spin up another work tree just for this one thing. I'm right here, just fix it while I'm doing this."
Milkana: And have your thoughts around the repo mapping and structure changed in this new world?
Ryan: Yeah, I think it's evolving right now. I mean, we really have loved having a monorepo in the sense that the coding agent can make sense of everything, and that has been really important. Although we have a separate design system repo and a separate repo for the CLI.
I think what we've observed is that at least with coding agents today, they often get lost when the repo is really large. So yes, you can build quickly, but once you get to a larger size repo — I don't know, we have like 750,000 lines of code right now — it might be better to break that down into smaller chunks. More well-defined, almost like when we went from monolithic services to microservices.
I think there's probably something to be said for breaking down repos into more micro-repos. Especially as agents are dealing more with all the dependency management, PRs, and dealing with the fact of having to port things across repos. That would have been annoying to humans too, to manage all this. But if you're not having to manage it as a human, agents might be very good at that. So I think that's something we'll probably explore at some point.
Right now we're still in a monorepo. But I think that's got to be something we revisit. And again, all these things that we've used as software engineers over the decades and learned — almost all of them you can say, "Okay, throw that out. Let's start from first principles. How should it be?" And then obviously you'll bring some of those techniques back that just make sense. But it's really a fresh opportunity to face these with new perspectives on how things should work.
We'll be sharing more of what we're learning as we go. Expect other interviews and takeaways. Drop us a note if you'd like a specific topic covered: feedback@sageox.ai.