Isaac Parker

Cultivating software

Some of my thoughts on software quality & AI-assisted software development.

The floor for quality is certainly lowering, but I’ve also seen the ceiling getting higher. More specifically, I see the potential for huge, long-lived software systems to remain flexible, maintainable, comprehensible, and refactorable as constraints, goals, and business needs change around them.

Even for those who cared deeply about code quality, the labor-intensive nature of writing code by hand inevitably created a heavy bent towards “it works, so don’t touch it”, and it’s a self-reinforcing trap:

The high cost of revision forced architectural design to behave like prediction: anticipating constraints, consumers, and requirements, and hoping you weren’t too far off. We had to design around imagined future consumers because correcting the design after encountering real ones was prohibitively costly. Even a design that was “good” when written can become “bad” as its environment changes around it. The problem isn’t necessarily that the original prediction was careless, but that it remained embedded in the system long after reality diverged from it.

Now that agents have reduced the mechanical cost of system-wide change, architectural design can become more empirical:

The important thing to design for up front isn’t every future consumer, but the ability to revise the system once those consumers exist. Keep ownership clear, dependencies explicit, and important concepts represented authoritatively, so that assumptions remain visible (and replaceable) when reality disproves them.

Some classes of evidence that revision may be necessary:

These are architectural problems, not necessarily aesthetic ones. Plenty of systems have ugly code that shouldn’t be touched, and plenty of systems have clean-looking code with a subtly wrong dependency direction that will become costly.

“Evolutionary design” isn’t a new concept, but its economics, and therefore its limiting factor, have drastically changed. As mechanical implementation becomes cheaper and more automatable, sustained architectural judgment becomes the scarce, high-leverage work. That means:

Agents can help inspect the system and execute a migration, but can’t make these decisions reliably merely by being asked to “improve the architecture,” because the decisions depend on intent, history, future direction, and judgment about which irregularities are meaningful.

This also makes it more important to allocate human attention according to the judgment a change requires, rather than its size. A thousand-line mechanical migration within an agreed model may require less architectural scrutiny than a five-line change that relocates authority or reverses a dependency. That’s always been true, but by increasingly severing the association between the volume of a change and the human effort required to produce it, agents make the distinction far more consequential. This is the source of both the higher ceiling and the lower floor: with sustained architectural judgment, agents make far more ambitious revision possible; without it, orders of magnitude more change devolves into incoherence.

The stakes extend beyond any abstract ideal of “code quality”. A business benefits from producing more software only while that software remains responsive to new needs. Unchecked growth makes each subsequent change harder, as new capabilities have to work around old assumptions, duplicated knowledge, and boundaries that no longer match the business. More implementation capacity can therefore create more business value now while quietly degrading the system’s capacity to create value later. Architectural revision is what allows a system to continue delivering more as its scale, consumers, and requirements change.

Making that revision safe depends on several conditions, none of which are radical or new:

These are established software engineering practices, but cheaper implementation increases their leverage: they let agents perform large amounts of mechanical work while humans concentrate on the model, invariants, migration strategy, and evidence. They make extensive change safer; they do not decide what changes will keep the system healthy.

I’ve been formulating this in my head through the metaphor of cultivation. A software system isn’t a finished artifact, meticulously built up piece by piece. Nor is it the output of a “software factory”; a factory assumes a stable process producing independent units, while every addition to a software system changes the structure in which the next addition must fit.

Software is living structure. Agents allow it to grow much faster, but cultivation (observing, pruning, reshaping, and sometimes cutting back) allows that growth to continue without degrading the system’s capacity to change and decides whether the result is a healthy system or an impenetrable bramble.