"Generated and pushed." AI is imperceptibly weaning IT professionals from thinking in code: is this a new skill or a degradation? Experts from EPAM, Levi9, Master of Code, and SPD Technology explain

Let's imagine a scene familiar to 2026. June gets a task, opens Cursor, writes a prompt, and in a few minutes has the code ready. Everything works locally, the tests are green, changes can be pushed to the repository. At first glance, everything is fine. The problem is that he doesn't always understand why this particular solution works and what will happen to it when it breaks at three in the morning in production.

A year ago, this would have sounded like an exaggeration for another discussion about the future of the profession. Today, it is a common reality for many teams. And the question is no longer whether AI can write code. It can — and often faster than a person. The question is different: does it gradually unlearn how to think like an engineer?

The worst thing about degradation is that it is almost invisible.

The paradox is that skill degradation is almost never felt from the inside. Subjectively, a developer becomes faster, but objectively, it is not a fact.

SPD Technology says that the changes are already visible. Senior Software Development Engineer Anton Nebylytsia explains: before, before writing code, the developer kept a model of the system in his head and tried to understand the logic of the solution. Now, more and more often, he immediately turns to the assistant and takes the first option that looks plausible.

This hits debugging skills the hardest. According to Nebylitsa, the habit of rereading stack traces, checking your own assumptions, and independently digging into the cause of the error gradually atrophies when it's easier to just paste the log into the chat and ask for an explanation.

This is especially dangerous for juniors. Engineering intuition has been formed for years through a simple cycle: wrote, broke, understood, rewrote. If this process is replaced by prompt engineering, the foundation simply does not have time to form. For seniors, the risk is different: not a lack of a base, but a gradual loss of criticality. The model's response begins to be perceived not as an assumption that needs to be tested, but as a ready-made truth.

At the same time, Data & ML Engineer at Levi9 Igor Kozlov draws attention to an unobvious plus: many experienced developers still treat AI with cautious skepticism. And this is what often works in their favor. According to him, controlled use of the assistant does not weaken skills, but on the contrary, strengthens them.

Stop writing code and start testing it

All dev.ua interviewees agree: the very nature of the profession is already changing. A good engineer of the future is not the one who types code the fastest by hand, but the one who best understands what exactly the model generated, where the weaknesses of this solution are, and what risks it poses to the product.

Kozlov describes this as a transition from “writing code” to “understanding code.” According to him, today it is critically important not to simply accept the result from AI, but to understand which parts of the system it affects, what is covered by tests, and where potential problems lie. That is why code review is becoming no less important, but on the contrary, more critically important.

AI Director of EPAM Ukraine Vadym Vlasenko speaks about this without romanticizing it.

According to Vlasenko, at the same time, thanks to his experience, he does a very high-quality code review. "So do I see a problem here? Rather, no, because the question is not who technically types the code. But it is a person who must check these results," the IT specialist notes.

And here an uncomfortable question arises for businesses. If AI really speeds up delivery, are companies willing to pay for the extra time for verification, review, testing and rewriting, without which this acceleration will very quickly turn into technical debt? Because AI-generated code without engineering discipline is not optimization. It is simply an accumulation of problems.

In fact, the problem is old. It's just that the scale is different now.

CTO Master of Code Global Bohdan Sergienko suggests not to dramatize, because, according to him, the problem itself is not new. "Jokes about Stack Overflow programmers existed long before the appearance of Cursor or Claude Code. It's just that modern agents generate much more complex and convincing code than the usual copy-paste from the forum," he says.

The fundamental thing has not changed: the responsibility for the final result always remains with the person, not the model. Risks arise not because the AI ​​wrote the code, but when this code does not pass sufficient verification. That is why code review, testing and architectural thinking matter even more today than a few years ago.

Banning AI is pointless. Only rules work

All interlocutors agree on one thing: prohibitions will not solve anything. Processes are needed.

SPD has an AI after attempt rule. The first 30–40 minutes the developer works independently. Only after that can he turn to the assistant. This allows him to first see the limit of his own misunderstanding, and only then close it through AI.

Another principle is formulated there as follows: AI is a pair programmer, where you are the navigator, not the passenger. Everything that gets into a commit, the developer should be able to explain in a review without an open chat nearby.

They also practice AI-free days or pet projects without assistants - like memory training after using the calculator.

SPD works with Claude Code, Codex, Cursor, and Copilot. But there is no cult of a specific tool. What matters is not what the developer uses, but how much he understands what exactly he is receiving from the model.

EPAM uses a different approach — token limits. Vlasenko jokes: if they run out on Wednesday, you'll still have to think for yourself by Friday. There's serious logic behind this joke: artificial scarcity prevents the brain from fully delegating thinking to a machine.

Levi9 reminds us of another good old practice: certifications. They cannot be "supplied." You still have to acquire the knowledge yourself.

Vlasenko is blunt: the term “vibecoding” annoys him because it devalues ​​the profession. Development is not about “vibes,” but about serious engineering work. Instead, he talks about AI-native delivery — restructuring processes so that AI speeds up delivery but doesn’t replace human responsibility.

According to Vlasenko, there can be no T-shape engineer without fundamental profile skills. In any AI-assisted process, there must be a person who is able to guarantee the quality of the solution.

AI strengthens the strong and masks the weak

All interlocutors formulate the result of using AI differently, but the meaning is the same: the qualification drops not from the very fact of using AI, but from the “generated and pushed without reading” mode. The risks arise not from the tool, but from the lack of verification. Working with assistants can be a way to learn — if you approach it thoughtfully.

AI, dev.ua's interlocutors are convinced, will not make a weak developer strong. But it will very quickly show where real understanding ends and its imitation begins.

Claude Code creator is annoyed by the term “vibecoding.” He’s looking for a new name for AI programming and is asking the community for help.

On the topic

Claude Code creator is annoyed by the term “vibecoding.” He’s looking for a new name for AI programming and is asking the community for help.

Notion has introduced a new platform for developers, Keynote, where all the work is done by AI agents. How it works

On the topic

Notion has introduced a new platform for developers, Keynote, where all the work is done by AI agents. How it works

Read the country's main IT news in our Telegram

On the topic

Read the country's main IT news in our Telegram