The work nobody asked for

John CraftsGeneral Blog

How AI makes it easier to create work, and harder to decide what’s worth doing.

Codex once suggested writing roughly 400 unit tests for a tool I was building. The intended user base was me.

I like tests. I’ve spent enough time around software to know what happens when nobody writes them. But test suites need maintenance, too, and there comes a point where you’re building a second project to keep the first one honest. There are plenty of applications where 400 tests would be perfectly sensible. I wasn’t building one of those.

I wanted a useful little tool. I hadn’t set out to establish a software quality assurance department.

What got my attention wasn’t that the suggestion was ridiculous. It was defensible engineering advice, presented without much consideration for the size of the job. I could decline it. It was my project. I was also the person who would have to maintain whatever we built.

In an office, the person proposing an elaborate solution and the person left looking after it are often two different people.

Corporate PowerPoint has enjoyed a long career making questionable decisions look respectable, so the polished proposal is hardly new. The difference now is that one can arrive with an executive summary, projections, a roadmap, and a pleasingly elaborate set of assumptions before the author has had much time to interrogate the premise. It might be good. Someone still has to find out.

The document has become much cheaper to produce than it is to evaluate.

I’ve been thinking about that whenever AI fatigue comes up. I use AI constantly, at work and in my own research and software projects. I like the technology. I’ve watched it become useful for things that were well beyond its reach a short time ago, and I have no interest in pretending otherwise.

I also understand the exhaustion. At industry events, I’ve heard people complain about being sold yet another feature as β€œAI-powered.” Sometimes they’re talking about capabilities like text recognition or object detection, which can legitimately involve AI. They just want to know what the software does and whether it’s any better than what they already had. The label isn’t much of an answer.

But some of the fatigue, I suspect, comes from a less obvious place: the technology is good enough now to create real work for other people.

The trouble with good work

β€œWorkslop” is a useful name for the confident junk that gets generated and passed along for someone else to clean up. A report full of invented claims can leave its recipient doing the miserable work of checking every line before they dare rely on it.

I’m interested in the cases where the output checks out.

Suppose someone produces a sound analysis of a market the company has no plans to enter. The analysis may be excellent and still need several people’s time before anyone is willing to shelve it. Or take a feature proposal that would work exactly as advertised, but would consume six months of engineering capacity to solve a problem customers barely notice. A competent proposal can be harder to turn down than a bad one. It comes with plausible numbers, a polished design, and enough apparent substance to acquire a meeting. Give it another week and it may have a recurring calendar invite.

Rejecting something plausible has a cost. People compare it against other priorities. They ask specialists to check assumptions. Someone writes the careful explanation of why it doesn’t fit. We count the hours saved by the person who made the thing, then stop counting when they hit Send.

If someone produces a proposal in fifteen minutes and three colleagues spend an afternoon evaluating it, how much time has the organization saved?

It’s an odd form of delegation. You can create work for other people without ever formally assigning it to them.

I don’t think every AI-assisted draft needs its own impact assessment. I can explore ten technical approaches in private, throw nine away, and spare myself hours of trial and error. That’s wonderful. A good summary can save several people from reading the same long document. Nobody needs a committee to approve that.

Things change when the experiment becomes a request. In website work, a landing-page mockup can look finished while the work that makes it usable has barely begun: accessibility, localization, performance, analytics, connections to existing systems, and the lovely question of who updates it next year. AI helps with parts of that, too, but a page doesn’t become ready for customers just because its first draft looks convincing.

And that’s before anyone asks whether the site needed another page in the first place.

The part after generation

Software engineering gives us a fairly clear view of these handoffs because so many of them leave records.

In Artificial Intelligence in the Firm: Bottlenecks in Software Production, Harvard researchers Fiona Chen and James Stratton studied what happened as firms adopted AI coding assistants and agents. Their November 2026 revision estimates that, twelve months after adopting coding agents, developers were opening roughly 36 percent more pull requests per worker, while elapsed time from submission for review to approval grew by about 56 percent. Increases in completed Jira issues and larger projects were smaller, with weaker statistical evidence.

Those numbers aren’t a verdict on the quality of AI-generated code. It’s an observational study, Jira counts are an imperfect measure of useful software, and elapsed review time includes waiting around for somebody to get to the work. But that last part matters. The code has to get through review before it can be shipped. Producing more of it doesn’t create extra hours in the reviewer’s week.

A related Harvard Business Review account of an eight-month workplace study describes employees taking on tasks that once required specialist help, getting partway with AI, then turning to those specialists to finish. Engineers found themselves coaching colleagues and checking AI-assisted work, sometimes through informal Slack messages and conversations rather than assigned work. From one desk, that’s a person getting a lot more done. From the other, it’s another interruption in a day that was already full.

There’s a useful counterexample in a Microsoft Copilot experiment involving 7,137 workers at 66 firms. People who used the assistant spent about two fewer hours each week on email and worked less outside regular hours. The researchers didn’t find a comparable shift in the quantity or mix of work. They point out that email habits are something a person can change alone; meetings and collaborative documents depend on other people changing their habits as well.

That seems right to me. I can change how I handle my inbox this afternoon. I can’t decide, on behalf of six coworkers, that we’re all going to run meetings differently starting tomorrow.

There’s the bill: when one part of the process gets cheaper, the cost doesn’t always vanish. Sometimes it just moves to the next desk.

Keep the experiments. Question the commitments.

One of my favorite things about AI is how cheap it has made experimentation. A decent idea used to require a fair amount of time, money, or specialized knowledge before you could test it. That screened out bad ideas, sure. It also screened out plenty of good ones, and often the people least able to afford the experiment.

I’m glad those barriers are coming down. I can chase a technical question on a whim now rather than save it for some imaginary weekend when I’ll have nothing else to do. Someone who has never written software can put together a rough prototype and discover whether the idea holds up. That access is worth protecting.

I don’t want companies to replace the old barriers with new ones. It would be painfully on-brand for corporate life to respond to the flood of AI-generated proposals by requiring everyone to complete a twelve-field intake form before they can have an idea.

I’d rather we got better at recognizing when an experiment has done its job.

Sometimes a twenty-minute investigation ends with β€œnot worth it.” Fine. Sometimes a prototype fails. Also fine. Neither result needs to be turned into a presentation proving that the experiment was productive. If an idea survives, then it’s fair to ask what decision the next person is supposed to make, what would persuade us to drop it, and who would be responsible for maintaining the thing if it works.

A rough sketch can become a roadmap, a business case, and a handsome set of mockups in very little time. That detail may help evaluate it. It can also make the idea feel inevitable. Give an idea a Gantt chart and suddenly it starts behaving as though somebody already approved it.

I’ve seen enough elaborate plans to know that complexity is not a credential.

There’s a difference between having the freedom to explore something and acquiring a claim on somebody else’s afternoon. I’d like that boundary to be clearer, without making it harder to cross when there’s a good reason.

What would we stop doing?

The temptation isn’t limited to management or to other people’s projects. I catch it in myself. If AI makes a small improvement possible, I start wondering what else I could add. Soon the little tool I wanted has acquired features, dependencies, and future chores that nobody assigned me. I can manufacture my own backlog quite efficiently, thanks.

Organizations have been doing a version of this long before AI. We’re accustomed to celebrating what gets made: reports delivered, features shipped, initiatives launched. We have fewer rituals for the report somebody realized was pointless, the feature a team decided not to build, or the process that was retired instead of automated.

Those can be excellent outcomes. They also make lousy slide decks. Imagine standing up at the quarterly review to announce that your biggest accomplishment was preventing three meetings and deciding against a project. Somebody would probably schedule a fourth meeting to ask how you measured the first three.

I expect AI to keep getting better, and I expect it to make genuinely new kinds of work possible. I’d like to see more organizations take that opportunity seriously, without assuming every new capability needs to become another deliverable.

The promise of workplace automation was that technology would take some work off our hands. It’s strange how quickly we’ve become preoccupied with finding more work to put there.

If all we do with AI is generate more reports nobody reads, more features nobody needs, and more meetings nobody has time for, we’ll have accomplished something rather peculiar.

We’ll have developed extraordinary technology for making ourselves unnecessarily busy.