Akshay Sura - Partner
29 May 2026
AI did not reduce the work. It changed where the work hides.
I have been using AI heavily for a while now.
Not casually. Not once in a while to summarize an article or write a cute email. I mean inside the actual work: code, architecture, blog drafts, logs, proposals, specs, research, debugging, planning. The boring stuff, the useful stuff, and sometimes the stuff I probably should have done slower.
And here is the uncomfortable part. AI absolutely saves time. I just do not think it always gives that time back to us.
We were sold a simple trade. AI clears the busywork, and we get our afternoons back. That is not what happened in my work, and the research now says it is not happening cleanly for a lot of workers either.
Here is the pattern I live every day. Claude Code writes the boilerplate. It drafts the migration plan. It collapses a wall of logs into a clean summary in seconds. The easy two hours of my day evaporate. And then, instead of closing the laptop early, I pick up a third project, open two more async threads, and pour the reclaimed time into harder decisions than I was making before. The tasks got cheaper, so I quietly bought more of them.
That pattern has a growing stack of evidence behind it. AI is not reducing work as cleanly as promised. In a lot of cases, it is intensifying it.
Before AI, a lot of work had natural friction. You had to sit with the problem. You had to write the first ugly version yourself. You had to read the logs line by line. You had to build the skeleton of the thing before you could argue about whether the thing was any good.
Some of that friction was waste. No question. I do not miss manually rewriting the same boilerplate for the 50th time. I do not miss staring at an error log and hunting for the one line that actually matters. I do not miss starting every document from a blank page. AI helps with all of that.
But some of that friction also acted like a speed limit. It forced a pause. It created breathing room between decisions. It made it harder to say yes to everything because every yes had a visible cost. Now the cost is hidden.
A spec gets drafted quickly, so now we can do three specs. A code branch gets generated quickly, so now we can open more pull requests. A research pass gets done quickly, so now we can explore five angles instead of one. A meeting summary shows up automatically, so now there are ten follow-up actions instead of three. The calendar does not get cleaner. The work gets denser.
That has been my lived experience with AI so far. I can move faster than I used to. I can also exhaust myself faster than I used to. Two very different things.
Harvard Business Review recently published a piece titled "AI Doesn't Reduce Work, It Intensifies It." The argument is simple and very believable to anyone using these tools seriously. AI speeds up execution, but people often respond by taking on more tasks, moving faster, and feeling less able to disconnect.
CEPR's VoxEU piece, "As AI's power grows, so does our workday," looked at time-use data and found that higher AI exposure is associated with longer work hours and less leisure. Moving from the 25th to the 75th percentile in AI exposure was associated with about 2.2 extra work hours per week. In highly exposed generative AI jobs after ChatGPT, the difference was roughly 3.15 extra hours per week.
Emory's summary of research on "Artificial Intelligence and the Extended Workday" goes even further. Moving into AI-intensive roles was associated with about 3.5 more work hours per week and a workday that was roughly 10 percent longer, with the extra time coming out of things like socializing and exercise.
That last part matters. Because when people say, "AI will save you time," the real question is, "Save time from what, and for what?"
If AI saves me 45 minutes and I spend those 45 minutes walking, thinking, reading, or being with my family, that is a win. If AI saves me 45 minutes and I immediately fill it with another task, another branch, another proposal, another Teams message, another "quick thing," then what did I actually save? Time was saved at the task level. It was not saved at the human level.
A United Nations University C3 piece on "The AI Productivity Paradox" points to the same issue from another angle. Workers report time savings, but about 80 percent of those saved minutes get reassigned to more job tasks. Only a small share of the productivity gains shows up as higher earnings for workers.
That is the uncomfortable part. We are doing more, and the day is not always getting better.
If you build software, the numbers get specific and uncomfortable. AI coding tools are really, really useful. I use them. I like them. I do not think we are going back. But I also think we need to stop pretending that generating more code is the same thing as creating better software.
Let me give you both sides of this from my own work, because I have lived both in the same month.
I once spent a 17-hour day hyper-focused on one problem with Claude, going back and forth. Code changes. Recompile. Test. The AI kept attacking the problem from different angles, and there is a lot of recursion when you do AI coding. You get stuck in a loop together and do not realize it until you step out. The next morning, away from the screen, I solved it in five minutes.
Then there is the other side. I had a HubSpot production integration break in a React project. No React developers available. I am not a React developer and never will be one. The AI reviewed the entire codebase in about 25 minutes and found the fix. One line. I would not have found that without it.
So I am not here to tell you the tools do not work. Sometimes they save you. Sometimes they burn an entire day generating plausible wrong answers while you chase them. The hard part is that you do not realize which one you are in until it is too late, and either way the hours got spent.
Scientific American recently covered this from the developer angle. AI helps developers release more software, but it is also linked to longer hours, more after-hours work, and more time spent fixing problems after code goes live. That sounds about right, because code generation is not the whole job.
Someone still has to understand the system. Someone still has to check the assumptions. Someone still has to review the pull request. Someone still has to debug the weird edge case. Someone still has to explain why the AI-generated solution technically works but is completely wrong for the architecture.
This is where the Faros.ai "AI Productivity Paradox" report is interesting. Their research says engineering teams with high AI adoption complete 21 percent more tasks and merge 98 percent more pull requests. That sounds amazing until you read the next part. PR review time increases 91 percent. Average pull request size grows 154 percent. Bugs per developer rise about 9 percent.
The bottleneck did not disappear. It moved downstream. Before, the bottleneck might have been writing the code. Now it might be reviewing the code, testing the code, integrating the code, securing the code, deploying the code, or figuring out whether the code should exist in the first place.
That is not an AI failure. That is a workflow failure. And to be quite honest, we have seen this movie before. Every time a tool makes one part of the process faster, everyone gets excited about the fast part and ignores the slow part that just became more important.
There is another thing I have noticed in my own work. AI removes a lot of the easy parts first. That sounds good, and it is good in many cases. But those easy parts were not always useless. Sometimes they were the warm-up. Sometimes they were the part of the work where your brain could recover a little. Sometimes they were the place where you discovered the problem hiding inside the problem.
When AI drafts the first version, you skip straight to judgment. Is this right? Is this wrong? What did it miss? What did it assume? Is this safe? Is this accurate? Does this sound like us? Does this belong in the architecture? Did it invent something? Did it make the code too clever? Did it flatten the nuance? That is valuable work. It is also draining work.
So we need to be careful with the simplistic version of the AI story. AI does not just remove busywork. AI often converts production work into review work, coordination work, decision work, and governance work. In my world, that is where the real pressure shows up.
The junior developer analogy still fits. AI can help. AI can move fast. AI can produce a lot. But you would not let a junior developer push unreviewed work into production just because they typed quickly. Speed does not remove responsibility. It increases the need for discipline.
A pre-AI eight-hour day for me might have looked something like this. Two hours writing a spec by hand. Two hours of implementation. Two hours in meetings. Two hours of admin, with natural pauses while I waited on other people.
A current AI-heavy day can look very different. The spec gets drafted in fifteen minutes, so now I own three initiatives instead of one. Code gets scaffolded quickly, so now I am debugging more edge cases and integration details. Stakeholders see things moving faster, so the "just one more quick thing" pings never really stop. The waiting-on-others pauses are gone, because AI filled them.
The day is busier. The cognitive load is higher. And nobody had to ask me to take any of it on.
A few forces are doing the work here, and naming them is the first step to managing them.
Cheap tasks invite more tasks. That is Jevons paradox in a new outfit. When something gets cheaper to use, we often use more of it, not less. AI made each draft, summary, and refactor cheaper, so we generate more of them. Email did this. PowerPoint did this. The work simply grows to fill the new capacity.
The constraint moves, it does not vanish. Amdahl's Law applies here too. Speed up the easy slice of the work and the slow slice becomes the whole story. AI accelerates production, but a lot of knowledge work is review, alignment, approval, validation, and waiting on other humans.
The organization quietly resets expectations. The first time AI helps produce a proposal faster, everyone is impressed. The third time, it is expected. The tenth time, someone wonders why it is not done yet. Nobody has to announce it. Nobody has to say, "We expect you to work more now." The expectation just creeps in through the side door.
More drafts. More tickets. More experiments. More variants. More reporting. More "can you just run this through AI quickly?" That phrase should scare us a little. "Quickly" is where a lot of bad work gets born. Not because the tool is bad, but because "quickly" often means nobody has decided who owns the outcome. And if nobody owns the outcome, the person using the tool becomes the safety net.
That is how AI creates more work. Not always through the task itself, but through everything around the task.
Most organizations are not designed to give time back. They are designed to consume capacity. If a team gets 20 percent faster, the common response is not, "Great, everyone take Friday afternoon off." The common response is, "Great, now we can do more."
Again, that is not automatically wrong. Companies exist to create value. Teams should improve. Tools should make us better. But let's call it what it is. If AI lets us do more work in the same day, that is productivity. If AI makes us do more work across a longer day, that is intensification. Those are not the same thing.
This is why I think the AI productivity conversation is incomplete. We keep measuring what got produced. We do not spend enough time measuring what happened to the people producing it. Did review queues grow? Did pull requests get bigger? Did bugs go up or down? Did context switching increase? Did senior people become the review bottleneck for everyone else's AI-assisted work? Did after-hours activity rise? Did people actually get time back?
That last question needs to be asked plainly. Not buried in a dashboard. Not implied by a productivity metric. Asked like a real question. Are people getting time back? If the answer is no, then we should be honest about what we are optimizing for.
I do not think the answer is to reject the tools. That would be silly. AI is already part of how many of us work, and in a lot of cases it is genuinely helpful.
The answer is to stop treating AI adoption as a tooling decision only. It is a workflow decision. It is a governance decision. It is a capacity decision. It is a human decision.
When a company rolls out AI coding tools, the question cannot only be, "How many developers are using it?" The better question is, "What happens to the time the tools free up?" Does the person get it back? Does the team use it to improve quality? Does the company turn it into more throughput? Does the workday quietly stretch? That is where the real story is.
I do not have this solved. But here is what I am experimenting with in my own workflow, in case any of it is useful to you.
First, I try to decide where the saved time goes before I start. If AI helps me finish something in 30 minutes instead of two hours, I want to know whether the remaining time is for review, deeper thinking, or recovery. If I do not decide that upfront, the time will get eaten by something else.
Second, I try not to confuse more drafts with more progress. AI can produce five versions of something quickly. That does not mean five versions are useful. Sometimes one thoughtful version is better than five average ones that now need review.
Third, I try to keep humans in the parts of the work where judgment matters. Architecture decisions, client nuance, content voice, security, accessibility, production risk, pricing, scope, and governance. AI can help around those things. It should not quietly own them.
Fourth, I try to watch the downstream bottlenecks. If AI speeds up implementation but slows down review, we did not fix the system. We moved the pain.
Fifth, I am trying to protect some non-AI time. Walks, thinking, conversations, reading without a prompt box open. That sounds soft until you realize that judgment is the main thing we are supposed to bring to this whole arrangement. If we let the tools consume every quiet moment, we should not be surprised when our judgment gets worse.
Here is what I keep coming back to. None of this is only a willpower problem, and you cannot fix an organizational dynamic with individual discipline. If your team ships 21 percent more work and your leaders treat the saved time as found capacity to be reclaimed, no amount of personal time-boxing will hold. The expectations ratchet faster than the habits.
That is why work intensification belongs in the AI governance conversation, not just the wellness conversation. For organizations already building AI policies around privacy, security, IP exposure, compliance, and data handling, this needs to sit beside them. What happens to the saved time? Who absorbs the review load? How do we prevent AI-assisted work from quietly becoming after-hours work? How do we measure quality instead of just volume? How do we make sure the people using the tools are not becoming the safety net for every shortcut the tools create?
The responsible organizations will decide, on purpose, what happens to the time AI frees up before the default answer becomes "more." That is a policy choice. It deserves a policy.
I still believe AI is a force multiplier. But force multipliers need direction. Otherwise they multiply the mess.
That is the lesson I keep learning. AI can make a good workflow better. It can also make a bad workflow louder, faster, and harder to escape.
So the question is not, "Does AI save time?" Sometimes it does. The better question is, "Who gets the time?"
AI did not give us a four-hour workday. In a lot of places, it gave us twelve hours of work that feels like eight because every individual task got faster. That is not the future of work I want by default.
So yes, use AI. Use it seriously. Use it with supervision. Use it with checks and balances. Use it to remove waste. But do not let it silently remove the pauses, the thinking, the judgment, and the human parts of the work. AI is the accelerator. Discipline is the brake. You need both.
That is the part that worries me most. We may not be choosing longer workdays. We may just be failing to protect shorter ones.
Since you started using AI heavily, are your hours going down, going up, or are you just packing more into the same day? And if AI gave you back two hours tomorrow, would you log off, or would you open another board?

Akshay is a ten-time Sitecore MVP and a two-time Kontent.ai. In addition to his work as a solution architect, Akshay is also one of the founders of SUGCON North America 2015, SUGCON India 2018 & 2019, Unofficial Sitecore Training, and Sitecore Slack.
Akshay founded and continues to run the Sitecore Hackathon. As one of the founding partners of Konabos Consulting, Akshay will continue to work with clients, leading projects and mentoring their existing teams.
Share on social media