Consider a morning spent fixing an intermittent login failure.
You ask an agent to explain the authentication flow. It finds some awkward code and suggests a cleaner approach. You ask what that would look like. Then you ask it to implement the approach, add tests, and handle a few edge cases.
An hour later, you have a substantial diff. The new tests pass. You can explain why the code is better.
You still haven't reproduced the login failure.
That was the unpleasant part. It meant digging through incomplete logs, questioning an assumption, perhaps discovering that code you wrote last month was wrong. The refactor gave you something useful and much more comfortable to do instead.
There is a kind of procrastination that survives every website blocker because it happens inside your work.
Programmers already have names for nearby habits. Yak shaving sends you through a chain of preparatory tasks. Bikeshedding absorbs attention in details that are easier to discuss than the difficult question. Both predate AI, and both can leave useful work behind.
A cleaner authentication module has value. You can defend the refactor in review and mention the new tests in your update. Neither requires you to explain why you chose that work while the login failure was still waiting.
My hypothesis is about the relative cost of those choices. AI can make a useful detour much cheaper while leaving the discomfort of the original task intact.
An agent can generate a replacement module in minutes. Asking a colleague about an undocumented field still involves waiting for a reply. Investigating the failing case still risks discovering that your approach was wrong. The easier activity now offers an immediate, tangible result.
It also supplies its own next steps. The replacement needs tests, the tests suggest edge cases, and the edge cases invite another abstraction. You can stay busy following that sequence without returning to the decision that sent you down it.
There is a related gap in organizational data. Farosβs June 2025 analysis covered more than 10,000 developers across 1,255 teams. Developers on teams with high AI adoption merged 98% more pull requests, while PR review time increased 91%. At the company level, the researchers found no significant correlation between AI adoption and improvements in delivery metrics. Review bottlenecks could explain that gap; individual procrastination cannot be inferred from it. But it is a useful reminder to ask what increased activity actually accomplished.
I don't know whether AI makes developers procrastinate more overall. It can clearly help someone get past a blank page, understand unfamiliar code, or work out which question to ask. Those benefits can coexist with a new way of getting stuck.
An ICSE 2025 interview study by Saghi, Zimmermann, and Chattopadhyay asked fifteen developers about procrastination. Participants described task-related, personal, and external triggers, and both harmful and beneficial consequences of delay. Those interviews offer reasons to examine the task and its context when someone puts work off. They don't establish whether AI changes that behavior.
An unfinished task proves very little. Debugging can take a day and leave you with three discarded hypotheses and no patch. A prototype can reveal that a feature is a bad idea. Even the authentication refactor may be necessary to understand the failure. The question is how the work advances the investigation.
Can you now reproduce the failure? Have you ruled out a cause? Did the refactor make a previously hidden state observable? If so, you can describe how it moved the investigation forward.
If all you can say is that the new code is cleaner, it is worth checking whether the original obstacle is still sitting exactly where you left it.
A merged PR tells you that a change was accepted. Whether it addressed the problem you sat down to solve requires looking back at that problem.
The smallest check I can suggest is to leave yourself a note before opening the agent.
Write down what you want to have changed by the end of this block of work. For an investigation, write down the uncertainty you want to reduce.
For the login bug, that might be:
Get one reproducible case and find out whether the session is missing before or after the redirect.
You might add logging, read the framework source, or have an agent build a test harness. The note gives you something to look back at when you're forty minutes into rewriting middleware.
When you stop, add what actually happened and what remains unresolved. If you changed direction, record why. Discovering that the original goal was wrong is a perfectly good reason to abandon it.
You can do this in an issue, a text file, or on paper. There's no need to turn it into a score. A completion percentage would introduce its own problems: smaller promises are easier to keep, difficult investigations look bad, and abandoned ideas can be valuable results.
The immediate value is having a record of what mattered before the work became absorbing. You get to compare it with your explanation afterwards.
If the same obstacle keeps appearing in those notes while the surrounding code keeps improving, you have something specific to examine. Perhaps you're blocked. Perhaps the task needs to be split up. Perhaps you know the next step and would rather generate something else.
In that last case, another implementation is unlikely to help. Close the diff for a moment. Open the logs, send the question, or run the test you've been putting off. Let the agent help with that.
The authentication module can be prettier tomorrow. Right now, someone still can't log in.
Disclosure: I work on NEDIO. We don't have data establishing the hypothesis described in this essay. The login scenario is illustrative, not a report of a measured incident.
This article was drafted and revised with AI assistance.
Top comments (0)