Operations get cheaper — whole value does not

Before mass models, many intellectual services were priced almost entirely as human execution time. A client email, a manual translation, a landing page, a scanned invoice parse, a draft SQL query — sold as specialist hours. When a model drafts in minutes, the price of execution falls. The price of a decision you can ship or put into a contract does not fall automatically.

That distinction matters more than the slogan “AI will replace everyone.” Task automation means an operation becomes cheaper and faster. Specialist replacement means nobody is needed to set the goal, hold context, check edge cases, and bear consequences. Between those two states sits a large zone: the human stays, but the work looks different.

Jevons’ paradox is often offered as comfort: if development gets cheaper, demand for software will rise, so we will need even more engineers. Part of that is a real tendency: projects that never paid off start to make sense; more prototypes, internal tools, and one-off scenarios appear. But rising demand for software does not automatically raise demand for juniors who only ship template code. Demand can move toward architecture, data, security, and operations — or toward people who never hired a developer and now assemble a narrow solution themselves.

Evidence is more careful than hype. In Brynjolfsson, Li, and Raymond’s customer-support study, access to a generative assistant raised productivity by about 14%, with larger gains for less experienced workers. Dell’Acqua and colleagues’ consultant experiments show a “jagged frontier”: inside the model’s competence zone, quality and speed rise; outside it, confident answers make outcomes worse. Developer field measurements around assistants like Copilot show more completed tasks, again with bigger effects for less experienced people. Newer observations of agentic tools on GitHub sketch another important pattern: commit activity rises sharply, while real releases and usage rise more modestly. Intermediate artifacts get cheaper faster than delivered user value.

Which applications risk losing relevance

The threat is not “all SaaS.” It is products whose only scarcity is an operation a general model already does well enough for mass users.

A category rarely vanishes entirely. What vanishes is margin on the simplest variant. A plain OCR app that only does “photo → text” competes with a free button. Industrial OCR with quality control, local execution, its own form dataset, and ERP export can become more necessary: a general model does not know your empty cells, tolerances, or acceptance rules.

The same pattern repeats in site generation, chatbots, and “AI wrappers” around one API. If the product does not add data, process, integration, or accountability, it sells what a platform will give away for free within a year. If it does add those things, AI becomes an accelerator inside the product, not its killer.

Education: a correct answer is not yet knowledge

The fastest way to devalue a learning product is to let the learner receive a finished answer before understanding the problem. An LLM gives a solution, a translation, a refactor, a lesson plan. A person can submit work without holding the principle. The gap between using a tool and building competence becomes political for schools, bootcamps, and corporate training.

What loses value fastest:

• courses whose goal is language syntax as a command list;
• drills that only practice writing template code by hand;
• prompt collections without a method for framing and checking;
• training on one tool’s UI that will change next year;
• reference dumps without projects and feedback;
• programs with no real cost of error in the exercise.

What should replace them is not “cancel theory,” but restore theory as a frame. Fundamentals matter more precisely because models freely emit plausible nonsense outside their reliable zone. Real tasks, projects, experiments, hypothesis checks, critical evaluation of AI answers, and independent domain research are required. Otherwise the market gets a generation of chat operators who cannot tell a working prototype from a system someone can own.

This ties directly to how the engineering on-ramp breaks: simple training tasks — exactly the ones that once built muscle — are automated first. I covered the programming career ladder in “The programmer in the AI era”; here the general learning principle matters more: if an exercise is fully solved by one button, it no longer measures skill.

Professions and tasks under pressure

Saying “the profession will disappear” is usually premature. It is more accurate to look at the task portfolio inside a role. Repeatable, well-described, easily checked pieces get automated. Framing, exceptions, communication, accountability, and work with incomplete context remain.

For each row the career ladder shifts similarly: lower rungs paid for execution volume shrink; upper rungs paid for judgment expand — and become harder to reach without practice. The WEF Future of Jobs 2025 report captures employer expectations: AI technologies both create and displace roles (on the order of 11 million created and 9 million displaced in their projection to 2030). That is a survey forecast, not a law of nature, but the signal direction is clear: task reshuffling is stronger than whole professions vanishing overnight.

Why the threat is not only for juniors

It is easy to say “only juniors will suffer.” Reality is harsher. One experienced engineer with good tools already covers volume that once needed a small execution team. That does not make seniors immortal: if their value was speed at writing a typical service, the model catches them too. More durable is the person who holds architecture, business communication, cost of error, and operations.

The traditional ladder “junior → middle → senior” rested on a stream of simple tasks. If that stream disappears, where does a newcomer gain experience? The market will have to redesign the on-ramp — through training grounds with real cost of error, paired review work, model-evaluation skills, participation in integrations and incidents. Otherwise we get a shortage of people who can check what models generate.

That is why the boundary “where generation ends and engineering begins” matters more than the argument over whether programming will die. See where code generation ends and human vs AI coding productivity. Review after an agent is a new bottleneck, not a formality: code review in the AI era.

What gets more expensive: data, integration, control

If a general model covers “average” intellectual labor, scarcity moves to where one model is not enough.

Applied and industrial AI. Line computer vision, defect detection, medical image review, industrial control, process-specific forecasting, robotics. The closer a system sits to a physical or tightly regulated business process, the harder it is to replace the whole product with one universal chat model. You need line data, tolerances, controller integration, and people who will sign the result.

Local and enterprise AI. Local language models, retrieval over internal bases (RAG), agents with access rights, privacy, security, ERP/CRM integration, model-serving infrastructure. Here the product is not “answer beautifully,” but “answer from our documents to people who are allowed to see them, and record why.” How such a contour is built — in production RAG and prompt injection.

Data engineering. Dataset prep, cleaning, deduplication, labeling, synthetic data, quality scoring, pipelines, ML operations, delivery of large corpora. When code gets cheap, data often become the main asset. See dataset engineering.

Control and verification. Model evaluation, AI-system testing, fact checking, observability, agent security, instruction-injection defenses, hallucination control, humans in the loop, audit. If producing an answer is nearly free, the market pays for the ability to say “this cannot be trusted.” Practical frames: AI eval harness and testing economics / cost of failure.

Which products keep their value

ERP, CRM, and industry systems do not vanish because a model can write a screen’s code. They hold complex business logic, years of integrations, historical data, regulation, company processes, and high migration cost. AI can speed enhancements; it does not zero the cost of replacing the core.

Products with unique data hold even harder: plant journals, medical archives (within the law), financial history, corporate document corpora, equipment telemetry. In a world of cheap code, data are often the main moat.

A separate class is software tied to the physical world: industrial automation, robots, medical devices, IoT, lab benches, transport, energy. Generating a script is fast; certifying the behavior of a system that moves metal or doses a substance is not.

Finally, products people trust: security, stability, predictability, contractual service levels, certification, audit, vendor legal liability. When anyone can assemble a prototype in an evening, buyers choose whoever will sign tomorrow morning’s consequences.

StuzhukLab experiment: generic OCR vs industrial OCR

To avoid arguing in the abstract, the hypothesis is convenient to test on one function AI already “can do”: text recognition. We use this frame in the lab and in industrial pilots.

Prototype A — generic AI OCR. Upload an image → multimodal model → text on screen. Build time measured in hours. Development cost low. On clean documents quality is often acceptable. Local run, empty-cell control, accounting-system integration, and legal accountability are usually missing or only simulated.

Prototype B — specialized industrial contour. Table detection, cell slicing, specialized recognition, confidence scoring, rules for empty and doubtful fields, result storage, export into a business system, ability to work without sending scans to an external cloud chat. Time and cost are higher. In return you get accuracy on your form class, managed false positives, audit, and a path to production.

Comparison metrics that matter to a buyer:

The core experiment question: if a basic AI feature is nearly free, where does real product value appear? The answer we see in practice: in data, acceptance rules, model confidence, integration, and cost of error. Handwritten industrial forms are a live case for why “one model is not enough”: UZТ practice notes.

A formula for new professional value

The list of what gets cheaper is already familiar: template code, text and image generation, basic translation, simple analytics, prototypes, draft docs, searching for typical solutions. The list of what gets more expensive is shorter and harder: correct problem framing, domain depth, unique data, architecture, integration, verification, security, running complex systems, decision-making, and accountability.

A useful working model:

Specialist value ≈ knowledge × ability to solve problems × use of AI × accountability for the result

If any factor is near zero, the product is small. “I can write prompts” without knowledge and accountability yields a pretty draft. Deep knowledge without AI fluency leaves a person slower than the market. A strong AI user unwilling to sign the result is dangerous precisely because of speed: they replicate error faster.

Hence the shift in the development contour. It used to be often: task → code → tests → result. Now it is closer to: problem → specification → model-assisted solution → verification → integration → operations → accountability. Programming does not have to disappear; three parallel scenarios are more realistic: somewhere demand for hand-written code falls; somewhere programming becomes a mass tool like spreadsheets; somewhere the profession shifts toward governing computational systems. Which scenario wins in your niche is still open; preparing for the second and third is the rational bet.

Threat / growth matrix

The matrix is not a sentence; it is a map of bets. High risk with low growth means staying only there is a bet against the trend. Low risk with high growth is where to move learning time and product stakes.

How to choose projects and direction

Before a new product, five questions help:

1. Can the core function be reproduced with one general model in an evening?
2. Does the product have unique data the off-the-shelf model lacks?
3. Are there complex integrations and a process someone pays for?
4. Is there a real business problem with a cost of error?
5. Will the product keep value if AI becomes ten times better at your current “feature” in two years?

If the first answer is yes and the rest are no, you are designing a demo, not a business. If the function is reproducible but data, integration, and accountability remain — AI is your ally inside the moat.

The career algorithm is similar:

1. Find tasks AI already automates in your zone.
2. Find tasks that appear because of AI (verification, data, rollout, security).
3. Choose a domain with physical, economic, or organizational context.
4. Grow domain expertise.
5. Make AI a production tool, not a toy.
6. Learn to measure results.
7. Build your own practical project with a non-zero cost of error.

A 2027–2030 outlook without certainty theater

Likely cheaper: template development, simple content, simple sites, basic design, translation, draft documentation, standard analytics. Likely more expensive: quality data, expertise, infrastructure, security, integration, compute, people who can run complex AI systems, and accountability for outcomes.

But linear forecasts are a bad habit. Keep alternative scenarios open: AI accelerates faster than expected; regulation slows adoption in sensitive industries; inference cost collapses and reshapes local-model economics; companies move en masse to private contours; agents become the main interface to enterprise software; the labor market adapts faster or slower than the news feed suggests. A rational strategy is not to guess one scenario, but to build skills and products useful in several.

FAQ

Further reading

• The programmer in the AI era — career, on-ramp, and the shift in code’s value
• Where generation ends and engineering begins
• Human vs AI coding productivity
• Practice: handwritten UZT forms
• Dataset engineering
• Production RAG
• AI eval harness

Conclusion

AI does not have to destroy a profession or a product. It destroys an economic advantage based only on the ability to run a standard intellectual operation quickly. So the useful future question is not “what can AI do?” but “what human or business value remains after AI learned to do that?”

In a world of cheap code, the winner is not whoever writes more code. In a world of cheap content, not whoever prints more text. In a world of cheap intelligence, the winner is whoever chooses problems well, owns data, understands the domain, builds systems, can verify results, and accepts responsibility for what came out.

If you pick one next step this week, take one product, course, or role and answer the five project-choice questions honestly. Where the only remaining claim is “the model can do that too,” it is time to change the moat — data, process, verification, or accountability — not to raise generation speed.