I belong to that gradually dying-out generation of developers who got the strange privilege of writing program code in its purest, most primordial form — creating every line by hand, with my own hands and head, without any smart copilot assistants, without prompts, without autocompletion that supposedly knows what you want to write better than you do. Bare algorithmic logic, liters of coffee drunk and a blinking cursor in an empty file of an open IDE, when the brain tries to hold the entire architecture of the system in its "RAM" all at once.
And I'm sincerely glad that I went through this experience in my time, that I caught that era when programming was still a real craft rather than the management of automatic code generators. In those very recent times, which now already seem like some tale of mammoths, I wrote code constantly: at the office, at home, when I was under stress from a major release, when I was happy from solving a hard problem, sometimes in my dreams I kept debugging something and hunting for bugs.
I did it not because someone forced me or because the bosses demanded it, but simply because the very process of creating a working system from nothing, fixing tricky bugs, building complex systems from simple components — all of it was genuinely fun, brought some childlike pleasure of creation. When you finally lean back in your chair away from the monitor after many hours of work, look at what you built with your own hands, and see that everything works as intended, and think: "Yeah, I'm a damn genius, I did all this myself, and nobody helped me." Well, except SO and a bit of googling.
Even five years ago you couldn't just mechanically assemble ready-made software components from libraries into a single system; you always had to hold the mental model and architecture in your head, keep all the interconnections between modules in memory and work through edge cases before they would arise in practice, simulate various failure scenarios before production managed to unpleasantly surprise you at three in the morning.
And every hard bug fixed made me a bit more experienced, a bit smarter, a bit better at understanding how everything works inside — it turns out I wasn't just writing yet another piece of code on assignment but forging it in the smithy of my mind, putting a piece of myself into every hammer blow.
I well remember how I embedded an ECMA sandbox for hot-reloading configs into one of our projects, because C++'s capabilities weren't enough, and I had to rewrite both the project and the sandbox itself — and it was hard, I was genuinely proud of it as a work of engineering art. And this system is still in use ten years later, and I have something to be proud of, simply because I built something truly difficult and elegant at the same time, and there's that sincere creative satisfaction from the results of your own labor that is very hard to fake or simulate on purpose.
And now let's fast-forward to today, to our era of AI being shoved in everywhere it can and can't go. Over the last few months of actively working with AI assistants I produced (not wrote), generated more program code than I used to write by hand in a whole year of work or even more. Formally the metrics of my commits show big growth, and my management ten years ago would simply have carried me on their hands for such numbers, but inside I see that something is going wrong, that something important has been lost in this process of how I write code. A strange feeling that all this code was built not by me personally with my own hands and head, but by some abstract programmer hired on outstaff. Yes, I formally review all of it line by line, read it carefully, refine the details, fix inaccuracies.
Yes, I broadly understand what's happening in the algorithms, because I've been sitting on this project for more than a year, but all this code wasn't born from that deep cognitive labor and inner struggle with the problem that made the process of programming so creative. It's now like watching games on YouTube, when someone else goes through the whole hard part for you, beats the final boss after a dozen tries and rescues the princess from captivity, while you just sit nearby and stare at the monitor.
You can even get the credits with acknowledgments at the end and a victory record in your profile, and even your name written into the high-score table... but you didn't play yourself, didn't feel the thrill, didn't experience defeats or rejoice in victory. And this is where the main paradox lies: when the process of creating something becomes too easy and fast thanks to automation, the very achievement of the final result starts to feel weightless, unreal, lacking the value it had before.
There's another important side effect of the mass use of AI in coding that no one talks about at conferences and in articles. That famous state of flow, of deep concentration, about which dozens of books on the psychology of creativity have been written — it used to come on its own in the process of writing complex software systems. You could disappear, fall for many hours straight into that flow, fully immerse yourself in building logic, in debugging edge cases, in polishing the small things, and time ceased to exist; I often forgot to eat and a second cup of coffee went cold beside the undrunk first, while outside it had already gotten dark.
And now it's enough to briefly describe to the AI in text what exactly you want at the output and wait while the model generates the answer, inevitably getting distracted by something extraneous, because the brain doesn't like idling, simultaneously checking messages in Telegram or mindlessly scrolling the feed. When I typed all the code on the keyboard with my own fingers, my brain and hands were synchronized with each other; the very physical struggle with the problem, overcoming difficulties and the implementation gradually encoded, recorded the whole system deep into the subcortex, into long-term memory, into an understanding of the domain. AI removes all this useful friction from the development process, but it's precisely this friction, this struggle with the material, that was the main mechanism of deep encoding of knowledge in a programmer, of turning information into understanding and experience.
And here's what became a real surprise to me, what I absolutely didn't expect to discover: the very process of typing code on the keyboard used to be pleasant in its own way, gave a kind of tactile pleasure. Different keyboards with different key travel or click affected the process of building game logic in the program differently; the mere physical rhythm of the thinking process itself, transmitted through the movements of the hands, affected how fast I solved a problem. Now it's much easier to describe the desired result abstractly instead of constructing it yourself step by step from elementary bricks, but describing the end goal in words is completely not the same as building the path to it yourself. And it's precisely in the process of building, in overcoming difficulties, that all the joy of creativity lived, all the buzz of a programmer's work.
And a few weeks ago, something broke again in our production because of the latest changes that were made with the help of AI. The old me, who wrote everything himself, would have known intuitively and exactly where in the code to look for this type of error, and how to fix the problem quickly with minimal changes. But this code wasn't written by me, and it wasn't even written by a programmer, and I had to literally reread the whole software system line by line from scratch, and it was completely foreign code, not in our code style, without our review (it's a separate question how the code got through review), written by an unfamiliar "person" on the other side of the world. And the realization of that fact hit me psychologically far harder than the technical bug itself and its consequences for players.
When code written personally by your own hands after long reflection suddenly crashes with an error in production under load, your brain has long had a detailed mental map of the whole system, a detailed model of the architecture. You can quickly get your bearings, understand what exactly went wrong, and manage to debug the code almost intuitively, on autopilot, physically remembering where the problem is, because the whole codebase once passed through your brain in the process of creation, not just through your eyes during a superficial review. This code had to be mentally simulated in different scenarios, fought with during debugging, you literally lived inside this system for a while and thought in its categories. And now, if something breaks in code created with the help of AI, you have to go and read line by line, not because you suddenly forgot how to program or got dumber, but simply because you didn't absorb this code deeply enough into yourself during its creation.
There's a fundamental cognitive difference, a huge chasm between three different things: writing the code from scratch yourself, expending mental effort on it; carefully reviewing already-ready foreign code for errors; and just understanding in general terms what the code does on a quick read. And we're now shifting from the first variant toward the third in this spectrum, and this fundamental shift in the way of working radically changes the depth with which professional knowledge becomes part of you yourself.
I'm not complaining about fate now or scolding progress, just observing from the side and recording the changes happening, trying to make sense of them. I'm not at all against the very existence and use of AI in work, that would be stupid and pointless. I witnessed the flourishing of classic programming, maybe not the golden age of code of the 90s, but I too got the historical privilege of writing programs by hand in the purest form of this craft, without any assistants and crutches, and I'm sincerely glad I managed to go through this experience, that I have it in my baggage. Now I simultaneously see and understand where all this is moving next.
AI assistants in programming won't go anywhere and won't disappear, no matter how much anyone resists. They'll only keep getting better every month, generating code faster, becoming more autonomous in solving problems, requiring less and less human participation in the process. But at the same time the very rules of the game in the programmer's profession have fundamentally changed literally in a couple of years, and maybe our new role in this changed world is no longer to type code faster than competitors and colleagues, to be the most productive by number of lines per day.
Maybe true programmer mastery is now in something else — in the ability to design the architecture of complex systems at a high level of abstraction better than others, to ask precise questions about requirements, to design deeper and more thought-out systems that account for future scaling, to understand more clearly the inevitable trade-offs between different qualities of a system, to truly own the architectural decisions being made at the level of deep understanding rather than just owning the specific lines of code that can be rewritten at any moment.
A programmer's professional mastery evolves along with the tools, and this is a normal process, but you have to approach this evolution consciously, understanding what we lose and what we gain in the process, because if we completely and unconditionally abandon the manual building of systems, delegate everything to someone else, we may quite accidentally and imperceptibly also abandon that very joy of building, that pleasure of creation that made the profession attractive to creative people rather than just a way to earn money.
This transitional moment in programming feels uncomfortable and anxious to me precisely because I'm right in the middle of a transitional era between two paradigms of work. The developers of my generation who wrote absolutely everything by hand for many years in a row also see this shift in the profession more sharply and painfully than everyone else. Sometimes I catch myself with the strange thought that I already sound like a grumpy old man telling the youth tedious stories about the "good old days" of programming, when we wrote code until two in the morning just for the pleasure of the process. The new generation, which is growing up already with AI assistants, may perhaps never in their lives experience that same feeling of satisfaction from building a system by hand, but they will quite likely experience some other satisfaction of their own from working at a higher level of abstraction.
I'm trying to figure out for myself how to use these new tools effectively while not losing myself as a specialist and, in the process of transformation, turning into a mere operator of other people's systems. I still write most of the code by hand, not only because my contract explicitly forbids me from using AI for coding, but because I like writing code with my hands and my own head. But the company has already opened up AI access for analyzing bugs and reviewing incoming commits.
← All articles