When I started using AI tools seriously across my side projects, I expected the work to get easier. AI handles the boilerplate, I focus on the interesting parts. That was the promise.
It didn't get easier. The interesting parts got harder, more frequent, and more exhausting.
I am not alone in this. A Google Staff Engineer recently went viral for leaving the company - not for pay, not for perks, but because the work had become rushed and less meaningful. AI was being pushed into places it did not belong. He was getting paged at 2am. He wrote: "I don't want to be just another execution arm for someone else."
If this is happening at Google - one of the most technically capable organisations on the planet - it is worth asking what AI is actually doing to software engineering. Not in the press releases. In practice.
Here is what I think is really going on.
The job used to be 80% execution, 20% thinking
For most of software engineering's history, the job broke down roughly like this:
The 80% - Execution
- Writing boilerplate code
- Fixing repetitive bugs
- Moving tickets and updating docs
- Setting up configs and environments
- Writing tests for known behaviour
The 20% - Deep Thinking
- Understanding the real problem
- Designing systems under constraints
- Debugging edge cases nobody predicted
- Making trade-offs with incomplete information
- Knowing what not to build
The 80% was the grunt work. Necessary, but learnable. The 20% was where experience actually mattered - where a senior engineer earned their title not by typing faster but by thinking clearer.
AI ate the 80%. Now the 20% is the whole job.
Tools like Claude Code, Cursor, and GitHub Copilot are genuinely excellent at the execution layer. Boilerplate? Gone. Standard CRUD endpoints? Done in seconds. Repetitive tests? Generated before you finish your coffee.
The narrative was: this is great news. Engineers freed from boring work can focus on interesting problems.
And in one sense, that is true. But here is what nobody said out loud:
The 20% was hard precisely because it required sustained, deep focus. Now engineers are expected to live there permanently - and the human brain was not built for that.
The 20% has become the new 80%. And it is exhausting in a completely different way than the old 80% ever was.
Writing boilerplate for three hours is tedious - but your brain recovers. Spending three hours designing a distributed system's failure modes, making architectural trade-offs, and debugging a race condition that only appears under specific load - that is a different kind of tired. And AI is not reducing how often you have to do it. It is increasing it.
Nobody is talking about the human context window
There is a conversation happening constantly in the AI world about context windows. How many tokens can the model hold? How do we optimise retrieval? How do we make sure the model has the right information at the right time?
It is a completely valid engineering problem. But there is another context window nobody is talking about.
⚠️ The human engineer's context window is not growing. It is the same brain it always was - now expected to hold more architectural complexity, make faster decisions under uncertainty, and context-switch between systems more frequently than ever before. Unlike the model, you cannot just upgrade to a longer context. You cannot add more RAM to your prefrontal cortex.
The Google engineer described being paged at 2am, unable to go back to sleep until 5-6am. That is not a productivity problem. That is a cognitive load problem. And it is becoming the norm, not the exception.
I feel this every single day
I am not speaking theoretically. I work with these tools daily across my five side projects.
The productivity gains are real - I ship things faster than I ever have. But the cognitive load is also higher than it has ever been. Every hour I save on execution goes straight back into harder thinking. Last week I spent a full afternoon on a single architectural decision about how to handle shared state across five products in my monorepo. That decision used to take days because the execution work around it gave me natural thinking time. Now the execution is instant - and the thinking time has to be deliberately carved out or it simply does not happen.
I am not writing less code. I am making more decisions. And decisions are the expensive part.
What this means practically
Protect your deep work time more than ever. When AI handles the shallow work, shallow interruptions become proportionally more damaging. A Slack notification that cost you ten minutes before now costs you an architectural decision. I now block two hours every morning before I open anything AI-related.
Get comfortable saying "I need to think about this." The speed AI enables creates pressure to decide faster. Resist it. Treating "let me think about this properly" as a professional response, not an admission of slowness, is one of the most underrated skills right now.
Treat cognitive recovery as part of the job. The old 80% gave your brain natural rest - switching from deep thinking to routine execution was recovery in disguise. That rest is gone. Deliberately ending deep work sessions with something low-stakes makes a real difference.
Know when not to use AI. Sometimes writing code slowly is what helps you understand the system. I once let AI generate an entire data-fetching layer for one of my products. It looked clean, it passed my quick review, and I shipped it. Three weeks later I hit a caching bug I could not debug - because I had never actually understood how the layer worked. I spent two days fixing something that would have taken two hours if I had written it myself. The comprehension debt is real and it shows up at the worst time.
The honest question
The Google engineer said the work had become rushed and less meaningful. I do not think AI made it less meaningful - but the pace it enables can make it feel that way if you are not careful.
And here is the question I keep coming back to: the 20% that is left - system design, trade-offs, debugging under uncertainty, knowing what not to build - this used to take years to develop. Junior engineers built it gradually, on top of the foundation the 80% of execution work gave them. That foundation is now disappearing fast.
AI is not replacing engineers. It is compressing the timeline of everything an engineer has to do. Whether that is a gift or a burden depends entirely on how deliberately you manage what is left.
Are you finding the work more demanding since AI tools arrived, or genuinely easier? And what is happening to the junior engineers on your team - are they getting the foundation they need, or being thrown into the deep end before they are ready?
Top comments (73)
I'm finding work generally much easier and the ability to deliver significantly increased. The dopamine patterns are totally different and I think that can mean you "try too much". I also think the massively increased output puts much more stress on other parts of a business (like sales, marketing, ops).
Why did the Google engineer get paged at 2am? That wasn't an AI issue, that was a Google strategy and resourcing issue.
Glad it feels easier for you .! But I think the real cost shows up later - more output means more surface area to maintain, more regression to catch, more edge cases nobody thought about at speed. The delivery feels faster but the tail gets longer. That is where the exhaustion quietly builds up.
It's easy nowadays for junior developers to leave the 80% work to AI, because honestly, who is reading all the AI code especially if it's too long. That's why it is much better to at least try a work that's part of the 80% again and again until you've mastered it. That knowledge will stick, trust me.
It's the same scene from Spiderman:
Peter: "This is all I have! I'm nothing without this suit!"
Tony: "If you're nothing without this suit, then you shouldn't have it."
If you depend on AI too much as someone starting out then you are intentionally hindering your own growth.
Great and relevant quote !
Tony: "If you're nothing without this suit, then you shouldn't have it."
The Spider-Man quote 😂 That's it. That's the whole debate. If the suit disappears tomorrow, can you still swing? That's the real question for every junior dev right now.
I've found the reality to be a lot more messy. A lot of the 80% is still there, and there are also new things there. I still have to:
That said, the key point is of course directionally true that AI is changing the composition of the job, and in a way that can make it harder. I've found everyone is expected to multi-task a lot more now, which is exhausting for most people. I've always found there to be a certain zen in quietly writing code line-by-line, and that is, indeed, mostly a thing of the past now. In fact that's always been my favorite part of the job. Not the "interesting problems", but just chilling with coffee, good music, and tapping on my keyboard. I do mourn the loss of that.
The zen of coffee, music, and just quietly typing I miss that too 😄 And you're right, the 80% didn't disappear. It just got louder. Re-prompting, reviewing, re-prompting again. Different kind of tired
"I've always found there to be a certain zen in quietly writing code line-by-line, and that is, indeed, mostly a thing of the past now. In fact that's always been my favorite part of the job."
💙 Mine too.
This nails something I see from the security side. The 80% AI absorbed was the writing; the 20% that's left — and now harder — includes auditing code you didn't write for the things it silently didn't do. That's more exhausting than writing it yourself, because plausible-looking code hides absent constraints. We benchmarked it: 63% of AI-generated functions had a security finding, and the misses were almost all "negative space" — auth checks, input validation, the hardening the prompt never named. Reviewing for what isn't there is a harder cognitive task than writing what is. Your 80/20 framing is the cleanest articulation of why "AI makes us faster" and "the work feels harder" are both true at once.
That 63% stat is wild - and honestly scarier than I expected. The 'negative space' framing hits perfectly. AI never knows what it does not know, so it writes code that looks complete but skips the invisible stuff like auth checks and edge cases. You basically have to hold the full mental model yourself just to review it properly. Makes me think the bar for senior engineers who actually understand security just went way up.
Thanks for sharing this from the security side - really adds to the point.
The issue is much more severe than outlined. AI Coders, which I refer to as the modern edition of the "compilers" concept, definitely accelerate code creation - but it is al built on top of libraries and frameworks developed by true coders - those trained via old school methods. These guys are disappearing slowly, and AI Coders will continue generating code based on 2020 techniques and libraries in 2030!. We will then realize that statistical imitation machines (read "AI Coders") will halt software innovation and, after a peak of seemingly "amazing productivity," will create chaos and stagnation.
Unfortunately, I am not a "true software engineer," and I cannot code the next amazing React. So I enjoy the current hype and convenience to make a living and create useful tools. When users realize that these tools (CRM, bits, ...) are not enough and will look for major advancements, no one will be able to respond.
The point about AI only being able to generate from what already exists is something I had not thought about but it is genuinely worrying. Who builds the next layer?
True coders who create new foundational technologies, such as frameworks and stacks like React, will become rare and controlled by 3-5 large corporations. The rest will let AI continue coding with what's available, which means no competitive advantage from code as we used to have. Over time, it will slow down innovations as big corporations tend to reduce spending on public tools (see: Google sending home the entire DART team).
That's a scary but realistic picture. Everyone is busy generating CRUD apps faster, and nobody notices until they need something genuinely new and nobody can build it
the PM side of this is worse. agents generate a sprint's worth of code in hours, but every spec now needs to be bulletproof or they go sideways. my review queue doubled after adding 3 agents to one codebase.
The PM angle is real and nobody talks about it enough. Agents generate fast, but the specs have to be bulletproof, or everything goes sideways. You did not save time, you just moved the effort upstream. Review queue doubling is the proof 😅
exactly — and the spec authoring muscle is different from standard PM writing. you need to pre-cover edge cases, agent failure modes, rollback triggers. most product people are building that skill under fire right now. the review queue doubling is just the cost of that gap while teams catch up.
Building that skill under fire that is exactly it 😄 Nobody got trained for this, everyone's just figuring it out in real time. And the gap only shows up when something ships that really should not have 😅
yeah, and the training material is usually a post-mortem doc that nobody wants to write but everyone reads twice
This is the part of the AI discussion that feels massively underexplored to me: can engineers still become really good at the hard 20% if they stop regularly doing the repetitive 80% that historically built the experience in the first place?
Because that “boring” work wasn’t just labor. It was training data for humans.
If AI removes too much friction too early, we may accidentally optimize away the path that creates senior engineers.
This one really stuck with me. That repetitive work wasn't just boring; it was how you built instinct. You learned to spot bugs, understand systems, and think ahead by actually doing the slow stuff first. If juniors skip all of that, they will have gaps they won't even notice - until something breaks in production and they don't know where to start. AI might actually be harder on new engineers than on experienced ones. The ladder is disappearing while they're still trying to climb it.
I'm completely with you on the value of boring! And as a matter of fact I like boring tasks: as you said, it helps makes mine the codebase and is also when my brain can go to rest. During semi-automatic refactoring and code cleanup, I get rest, uncover sometimes bugs and overall enjoy the satisfaction of leaving some part of the code better than it was. And you're very right, this is by doing this kind of 'easy' tasks (and reading other's code) that one gains experience.
This is such a refreshing take 😄 Most people complain about boring work, but you actually enjoy it - and you are right, that is where the real learning hides. The brain resting while the hands work is underrated. And finding a bug during a cleanup session feels way better than finding it in prod 😅
Also — the story about the Google engineer getting paged at 2AM isn’t really an AI problem to me. That’s bad corporate culture and broken communication boundaries wearing an AI-shaped costume.
A lot of companies would happily turn any productivity tool into an excuse for permanent urgency. AI just exposed it faster.
So yeah, I fully agree with your point about automation shifting work from routine execution toward high-cost decision making. But that’s also a labor ethics and regulation question now.
Feels like this is the real challenge for our generation:
adapt fast enough to survive the shift, while still making the new reality livable for actual people — not just AI vendors and enterprise slide decks.
Yeah, the 2AM paging was never really about AI, that is just a company pushing hard and calling it normal. AI just made it easier to justify. But your point about making the new reality livable, that's the bit most people are ignoring. Everyone's talking about how to adapt fast enough. Fewer people are asking whether the pace itself is sustainable. That feels like the more important conversation right now
Maybe I’m just getting old, but the pace for the last 5–10 years feels borderline unsustainable 🙃
A lot of people don’t want to spend their entire lives endlessly re-optimizing themselves for the newest stack, framework, AI tool, productivity ritual, and corporate trend cycle. Some people just want to do good work, live comfortably, and not feel like a replaceable productivity horse in an infinite benchmark race.
I think that’s a pretty human response to an industry that increasingly treats exhaustion like ambition.
You are not getting old, I think a lot of people feel this way but don't say it because it sounds like complaining 😅 But wanting to do good work and actually have a life isn't a weird ask. The industry just made constant self-upgrading feel like the default. And at some point, you have to ask - upgrade for what exactly? 🤔 A career should be something you can actually live in, not just survive.
Spot on. The part about AI making the hard parts harder really resonates. One of those hard parts that most people are not talking about yet: trust.\n\nAs AI agents proliferate - writing code, making decisions, interfacing with production systems - how do you know an agent is worth relying on? We have mature tooling for code-level trust: npm audit, pip-audit, Snyk, Dependabot. But there is nothing equivalent for the agent layer. An agent can pass all its unit tests and still be inconsistent in production, silently drift from its documented behavior, or be maintained by someone who abandoned it months ago.\n\nWe are building AgentRisk to address exactly this - a multi-dimensional trust scoring framework for AI agents. Think of it as the npm audit for agents: you should not deploy an agent you cannot verify.\n\nThe hard parts are only going to get harder as agent ecosystems grow. Trust infrastructure needs to be part of the foundation, not bolted on after the first incident.
The trust layer is a real gap nobody's talking about enough. Code audit tooling is mature, agent audit tooling is basically nonexistent. That's going to catch a lot of teams off guard
Exactly. The pattern is familiar - we went through the same maturation with open source packages. Nobody thought about supply chain security until incidents forced the issue. Agent trust will follow the same trajectory, just faster and with higher stakes because agents act autonomously.
The teams building agent-heavy workflows right now are essentially flying blind on the trust dimension. That is not a sustainable position when your agents are touching production systems and making real decisions.
This hits exactly right — especially the point about cognitive recovery time disappearing.
The old 80% wasn't just grunt work. It was thinking time in disguise. Writing boilerplate gave your brain space to process the harder problems in the background. Now that buffer is gone and people don't realize it until they're burned out.
The comprehension debt point is something I've felt personally. Letting AI generate something you don't fully understand feels like a shortcut until you're debugging it at midnight with no mental model of how it works.
The junior engineer question is the one that worries me most. The foundation used to be built gradually through execution work. If that's gone, how do you develop the judgment to know when AI is wrong?
Midnight debugging with no mental model that is when the bill comes due 😅 And yeah, how do you know when AI is wrong if you never had to figure things out the hard way first? That is the question 🙌
The "low-intensity recovery time" framing is what really lands for me. The old 80% wasn't just busywork — it was rumination time. Renaming variables kept my hands busy while the back of my brain quietly worked on the actual hard problem. By the time I got back to the design question, I often already had the answer.
That ambient processing is what disappears with AI, more than the typing itself. You don't just lose the rest — you lose the thinking that was happening during the rest. Then you're surprised that sitting down to "do the interesting 20%" feels harder than it used to, because you're trying to do cold what you used to do warmed up.
Has anyone found a deliberate way to recreate that in-between time? Feels like the next skill, not just "protect deep work" but "manufacture the recovery."
Ambient processing that is the best way I have heard it described. You weren't just typing boilerplate, the back of your brain was quietly solving the hard problem. Now you sit down cold and wonder why it feels harder than it used to. 'Manufacture the recovery' is the next thing to figure out
Some comments may only be visible to logged-in visitors. Sign in to view all comments.