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’re honest, isn’t that just an extremely fast version of copy-paste?
When people imagine programmers, the picture is usually quite dramatic. In the most optimistic version, it's a handsome hacker sitting in a basement full of computers with Angelina Jolie, breaking into bank systems and secret Pentagon databases.
A slightly less romantic but still impressive image is a developer hammering the keyboard at insane speed while lines of code cascade down the screen like in The Matrix.
And to be fair, when you start learning programming, that vision is not entirely wrong (except of course Angelina Jolie). You actually write a lot of code.
Someone even commented under my article
Your GitHub Contribution Graph Means Absolutely Nothing (And Here's Why)
that the greenest contribution graphs are often from aspiring developers who are simply learning by doing — coding every day, trying things out, experimenting. That’s completely natural.
I often talk with junior and mid developers, and many of them understand the job exactly this way: your role is to deliver features. Ship code. And honestly, there is absolutely nothing wrong with that.
Small personal update: I recently got accepted into the AWS Community Builders program 🎉I hope they give out cool hats and t-shirts 😅 If you feel like supporting me, you can leave a like on my LinkedIn post here.
But What Happens Later?
Something interesting happens as you move further in your career.
The more senior you become — and the more responsibility you have for the system — the less time you actually spend writing code.
Instead, more and more of your time goes into debugging, investigating strange issues, and generally solving problems that nobody else managed to solve.
You can think now: but some seniors still code a lot!
And yes, if you are an experienced developer working in a small startup, you will probably still spend a lot of time writing code. Especially now, when AI tools can accelerate development so much.
But as projects grow and become more successful, their complexity grows as well. And with complexity comes a different kind of work.
Less writing code. More understanding systems. Because when something breaks in production, someone has to investigate it.
Suddenly the support team needs answers. Right now!
Then you spend the whole day analyzing logs.
Oh, there is a race condition somewhere! You're a senior, you need to investigate it.
Is something wrong with our configuration? You need to figure it out!
And of course juniors always will come with the most famous developer question of all:
“Why is this null?”
Wait… Isn’t Programming Also About Architecture?
Now you might say: programming is not just debugging. Developers also need to choose architectures, frameworks, and technology stacks.
That’s absolutely true.
But the longer I work in this industry, the more I realize that in many areas almost everything has already been invented. There are design patterns, well-known architectural approaches, and proven solutions to many classes of problems.
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.
In that sense, architecture itself is often a kind of copy-paste — just at a much higher level.
Ignoring all that accumulated knowledge would be either genius… or stupidity.
When I Was a Junior
When I was a junior developer, I was shipping feature after feature. I must have written kilometers of code back then. If something didn’t work, I would spend some time researching, trying things, googling errors. If I still couldn’t fix it, I simply went to a senior developer.
And that was it. No matter how annoying and how time-consuming the issue was, the senior had to solve it. That was literally his job.
I remember one situation from that time when the project on my local machine suddenly stopped building. I spent hours trying to figure it out, until a senior checked a few things and calmly said: “Your Node version is wrong.” That was the whole mystery.
Back then I also felt a bit sorry for seniors. They were always on calls, constantly interrupted, rarely writing actual code. Meanwhile I was happily implementing feature after feature. Infrastructure? Pipelines? AWS? I barely even thought about those things.
Today
I’m now a senior developer myself, and I even have to coordinate work across multiple teams. Do I still write code? Of course. But do I deliver huge numbers of new features like I did when I was a junior?
Not really.
Instead, a lot of my work looks like this: upgrading a framework and trying to understand why everything suddenly breaks. Checking whether a dependency update introduced a regression. Investigating strange bugs that appear only in certain environments.
Remember these famous frontend CVE we had recently? The kind that suddenly appears everywhere and triggers a small wave of panic.
Does it affect our project? Fortunately not.
Now the only remaining task is spending a week replying to emails explaining that we don’t even use React 😉
The Real Skill
Writing code can look like copy-paste. Architecture is just a high-level copy-paste. But debugging is pure problem solving.
It forces you to understand the system deeply, follow data flows, analyze logs, and test hypotheses. Sometimes no Stack Overflow answer helps. Sometimes AI tools don’t help either.
You simply need to think.
And after hours of investigation, the root cause often turns out to be something surprisingly small: a missing property, an incorrect configuration, or a single line of code.
Debugging sometimes feels a lot like detective work.
The Responsibility
This reminds me one story.
Remember that senior that had to help me no matter what? Now I'm that senior for my teammates.
Some time ago, a junior developer came to me because, while implementing a complex form, he hadn’t noticed that validation wasn’t working in one place. He had no idea how to fix it and had already been stuck on it for quite a while. Deadlines were approaching.
I tried to guide him, pointing out a few places in the code that might help, but it didn’t work. In the end, I had to sit down and dig into that piece of code myself.
The day before the deadline (I finished at 1 a.m.).
Was it stressful? Maybe. Should he inform me about this issue earlier? Absolutely. But sometimes that's the reality.
So… Am I Unhappy About That?
Do I feel unsatisfied because I don’t ship as many features as I did when I was a junior?
Not at all.
After all — who didn’t want to become a detective as a kid?
Senior developers are basically software detectives. 🕵️♀️
Top comments (125)
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
Ohh that's great, please can we connect?
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 😅
The op declaration that the real skill in programming is debugging, ie detective work.
When I read your response, I'm confused by your counter argument so I'm going to debug it.
"I disagree with this, because right now, at the dawn of the AI era, the opportunity has opened up for a senior developer to tackle problems that he didn't dare to tackle before, because his knowledge in the given field was lacking."
at the dawn of ai
Why at the dawn of ai makes any difference? Are you implying you ai is better than experienced coders? Ai doesn't write fashion. It follows orders. All experienced ui developers are better than ai. Ai has not won any prize in any art creation, ever. Ai does not asses ui experience daily or know human interest to know whats next. The same I'd argue for code stability. Its not constantly on call to manage a code base which does a hundred different things simultanuously. Its not managing a business of change.
'his knowledge ... was lacking'
Correction:
His knowledge is lacking
Analysis:
So what. A person still needs to debug, read, interpret, think improvement, respond/apply
'...as a senior, he knows exactly how to control the agents...which if it's a problem that hasn't been addressed before, ...then it could be a program built on completely new foundations.'
I interpret that long statement (debugging) to mean a human coder (senior or otherwise) doesn't need to debug but can write a new solution from scratch using ai tools. That maybe possible (if small code base), but how can they prove their new solution meets all intention of original product.
No code is perfect. No original code has complete regression testing solution that a new approach can test against. Knowledge of systens typically exist with people (a mix of company lifers, and not all stake holders).
Thx your feedback!
The dawn of AI are just means the fact it is a brand new historical times for every one. I don't say AI can compare with a experienced developer.
Nor can you setup your agent to: constantly thinking on a code base which does a hundred different things simultanuously. Also able to Ihelp managing a business of change at least can monitorizing the business need.
Even in the detective works is fit for agents. The big gap is current AI agents fragmented works, and limited context handling capability. When connect AI agent to browser with mcp then able to saw and running a real program, in this case much easier help with debug problem, but the current level is need us, to localise a problem and drive it how can help.
AI is real good to read a debug message.
So I think experienced developer is better than AI, and going even better with a proper AI handling.
You totaly right: AI don't prove their new solution meets all intention of original product.
In my example the lack of knowledge is: I am not a rust developer, but AI solve that gap.
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.😂
amazing
Interesting take. In a way, I think you're right: we probably spend more time tracking down bugs than actually writing code. That may simply reflect how roles evolve—juniors write most of the code, while seniors spend more time stabilizing it.
That said, my experience has been slightly different. I've never really produced huge amounts of code, and I've probably spent more time debugging than I should have—ever since I started back in 1990.
But one thing is certain: finally finding and fixing the bug after hours of searching is incredibly satisfying.
You know, it was actually a bit similar for me. I always wanted to understand everything from the inside, build things myself, and really see how they work — which also meant running into a lot of bugs that I had to solve along the way.
I think that experience really pays off later.
And yes, when you finally figure out why something doesn’t work after hours of searching, the satisfaction is huge. 😅
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. 🙂
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.
I love your quote:
"...that the greenest contribution graphs are often from aspiring developers who are simply learning by doing — coding every day, trying things out, experimenting."
This is inspiring. I have tried to grapple my mind around why I have not gotten a bonified dev position yet, but also reiterate to myself that I need to take this time to learn absolutely everything I can. That means trying everything, being messy, going on week-long coding benders, and so on. I think I will miss that if it ever goes away.
My attitude has moved from "I am failing" all the way to "I will build an empire one day." LOL -- this is better for my mental health. 😅
I try to check in with myself to see where I stand on the dunning-kruger bell curve to steer void of becoming an imbecile. I would greatly like to believe that I've made it to enlightenment phase. 😂 I think the pit of despair hits you most when you realize how vast this space really is.
Oh yes, I remember those times very well! I remember putting “very good knowledge of JavaScript” on my CV… and then later realizing I actually knew almost nothing about it. 😅
I also spent a lot of time learning and experimenting before getting my first job. But it really paid off — during my interview the recruiter looked very positively at the projects I had built.
The real skill is not debugging, but it's problem solving, it sounds the same, it is not.
Architecture is not really a copy and paste, but it's to choose what's the best approach for a given problem and how does it scale over time.
Thanks for the thoughtful comment!
You’re absolutely right that problem solving is the bigger skill. A great problem solver can be a prime minister running a government or a parent managing the daily logistics of their kids. 🙂 In programming, though, that problem-solving ability most often reveals itself during debugging. That’s where you really have to understand the system and figure out what’s actually going on.
Of course there are other kinds of problem solving too, like discussions with clients or shaping requirements, but that’s slightly outside the part we usually call programming.
And regarding architecture: how do we actually decide what the best approach is and what will scale? Most of the time by looking at what has worked (or failed) before and learning from existing patterns. 😉
Also, the title is of course a bit provocative on purpose, the idea was to spark reflection and discussion like this one. And judging by the fact that I'm currently writing the 100th comment under this post… it seems to be working. 😅
In my work, I'm doing architecture every day. I may be making things out of lego bricks, but the way they go together is what makes the actual project - that is my primary role, if I put the right bricks in the right places I have one hell of a lot less debugging to do
That’s definitely the dream scenario. If the right bricks are placed in the right places from the start, life becomes much easier.
But imagine another scenario: two senior developers start a project with a very tight deadline, so they build things quickly with the promise that they’ll clean it up later. Right after the deadline they get moved to another project and the original one gets paused. A year later two junior developers fresh after a bootcamp are put there “just to do small fixes,” and they do what they can for another year.
Then the project is paused again, and suddenly a senior and two juniors have to deliver two large modules quickly. The project grows, multiple teams join, and rewriting or even introducing something like a strangler pattern is completely impossible because the deadlines are immovable.
At that point… debugging and pure survival instinct are often the only things keeping the system alive. 😅
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!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.