The Next Ten Years Will Not Be Kind to Software Engineers

Istanbul's business district at dusk. Photo by Vitaly Gariev, Unsplash.

If you are about to pick computer engineering in Türkiye, I want to tell you something nobody at a university open day will tell you. If you are not going to study at ODTÜ, Boğaziçi, İTÜ, Koç, Sabancı or Bilkent, think very hard before you put this department on your list.

I know how that sounds. I did not study at any of those six either. But the market I graduated into is not the market you will graduate into, and pretending otherwise would just be a lie dressed up as encouragement.

Right now, even graduates of those schools have to jump through ten hoops to land a single offer. For everyone else, the hoops are higher and there are more of them.

Let me explain why I think this is not one bad year, but the shape of the next decade.

Squeezed from two sides

The industry is being squeezed from two directions at the same time.

The first one is AI. I wrote about it in In Two Years, Your Position Won't Exist, so I will not repeat the whole argument here. The short version: the work that used to justify hiring a junior or a mid-level engineer is exactly the work an agent now does in an afternoon.

The second one gets talked about less. Remote work stopped being a perk and became normal. And once a company accepts that the team does not need to sit in the same building, it also stops caring whether the team sits in the same country. A role that used to be open to people in Istanbul or Ankara is now open to the whole world, and there are teams out there, many of them in India, offering the same work for a fraction of the price. You are not competing with your classmates anymore. You are competing with everyone, and some of them are very cheap.

Put the two together and you get the market we have today: fewer seats, and far more people fighting for each one.

"It only writes CRUD"

Whenever someone says you can build real projects with Claude Code, somebody else shows up to look down on it. Sure, it can write CRUD apps.

Yes. And almost all of the software in the world is CRUD. Screens that read from a database, forms that write to it, endpoints in between and permissions on top. That is what most of us have been paid to build for our entire careers. None of us is sitting down on Monday morning to write the Linux kernel.

Small and medium-sized projects really do get built with these tools today, start to finish, without drama. I have no doubt that large projects are next. And the CRUD argument misses something else: AI is also good at complex software design. Ask it to compare three architectures for the same system and you will get a clearer write-up of the trade-offs than a lot of design documents out there.

So the question is not whether AI can do the work anymore. The question is what is left for us when it does.

The job is now a list of questions

If I had to describe what an engineer actually does on an AI-heavy project today, it would be answering these:

• Is the AI doing the right thing?
• What exactly is it doing?
• How is it doing it?
• Is everything still fine?
• Does the solution it proposes actually fit us?

None of these questions are about typing. All of them are about judgment. And the last one matters most, because of a habit every model I have worked with shares.

The AI will over-build. Your job is to cut.

To guarantee that a solution works, AI tends to propose the most complicated, most defensive version of it. It is not wrong, exactly. It is covering every possible case, including the ones you will never have.

A concrete example. You have a system that gets maybe ten requests a day. The AI suggests making it concurrency-safe, adding thread synchronization, and coordinating requests coming from multiple instances on the database side, so nothing is ever processed twice. Every piece of that is technically correct. For ten requests a day, every piece of that is also unnecessary. It is more code to read, more code to test and more places for a bug to hide, all to protect you from a problem you do not have.

Machinery inside the Sonnenberg bunker in Lucerne, built for a war that never came. Photo by Simon Infanger, Unsplash.

Your job is to see that and step in. Throw out what is extra, and simplify the code until it does what is needed and nothing more.

But here is the twist. Sometimes that same system gets ten requests a day and each one moves money, or touches someone's medical record, or triggers something that cannot be undone. Then a request processed twice is not a small bug, it is an incident, and the over-built version is exactly what you need.

The AI cannot tell these two systems apart. You can. Making that call is the job.

Bad answers, bad software

There is one more thing people underestimate. AI rarely lands on the right solution on its own. It gets there by asking you questions, a lot of them. How many users? What happens if this fails halfway? Who is allowed to see this data? Does it need to be consistent right away, or is a few seconds late fine?

You have to be able to answer those properly. If your answer is "I don't know, just do whatever", you will still get something. It will compile, the demo will look great, and the whole thing will be built on guesses. What the AI builds can only be as good as your answers.

This is why I keep saying fundamentals matter more now, not less. You cannot answer a question about consistency if you do not know what consistency means.

Everything is urgent

Now the part that is specific to Türkiye, and it is equal parts tragic and funny.

In our country, every job is urgent. Even in the software projects of the biggest holding companies, nobody spends much time on design, architecture or testing. What matters is getting the project out as fast as possible. We even have a saying for it: kervan yolda düzülür, the caravan will sort itself out on the road. So the project goes live in a rush and it is declared finished. Everyone gets their bonus, everyone gets their promotion. Then the next two years, and a lot of money, go into turning that project into something that actually works.

Every one of these cables was urgent once. Photo by Felix Ngo, Unsplash.

That cycle was always wasteful. With AI, it becomes dangerous. AI-written code grows incredibly fast, much faster than any team could write it by hand. If code like that is pushed to production without control, and nobody really knows what it does, the data pollution and the security risks it creates are many times bigger than they used to be. Before, the mess was at most as big as what a team could type in a few months. Now it is as big as what an agent can generate in a few weeks, and nobody has read all of it.

The old model was: ship fast, fix it for two years. The new model is: ship ten times more code, then find out in production that nobody knows which part has been writing wrong values into your customer table for a month. I think we will see a lot of companies blow up at exactly this point, and soon.

The next ten years

So what am I actually saying? That the software industry is going through an unbelievable contraction in demand for people. Not a dip. A contraction.

In the long run, I do think demand comes back. Software will keep getting more complex, and if we move into new dimensions, like building whole three-dimensional worlds the way the metaverse promised, there will be far more to build than there are people who can build it well. When that happens, the people who can design, question and verify systems will be in a very good place.

But that is the long run. For the next five to ten years, I am fairly confident about this:

It will not be a bright decade to be a software engineer.

If you are choosing a department, choose with your eyes open. If you are already in the industry, stop thinking of yourself as the person who writes the code and start acting like the person who decides whether the code should exist. That is the part that will still be worth paying for.