有人预测软件工程的未来将趋于平淡

Alex Pliutau

Nov 08, 2026

12

5

2

Share

I didn’t want to put the word “AI” into the title, but it could also say “The future of AI coding is boring”, even though these two titles don’t necessarily hold the same meaning. The way software is being created is changing, whether we like it or not, whether for better or for worse, but AI coding has prevailed, but in my opinion has created only more problems than it solved. And the problems that are currently in front of us, looking at all that generated code, are not necessarily the most fun to solve. That’s why I say “boring”.

Let’s remind ourselves how joyful and prestigious it was to be a Programmer. I can’t go too far into the past, as I only started programming around the year 2005, but even that feels like a century ago nowadays. The code that we wrote back then wasn’t flawless, but we cared about it a lot, every line considered, every single memory allocation accounted for. We would spend days on making it stable. I am not saying there were no deadlines, they were still there, this part didn’t change. And there were only a handful of us who would truly understand how to write good and performant programs. That’s why it felt prestigious. But is it today? When every single person can generate code by prompting an LLM and paying a bit of money for tokens.

In a way, I could say that the programmer profession has ended, or changed so much that it’s just a new profession not fully defined yet. Imagine spending years becoming a food chef, perfecting your craft, only to discover one day that your job now is testing the meals prepared by a machine. Luckily it doesn’t happen with culinary what happened to programming.

Okay, enough of a sentimental intro, and let’s look at some of those problems, not in any particular order. Without much answers too, I want to leave it open for discussion or internal thoughts.

Problem #1 - How do we learn now?

I love reading books and making notes. That was an important skill if you wanted to learn something a few years ago, because in some cases that was the only way to figure out how to solve a specific problem. You had a database scaling challenge? Go and read the Designing Data-Intensive Applications by Martin Kleppmann. I know that many people dislike StackOverlow for its stubborn audience and not the best UX for asking questions, but I have to say that in most cases the process of asking the question there, looking at duplicates and opening a few links already gave you an answer. An answer that you would remember for years, because that’s how our brain works when we “use” it.

While writing this article, I opened my StackOverflow account to see if it’s still there and it reminded how much effort I put into answering and asking all those questions. What for? For Sam and Dario to scrape it without giving any credit?

Problem → Research / Reading / Brain → Solution

With such powerful shortcuts to a solution, how do we engage the brain? It seems that this part is completely skipped in most cases.

Problem #2 - Codebase Erosion

When you start introducing AI-generated code into a legacy pre-AI codebase, or even in case of a new codebase, in the beginning you can control most of it, by doing careful Pull Request reviews, engineers can still understand how the code works. But no matter what you do, if you started accepting AI-generated code, your codebase will eventually erode; it’s almost unavoidable, and the more generated code comes in, the harder it gets. Even AI now struggles understanding the codebase because of the enormous codebase size, loose interfaces, scattered and not coherent documentation. The code review process is almost always skipped, or AI is reviewing AI and stamping everything as LGTM. Because how else can someone review and test the horde of incoming changes? I like this quote even for big Pull Requests before AI:

Give a reviewer a 10-line Pull Request and he will find 10 issues, give him a 500-line one, and he will say LGTM.

My main motto was always to keep the code to a minimum, but AI just can’t do it, it’s only adding things, resulting in bloated codebases, slow builds and tests.

And it’s not only about the codebase. Because it’s so easy to request a feature, the codebase now consists of many unused features or functionalities that conflict with each other. The sad part is that it doesn’t happen immediately, at first AI gives you a noticeable boost, only then to show all of these problems. It’s like a drug for the codebase.

Can you spot a “prestigious” programmer somewhere in this process? I don’t.

Problem #3 - Noise and Management

Didn’t you notice that everything around our jobs became more bloated? Not just the code, but the memos people send or messages we get. Everything, or a lot of it is generated by AI, and the recipient is often tasked with deciphering it or cutting through the noise. I can tolerate the AI-generated code, but when the email or a doc is also a slop, you are simply showing a lack of respect.

The managers now have a higher expectations to deliver more and faster, because we have the AI right? Like generating code was ever a blocker. Therefore everyone pushes even more that leads to problems 2 and recursively 3 again.

So these are the problems we need to work on that will redefine the Programmer. And you may ask, “why boring then”? My answer would be: We used to spend time solving the problems with code, now we’ve become a caretaker of code that nobody really understands.