Keep Being an Engineer

Today, only the lazy don’t use neural networks for everyday tasks: want to animate an image - no problem, generate text on a specific topic - sure. But what about engineering tasks?

AZ

Alex Zakharov

January 06, 2026—5 min read

Transcription is now a trivial problem, and a simple web application can be built in a couple of hours. Should you be afraid if you spent 10 years learning this, and now anyone can do the same thing in 10 hours? square to round These thoughts can be unsettling. But if you take a step back, it becomes obvious: reality is simply pushing many engineers (myself included) to adapt to the environment - to learn new tools and develop new approaches to building software.

I’m convinced that the gap between people who use an engineering mindset and those who merely read about what vibe coding is continues to grow right now.

Over time, any engineer develops professional intuition - experience reinforced by practice and continuous learning. It is precisely this intuition and accumulated knowledge that act as a stop factor, preventing engineers from being replaced by prompt engineering.

Yes, today you can build some kind of application without knowing a specific technology or even an entire domain. It may even solve the task at hand. But in most cases, it will be a PoC - and then reality begins:

  • business behavior needs to change
  • defects need to be fixed
  • the application needs to be deployed in an environment

At each of these stages, problems arise that are impossible to solve without that very intuition and engineering experience (unless we’re talking about a calculator). You can, of course, keep fixing everything with new prompts - but that only creates new problems. circle_plan

From a pragmatic perspective, neural networks have primarily dramatically accelerated text production - and this is one of the key capabilities that is truly worth mastering.

A simple example. At some point, I mentioned that I didn’t have a tool for analyzing product releases at work and was just keeping notes in a notebook. In one evening, I built this project, personally writing no more than 100 lines of code: https://release-calendar-demo.vercel.app. But what did it actually take to make this happen? In practice, I barely coded at all. Instead, I:

  • Defined functional and non-functional requirements (which requires understanding the domain and quality attributes)
  • Designed an architecture ready for future changes and fixes (which requires knowing which architecture fits - and which doesn’t)
  • Prepared the application for launch (which involves environment and deployment skills)
  • Repeatedly asked clarifying and corrective prompts (and here it is crucial to understand why a specific result is good or bad)

There’s no need to worry about the emergence of tools that can generate "ready-made" applications. But it is absolutely worth learning new approaches and tools to speed up coding, diagramming, and other routine processes.

Engineering thinking hasn’t gone anywhere - on the contrary, it has become even more important.