(2025-09-28) I Have Seen The Compounding Teams

Sam Schillace: I have seen the compounding teams. A while back I wrote something to the effect of “if AI is getting better and more productive, where are the ‘compounding teams’ who show exponentially increasing output?” I think I’ve now seen at least two or three teams that seem to be showing this behavior

The teams that are compounding aren’t writing code at all. The each have built a framework (like the Amplifier framework) around a model. They will have some plumbing akin to Claude Code or Codex - something that has callback hooks, tool calling, and flow control, but then the system they build will be much more proactive. It will have a series of strategies, tools, opinions and behaviors that let it run more independently.

Most importantly, all of the teams I’ve seen doing this so far are making extensive use of low-level programming tools to give the system access to itself. All are heavily filesystem based, use git, use markdown, kubernetes, xml and other common tools. I suspect that the next wave of software at scale will be built on these programmer tools, even for non-programmers, the same way models will sometimes privately write code now to solve a hard problem asked by a non-coder. It’s fairly clear that these are good infrastructure for model-based action, since the models are so successful using them.

The compounding comes from a “build a tool for making a tool” recursive mindset.

All of these teams are overwhelmed with ideas now - that’s a common hallmark, because they are so productive that the new bottleneck is human attention. It’s common to have 5-10 processes running in parallel, and API spend is routinely hundreds of dollars a day

New work patterns are emerging around this capability. Coordination is the new challenge, and modular boundaries matter a lot. It’s much better to have two or three engineers who can design at this high level, working on well-defined but isolated pieces of functionality, than it is to have a large, mixed team. It’s hard to have some team members coding like this and others coding by hand, and it’s impossible to mix that in one repo

I think this is coming for most if not all knowledge work, too (see “Code goes first”). I know of teams using this technique and these tools to do all kinds of research and to create multiple kinds of artifacts. A common idea is to connect user feedback back into the system to do proactive product planning, marketing or bug fixing. Other workflows are easy to imagine.

there’s a bit of a trap here. Building one of the more advanced coding systems I’m talking about here takes a while to show benefits. It’s been something like 6 months of working on Amplifier and it’s only just now starting to be useful.