I have a feeling this statement is even more true in the age of AI and coding agents. Sure, today we often write prompts instead of code. But if we...
For further actions, you may consider blocking this person and/or reporting abuse
I never really felt to be one of those matrix hackers. As a frontend developer, too often dismissed as not doing real programming ("CSS is not a programming language" and JS or P** neither) and I even dare to prefer light mode editor schemes. I stare at browser developer tools more often than at source code. Maybe AI rarlely boosted my productivity 10x. But the code it spat out definitely needs debugging. But that just shifts the time I spent reading documentation, GitHub issues and StackOverflow asnwers to arguing with AI before double-checking official documentation anyway.
I spend a lot of time thinking, researching and planning, but debugging as well. I also adopted maintenance of legacy code not written by myself for several customers. So I'm becoming more and more of what you wrote:
Exactly, that’s pretty much what it looks like after a few years in the industry 🙂
A lot of the job becomes thinking, investigating, reading other people’s code, and figuring out why something behaves the way it does. And honestly, who knows, maybe these are actually the most powerful skills in the age of AI. Generating code is getting easier every year, but understanding systems and fixing what breaks is still very human work.
The only thing I truly can’t understand is the light theme for an IDE 😅
Although… to be fair, one of the best programmers I’ve ever worked with also used a light theme. So who knows, maybe that’s actually a sign of genius. xDDD
This hits different in 2026 with AI everywhere!
I've been thinking about this a lot lately with AI generating so much code, the ability to actually understand what's happening, debug it, and fix it when it breaks is becoming THE superpower. Anyone can generate code now, but not everyone can debug it.
The Matrix analogy is perfect 😂 Though my reality is more staring at console.logs for 2 hours than cool hacker vibes.
Question for you: How do you personally practice/get better at debugging? Would love to hear your approach!
Thank you so much for the comment! I really appreciate it 😊
And honestly… I don’t have any special exercises for debugging. For me it’s mostly just everyday reality at work. Bugs appear, something behaves strangely in production, something breaks after a dependency update — and you simply have to start digging.
Over time you just get used to investigating things: checking logs, tracing the flow, isolating variables, testing hypotheses. I guess debugging is one of those skills that mostly comes from experience and from seeing many different kinds of problems.
So my “training method” is basically: working as a developer every day 😅
Hi, Harsh!
You've described 2026 perfectly! We've built Etiq for this exact reason: AI is generating code, but it's hard to understand it. Etiq generates a lineage to make your code easier to be understood, it recommends testing and verified fixes. We are looking for product testers and we're ready to give free subscriptions. It will make debugging so much easier.
Another great article! You are basically exposing our biggest industry secret here. Writing code nowadays is mostly just aggressive copying and pasting, or asking an AI to do the heavy lifting. The real job is spending the next four hours staring at the screen, questioning all your life choices, trying to figure out why that copied code absolutely refuses to work. 😂 Always a pleasure reading your stuff.
Hahaha, exactly! Especially the part about staring at the screen and questioning all your life choices. 😂
And sometimes it gets even better: you spend an hour investigating why something doesn't work for someone… only to discover they installed the wrong version or forgot to update something. 😅
Oh, the classic 'it works on my machine' trap. Spending half a day deep-diving into the codebase only to find out they never actually updated their environment, or simply forgot to clear their cache, is a very special kind of pain. I think we need to start billing for emotional damage when that happens.😂
I agree with the core idea, but I think the deeper skill behind debugging is system understanding.
Modern software isn't just code anymore. It's a combination of services, APIs, queues, background workers, cloud infrastructure, authentication layers, and external integrations. Most bugs don't live inside a function — they live between systems.
In my experience, debugging usually means answering questions like:
Why did this request succeed locally but fail in CI?
Why does the queue worker process the message twice?
Why did the email confirmation arrive 40 seconds later?
Why does the WebSocket event fire before the DB transaction commits?
Those problems aren't solved by writing code. They're solved by tracing flows across the entire architecture.
Interestingly, this became very obvious while building a side project recently — a programmable temporary email infrastructure for developers and automation workflows. The code itself wasn't the hardest part. The real challenges were things like:
handling SMTP ingestion correctly
synchronizing inbox updates in real time with WebSockets
dealing with race conditions between email reception and API polling
designing expiration workers that don't delete active inboxes
Most of the work ended up being debugging distributed behavior rather than writing new features.
If anything, AI tools will make the "copy-paste coding" part even easier. But when a production system behaves unexpectedly across multiple services, debugging and architectural reasoning are still very human skills.
That's where senior developers spend most of their time.
Exactly! That’s a great way to put it. Thank you for such a thoughtful and clarifying comment!
I completely agree that the real skill behind debugging is understanding the whole system. Modern software is rarely just a piece of code anymore — it’s a network of services, infrastructure, queues, integrations, and timing issues between them. Many bugs don’t live inside the code, but somewhere between those moving parts.
And you’re absolutely right: the only way to debug those kinds of problems is to understand how the entire system behaves and how data flows through it.
Thanks again for expanding on that idea — this is a really great perspective. 🙂
I disagree with this, because right now, at the dawn of the AI era, the opportunity has opened up for a senior (1969 - at least that's what I am according to my age) developer to tackle problems that he didn't dare to tackle before, because his knowledge in the given field was lacking. However, the ideas may have been formulated in him for a long time, and now, as a senior, he knows exactly how to control the agents and what discussions will help him achieve his goal, which if it's a problem that hasn't been addressed before, or hasn't been addressed from that approach, then it could be a program built on completely new foundations.
Just so I don't talk into the air, here are my two most recent challenge submissions:
This one is about a laxy lines fill area calculation problem, realized by rust-wasm
This is a base problem of a modern online vector based drawing appllication, if you search them, you don't found one which is lighweight enough and free. Only the large vector editor have this functionality but that price is high.
dev.to/pengeszikra/rustroke-wasm-m...
Other one is much-much lazy problem: Can I hide a RPG game in a news page?
dev.to/pengeszikra/the-royal-gazet...
But on my real work I also fixing a legacy based EU, ME, EA wide used applications, that work is really software detective works. I found who is the killer ( left the company years ago )
But those two things don’t really exclude each other 🙂
AI can generate code, but you’re still the one managing it — deciding what makes sense, what doesn’t, and where something needs to be improved (sometimes just by writing a better prompt).
And I really liked the part about the “killer” who already left the company. I definitely have a few of those cases in my projects too 😅
Debugging is definitely a core skill, but calling everything else copy-paste oversimplifies the job. Writing reliable software also means making design decisions, understanding trade-offs, and preventing bugs before they happen.
Fair point 🙂 Of course it's a bit of an oversimplification — titles tend to be a little provocative by design.
I completely agree that writing reliable software is about design decisions, trade-offs, and preventing problems before they appear. But in practice I often feel that debugging is the moment when all those decisions get… stress-tested in reality. 😅
I'm afraid you are right, but I'm sad, because I miss the times when I thought my main skill was to craft beautiful code like a true artist, going back and forth between different patterns and chiseling out those variable and function names, until it was near perfection 😅
The satisfaction of finding and fixing a bug just doesn't last as long as the satisfaction from the persuit of perfect code.
Yes, exactly! Writing beautiful code can really feel like a form of art.
The worst moment is when you’ve crafted some truly elegant piece of code… and then a new requirement comes in and you realize you have to delete the most beautiful parts because the business actually doesn’t need them anymore. 😅
This speaks so clearly to my current position at work. Especially the “upgrade framework / check for bugs” line.
I continue to avoid using AI tools because it generates a lot of junior level code i have to spend time cleaning up. Id rather write code myself because i enjoy that part of the job and i get to try out new things ive read about.
That’s actually very interesting about avoiding AI tools.
Most developers I know use them quite a lot now, but I also have a friend who very consistently refuses to use them, and honestly, it hasn’t hurt her career at all. She’s doing perfectly fine without them. 🙂
My experience so far with AI has been mostly negative. Whenever I ask it a question, it outright fabricates and answer leading me down a trail that doesn’t really exist.
The tools are supposedly getting better, but I would prefer not to use a technology that’s boiling the ocean for easy answers.
That “boiling the oceans for easy answers” part is actually a very fair point.
I kinda see your point, but I think the title feels a bit extreme. Coding itself has never been the point anyways. Nobody pays purely for our code; they pay for problem-solving. If someone can achieve that without writing code, more power to them.
That said, I wouldn’t go as far as calling everything else to "copying and pasting." As a senior engineer in the past, and now as a principal engineer, planning, architecture, code reviews, and proper execution take significant time and effort. Debugging is just a small part of what I do daily - and I do it a lot.
Regarding the idea that "everything has already been invented," there’s some truth to it, but specific business requirements in complex domains still demand careful thought. You can’t just Google those answers, and AI can only help if it fully understands the context, something that’s often impractical, time-consuming, or even restricted by company policies. The context might be so large and complex, you might not even try to explain it to AI, it won't make any difference.
Ultimately, the less time we invest in the design phase, the more we’ll spend debugging later. So building strong design skills remains crucial and arguably even trickier than coding itself, even in the AI era.
But that's just my personal thoughts.
Yes, I completely see your point. I’m actually working on something very similar right now — a huge government application where the documentation alone could probably fill several volumes of books. No context window is going to handle that. 😅
At that scale it often feels less like “programming” and more like architecture and system understanding. And honestly, the first thing I usually think about is which known pattern or architecture we can reuse, maybe adapt a bit — definitely not reinvent the wheel.
In my daily work on a large enterprise system, most of my time still ends up going into different forms of debugging and investigation, while many of the new features are implemented by junior and mid developers (with support of course). The project existed long before I joined and has a very complex history, so even if I wanted to redesign everything perfectly, that was never really an option.
The domain is also extremely complicated with tons of edge cases, so rewriting the whole thing is unrealistic with limited time and resources. We can improve things gradually — a bit like repairing a car while it’s still driving. 😅
And I suspect that’s the reality for a lot of developers working in large systems.
Thanks a lot for the thoughtful comment and for adding another perspective to the discussion!
I always go on about the 80/20 approach for tasks (though the exact ratio is of course relative to the complexity of the task): 80% of your time should be dedicated to thinking about how to approach the problem, what architecture/mechanics should you use, what the edge cases are, what are the ramifications, how can you ensure maximal coverage with your test cases, etc. Actually implementing it should then be relatively straightforward, especially these days with LLMs. Of course as you mentioned, the more tenured you get, the less time your job is about tasks, and the more it's about refactoring, abstracting, bug-fixing, detective-ing.
Also on LLMs, I too tend not to use them to generate solutions. From time to time, I like to see how it would approach a difficult problem just to compare ideas, if the problem is well-contained (it's been useful a handful of times), but mostly I use Google's LLM search as a contextual Stack Overflow to save time/memory: I have to first understand precisely what I want to code, then copy-paste-adjust.
I've always found it interesting when I see engineers actually type out lines of code, code blocks --- even variable names --- that are identical to existing patterns already in the file. But then my left hand is a magnet to fn-C/V 😆
I enjoyed reading that, thanks!
Thank you very much for the comment! It really expands on the idea from the article beautifully.
I have a very similar approach — for me LLMs shouldn’t write and work instead of us, but rather help us think and move faster when we already understand the problem.
In the best case it becomes a kind of collaboration: human + machine. 🙂
In response to:
"When you design a system, you rarely invent everything from scratch. Instead, you reuse patterns that worked before, adapt architectures that others already tested, and build on the collective knowledge of the developer community." <<< Not everything has been invented, I had to come up with a solution to transalte my code, a code refractor/translation tool, that did not exist in the open, so I combined various ideas into one. Not evereything is done yet, there are new fields to explore as technology advances.
Exactly, and I actually love playing with things like that too. Exploring new ideas and combining different concepts can be really fun.
For example, some of my WebGPU demos are in a space that’s still not fully explored yet, and even AI sometimes gets completely confused there. 😅
But unless you’re very lucky, the reality of everyday work is usually much less romantic. Most of the time we’re working inside large existing systems rather than inventing entirely new ones.
I became a developer because I imagined being a handsome hacker in a basement full of computers, breaking into bank systems and secret Pentagon databases with Angelina Jolie.
Instead, I debug NullReferenceExceptions and review AI-generated code. Reality hits hard. 😄
Hahaha, this might be my top comment under the article. 😄 And yes… life really tricked us there. 😅
Yeah I think you have a point - the real #1 core skill seems to be debugging, analyzing issues, troubleshooting, understanding existing systems ...
RE "architecture" - I don't think it's ONLY copy/paste, because you also need to make (reasoned) choices, but in many cases even architecture is rooted in understanding existing systems (especially when there's already heaps of legacy code) ...
Yes, absolutely! I didn’t mean to say architecture is only copy-paste. There are definitely important decisions involved, trade-offs to consider, and a lot of context to understand.
But the longer I work in this industry, the more I notice that when a feature becomes even a little bit complex, the first smart thing to do is usually to look at existing design patterns. Very often someone has already encountered a similar problem and described a solid way to solve it.
And honestly, when I sometimes look at the… very creative inventions some developers come up with, even the thought of checking design patterns first already feels like a sign of wisdom. 😅
That's not a thing anymore with AI rising. I mean obviously you debug, but not in the small scale. Either you go all in with debugging or you don't ever get to.
Interesting point — I think I see what you mean.
With AI generating more code, debugging often moves from small code-level issues to bigger system-level problems. In that sense it becomes even more about understanding the whole system rather than fixing a single line.
So maybe debugging is actually becoming more important, not less.
I think system design is a more important skill set
That's a great point! System design is definitely a huge skill.
In my experience the two are very connected. The better you understand the system design, the easier it is to debug when something breaks.
So maybe debugging is just system design coming back to check our homework. 😅
Hey, congratrulation Sylwia :). Great article again!
Thanks a lot, Ben 💖😊
you are welcome :)
earlier I thought programming was mostly about writing lots of code. Now it feels like most of the job is reading logs, tracing data flows, and figuring out why something behaves differently in production than it did locally.
"reverse engineering" lies at so much of the core of effective software engineering