Quality assurance pays the bill

To me, it always seems to end up with more work hours, not less. A tool makes something faster, we fit more work into the day, and the expectation moves with it. The hours we thought we were getting back become room for the next assignment.

Time remains linear, but we keep finding ways to make it feel more compressed. We can have several pieces of work moving at once now. Each can return a finished-looking result while our attention is somewhere else. There is still one person who has to decide whether to trust it.

I keep coming back to what happens to the checking. I worry that doing more work is becoming an accepted reason to check less of it. The volume becomes the explanation for the reduced scrutiny. The time for quality assurance pays the bill.

the expectation moves

Elena Verna wrote last week about refusing a permanent 996 schedule: working from nine in the morning until nine at night, six days a week. She describes the way faster tools can raise expectations again. A project takes less time, so the organization takes on more projects. The person doing the work can want that expansion too. Being able to attempt something that used to be out of reach is exciting.

There is research behind that experience. On her research page about AI at work, Berkeley researcher Aruna Ranganathan describes qualitative findings in which people took on more tasks, multitasked, and allowed work to spill into their non-work time even as individual tasks became easier. That account describes a pattern worth examining; it does not tell us how much checking every workplace has lost.

The pressure can begin with a reasonable decision. A team finishes something early and accepts another useful assignment. After a few rounds, the higher output becomes the expected pace. Someone who wants to keep time for checking has to explain why work that appears finished is still occupying the schedule.

checking takes its own time

Consider a report that an agent drafts in a few minutes. It reads well, the charts are present, and the conclusion sounds plausible. Checking it still means going back to the sources. A reviewer needs to know whether the chart uses the right base, whether the calculation matches the question, and whether the conclusion goes further than the evidence allows.

Some of that work can be automated. A program can recalculate a total or find a broken link. Those checks save time I would otherwise spend on them. Someone still has to choose the checks, understand their coverage, and read the result in the context of the assignment.

Now give the reviewer several reports produced in parallel. The preparation time may have fallen enough to make that possible. The review time has its own constraints, especially when the reports concern different subjects. Dividing the same afternoon among more results leaves less attention available for each one unless the way we check them also improves.

Here I think we can start accepting a different standard without making a clear decision about it. We scan a document that we would previously have read closely. We ask an agent to check another agent's answer. We rely on a clean test result without asking which parts of the work the test covered. Each can be a useful choice in the right setting. The concern is letting the amount of output make the choice for us.

the work moves somewhere

Anthropic's October 13 engineering account describes coding moving faster while source control, builds, and continuous integration became bottlenecks. The company built a new source-control system and a code-review interface to handle the growth. It reports substantial improvements in checkout speed and infrastructure use.

Their investment in the systems around the faster work gives us a reason to look at what a productivity claim includes. Producing code is one stage. Getting a change reviewed and operating reliably takes additional work, and the tools supporting those stages can improve too.

For a smaller organization, the investment may be time on someone's calendar. A report needs a person who understands the subject. A software change needs checks suited to what it can affect. If we use all the released capacity to begin more work, those obligations remain with whoever receives the results.

If a customer later finds a discrepancy, someone has to reopen the analysis or work out why a change broke an existing process. A task that looked finished returns to the schedule, often with another person's day attached to it.

I wrote earlier about needing time to finish what my agents start. This adds a management decision to that problem. Once a higher rate of production is established, how much checking are we agreeing to fund?

leave room to trust the result

I want the time saved by a tool to be available for a decision. We might use it to deliver more, spend longer checking a consequential result, or finish the day earlier. Accepting the next assignment immediately uses up that choice.

Before taking on more parallel work, I would ask who will check the results and when they will have time to do it. The depth of review should follow the consequences of an error. An internal experiment and a report someone will use to make a costly decision need different treatment.

Quality assurance belongs in the estimate of what we can finish. If the schedule works only because everyone understands there will be less time to check, we should say that plainly before promising the extra output.