Systems Thinking Is the Skill AI Can’t Automate, IEEE Engineer Argues

How AI reshapes the engineering workflow

Aldogom’s description of the new workflow will be familiar to anyone who has used a frontier model on a real design task. An engineer can now define a problem, then use AI tools to search research and technical standards, generate design options, test them in simulation and compare results. Work that once required several people with different technical skills can now be compressed into a single afternoon by one engineer with good tooling.

What happens next is the part that resists automation. The engineer brings those results to specialists for judgments AI cannot make alone: whether the build is safe, whether the design fits a particular setting, what the effects on users will be. The final call on whether and how to proceed belongs to a person who can be held to it.

That division of labor is not a temporary arrangement pending a better model. It is a structural feature of engineering work, because the judgments at the end of the pipeline depend on context, values and accountability that no model currently holds. Aldogom’s framing is that machines excel at speed, scale, search, pattern recognition and data generation, while people are essential for context, values, responsibility and judgment.

The role shift: from performer to coordinator

The consequence is a change in what the job is. The engineer’s role is shifting from performing each technical step to deciding how people, machines and specialists’ knowledge work together. In practice that means making a series of calls that did not exist a decade ago: what work to give AI, what a person must check, when a specialist should decide, and when the problem itself needs redefining.

This is a quieter shift than the automation headlines suggest, and it is already visible in adjacent tooling. The same instinct that leads an engineer to script away a repetitive task now applies to design search and literature review. The difference is that a deterministic script produces the same output every time, while a model’s output needs verification before anyone builds on it.

Disciplines persist, but the boundaries get porous

Aldogom is careful not to claim that AI dissolves engineering disciplines. Electrical, mechanical, civil and software engineering persist, and AI does not replace the years of deep knowledge each requires. What changes is how easily an engineer can explore parts of a problem outside their own specialty.

His example is a software engineer working on a medical device. With AI, that engineer can review biomedical research, understand unfamiliar terms, analyze data and build an early model, all without becoming a physician or a biomedical expert. The point is not to substitute for the specialist but to ask better questions before consulting one.

The same pattern shows up in energy, transportation, manufacturing and elsewhere, where a problem may start as software and quickly involve hardware, safety, economics, human behavior and regulations. Engineers need not master every field. They need to recognize which expertise a problem requires and bring the right people and tools together.

Why systems thinking matters more, not less

Systems thinking, in Aldogom’s account, means looking at the whole problem: how the parts affect one another, where the constraints and failure points sit, and which trade-offs are worth making. AI adds a new layer of decisions on top of that: what to delegate, what to verify, when a specialist should take the lead, and when the framing itself is wrong.

His key line, quoted in the source, is worth quoting in full: “An engineer’s value is not in knowing everything. It is in knowing how to frame the problem, how to ask the right questions, how to test the answers, and when another expert must lead the project.”

Every item on that list is a judgment about scope, evidence or authority. None of them is a lookup, and none of them gets easier when generation becomes cheap. If anything, cheap generation raises the stakes on all four, because there is now far more plausible material to sift. The same logic applies to the problem statement itself: engineering challenges are seldom static, and new insights can shift objectives, surface unseen limitations or reveal that the initial premise was flawed. Aldogom notes that effective engineers revise the initial problem statement as their understanding of the system deepens, rather than rigidly following starting specifications. That is a disciplined habit, not a concession, and it is exactly the behavior AI-assisted workflows tend to discourage, because a model will happily keep optimizing the problem you gave it long after the problem has changed. An engineer who treats the specification as fixed will get fast, confident answers to the wrong question. An engineer who treats it as a living hypothesis will notice when the ground moves and adjust before the design hardens.

Where AI falls short

Aldogom is direct about the failure modes, and his list reads like a field guide to what engineers actually encounter. AI can produce convincing answers even when its assumptions are weak. It can generate code that works in one test but fails in another. It can summarize research without understanding which evidence is strongest, or optimize a design for the wrong goal.

Each of these is a different kind of error, and each requires a different kind of human check. Weak assumptions need someone who knows the domain well enough to spot them. Flaky code needs someone who will write the second test. A summary that misses the strongest evidence needs someone who has read the literature. A design optimized for the wrong goal needs someone who knows what the goal should have been.

These limits make human expertise more important, not less. That argument runs against the prevailing narrative in both directions: against the optimists who expect models to close every gap, and against the pessimists who expect engineering judgment itself to be commoditized.

A worked example: the medical sensor

The clearest illustration in the piece is a medical sensor. AI might generate several designs and predict each one’s performance. An engineer tests the predictions and rejects designs that violate technical requirements. A clinician then judges whether the sensor is realistically usable. Patients and practitioners may reveal problems neither the engineer nor the developer considered.

The final solution emerges from combining these perspectives. No single participant could have produced it alone, and no single model could have validated it alone. The engineer remains a builder and a specialist, but is increasingly also a coordinator of knowledge, deciding which perspective the problem needs next and in what order.

What engineers should take away

Three practical conclusions follow from Aldogom’s argument, and they are worth stating plainly.

First, treat AI as a fast search-and-generation layer. Use it to survey standards, draft options and run comparisons, then verify the output against the requirements that matter. Speed at the front of the pipeline is valuable only if the back of the pipeline holds.

Second, keep judgment and accountability human. The decision to proceed is not a technical step that can be delegated, and the engineer who signs off on a design owns the consequences of doing so.

Third, invest in problem framing and cross-domain coordination as core skills rather than soft extras. The engineers who will be most valuable in the next few years are the ones who can take a vague, multidisciplinary problem, decide which parts to hand to a machine, which to hand to a specialist, and which to keep for themselves. That is systems thinking, and it is the part of the job that gets more valuable as everything around it gets cheaper.

We covered second requested skill job in more detail elsewhere.