Future of Engineering: The Promise of AI

Four promises made about AI in engineering are delivered, three are partly delivered and rising fast, one is contested, and two have barely started. The line between them is not model capability. It is whether a trusted evaluator sits in the loop.

Two results from the same eighteen months tell you most of what you need to know.

In the first, a Google DeepMind system called AlphaEvolve wrote a new scheduling heuristic for Borg, the orchestrator that runs Google’s data centres. It was tested in a simulator built from historical workloads, deployed, and measured across the fleet. The heuristic continuously recovers on average 0.7% of Google’s fleet-wide compute that would otherwise sit stranded, and it has done so for over a year. The same system rewrote part of a highly optimised Verilog implementation of an arithmetic circuit in the matrix-multiplication unit of an upcoming TPU, and the rewrite passed the full verification suite and was integrated. It found a way to multiply two 4×4 complex matrices with 48 scalar multiplications, the first improvement in that setting on Strassen’s 1969 algorithm in 56 years.

In the second, an autonomous laboratory at Berkeley reported in Nature that over 17 days of robotic operation it had synthesised 41 new inorganic compounds out of 58 targets. Within weeks, solid-state chemists at UCL and Princeton argued that its automated X-ray refinement was at “novice human level,” that roughly two-thirds of the predicted compounds were ordered versions of materials already known in disordered form, and that no new materials had been discovered at all. In January 2026 Nature published an Author Correction. The version of the paper Nature now serves reports 36 of 57 targets. Its title used to end “the accelerated synthesis of novel materials.” It now ends “the accelerated synthesis of inorganic materials.”

Both are AI doing work that engineers do. Both came from world-class teams. One delivered exactly what it claimed and is running in production. The other overclaimed, was caught, and was corrected. The difference was not the model, the funding or the ambition. In the first case, every output passed through an automated evaluator the organisation already trusted — a fleet simulator, a hardware verification suite — before anyone believed it. In the second, the evaluator was the weakest link in the pipeline, and generation ran ahead of checking.

That is the pattern this report finds across the whole field, and it is a more useful finding than either of the two stories usually told. The promoter’s story is that AI is about to transform engineering. The sceptic’s story is that AI cannot do real engineering, only code. Both are wrong in the same way: they treat capability as a property of the model. The evidence says capability in engineering is a property of the model plus the evaluator, and the promise is being kept precisely where the second half exists.

Some reports on the topic get that badly wrong, and the way it went wrong is instructive enough to state up front. They argue that the machines were “worst at engineering,” built on a benchmark in which the best model scored 56.6% on strength of materials. On checking the full paper, the best model tested was Qwen-plus; no frontier reasoning model was evaluated at all. A second benchmark it cited as showing degradation under perturbation in fact shows the strongest model tested scoring above 80% and losing only 1.2% under perturbation. A third figure was attributed to the wrong paper. The lesson it leaves is part of the argument below: engineering benchmarks are routinely a model-generation or two behind the frontier, so anyone who reads them without checking which models were tested will systematically underestimate the machines.

So this is a grading, done carefully. Ten promises commonly made about AI in engineering, each assessed on four things: what has actually been delivered, how strong the evidence is, which way the trajectory points, and — the variable that turns out to decide everything — what checks the answer. The companion reports take the result into the two places it lands hardest: who is legally accountable when the machine produced the design, and how an engineer is formed when the machine does the exercises.

What this report argues

1. AI in engineering is delivering real, measured value in production today — in chip layout, infrastructure optimisation, weather simulation and lightweight structural design — and the scale of those results is routinely understated by sceptics.

2. Every delivered case has an automated evaluator the organisation already trusts in the loop: a verification suite, a fleet simulator, a finite-element check, observations of the atmosphere.

3. Every contested case is one where generation outran verification — most clearly materials discovery, where 2.2 million predicted crystals met a field that could experimentally check a few hundred.

4. On engineering problem-solving, frontier models are strong and improving fast: 75% on the FE Environmental exam in 2023, above 80% and stable under perturbation on EngiBench’s contextual-reasoning tier, and from 34% to nearly 60% on real design tasks when allowed to iterate against a simulator.

5. The weak spots are specific, not general: reading technical drawings, open-ended modelling, and design trade-offs with no single right answer — where humans still clearly lead.

6. Engineering benchmarks lag the frontier by a model generation or more, so the field does not currently know where the best systems stand on physical engineering — a measurement failure, not a capability finding.

7. Productivity evidence is almost entirely from software, and it has swung: 55.8% faster on a greenfield task, then 19% slower for experts on mature codebases in early 2025, then an estimated 18% faster by late 2025 — with every one of those numbers carrying caveats that matter.

8. Autonomy is growing on an exponential: the length of task an AI agent completes half the time has doubled roughly every seven months since 2019, and faster since 2024 — but the measured tasks are software and research, not physical engineering.

9. Adoption lags capability badly: only 27% of 1,000 surveyed architecture, engineering and construction professionals use AI at all, and 69% say regulatory uncertainty has affected their plans.

10. The binding constraint on the promise is evaluator infrastructure — simulators, verification suites, test rigs, validated reference cases — and building that infrastructure is engineering work.

11. This relocates the engineer’s value rather than removing it: specifying constraints, building and trusting evaluators, and adjudicating the cases no evaluator covers.

12. Here is what would change the assessment in either direction, stated precisely enough to be checked.

How the promises are graded

Each promise receives four assessments.

Verdict. Delivered means a system is running in production or in real mission hardware with published, externally checkable results. Partly delivered, rising means capability is real and measured but incomplete, with a clear upward trajectory. Contested means the headline claims are disputed in the peer-reviewed record. Early means credible demonstrations exist but nothing approaches routine use.

Evidence strength. Strong: peer-reviewed results with post-deployment measurement, or randomised trials. Moderate: benchmark results from independent teams, or deployment reports from the deploying organisation only. Weak: demonstrations, surveys, or vendor claims.

Trajectory. The direction and speed of change over the last two to three years, where the record allows a judgement.

What checks the answer. The evaluator — the thing that establishes the output is right before anyone relies on it. This turns out to predict the verdict almost perfectly, which is the main finding and is drawn out in section 11.

1. “AI will design better physical parts” — Delivered, with a solver in the loop

Verdict: Delivered · Evidence: Moderate to strong · Trajectory: Rising · What checks it: finite-element analysis, then physical test.

The cleanest proof case in engineering proper is NASA Goddard’s Evolved Structures programme, led by Ryan McClelland. The process is precise about who does what. A human specifies the design study: desired mass, minimum factor of safety, interfaces with other components, keep-out zones — including space for a laser path and for a technician’s hands during assembly — structural loads, minimum natural frequency, materials, manufacturing process. Commercial generative-design software produces the geometry. The part is analysed, then fabricated directly from the model.

The results, from McClelland’s SPIE paper: greater than 10x reduction in development time and cost and greater than 3x improvement in structural performance across mass, stiffness and strength. NASA reports that design generation takes “as little as an hour or two,” a prototype can be in hand within a week, parts reach about two-thirds lower weight than conventional equivalents, and stress concentrations run almost ten times lower than in parts produced by an expert human. These are not lab curiosities. Evolved components have been adopted on astrophysics balloon observatories including the EXCITE exoplanet telescope, Earth-atmosphere scanners, planetary instruments, space-weather monitors, space telescopes, and hardware for Mars Sample Return.

The critical half. A separate study in this library attacked the deep-learning surrogates used for fast topology optimisation with bounded adversarial perturbations and found that in vulnerable architectures compliance rose by multiple orders of magnitude through severed load paths — a part that looks optimised and carries almost no load. That is a real finding, and it is worth being exact about what it means. It is a worst-case attack on fast neural surrogates, not a finding about the solver-based generative design NASA uses. What it establishes is that a learned surrogate must never be the last word on a load-bearing part — which is precisely the discipline the working deployments already follow. McClelland’s own summary: “The algorithms do need a human eye. Human intuition knows what looks right, but left to itself, the algorithm can sometimes make structures too thin.”

Promise kept, where a physics solver checks every candidate and a human defines what the part must do.

2. “AI will lay out chips” — Delivered inside Google, contested outside it

Verdict: Delivered in-house; reproducibility contested · Evidence: Moderate · Trajectory: Rising · What checks it: electronic design automation sign-off.

AlphaChip, the reinforcement-learning placement method Google published in 2021, is according to its developers now responsible for “superhuman chip layouts used in three generations of TPU,” the Axion datacenter CPU, and other chips across Alphabet — and in each generation it has been “adopted in a greater proportion of blocks and has outperformed human experts by a wider margin.” That is a strong claim of production use at the most demanding end of the semiconductor industry.

It is also the most publicly disputed result in this entire library. An independent assessment from Cheng and colleagues found that simulated annealing and human baselines continued to outperform AlphaChip while using substantially fewer resources, and that an improved annealer achieved up to 26% better proxy cost in the same runtime on a quarter of the compute. Google’s response, That Chip Has Sailed, argues the reproduction failed on method — above all that it did not pre-train the model, which is what makes a learning-based placer improve with experience. A 2026 paper in the library adds a third position: that reinforcement-learning placers trained mainly on wirelength “often fail to achieve expert-quality layouts” because the reward is wrong, and that learning a reward model from expert layouts closes much of the gap.

The honest reading: in its home environment, with its training pipeline and its production sign-off flow, the system works and ships. Outside that environment the result has not been cleanly reproduced. Both things can be true, and the second is a serious limitation for anyone outside Google.

The adjacent evidence is less contested. NVIDIA’s domain-adapted ChipNeMo-70B outperformed GPT-4 on engineering-assistant chat and EDA script generation for its own design teams. AlphaEvolve’s Verilog rewrite passed the full TPU verification suite. In every case the output is only as trustworthy as the sign-off flow it passes through — and chip design happens to have the most mature automated verification infrastructure of any engineering discipline.

3. “AI will replace slow physics codes with fast learned surrogates” — Delivered in weather, early in engineering simulation

Verdict: Delivered for weather; early for structures and fluids · Evidence: Strong for weather · Trajectory: Rising fast · What checks it: reality — forecasts are scored against observations every day.

The strongest single result in this library is not from engineering in the narrow sense, but it is the proof of concept engineering simulation is chasing. GraphCast, a learned weather model, significantly outperforms the most accurate operational deterministic system on 90% of 1,380 verification targets, with better prediction of tropical cyclones, atmospheric rivers and extreme temperatures. Its probabilistic successor GenCast has greater skill than ECMWF’s ensemble on 97.4% of 1,320 targets, and better predicts extreme weather and wind-power production. ECMWF has run GraphCast forecasts experimentally, and GenCast is now part of Google’s operational WeatherNext family.

Weather matters for this argument for a structural reason. It is the one simulation domain with an enormous, continuous, free, objective evaluator: the atmosphere, scored against observations every six hours. The learned models could be trained on decades of reanalysis and judged on a daily basis. Nothing about the model architecture explains the success as well as the evaluator does.

Engineering simulation — computational fluid dynamics, structural mechanics, thermal — is attempting the same move with graph neural networks on large meshes, physics-constrained operators and reduced-order models, several of which are in this library. The early results are promising for speed. They are also data-hungry, and a paper in this library is devoted entirely to quantifying how much data a flow surrogate needs. The adversarial topology-optimisation study in section 1 shows the failure mode. The path to the weather result runs through validated reference data, which most engineering domains do not yet have at anything like weather’s scale.

4. “AI will optimise the machinery that runs the world” — Delivered

Verdict: Delivered · Evidence: Strong (post-deployment measurement) · Trajectory: Rising · What checks it: an automated evaluator built into the search loop.

AlphaEvolve is the clearest demonstration in the library of what a coding agent does when it is paired with an evaluator. Beyond the 0.7% fleet compute recovery, the system found a heuristic giving an average 23% kernel speedup over the expert-designed one and a 1% reduction in Gemini’s overall training time, sped up a FlashAttention kernel configuration by 32%, and improved the state of the art for 14 matrix-multiplication algorithms.

What makes these results trustworthy is not the language model. It is the architecture: every candidate program is scored by an automated evaluator — a simulator, a benchmark harness, a verification suite — and only survivors propagate. The paper is explicit that the Verilog changes were communicated in the hardware engineers’ own language “fostering trust and simplifying adoption,” and that post-deployment fleet measurements “confirmed the simulator results.” This is engineering in the most literal sense: optimisation of a physical system under constraints, with an engineer-built evaluator doing the certification.

The limitation is the flip side of the strength. AlphaEvolve works where the objective can be written as a program and evaluated automatically. Most engineering problems are not yet written that way.

5. “AI will discover new materials” — Contested

Verdict: Contested · Evidence: Moderate, with strong counter-evidence · Trajectory: Unclear · What checks it: expert experimental characterisation — the bottleneck.

GNoME, Google DeepMind’s materials model, reported 2.2 million structures below the known convex hull, an updated hull of 381,000 new stable entries — an order-of-magnitude expansion of all previously known stable crystals — and noted that 736 had already been independently experimentally realised. The scale is extraordinary.

The contest is over what the scale means. Cheetham and Seshadri, reviewing the output, found “scant evidence” that the compounds are simultaneously novel, credible and useful. The A-Lab episode described in the introduction — which used GNoME and Materials Project predictions as targets — is the experimental face of the same dispute: an automated pipeline that could propose and attempt synthesis far faster than it could correctly characterise what it had made, with the characterisation step (Rietveld refinement of diffraction data) performed at a level one critic called novice, and a peer-reviewed claim corrected two years later with the word “novel” removed from its title.

This is the sharpest illustration in the library of the report’s central claim. Generation scaled by a factor of millions. Verification — careful expert structural determination, and then the long work of establishing whether a material does anything useful — did not scale at all. The promise is not broken; 736 independent realisations are real. But it is unproven at the scale being claimed, and the reason is exactly the missing evaluator.

6. “AI will solve engineering problems the way an engineer does” — Partly delivered, rising fast

Verdict: Partly delivered, rising · Evidence: Moderate (independent benchmarks, lagging frontier) · Trajectory: Rising fast · What checks it: answer keys for closed problems; simulators for design tasks; nothing yet for open-ended modelling.

This is where the withdrawn draft went wrong, so the numbers are given with the models attached.

Licensing exams. In 2023, GPT-4 scored 66.42% on a Fundamentals of Engineering Environmental question set, rising to 75.37% with refined prompting — which the authors reasonably consider a passing grade. On FE Mechanical, GPT-4 answered 76% correctly against 51% for GPT-3.5, but both were text-only, and the authors conclude that the diagram-heavy real exam made passing unlikely. Three model generations have shipped since.

EngiBench grades problems at three levels: knowledge retrieval, contextual reasoning and open-ended modelling, and rewrites each into perturbed and abstracted variants. At the first level most models cluster between 70% and 90%. At the contextual-reasoning level, the strongest models tested — GPT-4.1 and Gemini 2.5 Flash — exceed 80% accuracy, and Gemini 2.5 Flash loses only 1.2% under perturbation, which is evidence of genuine competence rather than pattern-matching; a 7-billion-parameter model on the same tier drops 11.4%. Lightweight models collapse: a distilled 7-billion-parameter reasoning model reaches about 52%, others fall below 40%. The divergence is widest at the open-ended modelling level, where human experts still substantially outperform all models.

ENGDESIGN is the most realistic test: design tasks across domains are evaluated by running the proposed design through domain simulation against stated performance goals. On a single attempt, the best model, o3, passes 34.38%. Allowed to iterate against the simulator’s feedback, o3 reaches almost 60% after ten iterations. Reasoning models outperform chat models across most engineering domains. Some domains — analog IC design is the named example — still fail after ten iterations. The authors identify the recurring failures as over-reliance on textual patterns and failure to handle trade-offs.

SoM-1K, a benchmark of 1,065 strength-of-materials problems, reports a best score of 56.6% — but that best model is Qwen-plus, and the models tested were GPT-4o, DeepSeek-R1 and V3, Llama 3.3 70B and Qwen variants. No frontier reasoning model from OpenAI, Google or Anthropic was evaluated. The number says little about the frontier and a lot about measurement lag.

Diagrams remain the weakest modality. EEE-Bench, an electrical-engineering benchmark cited in SoM-1K, found vision-language models of its generation averaging 19.48% to 46.78%; SoM-1K itself found that text descriptions of diagrams often worked better than the diagrams. The 2026 “Do VLMs Reason Like Engineers?” study, which decomposes attempts into stages from assumptions through equation selection to final answer, is valuable less for its scores than for its method: it locates failures in physical modelling rather than algebra.

For context on the pace. When GPQA — graduate-level science questions written to be “Google-proof” — was published in 2023, PhD-level experts scored 65%, skilled non-experts 34%, and GPT-4 39%. Frontier models now report scores above 90% on its hardest subset, according to their developers. When SWE-bench was published, the best model resolved 1.96% of real GitHub issues; developer-reported scores on its verified subset now sit around 80%. Neither is an engineering benchmark in the narrow sense. Both show how quickly “the models cannot do this” has expired on hard technical tasks with checkable answers.

The accurate summary: on closed engineering problems, frontier models are at or above the level of a competent graduate and improving fast. On design tasks, they succeed a third of the time alone and more than half the time when they can iterate against a simulator. On open-ended modelling, trade-offs and drawings, humans lead — for now.

7. “AI will make engineers more productive” — Mixed, turning positive; the evidence is software

Verdict: Partly delivered · Evidence: Strong (RCTs), but almost entirely software · Trajectory: Rising · What checks it: tests and code review.

The randomised evidence is better than for any other promise, and it is genuinely mixed.

In the 2023 GitHub, Microsoft and MIT trial, developers with Copilot completed a greenfield task 55.8% faster (95% confidence interval 21–89%). In METR’s 2025 randomised trial — 16 experienced open-source developers, 246 real issues in mature repositories they had worked on for an average of five years, using Cursor Pro with Claude 3.5 and 3.7 Sonnet — allowing AI made tasks take 19% longer (confidence interval +2% to +39%). The developers had expected a 24% speedup and, afterwards, still believed they had been sped up by 20%. The gap between perceived and measured productivity is itself one of the most important findings in the library.

METR repeated the experiment with late-2025 tools. For the original developers who returned, the estimate reversed to an 18% reduction in completion time, with a confidence interval of −38% to +9% — crossing zero, so not statistically established. For newly recruited developers it was 4%. METR reports that “our raw results show some evidence for speedup,” and that the estimates are biased downward because a growing number of developers declined to take part at all: they no longer wished to work without AI. METR says it believes developers were more sped up in early 2026 than in early 2025, and is redesigning the study.

Anthropic’s analysis of millions of Claude conversations adds the usage shape: the highest use is in software-engineering roles, and 57% of interactions look like augmentation — iterating, learning, refining — against 43% that look like automation.

The critical point for this report is the one METR states among its own caveats: the results do not show anything about domains beyond software. There is, as far as this library shows, no published randomised trial of AI assistance on structural, mechanical, electrical or chemical engineering work. The productivity promise in engineering proper is unmeasured.

8. “AI will work autonomously on long engineering tasks” — Strong trajectory, narrow domain

Verdict: Partly delivered, rising fast · Evidence: Strong for its domain · Trajectory: Exponential · What checks it: automated task scoring in software and research environments.

METR measures the length of task, in human-professional time, that an AI agent can complete with 50% reliability. In the original study, frontier models such as o3 had a 50% horizon of around 110 minutes, and the horizon had doubled approximately every seven months since 2019, possibly faster since 2024. METR’s Time Horizon 1.1 update in January 2026, on a larger suite of 228 tasks, put GPT-5 at 214 minutes and Claude Opus 4.5 at 320 minutes — over five hours — with doubling estimated at about 131 days since 2023 and about 89 days since 2024.

The caveats are METR’s own and they matter. The measured horizon is at 50% reliability; the 80% horizon is several times shorter. The suite covers “skills required for research or software engineering.” The confidence intervals are wide, and METR notes that the suite “has relatively few tasks that the latest generation of models cannot perform successfully” — the frontier is running out of ruler.

For engineering, the implication is directional rather than quantitative. The capacity for sustained, multi-step, self-correcting technical work is growing faster than any other capability measured in this library. Whether that transfers to engineering tasks with physical constraints and no automated scorer is exactly what nobody has measured.

9. “AI will run the laboratory” — Early

Verdict: Early · Evidence: Weak to moderate · Trajectory: Rising · What checks it: the experiment itself — when it is characterised correctly.

Coscientist, published in 2023, combined multiple language models to design, plan and execute chemistry experiments through laboratory automation. Self-driving laboratories for thin films and materials synthesis, and LLM-driven materials design agents, are in the library. These systems are genuinely promising for a specific reason: they re-attach a physical evaluator — the experiment — to the generative loop, which is exactly what the materials-discovery case lacked at scale.

The A-Lab correction is the warning attached to the promise. An autonomous lab is only as good as its automated characterisation, and in the published case that was the weak link. A 2025 perspective in the library, The Need for Verification in AI-Driven Scientific Discovery, states the general form: without scalable and reliable verification, an abundance of machine-generated hypotheses risks slowing progress rather than accelerating it.

10. “Industry is adopting AI in engineering” — Not yet

Verdict: Early · Evidence: Moderate (surveys) · Trajectory: Rising slowly · What checks it: not applicable.

In a Bluebeam survey of 1,000 architecture, engineering and construction professionals published in October 2025, only 27% use AI in their operations at all — though 94% of those who do plan to increase use in 2026. The barriers are institutional, not technical: 42% cite data-sharing security, 33% cost and complexity, and 69% say uncertainty about AI regulation has affected their implementation plans. More than half still use paper during design.

Set that beside sections 1 through 8 and the gap is the story. The capability exists, in narrow but real forms, and the adoption does not. The companion report on licensure and liability argues that the regulatory uncertainty respondents cite is not a vague anxiety but a precise unanswered question: who signs.

11. The pattern: the evaluator decides

Line the ten promises up by verdict and look at the right-hand column.

• Designing parts — Delivered — checked by finite-element analysis and physical test, with a human specifying constraints.

• Chip layout — Delivered in-house — checked by EDA sign-off; contested where outsiders could not reproduce the training pipeline.

• Weather simulation — Delivered — checked by the atmosphere, daily.

• Infrastructure optimisation — Delivered — checked by an automated evaluator in the search loop and confirmed by fleet measurement.

• Engineering problem-solving — Partly delivered — strong where answer keys exist; 34% to 60% where a simulator is the judge; weakest where nothing checks open-ended modelling.

• Productivity — Partly delivered — measured only where tests and code review check the output.

• Autonomy — Partly delivered — measured only on tasks with automated scoring.

• Materials discovery — Contested — generation scaled by millions, expert characterisation did not.

• Autonomous labs — Early — promising exactly insofar as characterisation is reliable.

• Adoption — Early — blocked by the absence of an accepted accountability evaluator: a regulatory answer.

The correlation is nearly perfect, and it is not a coincidence. A generative system produces candidates. An evaluator decides which candidates are real. Where the evaluator is automated, trusted and fast, the system can search enormous spaces and the results survive contact with the world — this is why weather, chips and data-centre scheduling came first. Where the evaluator is slow, human-bottlenecked or absent, generation runs ahead and the result is a pile of plausible candidates nobody can certify.

This reframes the whole question. The promise of AI in engineering is not limited primarily by how smart the models are. It is limited by how much of engineering has been turned into something a machine can check. And building evaluators — simulators validated against reality, verification suites, test rigs, reference datasets, assurance cases — is itself engineering. It is arguably the most leveraged engineering work there now is.

12. The measurement lag

The second finding is methodological and it should embarrass the field a little, including the draft of this report.

Engineering-specific benchmarks are published months after the models they test were released, and they frequently test cheaper or open models for reasons of cost and access. SoM-1K evaluated GPT-4o, DeepSeek and Qwen models. FEABench evaluated Gemini 1.5 Pro, Claude 3.5 Sonnet and GPT-4o. The FE-exam studies used GPT-4 in 2023. Meanwhile the general frontier moved through several generations. The result is a literature in which the headline numbers about engineering capability are consistently those of models the frontier has already left behind.

This is a real gap in public knowledge. At the time of writing, as far as this library shows, nobody has published a rigorous evaluation of current frontier reasoning models on the core of physical engineering — mechanics of materials, structural analysis, thermofluids, circuit design from schematics — with perturbation controls and simulator-based grading. The sceptic who cites a 56.6% and the promoter who cites a coding benchmark are both extrapolating across that gap. Closing it is cheap relative to its value, and a European technical university with the relevant faculties is well placed to do it.

13. What this means for the engineer

If the evaluator is the constraint, several things follow for what an engineer is.

The engineer specifies. In every delivered case a human wrote the constraints: NASA’s list of mass, safety factor, interfaces, keep-outs, loads and frequencies; the objective function in AlphaEvolve; the sign-off criteria in chip design. Writing a complete, correct specification — including the keep-out zone for a technician’s hands — is the part of the work the generative system cannot do for itself, and its quality bounds the quality of everything downstream.

The engineer builds and trusts evaluators. The simulator, the verification suite, the validated reference case and the test rig are what turn a model’s output into a design. Knowing when a simulation can be trusted, and building ones that can, becomes more central, not less.

The engineer adjudicates what no evaluator covers. Trade-offs with no single right answer, novel configurations outside the validated range, and the question of whether a result is physically sensible. This is where the benchmarks still show a human lead, and it is the judgement McClelland means by “the algorithms do need a human eye.”

The engineer carries accountability. None of the delivered systems removed a human signature from the chain; the materials case shows what happens when the checking step is weak and a result is published anyway. The next report takes up who, legally, that engineer is.

None of this is a counsel of comfort. The capability curve in section 8 is steep, and the list of things that “only a human can check” is shrinking as evaluators are automated. But the direction of that change is itself instructive: every time a check is automated, the engineering value moves one step further up, into specifying what should be checked and deciding what the checks cannot see.

14. What would change this assessment

Toward a stronger promise. A rigorous evaluation of current frontier models on physical engineering showing near-expert accuracy with stability under perturbation and simulator-graded design success above 80% on a single attempt. A published randomised trial of AI assistance in structural, mechanical or electrical engineering practice showing measured speedup without increased error. Clean external reproduction of AI chip placement matching or beating expert and annealing baselines. Independent confirmation that a meaningful fraction of AI-predicted materials are novel and useful.

Toward a weaker promise. Evidence that learned surrogates in engineering simulation fail silently in normal use, not only under adversarial attack. A production failure traced to an AI-generated design that passed its evaluator. Late-2025 and 2026 productivity gains turning out, once selection effects are corrected, to be no better than zero.

Toward a different explanation. If systems without trusted evaluators start delivering reliably — if open-ended design, trade-off reasoning and drawing interpretation reach expert level with no automated checking in the loop — then section 11’s central claim is wrong, and the constraint really was model capability all along.

Close — the promise is real, and it is conditional

The promise of AI in engineering is not hype, and anyone who says otherwise has not looked at chip layouts shipping in three generations of TPU, a scheduling heuristic returning 0.7% of Google’s fleet, weather models beating the world’s best physics-based forecasts on more than nine in ten targets, or AI-evolved brackets flying on NASA instruments at a tenth of the development time. Nor is it a finished transformation: the industry has barely adopted it, the productivity evidence is almost entirely from software, the benchmarks trail the frontier, and the most ambitious discovery claim in the field was corrected with the word “novel” removed.

What connects every success and every failure in this record is a single condition. The machines deliver where something the organisation already trusts checks their work, and they overpromise where it does not. That condition makes the engineer’s job more important rather than obsolete, because the checks — what to specify, what to trust, what to test, and what to sign — are the engineering.

Written by the ENSI Foresight Division on the Engineer for Future library — 126 primary documents downloaded and indexed across twenty angles; the evidence for this report is concentrated in angles 08, 09 and 10, and every benchmark figure was checked against the full text of its paper, including which models were tested. Some facts come from web sources outside the downloaded library, and are listed here so they can be told apart: METR’s January 2026 Time Horizon 1.1 update (GPT-5 and Claude Opus 4.5 horizons, post-2023 and post-2024 doubling times); the Bluebeam survey of 1,000 AEC professionals as reported by ASCE; NASA’s article on AI-designed mission hardware (the two-thirds weight figure, stress-concentration comparison, named missions and McClelland’s quotation — the 10x and 3x figures are from his SPIE paper on disk); ECMWF’s experimental use of GraphCast and GenCast’s operational WeatherNext status; Cheetham and Seshadri’s critique of GNoME; the A-Lab critique and correction as reported by Chemistry World and indexed in PubMed; and current developer-reported GPQA and SWE-bench scores. An earlier draft of this report, “The Machines Are Worst at Engineering,” was withdrawn on 22 September 2026 for presenting a mid-tier model’s score as the frontier, misreporting a perturbation result, and misattributing a figure; it is retained in reports/_superseded/ for the record.