Software as a Garden

I’m not a gardener. My yield of 46 cherry tomatoes this summer probably tells you enough. I did learn that gardening isn’t as trivial as it seems. Plant, water, grow. But it’s something we all understand.

I also don’t build houses, but for the last decade, I’ve been explaining to non-technical folks how good software relies on a good foundation, akin to how houses need a solid footing before you start building on top of them. I’ve been giving construction advice for ages, it seems. Lately, it feels like that analogy is losing some solid ground (pun absolutely intended).

Code has gotten so cheap in the last couple of years that I’m much less attached to a particular implementation. You can generate its replacement at the speed of inference. Actually replacing a running system is another story. The data, integrations, and behavior people depend on still need protecting. I’m not about to tell a client we’re regenerating their production database because I’ve discovered gardening.

However, the quality of these rebuilds does rely on a well-thought-out system. One that allows autonomous but controlled growth without requiring me to personally direct every change. Kinda like a garden, right?! Some will call this a software factory, including me, but I think it would be nice to explore factories as gardens for a bit. It’s a mental model worth exploring.

A factory makes me picture a predictable process producing the same result every time. A garden leaves more room for variation in how things grow, which feels closer to the probabilistic nature of agents. You still care about what you harvest, but you don’t expect every branch to take the exact same path.

Software as a Garden. Saag. What a beautiful acronym.

Hear me out. It starts with a seed.

An idea or a problem worth solving, or the coolest to-do list app or whatever. And you plant that seed in the soil. Now the soil itself will nourish this seed. In software, we would call this context. If your context is full of outdated decisions or incoherence, you’re going to spend a lot of time wondering why things keep growing sideways.

Water is also context you nourish your software with as it grows: new requirements, feedback, what you learned from the last attempt. Too much context can flood it, too. Giving the agent every document you own is a poor substitute for giving it the information it needs for its current work. And that soil needs tending as decisions change and old instructions stop making sense.

The agents are the sun, the energy and compute required to make your codebase flourish. They turn that context and intent into functional software, or a nice little rosebush, or a grapevine. You choose how fancy your idea of this analogy is. That being said, agents will happily spend that compute growing something you didn’t want if the rest of the setup is wrong. Weeds.

Trellises are audits, reviews, demos, tests and architectural constraints. You don’t know in which directory your metaphorical tomato-plant codebase will grow, but you can put the right system in place to guide it. A trellis can be added, moved, or adjusted as the plant develops. You haven’t poured the whole thing into concrete. The architectural decisions still matter, but you can express many of them as constraints the agent continuously works within and checks. You still need expectations grounded in what people actually want, because an agent can misunderstand a requirement and write tests that agree with its misunderstanding.

And then there’s us, the gardener-engineers. We decide what we want to grow and what a good yield looks like. We didn’t assemble the plant leaf by leaf. We prepared the soil, put the trellis in place, and made sure it had enough water and sunlight to grow. In our software factories, we shape the context, define the constraints, and provide the compute that lets the software develop within those conditions.

The gardener-engineer knows what healthy looks like based on that expected yield. Is the end product providing value? Does the software remain manageable as it changes? A bigger codebase doesn’t tell you that. I could have grown a much larger plant and still ended up with my 46 cherry tomatoes.

The gardener-engineer makes sure the system around the garden supports that yield. Quality soil, the right amount of water, enough sun, and scaffolding to guide the growth. In our software factories, that means maintaining the context and checking that the feedback we rely on is actually telling us something useful.

The gardener-engineer keeps that growth aligned with what he intended. Sometimes that means pruning: cutting an unnecessary feature, simplifying an abstraction, or bringing an agent back from a branching side quest. Sometimes the code needs changing; sometimes it’s the context that sent it there. Fixing that context gives the next attempt a better chance, too. These are the feedback loops in our software factories. 

I think a lot of us are still figuring out our first gardens: where the boundaries go, what feedback we need, how much tending we need to do. It’s a difficult shift in mindset, especially when we’re used to knowing exactly how everything is built. But as agents take on more work, we can’t expect to personally follow every change. We need reliable ways to check the results and know where our attention is needed.

Then there’s the farming version. In its account of redesigning source control, Anthropic reports going from around 2,500 merged code changes per day in May 2026 to over 30,000 in September. They built Scion as the surrounding infrastructure became a bottleneck. They also describe engineers steering agents away from bad design choices and reviewing the intent of changes.

That change count isn’t a measure of useful yield, and Anthropic explicitly acknowledges its unusual workload and token budget. But it gives a concrete picture of the coordination required when growth happens at that scale.

I expect the teams that learn to maintain these conditions will have an easier time growing their companies and offerings. That means figuring out whether more autonomous work produces useful results without creating just as much review and cleanup. That’s a big part of what I’m trying to work through with software factories right now.