The good kind of lazy.

There is an old line, from Larry Wall by way of every greybeard who ever mentored us, that laziness is one of the three great virtues of a programmer. It always reads as a joke until you have done the job long enough to mean it. The lazy programmer is not the one who does less. It is the one who cannot stand to do the dull thing twice, and so spends a hard afternoon building the abstraction that means nobody ever has to. Laziness is what drives you to make the system as simple as it can be and no simpler, because every needless part is a thing you will have to carry up the hill again next quarter. The virtue is not the rest. It is the impatience with future toil that buys the rest.

We rediscovered the definition the week the agents got good, by watching something that had it removed. The model writes code for free. That is the whole of it. A human pays for every line in a currency the model does not hold: you will read this again at two in the morning, you will be the one who carries it when it breaks, the future version of you is real to you and you would like to be kind to him. That ledger is exactly where the good kind of laziness comes from. The machine has no two in the morning and no future self, so it has no reason to want less code, and it sprawls. Eight variants of the same logo, one of them empty. Three test harnesses for a thing that needs none. A whole second editor hidden inside the first. None of that is a bug. It is what building looks like when nothing pushes back toward the simpler shape.

So of course the metric that came with it is volume. Someone we will not embarrass was lately proud of thirty-seven thousand lines in a day, as though the number pointed up. The entire DTrace tree is about sixty. We were taught to read a diff that deleted a file as the better day's work, and we still believe it, and the new tooling is fluent in precisely the opposite. Assessing the work by the pound was always the brogrammer's mistake — the hustle about crushing code, never about what the code crushed down to — and the model is the most productive brogrammer who ever lived. It will hand you the weight you ask it to celebrate, and the weight is the cost, not the yield.

What unsettled us was realising our finitude had been a feature the whole time. The best engineering we have ever done came out of not having enough — not enough hours, not enough memory, not enough patience for the version with seven moving parts when five would do. Constraint was the press that squeezed the work down to something elegant. We spent years thinking of our limits as the tax we paid to ship, and it turns out the limits were doing the design. Take the human out of the inner loop and you do not just lose a reviewer. You lose the one component in the system that was tired enough to insist on simple.

The fix is not to write it all by hand again like penitents; the leverage is real and we are keeping it. The fix is to put the constraint back deliberately, since it no longer arrives for free. We make the model justify lines rather than count them, and we let deletion be the default ask. We point it at the work our laziness actually wants done — the debt nobody has time for, the rigor we are too rushed to enforce, the test that should have existed two refactors ago — and we keep it away from the part where it would happily pour concrete. The model should serve the old virtue, not stand in for it. It is a wonderful tool for being lazy in the right way, and a frictionless engine for the wrong way, and almost the whole of using it well is knowing, every single time, which of the two you have just asked it to be.