When writing code becomes cheaper, what happens to the value of engineering?
I grew up in Iran, where you learn to appreciate the value of a Persian carpet long before you learn much about economics.
A handmade Persian carpet can cost tens of times more than one produced by the most advanced weaving machines. Sometimes, the closer its craftsmanship is to centuries-old traditions, the more valuable it becomes. Natural dyes, traditional patterns, hand-tied knots, and even subtle imperfections can contribute to its character and value.
The same principle applies to art.
Imagine reproducing a Picasso painting using Microsoft Paint. You could draw cleaner lines, apply more consistent colors, and print the result on the finest paper available.
Technically, your reproduction might be more precise. Financially, it would be worth a tiny fraction of the original.
Why? Because in art, authenticity, history, human craftsmanship, and the creative process itself can be part of what we’re paying for.
But software is not a Persian carpet. And it certainly isn’t a Picasso painting.
When a company buys software, it generally doesn’t care whether developers spent six months lovingly handcrafting every API, form, and database query.
Nobody has ever asked me whether my REST endpoints were hand-knotted.
Customers care whether the software solves their problems. They care about reliability, security, performance, maintainability, and cost.
If someone can deliver an equally reliable solution in a fraction of the time, using fewer resources, why should the customer pay extra simply because another team wrote everything manually?
Of course, some software systems remain in operation for decades. But their value comes from their usefulness and reliability, not from how closely their development process resembles the one we followed twenty years ago.
And I think this distinction is important for understanding what’s happening to software engineering today.
When software production becomes industrialized
For years, a significant portion of software development has involved building forms, APIs, validation rules, database operations, reports, integrations, and business workflows.
Consider a traditional CRM or ERP system.
A development team could spend months implementing screens, connecting services, handling CRUD operations, and translating business requirements into code.
Much of that work was necessary. Much of it still is.
But increasingly, a substantial part of this implementation work can be generated, automated, or accelerated.
This doesn’t mean AI-generated software is automatically better. Producing code faster and delivering reliable software faster are two different things. Anyone who has reviewed a confidently incorrect AI-generated implementation knows the difference.
Still, the economics are changing.
And here’s the question I find much more interesting than whether AI will replace programmers:
If a developer previously spent most of their time implementing forms, APIs, and conventional workflows, what becomes possible when a significant portion of that work gets cheaper?
Should we simply build the same products faster?
Or should we reconsider what those products could become?
What if we stopped thinking of a CRM as a collection of screens?
Take a conventional CRM.
We typically think of customers, contacts, tickets, activities, dashboards, and workflows. Employees navigate between screens, retrieve information, make decisions, and update records.
Now imagine approaching the same problem differently.
Instead of building another interface where employees manually coordinate every step, what if we designed an agent-native CRM and customer support platform?
A customer reports a billing problem.
Rather than simply creating a ticket, the system could identify the customer, retrieve relevant transactions, understand contractual obligations, investigate the issue across multiple systems, determine which actions are permitted, and either resolve the problem or present a well-supported recommendation to a human.
Suddenly, the interesting engineering problems aren’t just about creating another ticket form.
They’re about how the system understands business context, reasons about permissions, coordinates actions, handles uncertainty, recovers from failures, and explains its decisions.
And this is where several technologies become particularly interesting.
Model Context Protocol (MCP) provides a standardized way to expose tools and data to AI applications. It doesn’t magically make your business logic intelligent, but it can change how agents interact with your systems.
LangGraph offers mechanisms for orchestrating stateful, long-running agent workflows, including persistence and human intervention.
Projects like NVIDIA Auto-Ontology explore how to build semantic layers over enterprise data, helping agents understand business concepts and relationships rather than blindly guessing what database columns mean.
Then we get into Context Engineering, Agent Identity, Policy-as-Code, Durable Execution, Observability, Evaluation, and the architecture of agent harnesses.
These aren’t merely new names for CRUD operations.
They represent different engineering concerns.
We can start treating a CRM as a set of business capabilities that can be exposed, orchestrated, and governed through an agent harness, rather than just an application made of screens.
To be clear, I’m not suggesting we replace every deterministic workflow with an LLM. That would be a rather expensive way to introduce uncertainty into problems we’ve already solved.
Sometimes a simple CRUD application is exactly what the business needs.
Knowing when not to introduce an agent is also an engineering skill.
The point is that engineers now have more architectural options, and potentially more time to explore them.
Software engineering was never just about building web applications
Another thing that bothers me about the current debate is how frequently we reduce software engineering to web development and business applications.
Look at industrial automation, autonomous vehicles, medical robotics, aerospace, or real-time control systems.
Do we really believe the interesting engineering problems in these industries are disappearing because AI can generate a controller class or a REST API?
If anything, new capabilities are introducing new problems.
How do we combine probabilistic AI models with deterministic safety requirements?
How do we validate autonomous behavior in unpredictable physical environments?
How do we use World Models, Digital Twins, Vision-Language-Action models, or simulation to develop systems that interact with the physical world?
How do we verify their behavior, handle edge cases, and recover safely when their assumptions turn out to be wrong?
A robot doesn’t get to apologize for a hallucination after crashing into something.
These fields still require serious engineering, often combining software architecture, algorithms, control theory, hardware constraints, testing, and safety.
And many of their problems remain far from solved.
We shouldn’t mistake the decreasing cost of certain software development activities for the disappearance of software engineering itself.
Read the industry reports, not just the headlines
As we approach the end of 2026, I think it’s worth spending less time reacting to dramatic headlines about programmers becoming obsolete and more time examining what’s actually happening across the industry.
Gartner’s Top Strategic Technology Trends for 2027, published in October 2026, identifies developments such as AI Coding Agent Harnesses, AI Context Platforms, AI Agent Identity, World Models, and Disposable Applications.
That last concept is particularly interesting.
For decades, software applications were expensive assets that organizations expected to maintain for years. As production becomes cheaper, some applications may instead be created for specific purposes and intentionally retired when they’re no longer needed.
Think about how dramatically that could change software architecture, procurement, and product strategy.
McKinsey’s Technology Trends Outlook 2026 also examines agentic software development, AI-driven scientific and engineering work, and the future of robotics.
These reports aren’t prophecies. Consulting firms don’t have a crystal ball, even if their presentations sometimes suggest otherwise.
But they offer useful evidence about where research, investment, and industrial experimentation are heading.
They also remind us that the software industry is considerably larger than the subset of it we happen to work in.
So, should software engineers worry about their jobs?
Yes, to some extent.
I don’t believe every developer will automatically benefit from these changes. Some skills will become less valuable, some roles will evolve, and some jobs may disappear.
Pretending otherwise isn’t particularly helpful.
But neither is treating the automation of repetitive programming tasks as evidence that the entire engineering profession is dying.
I’d rather ask myself a different set of questions.
Do I understand modern software architecture beyond the frameworks I use every day?
Am I familiar with the emerging technologies, algorithms, and systems being developed outside my immediate area of work?
Could I design an agent-native system, evaluate its limitations, and decide whether an agent is even appropriate?
Do I understand the fundamentals well enough to recognize when an AI-generated solution is wrong?
And perhaps most importantly, am I learning how to solve new problems, or merely learning how to produce familiar solutions faster?
I don’t think foundational engineering knowledge is becoming irrelevant. Distributed systems, algorithms, data modeling, security, fault tolerance, and architectural reasoning remain essential.
In fact, the more autonomy we give software systems, the more important some of these foundations become.
But knowing what worked ten years ago is not a good reason to stop exploring what might work tomorrow.
The value of software engineering may be shifting away from the effort required to produce code and toward the ability to design useful systems, manage their complexity, and make their behavior trustworthy.
We might write less code ourselves while taking responsibility for considerably more complex systems.
That doesn’t sound like the end of engineering to me.
It sounds like a change in what engineering is being asked to accomplish.
And unlike a Persian carpet, software doesn’t become more valuable simply because we insist on weaving every knot by hand.
The loom is changing. Perhaps it’s time to think about what else we could weave.