What Is the Part of Your Work You Would Never Let a Machine Do?

A two-part reflection on craft, identity, and the age of AI

There is a difference between executing code and engineering a solution.

Executing code is deterministic. You give it inputs, and it returns outputs. It can be automated, parallelized, and eventually replaced. Engineering a solution is something else entirely. It is the act of looking at a broken system, a vague brief, or a blank architecture diagram and deciding what should exist and why. That decision cannot be compiled. It cannot be unit tested. It lives in the judgment of the person who made it.

A software engineer once described the shift this way: the stack used to be your edge. Knowing the memory model, owning the infrastructure, and understanding what happened between the request and the response. But that edge is disappearing, not because engineering is dying, but because the infrastructure layer moved to the cloud, the cloud moved to abstraction, and abstraction is now moving to AI. What remains what will always remain is the thing no model can generate: the capacity to understand what a problem is actually asking, to sit with ambiguity without resolving it prematurely, and to make an architectural decision that carries consequence because a human being thought it through and chose it.

The question this raises for every engineer is the same: What is the part of your work that you would never let a machine do for you?

That question is not about job security. It is about identity. It is about knowing the difference between what you ship and what you think.

Part One: The Metrologist in the Age of AI

The Hardware Edge Is Disappearing

For decades, the metrologist's authority rested partly on proximity to the instrument. Knowing how a coordinate measuring machine behaves under temperature drift. Understanding the Abbe error principle not as a formula but as something you felt when a measurement came back wrong, and you knew before the software told you that the stylus had deflected. That embodied knowledge was rare. It was trained into you over the years. It was your edge.

AI is eroding that edge, and it will continue to do so.

Machine learning models can now detect calibration drift earlier than a human technician. Automated systems can run measurement cycles, flag anomalies, generate uncertainty budgets, and produce GR&R reports without a metrologist in the room. The software layer is absorbing what used to require a skilled hand and a trained eye.

This is not a threat. It is a clarification.

What Metrology Has Always Really Been About

Strip away the instruments, and what is a metrologist? At their core, they are someone who decides what truth looks like in a given context.

That is a philosophical act dressed in engineering clothes.

When a metrologist defines a measurement process by choosing the reference standard, establishing the measurement environment, and determining the acceptable level of uncertainty for a specific application, they are not merely following a procedure. They are making a judgment about what matters and how much it matters. They are asking: What is the consequence of being wrong? What is the risk to the process, the product, the person downstream?

AI can calculate uncertainty. It cannot judge the consequence of uncertainty in context. It cannot sit in a room with a manufacturing engineer and a quality director and say: " The number is within tolerance, but I am not comfortable with this measurement because the process upstream is unstable and this result does not feel representative. That sentence requires experience, judgment, trust, and the courage to say something that disrupts a release schedule.

The Metrologist Who Will Thrive

The metrologist of the AI age will be less a technician and more a measurement philosopher, someone who asks the questions the machine is not programmed to ask.

They will define what should be measured and why, not just how. They will translate between the language of engineering and the language of uncertainty. They will be the person in the room who knows that a measurement system can be precise yet useless if it measures the wrong thing.

They will also be the custodian of the trust. In a world where data is generated automatically, and audit trails are maintained by software, someone still has to stand behind the result and say, "I believe this." That is not a technical statement. It is a professional and moral one.

The metrologist's job will shift from operating the machine to interpreting its output and, more importantly, questioning it. The best metrologists have always known that the most dangerous number is the one that looks right.

The Part You Should Never Let a Machine Do

The essence of metrology, the part that no algorithm should own, is the act of defining fitness for purpose. What level of uncertainty is acceptable for this application, for this customer, for this risk profile? That question cannot be answered by computation alone. It requires judgment, and judgment requires a person who understands consequences, not just numbers.

Do not let a machine decide what truth is worth.

Part Two: The Software Engineer in the Age of AI

The Code Is No Longer the Moat

For a long time, the ability to write code was itself a form of power. To know Python, to understand data structures, to debug a recursive function at 2 am, these were skills that separated those who could build the future from those who could only use it.

That separation is collapsing.

AI can write functions, scaffold entire applications, refactor legacy code, generate unit tests, and explain a stack trace faster than any senior engineer. The mechanical act of translating logic into syntax, which once required years of training, is now available to anyone with an internet connection and a prompt.

The edge that came from writing code is disappearing. What remains is the edge that came from thinking clearly about problems.

What Software Engineering Has Always Really Been About

Ask any experienced engineer what they actually do, and if they are honest, they will tell you: they spend most of their time understanding the problem, not solving it.

The code is almost never the hard part. The hard part is knowing what to build. It is sitting with a product manager who is asking for one thing and actually needs another. It is realizing that the feature request is a symptom, and the disease lies elsewhere in the system. It is knowing when not to build something when the elegant solution is the one that removes code rather than adds it.

That capacity to understand human intent, to navigate ambiguity, to make architectural decisions that will constrain everything that comes after is not a technical skill. It is a thinking skill. It is what separates engineers who build products from engineers who build features.

AI can implement. It cannot originate. It cannot sit with the discomfort of a poorly defined problem and resist the temptation to solve the wrong thing cleanly.

The Software Engineer Who Will Thrive

The engineers who will thrive are not the ones who can prompt AI most cleverly, though that matters. They are the ones who bring something the AI cannot: judgment about what is worth building and why.

They will be systems thinkers who can see the second and third-order consequences of an architectural decision. They will be translators who can move between the business language and the machine language. They will be the person in the room who says, "Before we build this, can we talk about what problem we are actually trying to solve?"

They will also be the ethical voice in the system. As AI-generated code proliferates, someone has to take responsibility for it, not just whether it runs, but whether it is fair, whether it is secure, and whether it respects the people who will be affected by it. A machine cannot be responsible. A person can.

The Part You Should Never Let a Machine Do

The essence of software engineering, the part that belongs to you, is the act of defining the problem worth solving.

Before a line of code is written, someone has to ask: what are we actually trying to do here, and does this solution serve the people it is meant to serve? That question is not technical. It is a human one. It requires curiosity, empathy, and the willingness to say "I don't know yet," which a machine will never say, because a machine fills the void with confident-sounding output.

Do not let a machine decide what is worth building.

The Question That Holds Both

A metrologist, a software engineer. Different crafts, the same underlying truth.

The operational edge disappears. What remains is the thing that was always at the center, even when it was obscured by the mechanics of the work: the capacity to interpret, to judge, to feel the weight of a decision and carry it as a professional and a human being.

AI is not stealing your craft. It is stripping away the parts of your craft that were never really yours, to keep the parts that belonged to the machine all along.

What is left is the part that always mattered most.

That is the part you should protect.

What is the part of your work that you would never let a machine do for you?