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 inte...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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
AI didn’t remove cognitive load. It just moved it. From execution to decision-making and decision fatigue compounds in a way that boilerplate fatigue never did.
Three hours of writing configs leaves you tired. Three hours of architectural trade-offs leaves you genuinely depleted. That’s a different thing entirely, and I don’t think enough people are drawing that distinction yet.
Decision fatigue vs boilerplate fatigue: I wish I had put that distinction in the post. Tired from configs is one thing. Genuinely depleted from three hours of trade-offs is something else entirely. You said it better than I did
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
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
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 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
I feel that delivering is possible when you do not check the generated code. I mean, I am sure you spend time to code review what the AI agent generated, right? Right?
And that takes also a significant amount of time, especially when you need why this approach is better than another, and things like that. Unless if that is not necessary any more, and we are happy that the tests pass and we can deliver.
I find the struggles that you described accurate, but I would add that now we need to spend more time per week on reviewing more and more code. Because as developers write faster, more code comes in our plates for checking before deployed.
Code review is the hidden cost nobody puts in the productivity calculation. More code ships faster, but someone still has to read all of it. And review speed does not scale the same way generation speed does
I guess it will take some time for teams and the industry in general to find the right momentum on how to properly balance cognitive load and quality assurance vs asset generation.
As for the load, the SDLC is now more complex as a system, and adding another (AI) layer makes it trickier to process. On the other hand, code generation has gotten cheap, so we can loosen our attention here, at least for basic cases. Or it's a risk of piling up "congnitive debt"
What works for me is to be more picky about what I want to focus on, and once I'm too deep into a feature or decision, to step back and let it "settle" while I mentally offload and shift my attention to something else
Stepping back and letting it settle that is so underrated. The urge to push through is strong, but the answer usually shows up on its own when you stop forcing it
Great take. AI speeds up some tasks but reveals gaps in our mental models. The win: clear specs, sharper prompts, better tests, and a human in the loop to sanity-check the outputs.
So true .! Clear specs and a human sanity-check are still non-negotiable 😄
AI just helps you build the wrong thing faster if you are not careful .!
I have no tech background so I cannot say much about the topic.
But I have lots of questions
Could it be that there is not yet toolsbox for AI era mental work?
For example "deep brainstorming using tracer pullet approach on architecture"(I got the idea of the "tracer pullet" from book called pragmatic programmer warmly recommend reading it got me understanding what programming was about I wish I had read it before I ever wrote single line of code)
There is DDD and TDD (I just recently found out about them) but AI era might need something else "they were think a lot ahead the curve and far away from different kinds of sme" but now you can get access to sme in an one prompt.
Also the documentation has not caught up with AI era.
From now on documention needs to be more expressive AI can update it and summarize sections with snap of finger so keeping it succinct is counter productive.
Also I would guess without any reason documentation should be main debugging source.
All above is fragile because AI hallucinating turns it useless but it might be useful.
Really appreciate these questions, and honestly they are better than most comments from people with tech backgrounds 😄 You are right that the toolbox has not caught up. DDD and TDD were built for a slower world. The docs point is spot on too; keeping things too short makes no sense anymore when AI can summarise anything instantly. Lots of the old rules need rethinking now 🙌
A wise man once said: "IF YOU WANT TO BE FAST, GO SLOW!"
And somehow that's the one lesson the whole industry keeps forgetting 😄 Slow down to understand, speed up to deliver. Not the other way around.
Matches what I saw running four agents for a week. The easy parts collapsed to nothing - boilerplate, getters/setters, simple migrations. But the hard parts got disproportionately harder, not easier. Making three agents converge on the same data model, handling rollbacks when one of them was 4 minutes ahead of the others - those took more wall-clock time than they would have without agents. The total system was harder even though each task individually was easier.
Ha, this is exactly it 😄 Each agent doing its own thing perfectly, and then you spend twice the time just getting them to agree with each other. The individual parts get easier, but the whole thing somehow gets messier. And you only notice when you are already deep in a rollback wondering where it all went wrong 😅
The idea that losing the "boring 80%" means losing those natural cognitive recovery cycles. The caching bug example illustrating "understanding debt" is such a perfect, relatable warning. I also really appreciate your practical advice about protecting deep work and knowing when not to reach for AI. Thanks for putting this out there — it’s a refreshing and much-needed perspective.
Really glad it resonated 😄 Thanks for reading and for the kind words 🙌
AI accelerated coding, but architecture, scalability, security, and product thinking are now more critical than ever. Businesses need experienced engineering teams that can turn AI into real business value not just generate code. That’s where ValueCoders helps companies build smarter, scalable software solutions.
The distinction worth preserving is between two kinds of "80% work": boilerplate that's genuinely mechanical (format conversion, output parsing, integration glue) and boilerplate that builds understanding through productive friction (writing tests manually, tracing data flow, reading source). The first kind is worth automating. The second shouldn't be — and your caching bug story illustrates exactly why. The problem isn't that AI removed the 80%; it's that it removed both types indiscriminately, and the comprehension debt accumulates quietly until you hit a failure you can't debug because you never understood the system. The most useful discipline right now might be deliberately choosing when not to use AI — using the slower path as a tool for building genuine understanding, not just as a fallback when the model fails.
This made me see my own post differently 😄 I kept treating the 80% as one thing - but you are right, it never was. Some of it was just noise, but some of it was quietly teaching you the system. The caching bug was exactly that. AI didn't fail; I just skipped the part that would have made me understand. Good distinction 🙌
This:
"Sometimes writing code slowly is what helps you understand the system"
That's why I'm advocating "right and left" (in comments here on dev.to) to still write some code manually ...
Exactly this 😄 Writing it slowly is the whole point sometimes. You notice things you'd completely miss otherwise. Glad someone else is pushing for this too .!
"Writing it slowly" - nice!
somehow true, somehow false
This resonates a lot from a security perspective. The speed AI enables doesn't shrink the attack surface, it widens it. The gap between "shipped" and "audited" grows with every sprint, and most teams don't feel that until something breaks badly.
Pentesting used to catch issues that built up slowly. Now that accumulation is on fast-forward and nobody's slowing down to check.
Your point about knowing when not to use AI is spot on. Auth, permissions, data isolation, payments -> write it yourself, read every line, own it before it goes to prod. The two hours you save are not worth the breach disclosure email. 🙌
The security angle is something I did not cover, but you are so right. Speed without review is just technical debt with a shorter fuse. And you said it perfectly - auth, payments, data isolation, write it yourself. Those are the places where
it looked fineis the most dangerous sentence in engineering. The breach disclosure email is a really good way to put it. That two hours saved can cost months.The debugging complexity point hits hard. When I first added an AI pair-programmer to my workflow, I thought the bottleneck would be code generation quality. Turns out the real problem is that AI writes code confidently at a layer above your debugging tools. Stack traces reference generated abstractions you didn't fully understand, and the mental model gap slows you down more than writing it yourself would have.
What I've noticed specifically: AI excels at boilerplate and common patterns, but it compresses understanding in a way that backfires when something breaks in production. You're debugging behavior you didn't trace through mentally during authorship. The hard parts — concurrency, state management, edge cases under load — got harder because you now own code you didn't fully internalize.
Does your team have explicit conventions around AI-generated code review depth? Or has the review process adapted organically?
The 80% grunt work wasn't just grunt work — it was low-stakes learning time. You built intuition about the codebase while doing boring stuff. With AI handling that layer, juniors skip straight to the hard parts without the muscle memory. The real question isn't "can AI do the work" but "does the team still understand the system after AI did the work."
The 80% → 0% flip you're describing is right, but what makes it hard is that the skills required for the remaining 20% are qualitatively different from what built the 80%. Execution rewarded consistency, pattern recognition, accumulated templates. The thinking layer rewards judgment, taste, knowing when to stop — skills you don't build by doing more execution.
Most engineers never had to develop those explicitly because execution filled the day. The tools didn't just remove the grunt work — they made a latent skill gap visible overnight. A lot of the "AI made me worse" reports I see aren't about AI degrading people. They're about people discovering the gap was always there, just hidden under volume.
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 operational complexity of AI features compounds fast if you don't put guardrails in early. We got a Slack alert at 5 PM on a Friday showing our OpenAI org bill projecting $14k over budget. I tracked it down to a single team that shipped a feature calling Claude on every keystroke for an autocomplete function. We deployed per-team rate limits in our LiteLLM gateway the same evening. The hard part of software engineering now is putting guardrails around non-deterministic, expensive APIs. And most teams discover the need for them only after the first billing surprise.
The "comprehension debt" framing in your data-fetching example matches something we see on the audio side at AudioProducer.ai, where the deliverable is audio rather than text and the comprehension cost shows up even harder. Authors run Auto-Assign on a chapter, the AI tags every line with a speaker and the audio renders cleanly, and the writer's mental model of the cast structure never gets built; three chapters later when a minor character returns and the voice is wrong, they don't know which line was the character's first appearance to fix. You can't grep an audio file, so the recovery path is text editor mode plus per-line re-tagging, which is the slow path that builds the instinct AI just skipped. HR Pulsar's "training data for humans" point lands the same way here: the old 80% of hand-tagging dialogue was annoying but it was how writers learned to see their book as a cast structure rather than a stream of prose. We've started thinking of the text-editor-mode toggle as the deliberate-slowdown surface, not the productivity tool, because it's the only place where the writer can refuse the speed and stay in contact with the manuscript.