Esotericism
Is Dead.

My hot take: esoteric engineering software is cooked. Adding an MCP server won’t save it.

For decades, engineers have spent years learning how to operate tools like CAD, EDA, HMI/GUI frameworks. Each has its own way of organizing projects, configuring systems, and getting work done. Becoming productive means learning those conventions, understanding their behavior, and knowing what to do when they break.

A lot of what we call experience is accumulated knowledge of how to make a particular piece of software tool do what we already know we want.

That knowledge has been valuable because it was necessary. I think agents are about to make much of it unnecessary.

Built around the operator

These tools were built around a human doing the work. The engineer had to move information between screens, configure every component, and follow the right sequence of steps. Vendors spent decades building workflows to make that process manageable and efficient.

Those workflows solved real problems. But they also required every engineer to learn the vendor’s way of thinking before they could get anything done.

You can understand exactly how a machine should operate and still spend days figuring out how to express that in the software, I’ve faced this firsthand. You know the inputs, the outputs, the logic needed, and the failure conditions. What holds you up is getting all of that into the tool in the form it expects.

We’ve accepted that as part of engineering for a long time.

With agents, we can start building the process around what the engineer actually needs. The engineer defines the objective and the constraints. The agent handles the configuration, translation, and repetitive work, then brings back a result the engineer can inspect and validate.

The workflow can be specific to the task. It doesn’t need to be something a vendor designed years ago and every user has to memorize.

This is where I think a lot of existing engineering software gets into trouble.

The workflow is already changing

Start with something familiar like removing the background from a photo. You used to carefully trace the subject with a lasso, refine the edges, and build a mask. Now Canva offers a button for it. You still need to judge whether the result looks right. But you wanted the background gone. Learning the mechanics was a cost of getting there.

Now think about designing a circuit board. An electrical engineer needs to understand how much current a trace can carry, where the return path goes, and what creates noise. Those decisions matter whether the board is designed in KiCad, Altium, or anything else. Remembering which dialog configures a clearance rule is a different kind of knowledge.

That is the work I want agents to take on: turn the engineer’s requirements into the project’s rules, apply them consistently, and surface violations for review. The engineer still has to choose the right requirements and evaluate the board. Making the software express those requirements should take less of their time.

The same problem gets bigger when a decision crosses several tools. Imagine replacing a pressure transducer with one that has a different measurement range. You may need to update input scaling, review alarm thresholds, adjust an HMI display, check historian settings, and revise the documentation.

The engineer needs to understand what that change means for the process. A wider sensor range does not automatically mean the machine can operate at a higher pressure. An agent should trace the affected references, propose the changes, preserve the limits that still apply, and bring back a result the engineer can verify and ship.

Knowing what needs to change is expertise. Knowing every place the software makes you repeat that change should not have to be.

Photo editing already shows how much of a familiar workflow can disappear. I expect engineering tools to move in the same direction, with more of the work organized around the engineer’s intent and more of the engineer’s attention spent checking the result.

MCP doesn’t change the assumptions

The obvious response by the industry is to add an MCP server so agents can use the product. That’s useful, but it only gets you so far. Giving an agent access to your software doesn’t change the assumptions the software was built on.

If every operation still depends on a rigid sequence of steps, hidden project state, and conventions designed around a human clicking through an interface, the agent has to work around all of that too.

You’ve given it access to the same complexity your customers have been dealing with for years. That’s some real tech debt AI native alternatives just don’t have to carry.

My bet is that a large portion of today’s engineering software will turn out to exist primarily to help humans operate the software. As agents take over that work, a lot of those features become unnecessary. Some become obstacles.

That’s why I don’t think adding an AI interface will be enough. A product designed around agents can make different decisions about how projects are represented, how changes are made, and how results are verified. It can give agents direct access to the things that matter without carrying every assumption from the old workflow.

This doesn’t require throwing away every line of old code. What matters is whether the product lets an agent carry out the task and check the result, or just exposes the steps a human used to click through. An incumbent can make that change too. Shipping an MCP server alone doesn’t accomplish it.

The incumbents still have valuable technology. Reliable solvers, compilers, simulation, and hardware integration take serious engineering to build. That work absolutely matters. But the workflows wrapped around that technology need to earn their place again. Having spent 30 years building them doesn’t mean they’re the right way to work for the next 30.

Engineering expertise matters

Garry Tan put the opportunity plainly in a Y Combinator video:

“The barrier to building just collapsed. The only question left is what are you going to build?”

That question gets at why fundamentals matter more as execution gets cheaper. Knowing what is worth building, which constraints matter, and whether the result is any good takes judgment. Agents give that judgment more reach.

For engineers, I think this is a very good thing.

Understanding why a process oscillates, how heat moves through a system, or what happens when a sensor fails will remain valuable. Those problems are rooted in the physical world. You still need strong engineering judgment to choose the right constraints and know whether a result makes sense.

Knowing which obscure setting makes a vendor’s software behave is useful for as long as that setting is your problem.

Today, experienced engineers carry both kinds of knowledge. We should be giving them more time to apply their understanding of the world, and fewer reasons to memorize the quirks of a tool.

The same applies to engineers entering the field. Someone with strong fundamentals should be able to contribute without first spending years becoming fluent in a particular software environment. They still need to learn the machine, understand the process, and develop judgment. We should make it easier for them to spend their time doing exactly that.

Give the power back

This is what I mean when I say esotericism is dead. The value of knowing an artificial system’s rituals is going down. The value of understanding the actual engineering problem is going up.

We have real, difficult problems to solve. Engineers should be focused on making machines more reliable, processes more efficient, and systems safer. Agents should take care of more of the mundane work required to turn those decisions into something that runs.

Give the power (and time) back to the engineers.

Let them tame atoms, not bits