Modern development, thanks to LLMs, is increasingly turning into a multi-threaded conveyor belt. Today, Claude Code or ChatGPT can write you a whole application or microservice literally from a small prompt.
Will it be of good quality? That depends on the task.
If you're automating your routine tasks, even a clunky automation often brings benefits (for example, I've written many routine helpers for personal use).
However, if you're designing a complex multi-level pipeline, taking code “as is” is at least reckless.
So, the main skill of a programmer in the age of neural networks, as I see it, is no longer just writing code, but also quickly reviewing, understanding, and debugging someone else's code.
Let's say you're a strong developer and can use LLMs to immediately assemble a good microservice or a robust pipeline. You control the process from the prompting stage to deployment, understand what each decorator in your Flask application is responsible for, and how exactly the classes describe the behavior of entities.
But what do you do when you encounter someone else's code that you need to debug or, worse, restructure or extend? This is where the most challenging part begins. Those who have often dealt with code generation by neural networks know that it frequently adds unnecessary checks, excessive exceptions, complicates functions, and builds multi-step logic where it could have been simpler.
To understand the essence of this problem, we need to recall how large language models work. LLMs predict the next token based on the context of the task, meaning the prompt and chat history. If the prompt does not clearly, explicitly, and unambiguously state the requirements for simplicity, readability, and reproducibility of the code, the neural network will use averaged patterns and select a solution that fits a similar task solved previously.
You might say that LLMs often write in the style of an "experienced developer": with a lot of checks, exceptions, and auxiliary wrappers. Yes, BUT only if you understand this. However, if you cannot reproduce the logic of the code, refine it, or quickly fix it, then its practical value drops sharply, regardless of how "professionally" it looks.
In simpler terms, if while reading you think the code is clear, but you can't reproduce its logic at least in the form of pseudocode, then most likely, you have only understood it superficially.
One of the key skills to develop in the age of neural networks is not "grokking algorithms" and fighting for O(N), but debugging, simplifying, and optimizing already written code. The speed at which OSS and commercial projects are currently being written is impressive and even frightening. In N years, neural networks may be trained on code that has already been partially generated by other neural networks. But who will say whether this code is good or not?
You might notice that if the code accomplishes its task, then it is good. But reproducibility in case of emergencies, quick refinement, and working on NDA or GOV projects are at least scenarios where it is impossible to quickly or safely provide the neural network with all the necessary context (after all, we can't just feed it entire private repos?).
Writing code with the help of a neural network is not a problem. The problem arises when you take on code that you do not understand and for which you are not ready to take responsibility. You may not be perfectly familiar with every library or every method, and in the era of LLMs, that's okay. But you must manage the architecture and logic of the code.
I have taken on a daily practice of such an exercise: I ask an LLM to prepare a complex pipeline (classic ML or deep learning) with a lot of comments and explanations. Then I read this code like a book and try to reproduce the basic logic, simplify certain parts, and suggest improvements.
Try conducting an experiment:
- Ask an LLM to generate a complex pipeline (ML / backend / any stack).
- Ask it to add as many comments and explanations as possible.
- Read the code.
- Try to reproduce the logic in words or in the form of pseudocode.
- Find several places that can be simplified.
If you can't do it, then you understand the problem I've described.
p.s. One might argue that experienced developers can already quickly read someone else's code - that's true. But the problem is that in the era of LLMs, not only has the volume of code sharply increased, but so has its complexity and heterogeneity. As a result, even strong developers are increasingly spending a huge amount of time on analyzing and simplifying generated code rather than writing it from scratch.