Will agentic engineering kill deep work? (part 3)
Summary
In part three of this three-part series, I continue to argue against the agentic-engineering theory that predicts the end of deep work. Continuing from parts one and two of this series, I conclude that the case against deep work is flawed for three more reasons:
It ignores the true bottlenecks in software delivery
It even ignores executives with a counterview
And finally, it ignores people’s core motivations for knowledge work
By now, I’ve written two articles challenging the following notion,
“Future software builders and engineers must do less deep work and be ready for more interruptions as they orchestrate their agent army.”
In parts one and two of this series, I argued that the above premise:
doesn’t recognise the limitations of AI;
falls prey to marketing from the AI labs;
oversimplifies the workflow from said marketing;
ignores the sceptics;
dismisses the growing AI backlash;
and ignores the true costs of generative AI.
In this final instalment, I want to conclude my arguments. Here are a few reasons why the bull case for agentic engineering is flawed.
7. It ignores the true bottlenecks in software delivery
Look at the most common applications around you. Take Google Workspace, for example. For a minute, ignore the bolted-on generative AI features in any of these applications. Those are like plugins. Plugins are cute and have existed forever, but they don’t improve the core experience.
If AI is so amazing, why aren’t any of these platforms improving at a rapid pace? Google Slides is still the suckiest presentation tool in the universe. Can’t Google use its coding agents to bring Slides on par with Keynote, PowerPoint, or Canva? Why is Google Chat so much worse than Slack? Why isn’t Google Meet a patch on Zoom? Repeat that question for every application that sucks. They continue to suck regardless of generative AI.
Of course, coding agents are excellent at building prototypes. They’re terrific for going from zero to one and often, from one to a hundred. Working with established codebases, however, is a different challenge. That challenge may explain why Google has created Stitch, Jules, Antigravity, AI Studio, and several other new tools, but has left Google Workspace to languish.
Rob Bowley wrote a post in January this year, reminding us of a 2009 sticker showing monkeys typing on a keyboard, with the caption “Typing is not the bottleneck.” Indeed, many extreme programming practices, such as TDD and pair programming, may have slowed down coding to avoid downstream bottlenecks.
Software delivery is a complex beast. Think about the applications you use. Apart from the esoteric use cases only you care about, you have all the software you need. There are few new problems to solve. The market for greenfield products is shrinking every year. That’s why 90% startups fail! In a saturated market, figuring out what to build is often the hard part. Add to it operational bottlenecks, organisational politics, architectural complexity, user readiness and change management, and you’ll realise that writing code is the easy part.
Faros.ai has reported an AI productivity paradox across 2025 and 2026. Outputs are up, but production quality is declining. In their dataset, there’s a 58% increase in monthly incidents and 54% increase in bugs, although each developer is completing 66% more epics. It seems that Fred Brooks was right all those decades ago — there’s no silver bullet. But, you know, we needn’t go as far back as Fred. Even amongst executives, there are voices of reason.
8. It ignores executives with a counterview
It’s easy to say that there’s a disconnect between executives and technologists. I don’t think it’s as black and white. Many technologists welcome AI as a force multiplier, but dislike executives buying into marketing hype. And several executives challenge the AI psychosis we’re experiencing today, too.
It’s fair to say that Mitchell Hashimoto, founder of Hashicorp, knows a thing or two about technology. He was part of the team that built many well-loved technology products, like Vagrant and Terraform. Ok, he’s technically not an executive anymore, but only a pointy-haired executive would say that, right? Not you.
Now, Hashimoto has embraced AI as well as anyone else. However, he prefers running agents in the background while he focuses on deep work. He finds that he can focus his coding and thinking on tasks he loves while also completing those he doesn’t enjoy.
A few days back, Hashimoto wrote on X that “entire companies right now are under heavy AI psychosis and it's impossible to have rational conversations about it with them.” He worries that, by being over-reliant on agents,
“…you can automate yourself into a very resilient catastrophe machine. Systems can appear healthy by local metrics while globally becoming incomprehensible. Bug reports can go down while latent risk explodes. Test coverage can rise while semantic understanding falls. Changes happen so fast that nobody notices the underlying architecture decaying.”
Mitchell isn’t the only founder or executive raising concerns about AI psychosis. Take-Two CEO Strauss Zelnick is “all-in” on AI, but he realises that AI can create clones, but it can’t create the next big hit. Zelnick has a cogent argument:
Generative AI is three things mushed together — LLMs, lots of compute and big data sets.
Big datasets are backwards-looking, so LLMs can interpolate across those datasets and create clones of existing products.
In contrast, creativity is forward-looking and needs extrapolation. To create a hit game like Grand Theft Auto, you need extrapolation, which an LLM can’t provide.
Here’s how Zelnick dropped the mic.
“You know how many mobile games get put out a year? Thousands. You know how many hits are made in a year? Zero to five. You know who makes them? We do. This is just true. We don't need this new technology to create assets that are competitive. That already exists. It will be quicker to do it. But speed isn't the issue.”
Speed isn’t the issue. Let those words from an executive sink in, as we take our attention back to the poor old knowledge workers.
9. It ignores people’s core motivations for knowledge work
Two years back, I wrote an article about the inherent human desire to create. I create photographs after hours of toil, not because they’ll be hits or because LLMs are incapable of generating images for me. You could argue that my real-life photography struggles will result in images that are more random than an LLM’s output. But getting an image from a generate button doesn’t offer the same gratification as making one in the field — the more the struggle, the higher the gratification.
Many of us knowledge workers took to IT because it offered the same sort of gratification. You could interact with a computer using a cryptic coding language and UNIX terminal commands. If you organised the language in the right way, you could open the computer’s puzzle box and have it do your bidding. This process wasn’t easy. There was a messy way to do things, and then there was an elegant way. By choosing elegant options, we elevated our emotional connection to our craft.
That emotional connection was important. It reinforced autonomy, mastery, and purpose in Dan Pink’s theory of motivation. Take away that emotional connection, and knowledge work becomes a routine, meaningless, soul-sucking, button-pressing activity. It won’t be surprising then, if employees treat their jobs like emotionless transactions. If that’s what you want, then sure – take away the deep work.
None of this is to say that we shouldn’t employ coding agents or LLMs. For decades, programmers have found ways to make coding less laborious. You could say that LLMs are a step in that direction, their probabilistic nature notwithstanding. Efficiency is something most developers welcome. But advocating for shallow work and days full of mindless context-switching between agents is problematic for all the reasons I’ve explained in this series of articles.
We need workflows that allow for more, not less, of that puzzle box gratification. More of that tinkering, problem-solving and deep work. Everyone wins. You build software better. Your customers benefit from AI-powered productivity gains (while you can afford the AI). Your workers gain from a meaningful, stimulating job. Why wouldn’t you choose this option?
As I conclude this series, I do want to sound another warning. Big tech seldom keeps people’s best interests at heart. Between social media, crypto, the metaverse, and other grifts, all they’ve cared about is the next funding round, the next earnings call, or maximising shareholder value. Enshittification is the end state, and it’s not accidental.
Meanwhile, the benefits of any technology are not evenly distributed. Boris Cherny may well be shipping 30 pull requests a day. Andrej Karpathy could well be all-in on his agentic workflow. Linus Torvalds may not write a single line of code anymore. But their mileage will vary from yours because their context is different. Their motivations, infrastructure, skills, and the politics surrounding their work could all be different. Everything they say or do will not apply to you, your people, and your world.
It’s one thing to say that your workers must show judgment, taste and discernment. By the same token, your job as an executive is to show an even higher degree of discernment. Discernment that separates news from the hype. You need taste to know when to extrapolate rather than interpolate, and to tell a hit from a clone. And finally, you need the judgment to see through technology grifts and make the right choices for your customers and your people. No AI will upend that job!