The Epilogue of the Age of Executors
We stand at a threshold. Can you feel it? That trembling moment when an epoch ends and a new one quietly, without haste, enters through the door.
I've felt it in my own skin. Two years ago, I sat down at my computer and started a project that seemed insane. Deploy a full AI stack locally: Open WebUI via pipx, LM Studio on port 1234, ComfyUI for image generation, then Ollama with multiple models running simultaneously. RTX 4060 8GB — and everything had to work.
The first day it sounded like "why do I need this?" But then I started understanding. I wasn't just experimenting with models. I became an engineer in AI deployment. I built a RAG system on Express.js + React/Vite with SQLite. I wrote a ReAct-agent server where AI had tools to analyze SCSS and generate BEM structures. I configured the Continue extension in VS Code for local models, integrated Figma MCP with Open WebUI. I set up Unsloth Studio for model optimization, played with MTP and speculative decoding in llama.cpp.
And here's what I realized in the process: it wasn't about letting the machine do my job. It was about understanding how it works. It was about system architecture. About connecting components. About thinking about a problem deeper.
In the tech community, this feeling is palpable, like humidity before a storm. On forums, in Slack channels where people gather with monitors glowing — there's a frightening whisper.
A backend developer asks: "Will AI replace my job?"
A DevOps engineer: "Do we need people in automation in five years?"
A Data Engineer: "Maybe I wasted time on ETL pipelines when AI can write them in a minute?"
An ML engineer sits in silence and thinks the scariest thing: what if machines learn to build machines better than humans?
It's not panic. It's something more. It's a premonition. A perceptive person always feels the wind shift first.
And it's fair. Machines really can write code. Astonishingly fast. Without errors. Without fatigue. Without asking for a salary. It's not fantasy anymore, not a promise of the future — it's here, now, on our laptop.
But from one simple truth, people forget to think clearly.
They confuse code with engineering.
They think a developer is someone who writes code. That IT is a set of commands, syntax, scripts stacked on top of each other. And if a machine can stack lines — the game is over.
It's a mistake of epic proportions.
Part One: What's Really Happening
An IT engineer is something entirely different. A system architect. A solver of unforeseen problems. A philosopher who thinks about people, about how they interact with technology.
When I hear that ChatGPT wrote an API endpoint in 30 seconds, I smile. Because I understand what actually happened. AI wrote an endpoint. A simple endpoint. Maybe with basic functionality and validation. Sounds invulnerable.
But try asking AI something more complex. Something real.
"Write me a microservice that:
- Handles 50,000 requests per second without latency
- Syncs data with three external APIs with 99.99% uptime
- Auto-scales under peak loads
- Has built-in circuit breaker and exponential backoff
- Stores data in three different databases (SQL for structured, NoSQL for graphs, Redis for hot data)
- Transmits data bidirectionally with delivery guarantee
- Has detailed logging and tracing across distributed systems
- Complies with GDPR and encrypts sensitive data
- Auto-recovers from failures without losing state
- Has A/B testing for new features"
Suddenly the task becomes less simple.
AI will generate fragments. Syntactically correct, but they won't connect into a coherent system. Because AI doesn't know your context. Doesn't understand your reliability requirements. Can't anticipate potential race conditions and deadlocks. Won't have the experience to know which solutions will work in practice two years later, when the system grows 100 times.
And here's where a human appears. A person with 10 years of backend development experience. She doesn't just know programming syntax. She knows something much deeper:
She knows how to think about systems as living organisms. How to anticipate bottlenecks years before they become critical. How to design so the system stays flexible yet reliable. This knowledge comes from failures. From 3:00 AM on-call when the database crashed and 10 million users can't buy. From solutions that looked right on paper but fell apart under real load.
AI doesn't have this. And never will.
Even the most advanced models are statistical systems. They've seen millions of lines of code. But they don't have the experience of lost data. Don't have the fear of wrong architectural decisions. Don't have that ineffable knowledge about system behavior that comes with time.
Part Two: New Skill as New Power
But let's step beyond fear and think logically.
If AI can write code, then the person who understands the subject gains a new superpower: the ability to manage AI.
This isn't just about typing a prompt into ChatGPT. It's an art. It's a science. It's something between mathematics and poetry.
Let me give you a real example from my practice. When I deployed a local AI stack in LM Studio, I needed the right system prompt for frontend architecture.
First attempt: "You're an assistant for developers. Help write code."
Result? The model output syntax that didn't compile. Half the time I was debugging errors.
Second attempt — the one that worked:
You're an expert frontend architect with 10 years of experience. Your stack: React, Next.js, SCSS/BEM, GSAP, TypeScript.
Important:
- Generate code for scaling and maintenance
- SCSS modules with BEM — never CSS-in-JS
- ARIA labels and accessibility by default
- useMemo, useCallback, code splitting for performance
- Custom hooks instead of deep logic in components
Environment constraints: RTX 4060 8GB, LM Studio locally, testing through my SQLite RAG system.
Your job — propose architectural solutions, not just copy patterns.
With this prompt, the model started talking not just "how to write code," but "how to think about the system." I could ask: "How do I restructure a component to scale to 10,000 users?" — and the answer made sense.
The difference? I passed my context. I told the machine how I think architecturally. It required me to understand what matters in frontend (performance, accessibility, scalability).
A person without this context gets mediocre code. A person who understands the subject gets an architectural solution.
Imagine two engineers on one team.
The first writes: "Write me a database migration script."
AI gives something basic. Functionally correct, but not what you actually need for your situation.
The second engineer writes:
Write a Python script for safe database migration from Postgres 12 to 15. The script must:
- Execute zero-downtime migration using logical replication
- Work on a 500GB database without blocking reads/writes
- Have built-in rollback mechanism if something goes wrong
- Verify data integrity before and after (checksum comparison)
- Log the entire process with timestamps and status
- Have dry-run mode for testing without real changes
- Automatically create a backup before starting
- Sync secondary replicas after successful migration
- Have built-in retry mechanisms for temporary network errors
- Alert the team about critical moments via Slack
Constraints:
- Single file, runs from command line
- Config via environment variables for security
- Handle signals (Ctrl+C) gracefully
- Use connection pooling
- Encrypted connection strings
See the difference? The second engineer doesn't just throw a prompt at the wall. He thinks. He knows what matters (zero-downtime, data integrity), what's secondary. He anticipates potential problems (race conditions during replication). He understands that this script will run in production, where a mistake costs millions.
It requires:
- Deep understanding of databases and their behavior
- Experience from real projects
- Intuition about what can go wrong
- Discipline and structure
A person without fundamental IT experience can't write such a prompt. She won't have the intuition. She won't know what to ask.
She'll write something simple, and when this script runs in production, everything falls apart.
Therefore, AI actually increases the value of an engineer who understands the subject. It's a paradox many don't see.
AI doesn't replace engineers. It replaces mediocrity. It replaces people who just copy code from Stack Overflow without understanding. People who don't know that this code in production can lead to data loss or security breaches.
But a person who truly understands? They become 10 times more powerful.
Part Three: Evolution From Scribe to Architect
Let's be honest for a moment. Over the last 15 years, IT was the age of scribes. Not in a negative sense — just descriptive.
A developer would sit at the computer, get a list of requirements, and write functions. API endpoint after endpoint. Day after day. Years passed writing CRUD operations, debugging SQL queries, fixing error logic.
A DevOps engineer would get a list of server configurations and copy one to another. Script after script. Again and again.
A Data Engineer would take raw data from multiple databases and transform it by instruction. Pipeline after pipeline. Process after process.
It wasn't creative work. It was craft work. Important, necessary, but still craft. Work that repeats, that's predictable, that's perfect for automation.
And here's the huge shift: AI frees engineers from the need to be a scribe.
Think that's bad? It's wonderful.
Because now an engineer can be what they're really meant to be. An architect. A thinker. Someone who solves real problems.
Instead of spending 6 hours writing CRUD API, the engineer spends 20 minutes structuring a prompt, getting code, reviewing and adapting it. Then spends the rest of the time on real questions:
How do I design a system that scales to millions of users without redesign?
How do I restructure this monolith into microservices without downtime?
How do I prevent the technical debt we've accumulated over the last two years?
How do I create something nobody in the industry has ever seen?
How do I solve this unusual problem in production at 3:00 AM when everything's falling apart?
These are questions a neural network won't have answers for. These are questions that require human creativity, experience, research spirit, intuition.
And these are the people who will be valuable in the next decade. Not scribes. Architects. System thinkers. People who understand not just how something works, but why it works that way.
Part Four: Time of Engineers
But here I want to express something more philosophical.
We live in a time when technology becomes increasingly complex. The systems people build become increasingly massive. User requirements become increasingly sophisticated. The margin for error becomes increasingly narrow.
This is a time when engineering must rise to a new level.
I realize this when I launch Open WebUI on my local machine and it interacts with LM Studio on port 1234, with Qwen and Gemma models, with Unsloth Studio for optimization, with llama.cpp for inference. All of it works on RTX 4060 8GB, on a machine with i7 7700K.
It's not "give me AI to do the work." It's "how can I build a system that can think?" It's an architectural task. How do I divide load between VRAM and RAM? How do I optimize inference without losing quality? How do I integrate MTP in llama.cpp for speculative decoding? How do I connect Figma MCP with a local system for design-to-code workflow?
These aren't questions about syntax. They're about how to think about systems.
A time when people who just write code by instruction aren't needed. People are needed who can think about a system as an organism. People who understand connections between components. People who know how a system behaves under stress.
AI doesn't cancel the need for such people. AI makes this need urgent.
Do you know that one of the highest-paid categories of engineers in Silicon Valley are people in positions of "Staff Engineer," "Principal Engineer" — people who understand the architecture of massive systems? People who can think about how to build a service that handles billions of requests a day without interruption?
Their salaries sometimes exceed those of managers. Not because they write syntax better. Because they can think.
They understand systems deeply. They know where problems can arise. They can anticipate bottlenecks. They can propose architectural solutions that solve problems.
And this knowledge comes from time. From 10, 15, 20 years of experience. From failures and victories. From studying how systems evolve, how they break, how they recover.
This isn't something you can quickly learn from YouTube. This isn't something AI can generate in 30 seconds.
This is the time of engineers.
Part Five: What Remains for Humans
Let's clearly mark what AI cannot do.
AI cannot understand context deeply.
AI can detect patterns in millions of lines of code. But it can't understand why this specific pattern is better than others in your specific situation. It doesn't know about your team, about your users, about your business strategy, about your legacy codebase with 10 years of history.
AI cannot create something truly new.
It can combine and rewrite what it's seen. But it can't invent something radically different. Something that's never been before. When the whole world solves a problem one way, and you need a way that wasn't in training data — that moment belongs to humans.
AI cannot talk to people.
Human communication is an art. Understanding what a user really needs, even if they don't know themselves. Convincing a stakeholder, explaining complex technical decisions in simple language, listening to concerns. AI can imitate this. But imitation isn't the same thing.
AI cannot take responsibility.
When something goes wrong with your system, users don't call AI. They call the engineering team. The people. And a person who understands the subject can say: "I understand the problem, here's how to fix it." AI can't. It just says words.
AI cannot make complex decisions under uncertainty.
Architectural decisions are often made with incomplete information. You have to choose between SQL and NoSQL, between monolith and microservices, between simplicity and scalability. Often there's no one right answer. It takes intuition, experience, understanding of trade-offs.
I felt this acutely when I started deploying the local AI stack. AI could say: "Use Postgres for structured data, Redis for cache, SQLite for embedded data." Correct. But it wouldn't understand my constraints: RTX 4060 8GB, need for zero-latency local inference without calling remote API, necessity to have everything on one machine.
I had to choose:
- Use full PostgreSQL or get by with SQLite for embeddings? (Chose SQLite — simpler, enough for 100k vector records)
- Run LM Studio constantly or via API? (LM Studio constantly — frees VRAM only when not using)
- Cache embeddings or recalculate? (Cache in SQLite — saves precious VRAM)
- Integrate Unsloth for model optimization or leave as is? (Integrated — needed to understand LoRA and quantization)
These weren't technical decisions. They were architectural decisions. They required understanding not just "how it works," but "how it will work in my context in a year, when I have more data."
AI could give formal answers. But a person — one who understands — had intuition.
This all remains for humans.
Part Six: Building Prompts as New Art
But there's something new emerging. Something that didn't exist before as a distinct skill.
It's the art of prompt engineering.
A person who can talk correctly with AI has a superpower. They can:
- Break down a complex problem into parts AI can handle
- Provide context so clear that AI gives a useful answer on the first try
- Know when to follow AI's suggestion and when to go your own way
- Iterate on the prompt, improving the result at each step
- Generate architectural solutions, not just code
This is a skill. It can be learned. And it will become one of the most valuable skills for a specialist.
Because this skill requires understanding technical questions. Understanding how systems work. Understanding potential problems. Understanding what questions to ask.
A person without fundamental IT experience can't do this well.
An engineer who knows systems well, who understands trade-offs, who anticipates problems — this engineer, armed with AI, will be an unstoppable force.
And the person who just copies prompts from the internet, hoping for luck? They'll quickly become obsolete.
Part Seven: The Collapse of the Old Way of Thinking
It's hard to admit, but the old model of IT specialist — the one popular 10 years ago — is dying. And that's good.
The model where a developer is someone who sits at the computer, gets a task, writes code, commits, moves to the next task. Day after day. Work that requires nothing but syntax and copying patterns.
For such a person, AI is truly a threat. The machine stacks lines better. The machine doesn't get tired. The machine doesn't ask for a salary. The machine doesn't make syntax mistakes.
But for a real engineer — one who understands systems — AI is part of the new toolkit.
One who can think architecturally. Who can anticipate problems years before they arrive. Who understands people and business. Who knows when to go against the trend and solve a problem unconventionally. That one enters the new era with incomparable advantage.
Part Eight: Different Roles, One Principle
Here it's important to say something that applies not just to backend developers, but to all of IT.
A frontend developer — now not a markup scribe. He's an architect of user experience. AI will write a component, but the person decides how the system should feel.
I know this firsthand. AI will write me a React component with SCSS, ready to use. But I decide: how do I animate this through GSAP? How do I optimize re-renders for thousands of elements? How do I make it accessible from 320px screens to 4K? AI gives syntax. I give design, architecture, philosophy of how users should interact.
A backend engineer — not an API scribe. A designer of systems that must withstand billions of requests without panic.
A DevOps engineer — not a server administrator. An architect of reliability and scalability. AI can write a config, but the person understands what to do when everything falls apart.
A Data Engineer — not a pipeline transformer. A storyteller of information flows, making data speak.
An ML engineer — often most sees AI as a threat. But the thing is, the most valuable ML engineers are those who understand not just how to train models, but when they need to be trained at all.
I've watched Qwen and Gemma models running on my RTX 4060. I could just load them and run them. But real work is understanding which model to choose for which task. Qwen is better for code, Gemma for text tasks. When do you need quantization? When do you need fine-tuning? When will a simpler heuristic be better than a neural network?
This is ML knowledge. Not about how to run a model, but about when and why to use the machine at all.
A QA engineer — not just a test writer. Someone who reasons about hypotheses of where the system might fail. AI will write tests, but the person understands which scenarios are most complex.
One principle for everyone: hold onto context, architecture, and understanding. Let the machine write code.
Part Nine: Architecture as Superpower
The most interesting part of IT's transformation in the next decade is what changes in value.
For those who understand architecture — understand microservices and monoliths, understand databases, understand networks, understand trade-offs — for them it's a golden age.
Because architecture can't be automated. Can't be sent to AI. It requires deep understanding of the problem, experience, intuition.
I felt this acutely when deploying a local RAG system. AI could write a SQLite config, or an Express.js script. But the system architecture — how to connect LM Studio through local embeddings, how to cache results in SQLite, how to integrate this with a React frontend through Vite, how to structure vectors for fast search — that was all my work.
I could ask AI to write an embedding function. It would write it. But it wouldn't know I need batch processing to fit in 8GB VRAM on RTX 4060. It wouldn't know I need a caching mechanism to avoid recalculating the same embeddings. It wouldn't understand how to sync state between the backend and the React client.
It was an architectural choice. And when the system started working — it all paid off.
A person who can say "we need microservices, here's the architecture, here's how each service interacts" — that person becomes irreplaceable.
A person who knows when you need SQL, when NoSQL, when Redis cache, when message queue — that person understands systems at a level AI doesn't see.
People who understand how to scale systems, how to design for reliability, how to think at scale — they enter the new era as kings.
These are architects. Not code scribes. System architects.
Part Ten: Choice
And here everything narrows to choice.
You can stay in the old position. Write code. Do what you're asked. Copy patterns. Hope AI goes away.
Or you can move forward.
You can start thinking like an architect. You can study the deep foundations of your specialty:
- For backend: how databases really work, how distributed systems handle consistency, how to optimize queries
- For DevOps: how servers really work, what happens in failure, how to design for fault tolerance
- For Data: how statistics really work, how to predict it's not a coincidence, how to detect bias
- For ML: how neural networks really learn, when you need ML (and when simpler logic is better)
- For Frontend: how browsers render, how people really interact with interfaces, how to design for accessibility
You can develop new skills: prompt engineering, communicating with AI, managing machines as partners.
I do this every day. I ask AI to write an embedding processing function, then I ask: "How do I optimize this for 8GB VRAM?" The machine gives a variant, I say: "No, that won't work, because..." — and the machine adapts. I run code through llama.cpp with MTP speculative decoding, and the system infers twice as fast as without optimization.
It's not "AI does the work." It's "AI and I solve the problem together, but I know the direction and the machine is the executor."
You can be creative. Try something new. Build an architecture nobody's built before. Make mistakes. Learn. Try again.
I built a ReAct-agent on Express.js that can analyze SCSS files and generate BEM structures. It sounded weird in theory. In practice it required understanding how LLMs see structured data, how to pass context through a prompt, how to handle errors gracefully. The machine generated code, I designed the architecture.
It's not easy. It takes time. It takes courage to take a risk.
But people who make this choice — they'll have a future.
Conclusion: What You'll Choose
When I look at the IT community today, I see a division.
One half is tired. It's heard enough about AI, enough about fears. It just wants to write code and make money. It thinks if it writes code fast enough, it'll stay valuable.
This half is at risk.
The second half is curious. It experiments with AI, but continues learning. It asks "how can I use this?" instead of "how will this replace me?" It reads about architectures. It thinks about systems. It asks complex questions.
This half will be fine.
The choice is obvious.
But the choice is yours.
You can fear AI. You can hope it goes away. You can grumble that "it was better before."
Or you can accept the fact that you live in a time of transformation.
And transformation time is opportunity time.
A time when an engineer who really understands their craft gets a chance to be not just an executor. An architect. A leader. An innovator.
This is the time of engineers.
The question: are you one of them?
Epilogue: A Story of Transformation
Three years ago, a young PHP developer came to me in tears. He'd heard about AI, about his job being replaced. He was afraid that choosing PHP was a mistake.
Today, that developer is the architect of a system serving a million users. He understands databases, microservices, asynchronous operations. He uses AI to write boilerplate, but his architectural decisions bring millions to the company.
He's not afraid of AI. He uses AI.
And he earns three times more than he would have if he'd stayed a scribe.
I'm telling this not to give false hope. I'm telling this because it's true.
AI isn't the end of your career. It's its restructuring.
What you do with this transformative moment depends only on you.
Epochs don't change because people want them to. Epochs change because they must. And people who understand the forces driving change always become leaders of the next epoch.