Self-Evolving Software

so cool. Anthropic’s new post about how they’re handling source control for their monorepo reminds me of operational transformation (OT) for collaborative editing. perhaps a loose analogy, but i see similar mechanics in how lots of concurrent changes are coordinated through a shared system or server.

i’ve built a somewhat similar setup for my own software, with multiple feature agents responsible for writing features, and a release agent responsible for bringing those changes together. for me, this helped move the coordination problem from n × n towards n × 1. feature interactions still need resolving, of course, and the release agent could become a bottleneck. but that also gave me an opportunity to have a high bar for what actually gets deployed.

taking this further, i think this is an interesting step towards a self-evolving, recursively improving software factory.

imagine a product where the agents writing the product also live within the same monorepo. we could scale those agents up and down based on feedback from customers, both qualitative and quantitative. imagine agents debating or voting amongst themselves on which features to prioritize next, then writing those features and checking whether they actually helped.

we could add a system of accountability, where agents whose decisions lead to better outcomes get more weight in future votes, and agents that consistently make mistakes get less. voting alone doesn’t make something an improvement. the outcomes have to support it.

and since the agents live in the same repo, they could also propose changes to how they themselves work. improve the product, improve the process of building the product, and keep going.

to be honest, this doesn’t sound terribly hard to put together. but i do wonder, to what end? what does this lead to?

i have some thoughts. (hint: one of my previous posts.)

also reminds me of The Hitchhiker’s Guide to the Galaxy. if you get it, you get it.

Anthropic: Redesigning source control