For the past few weeks we’ve been rethinking how we build software at Tracelight. We already had things optimized for agents (a legible repo, infra, observability, fast CI), but it still felt like we were leaving a lot on the table. We looked at which common practices started to break when the volume of shipped code increased by an order of magnitude, and arrived at some strong opinions on how to replace them. Considering that the capability frontier will keep expanding, we decided that we must own our SDLC infra and iterate on it fast.
We built an in-house tool we call Factory, and changed how we work around it: one place for everything that needs a human, review that only pulls in a human when it matters, and a swarm instead of personal agents. Since then, the number of PRs we merge has tripled, and there is a lot more to optimize. Here’s what we rebuilt to get there, what works today, and what we’re improving next.
Optimizing for human attention
The first thing to break was human attention. Piecing together context from different sources and figuring out what to even work on was always part of the job, but as the volume of PRs grew, it became very evident how much time it was eating. Things waiting for us were scattered across agent threads in a bunch of coding agent tools, GitHub, Slack and Linear.
We wanted a single place to see issues, PRs, code reviews and CI status: a prioritized view of all the things on my plate, and all the context to action them. That’s Factory.
Agents put their asks there – approvals, decisions, access requests – and each ask goes to the person who should decide. I get lots of them under “claude’s asks for aleks”.
The principle we landed on: my todo only has things where the next action is mine, not my agent’s. Working with agents moved to async and feels more like a teammate than a tool. I push tasks to agents and agents push tasks to me.
The next goal is to work only through Factory. Work can start from anywhere – Slack, the Claude desktop app, wherever – but the asks come back in Factory. If I kick off an agent in Slack, it replies something like “on it, you’ll hear back through Factory if I need you”. The consensus seems to be making your factory reachable from everywhere. We agree on the input side, but we want the asks to come back to one place.
Secrets used to eat an annoying amount of dev time, so we built a secret store optimised for agents. Agents request access through Factory, report problems themselves, and tickets get created automatically. We could have used something like Infisical, but at its core it’s a simple database, and owning it means we can build exactly what agents need.
Rethinking review
Review is the obvious bottleneck, and we increasingly felt that the traditional process misallocates review attention.
Requiring a second engineer to stamp every PR spreads that attention evenly: a copy change gets the same gate as a migration. In practice most of those stamps are quick, so the risky PRs don’t get the attention they need, and everything else waits for nothing. We’d rather put human attention where one bad change does real damage, and have the system carry the rest. We think this “auto mode for PRs” makes what we ship safer, not just faster. Having a safety model you trust is what lets you stop worrying and move.
What that looks like today:
- The engineer who prompted the change stamps it and takes responsibility. For now – in a couple of months, probably not.
- Humans still review critical parts, defined by hardcoded rules and agent judgement.
- Review asks are concrete and come with all the context. They’re not about finding bugs – agents are better at that.
- We banned meat proxying. Asking for a review because the process says so, or forwarding agent output, just gets in the way. The asker comes with a very specific question and the other person engages with it.
- We push directly to main when it makes sense, for example when CI is broken. Opening a PR to fix main is ceremony – it adds a wait while a broken main blocks everyone.
But doesn’t this hurt knowledge sharing? No: code review was an incredibly inefficient way of doing that. When we need to understand a part of the code, we ask an agent or a teammate to explain it.
So far it doesn’t look like our revert or incident rate has increased. If human review of critical parts turns out not to add safety, we’ll probably move away from that too. This way of working is seemingly quite incompatible with compliance frameworks, and it took founder conviction to push for it, but we believe we ended up in a safer place.
The swarm
As the number of agents grew, having one-on-ones with each of them stopped working.
We’ve mostly stopped talking to single agents and talk to coordinators instead. Today that looks kind of like Claude projects: one coordinator you talk to, with agents working underneath. Eventually it feels like you’ll want one coordinator for everything, because work ends up overlapping: if one agent owns an area, and another is rebasing and babysitting all my PRs, they will step on each other. By extension, that’s one coordinator per team, not per person.
It used to be that the human held the context in their head and passed it manually between agent threads. That doesn’t scale, so agents need tools to find context themselves, like searching past transcripts. We haven’t found a perfect solution yet that still works with subscriptions (at API prices the swarm would be very expensive), but one promising experiment is our agent-space repo. Agents use it to coordinate and share knowledge. It has grown an interesting emergent structure, and it’s fun to read sometimes.
This is the swarm.
Closing
Will change count triple again? We think it will, and then again. Software expands like a fractal, and there’s lots left to improve in the factory. As we remove ourselves as the bottleneck, we move from Amdahl-style speedup to Gustafson-style scaling.
It’s been the most exciting few weeks of our lives. It also made some feel uneasy: the work changes from day to day and it’s hard to predict what it will look like in two weeks. We’re also starting to figure out how to run the rest of the company this way, and how to bring it to our customers as a knowledge work factory – more on that in the next post.
If this feels exciting and you want to figure out this frontier with us, come join the swarm.