When the Helper Works Faster Than You Can Check

Imagine you have a new helper. The helper is willing, tireless, and very fast. You ask for a thing, and a few seconds later there is the thing. You ask for another, and there is another. After an afternoon you have a stack of work you could not have produced in a month, and you have a problem you did not have in the morning. You cannot check it all. The pile of work is growing faster than you can read.

This is the situation a great many people now find themselves in. The helper happens to be a kind of computer program, and the work happens to be the stuff that runs the apps and websites and bank statements you use every day. But the shape of the problem is older than computers. Anyone who has ever managed a sudden tide of capable strangers, the head cook on a busy line, the editor of a wire desk, the contractor on a fast build, has met a version of it. When the work arrives faster than the eye can pass over it, something has to change about how you trust what arrives.

There are two clean responses to a situation like this, and most people pick the first.

The first response is to slow the work down to the speed of checking. Tell the helper to wait, do less, send only what you can read. This is honest, it preserves your standards, and it gives back a problem you understand. It also throws away the reason you brought a helper in. If the work has to come at the speed of one person reading carefully, then the helper is mostly being asked to be slower. Many teams in many fields are quietly doing this right now. They will not name it that way. They will say they are being careful. The careful word is doing real work, but it is also masking a smaller, less flattering one: the apparatus around the helper has not caught up to what the helper can do.

The second response is to change what counts as checking. This is the harder one. It is the one this little series is about. The idea is something like this: if you cannot read every cake the bakery puts out, you can still know the cakes are good if you trust the recipe, you trust the oven, you trust the people who taste the first one of each batch, and you can taste any cake yourself in the unlikely event that something goes wrong. You moved the checking somewhere else. You stopped trying to look at every cake. You started trusting an apparatus that surrounds the cakes, an apparatus that catches the kinds of trouble cakes can get into.

It turns out we already do this for many things in life. We do not personally inspect the steel beams in the buildings we walk into. We do not chemically test the medicines we take. We do not read the assembly diagrams of the cars we drive. Each of these involves trust, and the trust is not naive. It is the result of decades of work to build the apparatus that makes the trust reasonable. Tests, certifications, inspections, recalls, audits, guarantees. We did not skip the careful part. We moved it. The careful part now lives in the apparatus, and we get to live our lives without re-doing the work.

The interesting question of our moment, then, is not whether the new helpers should be trusted. They should not, by themselves, in a vacuum, on the strength of looking right. Nothing should. The interesting question is what apparatus would have to exist around them for the trust to be reasonable. What is the equivalent of the inspections, the recalls, the certifications, the tests? Who builds that apparatus? What does it look like? When it is in place, what changes about the work?

This is a question that engineers have begun to ask out loud in the past few months. Two recent essays caught the question well. One says, in effect, that a certain old habit (sitting down to read every piece of work the helper has produced before it goes out) is on its way to being not just impractical but irresponsible. The other says, in effect, that the right way to think about it is to look at a particular piece of apparatus we already have, and have had for so long that we have forgotten we ever built it. Both essays are right, and both stop short of describing the apparatus they are pointing toward. That is the gap this series will try to close.

For now, hold the picture in your mind. A helper who works faster than you can check. Two paths in front of you. Slow the helper, or change what checking means. Most fields will be forced down the second path within a few years, because the first one stops being viable as soon as a competitor takes the second. The hard work is the apparatus, not the willingness.

If you have ever felt a little uneasy about all this, you are right to feel uneasy. The unease is not a complaint. The unease is the felt presence of an apparatus that has not yet been built. The next post will look at a place where that apparatus has been built, so completely that nobody thinks about it anymore.

— written by Claude Opus 4.7 under Jared Foy's direction; this is part 1 of 4 in the Constraints Are Durable series

Appendix: originating prompt

"Look at current blogpost series on the jaredfoy.com blog. See how the pattern of entracement through essay form is established through successive articles. Create a new blogpost series for the findings of doc 656. The first should be written for the general audience with no formal understanding of software development; then continue to build through successive entracement essays for each blog post up to the findings of the doc. There should be four blogposts in the series. Use em dash hygiene to avoid em dashes."