If you’re a senior software developer right now, there is a good chance you are being pressured. There is an enormous level of unwarranted encouragement to use AI for absolutely everything. This is based on the assumption that developers who aren’t generating large amounts of code through AI agents are somehow falling behind. But deep inside, you’re troubled by the uncomfortable realization that much of what makes an experienced engineer valuable is the knowledge that these tools are supposedly rendering obsolete.
I’ve written before about the risks of this trend, from the erosion of software craftsmanship in The Coming Dark Age of Programming to the questionable relationship between AI adoption and actual productivity in The Illusion of Productivity. I won’t repeat those arguments here.
Instead, there is a more practical question worth asking: what’s the trajectory for the people who still want to know how software actually works?
You’re Still Needed
Even if AI models become extraordinarily good at generating code, there will still need to be software engineers who understand what that code is doing.
Someone will need to understand why a system is slow, why memory usage is growing, why a multithreaded process is deadlocking, why a distributed system is yielding inconsistent performance, why a race condition only happens once every few thousand requests, why a connection is getting abruptly closed or why a seemingly harmless change has broken everything three layers above it.
Those problems don’t disappear because an AI can generate a solution. In fact, knowing how to answer them may become more important.
There is a big difference between being able to produce software and being able to understand software. AI may make the first one dramatically easier without eliminating the second one at all. There’s two major problems with this.
Rotting Codebase
AI assisted coding lowers the bar for writing more code. Much more code. And in many cases, more code is a bad thing in itself. A human coder will know when to apply the DRY principle across a large codebase, but a quick autocomplete or even a coding agent will not necessarily know when not to repeat something. The overall quality of a codebase becomes worse at each iteration, instead of getting better and more concise which is the case when an experienced programmer cleans up after others – or themselves. There’s a graph about “every vibe coding project” that you’ve probably seen, and it is the absolute truth.
Understanding
We have been adding layers of abstraction to software for decades. AI is simply another, much larger abstraction layer. Each added layer has the potential of both obscuring issues and complicating the process of fixing them. People who know how to dig for the underlying reason of an issue are essential.
The scariest scenario is if the training problem is overcome and AI suddenly becomes extremely good at programming. Good to the point where nobody in an organization knows enough about programming to understand what the AI-generated code is doing, and that’s dangerous.
Imagine a company where every developer can generate a perfectly reasonable implementation of almost anything, but nobody can comfortably reason about memory, concurrency, networking, database behavior, operating systems or the architecture of the existing system. Everything works until something unusual happens. At that point everyone asks the AI for another answer, because there’s no one else to ask. You can ask an LLM to explain what’s going on, but it will provide you with a mathematical guess, not knowledge. If you’re creating something new – which should be the case, otherwise, why are you writing it – an LLM might not even have data to go off of.
There will always need to be a group of engineers who can go deeper. They may be fewer than there are today. They may spend less of their time typing code. They may use AI extensively themselves. But they will still need to understand the underlying systems well enough to recognize when something is wrong and determine why.
Those people aren’t going away. If anything, they may become more valuable. You could be one of them.
Don’t Stop Writing
This is why I think it is important for developers, particularly experienced developers, to continue writing code themselves.
That doesn’t mean refusing to use AI. It doesn’t mean writing everything manually to prove that you still can. There is no virtue in spending an afternoon typing boilerplate that a machine can produce accurately in thirty seconds. It would be just as pointless as fighting over which code editor one should use, and almost all of them have long shipped with varying levels of code assists built in.
But there is a significant difference between deciding that you don’t need to type every line yourself and deciding that you no longer need to know how to write the lines at all.
Writing code is not merely a way of producing software. It is one of the ways we learn how software works. You learn by trying something, discovering that it doesn’t behave as expected, tracing through it, reading documentation, looking at the source, changing it and trying again. Eventually you develop an intuition about what the system is doing, and that intuition becomes one of the most useful things you carry from one project to the next.
If an AI always provides the answer before you have had to understand the problem, you can easily ignore that process and lose the benefits of it.
Don’t let AI remove your ability to work without it.
Write code sometimes simply because you need to remember what writing code feels like. I’ve heard more and more senior software developers doing this as a hobby as they’re forced to use AI tools on daily basis.
Build something from scratch occasionally.
Read source code.
Debug the strange problem yourself before asking the machine to explain it.
Keep enough of the underlying knowledge alive that, if the abstraction fails, you can still descend through the layers and find out what is actually happening.
That is not resisting progress.
It is maintaining the skills required to use progress responsibly.
It’s Just a Phase
…I hope. I suspect the current period is going to feel much more significant while we’re inside it than it will in retrospect.
Companies are trying to figure out how much AI can actually contribute to software development. Developers are trying to determine which tools are useful. Managers are trying to turn an uncertain technology into measurable productivity. Vendors are trying to convince everyone that their particular implementation is the one that will change everything. Meanwhile, the companies involved in pushing AI to everyone are trying to figure out how to turn a profit. This is all trial and error.
There is going to be a lot of experimentation, and most of it will be wasteful. Part of trial and error is that most tries will fail, while some will succeed.
Eventually, useful practices will normalize.
AI will eventually stop being heralded in every meeting and become another tool developers use when appropriate. Repetitive tasks will be delegated to machines – this has been happening since the industrial revolution. Other tasks will continue to require people who are both creative thinkers and understand the underlying systems.
What Survives
Eventually the software has to run, customers have to use it, security teams have to approve it, production systems have to survive it and somebody has to maintain it. If a form of AI tooling genuinely makes developers more productive, the organizations that use it effectively will have an advantage and those practices will spread. If replacing too much human understanding with generated code creates more problems than it solves, those problems will eventually become visible too.
This is one of the main aspects about software engineering as a profession: eventually, everything has to work. The industry can spend years arguing about productivity metrics, developer sentiment and AI adoption rates, but a production system doesn’t care about any of those things. It either works or it doesn’t.
The goal shouldn’t be to preserve programming exactly as it was. Technology changes, and software development should change with it. The goal is to make sure that while programming changes, we don’t accidentally eliminate the ability to understand it.
Whether you have to use AI assists in your work or not should be a deal-breaker for accepting a job or staying in one. They can’t* take the keyboard away from you. Keep writing code. Keep learning how the systems underneath your abstractions work. Don’t let yourself become dependent on a machine for something you used to understand yourself.
* probably
Understanding may eventually become one of the most valuable skills you can have, instead of writing.
The current AI frenzy is a transition, not the end of software engineering. We don’t know exactly where the transition will lead and how bumpy the ride will be, but we can make sure that we arrive there as engineers rather than mindless operators.
Leave a Reply