What are we tryingto make beautiful?

Everything is sorted. Easier to count. In fact, it's easier for an engineer in a lot of ways. Of course, they also destroyed the branch, which was the whole point and where all the beauty lay.

I think software engineers confuse these two pictures more often than we'd like to admit. And with the advent of AI agents, it's even more clear a lot of engineers don't understand why their roles actually exist.

For decades, we've pursued clean code through practices like DRY, separation of concerns, and reusable components. Useful practices, until following them becomes our definition of good work or beauty or value.

Repeated code looks wrong, so we combine it. A feature crosses several architectural layers, so we separate it. Whether the result makes the product better can become a secondary concern. Since, in a lot of these cases, the engineer is ignorant of the business goals and values this product is trying to drive, it's easy for them to talk themselves into this.

DRY means Don't Repeat Yourself, but the principle concerns duplicated knowledge, not merely similar-looking code. Imagine combining the validation for public signups and employee-created accounts. Then employees need to skip a requirement. Public signups need an extra check. The shared function accumulates flags and exceptions. Two workflows that could change independently now require understanding both. And one group of folks would shake their heads and say "Yeah, see! It's important to abstract the core business logic...blah blah." And after weeks of debate, you get something. Meanwhile, an agent could've spat out an iteration every couple of minutes for those weeks. It just doesn't matter nearly as much as we thought it did before.

Sandi Metz put it well: “duplication is far cheaper than the wrong abstraction.”

Some engineers know when to leave repetition alone or keep related behavior together. Others see a deviation from the rule and start separating needles from stems.

Understandable, manageable, and beautiful are different judgments. Can someone follow the behavior? Can they change it safely? Do the parts fit together and serve the person using it? And now, can an agent work on this effectively? Does it understand why it's here and the value it brings? Neatly arranged code doesn't answer those questions by itself.

AI puts this confusion under a new microscope (or maybe it's a magnifying glass, actually).

Working with agents can mean trying several approaches, keeping pieces, discarding implementations, and changing direction after seeing something work. It can look messy. It's also a familiar part of creative work. Sketches and prototypes help us discover what to make, including what to abandon. Agents let us explore without personally writing every version.

If each attempt needs an approved architecture before we try it, we're limiting what we're willing to discover.

Some folks say generated software can be fragile or insecure. A convincing demo isn't enough. Someone still needs to inspect the work and take responsibility for it. But if the product works well and can be maintained, disliking how it was made is a different objection. In fact, it might be invalid moving forward.

AI can make the engineering mistake, too. Ask an agent to make everything DRY, modular, and clean, and it can dismantle the branch on your behalf.

I want the end product to be beautiful: the experience fits, the behavior makes sense, and the thing holds up in use. Getting there takes taste and editing. I don't need every step to look tidy.

When an agent makes something good through a process I wouldn't have chosen, I want to recognize that. And when it produces beautifully organized code that makes the product worse, I want to recognize that, too.