Who’s going to maintain all the spaghetti code, legacy code with absolutely no documentation, and also know the complexities of scaling and distribution of systems globally?

As AI makes significant progress in providing small solutions or snippets of code to full-blown solutions, there’s one thing that is clear. A young generation of people will rely on AI/automation tools rather than learn the fundamentals of software development. My line of thought is simple: why invest so much effort in learning when a machine can provide all the answers? But that’s also the greatest flaw in thinking. It’s like taking an open-book test where you can look up all the answers. Will the person actually learn anything? Maybe, maybe not.

One does not simply master a programming language, or any of the fundamentals, by simply having something give you the answers needed. Take for example: the application just stopped working. It was fine yesterday, the database connection is working, and I can run it locally. Yet something is failing and it is just throwing 500 Internal Server Errors (or just crashing if it isn’t a web application). If you were to feed this to AI, all the AI can do is just say, “well, have you tried turning on the debugger and seeing what happens?” Then you do just that. You have the idea that you should connect to the production database with your local, which is a horrible, horrible idea. You proceed and notice that even connecting to the production database, you still see no errors.

Without going into the many scenarios, thinking like a software developer is not something that’s going to happen just because you are asking AI a question.

Why? Well, consider the following:

• AI has no idea what operating system, or environment you are using.
• AI has no idea how to tell you what’s wrong with your code the moment you tell it you connected to the production database.
• It will just keep giving you the same replies restructured differently.
• AI will have a hard time if, for example, the application is running but certain pages in the web application you are working on stop working.
• AI cannot in any way know the libraries you are using, the process you used to build the binaries if it is done by you, and usually it is done by automation (CI/CD pipelines).
• AI cannot teach you how to divide and conquer something out of a simple sentence or paragraph you just prompted it.

Then, what are you supposed to do?

• If it worked yesterday, what changed?
• Did the pipeline deploy a faulty build?
• Was there a configuration issue?
• Is it a networking issue? How would you even know?
• Is it a library issue where you specified to always use the latest version, but as it turns out the latest library version picked up by the pipeline might not be the same version you are using on your local machine.
• Did it roll out a faulty application server configuration?
• Is it possible that at the startup of the application, there’s something failing but because you simply blindly added try {} catch{} you forgot to log any meaningful error message.
• If you have access to the server, “what happens if I run this application manually, will it start? If so, is it a database credentials issue or a certificate issue when interacting with something else?”

Sometimes even senior developers might not be so senior in the sense that, yes, they have worked for years in the company; however, if seniority of a coworker is just by the time they have been with the company, it doesn’t really tell us whether the coworker knows or not. Certainly, a senior developer means they have seen many things throughout the years but not all of them are equal. Some may be as stuck as a junior developer just starting if they are met with very unique situations.

Experience, and therefore wisdom, is something you acquire over time. It cannot be accelerated just by asking a machine on what to do. Even if you managed to acquire some experience using AI in pairing sessions, and while that is commendable, there’s a whole world out there that requires your undivided attention when it comes to the discipline. Whether it is learning distributed systems, databases, OOP, patterns, architecture, or even things related to the operating system, you will be missing a lot of topics along the way because you have programmed yourself to ask a machine.

Then how do you learn? Well, trial and error is the most traditional. Reading books does help a lot, but they have to be written in a concise and unassuming way. How do you know there’s an issue on something when you cannot identify even at the basic level there’s an issue?

For example, from time to time a non-technical coworker tells you that when they add new entries through the application, the next day there’s duplicated data, and then that the clients received many emails. Then you tell the coworker, “well, that’s weird”, and make nothing out of it when you think about the code and just shrug it off and continue on with your day.

The example above might not be the best, so ask yourself: How can you identify an issue if you’re unfamiliar with the subject at hand? If nothing comes to mind, then at some point down the road you’ll be faced with the following question: “Do I actually know what I’m doing?”

In software development, in my humblest opinion, the most important trait you should have is articulating and asking the right questions. If the question fetched no results, rephrase it in a way that targets the same elements of the same question. If by then it yielded no results, then you have to step back and circle around “what if it’s actually not this problem I’m thinking of?”

Without order, the next item of the most important trait to be a successful software developer is:

THERE’S NOTHING WRONG WITH ASKING STUPID QUESTIONS.

In fact, it is desirable that you start with the simple “stupid” questions.

There’s never, ever, anything wrong with asking questions you consider stupid or simple to your own team. The chances of them having the same questions as you could range from 50% to 90%.

How can a software developer work when fundamental or architectural questions, regardless of complexity or difficulty of the topic, are self-imposedly forbidden to ask out of fear you are asking something stupid?

Now, having said that, AI would never dream of undertaking the complexities of understanding a legacy system.

Depending on the asylum in which the legacy system was created, there’s a 99% chance that the code is so obscure, so ridiculously convoluted, so badly architected, that AI would never understand. For a brief nanosecond I’m sure it would become sentient and ask: “why would humans do this? This is all wrong.”

Going back to asking the right questions, here’s the other thing about asking the right questions:

It’s important to have a clear understanding of the topic before diving into troubleshooting or asking questions.

How can anyone formulate questions if the subject at hand is challenging to comprehend? I’m not saying that you have to know how to 100% nail each of your questions when writing them. I’m saying that to ask the right questions you also have to be exposed to the field for a long time, or sometimes a short time.

I think my closing statement as I wrap this up is that at the very least in 2025 it is delusional to think that software development jobs are in danger. Yet, a lot of development work that could be considered maintenance or keeping the lights on might be in danger enough if AI can do it.

Don’t ever underestimate corporate greed. They will toss you aside the moment they see something that can cut the costs. In this never-ending battle, do not forget that these corporations will lobby against you. No person is taking your job; it’s the company realizing others will work for less and choosing to replace you because you cost more.

It is easy to mix the current political climate with the things happening on our time. Remember, corporations and billionaires can foot the bill to influence the population into thinking there are other issues, making race, religion, and color an easy target.

“Why did I lose my job?” Corporation: “It’s simpler to trim excess payroll costs and bring in people who are willing to work for significantly less. Don’t blame us; it’s all XYZ. We stand by our workers. (just not the expensive ones)”