I have spent a lot of the last few months building the machinery that builds software rather than building software. Orchestration, context management, rule files, evaluation scaffolding, the whole apparatus. It has felt productive in a way I have learned to distrust, and I want to write down why before I talk myself out of it.
Here is the uncomfortable version. I ran an audit on my own work. For each piece of harness I had built, I tried to name a specific change that shipped because of it and would not have shipped otherwise. Not "it makes me faster." A change. Something with a commit and a date.
For a decent portion of it, I could not.
Building the tool is more pleasant than using it
Harness work has a property that makes it dangerous: it produces continuous, legible progress against problems you fully understand.
The actual work does not. Actual work involves deciding whether a feature is worth building, sitting with an ambiguous customer complaint, or shipping something you are not certain about. It is uncomfortable and the feedback is slow and often negative.
Harness work is the opposite. The problems are technical and bounded. You know when you have solved one. The system gets visibly better every session. You end the day with something that works and no one to tell you it was the wrong thing.
Programmers have always had this escape hatch. Configuring the editor, restructuring the build, rewriting the deploy script. What is different now is the story available to justify it. Editor configuration was obviously procrastination and we all knew it, which limited how long anyone could sustain it. Harness engineering comes with a thesis attached. This is leverage. This compounds. I am building the factory, and the factory is the product.
That story is sometimes true. That is exactly what makes it effective as an excuse. A rationalization that is occasionally correct is much harder to dislodge than one that is always wrong.
The discriminator
I do not think you can tell the difference by looking at the work. Good harness engineering and elaborate avoidance produce similar-looking artifacts, similar commit histories, and identical enthusiasm.
The only test I have found that works is retrospective and specific:
Name one thing that shipped because of this, that would not have shipped without it.
The rules matter. It has to be a specific change, not a category. It has to be something that shipped, not something that became possible. And you have to be able to describe the counterfactual, what would have happened without the harness, honestly enough that someone could argue with you about it.
Real answers sound like: the overnight run caught a regression in the billing path that I would have found in production on Monday. Or: I shipped four small fixes on a day I had ninety minutes, and without the setup I would have shipped zero, because ninety minutes is not enough to load the context by hand.
Avoidance answers sound like: it makes everything faster. It reduces friction. It will pay off once it is finished.
That last one is the tell. Harness that has not yet paid off is not necessarily waste, but harness that has been about to pay off for two months is not an investment. It is a hobby with a business justification.
Why the solo case is worse
I think this is more dangerous for me than for someone inside a company, and it took me a while to see why.
A team has structural interruptions. Someone asks where the feature is. A sprint ends. A customer escalates and you have to stop building the machine and go operate it. Those interruptions are annoying and they are also a forcing function that returns you to the actual work.
Running my own businesses, I have no such thing. Nobody asks. I set my own priorities, and the priority I set most naturally is the one that feels best while I am doing it. I can build harness for six weeks and the only signal is that revenue did not move, which is slow, ambiguous, and easy to attribute elsewhere.
There is also a specific trap in being fifty and experienced. I am good at building systems. Building systems is where my judgment is sharpest and my confidence is highest. So the activity I drift toward under uncertainty is precisely the one I am best at, which makes the drift feel like playing to my strengths rather than avoiding my weaknesses.
The harness that paid for itself is dull
I want to be clear that I am not arguing against harness engineering. I am arguing for a much less interesting version of it.
The harness that has actually paid for itself in my work is dull. A queue that survives restarts. A log I can read when something failed overnight. A way to run the same task against a different model without editing anything. A short rule file that gets pruned more often than it grows. None of it is clever. Most of it took an afternoon.
The parts I am least able to justify are the ones I was most excited about while building: the elaborate multi-agent topologies, the context management schemes with three tiers, the evaluation harness with more configuration surface than the thing it evaluates.
There is a pattern in that. The dull components solve a problem I had actually hit. The elaborate ones solve a problem I anticipated. Anticipated problems are where the enjoyable engineering lives, and they are also disproportionately problems I never had.
So the boring test, alongside the shipping test: did I build this because something broke, or because I imagined it breaking?
Where this argument is weak
The obvious objection is that infrastructure has a lag, and demanding an attributable shipped outcome will kill work that would have paid off in month four. That is a real risk and I do not have a clean way to distinguish slow-paying infrastructure from avoidance in advance. What I would say is that the demand is not "justify it before you build it." It is "audit it after." Building on instinct is fine. Never checking is not.
Second, the discriminator is gameable, and I am the one grading. I can construct a shipped-outcome story for almost anything if I want to badly enough. The test only works if you run it on someone else's terms, which is why I wrote this down rather than keeping it as a private resolution.
Third, there is a version of this that becomes an excuse for never investing in tooling, and that failure mode is also real and produces people hand-copying context into a chat window for two years. I am not arguing for that. I am arguing that the current environment makes the opposite error much easier to commit and much harder to notice.
I also cannot rule out that I am wrong about my own case. Some of the elaborate work may pay off later and I will have talked myself out of it publicly. I would rather make that mistake than the other one.
What this changes in my factory
I audit harness monthly, with the shipped-outcome question, written down. Anything that fails twice in a row gets deleted rather than deprecated.
New harness gets built only after the problem has actually occurred, at least twice. Anticipated problems go on a list and mostly stay there.
I cap harness work as a share of the week rather than trying to judge it case by case, because judging it case by case is exactly the process that got me here.
When I catch myself excited about a harness idea, I treat the excitement as evidence against it. This is a crude heuristic and it has been right more often than I expected.
The audit question
Take the piece of your setup you are proudest of. Name the change that shipped because of it, that would not have shipped otherwise, with a date.
If the answer comes quickly, keep building. If it takes a while, that is worth sitting with. And if the honest answer is that the harness has not caused anything yet but will once it is finished, you already know what that is.
The factory is only a factory if something comes out of it.